=== ogasawara is now known as Guest14527 | ||
=== c74d is now known as Guest58751 | ||
=== wgrant is now known as Guest27601 | ||
=== kgunn is now known as Guest52384 | ||
=== Guest27601 is now known as wgrant | ||
=== bigcat_ is now known as bicgat[afk] | ||
dholbach | good morning | 06:50 |
---|---|---|
fgimenez | good morning | 07:09 |
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)? | 07:20 |
ubottu | Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New] | 07:20 |
Chipaca | asac: beuno: http://jimbenton.tumblr.com/image/131162934224 | 08:26 |
tasdomas | morning | 08:29 |
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:30 |
Chipaca | tasdomas: where does it mention that? | 08:33 |
tasdomas | Chipaca, https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement | 08:34 |
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:35 |
Chipaca | tasdomas: so, yes it's supported, for oem snaps | 08:36 |
tasdomas | Chipaca, so for my own snap the only thing to do is use hw-assign, right? | 08:37 |
Chipaca | tasdomas: right | 08:37 |
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:38 |
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:39 |
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 |
ubottu | bug 1484645 in Snappy "Snappy hw-assign doesn't restart affected services" [High,Triaged] https://launchpad.net/bugs/1484645 | 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:40 |
Chipaca | wow, it's going to be a long day | 08:41 |
Chipaca | because you said exactly that | 08:41 |
Chipaca | sorry :-( | 08:41 |
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:42 |
tasdomas | I want to modify it to make it mdns discoverable | 08:43 |
Chipaca | tasdomas: have you tried asking the snap publisher? | 08:44 |
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:45 |
tasdomas | Chipaca, ah, will do | 08:46 |
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:48 |
dholbach | maybe we can talk about it in our next docs hour call? | 08:49 |
dholbach | dpm, ^ | 08:50 |
dpm | it could be a good topic, yes | 08:50 |
dholbach | cool | 08:50 |
davidcalle | dholbach, dpm, +1 | 08:50 |
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:54 |
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:55 |
dholbach | yep, that makes sense | 08:56 |
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?) | 08:58 |
ubottu | Launchpad bug 1506480 in Snappy "Broken link in https://developer.ubuntu.com/en/snappy/guides/porting/" [Undecided,New] | 08:58 |
JamesTait | Good morning all; happy Friday, and happy World Food Day! đ | 09:00 |
ogra_ | dholbach, ppisati should be able to help with the link | 09:22 |
dholbach | cool | 09:22 |
=== soee_ is now known as soee | ||
dpm | dholbach, davidcalle, do we have any document that specifies the format of the snapcraft.yaml file? | 09:30 |
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:32 |
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:33 |
dpm | ahaha | 09:34 |
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:35 |
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:52 |
Chipaca | mvo: ping | 09:53 |
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:54 |
Chipaca | mvo: tell me about it | 09:55 |
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:56 |
mvo | Chipaca: however ls a bit later is fine | 09:57 |
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:58 |
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 | 09:59 |
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:00 |
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:01 |
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:02 |
mvo | yeah, will do | 10:03 |
Chipaca | mvo: have you checked it for speed? | 10:03 |
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:04 |
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:05 |
mvo | Chipaca: do you want me to split the branch for the snapfs-mount up more? | 10:57 |
Chipaca | mvo: how would you split it? | 10:58 |
Chipaca | unless you moved all the systemd stuff to .. ahem .. systemd :-p | 10:58 |
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 | 10:59 |
beuno | Chipaca, lol | 12:18 |
longsleep | yaml question, how can i have a binary with a _ in the name? | 12:44 |
tedg | sergiusens: So I think I may need to copy the options locally to stay under the 79 character limit :-) | 13:07 |
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:30 |
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:31 |
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:32 |
tedg | I think it is nice. I just haven't see the overlays actually work well. Seems like they always get confused for me. | 13:33 |
ogra_ | because you talk like a pirate to them ? | 13:33 |
tedg | Stupid overlays are no fun, they never talk like pirates. | 13:38 |
dholbach | sergiusens, tedg: snappy clinic planning? | 14:01 |
jdstrand | mvo: hey, curious if you had a chance to review my email re snappy-debug. I know we were both pretty busy yesterday | 14:07 |
mvo | jdstrand: I saw it but have not acted on it yet, sorry | 14:18 |
jdstrand | mvo: ack | 14:20 |
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:03 |
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:04 |
dholbach | tedg, sergiusens: I added two more examples to the pad | 15:22 |
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:23 |
Chipaca | elopio: it's just a for loop with a sleep and a check | 15:24 |
Chipaca | elopio: give me a sec | 15:24 |
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:25 |
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:26 |
Chipaca | elopio: and you're waiting for bootok? | 15:27 |
elopio | Chipaca: I'm waiting for snappy_mode=regular | 15:27 |
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:28 |
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:29 |
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:30 |
=== kickinz1 is now known as kickinz1|away | ||
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:31 |
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:32 |
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 |
ubottu | Launchpad bug 1498293 in Snappy "after a successful update and reboot, the bootloader snappy_mode is set to 'try'" [Critical,Triaged] | 15:33 |
elopio | on bbb you don't have to be super fast. I actually can reproduce this manually. | 15:33 |
Chipaca | elopio: so that's the bug | 15:35 |
Chipaca | elopio: not that "try" thing :) | 15:35 |
Chipaca | so, we want the boot-ok to be done *before* ssh and getty lets people in | 15:36 |
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:37 |
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:38 |
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:39 |
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:40 |
dholbach | tedg, sergiusens: is the announce text roughly what you expected? | 15:41 |
sergiusens | dholbach, where is it? | 15:42 |
dholbach | sergiusens, ah sorry - on the pad :) | 15:42 |
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:43 |
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:44 |
* 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:45 |
tedg | dholbach: +1 | 15:46 |
dholbach | sergiusens, I guess it's not too hard to do - maybe something to look into some other time? | 15:53 |
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:05 |
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 | 16:10 |
sergiusens | elopio, very simple MP https://code.launchpad.net/~sergiusens/snapcraft/tested_or_not/+merge/274741 | 17:04 |
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:06 |
=== willcooke_ is now known as willcooke | ||
sergiusens | Chipaca, can we get the release from the rest api already or not? | 17:21 |
Chipaca | sergiusens: i don't think that's in stable yet | 17:22 |
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:24 |
Chipaca | sergiusens: updating to latest edge to see if it's there yet | 17:29 |
sergiusens | elopio, ok, it just bothers me to be honest :-) | 17:31 |
Chipaca | sergiusens: wait, the release? | 17:36 |
Chipaca | sergiusens: you could always get the release! | 17:36 |
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:37 |
Chipaca | sergiusens: ^ that's the output in rolling/edge :) | 17:38 |
sergiusens | Chipaca, yup, nice | 17:38 |
Chipaca | sergiusens: http://pastebin.ubuntu.com/12801274/ | 17:39 |
Chipaca | sergiusens: that's 15.04, now | 17:39 |
Chipaca | sergiusens: note the socket name has changed | 17:40 |
sergiusens | Chipaca, life is good! | 17:42 |
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:43 |
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:44 | |
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:45 |
sergiusens | Chipaca, btw https://github.com/docopt/docopt.go | 17:46 |
Chipaca | ! | 17:46 |
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:49 |
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:52 |
pitti | yes | 17:53 |
Chipaca | elopio: could you try that? | 17:53 |
Chipaca | pitti: thanks! | 17:53 |
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:55 |
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 | 17:56 |
sergiusens | Chipaca, let me fix! | 18:34 |
sergiusens | :-) | 18:34 |
sergiusens | Chipaca, I like the docopts thing, but I can't easily add help to commands | 18:56 |
sergiusens | tedg, final comment wrt setup_stage_packages | 20:00 |
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:01 | |
tedg | sergiusens: I don't think we can use pull with the current configuration of the command. Because the superclass is just empty. | 20:02 |
sergiusens | tedg, right, I mean, pull() -> handle_source_options; | 20:04 |
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:05 |
sergiusens | tedg, 2? | 20:06 |
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:07 |
sergiusens | tedg, let me try and propose something | 20:08 |
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:13 |
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:14 |
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:16 |
tedg | http://paste.ubuntu.com/12804340/ | 20:19 |
tedg | http://pastebin.ubuntu.com/12804368/ | 20:20 |
tedg | The first results in the second :-) | 20:20 |
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:31 |
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:32 |
sergiusens | tedg, its just a mnissing os.makedirs(os.path.basename(real_path, exist_ok=True) | 20:33 |
sergiusens | before the copy | 20:33 |
sergiusens | tedg, what I don't get is that that lib should of been relinked to the internal one | 20:35 |
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:40 |
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:41 |
sergiusens | tedg, all others come inherited from deb2snap | 20:42 |
tedg | sergiusens: So, I think it found a bug, but perhaps it isn't a bad bug once we get everything more refined. | 20:43 |
sergiusens | tedg, what bug? | 21:04 |
tedg | sergiusens: Not making the directory | 21:07 |
sergiusens | tedg, right, that is indeed a bug | 21:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!