[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


[00:12] <mup> PR snapcraft#1354 opened: catkin plugin: fix pythonpath for catkin_find <Created by mrjogo> <https://github.com/snapcore/snapcraft/pull/1354>
[02:51] <mup> PR snapcraft#1353 closed: cli: default options for the implicit snap command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1353>
[03:51] <mup> PR snapcraft#1355 opened: go plugin: filter the main packages go-packages are defined <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1355>
[07:10] <morphis> mvo: ping
[07:11] <mvo> morphis: pong
[07:11] <morphis> mvo: how was the long weekend? :-)
[07:12] <mvo> morphis: very nice, thank you! for you as well?
[07:12] <morphis> mvo: yeah, happily quite sunny yesterday so a great end :-)
[07:13] <morphis> mvo: one quick question for you: should we ship the snap-repair systemd units on classic systems?
[07:15] <mvo> morphis: we don't need to, its disabled there anyway
[07:15] <morphis> mvo: good!
[07:15] <mvo> morphis: so far we use the same debs to build classic and core this is why they are included currently
[07:15] <morphis> yeah, guesses that already but let me exclude these units for other distros then
[07:15] <morphis> doesn't make much sense to have them installed there
[07:16] <mvo> morphis: +1
[07:16] <NicolinoCuralli> hi guy i need to use ssh-pass and i need to access /dev/tty : is serial-port the right interface?
[07:17] <morphis> NicolinoCuralli: for serial-port you need to define a slot on the gadget snap for that specific tty, if that is an option, then the answer is yes
[07:17] <NicolinoCuralli> thanks morphis
[07:18] <morphis> mvo: thanks
[07:18] <morphis> mvo: can you merge https://github.com/snapcore/snapd/pull/3427 ?
[07:18] <mup> PR snapd#3427: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <https://github.com/snapcore/snapd/pull/3427>
[07:19] <mvo> morphis: looking
[07:19] <mvo> morphis: thank you
[07:19] <mup> PR snapd#3427 closed: interfaces/builtin: silence ptrace denial for network-manager <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3427>
[07:21] <zyga_> mvo: good morning!
[07:21] <mvo> hey zyga_!
[07:21] <zyga_> mvo: lots has happened since Friday :-)
[07:22] <morphis> zyga: morphis!
[07:22] <morphis> mvo: thanks
[07:22] <zyga_> hey hey :-)
[07:22] <mvo> zyga_: oh? tell me more? I'm slowly catching up (reading forum etc)
[07:23] <zyga_> mvo: mainly we know how to reproduce the error from last week
[07:23] <zyga_> mvo: looks like apparmor/lxd bug, still working on it (just got to the office)
[07:23] <zyga_> mvo: thank you for participating in the arch bug, I think the arch package needs to be improved slightly, I suspect we may be missing something simple just because the package is broken
[07:23] <mvo> zyga_: awesome!
[07:24] <zyga_> morphis: I wonder if we could do arch (after suse) CI next
[07:24] <morphis> zyga: why not, but lets land suse/fedora first :-)
[07:24] <mvo> zyga_: aha, thanks, the arch bug was a bit of a drive-by-comment. so the lock-error happens inside lxd?
[07:24] <morphis> zyga: I have mint on my list too
[07:24] <kunal> Hello dear community .... I need help regarding snapcraft of a python app
[07:25] <kunal> please help me
[07:25] <zyga_> mvo: not sure yet but what it looks like is that apparmor profile from the host confines the guest
[07:26] <morphis> kunal: best is if you post your specific question on https://forum.snapcraft.io
[07:26] <mvo> zyga_: great, thanks a lot for chasing this further. out of curiosity, how did you find this out?
[07:27] <zyga_> mvo: it was reported on the forum actually
[07:27] <mvo> zyga_: sweet
[07:27] <zyga_> mvo: so all the credits go to the reporter :)
[07:27]  * mvo takes a short tea break
[07:27] <morphis> zyga: why are you asking about ARch? anything specific?
[07:27] <zyga_> but forum is so nice to engage with, not like ML where you cannot reply to stuff you didn't see before easily
[07:27] <zyga_> morphis: to run spread tests on it
[07:28] <zyga_> morphis: even in nightly mode if we can
[07:28] <morphis> sure, but is there anything which brought this up or just in general?
[07:28] <zyga> morphis: ah, I wonder if the error reported on the forum is pointing out something deeper that's broken there
[07:28] <morphis> zyga: ?
[07:28] <kunal> My problem is - I am working on a snap for my python app... I am unable to understand why doesn't it download python packages available through apt-get
[07:29] <kunal> why doesn't snap download the python modules from main repository.
[07:31] <zyga> morphis: I mean this one https://forum.snapcraft.io/t/cannot-locate-core-snap-error/884
[07:32] <zyga> kunal: hey, what did you expect to happen and how did you express this in your snapcraft yam?
[07:32] <zyga> yaml*
[07:32] <kunal> or if it does not download some module for python, then how will my program/app run. It only downloads from pypi .  I need your help here... Please help me
[07:32] <morphis> kunal: that hardly depends on how you structure your snapcraft.yaml
[07:33] <zyga> kunal: apt is available through "stage packages"
[07:33] <zyga> kunal: why do you prefer apt over python package index?
[07:34] <kunal> I specified/ included espeak under python-packages in my snapcraft.yaml but then it gave me an error... the same thing happend with scipy .
[07:34] <zyga> kunal: I think you should open a question on the forum, include the error message and relevant parts of your snapcraft.yaml
[07:36] <kunal> I do not prefer apt over pypi but i just want to know that if some python module is not dowloaded by snapcraft then, how will my program run , because it requires those python module at runtime...
[07:36] <morphis> zyga: did you finish the changes for snap-confine we talked about last week?
[07:37] <zyga> morphis: almost, I ended up finishing something I already got a review of
[07:37] <zyga> morphis: (which grew slightly so took whole day)
[07:37] <zyga> morphis: I finished making the structural changes but I need to comment on everything heavily to guide the reviewers
[07:38] <zyga> morphis: though on the bright side almost all changes are in snap-confine.c so it's not a revolution
[07:38] <morphis> zyga: ok
[07:44] <morphis> zyga, mvo, pedronis, Pharaoh_Atem: another review on https://github.com/snapcore/snapd/pull/3222 would be much appreciated, getting really tired of merging/fixing that with master again and again :-)
[07:44] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[07:46] <morphis> and the PR is now pending for nearly 1,5 months
[07:56]  * zyga_ sees re-exec disabled by user again
[07:57] <morphis> zyga: Linode has an prebuilt Arch image so shouldn't be much work
[08:01] <NicolinoCuralli> morphis: i tell you wrong device : i need to use a pty device from my snap: actually is it possible ?
[08:05] <zyga> NicolinoCuralli: each snap gets private ptys
[08:07] <NicolinoCuralli> zyga: i have an error as this : debug1: read_passphrase: can't open /dev/tty: No such device or address
[08:08] <NicolinoCuralli> it seems as if the command can't access the device
[08:21] <NicolinoCuralli> zyga: some hint on the problem?
[08:22] <zyga> I don't think you can open /dev/tty
[08:22]  * zyga looks
[08:22] <zyga> yep
[08:22] <zyga> it's not allowed
[08:24] <NicolinoCuralli> zyga: neither enabling a new interface?
[08:28] <zyga_> NicolinoCuralli: a new interface could allow it but I think it is disallowed for a reason now
[08:28] <zyga_> NicolinoCuralli: can you please start a forum topic
[08:29]  * zyga_ is busy with some other things now and cannot actively look at why /dev/tty was left out of current interfaces
[08:32] <NicolinoCuralli> zyga: thanks for your help : I find another solution to implement what I make with sshpass, but I think to start a forum topic for document this restriction
[08:44] <morphis> fgimenez: is there any specific reason why you're using -q for nc in the networking spread tests for snapd?
[08:46] <fgimenez> morphis: iirc it was meant to limit the time the test waits, let me check
[08:46] <morphis> fgimenez: as -q is not really portable across distributions
[08:48] <fgimenez> morphis: feel free to tweak it as needed, maybe we can do the same with another portable option, perhaps -w?
[08:48] <morphis> maybe
[08:48] <morphis> let me play with that
[08:57] <om26er> where can i find documentations about delta uploads ? I have been looking around but didn't find them also google doesn't bring up anything related to that.
[09:16] <fgimenez> hey zyga_, snapd#3430 should be fixed now for 14.04, i was getting http://paste.ubuntu.com/24791901/ after the error, pls take another look when you have a moment
[09:16] <mup> PR snapd#3430: tests: modify core before calling set <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3430>
[09:17] <zyga> ok
[09:18] <zyga> hmm
[09:18] <zyga> not sure what to say
[09:20] <zyga> fgimenez: what think is missing is snap-confine's /snap sharing
[09:20] <zyga> fgimenez: is this done before snap-confine gets a chance to run?
[09:20] <ogra> fgimenez, ls /var/lib/snapd/snaps/core_*.snap will explode if there are more than one core snap (for whatever reason)
[09:22] <fgimenez> zyga: this is done after snapshoting the state, when restarting the units https://github.com/fgimenez/snappy/blob/cb71389e43b5aa0708715721faad1880c7629161/tests/lib/prepare.sh#L173
[09:23] <fgimenez> ogra: thx! at this point it is not expected to have more than one core, we are at a very early stage of suite preparation, but the check can indded be more robust, i'll push changes for that
[09:24] <ogra> :)
[09:25] <fgimenez> zyga: it is done also with the daemon stopped, not sure if that matters
[09:25] <zyga> fgimenez: is this easy to reproduce?
[09:25] <zyga> fgimenez: it should not matter
[09:25] <fgimenez> zyga: yep, from the branch seems to be very consistent
[09:25] <zyga> fgimenez: I'm happy to take a look after exploring the juju/lxd issue
[09:26] <fgimenez> zyga: great, thank you
[09:44] <pedronis> morphis: maybe I'm misreading but in snapd#3222 it seems you did exactly the opposite of what Gustavo asked
[09:44] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[09:47] <pedronis> morphis: https://github.com/snapcore/snapd/pull/3222#discussion_r116286335  soundes like ...Join(rootdir,... should be there, anyway I don't have a strong opinion, but sounds you need his re-review
[09:47] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[09:48] <morphis> pedronis: thanks, yeah I need his review again
[09:48] <morphis> pedronis: there are two different parts
[09:48] <morphis> there is CoreLibExecDir which never has a prefix
[09:49] <morphis> and in all others cases I am using dirs.StripRootDir like in https://github.com/snapcore/snapd/pull/3222/files#diff-6dd6f3a48b395a14870975240679b8cdR86
[09:49] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[10:00]  * zyga experiments with juju and has his head spinning
[10:00] <zyga> I think this is the perfect time for a coffee
[10:01] <tai271828_> haha
[10:07] <zyga> hey tai271828_ :)
[10:07]  * zyga looks at juju output and waits for more things to install
[10:07] <tai271828_> \o zyga did you get your coffee
[10:14] <mup> PR snapd#3434 opened: tests: add staging snap-id <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3434>
[10:16] <fgimenez> hi pedronis, we are missing another snap-id for staging, see ^^^, however i'm still getting an error after adding the right id http://paste.ubuntu.com/24792792/, i've just uploaded the same prod snap to staging, is something else missing?
[10:16] <zyga> tai271828_: yes I did
[10:16] <mup> PR core#35 closed: move xdg-open to proper paths <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core/pull/35>
[10:16] <mvo> if someone could have a second look at https://github.com/snapcore/core/pull/48 that would be great
[10:16] <mup> PR core#48: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
[10:17] <pedronis> fgimenez: you need to change the python in that test as well
[10:18] <fgimenez> pedronis: aha! thx on it
[10:18] <pedronis> fgimenez: sorry, not the python
[10:19] <pedronis> fgimenez: but the yaml has this:  environment:
[10:19] <pedronis>     TEST_SNAP_ID: aLcJorEJZgJNUGL2GMb3WR9SoVyHUNAd
[10:19] <fgimenez> pedronis: that should be addressed with the changes in snapd#3434
[10:19] <mup> PR snapd#3434: tests: add staging snap-id <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3434>
[10:20] <fgimenez> pedronis: hmm i see a typo in there, let me fix it
[10:22] <Chipaca> \o
[10:22]  * Chipaca appears in a cloud of post-physio exhaustion
[10:25] <ogra> clouds are the future i heard
[10:25] <zyga> unless it rains
[10:27] <Chipaca> I think people who used to gravitate towards torturer and executioner roles in the past now just pick up physio
[10:28] <Chipaca> "you'll feel a little stretch" <turns the rack wheel>
[10:28] <zyga> "you will fell a little sting"
[10:30] <fgimenez> pedronis: works fine now, sorry for the noise
[10:43] <mvo> flexiondotorg: hey, do you have an example app that uses gnome-keyring that could be used to do a real world test for a new interfaces for gnome-keyring?
[10:43] <flexiondotorg> Hi
[10:43] <flexiondotorg> I do.
[10:43] <flexiondotorg> Skype for Linux
[10:44] <zyga> flexiondotorg: skype for linux beta or the one that was de-comissioned just now/
[10:44] <mvo> flexiondotorg: great, where can I find the snapcraft.yaml to add the right ifcace for testing?
[10:44] <flexiondotorg> The new Electron version.
[10:44] <mup> PR snapd#3435 opened: interfaces: add password-manager-service implicit interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/3435>
[10:44] <flexiondotorg> ANd also Nylas Mail (the newer open source version), also Electron.
[10:45] <mvo> fgimenez: I have a new snap-test-security-service-consumer snap, what was the central place for those again so that they are all auto-build/uploaded?
[10:45] <flexiondotorg> mvo I'll just make sure both yamls are current.
[10:45] <flexiondotorg> Give me a few mins...
[10:46] <mvo> flexiondotorg: no worries, I will soon have lunch anyway, so no rush :)
[10:51]  * ogra glares at snapd 3432 ... how can a journald run on 14.04 (which doesnt have systemd)
[10:52] <zyga> ogra: snapd pulls it in
[10:52] <zyga> ogra: we have systemd on 14.04 but it is a special build
[10:52] <ogra> and that is a fully working systemd (providing logging )
[10:52] <ogra> i thought that was just a stub
[10:52] <zyga> ogra: oh, journald is there?
[10:52] <zyga> I thought journald did not work
[10:52] <zyga> nice :)
[10:52] <ogra> zyga, thats what i mean
[10:53] <ogra> how can https://github.com/snapcore/snapd/pull/3432 actually work on a 14.04
[10:53] <mup> PR snapd#3432: tests: clean journalctl logs on trusty <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3432>
[10:53] <ogra> where we have no fully working systemd
[10:53] <ogra> (and thus no journald)
[10:54] <ogra> tvoss, is the 14.04 systemd thing actually starting a journald ??
[10:54] <ogra> (iirc you worked on that)
[10:59] <morphis> ogra: I doubt that
[11:02] <ogra> morphis, hmm, curious ... why is that needed then ...
[11:02] <morphis> not sure
[11:09] <zyga> lazyPower: hey, I'm trying to reproduce the issue we spoke of yesterday
[11:09] <zyga> lazyPower: how long should conjure-up be doing its thing?
[11:10] <zyga> lazyPower: I'm currently seeing "waiting for applicationto start"
[11:10] <zyga> lazyPower: juju status spews a lot of output, some things being active, some in maintenance
[11:10] <zyga> lazyPower: (it all means nothing to me unfortunately)
[11:13] <zyga> hmm, actually, I think it is making progress
[11:18] <fgimenez> mvo: thx for the heads up! we are uploading the source files here https://code.launchpad.net/~snappy-dev/snappy-hub/ and from there they are published to production, i'll register and upload it to staging
[11:19] <fgimenez> mvo: btw we need two more test snaps in prod undere the shared account, i'll ping you later about this
[11:21] <ogra> wow, someone still uses snappy-hub ?!?
[11:25] <pedronis> all our test snaps are built under it I think
[11:26] <pedronis> test snaps, as used by spread tests
[11:28] <ogra> ah ... interesting
[11:28] <ogra> i thogught even that was moved to GH
[11:28] <zyga> lazyPower: almost all apps are active now, I see that kubernetes-master is still "waiting"
[11:29] <zyga> lazyPower: with a message "waiting for kube-system podto start"
[11:29] <zyga> lazyPower: still looks OK-ish
[11:30] <zyga> lazyPower: I did start with snapd 2.25 as that's what I got after update from 2.0.10
[11:30] <zyga> lazyPower: I'll let this finish and try again with manually started 2.21
[11:30] <zyga> lazyPower: you said you had 2.21 on the host and 2.25 in lxd, can you explain which of the machines had 2.25 exactly? how can I check that?
[11:32] <zyga> lazyPower: in the end it failed with "step requires paswordless sudo"
[11:32] <zyga> and a python backtrace
[11:34] <zyga> in the end I can see a few denials that are not caused by snapctl
[11:34] <zyga> let me add this to the forum
[11:35] <morphis> pedronis: can I set the device-service.url configuration item for the gadget snap after the firstboot process still if the device does not have a serial-assertion yet?
[11:37] <pedronis> morphis: in which context?
[11:38] <morphis> pedronis: in a case where a customer has it's own local serial-vault and we have a generic image and we want to point that now to the local serial-vault
[11:38] <pedronis> morphis: well generic image will have a generic model
[11:38] <pedronis> something doesn't compute there
[11:39] <pedronis> generic in which sense?
[11:39] <morphis> generic in a sense of that we want to cover a bigger set of devices with the same image to save costs of doing n different images
[11:40] <morphis> so we have an image generic for a brand
[11:44] <pedronis> morphis: in principle atm yes,  device registration is retried
[11:44] <morphis> ok
[11:49] <lazyPower> zyga: thats an unrelated thing, conjure-up is trying to fetch snap packages required to maintain the application
[11:50] <lazyPower> zyga: i had 2.21 on the host, each container would have had 2.25. after upgrading to 2.25 on my host yesterday it appears to have resolved itself as well
[11:51] <ogra> sounds like a re-exec vs non-rexec issue
[11:52] <zyga> lazyPower: aha, I see
[11:52] <zyga> lazyPower: I'll do another pass now, using 2.21 on the host
[11:52] <zyga> lazyPower: I think the bug is still there, it is just masked by 2.25 on the host
[11:53] <lazyPower> masked huh :)
[11:54] <mvo> fgimenez: sounds good, thank you
[11:59] <iliv> hi, when I run "snap alias" command as an unprivileged user it displayes the following "error: access denied (try with sudo)". is this expected or a problem?
[12:00] <ogra> iliv, well, that will also be the message when you snap install and such
[12:00] <iliv> well, I'm reading this https://insights.ubuntu.com/2017/01/28/ubuntu-core-how-to-enable-aliases-for-your-snaps-commands/ and it leads me to believe snap alias can be run as an unprivileged user (?)
[12:00] <ogra> iliv, it should also say that you can "snap login" instead of using only sudo ...
[12:01] <ogra> iliv, yes, an unprivileged user that used snap login before
[12:01] <iliv> hm
[12:02] <ogra> i dont think we support actual per-user aliases yet ... ( pedronis may correct me) which wouldnt need snap login or sudo
[12:03] <pedronis> aliases are global
[12:04] <iliv> pedronis, which user manages them? root?
[12:05] <pedronis> snapd so root
[12:05] <pedronis> iliv: anyway when 2.25/2.26 come out that blog post is not valid anymore
[12:06] <iliv> ogra, after issuing snap login I was able to "snap alias" as an unprivilged user
[12:06] <pedronis> things work differently
[12:06] <ogra> iliv, yeah :)
[12:06] <iliv> pedronis, I hope you guys will update it then
[12:06] <iliv> pedronis, btw I run 2.25
[12:06] <pedronis> davidcalle: hi, did you see my ping in the foru about that btw  ?
[12:06] <iliv> for both snap and snapd
[12:07] <pedronis> iliv: then you need to read: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18/33
[12:07]  * zyga -> lunch
[12:08] <davidcalle> pedronis: I don't think I did :/
[12:08] <pedronis> davidcalle: we need a new post or to update the old one about aliases once 2.26 is on stable
[12:09] <pedronis> given that things have changed
[12:11] <iliv> davidcalle, and if you add now "snap login is required before running all the commands below" it can save some time anyone who is reading that blog post. no need to wait for 2.26.
[12:12] <davidcalle> iliv: good point
[12:12] <davidcalle> pedronis: what's the eta on this? Two weeks?
[12:14] <pedronis> davidcalle: don't know,  mvo what's the eta on 2.6.4 going stable ?
[12:20] <zyga> davidcalle: I think this is in the hands of fgimenez now
[12:23] <mvo> pedronis, davidcalle: no firm deadline but ASAP. we need QA approval from fgimenez and the CE team. AIUI the CE team is currently testing the new core (correct federico?)
[12:24] <fgimenez> mvo yep, the validation on beta was successful, it was promoted yesterday to candidate and now CE QA and Cert are validating it, as soon as they finish with it and you and JamieBen_ give your ok it can be promoted to stable
[12:25] <mvo> fgimenez: excellent ! thank you
[12:28] <iliv> hm okay, so I've just created an alias for postgresql93.psql and "whereis psql" points to /snap/bin/psql. However, when I run "psql --version" /usr/bin/psql is called. what gives?
[12:28] <iliv> here's my terminal history that illustrates this problem: https://dpaste.de/62Vk/raw
[12:28] <mup> PR snapd#3434 closed: tests: add staging snap-id <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3434>
[12:29] <iliv> oh, I see
[12:30] <iliv>  I needed to relogin
[12:30] <iliv> that's weird anyway
[12:30] <iliv> once I exited and relogined psql started to resolve to /snap/bin/psql
[12:31] <iliv> this looks like a bug to me. normally system wouldn't require a shell logout to pick up a new location of a binary.
[12:32] <iliv> ogra, pedronis davidcalle
[12:34] <ogra> iliv, did you have a deb installed before ?
[12:34] <iliv> correct
[12:34] <ogra> sounds more like bash is caching something to me then
[12:34] <ogra> (not really like a snap issue)
[12:35] <iliv> right
[12:35] <iliv> I have just been ables to reproduce it the other way around
[12:35] <iliv> i.e. install snap package first, then deb
[12:35] <iliv> same issue
[12:35] <ogra> but yeah, sounds like a bug ... would be nice to know if that also happens when you have a deb where a binary moves from /usr/bin to /bin or some such
[12:35] <iliv> I guess a shell logout/reinitialization is required after all
[12:36] <ogra> (to prove it isnt actually snap related)
[12:36] <iliv> mhm
[12:58] <pedronis> davidcalle: so sounds a bit less thant 2 weeks in the good, more like this one or the next
[12:59] <davidcalle> pedronis: sounds good, thanks. I'll be in the snapcraftio sprint this week, I'll make it part of it
[12:59] <pedronis> thank you
[12:59] <pedronis> let me know if you have questions
[13:00] <davidcalle> +1
[13:16] <zyga_> mvo: https://github.com/snapcore/snapd/pull/3370
[13:16] <mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
[13:17] <zyga> mvo: that's the implicit pr, if this lands your pr won't have to change implicit anymore
[13:17] <zyga> mvo: and the last thing will be the base declaration
[13:22] <zyga> I cannot reconnect to the call
[13:23] <zyga_> I cannot re-connect
[13:33] <zyga_> fgimenez: hey
[13:33] <zyga_> fgimenez: I have one more idea about the 14.04 issue with mounted core
[13:33] <zyga_> fgimenez: I think /etc/mtab is a file, not a symlink to /proc/mtab
[13:33] <zyga_> fgimenez: and this is causing this issue
[13:34] <zyga_> fgimenez: if I'm right we may have to ensure we always keep those two in sync
[13:36] <fgimenez> zyga_: aha, that would make a lot of sense, when i try to unmount core it gives an error saying it wasn't mounted (that's the reason of the "|| true" in the PR), but it was reported by "mount"; after the call to umount all is good, seems that both versions are in sync
[13:36] <fgimenez> zyga_: and the original error messaage refers to mtab http://paste.ubuntu.com/24791901/
[13:36] <zyga> fgimenez: right, because on 14.04 mtab is a file maintained by userspace tools but later on it was changed to a symlink to kernel's mtab which is always correct
[13:38] <morphis> mvo: shouldn't the tests/main/snap-repair spread test case be ubuntu-core-* specific?
[13:38] <fgimenez> zyga_: should i raise a bug about this? also, about the PR, is there a better solution, maybe copying /proc/mtab to /etc/mtab?
[13:39] <zyga> fgimenez: I'm not sure yet, I think it is partially a "feature" of 14.04 but I wonder which changes triggered the problem now
[13:39] <zyga> fgimenez: if it is just affecting tests we can do something about it in spread, I wonder (and worry) about 14.04 outside of test environment
[13:40] <fgimenez> zyga_: the only difference is the call to snap-discard-ns core afaik
[13:40] <fgimenez> without it 14.04 doesn't give this error
[13:42] <mvo> morphis: yes, it should be
[13:43] <morphis> mvo: ok, will mark it as such
[13:43] <icey> so, after a forum post about getting a default alias (with several +1s), how long would be normal to wait? https://forum.snapcraft.io/t/ripgrep-aliased-as-rg/351
[13:47] <Chipaca> noise][: who deals with setting up aliases?
[13:48] <pedronis> jdstrand mostly
[13:48] <Chipaca> icey here has had a request for aliases open for over a month, with a +1 from jdstrand and niemeyer for nearly as long
[13:48] <Chipaca> that won't do :-(
[13:48] <icey> Chipaca: hence me coming to bug people about it :)
[13:49] <Chipaca> icey: yeah
[13:49] <Chipaca> icey: thanks!
[13:49] <Chipaca> so my question is, what do we do to avoid this from happening again
[13:49] <icey> maybe I shoudl make a forum/IRC bot to bug people when there are a lot of +1 (especially from some names) on the forums
[13:49] <zyga> Chipaca: I mentioned this once before but I really really think this should always be a bug on the snappy store project
[13:49] <icey> s/shoudl/should
[13:49] <zyga> https://launchpad.net/snapstore
[13:50] <noise][> zyga: i don't think that's the right place since my team doesn't handle those approvals
[13:50] <zyga> noise][: what do you suggest then?
[13:51] <Chipaca> right, if it's jdstrand, we need to bug him :-)
[13:51] <Chipaca> mup: pester jdstrand until morale improves!
[13:51] <mup> Chipaca: I apologize. I'm a program with a limited vocabulary.
[13:51] <noise][> need to chat w/jdstrand
[13:52] <noise][> the process is clearly leaky, but we've agreed (at least thus far) that we want the forum discussion for those requests, and not just a queue in the store
[13:52] <ogra> the prob with the forum discussions is that they vanish over time
[13:53] <ogra> (not physically but they simply scroll off the overview eventually)
[13:53] <zyga> noise][: maybe we just need both
[13:53] <ogra> some kind of remonder system would be nice there
[13:53] <zyga> noise][: file a bug and open a forum thread
[13:53] <icey> I wonder if there's some way to unite these two ideas, so that you have a forum discussion with some kind of queue that proposals can be removed from when handled
[13:53] <ogra> *reminder
[13:53] <zyga> mvo: hey, I read your new interface PR
[13:54] <zyga> mvo: I have two comments/suggestion
[13:54] <pedronis> people can bookmark things in the forum fwiw
[13:54] <mvo> zyga: excellent, I check them out
[13:54] <zyga> mvo: one is that you need to tweak tests to pass on fedora and other non-deb systems
[13:54] <jdstrand> icey, et al, let me look
[13:54] <zyga> mvo: ah, I didn't send them there :)
[13:54] <mvo> zyga: indeed
[13:54] <mvo> zyga: aha, ok :)
[13:54] <zyga> mvo: and the other one, which is just a suggestion, is to perhaps open a forum thread and document the interface there
[13:55] <zyga> mvo: my branch adds a DocsURL meta-data, so you can document the interface and people will be able to find that by saying "snap interface password-manager-service"
[13:56] <mvo> zyga: nice, I will do that
[13:56] <zyga> mvo: and if you +1 https://github.com/snapcore/snapd/pull/3370 we can also define implicitness through the meta-data, one less file to edit
[13:56] <mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
[13:57] <Chipaca> jdstrand: icey: it looks like what happened is that the request came in just as we were (re)defining the process for this, and fell through the cracks
[13:57] <icey> Chipaca: I'm good at finding those cracks apparently :-P
[13:57] <mvo> zyga: thanks, I check that branch out now too
[13:57] <icey> and it wasn't high enough on my priority list to follow up on
[13:57]  * ogra hands icey  a pot with plaster to close them :P
[13:57] <zyga> mvo: thank you! note that those are just suggestions (the docs at least)
[13:58] <zyga> mvo: so don't feel blocked by this
[13:58] <jdstrand> Chipaca: well, we defined the process, but there is a not great part of circling around after a week. that didn't happen with this one. there are a couple of others I'm going to follow up on too
[13:59] <Chipaca> jdstrand: i panicked for a moment thinking we were leaving people in limbo, but it looks like i was wrong; sorry if i was too pushy or something there
[14:00] <jdstrand> Chipaca: the circling around bit did slip through so thank you for the reminder
[14:00] <icey> Chipaca: limbo can be relaxcing too ;-)
[14:00] <jdstrand> icey: as mentioning in the forum, sorry for the delay
[14:01] <jdstrand> menioned*
[14:01] <jdstrand> meh
[14:01] <icey> no worries jdstrand, partially on me too for not following up
[14:01] <jdstrand> mentioned*
[14:01] <ogra> i really think remindesr should be a forum feature ...
[14:01] <ogra> reminders
[14:10] <niemeyer> Heya
[14:11] <niemeyer> For the requests queue, we already have a check mark we use when the request is handled
[14:11] <niemeyer> What's missing is a proper view that lists only such requests so it's obvious what's pending
[14:11] <niemeyer> I think either a category or a tag will do
[14:12] <ogra> niemeyer, well, couldnt it also send some reminder mail if such a request is open and untouched for a certain amount of time ?
[14:12] <niemeyer> Perhaps "upcoming" + "jdstrand"?
[14:12] <ogra> (or a forum notification, doesnt need to be mail indeed)
[14:15] <niemeyer> I expect this list to never be empty.. anything over a week needs resolution or continued discussion until we resolve it
[14:16] <niemeyer> So it's more a continuous process than something we need to be reminded about
[14:18] <mup> PR snapd#3436 opened: tests: fix econnreset on staging <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3436>
[14:23] <ogra> k
[14:36] <mvo> stgraber: hey, I wrote a simple lxd snap integration test so that we don't break it accidnetly https://github.com/snapcore/snapd/pull/3372 - however I get errors on 14.04 and 16.04-32, one looks like this "error: Get http://unix.socket/1.0/operations/a59c76b5-5f7c-4b39-b8c8-05315404a32a/wait: EOF" the other one (14.04) s a timeout. are those platforms supposed to work? if so, what can I do to help debugging?
[14:36] <mup> PR snapd#3372: tests: add basic lxd test <Created by mvo5> <https://github.com/snapcore/snapd/pull/3372>
[14:41] <zyga_> mvo: I think 14.04 is not going to work (CC jdstrand )
[14:47] <jdstrand> if 14.04 is using the lts kernel, I don't know why it wouldn't work
[14:48] <jdstrand> assuming it has all the required debs installed
[14:59] <cachio_> mvo, the change to move the prepare_each_classic to project level has broken the upgrade tests
[14:59] <cachio_> mvo, I am gonna revert the change
[14:59] <mup> PR snapd#3428 closed: tests: add snap-confine privilege test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3428>
[14:59] <mvo> cachio_: ok, thanks for trying it!
[15:00] <cachio_> mvo, sure
[15:23]  * zyga reboots to test something
[15:33] <mup> PR snapd#3430 closed: tests: modify core before calling set <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3430>
[15:58] <iliv> davidcalle, I continue exploring aliases and I've just realised one doen't even need aliases: in snapcraft.yml to set up manual aliases. Was it different in some prior version to 2.25?
[16:07] <Pharaoh_Atem> morphis: I'll take a look at the PR later today
[16:08] <morphis> Pharaoh_Atem: thanks
[16:14] <stgraber> mvo: sorry, sprinting. We run daily tests of the LXD snap on 14.04 and 16.04, works on both for us.
[16:15] <stgraber> mvo: https://jenkins.linuxcontainers.org/job/lxd-test-snap/
[16:17] <zyga_> jdstrand: do you have a chance to give me a +1 here: https://github.com/snapcore/snapd/pull/3370
[16:17] <mup> PR snapd#3370: many: derive implicit slots from interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3370>
[16:20] <kyrofa> zyga, any idea what's happening here? https://askubuntu.com/questions/922484/how-to-install-telegram-snap-on-ubuntu-16-04-2
[16:23] <zyga_> kyrofa: looing
[16:24] <zyga_> well, DNS
[16:24] <zyga_> no idea why
[16:25] <kyrofa> That error is... awful
[16:25] <cachio_> mvo, the env cleanup PR passing
[16:26] <zyga_> kyrofa: yes, chipaca opened a thread about this already
[16:27] <zyga_> https://forum.snapcraft.io/t/network-ish-error-messages/862
[16:27] <zyga_> kyrofa: here ^
[16:33] <jdstrand> zyga_: probably a bit later today, if not first thing tomorrow
[16:45] <mvo> stgraber: thank you, what is the link to see the source of your test?
[17:37] <zyga_> niemeyer: the lock issue is unlocked: https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390/19
[17:37] <zyga_> lazyPower: ^
[17:38] <lazyPower> zyga_: thats consistent with my findings
[17:38] <zyga_> lazyPower: can you explain why are you using lxd without apparmor?
[17:38] <zyga_> lazyPower: is this something that was recommended to you?
[17:38] <lazyPower> zyga_: namely because of flannel networking
[17:39] <zyga_> lazyPower: can you comment on the forum please, we can look for a solution together
[17:39] <zyga_> and I'm sorry it took so long to find
[17:39] <zyga_> niemeyer: my initial hunch was right (wrong profile) but the origin of the profile is very very unexpected
[17:40] <lazyPower> zyga_: certainly let me wrap up what i'm working on and i'll context switch back over to lend some detail
[17:40] <niemeyer> \o/
[17:41] <zyga_> lazyPower: thank you!
[17:57] <zyga_> JamieBennett: hey
[18:07] <Shannon_> might not be the best channel, but I'm trying to put snaps into a docker contrainer, and I'm having some problems.
[18:08] <lazyPower> zyga_: ok i hope that helps. i looped in some additional names on that thread to cover their specific domains if you have any questions about them specifically that i didn't answer in the generalized response.
[18:09] <zyga_> lazyPower: I saw, I already replied to your question
[18:09] <lazyPower> +1 understood
[18:09] <zyga_> lazyPower: I think we need to look at our options but I don't have a good idea of how to make it nice
[18:09] <zyga_> lazyPower: apart from disabling confinement for snap-confine on the host as well
[18:09] <lazyPower> yeah, i just want to make sure we aren't opening pandoras box in terms of both security and usability
[18:10] <lazyPower> i'm good at that for whatever reason, opening cans of worms i never intended to open.
[18:16]  * zyga_ calls it a dat
[18:16] <zyga_> day*
[19:01] <mup> PR snapcraft#1355 closed: go plugin: filter the main packages go-packages are defined <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1355>
[19:21] <cachio_> niemeyer, there?
[20:50] <nacc> so I just tried to update my classic snap to build on zesty 17.04 and got the following error https://launchpadlibrarian.net/322816537/buildlog_snap_ubuntu_zesty_amd64_git-ubuntu_BUILDING.txt.gz
[20:50] <nacc> specifically: W:GPG error: http://ppa.launchpad.net/snappy-dev/tools/ubuntu zesty InRelease: The following signatures couldn't be verified...
[21:25] <mup> PR snapcraft#1356 opened: common: find data files via sys.prefix <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1356>
[22:25] <sdrobertw> kyrofa: I still have that summary blog in the pipeline, been super busy. Maybe 1-2 more weeks please :) I will keep you posted once it is ready.
[22:26] <sdrobertw> kyrofa: have not forgot about it...
[23:29] <mup> PR # closed: snapd#2592, snapd#2837, snapd#3051, snapd#3111, snapd#3120, snapd#3222, snapd#3260, snapd#3317, snapd#3340, snapd#3346, snapd#3348, snapd#3365, snapd#3370, snapd#3372, snapd#3383, snapd#3391, snapd#3398, snapd#3399, snapd#3405, snapd#3406, snapd#3409, snapd#3410, snapd#3411,
[23:29] <mup> snapd#3412, snapd#3414, snapd#3416, snapd#3420, snapd#3429, snapd#3431, snapd#3432, snapd#3433, snapd#3435, snapd#3436
[23:32] <mup> PR core-build#13 closed: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[23:35] <mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
[23:38] <mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
[23:38] <mup> PR core-build#13 opened: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13>
[23:38] <mup> PR # opened: snapd#2592, snapd#2837, snapd#3051, snapd#3111, snapd#3120, snapd#3222, snapd#3260, snapd#3317, snapd#3340, snapd#3346, snapd#3348, snapd#3365, snapd#3370, snapd#3372, snapd#3383, snapd#3391, snapd#3398, snapd#3399, snapd#3405, snapd#3406, snapd#3409, snapd#3410, snapd#3411,
[23:38] <mup> snapd#3412, snapd#3414, snapd#3416, snapd#3420, snapd#3429, snapd#3431, snapd#3432, snapd#3433, snapd#3435, snapd#3436
[23:38] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[23:38] <mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
[23:39] <mup> PR # opened: snapcraft#1183, snapcraft#1258, snapcraft#1277, snapcraft#1291, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1314, snapcraft#1316, snapcraft#1318, snapcraft#1331, snapcraft#1332, snapcraft#1335, snapcraft#1337, snapcraft#1340, snapcraft#1342, snapcraft#1343,
[23:39] <mup> snapcraft#1345, snapcraft#1346, snapcraft#1348, snapcraft#1349, snapcraft#1350, snapcraft#1352, snapcraft#1354, snapcraft#1356


