[00:02] jdong, be careful using su, it may open a console kit session, making an error popup whenever you try to shutdown using ck [00:03] ran into that problem with mythbackend, and ended up patching in support to natively drop permissions in the app instead [00:03] superm1: ouch. Fortunately this is just a topless server so I' [00:03] err [00:03] did I say that? [00:03] I mean headless. [00:03] same thing :) [00:09] superm1: su is the wrong tool for nearly any job anyway, so I'm sure it's no great loss [00:09] you certainly should never use it noninteractively, since it opens a PAM session [00:09] and its argument parsing is awful [00:10] man-db.postinst does a simple thing in perl; there are many options [00:13] slangasek: FYI, I just updated 571093 (libvirt bug) looks like the SRU patch isn't the latest, the libvirt guys modified it slightly before pushing it and found a couple of other memory leaks [00:14] G: is the patch that's currently there free of regressions and an incremental improvement over the status quo? [00:15] (we're not going to have time for further fixes to libvirt before 10.04.1, so the question is whether we can commit to the current package in good conscience, or if I need to roll it back and respin candidate images) [00:16] slangasek: I believe it is [00:16] slangasek: let me just check one thing though [00:19] slangasek: yep just double checked, I just noticed that we are in one case with the patch in proposed free'ing twice, but the function libvirt uses to free it, does check that it exists, so there shouldn't be a Null Pointer as a result [00:21] slangasek: so I don't see any regressions in the code [00:22] and the patch proposed, has been working for me for a while [00:25] G: great, will promote to -updates then - thanks! [00:26] slangasek: no problem, it was a pain of a bug to try and reproduce :) [00:29] G: Are you using libvirt on a maverick install and if so do you find you have to disable the apparmor profiles for it? [00:29] penguin42: ha, my maverick machine hasn't been updated for a while and I never got round to doing VM stuff on it, it's been on my TODO list for ages :) [00:30] gotta work out the phantom reboots first, I think some are Kernel some PSU :( [00:30] G: OK, just wondered if it was just me; I have a pair of separte VM issues on maverick; apparmor and the SDL consoles broke a week or two [00:30] ago [00:30] hmm does 2.6.35 still have the alt-sysrq bug? [00:31] (and I couldn't get kdump etc working to try and report the panics) [00:31] hmm no the forgetting about key up seems to have gone [00:35] penguin42: is there a bug number for the libvirt/apparmor/SDL thing? [00:35] I've done the SDL one, not the apparmor one yet [00:35] I might start to throw Maverick on my other box [00:35] G: bug 615077 [00:35] Launchpad bug 615077 in qemu-kvm (Ubuntu) "[Maverick] SDL local window broken in last update" [Medium,New] https://launchpad.net/bugs/615077 [00:38] penguin42: I'll give it a go sometime :) [00:38] I'll try it again to see if it got fixed === jjohansen is now known as jj-afk === wendar_ is now known as wendar [01:24] cjwatson: when netbooting d-i, is there a way to specify to install from the cdrom (ie take packages from the cdrom)? [01:32] cjwatson, right, the reason the ck session was open was because of the pam. so yeah good it's all sorted out now === emma is now known as em [05:10] Good morning [05:10] morning [05:11] hi [06:07] pitti: do you know which process should be responsible for stopping ureadahead? === freeflyi1g is now known as freeflying [06:08] it seems that nobody is stopping ureadhead, it's paused waiting for sigterm (stop) [06:08] rsalveti: erm, I don't understand? it just exits by itself once it's done reading all the files [06:08] rsalveti: oh, you mean the collector? [06:08] “stop on stopped rc” [06:08] pitti: yep, because it sets up the collector (debugfs) and then pause waiting for someone to stop it (send the sigterm) [06:08] the collector is stopped by /etc/init/ureadahead.conf, "pre-stop exec sleep 45" [06:09] then it'll generate the pack file [06:09] but I don't know who is responsible for stopping it [06:09] rsalveti: after those 45 secs, it gets stopped ("stopped rc" means all the rc*.d scripts ran) [06:10] hm, so some other script is still running [06:12] I just updated another machine to maverick and then I noticed this issue [06:18] pitti: the weird thing is that rc is at "stop/waiting" but ureadahead is still "start/running" [06:19] need to run upstart with debug to understand what's happening [06:30] slangasek: AFAICS we now have everything in -updates for 10.04.1, right? [06:36] pitti: looks like it, though I see an openjdk security update was published to lucid-updates today [06:36] slangasek: do you want to include that on new respins? [06:36] there'll always be "that next update", after all [06:36] I hear a kernel update is coming soon, too [06:37] pitti: no, I think we should go with it as-is; but I would have expected a freeze to be in effect on copies to lucid-updates at least until we took the point release snapshot [06:37] (which I'll go ahead and do now) [06:38] oh, right [06:38] slangasek: does that run automatically from cron these days? [06:38] the pocket copy? I don't know [06:41] pitti: snapshot taken; I've also manually added the openjdk-6 sources to the snapshot, so we should be covered to proceed [06:41] nice; so 10.04.1 is carved in stone now? [06:42] slangasek: can you please ping me when you want to lift the -proposed freeze? [06:43] pitti: yes, I think 10.04.1 is locked in; everything is in -updates now that should be, if we do any further respins we can do them without -proposed, so please consider -proposed unfrozen [06:44] ah, nice; time to process the large backlog then :) [07:57] good morning [07:58] hi === almaisan-away is now known as al-maisan [08:34] 3 [08:35] sorry typed 3 by mistake [08:36] That’s unforgivable. [08:38] ion: jokes are not forgiveable on this channel [08:39] bilalakhtar: good bye, hello, good bye, hello again [08:40] pitti: I cannot help. services takes a long time to assign me my cloak [08:40] by that time irssi joins all the channels [08:46] When is M-o-M supposed to be up again? [08:46] manually merging until then [08:50] hola seb128 [08:53] hey dholbach === yofel_ is now known as yofel [09:50] cjwatson: In regards to bug 582183, would you like initialise-from-parent to also copy the archive permissions? [09:50] Launchpad bug 582183 in Soyuz "initialize-from-parent should initialise package sets in new series" [Medium,Triaged] https://launchpad.net/bugs/582183 [09:58] StevenK: oh, it doesn't already? I. e. right now ACLs need to be set up again for each new release? === diwic is now known as diwic_afk [11:08] pitti, can I ask you a quick apport question? [11:08] ara: sure [11:09] pitti, I am trying to add tags to a report (in an apport hook that I am writing) [11:09] if I put report['Tags'] = 'tag1 tag2', then 'maverick' and arch are not added [11:10] ara: they are added before [11:10] but if I use report.setdefault, then tag1 and tag2 are not added [11:10] ara: you need to use += [11:11] report['Tags'] += ' tag1 tag2' [11:11] pitti, ok, I tried that and debugging it (using python source_...) i got an exception, but I guess it works differently [11:11] ara: ah, in that case they aren't added by apport of course [11:11] \o/ the sponsor request count for main is < 70 [11:11] ara: add this so that it works in both cases: [11:11] report.setdefault('Tags', '') [11:11] bdrung: good work! [11:11] bdrung, woohoo! [11:12] pitti, OK, will try that [11:12] thanks a lot! [11:13] pitti, dholbach : thanks. i will be on vacation soon. hopefully the number won't be higher when i come back [11:13] StevenK: yes please, would save me a deal of hassle [11:14] slangasek: yes, copies from -security to -updates are cronned; I shouldn't think that matters because builds happen from -security as well anyway, in other words the thing that arguably should have been frozen was security publications rather than copies to updates [11:46] pitti, one more question, if the application crashes, and the package has an apport hook, will apport attach the information in the hook (apart from coredump) [11:46] ? [11:46] ara: yes, that's the main point of those :) [11:47] ara: you can test that locally by starting the app, and killall -SEGV appname [11:47] then apport will come up, and you can click the "details" expander to see the repot [11:47] report [11:47] pitti, thanks again, you rock :-) [11:48] ara: you too! :0 [11:48] my shift key doesn't [11:48] :D === diwic_afk is now known as diwic [12:23] cjwatson: Do you want xz for 3.0 sources as well? [12:25] wgrant: I figured one thing at a time; that should be a separate bug [12:25] wgrant: I have a diff locally for data.tar.xz; was just looking for a *cough* pre-impl chat in #launchpad-reviews [12:25] Yes, they do often tend to be "pre"-imp... === e-jat is now known as ejat [12:26] wgrant: though to give you a straight answer, .orig.tar.xz or whatever isn't an immediate priority for me; my motivation is in https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-spring-cleaning [12:26] Ah, so just killing off existing lzma stuff? [12:27] right [12:32] dholbach: you can wipe ~dholbach/tmp/sponsoring-list, all done [12:32] Riddell, done, thanks a lot === MacSlow is now known as MacSlow|lunch [12:38] dholbach: who should I subscribe to bug 617787 to get it approved? [12:38] Launchpad bug 617787 in Ubuntu "Sync request: 3depict" [Undecided,New] https://launchpad.net/bugs/617787 [13:14] <\sh> hmm...did anybody setup a squeeze sbuild chroot with mk-sbuild in the last days? it stops with "finish: apt-get command not found" [13:22] Riddell, ubuntu-sponsors [13:22] Hm... I have a build that failed in lucid-proposed, but worked excellently in my PPA. A debdiff between the two source packages only shows the different versions I used in debian/changelog and a different timestamp. It's a bit of a mystery. [13:22] The build that works: https://edge.launchpad.net/~soren/+archive/nova/+build/1918475 [13:22] The build that failed: https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058 [13:23] Everything is pretty much identical up until the build starts (the lucid-proposed build apparantly has lucid-proposed enabled which my ppa does not. Only difference seems to be an unrelated change in libc6). [13:24] The build starts out running a "make oldconfig" on the kernel. The build log from the non-PPA buildd suggests that the kernel's build system thinks it's a 32-bit system, but it's not. [13:24] Does anyone have any clues? [13:25] * soren is inclined to retry the build. [13:27] * soren saves the build log and retries the build [13:27] <\sh> can someone approve lucid nomination for bug #533369 and eventually fix it ? :) thx [13:27] Launchpad bug 533369 in debootstrap (Ubuntu Karmic) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,New] https://launchpad.net/bugs/533369 [13:32] I've approved the nomination but have no time to do SRUs just now [13:33] <\sh> cjwatson: thx :) [13:33] seb128, what do I need to do to start the ball rolling on MIRs for utouch stuff? [13:34] https://wiki.ubuntu.com/MainInclusionProcess? [13:34] cnd, write mir reports for those? [13:35] ok, I assume it's documented there [13:35] I asked before I google searched [13:35] did 10.04.1 go out? [13:35] * cnd chastises himself [13:35] thanks seb128 [13:36] cnd, right, that page describe what you need to do [13:42] <\sh> cjwatson: if it helps you, I'll prepared an debdiff for the SRU (needs uploading to lucid-proposed) === MacSlow|lunch is now known as MacSlow [13:46] siretart: do you know what the status of bug 374900 is? can it be closed? [13:46] Launchpad bug 374900 in faac (Ubuntu) "Libfaac not LGPL" [High,Triaged] https://launchpad.net/bugs/374900 [13:47] \sh: I thought you were a core-dev - can't you upload it directly? [13:47] \sh: the debdiff isn't what takes the time for SRUs for me, it's the administration [13:49] <\sh> cjwatson: I'm not :) [13:49] <\sh> cjwatson: anymore :) [13:52] I made a bug report against the upstream project in lp, how can I move that to the ubuntu package project? [13:52] or is that possible? [13:54] cnd: Click the "also affects distribution" link. [13:55] soren, ahh [13:55] thanks! [13:55] cnd: Sure. [14:04] <\sh> micahg: ping === juliank0 is now known as juliank [14:07] seb128, does a packages build deps all need to be in main, or just binary package deps? [14:07] build-depends as well === dendro-afk is now known as dendrobates [14:29] Riddell: the TB has asked cjwatson to look into this. Collin, any news on that? [14:37] hi persia - do you mind if i hijack bug 522645, or did you plan to do any work on that? [14:37] Launchpad bug 522645 in chromium-browser (Ubuntu) "[MIR] chromium-browser" [Undecided,Incomplete] https://launchpad.net/bugs/522645 [14:39] chrisccoulson, I never intended to work on it: I filed it because there were discussions as to whether it would be in main, and I thought they should be tracked in a bug. You aren't hijacking it (or I would have been assigned) [14:40] persia - cool, thanks. i'll use your existing report then rather than starting a new one [14:40] chrisccoulson, That's why it's there :) Good luck. [14:41] siretart: none, sorry [14:41] (P.S. "Colin") [14:41] heh, thanks ;) === _martin is now known as m4rtin [14:55] how can I figure out where a Linaro kernel package lives? linux-image-2.6.35-1001-omap_2.6.35-1001.5_armel.deb is not in http://archive.ubuntu.com/ubuntu/pool/{main,universe}/l/linux or http://ports.ubuntu.com/ubuntu-ports/pool/{main,universe}/l/linux [14:56] linux-image-2.6.35-1001-omap_2.6.35-1001.5_armel.deb ? [14:56] that would conflict with the existing omap image, no ? [14:56] ograthe ABI is different [14:56] ogra: ^^ [14:57] still very confusing [14:57] https://edge.launchpad.net/ubuntu/maverick/+queue?queue_state=3&queue_text=linux-image-2.6.35-1001-omap [14:57] tgardner, cant you have a linaro in the name somewhere ? [14:57] ogra: thats what I'm working on [14:57] ah [14:57] persia, hi! [14:58] tgardner, is the package through the NEW qeueu already ? [14:58] (else you wont find it in the archive) [14:58] dholbach, we pull the package from the archive to extract the ABI, so I need to know the URL [14:59] ara, The document I'm sure you want to ask me about has been getting better every couple days, but still doesn't quite make sense to the uninitiated. [14:59] tgardner, I'm afraid I don't know [14:59] ogra: I think so. checking... [14:59] tgardner, I just searched for it === sconklin-gone is now known as sconklin [14:59] the meta is at http://ports.ubuntu.com/ubuntu-ports/pool/universe/l/linux-linaro-meta/ but i dont see the actual package [14:59] persia, OK, thanks for the update [14:59] persia, anything I can help with? [15:00] tgardner, does https://edge.launchpad.net/ubuntu/+source/linux-linaro help? [15:00] persia! hope I didn't miss your ping in the recent past. I know you said you wanted to talk with me after Platform. [15:00] ara, Not right now, but I'll copy you on the next review round: I'm still processing notes from the last review (separation of policy & procedure, etc.) [15:00] dholbach, I can see it via Launchpad, but I'm not finding the binary in the archive [15:01] JFo, I think I didn't ping you, but I'll accept reverse pings :) [15:01] heh [15:01] tgardner, ok [15:02] tgardner, http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-linaro/ [15:02] there it is [15:02] ogra: wtf? why did it go there [15:03] armel is all on ports [15:03] tgardner, someone accepted it into main and its armel [15:03] is anyone here using GMA500 on maverick? [15:03] cjwatson, its not ports that I'm questioning, it linux-linaro === smb is now known as smb-afk [15:03] well that's just the source package name somebody gave it [15:04] Changed-By: John Rigby [15:04] Maintainer: Ubuntu Kernel Team [15:04] Signed-By: Tim Gardner [15:05] tgardner, well, you apparently signed it :) [15:05] cjwatson, ok, I get it now. it follows the source package name. guess I should have figured that out. === dendrobates is now known as dendro-afk [15:14] bdrung: OMG, you're fast. [15:15] I just saw a debdiff uploaded within 45 minutes of posting. [15:15] nigelb: i am always fast :P [15:15] Even before I could catch up with the mail trail ;) [15:15] bdrung: Now I know :D [15:16] nigelb: your debdiff for karmic needs a refresh and sponsor-patch should not pull a version from -backports === dendro-afk is now known as dendrobates [15:17] bdrung: wait, It should \sh gave a new debdiff? [15:18] ah, that was for lucid. [15:18] ok, I'll try to get to it. === bjf[afk] is now known as bjf [15:42] sabdfl: hi! any chance on choosing a name for 11.04 soon? it's getting to that part in the release cycle where people are writing maverick+1 a lot :) === jj-afk is now known as jjohansen [15:51] <\sh> nigelb: what? [16:02] <\sh> bdrung: thanks for sponsoring === rmcbride_ is now known as rmcbride [16:06] \sh: yw === pitti_ is now known as pitti === smb-afk is now known as smb === amitk is now known as amitk-afk [16:48] pitti: ping === asac_ is now known as asac [17:01] \sh: um, sorry about the ping. It was about the debbootstrab bug for which you uploaded debdiff for sru. [17:05] I'm still wondering about my user-mode-linux ftbfs in lucid-proposed. An identical build in my ppa worked flawlessly. Is there any reason whatsoever why an amd64 buildd would report a 32 bit personality? [17:05] *blink* cosmic rays? [17:05] not that I can think of, maybe check with lamont [17:05] It did it twice. [17:05] The only way I can get it to fail in a similar way for on my local box is by prefixing dpkg-buildpackage with linux32. [17:06] lamont: Any clues at all? [17:06] https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058 <---- the build in question [17:07] soren - it's funny you should mention that, as i've just started getting loads of weird build failures on amd64 for all of the mozilla daily builds [17:07] chrisccoulson: Fascinating. [17:07] things like this - http://launchpadlibrarian.net/53843956/buildlog_ubuntu-maverick-amd64.firefox_3.6.9~hg20100817r34534%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz [17:07] chrisccoulson: On all buildd's or just.. [17:07] soren: interesting as all get out [17:07] soren - on everything, on all releases [17:07] in fact, i386 builds are frequently done on amd64 kernels, with linux32 in front of things [17:07] soren - https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages [17:07] lamont: This is an amd64 build. [17:07] all todays builds failed :( === maco2 is now known as maco [17:08] chrisccoulson: Even in the PPA? [17:08] there was some chatter about repurposing some amd64 PPA buildds as i386; I smell a rat [17:08] soren - yeah, these are all PPA builds [17:08] chrisccoulson: Ah, I see. [17:08] sh: gcc: not found [17:08] dpkg-architecture: warning: Couldn't determine gcc system type, falling back to default (native compilation) [17:08] I don't like that much [17:08] that always happens, doesn't it? [17:08] yes, it does [17:08] I thought so too. It didn't raise an eyebrow. [17:08] I thought that was an artifact of something being run outside the chroo [17:08] Ok. [17:08] t [17:08] that's not new for sure [17:09] true [17:09] <\sh> nigelb: I didn't do the karmic one...cause I didn't have a karmic sbuild right now [17:09] the machine clearly thinks it's amd64... [17:10] \sh: I know. bdrung has asked me to refresh it a bit :) [17:10] Kernel build from 10 hours ago worked fine. My initial build that failed was from 6-7 hours ago. Did anything change roughly in that timeframe? === em is now known as emma [17:11] <\sh> nigelb: cool... [17:11] * soren does an experiment [17:11] soren: I assume MCORE2 is 64-bit, yes? [17:11] <\sh> now gone from office [17:11] nigelb: i would have refreshed it, but sponsor-patch pulls the wrong version. i need to fix this first. [17:11] lamont: It supports both. [17:11] cjwatson - checking target system type... i686-pc-linux-gnu [17:11] checking build system type... x86_64-pc-linux-gnu [17:11] :/ [17:11] err.. obviously. [17:11] bdrung: heh, trying to fix one bug exposes another. Normal :) [17:12] nigelb: it's unrelated. it's the first package i touch that had a backport [17:12] lamont: CONFIG_MCORE2 is set by the config. It chooses the config based on dpkg --print-architecture (which, incidentally perhaps, is unaffected by personality). [17:13] bdrung: Ah, cool :) [17:13] well, and crested is amd64 with an amd64 chroot, so shouldn't matter [17:14] nigelb: do you have the bug number at hand? [17:15] lamont: Unless something accidentally runs it with linux32. [17:16] soren: the last thing I'm aware of that has even a remote chance of having affected it happened on crested 20 hours ago [17:16] lamont: Can you bump the build score of this: https://edge.launchpad.net/~soren/+archive/ppa/+build/1922960 ? [17:16] and everywhere else about the same time [17:16] lamont: It's a bit of an experiment. [17:16] lamont: And what would that be? [17:17] Start in 1 minute (55555555) [17:17] lp-buildd upgraded [17:17] Wow. [17:17] I feel so special. [17:17] OTOH, changes were all elsewhere [17:17] string of 5's is my "special" value. [17:20] bdrung: 533369 [17:20] bdrung: bug 533369 [17:20] Launchpad bug 533369 in debootstrap (Ubuntu Karmic) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,New] https://launchpad.net/bugs/533369 [17:20] nigelb: thx [17:21] Aha! [17:21] Linux promethium 2.6.24-27-xen #1 SMP Wed Mar 24 12:56:18 UTC 2010 i686 GNU/Linux [17:21] from the amd64 build. [17:21] (output of uname -a) [17:21] lamont: ^ [17:21] i686 == bad [17:21] :) [17:22] so, that will be why all my builds fail then ;) [17:22] Indeed. [17:22] phew :) [17:22] * chrisccoulson wipes brow [17:24] neat [17:25] Maybe the kernel got lucky, because it specifically passes an ARCH value. [17:25] user-mode-linux's ARCH setting is "um", the SUBARCH is detected from uname -m. [17:26] * lamont yanks the rug out from under promethium, investigates [17:26] cjwatson: well, it's rather a long window to freeze all security updates, and in the past I thought we did handle this as freezing -updates publishing only since the relevant question is whether we have the source to reproduce the images? or maybe I've not accurately understood the purpose of the archive snapshot [17:27] slangasek: I may be wrong; I suspect there is room for process refinement ... [17:27] lamont: I doubt it's specific to promethium. If you're just picking a random one for investigation, that's cool, but I'm seeing the same on crested and chrisccoulson had it happen on a bunch of different ones. [17:27] lamont: just sayin'. [17:28] yeah - just picking a random known place [17:28] and I have my suspicion [17:29] so i've got a bzr branch that i had proposed for merge, and the relevant commits were in fact merged into lucid-proposed. But the tree is still listed as pending merge. Shoudl I cancel the merge request, or leave that until it gets from lucid-proposed into lucid-updates? [17:30] lamont: Lovely. [17:30] chrisccoulson: Thanks for chiming in. I would have stared at this for hours thinking it was local to this package. [17:31] chrisccoulson: Or days, even. [17:31] soren: so... I've put all of amd64 on manual for a little bit while I do somemore investigating. [17:31] since all around, feh. [17:31] soren - heh, you're welcome ;) [17:31] * soren is stubborn with stuff like this [17:31] i probably also would have spent a long time looking at it if cjwatson didn't suggest what the issue might be ;) [17:32] chrisccoulson: What? Cosmic rays? :D [17:32] we might need to look into the possibility that there have been misbuilds [17:33] cjwatson: verily [17:34] rephrase: does a merge proposal need to stay open for commits to propagate from lucid-propsoed to lucid-updates? Or will that happen (barring regressions/objections) regardless? [17:34] the merge proposal doesn't need to stay open for that [17:34] cjwatson: thanks [17:35] if it's been (effectively) merged into its target branch, you can mark it as merged [17:38] cjwatson: don't see how to do that in the lp bzr page (need some special privs?) but i've deleted the proposal, so hopefully all's good [17:38] that should be fine [17:39] (though then it always lists as 'supserseded' for merge... weird) [17:44] Hi, I am learning C++/Qt and want to switch to GTK [17:45] What are the packages that I need as a C++/GTK developer? [17:45] hallyn: you can just change the status to "Merged", can't you? [17:45] I do not want GTK+, I want GTKmm. But I do not know which packages I need? [17:45] mih1406: libgtkmm-2.4-dev is the primary one, and you'll probably want libgtkmm-2.4-doc too [17:45] (apt-cache search gtkmm) [17:45] SpamapS: where? [17:46] Is there a documentation for GTKmm packaged? [17:47] soren: version bump and re-upload your testpackage, give me the build record pls? [17:47] assuming it built successfully rather than failing, that is [17:47] lamont: 2 seconds. === bjf is now known as bjf[afk] [17:47] lamont: https://edge.launchpad.net/ubuntu/+source/user-mode-linux/2.6.32-1um-3ubuntu3.1/+build/1922058 [17:48] lamont: Just rebuild that one. [17:48] mih1406: libgtkmm-2.4-doc [17:48] sure [17:49] Heh. Launchpad has apparantly given up guessing when it'll build :) [17:49] 0 builders [17:49] Ah, of course. [17:50] lamont: That's not a PPA build, by the way. Don't know if you noticed or it matters at all. [17:51] cjwatson: libgtkmm-2.4-dev requires many packages!! [17:51] aborted all the currnetly-running amd64 builds [17:51] Are they important? [17:51] soren: yeah, no worries [17:52] 57 packages! [17:52] mih1406: yes, they're part of the interface [17:52] mih1406: (how much time do you want to spend second-guessing dependencies, versus getting on with your work? :-) ) [17:53] "second-guessing" ?? [17:54] "questioning". [17:54] Sort of. [17:55] sorry for that [18:00] mih1406: 100+ packages for build-depends is not a rare situation. just fyi [18:04] cjwatson: as for the meeting time problem, do you suggest earlier or later? [18:05] I want to develop in C++ and GTKmm what are good tools for that? [18:06] * jdong would be tempted to suggest a waterproof laptop and large amounts of vodka [18:07] bilalakhtar: I plan to suggest both and see what people like [18:07] cjwatson: well, my opinion doesn;t count that much, but I would say, early [18:08] bilalakhtar: it will have to be something that the board members can consistently make [18:09] cjwatson: yup, it appears persia is in a very eastern time zone, so for persia it would also be 'early' [18:09] lamont: Perhaps I should come up with a quicker test case :) [18:09] lamont: There it goes. [18:09] lamont: It works. [18:09] https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel - "Open to all to subscribe, posting moderated for people who are not Ubuntu developers" ... [18:09] lamont: It wouldn't have made it this far if it still failed. [18:09] Maybe its asking too much, but there seems to be no manpower behind said moderation. [18:10] cjwatson: 13 suspect builds, 12 if you ignore soren's lum build [18:10] Which, I know as an aspiring ubuntu developer, is fairly frustrating if you'd like to weigh in on anything. :-/ [18:10] bilalakhtar: OTOH push it much earlier and it's painful for USians [18:10] or Americans in general [18:10] always difficult [18:10] cjwatson: yup [18:10] SpamapS: I just did a partial moderation pass ... [18:10] with a developer community that huge its difficult to find the right time [18:11] SpamapS: I wouldn't object to more help, it's me + ev right now [18:11] cjwatson: You've been amazing at moderation. But I think you have quite a few things that count as higher priority on your plate. :) [18:11] though I do think moderators should be core-dev [18:12] I don't think I can claim to be an amazing moderator, no [18:12] I'm not saying I expect instant moderation. But the lag time for emails I've sent to ubuntu-devel has been 7-10 days since subscribing in June. [18:12] soren: awesome. time to go roll all the amd64 builders around [18:13] lamont: Care to share the gory details? [18:13] bilalakhtar: we may just need to rotate or something [18:13] cjwatson: yup [18:13] bye, people [18:13] cjwatson: I'm sure I've mentioned it before, but 4 in the morning is a better time for me than the current one. [18:14] cjwatson: I hate being a complainer when much of the work is in fact volunteer, so please feel free to tell me to stuff it and just concentrate on development. ;) [18:14] no, complaints are good reminders [18:14] soren: only under duress [18:14] lamont: :) [18:14] Oh, well, good times. It works now, I'm happy. [18:15] lamont: Thanks for looking into it so quickly. [18:15] soren: at this point, the 12 affected builds (1) might not be completely accurate, and (2) all I have is build ids.. working on getting actual URLs/package/version/archive info for them [18:15] lamont: How do you determine whether they're affected? [18:16] any amd64 build "first dispatched" since 20:00:00 UTC yesterday [18:16] There's only 12 of those? Wow. [18:17] I think we looked at builds launched since then, and found that none had been not first dispatched since then, but started. [18:17] soren: 13 with you. [18:17] this is a happiness [18:18] or at least a lesser sadness [18:18] Yeah, 12 builds are certainly a manageable set to have to rebuild. [18:19]