[00:55] <dobey> hey guys, anyone around?
[00:56] <lifeless> fsvo
[00:56] <dobey> i saw my ubuntuone-client upload got accepted, but i have a couple of merge proposals for libubuntuone and ubuntuone-control-panel that i'm concerned about getting in for tomorrow
[00:57] <lifeless> you could talk to the pilot
[00:57] <lifeless> or main sponsors I guess
[00:57] <dobey> topic says "Patch pilots: " :)
[00:58] <lifeless> right
[00:58] <lifeless> schedule is on the wiki
[01:03] <dobey> nobody on the oz side of the planet for monday it seems. and probably not a good time for cnd or seb right now :-/
[01:04] <RAOF> They might be a little bit asleep  :)
[01:06] <Jerub> what's that ubuntu bug reporitng thing called again?
[01:06] <Jerub> actually, nevermind.
[01:08] <dobey> well i doubt cnd is asleep this early, unless he's travelling somewhere :)
[01:09] <ajmitch> when do they need to be uploaded by?
[01:10] <dobey> Mon 00:00 UTC afaik
[01:10] <dobey> so i guess 10 minutes ago? :)
[01:10] <ajmitch> heh
[01:13] <dobey> but i proposed them on friday :-/
[01:15]  * ajmitch can't upload right now, otherwise would sponsor them
[01:20] <dobey> guess i should probably apply for motu soon
[01:20] <dobey> and more specific package rights for main
[01:20] <ajmitch> wouldn't make a difference for this stuff in main
[01:20] <ajmitch> yeah, more per-package rights would help here
[01:22] <dobey> would help with the ever-expanding suite of ubuntuone projects though, and initially getting them into ubuntu
[01:31] <Jerub> facinating, removing python-apport removes ubuntuone
[01:41] <JanC> ubuntuone-client depends on python-apport
[01:42] <JanC> I suppose that shouldn't be a hard dependency...
[01:43] <dobey> why would you remove python-apport anyway?
[01:44] <JanC> dobey: there might be no good reason to remove it, but I so no good reason for the dependency either?  ;)
[01:44] <JanC> *but I see*
[01:45] <dobey> JanC: well it installs an apport reporting module for ubuntuone which requires python-apport
[01:45] <dobey> i suppose it could recommends instead
[01:47] <JanC> yeah, a recommends would be reasonable, but a hard dependency seems a bit strong
[01:50] <dobey> eh, we like to get useful information in our bug reports :)
[01:51] <JanC> dobey: most people won't remove it anyway
[01:52] <dobey> right
[01:56] <cnd> dobey, it's still sunday here, but even so I don't really have the powers you seek :)
[01:56] <cnd> I only have upload rights for a very small set of packages
[01:57] <dobey> cnd: guess will have to wait for seb or someone to wake up :-/
[01:57] <dobey> cnd: thanks anyway
[01:57] <cnd> sorry!
[02:00] <JanC> dobey: so Ubuntu isn't global enough yet?  ☺
[02:01] <dobey> JanC: hrmm?
[02:01] <JanC> the developers I mean  ;)
[02:01] <dobey> sure, but i don't know who to ping in oz right now to upload my stuff :)
[02:01] <JanC> like, 24/7 uploaders available
[02:02] <JanC> hehe
[02:02] <stgraber> dobey: what do you need uploaded ?
[02:03] <dobey> stgraber: i have 2 merge proposals pending. one to lp:ubuntu/libubuntuone and one to lp:ubuntu/ubuntuone-control-panel
[02:04] <stgraber> ok, looking at it now. I'm really not familiar with these two packages, so I'm hoping it's not too big changes :)
[02:05] <dobey> no, just a couple of bug fixes
[02:05] <dobey> thanks
[02:12] <stgraber> dobey: ok, they are both uploaded. You'll just need to wait for an archive admin to review them and let them through.
[02:12] <stgraber> dobey: just wondering, was there a need to re-generate the configure in libubuntuone ?
[02:13] <dobey> stgraber: new tarball release does that
[02:13] <dobey> stgraber: thanks for the uploads
[03:51] <RAOF> kees: Rumour has it that you've got the full source of the archive unpacked somewhere to grep through.  Would it be possible to grep for the string “GEM” and “20100330”?  I'm interested in how many programs are checking the GL_RENDERER string for these values.
[04:20] <kees> RAOF: it's just a full source archive but it unpacks quick enough. if you can produce a regex for me to search for, I can run it. takes a few hours
[04:22] <RAOF> Ta.  I'll see if I can generate a suitably specific regex.
[05:19] <RAOF> kees: "([[:space:]]|\'|\")GEM([[:space:]]|\'\")" is the best I've been able to come up with.  Hopefully that won't generate *too* many false-positives.
[07:34] <pitti> Good morning
[07:41] <pitti> ScottK: p-d-e> seems someone already NMUed it, so seems alright; I'm really happy to see 2.7 in sid, I can finally upgrade calibre then :)
[07:51] <dholbach> good morning
[07:55] <didrocks> good morning
[08:42] <steveire> dholbach: Is there an ubuntu release party in Berlin?
[08:59] <dholbach> steveire, yes: http://ubuntu-berlin.de/natty-release-party
[09:00] <steveire> Ah, on Wednesday.
[09:03] <steveire> oh wait, that's next month :)
[09:07] <bambee> It's normal that I am able to bypass polkit auth with the language selector dbus backend ? (I just cancel the password request from the agent)
[09:07] <bambee> hello btw
[09:10] <bambee> typically just try this program http://paste.ubuntu.com/595420/ , with "de_DE.UTF-8" as argument (for example) and don't enter the password (click cancel).  Then log you from tty1 and try "locale".
[09:12] <bambee> (I am on natty)
[09:21] <JanC> bambee: I can confirm that your test case works
[09:27] <bambee> JanC: from the user point of view, he can reproduce this test case via language-selector-kde (which no longer runs as root and uses polkit only)
[09:36] <JanC> bambee: same for the GNOME equivalent
[09:40] <bambee> pitti: ping
[09:40] <pitti> hi bambee
[09:40] <bambee> hi
[09:40] <bambee> see my test case above
[09:41] <debfx> bambee: I think the backend just doesn't check the result of the authorization
[09:41] <bambee> then look at http://bazaar.launchpad.net/~ubuntu-core-dev/language-selector/ubuntu/view/head:/dbus_backend/ls-dbus-backend#L94
[09:41] <bambee> debfx: it does not
[09:41] <bambee> you're right
[09:41] <pitti> *headdesk* good catch
[09:42] <bambee> the fix is easy , just check the value returned by self._authWithPolicyKit() :)
[09:43] <pitti> I'll better check all instances of PK there
[09:43] <bambee> or raise an exception... see an example at lp:bambi there is a userconfig repository.
[09:45] <bambee> http://bazaar.launchpad.net/~bambi/guidance/userconfig-kde4-dbus-helper/view/head:/dbus_backend/userconfig_helper#L95
[09:45] <bambee> ;)
[09:45] <bambee> (still in development, but polkit auth works fine)
[09:47] <pitti> bambee: thanks; I actually know how this should work, I've done quite a bit with PK myself
[09:48] <pitti> (I didn't write the lang-sel code)
[09:48] <pitti> thanks for spotting this!
[09:48] <bambee> yw :)
[09:58] <pitti> bambee: would you mind filing a bug about it? I suppose we'll need to fix it in stable releases, too
[10:01] <bambee> pitti: I will open a bug for that and also attach a patch (we could do nothing if the authentification fails..)
[10:02] <bambee> what do you prefer ?
[10:02] <pitti> bambee: doing nothing at all is fine; avoids introducing a new dialog, and PK itself should already display "wrong password", etc.
[10:02] <bambee> I agree, ok
[10:16] <lifeless> pitti: ping
[10:16] <pitti> hey lifeless
[10:16] <lifeless> pitti: whats the right forum to discuss changing the way apport managings dupes and private bugs?
[10:17] <pitti> lifeless: as it concerns everyone, I'd say ubuntu-devel@ ?
[10:17] <lifeless> sure
[10:17] <lifeless> pitti: but lets do a quick chat here if you have time
[10:18] <lifeless> can take it to ubuntu-devel if you think it needs that afterwards
[10:18] <lifeless> basically we get a query quite often - perhaps once every 2 days - where apport detects a dupe
[10:18] <pitti> ok
[10:18] <lifeless> strips the backtrace etc and marks it a dupe
[10:18] <lifeless> but the master isn't audited yet, so is still private
[10:19] <pitti> right, I hear some complaints about that, too
[10:19] <pitti> the alternative is to leave the dupes private, too
[10:19] <pitti> that makes it harder to see which bugs already have been reported, though
[10:19] <lifeless> pitti: how would that fix it ?
[10:19] <pitti> i. e. will lead to filing more duplicates
[10:20] <pitti> lifeless: fewer people getting confused when looking at the public bug
[10:20] <lifeless> pitti: the people getting confused are the ones filing the bug
[10:20] <lifeless> pitti: so they will still be confused as they wouldn't be able to see the master.
[10:20] <pitti> reporter yes
[10:20] <lifeless> pitti: if the master is private, users cannot read it and thus will still file duplicates.
[10:20] <pitti> but I don't see a way around that
[10:20] <pitti> we can't just make all of them public
[10:21] <lifeless> pitti: could we:
[10:21] <lifeless>  - file a public master bug with only the metadata needed to detect that its a dupe.
[10:21] <lifeless>  - leave the raw data dupes private
[10:21] <lifeless>  - and optionally not strip them at all.
[10:21] <lifeless> LP will know how many dupes there actually are for calculating heat.
[10:23] <lifeless> and bugcontrol + devs can read the raw data at their leisure (we could include a 'original filed bug with private attachments is bug 12345' comment which can explain that only Ubuntu developers can read that.
[10:23] <pitti> more convenient for reporters, less convenient for developers
[10:23] <lifeless> pitti: I contend that dealing with confused reports subtracts from the convenience developers have
[10:23] <pitti> and it would mean that the retracer had to open the new master bug itself, so all bugs will appear to have been filed by apport, not by real people
[10:24] <pitti> which might be ok, just pointing out that it looks odd
[10:24] <lifeless> pitti: apport could open a new one and shuffle the attachments around, if that angle is important.
[10:25] <lifeless> pitti: (expanding) - open new bug to be private; move attachments to that bug; purge the original bug; make the original public.
[10:25] <lifeless> once we have bug relationships this can be easier still
[10:25] <pitti> should be possible in principle, yes
[10:25] <pitti> a lot of data downloading/uploading, so I hope that'll be robust enough
[10:26] <lifeless> its in the DC
[10:26] <lifeless> right ?
[10:26] <pitti> yes
[10:26] <pitti> but that doesn't help much
[10:26] <lifeless> should be fine; if its slow we can add an API to move attachments between bugs
[10:26] <pitti> it's slow and not transactional either way
[10:26] <pitti> I've seen it break way too many times to have a solid confidence in it, so error handling will be hairy :)
[10:27] <lifeless> pitti: thats true; OTOH the new bug is private, so you can start it with just apport viewing it, copy up the attachments one at a time, and only when its ready expose it.
[10:27] <pitti> but if attaching the data to the new private bug fails, we can just fall back to what we have now and leave the master private
[10:27] <lifeless> certainly
[10:28] <lifeless> we can also look at doing direct to librarian uploads.
[10:28] <lifeless> which we should do anyway for LP
[10:28] <lifeless> pitti: ok, should I take this to u-d@?
[10:28] <pitti> lifeless: if we'll need LP changes anyway, would it be hard to do private attachments?
[10:29] <pitti> harder than moving them or re-linking attachments to a new bug?
[10:29] <lifeless> pitti: we don't necessarily need LP changes; doing privacy per-attachment would be a data model change at minimum, not to mention needing a whole new way to describe visibility.
[10:30] <pitti> ok
[10:30] <lifeless> so yes, private attachments on public bugs is interesting but tricky to do well - and then there is the likelyhood of someone copying from a private attachment to the bug to make a point, and disclosure fail.
[10:31] <lifeless> s/tricky to do well/tricky to do -acceptably-/
[10:32] <pitti> well, subscribed folks can just as easily make the entire bug public
[10:32] <pitti> but if it's hard to implement, then let's use what we hahve
[10:32] <lifeless> it is, yes.
[10:35] <lifeless> pitti: rightiho - so, does this need to go to ubuntu-devel ?
[10:35] <lifeless> pitti: I'll summarise and send there now if it does.
[10:35] <pitti> lifeless: I guess at this point a bug report works as well
[10:35] <pitti> but there might be some more input on the changed workflow then
[10:36] <lifeless> pitti: whats the bugtracker for the backend?
[10:36] <lifeless> just the package, or ?
[10:36] <pitti> right
[10:46] <hrw> helo
[10:47] <hrw> I have a question. on friday there were builds of gcc-4.4-armel-cross done and then upload was rejected by archive admin. should I get FFe for it?
[10:48] <hrw> https://launchpad.net/ubuntu/+source/gcc-4.4-armel-cross
[10:49] <lifeless> pitti: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/764414
[10:50] <lifeless> pitti: I'll drop a note to u-d about this
[10:50] <pitti> thanks
[10:53] <lifeless> done
[11:44] <ogra_> TheMuso, still awake ?
[11:45] <ogra_> TheMuso, seems you miss one of the panda patches in your ppa build (i noted which one in the bug)
[12:37] <smoser> cjwatson, what do you think about bug 759545 ?
[14:27] <stgraber> mvo: ping
[14:27] <tseliot> hi pitti, what do you think about bug #763331 , especially comment 2 ?
[14:29] <stgraber> mvo: I was wondering if you have any comment on bug 760035 and if you are going to include that in the next python-apt upload + push it to debian ?
[14:35] <mvo> hey stgraber
[14:35] <mvo> stgraber: I have a look in a wee bit
[14:36] <speakman> I'm creating a .deb package, but how do I specify some example files to go into /usr/share/doc/mypackage/examples/ ?
[14:37] <speakman> It's an autotools package, but the example files are just within the tarball and not installed during "make install"
[14:39] <directhex> speakman, you can refer to them in your debian/install file
[14:39] <directhex> speakman, i.e. you can say "foo/bar/baz /usr/share/doc/mypackage/examples/"
[14:40] <speakman> hm?
[14:41] <tkamppeter> pitti, hi
[14:41] <geser> directhex: wouldn't add them to debian/examples be better?
[14:42] <directhex> geser, or that, sure
[14:43] <speakman> geser: are there any example of an debian/examples file? /me is totally newb
[14:44] <speakman> debian/examples was awesome! thanks!
[14:45] <speakman> When making a new "version" of the package - do I always have to edit the changelog?
[14:46] <speakman> Adding a new entry in it, I mean
[14:46] <speakman> Or can I just change the version specified in the latest (and currently only) entry?
[14:46] <speakman> It's for testing purpose currently.
[14:49] <speakman> are there any more similar files like "examples" which takes a list of files and make sure they're installed?
[14:59] <speakman> There are so many great benefits with .deb packageing, but it's terribly difficult for a newbie to learch packaging from scratch :(
[15:04] <geser> speakman: "man debhelper" contains a list of all those dh_* commands and a short summary of what they do. Some of them use files in debian/.
[15:07] <speakman> geser: thanks! will look at it!
[15:13] <directhex> speakman, you only need to worry about package versions when they are uploaded to an archive - for local testing the changelog's version doesn't matter
[15:13] <directhex> if you upload to a ppa, then the only thing that matters is a newer changelog version than the last upload
[15:13] <directhex> for a real distro, the history matters. "dch -i" inserts a new log entry
[15:16] <jjardon> Hi, currently lp:glib points to ~jjardon/glib/trunk instead ~vcs-imports/glib/trunk , how Can I fix this?
[15:27] <mr_pouit> mvo: thanks for xubuntu-meta ;-)
[15:29] <mvo> mr_pouit: your welcome, sorry for the delay in looking properly at it
[15:33] <ohsix> how can i get apport to re-send a crash report i dismissed earlier, it's insisting on full reports now for things and they're quite large; but i can submit them later when i'm not at home
[15:41] <Mirv> ffe/bug #714861 is stuck in universe new queue, could someone let it through?
[15:57] <tkamppeter> pitti, around?
[16:01] <Kurisutian> cjwatson: I checked the ubuntu server install today and it still messes up with the btrfs installation. So the problem from the previous installation still remains....
[16:09] <barry> mvo: hi do you have some time to chat about bug 458872?
[16:09] <brendand> does anyone know if a usb-vga adapter or similar is going to show as having the USB 'Video' base class (0Eh)
[16:09] <brendand> ?
[16:09] <brendand> from what i've read it looks like only input devices are given this class, but could be wrong info
[16:09] <seb128> jamespage, hi, you sent the milestone of bug #764391 to 11.10, is that wanted or an error? (i.e you want it for next cycle not this one)
[16:10] <jamespage> seb123: no that's not what I mean't - should be 11.04 - doh!
[16:11] <jamespage> seb128: thanks for pointing that out :-)
[16:11] <seb128> jamespage, thanks ;-)
[16:12] <seb128> kirkland, seems like you maintain cobbler, do you want to upload jamespage's fix on https://code.launchpad.net/~james-page/ubuntu/natty/cobbler/fix-764391/+merge/58112 or should I review it?
[16:12] <seb128> (you know the software better so you are probably best placed)
[16:13] <jamespage> seb128, kirkland: I think Daviey might already be on it - but I might be wrong
[16:14] <cr3> tseliot: hi there, regarding brendand's question above, I noticed you participated on this thread: http://ubuntuforums.org/showthread.php?t=260863. might you happen to know how to distinguish usb video and usb capture devices from udev and/or sysfs?
[16:14] <seb128> Daviey, hey, ^
[16:15] <seb128> jamespage, thanks for the notice, I'm just doing sponsoring and I'm not in an hurry so I will wait for them to reply
[16:15] <Daviey> seb128 / kirkland, it is in the queue already
[16:15] <seb128> Daviey, right, which is why I'm asking, I'm piloting, I can upload but I would appreciate a review from someone who has a clue about the software
[16:16] <seb128> I don't fell qualified to decide if the template change is right for example
[16:20] <tseliot> cr3: no, sorry, I wouldn't know. If you have a look at the udev rules in /lib/udev/rules.d/ maybe you'll find something useful though
[16:21] <seb128> Daviey, doh, you meant natty unapproved queue, not sponsoring queue
[16:21] <Daviey> seb128, Oh yeah... I've not long reviewed and uploaded it..  Thanks for looking out for it.
[16:21] <Daviey> seb128, Yes.. sorry - i should have been more verbose.
[16:21] <seb128> Daviey, would be nice to unsubscribe the sponsors or mark the bug fix commited when you upload to avoid someone else to duplicate work ;-)
[16:21] <seb128> Daviey, thanks
[16:21] <Daviey> seb128, i did mark it Fix Committed :P
[16:21] <seb128> which you did...
[16:21] <seb128> right
[16:21] <seb128> one less on the list ;-)
[16:22] <seb128> Daviey, kirkland, jamespage: thanks
[16:22] <RoAkSoAx> jamespage: correct me if I'm wrong, but .pc files and stuff should not appear in the branch. right?
[16:22] <RoAkSoAx> s/branch/diff
[16:22] <Daviey> RoAkSoAx, No, they should IMO... Whilst it makes it harder to review... That is what dpkg-source -x generates for deb src 3 files
[16:23] <Daviey> If you merge that into the real branch, then it'll be uncommited by james_w's bot.. and a new merge proposal raised.
[16:23] <Daviey> fugly yes, requires yes, ideal no.
[16:23] <RoAkSoAx> Daviey: right, but for example, because something was wrong and there were changes in .pc that weren't reflected in patches, then everytime a new patch was created automatically by quilt
[16:23] <RoAkSoAx> and that's just wrong
[16:24] <RoAkSoAx> Daviey: so the fix was to simply remove the "old" .pc
[16:24] <RoAkSoAx> and let quilt create new one
[16:24] <Daviey> RoAkSoAx, In that case, you'd need to commit in patch unapplied status
[16:26] <RoAkSoAx> Daviey: right, but that's what I'm saying. Isn't it the best approach to commit with a patch in unapplied status, and when debuild'ing, the .pc will be automatically updated by quilt avoiding situations as the one explained above?
[16:28] <Daviey> RoAkSoAx, Hmm.. i agree you can't really merge .pc files.. but overwrite.  So i do agree..  If you want to propose a workflow to ubuntu-devel, i'm sure people will have thoughts and comments on it.
[16:29] <Daviey> I do tend to suggest merge proposals in patch applied, with .pc files currently.. Happy to revist that if there is a consensus on work flow.
[16:30] <RoAkSoAx> Daviey: yeah, I preffer not have them in applied status, cause I've seen many cases on which .pc changes sometimes appear in debdiffs or simply, quilt creates new patches for changes that are in .pc that shouldn't be there... so the fix is really to cleanup .pc
[16:31] <Daviey> RoAkSoAx, Please write a proposal :)
[16:32] <Daviey> seb128, So, i didn't mark it as merged because i didn't think it was a clean thing to do - incase the release team nack the upload.
[16:32]  * Daviey afk's
[16:32] <RoAkSoAx> Daviey: won't exactly write it as a proposal but rather I'll raise a discussion over it :)
[16:33] <cnd> @pilot in
[16:51] <mvo> barry: sorry, was in a call, let me look at the bug
[16:55] <kees> RAOF: started the search. I'll email you the details when it's done. :)
[17:04] <robbiew> ev: ping
[17:04] <ev> robbiew: pong
[17:04] <robbiew> hey..any chance of getting some wordsmithing in the Installer for bug 420080
[17:05] <ev> it's a bit late for that, no?
[17:05] <ev> oh, Oneiric
[17:05] <robbiew> ev: yeah
[17:06] <robbiew> Oneiric
[17:06] <ev> yeah, I don't see that being a problem for O
[17:06] <robbiew> ev: agree...too late for Natty
[17:06] <ev> for a second there I thought you were going to have work for me to do :-P
[17:07] <robbiew> ev: heh
[17:07] <robbiew> ev: thnx
[17:07] <ev> any time
[17:15] <robbiew> ev: got another for ya
[17:15] <robbiew> bug 764750
[17:15] <ev> boo
[17:15] <robbiew> fixable now...or punt to Oneiric
[17:16] <ev> yeah, I've been trying to sort that.  I put what I thought was a stopgap measure in place, but that doesn't seemed to have solved it
[17:16] <ev> there's another bug where Iv'e been tracking this
[17:16] <ev> but yes, I think it's o at this point
[17:16] <ev> I can't reproduce it locally
[17:16] <ev> and it seems to be intermittent
[17:17] <robbiew> ack
[17:17] <ev> either way, it's not that common
[17:17] <robbiew> thx
[17:17] <ev> most people go through the installer only session, I think
[17:17] <ev> so they wont ever hit this
[17:17] <ev> and presumably most people click "reboot now" in the installer anyway
[17:17] <robbiew> agree
[17:17] <infinity> That's an... Odd bug.
[17:17] <robbiew> just checking to see if it was a "easy" fix
[17:17] <robbiew> if there is such a thing
[17:17] <robbiew> hehe
[17:18] <infinity> I disagree on the "most people boot installer only" though. I know plenty of people that use the LiveCD as a LiveCD.
[17:18] <ev> but then they're likely not installing
[17:18] <infinity> Sure...
[17:18] <ev> ubiquity is what's removing these items
[17:18] <ev> for the duration of the actual install
[17:18] <ev> s
[17:18] <infinity> At which point, a midding "reboot" menu option is confugin.
[17:18] <infinity> confusing, too.
[17:18] <infinity> Oh, it's dying during the install?  Okay, that's weird.
[17:19] <ev> well, ubiquity sets it for the file copy phase
[17:19] <infinity> The bug implies that the menu item is missing after boot.
[17:19] <ev> so people don't reboot their computer in the middle of that
[17:19] <ev> oh
[17:19]  * ev re-reads
[17:19] <ev> maybe this is different
[17:19] <infinity> Burn -> Boot -> No menu item.
[17:19] <ev> in the live session
[17:19] <ev> not the installed system
[17:20] <infinity> Yeah.
[17:20] <infinity> No reboot item on a live system isn't world-ending, since the odds of data loss on hitting the reset button are next to zero, but it sure is confusing.
[17:21] <ev> sure, I'd really like to nail this
[17:21] <ev> but I don't see that happening in natty
[17:21] <infinity> Yeah, fair enough.
[17:21] <robbiew> +1
[17:21] <infinity> And, to be fair, the sorts of users that intentionally use LiveCDs as LiveCDs are also the sorts of users who know how to reset a computer.
[17:22] <infinity> (Unlike say, my parents, who literally would have NO idea how to reset/reboot their machine without a GUI button to do so, short of pulling the power)
[17:22] <robbiew> heh...good point
[17:23] <infinity> ev: It's possible the bug reporter's intermittent issue was that he fired up Ubiquity and then cancelled the install?
[17:24] <infinity> ev: That would be hard to reproduce if you forgot that's how you got there in the first place. :P
[17:24] <ev> infinity: it's an atexit call
[17:24] <ev> so even that would catch it
[17:24] <ev> haha
[17:24] <infinity> Unless Python cores when you cancel.
[17:24] <infinity> Just saying. :)
[17:25] <infinity> (Or any number of other reasons an exit hook can get skipped)
[17:37] <kklimonda> doko: hey, any idea what's happening with clang in natty? I can't build applications that include (directlry or indirectly) curl/curl.h: http://paste.ubuntu.com/595577/
[17:38] <kklimonda> doko: If I make a symlink asm-generic -> asm then it works fine.
[17:38] <tkamppeter> pitti?
[17:49] <bdmurray> mvo: Are you still working on bug 683904?
[17:51] <mvo> bdmurray: I did not make any progress on this, sorry
[17:52] <bdmurray> mvo: okay, I just wanted to know where we stand
[17:56] <infinity> kklimonda: It's actually /usr/include/$gnu-machine-type/asm/ that you want.
[17:56] <infinity> kklimonda: I imagine clang isn't down with the New World Order there.
[17:57] <maco> ev: afaict, accerciser gets very unhappy with sudo. i think i had to DISPLAY= to get it to even start, but it still wasn't playing nicely
[17:57] <kklimonda> infinity: ah, that makes sense. Thanks
[17:59] <pitti> tkamppeter: I already ponged several times, didn't I? what's up?
[18:00] <ev> maco: oh, I completely forgot.  So I do: sudo -u ubuntu DISPLAY=:0 python test_ubiquity.py
[18:00] <ev> where test_ubiquity is:
[18:01] <ev> http://bazaar.launchpad.net/~ev/+junk/ubiquity-ldtp-tests/view/head:/test_ubiquity.py
[18:02] <maco> ev: thank you!
[18:02] <ev> sure thing
[18:02] <tkamppeter> pitti, sorry, did not see your pongs, something must have gone wrong. It is about several segfaults of CUPS, like for example bug 759031.
[18:03] <ev> let me know if you're still having trouble, though I wont be able to do anything until tomorrow
[18:03] <maco> ev: i'll be doing taxes tonight anyway ;-)
[18:03] <pitti> tkamppeter: ah,  right; are there better patches available for the avahi integration?
[18:03] <tkamppeter> pitti, they seem to be all caused by the Avahi patches but I cannot say exactly as Apport retracing generally does not work with CUPS. In addition, I did not succeed to reproduce any of these crashes.
[18:04] <pitti> tkamppeter: hm, that particular bug wasn't touched by the retracer at all as it seems; I marked it for retracing and will have a look what's going on
[18:05] <tkamppeter> pitti, What I have done now is asking twaugh about whether he has done fixes on these patches and he told yes and so I have regenerated our patch based on twaugh's newest version and there are indeed two small changes.
[18:06] <tkamppeter> pitti, Now I am thinking about replacing our patch in the hope that these two little changes cover some of the crashes.
[18:06] <pitti> tkamppeter: as long as the effective delta is small and looks sane, that sounds ok
[18:07] <tkamppeter> pitti, that is the case. It is one addeed check for a variable, one forgotten "free()" added, and a variable initialized to 0 (so actually three).
[18:08] <pitti> these sound like good fixes
[18:08] <pitti> tkamppeter: we have the cups-pdf apparmor fix queued as well, so we'll need another upload anyway
[18:08] <tkamppeter> pitti, I will add the updated patch ASAP.
[18:09] <tkamppeter> pitti, bug 754567 is another CUPS crasher ...
[18:09] <JFo> micahg, that plink error you reported against the kernel... it happens every time the chroot is destroyed?
[18:10] <tkamppeter> pitti, and bug 711875 is even worse, as 8 people tell they are affected by it.
[18:11] <micahg> JFo: yes, but I think it might be related to being in /dev/shm
[18:11] <JFo> ah,
[18:13] <JFo> micahg, is that something you need to be in for building, or are you testing an alternative?
[18:13] <pitti> ev: how can something be infinitively better than the old thing if the old thing wasn't completely broken? :-)
[18:13]  * JFo knows next to nothing about aufs
[18:13] <jibel> mvo, we are currently receiving many duplicates of bug 764883
[18:13] <ev> pitti: mind the hyperbole :-P
[18:14] <mvo> jibel: yeah, a fix is uploaded, sorry for this
[18:14] <JFo> micahg, this aufs version seems wrong as well
[18:14] <JFo> well, wrong/different from ours
[18:14] <mvo> jibel: aptdaemon 0.41+bzr646-0ubuntu2
[18:15] <mvo>  * debian/patches/01_fix_locking.patch:
[18:15] <mvo>     - cherry pick from evfool, many thanks (LP: #764422)
[18:15] <JFo> micahg, <tgardner> JFo, the file that the WARNING is coming from is only 396 lines in our version
[18:15] <micahg> JFo: well, jdstrand added a way to use sbuild in /dev/shm, so I thought I'd try it
[18:15] <JFo> ah, I see
[18:15] <micahg> JFo: idk, I should be using the latest kernel
[18:16] <jibel> mvo, seems to be the version affected by this bug. Package: aptdaemon 0.41+bzr646-0ubuntu2
[18:16] <micahg> JFo: 2.6.38-8.42
[18:17] <tkamppeter> pitti, new patch is pushed to the BZR.
[18:19] <tkamppeter> pitti, can you have a look at bug 711875, bug 754567, bug 751770?
[18:19] <pitti> tkamppeter: hm, your commit will close all four bugs in the changelog, but that's not proven yet, is it?
[18:20] <tkamppeter> pitti, that is true. So perhaps remove the ":" or so.
[18:20] <pitti> tkamppeter: ok
[18:21] <tkamppeter> pitti, I only want to have the reference to the bugs in the changelog.
[18:21] <pitti> tkamppeter: 711875 just got closed
[18:22] <pitti> tkamppeter: ok, will upload, then we'll see how it goes
[18:22] <tkamppeter> pitti, I see, seconds ago.
[18:23] <tkamppeter> pitti, perhaps a fix in a library which CUPS uses.
[18:25] <tkamppeter> pitti, there are many bugs of the kind "cupsd crashed with SIGSEGV in dbus_...()" with different D-Bus functions. Looks like that something is wrong with the D-Bus library. Perhaps it formerly supported certain calls from CUPS which it does not support any more. Can be a problem of libdbus.
[18:26] <pitti> unlikely, though; we don't see a lot of dbus crashes in other parts of the system; most likely it uses dbus in a wrong way
[18:28] <tkamppeter> pitti, so seems that they messed up the D-Bus use in CUPS 1.4.6? Or CUPS used a deprecated way of using D-Bus all the time and now it does not work any more (and all other programs use D-Bus correctly).
[18:28] <pitti> the dbus api hasn't changed in ages really
[18:29] <pitti> the only changed thing I'm aware of is the avahi patch (and avahi uses dbus extensively)
[18:30] <tkamppeter> pitti, so we must hope that these fixes in the Avahi patch solve also these ones.
[18:33] <tkamppeter> pitti, more we cannot do in the moment as CUPS is not retracing correctly. This needs really to get fixed.
[18:33] <SMG> im sorry about this, I know this is not the place, but running out of options " can someone help me, i need to update the "ar" file under "binutils", because it causes "*** buffer overflow detected ***: ar terminated" while compiling anything, but I cant update binutils because of the same problem?"
[18:44] <pitti> doko, chrisccoulson: seems doko's last upload of icedtea-web was against a previous  version and just reverted Chris' upload completely?
[18:44] <pitti> http://launchpadlibrarian.net/68408826/icedtea-web_1.1~20110320-0ubuntu2_1.1~20110406-0ubuntu1.diff.gz
[18:45] <pitti> chrisccoulson: I can sponsor it tomorrow morning if needed, but really need to run now
[18:56] <SpamapS> interesting..
[18:56] <SpamapS> the new chroot support in upstart can confuse things a bit
[18:57] <SpamapS> schroot doesn't stop all upstart jobs.. so processes stay alive in the chroot even on exit because upstart respawns them
[19:21] <mvo> jibel: oh - that was supposed to be the fix
[19:21] <mvo> jibel_: looking
[19:23] <achiang> doko: ping
[19:41] <SpamapS> jhunt: ugh, just now got to your email from 9 hours ago. ;)
[20:49] <cyphermox> hi, could someone please review this? --> https://code.edge.launchpad.net/~mathieu-tl/ubuntu/natty/mobile-broadband-provider-info/20110415/+merge/57946
[21:01] <stgraber> cyphermox_: looks good.
[21:01] <cyphermox_> stgraber, thx
[21:06] <stgraber> cyphermox_: merged and uploaded. You just need to wait for an archive admin to review it.
[21:06] <cyphermox_> ok, thanks
[22:09] <phb> hey guys, not sure if my channel fits here. I'm wondering if ALL of HAL (dbus) is deprecated, or only certain parts?
[22:09] <phb> s/channel/question/
[22:13] <ohsix> ok what do i do here. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/764874 a bug i posted earlier got marked as a dupe of a bug that's "resolved fixed": https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/711429 but it is still happening, the retracing service is the one that marked it as a duplicate; i don't know how it chooses to do that, but could someone manually confirm they're the same?
[22:14] <ohsix> moreover, it looks like an unrelated bug that was marked upstream as having solved it
[22:16] <ohsix> seb128: ping
[22:18] <seb128> ohsix, hi
[22:18] <ohsix> can you look at the above? you marked it with the upstream bug
[22:20] <seb128> ohsix, it's fix commited
[22:20] <ohsix> it's happened twice today so i expect it to annoy me for some time :|
[22:21] <ohsix> yea it's happening again, presumably i have whatever fix was added then, or is it not included yet?
[22:22] <ohsix> this is the second bug i reported that was marked dup of that one i think, but the last time i reported it was like 5 months ago; on mav, it started happening again today, though
[22:24] <ohsix> i don't know how to tell if i'm using packages with the fix included, or if it should be marked new again; or another bug should be filed for the same thing if it's a bug at the same site
[22:24] <seb128> ohsix, there is just a workaround in upstream git but it's not really a fix
[22:24] <seb128> ohsix, there is no fix in ubuntu
[22:24] <ohsix> oh ok
[22:25] <ohsix> a notice would be on the bug when a package is rolled with it, right?
[22:25] <seb128> the bug would turn to fix released
[22:25] <ohsix> ahh
[22:26] <ohsix> ok thank for the information
[22:28] <m4n1sh> in which package is mozilla/ModuleUtils.h file contained?
[22:28] <m4n1sh> this is for upgrading a firefox extension for FF4
[22:31] <ohsix> seb128: perhaps you can advise me on something else, i created a patch to restore functionality upstream dropped, and they are particularly brickwall about it; i want to get the patches included in more than my ppa, how do i do that? https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/713604
[22:32] <ohsix> they're even moderating their trac bug reports and removing comments on the related bugs
[22:33] <seb128> ohsix, no idea about how transmission upstream is working
[22:34] <ohsix> i contacted them a few days before i bothered with the patch and i was really surprised :[
[22:35] <ohsix> the patch is small and it's a revert of a change that was made just before the 2.13 release was tagged; basically all that changed besides bug fixes in 2.12 -> 2.13 was removing the tab and the suppot
[22:36] <ohsix> i tried contacting the packager but he hasn't replied yet, i just don't know the process of proposing it for inclusion
[22:36] <ohsix> need a sponsor i guess?
[22:40] <ohsix> thanks again for your time, and as i've said before you've touched a lot of my bugs! i really want this patch in but don't know where to start
[22:45] <ohsix> argh the same person that's very very very very rude and also moderating their ticket comments is the driver/maintainer for the package on launchpad, i really need someone bigger than myself to work with them; i already tried to negotiate with them with an abundance of good will and politeness and they just brushed me off
[22:45] <bloops> would there be any problems if I have two different versions of g++ installed on my system?
[22:47] <ohsix> seb128: is there someone with time to discuss these things available somewhere? or is patience and asking here all i can do
[22:50] <seb128> ohsix, you can open a bug with the diff and subscribe ubuntu-sponsors for review but we don't to no revert decisions from the upstream project
[22:50] <seb128> it's their code
[22:51] <ohsix> yea, in understand that; but they are being underhanded about accepting public comment, their public correspondence suggests they invited it but they are very very very rude if you even mention bringing it back
[22:52] <ohsix> theres no other public discussion than the trac bugs either, and as i've said they're moderating them to keep discussion down; so on the one hand they say they want public comment, but also won't allow it to get through
[22:53] <ohsix> it makes transmission useless for me, and 2.12 isn't packaged for natty; so it's a big deal, at least for me
[22:54] <ohsix> if they're not accepting public comment, even though they "are"; i need someone that frankly, matters; to ask them about it, so they will be as rational as you can get them
[22:55] <ohsix> seb128: i posted a diff on the original bug, should i open a new one just for it?
[22:56] <ohsix> (just for ubuntu-sponsors)
[22:59] <seb128> ohsix, if the bug is closed yes
[23:00] <ohsix> seb128: ok thanks
[23:01] <ohsix> seb128: any special things to put in the title? like [PATCH] or [FFe]
[23:01] <seb128> no
[23:02] <ohsix> k thanks
[23:09] <ohsix> seb128: https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/765248 posted, i'm very interested in things i might do well to correct :D
[23:10] <ohsix> if you could add your weight to it even better! like i said, i wasn't even given the respect you think they'd give a human being
[23:11] <seb128> ohsix, some extra context like the upstream commit reference and the upstream bug url would be nice
[23:12] <ohsix> they're on the ppa summary page but i can add them there
[23:12] <seb128> that would be useful
[23:13] <seb128> you want to subscribe ubuntu-sponsors to the bug as well
[23:13] <ohsix> oh i added it as a tag, not a subscriber :|
[23:14] <ohsix> i tried not to sound hyperbolic, but man you won't believe how i was treated :|
[23:16] <ohsix> added the references from the ppa page to the bug
[23:17] <ohsix> on the plus side i learned all about how to package and upload things :]
[23:17] <ohsix> i'll have to find something to package!
[23:29] <ohsix> seb128: ooh just realized i left the window open; saved the log