[01:55] <Admiral_Chicago> sounds good
[08:25] <mdke> bhuvan/nixternal: I'll report it to the sysadmins
[08:31] <mdke> mpt: seems that search.ubuntu.com isn't working? https://bugs.launchpad.net/bugs/112002
[08:31] <ubotu> Launchpad bug 112002 in yelp "Wrong url for the online search." [Medium,Confirmed]
[09:36] <mdke> man there are a lot of applicants for ubuntu-doc who have never posted to the list
[09:37] <Madpilot> heh. I'm an admin for ubuntu-wiki, we get a surprising number of people who've never edited the wiki applying...
[09:40] <Madpilot> ... we also have a wiki contributor with the username of "penis". How charming.
[09:46] <Burgundavia> indeed
[09:47] <mdke> awesome
[09:52] <Madpilot> charming nickname or not, 'penis' seems to do basically decent editing (see RecentChanges in huc/c)
[12:09] <mpt> mdke, that's not something I know or can do anything about, unfortunately
[12:09] <mpt> ping newz2000 when you see him
[04:58] <nixternal> mdke or mpt: any idea on who is in charge of the mailing lists overall and/or the servers they run on?
[04:58] <nixternal> it seems their spamassasin or whatever they use is broken
[04:59] <nixternal> we are getting 40+ bogus posts almost instantly on the doc and marketing mailing lists daily
[05:20] <mpt> nixternal, the Canonical sysadmins I guess
[05:21] <mpt> hmm, they used to have a Freenode channel but no longer seem to
[05:23] <mpt> I don't have any messages to ubuntu-doc@ in my Junk folder
[05:25] <nixternal> the moderator messages come with about 40 emails to approve/deny
[05:56] <mpt> ah, for the moderator
[05:57] <mpt> I don't know how people are supposed to report problems like that
[05:57] <mpt> I'll talk to jono and/or the sysadmins about it
[07:40] <ubotu> New bug: #49675 in ubuntu-doc "wrong command line in server guide (mysql)" [Undecided,Fix released]  https://launchpad.net/bugs/49675
[10:32] <mdke> nixternal<EMAIL_ADDRESS>I've spoken to elmo about the spam before, he's said there is nothing more that can be done
[10:51] <nixternal> that stinks
[10:54] <mdke> I've noticed the spam on my lists going up a lot recently too
[10:58] <nixternal> Docs and Marketing are insane, and Chicago isn't far behind
[10:58] <nixternal> KDE, we get may 10 a week
[10:58] <nixternal> s/may/maybe


