[01:29] <Daviey> Anyone from foundations around?
[01:31] <nixternal> go to bed
[01:32] <Daviey> nixternal, no you :)
[01:32] <nixternal> i will in a bit :)
[07:37] <didrocks> good morning
[08:10] <dholbach> good morning
[08:22] <pitti> Good morning
[08:34] <pitti> sconklin-gone: we need a matching linux-ubuntu-modules for hardy
[08:46] <pitti> jhunt: good morning
[08:46] <jhunt> pitti: morning
[08:46] <pitti> jhunt: would you like to write a short paragraph about new upstart features in alpha-3, in https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview ?
[08:47] <jhunt> pitti: certainly! I'll do that today.
[08:49] <pitti> jhunt: thanks; we'd like to finish the text soon
[08:50] <jhunt> pitti: in which case, I'll do it now :)
[08:53] <jhunt> pitti: should I add the detail to the "Ubuntu Desktop Edition" section, or do you think a new subsection in the "New Features" section is appropriate (since it affects all derivates?)
[08:55] <pitti> jhunt: there's already a 3.1.3 upstart section
[08:55] <jhunt> pitti: doh - where's that cup of coffee..
[08:55]  * pitti collects some "known bugs" documentation, but won't touch the wiki for now
[08:58] <pitti> jhunt: in fact, it doesn't actually need to be limited to a3 -- over time this page will become the full natty release notes
[08:59] <jhunt> pitti: gotcha
[09:22] <jhunt> pitti, cjwatson: how much detail do we want for user sessions (since we've disabled them by default)?
[09:22] <pitti> jhunt: I think leave them out for now, and add them for beta-1, when they'll actually work?
[09:23] <jhunt> pitti: ok. The good news is that they seem to work pretty well for me, but more testing is required.
[09:47] <jhunt> pitti: wiki updated. The styling on that page might need some work - look at how the heading "Override Files" displays in the body of the page.
[09:50] <pitti> jhunt: great, thanks! wow, that got quite detailled
[09:51] <jhunt> pitti: feel free to dilute it if necessary - my brain is currently stuck in "man page mode" :)
[10:27] <apw> jhunt, this tech overview for upstart is very good ...
[10:28] <jhunt> apw: thx! (I'll pay you later... ;)
[11:20] <apw> jhunt, upstart Q, where is virtual-filesystems emitted ?
[11:20] <jhunt> apw: mountall.
[11:22] <jhunt> apw: Here's a preview of the new upstart-events summary that'll be in natty next week - http://people.canonical.com/~jhunt/upstart/man/upstart-events.pdf
[11:22] <jhunt> apw: pdf rendering isn't perfect - looks much better in a console! :-)
[11:23] <apw> jhunt, awsome.  i am looking at how we might inject a fallback framebuffer load without unduly slowing boot
[11:23] <apw> as having vesafb and drm loaded at the same time is causing GPU hangs, and upstream just think we are mad loading both
[11:25] <apw> jhunt, nice information though ... good stuff
[11:30] <apw> jhunt, now 'graphics-device-added' etc are presumably created by the udev-upstart bridge ?
[11:31] <jhunt> apw: indeed
[11:31] <apw> those could do with being on your new page :)
[11:32] <jhunt> well, the trouble is - there are a lot of possible events there: "*-device-*". I have listed some common ones.
[11:33] <seb128> pitti, we should perhaps discuss cd use here
[11:33] <apw> jhunt, yeah i would prolly add just the two graphics ones as they are of interest in start sequence
[11:34] <seb128> pitti, so /usr/lib/gcc won a cc1plus binary between a2 and a3 it seems
[11:37] <seb128> pitti, the /usr/lib/egl dir was not in a2 and add an extra 6 as well
[11:38] <seb128> pitti, those are the obvious things I see
[11:38] <jhunt> apw: ok - I'll add graphics-device-added and drm-device-added. Would that cover it? See "Note K" (Tables 1 and 4) for what I have so far wrt the *-device-* issue.
[11:39] <apw> jhunt, yeah there are clearly infinite numbers of actual events, but those two as they appear comonly in the most complex upstart interactions seem appropriate
[11:39] <jhunt> apw: right
[11:39] <pitti> seb128: seems libcairo pulls in libegl
[11:40] <seb128> pitti, that's because we enabled the gl backend which is needed for wayland
[11:40] <pitti> seb128: I think we could safely drop g++; for building drivers (which is the primary reason we have this), gcc should be enough?
[11:40] <apw> jhunt, what sort of upstart job would i want to use to run a single modprobe
[11:41] <seb128> pitti, well, do you know why we g++ got added to the cd?
[11:42] <pitti> I don't know
[11:42] <pitti> seb128: I think it has been there all the time, it just grew?
[11:42] <jhunt> apw: not quite sure what you mean. There are existing jobs which do modprobes (gssd, autofs, cups, qemu-kvm, etc).
[11:43] <seb128> pitti, seems a2 didn't have build-essential or g++
[11:43] <pitti> seb128: ok, then that's new indeed
[11:43] <cjwatson> if the modprobe is triggered solely by a udev event, a udev rule should be sufficient for the modprobe
[11:43] <seb128> or the fact that it was missing in a2 was buggy
[11:43] <cjwatson> you'd use an upstart job for that if the start conditions are more complex
[11:43] <seb128> pitti, well in any case g++ and elg is most of the difference
[11:43] <seb128> they add an extra 16
[11:44] <apw> jhunt, i should better ask if i know which event woke a job ... as i want this job to basically start if a framebuffer appears or cold plug is complete ... but i want it to no-op itself if we woke on framebuffer
[11:44] <pitti> seb128: we'll drop 2.8 MB from libreoffice-style-tango
[11:44] <apw> cjwatson, yeah indeed.  this is going to me much more complex i fear
[11:44] <apw> this is vesafb fallback fixup
[11:47] <pitti> seb128: apparently build-essential is a new recommends, I can purge it
[11:47] <seb128> pitti, I've no strong opinion, I just tried to help by having a look at what changed between a2 and a3
[11:48] <seb128> works for me
[11:48] <cjwatson> apw: LESS=+/UPSTART_ man 5 init
[11:48] <seb128> let's try to drop it and see if it creates any issue?
[11:48] <pitti> seb128: did we have dpkg-dev previously?
[11:48] <seb128> pitti, no
[11:48] <seb128> it's all part of what ev added with dpkg-repack to ubiquity
[11:49] <pitti> aah
[11:49] <seb128> https://bugs.launchpad.net/ubuntu/+source/dpkg-repack/+bug/726453
[11:50] <seb128> ev: dpkg-repack is tiny but it's bringing g++ on the CD ;-)
[11:51] <seb128> ok so dpkg-repacks Depends on dpkg-dev which Recommends build-essential which depends on g++
[11:51] <seb128> pitti, ^
[11:51] <ev> oh, I mistakenly thought that was a recommends
[11:51] <pitti> right
[11:51] <seb128> not sure if we can lower the recommends to a suggest
[11:51] <ev> err yes
[11:51] <ev> suggest
[11:51] <pitti> dpkg --build needs dpkg-dev, I take it?
[11:52] <pitti> seb128: dpkg-dev suggests: b-e?
[11:52] <pitti> it doesn't really sound correct for a developer installing it, but then again the recommended package to install is b-e anyway
[11:52] <seb128> well that's the only thing we can lower in those
[11:52] <pitti> and it would certainly fix that
[11:52] <seb128> that seems wrong though
[11:53] <pitti> seb128: what?
[11:53] <seb128> if dpkg-dev recommends build-essential there is probably a reason
[11:53] <seb128> let me check
[11:54] <cjwatson> I think the dpkg-dev Recommendation needs to stay TBH
[11:54] <cjwatson> we already have enough confusion from users wondering why packages don't build
[11:54] <cjwatson> but I'm not sure of a better solution
[11:54] <cjwatson> hm, added in dpkg 1.14.16
[11:55] <cjwatson> one thing here is that we had *just* got to the point where all the Ubuntu-local dpkg changes had been accepted upstream
[11:55] <pitti> dpkg-dev itself is already .5 MB packaged, which we can cope with, but not b-e
[11:55] <cjwatson> it would be really very irritating indeed to add another source of long-term divergence
[11:55] <cjwatson> I wanted to get dpkg synced
[11:56] <seb128> ev: do you really need dpkg-repack?
[11:56] <pitti> would it be possible to copy /usr/bin/dpkg-buildpackage into dpkg-repack? (also hackish, I know)
[11:56] <cjwatson> ick, no!
[11:56] <seb128> or could you just copy what you need in ubiquity?
[11:57] <pitti> seb128: you mean copy the package's files, isntead of dpkg-repack'ing it and installing it again?
[11:57] <cjwatson> I don't actually understand why dpkg-repack needs dpkg-dev
[11:57] <cjwatson> it doesn't, AFAICS, use it
[11:57] <seb128> pitti, yeah, not sure what ubiquity was doing before dpkg-unpack started being used recently
[11:57] <pitti> cjwatson: it calls dpkg-buildpackage
[11:58] <pitti> cjwatson: well, it calls dpkg --build, which does AFAIK?
[11:58] <cjwatson> no
[11:58] <seb128> cjwatson, well, https://bugs.launchpad.net/ubuntu/+source/dpkg-repack/+bug/726453
[11:58] <cjwatson> dpkg --build does not call dpkg-buildpackage, that would be infinite recursion
[11:58] <cjwatson> dpkg --build is what dh_builddeb calls
[11:58] <seb128> hum
[11:58] <pitti> ah, it calls dpkg-deb -b, I figure (which is in dpkg)
[11:58] <cjwatson> indeed
[11:58] <pitti> perfect
[11:59] <pitti> I went through the dpkg-repack code, and that's the only place which could potentially use
[11:59] <pitti> ... dpkg-deb
[11:59] <pitti> dpkg-dev, I mean
[11:59] <cjwatson> likewise
[11:59] <cjwatson> dpkg-repack (1.19) unstable; urgency=low
[11:59] <cjwatson>   * Add missing dependency on dpkg-dev.
[11:59] <cjwatson>  -- Joey Hess <joeyh@debian.org>  Fri, 20 Aug 2004 13:42:03 +0100
[12:00] <cjwatson> ah, I think it may have been because it used to use 822-date
[12:00] <cjwatson> that was in dpkg-dev; but that was deprecated and replaced with date -R
[12:01] <cjwatson> I think that was the source of the dependency, but it's no longer relevant
[12:01] <pitti> \o/
[12:01] <cjwatson> pitti,seb128: ubiquity> the dpkg-repack stuff is a new feature in ubiquity
[12:02] <cjwatson> it's for trying to do a neater job of installing over an existing system I believe (I haven't actually kept up, bad me)
[12:02] <seb128> ok
[12:02] <seb128> in any case if we can drop the depends problem solved ;-)
[12:02] <cjwatson> yep
[12:04] <ev> neater job of installing over an existing system> yes, the original option was buried in the advanced partitioner and only preserved files in /home.  This cycle we've pushed it to an automatic partitioning option (as probably noticed) and added the functionality to preserve the set of applications previously installed (thus apt-clone and in turn, dpkg-repack).
[12:04] <Daviey> Hi, would a member of foundations mind looking at the debdiff for bug #711425 , comment 10.  Thanks.
[12:05] <seb128> ev: nice option ;-)
[12:06] <ev> seb128: thanks, much thanks to mvo for the apt-clone code.
[12:06] <seb128> pitti, so I'm not sure what to do about cairo, the only reason we turn on the gl backend (which is not a stable one) is to be able to get wayland in universe
[12:07] <pitti> seb128: it's 1.5 MB packaged, I guess we'll need to leave it for now? Or can we split out the backend in cairo?
[12:07] <seb128> we can't
[12:07] <seb128> it's not a separate file
[12:08] <seb128> pitti, it's likely bryce would not be happy if we said that wayland needs to go, he just got it in universe
[12:08] <seb128> pitti, though I doubt it's really useful for any users right now
[12:08] <seb128> it's rather a tech demo thing
[12:09] <pitti> seb128: so at most we could build a libcairo-egl (Providing libcairo)
[12:09] <seb128> it's likely people who want it will want to do work on it and will need updated builds
[12:09] <pitti> but no, libraries often have versioned rdepends, so nevermind
[12:09] <pitti> seb128: I think getting off g++ and b-e, and libreoffice-style-tango should already buy us quite a bit
[12:10] <seb128> right
[12:10] <pitti> I chopped of 20 MB worth of langpacks
[12:10] <pitti> 'off'
[12:10] <seb128> dropping egl will not win us an extra language pack it seems
[12:10] <pitti> ghostscript also grew quite a bit, that might be worth investigating, too
[12:11] <seb128> speaking of language-pakcs
[12:11] <seb128> the current one is 1.5 months old
[12:11] <seb128> is there any chance to get new ones in natty?
[12:12] <pitti> seb128: yeah, I'm still working on fixing up the firefox langpacks
[12:12] <seb128> so it's firefox blocking us?
[12:13] <seb128> it's not translated anyway in natty
[12:13] <seb128> can't we just do an update with firefox still broken?
[12:13] <seb128> ok, lunch time
[12:13] <seb128> brb
[12:27] <pitti> seb128: we can, but not now, when we're still rebuilding CDs :)
[12:27] <pitti> (also, we need a full export now)
[12:50] <ogra> to get messages on the splash using 'plymouth message --text"..."', do i need to drop quiet from the cmdline ?
[12:50]  * ogra wonders how mountall enforces that
[13:08] <apw> can someone remind me the magic command which one uses in a 'packaging only' bzr branch to make it packageable as a source package
[13:08]  * apw goes quietly mad trying to remember
[13:08] <pitti> seb128, cjwatson: FYI, opened bug 728424 to track this, and sent a bug to Debian as well (will link once ack comes in)
[13:08] <cjwatson> pitti: thanks
[13:08] <pitti> I can upload this after a3 if you want me to
[13:09] <cjwatson> apw: bzr bd -S
[13:09] <seb128> pitti, thanks
[13:09] <seb128> pitti, it doesn't seem to be any hurry there, maybe wait for debian to comment
[13:09] <apw> cjwatson, thanks ... no wonder i didn't remember
[13:09] <cjwatson> I think it would be OK to go ahead, but either way
[13:09] <pitti> seb128: it's a simple change, I'd like to do it to see where we are space-wise
[13:10] <cjwatson> apw: you should be able to use that (or a variation) for any source package in bzr, packaging-only or not
[13:10] <cjwatson> if that helps
[13:12] <apw> cjwatson, nice
[13:12] <seb128> pitti, seems safe enough to just upload as well yeah
[13:35] <cjwatson> jhunt: hm, are all those upstart changes in the technical overview actually in alpha-3?  I think perhaps it would be worth commenting out ones like visualisation which aren't, for now
[13:39] <janimo> fta, is there an easy way to build selected third-party modules under the chromium tree?
[13:40] <janimo> without having the whole package built once
[13:40] <janimo> I can probably look at the build log and copy paste the config/make equivalent bits but am wondering if the debian rules file provides some help in this regard
[13:46] <jhunt> cjwatson: do you know the magic to comment out chunks? I could just remove the vis sections until next week I guess.
[13:47] <cjwatson> jhunt: https://wiki.ubuntu.com/HelpOnProcessingInstructions has it
[13:47] <cjwatson> (and other useful stuff)
[13:47] <cjwatson> (the root of that is HelpOnEditing)
[13:48] <ricotz> pitti, hello, i think gobject-introspection could be synced from experimental http://packages.qa.debian.org/g/gobject-introspection/news/20110228T205151Z.html
[13:49] <jhunt> cjwatson: thx! I'd tried 3 other MoinMoin comment techniques, but they either didn't do what I wanted, or broke the parser horribly :)
[13:51] <jhunt> grr - am I the only one seeing lots of server errors when editing pages on wiki.ubuntu.com?
[13:56] <cjwatson> jhunt: no, it's common unfortunately; however, it's usually on redisplay *after* your changes have been committed, IME
[13:57] <jhunt> cjwatson: yes, I'd noticed that after attempting to re-apply changes and getting conflicts :)
[14:08] <ari-tczew> does anybody know when Robert is sponsoring today?
[14:09] <pitti> ari-tczew: Robert Ancell? He's currently off for some days
[14:12] <ari-tczew> pitti: I thought today is his piloting...
[14:14] <ari-tczew> pitti: https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com&ctz=Europe/Berlin&gsessionid=OK
[14:14] <fta> janimo, not really, depends on which modules, some are buildable independently, like v8 and nacl. what do you have in mind?
[14:17] <pitti> ari-tczew: yes, it wasn't a planned absence
[14:18] <janimo> fta, never mind I managed to get a build
[14:18] <janimo> ffmpeg. I am looking into the arm ftbfs
[14:18] <fta> janimo, i know the problem and the fix, it's my fault
[14:20] <fta> janimo, when i merged the codecs into the browser source package, i dropped a flag (arm_neon=0) inadvertently
[14:20] <ari-tczew> pitti: OK, thanks for info,
[14:20] <janimo> fta ah ok
[14:20] <janimo> fta also why is armv7=0 ?
[14:20] <fta> janimo, i will re-add it soon, but i need to check something else too
[14:21] <janimo> was that too dropped?
[14:21] <ogra> just dont set arm_neon=1 :)
[14:21] <ogra> unless there is runtime detection in the code
[14:21] <fta> exactly, that armv7=0 is troubling, it's enabled in the codecs and desabled in the browser, or the opposite, that's wrong
[14:21] <janimo> I saw armv7=0 is set in debian/rules
[14:22] <janimo> but if you are on it ok, I'll live it :)
[14:22] <fta> yeah, i'm on it, but more generally, as i said in my blog post yesterday, i suck at supporting arm, by lack of h/w
[14:23] <fta> can't build, can't test
[14:24] <fta> there's a problem with the PIE hardening on arm leading to a crash, i can't investigate
[14:24] <fta> so i disabled it :(
[14:26] <janimo> fta, do you want me to enable hardening (is this the PIE part then?) and see what happens?
[14:28] <fta> janimo, it was enabled for a while, but someone reported a crash. see bug 716703
[14:32] <didrocks> pitti: needs your lights right now, got a few minutes?
[14:33] <pitti> didrocks: my lights?
[14:33] <pitti> didrocks: in a bit, need to finish the alpha-3 images
[14:33] <didrocks> ok, that's not translatable :)
[14:33] <didrocks> pitti: sure
[14:33] <didrocks> pitti: then, can you join #ubuntu-touch?
[14:41] <sconklin> pitti: lucid ec2 and meta-ec2 may be copied from the PPEA to -proposed when you have time, thanks
[14:46] <mvo> ev: re bug 722758 (debconf db locked in apt-clone). I like the idea of clong the debconf db, I will add code for that and (for savety) chroot into the targetdir when invoking dpkg - does that sound reaonsonable?
[14:53] <ev> mvo: it does
[14:54] <ev> the installer does employ debconf-copydb at the end, but only for questions that wouldn't impact packages pulled in by apt-clone, if I remember correctly
[14:55] <ev> well, console-setup, but we'd want to overwrite that anyway.
[15:00] <cjwatson> SpamapS: do you want to deal with the SRUs for bug 531912?
[15:02] <cjwatson> SpamapS: (and sorry for the long review delay)
[15:03] <cjwatson> SpamapS: note that I applied a few tweaks on top of your merge, so you'd want to backport from lp:ubuntu/openssh
[15:05] <janimo> fta, the chormium rules file were much easier to read and modify if those nested ifdefs were indented :)
[15:05] <janimo> less chance to make mistakes too  I guess
[15:07] <fta> janimo, well, Makefiles and indentations..
[15:08] <psusi> cjwatson: got any hints on how I could try to debug that partman-auto reuse script problem?  like maybe running the scripts outside of ubiquity maybe with set -x?
[15:11] <cjwatson> psusi: bug#?
[15:11] <cjwatson> psusi: don't bother trying to run them outside of ubiquity
[15:11] <cjwatson> you will waste your time and get confused :)
[15:15] <psusi> cjwatson: bug #725408
[15:16] <cjwatson> psusi: please attach the syslog and partman logs to the bug
[15:16] <cjwatson> I can normally analyse from there
[15:16] <psusi> will do.. any others?
[15:16] <cjwatson> no
[15:34] <SpamapS> cjwatson: ack .. I will look at doing the SRU very soon.. don't want to commit just yet though.
[15:35] <cjwatson> SpamapS: np, thank you!
[15:36] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 25 minutes in #ubuntu-classroom
[15:39] <dholbach> chrisccoulson, micahg, how hard is it to fix thunderbird's click-on-a-link problem?
[15:39] <chrisccoulson> dholbach, hard
[15:39] <chrisccoulson> i'm going to work on it, but it's going to be a non-trivial patch
[15:39] <chrisccoulson> it's basically:
[15:39] <chrisccoulson> 1) Add gio support to mozilla-1.9.2
[15:40] <chrisccoulson> 2) Wire it in :)
[15:40] <dholbach> just put a "os.system('gnome-open %s' % link)" in there ;-P
[15:40] <dholbach> chrisccoulson, and that's something nobody upstream is interested in?
[15:40] <seb128> dholbach: will teach you to not sure what we ship with ubuntu ;-)
[15:40] <mr_pouit> s/gnome-open/xdg-open/ at least
[15:40] <chrisccoulson> i've been talking to upstream about it, it's not the sort of thing that's ever going to get fixed upstream in thunderbird 3.1
[15:40] <chrisccoulson> but we will fix it in comm-central and then carry a distro-patch
[15:41] <chrisccoulson> comm-central already has gio support though
[15:41] <chrisccoulson> comm-1.9.2 doesn't ;)
[15:41] <dholbach> mr_pouit, I was not really serious, but thanks for reminding me of xdg-open :)
[15:41] <chrisccoulson> i don't think the thunderbird guys are particularly pleased with things being broken like this
[15:42] <chrisccoulson> i will work on it next week, but i suspect it will be quite a substantial distro-patch to fix it
[15:42] <cjwatson> dholbach: subprocess.call(['gnome-open', link]) please ;-)
[15:42] <cjwatson> or in fact, probably webbrowser.open(link) ...
[15:43] <dholbach> ok ok ok ok, I better shut up before I make it worse
[15:43] <chrisccoulson> lol
[15:43] <cjwatson> heh
[15:43] <chrisccoulson> dholbach, it's also semi-broken in firefox too
[15:43] <chrisccoulson> but not as bad
[15:46] <ogra> pitti, are there any known issues with the WI tracker atm ?
[15:47] <pitti> ogra: not known to me, anyway
[15:47] <ogra> https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update doesnt show up for ubuntu-armel at all
[15:47] <chrisccoulson> dholbach, have you seen https://mozillalabs.com/messaging/messaging-menu/ btw?
[15:47] <chrisccoulson> you might be interested, as a tbird user ;)
[15:47] <seb128> we should stop shipping emails client and use web emails
[15:48] <chrisccoulson> heh
[15:48] <chrisccoulson> we should stop shipping everything, and just provide a console for users to install software with ;)
[15:48] <nigelb> hehe
[15:49] <nigelb> then we'd have big troll wars over whether emacs or vim is the default editor :P
[15:49] <dholbach> chrisccoulson, awesome
[15:49] <chrisccoulson> lol
[15:49] <chrisccoulson> it's nice they're using launchpad too :)
[15:49] <dholbach> it's not packaged yet?
[15:52] <chrisccoulson> dholbach, it's not packaged yet. i'll probably do that soon though
[15:53] <dholbach> nice
[16:07] <pitti> ogra: there are no work item s:)
[16:07] <pitti> ogra: I'm removing the empty line now, which will fix it
[16:07] <pitti> ... some more green on your charts now
[16:07] <ogra> hmm, it doesnt look any different than the other specs we have
[16:08] <pitti> ogra: there was an empty line after "work items:', which finishes the WI paragraph
[16:08] <ogra> oh
[16:08] <ogra> yeah
[16:08] <ogra> heh
[16:08] <ogra> thats why i didnt get error mail either then
[16:11] <pitti> a3 freeze lifted, go wild
[16:27] <jelmer> broder: thanks for sponsoring, much appreciated! :)
[16:27] <broder> jelmer: no problem. thanks for putting the patch together
[16:42] <pitti> wow -changes@ is fun again :)
[16:51] <pitti> sconklin: linux-ec2 lucid copied
[16:51] <sconklin> pitti: thank you!
[17:01] <ev> mvo: any preference on what the software center screenshot in the installer slideshow should show? The design team intern is updating them.
[17:01] <ev> how rude of me, Rollo, the intern for the design team.
[17:04] <mvo> ev: I have no preferences here
[17:04] <ev> okay
[17:40] <bjf> pitti, at your convenience, could the linux-firmware packages for lucid and maverick get promoted from -proposed to -updates ?
[17:49] <eitch0000> hello everyone. I'm trying to cross compile iperf from source. I'm on an amd64 machine and want to compile it for a i386 machine. Can someone help me with the ./configure script?
[19:57] <Daviey> Is an AA available to process SRU -proposed -> -updates for bug #717397... the duplicate reports are starting to build :(
[20:24] <fisch246> besides #ubuntu-bugs is there room for bite size bugs? or any other form of bug fixing?
[20:26] <fisch246> hm... that question might be considered support i suppose...
[20:28] <fisch246> nvm got my question answered :D
[20:37] <ari-tczew> Daviey: please be patient, pitti regularry takes care about SRUs
[20:38] <micahg> ari-tczew: if lots of people are affected, it's appropriate to attempt to escalate something
[20:38] <chrisccoulson> is someone available to approve firefox-globalmenu in NEW? :)
[20:38] <chrisccoulson> https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu3
[20:38] <chrisccoulson> perrrrrlease :)
[20:38] <ari-tczew> micahg: is there any problem with SRUs? maybe I'm not up-to-date
[20:40] <micahg> ari-tczew: normally not, but he said additional reports were coming in which could mean a need to push things out faster
[20:44] <ari-tczew> micahg: ah, so urgent is high
[20:46] <ari-tczew> how can I check which lib is needed for Objectpath::toString() ?
[21:29] <Daviey> ari-tczew, see the duplicate count :)
[21:39] <ari-tczew> Daviey: duplicate count?
[21:42] <notch> in some changelog files i see "Automated backport upload; no source changes". What is the tool used for this?
[21:48] <ari-tczew> notch: backportpackage
[21:49] <notch> ari-tczew: thx
[21:49] <ari-tczew> np
[21:50] <micahg> ari-tczew: no, it's an AA script that currently does this for official backports, backportpackage is different
[21:51] <micahg> one can use backportpackage to do something similar for oneself
[21:51] <Daviey> ari-tczew, For the SRU bug i quoted, how many bugs have been marked duplicate.
[21:54] <ari-tczew> Daviey: then poke pitti tomorrow
[21:54] <ari-tczew> ;)
[21:54] <ari-tczew> micahg: I know.
[22:30] <TheMuso> @pilot in
[23:42] <jderose> Question: in theory the Python Gobject Introspection bindings should work with traditional bindings, shouldn't they? They used to, but as of updated today `gi.repository.WebKit` isn't playing nice with plain ol `gtk` anymore... suggestions?