[06:44] <Kilos> o/
[07:53] <popey> Morning
[09:44] <ahoneybun> o/
[09:47] <Kilos> o/
[09:47] <popey> o/
[09:49] <ahoneybun> heyo Kilos and popey
[09:49] <Kilos> hi ahoneybun popey
[11:56] <Kilos> popey you having any success with spreadubuntu
[11:56] <popey> no
[11:56] <Kilos> oh my
[11:56] <Kilos> recruit helpers
[11:56] <popey> it would be somewhat easier if the person hosting the actual site looked at this
[11:57] <popey> as it's hard to replicate
[11:57] <Kilos> can you mail a request to him or even via me, just explain what you need done
[11:58] <Kilos> mainly so i can understand as well
[11:58] <popey> Well, it's not what I need done.
[11:58] <Kilos> hehe
[11:58] <popey> Whoever has access to the box which has the site on needs to debug what's going on
[11:58] <popey> look at logs etc
[11:58] <Kilos> ok explain what he needs to do in the mail
[11:58] <Kilos> is that ok?
[11:59] <Kilos> i cant get into rt.ubuntu.com either so i have no idea whats wrong
[11:59] <popey> ok, but I'm kinda surprised this hasn't been done already
[11:59] <popey> adding me into the mix to just say "hey, have you actually looked at the logs" seems a bit late
[12:01] <popey> but sure
[12:01] <Kilos> he told me once he has no time to do much of anything anymore,
[12:01] <Kilos> life seems to have taken control of him
[12:02] <Kilos> i didnt want to dig too deep in his hassles
[12:03] <popey> ok
[12:03] <popey> mail sent
[12:03] <Kilos> ty sir
[12:08] <popey> np
[18:08] <ahoneybun> mhall119, who do I talk to about stickers with the Kubuntu logo?
[18:45] <mhall119> ahoneybun: somebody who makes stickers
[18:47] <mhall119> ahoneybun: try the unixstickers.com folks
[18:48] <knome> ahoneybun, ^ they are our officially endorsed vendor for stickers
[18:48] <ahoneybun> knome, well now they are
[18:49] <ahoneybun> mhall119, I don't want to hit legal issues
[18:49] <knome> ahoneybun, "now"?
[18:49] <knome> ahoneybun, they've been for a while, we specifically mention them on our website as well
[18:49] <knome> in return for that, they basically give us free stickers for every N purchases
[18:49] <knome> you need to talk with pleia2 about the details as she's the one who's worked with them
[18:50] <ahoneybun> thanks knome they had been talking to Canonical for a while to make them though
[18:50] <mhall119> ahoneybun: I think they assumed they couldn't at some point, but after talking with Canonical they were given the green light
[18:51] <knome> ok, time to go do something else
[18:51] <knome> have a nice evening!
[18:52] <ahoneybun> pleia2, Kubuntu stickers from unixstickers?
[18:57] <ahoneybun> mhall119, I know the logos have legal hoops over them to use
[19:05] <mhall119> ahoneybun: only if you're doing something outside the existing trademark grand
[19:05] <mhall119> grant
[19:08] <ahoneybun> mhall119, which I don't know what it is
[19:10] <mhall119> ahoneybun: http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy Section 7
[19:10] <mhall119> IIRC, unixsticker.com was concerned about whether or not their selling of stickers would be a commercial use or not
[19:10] <ahoneybun> mhall119, Canonical's legal decisions are odd to be nice
[19:10] <mhall119> either way, the've been given the okay to use the marks in stickers, so there shouldn't be any problem with them using Kubuntu
[19:12] <mhall119> ahoneybun: oh I know it, the only clear lines would be "nobody else can use it, ever" and "anybody can use it for anything", Canonical is trying to navigate a reasonable path between those two extremes
[19:12] <ahoneybun> I know it is very tough to be fair when it comes to keeping a bottom line
[19:13] <mhall119> this isn't even about money, it's about reputation
[19:13] <mhall119> you wouldn't want some company selling "Kubuntu" that they had modified to include backdoors and keyloggers
[19:14] <mhall119> we can't stop them from doing that with the code, but we can stop them from telling people that their monstrosity is "Kubuntu"
[21:57] <tsimonq2> mhall119: (CC wxl) speaking of http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy , Section 4 states a few different flavors. So the flavors not listed are not covered? How's that work?
[21:58] <wxl> tsimonq2: from what i know from redwolf, he had to ask canonical legal for the right to use lubuntu on lubuntu.me.
[21:58] <mhall119> tsimonq2: probably those were all the official once when the policy was drafted
[21:59] <tsimonq2> mhall119: what kind of makes me confused is this statement: "Canonical’s Trademarks (registered in word and logo form) include:"
[22:00] <tsimonq2> mhall119: I'm no lawyer, but shouldn't that be s/include/include but are not limited to/ ?
[22:00] <mhall119> what confuses you about that?
[22:00] <tsimonq2> ¯\_(ツ)_/¯
[22:00] <mhall119> meh, that's lawyer-level details
[22:02] <tsimonq2> I mean, if they cite specific flavors, it might be worth it to update to remove the specific flavors and add an umbrella statement such as, "All flavors officiall recognized by the Ubuntu Community" (maybe add "Council" on the end of that)
[22:02] <tsimonq2> mhall119: what about Snappy?
[22:02] <mhall119> file a bug against lp:ubuntu-website-content if you'd like
[22:03] <mhall119> "snappy" isn't really the official name of anything
[22:03] <mhall119> "snapd", "snapcraft", "snap-confine", etc are
[22:03] <wxl> s/snappy/ubuntu core/
[22:03] <tsimonq2> mhall119: is there any way that bug report can be brought to the attention of the legal team? (subscribing)
[22:03] <tsimonq2> good point wxl
[22:04] <mhall119> tsimonq2: the web team will most likely bring it up with them when they triage the bug
[22:04] <tsimonq2> ok, thanks mhall119


[21:37] <codfection> hi
[21:37] <codfection> how can I contribute into xubuntu development?
[21:53] <knome> hello
[21:53] <knome> there are many ways; in what area would you like to contribute in?
[21:54] <knome> development as in bug fixing and writing code or something else?


[12:52] <Volkodav> You put it on hold
[13:34] <timppa> Hi!
[13:34] <timppa> I just upgraded my laptop to 16.10. I wish to test out unity8 but I cannot add ubuntu1 account and downloads on apps does  not work. Any idea how to fix this?
[18:11] <timppa> ping!
[18:12] <timppa> Anyone know how to add ubuntu1 account on Ubuntu 16.10?? I'd like to use/test unity8
[18:12] <timppa> Currently I cannot install any apps :/


