[00:12] <lool> wee, got an IP
[00:30] <ricmm> \o/
[00:31] <lool> ricmm: sent you a status email; some open questions for you
[00:32] <ricmm> lool: yea, just skimmed through it
[00:32] <lool> ricmm: if we're maintaining this, I might elect the ugly+complex but quick to deliver hacks on top of Ubuntu packages -- to avoid maintaining NM and deps twice
[00:33] <ricmm> I'll reply, keep an eye out
[00:33] <ricmm> lool: go sleep
[00:33] <lool> haha my inbox looks like a jungle now
[00:33] <lool> yeah, time for sleep
[01:30] <h00sier> I'm trying to add a user in snappy. I've already added lines to /var/lib/extrausers/{password,group,gshadow}, I don't know how to make the line for shadow. It's encrypted I guess, any help?
[06:23] <pitti> mvo: guten Morgen!
[06:24] <pitti> mvo: I reviewed the snappy classic dimension spec
[06:26] <mvo> pitti: great, thanks
[06:28] <mvo> pitti: I also have a systemd question again :) so I have this snappy-workaround.service and it needs to be completed before ppp-dns.service runs. in snappy-workarounds.service I used before=ppp-dns.service but thats not strong enough, I also added "wantedby=network-pre.target" to ensure its run earlier and indeed its run earlier but ppp-dns still starts in parallel, whats the best way to express that the unit has to have exited? (or the best way
[06:28] <mvo> to do what I want, namely that the workaround is applied before ppp-dns starts)?
[06:29] <pitti> mvo: before= does just that
[06:29] <pitti> mvo: but it only says that your unit must get *started* before the other one, not *ended*
[06:29] <pitti> mvo: maybe  you are missing a Type=oneshot?
[06:30] <pitti> mvo: for those, the unit only counts as "done" when all Exec= commands exited, not when they started
[06:31] <mvo> pitti: this is what it looks like http://paste.ubuntu.com/12551829/
[06:32] <mvo> pitti: is it the "remainafterexit"?
[06:32] <pitti> mvo: oh, when does ppp-dns.service get started?
[06:32] <mvo> iirc we added it to easily see the logs
[06:32] <pitti> mvo: my guess is that ppp-dns.service gets started in a target much ealier than multi-user.target
[06:33] <mvo> pitti: pps-dns is a old-school init script
[06:33] <pitti> mvo: and thus the snappy-workaround.service isn't even taken into account
[06:33] <pitti> mvo: in rcS?
[06:33] <pitti> oh, I have it
[06:33] <pitti> mvo: ah, rcS
[06:33] <mvo> pitti: indeed it is
[06:34] <pitti> mvo: ack, clear then; hang on
[06:34] <mvo> pitti: thanks!
[06:34] <mvo> pitti: would be nice if systemd would tell me in some way that the before= releation can not be satisfied or something :)
[06:35] <pitti> mvo: old-school init.d> err, is it? I have a /lib/systemd/system/pppd-dns.service which is in multi-user, but that might be new in wily
[06:35] <pitti> mvo: and indeed it being in rcS makes things unnecessarily hard :/
[06:35] <mvo> pitti: uh, I'm sorry, I have that in vivid too on my snappy image
[06:36] <mvo> pitti: but its also in rcS.d it seems, what happens in this case? will the native one always "win"?
[06:36] <pitti> mvo: http://paste.ubuntu.com/12551864/
[06:36] <pitti> mvo: yes, native always wins
[06:36] <pitti> ok, then I don't know -- journal SVP?
[06:37] <pitti> mvo: the above paste would be to start much earlier, in case pppd-dns already ran in rcS (aka sysinit.target)
[06:37] <mvo> pitti: sure, one sec and I can give you the journal and the systemd-analiyze output
[06:37] <pitti> mvo: systemd actually should tell you that, in that case you get a dependency cycle in journal and one service in the cycle doesn't start
[06:38] <pitti> mvo: so, given /lib/systemd/system/pppd-dns.service your wantedby=multi-user.target shoudl be fine
[06:38] <pitti> and the before=
[06:38] <mvo> pitti: http://paste.ubuntu.com/12551875/ is the journal
[06:39] <pitti> mvo: haha!
[06:40] <pitti> mvo: ppp-dns.service
[06:40] <pitti> mvo: spot the typo :)
[06:40]  * mvo drops dead
[06:40] <pitti> mvo: /me tosses mvo another 'd'
[06:40] <mvo> *cough* thanks, I guess I owe you one (or two)
[06:40] <pitti> and try to say "pppd-dns" very fast ten times
[06:40]  * pitti hugs mvo
[06:41] <pitti> no warning about this, as having an After=/Before= to nonexisting units is a common and legitimate use case
[06:41] <pitti> but we should maybe configure --enable-typo-detection
[06:42] <pitti> mvo: now that this is done, another thing: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/ is not actually a "classic" ubuntu tarball, it's snappy
[06:42] <pitti> mvo: fortunately it still has an intact dpkg database, but we need to remove the /usr/local/bin/apt* stuff at lesat
[06:42] <mvo> hmm
[06:42] <pitti> mvo: I was just wondering what these ubuntu core tarballs actually want to be -- a deb based minimal ubuntu, or classic
[06:42] <pitti> err, "or snappy"
[06:44] <mvo> pitti: indeed, I think we should find a real core tarball, the snappy one removes most of /usr/share/doc for example and iirc the man-pages so its not a great fit for the classic env
[06:45] <mvo> pitti: we could simply create another artifact with livecd-rootfs
[06:45] <mvo> pitti: I wonder what lxd is doing to build the ubuntu image? maybe we can use that?
[06:46] <pitti> mvo: I left a note and a TODO in the spec
[06:46] <pitti> mvo: lxc has pre-built images available for download, indeed
[06:46] <pitti> mvo: we don't have "lxc" installed to actually call the templates, but we could of coruse just hardcode the URL
[06:47] <pitti> mvo: but we would then depend on something.linuxcontainers.org, not on *.ubuntu.com infrastructure
[06:47] <pitti> http://images.linuxcontainers.org/images/ubuntu/vivid/amd64/default/
[06:48] <mvo> pitti: yeah, lets discuss in budapest, but my plan-b would be to just create another artifact on cdimage.u.c via livecd-rootfs
[06:48] <pitti> right
[06:48] <pitti> mvo: I'll adjust my prototype to use a hardcoded URL to the lxc tarballs for now
[06:50] <mvo> pitti: thanks!
[06:51] <mvo> elopio: I'm a idiot, the snappy-workaround issue is found and I uploaded a fix, thanks to pitti, will create a new image now
[06:51]  * yashi_ tring to send a fix to lp...
[06:52] <yashi_> https://code.launchpad.net/~yashi/snapcraft/snapcraft
[06:52] <mvo> pitti: thanks for the spec update, I just looked over it, you mostly replied to the comments, right? and the open question? the rest looks ok?
[06:52] <pitti> mvo: "making frustrating typos" != "idiot", happesn to everyone!
[06:52] <pitti> mvo: I also added some new comments, yes
[06:52] <pitti> mvo: open q?
[06:52] <mvo> pitti: indeed, thanks :) I feel a bit silly for not spotting it earlier
[06:53] <mvo> pitti: the open question about were to get the tarball from
[06:53] <pitti> mvo: ah, right
[06:53] <mvo> great, I think that spec is in good shape then
[06:53] <mvo> yashi_: nice!
[06:54] <mvo> yashi_: if you click on "prose for merging" and then propose to merge it into "lp:snapcraft" it will appear on the radar of the snapcraft developers automatically :)
[06:54] <pitti> mvo: meh, need to think about what to do with /etc/resolv.conf
[06:56] <mvo> pitti: oh, indeed :/
[06:58] <yashi_> mvo: done.  Thanks :)
[07:03] <fgimenez> good morning
[07:09] <mvo> hey fgimenez, good morning
[07:09] <fgimenez> hi mvo i'm going to check elopio's concerns. is all set in alpha, right?
[07:10] <mvo> fgimenez: yes, I found the bug why the workarounds ording was not quite correct and fixed it
[07:11] <mvo> fgimenez: the image is building right now in alpha
[07:11] <fgimenez> mvo, great! :) the image is ready for testing?
[07:11] <fgimenez> mvo, ah ok :)
[07:18] <pitti> mvo: btw, what does your workaround do?
[07:21] <dholbach> good morning
[07:22] <pitti> mvo: I mean, it's usually more elegant to create a /lib/systemd/system/pppd-dns.service.d/snappy.conf with an extra ExecStartPre=, or changing/deleting the ExecStart= command, or something
[07:22] <pitti> mvo: then you can restart/stop pppd-dns.service and things still work correctly; you don't need to be aware of re-running the workarounds.service as well, etc.
[07:23] <pitti> hey dholbach, wie gehts?
[07:25] <dholbach> hey pitti - sehr gut - und dir?
[07:25] <pitti> dholbach: prima, danke
[07:30] <mvo> pitti: aha, nice. I will keep that in mind
[07:31] <dholbach> pitti, thanks for looking at the ffe
[07:32] <pitti> dholbach: no worries, that's a trivial one
[07:32] <dholbach> yeah, I could imagine there's going to be another upload before release,  but it should be smaller to be reviewed
[07:32] <dholbach> mvo, asac: upload snapcraft 0.2 to wily
[07:33] <mvo> fgimenez: new image available, I do a quick test now
[07:33] <fgimenez> mvo, thanks on it
[07:35] <mvo> fgimenez: systemd analyize tells me the order is now correct
[07:39] <fgimenez> mvo, trying the update from 178 now. it's still not available on alpha, right?
[07:40] <mvo> fgimenez: not in alpha yet, I can do that now
[07:42] <mvo> fgimenez: there should be a new amd64 alpha now based on r185
[07:44] <fgimenez> mvo, thanks a lot, i'll try it now 178 -> 185 worked fine for ppp \o/ http://paste.ubuntu.com/12552242/
[07:45] <mvo> fgimenez: yay!
[07:45] <fictionedge> Hi everyone
[07:45] <fictionedge> Can anyone tell me what's the best way to submit a few suggestions to the developers team?
[07:47] <dholbach> fictionedge, if it's about snappy, the mailing list should be a good start: http://lists.ubuntu.com/mailman/listinfo/snappy-devel
[07:49] <asac> dholbach: uploaded or you want me to upload :)?
[07:54] <fictionedge> @dholbach it's about the general installation process for future releases
[07:54] <nothal> fictionedge: No such command!
[07:57] <fgimenez> mvo, 11 -> 13 worked fine too http://paste.ubuntu.com/12552292/ :)
[07:59] <fgimenez> mvo, i'll run the tests against 13 now
[07:59] <fictionedge> just joined the list thank you dholbach
[07:59] <mvo> cool
[08:04] <pitti> mvo: http://people.canonical.com/~pitti/tmp/setup-classic.sh updated for a few glitches
[08:04] <pitti> mvo: resolv.conf now works OOTB, I un-snappify the core tarball, and I added a policy-rc.d
[08:04] <pitti> mvo: so apt-get update/install postfix in the chroot now DTRT
[08:10] <mvo> pitti: nice! postfix DTRT means the service is not started but it does get started on the next reboot, right? (just to be sure I'm on the same page)
[08:10] <pitti> mvo: correct
[08:10] <pitti> mvo: or when you systemctl restart classic-container
[08:11] <pitti> mvo: I need to make this a bit more precise -- if you apt-get install in "machinectl login classic", it actually should start
[08:11] <pitti> mvo: but I don't think we want to advertise logging into the container too much
[08:12] <mvo> pitti: yeah, I would love to have a mechanism via policy-rc.d that would notify the host that it needs to do something like"machinectl login classic" to start it
[08:12] <mvo> pitti: but only if that can be made robust :)
[08:12] <mvo> pitti: but maybe its not feasible, not sure
[08:13] <pitti> mvo: that would be in invoke-rc.d
[08:13] <pitti> mvo: yeah, we could do something like that too
[08:13] <pitti> maybe it's even possible to do in policy-rc.d, that would be much nicer
[08:13] <mvo> probably not for now, I guess we should wait for the budapest discussion
[08:13] <pitti> right, before we waste too much time on the details of this
[08:14] <mvo> but it would be nice from a user experience point of view, but then we have the problem what systemctl inside the snappy classic env should show etc
[08:14] <mvo> so there are more questions :)
[08:24] <dholbach> asac, already uploaded
[08:27] <dholbach> pitti, snapcraft is in binNEW because of a new -examples package - could you take a look?
[08:32] <davidcalle> dholbach, I'm having issues with a snap, could you have a look?
[08:32] <dholbach> davidcalle, what's the issue?
[08:34] <davidcalle> dholbach, my "glue" bash script is calling bzr, and bzr has issues running (eg. can't find bzrlib), it's probably a path issue, I'm wondering if I'm doing things wrong in my snapcraft.yaml
[08:34] <davidcalle> dholbach, http://bazaar.launchpad.net/~davidc3/+junk/snapcraft-doc-snap/view/head:/snapcraft.yaml
[08:35] <davidcalle> dholbach, (the snap is pretty straightforward, go webserver + bzr imports snapcraft doc + script to convert it to html)
[08:37] <dholbach> taking a look in a bit
[08:37] <davidcalle> dholbach, thanks :)
[08:37] <pitti> dholbach: hm, shouldn't that be in /usr/share/doc/snapcraft/examples/ ?
[08:40] <dholbach> pitti, hmmm.... http://pastebin.ubuntu.com/12552504/
[08:40] <pitti> dholbach: right, I just checked the deb, hence my question
[08:41] <dholbach> ah ok, sorry
[08:41] <dholbach> my mistake
[08:41] <dholbach> I'll prepare 0.2.1
[08:41] <pitti> err, /usr/share/doc/snapcraft-examples/examples I meant
[08:42] <dholbach> I'm happy with whatever
[08:42] <dholbach> if it needs to be /usr/share/doc/snapcraft-examples/examples that works for me
[08:44] <pitti> dholbach: well, "needs to be" -> that's the standard path to put examples into
[08:44] <pitti> not a biggie, but that's what /usr/share/doc/ is for
[08:44] <dholbach> ok
[08:44] <pitti> dh_installexamples should DTRT
[08:44] <pitti> dholbach: danke!
[08:44] <dholbach> yep
[08:53] <dholbach> davidcalle, I'll get to it later, if that's all right - I have a few things to figure out first
[08:54] <dholbach> or ask m-vo or s-ergiusens
[08:54] <davidcalle> dholbach, no rush! Nothing urgent :)
[08:54] <dholbach> ok, good
[08:57] <JamesTait> Good morning all; happy Friday, and happy Comic Book Day! 😃
[09:49] <dholbach> mvo, pitti: https://code.launchpad.net/~dholbach/snapcraft/0.2.1/+merge/272362
[09:50] <dholbach> brb
[10:06] <mvo> timchen119: could you please try https://people.canonical.com/~mvo/tmp/ubuntu-device-flash-128mb-boot-plus-fw-dir
[10:08] <timchen119> mvo, ok
[10:55]  * Chipaca suddenly finds himself down a performance rabbithole and tries to get out
[10:56]  * ogra_ sends a fox to speed this up 
[10:56] <clobrano> LOL
[10:59] <Chipaca> on the one hand, I just cut a test from 0m7.208s to 0m0.072s
[10:59] <Chipaca> so I basically just made snappy.VersionCompare 100× faster
[11:00] <Chipaca> on the *other* hand, not that many people have 10k versions of a package installed, that it would make a difference
[11:02] <Chipaca> ah, no, that's with 1k versions, not 10k. Much more real-world a test case.
[11:13] <mvo> Chipaca: woah!
[11:13] <mvo> Chipaca: \o/
[11:15] <Chipaca> mvo: and I can knock down the 100k testcase from 22 seconds to 15 seconds if i change snappy.chOrder to be a table
[11:15] <Chipaca> mvo: i think i might draw the line above this one though :)
[11:15] <mvo> Chipaca: I look forward to that branch
[11:17] <Chipaca> mvo: it's fun, but i'm glad i got to a table quickly (because tables are ugly) :)
[11:17] <Chipaca> otherwise i might've been trapped all day
[11:19]  * mvo nods
[11:20] <Chipaca> otoh if we were using go:generate the table is totally generate'able :)
[11:25] <Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/sort-perf/+merge/272372
[11:31] <Chipaca> clobrano: whenever you check whether a file exists and if it does not you then create it you are creating a race
[11:31] <Chipaca> clobrano: somebody can create the file (with content) between you checking and you creating
[11:32] <clobrano> Chipaca: ooh, right!
[11:32] <clobrano> Chipaca: thank you :)
[11:32] <Chipaca> clobrano: e.g. the write it out in file.tmp, then move it to file just after you checked and before you created
[11:32] <Chipaca> clobrano: boom, you just stomped on their file
[11:32] <clobrano> Chipaca: sure
[11:33] <Chipaca> clobrano: note that with snappy right now that's not as possible because it has a global lock, but the snappy rest api does not
[11:35] <clobrano> Chipaca: I understand, but (apart from snappy) is always something to think about :)
[11:35] <Chipaca> yep
[11:38] <Chipaca> clobrano: then there's the symlink considerations, and using openat instead of open, but i think we can leave those for now
[11:38] <Chipaca> probably need to comb the code to grab those at some point though
[11:39] <Chipaca> ah
[11:39] <Chipaca> clobrano: could you add O_NOFOLLOW to the O_CREAT etc ?
[11:39] <Chipaca> clobrano: that's syscall.O_NOFOLLOW
[11:39] <Chipaca> not portable :-/
[11:59] <clobrano> Chipaca: sure, but O_NOFOLLOW is for?
[12:00] <Chipaca> clobrano: i'll answer that in a bit
[12:00] <Chipaca> clobrano: meanwhile, let me ask
[12:00] <Chipaca> clobrano: how far away are you from me?
[12:00]  * Chipaca hides
[12:00] <Chipaca> clobrano: :)
[12:00] <Chipaca> clobrano: i thought of a better way of doing this thing
[12:01] <clobrano> Chipaca: far away? Do you mean geographically? :D
[12:01] <Chipaca> yeah, in case you wanted to throw something at me
[12:01] <Chipaca> clobrano: it's that i just realised there's no reason to create the file at all at that point
[12:02] <Chipaca> clobrano: unless i'm missing something?
[12:02] <clobrano> Chipaca: I'd like, but I'm in Italy
[12:02] <Chipaca> clobrano: just, try to read it, if you fail, move on
[12:02] <Chipaca> clobrano: so you start with “rules, err := ioutil.ReadFile(udevRulesFile)”
[12:03] <Chipaca> clobrano: and check err != nil && !os.IsNotExist(err)
[12:03] <Chipaca> clobrano: you'll have the content of the file, or an empty slice, in rules
[12:03] <Chipaca> clobrano: and that's all you need
[12:04] <clobrano> Chipaca: first, sorry I didn't get at all the joke before ;D. You're talking about addUdevRule right? What if it's the first rule? The file does not exist at all
[12:05] <Chipaca> yes, talking about addUdevRule
[12:05] <Chipaca> clobrano: if it's the first rule, ie if the file does not exist
[12:05] <Chipaca> clobrano: you're creating an empty file
[12:05] <Chipaca> clobrano: and then reading that with ioutil.ReadFile
[12:05] <Chipaca> clobrano: right?
[12:06] <clobrano> Chipaca: uhmm, I think you're right
[12:06] <Chipaca> clobrano: so ioutil.ReadFile will return an empty slice of bytes, because the file is empty
[12:06] <Chipaca> clobrano: but ioutil.ReadFile will return a nil slice when it can't open the file
[12:07] <Chipaca> clobrano: and appending to a nil slice, and appending to an empty slice, results in the same thing
[12:07] <clobrano> Chipaca: ReadFile will return no errors?
[12:07] <Chipaca> it will
[12:07] <Chipaca> it will return a non-nil error
[12:07] <Chipaca> but os.IsNotExist(err) will return true
[12:08] <Chipaca> hence, you'd do: rules, err := ioutil.ReadFile(...)
[12:08] <Chipaca> if err != nil && !os.IsNotExist(err) { return err }
[12:09] <Chipaca> capisci?
[12:09]  * Chipaca couldn't resist
[12:09] <clobrano> Chipaca: ahahahaha
[12:10] <clobrano> Chipaca: sorry, just a sec
[12:12] <clobrano> Chipaca: sure I think it's fine. AtomicWrite will create the file if it doesn't exist, right?
[12:12] <Chipaca> yes
[12:12] <clobrano> then ok, I couldn't see any drawback
[12:23] <clobrano> Chipaca: done it, test it, ready to push it (I just added a comment to the code, since that could be not immediate to understand)
[12:23] <clobrano> :)
[12:23] <Chipaca> L(
[12:23] <Chipaca> :) i mean
[12:23] <Chipaca> L( is an off-by-one :)
[12:24] <Chipaca> clobrano: did you follow up the .precommit thing?
[12:25] <clobrano> Chipaca: yes, I did. I still have to check something with Bazaar-explorer, since it fails to find golint, but bzr by command-line it's fine
[12:26] <Chipaca> clobrano: you probably need to manipulate PATH from your bzr plugin so it finds golint
[12:26] <Chipaca> clobrano: or install golint into ~/bin :)
[12:26] <Chipaca> (assuming ~/bin is in your PATH, which it is by default if it exists)
[12:26] <clobrano> Chipaca: yes, it should be something like that
[12:27] <clobrano> I set both GOPATH and GOBIN, but explorer seems to ignore it
[12:27] <clobrano> and added GOBIN to PATH
[12:27] <Chipaca> clobrano: where did you do those additions, and where do you start explorer from?
[12:28] <clobrano> Chipaca: that's the point. The definitions are in my bashrc, and I couldn't find the name of the explorer bin to run it from shell
[12:29] <Chipaca> clobrano: dpkg -L bzr-explorer | grep /bin/
[12:29] <clobrano> Chipaca: nada
[12:30] <Chipaca> clobrano: dpkg -L bzr-explorer | grep .desktop | xargs grep Exec=
[12:30] <clobrano> but I found the .desktop with your command! Thanks
[12:30] <Chipaca> heh :) yep
[12:30] <clobrano> yep ;)
[12:32] <clobrano> Chipaca: I think I could open another bug :p. Bzr does not list "explorer" as basic command in its help :D
[12:32]  * Chipaca gives up and installs bzr-explorer
[12:32] <Chipaca> clobrano: sure it does, it's right there
[12:33] <Chipaca> ah, as *basic* commands
[12:33] <Chipaca> well, it's hardly basic :)
[12:33] <clobrano> Chipaca: well, for a basic user, a GUI is better than a shell ;)
[12:34] <clobrano> Chipaca: but ok, the command its in the full list
[12:37] <clobrano> Chipaca: done. Let me know if it's fine now
[12:38] <Chipaca> augh!
[12:39] <clobrano> :D
[12:39] <Chipaca> clobrano: commented inline
[13:45] <ogra_> Chipaca, hmpf ... webdm doesnt start on my last Pi2 image
[13:45] <Chipaca> ogra_: i can't even get it to build here
[13:45] <ogra_> webdm ?
[13:45] <Chipaca> yes
[13:45] <Chipaca> i am not building raspberry pies
[13:45] <Chipaca> although i do have raspberry jam
[13:45] <ogra_> http://paste.ubuntu.com/12554435/
[13:46] <ogra_> thats during forst boot
[13:46] <ogra_> *first
[13:46] <Chipaca> ogra_: and did you?
[13:46] <ogra_> webdm_snappyd_0.9.service - Snappy WebDM
[13:46] <ogra_>    Loaded: loaded (/etc/systemd/system/webdm_snappyd_0.9.service; enabled; vendor preset: enabled)
[13:46] <ogra_>    Active: failed (Result: start-limit) since Fri 2015-09-25 13:43:14 UTC; 1min 13s ago
[13:46] <ogra_>   Process: 1072 ExecStart=/usr/bin/ubuntu-core-launcher webdm webdm_snappyd_0.9 /apps/webdm/0.9/snappyd (code=exited, status=1/FAILURE)
[13:46] <ogra_>  Main PID: 1072 (code=exited, status=1/FAILURE)
[13:46] <ogra_> not actually informative
[13:47] <ogra_> syslog has:
[13:47] <ogra_> Sep 25 13:44:57 localhost ubuntu-core-launcher[1230]: Snappy: 2015/09/25 13:44:57 handlers.go:52: Initializing HTTP handlers...
[13:47] <ogra_> Sep 25 13:44:57 localhost ubuntu-core-launcher[1230]: Snappy: 2015/09/25 13:44:57 handlers.go:59: decoding problem
[13:47] <ogra_> thats the most recent 15.04 image btw
[13:48] <ogra_> (which i thought we plan to release today :/ )
[13:48]  * ogra_ wonders why nobody did hit that during testing 
[13:49] <ogra_> fgimenez, do you have webdm running on your armhf and amd64 tests for the last 15.04 edge or alpha image ?
[13:50] <fgimenez> ogra_ nope, i'll try to reproduce
[13:50] <ogra_> seems my amd64 auto-upgraded to 186 and there i see webdm run
[13:51] <ogra_> i dont have a BBB around to check if it is perhaps arm specific
[13:57] <fgimenez> ogra_ then flash alpha 11 for bbb, install webdm, update should be enough?
[13:57] <ogra_> fgimenez, yes
[13:57] <ogra_> well, i flashed edge
[13:58] <fgimenez> ogra_ ok, let me try
[13:58] <ogra_> and no upgrade ... i just used u-d-f on the last edge image
[14:08] <longsleep> ogra_: mhm webdm works fine in my 15.04/stable
[14:08]  * longsleep did not test edge yet
[14:08] <ogra_> weird
[14:09] <ogra_> i did build that image with --device raspi2_armhf ... i wonder if that forces an amd64 webdm to be installed or some such
[14:09] <longsleep> well id installed webdm later on the device
[14:09] <longsleep> -d
[14:09] <ogra_> ah, dd is done, lets see if it behaves differently without that option
[14:10] <ogra_> screen -r
[14:10] <ogra_> oops
[14:10] <ogra_> EFOCUS :P
[14:12] <ogra_> hmm, not caused by the --device option, still failing here
[14:13]  * ogra_ removes and reinstalls webdm
[14:14] <ogra_> nope, same issue
[14:38] <longsleep> ogra_: let me try mine
[14:38] <ogra_> trying with alpha 12 here now ...
[14:38]  * ogra_ waits for dd
[14:42] <longsleep> ogra_: webdm runs fine on my odroid
[14:42] <ogra_> sigh
[14:42] <longsleep> ubuntu-core   2015-09-17 5
[14:42] <longsleep> webdm         2015-09-24 0.9
[14:42] <ogra_> ah, but thats stable
[14:43] <longsleep> yeah
[14:43] <ogra_> havent gotten to that yet :)
[14:43] <ogra_> sigh, so alpha doesnt work either
[14:43] <Chipaca> clobrano: you need to set a commit message on the merge request
[14:44]  * longsleep builds an edge image now
[14:44]  * ogra_ builds stable 
[14:49] <longsleep> damn .. no space left on device  - foo!
[14:50] <ogra_> bah
[14:50] <longsleep> too many kernel build trees :/
[14:50] <ogra_> heh
[14:51] <ogra_> sigh
[14:51] <ogra_> stable doesnt uncompress the kernel for me :/
[14:51]  * ogra_ re-tries
[14:53] <jbdatko> Anyone know if the snappy image for BBB needs the SD card to run or can it run completely from the eMMC? The instructions talk about replacing the bootloader on the emmc...
[14:57] <clobrano> Chipaca: what should the content be?
[14:57] <Chipaca> clobrano: a short description of the changes in the branch?
[14:57] <Chipaca> oh!
[14:57] <Chipaca> and one more thing
[14:58] <Chipaca> clobrano: make a nochange commit with --fixes lp:1497299
[14:58] <Chipaca> clobrano: e.g. bzr ci -m 'fixes lp:1497299' --fixes lp:1497299 --unchanged
[14:58] <Chipaca> clobrano: and push that also
[14:59] <clobrano> Chipaca: ook
[15:04] <zyga> morphis: hey, I'm back now
[15:04] <zyga> morphis: does the security template work for you?
[15:04] <zyga> morphis: I merged the documentation changes and I'm about to rebuild and see if the snap works with the template for me
[15:05] <morphis> zyga: I just applied the last changes I got from jdstrand
[15:05] <morphis> can report in some minutes
[15:05] <zyga> morphis: ok, thanks
[15:06] <morphis> zyga: but pushed the change so you can test too
[15:06]  * zyga builds
[15:06] <zyga> make clean; make
[15:06] <zyga> I love that
[15:07] <longsleep> ogra_: webdm works fine here with edge
[15:07] <longsleep> ubuntu-core 2015-09-25 170     ubuntu
[15:07] <longsleep> (installed via ssh though, not together with u-d-f)
[15:09] <clobrano> Chipaca: done
[15:32] <Chipaca> https://code.launchpad.net/~chipaca/snappy/dddddirs/+merge/272430 for great justice^Wduhr duhr
[15:34] <ogra_> mvo, so any idea about the oem snap ?
[15:35]  * ogra_ quickly gets some food
[15:37] <Chipaca> ogra_: so, you get ErrDecode from oem.Oem() in two cases: one is a bad package.yaml
[15:37] <Chipaca> ogra_: the other is an unreadable package.yaml
[15:37] <Chipaca> 	yamlPath := filepath.Join("/oem", oem[0].Name(), oem[0].Version(), "meta", "package.yaml")
[15:38] <Chipaca> which is rather circuitous, but there you go
[15:38] <Chipaca> ogra_: so
[15:38] <ogra_> http://paste.ubuntu.com/12555387/
[15:38] <Chipaca> ogra_:  if the version in the yaml does not match the directory
[15:38] <Chipaca> ogra_: would be one failure mode
[15:38] <ogra_> how would thw dir match anything ?
[15:38] <Chipaca> ogra_: that is
[15:39] <ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls /oem/pi2/
[15:39] <ogra_> IBbBKVKXNDAQ  current
[15:39] <Chipaca> eep
[15:39] <Chipaca> why is it sideloaded?
[15:39] <ogra_> right, cant match :)
[15:39] <ogra_> because it is built using u-d-f --developer-mode
[15:39] <ogra_> with the --oem option
[15:40] <Chipaca> so
[15:40] <ogra_> thats how we port to new devices
[15:40] <Chipaca> something is out of sync
[15:40] <Chipaca> umm
[15:40] <Chipaca> ogra_: update snappy in webdm
[15:41] <Chipaca> ogra_: because oem[0].Version() should do the right thing here, and it isn't :)
[15:41] <ogra_> ??
[15:41] <ogra_> snappy in webdm ?
[15:41] <Chipaca> ogra_: you didn't rebuild webdm?
[15:42] <ogra_> why would i
[15:42] <Chipaca> ogra_: because it embeds snappy
[15:42] <Chipaca> ogra_: new snappy => new webdm
[15:42] <Chipaca> more or less
[15:42] <ogra_> i only use u-d-f like i did the last few releases for rpi
[15:42] <Chipaca> u-d-f *also* embeds snappy :)
[15:42] <ogra_> and bumped the version in the pi2 snap
[15:43] <Chipaca> but that's not here nor there
[15:43] <ogra_> and i'm using the lastes u-d-f i think
[15:43] <Chipaca> so
[15:43] <Chipaca> ogra_: webdm needs to be built agains the same version of snappy as the system snappy
[15:43] <Chipaca> ogra_: otherwise breakage happens
[15:43] <Chipaca> (you effectively have two different snappy implementations on the system)
[15:43] <ogra_> right, so we will see breakage on other systems too then
[15:43] <Chipaca> yes
[15:43] <Chipaca> or rather
[15:43] <Chipaca> no
[15:44] <ogra_> i mean, i'm not using anything special
[15:44] <Chipaca> because it doesn't understand the versioning thing
[15:44] <Chipaca> :)
[15:44] <Chipaca> so, webdm needs attention
[15:44] <ogra_> webdm hanst been rebuilt in months
[15:44] <Chipaca> yeh
[15:44] <Chipaca> this is not good :)
[15:44] <ogra_> right
[15:45] <Chipaca> ogra_: do you have vivid?
[15:45] <ogra_> trusty
[15:45]  * ogra_ isnt sure, probably vivid on the lappie
[15:45] <Chipaca> ricmm: where did you try to build webdm (and failed)?
[15:45] <Chipaca> i think it needs a vivid, but i might be wrong
[15:46] <Chipaca> and it might be broken beyond that :-/
[15:46] <Chipaca> ogra_: one of the reasons the rest api is important is to decouple webdm
[15:46] <ogra_> ah
[15:47]  * ogra_ is surprised to be the first one to actually hit an issue, these pieces must be massivel out of sync
[15:47] <ogra_> and that since a while
[15:49] <ogra_> i uess i could work around by pushing the 0.16 pi2 untested to the store then .... then it wouldnt be sideloaded
[15:49] <Chipaca> ogra_: i thought you'd tested it with everything except webdm?
[15:49] <ogra_> there is just something inside me screaming "dont upload untested, idiot !!!"
[15:50] <ogra_> well, yeah
[15:50] <Chipaca> ogra_: the broken bit here is webdm
[15:52] <Chipaca> clobrano: congratulations, btw :)
[16:07] <longsleep> ogra_: my version in /oem is just 0.3 - why is yours a hash version?
[16:08] <longsleep> ls /oem/odroidc/
[16:08] <longsleep> 0.3  current
[16:08] <longsleep> i am using vivid to build the images with ubuntu-device-flash 0.20snappy7-0ubuntu1.2
[16:09] <fgimenez> nice weekend everyone o/
[16:10] <ogra_> longsleep, all sideloaded snaps get a hash version nowadays
[16:10] <ogra_> so you are lucky because the snappy on the machine you called u-d-f on is old
[16:11] <longsleep> ogra_: um, i think it is the latest from the ppa
[16:15] <longsleep> aha - i am using snappy-dev-beta ppa - snappy-dev has newer :/
[16:18] <longsleep> ogra_: switched to snappy-dev/tools and now i have 0.31 - thanks for the hint!
[16:19] <ogra_> our PPAs are a mess :/
[16:34] <longsleep> ogra_: so the theory is that if i now create a new image with the newer u-d-f then webdm stops working for me as well?
[16:36] <ogra_> right
[16:36] <ogra_> well, if you use the --oem switch pointing to a local snap
[16:36] <ogra_> only sideloaded snaps get that hash version
[16:48] <longsleep> ogra_: yes thats what i am doing with the odroid oem snap, verifying now
[16:49] <ogra_> \o/
[16:49]  * ogra_ humps Chipaca's leg 
[16:49] <ogra_> WOOF !
[16:49] <ogra_> i has workin webdm !!
[16:49]  * Chipaca has a headache
[16:50] <ogra_> so pushin the snap to the store and using that makes everything work fine
[16:50] <ogra_> wow ... what a waste of my afternoon :/
[16:51] <longsleep> ogra_: so webdm currently breaks for any sideloaded snaps ?
[16:51] <ogra_> oem snaps, yes
[16:51] <longsleep> ah only oem ok
[16:51] <longsleep> good that i used an old u-d-f to create my image then :)
[16:51] <ogra_> :)
[16:52] <Chipaca> no, it'll break for any snap
[16:52] <Chipaca> sideloaded
[16:52] <ogra_> oh
[16:52] <ogra_> ok
[16:52] <Chipaca> the services will be confused
[16:52] <ogra_> well, it will still start at least if the oem one isnt sideloaded
[16:52] <Chipaca> right, so i should qualify that
[16:52] <Chipaca> snappy and webdm will have different opinions of where things should go
[16:52] <longsleep> ah, well that image i built with new u-d-f does not even boot :/ seems like i just got some work todo :(
[16:53] <Chipaca> and will break if you mix and match
[16:53] <ogra_> yeah
[16:53] <Chipaca> but if you use webdm, it'll mostly work
[16:53] <Chipaca> except for the bugs due to not having random versions for sideloaded apps
[16:53] <Chipaca> also none of the fixes in snappy-the-binary will be used by webdm
[16:54] <Chipaca> some might say this is bad :)
[20:20]  * ogra_ curses
[20:20] <ogra_> this rpi image starts getting on my nerves
[20:28] <ricmm> ogra_: whats the matter with it
[20:29] <ogra_> well, i tried to build an image from the s-i srver bits and ended up with a generic kernel ...
[20:29] <ogra_> it funnily booted, i only noticed the wrong kernel after 30min testing :(
[20:29] <ricmm> lol
[20:29] <ricmm> should just merge into that generic then
[20:30] <ricmm> if it actually booted...
[20:31] <ogra_> we tried that but rickspencer3 would be really unhappy ... we needed to add a plethora of patches to make all the bits work he wants
[20:31] <rickspencer3> ruroh
[20:31] <rickspencer3> no pwm? no i2c, no spi?
[20:31]  * ogra_ doesnt really get how he ended up with the worng device tarball now :(
[20:32] <rickspencer3> what would you even do with that?
[20:32] <ogra_> run owncloud or kodi :)
[20:33] <rickspencer3> heh
[20:33] <ogra_> ogra@nusakan:~$ grep raspi2 /srv/system-image.ubuntu.com/etc/config|tail -1
[20:33] <ogra_> file_device,raspi2_armhf = http;http://people.canonical.com/~platform/snappy/raspberrypi2/device-pi2.tar.xz;name=device,monitor=http://people.canonical.com/~platform/snappy/raspberrypi2/builddid
[20:33]  * ogra_ slaps forehead ...
[20:33] <rickspencer3> poor ogra
[20:33] <ogra_> indeed the s-i server points to an unversioned tarball
[20:34] <ogra_> (i uploaded device-pi2-0.16.tar.xz)