[00:21] lifeless: erm, how do I deal with that branch now? [02:47] nigelb: I like the idea of having a helper which we can make better [02:47] 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] then use a helper [02:48] okay [02:48] this means we've have to move all of the sorts into using the helpers, right? [02:52] theres what, 3 so far ? [02:53] alternatively [02:53] file a bug saying 'we collate in C order' [02:53] 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?) < https://launchpad.net/bugs/12345 > [02:54] okay, yeah makes sense [02:57] either way is fine with me [03:29] Project db-devel build #610: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/610/ [04:46] lifeless: Bah, pyunit-friends don't support python3 yet. [05:07] wgrant: FSVO [05:07] wgrant: testtools does, subunit does, fixtures does. [05:09] lifeless: Ah, testtools' LP page doesn't mention 3.x support, but I see on PyPy it does. [05:09] PyPI [05:10] (although it isn't tagged as such) [05:19] patches gratefully [05:20] Shh [09:59] Project windmill-db-devel build #362: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/362/ [10:28] rsyncing a no-op change to an archive: 16MB [10:32] lifeless: The whole primary archive? [10:32] the one carried by nz.a.u.c [10:33] Ah [10:33] rsync://nz.rsync.archive.ubuntu.com/ubuntu [10:33] so i386, amd64, oni etc [10:37] sent 16256452 bytes received 31851 bytes [10:48] * lifeless sighs @ btrfs [11:55] evening wgrant [12:17] 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] (dominator.py:196) [12:18] nm, disregard that [12:27] 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] https://launchpad.net/ubuntu/+source/emacs23/23.3+1-1ubuntu1 [12:28] but since SUPERSEDED isn't in the indicies, its effectively doing nothing beside taking up disk space [12:28] ^- wgrant StevenK [12:33] NCommander: What do you mean? Superseded is a final state. [12:33] They will stay there forever. [12:34] wgrant: right, but the dominator won't mark those packages for death [12:34] its already checking the condition I need to check for, its simply doing the wrong thing [12:34] 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] NCommander: There's a comment there describing the behaviour that you desire, but it's not implemented. [12:36] wgrant: no, it is [12:36] Where? [12:36] Its preventing packages in groups from being deleted (deathrow is not set) [12:36] Where? [12:36] 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] bah [12:36] hold on, I need an unedited copy [12:36] It does that for sources. [12:36] Not binaries. [12:37] Binaries get superseded only when multiple versions of them exist [12:37] Yes... [12:37] That is the definition of superseded. [12:38] bah [12:38] ok [12:39] now I see it. So its close to what I need, I just need it to retain the arch_all binaries [12:39] (or more specifically, the nominated_arch binaries) [12:41] I think the correct thing to do is to do something just like the source check. [12:41] But that only works if we subvert Julian. [12:41] wgrant: Julian said it was acceptable to have multiple PUBLISHED records, just publishing SUPERSEDED was a nono [12:41] Yes, but that's expensive. [12:42] Because it means we have to analyse everything in groups. [12:42] Not just stuff in SUPERSEDED. [12:42] Although, having multiple PUBLISHED records long-term is just strange. [12:42] We're already determining all the BPPHs per SPPH. The cost as it was is already being paid [12:42] Only for superseded SPPHs. [12:43] 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] YMMV [12:44] 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] SUPERSEDED stuff is often left published on disk. It's no stretch to include it in the indices. [12:44] ^from [12:44] Plus it makes the indices match the pool. Consistancy for the win. [12:44] Yes. [12:44] Which makes elmo happy. [12:45] NCommander: "Consistency" has one e, and no a. [12:45] * NCommander throws a brick at StevenK [12:45] Whereas "pedant" has both. [12:47] 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] It sounds counterintuitive. But they are on disk anyway. [12:48] We would keep sources in indices too, except apt didn't support that until recently. [12:48] Debian does it now. [12:48] NCommander: Personally, it does sound counter-intuitive. [12:49] am I the only one who was ever bugged by SUPERSEDED not being in the indices? [12:49] I have long found it odd that there is unindexed stuff on disk. [12:49] Keeping them PUBLISHED sucks, but so does putting SUPERSEDED in the indicies. [12:50] StevenK: Why does putting SUPERSEDED in the indices suck? [12:50] Debian does this now. The tools support it. [12:50] 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] NCommander: Painful and entirely pointless. [12:50] right [14:13] Yippie, build fixed! [14:13] Project db-devel build #611: FIXED in 5 hr 32 min: https://lpci.wedontsleep.org/job/db-devel/611/ === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === Ursinha-afk is now known as Ursinha === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha-afk is now known as Ursinha === Ursula is now known as Ursinha