[00:12] <LLStarks> cjwatson, who keeps pushing back apt-sync/delta-debs?
[00:35] <Laibsch> pitti: are you going to assume reponsibility for the regression you introduced in bug 580961 or not?
[00:36] <Laibsch> Is asking you to forward-port an existing patch really too much to ask?
[00:46] <ion> laibsch: Judging from the bug comments, it seems to me he’ll be happy to sponsor a patch. Have you made one yet?
[00:46] <Laibsch> why is the burden to provide the patch on me?
[00:47] <Laibsch> he dropped the patch (introducing the regression) assuming the patch was no longer needed
[00:47] <Laibsch> I don't blame him for that
[00:47] <Laibsch> Somebody will need to forward-port the patch to unzip 6.x
[00:47] <Laibsch> I'm sorry that won't be me, not because I don't want to, but because I can't
[00:48] <Laibsch> I think he should accept that he's the one that should do this unless somebody steps up to the plate and volunteers
[00:48] <Laibsch> "I'm not being paid anymore to work in this area" is ultra-lame
[01:30] <aSt3raL> hi
[01:31] <aSt3raL> how do i compile with a makefile and redirect the output to a file in bash?
[01:33] <RAOF> make > foo.  Just like any other redirection.
[01:43] <aSt3raL> make > make.log 2>&1 actually
[01:43] <aSt3raL> thanks though
[01:57] <arand> Bug #588076 Is http://pastebin.com/128hP8jq (which I have confirmed to work) something which is sane to do?
[02:01] <arand> ↑↑ Nevermind, someone fixed it in git already :)
[05:17] <pitti> Good morning
[05:17] <pitti> ScottK: seems someone beat me to it; soprano is built now
[05:18] <pitti> wgrant: ah, fun; I had expected that the diff generation was the performance critical bit, and that a mere regex match over the .changes was cheap?
[05:49] <Semperfi40> Hello
[05:49] <Semperfi40> Is this a support channel?
[05:50] <micahg> !support | Semperfi40
[05:52] <Semperfi40> *Sad face* Bleh I'll just wait for more useful people to join that channel then. *Wanders back over to the ubuntu channel*
[06:33] <wgrant> pitti: Well, the diff generation is done by a cron job.
[06:33] <wgrant> pitti: +queue is notoriously timeoutish.
[06:35] <wgrant> However, we store the .changes' changelog section in the DB, so I can access it quickly and do something like http://people.ubuntu.com/~wgrant/launchpad/changelog-in-queue.png
[06:35] <wgrant> Or I could extract just the numbers, if I can find somewhere good to put them.
[06:35] <pitti> wgrant: timeoutish> heh, I noticed; binNEWing kernels is fun
[06:36] <pitti> wgrant: adding expanders to the queue items to see the .changes (similar to e. g. the PPA +packages view) is out of the questin?
[06:37] <wgrant> pitti: That's what the screenshot shows, isn't it?
[06:37] <pitti> oh, right; that'd be nice indeed!
[06:37] <wgrant> It's a bit different on +queue, since at the moment all of the expandy bits are rendered as part of the main page, whereas in PPAs they're AJAX loaded.
[06:38] <wgrant> So there's only so much we can safely throw into +queue before we AJAXify it.
[06:38] <pitti> wgrant: ah, I see
[06:38] <wgrant> But this particular change requires no more DB queries, so it's safe enough.
[06:38] <pitti> wgrant: well, I guess we'd keep our sru-review helper script either way
[06:39] <pitti> it currently parses out the bugs from the .changes, creates the debdiff, and opens all the affected bugs in the browser
[06:39] <pitti> and creates a command line for sru-accept.py
[06:39] <pitti> I expect we want to keep those, and just change it to grab the diff from LP instead of having to download the two packages and run debdiff
[06:39] <wgrant> sru-accept.py does the commenting on the bug thing as well, I guess?
[06:40] <pitti> the diff is the expensive part from the client side, so with this existing now I'm actually really happy :)
[06:40] <wgrant> And I guess it screenscrapes? :/
[06:40] <pitti> wgrant: s-accept adds a "test me" comment, sets tags, subscribes folks, and updates task status, yes
[06:41] <pitti> wgrant: sru-review screenscrapes the queue, right
[06:41] <wgrant> Right.
[06:42] <wgrant> I'm not sure how often the diff generation cron job is running, so it could take a few minutes to show up.
[06:42] <pitti> that should be fine
[06:42] <pitti> we aren't usually reviewing SRUs *that* closely :)
[07:02] <pitti> zul: seems your last samba merge in maverick reintroduced the ctdb b-dep; this was already discussed before (bug 497035), can this be dropped again? samba currently doesn't build because of that, and causes some uninstallability
[07:13] <pitti> zul: I'll just drop ctdb again, if that's alright with you
[07:15] <dholbach> good morning
[07:16] <pitti> hey dholbach, good morning!
[07:16] <dholbach> hey pitti
[07:22] <pitti> apw: good morning!
[07:22] <pitti> apw: I guess there's not much hope for bug 587888 to be fixed for alpha-1?
[07:22] <pitti> apw: we can release alpha-1 without deskop images, it's not the end of the world
[07:48] <pitti> Riddell, ScottK: so kdebase-plasma depends plasma-widget-folderview, but p-w-f conflicts kdebase-plasma; what's the solution here?
[07:49] <pitti> JontheEchidna: ^ or maybe you know?
[07:53] <mneptok> pitti: "use GNOME"
[07:53]  * mneptok whistles innocently
[07:54] <pitti> heh
[08:00] <dholbach> pitti: I'll unassign ~kubuntu-dev from bug 588150 - else every core-dev will get an email
[08:00] <pitti> dholbach: ah, sorry about that
[08:01] <dholbach> does core-dev need to be a member of kubuntu-dev?
[08:01] <pitti> for bzr branch committing, I suppose
[08:01] <dholbach> we should just use source package branches - that'd solve all those problems :)
[08:02] <dholbach> our acl <-> team membership landscape gets more and more complicated
[08:02] <dholbach> Riddell: ^ which team do you suggest for this bug?
[08:02] <dholbach> or ScottK maybe ^
[08:18] <dupondje> https://bugs.launchpad.net/ubuntu/+source/python-central/+bug/588156 => any comments on the merge ? :)
[08:18] <pitti> mr_pouit: FYI, I'm removing a couple of langpacks from the xubuntu alternate to fix the oversizedness; for those early alphas that doesn't matter much, I suppose
[08:19] <pitti> next build should be okay
[08:48] <summers> i would like to invite everyone to my new ubuntu channel, #ubuntu-faggots
[08:48] <summers> +o for everyone
[09:13] <apachelogger> james_w: hullos! is there any documentation on launchpad recipes? or examples for that matter
[09:32] <geser> Could a core-dev please give back: lftp libnice mdbtools transfig. Thanks.
[09:34] <pitti> geser: doing
[10:04] <LucidFox> So, there is no longer separate ubuntu-main-sponsors and ubuntu-universe-sponsors, but rather a single ubuntu-sponsors?
[10:05] <seb128> correct
[10:12] <LucidFox> So, I heard there are plans to enable GTK RGBA by default in maverick?
[10:14] <RAOF> LucidFox: Not so much “plans” as “it's currently breaking emacs-gtk” :)
[10:14] <LucidFox> heh
[10:14] <LucidFox> Is there a special tag for software that breaks it?
[10:14] <LucidFox> for bug reports, that is
[10:15] <seb128> gtk-csd
[10:15] <seb128> there is already a list of those
[10:15] <seb128> banshee, emacs, flashplayer, etc, etc
[10:16] <LucidFox> isn't gtk-csd for client-side decorations?
[10:21] <seb128> LucidFox, client side decoration and rgba are in the same changeset
[10:21] <seb128> LucidFox, csd requires rgba
[10:21] <LucidFox> Ah.
[10:22] <seb128> we don't need 2 different tags to track the same changeset issues
[10:22] <seb128> the idea is to have those bugs listed, not to be strict about matching tags wording ;-)
[10:24] <LucidFox> You see, the reason I'm asking is because I've had a patch lying for a while for xchat-gnome crash: bug #92028
[10:24] <LucidFox> normally I'd upload it myself, but xchat-gnome happens to be in main (why, by the way?)
[10:24] <seb128> because it's our recommended IRC client
[10:24] <LucidFox> ah
[10:24] <seb128> it's on the DVD I think
[10:25] <seb128> I'm fine sponsoring a debdiff if you have one
[10:34] <Riddell> dholbach: kubuntu bugs can go to kubuntu-bugs I guess
[10:34] <seb128> apw, hi
[10:34] <seb128> apw, you have alpha1 work items on
[10:34] <seb128> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm
[10:34] <seb128> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-easy-wayland-testing
[10:34] <seb128> are those still going to happen?
[10:35] <seb128> RAOF, ^
[10:35] <dholbach> thanks Riddell
[10:35] <dholbach> done
[10:35] <zyga> ev, mvo: hello, any chance for that apt bash tab completion issue?
[10:35] <ev> zyga: I've already uploaded a fix.
[10:35] <zyga> ev: lovely, thanks :-)
[10:36] <ev> do let me know if you're still having issues
[10:36] <ev> once it's built and installed, that is
[10:38] <RAOF> seb128: I'm unsure about apw's items there, but they still can be done by alpha-1; they don't require any archive uploads.  Perhaps apw's planning to do them during the freeze?
[10:39] <seb128> RAOF, ok, I was just checking in case you knew since those specs are assigned to you
[10:39] <seb128> RAOF, I will check with apw when he's around, thanks
[10:40]  * apw looks blearily at seb128 and RAOF 
[10:41] <apw> they are on my list to do, i think the ones you are referring to are small so there is definatly hope
[10:42] <seb128> apw, if they are still on target for alpha1 that's fine, I'm just checking what should be moved to alpha2 now
[10:42] <RAOF> It's: review the crazy intel GTT coherency patch (I think there's actually a newer version of that available), and a little wayland checking.
[10:42] <apw> RAOF, a newer version ?
[10:42] <seb128> apw, RAOF: thanks
[10:43] <apw> RAOF, got a reference to that one
[10:43] <RAOF> apw: I'll check on the bug.  There was recent activity there, and there have been at least 9 versions of the patch, so it's non obvious to track. :)
[10:44] <apw> RAOF, heh sounds like a nightmare as normal, best if i review and package up the right one tho.
[10:45] <RAOF> _Man_ that bug has a lot of duplicates.
[10:45] <RAOF> Sucks to have an i845 card, too.  That bug's similar, but without anyone really working on it.
[10:46] <stenten> Do you need a link to the latest upstream version of that patch?
[10:46] <RAOF> apw: http://bugs.freedesktop.org/attachment.cgi?id=35548 is the v9 patch against drm-intel-next as of 2010/05/10.
[10:47] <RAOF> It's missed the 2.6.35 merge window, and there appear to _still_ be reports of GTT incoherency even with that patch.
[10:47] <RAOF> Yay hardware!
[10:48] <apw> RAOF, and this is the fix meant to fix the 8xx intel h/w ... right ?
[10:48] <Sarvatt> backporting things to intel 2.7.1 as a forked driver, turning off KMS for 8xx and adding the fork to the xserver autoconfig logic so it's automatically loaded for !KMS because -intel is KMS only really seems like the way to go at this point
[10:48] <RAOF> apw: It's meant to fix i855. i845 has a similar problem, but no patch.  And then there are other i8xx cards…
[10:48] <Sarvatt> apw: *one* specific 8xx
[10:48] <hrw> intel 8xx... nightmare
[10:49] <apw> Sarvatt, i thought we already had 8xx KMS disabled now, and it was causing issues for some people who used to work ?
[10:50] <hrw> bb in few
[10:50] <Sarvatt> apw: they're still using the newer xserver-xorg-video-intel, those GPU's were never made to work the way the modern driver is assuming and it's just getting worse and worse
[10:51] <LucidFox> seb128> Debdiff uploaded
[10:51] <apw> Sarvatt, so you are saying leave the kernel as is (disable KMS for 8xx) and fix the Xserver to use an older -intel drop for those cards only
[10:51] <seb128> LucidFox, thanks
[10:52] <RAOF> apw: Yup.  That was the outcome at the Xorg-in-Maverick overview session.
[10:53] <apw> RAOF, so does it even make sense to look at this patch then?
[10:53] <RAOF> apw: It'd be nice to apply to Lucid.
[10:54]  * apw shudders ... i can hear martin and stefan screaming already
[10:54] <RAOF> Where we *don't* have an old intel driver.
[10:54] <Sarvatt> problem is the old driver could still be screwed up with the newer kernel, it's something that needs testing
[10:54] <RAOF> Sarvatt: Should be much less likely, though; it won't be using the gem interfaces, right?
[10:54] <RAOF> Or will be using a much more restricted subset.
[10:56] <Sarvatt> >ubuntu-x :)
[11:00] <ogra> could an archive admin let my x-loader-omap4 package into the archive (sitting in NEW)
[11:07] <LucidFox> http://live.gnome.org/GTK+/ClientSideDecorations <-- Woo, wayland is a goal
[11:27] <cjwatson> could somebody KDEish look into the uim FTBFS?  It ends up triggering a minor but irritating Soyuz bug during autosyncs for reasons too tedious to explain in full ...
[11:27] <Riddell> uim?
[11:29] <Riddell> mm, ok
[11:30] <geser> cjwatson: could you please sync the new source package "git"? the source package "git-core" (in Ubuntu main) got renamed to "git" (it's not urgent)
[11:31] <Riddell> geser: I'm on archive admin duty today, file a bug and I'll get to it
[11:31] <geser> Riddell: ok
[11:33] <dholbach> james_w: how can I move https://code.edge.launchpad.net/~arky/ubuntu/karmic/qemulator/fix-257233/+merge/11510 from "Needs review" to something else?
[11:34] <pitti> cjwatson, slangasek, ScottK, Riddell: I just updated queuediff to use the LP generated debdiffs instead of building it itself; much less to download now
[11:34] <pitti> (the old version also broke on 3.0 format with current edge)
[11:35] <cjwatson> cool
[11:37] <highvoltage> mdz: I thought that you might like this video about motivation: http://www.youtube.com/watch?v=u6XAPnuFjJc
[11:39] <pitti> jdong: I just updated queuediff to use the LP generated debdiffs instead of building it itself; much less to download now
[11:40] <LucidFox> So, is CSD/RGBA now enabled by default in Maverick? I see it was patched into GTK 11 days ago.
[11:40] <wgrant> pitti: Note that it's only on edge at the moment.
[11:40] <pitti> wgrant: yep, that's fine
[11:40] <seb128> LucidFox, the patch is there but the theme doesn't use it
[11:40] <LucidFox> ah
[11:40] <seb128> LucidFox, the patch is there but the theme doesn't use it
[11:40] <seb128> ups
[11:41] <LucidFox> But RGBA can be forced with gnome-color-chooser, like with the Lucid RGBA PPA?
[11:41] <wgrant> pitti: (also, good luck reviewing udev SRUs with that... we blacklist it since it causes debdiff to generate infinite output)
[11:41] <wgrant> But I guess that's probably a problem locally anyway.
[11:41] <seb128> dunno
[11:42] <pitti> wgrant: hm, the uploaded orig.tar.gz's shouldn't; we filter out the test /sys tree
[11:42] <wgrant> Maybe it's fixed now. This has been in place for a while.
[11:43] <ion> I should get around to reporting a bug against whatever GUI library Vuze uses. Some horrible Java hack that abuses Gtk in a similar way to Firefox and OpenOffice. Since the Gtk patch, Vuze crashes on startup.
[11:43] <mdz> highvoltage, thanks, I've read about this research but it's nice to have a concise summary like this
[11:44] <seb128> thanks to whoever does sru reviewing
[11:45] <pitti> seb128: de rien
[11:45] <seb128> pitti, oh, it's you? ;-)
[11:45]  * seb128 hugs pitti
[11:45] <pitti> I've got some room in between alpha-1 juggling
[11:45] <seb128> sorry it's sticking so much to you though
[11:45] <seb128> somebody should perhaps do a call for extra members to join the sru team now?
[11:47] <geser> Riddell: bug 588237; I'm not sure if it needs a sponsor ACK or not, therefore I decided for the safe side (sponsoring)
[11:48] <pitti> seb128: as soon as we'll get a new release manager, it should get better
[11:51] <james_w> dholbach: currently it is broken and you aren't able to do it, so I did it for you
[11:51]  * dholbach hugs jam
[11:51]  * dholbach hugs james_w
[11:51] <dholbach> :)
[11:53] <LucidFox> "Horrible Java hack"? SWT is a wrapper around GTK...
[11:53] <LucidFox> As opposed to Firefox and OpenOffice, which use their own toolkits for rendering and only query GTK for widget appearance
[11:54] <LucidFox> But I did run into problems with SWT and RGBA, to the point that I had to blacklist Eclipse.
[11:59] <Chipzz> isn't being written in Java enough to qualify as a horrible hack as such? :P
[11:59] <newubuntuusr> Hello, is therea developer online?
[12:00] <soren> No. It's quite a phenomenon, really. All of the worlds hundreds of thousands of software developers all just logged off the internet two minutes ago.
[12:01] <ogra> apart from soren indeed
[12:01] <soren> I'm not a developer. I just play one on IRC.
[12:01] <Chipzz> is soren a developer? :p
[12:02] <ogra> he is dressed like one
[12:02]  * soren chuckles
[12:02] <ogra> but that might just be part of the playing :)
[12:03] <Chipzz> with some ppl you just know up front that this is the wrong channel for them
[12:03] <Chipzz> "newubuntuusr" is kind of a dead giveaway
[12:04] <Chipzz> in such cases, I'm very inclined to urge ppl to pls read the topic before asking further questions
[12:18] <Sarvatt> LucidFox: try the darkroom theme
[12:18] <LucidFox> Sarvatt> I will, after I get home and install Maverick :)
[12:30] <soren> pitti: About the check SRU: I approved the nomination for Lucid myself (someone else nominated it). After doing it, I couldn't help but wonder if I should have left that to ubuntu-sru? The wiki doesn't say.
[12:30] <pitti> soren: approving tasks is fine, and appreciated
[12:30] <pitti> so I don't have to do the extra clickery :)
[12:31] <soren> pitti: Ok, good. So the SRU team's ACK is a nudge towards the archive admins to accept it?
[12:31] <pitti> soren: right
[12:31] <soren> pitti: Ok, lovely. That explains. Thanks.
[12:40] <mvo> doko: what should we do with the powerpc SPU extension in crash? you introduced it in ~2007 and I was wondering if its still important to keep or if we can simply sync the debian package
[12:42] <doko> mvo: well, lucid still runs on the ps3 ...
[12:44] <mvo> doko: ok, just wanted to check before porting it over
[12:44] <mvo> doko: thanks
[13:06] <G> kirkland: oh, did you see, upstream submitted an updated patch, going to test it tonight
[13:06] <G> kirkland: for the libvirt bug that is
[13:20] <ttx> mvo: bug 223741 is due to people trying to do LTS->LTS before the .1 release, right ? If you confirm, i'll close it as invalid
[13:24] <mvo> ttx: yeah, until .1 that needs either "-d" or "--proposed"
[13:24] <ttx> mvo: ok, will clean up
[13:24] <mvo> thanks ttx
[13:37] <kirkland> g: i didn't see that yet, but that's excellent news
[13:41] <ogra> Riddell, i'd appreciate if x-loader-omap4 and u-boot-omap4 couls get out of NEW some time today (no hurry though)
[13:43] <G> kirkland: tbh, I think the new patch will work just fine
[13:44] <G> kirkland: I've got a feeling it could also prevent the change issue that I couldn't reproduce
[13:45] <h0ar3> hi devels
[13:45] <h0ar3> https://code.launchpad.net/wubi
[13:45] <h0ar3> how can I checkout its source?
[13:46] <hrw> I would try "bzr clone lp:wubi"
[13:46] <h0ar3> what is bzr
[13:46] <h0ar3> I'm on windows
[13:46] <hrw> You can browse the source code for the development focus branch or get a copy of the branch using the command:
[13:46] <hrw> bzr branch lp:wubi
[13:46] <hrw> that is on page there
[13:46] <hrw> bzr is scm used by ubuntu
[13:46] <ogra> hrw, only if you pick a branch and click it :)
[13:47] <h0ar3> oh
[13:47] <hrw> ogra: I went to page which h0ar3 gave
[13:47] <h0ar3> works on windows?
[13:47] <hrw> h0ar3: yes
[13:47] <h0ar3> executable?
[13:47] <ogra> http://wiki.bazaar.canonical.com/BzrOnPureWindows
[13:47] <h0ar3> why do need this
[13:47] <hrw> h0ar3: ?
[13:48] <h0ar3> there is svn,git,mercurial
[13:49] <h0ar3> seems reinvented the whell
[13:49] <h0ar3> wheel*
[13:49] <hrw> there is also perforce and zillion others
[13:49] <hrw> but ubuntu uses bzr
[13:49] <hrw> accept it
[13:49]  * hrw wants bitkeeper
[13:50] <ogra> eeek
[13:50] <cjwatson> bzr predates git, for the recor
[13:50] <cjwatson> d
[13:51] <cjwatson> it predates mercurial too
[13:52] <JontheEchidna> pitti: I want to testbuild to see if dropping the avogadro build-dep was the only thing I forgot to push to bzr, then I'll upload a fix
[13:53] <pitti> JontheEchidna: nice, thanks!
[13:53] <pitti> JontheEchidna: btw, I rebuilt the current alternates, they seem fine now
[13:53] <pitti> JontheEchidna: dropping kdebase-plasma seems to have solved/worked aroudn both problems
[13:53] <hrw> cjwatson: what about monotone?
[13:53] <JontheEchidna> pitti: nice
[13:54] <cjwatson> monotone was a slightly earlier generation - I think it was one of the things Martin looked at when he did the initial bzr design
[13:55] <cjwatson> it was kind of more the tla generation I think
[13:56] <hrw> cjwatson: I remember that in 2005 when OpenEmbedded devs tested existing dscms we moved to monotone from bitkeeper. bzr was rejected at that time
[14:04] <G> kirkland: btw, not sure if you've seen 455832 but it might also be an option to include, not sure what policy you guys have to follow though
[14:07] <ogra> pitti, can you reset the trend line on http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html at some point (not urgent)
[14:07] <pitti> ogra: to which number?
[14:09] <ogra> pitti, 46 if i'm counting correctly
[14:09] <pitti> ogra: for alpha-1 as well?
[14:10] <ogra> pitti, hmm, i have to check that, i dont think we have actual A1 targets
[14:10] <ogra> its all A2
[14:10] <pitti> ogra: ok, a2 will auto-reset past a1, so that's fine then
[14:10] <ogra> great
[14:10] <pitti> ogra: committed; just missed this hour's cron, though
[14:11] <ogra> great, thanks
[14:29] <cjwatson> JontheEchidna: is bug 517962 already fixed in maverick, or does it need an upload?
[14:30] <JontheEchidna> cjwatson: ah, it's fixed in maverick now
[14:30] <JontheEchidna> cjwatson: closed
[14:30] <cjwatson> thanks
[14:30] <jdstrand> seb128: hi! so, evolution has under Edit/Preferences/Composer Preferences the following: 'Top Posting Option (Not Recommened)'. While I would certainly not enable the option personally, it seems rather non-Ubuntu-like to have the '(Not Recommended)'. Maybe I am missing something, but it seems like a developer asserting his/her preference on bottom-posting
[14:31] <jdstrand> seb128: rather than any 'real' issue with the functionality
[14:31] <seb128> jdstrand, hey, indeed
[14:31] <jdstrand> seb128: obviously not anything important, but thought it might be a string to consider stripping out
[14:32] <seb128> jdstrand, could you open a bug on launchpad? (and to GNOME if you want, we will do it otherwise)
[14:32] <jdstrand> seb128: sure
[14:32] <seb128> thanks
[14:39] <james_w> apachelogger: thanks to dholbach: https://wiki.ubuntu.com/DailyBuilds/GettingStarted
[14:39] <jdstrand> seb128: done and done
[14:39] <seb128> jdstrand, thanks and thanks ;-)
[14:40] <jdstrand> he and he
[14:40] <jdstrand> :)
[14:45] <ogra> Riddell, thanks a lot !!
[14:46] <geser> has someone an idea why building "steam" in maverick failed on i386 and powerpc (xslt.c:(.text+0x1bb4): undefined reference to `__stack_chk_fail_local') but succeeded on amd64 and armel? [https://edge.launchpad.net/ubuntu/+source/steam/2.2.31-6ubuntu1]
[14:47] <Riddell> ogra: just doing my archive admin duties :)
[14:48] <ogra> :)
[14:49] <smoser> Keybuk, are you around?
[14:49] <Keybuk> smoser: no, I'm asquare
[14:49] <smoser> indeed L7
[14:50] <smoser> you may or may not be aware that there are people interested in running ubuntu in lxc (containers).  The attempts to do so that i'm aware of look like: http://github.com/phbaer/lxc-tools/blob/master/lxc-ubuntu
[14:50] <Keybuk> I am aware
[14:50] <smoser> reportedly that works on lucid.  i'd like to get your impressions on how difficult it would be to get "proper" support in upstart
[14:51] <smoser> and what you think of something like the above.
[14:51] <Keybuk> that's a very long shell script that does a lot of changing of things
[14:51] <smoser> i'm willing to type email so you can process when you have time.
[14:51] <Keybuk> so technically speaking, that's not Ubuntu in the container
[14:51] <Keybuk> and can never be something we can support
[14:51] <smoser> yes, i agree. (its not *very* long), but yes.
[14:51] <smoser> so those were my first thoughts
[14:52] <smoser> also.
[14:52] <smoser> but, the script basically gives some what of a recipe to fix the things that don't "justwork" with ubuntu boot.
[14:52] <Keybuk> I would rather they fixed the things that make the ubuntu boot not work with lxc
[14:52] <Keybuk> as clearly that's an lxc issue
[14:53] <smoser> well, sort of.
[14:53] <smoser> some things are "lxc issues" . some things are not really possible to change.
[14:53] <smoser> its basically a bit of a more functional chroot.
[14:53] <Riddell> ogra: E: u-boot-omap4: upstream-version-not-numeric L24.6-p1git20100520-0ubuntu1
[14:54] <ogra> Riddell, yes, wanted
[14:54] <smoser> so /dev isn't going to be there, you don't have block devices with partitions and filesystems, its much more like nfs root in that sense.
[14:54] <ogra> Riddell, i'm using the TI upstream system
[14:54] <Riddell> ogra: ok, accepted binary
[14:54] <ogra> thanks
[14:55] <smoser> so some things probably can be "fixed" in lxc, but others are probably going to need some adjustments in ubuntu boot process.
[14:55]  * ogra digs for the FTBFS of x-loader-omap4
[14:55] <Keybuk> smoser: the best way for that to happen would be for someone who knows and uses lxc to get interested in ubuntu boot
[14:55] <Keybuk> and maybe sign copyright for upstart, etc.
[14:56] <smoser> Keybuk, thanks for your time. i'll stop pestering for now.
[14:56] <Keybuk> I don't mean to brush off, but there's only one of me, I have limited time and knowledge
[14:57] <kirkland> bug 455832
[14:57] <smoser> Keybuk, completely understand.
[14:57] <Keybuk> I'm really not, personally, interested in things like servers, cloud, containers, etc.
[14:57] <Keybuk> so I'm the wrong person to work on that kind of thing in Ubuntu/Upstart
[14:58] <smoser> unfortunately, at the moment, i dont think there is a better person.
[15:05] <smoser> Keybuk, one other question, i nfs root generally supported?
[15:05] <Keybuk> it's known broken
[15:18] <ogra> damned
[15:21] <ogra> is there any way to replace a broken symlink with a dir using patch ?
[15:33] <ScottK> pitti: Nice (re queuediff).
[15:45] <doko> asac, seb128: which library should I use, when libmozjs.so is needed?
[15:55] <ogra_> Riddell, x-loader-omap4 in binary NEW now (sorry for the delay it had FTBFS)
[16:02] <Daviey> kirkland: Off the top of your head.. do you know which bug WalrusRESTBinding.java refers to?
[16:02] <kirkland> Daviey: hmm, no
[16:03] <Daviey> kirkland: things like, -						putQueue = getWriteMessenger().getQueue(key, randomKey);
[16:03] <Daviey> +						putQueue = getWriteMessenger().interruptAllAndGetQueue(key, randomKey)
[16:05] <Daviey> kirkland: the diff i have, http://paste.ubuntu.com/442846/
[16:06]  * kirkland checks loggerhead
[16:06] <Daviey> kirkland: good luck with that :/
[16:08] <kirkland> Daviey: hmm, where is this from?
[16:08] <kirkland> Daviey: is this a patch we're carrying, or a diff?
[16:08] <Daviey> kirkland: it's a reverse diff created from the difference between our lucid magic, and the current 1.6.2 head.
[16:09] <kirkland> Daviey: http://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu/annotate/head:/clc/modules/wsstack/src/main/java/com/eucalyptus/ws/handlers/WalrusRESTBinding.java
[16:09] <kirkland> Daviey: starting there?
[16:10] <Daviey> kirkland: Yeah.. but i'm trying to work out if there is anything we need to carry from there, into the 1.6.2 head branch.
[16:11] <Daviey> ie, lucid -> 1.6.2 branch doesn't cleanly merge on that file.
[16:11] <Daviey> and the generated diff is that pastebin.
[16:12] <kirkland> Daviey: in your pastebin, which is the - and which is hte + ?
[16:12] <Daviey> - = lucid
[16:12] <Daviey> + = 1.6.2 branch
[16:15] <kirkland> Daviey: i think you can safely drop this
[16:15] <kirkland> Daviey: drop our diff, i mean
[16:15] <Daviey> kirkland: yup, thought so.
[16:16] <Daviey> thanks.
[16:16] <kirkland> Daviey: the new code looks to be a better code
[16:35] <apachelogger> james_w: now that was too obvious, thanks :)
[16:36] <james_w> apachelogger: not linked from /DailyBuilds though, so I'll let you off :-)
[16:36]  * james_w fixes
[16:36] <apachelogger> phew ^^
[16:36] <james_w> oh, it is, right at the top
[16:36]  * apachelogger hides
[16:45] <apachelogger> james_w: http://imagebin.ca/view/xt3ktt6.html yet the wiki says "Source Package Name: if the package exists in Ubuntu, make the right connection here."
[16:46] <james_w> apachelogger: I thought that box had been dropped. Did you enter the source package name that the recipe will create?
[16:47] <apachelogger> james_w: doesnt work since the package is not yet in ubuntu :/
[16:47] <james_w> apachelogger: so if you put it in there it says "This isn't an Ubuntu package"
[16:47] <apachelogger> james_w: "Invalid value" it says
[16:48] <apachelogger> If I search "No items matched "ubuntuone-kde"."
[16:48] <james_w> apachelogger: that sucks
[16:48] <james_w> apachelogger: please file a bug
[16:49] <apachelogger> james_w: against soyuz or what?
[16:49] <james_w> apachelogger: it may be that the option has already been removed in the code, and just not rolled out, but we should track it again
[16:49] <james_w> apachelogger: um, launchpad-code I think
[16:49] <apachelogger> oh-k :)
[16:49] <apachelogger> james_w: can I enter any random package name for that? I suppose it is only for linking the data?
[16:51] <apachelogger> james_w: bug 515581
[16:52] <james_w> thanks
[16:53] <james_w> apachelogger: I have no idea what it is used for
[16:54] <apachelogger> oh, one can also upload to a PPA and it will show up as source package name
[17:28] <asac> doko: try to get rid of it ... 2nd try to get rid of it ... 3rd. use xulrunner with xulrunner --gre-version hack to figure LD_LIBRARY_PATH at startup
[17:36] <doko> asac: 1 and 2 won't work, 3 is ugly. it's dehydra which I try packaging
[17:36] <doko> asac: what's wrong with libmozjs-dev in debian?
[17:37] <asac> doko: no ABI stability
[17:37] <asac> always send a mail upstream and say they should move asap to webkit javascript core
[17:37] <asac> doko: and then use the ugly way until they have resolved it or block it from the archive if that would help getting it done upstream sooner
[17:40] <asac> doko: alternatively, you could talk to chrisccoulson ... if we want mozjs we need to package it from independent source and then take care that noone who has insecure remote content exposure uses that
[17:43] <doko> asac: that would be good. usually gcc doesn't have these problems
[17:46] <asac> doko: why is gcc using mozjs?
[17:46] <asac> cant we get rid of that?
[17:47] <asac> actually i hoped that such a package could at least live in universe
[17:49] <doko> asac: https://developer.mozilla.org/en/Dehydra
[17:51] <micahg1> doko: will you be around a little later (2 hrs)?  I need to chat with you about openjdk in hardy
[18:32] <lfaraone> If I post to ubuntu-devel with my personal email address (which I used to subscribe, and is listed in LP) will the email be moderated? (I'm an ~ubuntu-dev member)
[18:35] <cjwatson> probably
[18:35] <cjwatson> oh, if it's listed in LP, it should go through
[18:41] <LaserJock> cjwatson: is there a non ~ubuntu-dev team that is whitelisted or is it just individuals?
[18:46] <cjwatson> LaserJock: I thought it was ~ubuntu-dev
[18:46] <cjwatson> LaserJock: but that stuff isn't under my direct control
[18:50] <LaserJock> cjwatson: I just meant if there was some LP team that controlled the whitelist for people not in ~ubuntu-dev
[18:50] <LaserJock> or if it was just in the mailman interface itself or something like that
[18:50] <smoser> is there a blueprint that would cover dropping of udev ? something that i could subscribe to so I could knwo when it change?
[18:53] <cjwatson> LaserJock: mailman
[18:56] <apachelogger> james_w: what do you make of that: https://code.edge.launchpad.net/~apachelogger/+recipe/main/+build/26
[18:57] <james_w> apachelogger: urgh, it's still broken
[18:57]  * apachelogger falls back to doing own packages :P
[19:14] <jcastro> robbiew: do you have a page that lists all the release schedules for N-P or do you just have them individually like PReleaseSchedule, etc.?
[19:15] <james_w> apachelogger: I think that should be fixed when updated buildd packages are copied to the production PPA, which should happen soon.
[19:15] <robbiew> jcastro: one sec
[19:16] <robbiew> jcastro: https://wiki.ubuntu.com/ReleaseSchedule/LTStoLTS
[19:16] <jcastro> thanks!
[19:30] <cody-somerville> Does anyone know where I can find the number of packages in the Debian archive?
[19:30] <pochu> source or binary packages?
[19:31] <pochu> (UDD has it I guess)
[19:32] <cody-somerville> pochu, source
[19:32] <pochu> cody-somerville: unstable?
[19:32] <cody-somerville> pochu, aye
[19:34] <pochu> emilio@saturno:~$ grep Package /var/lib/apt/lists/ftp.de.debian.org_debian_dists_unstable_main_source_Sources | sort -u | wc -l
[19:34] <pochu> 15028
[19:34] <pochu> I think that would be accurate
[19:34] <james_w> might want ^Package
[19:34] <ion> ...or grep-dctrl ;-)
[19:35] <seb128> pochu, the sort doesn't make any difference there :-)
[19:35] <james_w> seb128: it does, as it is -u
[19:35] <james_w> and dak may now include more than one stanza per-source
[19:35] <seb128> james_w, do we have things listed several times in the Sources?
[19:35] <seb128> oh ok
[19:35] <pochu> cody-somerville, james_w: right, it's 15007 with ^Package
[19:36] <pochu> seb128: it's like 900 less packages with sort -u ;)
[19:37] <seb128> pochu, ok, we don't have that difference on Ubuntu ;-)
[19:40] <cody-somerville> Launchpad say testing has 16275 packages.
[19:40] <cody-somerville> *says
[19:41] <james_w> including contrib and non-free perchance?
[20:00] <ccheney> cjwatson, when is udev going away this cycle?
[20:11] <cjwatson> ccheney: nobody promised it would be this cycle
[20:11] <ccheney> cjwatson, ok
[20:14] <smoser> cjwatson, so your expectation is that udev will live through maverick ?
[20:15] <dupondje> udev gets removed ?
[20:15] <cjwatson> smoser: Keybuk said that he was generally planning on making the daemon go away at some point.  As far as I know not much directly depends on it, it has no work item assigned for it, it's not a priority, etc.
[20:15] <smoser> i've got some work items that i figured would sit atop udev, and had assumed (incorrectly) that udev was going away per Keybuk's talk at UDS.
[20:15] <ttx> cjwatson: we have work on ebsmount that would suffer from a potential transition
[20:15] <cjwatson> smoser: in any case, the configuration would remain
[20:15] <cjwatson> smoser: it shouldn't affect you
[20:15] <smoser> ok. that was the big thing.
[20:16] <smoser> we're square then. thank you for clearing this up.
[20:16] <cjwatson> this is a potential plumbing rearrangement, not (as far as I know) a major interface change
[20:16] <dupondje> https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/584287 => can the importance gets a bit bumped ? this is like the crappiest bug in maverick atm :)
[20:17] <cjwatson> smoser: do make sure, as ever, that you aren't using any constructs deprecated by the udev documentation
[20:17] <smoser> ok. thanks.
[20:17] <cjwatson> in particular you're now only supposed to add symlinks to the kernel's canonical device name, not rename the device
[20:22] <micahg> doko: ping
[20:26] <smoser> cjwatson, i'm more interested in the events and getting programs called based on add/remove
[20:28] <smoser> kees, are you around ? i'm looking at https://code.launchpad.net/~kees/vmbuilder/use-ext4
[20:30] <cjwatson> smoser: eventually, the latter will become upstart jobs; any transition to that will be clearly announced and will be some time before the removal of the daemon
[20:31] <cjwatson> smoser: for the meantime, just don't worry about it
[20:31] <smoser> sorry for the misunderstanding
[20:31] <smoser> i will aptly not worry
[20:33] <kees> smoser: the ext4 thing should already be in lucid
[20:33] <smoser> yes. but that doesn't concern me.
[20:33] <smoser> the uec images are built form 0.11 (which is where this is valid)
[20:33] <kees> ah-ha
[20:34] <smoser> i have your patch, but looking at it i dont know why i do not get ext4 filesystems on my karmic and lucid and maverick images
[20:34] <smoser> the only thing i can come up with is that they specify a partfile
[20:34] <kees> how is vmbuilder invoked for you?
[20:35] <smoser> (ie, --part)
[20:35] <smoser> http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/annotate/head:/build-ec2-image
[20:35] <smoser> (note, partfile does not include filesystem type -- that would have seemed to be the best way to do that)
[20:36] <kees> hm, i've only tried it with --dest
[20:37] <smoser> http://paste.ubuntu.com/442941/
[20:38] <kees> smoser: when i originally debugged this feature, i had to add prints all over the place
[20:38] <smoser> which is what i was trying to avoid by asking you.
[20:39] <kees> smoser: yeah, i don't know it much better than that :)
[20:39] <smoser> i think that set_filesystem_types must be getting overridden by my partfile
[20:39] <smoser> (which again, doesn't specify it).
[20:39] <smoser> thanks for your time.
[20:40] <kees> smoser: np, let me know if you don't figure it out. i can take a lot tomorrow
[20:45] <soren> smoser: I'm expecting to fix up EC2 builds with vmbuilder 0.12, if that matters.
[20:45] <smoser> soren, right now its not an effort that i would want to take on.
[20:45] <smoser> to move the official builds over to 0.12
[20:46] <smoser> even if i did i'd still want to leave the released versions working from the 0.11
[20:46] <smoser> just to make sure they dont just change (or otherwise verify that they're identical)
[20:46] <smoser> do you happen, soren, to know what would be causing me to not get ext4 filesystems ?
[20:47] <smoser> my interest is in turning those on for maverick but not for less than that.
[20:47] <smoser> https://code.launchpad.net/~ubuntu-virt/vmbuilder/0.11 is the branch i build from
[20:47]  * soren looks
[20:48] <smoser> invoked as http://paste.ubuntu.com/442941/ with part file looking like "root ${size} a1"
[20:48] <soren> smoser: Yes.
[20:49] <soren> smoser: Using a part file always makes the filesystem ext3.
[20:49] <smoser> thats what i thoguht. suggestions on how to fix/work around ?
[20:50] <smoser> my feeling is that the partfile should allow specification of the filesystem
[20:51] <soren> The whole partfile thing is horrible.
[20:52] <soren> smoser: ...but that particular bug is fixed in 0.12.
[20:53] <smoser> oh ? i dont see how.
[20:54] <soren> smoser: Do you see the bug to begin with?
[20:55] <soren> smoser: Then look at the same place in 0.12 and behold.
[20:55] <smoser> i'm confused
[20:55] <soren> I can tell. :)
[20:55] <smoser> ah. i see it.
[20:56] <smoser> nah. never mind. default_filesystem.
[20:56] <smoser> i guess i can cherry pick that back
[20:57] <soren> Hardly.
[20:57] <soren> Unless.
[20:57] <soren> Well, you can try. :)
[20:58] <smoser> well, not cherry pick, but take that logic
[21:48] <seb128> ogra, asac: do you need a stable archive now for armel alpha1 builds?
[21:58] <asac> seeker: we probably dont want to skip an alpha
[21:58] <asac> so would be nice to have some time to settle
[21:58] <seb128> asac, was that for me?
[21:59] <seb128> asac, sorry got to restart my irc
[22:00] <asac> seb128: ;)
[22:00] <asac> yes
[22:00] <asac> for you
[22:00] <seb128> asac, ok, I will delay the gtk update
[22:01] <seb128> asac, let me know when I can update it ;-)
[22:01] <asac> seb128: i am not responsible for mobile images anymore ;) ... ogra has to give thumbs up or not. maybe the images are busted anyway atm.
[22:01] <asac> then it wouldnt matter much :)
[22:01] <seb128> right, that's why I asked ;-)
[22:02] <seb128> I'm not even sure alpha1 is in working state anywhere right now
[22:12] <blueyed> Is AlwaysLoginCurrentSession=false not supported/ignored by gdm? Cannot find the string in gdm sources anymore. Would like to login to wmii besides awesome.. - so no gnome-protecting-itself required (which changed the default to true).
[22:13] <blueyed> or is just UPDATE_CONFIG not support anymore, via gdmflexiserver --command="UPDATE_CONFIG AlwaysLoginCurrentSession=false" ?
[23:21] <bluefoxicy> okay seriously
[23:22] <bluefoxicy> why the assballs do I need debugging symbols
[23:22] <bluefoxicy> whatever program is using these things to pull debugging information for bug reports is terminally broken
[23:22] <cjwatson> bluefoxicy: if you can't be polite, please go somewhere else
[23:22] <cjwatson> it's not clever
[23:23] <bluefoxicy> cjwatson:  neither is my ISP, which sputters to death when I try to download a 2 meg file for debugging symbols for a 17k binary package(?!)
[23:23] <cjwatson> that doesn't justify turning up here with foul-mouthed outbursts.  control yourself, please.
[23:26] <bluefoxicy> It should be possible to just yank the mappings and the stack, and run with that; put that with the package version, and then run that through some program along with the debugging symbols later, come to the same results
[23:26] <bluefoxicy> Or if that's not possible, take a (larger) core dump on demand, and download the debugging symbols then
[23:26] <cjwatson> that is how apport normally behaves; users do not normally need to download debugging symbols.
[23:27] <cjwatson> I don't know what's wrong in your case.
[23:27] <bluefoxicy> cjwatson:  I had thought as much when it first came out; however at the moment my system seems to insist on downloading debugging symbols, which makes me believe something is broken ~_~
[23:27] <cjwatson> the point of the retracer arrangement is so that users only need to upload reduced traces, and a central system retraces the stacks with the debugging symbols installed.
[23:28] <cjwatson> yes, apparently something is.  I suggest you file a civil-toned bug on apport
[23:28] <bluefoxicy> as soon as I figure out how/why it's broken