[00:00] <DanaG> I find that even my AHCI host system needs initrd, since the ahci driver is no longer built-in.
[00:02] <rcn-ee> rereading bug report... rlameiro does it work if you leave a usb-flash connected when you remove and insert another device?
[00:03] <rlameiro> rcn-ee: didnt tried
[00:03] <rlameiro> i will try now
[00:03] <rlameiro> need to reboot first
[00:04] <rlameiro> rcn-ee: thats another weird thing
[00:04] <rcn-ee> okay, no rush.. we had something like that on the beagle.. at one time everything had to be plugged in at boot.. weird things would happen if all devices where removed then added.. so the trick was to leave something connected.. 2.6.29 days..
[00:04] <rlameiro> i plugged now the hub and it didnt recognied it
[00:05] <rlameiro> it needs to be connected at boot
[00:05] <persia> rlameiro, You don't want to not use an initrd: theoretically it works without one, but that path is very poorly tested, and prone to issues.
[00:09] <rlameiro> rcn-ee: !!!!! WORKS!!!!!!!
[00:09] <rlameiro> how can i mount my flash drive on the cli
[00:10] <rcn-ee> mkdir ./tmp ; sudo mount /dev/sdxX ./tmp
[00:11] <rcn-ee> so it sounds like an ehci bug.. when no devices are connected it turns to a state and new devices don't get it out..
[00:11] <rlameiro> yeap
[00:11] <pwnguin>  /win 14
[00:12] <rlameiro> rcn-ee: how do i know th xX on the sdxX ??
[00:12] <rlameiro> sorry for the newbiness
[00:12] <rcn-ee> no problem... "sudo fdisk -l" L.. is easiest
[00:14] <rcn-ee> thinking out loud and googleing..... isn't there a "debug-usb" option for the bootargs?
[00:15] <rlameiro> rcn-ee: so, is there a correction for this bug?
[00:17] <rcn-ee> on the beagle it was: use a newer kernel that worked better... but that was 2.6.27/28/29 days.. so i dont' think that one applies..  I'm looking on google for a way to debug the usb subsystem on bootup, maybe that would show something..
[00:20] <rcn-ee> rlameiro, does your current kernel have "cat /boot/config-* | grep CONFIG_USB_DEBUG" ?
[00:21] <persia> I think most of the DEBUG config options aren't used (and `grep CONFIG_USB_DEBUG /boot/config-*` is faster)
[00:22] <persia> Unless there's a way to change them via boot parameters, might need a special kernel build.
[00:22] <rcn-ee> yeah it is thanks. ;)  rlameiro does it also happen with my kernel?
[00:22] <rcn-ee> take me about 3 minute to build one if it does..
[00:22] <persia> (we had issues in the past with kern.log overflowing the SD cards, and had a firm discussion with the kernel team)
[00:23] <rcn-ee> yeah, that's way to wear out an SD card quickly. ;)
[00:23] <rlameiro> rcn-ee: yes it did  happend with you kernel
[00:23] <rcn-ee> okay, then it'll be a valid test, just take a moment..
[00:23] <persia> Filled them up back in the early imx51 days when folks were using pre-pre-pre-production hardware.  I ended up writing a syslog.conf fragment so that people could complete the installer.
[00:25] <rcn-ee> I'm seeing something similar with my hacked up lucid NetInstall, the 2.6.35 kernel's HID input it noisy, the log is unreadable..
[00:28] <rcn-ee> okay they are up... rlameiro uImage and modules here.. and yes it's about 20kb download. ;) good for beer breaks..  http://rcn-ee.homeip.net:81/testing/lp-646985/CONFIG_USB_DEBUG/
[00:46] <rlameiro> rcn-ee: what did you put on your kernel?
[00:46] <rlameiro> its working
[00:47]  * persia dislikes heisenbugs intensely
[00:47] <rcn-ee> crap, what? did my previous build work? alli changed was two configs...
[00:47] <rlameiro> well
[00:47] <rlameiro> stoped working...
[00:47] <rlameiro> wow
[00:47] <rcn-ee> yay! ;) the logs should have more usb stuff..
[00:48] <rlameiro> where is the log file?
[00:49] <rcn-ee> it should be in the system log... off the top of my head i don't remeber which one.. but "dmesg > log.txt" then pastebin that log.txt should give us an idea of what's happening..
[00:50] <persia> /var/log/kern.log most likely
[00:50] <persia> Oh, and /var/log/dmesg.log may also be interesting, but likely less verbose.
[00:50] <rcn-ee> so both just incase. .;)
[00:50] <rlameiro> rcn-ee: http://dl.dropbox.com/u/1333955/usb.txt
[00:51] <rlameiro> dmesg > ub,txt :D
[00:51] <rlameiro> i forgot how cool is piping :D
[00:52] <rcn-ee> humm.. usb: resume on port1, status -19
[00:53] <persia> Next trick: `pastebinit /var/log/dmesg`
[00:53] <rlameiro> dont be scared its a 10 port hub
[00:53] <persia> The one with the extra socket on the end?
[00:54] <rlameiro> http://pastebin.com/P613QrxR
[00:54] <rlameiro> persia:  its trust one
[00:54] <persia> different than mine then :)
[00:55] <rlameiro> http://www.trust.com/products/product.aspx?artnr=16131
[00:56] <rcn-ee> humm, i'm stumped. ;)  i'd add that dropbox link to the launchpad bug, we are going to need one of the ti/nokia usb guys to look at it..
[00:57] <rlameiro> good that you mentioned it
[00:57] <rlameiro> i could delete it otherwise
[00:57] <persia> Better to put the original file into the bug, rather than the link to dropbox, just in case.
[00:57] <rcn-ee> you could upload it too.. then not worry about hosting it..
[00:58] <rcn-ee> it looks like it's defintelly stuck in suspend mode...
[00:59] <rlameiro> i can try with a diferent hub
[00:59] <rlameiro> 4 ports self powered
[00:59] <rlameiro> will it make diference?
[00:59] <rcn-ee> it might... if it fails it's just more ammo for a bug..
[01:00] <rlameiro> ok
[01:03] <rlameiro> http://pastebin.com/RmnF40NZ
[01:03] <rlameiro> with the other, this was faster failing
[01:06] <rlameiro> rcn-ee: http://dl.dropbox.com/u/1333955/usb4.txt
[05:34] <Neko_> is there a uboot irc channel?
[09:18] <persia> Neko_, Used to be #u-boot, but has been deregistered.  Dunno to where folks may have migrated (if they did).
[13:41] <ajay> hi all i have ubuntu 10.04 kernel and Serial controller: Device 4348:3253 but minicom is not working on this
[13:41] <ajay> i mean no boot message i  am able to get over serial port
[13:50] <persia> The images we produce don't use serial console by default.
[13:50] <persia> You'd have to do something special to get one (add it to kernel command line, etc.)
[13:56] <rcn-ee> hey persia, how frozen is the kernel for new patches? ;)  With the help of some meego guys, we figured out which 11 patches cherrypicked from 2.6.36 make the display work correctly on 2.6.35.. ;)  I'll file a bug and list the patches, so you guys can decide. ;)
[13:56] <rcn-ee> duh, i should list teh board... devkit8000
[13:58] <persia> rcn-ee, Which kernel?
[13:59] <persia> (the answer will be somewhere between jello and cabonite)
[14:00] <rcn-ee> the 11 patches were merged in the 2.6.36-rc with tony's merge.. they apply cleanly to the 2.6.35 kernel..  They basicly fix the power rails so the display actually gets setup properly...
[14:00] <persia> I should have asked: "Which kernel source package in Ubuntu?"
[14:01] <rcn-ee> um.. the combined omap3/x86 tree.. it only touches arch/arm/mach-omap2/board-devkit8000.c
[14:02] <persia> "linux"?  That would be "carbonite".  We have to show security fault, major regression, user data loss, etc.
[14:02] <persia> But we can prepare a set of patches to be dropped immediately post-release as an update.
[14:04] <rcn-ee> right now it'll bootup: omapfb error or something about can not init display....
[14:05] <rcn-ee> the problem with these boards, not a lot of people have them so it's not a big % (i don't even have one to test)  But i can file a bug link to the patches then if someone tries to run ubuntu with a devkit8000 will have a bug to read and help debug. ;)
[14:08] <persia> Please do file a bug.  Extra points for shepherding the patches through the SRU process to make them available post-release.
[14:08] <persia> Folks won't be able to use the display first-boot, but ought be able to update, and use it second boot.
[14:09] <rcn-ee> true..  and since they are merged, maverick+1 will work out of the box.. (pending some random breakage patch. ;))
[14:49] <rlameiro> afternoon
[14:50] <rlameiro> jo-erlend_igep:hey, wasnt you that had a problem with wifi on igep?
[16:29] <rlameiro> igep is going to launch a 1ghz version with OMAP3730
[18:56] <rlameiro> saturday its really slow over here...


