[00:14] barry: I am packaging gnome-games 3.1.3 and have updated it for dh_python2 [00:52] cjwatson: I should be able to make the release meeting on Friday, provided I can work out what time it actually is ;) [03:07] slangasek: I sent ubuntu-core-dev an invite to be a member of ubuntu-audio-dev a while back, but it wasn't followed up on. Should I be doing something differently? [03:07] Granted I didn't chase it up, but not many others outside of ubuntu-audio-dev nave needed to touch the package. [03:35] TheMuso: might get better results just asking an admin of the group to accept the invite [03:36] micahg: Yeah this is true, will chase it up later. [03:41] TheMuso, Why does ubuntu-core-dev want to me a member of ubuntu-audio-dev? I'm happy to press the button, but wonder about the use case. [03:42] persia: So people like slangasek can do multi-arch/other work on audio packages and can upload without having to file merge requests, as has been done for alsa-lib. [03:42] TheMuso, Also, do you happen to know why there are invitations outstanding to both ~ubuntu-core-dev and ~ubuntu-dev? Which do you want? If both, why? [03:42] should *not* be ubuntu-dev... IMHO :) [03:42] That ~ubuntu-audio-dev owns some package branches is a good reason :) [03:43] persia: Yes, I know why the core-dev one is there, because I created it as above. As for ubuntu-dev, I don't know why thats there, if I accidentally created it, then it should be declined. [03:44] Having worked without core-dev having access to ubuntu-audio-dev branches for a while, it hasn't been a problem, so I am personally happy with the status quo, but if others like slangasek think otherwise, then I'm fine with that too. [03:44] persia: having ubuntu-dev a member would allow any contributing dev write access [03:44] https://code.launchpad.net/~vorlon/alsa-lib/multiarch-merge/+merge/68624 is where it was raised. [03:44] TheMuso, ubuntu-core-dev accepted, ubuntu-dev declined. [03:44] ok thanks. [03:45] micahg, No it wouldn't. "Contributing Developer" is just confusing nomenclature for "Ubuntu Member". To be part of ~ubuntu-dev, you need to have been granted upload permission for *something*. [03:46] persia: I thought the only "ubuntu member" status the DMB could grant was through ubuntu-dev [03:47] micahg, Nope. A special group for Contributing Developers was created, which is a member of ~ubuntumembers but not ~ubuntu-dev [03:47] persia: ah, cool, well, then anyone with PPU :) [03:47] At one point what you say was true, but the MC asked the CC about it, because we had folk that we thought should be members, but not yet developers, and we didn't see why we had to tell them to go ask someone else, rather than just granting them membership. [03:48] And the CC directed the creation of a special team for the MC to grant membership indirectly, which the DMB has inherited. [03:48] ah, good to know [03:53] But anyway, we assert that we trust anyone with a PPU with the power to modify user systems, which is a fairly high level of trust. I don't think we'd want to exclude someone with PPU access from doing anything generally extended to all developers. [03:54] Whereas, ~ubuntu-core-dev is kinda different: to preserve the maintainer-of-all-software-in-the-archive characteristic, that team needs access to all packaging branches, all packages, etc. Which means that it makes sense for it to join lots of other teams. [03:54] TheMuso, I'm reminded: please make sure that any bugmail currently received by the Ubuntu Audio Developers team isn't leaking to all core-dev. [03:55] persia: right, which is what I think the goal was, that core-dev should be able to have branch commit access [03:55] persia: Ubuntu-audio-dev gets no bugmail, that goes to ubuntu-audio. [03:55] micahg, Indeed: just wanted to have a complete set of statements in the logs :) [03:56] TheMuso, Ah, excellent. Some teams are not so well organised. [03:57] TheMuso, So, a related question: would you want the members of ubuntu-audio-dev to be able to upload the packages for the branches owned by ubuntu-audio-dev, or does the team dynamic have a split between committers and releasers? [03:59] Good morning [03:59] bdmurray: ah, fair enough [04:00] persia: ubuntu-audio-dev came about primarily so that PPAs of audio software could be made available in one place. It also allows other audio devs who do not have upload privileges to do packaging work. I still do the final checks and upload, or Daniel if he is around at the time. [04:00] TheMuso, makes sense. If you decide to change at some point in the future, let me (or any DMB member) know, and we'll happily walk you through the process. [04:01] persia: ok thanks. === StevenK_ is now known as StevenK [04:58] I'm trying to build a package for testing in oneiric, and I'm getting "configure: error: Package requirements (indicator >= 0.3.0) were not met:" after it checks if indicator is installed. Any way around this? [05:02] pook1e: do you have libindicator-dev as a build-depends? [05:05] How can I check that? [05:06] Sorry, yes libindicator-dev is in the build-depends [05:10] pook1e: and you have libindicator-dev installed right? [05:11] good morning [05:22] I added libindicator-dev to my base tarball [05:22] But it's still giving me the same error. [05:23] pook1e: what package? [05:23] indicator-network [05:23] Trying to build it for oneiric-i386 with pbuilder. [05:30] Here's a paste of the end of the log, not sure if it will help or not: http://paste.ubuntu.com/648812/ [06:38] hello. Which port of keyserver.ubuntu.com does gpg connect to when uploading the key? I am behind a proxy/firewalll and i think that's why it's failing. [06:41] dnivra: you can explicitly use hkp://keyserver.ubuntu.com:80 [06:42] that ought to work [06:42] TheMuso, persia: like most such things, it doesn't become an issue until someone needs it... the Vcs-Bzr branches for several core library packages are owned by ubuntu-audio-dev, ubuntu-core-dev should have commit access there to avoid getting the archive out of sync [06:42] dnivra: the standard port is something like 11037, i. e. most probably firewalled for you then [06:43] pitti: no feedback is given in case of a successful upload? [06:43] persia: thanks for the perm accept :) [06:43] slangasek, Absolutely. If you find any other cases where ~ubuntu-core-dev can't do the right thing, I'm happy to help with group membership. [06:43] persia: ta [06:43] pitti: i guess it worked. Thanks! [06:44] slangasek, Note that I'm not generally in favour of misalignment between folks-who-can-push-to-packaing-branch and folks-who-can-upload, but that's more complicated to solve. Some folk like getting reviews of their work, and other folk don't like to use bzr merge. [06:45] heh [06:46] dnivra: I'm not sure [06:46] ah well I'll know when I upload the fingerprint in half an hour :) === smb` is now known as smb [06:54] dnivra: keyserver.ubuntu.com has also an web interface which you can use to query for keys [06:58] slangasek: heh, OK, I'll let you arrange it with doko then ... [07:08] cjwatson: ack [07:08] TheMuso: while I'm at it, is it ok if I upgrade the alsa-lib package branch to a modern bzr format? [07:10] TheMuso: i.e., people will need to use bzr from lucid or better when working with the oneiric branch... seems reasonable to me, but I'll ask to be safe :) === tkamppeter_ is now known as tkamppeter [07:34] good morning [07:46] dholbach, looks like the css is pointing to /media/img/ , not /media/images [07:50] Amoz, oopsie [07:51] I better get that fixed then :) [07:51] dholbach, where'd you get all that extra css code for light django theme? [07:56] I have problems with pbuilder, it does not create a new distro image, I get at the very end: [07:56] I: mounting /proc filesystem [07:56] mount: /proc already mounted or /var/cache/pbuilder/build//27206/proc busy [07:56] mount: according to mtab, /proc is mounted on /proc [07:56] W: Aborting with an error [07:56] I: cleaning the build env [07:56] I: removing directory /var/cache/pbuilder/build//27206 and its subdirectories [07:56] rmdir: failed to remove `/var/cache/pbuilder/build//27206/proc': Device or resource busy [07:56] rmdir: failed to remove `/var/cache/pbuilder/build//27206': Directory not empty [07:57] Amoz, we weren't supposed to use that branch - there was a newer one which I nicked it from [07:57] Amoz, it's all in the BORROWED-CODE file [07:57] I also cannot delete /var/cache/pbuilder/ccache/, I get "Permission denied" as root. [08:01] dholbach, I see [08:02] dholbach, also, the img/images directories seems to be spread out [08:02] it's a mess ^^ [08:03] Amoz, I'll have a look in a sec [08:12] slangasek: go ahead [08:14] dholbach, also, what is the indexes for in the guide? genindex.html for example? seems all the long names in the relbar will fudge the layout once one get to the konwledge base chapter [08:14] Amoz, I have no idea - you added it :-P [08:15] oh, did I? o.O [08:16] can I remove the general index link then? [08:16] it confuses me.. [08:17] I think it's part of the sphinx theming bits [08:17] if it has no effect we should remove it :) [08:17] it's in the default theme.. hmm [08:17] but it's very intrusive there [08:18] because the theme is much smaller now, we can't have a lot of long names in that small bar =( [08:19] TheMuso: ta :) === jibel__ is now known as jibel [08:37] dholbach, included the js-docs, now the search function works [08:37] or, it should [08:38] ah, nice [08:39] dholbach, I think we move down the searchbox from the relbar (where all the refs and chapters are supposed to be + next/prev ) [08:40] sure - that works for me [08:40] a css hacker need to fix it though [08:40] pitti, hi [08:43] hello tkamppeter [08:45] pitti, I have uploaded the first opackage of cloudprint last week and it is still in NEW (I had CCed you in a mail about my Google Cloud printing support plans). How will it get into the archive. [08:46] the archive admins should get to it; but NEW processing seems to lag behind a bit indeed [08:46] pitti, or do I need to report a bug about including this package? [08:46] no, that won't help [08:47] dholbach, we have a sphinx mystery. searchindex.js is probably a dynamic generated file for keywords and stuff. the question is where/how to generate it? [08:47] pitti, so in the worst case it will sit there until my planned UDS session happens? [08:47] no, it shold really be processed within the next days [08:47] Amoz, I never played around with it, so I have no idea - I suggest we try to get everything else ready first and a file a bug report as a reminder [08:48] pitti, also no answer on my e-mail, probably such planning works only on UDS. [08:49] dholbach, yeah, I need to stop bugging you when thinking aloud. oops, there I did it again, sorry! :P [08:49] pitti, did you get that e-mail? [08:51] * dholbach hugs amo [08:51] z === Quintasan_ is now known as Quintasan [09:03] Good morning. [09:04] hi Quintasan [09:05] pitti, still there? === doko__ is now known as doko [09:27] tkamppeter: what was "that" email? [09:27] tkamppeter: had an appointment, back now [09:36] pitti, sorry, I did not include you, but FYI I will forward it to you. [09:38] barry: I was wondering what a reasonable time-frame would be for dh_python2 and python-all > 2.6.6-3 to hit lucid? bug 811506 [09:38] Launchpad bug 811506 in python-defaults (Ubuntu) "please backport python-all 2.6.6-3 or later to lucid (dup-of: 788524)" [Undecided,New] https://launchpad.net/bugs/811506 [09:38] Launchpad bug 788524 in python-defaults (Ubuntu) "backport dh_python2 to lucid (and maverick if appropriate)" [Undecided,In progress] https://launchpad.net/bugs/788524 [09:43] pitti, I have also another problem, with pbuilder. I cannot set up an Oneiric image. See my messages of 09:56am today in this channel. [09:45] tkamppeter: This one with pbuilder is known, something wrong with debootstrap magic or something else [09:45] tkamppeter: You can create a natty one and upgrade it [09:45] Just use --save-after-login option [10:05] Quintasan, and how do I clean up the ccache, as I get "Permission denied" as root there? [10:11] Quintasan, unfortunately, it also does not build natty, same problem: [10:11] I: mounting /proc filesystem [10:11] mount: /proc already mounted or /var/cache/pbuilder/build//30385/proc busy [10:11] mount: according to mtab, /proc is mounted on /proc [10:11] W: Aborting with an error [10:11] I: cleaning the build env [10:11] I: removing directory /var/cache/pbuilder/build//30385 and its subdirectories [10:11] rmdir: failed to remove `/var/cache/pbuilder/build//30385/proc': Device or resource busy [10:11] rmdir: failed to remove `/var/cache/pbuilder/build//30385': Directory not empty [10:11] Quintasan, or should I --create on a Natty box, copy over the image and upgrade on an Oneiric box? [10:13] *shrug* [10:13] no idea, I was told that creating oneiric pbuilder was broken [10:13] so I created a natty one and upgraded [10:15] tkamppeter,Quintasan: that's bug 805886 [10:15] Launchpad bug 805886 in util-linux (Ubuntu) "/proc does not get umounted after debootstrap" [Undecided,New] https://launchpad.net/bugs/805886 [10:15] --create on a natty box should work [10:15] I don't believe it matters what target distribution you're trying to bootstrap [10:15] Thanks, Quintasan and cjwatson [10:17] cjwatson, do you have any idea about not being able to remove pbuilder's ccache as root? [10:20] tkamppeter: I just told you the bug number [10:21] it's because umount is unmounting / trying to unmount /proc rather than /var/cache/pbuilder/build//30385/proc. you can't remove a mount point that still has something mounted on it. [10:21] and it's a umount bug - it's being told the right thing and doing the wrong thing [10:28] cjwatson, this I understood, but I have a second problem. [10:29] cjwatson, I succeeded to unmount /var/cache/pbuilder/build//30385/proc manually by "sudo umount /var/cache/pbuilder/build//30385/proc". After that I wanted to delete /var/cache/pbuilder/ccache/*/* and get "Permission denied" as root. [10:32] tkamppeter: I strongly suspect that you will find that it is still mounted, and that in fact umount decided to unmount /proc instead for you [10:32] which is what I keep saying - umount isn't doing what you ask it, that's the bug [10:33] check /proc/mounts (and if it doesn't exist, remount /proc ...) [10:34] pkg-config is needed as build-depend? Thats not default installed right ? [10:37] dupondje: it is not build-essential, no. if you need it you must build-depend on it. [10:46] cjwatson, thanks, that was it, there was still one dangling mount. [11:40] cjwatson: I'm upgrading a system to oneiric here so I can test that umount bug, but can you test a hunch of mine? [11:47] infinity: sure [11:47] well, preferably if it doesn't involve a full debootstrap first [11:55] cjwatson: The failing recipe is "mkdir proc && mount -n -t proc proc proc && umount ./proc", right? [11:56] cjwatson: And I'm told that changing the name of the mountpoint fixes it. But I'm curious if changing the name of the filesystem might. [11:56] infinity: your recipe reproduces it here, anyway [11:56] cjwatson: (ie: "mkdir proc && mount -n -t proc proc-test proc && umount ./proc") [11:57] ^ confirmed [11:57] infinity: that recenlty changed in sysvinit, so that was the trigger for the bug? [11:57] i. e. sysvinit changed from "none" to "dev", "proc", "sys", etc. [11:57] debootstrap doesn't involve sysvinit [11:58] oh, I suppose it might depend on the host system though [11:58] I think it's a bonafide mount bug, but one that wasn't exposed until recently. [11:59] infinity: changing the name of the filesystem doesn't help [11:59] What I suspect is happening is that it's incorrectly mapping path to fs-name, then umounting by fs name. [11:59] cjwatson: Yeah, it shouldn't. [11:59] cjwatson: Not if I'm right. [11:59] $ mkdir -p proc && sudo mount -n -t proc proc-test proc && sudo umount ./proc [11:59] cjwatson: Now that I think about it, anyway. :P [11:59] umount: /proc: device is busy. [11:59] I'm sorry; I meant initramfs-tools, not sysvinit [12:00] that's what changed the /sys, /dev, /proc mounts etc. from "none" to named [12:00] /usr/share/initramfs-tools/init [12:00] I'll test more here when my netbook catches up to the present. [12:00] Cause further testing would be asking people to reboot, I think. [12:01] * cjwatson uses http://paste.ubuntu.com/649040/ to clean up after infinity's tests [12:02] cjwatson: Does make one wonder why /bin/umount isn't that simple, doesn't it? :P [12:02] cjwatson: ah, I used umount -l [12:02] cjwatson: (And really, in the case where it's a verifiable local path with something mounted on it, it should be. But I'm pretty sure it's failing to short there) [12:03] Clever software, for the loss. [12:03] I generally assume that complicated software had some reason to be that way, which I realise is unfashionable :-) [12:03] http://www.joelonsoftware.com/articles/fog0000000069.html and all that [12:04] cjwatson: mount and umount have tons of reasons to be complicated, but optimising for the simple cases is still smart. [12:05] (I don't always agree with Joel - in fact I suspect I mostly don't - but that one should be required reading) [12:05] infinity: *nod* [12:05] * infinity is tempted to substitute random livecd-rootfses and live-builds in that article. [12:06] notice how I was really, really slow to switch to live-build :-) [12:06] I just loathe abstraction for, seemingly, the sake of abstraction. It's not live-build's fault, it's been all the rage for a decade. [12:07] livecd-rootfs had too little; live-build has too much === MacSlow is now known as MacSlow|lunch [12:07] Following my command-line arguments through a twisty maze to figure out where something actually HAPPENS drives me batty, in something that's, ultimately, that "simple" in what it does. [12:08] And there are some glaring issues that I need to take up with upstream when I have round tuits. [12:08] much though it pains me to say it, many of live-build's abstraction confusion issues are due to trying to do too much in shell [12:08] and I think upstream knows that [12:08] The largest of which being that "lb clean" should, under no circumstances, be able to fail, except if it fails to actually clean. [12:09] cjwatson: Bite your tongue! Shell is beautiful and pure and true. [12:09] the whole way new command-line options need changes in several different places would be a lot easier to fix in a higher-level language [12:09] (And a good language for a project like this, but he's overcomplicated it a tad, perhaps) [12:09] I think the option processing would be better in Python, and then call out to hooks in shell [12:10] cjwatson: CLI parsing could be done globally in shell much differently than he's doing. But I don't much care what language it's in, at the end of the day. [12:10] that would keep the virtues of shell as a glue language while avoiding the horrible bits [12:10] cjwatson: The reason livecd-rootfs was shell was because, ultimately, it's entire job was to fork a lot. [12:11] right, Python isn't a good multi-process glue language [12:11] unless all the processes are themselves written in Python :-P [12:11] Anyhow. If "lb clean" would stop including a function library with "exit 1" throughout, I'd be happy enough for now. ;) [12:12] "Oh, you didn't select a default kernel? Well, you get a dirty build-tree. Enjoy!" [12:12] But yeah. Worked around for now, I'll worry about patching it correctly later. :/ [12:13] I suspect the software history would've been different if livecd-rootfs code had been public from the start [12:13] cjwatson: Maybe I can rewrite it in Perl before he rewrites it in Python? ;) [12:14] cjwatson: Yeah, I tried to get it public sooner. :( [12:14] I eventually won, but a bit too late. [12:14] heh, I actually don't know exactly what dba's plans are there [12:14] yeah, I remember [12:14] Granted, had it been widely adopted, it would have grown a lot anyway. [12:14] But perhaps in different directions. [12:14] *shrug* [12:14] Whatever works. [12:15] In the end, once we've wrestled with it a bit to get our various recipes in place, the rest is just adding and removing tasks, kernels, random packages, etc. Which is simple regardless of the underlying system. [12:16] yeahyeah [12:17] er, lag maded that sound sarcastic [12:17] was meant to be "yeah" [12:18] lag: please don't make people sound sarcastic. [12:18] Jerks! [12:18] ;) [12:18] lag: while you're at it, make sure cjwatson never typed "maded" again. [12:18] s/typed/types/ [12:19] HA! [12:19] Making typos whils criticising others' is poor form... [12:19] * lag loves that you were telling him off for typos, then made one yourself [12:19] :D [12:19] S'ok, I made ANOTHER while telling myself off. [12:19] infinity: More than one [12:20] I only see one. :P [12:20] Anyway... I need to go and do some real work now :) [12:20] s/whils/while/ [12:20] s/others'/others [12:20] No. I meant others'. [12:21] As in, the typos belong to others. [12:21] belonging. [12:21] Feh. [12:21] TYPING HARD. [12:21] I give up. I shold eat breakfast before I type anything else. [12:31] cjwatson: is it worth moving zz-update-grub into the old grub package? I just ran into a case where it would generate the initramfs after it ran update-grub during a automatic natty->oneiric upgrade test. or will grub1 vanish anyway and is not worth spending time on it? === kentb-out is now known as kentb [12:31] (the fact that grub1 is used in the auto-upgrade tester is a different bug … that I'm fixing now, ubuntu-vm-builder) [12:35] mvo: zz-update-grub is used for grub2 too [12:35] it's actually in both packages [12:36] oh, wait, it's in Debian grub but not in Ubuntu [12:36] yeah, I should fix that - not today though [12:40] cjwatson: no worries, I can have a look [12:41] mvo: yeah, if it's urgent, see Debian grub 0.97-62, 0.97-63, 0.97-64 [12:42] it's unfortunately non-trivial to merge but a compound cherry-pick would be fine [12:42] thanks cjwatson [13:02] hi pitti, could you initiate a build of new base language packs for Natty? The full translation export is done, and it is necessary to fix bug #774238 [13:02] Launchpad bug 774238 in gnome-user-docs (Ubuntu Natty) "Desktop help is untranslated in 11.04" [Undecided,Fix committed] https://launchpad.net/bugs/774238 [13:03] kelemengabor: sure; did you already discuss that with dpm, for the testing, regular schedule, etc.? [13:04] yes, the plan was to release a planned update last week, but we delayed that because of this [13:04] pitti, yeah, kelemengabor is aware of that. He's taking over from TLE as the new langpacks rockstar :) [13:04] * kelemengabor blushes [13:04] :) [13:06] dpm: disabling natty cronjob FYI [13:07] marking 07-21 langpack as current [13:10] kelemengabor, dpm: natty langpack build started [13:10] pitti: cool, thanks [13:12] pitti: I'm looking at https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA and it seems that we forgot to ask you to move those -proposed packages for Maverick to -updates for which we got a positive feedback [13:12] which is only Dutch [13:12] I tought we already did a few [13:13] I just checked my Maverick vbox, and it says that the Dutch update is still in -proposed [13:14] kelemengabor: released -nl packages to -updates [13:14] thanks! [13:14] kelemengabor: right, I meant that we already moved a bunch of other langauges to -updates which got verified [13:14] I suppose this also was the last maverick update ever? [13:15] well, we'll need another one once firefox 6 lands in maverick-updates [13:15] but for the regular schedule, I mean? [13:15] I think there was still another one, let me check the schedule... [13:15] pitti: https://wiki.ubuntu.com/Translations/MaverickLanguagePackReleaseSchedule [13:15] yes, there is one more scheduled for early August [13:16] we don't even have daily PPA cronjobs or regular exports from LP for maverick any more [13:16] perhaps it will see bug 690248 fixed :) [13:16] Launchpad bug 690248 in Ubuntu Translations "In Maverick 'About Ubuntu' displays Natty info" [High,Triaged] https://launchpad.net/bugs/690248 [13:17] RAOF, SpamapS: please don't release anything to lucid-updates until further notice from cjwatson (needs to stay locked down for 10.04.3 release) [13:17] pitti, yeah, we accorded to request an export whenever we'd need a new langpack release for Maverick, but I think if we're doing one soon to fix 690248, we could say it's the last one [13:17] kelemengabor, what do you think?^ [13:18] chrisccoulson: when do we expect firefox 6 for maverick? [13:18] since at that point we'll definitively need a -base refresh [13:18] pitti - you'll need to ask micahg that [13:18] i've already done all the work though [13:18] dpm: I agree, that bug is the last reason for releasing an update for Maverick [13:19] if we can get it fixed, I think it will be safe to leave Maverick alone [13:20] cjwatson: if you don't mind I will upload a new grub1 with the zz-update-grub cherry pick, that should make the auto-upgrader tester more happy again [13:22] mvo: not at all, go ahead [13:22] thanks [13:23] ok, sounds good, thanks kelemengabor. pitti, so I think we could just do a final maverick langpack upload if we fix that bug [13:23] dpm: and another one for ffox 6 [13:24] ah, yeah, good point then [13:24] dpm: and my gut feeling is that 690248 isn't serious enough to warrant doing that twice [13:24] i. e. could we just wait for ffox 6 and do one -base refresh then? [13:25] maverick has lived with this for some 9 months, after alal [13:25] pitti: http://asciimiki.blog.hu/2011/03/31/11_04_vs_maverick_lol [13:26] this is what local kids think about it :( [13:26] still, it hardly keeps maverick from actually working [13:27] I don't have a strong opinion on this one. chrisccoulson, even if it depends on micahg, when do you estimate the ff6 upload to happen (I haven't kept up with the FF schedule, so I'm not sure it's a matter of weeks or months) [13:29] dpm - well, firefox 6 is released on 2011-08-16 [13:29] but micah seems to want to stick with 3.6 [13:30] although, i've already spent lots of time this cycle preparing to push 6.0 out to maverick and lucid [13:30] and everything (except language packs) is ready to go now [13:32] dpm - the dates are here btw: https://wiki.mozilla.org/RapidRelease/Calendar === MacSlow|lunch is now known as MacSlow === Ursinha` is now known as Ursinha === Ursinha is now known as Guest44940 === Guest44940 is now known as Ursinha_ [13:41] barry, around ? === Ursinha_ is now known as Ursinha [13:53] RAOF, SpamapS: lucid-updates unfrozen [13:57] thanks chrisccoulson [14:32] dpm: langpack build done [14:33] dpm: do you happen to have some time to grab e. g. the Catalan one from /srv/language-packs.ubuntu.com/natty-proposed/, build it locally, and test it? [14:33] dpm: I'm pretty swamped today still, need to get some stuff done before my holidays next week === brendand_ is now known as brendand [14:34] pitti, sure. Let me do it after my call today. Going somewhere nice on holiday? [14:35] dpm: we'll do a bicycle tour along the Inn river, from Switzerland through Austria to Passau, Germany [14:35] with tenting [14:35] pitti, wow, nice :) [14:37] pitti: should be able to follow that down the Danube, to near Belgrade/Bosnia for Debconf [14:39] heh [14:40] yes, please bike to DebConf from Germany, shame these Dutch with their carpools :) [14:43] I can't even bring my laptop! === jamespage1 is now known as jamespage === Ursinha is now known as Ursinha` === Ursinha` is now known as ursinha` === ursinha` is now known as Ursinha [15:04] I thought this was mentioned in the StableReleaseUpdates wiki page, but I can't find it right now. Can I verify SRU fixes that I posted myself? I thought there was something about neither the bug fixer nor bug submitter can do so... === dnivra_ is now known as dnivra [15:15] slangasek, did you open a bug about indicator-datetime-service/e-calendar-factory causing dbus-daemon to spin the CPU? [15:16] all right, i guess i found my answer. free to verify, and two verifications == verification-done [15:30] looking at https://wiki.ubuntu.com/MainInclusionProcess, it looks like MIRs are placed against source packages. However, multipath-tools is in main, while multipath-tools-boot, from same source package, is in universe. Is that just an accident of history? Or is there a reason for it? (googling got me nowhere) [15:34] chrisccoulson: no, didn't open it yet - are you beating me to it? [15:35] slangasek, i haven't opened one yet, but i probably will do once i've finished my current task [15:35] and i'll try to figure out what's going on too. it's becoming quite disruptive now [15:38] chrisccoulson, there is one [15:38] chrisccoulson, works fine there, is that happening only if you don't use evolution? [15:38] seb128, i'm not sure. i haven't used evolution since before the rally ;) [15:39] does it stop being an issue if you start evo? [15:39] seb128, i'll give that a try in a sec [15:39] g'ah, all my window decorations just disappeared [15:40] jhunt_: wrt bug 803977 should that be crashes and package reports? [15:40] Launchpad bug 803977 in apport (Ubuntu) "Add hook to attach Upstart override files" [Wishlist,Triaged] https://launchpad.net/bugs/803977 [15:41] restarting the decorator takes forever :/ [15:41] bdmurray: all scenarios when a user can create an upstart bug ideally. [15:42] jhunt_: okay [15:42] hallyn: we only promote the binary packages that the seeds actually demand [15:43] normally we promote binary packages from sources that are already in main without any paperwork; although multipath-tools-boot sounds like something that should have a second pair of eyes on it anyway? [15:44] a brief skim looks OK to me [15:44] cjwatson: waht exactly does 'the seeds demand' mean? [15:44] that it gets installed on a server or desktop default install? [15:46] https://wiki.ubuntu.com/SeedManagement [15:46] thanks [15:46] the details of exact seed names are probably out of date, but the general idea hasn't changed [15:46] and no, there's lots of stuff in main that is not in any default install [15:48] cjwatson: thanks [15:53] pitti: dpm, so WRT Firefox in Lucid and Maverick, I'm waiting to hear what upstream plans to do WRT EOL on the 3.6.x branch, I'd like to SRU the latest version in after they release the last 3.6.x === deryck is now known as deryck[lunch] [15:54] but I suppose we could do maverick before Lucid [15:58] chrisccoulson: go for it :) [16:01] barry: any updates about psycopg2 on oneiric? [16:02] cr3: i think we're giving the maintainer a few more days to respond to my query about our ubuntu delta. if i don't hear from him by monday, we'll do a sync request and throw that delta away (i personally don't see much value in it) [16:03] cr3: the sid version should solve all our problems :) [16:05] slangasek: bug 803353 is the blocker [16:05] Launchpad bug 803353 in subvertpy "segfault during iconv close from ra cleanup" [High,Triaged] https://launchpad.net/bugs/803353 [16:19] UDD problem: rmadison shows natty-updates has multipath-tools 0.4.8-14ubuntu10.1, but bzr branch lp:ubuntu/natty/multipath-tools gives 0.4.8-14ubuntu10 [16:20] oops [16:20] i thought i'd looked for natty-updates bzr proj before and not found it [16:20] barry: sid will save us all! [16:20] pls ignore :) === sconklin1 is now known as sconklin === _LibertyZero is now known as LibertyZero === beuno is now known as beuno-lunch === hunger_ is now known as hunger [17:50] Daviey: are you around, and would you have 20-30 mins sometime today to verify bug 495394 (I'm around if you need any clarification on how to reproduce, though i tried to make the TEST CASE: part of SRU description clear) [17:50] Launchpad bug 495394 in libvirt (Ubuntu Natty) "autostart almost always fails on boot time host" [Undecided,Fix committed] https://launchpad.net/bugs/495394 [17:59] hallyn: o/ === beuno-lunch is now known as beuno [18:01] hallyn: You want me to verify the bug, and check that your patch fixes it - then sponsor? [18:02] Daviey: yes, please. well, i'm not sure that 'sponsoring' fits in with the SRU process, but whatever will push it into -updates asap would rock [18:13] hallyn: Yes, the process is to sponsor it into -proposed but blocks in unapproved queue, where SRU team review it before accepting it. [18:13] hallyn: is it okay to attack this tomorrow morning, my time? [18:14] the test case looks clear enough. [18:14] jdstrand: ^ is that early enough, or too late for you? [18:18] hallyn: that is fine with me. thanks. would you mind pinging me? if they go to verification-done I will just prepare packages against -proposed [18:18] (then wait) [18:18] jdstrand: is this blocking you? [18:23] Daviey: I have a security update. I think I have preempted hallyn 2 times already and woould prefer not to do it a 3rd time since this seems close to being verified [18:23] Daviey: if it gets urgent, I'll upload and we can start again. I'd rather not do that to poor hallyn again if I can help it :) [18:24] :) [18:24] jdstrand: Daviey: thanks! [18:26] jdstrand: okay, super.. i'll do it first thing in my morning, and maybe ask someone in ~ubuntu-sru to look at it - so it's ready for you when you start. [18:31] Daviey: thanks. it would be nice to publish on monday :) [18:41] jdstrand: I'm sure you know this, but -proposed packages normally bake for a week regardless of verfication-done.. [18:42] which means that if you publish on Monday with hallyn's change, that would be fasttracking that. [18:42] If it's not too destructive, it might be better for you to go first.. would hallyn's diff need refactoring? [18:47] Daviey: those are sitting at 9 days. [18:48] Daviey: all that is needed is verification-done (I waited until 7+ days before I started poking people) [18:49] Daviey: I'm more than happy to do the patches without the -proposed fixes, but like I said, I did that to hallyn 2 times already for this exact bug [18:50] Daviey: I wasn't proposing fast-tracking anything-- I was assuming that if it was verified, pitti or anohter sru member would copy to updates, then I would promptly push to security [18:55] jdstrand / hallyn: Ahh! I missunderstood.. I didn't realise it was already in -proposed. [18:56] that'll teach me to spout of before i read the bug/status [19:00] cool, no worries :) === dendro-afk is now known as dendrobates [19:16] barry: ping [19:16]