[14:03] <shadeslayer> hi, I was wondering, libkdcraw, marble and kdegraphics-thumbnailers are all valid candidates for moving, yet they haven't migrated over the last 3 days from -proposed
[14:03] <shadeslayer> any clue why?
[14:04] <cjwatson> "valid candidate" is only the first stage.  you have to look at update_output for the second
[14:04] <cjwatson> https://wiki.ubuntu.com/ProposedMigration
[14:05] <shadeslayer> ah
[14:05] <cjwatson> in this case: libkdcraw/kdegraphics-thumbnailers leaves calligra, digikam, digikam-dbg, kipi-plugins, kphotoalbum, krita, kubuntu-full, showfoto uninstallable
[14:05] <cjwatson> marble/kdeplasma-addons leaves calligra-reports-map-element, digikam, digikam-dbg, kexi-map-form-widget, libkgeomap-dev, libkgeomap1, showfoto uninstallable
[14:05] <cjwatson> unhandled soname changes?
[14:06] <cjwatson> libkdcraw22 -> libkdcraw23 and libmarblewidget16 -> libmarblewidget17, so looks like it
[14:07] <cjwatson> calligra's still building
[14:08] <cjwatson> at least digikam definitely needs a rebuild
[14:09] <cjwatson> and kphotoalbum
[14:09] <shadeslayer> I see
[14:09] <shadeslayer> makes sense
[14:09]  * shadeslayer can finally sort of understand update_output.txt \o/
[14:16] <shadeslayer> cjwatson: question , what does 85 and 125 mean in : skipped: libkdcraw (85 <- 125)
[14:17] <cjwatson> they're done/remaining counters in the list of packages currently being iterated over
[14:17] <shadeslayer> ah okay
[14:18] <cjwatson> but anyway, you don't want that bit - for packages involved in a transition, look for the first match following the "SUCCESS" line (which indicates the end of attempts to migrate sources one at a time, and the start of attempts to migrate groups)
[14:19] <seb128> I wonder if there are extra infos that could be put inline in that file to make easier to read/understand it
[14:19] <cjwatson> I'd rather put a frontend on it the way packages.qa.debian.org does
[14:19] <shadeslayer> ^^
[14:20] <cjwatson> http://release.debian.org/migration/testing.pl etc.
[14:21]  * seb128 basically does "look at the bottom of the page, for the source you are interested in, and try to install the packages listed on the arch lists"
[14:21] <cjwatson> and if we avoid mucking about with the format of the raw file, it will make it easier to put that kind of frontend on top
[14:21] <cjwatson> which is why I'm reluctant to touch it much
[14:21] <seb128> yeah, I'm not sure what makes it difficult to read/what would improve though :/
[14:22] <shadeslayer> seb128: well, it's just that you need to know how to read it :)
[14:22] <shadeslayer> if you look at it without knowing how to read it, then it doesn't make much sense
[14:23] <seb128> well, I sort of know how to find the info I want/need usually, but sometime I still manage to get it wrong
[14:23] <seb128> e.g when we had several transitions involved recently (e-d-s samba openchange) I managed to get really confused until Laney helped me
[14:35] <xnox> yeah, when there are multiple transitions, it seems to try all possible intersections of those, which means one needs to read the "middle one" where all transitions are tried together.
[14:40] <cjwatson> xnox: IME the most complete one is usually at the top
[14:40] <cjwatson> well, below the initial block ending in "SUCCESS"
[14:51] <shadeslayer> cjwatson: does valgrind need fixing wrt arm64?
[14:51] <shadeslayer> doesn't seem to be built for arm64
[14:51] <cjwatson> Don't know, you'll need to give me some context
[14:52] <shadeslayer> https://launchpad.net/ubuntu/+source/valgrind/1:3.8.1-5ubuntu1
[14:52] <cjwatson> Oh, presumably it needs to be ported
[14:52] <shadeslayer> ^^ no arm64 causes https://launchpad.net/ubuntu/+source/digikam/4:3.5.0-0ubuntu3/+build/5296982
[14:52] <cjwatson> digikam should only try to use valgrind on arches where it's available
[14:52] <shadeslayer> ack
[14:52] <cjwatson> it's never been "works on every architecture" kind of software
[14:53] <cjwatson> compare https://bugs.launchpad.net/linaro-aarch64/+bug/1236748
[14:53] <ubot2> Launchpad bug 1236748 in Linaro AArch64 cross-distro work "valgrind needs Aarch64 port" [Undecided,Triaged]
[14:54] <cjwatson> https://bugzilla.redhat.com/show_bug.cgi?id=926688 suggests "several months of work"
[14:54] <ubot2> bugzilla.redhat.com bug 926688 in valgrind "valgrind: Does not support aarch64 in f19 and rawhide" [Unspecified,Closed: cantfix]
[14:54] <shadeslayer> yeah, 95K lines of ARM specific code
[14:55]  * shadeslayer adds !arm64 to Build-Depends
[14:55] <cjwatson> Probably the wrong answer
[14:55] <shadeslayer> hm?
[14:56] <cjwatson> valgrind has "Architecture: amd64 armel armhf i386 mips mipsel powerpc ppc64 s390x x32" - better to match that than to invent an inaccurate negative version
[14:56] <cjwatson> that'd just need to be updated for the next port
[14:57] <shadeslayer> *nod*
[15:20] <cjwatson> could somebody in ~ubuntu-sru please review partman-basicfilesystems/precise?  apw eyeballed it a few days ago
[15:21] <stgraber> cjwatson: doing so now
[15:22] <ara> hello! could anyone in ~ubuntu-sru review https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=gnome-control-center, please?
[15:22] <shadeslayer> likewise for kscreen as well ^^ , it has a MRE
[15:22] <cjwatson> thanks.  I'd nag about grub2/precise as well but I'm currently waiting for upstream to reappear on IRC so I can jump on him about whether the latest iteration of the hotkey patch is ok
[15:23] <cjwatson> I'll take gnome-control-center
[15:23] <ara> cjwatson, thanks
[15:27] <cjwatson> shadeslayer: saucy, presumably - libkscreen too?
[15:27] <cjwatson> ara: done
[15:27] <shadeslayer> cjwatson: yep
[15:27] <ara> cjwatson, thanks!
[15:31] <cjwatson> stgraber: thanks
[16:36] <shadeslayer> cjwatson: thx
[17:28] <cjwatson> xnox: could you do another ubiquity/precise upload with the new partman-basicfilesystems in precise-proposed?
[17:28] <cjwatson> should be less busted now
[18:01] <xnox> cjwatson: ack.