[00:01] <darkxst> infinity, yes on both those
[00:03] <infinity> @pilot out
[00:07] <infinity> darkxst: Done.
[00:07] <darkxst> infinity, thanks
[02:28] <ghena1986> http://bit.ly/183GBEv
[07:07] <smb> infinity, In the unlikely event you are still around, could you accept xen in raring?
[07:46] <dholbach> good morning
[07:51] <JackYu> dholbach, morning:)
[07:52] <dholbach> hi JackYu
[08:23] <seb128> is anyone working on getting the kernel that fixes aufs out of proposed?
[08:29] <seb128> apw, ^ do you know?
[08:30] <seb128> the autolanders are still screwed since today's iso still has the buggy kernel :/
[08:33] <apw> seb128, that is waiting for d-i
[08:33] <seb128> apw, is anyone working on getting d-i updated?
[08:34] <apw> seb128, i do not know if anyone is no, normally they are pretty snappy at doing it, but it has some seed complexity so we arn't yet able to do it
[08:34] <apw> and some of the keener members are sprinting
[08:34] <seb128> apw, who is "they", cjwatson?
[08:35] <seb128> right :/
[08:35] <apw> and infinity
[08:35] <seb128> I fear it's going to be one of those days where CI is going to be screwed until Lexington people are in the office
[08:35] <seb128> apw, thanks
[08:36] <apw> seb128, i suspect that tells one that CI has a fundamental need to be able to select older things, like here the kernel boots, yuo could downgrade it and do the tests no problem
[08:36] <apw> so although the kernel is holding CI, if it holds CI, CI is broken
[08:37] <seb128> apw, I suspect they can downgrade the kernel or boot an old one, the issue is that "they" are all in Lexington this week :/
[08:37] <apw> seb128, then that is more of a problem for velocity ...
[08:37] <seb128> right
[08:38] <seb128> apw, btw is there any way we could have an autopkgtest or something that make sure aufs loads/work on kernel updates in the futur?
[08:39] <apw> seb128, perhaps, aufs has never been a gating feature before however, as union mounts have only been 'consumed' by CDs and if one of overlayfs or aufs work enough for that we are 'good' to go
[08:40] <seb128> we, seems our CI/daily landing rely on it nowadays
[08:40] <apw> seb128, heh, well it is always good to see communication working so well
[08:40]  * apw is tempted to revert the fix for a bit to focus the mind
[08:43] <seb128> shrug
[08:43] <seb128> let's just try to get d-i uploaded today and move on
[08:43]  * seb128 just wants fixes to land to saucy
[08:43] <seb128> (fixes for unity/touch components)
[08:44] <apw> seb128, this is one case where no manual override for CI is a fail
[08:44] <apw> seb128, can't you just upload it, like one would have to do in a fail scenario
[08:44] <apw> seb128, it would be a good test for the recovery process
[08:44] <seb128> apw, well, we still have direct upload available
[08:45] <seb128> but then we need to get the diffs merged back
[08:45] <seb128> so it's double work
[08:45] <apw> seb128, so test it on your laptop, with the fixed kernel and upload, win
[08:45] <seb128> I guess I could do that
[08:45] <seb128> anyway
[08:46] <seb128> apw, thanks for the replies, I've annoyed you enough about the topic, moving on to get stuff uploaded ;-)
[08:47] <apw> heh ... it is always good to test these paths :)
[08:53] <Chipaca> since yesterday's update, my chromium has no chrome :-(
[08:53] <Chipaca> i had forgotten how clunky firefox was :)
[08:56] <seb128> Chipaca, yeah, seems like something is wrong with the update :/
[08:56] <seb128> qengho is not around at this time though
[08:57] <seb128> Laney, that's going to teach us to override tests :p
[08:57]  * Laney glares
[08:57] <seb128> Chipaca, can you open a bug? https://launchpad.net/ubuntu/+source/chromium-browser/+filebug
[08:58] <Chipaca> also, just started a guest session to check whether it was my account or my machine, and the guest session started on the same vt
[08:58] <Chipaca> keyboard and mouse was still in the old vt
[08:58] <Laney> chromium has an apport hook
[08:58] <Laney> probably better to use ubuntu-bug chromium-browser
[08:58] <Chipaca> switched to a console to kill the guest user, and everything i typed also went to the terminal i had open in my xmir session
[08:59] <Laney> that's the bug mjg59 has been on about
[08:59] <seb128> seems like more mir and vt fun
[08:59] <Laney> at least the second part is
[08:59] <Chipaca> i thought it'd been fixed before we were told to use it
[08:59] <seb128> I though they got it fixed
[08:59] <Chipaca> holy boogers :-(
[08:59] <Laney> https://bugs.launchpad.net/xmir/+bug/1192843
[08:59] <seb128> Chipaca, can you ubuntu-bug chromium-browser?
[09:00] <Chipaca> seb128: am on it already :)
[09:00] <seb128> Chipaca, thanks
[09:00] <Laney> HAHA
[09:00] <Laney> I just did my daily dist-upgrade and got a file conflict on chromium :D
[09:00] <seb128> Laney, that's bug #1222488
[09:01] <Laney> yes
[09:01] <Chipaca> yesterday my session crashed in the middle of the upgrade so i missed that (hence why i needed to confirm if it was me or everybody affected)
[09:01] <seb128> I ran into it yesterday and pinged qengho about it
[09:01] <Laney> ho hum
[09:01] <cjwatson> apw: I'll sort that out nowish then
[09:02] <cjwatson> seb128: ^-
[09:04] <Chipaca> bug #1223251
[09:06] <Chipaca> seb128: ^
[09:06] <Laney> it does have chrome for me, fwiw
[09:07] <Chipaca> *now* you tell me :)
[09:07]  * Laney shrugs
[09:07] <Laney> still a bug
[09:07] <Chipaca> next you'll tell me ctrl+t still opens tabs for you
[09:08] <Laney> I'm sure there's a more constructive bug title you could have used :(
[09:08] <Chipaca> ooohhh. ctrl+n opens a window with all the chrome on it
[09:09] <Chipaca> Laney: where's the fun in that?
[09:09] <Laney> Thinking of poor old qengho reading that in his bug mail
[09:10] <apw> cjwatson, hey thanks, you are a star as always
[09:10] <Chipaca> well... it seemed better than "broken in a number of different ways", in that you'd get a chuckle out of it
[10:54] <cjwatson> debfx: Do you think you could merge cdbs from Debian?  It doesn't look like too unreasonable a set of changes (at least from the changelog), and it's blocking liblwp-protocol-psgi-perl in -proposed.
[10:55] <cjwatson> And libtest-checkdeps-perl.  Maybe others.
[11:04] <debfx> oh no, did I make the mistake of touching cdbs?
[12:09] <lool> pitti: Q on unattended-upgrades: why run the testsuite or specifically things like pep8/pyflakes in autopkgtests rather than at build time?
[12:10] <tseliot> ScottK: I hope my comment answered your question on bug 1095751
[12:10] <lool> (I can imagine /some/ tests require doing upgrades and what not, but pyflakes / pep8 are safe to run at build time?)
[12:46] <pitti> good morning
[12:47] <pitti> darkxst: all good now?
[12:47] <pitti> lool: unattended-upgrades> it just runs the whole testsuite during autopkgtest; pep8 in autopkgtest admittedly doesn't make much sense, so ideally we could filter out that one test
[12:59] <lool> pitti: I looked at upstreaming this, but the debian version has quite a lot of pep8 errors; FYI the current pep8 test is only on test/*.py rather than on the whole source tree; I'll try to fix these issues in the next hour or so
[13:00] <pitti> lool: ah, thanks; I did an upload yesterday to at least make the autopkgtest fix again, but more refinements are certainly appreciated
[13:00] <pitti> lool: after mvo left that whole update-manager/unattended-upgrades/etc. stack is a bit of an orphan
[13:04] <lool> pitti: ack
[13:38] <spot_> new ubuntu does not work out of the box
[13:38] <GSport> HDMI sound isnt working
[13:43] <infinity> GSport: raring?  If so, you need to dist-upgrade to the latest kernel.  The shipped one on the CD image had an HDMI sound bug.
[13:48] <GSport> nice try but i got the daily build
[13:49] <infinity> GSport: Well, you said "new Ubuntu", which was pretty non-specific.
[13:49] <infinity> GSport: Please file a bug, then.  "ubuntu-bug linux".  This isn't a support channel.
[13:49] <GSport> sorry i meant the newest build
[13:50] <GSport> yes something crash after login
[13:50] <GSport> but you seem to need to register
[13:50] <GSport> to post the auto bug thing
[13:51] <infinity> You do, yes.  But asking random people on IRC to debug something *right now* won't work, hence the request to file a bug.
[13:51] <GSport> nice way to keep the bug reports manegable
[13:53] <GSport> and nice way to mine email adresses
[13:53] <infinity> You can use a throwaway email address.  *shrug*
[13:53] <GSport> you got one to hand me?
[13:53] <infinity> A design decision we made in our bug tracker a decade ago probably isn't going to change based on someone's complaint today.  And we're hardly the only people who require you to log in to file a bug.
[13:54] <GSport> because i hate filling form
[13:54] <GSport> s
[13:55] <GSport> like im asking you to change anything
[13:56] <GSport> keep it the way you always have
[13:56] <GSport> if its working out for you
[13:57] <GSport> never mind the users
[13:57] <GSport> im just realizing that linux only seem to work fine on the deves boxes
[14:02] <GSport> besids the xchat app goes to a debian channel
[14:02] <GSport> by default
[14:02] <GSport> on OFTC irc network
[14:04] <GSport> being so well funded seem like ubuntu is pretty amatorish
[14:06] <cjwatson> we've had over a million bugs filed, if an account requirement is to "keep the bug reports manageable" then it isn't doing a very good job :-)
[14:07] <GSport> a million is alot more managable that 10 million
[14:10] <GSport> even on windows that sia colse enviroment you dont need to register to upload bug reports
[14:12] <GSport> i cant see the use of email after they invented IM
[14:12] <GSport> must be a nix preform
[14:14] <ogra_> you would want to use IM for say a 5 page document that discusses a complex code fix with a group ?
[14:15] <GSport> google groups?
[14:15] <ogra_> erm
[14:15] <ogra_> didnt youo just complain you need to register with a mail address ? how would using google groups prevent that ?
[14:16] <GSport> news gtoups?
[14:16] <ogra_> and thats the future ?
[14:17] <GSport> news groups is newer that email
[14:17] <ogra_> what ?!?!
[14:18] <GSport> news groups need no registration
[14:18] <ogra_> GSport, http://en.wikipedia.org/wiki/Usenet#History
[14:18] <ogra_> (though technically you might be right, mail is likely a few months older)
[14:18] <GSport> im sorry i want around when they invented it
[14:19] <GSport> wasnt*
[14:22] <GSport> the volume icon didnt even worked
[14:22] <slangasek> GSport: that's all well and good, but to get actionable bug reports requires a reliable feedback channel to the submitter.  That means email.  We've taken deliberate steps to not require accounts and email addresses for crash reports because those can operate at scale and give us the information we need without having to ask users for details, but for what you're talking about there needs to be a dialog between the developer and the user
[14:23] <slangasek> ... dialog happens by email
[14:23] <slangasek> so if you want someone to take a look at this issue for you, you're going to have to submit a bug report
[14:24] <GSport> email isnt a dialog
[14:24] <GSport> IM is a dialog
[14:24] <GSport> like irc
[14:26] <slangasek> this isn't something that arguing with us about is going to change
[14:31] <GSport> i couldnt care less
[14:31] <GSport> i never going to use this crap anymore ever
[14:32] <GSport> i dont have money to buy a new computer if this one breaksdown
[14:33] <GSport> probablly you are in the buisness of breaking pcs so that people buy macs
[14:33] <cjwatson> Please take this elsewhere; if you don't like Ubuntu that's fine but we're not here to be abused
[14:43] <arnoldk__> Darn, I missed out on the troll?
[14:43] <cjwatson> pitti: postgresql-9.1 in -proposed dropped the libraries on the grounds that -9.3 would be providing them instead, but -9.3 isn't in saucy(-proposed).  Is that a forgotten sync, a missing FFe, ...?
[14:48] <slangasek> cjwatson: I guess the export should be in the memdisk config, right?
[14:48] <cjwatson> slangasek: I think so
[14:48] <slangasek> cjwatson: er, I mean in the embedded config
[14:48] <slangasek> well, you tell me which I mean ;)
[14:48] <cjwatson> slangasek: No, I think it wants to be at the same level as where you set root=tftp
[14:48] <slangasek> ok
[14:49] <cjwatson> The main menu execution should be a child of that execution context
[14:49] <cjwatson> slangasek: This is all based on the hypothesis that what you meant by your comment in the MP was that when you got to the real menu all the tftp-set env vars had gone away
[14:49] <cjwatson> Or similar
[14:49] <slangasek> cjwatson: hmmm unfortunately the net_* variables include some net-device-specific ones
[14:50] <slangasek> net_efinet8_ip=10.98.5.66
[14:50] <cjwatson> slangasek: Yeah, that was why I said we could come up with something neater
[14:50] <cjwatson> slangasek: If this is actually the problem then we could make those be automatically exported, say
[14:50] <slangasek> oh, so just do this to see if it works, got it
[14:50] <cjwatson> Right
[14:57] <cjwatson> pitti: Also, what's the best way to set things up so that I can get useful retraces of parted crashes?  parted ships -dbg packages which are a separate build pass (because they turn on extra malloc debugging), so I want real dbgsyms rather than dummy ones; should I just add it as a special case in pkg-create-dbgsym alongside python?
[14:57] <cjwatson> Doesn't really seem ideal since it might change
[14:59] <slangasek> do you mean the crash was generated using the -dbg packages, and now you need the corresponding backtrace?
[14:59] <cjwatson> No, I mean the crash was generated using the non-dbg packages, and I can't get a backtrace because (a) -dbg is from a different build pass (b) pkg-create-dbgsym thinks it only needs to generate dummy -dbgsym packages because -dbg exists
[14:59] <slangasek> ah
[15:00] <cjwatson> Maybe I should just turn the -dbg packages into plain separated-debug-symbol packages in Debian.  mtrace is supposed to have no effect if MALLOC_TRACE is unset in the environment anyway
[15:00] <slangasek> I didn't realize pkg-create-dbgsym skipped when there was a -dbg package; I'm skeptical that this is actually sensible
[15:01] <cjwatson> parted is probably just Doing It Wrong, now that I look at it, but I'm sure we have the same problem elsewhere
[15:02] <cjwatson> This makes it irritatingly hard to attack bug 1215458 though
[15:11] <GSport> why has ubnutu satanic edition stoped being developed?
[15:38] <pitti> cjwatson: p-9.1> ah, got to fix that to build the libs on saucy, will do; thanks for the poke
[15:40] <pitti> cjwatson: I think if we special-case the dbg generation in parted, then we need to do a corresponding special-case in p-create-dbgsym
[15:40] <pitti> cjwatson: if that happens in more cases, we could try to come up with some way how pkg_create_dbgsym could see that the -dbg package is not a real -dbg package
[15:41] <Riddell> jbicha: I plan to update libdvdread with this http://starsky.19inch.net/~jr/tmp/install-css.sh
[15:41] <pitti> slangasek: infinity asked for this to lessen the impact of -dbgsym packages in the librarian, as they essentially just duplicate the same bits that are already in -dbg
[15:41] <cjwatson> pitti: Yeah, as I say I think the parted case is moot, I'm going to reorganise its handling
[15:41] <Riddell> jbicha: medibuntu is going away and videolan will replace it
[15:42] <slangasek> pitti: right; but the proper fix for this is actually to make Debian get ddebs done and get maintainers to stop adding -dbg packages by hand :)
[15:42] <pitti> slangasek: fully agree; just that the past two attemps of doing that stopped/failed :(
[16:07] <smoser> anyone able to get meegingology in #ubuntu-meeting ?
[16:07] <smoser> it seems to have gone elsewhere.
[16:08] <Laney> smoser: try #ubuntu-bots
[16:08] <smoser> Laney, what is its name ?
[16:08] <Laney> I think AlanBell is the guy, maybe
[17:22] <dobey> GSport: doesn't sound like an official ubuntu derivitive. you should ask whoever was making it.
[17:22] <dobey> GSport: likely it would have to be renamed, due to invalid use of the ubuntu trademark
[17:42] <cody-somerville> cyphermox: Any chance you'll do an SRU for quantul for lp #1011073?
[17:42] <cyphermox> cody-somerville: yes, let's
[17:43] <cyphermox> I'll look at this tonight
[17:46] <mterry> adam_g, heyo!  I'm looking at your python-troveclient package.  During the test run when building, I see a lot of errors like "run.py: error: no such option: -t"
[17:46] <cody-somerville> cyphermox: thanks! :) much appreciated.
[17:47] <cody-somerville> cyphermox: I think the problem might also affect LibreOffice so am looking forward to getting that fix. :)
[17:48] <adam_g> mterry, thanks for looking. hmm. let me check on that.
[17:48] <mterry> adam_g, it doesn't stop the build...  but it seems like maybe it isn't running all the tests (and I'm curious why it wouldn't fail the build  :))
[17:54] <pitti> cjwatson: uploaded p-9.1 fix to unstable, I'll sync it in a few hours when it's imported
[17:54] <cyphermox> cody-somerville: aye
[17:55] <pitti> cjwatson: I understand it's not immediately urgent as the current broken version is just held back in -proposed, right?
[17:58] <cody-somerville> cyphermox: Once you get it in proposed, I'll test it out. I think it might allow us to close lp #1045353 and lp #1085169
[18:12] <pitti> zul: neutron autopkgtests> NB you can (and should) just add test deps to debian/tests/control's Depends:, instead of calling apt-get install
[18:13] <pitti> that'll create easier to read output if the test fails (as it does right now as python-jsonrpclib doesn't exist)
[18:13] <adam_g> mterry, looks like a general issue with the projects test suite / its use of testrepository https://jenkins.openstack.org/view/All/job/gate-python-troveclient-python27/52/console
[18:16] <mterry> adam_g, where does run.py even live?  Is it just a testr thing?  Could we run the tests a different way that would work better?
[18:19] <adam_g> mterry, /usr/share/pyshared/testrepository/commands/run.py
[18:20] <adam_g> mterry, nosetests works fine, but Ran 162 tests (nose) vs Ran 324 (+162) (testr)   /me doesn't know enough about testr to interpret that
[18:47] <lifeless> adam_g: there is a bugin testr at the moment, off-by-x2 reported count
[18:48] <adam_g> lifeless, so we're not missing much using nose instead?
[18:49] <lifeless> adam_g: in what context?
[18:49] <lifeless> adam_g: I haven't read all the backlog
[18:49] <adam_g> lifeless, just some seemingly non-fatal errors form test suite during build of python-troveclient https://bugs.launchpad.net/ubuntu/+source/python-troveclient/+bug/1223097
[18:50] <lifeless> adam_g: but in terms of tests that are run, those counts seem fine; nose is an intruisive little beast though so I can't comment on much else
[18:51] <lifeless> you're talking about the
[18:51] <lifeless> 2013-08-06 04:27:54.432 | Usage: run.py [options] <cmd> <action> <args>
[18:51] <lifeless> 2013-08-06 04:27:54.432 |
[18:51] <lifeless> 2013-08-06 04:27:54.433 | run.py: error: no such option: -t
[18:51] <lifeless> stuff ?
[18:51] <adam_g> lifeless, yup
[18:51] <lifeless> I thought they fixed that ages back
[18:51] <lifeless> -> #openstack-trove
[18:54] <lifeless> adam_g: ok so thats an upstream problem, and it's cosmetic: there are unit tests running the cli code that aren't isolating their test environment correctly.
[18:54] <lifeless> adam_g: you can ignore it and run with testr just fine.
[18:55] <adam_g> lifeless, ill make a note in the bug. thanks for your input
[18:59] <lifeless> adam_g: I've reported the issue upstream, hub_cap and I had discussed this in the past
[18:59] <lifeless> adam_g: they thought it was fixed :)
[19:48] <cjwatson> pitti: right - thanks
[20:34] <pitti> zul: "apt-get intall" failed :/
[20:34]  * pitti throws zul an "s" :)
[20:35] <pitti> zul: but with the 2>&1 >/dev/null this would really be better as a test depends:, to see errors from package installation
[20:36] <zul> pitti:  *sigh*
[20:50] <darkxst> pitti, yeh all fixed now, had nothing to do with inhibitors ;)
[21:03] <pitti> zul: FYI, you can test that locally with run-adt-test -s -S file://`pwd` (in the unpacked source tree)
[21:03] <pitti> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[21:24] <zul> pitti:  cool thanks
[22:04] <Noskcaj> stgraber, Do you ming if i merge installation-report ? It's a translation only upload
[22:04] <cjwatson> uh, that needs to be done in bzr or you screw us up
[22:06] <stgraber> Noskcaj: I'd rather do it myself quickly than have to fix the bzr branches after you cowboy it.
[22:06] <stgraber> Noskcaj: debian-installer packages are special
[22:06] <Noskcaj> stgraber, ok
[22:07]  * Noskcaj should probably find something better to do than looking for bugfix releases on MoM
[22:07] <cjwatson> it's kind of the wrong time of the cycle for that, really
[22:08] <Noskcaj> cjwatson, i know
[22:08] <Noskcaj> my internet speed and lack of coding ability stop me from doing anything else
[22:10] <cjwatson> incidentally, while it isn't the case here, translation-only merges of d-i packages can be less trivial than they look sometimes; a number of those packages have branding changes and those require considerable care with translations to avoid causing other people work retranslating things that only differ by Debian/Ubuntu
[22:11] <Noskcaj> thanks for the tip cjwatson
[22:12] <cjwatson> (for example anna, which I'm doing now)