[00:21] <nigelb> lifeless: erm, how do I deal with that branch now?
[02:47] <lifeless> nigelb: I like the idea of having a helper which we can make better
[02:47] <lifeless> nigelb: there are some various utility modules around, have a look and see if you can find one to move the sort logic too
[02:47] <lifeless> then use a helper
[02:48] <nigelb> okay
[02:48] <nigelb> this means we've have to move all of the sorts into using the helpers, right?
[02:52] <lifeless> theres what, 3 so far ?
[02:53] <lifeless> alternatively
[02:53] <lifeless> file a bug saying 'we collate in C order'
[02:53] <lifeless> and reference that bug as an XXX: bug 12345 nigelb this collates using ASCII which is not as nice as unicode collation.
[02:53] <_mup_> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> < https://launchpad.net/bugs/12345 >
[02:54] <nigelb> okay, yeah makes sense
[02:57] <lifeless> either way is fine with me
[03:29] <LPCIBot> Project db-devel build #610: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/610/
[04:46] <wgrant> lifeless: Bah, pyunit-friends don't support python3 yet.
[05:07] <lifeless> wgrant: FSVO
[05:07] <lifeless> wgrant: testtools does, subunit does, fixtures does.
[05:09] <wgrant> lifeless: Ah, testtools' LP page doesn't mention 3.x support, but I see on PyPy it does.
[05:09] <wgrant> PyPI
[05:10] <wgrant> (although it isn't tagged as such)
[05:19] <lifeless> patches gratefully
[05:20] <wgrant> Shh
[09:59] <LPCIBot> Project windmill-db-devel build #362: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/362/
[10:28] <lifeless> rsyncing a no-op change to an archive: 16MB
[10:32] <wgrant> lifeless: The whole primary archive?
[10:32] <lifeless> the one carried by nz.a.u.c
[10:33] <wgrant> Ah
[10:33] <lifeless> rsync://nz.rsync.archive.ubuntu.com/ubuntu
[10:33] <lifeless> so i386, amd64, oni etc
[10:37] <lifeless> sent 16256452 bytes  received 31851 bytes
[10:48]  * lifeless sighs @ btrfs
[11:55] <NCommander> evening wgrant
[12:17] <NCommander> Was SUPERSEDED supposed to actually be in the indices are some point? I found a comment in the donminator.py that it was planned to hold the binaries in place, but it suggests they would remain SUPERSEDED
[12:17] <NCommander> (dominator.py:196)
[12:18] <NCommander> nm, disregard that
[12:27] <NCommander> So it appears Soyuz is actually keeping the binaries around in a SUPERSEDED state until the arch-all/arch-any skew is resolved, or a ne wSPR is uploaded
[12:27] <NCommander> https://launchpad.net/ubuntu/+source/emacs23/23.3+1-1ubuntu1
[12:28] <NCommander> but since SUPERSEDED isn't in the indicies, its effectively doing nothing beside taking up disk space
[12:28] <NCommander> ^- wgrant StevenK
[12:33] <wgrant> NCommander: What do you mean? Superseded is a final state.
[12:33] <wgrant> They will stay there forever.
[12:34] <NCommander> wgrant: right, but the dominator won't mark those packages for death
[12:34] <NCommander> its already checking the condition I need to check for, its simply doing the wrong thing
[12:34] <NCommander> I can refactor the code to keep these packages from being SUPERSEDED in the first place, but I can't understand why it exists unless the behavior of SUPERSEDED changed sometime in LPs development history
[12:35] <wgrant> NCommander: There's a comment there describing the behaviour that you desire, but it's not implemented.
[12:36] <NCommander> wgrant: no, it is
[12:36] <wgrant> Where?
[12:36] <NCommander> Its preventing packages in groups from being deleted (deathrow is not set)
[12:36] <wgrant> Where?
[12:36] <NCommander> I posted the link to a source that FTBFSed on ARM 7 days ago, but the i386 and other arches are being retained
[12:36] <NCommander> bah
[12:36] <NCommander> hold on, I need an unedited copy
[12:36] <wgrant> It does that for sources.
[12:36] <wgrant> Not binaries.
[12:37] <NCommander> Binaries get superseded only when multiple versions of them exist
[12:37] <wgrant> Yes...
[12:37] <wgrant> That is the definition of superseded.
[12:38] <NCommander> bah
[12:38] <NCommander> ok
[12:39] <NCommander> now I see it. So its close to what I need, I just need it to retain the arch_all binaries
[12:39] <NCommander> (or more specifically, the nominated_arch binaries)
[12:41] <wgrant> I think the correct thing to do is to do something just like the source check.
[12:41] <wgrant> But that only works if we subvert Julian.
[12:41] <NCommander> wgrant: Julian said it was acceptable to have multiple PUBLISHED records, just publishing SUPERSEDED was a nono
[12:41] <wgrant> Yes, but that's expensive.
[12:42] <wgrant> Because it means we have to analyse everything in groups.
[12:42] <wgrant> Not just stuff in SUPERSEDED.
[12:42] <wgrant> Although, having multiple PUBLISHED records long-term is just strange.
[12:42] <NCommander> We're already determining all the BPPHs per SPPH. The cost as it was is already being paid
[12:42] <wgrant> Only for superseded SPPHs.
[12:43] <NCommander> If SPPHs are checked first, BPPHs can be removed from the supersedication queue. That being said, I still feel its clearer to publish SUPERSED or implement a new publishing state
[12:43] <NCommander> YMMV
[12:44] <NCommander> The only other idea I can have is instead of have the packages go SUPERSEDED back to PUBLISHED, but I suspect thats just crack.
[12:44] <wgrant> SUPERSEDED stuff is often left published on disk. It's no stretch to include it in the indices.
[12:44] <NCommander> ^from
[12:44] <NCommander> Plus it makes the indices match the pool. Consistancy for the win.
[12:44] <wgrant> Yes.
[12:44] <wgrant> Which makes elmo happy.
[12:45] <StevenK> NCommander: "Consistency" has one e, and no a.
[12:45]  * NCommander throws a brick at StevenK 
[12:45] <StevenK> Whereas "pedant" has both.
[12:47] <NCommander> StevenK: do you have any feelings w.r.t. to publishing SUPERSEDED in the indicies? (or another sane solution to the above issue on archive skew?)
[12:48] <wgrant> It sounds counterintuitive. But they are on disk anyway.
[12:48] <wgrant> We would keep sources in indices too, except apt didn't support that until recently.
[12:48] <wgrant> Debian does it now.
[12:48] <StevenK> NCommander: Personally, it does sound counter-intuitive.
[12:49] <NCommander> am I the only one who was ever bugged by SUPERSEDED not being in the indices?
[12:49] <wgrant> I have long found it odd that there is unindexed stuff on disk.
[12:49] <StevenK> Keeping them PUBLISHED sucks, but so does putting SUPERSEDED in the indicies.
[12:50] <wgrant> StevenK: Why does putting SUPERSEDED in the indices suck?
[12:50] <wgrant> Debian does this now. The tools support it.
[12:50] <NCommander> Well, the other idea I had was PUBLISHED_BUT_SUPERSED status, but I suspect adding a new publishing state to Soyuz would be painful
[12:50] <wgrant> NCommander: Painful and entirely pointless.
[12:50] <NCommander> right
[14:13] <LPCIBot> Yippie, build fixed!
[14:13] <LPCIBot> Project db-devel build #611: FIXED in 5 hr 32 min: https://lpci.wedontsleep.org/job/db-devel/611/