[00:03] <broder> my parents always ask me to fix their google bugs. at least you can do something about those :-P
[00:04] <infinity> broder: Oh, my mom does that too.  And insists that I fix every broken spam filter around the world too.
[00:04] <Chipzz> in	
[00:04] <broder> hehe
[00:04] <Chipzz> argh
[00:04] <Chipzz> how do these chars even GET to irssi...
[00:05] <Chipzz> infinity: I'ld much rather have them unimpressed than them trying to get me to fix their windows tbh
[00:05] <StevenK> infinity: My mother used to work for a bank, and that experience seems to have completly turned her off computers, so I have no luck explaining what I do to her.
[00:06] <Chipzz> my parents (and a lot of other ppl I know) seem to think that just because I work in IT, I care about windows and/or care about fixing their windows
[00:06] <infinity> StevenK: I tried to explain "porting to other CPU architectures" to my parents once over dinner.
[00:06] <JontheEchidna> My dad is a software engineer, so unfortunately he knows what is in the realm of possibility to do :P
[00:06] <StevenK> infinity: Hahaha
[00:06] <infinity> StevenK: And, while that was painful enough, they asked me to try to explain it again a week later.  And a month after that.
[00:07] <JontheEchidna> He started using KDE because it was the DE most like CDE
[00:07] <Chipzz> JontheEchidna: "unfortunately" you say? :)
[00:07] <Chipzz> I would say "fortunately" :)
[00:07] <StevenK> infinity: Oh, that's dreadful. Absolutely hilarous, but dreadful. :-)
[00:08] <JontheEchidna> Chipzz: well, then he asks me to fix bugs that I can actually fix but maybe don't want to :P
[00:09] <JontheEchidna> It's the equivalent of the teenager problem of "parents finding your facebook profile" for software engineers ;-)
[00:09] <Chipzz> JontheEchidna: then again, he can fix his own windows. or that of your mother/other family ;P
[00:10] <JontheEchidna> He fixes my mother's Windows begrudgingly. If he had his way she would be using Linux too
[00:10] <JontheEchidna> especially since if something breaks around the time he fixes something else, he gets blamed :s
[00:10] <Chipzz> infinity: so.. why did you even bother in the first place if you knew they wouldn't get it? :)
[00:10] <Chipzz> making conversation? :)
[00:12] <infinity> Chipzz: They keep asking what I do for a living.
[00:12] <infinity> Chipzz: Over and over again.
[00:12] <infinity> Chipzz: As if, some day, it will stick.
[00:12] <infinity> Bless their luddite hearts.
[00:12] <StevenK> "I work with a bunch of hippies on this free software stuff." ?
[00:12] <Chipzz> infinity: explain it in simpler terms then? :)
[00:13] <infinity> I've tried simple.
[00:13] <infinity> And complicated.
[00:13] <infinity> And some in between.
[00:13] <Chipzz> "I'm trying to get firefox to work on your phone" ;)
[00:13] <infinity> They need TV shows about programmers.
[00:13] <StevenK> infinity: When I broke the news that I was joining Canonical to my mother her first answer was "Uh, when that finishes, will you go and get a real job?"
[00:13] <JontheEchidna> heh
[00:14] <infinity> It's not like my mother knows anything about the legal system either, but she's convinced she knows what my brother (a lawyer) does for a living because she watched Law & Order.
[00:14] <infinity> So, she doesn't ask him. :P
[00:16] <JontheEchidna> The company I work for provides board-level FPGA/DSP solutions, and I write development tools to aid developers with writing code for the boards.
[00:16] <JontheEchidna> It usually just gets described as "I write computer programs"
[00:17] <Chipzz> infinity: actually you may be rigt about the TV shows. like I mentioned earlier, if you mention you work in IT, the majority of the people will expect you to fix their stuff, even if you're say, a DBA
[00:17] <infinity> JontheEchidna: I'm sure Dick Wolf could make that into an entertaining plot for my parents.
[00:17] <StevenK> infinity: Have you tried having your parents watch The IT Crowd? :-P
[00:17] <infinity> StevenK: But I'm not a helpdesk monkey!
[00:18] <JontheEchidna> hehe
[00:18] <Chipzz> StevenK: you're not suggesting trying to turn infinity's parents on and off, are you? ;)
[00:18] <infinity> StevenK: (Even if I do bear a striking resemblance to Moss)
[00:18] <StevenK> Although thinking about it, that may make things worse ...
[00:18] <StevenK> "You hide under desks and plug things in, do you?!"
[00:18] <TheMuso> My mother and sister have some understanding of Linux and open source, my sister understanding more about distros etc, but my father is clueless about computers period.
[00:23] <stgraber> managed to get most of my family running Ubuntu, so sure I end up fixing their stuff but it's mostly interesting things to fix at least (where the last one in date was a weird kernel/NM ipv6 race condition, described by my grand-mother as "<wireless name> keeps showing up on my screen every 10 minutes")
[00:23] <stgraber> so as long as people don't break 12.04, I should be fine for a few years ;)
[00:34] <elky> My mother has submitted bug reports all by herself before. Do I win something?
[00:34] <cjwatson> The right to fix them?
[00:37] <elky> cjwatson, I recall one of them being about silly graphics cards that weren't intel, ati or nvidia. That gets fixed with fire aiui.
[00:48] <infinity> elky: People still make GPUs other than those 3?
[00:48] <elky> this was like 4 years ago now
[00:48] <infinity> (That's actually a half serious question. Other than all the players in the embedded market, I haven't seen a non-big-3 desktop video card in ages... Does VIA still make the S3 Savage stuff?)
[00:48] <elky> I would find what it was if launchpad wasn't insisting that she'd never reported bugs despite being able to find a different bug she reported.
[00:49] <elky> Ah yes, it was a VIA.
[00:49] <elky> And i never met one that didn't deserve to DIABCF
[00:58] <directhex> i had an SiS card as an undergrad.
[01:00] <RAOF> You sometimes find strange GPUs on server motherboards.
[01:01] <JontheEchidna> I got a VooDoo2 card for Christmas in 2000 (I was 8)
[01:01] <infinity> RAOF: I suspect that will finally be changing with Intel and AMD seeing the light about on-die graphics.
[01:01] <directhex> RAOF: oh, yeah, there's a modern trend towards really weird ones
[01:01] <infinity> RAOF: Though, it'll take a few CPU generations for them to realise they've seen it.
[01:25] <elky> infinity, https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/157941 VIA/S3G DeltaChrome IGP and approaching 5 years ago... so several generations
[01:26] <elky> i think the card had nothing to do with it though
[02:08] <cyphermox> @pilot out
[02:08] <cyphermox_> @pilot out
[03:28] <pitti> Good morning
[03:30] <ion> hi
[03:31] <stgraber> pitti: what, already? :) (I usually take you saying good morning as a sign that I should stop looking at IRC and think about getting some sleep)
[03:31] <pitti> stgraber: I got up with my wife today instead of taking another nap after the alarm clock
[03:31] <pitti> my brain started working and didn't let me sleep any more; silly invention, such a thing..
[03:32] <stgraber> hehe :)
[03:32] <StevenK> pitti: Bloody hell, I haven't even had lunch yet and you're up and on IRC.
[04:48] <digitalknight> hi all
[04:49] <digitalknight> I am a C and C++ developer with foundations in algorithms and distributed systems
[04:49] <digitalknight> I am really interested in contributing to ubuntu
[04:50] <digitalknight> Please let me know how I can proceed
[04:51] <ScottK> Find something that's broken and annoying you.  Figure out the fix and then attach the patch to the existing bug (or file a new one) and then subscribe ubuntu-sponsors to the bug and someone will look at getting the fix into Ubuntu.
[05:19] <larsduesing> good morning
[05:21] <larsduesing> please could anybody have a look at SRU: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 thanks :-)
[05:34]  * kees hugs infinity
[05:35]  * infinity blushes
[06:58] <kees> do uploads to quantal proposed not close LP bugs?
[06:59] <digitalknight> hi all
[06:59] <digitalknight> I am a C and C++ developer with knowledge of algorithms and distributed algorithms
[06:59] <digitalknight> Please let me know how can I contribute to Ubuntu
[07:01] <hyperair> digitalknight: didn't ScottK reply you earlier?
[07:01] <hyperair> 12:51:26 <ScottK> Find something that's broken and annoying you.  Figure out the fix and then attach the patch to the existing bug (or file a new one) and then subscribe ubuntu-sponsors to the bug and someone will look at getting the fix into Ubuntu.
[07:01] <digitalknight> hyperair, no,actually I went offline,so I could not read it
[07:01] <digitalknight> Thanks a lot for reiterating it
[07:02] <digitalknight> hyperair, Another thing,should I start off as a MOTU?
[07:03] <hyperair> digitalknight: you can't start off as a MOTU. you start off by contributing patches to bug reports, and once you've contributed enough and proven your level of technical expertise, you apply for MOTUship.
[07:03] <dholbach> good morning
[07:04] <digitalknight> hyperair, I meant,as a MOTU hopeful
[07:04] <hyperair> eh well, you can
[07:04] <digitalknight> hyperair,what exactly do MOTU hopefuls do?
[07:05] <hyperair> well the same things that MOTUs do, besides reviewing and uploading others' work.
[07:05] <hyperair> instead of uploading changes directly to the archive, you'll have to submit patches via launchpad and get a motu/core dev to upload them for you
[07:06] <digitalknight> hyperair, ok,and so eventually,I can try for core developer membership,right/
[07:07] <hyperair> yup
[07:07] <digitalknight> hyperair, right,thanks
[07:07] <digitalknight> I am associated with OSS already
[07:08] <digitalknight> I am a Google Summer Of Code 2012 student for PostgreSQL
[07:08] <digitalknight> I just want to contribute to Ubuntu also,because I love ir
[07:08] <hyperair> that's nice =)
[07:09] <digitalknight> hyperair, thanks,also,what kind of knowledge is required(apart from good knowledge of C)?
[07:10] <hyperair> well you eventually pick these up as you go along. it's easier for you to just jump straight in and learn fromthere
[07:10] <hyperair> i think there's a page on wiki.ubuntu.com about getting started
[07:11] <digitalknight> hyperair, okies,because,I do not have much knowledge of Operating Systems atm(I will be starting now)
[07:12] <hyperair> http://www.ubuntu.com/community/get-involved
[07:12] <hyperair> digitalknight: ^
[07:20] <smb> hallyn, no
[07:48] <sam-c> compare security 12.10 to 12.04 LTS??
[08:04] <josh____> Hello, Gtk.FileChooser dialog rightly picks an executable file but throws an error for non-executable files. How to solve this? Here is my code for this --> http://pastebin.com/yY2PVR3r
[08:32] <pitti> ogra_: the HDMI monitor bug with quantal/ti-omap4, would that be bug 1010423 or bug 1010009? or both?
[08:32] <pitti> gema: ^ FYI
[08:32] <gema> pitti: thanks!
[08:42] <gema> ogra_: ping
[08:44] <xnox> infinity: i gave my mom Ubuntu CD made her boot on the laptop setup wireless and open facebook / gmail. After that I said I work on making this CD. After she said "that doesn't look like much" I pointed out at thousands of things in the software centre, at which point she said "Oh, but surely that's impossible to do every 6 months"
[08:45] <xnox> infinity: non the less according to her I have been leaving in London for 6 six years, although I haven't yet lived in London. But that is a minor implementation detail.
[08:55] <vibhav> xnox: She could use only LTS versions?
[09:11] <cjwatson> kees: Not until they get copied into quantal.  Then the bugs get closed.
[09:14] <larsduesing> please could anybody have a look at SRU: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 thanks :-)
[09:16] <ogra_> gema, hello
[09:17] <gema> ogra_: you have been doing some arm testing this week, right?
[09:18] <ogra_> lots, yes, since we have live images now
[09:18] <ogra_> omap wasnt working at all (kernel issues) should be good with the new kernel
[09:18] <gema> ogra_: could you upload your results to the tracker, so that we can track the bugs and mark them as important, etc?
[09:18] <Sweetshark> quiz question to all the audience: so far I have seen bug 1017125 only on quantal -- with both gcc 4.6 and 4.7, but *not* on precise. Anyone having a hint on other toolchain changes that might cause this?
[09:18] <ogra_> omap4 was waiting for the new ubiquity and should be fine now as well
[10:31] <geser> Sweetshark: very wild guess: have your build-dependencies (c++ libs) been recompiled for your test with gcc-4.6 too in quantal? (see the thread about gcc-4.7, stl and c++ language version on ubuntu-devel)
[10:40] <Sweetshark> geser: no.
[10:41] <Sweetshark> geser: however, I see no external lib in the stack trace (not that that means anything ...)
[10:48] <Sweetshark> geser: thanks for the hint.
[11:01]  * ogra_ wonders if we changed something in frambuffer handling of the initrd recently ... looks like plymouth is broken on most of my arm installs (black screen until X)
[11:03] <larsduesing> After looking after bug https://bugs.launchpad.net/bzr-builddeb/+bug/1006611 and browsing through the source a little: Am I right, maybe it is only the wrong parameter quilt-tree-policy given to bzr merge?
[11:08] <xnox> larsduesing: nope. the quilt-tre-policy is correct. Due to the way bzr-builddeb operates the files in the .pc directory get new file-ids (equivalent of rm & add due to quilt pop; merge; quilt push)
[11:08] <xnox> larsduesing: hence the massive diff of everything removed & everything added back again
[11:10] <xnox> larsduesing: plus the merge proposal diff would be against old ubuntu, not debian. And all the removed & new patches will generate even bigger .pc dir diff
[11:20] <larsduesing> hmm... ok..
[11:20] <larsduesing> I'll trying to look after it
[11:21] <xnox> larsduesing: see also a related bug that I added in the comment, it's all the same code area
[11:23] <xnox> larsduesing: my guess is that when both trees get 'quilt pop -a' treatment the file-ids are not backed-up in anyway, such that 'quilt push -a' treatment generates brand new fileids different from either trees. But this does sound very odd....
[11:23]  * xnox is not a bzr dev, just a 'poweruser'
[11:24] <cjwatson> quilt pop/push wouldn't drop file IDs unless you commit in between
[11:24] <cjwatson> (haven't looked at the bug, just a drive-by comment)
[11:25] <xnox> cjwatson: hmm but there is merge tree in between. It fails horribly if the quilt patch introduces new files, you get malformed tree bzr exception
[11:26]  * xnox generally does ` quilt pop -f ` then
[11:28] <larsduesing> yes
[11:29] <larsduesing> there seems to be a much deeper problem in it...
[11:30] <xnox> yeap, the idea & code in bzr-builddeb is sensible on high level
[11:32] <larsduesing> any idea how to debug python-code which is run by "bzr merge"?
[11:34] <xnox> larsduesing: read/use bzr verbose & debug modes??....
[11:35] <larsduesing> oh.. maybe thats enough... yeah... thinking too deep :)
[11:50] <larsduesing> Ohh...
[11:50] <larsduesing> strange
[11:50] <larsduesing> bzr -Dmerge -Dfetch -Dhooks merge debianlp:sid/aiccu &>../bzr.log
[11:50] <larsduesing> does not give ANY debug-information...
[12:04] <cjwatson> Sweetshark: I can help you with using the API to work around bug 1018349 if you'd like
[12:04] <cjwatson> Sweetshark: Oh, except apparently I'm too late :-(
[12:05] <cjwatson> Could've saved you six hours of build time there
[12:06] <Sweetshark> cjwatson: :(
[12:06] <Sweetshark> cjwatson: what would be the workaround?
[12:06] <cjwatson> There's an API request you can make which is always asynchronous
[12:07] <Sweetshark> cjwatson: I dont mind the build time too much personally, but hugging the ressources is bad.
[12:07] <Sweetshark> cjwatson: k
[12:11] <cjwatson> Sweetshark: something like this (and I do have a work item somewhere to script this more generally): http://paste.ubuntu.com/1062452/
[12:13] <Sweetshark> cjwatson: saved, with try next time.
[12:13] <didrocks> cjwatson: I have something generic I made for the autopilot run (copying all content from one ppa to another), I just need to find it again somewhere ;)
[12:14] <cjwatson> didrocks: In my case it's part of the replace-archive-admin-shell-access spec, replacing the copy-package.py script that's part of Launchpad and requires direct DB access
[12:14] <didrocks> cjwatson: ah ok ;)
[12:15] <cjwatson> It'll be easy enough to translate, but I just want to make sure that it has all the options and checks done by the Launchpad version
[12:15] <cjwatson> Since then (after a few other bits of work) I can delete it from Launchpad with a clear conscience
[12:51] <hyperair> how does the software centre handle arch:all packages that depend upon an arch:i386 package on architectures that don't support i386?
[13:00] <roaksoax> jodh: ping
[13:04] <jodh> roaksoax: hi
[13:05] <roaksoax> jodh: howdy!! so I'm trying to run a daemon as a particular user/group
[13:05] <roaksoax> jodh: and added the stanzas setuid setgui however, it fails to start
[13:06] <roaksoax> jodh: if I only add setgid it does start, however, still runs as root, ideas?
[13:06] <roaksoax> http://paste.ubuntu.com/1062511/
[13:07] <jodh> roaksoax: it might be becuase HOME isn't set for the user. See if you can run celeryd as shown here: http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job
[13:07] <xnox> roaksoax: is /var/log/maas/ created and user accessible?
[13:09] <roaksoax> xnox: yep
[13:10] <roaksoax> jodh: that asks for root password
[13:12] <jodh> roaksoax: are you passing 'maas' at the very end?
[13:12] <roaksoax> jodh: yes
[13:12] <roaksoax> it asks for password
[13:12] <jodh> roaksoax: it should be asking for the 'maas' users password
[13:13] <roaksoax> jodh there's no password for the user
[13:14] <jodh> roaksoax: what does 'su -c date maas' do?
[13:15] <roaksoax> jodh: asks for password
[13:15] <roaksoax> jodh: http://pastebin.ubuntu.com/1062524/ --> that's how it was created
[13:19] <jodh> roaksoax: well you don't appear to have set a password for the user. That aside, what does /var/log/upstart/maas-celery.log show?
[13:25] <roaksoax> jodh: i think it might be because of this: [2012-06-27 09:24:03,468: WARNING/MainProcess] [Errno 13] Permission denied: '/run/maas-celeryd.pid'
[13:26] <roaksoax> jodh: yeah was that
[13:26] <roaksoax> jodh: so how can I effectively be able to have a pidfile
[13:27] <roaksoax> jodh: when running it as non-root. Simply create a /run/maas owned by 'maas'?
[13:27] <xnox> roaksoax: why do you need a pid?
[13:27] <jodh> roaksoax: yup.
[13:28] <xnox> roaksoax: but /run/maas should be created on each boot, as in the pre-start script
[13:29] <roaksoax> jodh: cool thanks
[13:29] <roaksoax> xnox: I know that :). Thanks though
[14:17] <kenvandine> @pilot in
[14:43] <mterry> kenvandine, ooh ooh, you're a pilot now?  can you review https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split/+merge/109209 ?
[14:43] <didrocks> mterry: well done :)
[14:44] <mterry> didrocks, :)
[14:44] <mterry> didrocks, I forgot that pilots existed
[14:44] <didrocks> mterry: yeah, this totally suits the case. I feel already sorry for kenvandine :)
[14:44] <seb128> didrocks, aren't you piloting as well today? ;-)
[14:45] <kenvandine> mterry, indeed :)
[14:45] <didrocks> seb128: yeah, but I'll switch my shift for tomorrow or friday
[14:45] <didrocks> seb128: noticing that I already spent hours on mterry's branches :)
[14:45] <seb128> didrocks, escaping mterry's reviews? ;-)
[14:45] <seb128> right
[14:45] <mterry> He did half  :)
[14:45] <didrocks> he's doing work, that's annoying! :)
[14:46] <kenvandine> mterry, pointers on what to look at for those tests?
[14:46] <mterry> kenvandine, the deja-dup tests?
[14:46] <kenvandine> yeah
[14:47] <kenvandine> mterry, it's weird... one of those tests in the scripts dir passes
[14:47] <kenvandine> but others fail
[14:48] <kenvandine> ** (/home/ken/src/deja-dup/simple-threshold/tests/runner/.libs/lt-runner:17750): WARNING **: runner.vala:193: Error string didn't match; expected (null), got Failed with an unknown error.
[14:49] <mterry> kenvandine, run a failing test like so:  DEJA_DUP_DEBUG=1 ./runner --verbose ../scripts/bad-hostname.test
[14:49] <mterry> should give enough info to figure out why
[14:50] <kenvandine> (MSG: DEBUG: DuplicityInstance.vala:557: duplicity (18336) exited with value 255
[14:50] <kenvandine> mterry, is that helpful?
[14:50] <mterry> mvo, I wanted to change update-manager's user-visible name in LP to "Software Updater" instead of "Update Manager", but you're the maintainer
[14:50] <mterry> kenvandine, can I have the whole thing in a pastebin?
[14:51] <kenvandine> http://paste.ubuntu.com/1062643/
[14:52] <mvo> mterry: let me fix that
[14:52] <mvo> mterry: its now ubuntu-core-dev
[14:52] <mterry> mvo, ah neat, thanks!
[14:53] <mterry> kenvandine, it's because "'--exclude=/storage/1/Downloads" got passed to the mock duplicity script and it wasn't expected
[14:53] <mterry> kenvandine, is that an exclude from your normal user?  (we shouldn't be seeing those)
[14:53]  * kenvandine checks
[14:54] <kenvandine> oh... ~/Downloads is a symlink
[14:54]  * kenvandine doesn't want to fill up his SSD
[14:57] <mterry> kenvandine, interesting...  that's a side effect of how deja-dup handles symlinks in the exclude list (it expands it out and includes both the source and the target)
[14:57] <mterry> kenvandine, let me see if I can make the mock smarter...
[14:57] <kenvandine> thx
[14:57] <mterry> kenvandine, in the meantime, there's that nice ubuntu-release-upgrader branch...  ;)
[14:58] <kenvandine> in the mean time i'll try to run the tests on another box, after reviewing the release upgrader
[15:02] <mterry> mvo, are there any consumers left for python-update-manager (as apposed to python3-update-manager)?
[15:04] <cjwatson> reverse-depends says no
[15:04] <cjwatson> It was fairly temporary I think
[15:04] <cjwatson> We do need to keep py2 compat in the release upgrader though
[15:04] <mterry> cjwatson, right, but I didn't know if there were any planned or 3rd parties that we knew would want it
[15:05] <cjwatson> The main thing we knew about in the time was in the Ubuntu archive (I forget exactly what it was) and has apparently been fixed
[15:05] <mterry> cjwatson, OK, you mean provide a python-distupgrade as well as python3-distupgrade, or something more intricate?
[15:05] <cjwatson> Oh, I think it was apturl
[15:05] <cjwatson> The upgrader probably needs to run with Python 2 when upgrading from precise and with Python 3 when upgrading from >=quantal
[15:05] <cjwatson> Which is going to be quite intricate in the dist-upgrade tarball
[15:06] <cjwatson> The tarball can't rely on python-distupgrade or python3-distupgrade packages
[15:07] <mterry> cjwatson, OK, sounds like a separate branch after we do the split
[15:07] <cjwatson> Providing your current branch doesn't break the upgrader from precise :)
[15:08] <cjwatson> So, presumably your main useful purpose in providing python3-distupgrade is that python3-update-manager needs to depend on it
[15:09] <cjwatson> As such, I don't think it will be terribly useful to build python-distupgrade
[15:09] <mterry> cjwatson, agreed, as long as we drop python-update-manager
[15:10] <mvo> yeah, the important part is that it does not break the release upgrader, if that is ensured I'm fine and I don't think there are any other users of it
[15:17] <kenvandine> mterry, your the king of refactoring!
[15:17] <cjwatson> mvo: Is command-not-found still busted?
[15:19] <mvo> cjwatson: unfortunately yes, I meant to just update it in the evening but wasn't aware that so much override_ magic is needed for a py3 package at this point and then I went to bed, sorry for that
[15:20] <cjwatson> Oh, I've dealt with that before.  Want me to finish it?
[15:20] <cjwatson> I can just copy stuff from germinate or so
[15:30] <hippiehacker> https://gist.github.com/3004812 # a question regarding metapackages and dependencies, 'apt-get install -y ubuntu-virt-mgmt ; apt-get autoremove -y ubuntu-virt-mgmt' leaves behind the dependencies but 'apt-get install -y virt-manager ; apt-get autoremove -y virt-manager' removes it's dependencies... both are metapackages
[15:30] <hippiehacker>  can anyone explain the difference in behavior between the two metapackages? (one does depend on the other, but removing the higher dependency should remove both right?
[15:47] <apw> TheMuso, i want to confirm that I have the right config options tweaked for lowlatency, do you have a list of the key changes, from the session I recall it being CONFIG_PREEMPT and HZ=1000 basically
[15:48] <kenvandine> mterry, in the ubuntu-release-upgrader split merge proposal
[15:48] <kenvandine> [15:49] <mterry> kenvandine, yeah
[15:49] <cjwatson> That's a Python 2 path
[15:49] <cjwatson> Um, be kind of careful there
[15:49] <hallyn> RAOF: bug 231060, stgraber mentions you both agreed it was ok for sru, if you agree can you comment in the bug?  (I'll fix the postrm bitof course)
[15:49] <kenvandine> mterry, and i don't have that...
[15:50] <cjwatson> It's only in python-update-manager
[15:50] <kenvandine> and that is temporary right?
[15:50] <cjwatson> Indeed
[15:50] <mterry> hm
[15:50] <cjwatson> Maybe link to /usr/lib/python3/dist-packages/UpdateManager/Core/MetaRelease.py instead
[15:50] <cjwatson> But really this ought to be solved some other way than symlinking to system files from the source package
[15:50] <mterry> Maybe better to fix the imports
[15:51] <kenvandine> mterry, yeah
[15:51] <cjwatson> Like having a vaguely rational hierarchy of modules
[15:51]  * kenvandine comments on MP
[15:51]  * mterry was just trying to have as little changes as possible, but that's a good reason to change it
[15:51] <cjwatson> Same goes for the other symlinks to pyshared
[15:52] <kenvandine> mterry, sorry... make sure you ping me when you need another review
[15:53] <kenvandine> i spent a fair bit of time on this already so finishing it off won't be hard
[15:53] <mterry> kenvandine, k
[16:01] <mterry> cjwatson, do you know why these symlinks were used in the first place?  Are they part of how the release upgrader tarball works?
[16:02] <cjwatson> You need mvo really
[16:02] <mterry> mvo, I summon thee
[16:03] <cjwatson> The dist-upgrade tarball does need to be pretty much self-contained
[16:03] <dobey> mterry, kenvandine: why arey ou symlinking it anyway?
[16:03] <cjwatson> But to me this rather feels like modules being in the wrong hierarchy
[16:03] <mterry> dobey, that's what we're trying to figure out
[16:03] <dobey> ah
[16:03] <hippiehacker> vanhoof: you around?
[16:03] <cjwatson> UpdateManager should be importing from DistUpgrade, I think, not the other way round
[16:04] <mterry> Yeah, but some of the links seem obviously odd, like symlinking to apt-clone or sourceslist.  that's not updat-emanager related
[16:04] <cjwatson> Although I'm less sure about UpdateManager.Core
[16:04] <cjwatson> I would skip those for now if I were you, and concentrate on the DU/UM cross-imports
[16:04] <cjwatson> Those other ones are generally in order to ship newer versions of some modules because the ones in older releases were broken in some way
[16:04] <cjwatson> Or unavailable
[16:05] <cjwatson> (Note that a symlink in the source tree turns into a real file in the dist-upgrade tarball, mostly)
[16:06] <cjwatson> In order to work out whether we can get rid of those other symlinks, we need to know whether the version shipped in any version of Ubuntu we might be upgrading from is (a) guaranteed to be installed when dist-upgrading, (b) sufficient to support the dist-upgrader's needs
[16:06] <vanhoof> hippiehacker: I am but on a call atm
[16:08] <hippiehacker> vanhoof: np just wanted to catch up at some point
[16:09] <vanhoof> hippiehacker: shoot me a mail or /msg, should be off in an hour or so
[16:20] <mterry> kenvandine, ok, updated the branch
[16:23] <lifeng> hi all, I am the maintainer of root-system package in Debian. http://packages.qa.debian.org/r/root-system.html
[16:23] <lifeng> The current version cannot be built on ubuntu due to build-dep unmet, however, I fixed this issue in git-repo of Debian packaging stuff, is it possible for ubuntu to import the package from git-repo?
[16:25] <bdmurray> bryceh: having been subscribed to the regression- tagged bugs for a few days now it seems like the xorg package hook is creating quite some false positives
[16:25] <bdmurray> slangasek: would you agree?
[16:25] <bryceh> bdmurray, ok
[16:27] <slangasek> yes, very much so
[16:27] <bdmurray> one issue might be presenting the question during the development of the release
[16:28] <bdmurray> like in quantal now don't tag it regression-update
[16:30] <bryceh> bdmurray, what tag should it use in that case?
[16:31] <bdmurray> bryceh: regression-release if it happened between P and Q
[16:31] <bdmurray> I suppose I could write something to remove regression-update from all bugs reported about P before 2012-04-whatever
[16:32] <bryceh> actually wait, looking at the logic, the question leading to the 'regression-update' tag *only* gets asked if the distro version is "Supported" or "Current Stable Release"
[16:33] <bryceh> if it's "Active Development" (as in quantal) it doesn't ask about software updates
[16:33] <bryceh> bdmurray, so, that should be zero bugs
[16:34] <bdmurray> oh, that's good
[16:34] <slangasek> bryceh: hmm?  because people don't file bugs against stable releases?
[16:36] <bdmurray> bryceh: it still seems to generate quite a few false positives though
[16:36] <bryceh> bdmurray, can you show me a couple examples?
[16:37] <bryceh> bdmurray, could it just be user confusion?
[16:38] <slangasek> there are also a large number of unity-specific ones; I don't know if that's related to a specific script, or some sort of unity bug filing documentation?
[16:38] <slangasek> (I think it's unlikely to be random user confusion)
[16:38] <kenvandine> mterry, thx
[16:39] <bryceh> slangasek, compiz uses the xorg apport hook, and I think unity redirects to compiz for some issues
[16:39] <slangasek> bryceh: so it sounds like this script /is/ related to the large number of false positives, then?
[16:39] <bdmurray> bug 888872
[16:40] <slangasek> bug #876745
[16:40] <bdmurray> bug 908161
[16:41] <bryceh> if the bugs have GraphicsCard defined, that's something only the xorg apport hook adds, so that's a way to tell.
[16:42] <bryceh> so, yeah, I think I know what may be happening
[16:42] <bryceh> I think it is indeed user confusion
[16:43] <slangasek> the current hook's question is "The problem began right after system software update"
[16:44] <slangasek> mapping that to regression-update is wrong; I don't think that's user confusion
[16:44] <slangasek> the user is answering honestly, but it's setting a tag that's problematic
[16:44] <bdmurray> earlier in the hook we can see a tag of just regression added in some cases
[16:45] <bdmurray> maybe that would work?
[16:45]  * bryceh shrugs
[16:45] <bryceh> yeah if you'd prefer that, it's fine by me
[16:45] <slangasek> the problem is that most of these users are truthfully answering that yes, it happened after a system update... but that system update was a dist-upgrade from one release to the next
[16:46] <slangasek> so yeah, I think it's better to just use 'regression' here
[16:46] <bryceh> slangasek, I would call that user confusion
[16:46] <bdmurray> then those will be modified to regression-release or regression-update as appropriate
[16:46] <bryceh> maybe honest user confusion :-)
[16:47] <bryceh> bdmurray, I'll just eliminate the question
[16:49] <bdmurray> bryceh: okay, I'm sure the SRU team would be happy to review SRUs for this ;-)
[16:51] <bryceh> bdmurray, I wish they would be.  I already have an SRU filed (and confirmed) for this exact dialog, that still hasn't gone out :-(
[16:51] <bryceh> in fact, that fix might solve this issue... hmm
[16:51] <slangasek> bryceh: how do you mean, hasn't gone out?  There's an SRU of xdiagnose in -proposed that has one bug awaiting verification?
[16:52] <bryceh> slangasek, what bug is waiting?
[16:52] <slangasek> (bug #1009971)
[16:52] <slangasek> oh
[16:52] <slangasek> it's a duplicate of one that has been verified
[16:52] <slangasek> ok, publishing then ;)
[16:52] <bryceh> that got verified like a week ago
[16:55] <kenvandine> mterry, back at you :)
[16:56] <bdmurray> slangasek: does the sru report need another improvement?
[16:57] <slangasek> bdmurray: well, this particular bug was marked already as a duplicate when the package was accepted into precise-proposed... I think we need to be more diligent about checking such things
[16:57] <slangasek> so maybe that's an enhancement for queuediff
[16:57] <cjwatson> My experience has been that I'm reluctant to bounce things for tweaking bug numbers, particularly if the upload has been there for a while
[16:57] <slangasek> that reminds me, I still need to reupload update-manager, whose changelog references a private bug :-P
[16:58] <slangasek> cjwatson: bdmurray has convinced me that it's better for us to just fix them up ourselves and reupload
[16:58] <cjwatson> I'd rather that (a) the SRU report should be able to chase such references if possible (b) there should be some override mechanism that doesn't require a reupload
[16:58] <cjwatson> ourselves, as in the SRU team?
[16:58] <slangasek> cjwatson: yeah
[16:58] <cjwatson> Hm, I suppose that's workable
[16:58] <bdmurray> I don't remember trying to hard to convince you
[16:58] <cjwatson> Though it does require pushing stuff back to revision control, often
[16:59] <cjwatson> Kind of tedious for say the kernel
[16:59] <slangasek> and in cases like update-manager, the changelog is wrong and needs to be fixed because it references private bugs
[16:59] <cjwatson> (Which is a case where I'm particularly reluctant to reupload because it's generally already been built in a PPA by the time it gets to us)
[16:59] <slangasek> cjwatson: right... though the kernel is a special case where we really just care about the tracking bugs
[16:59] <slangasek> bdmurray: it didn't take much convincing ;)
[16:59] <cjwatson> Yes, and there have been cases where the tracking bugs are missing :-)
[16:59] <cjwatson> It'd be nice to have an override file for such things
[17:02] <slangasek> cjwatson: ah, heh
[17:03] <cjwatson> Or there was a recent cups SRU where some of the bugs turned out to be unrelated to the SRU and Till tried to "disconnect" them after the fact
[17:03] <cjwatson> Which was sort of OK I guess but very confusing, and if I hadn't been processing it all at one go it would have been hard to keep track
[17:04] <cjwatson> A way to tell sru-report "no, just forget about that one" would have helped
[17:04] <cjwatson> (Till would still have had to reopen the bugs after the janitor closed them on moving to -updates, but not much to be done about that)
[17:22] <bryceh> bdmurray, alrighty, regression-update removed.  Do you want to file the sru bug for this?
[17:25] <bdmurray> bryceh: okay
[17:27] <bryceh> while I'm at it I'll fix one other question that's been ambiguous
[17:31] <bdmurray> bryceh: bug 1018510
[17:32] <bryceh> bdmurray, thanks
[17:32] <bdmurray> thank you
[17:35] <bryceh> your welcome, hopefully you can find some other way to identify update regressions in X/compiz/unity bugs
[17:55] <bryceh> bdmurray, don't forget to add a test case, etc. to the bug.  I've subbed ubuntu-sru
[18:12] <black_joe> http://pastebin.com/VDeZnR5T Apparently debuild doesn't like my rules file. Does anyone know how to let it just brush over the rules? I have a separate make / install file. (First time packaging)
[18:17] <infinity> black_joe: Why mix-and-match cdbs and dh7 that way?
[18:18] <infinity> black_joe: I bet if you drop the two includes (and stop using cdbs entirely), that'll Just Work.
[18:18] <black_joe> Okay. I will try that.
[18:19] <black_joe> I removed the includes, but what do you mean by "cdbs"?
[18:19] <infinity> black_joe: If you don't know what cdbs is, you didn't want the includes. ;)
[18:20] <black_joe> I just put them in to try to silence other errors. But I think they were cuased by something else.
[18:20] <black_joe> (I actually copied most of this from gedit's rules)
[18:21] <infinity> black_joe: Ahh.  Instead of cargo-culting from other packages, you might try installing dh-make and running "dh_make" in a clean unpacked source tree.
[18:21] <infinity> black_joe: You'll get a dreadfully simple debian/* to tweak.
[18:21] <black_joe> Yeah. The errors have returned. http://pastebin.com/4R3J4XMu
[18:21] <infinity> black_joe: Also, most of this probably belongs in #ubuntu-motu or something.
[18:21] <black_joe> I can try dh_make instead.
[18:22] <black_joe> Probably. This was the most related channel I saw when I scanned over freenode though.
[18:22] <black_joe> I'll try dh_make then go there. Thanks.
[18:26] <slangasek> infinity: per resolution 698.1, §5.2, subsection B, packaging questions are now equally on topic for both channels
[18:27] <infinity> slangasek: Coffee, laptop, narrow miss, nearly had to email you a bill.
[18:29] <kenvandine> mterry, see my last comment on the ubuntu-release-upgrader split MP?
[18:29] <mterry> kenvandine, yeah, it prompted a rabbit hole of looking at the tests
[18:29] <kenvandine> haha :)
[18:29] <kenvandine> ok
[18:29] <mterry> kenvandine, about to fix an unrelated-to-my-branch test problem and upload
[18:29] <kenvandine> i approved your other deja-dup branch :)
[18:30] <mterry> kenvandine, I'm going to leave the pyflakes test alone for now.  that can be fixed post-merge
[18:30] <kenvandine> ok
[18:30] <mterry> kenvandine, oh cool.  I was halfway to figuring out how to make that work well for your weird symlink case  :)
[18:30] <kenvandine> well, would be good to handle that :)
[18:30] <kenvandine> i just ran the tests on my laptop
[18:31] <kenvandine> @pilot out
[18:32] <mterry> kenvandine, guh, the thing I thought would fix this error isn't.  I'm just pushing as is, it's not caused by my branch
[18:32] <kenvandine> ok
[18:32] <mterry> kenvandine, so the tests that I expect to still fail are pyflakes and quirks
[18:32] <mterry> kenvandine, branch updated
[18:32]  * kenvandine tests
[18:39] <kenvandine> mterry, test_end_of_life.py fails for me with python3
[18:39] <kenvandine> am i just missing a depends?
[18:41] <kenvandine> mterry, it's an import error, no module named Dialogs
[18:41] <mterry> kenvandine, ah yes...  that's because Dialogs is from update-manager trunk
[18:41] <kenvandine> ok
[18:41] <kenvandine> i'll ignore that one then :)
[18:46] <kenvandine> mterry, the pyflakes test pass here :)
[18:47] <mterry> kenvandine, really?  hmm
[18:48] <kenvandine> quirks test pass with python3
[18:48] <kenvandine> but not 2.7
[18:48] <mterry> kenvandine, ah yeah, my flakes errors are from leftover built code in debian/
[18:49] <mterry> kenvandine, yeah.  I didn't figure out why we are getting a unicode conversion error in 2.7 at a certain point
[18:52] <kenvandine> mterry, approved :)
[18:53] <mterry> kenvandine, yay.  thanks so much for the reviews
[18:53] <kenvandine> np
[18:54] <kenvandine> mterry, never a small diff from you!
[18:57] <seb128> kenvandine, mterry: good job guys!
[19:04] <smoser> jodh, around?
[19:14] <dupondje>  trying to overwrite '/usr/lib/evince/4/backends/comicsdocument.evince-backend', which is also in package libevince3-3 3.5.3-0ubuntu1
[19:14] <dupondje> hmz :)
[19:16] <micahg> dupondje: file a bug and subscribe jbicha and robert_ancell unless another desktopper speaks up here to take it
[19:17] <dupondje> No apport report written because MaxReports is reached already
[19:17] <dupondje> why is that
[19:19] <infinity> dupondje: Which package had that overlap?
[19:20] <dupondje> libevdocument3-4_3.5.3-0ubuntu3_amd64.deb
[19:20] <dupondje> -rw-r--r-- root/root      3770 2012-06-27 15:45 ./usr/lib/evince/4/backends/comicsdocument.evince-backend
[19:23] <dupondje> micahg: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1018543 seems somebody else was first :)
[20:36] <ggherdov> Hi all. I am trying to install the search UI solritas on my solr 1.4.1 instance, which I installed as an ubuntu package on ubuntu 11.04 (natty). This is being harder than expected. The recipe at http://wiki.apache.org/solr/VelocityResponseWriter says to copy a bunch of .jar from contrib/velocity/src/main/solr/lib to /lib .
[20:36] <ggherdov> Well, I don't have any of those .jar, not in the solr-common package (list here: http://bpaste.net/show/WG6bJiFKuJhA4voRNTrI/ ) nor in the 'velocity' module, that I installed separatedly (list here http://bpaste.net/show/MAEICAOm8NpVbocS18Rj/ ).
[20:36] <ggherdov> should I submit a bug in the solr-related packages?
[20:38] <ggherdov> I might also add that "apt-cache show solr-common"  shows this note: This package also contains the dataimporthandler contrib while omiting  dataimporthandler-extras, clustering, extraction and velocity due to missing  dependencies.
[20:39] <ggherdov> what does it mean? what are the "missing dependancies" for velocity in solr-common ?
[20:40] <slangasek> stgraber, cyphermox: does network-manager-openvpn generally work well in quantal?  I'm having strange periodic drops, with nm-openvpn SIGTERM in the logs
[20:41] <cyphermox> slangasek: stgraber can tell you. I don't have a permanent setup that I use
[20:41] <slangasek> ggherdov: please see the topic - this is a channel for development of Ubuntu, not support.  Try #ubuntu
[20:41] <cyphermox> slangasek: if it's flaky on quantal might want to take a good look at precise though, because it would be the same version, most likely the same behavior
[20:42] <stgraber> slangasek: works great here, what VPN is that? QA?
[20:42] <slangasek> stgraber: yes
[20:43] <stgraber> slangasek: let me connect to that one. My config is quite different from that VPN though. One notable difference between my own VPNs and that one is that I'm running in tcp mode by default, not udp.
[20:46] <slangasek> stgraber: tcp?!  madness
[20:46] <slangasek> stgraber: but I'm testing now with a raw openvpn profile instead of through NM, and it seems to be working stably
[20:47] <stgraber> slangasek: I just connected from here, will see if it disconnects
[21:34] <bdmurray> bryceh: its possible to see what pocket a version of a package appears in so something like this could be used in your hook http://paste.ubuntu.com/1063282/
[21:35] <bryceh> bdmurray, well the problem is that half the bugs reported against X actually aren't X bugs at all
[21:36] <bryceh> and the other half are usually so ambiguous they might be legitimate X bugs but are rarely associated with the right X package
[21:37] <infinity> bryceh: So, the solution is to file them all against mysql-5.5 and let SpamapS sort it out.
[21:37] <bryceh> bdmurray, however that code would still be mighty handy for at least just indicating if the user has stuff installed from those other pockets
[21:39] <bryceh> infinity, 90% of everything is just crap.  So maybe random.random() > .9 would work?
[21:40] <SpamapS> =o
[21:41] <bryceh> bdmurray, so yeah I like where you're going with that code.  do you think launchpadlib calls from apport hooks are ok?
[21:42] <bdmurray> bryceh: I thought you already did one in check_is_supported
[21:43] <bdmurray> but yes I think its fine
[21:43] <bryceh> bdmurray, hey you're right
[21:44] <bryceh> bdmurray, ok cool.  maybe with your change I should centralize the login to avoid re-logging in multiple times
[21:44] <bryceh> bdmurray, hmm what do you think about us maybe getting lpltk included in main?
[21:44] <bdmurray> well and it really could be one function and just pass the pocket
[21:45] <bryceh> bdmurray, oh yeah, just do all the data lookup in one go, that's a good idea
[21:45] <bdmurray> I was just experimenting there
[21:46] <bryceh> bdmurray, yeah I like it.
[21:46] <bryceh> although like I mentioned it probably won't work for finding regression-update appropriate bugs, since the bugs are almost never filed against the package the bug is actually in
[21:47] <bryceh> ...which is kind of a separate issue in itself...
[21:47] <hallyn> slangasek: just got a response on the debian bug for the sysvinit/initscripts /dev/shm bug - he's put a fix into the git tree
[21:47] <slangasek> hallyn: is it the same fix?
[21:49] <slangasek> hallyn: looks like he's applied your patch... which I think we're now agreed doesn't completely cover all the cases?
[21:51] <cjwatson> bryceh: as long as you aren't assuming that launchpadlib will be available by default in 10.10
[21:51] <cjwatson> er, 12.10
[21:52] <cjwatson> we're not likely to have it ported to py3 ...
[21:52] <hallyn> slangasek: what exactly does it do differently?  if /dev/shm is a non-mounted-on directory, it won't turn that into a symlink.
[21:52] <bryceh> cjwatson, hmm that could be a problem, yes this does indeed assume it to be available
[21:53] <bryceh> well, I guess that's one way to stop the deluge of bug reports to X.org :-)
[21:53] <hallyn> i'm having late-afternoon logic inversion issues :)
[21:56] <slangasek> hallyn: the question of whether /dev/shm itself is a bind mount
[22:00] <hallyn> slangasek: it doesn't ask that q, but it simply leaves it be if /dev/shm exists and /dev was not a mountpoint (and always leave it be is /dev was a mountpoint)
[22:02] <hallyn> i'll reply to the debian bug pointing to yours, thanks
[22:02] <slangasek> ok
[22:04] <hallyn> sent :)  thanks, ttyl
[23:39] <xnox> infinity: "if we don't add explicitly pthreads library to linker flags after update glibc to version 2.15"
[23:40] <xnox> a see a similar failure now, but the package compiled fine in precise
[23:40] <xnox> did something change in eglibc to follow suite?
[23:41] <infinity> xnox: Err, I might need some context.  And that first sentence in English. ;)
[23:41] <infinity> xnox: (And no, we haven't changed anything in eglibc, but we have changed the compiler)
[23:41] <xnox> infinity: http://paste.ubuntu.com/1063440/
[23:42] <xnox> infinity: quick google search suggests that glibc stopped exposing/linking against pthreads.
[23:42] <infinity> xnox: That just looks like as-needed, your -lpthread is in the wrong place.
[23:42] <xnox> qutecom used to compile fine, but now it doesn't
[23:43] <infinity> xnox: -lpthread IS on the command line there, just not with the rest of the libs.
[23:43] <infinity> xnox: That said, you probably want -pthread, not -lpthread.  I believe.  I keep forgetting which direction that's flip-flopped in the toolchain.
[23:44] <xnox> right.... i need to figure out where they are comming from. I am scared if the boost stuff is providing the flags the wrong way around now
[23:44] <infinity> xnox: What package is this?
[23:45] <xnox> qutecom
[23:45] <xnox> infinity: to get to that error you need this patch http://paste.ubuntu.com/1063444/
[23:45] <xnox> due to changes in quantal
[23:45] <infinity> It's not boost-related at all, I'm sure.
[23:47] <infinity> xnox: Plenty of hits for -lpthread in the source.
[23:49] <xnox> infinity: how come it compiled fine on precise though?
[23:53] <infinity> xnox: If I had to guess, I'd say maybe -lboost_thread used to link pthread, so it worked by accident.
[23:57] <xnox> CXX_FLAGS look correct and have -pthread in them, but not the link command has -lpthread which should be just -pthread
[23:57] <xnox> CMake is confusing
[23:57] <infinity> CXX_FLAGS obviously doesn't have -pthread in that invocation.
[23:57] <infinity> And -lpthread *would* work, if it wasn't where it is in the commandline. :P
[23:57] <infinity> (But -pthread is much less hassle to get right, since the compiler just magically DTRT)