| sergiusens | elopio, I've updated bug 1497108 | 01:27 |
|---|---|---|
| ubottu | bug 1497108 in Snapcraft "Long paths are not handled correctly when deleting partition mappings" [Medium,In progress] https://launchpad.net/bugs/1497108 | 01:27 |
| sergiusens | plars, btw ^ | 01:27 |
| sergiusens | plars, if you don't want u-d-f to bail with loops all around, use relative paths for output image :-) | 01:27 |
| plars | sergiusens: ah, ok. I thought I had tried relative paths on an older version of udf and it didn't like that | 01:30 |
| sergiusens | elopio, btw https://code.launchpad.net/~sergiusens/snapcraft/1498157/+merge/271872 | 01:55 |
| tedg | sergiusens: Uhg, we need a way for plugins to tie into that processing... | 02:00 |
| tedg | sergiusens: Or perhaps just append values instead of replacing the whole file. | 02:00 |
| tedg | It's getting complex | 02:00 |
| sergiusens | tedg, it is | 02:08 |
| sergiusens | tedg, which part specifically? env? | 02:08 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| elopio | sergiusens: could you look at this one tomorrow please? https://code.launchpad.net/~dholbach/snapcraft/snapcraft-examples/+merge/271838 | 03:51 |
| sergiusens | elopio, since it is a merge into federico's branch I just skipped it | 03:52 |
| sergiusens | elopio, and thought of reviewing once he merged it all in one shot | 03:52 |
| sergiusens | elopio, I approved in any case ;-) | 03:53 |
| elopio | sergiusens: thanks. It was you who requested it, so I wanted to make sure it made you happy. | 03:57 |
| sergiusens | elopio, yeah, it is good :-) | 03:58 |
| sergiusens | elopio, goodnight, just been through my last item for the day :-) | 03:58 |
| elopio | sergiusens: good night. | 03:59 |
| === bigcat_ is now known as bigcat[fooding] | ||
| === chihchun_afk is now known as chihchun | ||
| === bigcat[fooding] is now known as bigcat | ||
| dholbach | good morning | 06:35 |
| fgimenez | good morning | 07:02 |
| clobrano | morning o/ | 07:03 |
| dholbach | hola fgimenez, hola dpm | 07:03 |
| dholbach | morning clobrano | 07:03 |
| guest42315 | mornin' | 07:03 |
| dholbach | hey guest42315 | 07:03 |
| guest42315 | \o | 07:04 |
| dholbach | wow, it looks like snappy land is just waking up! :) | 07:04 |
| fgimenez | hey dholbach and all :) | 07:04 |
| * guest42315 sudo snappy install coffee | 07:05 | |
| dholbach | :-) | 07:05 |
| dholbach | mvo, can you take a look at https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801 and let me know if it's the right way to deal with the problem? | 07:05 |
| dholbach | fgimenez, I wasn't quite sure if I was doing the right thing with my branch (https://code.launchpad.net/~dholbach/snapcraft/snapcraft-examples/+merge/271838) yesterday | 07:06 |
| dholbach | fgimenez, from a packaging POV it's correct, but I don't know if the test machinery will be able to cope with it like that | 07:06 |
| mvo | dholbach: sure, I have a look now | 07:06 |
| dholbach | <3 | 07:06 |
| dpm | hey dholbach | 07:07 |
| dholbach | mvo, https://bugs.launchpad.net/snapcraft/+bug/1497582 and https://bugs.launchpad.net/snapcraft/+bug/1495525 are examples you can use to test it | 07:07 |
| ubottu | Launchpad bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress] | 07:07 |
| ubottu | Launchpad bug 1497582 in Snapcraft "duplicate for #1495525 pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress] | 07:07 |
| fgimenez | dholbach, totally, thanks a lot :) i need only to adjust the path to the examples directory and the dependencies to work with it, let me have a look | 07:08 |
| dholbach | <3 | 07:09 |
| dholbach | awesome | 07:09 |
| mvo | dholbach: hm, I think lp:~snappy-dev/snapcraft/more-apt solves this actually already :/ | 07:12 |
| dholbach | mvo, ok - that works for me | 07:12 |
| dholbach | thanks mvo | 07:16 |
| dholbach | fgimenez, do you still remember where the libssl-dev depends came from in https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798? | 07:20 |
| dholbach | mvo, would it be easy to let apt download all the necessary packages in one go instead of one by one? | 07:21 |
| fgimenez | dholbach, i was getting errors when building the examples without it, give me a second and i'll pastebin it | 07:22 |
| dholbach | mvo, if you try the qmldemo example it feels veeery slow - also the remaining-download-estimate will never give you anything remotely accurate :) | 07:22 |
| dholbach | fgimenez, maybe a missing build-packages in the case of downloader-with-wiki-parts? | 07:24 |
| dholbach | mvo, I'm happy to file a bug for it though, so we can resolve it sometime later | 07:24 |
| mvo | dholbach: right, we should probably download htem all togehter, I can prepare a branch, essentially we need to adjust dir::cache::archives to the download dir and run cache.fetch_archives() | 07:29 |
| zyga | good morning :) | 07:29 |
| dholbach | awesome - I'll file a bug and let you know | 07:30 |
| dholbach | cześć zyga | 07:30 |
| * zyga wants to try to re-iterate on hostapd example snap/part so that it can be merged | 07:30 | |
| dholbach | mvo, can you reject https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801? | 07:30 |
| dholbach | and milestone https://bugs.launchpad.net/snapcraft/+bug/1497582 to 0.2? | 07:31 |
| ubottu | Launchpad bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress] | 07:31 |
| zyga | dholbach: how do I say "hi" in German? I only remember tschus but AFAIR that's more like "bye" | 07:31 |
| dholbach | zyga, 'hallo' :) | 07:32 |
| zyga | dholbach: thanks :) | 07:32 |
| dholbach | yes, "tschüss" is "bye" :) | 07:32 |
| dholbach | mvo, https://bugs.launchpad.net/snapcraft/+bug/1498333 | 07:35 |
| ubottu | Launchpad bug 1498333 in Snapcraft "Let apt download all packages in one go" [Undecided,New] | 07:35 |
| mvo | dholbach: ta, shall I give it a go or do you want to do it? | 07:38 |
| mvo | dholbach: happy to do it, just want to avoid duplication of effort | 07:38 |
| dholbach | wow | 07:42 |
| davidcalle | Hmm | 07:43 |
| dholbach | I just asked on #ubuntu-irc | 07:43 |
| dholbach | <Flannel> Looks like irccloud was k-lined. | 07:44 |
| mvo | dholbach: I think I have a branch | 07:44 |
| dholbach | <3 | 07:44 |
| dholbach | mvo, can you milestone bug 1497582 to 0.2? | 07:45 |
| ubottu | bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,Fix committed] https://launchpad.net/bugs/1497582 | 07:45 |
| mvo | dholbach: sure | 07:45 |
| dholbach | maybe at some stage I should join ~snappy-dev :) | 07:45 |
| mvo | dholbach: do we have a 0.2 series yet? | 07:45 |
| dholbach | no series, just a milestone | 07:45 |
| mvo | dholbach: done | 07:46 |
| fgimenez | dholbach, probably, this is the output http://paste.ubuntu.com/12519630/, i've pushed the changes needed to work with snappy-examples and removed the libssl-dev dependency, you should be able to see the error now | 07:54 |
| dholbach | fgimenez, cool - I'll take a look in a sec | 07:56 |
| dholbach | mvo_, will check it out in a sec | 08:00 |
| mvo_ | dholbach: no rush, all good | 08:01 |
| mvo_ | dholbach: the qml example is 350mb big | 08:01 |
| mvo_ | that explains why I had to wait a bit to get it :) | 08:01 |
| dholbach | yep, I noticed :) | 08:01 |
| dholbach | squid-deb-proxy to the rescue | 08:01 |
| dholbach | it's the perfect example :) | 08:01 |
| mvo_ | hahaa | 08:01 |
| mvo_ | indeed | 08:02 |
| dholbach | mvo_, | 08:03 |
| dholbach | Get:823 http://de.archive.ubuntu.com/ubuntu/ vivid/main usb-modeswitch amd64 2.2.0+repack0-2ubuntu2 [51.2 kB] | 08:03 |
| dholbach | Fetched 253 MB in 6s (25.9 MB/s) | 08:03 |
| dholbach | :) | 08:03 |
| dholbach | looks like it works ;-) | 08:03 |
| dholbach | a thing of beauty | 08:03 |
| dholbach | mvo_, just two small typos in https://code.launchpad.net/~mvo/snapcraft/lp1498333-even-more-apt/+merge/271918 | 08:05 |
| mvo_ | dholbach: thanks for the review and yeah, python-apt rocks | 08:09 |
| mvo_ | (and apt as well!) | 08:09 |
| dholbach | fgimenez, commented on https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798 | 08:11 |
| davidcalle | asac, jdstrand, mvo, lool, sergiusens, fyi, I've started porting the manual to markdown. I'd like to propose a string freeze on thursday european evening for a v0.1 of development basics, debugging basics (and, if ready, app porting). In order to start publishing what we have before eow and solve our most prominent docs pain points asap. | 08:19 |
| dholbach | https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921 | 08:21 |
| fgimenez | dholbach, thanks! already pushed | 08:34 |
| dholbach | great | 08:34 |
| asac | davidcalle: the application manual? think its a bit too early to do that porting | 08:45 |
| asac | folks are still doing content etc. | 08:45 |
| davidcalle | asac, I'm doing the general outline and already written sections (even if they change during the week), it gives me content to test on the automagic importer to dev.ubuntu.com | 08:48 |
| davidcalle | asac, do you think we can have a freeze on some main sections this week? (at least yours and mvo's) | 08:49 |
| JamesTait | Good morning all; happy Tuesday, and happy Business Women’s Day! 😃 | 08:59 |
| asac | davidcalle: maybe... have to check with team. My section I have to rewrite as the content is mostly the future. have to redo it with what is real right now | 09:14 |
| asac | davidcalle: why do you want to freeze? | 09:14 |
| asac | or is it about moving it top markdown and abandoning this doc at some point? | 09:15 |
| davidcalle | asac, that too but it can happen later, mostly to be able to publish something in the rough timeline we have defined | 09:16 |
| davidcalle | asac, I'm asking about these two sections, because they are the most important for app devs ( and snapcraft of course, but for now the trunk demos + currently published docs are fine) | 09:19 |
| asac | davidcalle: so our tiemlnie is to get this doc done early octobver ... like 1st or 2nd | 09:38 |
| asac | outline we need to finish today | 09:38 |
| asac | first two sections is me and mvo... i think we can do it by EOW ... and given that we are busy next week I guess thats what we have to do | 09:38 |
| davidcalle | asac, sounds good to me, are you fine with publishing sections as soon as they are ready? We'll be able to change and update them of course, but I think it makes sense to do it early, especially if we have snappy events and clinics coming up | 09:40 |
| asac | true | 09:41 |
| asac | when are we doing first clinic? | 09:41 |
| davidcalle | dholbach, ^? | 09:41 |
| asac | mvo_: can we get development basic and debugging section done by EOW? | 09:41 |
| asac | you and me? :) | 09:41 |
| asac | debuggin section includes sergiusens work | 09:41 |
| dholbach | asac, on the clinic: no idea - I was sort of waiting on news regarding the competition | 09:41 |
| dholbach | asac, but I'm working on bullet points for a presentation already | 09:42 |
| asac | ok i will poke mectors | 09:43 |
| asac | have a call with him in a bit | 09:43 |
| dholbach | <3 | 09:44 |
| biezpal | asac, hey, bug filed - https://bugs.launchpad.net/snappy/+bug/1498396 | 09:45 |
| ubottu | Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,New] | 09:45 |
| ogra_ | mvo_, shouldnt snapcraft delete stage/usr/share/man ? we dont really need it | 09:49 |
| * ogra_ notes that he has a ton of manpages there | 09:49 | |
| asac | ogra_: you can use | 09:50 |
| asac | snap: | 09:50 |
| asac | - -usr/share/man | 09:51 |
| asac | or something | 09:51 |
| asac | to strip stuff fromn snap that you dont want | 09:51 |
| ogra_ | well, i thionk it should be a default | 09:51 |
| asac | why? | 09:51 |
| asac | why wiouldnt someone just be able to ship manpages | 09:51 |
| ogra_ | at least for the debian packages | 09:51 |
| ogra_ | why would you ship them ? | 09:51 |
| ogra_ | nothing can use them | 09:51 |
| asac | because someone might want to read the manpage for some cli you packaged | 09:51 |
| asac | like for bip | 09:51 |
| asac | makes sense | 09:51 |
| ogra_ | you would ahve to ship man yourself | 09:51 |
| asac | sure ... still doewsnt mean that all want to strip it | 09:52 |
| asac | i can also read manpages with vi | 09:52 |
| asac | :) | 09:52 |
| asac | anyway, talk to sergiusens and then have him align with niemeyer on this i guess | 09:52 |
| ogra_ | what use would he have to read that manpage ... the ircproxy package is fully cobfigured via snappy config | 09:52 |
| ogra_ | ok | 09:52 |
| asac | ogra_: but the fact that its so nicely done with sanppy config is because your package is nicely done | 09:53 |
| asac | doesnt mean that others want to do something like that | 09:53 |
| ogra_ | indeed | 09:53 |
| asac | btw, we mifght watn to talk about how to ship docs at all | 09:53 |
| asac | e.g. how would you now doc your nice ircproxy package | 09:53 |
| ogra_ | yeah | 09:54 |
| asac | the config options you providem, how to use it, etc | 09:54 |
| ogra_ | well, theoretically i would describe it in the store description ... but only webdm will show that (hopefully one day :P ) | 09:54 |
| davmor2 | asac: sanppy sounds like an awesome name for snappy san :) | 09:54 |
| mvo_ | ogra_: yeah | 09:54 |
| ogra_ | do we plan a snappy equivalent to "apt-cache show <package>" ? | 09:55 |
| ogra_ | that would show the store description ... | 09:55 |
| mvo_ | asac: develpment basics? is that also on my list? I was working on "Debugging basics" so far and its mostly done except strace/gdb because there is no package yet | 09:55 |
| mvo_ | ogra_: yes, its not speced yet, but snappy info <pkgname> is probably that | 09:56 |
| ogra_ | ah | 09:56 |
| ogra_ | asac, so that would be my docs then ... not sure we want some additional mechanism | 09:56 |
| ogra_ | probably the store could just have a field that specifically describes configuration | 09:57 |
| ogra_ | snappy info -c <packagename> could then spit our "snappy config" output with the possible values shown for each option | 09:58 |
| ogra_ | (or something like that) | 09:58 |
| ogra_ | hah, hello ogra2, hello snappy autopilot :) | 10:15 |
| ogra_ | (looks like my ircproxy machine just restarted itself) | 10:16 |
| === ogra2 is now known as ogra-snappy-test | ||
| sergiusens | asac, you haven't sent out the docs? | 10:18 |
| sergiusens | asac, I found it hard to describe snapcraft.yaml without describing parts, so was thinking of inverting the order | 10:19 |
| pitti | mvo_, ogra_: hm, neither wget nor curl installed; what's the recommended way on snappy to download something? | 10:23 |
| pitti | call python3? | 10:23 |
| ogra_ | pitti, download on your host and scp | 10:23 |
| pitti | ogra_: well, this is for a "setup-classic" script I'm supposed to write | 10:24 |
| ogra_ | i have an unconfined wget snap too (amd64 only atm though) | 10:24 |
| ogra_ | pitti, ah, well, ship wget inside your sanp then | 10:24 |
| ogra_ | *snap | 10:25 |
| ogra_ | assuming your "classic" thing comes as snap | 10:25 |
| pitti | mvo_: ^ will we have a snap for this "classic" setup, or will that need to go into snappy core then? | 10:25 |
| * ogra_ thinks core is way way to bloated already | 10:25 | |
| ogra_ | we are slowly moving out of the embedded space | 10:26 |
| pitti | would calling python3 -c ... with urllib.urlretrieve() be okay? | 10:26 |
| pitti | or will python3 go away too/ | 10:26 |
| pitti | ? | 10:26 |
| ogra_ | once we drop clooud-init and system-image we might drop it | 10:26 |
| ogra_ | not sure about the first, the latter is actively worked on atm | 10:27 |
| pitti | okay; this is just a PoC for now, we might even retrieve the "classic" environment through some other way, or bind this to comfy or whatever | 10:27 |
| pitti | so I guess I don't worry about this too much for now | 10:27 |
| * ogra_ would expect system-image to be gone with the next stable release | 10:27 | |
| ogra_ | pitti, i'm surprised systemd doesnt have a wget equivalent yet :) | 10:29 |
| mvo_ | pitti: there is apt-helper download | 10:29 |
| mvo_ | ogra_: apt has a wget ;) | 10:29 |
| ogra_ | hah | 10:29 |
| pitti | mvo_: I thought apt would be gone? | 10:30 |
| mvo_ | pitti: yeah :( | 10:30 |
| mvo_ | pitti: its still there in 15.04 | 10:30 |
| sergiusens | pitti, I would expect that that would eventually manage setting this up (classic mode) | 10:30 |
| pitti | mvo_: "403 Forbidden file type or location" | 10:30 |
| pitti | sergiusens: what is "that"? | 10:31 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | he means "this" | 10:31 |
| ogra_ | :P | 10:31 |
| pitti | doesn't help :) | 10:32 |
| sergiusens | pitti, err; I just woke up :-P first s/that that/snappy/ | 10:32 |
| pitti | sergiusens: ah, ok :) so this shell script PoC might be rewritten in go or so | 10:32 |
| ogra_ | sergiusens, so snappy woould have a builtin wget ? | 10:32 |
| pitti | I suppose Go has some url retrieve API | 10:32 |
| sergiusens | ogra_, no; setting up classic mode would be eventually driven by snappy | 10:33 |
| mvo_ | yeah, go can fetch stuff from http | 10:33 |
| sergiusens | I'm just guessing | 10:33 |
| ogra_ | right | 10:33 |
| ogra_ | as long as we dont have to bloat core more and more ... | 10:33 |
| pitti | right | 10:35 |
| pitti | I'm using python3 in the PoC for now that shoudl survive at least next week (and then we might do this completely differently anyway0 | 10:35 |
| ogra_ | yeah | 10:36 |
| mvo_ | pitti: you have a mail with slides :) | 10:39 |
| zyga | sergiusens: this can land as-is https://code.launchpad.net/~zyga/snapcraft/fix-1484596/+merge/271863 | 10:44 |
| zyga | sergiusens: the plainbox bits are merge in trunk now | 10:44 |
| zyga | sergiusens: and the will be a part of plainbox 0.23 | 10:44 |
| zyga | sergiusens: which is now in QA | 10:44 |
| davmor2 | mvo_: wow sliding mails what will you guys come up with next ;) | 10:44 |
| dholbach | sergiusens, I'm not sure I understand your comment in https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921 | 11:40 |
| dholbach | sergiusens, AFAICS you need libgudev-1.0-dev installed as part of build-packages (for the build to pass locally) AND to bundle libudev-1.0-0 for the snap to work on a snappy system | 11:41 |
| * mvo_ hugs dholbach for fixing bug #1498347 | 11:59 | |
| ubottu | bug 1498347 in Snapcraft "godd example: error while loading shared libraries: libgudev-1.0.so.0: cannot open shared object file: No such file or directory" [High,In progress] https://launchpad.net/bugs/1498347 | 11:59 |
| * dholbach hugs mvo_ back :) | 12:03 | |
| dholbach | mvo_, is the MP the right way to fix it? it looks like sergiusens had reservations | 12:06 |
| mvo_ | dholbach: not sure if he has reservations in general | 12:07 |
| dholbach | mvo_, no, I meant the comment in the MP | 12:07 |
| mvo_ | dholbach: aha, let me read | 12:08 |
| sergiusens | dholbach, mvo_ since this is an example, I would use a stage-package without filesets (to remove the headers at least) so the snap doesn't have header file all over it | 12:22 |
| sergiusens | mvo_, dholbach the other option is to stage-package the library itself and not -dev; but it makes it a nicer example if the stage-package is the dev one | 12:23 |
| dholbach | sergiusens, I think that's what I'm doing | 12:23 |
| dholbach | stage-packages: [libgudev-1.0-0] | 12:23 |
| sergiusens | dholbach, yeah, but you should remove the build-package entry below :-) | 12:23 |
| dholbach | build-packages: | 12:23 |
| dholbach | 10 - libgudev-1.0-dev | 12:23 |
| dholbach | why? | 12:23 |
| sergiusens | dholbach, and use a fileset | 12:24 |
| dholbach | it is required to build the package | 12:24 |
| dholbach | hum | 12:24 |
| dholbach | I never used filesets before | 12:24 |
| sergiusens | dholbach, it shouldn't be needed; stage-package entries are also used for building | 12:24 |
| dholbach | I see | 12:24 |
| dholbach | mvo_, ^ do you have a strong opinion? | 12:24 |
| sergiusens | tedg, hey, mind looking at https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751 https://code.launchpad.net/~ted/snapcraft/multi-python-version/+merge/271716 ? | 12:36 |
| jdstrand | davidcalle: what manual are you referring to, the the enterprise manual? | 12:45 |
| jdstrand | davidcalle: the parts I've written are only a first draft and I have two more sections. I already know there are edits I need to make to the sections I've written | 12:46 |
| jdstrand | if we work off a single bzr tree for markdown, things are going to get complicated with merges | 12:46 |
| davidcalle | jdstrand, no worries about that, bzr tree will come only after the first published version. DIfferent files for each section as well. | 12:48 |
| davidcalle | jdstrand, we can even split it more if needed to ease having simultaneous editors working on it at the same time. Having a bzr trunk makes the publishing process very streamlined. Trunk would be pulled every 2h and turned into fancy cms pages. | 12:51 |
| jdstrand | davidcalle: I'm only talking about this week | 12:52 |
| jdstrand | davidcalle: what is the verdict? am I supposed to be editing markdown now? | 12:52 |
| jdstrand | where is it? | 12:52 |
| davidcalle | jdstrand, nope :) | 12:52 |
| jdstrand | ok, cause assuming I don't get pulled aside (like the last three days), I plan to work on it after a couple of meetings | 12:53 |
| davidcalle | jdstrand, keep going with the gdoc, no rush for this week on your end, by eow I'll publish what's ready: hopefully development basics and debugging basics. What's finished will be converted to markdown as well but I'm happy with this first iteration being in gdocs, I'll handle the publication related details. | 12:55 |
| davidcalle | That's a big enough task, let's avoid editors being annoyed by formatting (yet :D) | 12:57 |
| sergiusens | dholbach, https://code.launchpad.net/~sergiusens/snapcraft/doc-services/+merge/271959 | 12:59 |
| dholbach | ok... mvo is looking at right now as well | 12:59 |
| tedg | sergiusens: Sure, BTW, I'm not sure the fixup code should go in the Ubuntu plugin. It seems like it'd be needed no matter how you installed libxml or libxslt. | 13:07 |
| sergiusens | tedg, ok, makes sense | 13:16 |
| sergiusens | mvo_, thanks for that apt improvement! | 13:36 |
| jdstrand | davidcalle: ack, thanks. I hope to have all my parts written by eow at least in 1st/2nd draft quality | 13:37 |
| jdstrand | so that seems to work well with your timeline (and moving into bzr) | 13:37 |
| davidcalle | jdstrand, indeed, wfm :) | 13:37 |
| pedronis | hey, is it expected/known that building a amd64 image with udf core 15.04 --channel edge and --developer-mode sshing doesn't work? it works with stable though | 13:42 |
| mvo_ | sergiusens: your welcome! | 13:45 |
| dholbach | sergiusens, so I'm going to merge mvo's work which does what I guess you were expecting (correct me if I'm wrong): https://code.launchpad.net/~mvo/snapcraft/1498347/+merge/271961 | 13:48 |
| mvo_ | sergiusens, dholbach: so the godd example got a little bit more complicated due to the new libgudev dependency. now I could try to hack around that in godd by doing static linking with cgo etc, but it made me wonder if maybe we should do something smarter in snapcraft | 13:48 |
| dholbach | sergiusens, I personally don't feel that snapcraft is easy to understand in this specific example or easy to handle | 13:48 |
| dholbach | mvo_, I'm sure we are going to have more cases like that | 13:49 |
| mvo_ | sergiusens, dholbach: i.e. we could auto-copy all libs from the ldd output of each binary listed in binaries by default maybe? | 13:49 |
| dholbach | add a build-dep, bundle a certain set of packages or set of files from other packages | 13:49 |
| dholbach | mvo_, that would probably eliminate most of the hassle :) | 13:49 |
| sergiusens | mvo_, stage-packages should get copied over by default | 13:50 |
| dholbach | https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921 is up for review again | 13:51 |
| sergiusens | mvo_, dholbach this looks nice! | 13:51 |
| dholbach | sergiusens, I'm not sure I agree - I find it a bit hard to explain it to future snappers :) | 13:52 |
| dholbach | or hard to explain the "here's how you debug which files are missing in your snap" iteration cycle :) | 13:52 |
| dholbach | it'd be nice if it was easier at some golden, glorious and beautiful point in the future | 13:53 |
| mvo_ | maybe doing it magically is not the right way, but I would love to have something simple like snap: [$shlibs] or something, a magic var that snapcraft fills that contain the shlib depends? | 13:55 |
| mvo_ | dholbach, sergiusens: -^ | 13:55 |
| mvo_ | we could even steal https://code.launchpad.net/~mvo/click/click-check-libs/+merge/235960 for this | 13:55 |
| sergiusens | mvo_, as long as we look only in the parts | 13:57 |
| sergiusens | mvo_, but not the host | 13:57 |
| sergiusens | mvo_, but by default everything will be included | 13:57 |
| sergiusens | dholbach, ^ | 13:57 |
| sergiusens | the fileset is just to make the final snap look nicer | 13:58 |
| sergiusens | not mandatory | 13:58 |
| sergiusens | I'm only saying we should use it as it is an example | 13:58 |
| dholbach | ok, I think that makes sense | 13:58 |
| Chipaca | mvo_: https://code.launchpad.net/~chipaca/snappy/husk/+merge/271965 if you're itching to review something juicy | 13:58 |
| dholbach | we could have two examples, that's right | 13:58 |
| sergiusens | but just using 'stage-packages' would of included the libs | 13:58 |
| sergiusens | dholbach, the walkthrough goes over this fwiw | 13:58 |
| mvo_ | Chipaca: I love to review your stuff, you know that | 13:58 |
| Chipaca | mvo_: ⁑D | 13:59 |
| sergiusens | mvo_, btw, I don't mind building in default fileset filters as you mentioned 'bins', 'shlibs', 'headers' or 'development' | 14:09 |
| mvo_ | sergiusens: I think that would be good, we need to prune the shlibs of course to filter out the ones we already have in core, but that should be straightforward | 14:10 |
| sergiusens | mvo_, well, if grabbed from 'stage' it shouldn't matter too much | 14:11 |
| sergiusens | then again, weird things can happen | 14:11 |
| sergiusens | tedg, btw, do you want me to change env management to use dicts and have each plugin get a copy of the env, be able to add to it and return it when called? | 14:15 |
| sergiusens | tedg, it could clean up the case where things get stepped over | 14:15 |
| tedg | sergiusens: Are we still gonna do shell expansions? | 14:17 |
| tedg | I think we need to keep those. | 14:17 |
| sergiusens | tedg, I don't see why not | 14:20 |
| elopio | ogra_: have you been able to use parted with --pretend-input-tty ? | 14:38 |
| ogra_ | elopio, i havent looked into resizing this week | 14:40 |
| ogra_ | on my TODO though | 14:40 |
| ogra_ | but RPi is more important | 14:40 |
| elopio | ogra_: please let me know when you have time for this. For some reason, we are now getting a warning when shrinking the partition on the bbb. | 14:44 |
| ogra_ | on the BBB ? | 14:44 |
| ogra_ | that doesnt use the GPT codepath at all | 14:45 |
| elopio | no hurry, but I can't use that option. | 14:45 |
| elopio | ogra_: yes, on mbr. | 14:45 |
| ogra_ | well, MBR is not using any magic | 14:45 |
| ogra_ | just the resizepart command | 14:45 |
| ogra_ | whats the error you get ? | 14:45 |
| elopio | ogra_: no, but if I can send a "yes" to parted on mbr, this could work. | 14:45 |
| ogra_ | we dont want it interactive at all | 14:46 |
| ogra_ | elopio, got some log with the actual error ? | 14:47 |
| elopio | ogra_: sorry. one second. | 14:48 |
| ogra_ | mvo_, so even an image rebuild doesnt make cloud-init show up anymore on the 15.04 image ... do you know where it is seeded for 15.04 ? | 14:51 |
| ogra_ | (it is definitely not hardcoded in livecd-rootfs) | 14:52 |
| mvo_ | ogra_: its part of the "Task:" header | 14:54 |
| mvo_ | ogra_: which is not available in ppas, sowe need to fake it via "X-Tasks: ubuntu-core" | 14:54 |
| ogra_ | mvo_, well, or force install it from livecd-rootfs | 14:55 |
| ogra_ | live-build/auto/config for 15.04 is a mess already, adding one more line wouldnt hurt i guess | 14:55 |
| mvo_ | ogra_: sure, either way is fine | 14:56 |
| ogra_ | let me do that then | 14:56 |
| === kickinz1|afk is now known as kickinz1 | ||
| elopio | ogra_: Warning: Shrinking a partition can cause data loss, are you sure you want to continue? | 15:01 |
| ogra_ | shrinking ?!?! | 15:01 |
| ogra_ | there is surely something wrong then | 15:01 |
| elopio | ogra_: that's what I do to test your resize. That's on my script. | 15:02 |
| longsleep | ogra_: Your resize code works perfectly for my testing so far by the way. So nice work! | 15:03 |
| ogra_ | longsleep, thanks, still a hack that will need fixing :) | 15:03 |
| longsleep | ogra_: i am very happy with it :) | 15:03 |
| ogra_ | i'm actually pondering to just switch to gdisk | 15:03 |
| ogra_ | there is a minor chance you trash your disk if you have powerloss while resizing | 15:04 |
| ogra_ | i'd like ot get rid of that possibility ... or at least reduce it | 15:04 |
| tasdomas | my snappy on RPi2 seems to be stuck "Starting kernel..." after update - where do I look to investigate the cause? | 15:21 |
| ogra_ | tasdomas, oops, i was supposed to mail about that ... you will need to manually copy the kernel and initrd from /boot/uboot/a to /boot/uboot/b for the upgrade to work | 15:25 |
| ogra_ | tasdomas, if you reboot the system should boot back into the a partition ... then run snappy update again and then do the file copy before reboot | 15:26 |
| tasdomas | ogra_, ack - thanks | 15:26 |
| ogra_ | thats sadly caused by the non-official state of the RPi image ... (about to change for the next release) | 15:27 |
| elopio | plars: could you provide us with an agent for prodstack snappy instances? | 15:54 |
| plars | elopio: I thought you were working on that? We specifically said that we would not provide cloud instances since that's something that didn't require special hardware | 15:58 |
| elopio | plars: I know. We have it solved for canonistack and now we need prodstack. I'm asking if we could add that as a new requirement for the lab. | 15:58 |
| plars | elopio: how is it different from canonistack? Why would it be a lab thing? | 15:59 |
| plars | we don't have any special connection to prodstack that you don't | 15:59 |
| elopio | plars: I just don't want to maintain it. As you are maintaining all the other testbeds, I want you to maintain it. | 16:00 |
| elopio | but if you can't or don't want to, I can do it. That's what I'm asking. | 16:00 |
| plars | elopio: I can talk to cwayne about it, but I suspect it's going to fall into the same territory as canonistack | 16:00 |
| plars | elopio: on the plus side, I'm very close to being able to provide you with rpi2 | 16:01 |
| elopio | plars: you see, you'll soon be out of things to do ;) | 16:01 |
| plars | elopio: fighting with power problems at the moment - from what I understand, the pi's in the lab may only have a 200ma adapter on them, which makes me wonder how they are running at all | 16:01 |
| elopio | plars: should I send an email to cwayne? | 16:01 |
| plars | elopio: haha, I only wish I were out of things to do! | 16:01 |
| plars | elopio: there's a LOT more coming | 16:01 |
| plars | elopio: sure, just cc me on it please | 16:02 |
| elopio | plars: it's a joke, of course. | 16:02 |
| elopio | plars: sending email... Thanks. | 16:02 |
| T-mon | Hello everyone! | 16:11 |
| T-mon | I'm updating my snappy package and tested it with the new release | 16:11 |
| T-mon | somehow, the SNAPP_APP_PATH env dissappeard | 16:12 |
| T-mon | is there a new way to get the path? | 16:12 |
| elopio | ogra_: how would you get the start of a partition, by number? | 16:19 |
| elopio | like get_start /dev/mmcblk0 4 | 16:20 |
| ogra_ | utlemming, the latest 15.04 edge has your cloud-init now | 16:25 |
| ogra_ | (sorry, that took quite a bit to have it land there) | 16:25 |
| utlemming | ogra_: thank you kindly :) | 16:25 |
| ogra_ | elopio, there is code that uses sysfs, somewhere in that sysfs node you should be able to get the start and end bvalues | 16:26 |
| utlemming | ogra_: what is the version number? 176? | 16:26 |
| ogra_ | utlemming, 177 | 16:27 |
| utlemming | ogra_: ack, thanks | 16:27 |
| === ogra2 is now known as ogra-snappy-test | ||
| ogra_ | sergiusens, you havent synced snapcraft -proposed into -daily yet, right ? | 16:29 |
| ogra_ | (LP uses -daily so my ircproxy test build failed ... ) | 16:30 |
| tedg | T-mon: I think you want SNAP_APP_PATH, only one P | 16:33 |
| elopio | ogra_: in bytes :D | 16:34 |
| T-mon | oh, did that change? 2 months ago it worked | 16:34 |
| ogra_ | elopio, an opportuntity to compute some math in shell for you \o/ | 16:35 |
| ogra_ | tedg, i thought we still support the old way | 16:35 |
| sergiusens | ogra_, oh yeah, daily is dead to me :-) | 16:35 |
| elopio | ugh, last time I spent like an hour trying to take a percentage out of the end. | 16:36 |
| sergiusens | ogra_, but I haven't told cjwatson yet | 16:36 |
| ogra_ | sergiusens, well, cjwatson uses it for pulling from | 16:36 |
| ogra_ | better tell him :) | 16:36 |
| elopio | behold, /me does some shell math. | 16:36 |
| sergiusens | ogra_, if I do, we should update the docs and prepare some for of announcement | 16:36 |
| T-mon | tedg: thx, I'll try it right now :) | 16:36 |
| ogra_ | elopio, var=$((1+1)) | 16:37 |
| ogra_ | elopio, echo $var | 16:37 |
| ogra_ | 2 | 16:37 |
| elopio | ogra_: I know that now. That double parentheses was tricky :) | 16:37 |
| * ogra_ is afk for 1h | 16:37 | |
| sergiusens | ogra_, there, told him :-) | 16:49 |
| sergiusens | elopio, mind looking at https://code.launchpad.net/~sergiusens/snapcraft/doc-services/+merge/271959 ? | 16:50 |
| elopio | sergiusens: for you, anything. | 16:50 |
| T-mon | tedg: SNAP_APP_DATA does not exist...the are no SNAP_* ord SNAPP_* env variables | 16:50 |
| sergiusens | elopio, lol, it is a one liner in docs :-) | 16:51 |
| elopio | sergiusens: two lines. | 16:54 |
| sergiusens | elopio, sorry, my mistake | 16:58 |
| tedg | T-mon: You can check the wrapper script for your binary by looking at /apps/bin | 18:49 |
| elopio | sergiusens: could you review if our go is decent here? https://github.com/elopio/go-subunit/blob/master/subunit.go | 18:54 |
| sergiusens | elopio, sure thing | 18:59 |
| sergiusens | elopio, btw, any eta on landing the examples test branch? | 18:59 |
| elopio | sergiusens: there is a tiny lintian error. I could top-approve it, and then give you another branch to fix the issue. | 19:00 |
| elopio | sergiusens: not all the examples are building, but that's expected, right?} | 19:00 |
| sergiusens | elopio, or just take over the branch and resubmit ;-) | 19:00 |
| elopio | and take all the credit \o/ | 19:01 |
| elopio | sergiusens: top approved and https://code.launchpad.net/~elopio/snapcraft/fix_lintian/+merge/272023 | 19:06 |
| elopio | I felt bad to steal Federico's branch. | 19:06 |
| sergiusens | tedg, mind adding a '-q' to the grep calls in the test in https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751 ? | 19:43 |
| tedg | sergiusens: Heh, because that's the biggest source of output ;-) Will do. | 19:45 |
| sergiusens | tedg, I hope and wish zyga gets his branch in soon ;-) | 19:47 |
| longsleep | Is there any particular reason why "auto eth0" was added? I added bug #1498631 for this as it blocks boot for 2 minutes | 19:48 |
| nothal | Bug #1498631: Snappy waits 2 minutes while booting if eth0 is not connected <Snappy:New> <http://launchpad.net/bugs/1498631> | 19:48 |
| ubottu | bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [Undecided,New] https://launchpad.net/bugs/1498631 | 19:48 |
| sergiusens | longsleep, wasn't that always there? | 19:50 |
| longsleep | sergiusens: i do not think so, boot delay started with release 5/stable | 19:51 |
| sergiusens | longsleep, right, but auto eth0 was always there iirc | 19:51 |
| sergiusens | longsleep, might be the first manifestation for something else blocking and I think it may be the wait4network thing | 19:52 |
| sergiusens | Chipaca, ideas? ^ | 19:52 |
| longsleep | sergiusens: ok then some change in systemd might cause it or the ifup-wait-all-auto.service is new | 19:52 |
| longsleep | that service does just wait for a pid file to appear for any interface which gets returned by ifquery --list --exclude lo --allow auto | 19:54 |
| longsleep | maybe that has failed earlier for other reasons | 19:55 |
| sergiusens | longsleep, that service does not ring a bell with me; I'll defer to ogra_ or Chipaca | 19:55 |
| longsleep | sergiusens: yeah - just went through a test run and added 4 or 5 new issues to the tracker. But that one is the most annoying as it requires me to connect a network cable while testing :/ | 19:56 |
| tedg | sergiusens: greps are now quieter | 19:57 |
| * tedg can now hear himself think | 19:57 | |
| * longsleep has turned on loud music and got drunk to prevent thinking | 19:58 | |
| sergiusens | yay | 19:59 |
| Chipaca | longsleep: hi | 20:11 |
| Chipaca | longsleep: you still there? | 20:11 |
| Chipaca | oh, drunk longsleep might be even longer sleep | 20:11 |
| sergiusens | tedg, the tests are failing on tarmac | 20:18 |
| sergiusens | while running 'sed' | 20:19 |
| Chipaca | ooh, nice ppp bug :-/ | 20:22 |
| tedg | sergiusens: Perhaps a dep? | 20:23 |
| tedg | sergiusens: Where is the error? | 20:23 |
| sergiusens | tedg, oh; so complicated; download https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751/comments/685604/+download | 20:24 |
| sergiusens | tedg, and search for failed | 20:24 |
| sergiusens | tedg, train your eyes to get rid of the Leftover thing | 20:24 |
| sergiusens | ;-) | 20:24 |
| longsleep | Chipaca: still there watching soccer | 20:36 |
| Chipaca | longsleep: i presume you filed bug 1498631 ? | 20:37 |
| ubottu | bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [Undecided,New] https://launchpad.net/bugs/1498631 | 20:37 |
| longsleep | Chipaca: yeah - it annoyed me pretty hard last couple of hours :) | 20:37 |
| tedg | sergiusens: It seems to be failing on the greps... wish they weren't quiet ;-) | 20:37 |
| tedg | sergiusens: Not sure what could be failing. Can you run the tests on your system? | 20:38 |
| Chipaca | longsleep: could you add details like the architecture, and how you got the image? | 20:38 |
| tedg | Curious if I've made a special snowflake here. | 20:38 |
| Chipaca | longsleep: I don't think that particular aspect of the system changed; we added a wait4network and make network-needing services start after that, but it should not block boot | 20:38 |
| longsleep | longsleep: Uhm sure - like armhf and u-d-f sytax you mean? | 20:39 |
| Chipaca | longsleep: yeah | 20:39 |
| longsleep | =n | 20:39 |
| * longsleep can't type properly any more :) | 20:39 | |
| tedg | Soccer, does it to me too. | 20:39 |
| Chipaca | longsleep: that way when whoever gets to poke at it does, they don't have to wonder/guess as much :) | 20:39 |
| longsleep | Chipaca: if you have a snappy installation at hand, can you check if you have /lib/systemd/system/ifup-wait-all-auto.service | 20:40 |
| Chipaca | longsleep: sure, let me boot a stable though | 20:40 |
| longsleep | that service is responsible and i think it was not added by anything i did | 20:40 |
| longsleep | actually i did not su much except using my own device and oem snap | 20:41 |
| Chipaca | booting. with network -- i wonder if i can boot kvm without network | 20:41 |
| longsleep | Chipaca: yeah, if you use virsh you can use domif-setlink | 20:42 |
| Chipaca | longsleep: one thing is that we expect the first boot of an updated system to take a while | 20:43 |
| Chipaca | longsleep: but i presume this isn't that | 20:43 |
| longsleep | longsleep: no it waits on any boot until eth0 is up or 2 minutes systemd timeout | 20:44 |
| longsleep | first boot takes longer because it creates keys and such | 20:44 |
| longsleep | but on quad core 1.6 ghz arm it is almost no difference | 20:44 |
| Chipaca | longsleep: first boot after update also needs to shunt kernel and initrd to their new! updated! locations, which is slow | 20:45 |
| Chipaca | but that's just once, just on updated systems (ie systems that were updated, not created from scratch) | 20:46 |
| Chipaca | anyway, yes it exists | 20:46 |
| longsleep | so then ifquery --list --exclude lo --allow auto does return eth0 for you as well, meaning it will wait until the pid file is there | 20:47 |
| longsleep | Chipaca: details added to bug #1498631 | 20:47 |
| nothal | Bug #1498631: Snappy waits 2 minutes while booting if eth0 is not connected <Snappy:New> <http://launchpad.net/bugs/1498631> | 20:47 |
| ubottu | bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [Undecided,New] https://launchpad.net/bugs/1498631 | 20:47 |
| Chipaca | verterok: can you disable the bug plugin for nothal in this channel? it fights with ubottu :-/ | 20:48 |
| Chipaca | verterok: also: hello! long time no chat. | 20:49 |
| Chipaca | longsleep: ifup-wait-yadda-yadda is there in stable 4 also | 20:51 |
| longsleep | Chipaca: regarding the update of kernel, initrd and stuff i have bug #1464859 and it really took ages for me when i was testing upgrade to 5 yesteday and it does not even need the stuff | 20:52 |
| nothal | Bug #1464859: /boot contains unused initrd.img <Snappy:Triaged> <Snappy 15.04:New> <Snappy trunk:Triaged> <http://launchpad.net/bugs/1464859> | 20:52 |
| ubottu | bug 1464859 in Snappy trunk "/boot contains unused initrd.img" [High,Triaged] https://launchpad.net/bugs/1464859 | 20:52 |
| longsleep | Chipaca: yes, so something else must have triggered the new behavior, in 4 there was no boot delay. | 20:52 |
| longsleep | Chipaca: i assumed that the eth0 auto was added, but sergiusens mentioned that was also there before | 20:52 |
| Chipaca | longsleep: do you have snaps installed that have services that have external ports configured? | 20:54 |
| longsleep | Chipaca: no, nothing installed - just the plain image | 20:54 |
| Chipaca | k | 20:54 |
| longsleep | Chipaca: it directly does that on first boot, so only snap installed is the oem snap and that has no services | 20:55 |
| Chipaca | fwiw, “-net none” is what to add to a kvm commandline to get no network | 20:57 |
| longsleep | Chipaca: ok, does it have a NIC then or do you end up without having eth0 ? | 20:57 |
| Chipaca | with that added, i get no network interface | 20:57 |
| Chipaca | and 15.04.5 is taking ages to boot | 20:58 |
| Chipaca | :) | 20:58 |
| Chipaca | but not two minutes | 20:58 |
| longsleep | Chipaca: well there is a nice animation on the boot conole while it waits | 20:58 |
| Chipaca | in fact, significantly less than two minutes | 20:58 |
| longsleep | including countdown | 20:58 |
| Chipaca | yeh, i need to reboot so i can set the console to the right place | 20:58 |
| longsleep | but if you have no eth0 it will not wait | 20:58 |
| longsleep | you need to have eth0 which does not have a connection | 20:59 |
| verterok | Chipaca: hola! | 21:02 |
| verterok | Chipaca: sure, will disable it asap | 21:02 |
| Chipaca | longsleep: just confirmed, no waiting for network at all, here | 21:03 |
| verterok | Chipaca: done | 21:03 |
| Chipaca | longsleep: need to dig a little more | 21:03 |
| Chipaca | longsleep: will do so in a bit | 21:03 |
| Chipaca | verterok: thanks! | 21:04 |
| Chipaca | bug #1 | 21:04 |
| ubottu | bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 | 21:04 |
| Chipaca | \o/ | 21:04 |
| longsleep | Chipaca: yeah, you can easily test with ifquery, if that returns nothing then it will never wait | 21:05 |
| * Chipaca facepalms | 21:05 | |
| longsleep | Chipaca: exactly with 'ifquery --list --exclude lo --allow auto' | 21:05 |
| Chipaca | longsleep: yeah, sorry | 21:05 |
| Chipaca | longsleep: ok, reproduced | 21:28 |
| longsleep | Chipaca: ok great, any ideas why it did not happen on previous builds? | 21:28 |
| Chipaca | longsleep: no | 21:28 |
| Chipaca | longsleep: baby steps :) | 21:28 |
| Chipaca | longsleep: meanwhile you can change that yourself using ubuntu config, yes? | 21:34 |
| longsleep | Chipaca: uhm, sure i just removed auto eth from /etc/network/interfaces.d/eth0 - not sure about ubuntu config | 21:35 |
| longsleep | Chipaca: what is "ubuntu config" ? | 21:36 |
| * longsleep is probably just too drunk | 21:36 | |
| Chipaca | um | 21:36 |
| Chipaca | or i'm too tired | 21:36 |
| Chipaca | because i meant snappy config :) | 21:37 |
| Chipaca | something like | 21:37 |
| longsleep | ah :D | 21:37 |
| Chipaca | echo -e "config:\n ubuntu-core:\n network:\n interfaces:\n - name: eth0\n content: |\n ohgodwhy" | sudo snappy config ubuntu-core | 21:37 |
| longsleep | not sure, does ubuntu-core config now expose network config? I missed the last bunch of weeks snappy development :/ | 21:37 |
| Chipaca | longsleep: yes | 21:38 |
| Chipaca | longsleep: not very cleanly yet, but it gets the job done | 21:38 |
| Chipaca | longsleep: expect it to change | 21:38 |
| Chipaca | longsleep: also, apparently, expect it not to work for ppp :-( | 21:38 |
| * Chipaca needs to check on that | 21:39 | |
| longsleep | Chipaca: ah yes i see, seems one can now handle the content of the eth0 file with snappy config via the oem snap | 21:39 |
| Chipaca | yes | 21:40 |
| longsleep | Chipaca: so yes - no blocking issue for my use case then | 21:40 |
| Chipaca | longsleep: however, note that on first boot a file will be created | 21:40 |
| Chipaca | :-/ | 21:40 |
| Chipaca | so, it will continue to annoy you for a bit | 21:40 |
| longsleep | Chipaca: what do you mean? What file? | 21:40 |
| Chipaca | longsleep: that eth0 file is created on first boot | 21:41 |
| longsleep | Chipaca: right, why would that be a problem? | 21:41 |
| Chipaca | longsleep: doesn't oem config happen at image creation time? | 21:42 |
| longsleep | Chipaca: this is on my list of things to test | 21:42 |
| Chipaca | i have not looked into the oem config magic, though, so i might be wrong :) | 21:43 |
| longsleep | I got told by ogra_ that oem config is applied on first boot, but i might remember it wrong. | 21:43 |
| Chipaca | ogra would know :) | 21:47 |
| longsleep | Chipaca: regarding ppp, did you see #1498620 - i just added some more details | 21:47 |
| longsleep | bug #1498620 | 21:47 |
| ubottu | bug 1498620 in Snappy "Failed to start Restore /etc/resolv.conf if the system crashed before the ppp link" [Undecided,New] https://launchpad.net/bugs/1498620 | 21:47 |
| Chipaca | longsleep: i didn't, but did you see https://lists.ubuntu.com/archives/snappy-devel/2015-September/001047.html | 21:48 |
| longsleep | Chipaca: ah i did not, but that is the problem for #1498620 - so i might have added a duplicate | 21:49 |
| Chipaca | longsleep: i don't think there's a bug for the mailing list message | 21:49 |
| Chipaca | longsleep: are you subscribed? otherwise i'll point him at the bug myself | 21:49 |
| longsleep | Chipaca: yes, i am subscribed - though i can reply tomorrow from the office only | 21:50 |
| * longsleep does not want to read office mail now :) | 21:50 | |
| Chipaca | SGTM :) | 21:50 |
| Chipaca | bug 1498620 | 21:51 |
| ubottu | bug 1498620 in Snappy "ppp files are created one level too deep" [Undecided,New] https://launchpad.net/bugs/1498620 | 21:51 |
| Chipaca | \o/ | 21:51 |
| Chipaca | or /o\ | 21:51 |
| Chipaca | depending | 21:51 |
| longsleep | Well thats an easy one so \o/ for sure :) | 21:52 |
| jakew | As far as I can tell, snapcraft doesn't currently support building armhf snaps. Is that correct? | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!