[00:14] <Keybuk> jono: have a little matter of moving apartment
[00:14] <Keybuk> and David is visiting too from tomorrow
[00:15] <Keybuk> if Collab looked like anything other than an LF wankfest, I may have made some time
[00:15] <Keybuk> but it's too warm outside to get sticky
[00:15] <lifeless> LF ?
[00:15] <azeem> linux foundation
[00:15] <lifeless> ah
[00:16] <azeem> it's the plumbers conference for business people or something
[00:18] <Keybuk> it was supposed to be the plumbers conference, but for distro people
[00:18] <Keybuk> but then they turned it into the Moblin conference
[00:18] <Keybuk> which became the MeeGo conference
[00:18] <Keybuk> now it'
[00:18] <Keybuk> now it's the "let's do something that's not Linaro" conference, I think
[00:39] <bradm> hey, I'm being affected by bug#727620, is there anything I can do to help with it in terms of info / whatever?
[00:41] <robert_ancell> poolie, hey, have you got the mouse issue in unity again?
[00:57] <poolie> robert_ancell, hi, which mouse issue?
[00:57] <poolie> ignoring mouse input?
[00:57] <poolie> i'm back to the classic ui at the moment
[00:58] <robert_ancell> poolie, bug 750816
[00:58] <poolie> robert_ancell, i had it this morning (before applying today's updates)
[00:58] <robert_ancell> poolie, I've had similar issues before, and it's actually been due to an interaction between the touchpad and the mouse.  In that case I move the touchpad and it starts working again.  I'm wondering if you've got the same thing
[00:59] <poolie> interesting
[00:59] <poolie> i can re-test in a bit
[00:59] <robert_ancell> I think it's an X issue, but it seems to have reduced recently
[00:59] <robert_ancell> thanks
[00:59] <poolie> i guess i could start a guest session, so i (maybe) don't lose my work
[00:59] <robert_ancell> poolie, heh, no rush, but ping me if you get it again
[01:01] <poolie> the other X issue that's hurting a lot is bug 749817
[01:02] <bradm> poolie: at least you can get X, my laptop won't even boot since I've gone natty :-/
[01:03] <RAOF> poolie: I've looked at your description - do you have a picture in both screens *before* logging in?
[01:03] <bradm> bug 727620 seems pretty serious
[01:03] <poolie> RAOF, yes, pretty sure i do
[01:03] <poolie> the same as in maverick
[01:04] <poolie> the gdm greeter is displayed in mirror mode
[01:04] <RAOF> So something's setting strangeness.
[01:04] <RAOF> I don't suppose a guest mode login works?
[01:05] <RAOF> Also, could you set the drm.debug=0x04 kernel parameter (either from the command line, or via /sys/modules/drm/parameters/debug) and reproduce, then attach dmesg and Xorg.0.log to the bug?
[01:05] <poolie> ok
[01:06] <poolie> will just finish filing other bugs then try these
[01:40] <bradm> natty really doesn't like ATI 5600 series cards, now my 2nd monitor has its screen shifted across a few cms, its very disconcerting
[02:00] <poolie> bradm, looxury
[02:49] <poolie> RAOF, i updated bug 749817 with the data you asked for
[02:49] <poolie> and it's still present in today's xorg update
[02:49] <RAOF> poolie: Ta muchly.
[02:49] <poolie> robert_ancell, i'm running unity again; if i hit that problem i will try wiggling the touchpad and trackpoint
[02:51] <robert_ancell> poolie, ta
[02:53] <RAOF> poolie: Incidentally: nice boot time!
[03:02] <RAOF> poolie: Oh.  That dmesg seems to be truncated at ~6sec, which is before you hit the blank screen problem.
[03:42] <twb> Can rmadison lag behind the actual pool?
[03:43] <twb> Never mind, I found the problem.
[03:43] <StevenK> twb: Yes, by up to 6 hours
[03:44] <twb> (Somehow I accidentally uploaded one of my Debian packages to my company's in-house lucid apt archive.)
[03:45] <twb> Probably happened a while ago and I only just noticed because it was i386-only, and only the router is still 32-bit.
[04:35] <poolie> bryceh, do i need to wait for an updated xorg before i can apport-collect that data?
[04:50] <bryceh> poolie, yep
[04:55] <poolie> bryceh, would that be in natty-proposed already...?
[04:55] <ScottK> lamont: Just uploaded postfix 2.8.2 to Natty.
[04:55] <ScottK> poolie: No.  Nothing's there yet.
[04:59] <bryceh> poolie, you're looking for xorg_7.6+4ubuntu2
[04:59] <bryceh> poolie, or if you're in a rush, it's easy to fix locally
[05:00] <bryceh> edit /usr/share/apport/package-hooks//source_xorg.py
[05:00] <poolie> i'd be happy to just apply a patch or tweak it
[05:00] <bryceh> around line 288
[05:00] <bryceh>         "libgl1-mesa-dri*",
[05:00] <bryceh> change to
[05:00] <bryceh>         "libgl1-mesa-dri",
[05:01] <poolie> k
[05:04] <poolie> bryceh, ok, attachments attached; thanks
[05:08] <poolie> hi ScottK
[05:08] <ScottK> Hello poolie.
[05:09] <ScottK> bryceh: Is that the same issue I just filed Bug 750967 about?
[05:11] <poolie> scottk, i heard quite a different story about the python3 transition from allison the other day
[05:11] <poolie> (i may have misunderstood)
[05:11] <ScottK> Oh?
[05:11] <poolie> but that was that basically packages did not seem very ready to go to python3 so it was unlikely ubuntu would drop python2 soon
[05:11] <bryceh> ScottK, yep that's it
[05:12] <poolie> if ubuntu is considering such a move that would obviously be a pretty strong motivation for bzr
[05:12] <poolie> there aren't a lot of other reasons to move at this point
[05:12] <ScottK> There's a lot of work to do, but I think it's achievable for 'P' if the project decides to focus on it.
[05:14] <ScottK> Most of the major upstream stuff supports python3 (although we don't have it all properly packaged).  The major issue will, IMO, be the custom code that's used in Ubuntu only.
[05:14]  * ScottK has no idea how hard a Python3 Ubiquity port would be.
[05:18] <lifeless> ScottK: last I saw stats, most stuff *didn't* support python3 upstream
[05:19] <lifeless> ScottK: but thats from a total population, not the 'we package it' subgroup
[05:19] <ScottK> lifeless: In the broader python world I think that's true.  The stuff needed for a KDE/Gnome desktop though I think supports it.
[05:19] <ScottK> I know PyQt and PyKDE do.
[05:20] <ScottK> The Python3 stuff I've done has seen very little uptake, so it's still early going in the broader sense.
[05:21] <ScottK> poolie: Wouldn't "Barry will haunt you if you don't go to Python3" be enough motivation?
[05:22] <poolie> :)
[05:22] <poolie> he is not the scariest ghost in the treehouse
[05:23] <ScottK> True.
[05:23] <ScottK> Upstream Python is, though, I think totally committed to Python3, so eventually if you want to do Python, you'll have to take the plunge.
[05:24] <ScottK> If you're writing for python2.6 or later, it's pretty easy to also write stuff that is either valid python3 or 2to3 will handle.
[05:24] <ScottK> So you can be 'working on it' even when you haven't decided to switch yet.
[05:45] <poolie> scottk, that's true
[05:46] <poolie> though, i wonder
[05:46] <ScottK> So even if you aren't considering a near-term port, I think having coding standards that support making the eventual transition 'easy' are a good idea for now.
[05:46] <poolie> if someone will fork py2.x if the transition is too hard
[05:46] <poolie> yes
[05:46] <ScottK> Maybe.
[05:46] <poolie> i have no real evidence, i just wonder about it
[05:47] <ScottK> Upstream's pretty clear that's the only way 2.8 would ever happen.
[05:47] <ScottK> My experience so far is that code that's written with 2.6 features in mind is pretty easy.
[05:48] <StevenK> I worry about the 3.x transistion for LP.
[05:53] <ScottK> It will be "fun".
[05:53] <StevenK> I think you're spelling it wrong.
[05:54] <StevenK> ScottK: But, things like Zope, Twisted and Storm need to support it before we can consider it.
[05:54] <ScottK> Yep.
[05:54] <ScottK> It's a long term issue.
[05:55] <ScottK> I still think coding standards to push to make compatibility easy when the time comes is what makes sense for now.
[05:55] <StevenK> ScottK: The problem is that with Twisted, it wants to support a wide range of Python versions.
[05:56] <ScottK> Yep.
[05:56] <ScottK> I recently managed to convince the other maintainer on one project I'm working on to give up on python2.2.1 compatibility.
[05:56] <StevenK> I don't remember 1.5 to 2.1 being this hard. :-)
[05:56] <ScottK> It wasn't.
[05:57] <lifeless> python had a psychotic break
[05:57] <ScottK> python2 -> python3 is more discontinuous.
[05:57] <ScottK> Not accidental though.  On purpose.
[07:42] <didrocks> good morning
[07:57] <Sweetshark> didrocks, all: good morning!
[07:59] <didrocks> hey Sweetshark
[08:17] <pitti> Good morning
[08:23] <dholbach> good morning
[08:37] <slangasek> mvo: hi there!  Have you seen that DonKult has a branch available that fixes bug #733741?  is it ok if I pluck the fixes in, or do you prefer to do so yourself?
[08:38] <mvo> slangasek: yeah, its on my radar, I want to upload it today
[08:38] <slangasek> mvo: woohoo :-)
[08:39] <mvo> slangasek: I want to look look at the other fixes in his branch too and coordinate with debian, but should be done today :)
[08:39] <slangasek> mvo: cool :)
[09:16] <buhl> Does anyone know why the beta1 is sooo much heavier on my system? - It's using three times more RAM idling...
[09:28] <pitti> buhl: nvidia?
[09:33] <buhl> pitti, Yes..
[09:33] <pitti> buhl: that's bug 725434 then; we'll get it nailed for final one way or the other
[09:35] <buhl> pitti, Is there a temporary workaround?
[09:35] <pitti> buhl: use nouveau?
[09:35] <pitti> (perhaps with the experimental 3D drivers)
[09:36] <buhl> pitti, Excuse me for maybe being a dumb-ass, but what's nouveau?
[09:36] <infinity> buhl: The free nvidia driver.
[09:36] <pitti> buhl: sorry; it's the default free driver for nvidia cards, i. e. what you get when you don't install the proprietary one in the "addidional hardware" app
[09:36] <cjwatson> StevenK: the lag is no longer six hours; I believe the rmadison backend mirror updates hourly now
[09:37] <pitti> buhl: in "additional drivers" you might also see the experimental nouveau 3D driver; worth giving them a shot :)
[09:37] <StevenK> cjwatson: Neat!
[09:37] <buhl> Pitti, So if i stop using the proprietary driver, it might work?
[09:38] <pitti> buhl: the memleak will be gone, and 2D apps will still work; I don't know how well the 3D nouveau driver will work on your system, of course
[09:38] <infinity> buhl: If you stop using the proprietary driver, it'll certainly fix this particular issue.  It may also, however, lead to other issues, depending on your chipset, and your usage patterns (ie: heavy 3D use)
[09:38] <cjwatson> ScottK: python3 ubiquity> not desperately hard for oneiric, I think; the only real reason we were holding off was that it would commit us to shipping python3 on the CD
[09:39] <infinity> buhl: The situation with nvidia and ati chipsets has always been a bit lose-lose in these cases.  The proprietary drivers work great until they explode, and there's little we can do about them except try to find a sweet spot, and due to lack of documentation, the free drivers always lag behind and seem a bit lackluster, especially on newer chips.
[09:39] <cjwatson> bah, netsplit
[09:40] <buhl> infinity, But as i'm using a relatively old chip, i might benefit from a free driver?
[09:41] <infinity> buhl: Depends on how relatively old.  On the other hand, if you pretty much just do 2D/desktop type stuff, nouveau will probably be fine for you regardless.
[09:41] <infinity> buhl: It pretty much just fails miserably at being a cutting edge 3D driver for, say, video gaming.
[09:42] <buhl> infinity: I'm a student, so its mostly simulations and math-programs.. And its about 5 years old..
[09:42] <infinity> doko: Mornin'.
[09:43] <infinity> buhl: Well, as pitti says, one way or another, we'll find a solution to the non-free driver sucking, but there's no harm in you flipping to the free one, and if it does everything you need it to, win.  No need to worry about the binary pain.
[09:43] <doko> infinity: you're in Europe?
[09:43] <infinity> doko: No, but I assumed you were. :P
[09:44] <doko> heh ...
[09:45] <buhl> infinity, pitty: Thank you very much. Both of you! And i'm looking forward to benefit from your work!
[09:45] <infinity> That was a long split.
[09:45] <infinity> Clearly, we should have switched the free software world to AOL chat rooms a decade and a half ago.  This IRC thing's sketchy.
[09:53] <cjwatson> ScottK: python3 ubiquity> not desperately hard for oneiric, I think; the only real reason we were holding off was that it would commit us to shipping python3 on the CD
[09:53] <cjwatson> ScottK: so sort of wanted to make sure that the rest of the desktop would be switched over
[10:21] <seb128> ev: hi, is there any web ui or something easy to use to query the ubuntu-geonames database?
[10:22] <ev> seb128: http://geoname-lookup.ubuntu.com/?query=wandsworth
[10:22] <seb128> ev: like bug #750395 points that lima, peru is not listed by the indicator not sure if that's a client or server side issue
[10:23] <seb128> ev: ok, thanks, seems it's a server issue again :-(
[10:23] <seb128> ev: is ubuntu-geonames being actively maintained? like is it worth waiting on those issues to be fixed or should we switch to another db?
[10:24] <seb128> I'm close suggesting we switch to libgweather for the indicator since it has proved to be working and it's translated
[10:24] <ev> seb128: the data is maintained by geonames.org.  They're, as far as I'm aware, the largest free source of that data.
[10:25] <seb128> ev: well geonames.org does list lima,peru
[10:25] <seb128> ev: it's the first match for "lima" on their site
[10:25] <seb128> it's only one example, we got several bugs reported that happen on ubuntu-geonames but not on geonames.org
[10:26] <ev> the existing database used by geoname-lookup.u.c uses a dump from last year (when it was created).  I can update that today and ask IS to merge the changes in.  I don't know if that will fix the problem though
[10:26] <ev> it might be an issue with the way in which we query the database
[10:27] <seb128> ev: if you could start by updated the database that would be great ;-)
[10:27] <seb128> then we can try to figure what is wrong if there is still an issue
[10:28] <ev> sure
[10:28] <seb128> ev: thanks a lot!
[10:28] <ev> no problem
[10:28] <seb128> ev: and sorry to bother you about that, let me know if there is somebody else I should ping about ubuntu-geonames rather
[10:28] <seb128> bug #740874 as well btw
[10:28] <ev> no, it's okay
[10:29] <ev> I'll have a look
[10:49] <Mez> Any release team here?
[10:49] <Mez> (and active)
[10:50] <Laney> Mez: #ubuntu-release is the hangout
[10:50] <Mez> Laney: ah, didn't realise they had their own channel (though it makes sense)
[10:50] <Laney> :-)
[10:55] <ogra_> TheMuso, i mailed you the URL for the patches, did you get it ?
[11:28] <Mez> o_O  Build logs say that the build was fine, but page says it failed to build
[11:30] <cjwatson> URLs?
[11:30] <Mez> https://launchpad.net/~mez/+archive/mez-mf/+buildjob/2428596
[11:31] <elmo> Mez: look at the end of the build log
[11:31] <elmo> or grep for http://wiki.debian.org/ImplicitPointerConversions
[11:32] <Mez> elmo: Er... I didn't think ubuntu shipped for ia64?
[11:32] <cjwatson> we sure as heck ship for amd64
[11:32] <cjwatson> the problem is actually worse there, because it only happens sometimes
[11:33] <cjwatson> (or worse in a sense, anyway)
[11:33] <Mez> cjwatson: :( I've never seen it happen on that package... which is a shame...
[11:33] <cjwatson> just fix the bug
[11:34] <cjwatson> it's not that hard and it will make your package more robust
[11:34] <Mez> cjwatson / elmo - maybe make it a little bit clearer - so that it mentions that it's a failed build.
[11:34] <cjwatson> it does, it says "Failed to build" in red letters on the build page
[11:35] <Mez> cjwatson: In the build log - it just says "these are errors" - not "failed to build because of this"
[11:35]  * Mez shrugs
[11:35] <cjwatson> it's hard to do better with the way gcc works
[11:35] <cjwatson> most people get the habit of scrolling down immediately to the end of the build log, anyway
[11:36] <cjwatson> if you think the text could be improved, file a bug on launchpad-buildd
[11:36] <cjwatson> (neither elmo nor I work on that code)
[11:51] <Mez> cjwatson: unfortunately, that error's actually in gtk... not in the package :(
[11:55] <infinity> Mez: So fix GTK?
[11:56] <cjwatson> Mez: no it isn't, it's in your package's *copy* of bits of GTK
[11:56] <cjwatson> (as far as I can see)
[11:56] <cjwatson> gtk+2.0 builds fine
[11:57] <mr_pouit> ./query-browser/source/linux/gtksourceview/gtksourceview/gtksourceview.c
[11:57] <cjwatson> in fact, gtksourceview.c is not part of GTK at all
[11:59] <Mez> cjwatson: yes... that's not... It does seem however, that it's either a) not including the right file or b) had the definition in the header moved.
[12:00] <cjwatson> Mez: not including the right file is a standard reason for this problem.
[12:00] <Mez> cjwatson: is another one -GDK_DISABLE_DEPRECATED ? :P
[12:01] <cjwatson> Mez: sure, anything that causes the prototype to go away.
[12:01]  * Mez attempts to shove up a new copy
[12:01] <Mez> :( Direct sync from Debian wont work either (until I push up changes to debian)
[12:02] <infinity> Incentive to push changes back to Debian doesn't sound like something worth frowning over...
[12:03] <Mez> infinity: long time no speak - but yeah - no - I don't mind pushing the changes to debian - but that adds time to it - meaning it might get to a point where I have to try and do an SRU rather than a bugfix before :D
[13:09] <chrisccoulson> @pilot out
[13:09] <chrisccoulson> oops ;)
[13:10] <chrisccoulson> oh
[13:10] <chrisccoulson> Current Friendly Patch Pilots: chrisc
[13:10] <chrisccoulson> hmmm :/
[13:10] <chrisccoulson> who is chrisc? ;)
[13:15] <Pici> probably the person whose name is too long for the topic ;)
[13:46] <pitti> SpamapS: ah, someone already added you to core-dev (I was just about to do it, as I saw the official mail from DMB); congratulations!
[13:53] <cjwatson> Mirv: for bug 747090, are you using kvm by any chanc?
[13:53] <cjwatson> *chance
[13:59] <Mirv> cjwatson: yes I am... I can boot from USB in a moment instead. if that bug only hits kvm users and not "real" users, it's quite evil bug :S
[14:01] <cjwatson> Mirv: if you wouldn't mind trying, I'd appreciate confirmation that it doesn't affect bare-metal boots.  I think I've narrowed it down to a kvm bug, and I've certainly confirmed that it affects kvm for me but not qemu -no-kvm
[14:02] <cjwatson> (and I have a rationale, because I appreciate that that's an extraordinary claim ...)
[14:14] <Mirv> cjwatson: confirming that everything works fine when booting an actual computer
[14:23] <cjwatson> Mirv: excellent - writing a long rationale for reassigning to qemu-kvm now
[14:24] <Kaleo> Riddell: have you observed that bug where Qt apps have bold fonts everywhere? https://bugs.launchpad.net/ubuntu-font-family/+bug/751048
[14:25] <Kaleo> Riddell: it's quite recent, maybe 2 weeks
[14:27] <Kaleo> Riddell: I suppose it's a dupe of https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/741862
[14:29] <Riddell> Kaleo: I haven't seen that no
[14:33] <Shawn727> Anyone need help?
[14:33] <Shawn727> Im here to help
[14:34] <tjaalton> who's in charge of libburn / libisoburn packages? they are rather old (0.8.0 / 0.5.6), there is 1.0.4 in wheezy
[14:34] <tjaalton> interested in BD-* media support
[14:34] <cjwatson> tjaalton: feature freeze, no?
[14:34] <tjaalton> cjwatson: yes :)
[14:35] <Shawn727> ?
[14:35] <tjaalton> but there's been bug 685600 open for months
[14:36] <cjwatson> IIRC we were more or less in sync with Debian at feature freeze; of course, Debian was itself frozen at that point
[14:36] <tjaalton> right
[14:36] <tjaalton> 1.0.0 was released on jan 17th
[14:38] <Laney> 1.0.4 was uploaded into Debian on March 13
[14:38] <Laney> which is almost three weeks after FF started
[14:38] <tjaalton> ah, so it was bumped from 0.8.0 directly
[14:45] <soren> cjwatson: Are you on intel or AMD hardware (for that "gfxboot" bug)?
[14:46] <cjwatson> soren: Intel
[14:46] <soren> cjwatson: ok.
[14:47] <cjwatson> I've posted /proc/cpuinfo to the bug
[14:47] <jpds> slomo: bug #751343 - is interesting.
[14:48] <slomo> jpds: already fixed, sorry for the trouble
[14:56] <SpamapS> pitti: ty! :)
[14:57] <SpamapS> pitti: actually I already uploaded something to lucid-proposed. :)
[14:57] <pitti> SpamapS: nice!
[15:02] <SpamapS> @pilot in
[15:02] <Laney> topic limit eh
[15:06] <cjwatson> @pilot in
[15:06] <cjwatson> dholbach: I know you like it all fluffy and all, but can we make that just "Patch Pilots:"?  topic space is very limited
[15:07] <hallyn> ok, this is disconcerting: i just wget'ed natty-alternate-amd64.iso, burned it, and it hangs on parted_server
[15:07] <cjwatson> hallyn: /var/log/syslog /var/log/partman please
[15:08] <cjwatson> hallyn: or a repro case
[15:08] <cr3> hi folks, under what circumstance does a -proposed Packages.bz2 file contain a reference to a package which does not appear under archive.ubuntu.com/ubuntu/dists...
[15:08] <dholbach> cjwatson, I'm not opposed at all - I think it was ogra's fault
[15:08] <dholbach> ;-)
[15:08] <Laney> we could change the middle bit to "Development of Ubuntu (not support [#ubuntu], not app development [#ubuntu-app-devel])"
[15:08] <ogra_> hey, use aa fluffy font at least :P
[15:08] <hallyn> cjwatson: repro case?  get a vostro laptop and try to install :)
[15:09] <hallyn> lemme get a usb stick to copy those files over
[15:09] <dholbach> tsimpson, do you think the bot could make it "Patch Pilots:" instead of "Current Friendly Patch Pilots:"?
[15:10] <hallyn> i don't see any obvious errors though (just cat'ing it)
[15:10] <cr3> specifically, linux-image-2.6.35-28-generic does not seem to appear in maverick-updates when running apt-get update + dist-upgrade
[15:13] <cyphermox> hallyn, what kind of Vostro laptop?
[15:13] <hallyn> cjwatson: I'll upload these to a bug.  What should a file bug against?
[15:13] <hallyn> cyphermox: 1220
[15:14] <hallyn> i'll file against debian-installer
[15:17] <cjwatson> hallyn: debian-installer is fine, yes
[15:17] <cjwatson> hallyn: "get a vostro laptop" is not much good to me for debugging :)
[15:17] <hallyn> :)
[15:19] <hallyn> cjwatson: bug 751449
[15:26] <ogasawara> could I get an archive admin to accept the linux-meta and linux-backports-modules-2.6.38 packages for i386 and amd64 in the New queue?
[15:32] <cr3> turns out the problem is that linux-image-generic is not contained in Packages.gz in the current maverick-proposed archive whereas a more recent linux-image package is available in the archive, might anyone know if there's a reason for that?
[15:38] <cr3> nevermind folks, found the linux-image-generic package under maverick-security. my mistake, I looked under maverick-updates just in case
[15:38] <cjwatson> cr3: it's in maverick-updates too
[15:39] <cjwatson> cr3: packages are removed from -proposed shortly after they're promoted to -updates
[15:39] <cr3> cjwatson: good to know, thanks!
[15:40] <cr3> will a sru always land in -security or might it be possible that it only lands in -updates?
[15:42] <tsimpson> dholbach: it was, but someone asked me to change it to friendly patch pilots
[15:42] <cjwatson> cr3: SRUs don't land in -security; only security updates (a different process) land in -security
[15:44] <brendand> cjwatson - why is linux-image-2.6.35-28-generic in -updates? isn't that the current SRU?
[15:44] <brendand> cjwatson - at least according to the tracking page
[15:45] <dholbach> tsimpson, maybe we can change it back? :-D
[15:45] <tsimpson> @pilot in
[15:45] <tsimpson> @pilot out
[15:45] <udevbot> An error has occurred and has been logged. Please contact this bot's administrator for more information.
[15:45] <tsimpson> yay! :(
[15:46] <dholbach> glad we have the bot's administrator here :)
[15:46] <cjwatson> brendand: according to the tracking page, the update currently being validated is 2.6.35-28.50, and the previous version was 2.6.35-28.49.  Both of those built a linux-image-2.6.35-28-generic binary package
[15:46] <tsimpson> @pilot out
[15:46] <tsimpson> *sigh*
[15:46] <cjwatson> brendand: if you use rmadison (in the devscripts package), you'll get a table with versions
[15:47] <tsimpson> @pilot out
[15:47] <tsimpson> ok, no more spam from me :)
[15:47]  * dholbach hugs tsimpson
[15:56] <brendand> cjwatson - it seems there is no linux-image-generic package in -proposed, which is meaning the dist-upgrade is not seeing anything
[15:59] <cjwatson> brendand: there doesn't need to be - the linux-image-generic package in -updates is sufficient, since its dependencies don't need to change
[15:59] <cjwatson> linux-image-generic just depends on linux-image-2.6.35-28-generic, and doesn't actually ship any significant files itself
[16:00] <cjwatson> and all systems with -proposed in sources.list must also have -updates in sources.list
[16:00] <cr3> brendand: aha! so the problem is that we only had maverick and maverick-proposed, no maverick-updates so we didn't get the latest linux-image-generic package
[16:01] <cr3> I'm not sure how I feel about having to perform a whole upgrade in order to perform sru testing on each system
[16:01] <cjwatson> such a configuration will certainly cause problems, yes
[16:01] <cjwatson> you don't have to; you can install just the packages you're testing, if you like
[16:02] <cr3> perhaps a compromise would be to add -updates but only dist-upgrade linux-image-generic rather than dist-upgrade without arguments
[16:02] <cjwatson> 'install linux-image-generic', not 'dist-upgrade linux-image-generic' - dist-upgrade doesn't take arguments
[16:02] <cjwatson> (although bear in mind that most users will have fully upgraded; ideally, our testing should match their configuration)
[16:03] <hallyn> anyone know of an irc channel relevant to libpciaccess?
[16:04] <brendand> cr3: so why did it work on the laptops?
[16:04] <cr3> cjwatson: sru testing mostly consists of making sure the hardware is still supported, so that's mostly kernel related but not fully related
[16:04] <cjwatson> maybe the laptops were already upgraded to some vintage of -updates
[16:05] <brendand> cjwatson - they went through the same process as the servers
[16:05] <brendand> cjwatson - something for us to worry about
[16:05] <cr3> brendand: maybe linux-image-generic happened to be in the maverick-proposed Packages.gz file yesterday
[16:08] <cjwatson> that's quite possible; the removal is semi-manual
[16:17] <dylan-m> didrocks, are you about? :)
[16:17] <didrocks> dylan-m: yeah
[16:20] <dylan-m> Yay! I'm just wondering what's going on with bug #749428 :)
[16:20] <dylan-m> You were wondering what I was babbling on about, and then all of a sudden it looks like you had it under control. Do you still need any clarification?
[16:25] <dholbach> hey dylan-m
[16:25] <dholbach> how are you doing?
[16:28] <dylan-m> Hi dholbach! I'm doing pretty well. Need to stop writing patches for things, though; lots of other stuff to do… :b
[16:28] <dholbach> haha - I can imagine :)
[16:30] <highvoltage> howdy dylan-m and dholbach
[16:31] <dholbach> hey highvoltage
[16:31] <dylan-m> Hi highvoltage!
[16:38] <cjwatson> Keybuk: reading bug 707479 - is there anything in https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/upstart-job-change-restart/+merge/52547 that you object to?  it's only changing the effect when called in a SysV kind of way rather than an Upstart kind of way, and the proposed behaviour seems more SysV-compatible to me
[16:39] <SpamapS> cjwatson: o/ thanks for taking another look at that btw. :)
[16:39] <cjwatson> (I don't know if you've already discussed this with Clint on IRC, but since there's no record of a discussion I wanted to check)
[16:39] <cjwatson> jhunt_: ^ FYI
[16:40] <Keybuk> cjwatson: I haven't seen that patch
[16:40] <Keybuk> but I think I may have told Clint that I thought doing that was the right fix
[16:40] <Keybuk> (making "service" behave SysV-y)
[16:40] <cjwatson> right, thanks - I just wanted to check that there wasn't contention about that part that I was misssing
[16:40] <cjwatson> *missing
[16:41] <cjwatson> since the original report in #707479 did mention service(8)
[16:41] <Keybuk> no, I definitely think that's the right way to bridge the behaviours
[16:41] <cjwatson> ok, excellent - thanks!
[16:41] <Keybuk> right, but the original report was on upstream
[16:41] <Keybuk> which doesn't contain service(8)
[16:41] <cjwatson> ah, I missed that
[16:42] <Keybuk> the Ubuntu task was left open, because it does
[16:42] <cjwatson> it's never very clear in LP bug history
[16:42] <Keybuk> Launchpad makes it too damned hard to see that subtlety
[16:43] <cjwatson> jhunt_: can you merge the branch discussed above for your next Ubuntu upstart upload, then, if you also agree with it?
[16:44] <jhunt_> cjwatson: ok - taking a look at it now...
[16:44] <SpamapS> could somebody add me to ubuntu-sponsors so I can unsubscribe bug #712614 from it? thanks!
[16:44] <mvo> dpm: when is the next langpack update planned? there is a issue with file overwrites that is showing in the auto-upgrade-tester but that is fixed in langpack-o-maitc
[16:46] <cjwatson> kees,TheMuso,nhandler: ^- request for ubuntu-sponsors addition from SpamapS above; you're all administrators
[16:47] <Laney> shouldn't we just have ubuntu-dev as a member of ubuntu-sponsors?
[16:47] <SpamapS> Laney: that would make a lot of sense. :)
[16:49] <Laney> I think there were some counter-arguments, but don't remember what they are
[16:49] <cjwatson> I think there was a desire to have ubuntu-sponsors be people who were actually active in sponsoring
[16:50] <SpamapS> Was that pre-pilot? Seems like most devs are active in that on some level.
[16:51]  * Laney doesn't share that desire: every dev /can/ sponsor, and most will want to at some point
[16:54] <lool> mvo: WRT LP #733741, does python-apt also need a rebuild before the fix is visible?
[16:56] <juliank> lool: No.
[16:57] <juliank> Although it still returns amd64 here.
[16:57] <lool> mvo, juliank: You two have any clue where this might come from?
[16:58] <lool> I could ask james_w whether he has a smaller test case
[16:58] <Keybuk> kees, cjwatson, pitti, mdz: ok, so now I'm officially confused about when the Tech Board meeting is supposed to be
[16:58] <kees> SpamapS: added!
[16:58] <lool> james_w: I'm still seeing the APT multiarch regression with linaro-image-tools testsuite and latest APT; do you have a reduced testcase?
[16:59] <juliank> lool: apt_pkg.Cache()["python-apt-common"].architecture should be all, right?
[16:59] <kees> Keybuk: 1800UTC.  Which is 11am on the US west coast.
[16:59] <SpamapS> kees: dekujume moc! :)
[16:59] <Keybuk> kees: but it was 11am during the timezone screwage too?
[17:00] <kees> Keybuk: when DST changed, it went from 10am to 11am for us.
[17:00] <lool> juliank: Yup; I get amd64 here; I wonder whether it could relate to file:// URIs?
[17:00] <Keybuk> kees: ah, and there is no intent to change it to be 6pm London time again?
[17:00]  * lool needs to run to a phone call
[17:00] <dylan-m> Hey, highvoltage, I think your change for the Edubuntu installer slideshow is mostly new strings, with just five existing translations actually changed (not counting removals). Is that correct?
[17:01] <cjwatson> Laney: yeah, it's possible that this is an obsolete requirement
[17:02] <kees> Keybuk: no, tb moved to UTC about 6 months ago because it's not sane to tie it to anything else.
[17:03] <Keybuk> kees: well, if you and I agree on 11am, we have Quorum, so can just decide things by ourselves <g>
[17:03] <kees> Keybuk: heh I'm not sure "2" is enough, but it is UTC, and we did set it to 1800. :)
[17:04] <Keybuk> kees: 2 was always good enough in the old days ;-)
[17:04] <kees> heh
[17:05] <mvo> lool: its possible that a rebuild is needed, iirc is some of this inline code
[17:05] <juliank> lool: mvo: Yes, with a rebuild we get All -- but only on versions, on packages it remains the native architecture.
[17:06] <cjwatson> Keybuk: 2 was good enough when there were 4 board members :)
[17:06] <pitti> kees, Keybuk: FWIW, any earlier hour is greatly appreciated
[17:06] <pitti> so +1 for moving earlier
[17:06] <lool> mvo juliank: Would you like me to upload a nochange rebuild?
[17:06] <kees> pitti: let's discuss it with mdz and sabdfl; they had the tightest schedules.
[17:06] <Keybuk> I was going to say how much I liked 11am because it's further away from breakfast than previous times ;-)
[17:10] <mvo> lool: sure, thats fine, I can do it as well in a little bit
[17:11] <Keybuk> 9.30am is probably the earliest time I can guarantee attending though
[17:11] <mdz> kees, my understanding is that it's fixed to UTC
[17:11] <kees> I would prefer to keep it at 11am so when it moves back an hour I can still show up for it.
[17:11] <kees> mdz: yup.
[17:11] <mdz> and I plan to be there at 1900 BST during the summer here
[17:11] <hallyn> gah.  how do i unmark a bug as dup?
[17:11] <hallyn> phew
[17:11] <kees> hallyn: change it and delete the number
[17:11] <Keybuk> pitti: this isn't a "I don't like getting up early" restriction btw - this is a "FreeNode won't let me connect from G-Bus WiFi" problem
[17:11] <hallyn> kees: thx :)  i often fail to notice that little icon
[17:11] <kees> hallyn: yeah, took me a while to see it too
[17:15] <SpamapS> clint     2199  0.8 46.2 2932304 1866600 ?     Sl   Mar30  63:53 compiz
[17:15] <SpamapS> youch
[17:15] <SpamapS> clint     2199  0.8  3.7 650508 150088 ?       Sl   Mar30  63:56 compiz
[17:15] <SpamapS> heh.. post -HUP
[17:15] <juliank> mvo: Now we have a situation where two programs compiled against different apt versions have different results without an official API break. I don't really like that.
[17:16] <juliank> mvo: We should try to remove inline code as much as possible in apt 0.8.14
[17:16] <mdz> juliank, except where it kills performance of course ;-)
[17:16] <juliank> mdz: Actually, performance should be nearly identical between function calls and inlined code, as most of the time in apt is spent reading files on start
[17:16] <mdz> juliank, I notice performance in some other areas, at least on my Atom netbook
[17:16] <Keybuk> juliank: err
[17:16] <Keybuk> juliank: performance would be massively different between inlines and function calls
[17:16] <Keybuk> relative time spent in individual activities might not be affected so much, if the majority is I/O
[17:16] <Keybuk> but that's quite a different thing
[17:16] <mvo> for the resolver it does matter, for readng list file stuff not so much
[17:17] <Keybuk> and there are plenty of processors out there which *do* care about sheer number of operations and stack changes
[17:17] <mdz> Keybuk, yes, I assumed that was what juliank meant
[17:18] <juliank> Well, if we spent 1 second for initializing apt and then 100ms for processing data, it does not matter if we spent 200 ms instead.
[17:18] <lool> mvo, juliank: Uploaded; thanks
[17:19] <cjwatson> it's funny how ideas about performance stick around.  for ages I had a bit set that linking against additional libraries was bad on i386 because of register starvation; while actually this may be true for the *first* library, but once you've linked against libc it doesn't make a whole lot of difference :)
[17:19] <juliank> And a function to return an architecture name does not need inlining, as far as I know, it's not used in solvong
[17:19] <cjwatson> (unless you're openoffice or something and are linking against two zillion libraries)
[17:20] <sabdfl> kees, pitti, Keybuk, mdz: i fear i'm adding less and less value and making the schedule more and more complicated
[17:21] <Keybuk> juliank: it depends, if you do that 100ms ten times then it does matter
[17:21] <juliank> cjwatson: Another interesting performance thing is that gcc -O3 optimizes array accesses so badly, that using functions compiled with -O2 is much faster
[17:22] <Keybuk> optimisation such as inlining and replacement can turn that 1s back into 100ms or less
[17:22] <Keybuk> juliank: -O3 is slower than -O2 is almost a universally known truth about gcc (but less true as gcc gets better)
[17:22] <cjwatson> juliank: heh, interesting; I can't say I'm surprised about issues with -Ogentoo, mind you :-)
[17:22] <mdz> juliank, I completely agree that we should be able to remove problematic inlining without significantly affecting performance, and we should do that. :-)
[17:22] <Keybuk> cjwatson: I thought -Ogentoo was -O4
[17:22] <cjwatson> (OK, -Othelesscluefulofgentoousers)
[17:23] <Keybuk> because they were using -O4 when gcc only went up to 3 ;-)
[17:23] <mdz> I just didn't want to ignore performance completely, because I think some of the inlines may make a difference
[17:23] <cjwatson> Keybuk: I think that was -O6, but same deal
[17:23] <juliank> Keybuk: Yes. But code should not be inlined just because it is short, only if it is performance critical. In APT, many inline functions are not performance-critical
[17:23] <Keybuk> juliank: if they are not performance-critical, the compiler will probably ignore the "inline"
[17:23] <cjwatson> inlining: profile profile profile
[17:23] <cjwatson> (since excessive inlining can kill i-cache locality)
[17:23] <Keybuk> juliank: the "inline" keyword isn't so much of a rule as a guideline to the compiler
[17:24] <Keybuk> (at least I'm pretty sure that's true in C++ too, but I'm rusty and frankly the C++ standard scares me :p)
[17:24] <juliank> Keybuk: In short: Code should not be in the header file, but in the .cc file; unless it is extremely important for performance
[17:26] <mdz> juliank, +1
[17:26] <juliank> cjwatson: Doesn't gcc 4.6 have a new option called -Ofast or something like this?
[17:26] <mdz> juliank, and I'd add (with a nod to cjwatson) that means "we've measured it"
[17:36] <lasha> guys anyone knows good system cleanup tool? please help I need to know how to cleanup trash :|
[17:36] <SpamapS> lasha: #ubuntu would be a better place to ask
[17:36] <juliank> lasha: This is a development channel, not a support channel
[17:37] <lasha> hmm ok guys, I just had trouble getting answer there :)
[17:37] <lasha> how can i help in development though, I know java
[17:38] <highvoltage> dylan-m: the strings didn't really change, it was icons that somehow didn't get into the last merge. so now we just have placeholders for some images where it should be the proper icons
[17:38] <highvoltage> dylan-m: but string changes should be quite minimal, if any, yes
[17:40] <ogra_> lasha, https://wiki.ubuntu.com/ContributeToUbuntu
[17:41] <ogra_> and https://wiki.ubuntu.com/UbuntuDevelopment
[17:42] <dylan-m> highvoltage: Okay, thanks. Something fishy going on with my revision history, then; my diff says there were a bunch of changes in the new .pot file, but the (awesome as always) Spanish translation has just about everything…
[17:42] <dylan-m> I think it will all sort itself out when it gets uploaded :)
[17:42] <lasha> ok thank you ogra_
[17:42] <highvoltage> dylan-m: ok, great.
[17:43] <highvoltage> dylan-m: I'll test it as soon as it's in the archive, so if something isn't quite right there will be a little time to find it
[17:45] <lasha> ogra_ #ubuntu-beginners-dev hehehe :P
[17:48] <cjwatson> ogasawara: sorry for the delay.  done.
[17:48] <ogasawara> cjwatson: awesome, thanks
[17:49] <cjwatson> mvo: does https://code.launchpad.net/~evfool/update-manager/fix150677/+merge/55874 look OK to you?
[17:49] <cjwatson> (actually, there seem to be a few outstanding u-m branches from evfool)
[17:57] <cjwatson> kirkland: did you notice bug 700511?  it has a question directed at you
[18:04] <kirkland> cjwatson: i hadn't notice, i'll look at it now
[18:04] <kirkland> cjwatson: fwiw, hallyn is more or less maintaining that now
[18:04] <kirkland> hallyn: let's take a look at https://bugs.launchpad.net/ubuntu/+source/vgabios/+bug/700511
[18:08] <cjwatson> kirkland: *nod*
[18:09] <cjwatson> hallyn: (speaking of which, sorry for today's horrible kvm bug report ;-) )
[18:09] <hallyn> cjwatson: that is a bad one :)
[18:09] <hallyn> cjwatson: unfortunately libvirt looks likely to keep me occupied today
[18:09] <cjwatson> yeah, that's ok
[18:09] <hallyn> broken in every release
[18:28] <cjwatson> @pilot out
[18:44] <cdbs> Hello all, it appears someone tried to snatch control of my IRC account
[18:44] <cdbs> I can see some sent messages to this channel
[18:45] <cdbs> Anyone has a backlog? Sorry in advance
[18:45] <cdbs> sent messages means the attacker probably tried to send messages here in my name
[18:46] <Pici> cdbs: huh?
[18:46] <geser> http://irclogs.ubuntu.com/ has the logs of all logged Ubuntu channels
[18:46] <geser> cdbs: didn't you protect your nick or did someone guess your password?
[18:47] <cdbs> geser: Neither, it appears when I got disconnected and moved to cdbs_ someone connected with cdbs
[18:47] <cdbs> geser: Even without the NickServ password NickServ allowed him to come up with my nick
[18:47] <cdbs> and I can see myself banned from some non-Ubuntu channels
[18:48]  * cdbs moves discussion to -ops
[18:49] <geser> do you enforce identification with nickserv?
[18:49] <cdbs> geser: I just set that now
[18:49] <cdbs> wasn't set before
[18:50] <cdbs> okay, enough offtopic discussion on a -devel channel
[19:24] <SpamapS> pitti: remind me again, its ok for me to sponsor an upload to lucid-proposed and then review it for acceptance into lucid-proposed, right?
[19:25] <slangasek> SpamapS: there's no firm policy against it, but I've always tried to be arms-length about sponsor vs. SRU accept (or RM / archive admin accept)
[19:25] <slangasek> I guess it depends how much you trust that your eyeballs are sufficient :-)
[19:26]  * SpamapS is constantly suspicious of his eyeballs
[19:26] <Keybuk> are you saying there's something wrong with cowboying a package through NEW, and then straight into main? :-)
[19:26] <Keybuk> (yee-haw)\
[19:27] <SpamapS> slangasek: btw, I'd like to get back to the work of fixing Debian policy so we can start putting upstart jobs in debian packages. You sent me a checklist which I still have.. has the TODO changed any?
[19:28] <pitti> SpamapS: as slangasek said, there's no firm rule; I used to do sponsoring and SRU accepting for the same patch as well, though
[19:28] <pitti> (as both is pretty much "review that it's sane etc.")
[19:29] <pitti> Keybuk: don't we all? all this bureaucracy ... :)
[19:31] <slangasek> SpamapS: I don't have that todo list in front of me; the high level where-are-we is Debian bug #591791 against policy
[19:32] <slangasek> I think I may have done something from that list since then, but I don't remember what :)
[19:32] <slangasek> or maybe I just dreamt of doing something
[19:32] <SpamapS> I dream of a day where upstart jobs and debian developers live in harmony. ;)
[19:33] <SpamapS> slangasek: ty.. I'll take a look at the todo again and see if there's something I can get done in the early weeks of oneiric.
[19:33] <slangasek> yay
[19:33]  * cjwatson finds and kills another of the N reasons Wubi breaks for people
[19:33] <cjwatson> only N-1 to go
[19:34] <cjwatson> now if only I knew the value of N
[19:34] <Keybuk> cjwatson: since we're in an expanding universe, the value of N increases at the speed of light
[19:34] <Keybuk> so, kill faster
[19:35] <cjwatson> doh
[19:35] <mvo> cjwatson: indeed, I'm a bit behind there, I will go over the u-m branches now (or tomorow morning)
[19:37] <cjwatson> mvo: great, thanks
[19:38] <psusi> cjwatson: how about that new partman script hanging on my system problem now? ;)
[19:39] <cjwatson> I'm afraid I have my own to-do ordering
[19:39] <cjwatson> and all the other things on it are beta-critical too :-P
[19:39] <psusi> hehe
[19:39]  * psusi needs a shell debugger so he can step though that thing
[19:40] <cjwatson> set -x
[19:40] <psusi> hrm...  guess that's what I'llbe doing tonight...
[19:40] <cjwatson> hallyn_afk: any chance of you doing SRU verification on bug 687501?
[19:40] <cjwatson> (the lucid task)
[19:40] <cjwatson> I suppose I should backport that to maverick too :-/
[19:40] <hallyn_afk> cjwatson: i haven't got the hardware any more
[19:41] <cjwatson> drat
[19:41] <hallyn_afk> dannf: ^ any chance you'd hae time for that?
[19:41] <cjwatson> I'll try to track down Peter
[19:42] <dannf> hallyn_afk: i'll take a look
[19:43] <hallyn_afk> thanks!
[19:44] <cjwatson> looks like I did the maverick backport in a PPA but never uploaded it to -proposed
[19:45] <cjwatson> I'll rectify that now
[19:47] <dannf> cjwatson, hallyn: what exactly should i test - that upgrading to the proposed grub2 lets me install/reboot on an existing lucid/mpath system, or do i need to try something at installtime?
[19:47] <cjwatson> I think ideally we want to make sure that it handles fresh install correctly
[19:48] <cjwatson> it should be sufficient to put apt-setup/proposed=true on the kernel command line for a lucid netboot install
[19:48] <dannf> cool
[19:48] <dannf> yup - i can do that
[19:49] <cjwatson> maverick-proposed version uploaded now too, waiting for approval
[20:07] <hallyn> cjwatson: regarding bug 700551 - the patch in the patch in the patch doesn't apply :)  Is it safe to just add any of the modelines which it adds back into vbetables-gen.c, as far as you know?
[20:07] <hallyn> 700511 i guess
[20:09] <hallyn> eh, will assume it is
[20:26] <cjwatson> hallyn: not sure really, I was just being patch pilot
[20:27] <cjwatson> hallyn: I guess so though
[20:29] <hallyn> cjwatson: yup, building the package, will test.  thanks.
[20:30] <hallyn> here's a q - is there a good reason why 'bzr uncommit' doesn't remove any tags pointing to the commit being undone?
[20:30] <hallyn> oh, bc of looms or somesuch i suppose?
[20:33] <cjwatson> the revision still exists in the repository, and can be accessed again
[20:33] <cjwatson> in fact, you might still have another branch pointing to it
[20:33] <cjwatson> uncommit just winds back the current branch
[20:52] <ohsix> anyone have some pointers on debugging icedtea/appletviewer?
[20:53] <ohsix> been having lots of trouble with it lately; the applet uses native code though
[21:27] <SpamapS> @pilot out
[21:28] <SpamapS> oh noes.. no pilots! we're gonna crash!
[22:03] <ari-tczew> SpamapS: who cares :)
[22:08] <SpamapS> did we intentionally break runlevel 1 -> 2 transitions in the upstart conversion? Seems that many many upstart jobs 'stop on runlevel [!2345]' but do not start on runlevel [2345]
[22:19] <seb128> slangasek, hey
[22:20] <slangasek> seb128: hi there
[22:20] <seb128> slangasek, how are you?
[22:20] <slangasek> good! you? :-)
[22:20] <seb128> I'm fine thanks
[22:20] <slangasek> (what did I break? :-)
[22:20] <seb128> slangasek, does https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/751940 makes any sense to you?
[22:21] <slangasek> oh, cmake - yes, I broke that ;-)
[22:21] <seb128> slangasek, should I reassing to cmake? is there a known bug?
[22:21] <SpamapS> on purpose? :)
[22:21] <slangasek> SpamapS: in the sense that cmake consumers make buggy assumptions which multiarch will not tolerate, yes :-)
[22:22] <slangasek> seb128: whatever owns cmake/FindGTK2.cmake, yes
[22:22] <SpamapS> cmake and buggy builds seem to go hand in hand
[22:22] <slangasek> seb128: this ought to use pkg-config as the abstraction
[22:23] <seb128> slangasek, cmake-data says dpkg
[22:23] <slangasek> seb128: FindGTK2.cmake does appear to be part of cmake-data; I'll reassign with explanation
[22:23] <seb128> slangasek, thanks!
[22:27] <seb128> slangasek, bug #744910 btw might be yours as well
[22:28] <seb128> slangasek, well "yours" as a consequence of multiarch update
[22:28] <seb128> https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/743438
[22:28] <seb128> bah
[22:29] <seb128> bug #744910
[22:29] <seb128> slangasek, I'm pointed the duplicate on purpose since it has details
[22:29] <seb128> it has a patch as well which is wrong but shows where the issue is ;-)
[22:33] <lool> slangasek: One of the apt issue went away, but most regressions are still here sadly
[22:34] <lool> slangasek: I filed a new bug (LP #751961) to track them
[22:41] <Tetsuo55> pitti: hello, yofel told me to ask you about the retraces
[22:41] <Tetsuo55> pitti: most of the time retraces for my bug reports are too late (some update has occured and the trace fails)
[22:42] <Tetsuo55> pitti: isn't there anything we can do about this? it often takes a few days for the scan to occur so it will often fail this way
[22:42] <pitti> Tetsuo55: yeah, unfortunately the retracers break very often, it's quite a lot of maintenance
[22:42] <pitti> Tetsuo55: not much, I'm afraid
[22:43] <Tetsuo55> they seem to be critical for even taking the bug at all seriously
[22:45] <Tetsuo55> i have no idea how the retrace bots? work, but it would seem to me that if retraces are required to accept bug reports that canonical would invest more into making them faster and more stable?
[22:48] <yofel> pitti: how much work would it be to make  at least apport-cli able to retrace a crash before filing it? At least giving the option to refresh the attached stacktrace if you install more debugging symbols
[22:48] <yofel> or can you file bugs with apport-retrace?
[22:51] <pitti> yofel: you can not report the crash through the ui, then run apport-retrace locally on the .crash file, and then submit the updated .crash file through ubuntu-bug
[22:52] <pitti> it's not nicely integrated into the UI, but at least works
[22:52] <pitti> note that with apport-retrace it's rather easy to break your installed packages
[22:52] <pitti> it's mostly designed to work in chroots
[22:52] <yofel> ah ok, thanks
[22:53] <slangasek> seb128: waah, why does avahi have to use a non-portable database format (gdbm)
[22:54] <slangasek> maybe I should just roll back the multiarch change to avahi... it was only uploaded to natty by accident anyway
[22:57] <seb128> slangasek, I've no strong opinion either way but we should at least make sure it's reported upstream we will need that fixed next cycle
[22:57] <seb128> slangasek, btw do you have a tag or something to track multiarch issues?
[22:57] <slangasek> seb128: sure, I'm using 'multiarch'
[22:58] <seb128> slangasek, ok, that one just won this tag then ;-)
[22:58] <slangasek> thanks :)
[22:58] <seb128> thank *you* ;-)
[22:59] <slangasek> I think the quickest fix is to make python-avahi arch: any
[22:59] <slangasek> and properly populate the .py.in at build time
[22:59] <slangasek> so let's do that
[23:02] <micahg> slangasek: do you want me to get multiarch to be an official distro tag?
[23:03] <slangasek> micahg: that seems like a reasonable thing to do
[23:03] <micahg> ok, will bring up at the bugsquad meeting next week
[23:04] <slangasek> cheers :)
[23:05] <TheMuso> ogra_: oh sorry forgot about that URL. Got the email, thanks. Will take a look at those this morning.