[01:42]  * KombuchaKip finally understands upvalues and closure, but the lambda calculus is still giving him a headache.
[03:15] <paultag> dscassel, just logging it
[09:42] <czajkowski> dscassel: see I told you we hadn't forgotten you
[10:26] <lalya> hello
[10:26] <lalya> is anyone online?
[10:26] <czajkowski> bit early I guess for folks lalya
[10:26] <lalya> can you help me?
[10:26] <lalya> i have installed this ubuntu 10.10
[10:27] <lalya> but i dont understand something
[10:27] <czajkowski> what ?
[10:27] <lalya> basically i want to know the hardware address
[10:27] <lalya> of a fingerprint installed in my laptop
[10:27] <lalya> but in administration i cannot find anything like.. devices in windows
[10:28] <lalya> how can i see all the devices and their addresses in ubuntu?
[10:28] <czajkowski> lalya: in a terminal type lspci
[10:28] <lalya> ok hold on
[10:28] <lalya> i do it now
[10:28] <lalya> * i try
[10:29] <czajkowski> lalya: also asking in #ubuntu might make more sense as folks are awake in there 24/7
[10:30] <lalya> it doesnt see it :(
[10:30] <lalya> i see a bunch of usb intel controllers...
[22:15] <MattQC> hey hey
[22:34] <willwh> hi
[22:34] <willwh> wups
[22:34] <willwh> wrong channel, but hello folks! :)


