[02:25] <nemo> *sigh*  who writes these depressingly wrong reviews in the Ubuntu Software Centre :(
[02:25] <nemo> In the past I had admired the ones we had for prior versions of Ubuntu...
[02:25] <nemo> http://m8y.org/hw/ubuntu.png
[02:26] <nemo> Well written, nice appreciation of the game, detailed
[02:26] <nemo> Sooo, I go to Ubuntu 12.04
[02:26] <nemo> And I get Brendon King saying that you should install and run it under Windows instead because it is a little more stable
[02:26] <nemo> Sooooooo totally wrong!
[02:26] <nemo> We have way more problems with our Windows users
[02:26] <nemo> Qt problems, OpenGL problems
[02:27] <nemo> It was only recently that we even managed to get fullscreen to *work* in windows
[02:27] <nemo> and we still have IFDEFs to work around issues
[02:27]  * nemo sighs
[02:27] <lifeless> well, $users :)
[02:27] <nemo> lifeless: so it *is* users? It isn't microsoft astroturfing spreading to top entries in your software centre?
[02:28] <nemo> lifeless: I wonder 'cause there's been increasing Microsoft astroturning on /.
[02:28] <nemo> Admittedly the SNR on /. is not great, but the astroturfing for major companies is kind of obvious.  Long posts that appear the instant an article goes up
[02:29] <nemo> eh. guess I'm being paranoid. still. sad.  hopefully quality of the reviews improves over time. I guess 12.04 has only been out for a month
[02:34] <lifeless> I think there is a voting system :)
[02:44] <nemo> lifeless: what I really want is a way to e-mail him to talk some sense
[02:45] <nemo> but unfortunately google wasn't forthcoming :)
[02:46] <nemo> lifeless: hm. something else I just noticed. total size on disc is totally wrong too
[02:47] <nemo> looks like it isn't including hedgewars-data
[02:47] <nemo> weird I thought it was correct before
[02:49] <nemo> 8.5MiB instead of closer to... 150MiB I guess - the ogg files really take up space
[02:50] <nemo> $ du -hs /usr/share/games/hedgewars/
[02:50] <nemo> 122M	/usr/share/games/hedgewars/
[02:50] <nemo> aaand 8.0M/usr/lib/hedgewars/
[02:50] <nemo> ok. just 130MiB - still :)
[02:54] <ion> Base-2 unit prefixes aren’t very useful for us humans. :-P
[03:07] <nemo> ion: eh? is all relative anyway. and 2^10 ~ 10^3
[03:08] <nemo> anyway. nowhere near 8½MiB :-p
[04:34] <pitti> Good morning
[04:39] <doko> you're late this morning ;p
[04:39] <pitti> hehe
[04:39] <pitti> doko: are you still in Taipei, or also up early?
[04:40] <doko> pitti, no Hongkong now
[04:40] <pitti> ah
[04:40] <pitti> doko: time for a quick python question?
[04:40] <doko> sure
[04:41] <pitti> doko: has it ever been discussed to provide a python version with --enable-valgrind?
[04:42] <pitti> doko: e. g. could we at least build -dbg with it, if the runtime check is considered unnecessary overhead?
[04:43] <pitti> without it, it's practically impossible to use valgrind to debug leaks in your extension, as python itself throws hundreds of those due to its own allocator
[04:43] <doko> pitti, afaik, no. sure, that sounds doable. otoh, I would like to know how much it slows down the execution
[04:43] <pitti> doko: I'm perfectly fine with only building -dbg with it
[04:44] <pitti> doko: it incurs an extra check if the program is running under valgrind (not much, but might cost a few thousand cycles), and an extra "if" check on a boolean for every object allocation
[04:45] <pitti> doko: do you know a standardized test for this? if not, I could just run the pygobject test suite with the two builds and compare the times
[04:45] <pitti> doko: so if that hasn't been discussed, I guess I'll open a bug and do some performance comparison; would you prefer a Debian or LP bug?
[04:46] <doko> pitti, let's do LP first. won't be for the next debian release anyway
[04:46] <pitti> no? ok
[04:48] <pitti> doko: danke
[05:39] <larsduesing> Guten Morgen - Good morning :-)
[07:06] <dholbach> good morning
[07:07] <mvo> ev: hey, good morning! is there a way for errors.ubuntu.com to show me only report for the "last-seen" version? the top bug there should be fixed with 5.2.2.1 and I would love to see a stacktrace from the 5.2.2.1 version (if its really not fixed there)
[07:07] <mvo> hey dholbach, good morning!
[07:08] <dholbach> hey mvo
[07:12] <ev> mvo: getting a stacktrace for a binary program for a specific version is impossible right now. We only ask for one per stacktrace address signature. However, it's definitely something to look at in the future.
[07:12] <ev> mvo: I could make it so clicking on the "last seen" version takes you to a report for that version. mpt, what do you think?
[07:12] <ev> mvo: we chatted about 5.2.2.1 last night. In precise, we still get reports from users where the running binary does not match the installed version (they upgraded while running). This is fixed in quantal (thanks pitti!) and being backported to precise.
[07:12] <pitti> I'm preparing the SRU right now
[07:13] <mvo> ev: oh, awsome
[07:13] <pitti> unfortunately someone else than me still needs to verify bug 989698, to unblock precise-proposed for apport
[07:13] <mvo> ev: yeah, it would rock to be able to click on the latest ver and get taken to the stracktrace
[07:13] <mvo> ev: and thanks pitti for this fix, that is a relief :)
[07:13]  * mvo was a bit worried about a overlooked case in this fix
[07:14] <pitti> mvo: actually, the fix only applies to signal crashes, not to Python stack traces -- is that a signal crash?
[07:14] <mvo> its a python stack trace
[07:14] <pitti> oh -- I'm afraid that's not fixed yet then
[07:15]  * mvo nods
[07:15] <pitti> just curious that people keep s-c open for such a long time
[07:16] <pitti> this fix was actually aimed at things like gnome-settings-daemon, which run all the time
[07:16] <pitti> and you might still have a 30 day old process running after upgrading twice in between
[07:16] <mvo> yeah, indeed
[07:17] <mvo> but for 5.2.2.1 the update is just 17h old, so that would explain why the frequency is still relatively high
[07:22] <didrocks> @pilot in
[07:26]  * dholbach hugs didrocks
[07:28]  * didrocks hugs dholbach back
[07:28] <dholbach> :)
[07:32] <dupondje> didrocks should join https://launchpad.net/~dholbach-huggers/+members :p
[07:33] <didrocks> dupondje: heh, kind of old good time ;)
[07:34] <sladen> hug mob Prague?
[07:36] <dholbach> :-)
[07:38] <sladen> the interweb provides:  http://www.youtube.com/watch?v=4jzGIaZcGcM
[08:33] <doko> micahg, ping
[08:37] <mvo> ev: errors.ubuntu.com is already collecting quantal crashes I assume, right?
[08:38] <mvo> ev: aha, unquestion, just found it I think
[08:39] <didrocks> jamespage: hey, FYI, https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/107908 has been resubmitted, I guess you directly want to take it upstream, isn't it?
[08:40]  * jamespage looks
[08:41] <jamespage> didrocks, wrong james - you want jodh :-)  but I agree that it should go upstream
[08:42] <jodh> didrocks: actually, no - mountall is a native package.
[08:44] <vibhav> Could anybody nominate https://bugs.launchpad.net/ubuntu/+source/shogun/+bug/1006039 for natty ?
[08:44] <pitti> that doesn't sound like a good SRU
[08:45] <vibhav> HAVE_ATLAS triggers <atlas/clapack.h>
[08:45] <vibhav> Which is in libatlas-dev
[08:46] <vibhav> pitti: why?
[08:46] <pitti> that's only necessary to build packages
[08:46] <xnox> because you can easily fix it by doing $ apt-get install libatlas-dev
[08:46] <pitti> and we won't start a mass rebuild in natty now
[08:47] <xnox> vibhav: is missing that dependency causing other SRU's to FTBFS? Has the dependency been removed in Natty, since Natty was released? (Regression)
[08:48] <pitti> if that was a problem, it would have come up by now
[08:48] <vibhav> But a program using HAVE_ATLAs could get this problem
[08:49] <pitti> again: trivial workaround, not a run time bug problem -> very far away from SRU criteria
[08:49] <pitti> it's not worth spending anyone's time on this really
[08:49] <jodh> didrocks: the mountall change looks good to me.
[08:49] <vibhav> fine, thanks
[08:53] <didrocks> jodh: do you want me to sponsor it?
[08:53] <didrocks> jamespage: sorry for the wrong ping :)
[08:53] <didrocks> hum, I can't push to lp:ubuntu/precise/qwt weird…
[08:53] <jamespage> didrocks, np :-)
[08:54] <pitti> didrocks: precise-proposed?
[08:56] <didrocks> ah, the branch name as well, yep, didn't notice thanks pitti
[08:56] <didrocks> pitti: can you mark https://code.launchpad.net/~l3on/ubuntu/oneiric/qwt/fix-921430/+merge/107534 and https://code.launchpad.net/~l3on/ubuntu/precise/qwt/fix-921430/+merge/107533 as merged or reject? I'll add a comment and push to the right branch
[08:58] <pitti> didrocks: done
[08:59] <didrocks> thanks pitti :)
[09:00] <didrocks> pitti: it seems to only have worked on the precise MR, not the oneiric one: https://code.launchpad.net/~l3on/ubuntu/oneiric/qwt/fix-921430/+merge/107534
[09:01] <pitti> didrocks: perhaps I mis-clicked; done
[09:01]  * didrocks hugs pitti
[09:03] <micahg> doko: pong
[09:07] <didrocks> pitti: can you reject as well https://code.launchpad.net/~gleichsnerd/ubuntu/precise/mountall/fix-for-805509/+merge/107908 please?
[09:07] <micahg> doko: I saw the E-Mail, I haven't gotten as far as a test build for Chromium 19 (having some issues with source generation), about to go to sleep, will try to have a look later toady
[09:07] <micahg> *today
[09:09] <jodh> didrocks: thanks for the offer, but I'd like to give that one a go if you don't mind?
[09:09] <jodh> didrocks: oh - is there a problem with that mp?
[09:10] <didrocks> jodh: no, I just merged into lp:ubuntu/mountall (it's your trunk, right?)
[09:10] <didrocks> jodh: the target is wrong: lp:ubuntu/precise/mountall
[09:10] <didrocks> jodh: but the manpage is now merged, I won't upload it and let you this pleasure ;)
[09:10] <jodh> didrocks: ah, right. thanks! :)
[09:11] <didrocks> yw ;)
[09:13] <pitti> didrocks: done
[09:26] <doko> micahg, ok, thanks
[09:26] <mpt> pitti, sorry to bother you with administrivia, but could you reset the slope lines on the quantal burndown charts? The current lines start from before most work items were approved.
[09:26] <mpt> (or tell me who I should badger about it instead:-)
[09:26] <pitti> mpt: I can't, sorry; I have no access to status.u.c.
[09:26] <pitti> mpt: cjohnston knows how the process works now
[09:27] <mpt> pitti, ok, thanks. Will bug 1002828 be similarly a configuration problem rather than a bug?
[09:27] <cjwatson> mpt: cjohnston told me that we'd do this at FeatureDefinitionFreeze; the release schedule says that's tomorrow
[09:28] <pitti> right, was just going to suggest taht
[09:28] <pitti> we should just trash the db
[09:28] <pitti> it's rather late in the cycle to do that, but better than starting with totally wrong WIs
[09:28] <mpt> I don't see anything wrong with the WIs, just with the slope lines
[09:29] <mpt> oh, if you mean start from a new zero date for Quantal
[09:29] <pitti> right
[09:29] <mpt> makes sense
[09:29] <pitti> well, trash the db so that we discard all the history
[09:30] <cjohnston> I'm slightly confused.. I'm trashing the quantal db for feature def freeze...
[09:30] <geser> do we get dpkg >= 1.16.2 for quantal?
[09:30] <cjohnston> I don't think doing that with precise will provide the desired output
[09:31] <cjohnston> The precise issue, I believe, is because we are still running the scripts for the precise release cycle
[09:31] <cjohnston> and so it picked up the further milestones
[09:31] <pitti> righth, that'll require some db surgery to remove again
[09:31] <cjohnston> we have to fix the process by which we run the scripts to where we arent doing all releases prior to doing anything with precise
[09:31] <micahg> geser: as soon as someone sorts out how to not break the world with the upgrade
[09:31] <pitti> and I think we can just stop this; it's taking many hours a day for little (or even negative) purpose
[09:32] <cjohnston> pitti: there are some backups, so I will maybe be able to figure out how to get back close to what it should be
[09:32] <cjohnston> pitti: the issue is because we want to be able to change the config files at will, IS wrote a script that pulls the bzr branch with the configs, then runs the all script
[09:33] <cjohnston> so the script needs to be rewritten to where the config files that it runs are defined somehow
[09:33] <pitti> right, the precise config should be renamed to .disabled or so
[09:33] <infinity> micahg: Not much to sort out except migrating dpkg.cfg multiarch configs to the New World Order...
[09:33] <cjohnston> that wouldnt have any effect on the site or the data that is already there pitti ?
[09:34]  * infinity wonders if he just volunteered to do this.
[09:34] <pitti> cjohnston: in addition to the db surgery
[09:34] <micahg> infinity: right, but someone has to do it (and I thought you already volunteered)
[09:34] <infinity> micahg: Oh, did I?  In that case, I should do that. :P
[09:34] <cjohnston> pitti: right.. but not a negative effect on the actual site as it sits today
[09:35] <cjohnston> if so, would you mind making that change to all of the config files in the branch except quantal and summit-2012?
[09:35] <penguin359> hello
[09:35] <infinity> geser: I guess the answer is that we get a new dpkg when I do the migration. :P
[09:35] <penguin359> I'm looking to work on an issue in network-manager, but I am getting lost in the various branches on launchpad.net
[09:36] <mpt> penguin359, cyphermox is the person to ask about that
[09:36] <cjwatson> infinity: *applause*
[09:36] <penguin359> It looks like lp:network-manager represents a branch of the upstream version
[09:38] <pitti> penguin359: if you want to work on the upstream branch, I recommend using http://cgit.freedesktop.org/NetworkManager/NetworkManager/ instead
[09:38] <pitti> penguin359: that way you can use format-patch for upstream submission, and have the current version
[09:38] <penguin359> pitti: no, it's a file only in Ubuntu.
[09:39] <penguin359> I'm trying to figure out what the packaging branch is
[09:39] <pitti> penguin359: if you want to work on the package, use "debcheckout network-manager" to get the right branch
[09:39] <pitti> penguin359: see Vcs-Bzr: field on apt-cache showsrc (that's what debcheckout uses)
[09:41] <cjohnston> pitti: are you ok with that?
[09:42] <pitti> cjohnston: you mean disabling all non-current files? sure, I think that's what I used to do back in the days
[09:42] <cjohnston> ok.. great.. thanks.. I'm off to dinner in a few minutes.. :-)
[09:44] <pitti> cjohnston: committed
[09:45] <cjohnston> thanks pitti
[09:45] <cjohnston> I'll try working with IS to see if there is a good db backup
[09:46] <cjohnston> any idea when the change happened so that I can try to find one after release but before the change that broke the charts?
[09:46] <pitti> I'd use the release date, April 28
[09:46] <pitti> cjohnston: i. e. end of april/may 1 or so would do fine
[09:46] <cjohnston> ok.. I don't think they are doing daily backups, so I'll look around but after that time..
[09:47] <pitti> if not, we can apply a little sql
[09:47] <cjohnston> :-)
[09:48] <cjohnston> I'd also be quite interested in seeing how much of a change there is to the update time
[09:50] <penguin359> Doesn't Vcs-Bzr: represent the most current version that is on it's way to become Quantal?  What would I checkout if I was working on a patch for Lucid that no longer applies in more recent Ubuntu releases?
[09:51] <infinity> penguin359: If in doubt, apt-get source on lucid.
[09:52] <infinity> penguin359: (There may or may not be lucid branches for everything, but the archive is authoritative regardless)
[09:54] <penguin359> I do regularly use apt-get source for modifying packages for my system, but that has always been for private use and hasn't involved source control.  I'm trying to better understand the various release patterns and branches now that I am working on patching a bug that might affect others in my situation.
[09:55] <penguin359> I can just produce a patch with that, but I recently tried using Bazaar and I got a disapproval mentioning that I applied it to the wrong branch.
[09:55] <didrocks> @pilot out
[09:56] <pitti> penguin359: we don't really have a good story for old stable branches so far; debdiffs should always work and be appreciated for sponsoring
[09:56] <pitti> penguin359: if you find someone who tells you "I won't sponsor that debdiff, do a branch instead", there's something wrong
[09:56] <pitti> (particularly for an SRU)
[09:57] <penguin359> ok, thankx
[10:01] <penguin359> Could you take a quick look at http://bit.ly/Kb5DpC and tell me what he's referring to as the packaging branch?
[10:02] <penguin359> I thought he meant lp:~network-manager/network-manager/ubuntu, but that looks like what I used in the first place
[10:03] <pitti> penguin359: yes, that comment seems wrong
[10:03] <pitti> penguin359: I suggest to ping cyphermox about it, that MP looks fine
[10:04] <penguin359> ok
[10:33] <infinity> ogra_: So, regarding f-k... If you're willing to clean up the mess, let's just sync it.
[10:33] <infinity> ogra_: But clean fast. :P
[10:33] <ogra_> well, i planned to at least have omap, ac100 and omap4 for A1 ...
[10:34] <ogra_> in the realese meeting we said arm is a nice to have for A1, so everything extra would be fine but missing it wouldnt be a disaster
[10:34] <infinity> Yeah, I wasn't sure we'd make the live switch by A1 anyway.
[10:34] <ogra_> i just dont want to inverst a minute in the old f-k after switching to live ... that would be waste
[10:34] <infinity> But syncing/merging f-k is a good first step.
[10:34] <ogra_> yeah
[10:35] <infinity> Alright.  Sync away, then.  I'll just become remarkably silent here in HK if it explodes. ;)
[10:35] <ogra_> k, i'll try to have it in by EOD
[10:35] <ogra_> HK uses quantal images ?
[10:35] <infinity> If you're just syncing, we can have it in by.. Now.
[10:35] <ogra_> well, i cant sync, can just file a bug :)
[10:35] <infinity> ogra_: No, I just mean that I'll ignore you when it breaks. ;)
[10:36] <infinity> ogra_: Sure you can.
[10:36] <ogra_> oh, thats fine ...
[10:36] <ogra_> i can ? you mean i can do more than running requestsync ?
[10:36]  * ogra_ wasnt aware 
[10:36] <infinity> ogra_: syncpackage --force -d unstable flash-kernel
[10:36] <ogra_> oh my
[10:36] <ogra_> how did i miss that
[10:37] <ogra_> oh, probably because i never use ubuntu-dev-tools :P
[10:37]  * ogra_ installs 
[10:37] <infinity> Pretty sure that works off of upload rights, not queue permissions.  You can tell me if I'm wrong. :P
[10:38] <cjwatson> You're correct.
[10:38] <cjwatson> ogra_: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html
[10:39] <ogra_> cjwatson, yeah, i remember having read that, but u-d-t has such a lot of messy deps i never use
[10:39] <infinity> Even with --no-install-recommends?
[10:39] <cjwatson> Meh, most of the heavy ones are Recommends.
[10:39] <infinity> I didn't think it was that bloated...
[10:39]  * infinity looks.
[10:39] <ogra_> 43M here
[10:39] <cjwatson> The Depends are sane enough.
[10:40] <ogra_> better than devscripts for sure
[10:40] <cjwatson> Mostly stuff you'd have on a development system (at least one with launchpadlib) anyway.
[10:40]  * ogra_ doesnt want an MTA on his ac100 ...
[10:40] <cjwatson> ubuntu-dev-tools Depends: devscripts ;-)
[10:40] <infinity> devscripts is also really lightweight with --no-install-recommends.
[10:40] <ogra_> argh !
[10:41] <ogra_> so let me install devscripts first omitting recommends
[10:41] <cjwatson> But yeah, with --no-install-recommends I wouldn't expect either to pull in an MTA.
[10:41] <ogra_> it wouldnt be that annoying if the apt option wouldnt be half a novel to type :)
[10:42] <infinity> It's muscle memory here.
[10:42] <ogra_> if it actually becomes muscle memory i would start using a config option
[10:42] <ogra_> ;)
[10:42] <ogra_> though we dont have the inverse of this option, do we ?
[10:42] <infinity> Nah, I like to try without the switch first, see what it wants, then do the opposite. :P
[10:43] <ogra_> heh
[10:43] <infinity> --install-recommends may well exist to invert configs.
[10:43] <cjwatson> It does seem like a good case for a short option.  I think -r is unused.
[10:43] <infinity> Dunno, never tried.
[10:43] <cjwatson> infinity: I think it does, yes.
[10:43] <cjwatson> cmdline/apt-get.cc:3464:      {0,"install-recommends","APT::Install-Recommends",CommandLine::Boolean},
[10:43] <ogra_> aha
[10:46] <ogra_> phew, what a changelog
[10:47] <geser> and there is also "apt-get install --fix-policy --install-recommends" to fix it afterwards
[10:47] <ogra_> heh, even more typing
[10:47] <Laney> and you can apt-get install foo bar- to negate a specific recommends
[10:48] <infinity> Laney: Or apt-get remove foo+ bar JUST TO CONFUSE YOURSELF.
[10:48] <ogra_> haha
[10:48] <Laney> that works?!?!?!
[10:49] <ogra_> anyway, time for an announcement mail, i wonder if ubuntu-devel is enough
[10:49] <infinity> ogra_: More than enough.
[10:49] <ogra_> k
[10:49] <infinity> ogra_: As is usually the case with such announces, the people who read it won't care, and the people who need to know won't read it. ;)
[10:50] <geser> Laney: of course that works, apt has super cow powers
[10:50] <ogra_> heh, indeed, i even doubt they are subscribed to u-d
[10:50] <ogra_> but at least i have something to point to if someone complains
[10:56] <xnox> ogra_: "But Mr Dent, the plans have been available in the local planning office for the last nine months."
[10:56] <xnox> -- Quotes From Hitchhiker's Guide To The Galaxy
[10:57]  * ogra_ has his towel 
[10:57] <ogra_> so dont panic ;)
[12:35] <dupondje> Hi, when do we create a -dbg package? Are there some defaults for this ?
[12:35] <hallyn> jdstrand: as far as you know is there anything under /proc/device-tree that qemu under libvirt shouldn't read?  (bug 1006149)
[12:35] <cjwatson> dupondje: It's up to each package.
[12:36] <cjwatson> dupondje: I'd recommend only doing so when the -dbg package is built in a different build pass with some different configure or compiler options.  Otherwise, the automatically-generated -dbgsym packages on ddebs.ubuntu.com are usually adequate.
[12:37] <dupondje> cjwatson: oh ok, didn't know there were auto-generated
[12:37] <dupondje> thats fine enough indeed
[12:42] <jdstrand> hallyn: no, I don't. the 'davis' porting machine has /proc/device-tree
[12:43] <jdstrand> hallyn: if libvirtd needs access to /roc/device-tree, that is fine, but the bug is asking for libvirt-qemu to be updated, which is every guest
[12:44] <jdstrand> hallyn: we have quite restricted files for guests, so I would prefer that only specific entries or limited globs to libvirt-qemu be added
[12:45] <jdstrand> hallyn: in other words, demonstrated denials
[12:45] <hallyn> jdstrand: ok, thanks
[12:48] <hallyn> i wonder if device-tree will ever show up on x86 (if not i guess this minimizes the worry at least a bit)
[12:49] <jdstrand> I doubt it. I see /proc/device-tree/openprom
[12:49] <jdstrand> but that is just a hunch
[14:09] <mterry> didrocks, heyo.  Can I bug you for a review of that quickly branch sometime this week?
[14:10] <mterry> pitti, does apt-cache rdepends not cover build-depends?
[14:21] <xnox> mterry: no. use reverse-depends from ubuntu-dev-tools
[14:21] <mterry> xnox, ah, thanks!
[14:24] <didrocks> mterry: yeah, it's in my TODO :)
[14:24] <didrocks> mterry: sorry, just had a meeting
[14:25] <mterry> didrocks, no probs!  thanks!
[14:25] <didrocks> mterry: probably tomorrow will be the day!
[14:37] <henrix> cjwatson: sorry to bother you again, but it looks like there are still some kernel pkgs in universe...
[14:38] <cjwatson> henrix: let me recheck
[14:38] <henrix> cjwatson: thanks
[14:38] <cjwatson> henrix: I can't find them - can you give me examples?
[14:38] <cjwatson> Or a list
[14:38] <henrix> cjwatson: 1 sec
[14:39] <henrix> cjwatson: for example: block-modules-3.0.0-21-generic-di 3.0.0-21.35~lucid1
[14:39] <henrix> cjwatson: you can have the complete list on bug #1005456
[14:39] <cjwatson> Oh, lucid
[14:40] <henrix> ah, right... yesterday i may have referred oneiric only :-/
[14:42] <cjwatson> henrix: Fixed, sorry about that
[14:42] <henrix> cjwatson: thanks a lot
[14:54] <bdmurray> pitti: where is the code for the pending-sru page?
[14:57] <cjwatson> bdmurray: sru-report in lp:ubuntu-archive-tools
[14:57] <cjwatson> In fact it says that in the HTML
[14:59] <bdmurray> cjwatson: heh, thanks
[15:02] <bdmurray> cjwatson: is there no API way to get the queue count?
[15:03] <cjwatson> >>> ubuntu = lp.distributions["ubuntu"]
[15:03] <cjwatson> >>> quantal = ubuntu.getSeries(name_or_version="quantal")
[15:03] <cjwatson> >>> len(quantal.getPackageUploads(status="New"))
[15:03] <cjwatson> 4
[15:03] <cjwatson> Like that you mean?
[15:10] <bdmurray> cjwatson: exactly, thanks
[15:11] <PaoloRotolo> Hi all!
[15:11] <cjwatson> bdmurray: wow, I had no idea it was screen-scraping that
[15:12] <bdmurray> cjwatson: I'll have a branch in a bit
[15:13] <bdmurray> cjwatson: the count also includes backports which I'd like to exclude
[15:14] <Laney> you can supply pocket too
[15:14] <cjwatson> bdmurray: hm, not sure about that, we should be able to process all the backports more or less immediately and if we aren't doing so that's kind of rubbish
[15:14] <cjwatson> separate table or something maybe?
[15:14] <bdmurray> but is the SRU report not backports report
[15:14] <cjwatson> true but we have so many reports as it is ...
[15:14]  * cjwatson isn't going to look at another one, realistically
[15:14] <bdmurray> okay, it should be easy to separate them out anyway
[15:15] <cjwatson> I dunno, it's kind of cheesy I know but it's handy
[15:59] <jdstrand> @pilot on
[15:59] <udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[15:59] <jdstrand> @pilot in
[16:07] <jamespage> doko, when you are around please could you review the openjdk-7 debdiff on bug 888129?
[16:08] <jamespage> I've tested it locally and it fixes this bug and bug 888123
[16:24] <stgraber> kees: heya, just noticed that hardening-includes uses readelf but doens't depend on binutils (lxc containers really don't contain much by default ;))
[16:25] <slangasek> why are you using hardening-includes without build-essential?
[16:26] <stgraber> for hardening-check
[16:26] <stgraber> I'm doing a quick sru verification of bug 986314
[16:26] <slangasek> ah
[16:26] <stgraber> and the test case uses hardening-check which I installed in my test container but failed because it tries to call readelf which I don't have :)
[16:54] <mterry> mvo, hello!  Got a moment to talk about "update-manager --no-update" ?
[17:03] <bdmurray> pitti: your precise apport -proposed upload doesn't mention bug 1002535 which is included in the changelog
[17:05] <mvo> mterry: I'm about to call it a day, is it urgent? could we do it tomorrow your morning maybe?
[17:06] <mterry> mvo, sure, no rush
[17:06] <mvo> thanks!
[17:08] <mvo> mterry: please ping me when you go online, I should be around and have time then
[17:09] <mterry> mvo, ok
[17:09] <mvo> ta
[17:11] <mterry> mpt, what is your opinion of the badge on the update-manager launcher icon that shows the number of updates?  The new design seems to de-emphasize the specific number elsewhere
[17:11] <mvo> mterry: no opinion, I'm fine killing it
[17:11] <mvo> mterry: if mpt thinks that is the right way forward
[17:12] <mterry> mvo, cool
[17:24] <slangasek> lool: timezones notwithstanding, would you be able to verify the correctness of my SRU change for bug #986183?
[18:06]  * xnox today I learned $ man dh-exec
[18:06] <slangasek> it's total crack, but it's tasty crack :)
[18:10] <seb128> slangasek, other SRU people: did you read my comment about emailed about the (new) SRU rules?
[18:10] <seb128> (that was yesterday)
[18:10] <slangasek> seb128: yes, I am drafting a mail
[18:10] <seb128> slangasek, thanks
[18:11] <seb128> slangasek, I got several other people a bit puzzled about the change again today, it will be good to have some public email out ;-)
[18:11] <slangasek> well
[18:11] <seb128> slangasek, will spare work on both sides
[18:11] <slangasek> it's a change to enforce the rules that were always documented
[18:11] <slangasek> so I'm not too sympathetic towards people not knowing these were the rules - but yes, a mail will save us all time in the end :)
[18:11] <seb128> slangasek, right, well the rules were not enforced for years so people are surprised that what they have been doing for ages get bounced back from one day to the next one
[18:12] <seb128> slangasek, I've to admit I prefer less paperwork, I liked better when we were focussed on getting things done rather than on writing but I guess we need a balance there ;-)
[18:14] <bdmurray> seb128: the test cases make the getting the verification done easier
[18:15] <seb128> bdmurray, right, the "[Stable Fix] section pointing out a minimal patch applicable to the stable version of the package" just doesn't make sense to me though for example
[18:15] <seb128> is that "attach the debdiff to the bug"?
[18:15] <seb128> if so it's weirdly formulated
[18:15] <slangasek> seb128: that section is going away
[18:15] <slangasek> as part of the mail I'm drafting :)
[18:15] <seb128> slangasek, well it's being asked on bugs which get commented on this week
[18:15] <slangasek> it is?
[18:15] <seb128> well the comment point to that wiki
[18:15] <seb128> https://wiki.ubuntu.com/StableReleaseUpdates
[18:15] <slangasek> well, yes
[18:16] <slangasek> but the comment doesn't say that you need to add that section, does it?
[18:16] <slangasek> I will fix the wiki and send out mail
[18:16] <seb128> let me read it again ;-)
[18:16] <bdmurray> and if the comment needs fixing after the email I'll fix it
[18:16] <seb128> " To be more succinct, make sure the bug description lists these
[18:16] <seb128> fields: "Impact, Dev Fix, Stable Fix, Regression Potential, Test case"."
[18:16] <seb128> slangasek, ^ that's what the comment says
[18:16] <seb128> so yes, it does
[18:16] <slangasek> ah
[18:16] <seb128> well those were comments from SpamapS
[18:17] <bdmurray> right and I don't think he made the UDS session where this change was discussed
[18:17] <slangasek> right
[18:17] <bdmurray> we should all be on the same page real soon now
[18:17] <seb128> slangasek, and to fair I've no clue wat to write in "stable fix" out of copying the diff inline ... good to know it's being addressed ;-)
[18:17] <slangasek> SpamapS: ^^ so we should probably brief you on the changes to ubuntu-sru, rather than you reading about it on ubuntu-devel-announce ;)
[18:17] <seb128> bdmurray, slangasek: thanks
[18:18] <seb128> it's a bit backward that those rules are randomly applied before the SRU team got the documentation updated
[18:18] <seb128> or its things together
[18:18] <seb128> seems a bit backward
[18:18] <seb128> doh, I already said that :p
[18:18] <seb128> well anyway enough on the topic from me, thanks for addressing the issues ;-)
[18:19] <SpamapS> slangasek: that would be great. :)
[18:19] <SpamapS> I'm just going by the wiki page. 
[18:20] <SpamapS> The dev/stable fix is only necessary if the bug has to be fixed in different ways.
[18:21] <SpamapS> I would love for there just to be a "Fix" section which just asks the developer fixing the issue to explain what their intended fix is.
[18:22] <slangasek> SpamapS: the changes are to drop the 'development fix' / 'stable fix' sections in favor of release tasks; clarify 'regression potential' so that it's focused on giving testers information about what parts of the package might warrant additional regression testing; relaxing the requirement for a distinct 'impact' header since this should be the bug description
[18:22] <slangasek> also, based on cjwatson's feedback, I think we're going to relax the requirement for uploader & verifier to be separate people, so long as there's a solid test case write-up
[18:23] <SpamapS> slangasek: Fantastic. So basically, everything that I use to make decisions, has been sprayed out to different parts instead of put in a succinct place in the description?
[18:23] <slangasek> this is mostly of concern to cjwatson due to the complexity of testing installer SRUs, but probably benefits SRUs for other packages too
[18:24] <slangasek> SpamapS: hmm, walk me through how these help you make decisions, please?  The SRU team members who were in the room didn't think these changes were a problem
[18:24] <SpamapS> The requirement for fixer/tester to be different has never been specified in strong wording anyway, so that part makes sense.
[18:24] <slangasek> indeed, most of the time we don't have this information *anyway* in SRU bug descriptios
[18:24] <SpamapS> slangasek: I use the fields to decide whether or not the diff is even worth looking at.
[18:25] <SpamapS> slangasek: low impact bugs with a poorly specified test case or high regression potential should be rejected.
[18:25] <slangasek> SpamapS: oh, I agree - and the test case is the one absolutely mandatory section
[18:25] <SpamapS> The description is often "It 'sploded when I poked it"
[18:26] <slangasek> the regression potential section, there was concern that having the uploader write this may often not be useful
[18:26] <SpamapS> Impact is clear, users affected by this will be in state X until the fix is made.
[18:26] <SpamapS> Really? I think thats the most useful field for me during SRU review.
[18:26] <slangasek> right - AIUI the agreement was that we would require clear bug descriptions, but not enforce an "impact" header
[18:27] <SpamapS> It helps me evaluate that the uploader actually understood the diff
[18:27] <slangasek> hmm
[18:27] <slangasek> so you find good [regression potential] sections being written?
[18:27] <SpamapS> slangasek: basically I don't want to have to understand *everything* about the package before I evaluate the diff .. all of those fields give me an idea of what the uploader is thinking.
[18:28] <slangasek> anyway, we're not proposing to drop that one
[18:28] <slangasek> merely clarifying the language to say that the *purpose* of the section is to give guidance for testers
[18:28] <SpamapS> Its also about making the uploader stop and think about it.
[18:28] <slangasek> agreed
[18:29] <SpamapS> If I stopped and started writing regression potential "Well I'm not really sure how many things use this API call but probably not many" .. I'd feel like an idiot and go figure out how many things make that call.
[18:29] <slangasek> I just think we get better results if we frame the question in terms of what areas should be focused on for regression-testing
[18:29] <slangasek> I've certainly seen SRUs where people claimed "regression potential: none"
[18:29] <SpamapS> hah yeah
[18:30] <SpamapS> so did nobody get my message to ubuntu-devel where I said I'm going to start holding people to these fields?
[18:30] <SpamapS> because that was like, 2 weeks ago and I basically said "I'm going to hold people to the standard that was mostly thrown away at UDS" ;)
[18:31] <SpamapS> hm I don't see it in the archives
[18:31] <slangasek> anyway, I think the net outcome here is that we should get better SRUs, by a combination of enforcing the requirements up front and trimming the fat from these requirements to focus on the things that aren't just paper-pushing (i.e., development fix/stable fix)
[18:31] <SpamapS> maybe it got eaten
[18:31] <slangasek> heh, apparently not ;)
[18:32] <slangasek> are you ok with dropping the development/stable fix sections?  I don't think it adds anything at all to have people write this up
[18:32] <slangasek> instead of having bug tasks
[18:34] <SpamapS> I am ok with folding them into one thing.
[18:34] <slangasek> why should there be a thing for it at all?
[18:34] <SpamapS> I'd still like for the bug to state clearly "The intended fix is X"
[18:34] <slangasek> well
[18:34] <SpamapS> so if the patch does something else, I can quickly reject and move on. ;)
[18:34] <slangasek> this hasn't been enforced in practice because there's not a consensus in the SRU team that this is useful
[18:35] <slangasek> I think we do have consensus that the other sections are useful
[18:36] <SpamapS> Basically, I think we need to crowd-source a lot of the "orienting yourself around the fix", rather than making the SRU team members grok every bit of every patch
[18:36] <Daviey> awesome.
[18:36] <SpamapS> Yes I *can* understand a debdiff without any of those fields
[18:36] <SpamapS> and I can sit and think about the regression potential
[18:36] <SpamapS> and even figure out a test case on my own
[18:36] <SpamapS> but there aren't many of us
[18:38] <SpamapS> slangasek: I wasn't available for the discussion, so I defer to those who hashed it out. I'm fine with the changes, but I think it will put a tiny bit of extra burden on the SRU team that is not necessary.
[18:38] <slangasek> dropping the 'regression potential' field is not on the table
[18:39] <slangasek> SpamapS: well, those who were in the room felt that this will *remove* burden from the SRU team compared to where we are today, because of the poor enforcement of the requirements to date... so I'm hoping to prove you wrong and show that we've found a good balance :)
[18:53] <SpamapS> slangasek: indeed, I think the only thing that actually needed to happen was just to enforce more.. but removing fields is fine
[19:04] <vsingh165> anyone here know how to branch to source without using bazaar?  I'm trying to fix a bug in Nautilus (#822993 in Launchpad), and bazaar is not grabbing the latest source (it's many versions behind).
[19:04] <vsingh165> I'm quite new to all this packaging stuff.
[19:05] <jtaylor> apt-get source nautilus?
[19:05] <jtaylor> or if for a different distro, pull-lp-source package distro
[19:05] <jtaylor> s/distro/series/
[19:06] <vsingh165> I'm working on precise...is there a way to force bazaar to get the latest source?
[19:06] <jtaylor> what are you currently trying?
[19:06] <jtaylor> bzr branch lp:ubuntu/nautilus should get the newest source
[19:07] <vsingh165> I'm trying just a simple bzr branch ubuntu:nautilus
[19:07] <vsingh165> but it's saying that it's out of date
[19:08] <micahg> vsingh165: http://package-import.ubuntu.com/status/nautilus.html#2012-02-17%2010:22:13.701084
[19:08] <vsingh165> micahg:  yes,  I saw that earlier and didn't know what to make of it.  I kind of wish there were non-bazaar bug fixing instructions on the wiki.
[19:09] <micahg> anyways, that's not the canonical branch for nautilus, it's https://code.launchpad.net/~ubuntu-desktop/nautilus/ubuntu
[19:09] <vsingh165> jtaylor: it's still fetching out of date.
[19:10] <micahg> vsingh165: you want debcheckout nautilus
[19:10]  * micahg wonders if that would DTRT even though
[19:11] <vsingh165> micahg:  so now I just use the ubuntu-desktop:nautilus branch?
[19:11]  * micahg has no idea if that'll work, but that's the branch for quantal
[19:11] <vsingh165> hmm let me try it.
[19:14] <vsingh165> that's not what I wanted...now I don't see any of the source files I got earlier using ubuntu:nautilus branch.
[19:16] <vsingh165> I wonder if I could just debcheckout and somehow add a diff to a bug.
[19:20] <kees> stgraber: ah! good catch, I'll fix that.
[19:21] <stgraber> kees: thanks
[19:21]  * kees wonders if it should dep on binutils or build-essential
[19:23] <stgraber> kees: well, for hardening-check I don't see a reason to have the rest of build-essential, though maybe there are other tools in there that do require build-essential
[19:23] <kees> hardening-check itself should be just the compilers. hardening-includes ... yeah, just binutils. cool. Will upload to unstable.
[19:25] <seb128> slangasek, SpamapS: reading the backlog, I would welcome one of you explain me what "regression potential" is supposed to be ... I basically use it as "it's a gtk upload, it can virtually break your entire desktop if the lib is broken"
[19:26] <seb128> slangasek, SpamapS: but I'm not sure it's an useful info in a SRU with 3 patches backported
[19:35] <jdstrand> james_w: hi! can you mark https://code.launchpad.net/~jtaylor/ubuntu/precise/python-tornado/CVE-2012-2374/+merge/106863 as done? (the fix was in a security update last week)
[19:38] <jtaylor> done ^
[19:43] <slangasek> seb128: what's most helpful is some analysis of what kinds of problems are likely to occur if there *is* a bug in the patch
[19:44] <jdstrand> jtaylor: thanks
[19:53] <bdmurray> slangasek: does this seem right for an re regarding update-grub failures?
[19:53] <bdmurray> ug_failure = 'User postinst hook script \[(/usr)?/sbin/updaate-grub\] exited with value [1-9]+'
[19:54] <hallyn> hey - i'm looking at bug 994212 . users who don't use /etc/network/interfaces have autofs failing to start, bc it starts on runlevel [2345].  Do we call that abuse, or is there a way to work around it?
[19:54] <soren> bdmurray: "updaate"
[19:54] <bdmurray> soren: thanks fixed when testing but not in code - odh
[19:55] <hallyn> is static-network-up emitted when networkmanager starts up a nic?  (i assume not)
[19:55] <hallyn> jodh: ^
[19:55] <stgraber> hallyn: no
[19:55] <stgraber> hallyn: with NM static-network-up is emitted when the loopback interface is up IIRC
[19:55] <hallyn> is anything?
[19:56] <soren> hallyn: Yes.
[19:56] <soren> net-device-up
[19:57] <soren> hallyn: NetworkManager calls /etc/network/if-up.d/*
[19:57] <soren> hallyn: See /etc/NetworkManager/dispatcher.d/01ifupdown
[19:57] <stgraber> hallyn: basically any time an ifup call is made, the ifupdown upstart script checks whether all "auto" interfaces defined in /etc/network/interfaces are up, if they are, then it sends static-network-up
[19:57] <stgraber> on a desktop system, the only interface you have in /etc/network/interfaces is the loopback interface, so as soon as the loopback is brought up, you should get static-network-up
[19:58] <slangasek> bdmurray: it won't match any failures when update-grub is triggered from the old /etc/kernel-pkg.conf, but that should never happen nowadays; it also won't catch cases of update-grub invocations from other maintainer scripts; but if there are any of those they're probably in the minority
[19:58] <stgraber> cjwatson: I'm told we're some interesting things in the TB mailing list queue, can you let them through?
[19:59] <hallyn> I dunno, maybe the bug is just that automount should adapt to a nics-go-up-and-down world
[20:00] <hallyn> soren: thanks, I guess I knew the base net-device-up, but was looking for a 'default route is up' signal
[20:00] <bdmurray> slangasek: ah, postrm makes sense too
[20:00] <hallyn> but really that doesn't seem like the right fix anyway
[20:00] <hallyn> do we have anyone babysitting automount?
[20:00] <slangasek> hallyn: well, provided that the bug isn't that the system is configured with user-level NM profiles (in which case you might have a circular dependency), yeah, it's probably autofs's problem
[20:00] <slangasek> we do not
[20:01] <slangasek> bdmurray: ah, sure
[20:03] <hallyn> ok, thanks
[20:19] <bdmurray> pitti: to be fair regarding apport and precise -proposed I think I fixed it and then reported the bug for precise
[20:20] <nemo> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/795038/comments/10 - "integrated menus in the titlebar"  - does that actually exist in 12.04 ?
[20:20] <cjwatson> stgraber: just the one after I'd ditched MP spam and actual spam, but yeah, moderated
[20:20] <larsduesing> jamespage: may I ask you for help with merging aiccu from debian-sid to ubuntu-quantal?
[20:21] <jamespage> larsduesing, sure
[20:21] <larsduesing> I tried it word for word after documentation: https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge/+merge/107823
[20:22] <larsduesing> but: in the ubuntu-bzr there are many file in directory .pc - which I do not think should be there...
[20:22] <larsduesing> files
[20:22] <larsduesing> (and merge killed them...)
[20:23] <cjwatson> presence of .pc is correct
[20:23] <larsduesing> ouch
[20:23] <cjwatson> (modulo design disagreements; but it's the intended behaviour right now)
[20:24] <larsduesing> so my merge is incorrect?
[20:24] <cjwatson> if you deleted .pc, then yes it is
[20:24] <larsduesing> I did not
[20:24] <larsduesing> but bzr merge did
[20:24] <larsduesing> apparently
[20:25] <larsduesing> i did bzr merge debianlp:sid/aiccu
[20:25] <geser> .pc/ is created/used by quilt
[20:26] <larsduesing> yes
[20:26] <cjwatson> ok, I'm not going to look this up on my phone.  but the intended invariant is that the bzr branch should match the result of creating a source package from that branch and then unpacking it (dpkg-source -x) somewhere else, including dotfiles, possibly excluding .bzr* differences
[20:26] <larsduesing> cjwatson: nobody asks you for wonders :-)
[20:26] <jamespage> larsduesing, if you apply all the quilt patches and add the .pc folder to bzr it should be OK
[20:27] <dobey> bzr merge removing the .pc makes sense to me
[20:27] <cjwatson> if it's a 3.0 (quilt) format package then it's possible you'll have to quilt push -a after the merge
[20:27] <jamespage> I think that when you bzr merge it unapplies the patches
[20:27] <jamespage> but does not re-apply them
[20:27] <larsduesing> Oh
[20:27] <jamespage> ah - I see we all think the same
[20:27] <cjwatson> dobey: I am aware that there are design disagreements here, but that's not helpful
[20:27] <dobey> right
[20:27] <dobey> cjwatson: i'm not arguing about the design disagreement issues :)
[20:28] <larsduesing> So the bzr-branches are fully patched.. *learn*
[20:28] <dobey> cjwatson: i think the patches get unapplied when merging in bzr, as jamespage said
[20:28] <cjwatson> it's a bug that bzr merge doesn't put the branch back into a state where you can commit something that can validly be merged
[20:28] <larsduesing> ok, so I kill that branch
[20:28] <larsduesing> do another merge
[20:28] <larsduesing> and qult push -a
[20:28] <dobey> cjwatson: but it does, unless it also deletes the patches themselves, which as i understand, it does not
[20:28] <slangasek> larsduesing: 'bzr merge' unapplies patches; you then need to 'QUILT_PATCHES=debian/patches quilt push -a'
[20:28] <larsduesing> and then bzr push
[20:28] <slangasek> then bzr add .pc/* .pc/*/*
[20:28] <cjwatson> my understanding of jelmer's changes was that they were supposed to cause merge to leave things as it found them
[20:29] <jamespage> larsduesing, I think that if you just apply the patches in the current branch and then re-push it will be OK
[20:29] <slangasek> (this is unfortunate and something to fix for this cycle)
[20:29] <cjwatson> i.e. unapplied if that's how things started, applied if that's how things started
[20:29] <larsduesing> Guys, I didn't want creating religious wars :-)
[20:29] <cjwatson> if it's not doing so, I think that's a bug, because it's misleading people
[20:30] <slangasek> I don't think there's any religious war here, just vehement agreement that there's a bug
[20:30] <cjwatson> the intent of that set of changes was to *reduce* confusion ...
[20:30] <jelmer> cjwatson: that is intention, if it doesn't do so that's definitely a bug
[20:30] <jelmer> *the
[20:30] <jelmer> I'd love to hear more about it :)
[20:30] <larsduesing> Fine, who's filing a bug against quilt, bzr or whatever is the bad guy? *g*
[20:31] <cjwatson> jelmer: maybe larsduesing can provide you with a test case then :)
[20:31] <dobey> jelmer: would the merge then fail, if the patches failed to apply against the newly merged changes?
[20:31] <slangasek> jelmer: right, there's definitely a bug then, because 'bzr merge' always leaves the quilt patches unapplied
[20:31] <slangasek> and then if you apply them by hand, it shows the .pc files from :other as removed + added :(
[20:31] <cjwatson> dobey: that's a conflict of some kind, surely - at least logically
[20:33] <larsduesing> if I would be an author, I should write a book "learing ubuntu-devel - pitfalls and super community" or such :)
[20:34]  * micahg would think that would make a nice appendix to the packaging guide
[20:34] <dobey> cjwatson: perhaps, but the workflow introduced, or rather, enforced, by such a behavior, doesn't seem logical to me. :)
[20:35] <larsduesing> Ahem, short questionaire: Anybody wants this merge as test-case?
[20:35] <cjwatson> dobey: given the on-disk format is quilt, I'm pretty sure I'd want it to stop and let me walk my way up the stack, whether that be presented in terms of raw quilt operations (which I'm quite happy with personally) or bzr looms or whatever
[20:35] <larsduesing> If not, I will do re-push with quilt in the same bzr-tree
[20:35] <jdstrand> @pilot out
[20:36] <cjwatson> larsduesing: you don't lose the test case - just remember the URLs and revision numbers of the branch you started with and the branch you attempted to merge in
[20:36] <cjwatson> the test case doesn't get invalidated by pushing more revision on top
[20:36] <cjwatson> *revisions
[20:36] <larsduesing> ah, yes... there was some sense for a versioning system *head->desk*
[20:36] <larsduesing> :)
[20:37] <dobey> s/remember/stick in the bug report/ :)
[20:38] <larsduesing> dobey: Whoever does this report - I don't think I'm deep enough in the problematic parts here :)
[20:40] <xnox> slangasek: cjwatson: larsduesing: my favourite bug in the new handling is 1.0 packages with quilt patches - bug 999586
[20:40] <dobey> larsduesing: well surely you can file a bug report about the problem you're seeing. you don't need to explain the deep technical parts or where the problem is exactly in code
[20:41] <dobey> larsduesing: you can file a bug against udd and just say "The patches are unapplied, but not reapplied, when i merge branch X into a local copy of branch Y."
[20:41] <larsduesing> dobey: My problem begins at against which package should I file a bug? quilt? bzr? bzr-builddeb?
[20:42] <jelmer> larsduesing: bzr-builddeb
[20:42] <larsduesing> ok
[20:42] <dobey> ah ok, that works. i was going to say udd :)
[20:43] <larsduesing> udd?
[20:43] <cjwatson> ubuntu distributed development
[20:43] <cjwatson> but jelmer's authoritative here
[20:44] <larsduesing> oh
[20:44] <larsduesing> https://bugs.launchpad.net/bugs/616791
[20:44] <hallyn> I suppose a hacky way to fix the automount bug woudl be to just make it 'start on runlevel [2345] or net-device-up', so it quietly restarts if it failed at runlevel 2
[20:54] <larsduesing> bug filed:
[20:54] <larsduesing> https://bugs.launchpad.net/bzr-builddeb/+bug/1006611
[21:02] <larsduesing> https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-sid-merge
[21:03] <larsduesing> it keeps telling review diff without .pc - but branch is with
[21:12] <cjohnston> pitti: we are able to go back to hourly status updates
[21:13] <cjohnston> skaet: ^
[21:20] <larsduesing> so, going to bed... <6 hours of sleep in front of me... Good night everyone, and thanks!
[21:22] <cyphermox> larsduesing: will review aiccu later on (or tomorrow morning my time), unless somebody beats me to it
[21:24] <david> may i speak with an ubuntu devoloper?
[21:24] <larsduesing> cyphermox: take your time... thanks
[21:24] <larsduesing> david: what's your problem? Here are divisions of developers :)
[21:25] <david> i am a visually impared user trying to use ubuntu 12.04
[21:26] <david> my problem is that the orca screen reader and magnifyer  is really no good
[21:26] <david> i was wondering if their was an easy way to get compiz enhanced zoom desktop to work in unity
[21:29] <larsduesing> david: A quick look says to me, in 12.04 this problem should be already fixed...
[21:30] <larsduesing> https://bugs.launchpad.net/unity/+bug/684925
[21:31] <david> thanks but i was wondering if maybe compiz config settings manager could be intigrated with ubuntu 12.10 or something
[21:32] <david> that way users like me would not have to go through a lot of trouble trying to get it working
[21:32] <cyphermox> david: I think you might to be filing bugs for each specific issue you're encountering, though I suspect that might be difficult
[21:32] <cyphermox> david: ccsm is evil, we explicitly want to avoid pointing people to it, because it's so easy to break your system with it
[21:33] <larsduesing> <- night :-)
[21:34] <david> um okay could ubuntu incorperate something like zoom desktop somewhere?
[21:34] <cyphermox> david: that would be something to bring up as a bug report ;)
[21:34] <cyphermox> david: or you might want to talk to TheMuso who knows a lot more about accessibility than I do; but I'm not sure if he's around just yet.
[21:34] <david> i don't know how to file bug reports without an application crashing
[21:35] <cyphermox> david: 'ubuntu-bug unity' or 'ubuntu-bug compiz' for this type of thing, I guess
[21:35]  * cyphermox has to log off
[21:36] <david> i'm even considering trying to call canonical about it
[21:37] <david> i'm currently running mint for the accessibility issues i've mentioned
[21:41] <david> really the only accessibility linux has is the gnome 3 magnifyer orca(sucks) and ccsm enhanced zoom desktop
[21:44] <Daviey> david: I'd suggest not calling canonical.. but the desktop manager would no doubt love to hear your feedback, jasoncwarner_ :)
[21:45] <david> where could i find him
[21:47] <Daviey> david: #ubuntu-desktop is probably best
[21:47] <david> k thanks
[21:54] <barry> dobey: still around?