[00:03] hallyn, slangasek: Found it. [00:03] # Consult white-list to determine whether to enable werror [00:03] # by default. Only enable by default for git builds [00:03] z_version=`cut -f3 -d. $source_path/VERSION` [00:04] qemu-linaro-1.0-2011.12/VERSION:1.0 [00:04] qemu-linaro-1.0.50-2012.01/VERSION:1.0.50 [00:04] slangasek: So -Werror gets enabled becuase there's a microversion. [00:05] aha! :) [00:05] Sorry, poor cut/paste job. The first three lines there are from configure. the last to are the VERSION files from the older and the newer qemu, respectively., [00:05] *last two [00:05] right, so maybe we should disable that again in the package for now [00:05] Bit of a brain bender there :) === kalosaurusrex is now known as albrigha [00:11] soren: That error message suggests that you'll be trading a build failure for a run-time crash, though? [00:16] RAOF: clearly preferrable :P [00:31] RAOF: pretty unlikely, really [00:32] I suspect spice-protocol is using a wrong integer type for "int that can store a pointer" [00:32] slangasek: Maybe my experience is atypical, but for me that error generally indicates someone's going to try to jump through the low 32 bits of a 64bit pointer :) [00:33] RAOF: yes, but this error *only* occurs on *32* bit systems :) [00:33] Ah. Context! [00:48] micahg: Absolutely not, it's yours [00:48] micahg: thanks for checking [01:02] SpamapS: were you specifying mtrack in your xorg.conf or something? You have a macbook air if I'm not mistaken right? synaptics works absolutely fine on these [01:10] SpamapS, I closed out the bug with an explanation of what's going on [01:11] SpamapS, thanks for filing it, I hadn't really looked at mtrack until this. [05:11] Good morning [05:39] I've uploaded mesa 8.0~rc2 which needs some help from an archive admin to push it through NEW, it adds libxatracker which is needed by xserver-xorg-video-vmware (and demoed at FOSDEM tomorrow I'm told..) [05:39] so if someone could give it a push once it's uploaded, that'd be great [05:40] ah, it's not yet in the queue [05:40] yeah it'll take some time to build too [07:58] pitti: Bug #924181 looks like apport is trying to set a tag with capital letters in it, which is forbidden. [07:58] Launchpad bug 924181 in launchpadlib "unable to log bugs with ubuntu-bug for unity or unity-2d" [Undecided,New] https://launchpad.net/bugs/924181 [08:08] wgrant: ah, thanks! will adjust accordingly [08:09] pitti: Thanks. [08:16] pitti: x86 mesa built. can you accept the new binaries now, or should the other archs be finished building before accepting? [08:16] tjaalton: we usually wait for most arches; if it's very urgent, I can accept them now [08:16] well I don't know how long the arm* and powerpc builds take [08:17] I can check and get back to you [08:17] tjaalton: I'm not that concerned about ppc -- it's notoriously behind anyway [08:18] well armel will take around 11h :) [08:18] but maybe armhf is faster? [08:18] ok, looking [08:18] thanks [08:20] good morning [08:21] tjaalton: accepted [08:21] hey dholbach, guten Morgen [08:21] hey pitti [08:23] pitti: ty === dendro-afk is now known as dendrobates [08:33] micahg: lucid-proposed has gecko-mediaplayer and moon, but the two tasks on the tracking bug are all "New"; what should happen with these? [08:40] zul: what's with all the new package uploads to oneiric-proposed? https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0 [08:40] zul: were they meant for -backports, or something else? [08:42] jtaylor: rejecting python-networkx oneiric-proposed, as it does not have a bug link; can you please reupload? [08:46] dholbach: About https://bugs.launchpad.net/ubuntu/+bug/923637/comments/4 "ACKed, sync performed, sitting in the NEW queue, to be reviewed by our archive admins", where can I see the status? [08:46] Ubuntu bug 923637 in Ubuntu "Sync hime 0.9.9-1 (universe) from Debian unstable (main)" [Undecided,Fix released] [08:46] * apw is attempting an update today and every :i386 package i have appears to be being 'REMOVED' is that to be expected in precise? [08:49] apw: the buildds are clogged due to the rebuild test, and thus we have a lot of i386 vs. amd64 build desync [08:49] apw: so it's not unlikely that you hit a library which already has built on i386 but not yet on amd64 [08:49] multiarch requires them to be in sync [08:49] so perhaps only apt-get upgrade today [08:50] pitti, ok thans [08:51] if multiarch requires i386 and amd64 to be in sync, maybe launchpad must be modified not to publish one of them but not the other? [08:51] or apt modified to not think removing my packages is the solution [08:51] diwic: That gets extraordinarily awkward when you have powerpc lagging, and build failures. [08:51] but to hold them back instead [08:51] wouldn't be fun to have these kind of issues in an SRU situation, I can imagine [08:51] apw: A normal upgrade should do that. [08:51] Only dist-upgrade will remove. [08:52] diwic: SRUs are copied atomically from -proposed to -updates. [08:52] and dist-upgrade is what update-manager is doing no ? [08:52] diwic: After they've built. [08:52] well, dist-upgrade is really the "normal" case, t hough [08:52] wgrant, I'm not saying wait for all; just wait for amd64 and i386 to be in sync [08:52] and indeed what i am always advised i need to do to actually have what the archive intends on my machine [08:52] diwic: But what if I have armel installed as well? :) [08:53] thats why it needs to be apt side, it knows what combinations you have installed [08:53] wgrant, hmm, there are no amd64-armel dependencies the way there are amd64-i386 dependencies (for certain software) [08:54] so is the situation really applicable on that case? [08:54] diwic: But it's very possible to have armel binaries installed on an amd64 system. === smb` is now known as smb [08:54] And multiarch requires that the versions be identical. [08:54] Regardless of dependencies. [08:56] It's similar to the old arch-all skew issue, which we solved in Launchpad a few months ago. [08:56] Right around the time the multiarch problem sprung up :D [08:56] wgrant, hmm, maybe we need to fix/improve multiarch instead then? I can understand cases where both amd64 and armel would depend on an -all package [08:56] in which case the upgrade must be held back until both versions are ready [08:56] That's a bit of a challenge. [08:57] That would be doable, I imagine. [08:57] But removing the version match restriction is a little difficult. [08:57] but maybe I should go back to discuss what I know :-) and trust you guys to work out apt for me. === dholbach_ is now known as dholbach [09:02] FourDollars, normally https://launchpad.net/ubuntu/precise/+queue [09:02] FourDollars, but it seems it was accepted already [09:02] FourDollars, http://pad.lv/u/hime [09:04] dholbach: Thanks. === Guest97741 is now known as Lutin === chrisccoulson_ is now known as chrisccoulson [09:35] pitti, any idea how long we are going to be skewed by the buildds? as i have half of the X update installed now as a result of doing 'update' and i am not sure thats a good combination [09:35] pitti, hopefully its not the 12/13 days that the status page implies [09:39] apw: no, I think a day or less [09:39] apw: the 13 days is because we are running a rebuild test on the main builders [09:39] but most is universe [09:39] pitti, why is the rebuild on the main builders, and if its going to be, why are we not putting some more online [09:39] I don't know [09:40] * apw assumes its cause they are doing armhf as well [09:40] apw: you know, if only we had some technology to temporarily rent 200 vboxes from amazon or so.. [09:41] pitti, or perhaps we had our own openstack instance [09:41] * pitti guesses it's to heat up the DC [09:41] * pitti brrrrrs at -14 degrees [09:41] pitti, now that is cold, i am whining cause its -1 outside [09:42] you had some general warning that it might get -10 or even less :) [09:42] we have -17 and a blizzard [09:42] was fun driving this morning [09:45] * apw isn't going out "there" [09:48] One of the brakes on my bike was frozen this morning ... [09:49] apw, You would feel awake and alive... well for about 1 minute... :) [09:49] it's a relatively balmy -1 degrees C here [09:50] * diwic weighs in at -11 === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [09:56] * tumbleweed waves from the land of 28°C :) [09:56] /ignore tumbleweed [09:56] "oops" [09:57] :) [09:58] * apw puts hit feet on tumbleweed [09:58] his [09:59] * Laney is wearing 2.3 tog rated socks :-) [09:59] tumbleweed: now that's just cruel [09:59] mini duvets [10:03] * tumbleweed decides he should mabe put a shirt on [10:18] mvo, ping [10:19] cjwatson, i upgraded O->P and its not kept the latest kernel from the old series correctly, any idea what does that chosing ? [10:27] apw: there is a ticket open already to upgrade the primary buildd pool [10:27] apw: upgrade> um, not sure I understand [10:28] cjwatson, i thought that when we upgrade N -> N+1 that we keep the latest kernel installed from N as well as a fallback === dendrobates is now known as dendro-afk [10:28] my upgrade seems to have purged that kernel [10:28] apw: I thought that was usually just by way of not removing the currently-installed kernel [10:28] apw: if there's any specialised logic here, it must be in update-manager [10:29] cjwatson, ahh, so if i was runnning something else i'd not keep it, ok that makes sense at least [10:30] apw: update-manager/DistUpgrade/DistUpgradeCache.py:MyCache.identifyObsoleteKernels(), I think [10:30] cjwatson, thanks :) [10:30] indeed it removes obsolete kernels but skips the running kernel [10:30] which actually is very logical, as that one clearly works [10:30] right :) [10:31] MacSlow: pong [10:31] cjwatson, so i now forgive it :) [10:32] *puhhh* [10:32] cjwatson: in ubiquity, there's an incorrect and misleading message, which should be adapted or deleted, IMHO. Because it may lead to damage. [10:32] I've made a Launchpad bug report about it: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/925427 [10:32] Ubuntu bug 925427 in ubiquity (Ubuntu) ""Ready when you are" message is misleading and incorrect" [Undecided,Confirmed] [10:33] Can you do something about it? [10:33] mpt: ^- [10:33] I believe that's a design-specified message, and it's already been through an iteration or two. I'd like mpt to review and suggest an amended design rather than just changing it myself. [10:35] ah yes [10:35] I don't think there's been a formal test on it, but that's tripped up everyone I've watched installing [10:36] Not that they think installation is finished, but that they sit there waiting for something else to happen === dendro-afk is now known as dendrobates [10:37] The original intent was to remind people that the installer is currently waiting for you to finish answering questions before it can carry on [10:37] "Get on with it" [10:37] :) [10:37] "Waiting for you to complete the configuration questions" [10:37] Gets a bit long for a button :) [10:37] Er, actually it isn't a button is it [10:38] cjwatson, do you have a screenshot handy? [10:38] Not immediately [10:38] * cjwatson googles [10:41] I'm sorry, I have no screenshot either... [10:42] mpt: http://cache.sudobits.com/wp-content/uploads/2011/09/create-user.png [10:42] from http://blog.sudobits.com/2011/09/11/how-to-install-ubuntu-11-10-from-usb-drive-or-cd/ [10:42] it might appear on previous question pages as well [10:44] It's not related to any Ubiquity instance that needs a user action. In that way, the screenshot is a bit confusing [10:46] Hmm? It certainly is - it's waiting for the user to complete the action of answering all the questions [10:46] The user setup page constitutes some of those questions [10:46] thanks cjwatson -- I think this is going to require more than a string fix unfortunately [10:47] No, the answering could have happened earlier on, and been finished already. [10:47] * cjwatson eyes his upcoming leave [10:47] Pjotr: In that case you won't get the "Ready when you are" message. [10:47] the "ready when you are" message happens anyway, regardless [10:47] I've talked about this with ev before, maybe moving the progress bar bit to the top and then saying something like "While we're doing that..." [10:47] Pjotr: It's not supposed to. That would be a separate problem. [10:49] mpt: OK, I definitely won't have time for that, so I guess the question is whether we can reasonably do something intermediate [10:49] Fixing the message being shown when we aren't actually waiting for the user would be an example [10:50] sounds fine to me... :-) [10:50] Unfortunately that code is some of the twistiest in ubiquity ... === _salem is now known as salem_ [10:54] Maybe http://paste.ubuntu.com/827492/ (untested) [10:55] "This flight is ready to depart. All other passengers are waiting for you." [10:55] I had that for me once - I made like Linford Christie [10:55] It's a bit above my head now... Thanks for the attention that you're giving this matter. Hopefully you'll be able to fix it before Precise ships. [10:56] Goodbye [10:59] cjwatson, how many steps are there after that progress bar appears? Is it just the "Who are you?", or are there others? [10:59] Everything from location on [11:01] So location, keyboard, user, possibly migration and webcam, and I have a feeling I'm missing one [11:06] is alpha1 livecd still available somewhere? [11:07] cjwatson, I've just written half a dozen possible strings and they all suck :-) [11:07] cjwatson, how about just hiding the black area altogether? That should be a simple GTK property, right? [11:07] And then re-showing it once stuff starts happening again. [11:09] mpt: Wasn't the worry about that that people didn't notice that we were waiting for them? [11:09] Maybe that isn't a real concern [11:09] cjwatson, I think the root cause is either that they see a progress bar and think that something's happening, or that they see a filled progress bar and think that everything's finished. [11:10] We'd want to avoid the window resizing [11:10] yes [11:10] Let's see. This takes ages to test unfortunately ... [11:11] I wonder how bad it would be to hide all the elements but keep the black area [11:11] (BTW I was hunting around for a screencast of the installation process to give me more context, and then realized, oh, YouTube. There's hundreds of them.) [11:12] cjwatson, I think that would be fine. [11:12] Yeah, I don't bother keeping screencasts any more because the Internet does it for me [11:12] In fact the black area balances nicely with the title area, doesn't it ... [11:13] yes [11:13] Happy to give that a try and see what it does [11:20] Damn, and this test requires me to sit and watch the installer because I need to see what it does just after it's finished copying files ... === Quintasan_ is now known as Quintasan === dendrobates is now known as dendro-afk [12:03] seb128, salut mon ami [12:04] what do we do with goocanvas-2.0 in the queue? :) === MacSlow is now known as MacSlow|lunch [12:17] dholbach, hey, sorry I was at lunch [12:17] dholbach, I was thinking about that yesterday, what about the other sources for murray? ;-) [12:17] didrocks, Riddell: is there any chance you could review goocanvas in source NEW? it's there since the rally and blocking some other packages to land, should be an easy enough one [12:18] it's basically a new version of goocanvas for gtk3 renamed [12:19] seb128: pending to my list [12:19] didrocks, thanks [12:19] yw :) [12:20] seb128, which other sources? [12:20] dholbach, libgdamm and goocanvasmm and the glom update [12:20] seb128, you mean goocanvasmm and glom? no idea - I would have to look up if there are merge proposals for them [12:21] I'm a bit hard pressed for time this and part of next week [12:21] dholbach, I don't think there are, we should find somebody to do it though ;-) [12:21] dholbach, yeah, I didn't mean you need to do it [12:21] maybe a blog post or post to ubuntu-desktop? [12:22] dholbach, yeah, I will try to figure something out ;-) [12:22] awesome === dduffey_afk is now known as dduffey === MacSlow|lunch is now known as MacSlow === dendro-afk is now known as dendrobates [13:23] mvo: mind if I upload a new software-properties? [13:29] mvo: too late :) [13:34] mdeslaur: please do and thanks! [13:34] mvo: cool, thanks [13:47] i assume the unity upload is responsible for my machines desire to remove ubuntu-desktop and unity [13:47] and ... didn't we decide building this stuff in a PPA made more sense as it always triggers this? [13:49] I doubt it, it failed to build on all architectures [13:49] yeah, dist-upgrade wants to remove ubuntu-desktop and unity for me too [13:50] more likely nux [13:51] * cjwatson eyes didrocs [13:51] didrocks [13:51] cjwatson: ABI break, unity will build as soon as bamf is published [13:51] it's being fixed [13:51] they run into new depreciations in the glib uploaded yesterday combined with -Werror [13:52] \o/ [13:52] but yeah, having a ppa we can pocket copy from would be nice [13:52] bamf is published now for all but armel, as far as the buildds are concerned [13:52] it would have been useful for the glib,gtk upload yesterday as well [13:52] so you can retry on !armel now [13:54] hmm [13:54] we should really discuss about pocket copy yeah :) [14:19] There was discussion at UDS (also in #-motu yesterday) about using proposed for this. [14:22] hello! How can my (Python) app get the user's default browser (as configured in system info -> default apps) to open a URL? what's the recommended way? [14:22] Laney, yeah, I was in that UDS session, that would work ;-) [14:23] providing LP lets you copy down from proposed to release [14:24] roadmr, try using the gio g_app_info_get_default_for_type () api I guess [14:24] or g_app_info_get_default_for_uri_scheme() [14:24] seb128: awesome! I want to open a local .xml file, I'll give those two a try [14:25] roadmr: there's Gtk.show_uri() too [14:26] cjwatson: thanks, another option to try! [14:26] >>> from gi.repository import Gtk, Gdk [14:26] >>> Gtk.show_uri(None, 'http://www.ubuntu.com/', Gdk.CURRENT_TIME) === bladernr_afk is now known as bladernr_ [14:30] pitti: its updated packages that are needed in order to get the openstack experience working together in oneiric [14:35] cjwatson: Hello, Colin! [14:36] cjwatson: cjwatson: Currently, if I understand it correctly, the installer sometimes sets LC_MESSAGES, LC_CTYPE and LC_COLLATE in /etc/default/locale. Considering recently uploaded changes in accountsservice and language-selector, meaning that those env. variables are no longer used, the installer should better stop doing those settings. [14:38] GunnarHj: please file a bug, I'm going to need this written down permanently somewhere for the record [14:39] anyway I'm not convinced [14:39] the installer does that for reasons outside what language-selector happens to be doing today ... [14:39] (Incidentally, I wish this would stop changing. It's disruptive.) [14:39] cjwatson: I'll file a bug. [14:41] cjwatson: It's about a conceptual (hopefully final) change. LANG is now considered to represent the language, so in cases where people wants some other locale for regional formats, the formats related LC_* variables are now set explicitly. [14:41] In other words, even if accountsservice et al are no longer consuming those variables, that's entirely irrelevant - they're part of the POSIX locale system and affect other applications. [14:42] It is wrong to rely entirely on accountsservice/language-selector for that, IMO. [14:43] The installer sets multiple variables when it's been given information it can't just cram into LANG. === dholbach_ is now known as dholbach [14:44] cjwatson: Yes, but what I'm suggesting is that it should rather set the formats related LC_* variables instead of LC_MESSAGES, LC_CTYPE and LC_COLLATE. [14:45] OK, IRC is too narrow for this conversation. [14:46] cjwatson: I'll try to explain it on the bug. === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [16:16] hello. is anyone else noticing broken upgrades today on multiarch systems? === fenris is now known as Guest21494 === Guest21494 is now known as ejat [16:55] mvo, ping [16:56] pong === glebihan_ is now known as glebihan [17:05] chrisccoulson, is it expected that libxul-dev is missing from firefox-dev? [17:05] ehh, libxul.pc [17:06] doko, yeah, nothing should be linking against our libxul. what needs it? [17:06] libxul.pc is specifically for embedders [17:16] pitti: they need to be tested [17:22] stgraber: ping === dendrobates is now known as dendro-afk [17:22] mhall119: pong [17:23] stgraber: hey, can I talk to you for a minute about the ARB's rules? [17:24] mhall119: sure === yofel_ is now known as yofel [17:24] stgraber: so getting 3rd party Unity lenses and scopes in software-center is a big deal [17:25] but scope packages will need to depend on the lens package they work with [17:25] I was told that we were going to get an exception for this, so a scope package in extras can depend on a lens package in extras [17:25] has this become the official ARB policy yet? [17:25] right, which they can only do if they are built from the same source or if the lens package is in the distro and not in extras [17:26] so we want different people making the scopes [17:26] the only exception we approved is for one source to build multiple packages and have them depend on each other, we still don't allow two different sources in extras to build packages depending on each other [17:26] so they would be in independent source packages [17:26] and don't plan on allowing that [17:27] ok, that's someething we need to consider, otherwise we will lose a lot of the benefit of the dash [17:27] the reason is, packages in extras need to be independent as we can pull them off at any time if they break === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [17:28] stgraber: can you join ubuntu-app-devel? [17:28] so I'd recommend whoever submits the lens to the ARB do the work of aggregating the scopes and send us that as a single source package building multiple binary packages [17:28] mhall119: can you join ubuntu-arb? :) [17:40] doko: openjdk-6 has still broken multiarch support [17:41] chrisccoulson, icedtea-web [17:42] bdrung, your level of detail is fantastic [17:42] doko, oh, icedtea-web should definitely be using mozilla-plugin.pc :) [17:43] ok [17:43] doko: comment #2 on bug #879167 [17:43] Launchpad bug 879167 in openjdk-6 (Ubuntu) "Broken multi-arch support" [Medium,In progress] https://launchpad.net/bugs/879167 [17:43] i thought it was already though? [17:43] i must have been confused [17:43] sorry about that! [17:43] yeah, a configure check still uses libxul [17:43] doko: the order of the "grant codeBase [...]" lines matter [17:44] bah === fenris is now known as Guest21540 === Guest21540 is now known as ejat === gord is now known as Guest53691 [19:13] seb128: you can poke tyhicks about your ecryptfs issue [19:13] smb: hi, can you confirm that the ppa upstart still works for you with --log? (The ppa package has --no-log as a default still) [19:14] anyone here knows if I can build packages for my ppa and armhf architecture? [19:14] (on launchpad) [19:14] mdeslaur, I will open a bug later, it's basically [19:14] - apt-get source automake1.11 [19:14] cd automake1.11-1.11.1 [19:14] ./configure && make [19:14] cd tests [19:14] ./distdir.test [19:14] morphis - no [19:14] seb128: hi - I don't see any mentions of the problems in backscroll, so let me know what problems you're having [19:15] mdeslaur, tyhicks: ^ [19:15] sorry i've to go for dinner [19:15] brendand: so I have to build locally with qemu until I have a native board [19:15] seb128: thanks [19:15] same issue on https://launchpad.net/ubuntu/+archive/primary/+files/automake1.11_1.11.2.orig.tar.bz2 [19:15] * tyhicks gives it a go [19:15] it fails to rm empty file in the dist dir [19:15] bbl [19:15] morphis, i guess so [19:16] morphis - #ubuntu-arm is a good channel for ARM questions too [19:16] morphis, but i know you can't do armhf builds in a ppa [19:16] brendand: #ubuntu-arm is a very good idea [19:17] morphis, for that matter - can you do armel builds? [19:17] brendand: hm, I coming from OpenEmbedded and currently trying to find out how I can do embedded development with debian/ubuntu [19:18] brendand: I didn't tried yet [19:18] brendand: I am just trying to find out all relevant details before I start with the real stuff [19:33] seb128: I've subscribed you to bug 926292 [19:33] Launchpad bug 926292 in linux (Ubuntu) "automake distdir.test fails because of an EPERM error" [Medium,Confirmed] https://launchpad.net/bugs/926292 [19:34] seb128: I'm heading out, but I'll try to get some time to chase down the problem this weekend === bregma is now known as bregma|afk [19:50] tyhicks, thanks === salem_ is now known as _salem [20:44] hello! any unity developers out there? [20:44] i hae a question about new string in unity 5.2 [20:51] @pilot in === udevbot changed the topic of #ubuntu-devel to: Alpha 2 released! Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: hallyn [20:59] andrejz: I think #ubuntu-unity or #ubuntu-desktop would be better (I don't recall for sure). [21:00] ok thanks [21:08] Hey, can anyone answer a quick question about apport and /var/crash... when a crash dump is created and put into /var/crash, I've noticed that there's also a hidden lock file in /var/crash. What creates that and why? [21:10] nm... found an answer in apport changelog === panda is now known as Guest88129 [21:20] hi everyone - I've tested and verified (and 'Approved') https://code.launchpad.net/~jtaylor/ubuntu/oneiric/subversion/sasl-crash-881862/+merge/85228 . I don't have the rights to actually upload it. Is someone around who can finish that off? === ]reed[ is now known as [reed] === dduffey is now known as dduffey_afk [21:59] roaksoax: ^ === bfox is now known as bfox_afk === arosales1 is now known as arosales === dendrobates is now known as dendro-afk [22:56] ayone around? [22:56] who should i subscribe to a bug to upload a new source package (which replaces an existing source)? [23:00] hallyn: micahg wanted to do that soonish [23:00] thanks for testing ig [23:00] it [23:01] dobey: hi, i think you can subscribe "ubuntu-sponsors" [23:01] hallyn: thanks [23:02] jtaylor: ok (np) I just don't have the rights to actually upload it to the archive, or i'd finish it up right now [23:03] me neither, and for some reason sponsors don't like me, I have 3 of the top 9 oldest things in the queue :( [23:07] jtaylor: well you scare me with the 'multiarch' one - that's nothing personal, i'm just a wuss :) [23:07] yes thats an uglyone :/ [23:07] jtaylor: tbh i was hoping stgraber or slangasek would look at that one. but maybe i should man up... === yofel_ is now known as yofel === SolidLiq is now known as solid_liq [23:30] jtaylor: so with the multiarch one - you say oneiric has been patched to work around it. precise's too? so you actually want that merged into lp:ubuntu/natty/python-numpy (not lp:ubuntu/python-numpy)? Or am i misreading? [23:32] no I actually wanted a fix in oneiric but it was to late in the cycle [23:32] so instead the rdepends where patched [23:32] this is now prettymuch to fix it for non packaged stuff [23:32] though now its pretty much as late as it was when I wanted it in oneiric :/ [23:33] we're still before ff [23:34] its noot even a new feature just a minimal (ugly) workaround [23:34] my point is that it's not currently late at all [23:35] jtaylor: I'm wondering if something more like https://launchpadlibrarian.net/78315456/libxaw-1.0.9.multiarch.diff could be done (to make it - i hope - more standard - i don't judge ugliness when it comes to x stuff) [23:35] i.e. --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) passed to confgure in debian/rules [23:36] its the issue of the buildsystem numpy *provides* for other stuff [23:36] if any MIR team folks are still around, debtags and java-atk-wrapper are currently on the list for promotion to main; I've seen at least debtags breaking image builds and java-atk-wrapper looks like a possibility for that too [23:36] ah [23:36] I'd like not to leave image builds broken over the weekend [23:36] so it must now the triplet of the host its used on not where numpy wasy built on [23:36] s/now/know/ [23:37] java-atk-wrapper is breaking builds already, yes [23:37] jdstrand: ^^ are you up for some MIRs? [23:37] the other three source promotions look like they can wait [23:37] I had perhaps wrongly assumed that since doko did the upload that pulled java-atk-wrapper in, and he has strong opinions about prepromotions, he might have gotten the MIR done first ;) [23:38] slangasek: I have about 10 in my queue assigned to me. I was dealing with some important updates today. I won't get to them until monday [23:38] *shocked face* [23:38] slangasek: if you want to assign it to me-- I have an appt in a few minutes [23:38] I actually don't see an MIR open for java-atk-wrapper [23:38] perhaps it's already marked closed? [23:38] neither have bugs open according to component-mismatches [23:39] jtaylor: I'm trying to use your "ldd -r /usr/lib/python2.7/dist-packages/kiva/agg/_plat_support.so" to verify it's broken, but i don't get the break. I'm sorry I'm being dense, but is there any other quick recipe I can use to verify? [23:39] oh, wait, java-atk-wrapper just vanished from c-m [23:39] hallyn: this library is from which package? [23:39] moving targets FTW [23:40] hallyn: version, the one in oneiric and precise have been fixed [23:40] hallyn: you have to compile the natty package on oneiric to get the broken version [23:40] so it's just debtags [23:40] jtaylor: oh *that*'s what you were saying. [23:40] right, bug #849729 was the MIR for j-a-w [23:40] jtaylor: off to try again [23:40] Launchpad bug 849729 in java-atk-wrapper (Ubuntu) "[MIR] java-atk-wrapper" [Undecided,Fix released] https://launchpad.net/bugs/849729 [23:41] hallyn: with this numpy the workaround applied to enable is not necessary anymore [23:41] hallyn: it will then find the multiarched libraries and link them correctly [23:42] jtaylor: thanks, got it. fetching to build... [23:42] cjwatson: maybe it's better to push a s-c that drops debtags for now? [23:43] dunno - debtags was in main in hardy [23:43] oh [23:43] then hmm [23:43] which is a while back,but [23:43] due to adept-common [23:43] jinkeys: bzr just segfaulted while trying that merge [23:44] * cjwatson looks at what s-c is doing [23:44] * slangasek teaches ureadahead about /run [23:44] wuh, I thought I'd done that [23:45] bah, changed locally 2011-10-22, never committed :-( [23:45] http://paste.ubuntu.com/828250/ [23:45] * slangasek nods [23:46] s-c actually copes if debtags is missing - it's in a try/except [23:46] strangely, my /var/log/upstart/ureadahead.log complains about lots of symlinks that seem to be from under proc... I wonder if those should be filtered out at an earlier stage [23:47] though it looks like a fairly deliberate addition [23:47] by mvo [23:47] * slangasek nods [23:47] definite feature work here [23:48] hah, there's an interesting question. should ureadahead force a reprofile when the only package that's changing under /etc/init is itself? [23:48]