[10:20] <rmg51> Morning
[13:22] <teddy-dbear> Morning peoples, dogs, turkeys?, hamsters and everything else
[18:34] <lazyPower> o/


[12:20] <mihailv> hi can someone tell me please where i can find the actual code for ubuntu maas?
[12:21] <mihailv> i mean on a vcs system
[12:21] <mihailv> like github
[12:25] <rbasak> mihailv: https://code.launchpad.net/maas
[12:28] <mihailv> rbasak: thank you very much
[12:34] <mup> Bug #1566829 opened: DoesNotExist: RegionControllerProcess matching query does not exist. <MAAS:Triaged> <https://launchpad.net/bugs/1566829>
[13:31] <mup> Bug #1560815 changed: [2.0a3] apt-get install maas fails due to postgresql connection <cdo-qa> <MAAS:Opinion> <https://launchpad.net/bugs/1560815>
[13:31] <mup> Bug #1566848 opened: [2.0 beta1] Xenial is not the default image <MAAS:Confirmed> <https://launchpad.net/bugs/1566848>
[13:34] <mup> Bug #1566848 changed: [2.0 beta1] Xenial is not the default image <MAAS:Confirmed> <https://launchpad.net/bugs/1566848>
[13:34] <mup> Bug #1560815 opened: [2.0a3] apt-get install maas fails due to postgresql connection <cdo-qa> <MAAS:Opinion> <https://launchpad.net/bugs/1560815>
[13:44] <mup> Bug #1560815 changed: [2.0a3] apt-get install maas fails due to postgresql connection <cdo-qa> <MAAS:Opinion> <https://launchpad.net/bugs/1560815>
[13:44] <mup> Bug #1566848 opened: [2.0 beta1] Xenial is not the default image <MAAS:Confirmed> <https://launchpad.net/bugs/1566848>
[14:01] <ScabS> Hi, can i get help with nodes commissioning here?
[15:13] <cscf> Right on maas.io, it says MaaS integrates with Salt.  But I can't find any Salt Provider plugin for MaaS.
[15:16] <cscf> Has anyone here gotten this "Salt integration" working?
[15:26] <mup> Bug #1523971 changed: [xenial,1.9]Failure when creating interface on cluster with MAAS 1.9 under Xenial <python3> <MAAS:Invalid> <https://launchpad.net/bugs/1523971>
[15:26] <mup> Bug #1566920 opened: Cannot change power settings for machine <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1566920>
[17:11] <mup> Bug #1512742 changed: Mouseover an item in Storage/Available Disks and Partitions causes filesystem to disappear <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1512742>
[17:38] <mup> Bug #1557100 changed: [2.0a1] Fabric IDs (and thus default names) can get very large if rack continually fails to register <MAAS:Won't Fix> <https://launchpad.net/bugs/1557100>
[18:56] <mup> Bug #1561659 changed: MAAS fails to deploy on a system with 4Kn (4096-byte native sector size) disk <MAAS:Incomplete> <MAAS 1.9:Incomplete> <https://launchpad.net/bugs/1561659>
[18:56] <mup> Bug #1564977 changed: curtin miscalculates partition offsets when logical_block_size is 4k <sts> <uosci> <curtin:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1564977>
[19:20] <QCC> not sure the level of interest, but wanted to announce my first bzr checkin.  A few of us here at Caringo are embarking on MAAS development this week.
[19:20] <QCC> I encountered errors with buildout when running make.  Fix for me was to bump versions of flake8 and pep8.
[19:20] <QCC> I branched from trunk and pushed to lp:~quentin-conner/maas/trunk
[19:20] <QCC> Eventually we will suggest a merge but are pretty far away right now
[19:41] <roaksoax> QCC: sounds good! what version of Ubuntu are you using for dev ?
[19:50] <QCC> Hey roaksoax, this is 16.04 Beta2, Desktop edition
[19:50] <QCC> I had fun today
[19:51] <roaksoax> QCC: glad to hear that! do please file bugs reports :)
[19:51] <QCC> On another topic, we don't expect any Postgres deadlocks during 'make test', do we?
[19:51] <QCC> I did do a quick bug search.  Just learning.  Will file.
[20:01] <roaksoax> QCC: thanks!
[20:03] <QCC> my pleasure.  bzr's not so bad...  I expect the bot will post something about bug 1567055 here soon
[20:04] <roaksoax> 16:04 < mup> Bug #1567055 opened: flake8, pep8 buildout error <MAAS:New> <https://launchpad.net/bugs/1567055>
[20:04] <roaksoax> QCC: it will, the internal already did
[20:14] <mup> Bug #1567055 opened: flake8, pep8 buildout error <MAAS:New> <https://launchpad.net/bugs/1567055>
[22:12] <mup> Bug #1567103 opened: [2.0 beta 1] maas-region createadmin shouldn't require email to be provided <MAAS:New> <https://launchpad.net/bugs/1567103>