[12:19] <meena> aciba[m]: updated the bug https://github.com/canonical/cloud-init/issues/4193#issuecomment-1620143934
[12:19] -ubottu:#cloud-init- Issue 4193 in canonical/cloud-init "FreeBSD: get_tmp_exec_path() still fails" [Open]
[12:20] <meena> let's see if i can get this fixed
[12:53] <meena> https://github.com/canonical/cloud-init/pull/4222
[12:53] -ubottu:#cloud-init- Pull 4222 in canonical/cloud-init "mount parse: Fix matching non-existent directories" [Open]
[14:38] <OutOfService> hi people
[15:01] <meena> OutOfService: hi
[15:02] <OutOfService> meena, do you know the differences between cloud-init and ubuntu autoinstall? I think I'm quite lost. The use the same user-data file, right?
[15:03] <meena> cloud-init invokes autoinstall, from what i gather
[15:03] <OutOfService> it's more than what I do hehehe
[15:04] <meena> while i am a cloud-init developer, I'm developing for FreeBSD… and while I am writing this message from an Ubuntu based laptop, i haven't used Ubuntu as server in… uh, a long time
[15:05] <meena> also, i think, it's July 4th, and everyone who's US based and could answer any questions is probably having BBQ
[15:05] <OutOfService> I do not use ubuntu as well, but I'm trying to configure an ipxe server in order to autoinstall some test machines, and I don't want to spend time configuring their install options. That's why I'm messing up with ubuntu at this moment.
[15:05] <OutOfService> thanks for your help, anyway
[15:05] <meena> OutOfService: i recommend asking in #ubuntu-server
[15:06] <OutOfService> it's an option, yes
[15:06] <OutOfService> I'll give it a try
[15:06] <minimal> OutOfService: ubuntu autoinstall is a SUPERSET of cloud-init config
[15:07] <OutOfService> i don't know what superset means. I'm sorry for my poor english. I'm spanish
[15:07] <OutOfService> do you mean that cloud-init calls autoinstall?
[15:07] <minimal> no, the ubuntu server stuff makes use of cloud-init
[15:07] <OutOfService> ok
[15:09] <OutOfService> I can promisse that I read most of the cloud-init documentation, but for me, its being hard to understand, and to differentiate cloud-init from ubuntu autoistall.... I don't wan to be bad, but I think that documentation could try to be a little more speccific, maybe.. or written for not so clever people :)
[15:09] <minimal> OutOfService: you were also pointed to several Ubuntu docs about this several days ago
[15:09] <OutOfService> yes, i did
[15:10] <OutOfService> I think I'm getting old
[15:10] <minimal> so that should have provided everything you need to know
[15:10] <OutOfService> anyway... ay this moment I'm so confused that I don't have any specific question to make....
[15:10] <OutOfService> but i like being here in order to try to learn from other people and questions
[16:41] <meena> aciba[m]: https://github.com/canonical/cloud-init/pull/4222 is ready to review!
[16:41] -ubottu:#cloud-init- Pull 4222 in canonical/cloud-init "mount parse: Fix matching non-existent directories" [Open]


