=== _bjf is now known as bjf === jhodapp is now known as jhodapp|afk [04:07] rsalveti: I really just package it, I haven't looked at the code (qtsystems). Renato was working on qtpim, not qtsystems, so I think there isn't anyone truly familiar with it. [04:12] Mirv: right, no worries, I can take a better look once this multimedia stack lands [05:50] ^^^ security fix. [06:09] ScottK: do you need someone to review it, then? [06:09] Yes. Review/accept since it's my uplaod. [06:10] It's closely based on what the security team did for precise where the package is in Main. [06:11] * ScottK sleeps (since the alarm goes off in < 3 hours). [06:14] accepted [07:00] slangasek: Gold star for the insighttoolkit [07:00] ... upload [07:17] infinity: I'm sure I don't know what you're talking about; it's the middle of the night and I'm asleep [07:17] slangasek: Are you claiming the NSA backdoored your PGP key? [07:17] slangasek: (... and used that backdoor to fix bugs in... Ubuntu?) [07:18] no, merely suggesting that you're asleep [07:18] and dreaming [07:18] I'm neither elated, confused, or terrified, I can't be dreaming. [07:18] and while the dream me is flattered to be included, this is probably not healthy [07:20] ok, off to bed. 'night. :) [07:21] slangasek: Toodles. === psivaa-afk is now known as psivaa [08:27] is this the right place to ask questions about the cloud-archive? [08:27] I expect not, but I can't find a link to an IRC channel [08:35] Ubuntu Release Team: I'm not understanding something. After UIF and DocStringFreeze we are supposed to send emails to ubuntu-doc and ubuntu-translators right? I didn't see any of these e-mails sent to these mailing lists, and I don't believe there has been uploads without UI changes in the past few days [08:40] s/has been uploads without UI changes/all uploads are without UI changes/ [08:40] if you have an example, please raise it [08:42] smartboyhw: do note, e.g. packages on ubuntu touch images have a standing exception, so those do still change. [08:42] xnox, I know [08:45] Laney, I don't know if I'm correct, but I saw gnomeradio having icons removed (does that deserve a UIF?) [08:46] it's not installed by default, so no [08:46] Um, - Added option to disable audio loopback mode in Preferences settings. looks like a much better one [08:46] Laney, ^ [08:46] which package? [08:47] Laney, gnomeradio [08:47] not installed by default: not covered by UIF [08:47] https://wiki.ubuntu.com/UserInterfaceFreeze [08:47] Hmm [08:48] smartboyhw: typically UIFe are for things which have screenshots in documentation from default installs (ubuntu, edubuntu, xubuntu, lubuntu, kubuntu, etc) which blindly rewrite complete UI and thus confusing help / documentation readers. But minor tweaks and bugfixes are ok, "e.g. remove broken button" and etc. [08:48] * smartboyhw needs to check something then [08:48] Hmm, I might not need a UIFe then [08:49] xnox, any good tools to check if one package is in the seeds/metas? [08:49] (all of them) [08:50] seeded-in-ubuntu [08:51] Default install != supported (I believe). Yeah, no need UIFe:P [08:51] (supported seeds) === brainwash_ is now known as brainwash [09:00] sgran: #ubuntu-server would probably know more - the cloud archive is a kind of bolt-on thing and the release team proper doesn't run it [09:06] cjwatson: thanks, I'll ask there [09:26] slangasek: Thanks. === doko_ is now known as doko [10:23] infinity, the mpfr issue is a wrong-code issue. in th works ... [10:24] kde 4.11.2 going up, here comes the flood [10:24] queue mute #ubuntu-release [10:25] worth a go [10:25] queue mute unapproved #ubuntu-release [10:25] * Laney goes away [10:25] Hm, better rebalance i386/amd64 builders then [10:26] (done) [10:27] cjwatson: why the need for a rebalance and what elite powers enable you to do that? [10:27] doko: Awesome, thanks. [10:27] Riddell: We had all but one builder on i386 to finish the test rebuild. [10:27] Riddell: we had 7 i386 / 1 amd64 in order to try to finish the test rebuild faster [10:27] Riddell: powers> ~launchpad-buildd-admins [10:27] Riddell: this is all a workaround for not having cross-architecture builder pooling in LP, though [10:28] * Riddell learns new things [10:28] I think I'll work on fixing that around release week, or the week after. [10:29] The main thing I can't quite work out is how to calculate/represent queue lengths with pooled builders [10:29] Since the queues would no longer be per-architecture, and would sort of overlap in complicated ways [10:29] cjwatson: Queue lengths shouldn't be hard to estimate, it's just the general potential uglification of /builders I haven't quite figured out how to deal with. [10:30] I think the processor column has to just become a list of architectures per builder, but I have no idea how to adjust the "build status" sections [10:31] The actual dispatch bit is easy enough ... [10:32] cjwatson: The queue status, you mean? That should still be per-arch. I don't see it changing much, except that the number of builders per arch will go up, as it'll account for every builder that can build that arch. [10:32] cjwatson: The math to sort out the actual queue time isn't rocket surgery and shouldn't lead to results that are any more of a lie than the current lies. [10:32] infinity: But if we have 8 builders that can do either i386 or amd64, saying "amd64 8; i386 8" is grossly misleading [10:32] infinity: Even worse for the PPA case where (IIRC) some of the builders can do i386 amd64 and some can do i386 amd64 armhf [10:33] cjwatson: Nah, it's true. There are 8 builders capable of building that arch. [10:33] cjwatson: Also, all the PPA machines are x86_64 now. [10:33] cjwatson: Pretty sure I checked that last time this came up. [10:33] Yeah, but I think only the multi-guest ones can do armhf [10:33] It may be true, but I think it needs some refinement to be intelligible [10:33] cjwatson: Nope, everything can do armhf. It's built into lp-buildd (well, if the qemu-user-static bits are installed) [10:34] That doesn't mean we want to allow all of them to do it, mind you. [10:34] And are they installed everywhere? I thought I understood from wgrant that that wasn't true. [10:34] Right, so whether it's policy or capability, the effect is the same [10:34] cjwatson: Not sure if everything has qemu-user-static installed, but that's easy to fix if that's the result we want. [10:35] cjwatson: Anyhow, I'm okay with the reporting of "builders that are allowed to build this arch", even if it has overlap. And calculating potential queue depth from there is not particularly hard, with a bit of fudging. And that algorithm is all about fudging already. [10:35] I think I'd prefer a refactored build status table, separating "number of builders" from "queue length" [10:35] Perhaps [10:36] Or perhaps with some indication of how many builders are shared [10:36] Something like that ... [10:36] Well, we can redesign the page whenever. That's less interesting than doing the pooling and making the queue not be completely inaccurate. [10:37] The dispatch bit is ridiculously easy, since build records already come out in the order we want them. [10:37] I wonder if that's actually true [10:37] cjwatson: It is in all cases except a missing build created post-upload. [10:37] Are we sure that, given long i386 and amd64 queues, it wouldn't do all of one architecture first and then the other? [10:37] There's nothing today that would prove that one way or another [10:38] cjwatson: But on a fresh upload, when 5 builds are created, the records are sequential (or close enough) and have the same score. [10:38] cjwatson: So, if you use the score and the ID, you can get them out in the order that's sane. Score alone isn't enough. [10:38] If it's score then id, or similar, then fine [10:39] order_clause = " ORDER BY buildqueue.lastscore DESC, buildqueue.id" [10:39] Yeah, that looks OK [10:40] cjwatson: It actually has the curious side-effect, if dispatched correctly, to fix arch skew issues that you have on mismatches builder pools. [10:40] cjwatson: Cause all arches should always dispatch for the same source at almost the same time on pooled arches. [10:41] Well, in that case the work is something like (a) add many-to-many builder/processor DB table (b) add model/browser code to represent that and let us edit it in the API/UI (c) populate production data (d) change dispatch code and /builders to look at many-to-many table rather than single-processor mapping (e) clean up old DB bits at leisure [10:41] infinity: Yeah [10:42] I guess I'm spending today retrying KDE dep-waits in the right order [10:42] Someone should have muted queuebot. [10:43] At least the ones that aren't automatically determined [10:43] I tried and floundered [10:43] there's still time if you know the syntax [10:44] mute queue saucy-proposed [10:44] Added mute entry: ['#ubuntu-release', 'queue', 'saucy-proposed'] [10:44] Hah, Google just got me there. 2 seconds late. [10:45] doko: How long did the full rebuild test take on armhf? [10:46] (Not counting esys-particle) [10:46] I need to patch that to build a -data/-common/whatever package and put all those images in it. Crazy build times. [10:47] Or NO_PNG_PKG_MANGLE=1 if it doesn't make much size difference [10:48] Oh, or that, even if it does. :P [10:48] Well, if it does, optimise things statically first [10:48] But duplicating all that data in every arch:any package is Wrong(tm) anyway. [10:48] Not that I care that much since it isn't on images [10:48] A proper patch submitted to Debian seems saner. [10:49] Yeah [10:49] esys-particle_2.2.u1-2_armhf.deb (200.4 MiB) [10:49] It ain't tiny. [10:49] Hah [10:49] Curious how much the png optimisation saves. [10:51] * infinity grabs the source and tries a no-mangly build. [10:51] Riddell: What are the deepest bits of the build-dep chain here, and I'll accept them first? [10:51] kdelibs, usually. [10:51] It'd save a lot of time not to have to go round retrying things later because Kubuntu people never do :-P [10:51] infinity: IME there are several, though [10:52] cjwatson: kdelibs, kdepimlibs, kde-runtime are the ones I recall. [10:52] all the kdepim stuff, kde-workspace - I just don't know the ordering [10:53] And I don't actually see a kdelibs upload... [10:53] Well, kde4libs. [10:53] Ahh, cause it was done 18h ago. [10:54] Yay for that. [10:54] So kdepimlibs is probably pretty much at the bottom [10:55] Oh, there's akonadi, soprano, nepomuk in those build-deps [10:56] * cjwatson goes for nepomuk-core first [10:57] cjwatson: I already accepted them [10:58] https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph for the gory details [10:58] a widescreen monitor helps with that one [10:59] Ah [11:00] Well, let me know if there's anything you particularly don't want accepted early [11:00] w/g 23 [11:00] oops [11:16] infinity: I tried a full britney analysis run on universe, which has now been running for 14 hours (and there's no way to tell how far it's got). I'm going to kill it and try a different approach [11:16] I assume it was stuck in NP-complete hell [11:20] cjwatson: Eek. [11:21] cjwatson: I'm guessing that's probably a sign of things being excessively broken? It really shouldn't take that long to run, I'd think? [11:21] infinity, didn't look that close. below one week [11:21] cjwatson: Did you try on just a single arch first? [11:21] No [11:21] Not sure I believe time's output [11:21] real 849m23.490s [11:21] user 0m1.236s [11:21] sys 0m0.200s [11:21] It was sitting at 100% CPU for most of that time [11:22] doko: Hrm. Kay. I might still try to get a glibc 2.18 done this week, then, and we could do an armhf-only rebuild to see if there are any obvious regressions. [11:22] infinity: I probably need to rebase that britney instance on top of the one in proposed-migration, which has Debian's performance work [11:22] doko: Sadly, there are glibc testsuite regressions on 2.18 on armhf that I'd like to try to sort. Not sure if they'll bubble through to packages, though. [11:22] infinity: But, easier approach: just get proposed-migration to dump out a list of uninstallables as well as the count [11:22] It already has that information to hand [11:25] cjwatson: Oh sure, that wouldn't be a bad start. If we clean that up, maybe your full run won't take 17 days. :P [11:25] Hm, in fact it seems to have an option for that already [11:26] cjwatson: So, if you're curious, a non-mangled esys-particle is about 60MB larger. And builds in 26 minutes instead of 8 hours on x86. [11:26] Probably worth doing the split and submitting to Debian. [11:26] Mm, yeah, and probably worth optimising the PNGs statically then [11:26] Eating one x86 buildd for 8 hours is alright. Eating one on every arch hurts. [11:26] (Or pre-optimising in the source, sure) [11:27] So, most of the uninstallables are because britney doesn't understand udebs [11:27] cjwatson: She doesn't? In what sense? [11:27] Claims they're uninstallable [11:28] I don't know exactly why but this tallies with mutterings I've heard from the Debian release team :) [11:29] The uninstallables report takes an extra 30 seconds to generate, but I think that's acceptable :) [11:29] The udeb thing shouldn't be that hard to solve, one would think? [11:30] (And it doesn't block promotion) [11:30] infinity: Probably not [11:30] It is because there are some base deps provided by the d-i initrd that britney just doesn't know about? [11:30] I mean, ultimately, they're just debs. [11:30] Just really sketchy ones. [11:31] It probably needs the same algorithms germinate has to follow dependencies in the right world [11:31] I like how they're almost the inverse of click packages, in the sense that many udebs are nothing BUT maintainer scripts with complex dependencies. [11:33] infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt [11:34] I'll see if I can work out the udeb thing - it might just be a matter of inserting faux packages [11:34] And the very top of the list is something that should be arch-restricted. [11:34] It's Architecture: all [11:35] Yes, I know. I'm arguing it probably shouldn't be. [11:35] There'll probably be several of those showing up on i386 [11:35] Yeah, perhaps [11:35] Sadly, the crossbuild stuff fails due to britney not groking multiarch. [11:35] And wine is in that camp too, IIRC. [11:36] Overall, though, this isn't as bad as I thought it would look. [11:36] The udeb things might actually come down to incorrect kernel Provides [11:36] I thought we'd mostly fixed the kernel provides issues? [11:36] Ahaha no not for udebs [11:36] Cause when they go wrong, component-mismatches has a hissy fit and tries promoting random universe kernels. [11:37] kernel-image-BLAH is meant to provide FOO-modules for the various things that would be in *-modules-BLAH but are actually built in [11:37] But the Ubuntu kernel team has never got this right [11:37] apw: ^ [11:37] I know someone who'd be happy to get it less wrong. :P [11:38] I wonder if I can figure out the proper list [11:38] (Please wait a week while I update my saucy kernel remote :P) [11:38] Anyhow, a good chunk of this goes away when we clean up the last of NBS. [11:38] Yep [11:38] And the udebs things are mentally filterable. [11:38] All in all, it's way less ugly than I thought it would be. [11:40] infinity, i am listening [11:40] I can certainly work on cleaning some of this up [11:40] apw: The two lines above where I paged you. :) [11:40] and yes if there is something linux-image-foo.udeb should be providing to make your life easier we can do that [11:40] kernel-image-foo.udeb but yeah [11:40] I'll hopefully be able to come up with a patch shortly ... [11:41] so i assume that is any udeb which becomes empty, we should provide ... ish [11:41] cjwatson, well i am in testing mode for various things, so now is a very good time [11:41] Anything that's depended on by other udebs and that is built in [11:41] In practice, mostly filesystems [11:42] That's very probably what all the partman-* output there is for, along with all the other stuff that's in stages of d-i after partitioning [11:42] Since they tend to depend on (virtual package meaning that partman is done) [11:42] we have typically not understood the udebs relationship to d-i well enough, and made a hash of it as a result [11:42] I'm at 11% of "git remote update saucy" :) [11:43] this is a good time to repair that and once done to get some knowledge transfer into the team to keep it fixed [11:43] So, here's my logic [11:43] in the good-old-days (tm) i would have suggested a bar session at UDS for this [11:43] view http://archive.ubuntu.com/ubuntu/dists/saucy/main/debian-installer/binary-i386/Packages.gz [11:43] After a bit of "what's the underlying problem" you get to (say) partman-basicfilesystems [11:43] Depends: cdebconf-udeb, dosfstools-udeb, e2fsprogs-udeb, ext2-modules, fat-modules, partconf-mkfstab (>= 1.09) [11:44] And nothing provides ext2-modules, fat-modules, and the world explodes? [11:44] cdebconf-udeb, dosfstools-udeb, e2fsprogs-udeb, partconf-mkfstab are real packages not listed as uninstallable [11:45] fat-modules-3.11.0-9-generic-di Provides: fat-modules [11:45] But nothing Provides: ext2-modules [11:45] Oh, fat's not built in? [11:45] Not on i386 anyway [11:45] Maybe on other architectures - the kernel-wedge framework has plenty of provision for this being arch-specific [11:45] infinity, on arm probabally but here not so much [11:45] ext2 is probably built into the kernel, and the way you tell d-i this is by having kernel-image Provides: ext2-modules [11:46] Similar to the way that fs-core-modules Provides: *-modules for the filesystems it builds [11:46] d-i has probably actually been warning about this for ages but it hasn't mattered so much [11:46] Hah, no. fat-modules-udeb exists solely to ship msdos.ko, I think. [11:46] * apw wonders if the d-i logs have the info one needs to fix and validate soame [11:46] But if we can get it consistent then we can make proposed-migration have better behaviour - it could enforce that we don't accidentally make udebs uninstallable [11:47] The rest (fat, vfat, etc) are built in. [11:47] infinity: Mm, well, I think that can stay as it is [11:47] apw: http://people.canonical.com/~ubuntu-archive/proposed-migration/saucy_uninst.txt should be enough [11:47] That's where I'm starting here [11:47] cjwatson: I think that's just a happy accident of poor configs. :) [11:48] infinity, doesn't that mean there is someting other than fat in that udeb so that it actually still exists [11:48] apw: Right, msdos.ko [11:48] apw: Yeah, like I said, msdos... What he said. [11:48] There are probably a few other similar cases; I see efi-modules in a similar situation [11:49] so you would make britney check udebs as well, and then we would be unable to break it again [11:49] Just trawling [11:49] apw: It actually does right now - I think I was mistaken in saying it didn't [11:49] It's just that it's allowing things to be "as broken as before" (which is what it always does), so if it's always been broken... [11:49] Right [11:50] This has been broken since before proposed-migration existed, and so was grandfathered [11:50] heh ok perfect [11:50] But if we reach the goal of making the whole archive installable, and then hit people with large sticks when they try to force things in, britney can do its job much better. [11:50] works for me, i don't like being an outlier, which is why we now have the lists of udebs udebs and the like [11:51] i am all for sanity [11:51] I plan to spend a bunch of the rest of the cycle analysing and zeroing all this [11:52] cjwatson, so are you doing these udebs for me, or do you awnt me to [11:52] I'll come up with something [11:52] ack [11:52] Since I'll need to do the analysis anyway, I guess :) [11:52] It's kind of a pain to expect anyone else to do [11:52] There should probably be some automated way of doing it. [11:52] i was wondering the same [11:53] If we know all the udebs we could produce, and know all the udebs we did produce. [11:53] presumable i can look at the Depends in this package-list [11:53] Meh, analyse once and it'll be way easier from then on [11:53] Won't take that long [11:53] and for those which arn't in the list, and arn't packages in saucy, fail [11:53] Though, that assumes that all the ones we didn't produce are built-in, rather than a victim of anemic configs that lack features. [11:53] I'll check for that [11:54] well when cjwatson sends me over a patch for the missing one, i can check, or ... he can do everything and i can get a coffee [11:54] I used to help maintain the kernel udeb handling in Debian, it's no harder :) [11:54] apw: Get me one too. I think I've given up on sleep tonight being a thing. [11:54] heh, i bet we make it harder [11:56] Other problems not mentioned above: btrfs-modules, crypto-dm-modules, ext3-modules, ext4-modules, ufs-modules [11:56] I think that's the lot === jhodapp|afk is now known as jhodapp [12:53] Not all of KDE is through, but the bulk is, so unmuting [12:53] unmute queue saucy-proposed [12:53] Removed mute entry: ['#ubuntu-release', 'queue', 'saucy-proposed'] [12:57] thanks cjwatson [13:24] apw: I think http://paste.ubuntu.com/6179577/ would be a fine start [13:24] apw: I expect the ARM and PowerPC variants would need something similar [13:29] cjwatson, ok are you sending a patch or shall i suck that in from the pastebin [13:29] kernel-team@ is it still? [13:30] cjwatson, yep thats the one [13:33] apw: https://lists.ubuntu.com/archives/kernel-team/2013-October/033011.html [13:34] apw: Er, sending a followup [13:34] apw: Should be correct with the typo fix in https://lists.ubuntu.com/archives/kernel-team/2013-October/033012.html [13:35] (I can send a new patch if you need it) [13:35] cjwatson, na i can wangle it out [13:35] ta [13:47] Urgh, proposed-migration is crashing. Looking into it. [13:47] Should be happier once kcron builds, so I've just scored that up ... [13:47] kcron/i386 that is [13:48] Though maybe I can fix it otherwise ... [13:52] can we get someone looking at mir? we would need it for image build #75? (it's in the unapproved queue) [13:52] tested on desktop and touch [13:53] * didrocks wonders why unity-mir is blocked though in update_output.txt, no trace of success [13:53] didrocks: I'll do queue reviews once I'm 1) done with the current issue 2) actually awake ;) [13:53] (there is no new dependency, unity-mir should be enough on its own) [13:53] stgraber: thanks! [13:54] didrocks: It seems quite clear why it's blocked [13:54] * i386: indicators-client, libunity-mir-dev, libunity-mir1, unity8, unity8-autopilot [13:54] libunity-mir1 : Depends: libmirserver4 (>= 0.0.12+13.10.20131001) but 0.0.12+13.10.20130926.1-0ubuntu1 is to be installed [13:55] Which is presumably because it needs the new mir [13:55] * infinity looks at the new mir. [13:55] cjwatson: this is in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt? [13:55] Yes [13:55] * cjwatson fixes the proposed-migration crash [13:55] * didrocks doesn't see libunity-mir1 : Depends: libmirserver4 (>= 0.0.12+13.10.20131001)… [13:55] didrocks: The first line is in update_output.txt [13:55] didrocks: That's from him trying to install it. [13:56] didrocks: The second line was from "chdist apt-get saucy-proposed-i386 install libunity-mir1" as ubuntu-archive@snakefruit [13:56] cjwatson: ah, so it's not clear from update_output.txt, you need to try to chdist it, ok :) [13:57] Mirv told me there was no ABI break though… [13:57] It tells you that that package is uninstallable, just not exactly why [13:57] + [ Michael Terry ] [13:57] + * merge latest dev branch. [13:57] + [13:57] + [ Kevin DuBois ] [13:57] + * merge latest dev branch. [13:57] + [13:57] For that matter sometimes apt takes some persuasion to tell you exactly why [13:57] + [ Daniel d'Andrada ] [13:57] + * merge latest dev branch. [13:57] cjwatson: hum libmirserver4 is in suacy [13:57] Most. Informative. Changelog. Ever. [13:57] didrocks: Not in a high enough version. [13:57] infinity: I know… already told upstream they need to change their commit message in the future [13:57] libmirserver4 | 0.0.12+13.10.20130926.1-0ubuntu1 | saucy | amd64, armhf, i386 [13:57] 0.0.12+13.10.20130926.1-0ubuntu1 < 0.0.12+13.10.20131001 [13:58] oh right, I'm so used they don't have any kind of compatibility [13:58] cjwatson: ok, so, I'll try chdist next time I don't see it installing [13:58] thanks [13:59] Riddell: Um, what is this kate upload [14:00] + $(overridden_command) -- -DKDE4_BUILD_TESTS=false -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1 [14:00] Riddell: That really isn't a sensible thing to put in debian/rules for all architectures :-) Rejecting [14:00] shadeslayer: ^- [14:02] ack [14:02] Riddell: I didn't realize 4.11.2 was out? [14:02] cjwatson: good point [14:03] shadeslayer: ftp is open [14:03] okay [14:03] I'm guessing you want $(DEB_HOST_MULTIARCH) there, with "DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)" at the top if tat isn't done already [14:03] I didn't see a release announcement [14:03] (thanks) [14:04] cjwatson: /me prefers "include /usr/share/dpkg/architecture.mk" to get all the DEB_{BUILD|HOST}_* vars with caching and for free =) [14:04] xnox: whatever :-) [14:04] shadeslayer: no they open ftp the night or the morning before the announcement [14:04] xnox: (note my version isn't lacking caching) [14:04] okay :) [14:05] cjwatson: it's always executed though, even when not needed. architecutre.mk only execs on demand & then caches. [14:05] (not that it matters, it's not that expensive to call) [14:06] /join #kde-devel [14:06] shadeslayer, the whole channel? ;) [14:07] yep [14:07] shadeslayer, er, you do realize where you are talking right? .... [14:07] yep [14:07] ;O [14:07] wait [14:07] eh [14:07] no no no [14:07] LOL [14:07] smartboyhw: I read that as "The wrong channel" [14:08] and then went "yep" [14:08] shadeslayer, sure;) [14:08] Well, we welcome everybody anyway [14:09] cjwatson: \o/ thanks for removals. [14:10] np [14:19] xnox: cjwatson -DPYTHON_LIBRARY=/usr/lib/$(DEB_HOST_MULTIARCH)/libpython1.7.so.1 [14:19] look better? [14:22] shadeslayer: actually you want `python-config --ldflags` & -lpython2.7 [14:22] shadeslayer: cause there list libpython2.7.so in the proper /usr/lib/python2.7/config-$triplet/ directory, and will enable you to e.g. do python2.7 debug build. [14:23] shadeslayer: which is then e.g. under /usr/lib/python2.7/config-x86_64-linux-gnu_d/, vs /usr/lib/python2.7/config-x86_64-linux-gnu/ (_abi suffix) [14:29] xnox: I don't quite follow, but the problem is that kate can't find the python lib causing python plugins in kate to not work [14:29] shadeslayer: ah, if you need the runtime library, you are correct. [14:30] correct [14:31] mir/unity-mir passed proposed-migration now, I see [14:32] btw did the swith to xmir happen already? because I don't think I saw it running on the Beta 2 [14:33] no [14:33] okay [14:59] Riddell: can you confirm that the "a" in the version number for kate is intentional (not seeing it in the others, so wondering) [14:59] stgraber: yes it is, upstream rerolled the tar [14:59] ok [15:15] Riddell: hmm, kdeartwork contains what looks like a feature change (disabling a bunch of slideshow transitions) [15:16] stgraber: are you really reviewing every package? I'm quite impressed [15:18] Riddell: I sure am ;) [15:19] most of those take just a few seconds though as they're just re-versioning and updates to debian/control [15:19] stgraber: kdeartwork change is for bug http://bugs.kde.org/182104 [15:19] KDE bug 182104 in general "Specific transition effect of the slideshow screensaver is extremely slow" [Normal,Resolved: fixed] [15:19] Bug 182104 - Specific transition effect of the slideshow screensaver is extremely slow [15:20] it's removing a feature not adding it [15:21] Riddell: feature freeze also covers feature removal ;) [15:21] * stgraber looks at the bug report [15:21] introducing a negative feature [15:22] fine, I'll consider that fixing a nasty performance bug and let it through ;) [16:52] infinity, balloons: rbasak just raised that someone from the server team needs to signoff on server images [16:52] I'll pickup that honour for this cycle :-) [16:53] jamespage, :-) wonderful. I've already got a task for you then [16:53] nice [16:54] balloons, what do I need todo? [16:54] jamespage, Can you review the current tests and make sure they are all still valid and needed? In particular we have a few questions about the jeos tests [16:54] jamespage, http://iso.qa.ubuntu.com/qatracker/milestones/270/builds/54674/testcases [16:54] plars, if you around, let's sort this out with jamespage now for the final images ^^ [16:55] I see we are oversized as well [16:55] I guess that needs looking at [16:56] jamespage, umm, is server still trying to fit on a cd? the other images are not longer constrained to that size [16:56] whilst I'm here - we have a bit of a problem with python-lesscpy (bug 1233749) [16:56] Launchpad bug 1233749 in python-lesscpy (Ubuntu Saucy) "lesscpy command fails" [High,Triaged] https://launchpad.net/bugs/1233749 [16:56]