| === chihchun_afk is now known as chihchun | ||
| === devil is now known as Guest24582 | ||
| === leftyfb_ is now known as leftyfb | ||
| zyga | good morning | 07:23 |
|---|---|---|
| qengho | zyga: good...morning | 07:26 |
| ngaio | hi all good morning / afternoon. Hey how do I minimize the amount of packages being pulled down when I do a pull. I'm on a metered Internet connection and pay by the MB. I'm taking my first steps to building a snap, and it seems when I pull one part, it downloads all over again the same packages for another part | 07:40 |
| qengho | ngaio: Could you not clean up the part that downloads a lot? | 07:43 |
| ngaio | qengho, I didn't clean anything | 07:43 |
| ngaio | all I did was one pull, then another | 07:43 |
| qengho | ngaio: what kind of section do you have that lists packages? | 07:44 |
| ngaio | where can i copy & paste a sample? | 07:45 |
| qengho | paste.ubuntu.com | 07:45 |
| ngaio | http://paste.ubuntu.com/16486317/ | 07:46 |
| ngaio | there is a problem with the pyzmq package-- i can't figure out how to specify the version | 07:46 |
| ngaio | it's failing there | 07:46 |
| ngaio | but that's a different problem | 07:46 |
| qengho | probably "pyzmq=15.1.0", fwiw | 07:47 |
| qengho | That's an APT-ism. | 07:47 |
| ngaio | I couldn't find that anywhere in the online docs or in the comments in the plugin source | 07:47 |
| qengho | Oh, but that's not the package you mean. | 07:47 |
| ngaio | no it's not an ubuntu package.... it's a pypi package | 07:48 |
| qengho | Different kind of package, right? | 07:48 |
| qengho | Right. | 07:48 |
| qengho | ngaio: For development, I think you can probably put a full local filename path instead of Ubuntu packages, and perhaps of Python packages, and your local cached files will be used instead. I think. Maybe. Possibly. | 07:49 |
| ngaio | qengho, that would be a big help when it comes to my internet usage, if it works! | 07:50 |
| qengho | ngaio: I have never tried it for "package" things, just for large source tarball sources. | 07:50 |
| qengho | ngaio: The snapcraft sources are not too hard to read. You should look into what the python source does, to see if it takes a version. $ dpkg -L snapcraft | 07:52 |
| qengho | ngaio: And if versions are a common thing to specify, then file a bug report to ask for it. $ ubuntu-bug snapcraft | 07:53 |
| qengho | And even "debpackage=version" doesn't work. Sigh. | 07:57 |
| qengho | Bed time. | 07:57 |
| ngaio | qengho, thanks for your help... I'm looking at the source now | 08:03 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| morphis | zyga: ping | 08:36 |
| zyga | morphis: o/ | 08:41 |
| zyga | morning | 08:41 |
| morphis | zyga: morning | 08:41 |
| morphis | zyga: have a first draft for a pulseaudio slot part of the interface | 08:41 |
| morphis | zyga: but wondering if we don't want to do an audio interface too which abstracts the kernel access for audio devices | 08:42 |
| zyga | neat! what's the pull request number? | 08:42 |
| zyga | morphis: like alsa? | 08:42 |
| morphis | zyga: no PR yet | 08:42 |
| morphis | zyga: like also, yes | 08:42 |
| zyga | morphis: so pulse would consume alsa and expose pulse? | 08:42 |
| morphis | yes | 08:42 |
| zyga | mmm, I guess the answer is, perhaps | 08:42 |
| zyga | but I'd wait with that for a real consumer | 08:42 |
| zyga | and for hooks | 08:43 |
| morphis | ok | 08:43 |
| zyga | e.g. you assign alsa, cannot use pulse yet | 08:43 |
| morphis | then lets add those things to the pulse interface for now | 08:43 |
| zyga | it's sensible just more complicated to model | 08:43 |
| zyga | yep | 08:43 |
| morphis | sth like hw-assign doesn't exist anymore, right? | 08:43 |
| zyga | morphis: correct | 08:43 |
| morphis | good | 08:43 |
| morphis | zyga: either I base my PR on top of yours or I do a new one covering yours and mien at the same time | 08:44 |
| zyga | morphis: is there an actual difference? | 08:46 |
| === joc__ is now known as joc_ | ||
| === cprov_ is now known as cprov | ||
| === ev_ is now known as ev | ||
| === thomi_ is now known as thomi | ||
| zyga | morphis: do you have an idea when we can land pulseaudio record lockout? | 08:46 |
| zyga | morphis: and I wonnder if you saw my message about the memory leak last night | 08:46 |
| morphis | zyga: (message) saw it and fixed the leak | 08:46 |
| morphis | zyga: the change needs testing and review | 08:46 |
| === plars_ is now known as plars | ||
| === xnox_ is now known as xnox | ||
| morphis | zyga: and need to find out who maintains pulse these days :-) | 08:47 |
| morphis | maybe seb128 knows | 08:47 |
| === tedg_ is now known as tedg | ||
| zyga | morphis: do you have a plan to SRU it anytime soon? | 08:47 |
| * seb128 doesn't know anything | 08:47 | |
| seb128 | hey there :-) | 08:47 |
| zyga | seb128: hey :) | 08:47 |
| morphis | zyga: no concrete | 08:47 |
| morphis | seb128: hey | 08:47 |
| seb128 | morphis, zyga, TheMuso maintains pulseaudio for us | 08:48 |
| seb128 | you can find him on #ubuntu-desktop/devel | 08:48 |
| morphis | seb128: thanks! | 08:48 |
| seb128 | but he's .au based might be off for the evening already | 08:48 |
| seb128 | yw | 08:48 |
| morphis | zyga: I must say I never did a real SRU yet | 08:48 |
| morphis | so would be good if we could just hand this to somebody | 08:49 |
| seb128 | morphis, zyga, I can help you ... what serie do you want to SRU to? | 08:49 |
| morphis | seb128: xenial | 08:49 |
| seb128 | just get a bug on launchpad with the patch | 08:49 |
| zyga | morphis: can you build pulse in a ppa somewhere | 08:49 |
| seb128 | and give me the number | 08:49 |
| seb128 | we can handle the SRU process | 08:49 |
| zyga | morphis: or just listen to seb128 | 08:49 |
| morphis | seb128: sounds great! | 08:49 |
| morphis | seb128, zyga: have it in https://requests.ci-train.ubuntu.com/#/ticket/1428 already but still under testing | 08:50 |
| seb128 | morphis, we need a bug anyway for SRU process | 08:50 |
| morphis | seb128: ok, let me create one then | 08:50 |
| fgimenez | hey mwhudson, i'm getting http://paste.ubuntu.com/16486677/ while trying to execute snappy's integration test suite and have been told that you could help me with that | 08:51 |
| fgimenez | mwhudson, sorry if that's not the case :) could you please have a look at it? | 08:52 |
| zyga | morphis: is there any tiny app we can use to demo the fact that recording is forbidden | 08:52 |
| === braderhart_ is now known as braderhart | ||
| morphis | zyga: on the way building one | 08:53 |
| morphis | seb128, zyga: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1583057 | 08:53 |
| ubottu | Launchpad bug 1583057 in pulseaudio (Ubuntu) "Deny audio recording for all snap applications" [Undecided,New] | 08:53 |
| seb128 | morphis, thanks | 08:53 |
| seb128 | morphis, zyga, lol, I though you guys wanted to fix a leak ... adding a new module is not going to be as easy by SRU rules | 08:56 |
| zyga | seb128: it's data privacy leak ;) | 08:57 |
| zyga | seb128: can we get help somewhere? | 08:57 |
| zyga | summon some super powers or something? | 08:57 |
| morphis | seb128: :-) | 08:57 |
| seb128 | zyga, no, need to play by the rules, https://wiki.ubuntu.com/StableReleaseUpdates | 08:57 |
| seb128 | zyga, but basically could you put the rational/test case/regression potential | 08:57 |
| seb128 | like rather is "needed for snappy" | 08:58 |
| seb128 | we can get it uploaded&co | 08:58 |
| seb128 | I'm just unsure the SRU team is going to be too happy about it | 08:58 |
| zyga | seb128: understood, we'll do our best | 08:58 |
| mwhudson | fgimenez: huh | 08:59 |
| mwhudson | fgimenez: go version? | 08:59 |
| zyga | morphis: I think we should test this thoroughly on random non-snappy apps to ensure there's no impact | 09:00 |
| zyga | morphis: and play the only-affects-snappy card as a regression potential | 09:00 |
| mwhudson | fgimenez: also, reproduction instructions? | 09:00 |
| mwhudson | fgimenez: i guess it must either be s390x or yakkety? | 09:00 |
| morphis | zyga: that is the plan | 09:00 |
| morphis | zyga: the module shouldn't have any impact on non-snappy apps | 09:00 |
| morphis | and still simply allows recording | 09:01 |
| morphis | zyga: you have time to test this one too? | 09:01 |
| zyga | morphis: yes, I will gladly help | 09:01 |
| morphis | great | 09:01 |
| zyga | especially now when I'm just about as sleepy as I can | 09:02 |
| === jospoortvliet_ is now known as jospoortvliet | ||
| morphis | zyga: :-) | 09:07 |
| fgimenez | mwhudson, yes, yaketty, more about the environment http://paste.ubuntu.com/16486953/ | 09:08 |
| fgimenez | *yakkety | 09:09 |
| mwhudson | fgimenez: ok, i think that should be working so i'll have a poke | 09:09 |
| fgimenez | mwhudson, ok thanks, to reproduce from a working $GOPATH "mkdir -p ./github.com/ubuntu-core && cd ./github.com/ubuntu-core && git clone https://github.com/ubuntu-core/snappy && cd snappy && go run ./integration-tests/main.go" | 09:13 |
| fgimenez | in fact from $GOPATH/src | 09:14 |
| mwhudson | fgimenez: well hooray, it works for me | 09:23 |
| mwhudson | fgimenez: can you run go run -x ./integration-tests/main.go and show me the output | 09:24 |
| fgimenez | mwhudson, sure http://paste.ubuntu.com/16487054/ | 09:25 |
| mwhudson | fgimenez: doesn't look like you're running /usr/bin/go | 09:29 |
| mwhudson | fgimenez: /home/fgimenez/src/go/pkg/tool/linux_amd64/compile | 09:29 |
| mwhudson | fgimenez: i don't maintain that one :-) | 09:29 |
| fgimenez | mwhudson, oops thanks! will try with the package version, sorry for the noise | 09:34 |
| mwhudson | fgimenez: heh nw | 09:35 |
| sborovkov | Hello, asked this question yesterday, but no one answered. May be better luck today. Let's say I install snap in --devmode. If I upgrade to newer version of snap - can I automatically remove --devmode somehow | 11:28 |
| kyrofa | Good morning | 11:40 |
| === tai271828_ is now known as tai271828 | ||
| === Aria|away is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| === Aria22 is now known as Aria22|away | ||
| === Aria22|away is now known as Aria22 | ||
| === Aria22 is now known as Aria | ||
| === Aria is now known as Aria22 | ||
| morphis | zyga: you had time to take a final look at https://github.com/ubuntu-core/snappy/pull/1036 ? | 12:55 |
| === john-mca` is now known as john-mcaleely | ||
| zyga | morphis: not fully but I think we should land it | 13:00 |
| morphis | zyga: ok, then lets do that | 13:00 |
| morphis | zyga: so when you merge it today, when will we have it in xenial? | 13:01 |
| zyga | morphis: next week | 13:01 |
| zyga | morphis: every Wed AFAIR | 13:01 |
| morphis | end of next week? | 13:01 |
| zyga | morphis: we have one SRU in the pipe now | 13:01 |
| zyga | morphis: if it lands now it will be released next week | 13:01 |
| zyga | jdstrand: do you have any last comments on n-m interface? | 13:06 |
| noizer | Hi zyga | 13:09 |
| noizer | zyga how are you? | 13:10 |
| noizer | zyga I have a strange problem with copying the armel build (chroot) to my snap | 13:10 |
| noizer | zyga here you got a minified yaml file of my snap http://paste.ubuntu.com/16490708/ | 13:10 |
| noizer | zyga and thats the error [Errno 2] No such file or directory: '/home/ubuntu/software3003/parts/ | 13:11 |
| noizer | staticfiles/build/./armel/usr/share/zoneinfo/localtime' | 13:11 |
| jdstrand | zyga: I want to go through the recent comments, yes. I have a couple of meeting so it will be a couple of hours | 13:14 |
| jdstrand | meetings* | 13:14 |
| zyga | jdstrand: sounds good, thank you | 13:16 |
| zyga | noizer: hey :-) | 13:16 |
| zyga | noizer: sudo won't work there | 13:17 |
| zyga | noizer: as in, in is not allowed | 13:17 |
| zyga | noizer: I would suggest you to put this into a wrapper script and not put everythiong on one long line | 13:17 |
| noizer | zyga ok but my snapcraft build won't build :s | 13:18 |
| zyga | noizer: why? | 13:19 |
| noizer | zyga [Errno 2] No such file or directory: '/home/ubuntu/software3003/parts/ | 13:21 |
| noizer | staticfiles/build/./armel/usr/share/zoneinfo/localtime' | 13:21 |
| zyga | noizer: I'm not sure what that error means, perhaps this should be reported to snapcraft | 13:22 |
| noizer | zyga Wait I will try some other things and then report it if it is nec. | 13:22 |
| zyga | noizer: I would also suggest you to make the snap manually | 13:23 |
| zyga | noizer: just use mksquashfs on it, put meta/snap.yaml in place | 13:23 |
| zyga | noizer: and see what happens | 13:23 |
| morphis | zyga: how do I get the bot to run all tests on my PR? | 13:23 |
| morphis | wasn't there a command to do that? | 13:24 |
| zyga | morphis: "retest this please" | 13:25 |
| zyga | but it may be picky as it may not let you do it | 13:25 |
| zyga | let me run that for you | 13:25 |
| noizer | zyga Ok I'll try that | 13:25 |
| zyga | morphis: running now | 13:29 |
| zyga | morphis: n-m one | 13:30 |
| morphis | zyga: thanks | 13:30 |
| Facu | question: when packaging a snap, where should I put the "man" page? | 13:39 |
| qengho | Facu: it doesn't matter, because outside "man" can't find it. | 13:41 |
| Facu | qengho, how the man pages, or this kind of documentation in general, is handled in the snap world? | 13:41 |
| qengho | Facu: You might want to add a new app: help: command: cat $SNAP/formatted_man_page | 13:42 |
| morphis | zyga: do we have any possiblity to populate udev rules from a snap? | 13:42 |
| morphis | and not as part of an interface? | 13:43 |
| Facu | qengho, ack, thanks | 13:43 |
| zyga | morphis: no, but an interface can | 13:54 |
| zyga | morphis: what do you need? | 13:54 |
| zyga | morphis: (so a permanent snippet on a slot could do it) | 13:54 |
| morphis | zyga: for modem-manager we have device specific udev rules | 13:54 |
| morphis | and putting them into a interface is not what we should do | 13:55 |
| zyga | morphis: hmmmmm | 13:56 |
| zyga | morphis: perhaps it is, just in the slot definition itself | 13:56 |
| zyga | morphis: we talked about having device specifc stuff in a slot, (pinging ricmm for context if needed) | 13:56 |
| zyga | morphis: think about it | 13:56 |
| morphis | zyga: you mean as parameter? | 13:56 |
| zyga | morphis: we could have a "hardware-enablement" interface or similar | 13:56 |
| morphis | yes | 13:57 |
| zyga | morphis: and we'd stick it on the kernel snap | 13:57 |
| zyga | morphis: and connect to mm | 13:57 |
| zyga | morphis: (so the plug would gain the real power) | 13:57 |
| zyga | morphis: but the slot would say what the powers are | 13:57 |
| morphis | hm | 13:57 |
| morphis | zyga: kernel / gadget snap sounds like a possible thing | 13:57 |
| zyga | morphis: I'm going to pick up kids from school now, bbl | 13:57 |
| zyga | morphis: ping me with details please or use email | 13:58 |
| morphis | zyga: will do | 13:58 |
| === not_phunyguy is now known as phunyguy | ||
| kyrofa | elopio, are you around today? | 15:11 |
| zyga | re | 15:30 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | mhall119 (CC Trevinho): hey, you said in https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 'and am also getting some apparmro denials' -- what were they? if they are the ones I mentioned in the MP then I think there is more work to do on the MP | 16:02 |
| didrocks | hey kyrofa, how are you? | 16:08 |
| kyrofa | didrocks, hey! How's Texas? | 16:08 |
| kyrofa | And I'm doing well :) | 16:08 |
| didrocks | kyrofa: rainy :p | 16:09 |
| kyrofa | Yikes | 16:09 |
| kyrofa | All legs of my flight were delayed because of thunderstorms over that area | 16:09 |
| kyrofa | And it's still going? | 16:10 |
| didrocks | no, it's stopped right now | 16:10 |
| kyrofa | Oh, okay | 16:10 |
| didrocks | but it was quite impressive :) | 16:10 |
| kyrofa | I bet it was! | 16:10 |
| didrocks | yeah :) | 16:10 |
| didrocks | I was wondering how you generally approach this: I'm trying to snap galculator, but as most of project, they hardcode datadir at compile time to fetch resources at runtime | 16:10 |
| didrocks | but ofc, then, nothing is available at runtime on /share ;) | 16:11 |
| kyrofa | Ah yes | 16:11 |
| kyrofa | Pretty typical problem | 16:11 |
| didrocks | and ofc, changing datadir in the configure flag make it install relative to that path | 16:11 |
| didrocks | so that doesn't even workaround the issue | 16:11 |
| didrocks | (be installed in /snap/galculator/current/snap/galculator/current/share/foo for instance) | 16:12 |
| kyrofa | So the way I solve it typically depends on the project. Lots of projects that need to reach out like that also support configuration files. No go there? | 16:12 |
| didrocks | well, I can setup datadir=/snap/galculator/current as a workaround for now | 16:12 |
| didrocks | but | 16:12 |
| jdstrand | zyga: hey, I had a number of PRs for unity7 interface that I was hoping would be in 2.0.4, but it seems they weren't committed. should I be doing something differently? | 16:12 |
| didrocks | then, it influences the installation path | 16:12 |
| jdstrand | aiui, I request, it gets a review, but then I was told someone else needs to commit | 16:13 |
| kyrofa | didrocks, yeah, I see what you mean | 16:13 |
| didrocks | kyrofa: apart from patching upstream, I don't have a good idea on how to resolve this | 16:15 |
| * seb128 is interested as well | 16:15 | |
| kyrofa | didrocks, so no config file, and no runtime flag available either? | 16:15 |
| didrocks | nothing that I saw in the code | 16:16 |
| kyrofa | didrocks, I've not actually encountered a project that was so inflexible | 16:16 |
| kyrofa | didrocks, yeah the only option I see left is to maintain a fork and try to move a runtime flag upstream | 16:16 |
| kyrofa | (or a config file, if you like that better) | 16:16 |
| ogra_ | hexedit ! | 16:16 |
| kyrofa | ogra_, hahaha | 16:16 |
| didrocks | kyrofa: no way to patch I guess? | 16:17 |
| kyrofa | didrocks, not yet, but you're not the first to ask | 16:17 |
| zyga | jdstrand: no, I guess just bash me more often | 16:17 |
| zyga | jdstrand: 2.0.4 is last Friday | 16:17 |
| didrocks | which is making taking all goodness of getting things from last upstream hard | 16:17 |
| kyrofa | didrocks, it needs some thoughtful design | 16:17 |
| zyga | jdstrand: 2.0.5 aka 2016W20 is next week so don't worry, we'll just merge them | 16:18 |
| seb128 | didrocks, kyrofa, Trevinho made a quilt plugin in https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 to apply a patch at build time | 16:18 |
| seb128 | sharing one of the existing workarounds invited by people around | 16:18 |
| Trevinho | it's hacky, eh... | 16:18 |
| seb128 | Trevinho, good morning! ;-) | 16:18 |
| Trevinho | seb128: hey... Sort of :) | 16:18 |
| * zyga wonders where is the person that was working on arch support | 16:19 | |
| didrocks | thanks seb128, Trevinho, kyrofa | 16:19 |
| didrocks | kyrofa: yeah, it's quite hackish and will need to rewrite a good part of upstream | 16:19 |
| didrocks | and I bet GNOME is mostly the same | 16:19 |
| didrocks | seb128: do you have any GNOME app snapped at all? (and working :p) | 16:19 |
| seb128 | didrocks, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap | 16:20 |
| seb128 | didrocks, our list if issues is on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=snap-desktop-issue | 16:20 |
| Trevinho | jdstrand: mhmh... I've got the thing running here unconfined, but yes... maybe it doesn't work unconfined because it can't access to some local files.. .I didn't check that yet... | 16:20 |
| seb128 | didrocks, the branch from Trevinho I just pointed has some improvement I'm looking at now | 16:20 |
| kyrofa | didrocks, which files are we talking about here? | 16:20 |
| seb128 | like generating caches are runtime | 16:20 |
| ogra_ | zyga, blackout24 you mean ? | 16:21 |
| Trevinho | jdstrand: probably hello-unity python installer has something wrong... | 16:21 |
| jdstrand | Trevinho: right, I'm talking about when not using --devmode | 16:21 |
| ogra_ | (obviously not here atm) | 16:21 |
| Trevinho | or it's wrong the way snapcraft handles it | 16:21 |
| jdstrand | Trevinho: and the accesses indicate it is using some weird paths | 16:21 |
| didrocks | kyrofa: lp:~didrocks/+junk/galculator-snap for instance, here is the output (installed with --devmode): http://paste.ubuntu.com/16494689/ | 16:21 |
| Trevinho | seb128, didrocks: my plan was to move those script in something like a build plugin that can generate something at build time | 16:21 |
| zyga | ogra_: thanks! | 16:22 |
| didrocks | seb128: yeah, like the gdk pixbuf issue as well ^ | 16:22 |
| Trevinho | since something (like gsettings cache, or mime or icon cahces) can be done at that level | 16:22 |
| Trevinho | seb128: it would be quite easy to do. We can do it. | 16:22 |
| kyrofa | didrocks, ah, so indeed something gnome-specific | 16:23 |
| didrocks | kyrofa: well, Mate for this case, but yeah | 16:23 |
| seb128 | gtk* | 16:23 |
| Trevinho | seb128: however, as discussed in bug #1551716, we should fix snapcraft to allow patching in a native way (or imho, just runing a script in between source pulilng and building). sergiusens if you can comment in what's your preferred approach in that, I could come with a PR. | 16:23 |
| seb128 | didrocks, seems like we are getting bind mount interfaces though, so that are going to be able to make things like mimetypes or pixbuf loaders work | 16:23 |
| ubottu | bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New] https://launchpad.net/bugs/1551716 | 16:24 |
| didrocks | seb128: oh, so we will be able to bindmount some files? | 16:24 |
| seb128 | Trevinho, imho we require to apply patches to upstream code to work on snap we loose | 16:24 |
| zyga | didrocks: we're getting support for that | 16:24 |
| seb128 | didrocks, seems o | 16:24 |
| seb128 | so | 16:24 |
| zyga | didrocks: there is a bug open on snappy and ubuntu-core-launcher | 16:24 |
| zyga | didrocks: ~ next week | 16:24 |
| kyrofa | didrocks, yeah, we need that for fonts, locales, etc. | 16:24 |
| didrocks | kyrofa: zyga: ok, that wouldn't help that .ui file though (which is part of upstream's project) | 16:25 |
| didrocks | basically in one Makefile.am: | 16:25 |
| didrocks | uidir = $(datadir)/galculator/ui | 16:25 |
| zyga | though note that it's not a way to just load random files from classic | 16:25 |
| didrocks | so changing datadir change uidir, which is where things are stored | 16:25 |
| seb128 | didrocks, the --prefix=... should work for that case though? | 16:25 |
| kyrofa | Trevinho, seb128 yeah at least from my perspective I keep getting conflicting requests about patching/not patching and how it relates to contributions upstream | 16:26 |
| Trevinho | jdstrand: yeah... it's weird that those paths are hardcoded. Not sure what's doing the setup.py under the hood, but it doesn't seem anything particular hard... However I just focused in getting compoments to run. So... if you want o check the code further, I leave that in hold for a while | 16:26 |
| didrocks | seb128: hum, using --prefix=/snap/galculator/current/ ? | 16:26 |
| kyrofa | sergiusens may have more information-- he'll be back on Monday | 16:26 |
| seb128 | didrocks, yes | 16:26 |
| zyga | didrocks: note that /snap might change some day, it's better (though harder) to really understand $SNAP | 16:27 |
| seb128 | didrocks, otherwise get upstream to use gresources and have the .ui including in the binary ;-) | 16:27 |
| Trevinho | kyrofa: well, patching is something we need to provide... People can't just fork a project when a patch can live without having to care about pulling at every upstream update. | 16:27 |
| seb128 | zyga, well, those are defined at buildtime | 16:27 |
| seb128 | zyga, those being the code function calling things on a path | 16:27 |
| Trevinho | kyrofa: and Mark gave is +1, if I read correctly that bug. | 16:27 |
| seb128 | same for locales and bindtextdomain() | 16:28 |
| seb128 | they do | 16:28 |
| seb128 | bindtextdomain ("domain", LOCALEDIR)' | 16:28 |
| zyga | seb128: and all of that can be moved | 16:28 |
| didrocks | zyga: yeah, but here, we are quie in a blocked situation | 16:28 |
| zyga | seb128: note that snap name can be changed too | 16:28 |
| seb128 | zyga, so what do you suggest doing? | 16:28 |
| didrocks | seb128: sure, that's totally doable for delivering that this week… | 16:28 |
| zyga | this is fine for a short term solution but IMHO patching the world to understand $SNAP in various low-level toolkits would be best | 16:29 |
| kyrofa | Trevinho, ah, so did gustavo. Okay, that clears things up, I guess I missed that conversation | 16:29 |
| seb128 | that's bong | 16:29 |
| seb128 | we message snap as a way for upstream to ship their code unmodified by distro | 16:29 |
| zyga | seb128: why? | 16:29 |
| seb128 | and now we tell them they need distro patches to work on our system | 16:29 |
| seb128 | head -> desk | 16:29 |
| zyga | seb128: that doesn't mean some middleware layer must stay oblivious to what snaps are | 16:29 |
| zyga | seb128: we had to patch nearly all major pieces | 16:29 |
| zyga | seb128: (ask morphis) | 16:30 |
| seb128 | well, you loose adoption at this point | 16:30 |
| seb128 | the interfaces yes | 16:30 |
| zyga | seb128: well, what is your suggestion? | 16:30 |
| jdstrand | Trevinho: I may be able to work with what it there | 16:30 |
| zyga | seb128: no, for paths | 16:30 |
| seb128 | but if you need to patch "randomcalc" code to change it's paths | 16:30 |
| zyga | seb128: --prefix is never correct for a snap (it can move around) | 16:30 |
| jdstrand | zyga: ack, thanks | 16:30 |
| seb128 | I suggest fixing that ^ | 16:30 |
| seb128 | and making a predictable prefix | 16:30 |
| zyga | seb128: that's a design decision that we've commited to | 16:31 |
| zyga | seb128: this is not my decision but we shouldn't build everything against that | 16:31 |
| seb128 | well, it's fine | 16:31 |
| seb128 | it's just going to slow down adoption | 16:31 |
| seb128 | if upstream need to "fix" their code to work on snappy | 16:31 |
| zyga | seb128: I suspect that is true | 16:31 |
| zyga | seb128: but only for middleware pieces | 16:31 |
| zyga | seb128: (most things should not care much) | 16:31 |
| seb128 | they do though | 16:32 |
| zyga | seb128: but I agree in principle | 16:32 |
| seb128 | any gettext program calls | 16:32 |
| seb128 | bindtextdomain ("domain", LOCALEDIR)' | 16:32 |
| seb128 | to read translations | 16:32 |
| zyga | seb128: well, we could patch glibc (we plan to anyway) | 16:32 |
| seb128 | where LOCALEDIR is $prefix/usr/locale | 16:32 |
| zyga | seb128: and a few other things to make that code correct in a snappy context | 16:32 |
| seb128 | and to fix calculator loading its .ui from $prefix/usr/share/ui you patch calculator | 16:33 |
| seb128 | you fork the world and end up maintaining patched versions of everything | 16:33 |
| zyga | seb128: with $SNAP being relocatable, we have no other choice really | 16:33 |
| didrocks | seb128: I don't see that specific issue (hardcoded paths) being in the bug list, should I open one or did I mis it? | 16:33 |
| seb128 | sounds like deb based ubuntu :p | 16:33 |
| zyga | seb128: I mean that all of those patches should end up upstream | 16:33 |
| zyga | seb128: or at least in ubuntu as patches for deb-based snaps | 16:33 |
| seb128 | didrocks, I mentioned it on https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282 which is one of those cases | 16:33 |
| ubottu | Launchpad bug 1576282 in snapcraft (Ubuntu) "Snaps built from deb can't be gettext translated" [Undecided,New] | 16:33 |
| zyga | seb128: anyway, sorry for derailing your discussion | 16:33 |
| seb128 | didrocks, but yeah, feel free to open one | 16:33 |
| didrocks | seb128: let me open an explicit bug about it, shall we? | 16:33 |
| didrocks | yeah | 16:33 |
| seb128 | thanks | 16:34 |
| didrocks | ok, building with --prefix, and see how it goes | 16:34 |
| seb128 | zyga, it's not derailing, don't worry | 16:34 |
| seb128 | zyga, I'm ready to bet that you are going to figure out at some point that you need a way to fix that path problem other than asking every app in the world to patch their code to have a if (getenv(SNAP...)) hacks | 16:35 |
| seb128 | but let's see | 16:35 |
| zyga | seb128: a kernel patch perhaps? :) | 16:35 |
| zyga | something like /proc/self | 16:35 |
| seb128 | yeah | 16:35 |
| zyga | seb128: though I think smart patches in glibc could do 90% of the work | 16:35 |
| seb128 | or maybe you need to divert libc and other libs in a wrapper changing the paths on fly for you :p | 16:35 |
| zyga | seb128: we though ot LD_PRELOAD library or a runtime helper (added at link time) to "cure" some common issues | 16:36 |
| seb128 | I can see how one gets there | 16:36 |
| seb128 | but you are working around in hackish way for issues selft created :-/ | 16:37 |
| seb128 | well the bind mount is at least going to solve a part of those | 16:37 |
| seb128 | locales, mimetypes, fonts, etc | 16:37 |
| zyga | seb128: until we do personal and we expect those snaps to still work | 16:37 |
| zyga | seb128: we have to be careful with bind mounts | 16:37 |
| zyga | seb128: there's a reason we bind mount the os snap over regular ubuntu today | 16:37 |
| didrocks | seb128: hum, modifying prefix modify destdir as well… | 16:38 |
| seb128 | didrocks, you can make install DESTDIR=..., which is what deb do | 16:38 |
| kyrofa | seb128, that's what the autotools plugin does | 16:39 |
| didrocks | yeah, unsure you can do that easily with snapcraft, kyrofa ^ | 16:39 |
| zyga | (sooner or later you will start patching, this is barganing phase of kubler-ross :/ | 16:39 |
| didrocks | kyrofa: hum, maybe I'm doing something wrong, but here is what I changed: | 16:39 |
| didrocks | kyrofa: configflags: ["--prefix=/snap/galculator/current/usr/"] | 16:39 |
| kyrofa | didrocks, have you tried doing this standalone? Make sure the build system actually respects DESTDIR correctly? | 16:39 |
| didrocks | and nothing else | 16:39 |
| kyrofa | didrocks, because I've run into a few that don't | 16:40 |
| kyrofa | didrocks, ohh, wait, try this | 16:40 |
| morphis | seb128: this problem does not only affect us but also apps for xdg-app need adjustments from what I saw | 16:41 |
| kyrofa | didrocks, there are two ways to install something. Set a prefix and install (in which case is goes to the prefix), or use DESTDIR to put it where you want it to go | 16:41 |
| zyga | kyrofa: prefix and destdir serve different purpose but I'm sure you know that | 16:41 |
| didrocks | kyrofa: yeah, I know that, did packaging for years ;) | 16:41 |
| morphis | seb128: I don't see that $SNAP should be part of every opensource software but every software should be relocatable and not hardcode any paths | 16:41 |
| seb128 | morphis, most are relocatable but the destination is defined at build time | 16:42 |
| morphis | seb128: right, and that is something which has to change somehow | 16:42 |
| kyrofa | didrocks, yeah I figured you knew that from autotools, but what I mean to say is that the autotools plugin also supports that | 16:42 |
| didrocks | kyrofa: what's the right combination then? I did try to set install-via desdir | 16:42 |
| didrocks | destdir | 16:42 |
| seb128 | morphis, that's not going to change overnight and sort of conflicting with the goal of what main apps to be snapped by next week | 16:42 |
| didrocks | (you have the branch, right?) | 16:42 |
| kyrofa | didrocks, so: was there another flag you can use instead of prefix to get it using the right file? | 16:42 |
| zyga | morphis: very true, this is a dual transition: from debs to snaps and from fixed prefix to "portable" installation | 16:42 |
| morphis | seb128: I know that somebody tried something like overlayfs but somehow that didn't worked out | 16:42 |
| zyga | morphis: overlayfs breaks aa | 16:43 |
| zyga | seb128: would it change anything if we gave each app process a bind mount to /snap | 16:43 |
| zyga | seb128: I mean to $SNAP | 16:43 |
| didrocks | kyrofa: uidir is defined from datadir, which is set from prefix | 16:43 |
| morphis | seb128: for network-manager/modem-manager/bluez we're patching things to understand $SNAP for now | 16:43 |
| zyga | seb128: like /snap/self | 16:43 |
| didrocks | but setting prefix seems to change make install dest directory | 16:43 |
| morphis | seb128: but we're not putting those patches into any debian package | 16:43 |
| zyga | seb128: being always bind mounted to /snap/$SNAP_NAME/$SNAP_REVISION/ | 16:43 |
| morphis | seb128: see https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/ | 16:44 |
| kyrofa | didrocks, eh... let me clone this thing. Hold on | 16:44 |
| morphis | seb128: somewhat is this an interim solution | 16:44 |
| zyga | (or perhaps a symlink though that is harder) | 16:44 |
| morphis | zyga: yeah | 16:45 |
| morphis | seb128: and something like --prefix=/snap/galculator/current/usr didn't really worked for us | 16:46 |
| seb128 | zyga, yeah, I guess having a stable path would make things much easier | 16:46 |
| roadmr | jdstrand: hey, click-reviewer-tools r651 is finally out on the store. Apologies for the dlay | 16:46 |
| zyga | seb128: we should be able to at least prototype something like that next week but I cannot promise the design will be approved | 16:46 |
| morphis | as that will still end up as /snap/galculator/current/snap/galculator/current/usr | 16:46 |
| seb128 | morphis, you are getting n-m/bluez/etc upstream to take patches snap specific? | 16:46 |
| morphis | seb128: if you don't strip the prefix again | 16:46 |
| morphis | seb128: no | 16:46 |
| morphis | seb128: we will not bring those patches upstream | 16:47 |
| morphis | seb128: but longer term upstream needs to be relocatable at runtime | 16:47 |
| seb128 | right | 16:47 |
| zyga | patch glibc, qt, gtk and you'll see most people not noticing | 16:47 |
| zyga | (with a grain of salt) | 16:47 |
| zyga | people bundle gtk/qt on windows so it has to "work" | 16:48 |
| morphis | zyga: glibc/qt/gtk should be fine mostly | 16:48 |
| zyga | morphis: yeah? including things like locale and fonts? | 16:48 |
| morphis | seb128: and you can also write wrapper scripts like https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/bin/networkmanager to adjust things like HOME or LD_LIBRARY_PATH | 16:48 |
| morphis | zyga: that is why I said "mostly" :-) | 16:48 |
| kyrofa | didrocks, any chance you have your snapcraft recipe pushed somewhere? | 16:48 |
| seb128 | didrocks, hum, the --prefix= thing doesn't work because make install is going to install in that dir as well and you end up with having /snap/galculator/current/snap/galculator/current/usr as morphis said | 16:49 |
| zyga | morphis: one more thing, we're getting support for controling environment variables from interfaces | 16:49 |
| zyga | morphis: so we'll be able to pre-seed sensible variables for the most common stuff | 16:49 |
| zyga | morphis: and also use interfaces to influence that | 16:49 |
| morphis | zyga: sounds good | 16:49 |
| seb128 | morphis, right, that's we do, e.g http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc | 16:49 |
| zyga | (e.g. set something to see classic fonts when classic font interface is connected) | 16:49 |
| morphis | zyga: I have a feeling that we two should sync up somewhere soon on what is coming and planed etc. | 16:49 |
| morphis | feel like there are certain things we're really interested in | 16:49 |
| seb128 | morphis, that's quite hackish though, I doubt any upstream maintainer is going to find that being clean/something they can to do :p | 16:49 |
| didrocks | kyrofa: sure, it's at lp:~didrocks/+junk/galculator-snap. I did try then multiple combinations of prefix and destdir… | 16:50 |
| didrocks | seb128: exactly | 16:50 |
| morphis | seb128: I would simply ignore the "clean" part of this for now and get it working | 16:50 |
| morphis | seb128: I remember that loic started with binary search&replace on NetworkManager coming from a deb | 16:50 |
| seb128 | morphis, that's what we are doing, but are also asked to get upstream adoption, which is more difficult in that case | 16:51 |
| morphis | seb128: absolutely | 16:51 |
| didrocks | kyrofa: another way is to move the whole datadir directory after install, even setting an incorrect prefix | 16:51 |
| morphis | zyga: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 is something we should provide from snappy | 16:51 |
| kyrofa | didrocks, yeah, but then you're talking custom plugin or yucky makefile (I had to do that for apache) | 16:51 |
| didrocks | yep | 16:51 |
| didrocks | kyrofa: any better idea for now? :p | 16:52 |
| kyrofa | didrocks, experimenting, give me a minute | 16:52 |
| zyga | OMG :) | 16:52 |
| zyga | morphis: thanks! | 16:52 |
| morphis | jdstrand: you already had time to look on the nm interface? | 16:53 |
| zyga | morphis: https://bugs.launchpad.net/snapcraft/+bug/1583259 | 16:56 |
| ubottu | Launchpad bug 1583259 in Snappy Launcher "Snappy needs to influence environment variables in applications " [Undecided,New] | 16:56 |
| zyga | jdstrand: ^^ | 16:56 |
| zyga | tyhicks: (we talked about this at the sprint) ^^ | 16:56 |
| zyga | tyhicks: and gustavo wants it so I think we have agreement for the general direction | 16:56 |
| zyga | seb128: ^^ I'd love to know if you have suggestions on what some defaults might be when people connect the unity7 interface to make more things work out of the box | 16:56 |
| morphis | zyga: sounds good | 16:56 |
| morphis | zyga: couldn't we also add a set of env variables from the gadget snap? | 16:57 |
| zyga | morphis: that's somewhat more risky, can you give me a use case as a thought experiment? | 16:57 |
| morphis | zyga: like on Ubuntu Touch we're supplying different env variables directly from the device tarball to adjust runtime behaviour | 16:58 |
| zyga | morphis: remember nobody will review gadget snaps | 16:58 |
| zyga | morphis: that's a lot of power | 16:58 |
| morphis | zyga: like the device specific GU value | 16:58 |
| zyga | morphis: I see, that's an interesting case | 16:58 |
| morphis | zyga: why that? | 16:58 |
| zyga | morphis: is that something mir consumes or something that each snap needs to have set? | 16:59 |
| morphis | and we're adding more of them like to adjust the wifi management for different BSPs etc. | 16:59 |
| zyga | morphis: why nobody will review gadget snaps? | 16:59 |
| morphis | yes | 16:59 |
| zyga | morphis: because we want many people to make devices and reviews don't scale | 16:59 |
| morphis | same would apply for snaps, right? | 16:59 |
| zyga | morphis: so the only choice is to confine and limit gadget snaps and let us land them without review | 16:59 |
| zyga | morphis: yes but specifically the gadget snap has a very strong power over each device, we should not just let arbitrary things to go through it | 17:00 |
| zyga | morphis: perhaps a gadget snap could announce meta-data that each snap could see? | 17:00 |
| morphis | possible | 17:00 |
| zyga | morphis: and snaps could then opt-into loading some things (just a random idea) | 17:00 |
| morphis | yeah | 17:00 |
| morphis | off to the future | 17:01 |
| zyga | morphis: I see the need for this but I don't see a solution that's not a compromise over something | 17:01 |
| zyga | yep | 17:01 |
| morphis | zyga: most important thing for us will be udev rules supplied by either the gadget or kernel snap | 17:01 |
| zyga | morphis: can you open a bug on that and add some back story (enough for us to drive the design discussion) | 17:02 |
| zyga | morphis: I think this will be a gadget/kernel-snap (both perhaps) hardware-specific interface but I may be wrong | 17:02 |
| zyga | morphis: specifically if snaps have to specifically connect to it | 17:02 |
| zyga | morphis: and what exactly should be in those udev rules | 17:02 |
| morphis | zyga: sure, can open that tomorrow | 17:03 |
| zyga | morphis: thanks | 17:03 |
| === Aria22 is now known as Aria22|away | ||
| ssweeny | zyga, I'm trying to genericise the slotAppLabelExpr function and my go-fu is weak. Is there a way to make that function take either a slot or plug or do I need to make wrapper functions to call that logic? | 17:14 |
| jdstrand | morphis: been in meetings all morning (both on the schedule and impromptu). I'm done with those for the day so going to eat then look at all the PRs, starting with nm | 17:27 |
| morphis | jdstrand: great! | 17:27 |
| jdstrand | zyga: interesting. I'm going to point tyhicks at that too since he is looking at something related to env handling | 17:28 |
| oparoz | Will installing snaps on Ubuntu on Windows be supported? | 17:31 |
| ogra_ | heh | 17:32 |
| ogra_ | unlikely | 17:32 |
| oparoz | OK :) | 17:32 |
| ogra_ | unless windows grows some kernel fetures | 17:32 |
| ogra_ | *features | 17:32 |
| oparoz | Yeah, I was wondering what would be limiting the concept. Systemd might be another issue | 17:33 |
| ogra_ | systemd, apparmor, seccomp | 17:35 |
| kyrofa | oparoz, yeah basically our entire confinement story is missing there, I imagine | 17:35 |
| oparoz | That's a bit too much to make it work :) | 17:36 |
| zyga | ssweeny: no generics in go, you need to fork it | 17:38 |
| ssweeny | zyga, ack, thanks | 17:38 |
| zyga | ssweeny: you might be able to move the common part to a helper that just takes the raw data (apps AFAIR) | 17:38 |
| ssweeny | zyga, yeah that's what I was thinking. Just wanted to make sure I wasn't missing some idiomatic go thing that would be super easy :) | 17:38 |
| zyga | ssweeny: I'm still new to go but I'm pretty sure there's no generics around | 17:39 |
| ssweeny | zyga, apparently you can switch on type which is neat but I'd still have no idea how to pass the slot/plug in without them implementing the same interface at least | 17:40 |
| zyga | ssweeny: you cannot switch types, you can "upcast" interface{} to a real type but you cannot "cast it" to something totally different | 17:41 |
| ssweeny | zyga, I meant you can switch ON type like switch foo(type) case bool: <do stuff> case int: <do other stuff> | 17:42 |
| ssweeny | syntax is probably wrong but that's the idea | 17:42 |
| zyga | ssweeny: ah, yes you can do that | 17:42 |
| zyga | ssweeny: switch foo.(type) AFAIR | 17:43 |
| ssweeny | that's it | 17:43 |
| ssweeny | but still no way to say "this function takes a plug or a slot and I'll figure out which it is in the body" | 17:44 |
| ssweeny | I'll go ahead and factor the common stuff out | 17:44 |
| zyga | ssweeny: well you can have it take an interface{} | 17:45 |
| zyga | ssweeny: but that's not type safe then | 17:45 |
| ssweeny | right | 17:45 |
| zyga | ssweeny: I think that's the best we have for now | 17:45 |
| zyga | ssweeny: we toyed with an idea to have a private base class for plug and slot but that wouldn't help you much | 17:45 |
| ssweeny | zyga, I guess I could make an interface that covers the needed fields but by that point I've done more work than just factoring out the common code | 17:47 |
| tyhicks | zyga: fyi regarding the env var bug> mvo is having trouble with the "... and ubuntu-core-launcher (to actually apply those variables to each started process)" part | 17:48 |
| zyga | with the "..." and"? | 17:48 |
| zyga | well, I don't suppose we can assume the env is really inherited | 17:49 |
| tyhicks | zyga: some variables, such as LD_LIBRARY_PATH are being scrubbed when the launcher execs the app | 17:49 |
| zyga | because that doesn't work on all the variables | 17:49 |
| zyga | right | 17:49 |
| zyga | oh? | 17:49 |
| zyga | execs? | 17:49 |
| tyhicks | right | 17:49 |
| zyga | can we still set it after forking:? | 17:49 |
| zyga | (I assume we must) | 17:49 |
| zyga | both do it and must be really able to do it, otherwise shell would break too | 17:49 |
| tyhicks | some vars are scrubbed because the launcher is setuid root | 17:49 |
| zyga | right but I'm not talking about inheriting environment | 17:50 |
| tyhicks | but the launcher should, I think, be able to set those vars itself | 17:50 |
| zyga | just loading it from a file | 17:50 |
| zyga | exactly | 17:50 |
| tyhicks | right now, that's not working | 17:50 |
| tyhicks | I'm looking at it | 17:50 |
| tyhicks | zyga: I'll keep you updated when I make progress | 17:51 |
| oparoz | Is there a kernel for core which include grsecurity or do we have to compile one ourselves? | 18:10 |
| kyrofa | oparoz, you probably need to build that yourself | 18:16 |
| oparoz | Thanks kyrofa | 18:16 |
| jdstrand | morphis, zyga: I responded to the nm PR. I think it is fine pending a comment from zyga | 19:13 |
| jdstrand | morphis: note that I asked you something as well (but it isn't blocking) | 19:14 |
| jdstrand | plars: hey, how did you create the snap in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/9 ? | 20:38 |
| ubottu | Launchpad bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,New] | 20:38 |
| plars | jdstrand: with snapcraft, on a branch I have at https://github.com/plars/snappy-tests | 20:59 |
| jdstrand | ack, thanks | 21:00 |
| plars | jdstrand: if you want to build yourself, it may take running it a second time. For some reason it tries to build the go code rather than just the tests. I haven't sorted out why just yet, but rerunning snapcraft does it right if it hits an error the first time | 21:01 |
| plars | jdstrand: basically it's just a compiled version of the tests in the snappy source tree | 21:02 |
| jdstrand | ok | 21:08 |
| jdstrand | I'm having some issues with embedded paths that I think is a snapcraft python issue. I've seen the same thing with hello-unity for example | 21:09 |
| jdstrand | since I just want the tests to run, I figured if I recreate it locally I could run it locally | 21:10 |
| plars | jdstrand: I can try to rebuild the snap later too if you like - I'm just tied up trying to get some progress on another thing right now | 21:31 |
| jdstrand | plars: I have the snap. should snappy-tests -check.f homeInterfaceSuite be run under sudo? | 21:32 |
| jdstrand | plars: and that is /snap/bin/snappy-tests ? | 21:32 |
| jdstrand | doesn't look like it on either | 21:33 |
| plars | jdstrand: no, sudo shouldn't be required | 21:34 |
| jdstrand | plars: installed with --devmode? | 21:35 |
| plars | jdstrand: if there's still a problem, we may need to check with elopio and see if they are still having issues - yes, I did install with --devmode | 21:35 |
| plars | I think it should be require for those tests to have any chance at running | 21:35 |
| jdstrand | panic: runtime error: invalid memory address or nil pointer dereference | 21:37 |
| jdstrand | let me try one more time with your snap | 21:37 |
| jdstrand | plars: fyi https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/11 | 22:06 |
| ubottu | Launchpad bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,Incomplete] | 22:06 |
| jdstrand | plars: fyi I'm EOD now so feel free to comment in the bug | 22:08 |
| jdstrand | jjohansen: fyi, ^ | 22:08 |
| plars | jdstrand: will do, thanks for taking a look. Very possible that snappy and/or the tests have changed since then | 22:08 |
| plars | elopio: are you hitting errors like that with the tests now? ^ | 22:08 |
| jjohansen | plars: I am building a test kernel, with what I hope is the fix. Is a deb good enough for you to test or do you need it in a ppa? | 22:17 |
| jjohansen | plars: this is for bug 1579135 | 22:17 |
| ubottu | bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,Incomplete] https://launchpad.net/bugs/1579135 | 22:17 |
| plars | jjohansen: well it sounds like something is preventing reproduction of the bug. I would need to test it in snappy, so any chance I could get it as a kernel snap? | 22:18 |
| jjohansen | plars: uhmm, no :) | 22:18 |
| plars | jjohansen: but I'll need to try reproducing again first, and check with QA if they are seeing the new problem in their test runs or if it is something unique to running it this way | 22:18 |
| plars | jjohansen: heh, ok | 22:18 |
| jjohansen | I'll look into it, I've never done a kernel snap before | 22:18 |
| plars | jjohansen: me neither, I'm happy to try, just would need to do some rtfm | 22:19 |
| plars | jjohansen: in any case, no rush... I'm already going to be swamped for most of the night on other problems | 22:19 |
| jjohansen | right, let rephrase the kernel snap won't happen right away | 22:19 |
| jdstrand | jjohansen: you'll want to talk to ogasawara for a kernel snap-- I think she can point you to someone. I think there is tooling to convert a deb to a snap, but I might be making that up | 22:20 |
| jjohansen | jdstrand: ack thanks | 22:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!