| === devil is now known as Guest37061 | ||
| mup | PR snapd#4337 opened: cmd/snap: use snap-exec from core with a classic snap when reexecing <Created by mwhudson> <https://github.com/snapcore/snapd/pull/4337> | 00:11 |
|---|---|---|
| lundmar | definitely something is wrong with build.snapcraft.io - it's not building amd64 and i386 snaps. I can't even trigger them manually. | 00:30 |
| === ahayzen is now known as Guest18048 | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mborzecki | morning | 06:13 |
| ogra_ | [ 25.409984] cgroup: new mount options do not match the existing superblock, will be ignored | 06:20 |
| ogra_ | hmm .... why would anything expect a superblock there | 06:20 |
| mup | PR snapd#4321 closed: configstate: simplify ConfigManager <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4321> | 06:38 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR core#65 opened: xdg-settings: make the reply timeout for xdg-settings set 5min <Created by mvo5> <https://github.com/snapcore/core/pull/65> | 07:16 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | `man --what snap` shows 'nothing appropriate', but `man snap` shows the manpage | 07:29 |
| mborzecki | any ideas what might be causing this? | 07:29 |
| mvo | mborzecki: hm, that appears to be working here on ubuntu | 07:41 |
| mvo | mborzecki: I would assume some metadata in the man-page missing but that is of course not very helpful | 07:41 |
| mborzecki | mvo: something strange on Arch again, snapd package is installed first in project prepare and man-db is installed later in task prepare, that does not seem to run mandb to index the pages | 07:43 |
| mborzecki | i think that if if the order was reverse, package install hooks should retrigger indexing of new manpages, but for now there's a workaround at least | 07:43 |
| mborzecki | mvo: since you're available, can i ask you for a review of #4313? | 07:45 |
| mup | PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313> | 07:45 |
| mvo | mborzecki: aha, interessting | 07:47 |
| mvo | mborzecki: sure, I have a look | 07:48 |
| mvo | mborzecki: hm, one low hanging fruit might be to split out the (small) change to make the snapstate/corecfg code look at ParseLegacySchedule, that would (slightly) reduce the PR size and is probably trival to pull in | 07:51 |
| mborzecki | mvo: i'll try to pull it into a separate PR | 07:53 |
| mup | PR snapd#4338 opened: config, overlord/snapstate, timeutil: rename ParseSchedule to ParseLegacySchedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4338> | 08:14 |
| mborzecki | mvo: ^^ | 08:14 |
| mvo | mborzecki: thanks, I started with the other PR now as well | 08:17 |
| mborzecki | great, thanks :) | 08:17 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | so... I can repro the EOF thing | 09:24 |
| mvo | Chipaca: what EOF thing is that? | 09:42 |
| Chipaca | mvo: spread test dying with no failure message, debug and restore giving EOF (or "ssh: zlib failed to flush data" if you have a newer spread) | 09:44 |
| Chipaca | now going to try too repro in qemu, so i can get dmesg; i'm suspecting the whole thing is OOMing or getting killed by something | 09:53 |
| mvo | Chipaca: oh, maybe related to the compression changes? | 09:53 |
| mvo | Chipaca: aha, ok | 09:53 |
| Chipaca | mvo: no, the bare EOF is in a spread pre-compression | 09:53 |
| Chipaca | the message is different with compression, but it's the same issue: it dies with no apparent reason, and it stays dead (so you get no debug info) | 09:54 |
| Chipaca | ie instead of the useful logs from the debug step you just get EOF (or failed-to-flush from ssh/zlib) | 09:54 |
| mvo | Chipaca: aha, thanks | 09:56 |
| mvo | Chipaca: how did you manage to reproduce it? | 09:57 |
| Chipaca | mvo: spread -seed=1512088627 -shell linode:ubuntu-14.04-64:tests/main/{interfaces-browser-support,abort} | 09:58 |
| Chipaca | mvo: (with my users PR; haven't tried master) | 09:58 |
| Chipaca | bah, change -shell to -debug | 09:58 |
| Chipaca | (with -shell you need to do things by hand :-) ) | 09:58 |
| mvo | oh, nice | 10:00 |
| Chipaca | mvo: for Friday values of 'nice' | 10:15 |
| mvo | Chipaca: heh, well, reproducible++ :) | 10:18 |
| mup | PR core#65 closed: xdg-settings: make the reply timeout for xdg-settings set 5min <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/65> | 10:21 |
| === matteo` is now known as matteo | ||
| === chihchun is now known as chihchun_afk | ||
| Chipaca | in other news, I've been typing ‘M-x join-line’ for ages, when ‘M-^’ does basically the same thing /o\ | 10:23 |
| Chipaca | (M-^ is delete-indentation, not join-line, so you don't get the hint about using the key combo -- but join-line is an _alias_ of delete-indentation... //o\\) | 10:24 |
| mvo | Chipaca: heh, emacs is almost as good as nethack when it comes to text adventures | 10:32 |
| mup | PR snapd#4316 closed: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316> | 10:35 |
| === Guest18048 is now known as ahayzen | ||
| Chipaca | as feared, it looks like it's killed by confinement :-( | 10:45 |
| Chipaca | mvo: the new users thing tries to be smart by not even looking at non-people users for snap directories, where non-people are things below UID_MIN (from reading login.defs) and things with a shell not in /etc/shells | 10:49 |
| Chipaca | mvo: it also reads extrausers/passwd | 10:49 |
| Chipaca | these three things throw up denials -- and it looks like at some point it's all just killed outright (i don't get to see logs about that) | 10:50 |
| mvo | Chipaca: woah | 10:52 |
| Chipaca | mvo: I can drop the shells lookup and hardcode UID_MIN to 1000, and only look at extrausers in core, but it feels like a step back | 10:54 |
| ikey | Chipaca, if you're trying to determine human vs non human you might look at this for inspiration: https://github.com/solus-project/qol-assist/blob/master/src/user-manager.c | 11:03 |
| ikey | we had to solve the same thing in solus for qol-assist to reliably detect peoples | 11:03 |
| ikey | being human basically comes down to having a valid shell *and* meeting uid requirements | 11:04 |
| Chipaca | ikey: yes, that's what i implemented | 11:04 |
| ikey | and i got a cheap "grab all user shells" function here https://github.com/solus-project/qol-assist/blob/master/src/util.c#L31 to save keep calling the function | 11:05 |
| Chipaca | now i need to go scrub my eyes of Qs | 11:05 |
| ikey | heh | 11:05 |
| Chipaca | dude | 11:05 |
| Chipaca | the problem is that i get killed by seccomp (or sth) because of doing those checks | 11:05 |
| ikey | i get that - was merely trying to save you duplication of effort :p | 11:06 |
| ikey | no need to dude me :p | 11:06 |
| Chipaca | ikey: i appreciate that | 11:06 |
| * ikey gets back to fighting with appstream-builder | 11:07 | |
| ikey | aka worlds most inefficient tool | 11:07 |
| Chipaca | mvo: did you merge a pr bboozzoo asked not to be merged yet? | 11:08 |
| Chipaca | i mean #4316 | 11:08 |
| mup | PR #4316: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316> | 11:08 |
| Chipaca | ikey: where does QOL_MIN_UID come from in your code? | 11:09 |
| ikey | config.h | 11:09 |
| ikey | >_> | 11:09 |
| ikey | its a build time option | 11:09 |
| ikey | lol | 11:09 |
| ikey | technically to be more portable you'd want to consult shadow config | 11:10 |
| ikey | which is begging for issues | 11:10 |
| Chipaca | ikey: /etc/login.defs is what you want to consult for that one | 11:10 |
| ikey | swhat i said :p | 11:10 |
| Chipaca | mmkay | 11:10 |
| ikey | solus: Package shadow has file /etc/login.defs | 11:11 |
| pedronis | mvo: hi, if you have seen I have put more comments with issues in the default-provider PR, happy to chat again about it, better on Monday though I suppose | 11:14 |
| mborzecki | mvo Chipaca zyga's comment https://github.com/snapcore/snapd/pull/4316#pullrequestreview-79846561 was supposed to be fixed by this patch https://github.com/snapcore/snapd/pull/4316/commits/44cec064f04899d4821093b0c69459df5e331926 can you take a quit look at it? | 11:14 |
| mup | PR #4316: cmd/snap-mgmt: introduce snap-mgmt tool <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4316> | 11:14 |
| mborzecki | is there a checker that can do `c.Check(iface, Or(<another-checker>), alternative1, alternative2)` ? | 11:27 |
| pstolowski | mborzecki, I don't think so | 11:28 |
| mborzecki | i have an error message that depends on the order the elements are ranged over in a map, and it's different on each run ;? | 11:28 |
| cachio | mvo, beta validation almost completed | 11:28 |
| cachio | no regressions | 11:28 |
| cachio | results on here: https://docs.google.com/document/d/16sp6iXv9rqVsysjmAS9DxN7lfkoy-tKvJN2BpF3d4Wk/edit | 11:29 |
| pstolowski | mborzecki, in such cases we usually sort | 11:29 |
| pstolowski | mvo, ah, sorry, map. | 11:29 |
| pstolowski | mborzecki, ^ | 11:29 |
| pstolowski | mborzecki, DeepEquals should do it, no? | 11:30 |
| mborzecki | nope, it won't | 11:30 |
| mborzecki | what i'm doing is that once a snap yaml is parsed, i verify that the apps that have `start-before/start-after: list-of-apps` (new thing) are actually valid | 11:31 |
| mborzecki | so i need to range over the snap.Info.Apps, and it's a `map[string]*AppInfo`, so keys are in some random order | 11:32 |
| pstolowski | mborzecki, sort the keys first? | 11:33 |
| mvo | cachio: great, looking | 11:42 |
| mvo | Chipaca: if I did I'm sorry, I though all was addressed. maybe we need to use "blocker" more liberal if I prematurely merged | 11:42 |
| Chipaca | mvo: it's unclear to me :-) | 11:42 |
| mvo | pedronis: monday sounds good, I'm not sure I have the energy to dive into it | 11:43 |
| mvo | mborzecki: did I merge 4316 too early? | 11:43 |
| cachio | mvo, the core revert test cannot be executed until the user assertion is not updated | 11:43 |
| mborzecki | mvo: i fixed the problem that zyga raised in a patch listed ^^, i'd be gread if you could give it a 2nd look | 11:44 |
| cachio | mvo, it is also affecting some executions in spread-cron | 11:45 |
| cachio | mvo, I'll be 5 minutes late today | 11:45 |
| mborzecki | mvo: https://forum.snapcraft.io/t/snap-app-startup-ordering/3009 systemd After/Before we talked about yesterday | 11:47 |
| mvo | mborzecki: thanks for the form topic | 11:49 |
| mvo | cachio: late> no worries, I may be late myself (or miss it entirely :/) | 11:49 |
| mvo | niemeyer: I *may* miss the standup today, a repairman will come today and its not clear when exactly. I need to open him and explain what needs to be done etc so there is a chance I cannot make it | 11:50 |
| niemeyer | mvo: Heya, and ack, thanks for the note | 11:50 |
| mvo | niemeyer: thank you | 11:51 |
| niemeyer | mvo: Opening a repairman must take a while, so take your time :P | 11:51 |
| mvo | mborzecki: I think your changes in snap-mgmt look fine, | 11:51 |
| niemeyer | pedronis: Hey, btw, I suspect we talked across each other for a while yesterday | 11:52 |
| mvo | mborzecki: just in case, if things are not quite ready feel free to use the "blocked" label (or just close the PR) | 11:52 |
| mborzecki | mvo: noted | 11:53 |
| mvo | mborzecki: and no worries | 11:53 |
| niemeyer | mvo | 11:53 |
| niemeyer | mvo: I suspect pedronis was really talking about the check inside changeInProgress, rather than the test that for loop that verifies whether the current change has the link-snap | 11:54 |
| mvo | niemeyer: *nod* | 11:55 |
| mvo | niemeyer: yeah, he added some further comments to the PR, I will add more tests and rework the approach on monday | 11:56 |
| niemeyer | mvo: That test indeed seems unnecessary, I think, since the loop right above would have caught the same situation and skipped the rest altogether | 11:56 |
| mvo | niemeyer: right | 11:57 |
| mvo | niemeyer: I was thinking about creating something circular as a testcase just to be sure we handle this | 11:58 |
| niemeyer | mvo: You mean in this area, or in state specifically? | 12:00 |
| mvo | niemeyer: for this specific area | 12:00 |
| mvo | niemeyer: a circular content provider loop or something, I have not thought it through yet but the discussion from yesterday indicated it is probably a good idea to have a test for this | 12:01 |
| mup | PR snapd#4339 opened: userd: generalize dbusInterface <Created by mvo5> <https://github.com/snapcore/snapd/pull/4339> | 12:01 |
| niemeyer | mvo: Hmm | 12:02 |
| mvo | niemeyer: if you think its not needed/something different is needed, happy to do that instead | 12:03 |
| niemeyer | mvo: I'm trying to think whether the cost benefit would good in this case, or whether we should try to split it down into more fundamental properties of the system that would just mean we handle this correctly in the end | 12:05 |
| niemeyer | mvo: For the case we discussed yesterday, we might artificially produce a change set that has the to-be-included install before and the another one after the expansion task | 12:09 |
| niemeyer | s/and the another/and then another/ | 12:09 |
| pedronis | niemeyer: mvo: I don't think we can do something sane for the circurlar case until we split setting up repo/slots and plugs for snap, vs handling autoconnect, atm it's all in one task | 12:10 |
| pedronis | I imagine that pawel will need to change that though | 12:10 |
| * mvo needs to leave to get lunch, will be back in some minutes | 12:10 | |
| niemeyer | mvo: o/ | 12:10 |
| niemeyer | pedronis: I think we should just prevent the circular case from going through | 12:11 |
| niemeyer | pedronis: Other package managers show this is a huge can of worms | 12:11 |
| pedronis | niemeyer: it's just that we can only detect while doing, not upfront, unless we consult the store potentially various level deep at the beginning | 12:12 |
| niemeyer | pedronis: Well, we can simply not attempt to close the circle | 12:12 |
| niemeyer | pedronis: Again taking the view that those are not strictly pre-requisites | 12:12 |
| niemeyer | pedronis: In practice, if we find a snap to be installed that is already on the list, just don't order it further | 12:13 |
| niemeyer | pedronis: The base snap is the only real pre-requisite, and this one will have been inserted into the change upfront | 12:14 |
| niemeyer | pedronis: I mean, just don't order it further if it would establish a circle | 12:14 |
| pedronis | it will be fairly non-deterministic though, otoh it might be a corner case enough that we don't care | 12:15 |
| niemeyer | pedronis: Right, and also a "doctor it hurts" case | 12:16 |
| niemeyer | pedronis: The connection will simply be established later, and good interface hooks should tolerate that nevertheless | 12:17 |
| mup | PR snapd#4340 opened: snap: YAML and app validation parts of after/before app startup ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4340> | 12:25 |
| mup | PR snapd#4341 opened: tests: new test to validate location control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4341> | 13:30 |
| LyzardKing | Hi! I need help with the waf plugin. I need to build pycairo, and it comes with a waf installer. By default the installer uses python2...how can I run "python3 ./waf..."? | 13:53 |
| ikey | pycairo also has setup.py | 13:55 |
| ikey | so you can build it setuptools style | 13:55 |
| * ikey actually sees no waf in the pycairo tarball :/ | 13:55 | |
| ikey | LyzardKing, are you building from https://github.com/pygobject/pycairo/releases/ ? | 13:56 |
| LyzardKing | ikey: That version apparently does not have py3cairo, which is needed by pygobject | 14:03 |
| ikey | you build it with python3 | 14:03 |
| ikey | https://dev.solus-project.com/source/python3-cairo/browse/master/package.yml | 14:03 |
| ikey | idk what the new ones like :3 | 14:04 |
| ikey | (1.15) | 14:04 |
| ikey | i can python3 -c 'import cairo'.. | 14:04 |
| LyzardKing | I tried adding the tarball from github to the requirements.txt, but that didn't work... | 14:05 |
| LyzardKing | the setup for pygobject can't find py3cairo, (even though pycairo is indeed installed from the github tarfile) | 14:06 |
| LyzardKing | configure: error: Package requirements (py3cairo >= 1.11.1) were not met: No package 'py3cairo' found | 14:08 |
| ikey | o_O | 14:09 |
| ikey | thats pkgconfig level stuff | 14:09 |
| ikey | i.e. python3-cairo-dev or whatever the subpackage would be called.. | 14:10 |
| LyzardKing | ...If I install that as a build-dependency, I then have the issue that the version in the repo is 1.10.0, and the first version with pip is later (1.11.1?) | 14:14 |
| LyzardKing | And I can't use the version from the repo because in a classic snap it will segfault... | 14:15 |
| jdstrand | mvo: hi! I wanted to confirm something. is the os snap supposed to ship device files in /dev? | 14:20 |
| mvo | jdstrand: no, that is a bug AFAICT | 14:20 |
| jdstrand | mvo: related, are base snaps not supposed to ship device files in /dev? | 14:20 |
| jdstrand | it seems for sure base snaps should not | 14:20 |
| jdstrand | but it wasn't clear to me about the os snap | 14:21 |
| jdstrand | mvo: would you agree with my assessment re base snaps? | 14:21 |
| mvo | jdstrand: I think we don't need /dev files, do we have those currently? | 14:22 |
| jdstrand | mvo: base-18 did and I mentioned they should be removed (I don't know how we would even override devices via a base snap. that seems really wonky...) | 14:23 |
| jdstrand | mvo: let me double check core | 14:23 |
| mvo | jdstrand: yeah, base-18 is just a bug | 14:23 |
| mvo | jdstrand: I'm not 100% certain about core itself, but probably the same, I don't think we need them | 14:24 |
| jdstrand | mvo: core ships them: unsquashfs -lls /var/lib/snapd/snaps/core_3604.snap | grep 'squashfs-root/dev/' | 14:25 |
| pedronis | mvo: how does that work on core? | 14:26 |
| jdstrand | mvo: it would be ideal if we could say 'no device files allowed in snaps'. right now I whitelist for os snaps and mistakenly for base snaps | 14:26 |
| * jdstrand will fix test for base snaps | 14:26 | |
| pedronis | mvo: where does /dev come from on a core device? | 14:27 |
| jdstrand | mvo: I suspect you may be right that those devices files in core are not needed, but I'm not sure how the early boot code works (ie, pedronis question) | 14:28 |
| pedronis | jdstrand: we plan at some point to have bootable bases so that question will apply to them | 14:29 |
| pedronis | as well | 14:29 |
| * jdstrand raises eyebrows at boot base | 14:30 | |
| jdstrand | how is that now an os snap? | 14:30 |
| jdstrand | s/now/not/ | 14:30 |
| mvo | pedronis: initramfs iirc, but I need to double check | 14:30 |
| pedronis | jdstrand: that might be how to do it, but at some point the plan was not to have os snaps anymore, just bases and a some kind of snap carrying snapd | 14:31 |
| pedronis | as I said this is is not an immediate concern | 14:31 |
| mvo | jdstrand: yeah, what pedronis said, the idea was to phase out "os" snap and use "base" snaps and a "snapd" snap and core snap only for compatiblity with classic snaps | 14:31 |
| mvo | jdstrand: but we are some days behind this | 14:32 |
| jdstrand | pedronis: I thought the plan was strip down the os snap to what is needed for snapd to run/etc and everything else in a base snap. | 14:32 |
| jdstrand | oh, this is news to me | 14:32 |
| mvo | jdstrand: we cannot easily do that with core at least, we might introduce new os snaps though | 14:32 |
| jdstrand | I thought os was going to still be a thing, just alot smaller | 14:32 |
| mvo | jdstrand: yeah, its all a bit in the air still, we have some options | 14:32 |
| jdstrand | how in the world are you going to resolve things like multiple systemds? | 14:33 |
| mvo | jdstrand: the trouble is that we cannot change core, it is used for classic snaps because snapcraft may link to things in /snap/core/current | 14:33 |
| pedronis | jdstrand: there's is only one bootable base per device | 14:33 |
| pedronis | but yes, we do have a question about where do services come from | 14:33 |
| jdstrand | well, 'bootable base' is then effectively 'os snap minus snapd' | 14:34 |
| pedronis | jdstrand: to be clear this is all for core dvices | 14:34 |
| pedronis | it's not a concept relevant on classic | 14:34 |
| jdstrand | anyway, I don't mean to distract | 14:34 |
| pedronis | jdstrand: that part is not clear, some discussion mentioned that systemd would be in the snapd snap | 14:35 |
| pedronis | lots of questions and options | 14:35 |
| jdstrand | heh, well, that ends up looking a lot like an os snap after you add its deps, etc | 14:35 |
| jdstrand | anyway | 14:35 |
| jdstrand | mvo: so, device files cause problems with the review tools | 14:36 |
| mvo | jdstrand: yeah, it will be conceptually similar | 14:36 |
| mvo | jdstrand: cause problems for the os snap as well? | 14:36 |
| mvo | jdstrand: or just for the base snaps? | 14:36 |
| jdstrand | mvo: cause if they are in the snap, you can't mknod them unless you are root | 14:36 |
| pedronis | anyway whatever we do bootable bases will have more constraints and rules than generic bases | 14:36 |
| jdstrand | mvo: conceptually they are problematic | 14:36 |
| mvo | jdstrand: its ok to have them blacklisted for now, we may need them for bootable bases, otoh I think we can probably get away with the right initramfs magic | 14:37 |
| jdstrand | mvo: the kernel requires root to mknod. unsquash as non-root just creates regular files, so a resquash fails. as root is possible, but really need the tools confined (eg, as a snap) and that causes issues with the security policy | 14:37 |
| mvo | jdstrand: aha, I see. does fakeroot helps? | 14:39 |
| jdstrand | today base and os snaps are all manual reviewed anyway, so we skip the test, but if the device files aren't meant to be there at all, it would mean we don't have to do anything special in the tools | 14:39 |
| jdstrand | mvo: nope | 14:39 |
| jdstrand | the kernel requires root | 14:39 |
| jdstrand | fakeroot just gives you regular files | 14:39 |
| mvo | jdstrand: even inside the fakeroot env? | 14:40 |
| mvo | jdstrand: I though as long as you are inside the fakeroot session you see them as device files (because of the preload magic), no? | 14:40 |
| jdstrand | that's right, unsquash as non-root skips them, unsquash with fakeroot creates regular files, unsquash as root works but need lots of extra security permissions | 14:40 |
| jdstrand | mvo: let me try that. I just did fakeroot unsquash then looked | 14:41 |
| mvo | jdstrand: I think that should work | 14:42 |
| mvo | jdstrand: anyway, we will know soon :) | 14:42 |
| mvo | jdstrand: the key is that have the same FAKDEROOTKEY environemnt | 14:42 |
| LyzardKing | ikey: Is it possible to satisfy the python-cairo-dev dependency from pip? | 14:44 |
| jdstrand | mvo: that seems to work. | 14:45 |
| jdstrand | mvo: thanks! | 14:45 |
| mvo | jdstrand: yay, great | 14:46 |
| Chipaca | jdstrand: in 14.04, should seccomp be logging when it kills things? | 14:59 |
| Chipaca | jdstrand: i'm trying to debug a thing where a whole process group is killed, in 14.04 only, but not getting anywhere | 15:01 |
| Chipaca | jdstrand: (the reason it's hard to debug is that it's in spread, and the process group includes everything that spread has a hand in afaict) | 15:04 |
| jdstrand | Chipaca: it should, yes. do sudo sysctl -w kernel.printk_ratelimit=0 and watch /var/log/syslog or dmesg (not journalctl) | 15:12 |
| mup | PR snapd#4342 opened: userd: add support for a simple UI that can be used from userd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4342> | 15:15 |
| Chipaca | jdstrand: all that appears in syslog is apparmor denials :-( | 15:25 |
| Chipaca | http://pastebin.ubuntu.com/26089734/ | 15:25 |
| jdstrand | Chipaca: is it getting killed or just dying on its own cause it doesn't have what it needs? (that is very common) | 15:35 |
| Chipaca | jdstrand: the thing trying to run dies, but the bash running it dies also, the su running that bash dies, and the bash running that su dies | 15:36 |
| Chipaca | jdstrand: (so the 'debug' phase of spread gets EOF) | 15:37 |
| Chipaca | jdstrand: and the restore phase also EOFs | 15:38 |
| Chipaca | ie the ssh client connection from spread dies | 15:38 |
| jdstrand | that's a massacre | 15:38 |
| Chipaca | it's like oprah, but with kill | 15:38 |
| jdstrand | the bash running the thing shouldn't die unless it is using 'exec thing' | 15:39 |
| Chipaca | jdstrand: now, there's a bug i need to fix, but this cascade of death seems to be indicating a deeper concern, which is why i'm still digging | 15:40 |
| jdstrand | I mean, if you are using su -c 'bash -c foo' | 15:40 |
| jdstrand | then I would expect foo, bash and su to all exit | 15:40 |
| jdstrand | but that upper bash is presumably the spread debug which shouldn't die since it is interactive | 15:41 |
| jdstrand | anyhoo, good luck :) | 15:42 |
| Chipaca | :-) | 15:42 |
| Chipaca | thanks | 15:42 |
| Chipaca | jdstrand: I can hand it over to you if you feel like bashing your head on something soft | 15:42 |
| jdstrand | hehe | 15:42 |
| jdstrand | I'm good :) | 15:42 |
| * Chipaca is very generous | 15:42 | |
| ikey | jdstrand, quick q - when i do a build of the snaps later will those dudes need manual review or is that tooling active now? | 15:47 |
| ikey | gonna update the base images once the solus repos sync today | 15:47 |
| mup | PR snapd#4331 closed: systemd: add support for the mask/unmask operations <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4331> | 15:49 |
| mup | PR snapd#4332 closed: corecfg: also "mask" services when disabling them <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4332> | 15:49 |
| sergiusens | kyrofa get ready for a tough review :-) | 16:00 |
| kyrofa | sergiusens, okay | 16:07 |
| jdstrand | ikey: it is live now (as of today) | 16:22 |
| ikey | ah thanks bud :D | 16:22 |
| ikey | no promises i can get it done today but i thought id ask you before we all EOW | 16:22 |
| kyrofa | sergiusens, snapcraft#1779 is green, when you have some time to take a look | 16:24 |
| mup | PR snapcraft#1779: catkin-tools plugin: use stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1779> | 16:24 |
| sergiusens | kyrofa sounds good, I'll do it after lunch | 16:25 |
| sergiusens | btw, the fact that we have $(root)/snapcraft/tests and not $(root)/tests is really starting to annoy me | 16:25 |
| mup | PR snapcraft#1781 opened: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781> | 16:26 |
| sergiusens | kyrofa snapcraft#1781 | 16:26 |
| mup | PR snapcraft#1781: many: set rpath for elf files for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1781> | 16:26 |
| mup | PR snapd#4343 opened: interfaces: rename sanitize methods <Created by stolowski> <https://github.com/snapcore/snapd/pull/4343> | 16:55 |
| cachio | mvo, there? | 16:59 |
| cachio | mvo, I am working with the test that check interfaces after reboot | 16:59 |
| cachio | mvo, what I see is that after reboot the directory /snap/core/current is empty | 17:00 |
| cachio | and /snap/core/3615/ also empty | 17:00 |
| cachio | mvo, at the begining of the test it is not empty | 17:01 |
| kyrofa | jdstrand, any ideas on this issue? https://askubuntu.com/questions/978639/mount-error-when-installed-using-snap/981802 | 17:02 |
| cachio | mvo, I see this in a linove vm | 17:03 |
| cachio | do you want ips? | 17:03 |
| mvo | hey cachio | 17:06 |
| mvo | cachio: yeah, if you /msg it to me, that would be cool | 17:06 |
| mvo | cachio: I can poke around a bit | 17:06 |
| mvo | we need to think how we can tame the tests again :/ master is timing out a lot right now (runtime more than 49min) | 17:17 |
| mup | PR snapcraft#1778 closed: Add sentences to error when registering name <Created by daniellim2000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1778> | 17:29 |
| jdstrand | kyrofa: otoh, no | 17:54 |
| jdstrand | kyrofa: maybe /home is a separate partition? | 17:54 |
| sergiusens | kyrofa did you have a chance to check the PR? I am EODing in an hour or so | 19:47 |
| kyrofa | sergiusens, not yet, just about done here, then I can | 19:47 |
| mup | PR snapcraft#1782 opened: project_loader: support grammar on architectures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1782> | 20:15 |
| mup | PR snapcraft#1761 closed: lxd: ContainerConnectionError on failed launch/ start <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1761> | 20:27 |
| mup | PR snapcraft#1783 opened: tests: run codespell as part of static tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1783> | 21:06 |
| === edk is now known as demiurge | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!