[01:44] <smoser> hey. roaksoax uploaded maas today to saucy. can I get get an ACK on that to release pocket ?
[03:30] <Noskcaj> Is there any way to tell what packages in main are O or RFA in debian?
[03:49] <pitti> Good morning
[03:50] <pitti> wow, no cjwatson on IRC
[03:57] <stgraber> yeah, I suspect his home internet went down again. He disconnected a while back with a ping timeout and hasn't reconnected on IRC or been heard from since.
[06:41]  * zyga updated bug 1233610 with logs from failed boot
[07:09] <dholbach> good morning
[07:09] <ion> that
[08:06] <Noskcaj> Will ubuntu have a Powerpc image next cycle since Qt5.2 should work on PowerPC?
[09:07] <rbasak> I'd like to pull a delayed upload out of Debian ftp-master.d.o/deferred, but only the .changes file exists. Other packages in that queue have source packages, just not this one. Any ideas? It's subversion in http://ftp-master.debian.org/deferred/
[09:09] <cjwatson> You'll have to ask the Debian uploader.
[09:10] <cjwatson> Or a Debian ftpmaster
[09:12] <rbasak> Thanks. Out of interest, why is it different from the other packages there? Is it something the uploader decides? He pasted the patch in the bug, so I can use that. I'm just wondering for future reference.
[09:12] <cjwatson> I don't know
[09:12] <cjwatson> I know of no uploader-accessible control for this
[09:13] <cjwatson> A Debian ftpmaster might be able to figure it out; perhaps it's a bug
[09:18] <rbasak> If you don't know then I figure it's worthwhile asking then. Thanks.
[09:22] <xnox> rbasak: which package?
[09:22] <rbasak> xnox: subversion
[09:23]  * rbasak has asked in #debian-ftp
[10:05] <rbasak> cjwatson, xnox: in case you're interested, it was because the upload involved (re-)adding "new" binaries, causing the whole thing to be hidden.
[10:05] <cjwatson> OK
[10:05] <jamespage> rbasak, I've got a similar one - http://ftp-master.debian.org/new/python-lesscpy_0.9j-2.html
[10:06] <cjwatson> I'd actually thought of that but I had incorrectly dismissed the idea on the basis that deferred wouldn't yet know about the binaries
[10:06] <jamespage> :-(
[10:06] <cjwatson> Which is of course nonsense in Debian
[10:06] <rbasak> I wanted it to re-add libapache2-(mod-)svn so the reason I looked is exactly the reason I can't get it. No matter - I have other options, or can just wait.
[10:06] <jamespage> cjwatson, I need to pull that new version of lesscpy into Ubuntu Saucy, but its stuck in Debian NEW due to a new binary package
[10:06] <pkern> cjwatson: delayed weren't actually dak parsed. deferred is.
[10:06] <jamespage> is there a precendent/good way of doing that?
[10:07] <cjwatson> jamespage: ask the uploader for a copy of the package
[10:07] <cjwatson> pkern: Yeah
[10:07] <jamespage> cjwatson, and sign and upload that to saucy?
[10:07] <cjwatson> jamespage: Or give an ftpmaster chocolate
[10:07] <cjwatson> (Debian ftpmaster that is)
[10:07] <cjwatson> jamespage: Yes.  If it can be fast-tracked into Debian and synced, though, that's better
[10:08] <cjwatson> jamespage: Decrement the version if you upload it to saucy directly
[10:08] <cjwatson> jamespage: i.e. append ~ubuntu1
[10:08] <rbasak> Oh. Does that mean that subversion will also get stuck in NEW after the delay?
[10:08] <cjwatson> Then we can sync the real version later and have it properly linked to the Debian one in the DB
[10:08] <cjwatson> I believe so
[10:09] <cjwatson> Although subversion is pretty high-profile so it wouldn't surprise me if it were processed rather quickly
[10:09] <jamespage> cjwatson, OK - I can pull it directly from the debian git repository if need be
[10:36] <ricotz> doko, hello, maybe you remember this one https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/1163805 -- i am hitting this building the current libx11 master in a ppa
[10:36] <ricotz> https://launchpadlibrarian.net/152123093/buildlog_ubuntu-saucy-i386.libx11_2%3A1.6.2%2Bgit20131002.18a5278b-0ubuntu0ricotz_FAILEDTOBUILD.txt.gz
[10:45] <doko> ricotz, and?
[10:51] <ricotz> doko, sorry, i was hoping you have an idea why this happened/happens?
[10:52] <ricotz> doko, doesnt seem to be a toolchain problem though
[10:52] <doko> no. didn't look. it's only one of the outstanding ftbfs
[10:53] <ricotz> doko, i see
[11:25] <sergiusens> jodh, ping
[11:25] <jamespage> rbasak, just uploaded that nagios/apache2.4 cgi fix
[11:25] <jamespage> (beat you to it)
[12:15] <cjwatson> yolanda: openerp-desktop seems to have been uninstallable ever since it was first introduced in quantal, because it depends on openerp-core which doesn't exist.  Could you investigate?
[12:17] <tjaalton> doko: mlankhorst said it could be due to a bug in w3m, and I've requested a sync from debian which has a newer patched revision and the changelog claims it fixes some segfaults
[12:18] <tjaalton> synced w3m that is
[12:19] <mlankhorst> oh perfect
[12:19] <mlankhorst> I'll retry the libx11 build then
[12:19] <tjaalton> well the sync needs to be processed first :)
[12:20] <xnox> cjwatson: openerp-core was attempted to be included multiple times but it was kept on getting rejected (mainly because it's massive and embedds a lot of 3rd party python & javascript projects)
[12:20] <tjaalton> but i think it should be safe to sync since it's already in testing since august
[12:21] <cjwatson> yolanda,xnox: In that case perhaps openerp-desktop should be demoted to saucy-proposed until such time as openerp-core is in; it's not wrong in itself but we shouldn't expose it to users until it's installable, IMO
[12:21] <mlankhorst> tjaalton: lies, I'll just backportpackage it from sid and retry building in the ppa :P
[12:21] <tjaalton> mlankhorst: of course :)
[12:21] <xnox> cjwatson: agree. I kind of gave up on openerp packaging, didn't have spare time and in the mean time it's moved on to a next major series.
[12:21] <yolanda> cjwatson, i can take a look
[12:22] <xnox> yolanda: are you still packaging openerp?
[12:22] <cjwatson> yolanda: Has the third-party-embedding situation with openerp-core improved significantly?
[12:23] <yolanda> cjwatson, xnox, i haven't touched openerp since i packaged it first time, i think
[12:24] <yolanda> cjwatson, what do you mean with third-party-embedding?
[12:24] <cjwatson> 13:20 <xnox> cjwatson: openerp-core was attempted to be included multiple times but it was kept on getting rejected (mainly because it's massive and embedds a lot of 3rd party python & javascript projects)
[12:24] <cjwatson> yolanda: ^- that
[12:24] <xnox> yolanda: it hasn't made it into the ubuntu archive proper yet https://launchpad.net/ubuntu/+source/openerp-core
[12:25] <xnox> cjwatson: hm. bad rename? https://launchpad.net/ubuntu/+source/openerp6.1 provides openerp6.1-core
[12:25] <yolanda> well, they deployed a new version, openerp 7, and it's totally different
[12:26] <xnox> yolanda: shouldn't then openerp-desktop depend on openerp6.1-core instead of openerp-core?
[12:29] <yolanda> xnox, cjwatson, correct files are openerp6.1, openerp-desktop and openerp-core are not valid
[12:29] <cjwatson> yolanda: Should openerp-desktop simply be removed, or is it worth updating?
[12:29] <yolanda> openerp6.1-full does the same as openerp-desktop
[12:29] <yolanda> so openerp-desktop can be removed
[12:29] <rbasak> jamespage: thanks!
[12:30] <cjwatson> yolanda: OK, for tracking, please file a bug on openerp-desktop with reasoning, and subscribe the ubuntu-archive team
[12:30] <yolanda> ok
[12:38] <cjwatson> sconklin: I may have to cancel some of your PPA kernel builds for a buildd upgrade happening soon.  If I do then I'll retry them afterwards
[12:38] <cjwatson> (I don't recall whether you get mailed about cancelled builds)
[12:58] <zyga> slangasek: hey
[13:19] <smoser> anyone know how to run the test suite for software-properties ?
[13:20] <smoser> in https://code.launchpad.net/~smoser/software-properties/shortcut-refactor/+merge/188500 i've busted something, but i can't get it to run
[13:20] <smoser> http://paste.ubuntu.com/6183814/
[13:51] <pitti> smoser: hm, that seems to be the correct command; the autopkgtest uses exactly this and succeeds (https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-software-properties/)
[14:03] <smoser> pitti, i'm embarrased to ask. but is there a way for me to run the same stuff sans the vm launch ?
[14:04] <cjwatson> There's an LXC runner somewhere in the pipeline
[14:04] <cjwatson> Or you can do it with adt-virt-schroot but you don't get network isolation
[14:05] <pitti> smoser: no, I meant to say "python setup.py test" is supposed to just work
[14:05] <pitti> smoser: (and it does here)
[14:05] <pitti> apt-get source, python setup.py test, success
[14:06] <pitti> smoser: same with sudo (it skips some tests as non-root)
[14:06] <sconklin> cjwatson:  I didn't see any email. This is a production week for us, what are the time frames for canceling/retrying the builds?
[14:06] <cjwatson> sconklin: I already retried them
[14:07] <cjwatson> so they should restart within a few tens of minutes
[14:07] <sconklin> ack, thanks
[14:07] <cjwatson> sorry but it's impossible to have the build farm entirely clear and I've been trying to get hold of a sysadmin for this upgrade since Friday ...
[14:07] <smoser> pitti, ok. so i'm doing something really stupid then,
[14:08] <smoser> apt-get source software-properties.
[14:08] <smoser> cd software-properties-0.92.26
[14:08] <smoser> python setup.py test
[14:08] <smoser> http://paste.ubuntu.com/6183992/
[14:11] <dobey> smoser: missing build-depends?
[14:13] <smoser> dobey, no. i have them.
[14:14] <cjwatson> sconklin: Of the five builds in question, two built before the upgrade, two are building now, and one is due to start in 8 minutes.
[14:15] <sconklin> cjwatson: ack, thanks
[14:18] <zyga> slangasek: around?
[14:23] <larsu> doko: hi! how are you? I've just found a gcc regression and hear you're the one who cares about them :)
[14:24] <doko> larsu, just one?
[14:25] <larsu> doko: haha ya. I've just found the list of regressions online. Crazy!
[14:25] <larsu> doko: what do you advise? File an upstream bug?
[14:25] <infinity> sconklin: FWIW, I mentioned the upgrades in another channel you're in a half hour before you poked Colin. :P
[14:26] <doko> larsu, well, a launchpad bug first please
[14:26] <sconklin> infinity: fwiw I'm in a number of channels and unless you type my nick, I probably won't see it
[14:27] <larsu> doko: will do
[14:28] <smoser> ok. i'm clearly doing *something* stupid (this is nothing new).
[14:28] <smoser> I run this on a fresh cloud instance (saucy)
[14:28] <smoser> http://paste.ubuntu.com/6184053/
[14:28] <smoser> out.log looks like this:
[14:28] <smoser> http://paste.ubuntu.com/6184063/
[14:28] <smoser> which is exactly what i'm seeing here.
[14:29] <smoser> pitti, ? anyone. i' realize i'm  probably doing something terribly stupid, but i'd appreciate someone pointing it out ot me.
[14:30] <smoser> i'll also note that 'test_lp' likely references 'tests/test_lp.py'
[14:30] <infinity> smoser: Well, it kinda looks like the build-deps don't include the packages required to run that test.  Just sayin'.
[14:31] <smoser> infinity, so then adt-pkg-test is doing something else to fix it .
[14:31] <smoser> right?
[14:32] <infinity> smoser: Well, the adt test installs software-properties itself.
[14:32] <infinity> smoser: (And, in fact, all the packages produced by the source)
[14:33] <infinity> smoser: Which, in turn, depends on all those missing modules.
[14:34] <smoser> infinity, thank you.
[14:39] <smoser> infinity, ugh. so
[14:39] <smoser> sudo apt-get install python-software-properties python3-software-properties software-properties-common software-properties-gtk software-properties-kde
[14:39] <smoser> did not solve my problem.
[14:41] <infinity> smoser: You still get all the same failed imports?  Really?
[14:41] <smoser> yes
[14:43] <smoser> infinity, http://paste.ubuntu.com/6184127/
[14:44] <pitti> smoser: do you actually have tests/test_lp.py?
[14:44] <smoser> yes
[14:44] <smoser> $ ls -l tests/test_lp.py
[14:44] <smoser> -rwxrwxr-x 1 ubuntu ubuntu 3945 Jul 30 11:48 tests/test_lp.py
[14:45] <smoser> i suspect that the issue is the name 'tests' is conflicting with something else
[14:45] <smoser> i'll let anyone interested in helping into the node to poke around
[14:48] <smoser> but this is what i've done http://paste.ubuntu.com/6184138/
[14:48] <smoser> (recently aded the install of packages)
[15:41] <rbasak> smoser: is this a namespace conflicts that needs a from __future__ import absolute_import? I've not looked in detail at all - it just has a whiff of that.
[15:41] <smoser> rbasak, i'm not familiar with that. but i do think its a namespace conflicts.
[15:42] <rbasak> I'm not sure what you're doing, but when you mentioned the name "tests", it makes me suspicious.
[15:47] <xnox> smoser: python3 setup.py test ?
[15:47] <xnox> vs python2....
[15:48] <smoser> xnox, same thing actually. almost identical
[15:48] <xnox> unless you have tried that already.
[15:48] <xnox> =(
[15:50] <smoser> http://paste.ubuntu.com/6184392/
[16:15] <sil2100> Hi again! Anyone from the SRU team free for https://bugs.launchpad.net/unity/+bug/1043627 analysis? Thanks!
[16:25] <zyga> jodh: ping
[16:25] <jodh> zyga: hi
[16:26] <zyga> jodh: is there a way to peek at, say, signal data intercepted via upstart-dbus-bridge?
[16:26] <jodh> zyga: upstart-monitor
[16:26] <zyga> jodh: I want to capture network manger StateChanged signal and trigger some scripts when that happens
[16:26] <zyga> jodh: I mean in the job file
[16:26] <zyga> jodh: can it go to a variable or something like that
[16:27] <jodh> zyga: it already does: man dbus-event
[16:27] <zyga> thanks, let me check those!
[16:31] <zyga> jodh: so I should use ARG0... ARGN to filter on the values packed into the signal I want, correct?
[16:33] <jodh> zyga: yes. Note that only bools, ints, strings and object paths are encoded though.
[16:33] <zyga> ok, that's good enough
[16:33] <zyga> cool
[16:33] <zyga> I guess this will work
[16:33] <zyga> I'll show you what I did in a second ^_^
[16:44] <zyga> jodh: I cannot see dbus events with upstart-monitor, do I need to do something to be able to see them?
[16:45] <zyga> jodh: and related to that, can I inspect ARG0 in my script section? or is that just for event matching?
[16:47] <xnox> zyga: try --system bus?
[16:47] <jodh> zyga: ah - you need to actually create a job that specifies "start on dbus" since otherwise the upstart-dbus-bridge won't bother proxying the signals into upstart as events. You can change that behaviour if you wish by running the bridge with '--always'.
[16:48] <zyga> ah, thanks
[16:48] <zyga> yeah, I thought that, I'm just writing my job and it wasn't ready to be placed there
[17:23] <zyga> jodh: do I need to restart something for upstart-dbus-bridge to notice that I'm using dbus stanza? I just don't see any events (on dbus side)
[17:23] <zyga> jodh: alternatively, do I need to specify each field (including SENDER?)
[17:25] <zyga> ohhh
[17:25] <zyga> I'm dumb
[17:25] <zyga> 'dbus' vs 'start on dbus'
[17:39] <zul> mterry:  ping cherrypy3 should be good to go https://bugs.launchpad.net/ubuntu/+source/cherrypy3/+bug/1229778
[17:43] <mterry> zul, will look in a bit
[17:43] <mterry> zul, thanks
[17:43] <zul> mterry:  thanks
[17:50] <mterry> zul, approved, thanks so much
[17:51] <zul> mterry:  thanks
[18:40] <zyga> damn
[18:40] <zyga> upstart-dbus-bridge CLOBBERS PATH
[18:40] <zyga> WHY
[18:40] <zyga> :/
[18:40] <zyga> I know why but it just sucks
[18:57] <stgraber> zyga: this got fixed with the last upload
[18:58] <stgraber> which is apparently stuck on autopkgtest...
[18:59] <stgraber> xnox: http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-upstart/
[19:07] <zyga> stgraber: oh, so what is it being set to now?
[19:08] <stgraber> zyga: OBJPATH IIRC
[19:09] <zyga> stgraber: does it change how matching is done as well?
[19:09] <stgraber> ok, just confirmed, it's indeed called OBJPATH now so you'll need to change your start conditions to use that (if you were filtering on PATH= before)
[19:10] <zyga> stgraber: thanks, since that's an incompatible change, is this announced/documented somehow?
[19:10] <stgraber> zyga: sorry don't have much more details, I just noticed that when going through the package uploads this morning
[19:10] <zyga> thanks
[19:10] <stgraber> zyga: I don't think so, the documentation was updated (manpage) but that's apparently about it...
[19:12] <slangasek> zyga: not advertised widely, following the principle of "if you were relying on the previous behavior it didn't work anyway for obvious reasons"
[19:12] <zyga> slangasek: well, I just patched DBUS_PATH=$PATH; PATH="..."
[19:12]  * zyga suspects that dbus-file-bridge is broken :/
[19:16] <slangasek> zyga: why's that?  It's being used successfully in various places
[19:16] <zyga> slangasek: first, it sends create event for reasons beyond my understanding if the file already exists there
[19:17] <zyga> slangasek: second, it does not seem to send modify event when the file changes, but this might be just me doing something wrong (still checking)
[19:18] <zyga> slangasek: and I suspect that it's not looking at jobs being redefined, do I need to restart the machine for upstart to note that my job uses 'file' ?
[19:19] <slangasek> zyga: expected behavior, if the file exists when first started you get an initial notification of its existence as a 'create' event
[19:19] <zyga> slangasek: ah, then it must have eluded my reading of the man page
[19:20] <slangasek> looking at jobs being redefined> you mean, the file bridge detecting that a job definition has changed?
[19:20] <slangasek> I think that's supposed to work
[19:20] <zyga> yes
[19:20] <slangasek> you don't have any overlayfs in the mix, do you?
[19:20] <zyga> slangasek: nope
[19:20] <zyga> slangasek: nothing fancy, just stock 13.10
[19:30] <slangasek> zyga: wrt bug #1233610, it would be interesting to know if this is reproducible with the nfs-common from quantal
[19:31] <zyga> slangasek: I'll try, is this in backports?
[19:31] <slangasek> zyga: 1:1.2.6-3ubuntu2 fixes a bunch of race conditions; the intent is to SRU it into precise now that mountall has cleared the SRU queue, but I haven't had a chance yet
[19:32] <slangasek> (cf. https://bugs.launchpad.net/ubuntu/precise/+source/nfs-utils/)
[19:32] <slangasek> zyga: not in backports, and shouldn't be; best bet for testing is just to manually install it
[19:43] <zyga> slangasek: ok, I'll give it a try
[19:46] <slangasek> zyga: the filesystems not being correctly tagged 'remote' also looks like a mountall bug, possibly one that's been fixed in saucy only; so if quantal nfs-common doesn't fix it, you may want to test with the newer mountall too
[19:56] <zyga> slangasek: thanks, I'll try both
[19:56] <zyga> slangasek: as for upstart bugs, I suspect that I'm either not using dbus syntax correctly or that dbus events are simply not ever forwarded, the only case that I see, is when I run upstart-dbus-bridge --always manually
[19:57] <zyga> I'm using this:
[19:57] <zyga> start on dbus INTERFACE=org.freedesktop.NetworkManager PATH=/org/freedesktop/NetworkManager SIGNAL=StateChanged
[20:00] <slangasek> zyga: so still using PATH= ? maybe you want to upgrade to a version that uses OBJPATH, to be sure
[20:00] <slangasek> zyga: is this a system-level job or a user-level job?
[20:01] <zyga> slangasek: system level, let me upgrade to check if that changes
[20:07] <zyga> slangasek: hmm, upstart is not in my upgrade list, is it still in some other place -proposed/
[20:08] <stgraber> zyga: it's still in -proposed due to failing autopkgtest
[20:08] <zyga> ah, right
[20:08] <zyga> ok
[20:18] <slangasek> stgraber: is the ADT failure the same as bug #1089159?  Seems hard to check now, since the jenkins frontend is currently unhappy
[20:21] <stgraber> ...with missed reboot in utmp file
[20:21] <stgraber> BAD: wrong value for utmp->ut_tv.tv_usec, got unexpected 487301
[20:21] <stgraber> 	at tests/test_utmp.c:990 (test_write_runlevel).
[20:21] <stgraber> /bin/bash: line 5: 15378 Aborted                 (core dumped) ${dir}$tst
[20:21] <stgraber> FAIL: test_utmp
[20:21] <stgraber> slangasek: ^ that's the current failure
[20:23] <stgraber> slangasek: http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-upstart/ARCH=amd64,label=adt/81/console works here (QA VPN)
[20:23] <stgraber> (works as in, I can access the page showing me the test failure)
[20:24] <zyga> so, new upstart installed
[20:24] <zyga> start on line changed to...
[20:24] <zyga> start on dbus INTERFACE=org.freedesktop.NetworkManager OBJPATH=/org/freedesktop/NetworkManager SIGNAL=StateChanged
[20:25] <zyga> and still nothing in upstart-monitor or in a log (I just log all instances of this job being started)
[20:33] <zyga> stgraber: remeber when I reported that on 12.04 pastebinit has '/usr/bin/env python' and sent a patch to fix that
[20:33] <zyga> stgraber: it's still broken on saucy :/
[20:33] <zyga> stgraber: you said you have a python3 version handy that fixed that
[20:35] <zyga> slangasek: so about dbus-upstart-bridge, with this job, http://paste.ubuntu.com/6185493/ I see nothing in upstart-monitor, either docs are wrong or this just dones't work
[20:35] <stgraber> zyga: I do, in a branch somewhere, I should probably look into that at some point... pastebinit is one of those, couple hours a year kind of project for me (since it mostly just works)
[20:35] <zyga> stgraber: yeah, I know how that feels
[20:35] <stgraber> zyga: the python3 branch is basically a rewrite to drop configobj and use much cleaner, readable python, though so far I haven't found the time to finish it...
[20:35] <zyga> now if I start upstart-dbus-bridge --always I do see events, smells like a bug IMHO
[20:36] <zyga> stgraber: cnf feels exactly like that
[20:36] <stgraber> zyga: also, I usually hack on my personal project on the plane when traveling which doesn't work too well for pastebinit as most of the pain is interfacing with all the random servers :)
[20:36] <zyga> stgraber: do you think it's possible to land that fix I sent you?
[20:37] <zyga> grepping dbus in /etc/init shows that nothing is using this feature (start on dbus)
[20:37]  * zyga files a bug on upstart
[20:40] <mlankhorst> can someone drop libx11 from proposed? there's a bug in w3m somewhere which causes a FTBFS for the documentation, no idea how to workaround it yet :/
[20:41] <mlankhorst> tempted to just drop the .txt documentation
[20:42] <zyga> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234393
[20:44] <stgraber> mlankhorst: just upload a fixed package, no need to remove it from proposed
[20:44] <mlankhorst> I have no idea what the fix is yet :/
[20:45]  * zyga calls it a day
[20:47] <slangasek> stgraber: so I haven't wrapped my brain around what that test failure means... is that something you have time to dig into yet today and get upstart unstuck?
[20:47] <slangasek> zyga: I have no hands-on experience with the dbus bridge, sorry
[20:48] <slangasek> zyga: bug report is best :)
[20:54] <stgraber> slangasek: kinda busy trying to finish the sourceforge -> github migration for LXC upstream (big backlog of patches). I may look into upstart later tonight if I find some time though. (I suspect xnox or jodh may be way more efficient at figuring that one out, though I agree it'd be better if we could have it fixed before the UK morning)