[06:50] <dholbach> good morning
[07:09] <fgimenez> good morning
[07:20] <dholbach> ogra_, ogra2: do you know who could help figuring out https://bugs.launchpad.net/snappy/+bug/1506480 (link to "Kernel requirements for Snappy" is broken and I'm not sure what else to link to)?
[08:26] <Chipaca> asac: beuno: http://jimbenton.tumblr.com/image/131162934224
[08:29] <tasdomas> morning
[08:30] <Chipaca> mo'in!
[08:30] <tasdomas> the wiki specification for snappy confinement mentions an assign.yaml file that can be used instead of running the hw-assign command
[08:30] <tasdomas> however, I couldn't find any more information about it (format, etc.)
[08:30] <tasdomas> is it supported?
[08:33] <Chipaca> tasdomas: where does it mention that?
[08:34] <tasdomas> Chipaca, https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
[08:35] <Chipaca> tasdomas: there's no assign.yaml in that doc
[08:35] <Chipaca> tasdomas: it says "assign yaml"
[08:35] <Chipaca> tasdomas: no dot
[08:35] <Chipaca> tasdomas: it's not a file; it's part of the oem config
[08:35] <tasdomas> Chipaca, ah, sorry - misread that
[08:36] <Chipaca> tasdomas: so, yes it's supported, for oem snaps
[08:37] <tasdomas> Chipaca, so for my own snap the only thing to do is use hw-assign, right?
[08:37] <Chipaca> tasdomas: right
[08:38] <Chipaca> tasdomas: what're you wanting to do?
[08:38] <tasdomas> Chipaca, I was writing a simple snappy app to control the piglow device on my orange matchbox
[08:38] <tasdomas> Chipaca, http://domas.monkus.lt/posts/2015-10-15-writing-a-snappy-application/
[08:39] <tasdomas> Chipaca, my main problem was that I need to restart the service after assigning the i2c device to it
[08:39] <Chipaca> really?
[08:39] <Chipaca> that's surprising to me -- but then i know little about i2c and the rpi2
[08:40] <Chipaca> tasdomas: are you sure it's not that you need to restart the service that uses it?
[08:40] <Chipaca> (that'd be bug 1484645 fwiw)
[08:40] <tasdomas> Chipaca, sorry - maybe I wasn't clear - my problem was that I needed to restart the service (exposed by my snappy app) that uses the i2c device
[08:41] <Chipaca> wow, it's going to be a long day
[08:41] <Chipaca> because you said exactly that
[08:41] <Chipaca> sorry :-(
[08:42] <Chipaca> tasdomas: that's a bug, we know about it, should get fixed (on rolling/edge) soonish
[08:42] <tasdomas> Chipaca, ah, cool!
[08:42] <tasdomas> Chipaca, can I bother you with one more question?
[08:42] <Chipaca> tasdomas: i dount you can bother me with a question, but you're welcome to try
[08:42] <Chipaca> doubt*
[08:42] <tasdomas> there's an mqtt snappy app available in the store - but I can't find the source for it
[08:43] <tasdomas> I want to modify it to make it mdns discoverable
[08:44] <Chipaca> tasdomas: have you tried asking the snap publisher?
[08:45] <Chipaca> or gone to the snap support url?
[08:45] <Chipaca> tasdomas: this one, i presume https://search.apps.ubuntu.com/api/v1/package/mosquitto.kartben
[08:46] <tasdomas> Chipaca, ah, will do
[08:48] <dpm> davidcalle, dholbach, looking at askubuntu, there seems to be quite a lot of questions around snappy already
[08:48] <dpm> might be worth for us looking at them in the upcoming weeks
[08:49] <dholbach> maybe we can talk about it in our next docs hour call?
[08:50] <dholbach> dpm, ^
[08:50] <dpm> it could be a good topic, yes
[08:50] <dholbach> cool
[08:50] <davidcalle> dholbach, dpm, +1
[08:54] <tasdomas> by the way, is it possible to use snapcraft to build a snappy package for a different architecture? e.g. build a RPi2 compatible package on my amd64 laptop?
[08:55] <dpm> davidcalle, dholbach, it might be worth creating a snapcraft tag as well. Right now we've got 'snappy' already, which redirects to 'ubuntu-core'
[08:56] <dholbach> yep, that makes sense
[08:58] <dholbach> ciao ppisati, do you know how we could fix https://bugs.launchpad.net/bugs/1506480? (which information should we link to in the article there?)
[09:00] <JamesTait> Good morning all; happy Friday, and happy World Food Day! 😃
[09:22] <ogra_> dholbach, ppisati should be able to help with the link
[09:22] <dholbach> cool
[09:30] <dpm> dholbach, davidcalle, do we have any document that specifies the format of the snapcraft.yaml file?
[09:32] <dholbach> dpm, no spec-like doc in our docs yet, but there's 1) https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/ and 2) ./examples in lp:snapcraft and 3) https://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/snapcraft-advanced-features.md which will land as soon as the md importer is working
[09:32] <davidcalle> dpm, closest thing we have to a spec for it in the the App dev manual
[09:32] <dholbach> ah yes, and that
[09:32] <davidcalle> It's actually quite detailed
[09:33] <dpm> davidcalle, yeah, I've gone through 1) and 2), but I've been missing a doc that is specific to snapcraft.yaml
[09:33] <davidcalle> dpm, https://docs.google.com/document/d/1Rj9nVBttx62BvGlbnkmKOzAlAIEWuLNr1QaSGe3gQDA/edit#heading=h.8o7w1g30gucy
[09:34] <dpm> ahaha
[09:35] <dpm> I had actually seen this, but couldn't figure out where, glad I wasn't going mad
[09:35] <davidcalle> dpm, not sure the link is world-readable though, hopefully next week in some form on duc...
[09:35] <dpm> yeah
[09:52] <dpm> davidcalle, dholbach, http://askubuntu.com/questions/686167/what-is-snapcraft, this might help with AskUbuntu/Stackoverflow searches to give a 5 min intro and direct folks to the site
[09:53] <Chipaca> mvo: ping
[09:54] <davidcalle> dpm, this is excellent
[09:54] <davidcalle> dpm, love it :)
[09:54] <mvo> Chipaca: pong
[09:54] <dpm> glad it if it's useful :)
[09:54] <Chipaca> mvo: this race condition with the automount unit
[09:55] <Chipaca> mvo: tell me about it
[09:56] <mvo> Chipaca: its not that much that I know - so the code will activate and start the automount unit, right after that it runs the click stuff
[09:56] <dholbach> dpm, nice one!
[09:56] <dholbach> dpm, now we can't change the URLs anymore! :-)
[09:56] <mvo> Chipaca: when I do not unpack the meta,.click dirs it will fail to generate the apparmor profiles
[09:57] <mvo> Chipaca: however ls a bit later is fine
[09:58] <dpm> dholbach, oh, I can update the link after we've done the IA rearrangement. Or just make it point to https://developer.ubuntu.com/snappy
[09:58] <mvo> Chipaca: hm, maybe its something else, need to look deeper
[09:58] <dholbach> dpm, or we add redirects - in any case, no problem :)
[09:58] <Chipaca> mvo: aiui, systemctl should not return until automount has actually started
[09:59] <Chipaca> mvo: maybe we're creating the units but not starting the .automount until later?
[09:59]  * Chipaca looks
[09:59] <mvo> Chipaca: adding a sleep did not solve it, so its something else
[10:00] <mvo> Chipaca: here we go, its a missing .click/manifest in the snap :/
[10:00] <mvo> Chipaca: sorry
[10:00] <mvo> Chipaca: let me fix that
[10:01] <Chipaca> hue hue hue, to quote a brazilian
[10:01] <mvo> Chipaca: we also may want to keep the .meta for now because of "snappy list -v"
[10:01] <mvo> unless we go husks
[10:01] <Chipaca> mvo: that one i don't follow
[10:01] <Chipaca> mvo: once automount is started, any access under it will trigger the mount
[10:01] <Chipaca> mvo: even if you're accessing things that are there
[10:02] <mvo> Chipaca: so only the active snap has a automount unit
[10:02] <Chipaca> ohhhh
[10:02] <mvo> Chipaca: so snappy list -v (old snap) will not have a meta/packages.yaml
[10:02] <Chipaca> yep yep
[10:02] <Chipaca> so, yeah, leave it for now, flag it for removal when we switch to lightweights
[10:02] <Chipaca> ok
[10:03] <mvo> yeah, will do
[10:03] <Chipaca> mvo: have you checked it for speed?
[10:04] <mvo> Chipaca: not yet, no
[10:04] <Chipaca> k
[10:04] <Chipaca> mvo: the lightweight thing of looking at remote manifests does not work for sideloaded stuff though
[10:04] <mvo> Chipaca: one more complication - the hooks expect .click/$name.$origin.manifest - and the $origin is not known at build time. so we can not ship that in the snap and need to generate it
[10:05] <mvo> Chipaca: once hooks are gone this is no longer a issue of course
[10:05] <Chipaca> hooks were going to be gone "soon" since i joined
[10:05] <Chipaca> not lookin' good
[10:05] <mvo> yeah
[10:05] <mvo> there is only one left
[10:05] <mvo> but that one is pretty sticky :P
[10:57] <mvo> Chipaca: do you want me to split the branch for the snapfs-mount up more?
[10:58] <Chipaca> mvo: how would you split it?
[10:58] <Chipaca> unless you moved all the systemd stuff to .. ahem .. systemd :-p
[10:59] <Chipaca> mvo: anyway, you don't have to, but my review is slower :)
[10:59] <mvo> Chipaca: I can do that I think if it helps (I will do that in any case in this MP, your suggestion makes sense)
[10:59] <mvo> but lunch first
[10:59] <Chipaca> mvo: i'm not sure the total time would be less, so i'd say nah
[12:18] <beuno> Chipaca, lol
[12:44] <longsleep> yaml question, how can i have a binary with a _ in the name?
[13:07] <tedg> sergiusens: So I think I may need to copy the options locally to stay under the 79 character limit :-)
[13:30] <sergiusens> tedg, harr harr :-)
[13:30]  * sergiusens notices that today is not talk like a pirate day
[13:30] <tedg> sergiusens: It can be here!
[13:30] <tedg> matey
[13:31] <sergiusens> tedg, I couldn't sleep last night thingking about the override of setup_stage_packages; maybe it is best to use repo.Ubuntu directly instead
[13:31] <tedg> Since we can't have casual Friday's working from home, we should have talk like a pirate Fridays.
[13:31] <sergiusens> tedg, right on
[13:31] <tedg> sergiusens: Heh, I never meant for you to lose sleep over it :-)
[13:31] <sergiusens> although my vocabulary is rather scarce
[13:31] <sergiusens> tedg, it is one of those things
[13:32] <sergiusens> I also stayed up late as I went to a docker meetup to see a bunch of old friends
[13:32] <sergiusens> learned a lot about docker and why developer like it so much
[13:32] <tedg> I'm feeling like we might need to detach the plugin lifecycle from the overall one. Like have more phases for plugins.
[13:33] <tedg> I think it is nice. I just haven't see the overlays actually work well.  I know we were both pretty busy yesterday
[14:18] <mvo> jdstrand: I saw it but have not acted on it yet, sorry
[14:20] <jdstrand> mvo: ack
[15:03] <dholbach> sergiusens, I found an interesting one: http://pastebin.ubuntu.com/12799579/
[15:03] <dholbach> not sure if we support this
[15:03] <dholbach> tedg, ^
[15:04] <dholbach> I just used: apt-get source bamtools
[15:04] <sergiusens> dholbach, thanks, perfect example for custom plugin
[15:04] <dholbach> I'll leave that one for you then :)
[15:22] <dholbach> tedg, sergiusens: I added two more examples to the pad
[15:23] <Chipaca> sergiusens: i should probably have pointed you at that talk earlier
[15:23] <Chipaca> sergiusens: 's good stuff
[15:23] <elopio> mvo: Chipaca: yes! with this last test I saw the moment when the last cloud init message appeared and the moment when the mode switched to regular. It's just twice as slow as the last time I tried.
[15:23] <elopio> fgimenez: ^
[15:23] <elopio> Chipaca: tell me more about waiting for a systemd service.
[15:24] <Chipaca> elopio: it's just a for loop with a sleep and a check
[15:24] <Chipaca> elopio: give me a sec
[15:25] <elopio> Chipaca: ah, we have that.
[15:25] <Chipaca> elopio: ah! show me the code :)
[15:25] <elopio> I thought you were talking about subscribing a listener to the service or something like that.
[15:25] <Chipaca> elopio: well, you could, but why bother
[15:26] <elopio> Chipaca: https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/testutils/wait/wait.go
[15:26] <elopio> to work around the workaround I will just have to increase the maxWaitRetries.
[15:27] <Chipaca> elopio: and you're waiting for bootok?
[15:27] <elopio> Chipaca: I'm waiting for snappy_mode=regular
[15:28] <Chipaca> elopio: and is that better, or worse than waiting for boot ok?
[15:28]  * sergiusens wonders if it is beer o clock already
[15:28] <Chipaca> sergiusens: it is!
[15:29] <elopio> Chipaca: better, I think. Instead of checking the service, we check it's effect.
[15:29] <Chipaca> sergiusens: you should come visit. can't have beer on my own (and ellie doesn't do beers)
[15:29] <elopio> *its
[15:29] <elopio> it's beer-on-hangout o'clock.
[15:30] <Chipaca> elopio: so, yeah, looks like you're already doing the right thing and all :)
[15:30] <Chipaca> elopio: wrt increasing maxWaitRetries, maybe instead have an arch-dependent base?
[15:30] <Chipaca> elopio: ie scale checkInterval by some bogomips factor
[15:31] <elopio> Chipaca: that would be nice.
[15:31] <Chipaca> var bogomips = map[string]int{"arm": 100, "amd64": 1, etc}
[15:31] <Chipaca> and index it on GOARCH
[15:31] <elopio> I'll make a card to be able to configure the wait, with a delay factor.
[15:32] <elopio> but anyway, this is a bug :) Instead of working it around, somebody should fix it.
[15:32]  * elopio looks at somebody.
[15:32] <Chipaca> elopio: which is the bug, exactly?
[15:32] <Chipaca> elopio: that you can ssh in before you can log in?
[15:33] <elopio> Chipaca: you can sign in before boot-ok. both ssh and normal log in through serial. And if you are fast with a rollback, that makes the boot crazy.
[15:33] <elopio> https://bugs.launchpad.net/snappy/+bug/1498293
[15:33] <elopio> on bbb you don't have to be super fast. I actually can reproduce this manually.
[15:35] <Chipaca> elopio: so that's the bug
[15:35] <Chipaca> elopio: not that "try" thing :)
[15:36] <Chipaca> so, we want the boot-ok to be done *before* ssh and getty lets people in
[15:37] <Chipaca> pitti: do you remember offhand whether there's a target that would let us do that easily?
[15:37] <elopio> Chipaca: I think so. You could fix the rollback so it waits for boot-ok, but then it might affect something else.
[15:38] <elopio> Chipaca: and if you just move the log in after boot-ok, the reboot will take twice the time to let you access the board.
[15:39] <Chipaca> elopio: well, but it's letting you in before things are ready
[15:39] <sergiusens> Chipaca, I don't mind visiting; when are we having a sprint in London?
[15:40] <Chipaca> sergiusens: i have space for two for half a week every week
[15:40] <Chipaca> as long as they're not super tall :)
[15:40] <elopio> Chipaca: well, before cloud-init has finished. Most of the things are ready.
[15:41] <dholbach> tedg, sergiusens: is the announce text roughly what you expected?
[15:42] <sergiusens> dholbach, where is it?
[15:42] <dholbach> sergiusens, ah sorry - on the pad :)
[15:43] <sergiusens> dholbach, looks good, just added on clarification just in case
[15:43] <dholbach> thanks sergiusens
[15:43] <sergiusens> dholbach, btw, how hard would it be to patch clog?
[15:43] <dholbach> rock and roll
[15:43] <dholbach> let me check
[15:44] <sergiusens> dholbach, so ideally, patch CMakeLists.txt to take an arg to provide an alternate ~/.clogrc path
[15:44] <tedg> If sergiusens is happy I'm good.
[15:45]  * tedg didn't keep a link to the pad :-)
[15:45] <dholbach> tedg,
[15:45] <dholbach> http://snappy.asac.ws:9001/p/snapcraft-clinics
[15:45] <sergiusens> -DLOGRC_PATH=$SNAP_APP_DATA_PATH or something like that, and then the code would need to expand the var
[15:46] <tedg> dholbach: +1
[15:53] <dholbach> sergiusens, I guess it's not too hard to do - maybe something to look into some other time?
[16:05] <dholbach> tedg, sergiusens: thibautr suggested next time we ask for proposals on what people would like to see snappified :)
[16:05] <fgimenez> have a nice weekend o/
[16:10] <sergiusens> dholbach, sounds like a good idea
[16:10] <sergiusens> dholbach, maybe at the end of the clinic we ask that question too
[16:10] <dholbach> for next time we can maybe leave it a bit more time in advance, so we can collect suggestions beforehand
[17:04] <sergiusens> elopio, very simple MP https://code.launchpad.net/~sergiusens/snapcraft/tested_or_not/+merge/274741
[17:06] <elopio>  sergiusens: why is that needed? I find it good to see if all your test code is being run.
[17:06] <elopio> if it isn't, you can probably remove it. Or you have a condition that has to be faked.
[17:21] <sergiusens> Chipaca, can we get the release from the rest api already or not?
[17:22] <Chipaca> sergiusens: i don't think that's in stable yet
[17:24] <Chipaca> sergiusens: why?
[17:24] <sergiusens> Chipaca, to be able to ask it to be able to ask the store if you know what I mean.
[17:29] <Chipaca> sergiusens: updating to latest edge to see if it's there yet
[17:31] <sergiusens> elopio, ok, it just bothers me to be honest :-)
[17:36] <Chipaca> sergiusens: wait, the release?
[17:36] <Chipaca> sergiusens: you could always get the release!
[17:37] <sergiusens> Chipaca, as in 15.04-core .. btw, I'm not saying you can't, I'm asking if you can! :-D
[17:37] <Chipaca> sergiusens: the store id is what was missing, and is there now
[17:37] <Chipaca> sergiusens: http://pastebin.ubuntu.com/12801235/
[17:38] <Chipaca> sergiusens: ^ that's the output in rolling/edge :)
[17:38] <sergiusens> Chipaca, yup, nice
[17:39] <Chipaca> sergiusens: http://pastebin.ubuntu.com/12801274/
[17:39] <Chipaca> sergiusens: that's 15.04, now
[17:40] <Chipaca> sergiusens: note the socket name has changed
[17:42] <sergiusens> Chipaca, life is good!
[17:43] <sergiusens> Chipaca, mind looking at this https://code.launchpad.net/~sergiusens/snapcraft/build-deps-request-something-missing/+merge/274749 among other complicated things in your life?
[17:44] <Chipaca> sergiusens: i don't *mind*, but it's friday afternoon and the malbec has already confessed its crimes
[17:44] <sergiusens> Chipaca, look at it and then decide ;-)
[17:44]  * Chipaca obeys
[17:45] <Chipaca> sergiusens: no, that's too many lines of code for this hour
[17:45] <Chipaca> sergiusens: also, the complexity is astounding
[17:45] <Chipaca> sergiusens: flabbergasting
[17:45] <Chipaca> sergiusens: maybe split it in two or three and have a team work on it on monday
[17:46] <sergiusens> Chipaca, btw https://github.com/docopt/docopt.go
[17:46] <Chipaca> !
[17:49] <Chipaca> sergiusens: also, in that branch, i think you're using the Schwarzschild metric wrong; you need to use Kruskal–Szekeres coordinates to express it like that
[17:52] <pitti> Chipaca: Before=systemd-user-sessions.service? That's "before people can log in" (I didn't read the full backscroll)
[17:52] <Chipaca> pitti: that includes ssh and getty (both tty and serial)?
[17:53] <pitti> yes
[17:53] <Chipaca> elopio: could you try that?
[17:53] <Chipaca> pitti: thanks!
[17:55] <Chipaca> pitti: can something be after: multi-user.service *and* before: systemd-user-sessions.service?
[17:55] <Chipaca> that seems to be a no-no
[17:55] <pitti> no
[17:55]  * Chipaca could test, but me has already checked out
[17:55] <pitti> as multi-user is after user-sessions
[17:55] <Chipaca> suspected as much
[17:56] <Chipaca> we need to check on monday, then, whether sessions is enough
[17:56] <pitti> it has multi-user in it, after all :)
[17:56] <pitti> right; I'm just on a drive-by, need to leave again
[18:34] <sergiusens> Chipaca, let me fix!
[18:34] <sergiusens> :-)
[18:56] <sergiusens> Chipaca, I like the docopts thing, but I can't easily add help to commands
[20:00] <sergiusens> tedg, final comment wrt setup_stage_packages
[20:01] <sergiusens> and there's a merge conflict (very minor)
[20:01] <tedg> Heh
[20:01]  * tedg isn't sure if he wants to look
[20:02] <tedg> sergiusens: I don't think we can use pull with the current configuration of the command. Because the superclass is just empty.
[20:04] <sergiusens> tedg, right, I mean, pull() -> handle_source_options;
[20:05] <sergiusens> tedg, then have your private implementation of setup_stage_packages keeping self.stage_packages empty (or reuse if you want)
[20:05] <tedg> Oh, I see.
[20:05] <tedg> That seems a little scarier to me...
[20:05] <sergiusens> tedg, in other words, setup_stage_packages should have always been _setup_stage_packages
[20:05] <tedg> Because then we have two overrides
[20:06] <sergiusens> tedg, 2?
[20:07] <tedg> sergiusens: We'd have to override setup_stage_packages to be null, then have pull get sources, setup deps, and then call it.
[20:08] <sergiusens> tedg, let me try and propose something
[20:13] <sergiusens> tedg, meh, I'll do this in another proposal (I'll fix the priv/pub thing first)
[20:13] <tedg> sergiusens: I think restructuring pull() also would help.
[20:14] <sergiusens> tedg, indeed, that's why :-)
[20:14] <sergiusens> well another reason why
[20:14] <tedg> I think there may need to be a "get_deps_from_source()"
[20:14] <tedg> Or something for plugins.
[20:16] <tedg> sergiusens: I'm getting an odd error with trying to copy system libs. Basically the -dev packages are bringing in symlinks and that seems to be confusing snapcraft.
[20:16] <tedg> sergiusens: Does that sound like something you've seen?
[20:19] <tedg> http://paste.ubuntu.com/12804340/
[20:20] <tedg> http://pastebin.ubuntu.com/12804368/
[20:20] <tedg> The first results in the second :-)
[20:31] <sergiusens> tedg, that is weird, the path exists but can't be copied to
[20:31] <sergiusens> tedg, does /home/ubuntu/readlinetest/parts/ginac/install/lib/x86_64-linux-gnu/ exist?
[20:32] <tedg> sergiusens: No
[20:32] <sergiusens> tedg, that is the darn problem then :-/
[20:32] <tedg> sergiusens: I'll get an MR here in a sec.
[20:33] <sergiusens> tedg, its just a mnissing os.makedirs(os.path.basename(real_path, exist_ok=True)
[20:33] <sergiusens> before the copy
[20:35] <sergiusens> tedg, what I don't get is that that lib should of been relinked to the internal one
[20:40] <tedg> sergiusens: There is no internal one because it's on the list of blocked packages.
[20:40] <tedg> sergiusens: I'm not sure that readline should be on that list though.
[20:41] <sergiusens> tedg, ah, then the makedirs missing is the correct thing to do or if it is one of those that is always on the system, add it to the skip list
[20:41] <sergiusens> tedg, right, maybe not; the only real problematic one is libc
[20:42] <sergiusens> tedg, all others come inherited from deb2snap
[20:43] <tedg> sergiusens: So, I think it found a bug, but perhaps it isn't a bad bug once we get everything more refined.
[21:04] <sergiusens> tedg, what bug?
[21:07] <tedg> sergiusens: Not making the directory
[21:11] <sergiusens> tedg, right, that is indeed a bug


[02:24] <mup> PR operator#324 opened: model: don't use --app for relation-get/-set before 2.7.1 <Created by chipaca> <https://github.com/canonical/operator/pull/324>
[06:12] <davigar15> Any updates on this? https://bugs.launchpad.net/juju/+bug/1882127 I have asked in the #juju channel too. I'm not sure which team should look into it.
[08:44] <Chipaca> moin moin
[08:44] <jam> morning Chipaca
[08:45] <Chipaca> jam: had a bit of insomnia yesterday
[08:46] <jam> hi davigar15, I don't have any updates, I'll raise it in standup today with the Juju team to hopefully increase visibility. At a minimum there is a Juju bug if it *ever* panics.
[08:46] <Chipaca> jam: so there's a pr up
[08:46] <jam> Chipaca, yeah, I saw about --app. I was trying to set up different Juju versions to test it for you.
[08:46] <Chipaca> jam: (and email with context on snapcrafters)
[08:46] <Chipaca> jam: <3
[08:46] <Chipaca> incidentally we have no tests with is-app true
[08:47] <jam> Chipaca, well, you can fix that one :)
[08:47] <Chipaca> should i fix it in the same pr i'm touching the code tho
[08:47] <jam> Chipaca, do you know how far back we care about? eg, do we care about 2.6?
[08:47] <jam> Chipaca, adding tests when touching the code sounds like a good thing, no?
[08:47] <Chipaca> jam: I wouldn't care about 2.6 unless somebody asks for it
[08:48] <Chipaca> jam: but i would like to know what would break in 2.6 :-)
[08:48] <Chipaca> at some point
[08:48] <Chipaca> wrt tests, yeah, on it
[08:48] <jam> Chipaca, k. I can at least spin one up and be somewhat aware.
[08:48] <Chipaca> brain not fully engaged
[08:50] <jam> Chipaca, we should (eventually) look to have a "test the features" charm that we can run against various Juju versions. Maybe we can polish 'test-main' to grow into that.
[08:51] <Chipaca> d'oh there's a bug in my pr
[08:51]  * Chipaca fixes
[08:51]  * Chipaca writes tests first
[09:11] <Chipaca> today is going to be a long day
[09:12] <Chipaca> spent 10 minutes trying to figure out why 1.8.0 was saying it didn't have app data
[09:44] <jam> Chipaca, 1.8 ? ah, in testing
[09:44] <jam> I don't think Juju ever had a 1.8 (due to odd numbering with pyjuju vs go juju, etc.)
[09:44] <Chipaca> jam: as opposed to 2.8
[09:45] <Chipaca> ah, yeh
[09:45] <Chipaca> that
[09:46] <Chipaca> i think i'm going to take a break, go outside, see if the cobwebs go away
[09:47] <Chipaca> can't be this /lelo/ for the hangouts
[10:50] <jam> Chipaca, feeling any better?
[10:50] <jam> i'm trying to figure out what the actual issue is that they're running into, because --app was introduced in 2.7.0
[10:56] <mup> Issue operator#223 closed: Operator fails on Juju 2.7.0 and below <bug> <Created by chris-sanders> <Closed by jameinel> <https://github.com/canonical/operator/issues/223>
[10:57] <mup> Issue operator#223 opened: Operator fails on Juju 2.7.0 and below <bug> <Created by chris-sanders> <https://github.com/canonical/operator/issues/223>
[11:00] <Chipaca> jam: omw
[11:37] <facubatista> Muy buenos días a todos!
[11:38] <Chipaca> facubatista: [citation needed]
[11:38] <Chipaca> facubatista: :) hola
[11:39] <facubatista> Chipaca, hola! sorry I skipped the first meeting, had a rough night
[11:57] <Chipaca> facubatista: same here (but 4 time zones)
[12:03] <Chipaca> jam: ping
[12:03] <jam> Chipaca, pong
[12:04] <jam> ah, sorry, brt
[12:13] <Chipaca> and now i'm going to have lunch
[12:13] <Chipaca> i blame james for that
[12:56] <jam> davigar15, can you confirm which charm it is where you run into https://bugs.launchpad.net/juju/+bug/1882127 ?
[12:57] <davigar15> Zookeeper one
[12:58] <jam> Chipaca, reading operator#223 I'm pretty sure it is just "below 2.7.0" where we fail
[12:58] <mup> Issue #223: Operator fails on Juju 2.7.0 and below <bug> <Created by chris-sanders> <https://github.com/canonical/operator/issues/223>
[12:58] <davigar15> When relating to Kafka
[13:29] <Chipaca> jam: but note in email '~2.7.4' is mentioned
[13:31] <jam> Chipaca, so if it is 2.7.4 then it is about bugs in reading application data in K8s charms, not about --app not being available as an arg
[13:31] <jam> but I have the feeling they saw something that kind-of sounded like what they were seeing and decided it was the same
[13:31] <jam> Chipaca, sorry, having a serious discussion in daily, will be to standup soon
[13:31] <Chipaca> jam: yay
[15:23] <Chipaca> need to step out, bbiab
[16:31] <Chipaca> facubatista: i'll be 5 minutes late
[16:31] <facubatista> Chipaca, no worries
[16:31] <facubatista> (I'm there, just step in)
[17:03] <Chipaca> OK
[17:03] <Chipaca> I am EOD, peeps
[17:03] <Chipaca> i didn't think i'd make it this far after barely sleeping, but hey :-)
[20:58]  * facubatista eods and tomorrow is off
[20:59] <facubatista> see you all on Thursday


