=== Tonio__ is now known as Tonio_aw === slank is now known as slank_away [00:43] zykes-: as I said yesterday, the apt_pkg.TagFile class can read Packages files [00:45] zykes-: I'm not aware of any *library* that can read Contents-* files; in your context I think it's probably reasonable to knock together your own quickly [00:45] cjwatson: I spotted an x lts backport package in -proposed that's in universe, xserver-xorg-input-mouse-lts-quantal. should this be promoted to main? [00:47] ajmitch: yeah, moved (along with -keyboard-), thanks - but the whole thing probably needs a complete audit which I'm not going to do now :) [00:47] I'm somewhat surprised you're still awake :) [00:48] thanks for that [00:48] just back from a Christmas dinner ... [00:49] anyway I have fairly mutable hours, you should be used to that by now :P [00:49] certainly [00:51] * xnox declares defeated by cmakes inability to be cross-compiled (from bootstrap)... for now... [00:53] xnox: dpkg-cross has helper bits for that [00:54] ah, if you mean cmake itself not sure about that [00:54] cjwatson: awesome, actually it does have cmake toolchain file, that should be possible to feed to cmake's bootstrap script. [00:55] there's stuff in dpkg-cross' man page about how to use it, if that actually turns out to be helpful [00:55] I fixed it to suck marginally less just recently [00:55] but haven't actually got an entire package cross-building with it yet - just got past some initial obvious errors [00:56] well, I was missing only 2 out of 9 magic variables needed to make it work. close but not enough. Will try cmake again later. [00:57] cjwatson: how often new builds are tried as eventually seen on http://people.canonical.com/~cjwatson/cross/armhf/raring ? Approx. ~once a week? [00:57] or is it continious? [00:57] on request [00:58] it's all still kind of manual [00:59] fair enough. [00:59] good night. [01:02] xnox: I've poked it now - you should have updated results by the time you get up === Amaranthus is now known as Amaranth [01:04] cjwatson: Oh, you don't have something importing to wanna-build on a regular basis? [01:05] cjwatson: (And by "something", I'd mean quinn-diff, if it still exists) === cpg|away is now known as cpg [01:33] cjwatson: will your reimport pick up new versions of build-dependencies that happen to land in raring now-ish? The valac I've just uploaded probably unbreaks a bunch of build-deps, but I don't know how many === cpg is now known as cpg|away === Tonio_aw is now known as Tonio__ === cpg|away is now known as cpg === cpg is now known as cpg|away === cpg|away is now known as cpg === Tonio__ is now known as Tonio_aw === chiluk is now known as chiluk_away === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [04:23] banshee appears to have been misbuilt somehow... it lists depends that don't exist ( future versions )... how could this have happened? build server misconfiguration? [04:29] psusi: In what release? === cpg is now known as cpg|away === cpg|away is now known as cpg === bregma is now known as bregma|away [05:11] psusi: i saw your bug. where are you installing banshee from, and what version of ubuntu is that? [05:15] psusi: apt-cache policy banshee? [05:15] huh, hang on, how old is libc6 2.6 anyway? the bug report complained that banshee was depending on libc6 2.7. [05:16] Erm, wait, the complaint is about libc6? What bug is this? :P [05:16] We have 2.7 in hardy... [05:16] https://bugs.launchpad.net/bugs/1091942 [05:16] Ubuntu bug 1091942 in banshee (Ubuntu) "Banshee is uninstallable due to broken depends" [Undecided,Incomplete] [05:16] that must have been a seriously old version of ubuntu.. [05:17] and he probably plucked the deb out of a later release [05:17] It does, indeed, list libc6 twice, but that's a non-issue (other than being weird). [05:17] banshee in raring does have a dependency on libc6 (>= 2.7), [...] libc6 (>= 2.16); but that's clearly not the cause of uninstallability [05:17] So, I'd like to see the actual error message. [05:18] and it's installable here [05:18] infinity: it's probably a result of dh_shlibdeps and dh_clideps both running. [05:18] (Why it's producing that dep is a different and curious question, mind you) [05:18] Second-guessing shlibs is usually not smart. [05:18] no actually shlibdeps is smarter than clideps [05:19] hyperair: why would dh_clideps reference libc6 | libc6.1? That's unhelpful [05:19] the issue is probably that ${shlibs:Depends} has libc6, and ${cli:Depends} has libc6 as well [05:19] hyperair: Yes, shlibdeps is smarter, that was sort of my point. [05:19] slangasek: clideps just gets it from the .shlibs file. [05:19] hyperair: shlibdes gets it right (>= 2.7), clideps is a lie. :P [05:19] slangasek: and clideps doesn't understand .symbols [05:20] Anyhow, the libc6 dep there isn't causing an issue, it's just silly. [05:20] hyperair: it most certainly isn't doing so here [05:20] the libc6 .shlibs file lists libc6. Only the libc6.1 .shlibs file lists libc6, and I'm pretty sure banshee wasn't built on an alpha. [05:21] i see libc 6 libc6 (>= 2.15) [05:21] but i don't see libc6.1. [05:21] hmm [05:21] Right, but not 6.1 or 0.1 [05:21] weird [05:21] So something's doing that manually to work around some other braindeadery. [05:21] Where does dh_clideps come from? [05:21] but i don't think dh_clideps does any weird things with libc6.. [05:22] oh there is a hack in dh_clideps [05:23] if you grep -C3 libc6 /usr/bin/dh_clideps you'll see it [05:23] Yeah, I'm there. [05:23] And lost as to why anyone feels this is necessary. [05:23] because dh_clideps is arch:all [05:23] If something links to libc6, dh_shlibdeps will pick it up. [05:23] And if it doesn't, you don't depend on it... [05:24] dh_clideps parses .dlls [05:24] as in mono p/invokes [05:25] stuff that appears in ${cli:Depends} comes from parsed .dll's. if libc6 shows up there, that means a mono .dll or .exe has a DllImport of libc6. [05:25] s/libc6/libc/, surely. [05:25] whichever [05:25] Otherwise, there's no way this hack would work. :P [05:25] eh well [05:25] it's overridden in /etc/mono/something [05:25] [05:26] yeah libc [05:26] I'm beginning to be sorry I asked. [05:26] :) [05:26] Anyhow, those deps can all be satisfied, so I'm still curious what psusi's bug is about. [05:26] see, the issue is that windows's .NET engine has no support for remapping library name imports [05:27] only mono does. so you have to target windows, and map it back to the appropriate one on other platforms [05:27] well this whole ugliness only happens when you try to call native code from within managed code [05:27] oh i see the culprit has vanished. [05:28] he's busy time travelling with his warty system [05:29] hahah [05:29] i wonder if i should wait or if i should just mark the bug invalid immediately [05:29] My guess would be a multiarch issue clouding things. [05:29] eh maybe [05:29] Since that sort of thing can get apt to print unhelpful messages that look like "all your libraries aren't installable", as he claimed. [05:30] especially if you try to use aptitude [05:30] that bug's still not fixed [05:30] Just double-checked, and banshee's installable on precise/quantal/raring. [05:30] great [05:32] Now, back to packaging glibc 2.17, which will obviously solve his problem. [05:32] Since 17 is a pretty big number. [07:03] Good morning === cpg is now known as cpg|away [07:24] ah, UDD discussion round umpteen === jiboumans__ is now known as jiboumans [08:06] good morning [09:09] pitti: shall we start a systemd/upstart thread to distract everyone? :-) [09:10] Laney: christmas holiday, the time for harmony :) [09:10] you need the flames to keep you warm in this cold cold winter [09:10] we need upstart maintained in UDD with a graphical Unity shell that sends all your system events to amazon [09:11] and with naked people, of course! [09:11] * pitti wonders if the old warty backgrounds package still exists somewhere in the mists of the interwebs === cpg|away is now known as cpg [09:16] naked people! [09:17] pitti, if you search on images.google.com for 'ubuntu calendar' you should be able to find them :) [09:17] http://ubuntu.ecchi.ca/wallpapers/, at the very bottom === henrix_ is now known as henrix [09:32] http://old-releases.ubuntu.com/ubuntu/pool/main/u/ubuntu-calendar-*/... [09:34] heh === Ursinha-afk is now known as Ursinha [09:49] RAOF: still here? [09:50] banshee was released into quntal-updates but it's uninstallable [09:51] Depends: libglib2.0-0 (>= 2.34.1) but 2.34.0-1ubuntu1 is to be installed [09:55] can I query e.u.c somehow to see if any instances of a crash have the SRUed glib installed? [09:56] infinity: I haven't made it regular because wanna-build's merge algorithm tends to involve retrying uninstallable-build-dep failures over and over again, and there are hundreds of those here so I don't want to overdo it - for now, I have a script I run every day or two [09:59] slangasek: should build against current raring+raring-proposed as of whenever the build starts - I'm not using an imported archive to satisfy build-deps or anything === Tonio_aw is now known as Tonio__ [10:12] I checked a lot of instances of bug #1044322 on e.u.c and none had the -proposed glib installed [10:12] bug 1044322 in glib2.0 (Ubuntu Quantal) "indicator-messages-service crashed with assert in g_menu_exporter_name_vanished()" [Medium,Fix committed] https://launchpad.net/bugs/1044322 [10:12] someone SRUy please to be advising [10:12] If I need to modify an existing Quilt patch in a package, and I'm working off the bzr branch, is it expected to have the ./pc quilt files included in the merge proposal ? [10:13] I did "quilt pop; {modify the patch};quilt push;quilt refresh" to update the patch, so some of the ./pc files got also modified [10:15] another way at it would be to work off the source package & submit a debdiff (this is for an upcoming SRU btw) [10:17] caribou: yes, please do "$ bzr add .pc" before committing. [10:18] caribou: easy test - $ bzr bd -S, should work. SRUs are typically easier to sponsor with debdiffs though. [10:19] +1 [10:19] UDD is just an unnecessary pain for both sides for SRUs [10:19] xnox: depends who I talk to :) some teams have asked me for Merge Proposals [10:19] (IMHO with my sponsor hat on) [10:20] the sponsoring into Ubuntu side is smoother with a diff [10:20] you might want MPs at some other stage, like submitting upstream [10:20] Do the importers not import all the -security and -updates uploads? [10:20] If not, is there a bug about this? [10:20] (when I say "easier" I imply that a subjective majority of sponsors prefer that. I prefer UDD branches for everything: as then it doesn't matter if it's a new package, SRU, merge, new upstream release & i can work with it) [10:20] pitti: I tend to agree too; working off the source pkg/debdiff is easier for most of the changes [10:20] they do, but an MP for the first-ever SRU doesn't work as there is no branch to propose _to_ [10:21] and then, almost nobody can modify the status of those MPs, so everyone pings me about "please close/reject/wip this branch", etc. [10:21] Oh, there's no "we're releasing now, so populate all the release branches" action? [10:21] plus, UDD and quilt patches are just a pain [10:21] caribou: I find bzr branches to be the best tool to create the debdiff: out of tree builds are awesome and vcs is awesome for work-in-progress. In the end generate a source package, debdiff & done. [10:22] Why? I thought the advantage of UDD was to have stuff in branches to generate diffs, etc. With Format:3.0(bzr) being quite as experimental as it is, I would expect everyone to use quilt. [10:22] xnox: you obviously do not work a lot with debian/patches/ :) [10:22] heh, I do =) [10:22] for native packages I fully agree [10:23] * xnox has scripted around quilt patches. [10:23] but UDD only keeps precisely those bits under "proper" version control which we are not interested in modifying [10:23] Oh, that's a different problem then :) [10:23] but with the bits that we do it still requires quilt, plus keeping track of pre-applied patches in the actual source, not forgetting .pc, and so on [10:24] oh argh, I'm being drawn into that discussion again, I'll STFU [10:24] :D [10:24] xnox: from a bugfixing pow, debdiff are simpler, but I can understand the value of UDD from a developer's pow [10:24] pitti: Sorry for dragging you into that discussion: I did appreciate the better understanding. [10:24] pitti: thanks for the clarification though :) [10:24] heh, no worries :) === mcclurmc_away is now known as mcclurmc [10:42] bug #1091942 [10:42] bug 1091942 in banshee (Ubuntu) "Banshee is uninstallable due to broken depends" [Undecided,Incomplete] https://launchpad.net/bugs/1091942 [10:42] it looks like banshee was released from -proposed before its dependencies. [10:42] fixed [10:42] ah [10:42] thansk [10:43] Laney: as in, glib has been released from proposed? [10:43] right [10:43] okay, thanks [10:43] I saw you talked about it last night, how come nobody did it then? [10:44] because nobody knew what was wrong [10:44] psusi filed a bug report with hardly any information [10:44] but it was uninstallable in updates [10:44] it just said that "a lot of libraries had the wrong version" but it didn't say which ubuntu he was running [10:44] in fact, he said that banshee depended upon libc6 2.7 [10:44] while he only had libc6 2.6 [10:44] that really threw us off [10:45] libc6 2.6 was during hardy. [10:45] before that, even, since it looks like hardy has 2.7 [10:46] Oh, urgh. Why did banshee pick up a depend on that glib? Stupid dh_clideps. [10:46] http://people.canonical.com/~ubuntu-archive/testing/precise-updates_probs.html FYI [10:46] heh [10:46] RAOF: or precise-proposed's glib bumped shlibs? [10:47] that's most probably it. [10:47] it could be -V [10:47] not precise, quantal [10:47] pitti: That would be unusually obnoxious. [10:47] and it has symbols [10:47] which clideps doesn't understand ... [10:47] yes, clideps only uses shlibs [10:48] * hyperair brb. leaving work [10:48] You know, I bet it wouldn't be *that* hard to get clideps to use symbols. [10:48] * RAOF foretells of some more godforsaken perl hacking in his future. === Tonio__ is now known as Tonio_aw === Zilvador_ is now known as Zilvador [10:53] RAOF: can you clear the x sru queue for precies? :> === tkamppeter_ is now known as tkamppeter [10:54] * RAOF did a bunch of precise unapproved clearing this morning. [10:54] mlankhorst: What are you after? Not that I'll get to it today; it's 10pm. [11:07] RAOF: 'xorg' + blobs === Tonio_aw is now known as Tonio__ === _salem is now known as salem_ === mcclurmc is now known as mcclurmc_away [11:28] jibel: Hi - did you get my mail with further questions about britney/autopkgtest integration? [11:29] I was hoping to make some progress on that before EOY but am blocked on those questions [11:32] cjwatson, Hi, I did, I've been side tracked by other things and delayed my reply, sorry, replying now. [11:32] great, thank you === Tonio__ is now known as Tonio_aw === cpg is now known as cpg|away === mcclurmc_away is now known as mcclurmc [11:58] ev: s3 merge> yay! that means the charms can now be updated to just lp:daisy? [12:00] cjwatson: so is bug #917708 officially fixed? can the "workaround" applied to affected packages be dropped? [12:00] bug 917708 in Launchpad itself "Launchpad does not recognize Arch = any-arm" [Low,Fix released] https://launchpad.net/bugs/917708 === bregma|away is now known as bregma [12:07] blackz: yes [12:11] blackz: I didn't know there were outstanding workarounds or I might have dropped them myself :) [12:13] cjwatson: https://launchpad.net/ubuntu/+source/bitcoin/0.6.2.2-1ubuntu1 for example [12:15] feel free to revert that === odifis_ is now known as oDiafanos [12:39] Hi, nvidia-current does not build with linux-image 3.5.21-generic on precise (there is a 3.5 kernel packaged on precise) [12:42] pitti: yes :) [12:42] pitti: working on integrating it into lp:~ev/daisy/prodstack-prep [12:54] bambee: but nvidia-updates does build. [12:54] bambee: also note ubiquity sru comment: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1070427/comments/24 [12:54] Ubuntu bug 1070427 in ubiquity (Ubuntu Quantal) "Ubiquity removes kernel headers, fails to build nonfree drivers" [High,Triaged] [12:56] nvidia-current-updates you said, interesting, looking [12:56] thanks === Quintasan_ is now known as Quintasan [13:33] cjwatson, I replied and updated the interface on lillypilly to never overwrite sources.list, so it can uses the apt index directly. === yofel_ is now known as yofel === chiluk_away is now known as chiluk === chiluk is now known as chiluk_away === chiluk_away is now known as chiluk [14:06] pitti, I finished enabling jhbuild for gnome on raring [14:06] https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/ [14:06] it's written Quantal but is really Raring [14:07] I filled a ticket to have that changed [14:07] pitti, currently it builds gnome-core moduleset, check is disabled [14:27] jibel: merci! il semble mieux que j'ai pensé [14:30] pitti, indeed, I think I can enable checks, what do you think? [14:31] jibel: in my jhbuild I have quite a lot of failures, but indeed let's enable them so that we have something to point to for upstream reports [14:31] that's the point anyway [14:32] jibel: any idea what this is about? https://jenkins.qa.ubuntu.com/view/Quantal/view/JHBuild%20Gnome/job/jhbuild-amd64-gnome-doc-utils/1/console [14:32] ah, so control-center is an actual bug, it shouldn't hard-depend on systemd [14:32] xnox: I'm preparing the SRU for https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368 on Precise [14:32] Ubuntu bug 833368 in resource-agents (Ubuntu) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress] [14:33] xnox: should there be a specific task for Precise in the bug ? === Ursinha is now known as Ursinha-afk [14:37] pitti, wrt. gnome-doc-utils, I started the build while there is nothing to build, and it was waiting for something that will never happen [14:38] jibel: ah, so that was a genuine timeout === Tonio_ is now known as Tonio_aw [14:46] xnox or anyone who can answer, just so happen that he is assigned to that bug [14:48] caribou: well, I need to sponsor this into raring first before it goes into precise. & also sru for quantal will be needed. [14:48] xnox: it's already fixed in Q & R [14:49] xnox: let me double check again, but I tested both and only found the bug in Precise [14:51] caribou: ok, I have adjusted statuses and opened the task for precise. please correct me if the per-series tasks are wrong now. [14:53] xnox: looks good. I'll assign myself to the bugs and will check with ivoks on the resource-agent side when he's back from vacation [14:53] xnox: just checked Quantal and it is indeed fixed but I'll confirm with ivoks [14:54] heh? [14:55] caribou: act fast; i'm not on vacation today and tomorrow; but i will be starting on friday :) [14:56] ivoks: so will I, so I want this one SRUed before I leave [14:56] caribou: xnox first glance is that this bug is *invalid* in Q and R and will be invalid in P once lvm2 monitoring bug is fixed === slank_away is now known as slank [15:00] ivoks: are you saying that resource-agents should not be part of the bug at all? === Tonio_aw is now known as Tonio_ [15:13] xnox: caribou overall view of the problem is that clustered lvm requires monitoring to be on [15:13] xnox: caribou in ubuntu, default is monitoring off [15:14] xnox: caribou and it's off by a change in the code, not by choosing within lvm.conf [15:14] xnox: caribou resource-agents assumes that monitoring is set to on, if one wants to use it [15:15] xnox: caribou since we disable monitoring in the code of lvm, even if someone enables monitoring in lvm config, that setting is ignored [15:15] * xnox really should setup & learn clustered lvm & add automatic tests for it..... [15:15] xnox: caribou therefore, user enables monitoring in lvm.conf and finds out that lvm commands still don't enable monitoring [15:16] xnox: caribou once we fix lvm in precise to use config option to disable monitoring, instead hardcoding it in the code, all problems go away [15:16] ivoks: this is the SRU I'm preparing, right ? [15:17] caribou: correct [15:17] ivoks: the one we discussed yesterday [15:17] xnox: ivoks: the debdiff is ready, changes tested on precise so the SRU is about to go [15:17] if you need help in testing it, let me know [15:18] caribou: well, attach debdiff to the bug report & i can test & sponsor it. [15:18] ivoks: I've tested monitoring = [0|1] in /etc/lvm/lvm.conf and it works as designed [15:18] caribou: note that for an SRU the bug description should match https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=StableReleaseUpdate#SRU_Bug_Template [15:18] caribou: and without the rest of the changes in the code? [15:18] xnox: yep, was waiting for the Precise task you just added to add the SRU template [15:19] ivoks: with the patch you gave me yesterday [15:19] caribou: excellent [15:19] ivoks: it basically reverts the hardcoding and changes doc/example.conf.in [15:19] yep [15:20] caribou: you might build that package and ask people in the bug 833368 to test it [15:20] bug 833368 in resource-agents (Ubuntu Raring) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress] https://launchpad.net/bugs/833368 [15:20] ok, I'm updating the template then will subscribe the proper people to it [15:20] ivoks: I already have a PPA ready for testing if someone wants to [15:21] caribou: there are few candidates in that bug [15:21] ivoks: well testing a package from ppa will not speed up sru.... as we want people to test the -proposed package. [15:21] xnox: ah, right [15:21] xnox: yeah, usually I refrain from doing that, so people don't end up using my PPA instead of the fix [15:22] ivoks: and building a new pkg from the debdiff can be done if they want to [15:22] caribou: ivoks: as far as I understand resource-agents task should be removed or marked as "invalid" since the bug is in the lvm package. [15:22] caribou: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/833368/comments/31 target this guy [15:22] Ubuntu bug 833368 in resource-agents (Ubuntu Raring) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [Undecided,In progress] [15:23] ivoks: ok [15:23] caribou: ask him to revert his changes [15:23] caribou: and, of course, test the package from proposed, including changing monitoring to 1 in lvm.conf [15:24] ivoks: yep, that will be done as well === Ursinha-afk is now known as Ursinha === Tonio_ is now known as Tonio_aw [15:51] Are ubuntu-sponsors automatically suscribed when a merge proposal is created? [15:51] if the merge is targeted to the right branch, yes [15:52] check http://reqorts.qa.ubuntu.com/reports/sponsoring/ if you're in doubt [15:57] slangasek, Laney: thanks [15:58] pitti, look http://10.98.0.1:8080/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-nautilus/2/ failed [15:58] pitti, commit was 34 min ago :) [15:58] looks like our testing is working [15:59] https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-nautilus/2/ for the public address === doko_ is now known as doko [16:05] doko: do you know if python2.7 has had recent multiarch changes? [16:06] Riddell, yes [16:08] doko: mm, poor old cmake seems to be confused [16:08] Riddell, about what? [16:08] Riddell: i almost have a working patch for cmake to unbreank FindPython [16:08] Riddell: sorry for the delay. === amitk is now known as amitk-afk [16:08] doko: it can't find pyconfig.h which has been moved to a multiarch dir [16:09] xnox: oh? [16:09] I'm using this workaround currently http://paste.kde.org/627974/ [16:09] Riddell: do you know who did original debian-multiarch patches for cmake? /me wants a review. [16:09] Riddell: that workaround is fine, but it does not scale across all of cmake code for python2.7 =/ [16:09] xnox: might have been slangasek? [16:10] (there were only a couple of packages for python3) [16:15] xnox: MoDaX did them [16:17] slangasek: heh a comrade =) === Tonio_aw is now known as Tonio_ [16:21] doko: were you interested in working on bug 914631 ? [16:21] bug 914631 in mesa-demos (Ubuntu) "[mir] mesa-demos" [Wishlist,Confirmed] https://launchpad.net/bugs/914631 [16:23] not now [16:27] jibel: hah -- unpackaged/undeclared dependency === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ [17:05] xnox, when will you commit the cmake fix? wanting to start the test rebuild tomorrow [17:08] doko: ha. ok. let me do the cmake fix now & come back to upstart tomorrow. [17:14] does someone here has Samsung Chromebook (arm one)? === Tonio_ is now known as Tonio_aw === deryck is now known as deryck[lunch] [17:34] hello everybody, short question: is it possible to find out which packages are depending on an individual one? e.g. which packages are depending on libc [17:34] armor_xt: apt-cache rdepends [17:35] though the outpout for libc6 may be pretty long ;) [17:35] (16k) [17:35] great, thank you! [17:35] I was looking in the apt-get *cache evironment, but couldn't find it === fisted_ is now known as fisted [17:35] stgraber, *lol* was just an example [17:39] stgraber: apt-cache rdepends is poorly-named, it actually lists packages with *any* relationship (including breaks and conflicts) [17:39] armor_xt: reverse-depends from ubuntu-dev-tools is a bit more reliable on this score. [17:40] (And also acts on all architectures, rather than just the one(s) you have in your apt cache) [17:41] infinity: indeed. Main brain still isn't used to reverse-depends (and reverse-depends -b for build-dep) :) [17:41] src:foo is awesome too [17:42] Of course, the CGI may be having a hissy fit right now. I can't get it to spit out any useful responses... [17:42] Oh, there it goes. Probably just overloaded. [17:47] jo [17:47] Are ubiquity dev's available? [17:47] Can you tell me where can I change the font for the terminal in ubiquity while installing? [17:47] at the bottom [17:48] that'd be in the gtk theme [17:48] we don't explicitly configure the theme for that part of the ubiquity UI, we just use the standard gnome vte widget [17:48] I talk about changing the font, the installer uses for the embeded terminal [17:48] the font is different for the embedded terminal. [17:48] that is not ubuntu mono [17:49] gotwig: oh, actually, we do hardcode the font [17:49] ./ubiquity/frontend/gtk_ui.py: self.vte.set_font_from_string("Ubuntu Mono 8") [17:49] lol? xD [17:50] stgraber, thank you for your quick help [17:50] stgraber, may I show you the bug report, I want to fix? [17:50] https://bugs.launchpad.net/bugs/1072426 [17:50] Ubuntu bug 1072426 in elementary OS "Ubiquity using incorrect font for monospace output" [Low,New] [17:51] When I would change the font to e.g Droid Sans Mono, would it use that font for the terminal? [17:52] Could it be that your image isn't shipping "Ubuntu Mono" in the live environment, and X is doing a near-match lookup and finding something uglier? [17:52] infinity: on your system where you get the "disk drive for /tmp is not ready yet" error, do you have crypted swap (on its own partition, not via LVM)? [17:52] gotwig: you can try, just edit gtk_ui.py directly on the live media [17:52] infinity: Nope, no LVM or encryption on this machine. [17:53] gotwig: it should be either under /usr/lib/ubiquity/ or /usr/share/ubiquity/ (can't remember, sorry) [17:53] slangasek: Just a big, fat / [17:53] stgraber, can you tell me, how to test such stuff, demo an installation :X? [17:53] infinity: no crypted swap, even? Ok, then that's not a commonality with bug #1091792, drat [17:53] slangasek: Though, I haven't seen the bug since I reinstalled, so maybe I accidentally made it go away. :/ [17:53] bug 1091792 in mountall (Ubuntu) "The disk drive for /tmp is not ready yet or not present" [Undecided,New] https://launchpad.net/bugs/1091792 [17:53] heh [17:53] gotwig: you could write a gtk software using the same vte code, or just run a test install in a vm [17:54] slangasek: I reinstalled to correctly 4k-align my partitions (and switched from GPT to MBR at the same time and ditched EFI), so I've probably changed far too many variables to be of use. Unless the bug comes back anyway. [17:54] thank you really much [17:54] you *ditched* EFI? Luddite [17:54] slangasek: I sure did. [17:55] can someone upload packages from bug #1085392 so SRU process can start? [17:55] gotwig: usually on #ubuntu-installer channel, what's up? [17:55] bug 1085392 in Cross distro support for Samsung Chromebook (ARM based) "Merge Chromebook UCM profiles into ALSA packages" [Critical,Triaged] https://launchpad.net/bugs/1085392 [17:55] xnox, I've already got help I guess, thx === chiluk is now known as chiluk_away [17:56] hrw: Why are we SRUing Chromebook userspace support back to Q and P? It's not like we ship kernels. [17:57] infinity: because users use 12.04 and 12.10 with chromium kernel? [17:57] infinity: I think this falls under the "hardware non-disablement" policy for SRUs, doesn't it? [17:57] infinity: I created chromium kernel package today - will build for my ppa in 14+ hours [17:58] (we don't have to support the hardware, but maybe we shouldn't set it on fire :) [17:58] slangasek: Yeah, in this case, I'm okayish with it because it melts laptops. [17:58] slangasek: I'd forgotten about that until I re-read the bug and the test-case. :P [17:58] :-) [17:58] :) [17:59] hrw: I'll look at both these diffs. I have a nagging suspicion I might also need to re-fix PandES in Q while I'm at it (as I did with the R upload) [17:59] infinity: iirc Q has pandaes but P does not [18:00] Oh, so maybe the ES stuff was dropped between Q and R? That could be. I forget the history. [18:00] Anyhow, I'll poke 'em sometime today. [18:00] infinity: thanks [18:05] slangasek: vala cross> you seem to have managed to get unity-lens-music and unity-lens-shopping cross-building, at least [18:05] huzzah [18:15] slangasek: Good job on fixing the most contentious package in the archive? [18:15] infinity: which one is that? [18:15] (unity-lens-shopping) [18:16] ah, heh [18:30] doko: the fix will make sure that PYTHON_INCLUDE_DIRS has the correct both paths & work for all pythons[2,3]. but many packages still use deprecated PYTHON_INCLUDE_PATH & those will still need manual fixing. === deryck[lunch] is now known as deryck === henrix is now known as henrix_ === mcclurmc is now known as mcclurmc_away === chiluk_away is now known as chiluk [19:13] pff, why is gobject-introspection FTBFS due to a *libtool-generated linker script*? [19:18] ah, because I screwed up a symbol name, hee [19:56] barry: ping [19:56] slangasek: pong [19:57] barry: hey, so I have most of a python3 port now at lp:~vorlon/ubuntu/raring/gobject-introspection/python3/ [19:57] barry: the most recent "last" issue I have is DictMixin -> MutableMapping telling me that I need to implement __len__ and __iter__... where would I find documentation on the right way to do this? [19:59] * barry looks [20:00] slangasek: this has some examples:http://docs.python.org/3/library/collections.abc.html#collections.abc.MutableMapping [20:01] slangasek: and this some additional background: http://docs.python.org/3/reference/datamodel.html#object.__len__ [20:13] stgraber, it worked. Thx [20:14] xnox: mdeslaur seems to have found your ubiquity-desktop-background-broken-in-raring-VM bug [20:14] xnox: bug #1080674 [20:14] bug 1080674 in xserver-xorg-video-cirrus (Ubuntu) "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Undecided,Confirmed] https://launchpad.net/bugs/1080674 [20:15] aha. good. [20:17] doko: Riddell: cmake uploaded, if packages use standard FindPythonLibs & PYTHON_INCLUDE_DIRS they should be all multi-arch ready.... if not patch them to use system FindPythonLibs & PYTHON_INCLUDE_DIRS (instead of _DIR or _PATH) [20:25] slangasek: IIRC I did that in python-debian, if you want a cargo-cult source for MutableMapping stuff [20:26] or maybe in germinate [20:26] cjwatson: barry hit me over the head with a pointer to the stock OrderedDict instead :) [20:27] collections.OrderedDict [20:27] if that's appropriate, sure :) [20:28] IIRC it requires 2.7, so upstream might raise an eyebrow [20:28] yeah, i was gonna ask how far back you needed to support [20:28] I just wrapped the import with a try [20:29] they can fall back to their existing implementation for python2.6, that's fine [20:34] OK; failing that I believe MutableMapping is in 2.6 [20:35] which I believe is the approach I took in germinate, albeit for something less stock than an ordered dict [20:47]