[00:26] <jbassett> Hello
[00:26] <jbassett> I have a suggestion for Ubuntu interface, is this the right place to put it forward?
[00:29] <jbassett> A user has an external monitor on a laptop and generally only uses the external monitor when at home, so turns off the laptop screen using the Ubuntu Displays interface.  They have found that unplugging the external monitor in order to wander elsewhere in the home for example, does not automatically reactivate the laptop screen.  In such a use case I would have expected this to have been the case.  I would ther
[00:29] <jbassett> efore recommend such addition or even a checkbox in the Display area to facilitate the toggle of this feature on or off.
[01:28] <sladen> jbassett: it's more likely a particular hardware in a particular laptop causing this behaviour at a lower level
[04:25] <ScottK> TheMuso: Could you have a look at Bug #1127461 ?  It's causing enough problems it's getting blogged about on Planet KDE.  The recommended solution is uninstalling qt-at-spi.
[04:26] <TheMuso> ScottK: Right, I'd say the solution for raring at least is for you to stop shipping qt-at-spi, as the Qt accessibility code for QT4 is no longer maintained, given the move to Qt5.
[04:26] <TheMuso> But I'll take a look.
[04:27] <ScottK> TheMuso: Thanks.  I''m particularly concerned about precise though.
[04:27] <TheMuso> Ah right.
[04:27] <ScottK> The issue, as described in the blog post I saw, affected people in Unity sessions as well.
[04:28] <TheMuso> RIght.
[04:30] <ScottK> TheMuso: I checked and it's not in the Kubuntu seeds, but it is in Ubuntu desktop seed for raring.
[04:31] <ScottK> Thanks for looking into it.
[04:32] <TheMuso> ScottK: Right, a result of people using KDE apps in general. I'll see what I can do, no promises as I am unfamiliar with the code base. Hopefully newer code in the qt-at-spi git repo fixes, it, but I doubt it.
[04:32] <TheMuso> np
[04:32] <ScottK> Thanks.  I pinged you since I saw you did the last upload ...
[04:32] <TheMuso> Fair enough.
[06:33] <pitti> infinity: udev-acl conditional> splendid, thank you!
[06:33] <pitti> Good morning
[07:48] <dholbach> good morning
[08:05] <pitti> stgraber, slangasek, ScottK: I followed up to bug 1153224 with a current status, FYI
[08:07] <pitti> NB that I won't be totally disappointed if you say "not for raring"; I'm mostly pushing for a decision now to see how to go on with this
[08:07] <pitti> (but I think the desktop team and even more so the GNOME Ubuntu flavor teams may want this more than I do)
[08:36] <dholbach> pitti, can you reject texlive-base_2012.20120611-5~12.04_source.changes please - it was meant to go my ppa... O:-)
[08:40] <pitti> dholbach: *zap*
[08:40] <pitti> *splatter*
[08:42] <dholbach> thanks pitti
[08:44] <tjaalton> is the consolekit/logind migration complete now?
[08:47] <pitti> tjaalton: no, still waiting on above FFE
[08:56] <tjaalton> pitti: ok, just wondering if jbicha is/was using some ppa with it that might cause bug 1156074
[08:57] <pitti> could be, following up
[08:57] <tjaalton> I added a question, refresh if it wasn't there yet :)
[08:58] <pitti> ah, I added a similar one
[08:58] <pitti> but it's not a PPA any more actually, you can just use the universe package
[09:13] <pitti> cjwatson: FYI, I committed your aptdaemon updates to bzr, thanks for those! I also added the missing pep8 test dep in bzr now, and looking at the other failed test
[09:17]  * pitti fixes the three PEP-8 violations upstream
[09:26] <mardy> tvoss: hi! Are you subscribed to the ubuntu-phone ML? I'd like to start a topic there about how implementing the keyring on the phone/tablet, and I think that your participation would be very important :-)
[09:26] <tvoss> mardy, I'm subscribed, yes.
[09:27] <tvoss> mardy, I think lool should be involved with the discussion, too. Perhaps explicitly list him as recipient?
[09:27] <tvoss> lool, are you subscribed to ubuntu-phone?
[09:28] <lool> tvoss: yes
[09:29] <tvoss> lool, thx
[09:29] <LyzardKing> I need help with the ubuntu-sdk
[09:30] <LyzardKing> When I run the tutorial  I get errors regarding like file:///usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/Toolbar.qml:112: TypeError: Cannot read property 'visible' of null
[09:30] <LyzardKing> and other similar ones
[09:30] <dholbach> LyzardKing, you might want to ask in #ubuntu-phone or #ubuntu-app-devel
[09:30] <LyzardKing> ok
[09:53] <cjwatson> pitti: thanks
[09:54] <cjwatson> pitti: I think I looked at bzr and it was just an auto-import; I must have been looking at the wrong branch
[09:54] <pitti> debcheckout / Vcs-Bzr: are right
[09:54] <pitti> anyway, I can reproduce the "debian-security/nonfree" failure in a VM
[09:54] <pitti> it works on my normal workstation
[09:54] <mlankhorst> debcheckout? awesome
[09:55] <ogra_> oh, wow, multiarch on my 12.04 desktop fails miserably if i add armhf
[09:56] <ogra_> (apt-get update chokes on security.ubuntu.com)
[10:05] <lool> pitti, cjwatson: woot, should Mark's proposal be on the techboard agenda for today?
[10:05] <pitti> lool: yes, I think it should
[10:05] <lool> pitti, cjwatson: https://lists.ubuntu.com/archives/technical-board/2013-March/001527.html that is
[10:07] <cjwatson> Yeah
[10:07] <cjwatson> pitti: ah, my bad for trusting my old checkout :)
[10:09] <lool> added, thanks
[10:26] <pitti> bdrung: FYI, uploading libsoxr to fix autopkgtest failure
[10:46] <bdrung> pitti: thanks. i will forward your patch upstream.
[10:47] <pitti> bdrung: danke!
[10:47] <bdrung> bitte :)
[10:51] <jamesh> pitti: I was moving some tests for an app over to using your dbusmock library, and found it was leaving dbusmockobject processes hanging around.
[10:52] <jamesh> pitti: the docstrings imply that these processes should automatically exit when the bus they connect to goes away, so is this a bug?
[10:52] <pitti> jamesh: yes, that's a bug
[10:54] <jamesh> pitti: okay.  I added explicit terminate()/wait() calls as the dbusmock examples do.  So I was wondering if it was a code bug or a docs bug
[10:55] <pitti> jamesh: they should listen to their attached bus going down and terminate themselves
[10:55] <pitti> jamesh: yeah, the examples do that manually indeed, but automatic termination sounds nicer
[11:01] <henrix> @pilot in
[11:07] <jamesh> pitti: I filed https://bugs.launchpad.net/python-dbusmock/+bug/1156561 so it won't be forgotten
[11:07] <pitti> jamesh: thanks
[11:19] <melodie> hello
[11:21] <melodie> cjwatson I just read what you told me last night about the dangling symlinks. I will try to give an example, and I was not from outside chroot but once inside then in the live in virtualbox, and after that in the installed os in virtualbox.
[11:36] <pitti> sl-modem-dkms has failed to build for quite a while, as exposed by the ubuntu-drivers-common autopkgtest
[11:36] <pitti> do we still actually care about this one?
[11:40] <lool> pitti: I have an intel graphics card and updated earlier this morning, I have 175-0ubuntu24 and I get LP #1156074
[11:40] <pitti> lool: are you running standard raring with consolekit or logind?
[11:41] <lool> pitti: actually, not sure it's the exact same bug
[11:41] <lool> pitti: I've rebooted and I'm now getting relatively low res graphics
[11:41] <pitti> lool: do you have an acl on /dev/dri/card0 ?
[11:41] <lool> but glxinfo works
[11:41] <lool> yes
[11:41] <pitti> ok, so not the same bug
[11:41] <lool> and I have facl permission on it
[11:41] <pitti> well, at least the one above said it was due to having no ACL
[11:42] <lool> I have consolekit but not logind
[11:42] <xnox> pitti: i'd say we do care about sl-modem-dkms, but it often lags behind linux kernel & debian patches it only up to debian's kernel, which is usually less than ours....
[11:42] <pitti> xnox: there's even a bug for it, but I wonder if I should keep ubuntu-driver-common's tests fail eternally for this
[11:42] <pitti> I guess that autopkgtest should move to sl-modem rather
[11:43] <xnox> pitti: dkms FTBFS tests should be all in each dkms module package. I guess ship a test script in the dkms module, and add/symlink it in each -dkms package?
[11:43] <lool> apparently, xrandr believes I have a screen connected when I dont
[11:44] <xnox> pitti: ... or with some jenkins magic auto-add them the way autopkgtests are added?
[11:44] <pitti> xnox: that'd be possible, yes; I also have some test in u-d-common to detect that sl-modem is necessary, but that one could drop the actual installation
[11:46] <xnox> pitti: /me ponders about dh_installdep8 which would detect and add typical tests (e.g. initctl checkconf for all upstart jobs, dkms module FTBFS, abi-compliance-checker)
[11:48] <pitti> tseliot: so we have a nvidia-experimental-304 AND nvidia-304? same with -310?
[11:48] <tseliot> pitti: do you mean in raring?
[11:49] <pitti> tseliot: as nvidia-current isn't what it used to be any more, I'm adjusting u-d-common's autopkgtests and wonder which versions we shoudl cover
[11:49] <pitti> tseliot: yes
[11:50] <tseliot> pitti: I don't remember if I'm doing this already but ideally nvidia-experimental-304 should be a transitional package of 304 (or maybe 304-updates), same as with 310 and its experimental flavour
[11:50] <pitti> apparently not
[11:51] <pitti> also, we have a nvidia-313-updates, but no nvidia-313, is that intended?
[11:51]  * pitti adds -310 to autopkgtest
[11:52] <tseliot> pitti: ok, I'll deal with the transitional packages this week. Furthermore, 313 is not an LTS series, so it won't get a non updates flavour
[11:53] <pitti> ok, so I'll just add a test for 313-updates
[11:53] <tseliot> right
[12:16] <melodie> cjwatson in the installed version, in Virtualbox, here are the results for "find -L /usr -l", the for /etc then for /var:
[12:16] <melodie> http://pastebin.com/0cjYFLv2
[12:16] <melodie> http://pastebin.com/Bim1Mk3m
[12:16] <melodie> http://pastebin.com/D4kBPDMQ
[12:17] <melodie> I will start the live version in vbox just now and do the same to compare
[12:17] <mlankhorst> for MRE's and backports of those MRE's to the lts-stack, do I need to run piglit for both on all hardware, or is a smoke test for the lts-stack enough?
[12:29] <cjwatson> melodie: ah, OK; well I suppose you could clean up the help symlinks, but that will just mean that if people install the langpacks later then they won't get localised help whereas otherwise they might have done
[12:29] <cjwatson> i.e. it's intentionally breaking stuff for the sake of a few inodes, which is rarely worth it
[12:29] <cjwatson> Some of the /usr/share/doc/ ones are probably bugs
[12:30] <cjwatson> No idea where /usr/lib/pkgconfig/python2.pc comes from, I don't have that here - but probably a bug
[12:30] <melodie> cjwatson this is what I thought (languages sake) when I saw what the major number of lines were : not worth trying to remove them
[12:30] <melodie> perhaps ?
[12:30] <cjwatson> Indeed, I don't think this is worth even the amount of time spent discussing it so far :)
[12:31] <cjwatson> It will have only a negligible effect on the system
[12:31] <melodie> cjwatson yes, but I could not know before trying to discover why it was there
[12:31] <melodie> thank you very much
[12:31] <cjwatson> It might be worth tracking down why some of the other symlinks (i.e. not the obvious localised ones) are dangling
[12:32] <cjwatson> libnss_db.so is odd too
[12:32] <melodie> it might be there after I removed some packages to priviledge others
[12:33] <melodie> I look in my install to see if I find a clue
[12:34] <melodie> in my install it is also a dangling link and it points to /lib/i386-linux-gnu/libnss_db.so.2
[12:34] <xnox> some of the automatic package mangling-foo was spotted to generate broken symlinks in /usr/share/doc in the past. Also it seems like a few things are "waiting" on language packs, if all of them were installed most of gnome-docs would be fine.
[12:35] <xnox> python2.pc looks like a bug it should be python.pc only.
[12:38] <melodie> hi xnox, is this likely to lead to improvements ?
[12:38] <xnox> melodie: no.
[12:39] <melodie> not important enough ? :)
[12:39] <melodie> ok, I go work on something else thank you
[12:39] <xnox> melodie: installing all language packs, will just use up a lot of disk-space. These documentation dangling symlinks is actually an optimisation, we bundle all translations in language-packs, such that one doesn't carry ~ 4GB of translations to languages one does not speak.
[12:40] <xnox> (~4GB of translations can be stripped from default Mac OS X installation last time I did it)
[12:40] <melodie> xnox I was asking about the two dangling links which should not be there and which you consider as probable bugs
[12:41] <melodie> I know all language packs can't be inside a 700 MB max iso
[12:41] <xnox> melodie: the only "win" will be a couple of bytes saved from the entries in the file system. I'd think one would win more by removing a single /usr/share/doc/$package/changelog.Debian.gz
[12:42] <xnox> (which was proposed to do by default in the past)
[12:43] <melodie> and it seems these broken links don't even take any space
[12:44] <xnox> melodie: yeah broken links are almost zero cost in terms of disk space.
[12:47] <melodie> in my system, python2.pc points to -> python-2.7.pc
[12:47] <melodie> which does not exist
[12:47] <melodie> it is is Precise
[13:10] <xnox> melodie: yeap, cause it's multiarched.
[13:12] <xnox> see /usr/lib/x86_64-linux-gnu/pkgconfig/
[13:13] <melodie> xnox ok, then I suppose it is normal
[13:13] <melodie> I don't have a 64bits system here
[14:59] <bdrung> xnox: re debian bug #703323, can you update the man page?
[15:02] <xnox> bdrung: *sigh*, yes.
[15:02] <bdrung> xnox: i am merging the ubuntu change back to debian, but the tests fail in experimental.
[15:03] <pitti> there, 9 autopkgtest failures less than than this morning
[15:03] <xnox> bdrung: i had no test-failure here. Is it related to ubuntu's switch to python3, which is not possible in debian yet?
[15:03] <xnox> (here as in ubuntu)
[15:04] <bdrung> xnox: yes. the python3 switch is possible in debian too. i poked the file maintainer to add python3 support and he did it.
[15:05] <bdrung> xnox: http://paste.debian.net/242557/
[15:05] <xnox> bdrung: interestingw, will look into it later.
[15:15] <bdrung> xnox, tumbleweed: the test suite is broken: http://paste.debian.net/242561/
[15:15] <bdrung> the test fails even if the timeout is set to 10 mins.
[15:16] <xnox> bdrung: what if you revert my adding a new option? or is that even with /bare/ devscripts without my patch?
[15:17] <bdrung> xnox: i haven't applied your patch. so it's not the fault of your patch. you can try building devscripts 2.13.0ubuntu1 on experimental with the same result.
[15:18] <xnox> bdrung: fun.
[15:46] <bdrung> tumbleweed: do you object to add a copy of devscripts.logger to ubuntu-dev-tools?
[15:55] <xnox> bdrung: i'm for it. that means dropping python2 module from devscripts on ubuntu side and syncing ubuntu-dev-tools from debian once again =)
[15:56] <xnox> i mean the devscripts.logger delta will go away, and we can switch to python3 on debian side as well that s.
[16:07] <hallyn> all right so to get openbios-sparc, i guess i'd need to look at gcc-ppc-linux-gnu and get the analogous for sparc
[16:09] <ogra_> janimo, sad, you arent in #ubuntu-release ... you just missed the dead of cdimage-private :)
[16:11] <janimo> ogra_, I got a mail from LP with the WIs set to DONE so did not miss it :)
[16:11] <ogra_> oh, there were still WIs ?
[16:11] <ogra_> haha
[16:12] <janimo> ogra_, yes, there was an old blueprint
[16:12] <ogra_> yeah, i was looking for it but couldnt find it
[16:13] <janimo> ogra_, https://blueprints.launchpad.net/ubuntu/+spec/ubuntu-arm-p-image-build-tools
[16:13] <ogra_> ah, there it is
[16:13] <ogra_> i guess i wasnt subscribed
[16:13] <ogra_> i searched in my mail
[16:14] <cjwatson> I happened to run across it the other day and thought I might as well claim them
[16:23] <bdrung> xnox: okay. i will do that after the build failure ( http://paste.debian.net/242557/ ) is fixed.
[16:38] <henrix> @pilot out
[16:57] <lamont> bdmurray: around?
[16:57] <lamont> update-manager -d tells me: The requested URL /ubuntu/dists/raring/main/dist-upgrader-all/current/DevelReleaseAnnouncement.html was not found on this server.
[16:58] <lamont> bdmurray: is that expected?
[16:59] <jbicha> stgraber: could you upload a newer lintian version as suggested at https://lists.ubuntu.com/archives/ubuntu-release/2012-December/002140.html ? I noticed that my computer still had the old one installed
[17:03] <stgraber> jbicha: I think the hope was that we would be able to sync from Debian and get something slightly higher than what we have in extra. I'd have to check what they have in Debian nowadays. Will try to do that once I'm done with my meetings
[17:03] <bdmurray> lamont: that's from a quantal system?
[17:03] <lamont> current quantal running update-manger -d
[17:03] <lamont> quantal + security + udpates only
[17:03] <bdmurray> lamont: okay thanks
[17:04] <lamont> bdmurray: does it deserve a bug?
[17:04] <psusi> smoser: it seems some work has already been done to accelerate d-i... it no longer uses debootstrap, but copies a pre debootstraped squashfs for the base install... scaling this up a  bit may get you to where you want for fastpath install... adding eatmydata for the subsequent part of the install took my total install time for 7m to 3m, how fast did you have in mind?
[17:04] <bdmurray> lamont: no, I'll just try and fix it
[17:05] <lamont> 0.192.4 had the file, 0.192.5 dropped the .html versions
[17:05] <bdmurray> lamont: the file is really missing http://archive.ubuntu.com/ubuntu/dists/raring/main/dist-upgrader-all/current/
[17:05]  * lamont finally notices that there is still an 'upgrade' button at the bottom of things
[17:06] <lamont> bdmurray: it is in fact
[17:06]  * lamont actually went and verified it on the master
[17:07] <smoser> psusi, well,it is much faster, yes. and that avoids many dpkg -i.
[17:08] <smoser> however, it still makes sense to use eatmydata for *all* dpkg during an install (squashfs just gets the "base image"), and then any additional packages are installed with dpkg.
[17:09] <psusi> smoser: right.. I tested that and it dropped install time from 7m to 3m
[17:09] <xnox> slangasek: why unionfs? =) we got overlayfs in nexus7 landing soon and heading upstream as well.
[17:09] <psusi> scaling up the squashfs to contain more of a typical virtual install instead of just required/important packages might be a way to improve on it too
[17:10] <cjwatson> it's the minimum subset of all the possible things that that image can install
[17:10] <cjwatson> or was last I checked
[17:10] <psusi> cjwatson: right... it's just required/important packages, i.e. what debootstrap used to install
[17:11] <cjwatson> I know what it is - my point is that it can't be expanded without suddenly having to teach other bits of d-i about how to *remove* packages
[17:11] <psusi> but you could add in more packages if you wanted to.. so maybe identify the set of packages that all cloud installs will want and throw them in too
[17:11] <cjwatson> I started out with it larger and had to scale it back
[17:11] <psusi> ohh, right.. adding packages means they basically aren't optional to install any more
[17:11] <cjwatson> it could be expanded to standard if the server team decided to drop the minimal-virtual-machine install type
[17:12] <cjwatson> (I think I discussed this with the server team at the time)
[17:12] <psusi> or if you choose to do that, then fall back to debootstrap instead?
[17:12] <cjwatson> can't, files aren't present
[17:13] <psusi> ohh, wait.. the required and important packages have already been removed from the pool?
[17:13] <cjwatson> from the CD image pool
[17:13] <psusi> ahh... nice...
[17:13] <cjwatson> also the bootstrap-base udeb isn't present
[17:14] <psusi> wait.. what about a dual squashfs?  one with the base, and a second one with -standard?  then you just unpack the second one after the first, or not..
[17:15] <cjwatson> if somebody can figure out how the heck to make it all work *shrug* - I think dropping the minimal vm install type is a much more rational use of time personally
[17:15] <psusi> I agree
[17:16] <xnox> cjwatson: psusi: well there are server images with squashfs containing everything pre-installed what is needed to become an openstack node and it's in use in the jenkins lab for automatic bare-metal deployment of openstack clouds.
[17:17] <xnox> see qa talk from fosdem by james page.
[17:17] <xnox> there is ongoing work to open up this method and make it more generic and less speciliased on openstack-only.
[17:17] <xnox> it's the fastpath installer work.
[17:19] <smoser> xnox, well, i'm not sure what jamepage said at fosdem.
[17:19] <xnox> smoser: =)))))
[17:20] <smoser> but the fast path installer largely overlaps with much of what d-i does.
[17:20] <smoser> and doesn't use squashfs images.
[17:20] <xnox> smoser: it was so fluid and so well rehersed everyone believed anything he was saying ;-)
[17:21] <psusi> xnox: it sounded to me like the current proposal for fastpath is to reinvent a whole new installer, rather than modify d-i... I'm just pointing out that maybe modifying d-i would be better and doable ( and some work has already been done )
[17:24] <slangasek> xnox: I'm using unionfs as a generic term here
[17:24] <ogra_> xnox, slangasek, dont forget that we have to deal with (possibly old) android kernels when aiming for union/overlayfs
[17:25] <bosyi> hi. i have problem in 13.04. after awaking from sleep notebook gets slow. mouse pointer move like with delay.
[17:25] <bosyi> it's ok to ask here?
[17:25] <ogra_> nexus7 should be safe though, we use the same in the desktop and touch images
[17:26] <xnox> slangasek: ack.
[17:26] <ogra_> but in general i think it will make porting for people problematic if we require huge kernel changes
[17:28] <xnox> slangasek: ack.
[17:28] <xnox> bosyi: no. #ubuntu+1 is a better channel.
[17:29] <bosyi> xnox: thanks
[17:44] <seb128> xnox, cjwatson: hey, is there any known issue with the installer and username pre-seeding?
[17:45] <cjwatson> The only thing I've heard of that's related is bug 1155704, but I suspect that's a wider problem
[17:45] <seb128> cjwatson, http://ubuntuone.com/6g6zED1AQpXiDFmAL6qJ0H
[17:45] <xnox> seb128: not that I know of, but u1 plugin started to fail for me with today's images.
[17:45] <seb128> xnox, ^
[17:45] <seb128> the username in the error is "root"
[17:45] <seb128> where the entry has "jenkins"
[17:45] <cjwatson> I certainly haven't changed anything near there in ages ...
[17:45] <seb128> k
[17:46] <cjwatson> Would need to see logs I guess, ideally debug logs
[17:46] <seb128> could be a #qa issue
[17:47] <seb128> cjwatson, thanks, I'm asking the #qa guys to come here to discuss it directly
[17:47] <seb128> mmrazik is the one who got the screenshot
[17:48] <seb128> but he doesn't have access to the logs apparently
[17:48] <seb128> mmrazik, hey ;-)
[17:48] <mmrazik> cjwatson: let me fwd the screenshot
[17:48] <cjwatson> screenshots aren't logs :)
[17:48] <seb128> mmrazik, I shared the screenshot
[17:48] <cjwatson> seb128 already posted the screenshot
[17:48] <mmrazik> great
[17:49] <cjwatson> 17:46 <cjwatson> Would need to see logs I guess, ideally debug logs
[17:49] <mmrazik> cjwatson: what are logs? /var/log/syslog?
[17:49] <mmrazik> cjwatson: its going to be a bit difficult, though
[17:49] <mmrazik> as the machine has no networking AFAICS and is in Lex
[17:50] <cjwatson> /var/log/installer/syslog
[17:51] <cjwatson> well, /var/log/syslog at this stage actually
[17:51] <cjwatson> and /var/log/installer/debug
[17:51] <mmrazik> nuclearbob: do you have access to any of those ^ ?
[17:51] <cjwatson> feel free to come up with a way to reproduce the problem that doesn't involve jenkins in a remote lab ...
[17:51] <nuclearbob> mmrazik: I can look at them over a kvm-over-ip and get screenshots, I'm trying to find a better way to get them on the machine
[17:51] <nuclearbob> yeah
[17:52] <nuclearbob> I can try the same preseed on a bm
[17:52] <nuclearbob> *vm
[17:53] <slangasek> hallyn: edk2 persistence issues> so step one is to figure out how to do a proper debugging build of ovmf, since I'm failing at that so far ;) any ideas?
[17:54] <cjwatson> xnox: I'm still testing, but any opinions on http://paste.ubuntu.com/5625860/ and http://paste.ubuntu.com/5625861/ ?  It seems to have improved things for the ruby1.8 build, at least
[17:54] <cjwatson> (As in it actually detects Tcl/Tk now)
[17:55] <mmrazik> nuclearbob, cjwatson: I'll have the logs in a minute
[17:56] <hallyn> slangasek: no.  but i need to learn about the upstream source and package, so i'll look into that.
[17:56] <cjwatson> whoopsie dialog of the day: "Sorry, the application crash.jar has stopped unexpectedly"
[17:56] <cjwatson> Ya think
[17:57] <mlankhorst> :X
[17:57] <mlankhorst> it didn't crash in the way it should, perhaps?
[17:57] <cjwatson> I think it's part of the apport testsuite
[17:57] <ev> poor whoopsie, always taking a bad rap for apport
[17:57] <cjwatson> Yeah, my bad, had the wrong package that pops up annoying dialogs :)
[17:58] <ev> cjwatson: everyone conflates the two :)
[17:58] <mmrazik> cjwatson: /var/log/syslog: http://pastebin.ubuntu.com/5625877/
[17:58] <tumbleweed> bdrung: no
[17:59] <mmrazik> cjwatson: /var/log/installer/debug: http://pastebin.ubuntu.com/5625879/
[17:59] <cjwatson> mmrazik: is it possible to start the machine with the 'debug-ubiquity' boot parameter?  things are a lot more informative that way
[18:00] <mmrazik> nuclearbob: I actually don't know how to do that easily with utah, etc ^^^
[18:02] <nuclearbob> mmrazik: adding -b debug-ubiquity to the utah command line should do it, I can try that as well
[18:02] <mmrazik> nuclearbob: thanks
[18:02] <mmrazik> I need to leave soon
[18:03] <nuclearbob> recreating this on a VM doesn't seem to be working either, unfortunately and to nobody's surprise
[18:21] <xnox> cjwatson: looks correct. as long as nothing drops out of main, like with my first defaults upload ;-)
[18:21] <cjwatson> As in tcl-lib?  I think I avoided that trap
[18:21] <infinity> xnox: If at first you don't succeed?
[18:22] <xnox> cjwatson: yeah. I think you did it all correctly.
[18:24] <cjwatson> xnox: I might wait until tomorrow morning to upload it, since I'm getting pretty tired and prefer to be fresh before hitting enter on this kind of thing.  But I do seem to have managed to climb up to the point where ruby-ffi builds, which was the original point of this yak-shaving exercise.
[18:26] <jmleddy> cjwatson: hi there
[18:27] <cjwatson> jmleddy: Finishing for the day as the above indicates.  Is it quick?
[18:28] <slangasek> cyphermox: hmm, what needs "solved" wrt polkit/consolekit on the tablet for NM?
[18:28] <cyphermox> slangasek: err, I don't know?
[18:28] <slangasek> cyphermox: I ask because of the ongoing ck->logind migration discussion
[18:28] <cyphermox> ok
[18:28] <jmleddy> cjwatson: yeah, I was just wondering if you had an estimate for bug 967229
[18:28] <slangasek> cyphermox: oh; sergio just assigned a work item to you for it :)
[18:29] <cjwatson> jmleddy: I thought that had been handed over to bdmurray
[18:29] <cyphermox> ok
[18:29] <cyphermox> can you link?
[18:29] <jmleddy> slangasek: particularly the part about starting plymouth before lightdm stops
[18:29] <cjwatson> It came up a foundations meeting or two ago
[18:29] <jmleddy> cjwatson: yes, I think he is working on it
[18:29] <cjwatson> I haven't heard anything about progress
[18:29] <cjwatson> bdmurray: ^- ?
[18:30] <slangasek> jmleddy: hrm, you aren't mixing up me and cjwatson, are you? :)
[18:30] <jmleddy> slangasek: oh, perhaps o_O
[18:30] <slangasek> sweet
[18:30]  * slangasek dyes his hair
[18:30] <jmleddy> slangasek: I though he jumped in
[18:30] <cjwatson> He's the talented one, I'm just ruggedly handsome
[18:30] <bdmurray> slangasek's last idea did not improve the situation
[18:30] <jmleddy> haha,
[18:31] <slangasek> bdmurray: improved vs. what?
[18:31]  * cjwatson goes to try to scavenge dinner, in a hunter-gatherer kind of way
[18:31] <bdmurray> I still see messages when shutting down
[18:31] <slangasek> jmleddy indicated that clearing the VT before lightdm starts takes care of some of it
[18:32] <jmleddy> bdmurray: slangasek: basically a manager asked me for a date when we would have a complete fix (ie, plymouth starts before lightdm stops)
[18:32] <slangasek> and clearing the VT /after/ lightdm starts will take care of more of it
[18:32] <jmleddy> huh, I had success with turning the text color black and clearing the vt
[18:32] <slangasek> bdmurray: so from my POV, this is a per-se correct change to the lightdm job
[18:33] <slangasek> well, turning the text color black is a workaround
[18:33] <jmleddy> agreed
[18:33] <jmleddy> but yeah even just doing a clear > /dev/tty7 fixed it for the startup text
[18:33] <jmleddy> still saw services shutting down though
[18:33] <bdmurray> right, and that is what I still see
[18:34] <slangasek> bdmurray: so we do need to clear at boot, even though that doesn't solve the full problem for shutdown; can you drive that piece forward on lightdm?
[18:34] <jmleddy> bdmurray: okay, that makes more sense
[18:34] <slangasek> for shutdown, I think we need to change things so that the plymouth /daemon/ starts before lightdm stops, so that we get the console indirection in place, but that we only start the plymouth /splash/ after lightdm exits
[18:35] <bdmurray> slangasek: right clearing on boot solves logout and log back in issues
[18:35]  * slangasek nods
[18:35] <jmleddy> slangasek: how hard is that to change?
[18:35] <slangasek> jmleddy: it's easy to change, hard to get right
[18:35] <slangasek> the ordering of all of this is fiddly and the architecture is not fully documented
[18:36] <jmleddy> okay
[18:36] <slangasek> but basically, the plymouth upstart jobs need to be split differently
[18:36] <jmleddy> I think as long as we're actively working on it I can hold off the OEMs
[18:36] <bdmurray> I believe the ordering is the last thing we'd talked about and the change had no effect
[18:36] <slangasek> bdmurray: which change?
[18:37] <jmleddy> but ideally they'd like to have a target for when this will be fixed
[18:38] <infinity> I suppose there's a reason why the old "start the splash from the DM on shutdown" method that we used eons ago doesn't work?
[18:38]  * infinity has always been a bit annoyed that this used to be a solved problem until it was all torn out.
[18:38] <slangasek> infinity: you still have to stop the X server first
[18:39] <infinity> Is that actually true in a KMS world?  The kernel is perfectly happy with writing my oopses to the same FB as my X session.
[18:39] <infinity> s/oopses/panics/
[18:40] <slangasek> infinity: the X server has to be stopped before you can start the plymouth splash.
[18:40] <slangasek> because only one process can own the VT at a time
[18:40] <slangasek> and it's important that the VT have an owner
[18:40] <infinity> Well, yes, I get what you're saying.  I'm arguing that if that's true, it may be a design/implementation issue with plymouth, not actual architectural fact.
[18:40] <bdmurray> slangasek: http://pastebin.ubuntu.com/5626006/
[18:41] <infinity> Anyhow, that same limitation should have been true with gdm and usplash too.  How did my old splash-down crap handle it?
[18:41] <infinity> Oh, I didn't use the same VT as X, I bet.
[18:41] <infinity> So, I did a chvt, then splashed away.
[18:41] <slangasek> now, this doesn't mean that X has to switch it into text mode when it exits, but in most cases it *is* important that X switch back to text mode, so implementing this correctly means changes to the X server and lightdm
[18:42] <jmleddy> infinity: to me, that's the ideal solution, put the kernel console to a different vt
[18:42] <slangasek> switching to a different VT still implies a race
[18:42] <infinity> jmleddy: This is what we used to do.  There's exactly one valid and cool argument not to, which is panics.
[18:43] <slangasek> it doesn't matter which VT you're on if that VT is in text mode (however briefly in theory) and things are writing to it
[18:43] <jmleddy> infinity: yeah, that's what I was worried you would say ;)
[18:43] <slangasek> the point is that we should *not* have services writing to the desktop's console on startup/shutdown except in the case of errors (panics)
[18:43] <infinity> slangasek: You bind your splash to a VT, then chvt to it.  In that order.
[18:43] <infinity> slangasek: But yes, we shouldn't have output in the first place, I agree.
[18:44] <slangasek> bdmurray: so given that didn't help, can you post a screenshot to the bug of what output you were still seeing?
[18:45] <bdmurray> slangasek: sure
[18:58] <bdmurray> slangasek: added
[19:17] <slangasek> bdmurray: thanks; that's more or less consistent with the remaining race condition I expected (although I don't know why acpid is talking to the console since it's an upstart job that doesn't have 'console' set), I think the next step is to think about changing /etc/init/rc.conf to no longer be 'console output'
[19:17] <slangasek> bdmurray: but I think we need to coordinate this with the server team to make sure we don't disrupt that case
[19:18] <slangasek> smoser: what's the right answer for where init script and upstart job start/stop messages should be going on the server images (and cloud in particular)?
[19:20] <smoser> slangasek, i dont know what the right answer is.  cloud-init jobs writes with 'console output'.
[19:20] <smoser> but even that is proxied through plymouth.
[19:21] <slangasek> smoser: I'm not asking about the mechanism, I'm asking about where you want it to show up
[19:21] <smoser>  /dev/console is right.
[19:21] <slangasek> ok
[19:21] <smoser> the fact that that is busted in some cases is something that has to be fixed.
[19:21] <slangasek> yep
[19:22] <smoser> slangasek, do you have thoughts on a more appropriate place?
[19:22] <smoser> (other htan /dev/console)
[19:22] <slangasek> no, my opinion doesn't matter :
[19:22] <slangasek> :)
[19:22] <slangasek> this is for the server team to decide where they want these messages to go
[20:05] <lool> cjwatson, pitti: Sorry, where/when is the techboard meeting?
[20:05] <lool> fridge suggests it's either now or was an hour ago on #ubuntu-meeting, but nothing there
[20:06] <stgraber> lool: in an hour in #ubuntu-meeting
[20:06] <mdz> my calendar says now
[20:06] <stgraber> lool: the meeting time is 21:00 London time
[20:06] <ogra_> fridge too
[20:06] <mdz> bloody time zones
[20:07] <lool> thanks
[20:07] <mdz> who is chairing? I can't find the minutes and have a funny feeling that it's my turn
[20:07] <stgraber> mdz: hehe, I actually just went to the agenda to confirm myself as I wasn't sure with the DST change :)
[20:07] <ogra_> lol, then you picked a really bad one to chair
[20:07] <stgraber> mdz: you're chairing
[20:07] <stgraber> mdz: or so we said at the end of last meeting
[20:07] <mdz> ok
[20:07] <mdz> who chaired that meeting? they didn't send out minutes yet
[20:08]  * ogra_ humms .... ".... rollin, rollin, rollin .... "
[20:08] <cjwatson> My calendar says now, but it's DST confusion month
[20:08] <cjwatson> An hour from now works better for me, but meh
[20:09] <mdz> I have a conflict but I think I can juggle it
[20:09] <stgraber> mdz: kees was the last chair
[20:10] <stgraber> cjwatson: I remember us deciding to pin it to whatever timezone London happens to be on, but I guess the fridge is still tied to some other random timezone...
[20:10] <ogra_> fridge says GMT at the bottom
[20:10] <stgraber> ogra_: right, so that's wrong ;)
[20:11] <mdz> why is the meeting scheduled for so late in the day? seems odd given our composition
[20:11] <cjwatson> Who the hell knows what calendars are going to do
[20:11] <ogra_> heh
[20:11] <stgraber> mdz: not sure, but I'm not particularly looking forward to going through the whole doodle mess again if we can avoid it ;)
[20:12] <cjwatson> I think Keybuk had a problem with the earlier time when he was on the board
[20:12] <cjwatson> Anyway, if we're doing it now I'd like it if we could start :)
[20:12] <stgraber> anyway, it'll move an hour earlier for all the US+Canada folks by next meeting as Europe will have its DST change by then too (that's assuming I'm not doing DST backwards, which I've been known to do on occasion, damn I hate that thing)
[20:13] <mdz> I've changed the Google calendar to schedule it for 2100 London time going forward
[20:13] <mdz> including today
[20:13] <cjwatson> Aha
[20:13] <cjwatson> yay
[20:13] <stgraber> mdz: nice, thanks!
[20:13] <sarnold> London Time isn't the same as UTC.
[20:13] <cjwatson> I shall wander off for 45 mins then
[20:13] <cjwatson> sarnold: We know
[20:13] <sarnold> okay :)
[20:14] <stgraber> mdz: good to know you've got power over that Calendar. I always had to randomly poke people within Canonical until I find someone had access
[20:14] <cjwatson> That is the point
[20:14] <sarnold> (incidentally, having a UTC clock widget in our phone would be keen. :)
[20:14] <mdz> stgraber, I've always set it to "guests can modify"
[20:14] <stgraber> sarnold: we're using London as a UTC+DST so we don't need to re-schedule twice a year for DST
[20:14] <stgraber> mdz: ah, cool, was I a guest? I can't remember seeing an invite for it until just about now when you changed it :)
[20:14] <sarnold> stgraber: aha :)
[20:15] <lool> you guys should rather have it at 2200 Paris time, it would feel less rainy
[20:17] <mdz> stgraber, you were already a guest when I looked at it today
[20:17] <stgraber> I don't know what's that whole thing about London and rain, I can't recall ever seeing any rain over there! (yeah, I've been there THOSE two weeks)
[20:17] <stgraber> mdz: hmm, okay
[20:17] <mdz> you should have an "edit event" link when you look at it
[20:17] <mdz> (as opposed to "more details")
[20:18] <lool> cjwatson: bzr branch lp:ubuntu-cdimage: bzr: ERROR: No such file: 'buildlive-20130315144326-j37epwgp79kvsxht-1'
[20:18] <stgraber> mdz: ah, I know why, I think Google can't cope with the fact that my @ubuntu.com isn't hosted on gmail
[20:19] <lool> bzrin surgery needed
[20:19] <mdz> stgraber, ah, yes
[20:19] <mdz> it only works if your address is associated with a gmail or google apps account
[20:19] <mdz> stgraber, let me know if you have another address I should add
[20:20] <lool> stgraber: ah so you had snow I guess?  ;-)
[20:21] <bryce> btw I posted an mre proposal for xserver to the tb list; it's in the moderation queue
[20:21] <stgraber> lool: I wish ;) it was just grey and cold though I vaguely remember being there one day where we could actually see the sun ;)
[20:29] <slangasek> awe_: ping
[20:47] <awe_> slangasek, pong
[20:53] <slangasek> awe_: hey, so cyphermox tells me NM (or rather, consolekit) isn't happy on the phablet snapshots, and that there's some different plan for dealing with this on Mir
[20:54] <slangasek> awe_: I'd like to make sure we're on the same page regarding what that "different plan" is, given that we have a migration from ck to logind in flight
[20:54] <awe_> you are correct sir
[20:54] <slangasek> and logind is *not* tied to X, and I was expecting we would be converging around logind
[20:54] <awe_> we disabled polkit & session tracking due to the lack of X
[20:54] <awe_> was a bit of a short-cut
[20:55] <awe_> slangasek, ricmm has an action item on the Mir blueprint, but I left an item for cyphermox to coordindate with the Mir team
[20:55] <slangasek> ok
[20:55] <slangasek> ricmm: ping
[20:55] <slangasek> :)
[20:56] <cjwatson> lool: hmph
[20:56] <awe_> slangasek, I think their plan involved logind too.  ;)-
[20:57] <cjwatson> I might repush - had a stacking problem earlier
[20:57] <slangasek> awe_: I hope so, but want to confirm ;)
[20:57] <awe_> no prob
[21:00] <awe_> slangasek, we need to schedule a power mgmt session later this week.  Who on your team should invite?
[21:01] <slangasek> awe_: "power mgmt" being rather broad, can you be more specific?  there isn't currently anybody on Foundations assigned to power mgmt, unless they've been taking WIs on the side that I haven't seen yet ;)
[21:01] <awe_> power mgmt plumbing on ubuntu touch
[21:01] <awe_> ( or lack thereof )
[21:02] <slangasek> awe_: in practice, I think pitti is the domain expert on our PM stack
[21:02] <slangasek> awe_: we can certainly participate, but I think you'll find it's more important to have pitti there
[21:02] <awe_> ack
[21:03] <awe_> if you think of someone else you'd like to be involved, let me know.  Will probably shoot for Wed/Thur
[21:05] <ricmm> slangasek: pong
[21:06] <cjwatson> lool: try again now
[21:06] <slangasek> ricmm: hi, question came up regarding NM session management and the future of consolekit wrt Mir
[21:07] <slangasek> ricmm: it's been implied that there will be "a solution" for session management in Mir, and I want to make sure it's aligned with the work we're doing to replace ck with logind
[21:07] <ricmm> slangasek: right, we did take a shortcut before demo by disabling session tracking, pk and ck
[21:08] <ricmm> I have a WI to bring a discussion forward about the convergence of Mir+lightdm to plug the holes in ubuntu-touch
[21:08] <ricmm> I didnt think of it in terms of CK -> logind at the time but it can be all part of the same
[21:08] <ricmm> we can either leave mine or your action item and just do a bigger discussion with tvoss and others
[21:08] <ogra_> awe_, slangasek, i'm not volunteering for WIs, but have some experience with cpufreq governor stuff on arm, so i'l like to attend ...
[21:09] <lool> cjwatson: woot!  thanks
[21:09] <slangasek> ricmm: well, we are getting rid of ck and replacing it with logind; this solves the X dependency problem; so anything further that's needed for Mir should be limited to logind integration
[21:09] <cjwatson> lool: Great.  Things can get a bit confusing if you switch the development focus branch around in an incautious order
[21:09] <slangasek> ricmm: as long as we're on the same page, I don't think I need to be directly involved - I just wanted to make sure nobody was thinking in terms of NIHing something else
[21:10] <awe_> ogra_, ack
[21:10] <ricmm> slangasek: ok, I'll track this from the Mir side of things then
[21:10] <slangasek> ogra_: +1
[21:10] <slangasek> ricmm: perfect, thanks
[21:10] <awe_> ogra_, do you remember who it was that did the analysis of the power code in gsd recently?  Was it seb?
[21:11] <ogra_> awe_, i dont remember exactly, but i think jibel did some stuff there
[21:11] <awe_> alright, I'll ping seb in the morning.
[21:14] <xnox> awe_: there was seb, gemma, plars and pitti doing extensive power measurement & hacking at the n7-squeeze-it-down sprint week.
[21:15] <awe_> thanks xnox!
[21:15] <marga> I'm trying to debug a crash in gnome-screensaver.  I have the debug package and I have the core dump, but I my bt is still just ??... is there anything I can do to get more info>
[21:15] <xnox> awe_: then based on their graphs there was a clear indication what to target, which the rest of us did.
[21:17] <awe_> xnox, fyi, this conversation is more of an architecture discussion focused on Ubuntu Touch, than measurement/targets ( which are important too ).
[21:18] <xnox> awe_: i was just observing =) but together they should be able to answer anything top->down and bottom -> up.
[21:18] <ogra_> and i guess much of the data isnt relevant
[21:18] <ogra_> since it was measuring desktop setups only
[21:18] <ogra_> and apps there speccifically
[21:18] <ogra_> -c
[21:19] <awe_> xnox, sure... I think most of them are on my short list, but appreciated
[21:19] <xnox> ogra_: yeah, android kernel has special hooks to measure on per app basis, which mainline does not....
[21:19] <ogra_> well, and a totally different userspace
[21:19]  * xnox is educated more about android kernels after recent lwn.net article about "what's the delta between android and mainline today"
[21:23] <lindi-> marga: check /proc/$pid/maps to see which ELF file is mapped to the address where you see just ??
[21:24] <marga> lindi-, this crash report was not created in my machine... Which pid would that be?
[21:24] <lindi-> marga: ah, and you can't reproduce the crash?
[21:25] <marga> Not likely... It's a gnome-screensaver crash that is triggered randomly after some amount of inactivity
[21:25] <lindi-> marga: I'm bit unfamiliar with ubuntu crash report but there should be ProcMaps.txt?
[21:26] <geofft> marga, have you played with apport-retrace?
[21:26] <marga> geofft, retrace complains that the crash doesn't include a Package.
[21:26] <marga> lindi-, yes, I do have ProcMaps
[21:27] <geofft> you could try faking that file. :) but hmm, I'm surprised by that if it's actually in gnome-screensaver
[21:28] <lindi-> marga: each line in ProcMaps has an address range, now just find out which file was mapped to that mysterious address where you only got "??" in the backtrace
[21:29] <lindi-> marga: might be easier to explain if I'd have some concrete example at hand
[21:29] <marga> ok, I think I found it.  It's a file in dconf-gsettings-backend.  Will install that debug deb and see if I get real info. Thanks
[21:30] <marga> No, still ?? :(
[21:31] <marga> The address is: 0x00007f45bc27415c. ProcMap says 7f45bc270000-7f45bc277000 is mapped to /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
[21:33] <geofft> If you want entirely too much info, you can run objdump -d on that file (pipe to less, probably)
[21:33] <geofft> and look at offset 0x415c within it
[21:33] <geofft> on my quantal machine it's in g_io_module_query
[21:34] <geofft> right after a call to g_queue_is_empty and a conditional jump
[21:34] <geofft> which should be enough to find it in the source, if you're inclined.
[21:37] <marga> Ok, this is precise so it's probably something else, but I'll take a look, thanks.
[21:40] <lindi-> marga: if you think you have found the right place you can verify it by running "x/16i $rip" or similar in gdb and then compare the disassembly
[21:41] <marga> Sorry, I really don't know what you are talking about now.
[21:42] <lindi-> marga: the core dump has a copy of the memory. objdump -d shows what is on the disk. it's a good idea to verify that they match: there could be some memory corruption at play as well
[21:42] <marga> Right
[21:42] <marga> but what's x/16i and what's $rip ?
[21:43] <lindi-> marga: x/16i is a gdb command that shows up to 16 instructions from the address that you give to it. $rip points to the current instruction on amd64
[21:44] <lindi-> these are bit cryptic I admit, there's a "disassemble" command but it only works for functions I think
[21:46] <marga> => 0x7f45bc27415c:	Cannot access memory at address 0x7f45bc27415c
[21:46] <marga> That's why I get ??, I guess
[21:46] <lindi-> marga: well, according to maps that should be mapped but maybe this is some apport thing I don't know about...
[21:47] <marga> Yeah, I should probably do this with apport-retrace and not with gdb
[21:48] <marga> but apport-retrace doesn't like that the package is missing :(
[21:49] <marga> oh, I tricked it!
[22:04] <stokachu> doko: ping
[22:06] <bdrung> tumbleweed: no = you are fine with adding a copy of devscripts.logger to ubuntu-dev-tools?
[22:06] <doko> stokachu, ?
[22:07] <bdrung> tumbleweed: can you have a look at the bug in the testcase when building on experimental: http://paste.debian.net/242561/
[22:07] <stokachu> doko: question about bug 778627 update comment #27, im not quite sure what kind of test i should write for validating "
[22:07] <stokachu> A set of heuristics that reduce the number of times special characters
[22:07] <stokachu>         such as `$' are quoted when the directory name is not expanded.
[22:07] <stokachu> "
[22:07] <stokachu> doko: do you have any recommendations?
[22:08] <stokachu> only thing ive come up with is testing to make sure if multiple shell variables are used in readline that none of them are escaped
[22:09] <xnox> stokachu: the description on the bug as it is now, is suffiently good for me to sponsor/upload this SRU.
[22:10] <stokachu> xnox: cool i was just making sure i covered all your test cases
[22:10] <stokachu> xnox: do you want me to subscribe the relevant teams or will you handle it now?
[22:10] <tumbleweed> bdrung: no, as in no objection
[22:10] <xnox> stokachu: the idea is that people who complain/notice this broken new bash, can be pointed to the bug description and they get sufficient information about what has changed, what are the symptoms, what needs configuring / changing to enable previous behaviour.
[22:11] <bdrung> tumbleweed: okay. then i will go ahead and do it.
[22:11] <stokachu> xnox: gotcha
[22:11] <bdrung> tumbleweed: do you have an idea why the testcase fails on experimental? the timeout doesn't work correctly.
[22:15] <tumbleweed> bdrung: what do you mean by "on experimental" ?
[22:15] <stokachu> xnox: i went ahead and subscribed sponsors team
[22:15] <stokachu> xnox: lemme know if you need anything else from me
[22:15] <bdrung> tumbleweed: debian experimental
[22:15] <tumbleweed> bdrung: but building for experimental is the same as sid, unless yuo have dependencies that can't be met in sid
[22:16] <bdrung> tumbleweed: we need python3-file from experimental
[22:17] <tumbleweed> bdrung: master doesn't. what branch is this?
[22:17] <doko> stokachu, xnox, I'm not sure I'm the right person to ask for a SRU-compatible testcase ...
[22:18] <bdrung> tumbleweed: master + http://paste.debian.net/242685/ OR devscripts from raring
[22:19] <tumbleweed> ah. looks...
[22:20] <bdrung> tumbleweed: and we have an unrelated test failure on raring: https://launchpadlibrarian.net/134570548/buildlog_ubuntu-raring-amd64.devscripts_2.13.1~daily%2Bbzr2631~raring1_FAILEDTOBUILD.txt.gz
[22:23] <stokachu> doko: no worries i think its sorted
[22:25] <tumbleweed> bdrung: builds for me, with that patch
[22:25] <bdrung> strange
[22:27] <tumbleweed> bdrung: also. that doesn't actually look like a timeout. but rather a syntax error, from using u'strings' with python < 3.3
[22:28] <cody-somerville> I just tried to install today's daily for amd64 and it crashed and burned horribly. network-manager segfaulted in some dhcp related function when I tried to connect to wireless network which caused install to abort and launch session. I plugged in ethernet port to send in bug report but nm was unable to bring up the network on ethernet port either. I also got segfaults in gsetting-daemons. Also not sure if I caused this when I
[22:28] <cody-somerville>  was trying to bring the network back up but the system-wide dbus daemon crashed which made it difficult to communicate with upstart to bring up/down services. Anyhow, is nm issue a known issue?
[22:28] <bdrung> tumbleweed: strange. now it builds on experimental.
[22:30] <bdrung> tumbleweed: now only https://launchpadlibrarian.net/134570548/buildlog_ubuntu-raring-amd64.devscripts_2.13.1~daily%2Bbzr2631~raring1_FAILEDTOBUILD.txt.gz needs to be fixed
[22:31] <slangasek> cody-somerville: first I've heard of it.  Maybe you're looking at a hardware problem?
[22:31] <tumbleweed> bdrung: scripts/devscripts/control.py:68 doesn't match the exception in your earlier paste
[22:31] <tumbleweed> the u was removed
[22:32] <bdrung> right. i removed that u after i found an older python3-port.patch on my system
[22:32] <cody-somerville> slangasek: Do you know if there is a way to get apport to save reports to disk and then be able to submit it once I boot back into 12.10?
[22:33] <slangasek> cody-somerville: if it's a crash, it gets written to disk under /var/crash already; you'd just need to copy them over
[22:34] <tumbleweed> bdrung: whitelist Popen in the pylint config
[22:34]  * tumbleweed -> bed
[22:35] <bdrung> tumbleweed: thanks. will do that.
[22:39] <cody-somerville> Also, I found that there is a significant (and rather annoying) delay in the hover-over label displaying for items in the dash compared to 12.10 (which displays them immediately). Is this intentional?
[22:41]  * cody-somerville is going to collect those crash reports.
[22:46] <xnox> doko: i guess stokachu involved you in the conversation because you are bash maintainer =)
[23:20] <robert_ancell> bdmurray, was that lightdm MP for packaging or trunk? You've merged it against trunk but it's about 500 revisions behind
[23:20] <robert_ancell> bdmurray, https://code.launchpad.net/~brian-murray/lightdm/bug-967229/+merge/153953
[23:23] <bdmurray> robert_ancell: ah, for packaging
[23:46] <bdrung> xnox: all devscripts issues resolved. i am waiting for an updated patch for debian bug #703323