[11:46] <Anita_> while installing juju 1.25, getting error The following packages have unmet dependencies:  juju-local : Depends: lxc (>= 1.0.0~alpha1-0ubuntu14) but it is not going to be installed               Depends: lxc-templates but it is not going to be installed E: Unable to correct problems, you have held broken packages.
[11:46] <Anita_> for sudo apt-get install juju-local
[11:47] <Anita_> how to resolve this?
[11:50] <Anita_> sudo apt-get install juju-local gives following error
[11:50] <Anita_> The following packages have unmet dependencies:  juju-local : Depends: lxc (>= 1.0.0~alpha1-0ubuntu14) but it is not going to be installed               Depends: lxc-templates but it is not going to be installed E: Unable to correct problems, you have held broken packages.
[11:50] <Anita_> any idea?
[12:09] <Anita_> Hi Matt
[13:13] <anita_> getting error while installing juju-local
[13:13] <anita_> on 1.25
[13:13] <anita_> The following packages have unmet dependencies:  juju-local : Depends: lxc (>= 1.0.0~alpha1-0ubuntu14) but it is not going to be installed               Depends: lxc-templates but it is not going to be installed E: Unable to correct problems, you have held broken packages.
[13:13] <anita_> any idea how to resolve this
[13:29] <anita_> Hi Matt
[13:30] <caribou> A question on actions (juju 1.25) : what is required in order for an action to return success (python script)
[13:30] <caribou> I'm returning sys.exit(0) but my action systematically fails, even if it returns 0 in debug-hooks
[14:23] <bdx> marcoceppi: can you clear out my aws charm dev account?
[14:27] <D4RKS1D3> Hi, I need to add new hard disk to an lxc
[14:28] <D4RKS1D3> but I received this line "lxc-start: utils.c: safe_mount: 1284 No such file or directory - Mount of '/media/disk3' onto '/usr/lib/x86_64-linux-gnu/lxc//sdc1' failed"
[14:28] <D4RKS1D3> Someone knows what happends?
[14:28] <D4RKS1D3> Thanks!
[14:41] <caribou> nevermind, I found the reason why it always failed : was relying on deprecated JUJU_HOME :-/
[14:59] <magicaltrout> fscking jet lag
[16:02] <catbus1> Hi, juju debug-log doesn't work with beta18, is it known? Any workaround?
[16:02] <catbus1> any other way to view the juju logs during the deployment
[16:03] <rick_h_> catbus1: you need to run it from the controller model. juju switch controller
[16:05] <catbus1> rick_h_: thanks!
[16:11] <magicaltrout> ahhh one of those days where you've had 4 hours sleep and decide to rewrite large chunks of your talk...
[16:12] <x58> magicaltrout: Best kind of days.
[16:13] <magicaltrout> we'll see at 1pm if i have a talk or not ;)
[16:13] <x58> lol
[16:25] <lpSummit> Greetings programs
[16:25] <magicaltrout> they called him chuuuuuuck... chuuuuck the truck.....
[16:58] <lpSummit> magicaltrout: i see what you did there
[16:59] <magicaltrout> have to do something to entertain myself after ~4 hours sleep
[16:59] <lpSummit> i know that feeling sir. I was up a bit too late myself
[17:00] <magicaltrout> i have the inverted problem. Wake up at 4:30 cause of the jet lag
[17:02] <lpSummit> I'm ready for a mid day coma
[17:02] <magicaltrout> hehe
[17:02] <lpSummit> s/coma/nap/
[17:17] <cholcombe> rick_h_, looks like beta 17 is broken also for me.  i'm trying to find beta 16
[17:19] <rick_h_> cholcombe: doh, ok.
[17:19] <rick_h_> cholcombe: just to verify, this is the local charm deploy issue?
[17:19] <rick_h_> cholcombe: beta15 I think is in the xenial archive might be a next middle ground to check easily
[17:22] <magicaltrout> anyone know what uses layer:apt so I can see what I've done wrong in my own?
[17:23] <cargill> I have this issue now, possibly with beta 18, seems like lxd issue, juju status and juju controllers --refresh error out with 'invalid controller tag "" returned from login: "" is not a valid tag'
[17:26] <cholcombe> rick_h_, correct
[17:26] <cholcombe> rick_h_, ok i'll try that
[17:26] <rick_h_> cargill: this is because it's a beta17 controller with the beta18 client
[17:26] <rick_h_> cargill: there was a breakage and the controller needs to be rebootstrapped with beta18
[17:26] <cargill> how do I upgrade the controller?
[17:26] <rick_h_> cargill: you cannot
[17:27] <cargill> oh, so remove and start over
[17:27] <rick_h_> cargill: yes please
[17:27] <rick_h_> cargill: soon with rc1 we'll support upgrades but the betas still do not
[17:41] <lpSummit> magicaltrout: - we've used the apt layer, one sec while i find you an example
[17:42] <magicaltrout> i found your example lpSummit
[17:42] <magicaltrout> thanks
[17:42] <magicaltrout> in beats
[17:43] <lpSummit> :D
[17:43]  * lpSummit sings the beats stack song
[17:43]  * lpSummit notes it has no lyrics
[17:44] <lpSummit> boodoom, bud duh boodoom boodooom buh duh buh duh boodoom boodoom
[17:45] <magicaltrout> lpSummit: http://<IP_ADDRESS>:5050/#/
[17:46] <lpSummit> oooo mesos
[17:46] <magicaltrout> yup, vanilla mesos on Xenial
[17:46] <magicaltrout> in a semi working charm
[17:58] <mliberte> Hi everyone. How do I add heat to openstack bundle?
[18:25] <lpSummit> magicaltrout: question for you
[18:25] <lpSummit> magicaltrout: have you considered making any level of SDN abstracted in the mesos charms?
[18:41] <magicaltrout> hey lpSummit sorry was on a call
[18:41] <magicaltrout> absolutely I have
[18:47] <lpSummit> magicaltrout: great, the juniper guys are interested in talking with you if you have a moment
[18:48] <lpSummit> magicaltrout: we're in the container track room
[18:52] <magicaltrout> lpSummit: cool, i'm prepping for my 1pm demo, but we can talk after that
[18:52] <lpSummit> sounds good to me
[19:10] <catbus1> Hi, I don't see 2.0 version of this page https://jujucharms.com/docs/1.25/authors-charm-upgrades, is it the same for 2.0?
[19:11] <magicaltrout> yeah i don't think its changed catbus1
[19:12] <catbus1> ok
[19:13] <magicaltrout> lpSummit: you still there?
[20:42] <gQuigs> is there a juju 1.25 daily PPA?
[21:57] <coreycb> pragsmike, https://jujucharms.com/u/james-page/openstack-on-lxd
[21:57] <pragsmike> thanks
[22:42] <cargill> what would make juju debug-hooks <unit> <hook> not actually do what https://jujucharms.com/docs/stable/developer-debugging#the-'debug-log'-command promises? It just lands me in a clean tmux session, no JUJU_HOOK_NAME or anything set
[22:45] <jose> cargill: that's intended, and you will get a new tmux window as soon as the hook fires up
[22:46] <cargill> jose: oh, thanks, now that I reread the docs I can see that being described clearly
[22:47] <jose> :) np!
[22:48] <kk> https://gist.github.com/anonymous/ed1d1878b8de26ce43e8b73a59c0a602
[22:48] <perrito666> kk: tx
[23:42] <cargill> is there an example how to use charmhelpers.core.services.helpers.TemplateCallback?


[00:19] <tgm4883_laptop> Is there anyone that is willing to either help in writing documentation for the Ubuntu derivative Mythbuntu or help in mentoring the people that are currently writing it?  If this is the wrong place to ask this, just let me know
[15:31] <Rugby471> hi guys
[15:31] <Rugby471> i am developing some documentation
[15:31] <Rugby471> but i just have one question
[15:31] <Rugby471> about the kde help viewer
[15:32] <Rugby471> is the syntax to view a hlep file similiar to yelp
[15:32] <Rugby471> ie. what is equivalent in kde to:
[15:32] <Rugby471> yelp file.xml
[15:36] <Rugby471> ?