| zyga | good morning | 06:27 |
|---|---|---|
| zyga | hey pedronis :) | 06:32 |
| pedronis | hi | 06:59 |
| mvo | hey pedronis | 07:02 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:07 |
| mvo | hey pstolowski | 07:09 |
| mup | PR snapd#7329 opened: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <https://github.com/snapcore/snapd/pull/7329> | 07:13 |
| pedronis | mvo: ^ pstolowski: ^ | 07:14 |
| pedronis | pstolowski: hi | 07:14 |
| mvo | pedronis: ta | 07:14 |
| pstolowski | ok | 07:15 |
| zyga | mvo: what about https://github.com/snapcore/snapd/pull/7321 | 07:19 |
| mup | PR #7321: tests: restore dpkg selections after upgrade-from-2.15 test <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7321> | 07:19 |
| zyga | I'm not sure how many reviews we need now | 07:19 |
| mup | PR snapd#7328 closed: tests: pass --remove to userdel on core <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7328> | 07:20 |
| mvo | zyga: its fine from my POV, its not perfect | 07:25 |
| zyga | mvo: yeah, I'd like to land it | 07:25 |
| mvo | I mean, you pointed out that the tool has flaws | 07:25 |
| mvo | but its fine IMO | 07:25 |
| zyga | mvo: yeah | 07:25 |
| zyga | mvo: do we need zero, one or two reviews on top of this state? | 07:25 |
| mvo | zyga: so far this has zero reviews… :( let me review it | 07:28 |
| mvo | zyga: having one review from !us would be nice I think | 07:28 |
| zyga | yeah, I feel the same way | 07:29 |
| zyga | it's unclear what the rules say when two people work on something and agree | 07:29 |
| mvo | zyga: lets not fuss too much, its a tiny PR and affects only tests. I'm sure if e.g. pstolowski can have a quick look it can land :) | 07:29 |
| zyga | +1 | 07:30 |
| pstolowski | seems i missed my 2 minute window to review this ;) | 07:32 |
| pstolowski | ah, it wasa about 7321, looking at it | 07:38 |
| zyga | brb | 07:44 |
| pstolowski | one comment there, +1 | 07:46 |
| zyga | re | 07:51 |
| zyga | pstolowski: replied | 07:51 |
| pedronis | mvo: I archive 2.40 and created the 2.42 lane, I also made cards for the UC20 things I'm working on | 07:52 |
| mup | PR snapd#7321 closed: tests: restore dpkg selections after upgrade-from-2.15 test <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7321> | 07:54 |
| mvo | pedronis: excellent, thank you | 07:58 |
| Chipaca | ullo ullo | 08:38 |
| Chipaca | i just popped in to make sure y'all were aware today's a bank holiday so that's why i'm not here | 08:39 |
| pstolowski | pedronis, zyga: when we optimize apparmor backend to load multiple profiles in one go we're going to loose the granularity of error handling we have now for the apparmor_parser invocation. at the moment regenerateAllSecurityProfiles just logs an error for a given snap and carries on with the rest (we can still have such per-snap policy for intermediate errors before aa parser is invoked). any toughts on that? | 08:39 |
| pstolowski | hey Chipaca | 08:39 |
| pstolowski | pedronis, zyga unless we run apparmor parser with --vebose flag and go into business of parsing it's output ('Replacement succeeded for "snap....' gets printed for every successfull profile) | 08:42 |
| abeato | mvo, morning! would it be possible to merge https://github.com/snapcore/snapd/pull/7252 now? Also, what about https://github.com/snapcore/snapd/pull/7173 ? Is retriggering the tests needed there? | 08:51 |
| mup | PR #7252: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7252> | 08:51 |
| mup | PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173> | 08:51 |
| mvo | abeato: in a meeting, will check in ~1h when they are over | 08:52 |
| abeato | mvo, ack, thanks | 08:52 |
| zyga | pstolowski: interesting | 08:55 |
| zyga | pstolowski: on failure, we can re-run per profile and see what really failed | 08:55 |
| pstolowski | zyga: yeah but we need to find out which one failed (for which snap), just log this snap and don't consider entire operation as failed | 08:58 |
| zyga | pstolowski: yeah but when the batch fails you can re-try non-batch to reliably get information about those that really failed | 09:02 |
| zyga | pstolowski: alternatively | 09:02 |
| zyga | pstolowski: we can batch only inside one snap | 09:02 |
| zyga | pstolowski: that's less generic but better in terms of our understanding what to do | 09:03 |
| zyga | pstolowski: because when things fail, we need to change at the snap-granularity anyway | 09:03 |
| pstolowski | zyga: we already pass all profiles of given snap to aa parser (if that's what you mean). but re-trying one-by-one is an interesting idea | 09:04 |
| zyga | pstolowski: if it's already per-snap then retrying is not of much use | 09:05 |
| zyga | pstolowski: because it partially failed anyway | 09:05 |
| zyga | pstolowski: another idea: do it in stages: first compile then load | 09:05 |
| zyga | pstolowski: if compilation failed nothing in the system is broken | 09:05 |
| zyga | pstolowski: it's easier to reason about the state | 09:05 |
| zyga | pstolowski: you can pass a flag to the parser to let it just compile all profiles | 09:06 |
| zyga | pstolowski: then you can pass a different flag to ask it to just load binary profiles | 09:06 |
| pstolowski | -d, --debug | 09:08 |
| pstolowski | Given once, only checks the profiles to ensure syntactic correctness. | 09:08 |
| pstolowski | zyga: ^ yeah, interesting | 09:08 |
| zyga | pstolowski: rather than debug I'd try something like --skip-kernel-load | 09:11 |
| pstolowski | zyga: aha! thanks | 09:11 |
| zyga | pstolowski: you can use other options to capture the compiled profile into memory | 09:11 |
| zyga | pstolowski: or to disk | 09:11 |
| niemeyer | Morning all | 09:26 |
| mvo | hey niemeyer ! welcome back | 09:30 |
| niemeyer | Thanks! Glad to be back | 09:30 |
| niemeyer | How're things going? | 09:30 |
| mup | PR snapd#7252 closed: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7252> | 09:38 |
| mvo | niemeyer: going well, thank you! | 09:40 |
| niemeyer | I see mup is still going strong | 09:40 |
| mvo | niemeyer: some annoying test hickups that we are fighting but its getting better | 09:41 |
| mvo | niemeyer: yeah, mup was doing great last week iirc | 09:41 |
| mvo | mup: hey, still fine? | 09:41 |
| mup | mvo: I apologize, but I'm pretty strict about only responding to known commands. | 09:41 |
| * mvo hugs mup | 09:41 | |
| niemeyer | Nice | 09:42 |
| zyga | mvo: found the bug :) | 10:33 |
| zyga | mvo: whee | 10:33 |
| zyga | core is good | 10:33 |
| mvo | zyga: tell me more! | 10:33 |
| zyga | mvo: the logic in reset_all_snap was silly wrong | 10:33 |
| zyga | I'll send a PR in a moment | 10:34 |
| mvo | zyga: ta | 10:34 |
| zyga | mvo: two bugs actually | 10:45 |
| zyga | in other news, shell is tricky | 10:45 |
| ogra | pfft | 10:52 |
| zyga | fired one more run to be sure, brb | 11:14 |
| zyga | mvo: tl;dr; grep -w is a deception | 11:14 |
| zyga | mvo: - is a word separator | 11:14 |
| zyga | mvo: dont-remove-this-snap-core18 matches against grep -w core18 | 11:14 |
| mvo | zyga: woah, nice find | 11:25 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/7330 | 11:32 |
| mup | PR #7330: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330> | 11:32 |
| mup | PR snapd#7330 opened: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330> | 11:32 |
| mup | PR snapd#7331 opened: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7331> | 11:38 |
| zyga | ohh, a new PR label | 11:40 |
| mup | PR snapd#7332 opened: tests: remove trailing spaces from shell scripts <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7332> | 11:40 |
| abeato | mvo, it looks like tests for https://github.com/snapcore/snapd/pull/7173 finally passed :) | 11:41 |
| mup | PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173> | 11:41 |
| zyga | I need to do some reviews while tests are churning | 11:41 |
| mup | PR snapd#7333 opened: tests: fix system version check on listing test for external backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7333> | 11:49 |
| zyga | wow, only one test not passing cleanly in main on core16! | 11:51 |
| zyga | and a simple one at that | 11:51 |
| zyga | unit test failure? | 12:15 |
| zyga | https://www.irccloud.com/pastebin/AQb5iDB8/ | 12:15 |
| zyga | and another one on snap_daemon user | 12:15 |
| zyga | https://www.irccloud.com/pastebin/5rYhzSZG/ | 12:15 |
| zyga | mvo: is that still expected?^ | 12:15 |
| zyga | or should I get more recent master | 12:15 |
| mup | PR snapd#7334 opened: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7334> | 12:32 |
| === ricab is now known as ricab|bbl | ||
| mvo | zyga: the daemon-user in tumbleweed? | 12:38 |
| zyga | mvo: that is 16.04 | 12:38 |
| zyga | mvo: not TW | 12:38 |
| zyga | mvo: group removal failed because there's a user using it as primary group | 12:38 |
| mvo | zyga: let me check | 12:39 |
| zyga | mvo: offtopic: core18 does not leak any more mount points as far as my tests are showing | 12:39 |
| zyga | mvo: I'm running a more complete pass but this is fantastic, it's not buggy anymore : | 12:39 |
| zyga | mvo: this means both core and classic are clean, only two PRs to review to get there | 12:40 |
| mvo | zyga: cool | 12:42 |
| mvo | zyga: where is the userdel failure? | 12:42 |
| mvo | zyga: I mean, what PR failed ? I want to check the log | 12:43 |
| zyga | mvo: I restarted it already | 12:43 |
| zyga | mvo: sorry, :/ | 12:43 |
| === pedronis_ is now known as pedronis | ||
| jamesh | and then the test suite will be 100% robust? :-) | 12:43 |
| zyga | jamesh: no :) | 12:45 |
| zyga | jamesh: but that aspect will | 12:45 |
| zyga | jamesh: so my test that measures it can be enabled again | 12:45 |
| zyga | jamesh: without acting like a mount leak detector | 12:46 |
| jamesh | zyga: fyi, I'm in Greece for GUADEC until Thursday (and then flying home until Friday evening). So I may be slow to respond to activity on my PRs | 12:47 |
| zyga | jamesh: enjoy Guadec, I'd love to visit Greece for one :) | 12:48 |
| zyga | I'm doing a pass over older PRs, including many that you sent, sorry for the enormous lag | 12:48 |
| jamesh | zyga: no problem. At some point I'd like to go over the work I need to complete for 20.04 | 12:49 |
| jamesh | dbus activation is still the big one (which hopefully is getting close to unblocked) | 12:50 |
| jamesh | there will probably be some xdg-desktop-portal related changes too though | 12:50 |
| zyga | jamesh: any interesting portal work that would be of interest for us to integrate with? | 12:50 |
| * zyga has some back pain today, should move to laptop | 12:50 | |
| jamesh | zyga: mostly things that were brainstormed almost a year ago | 12:51 |
| zyga | jamesh: as in, they are coming now? | 12:51 |
| zyga | after a year of being under development? | 12:51 |
| jamesh | I want to give xdg-desktop-portal more information about snaps, which will probably involve adding a hidden "snap" command that takes a pid for a confined app and spits out some machine readable data about the snap | 12:52 |
| jamesh | a year of having other priorities | 12:52 |
| zyga | jamesh: oh neat | 12:52 |
| zyga | jamesh: would it be like snap info --pid=123 | 12:52 |
| zyga | that then matches that pid to a snap and gives you that kind of information | 12:52 |
| zyga | jamesh: my question is mainly: do you need more than what snap info would say | 12:52 |
| jamesh | in particular, I want snap name, desktop file ID, possibly presence of network plug | 12:53 |
| jamesh | maybe some information about readable/writable paths | 12:53 |
| zyga | mmm | 12:53 |
| zyga | jamesh: what kind of writable paths do you mean? precise rules or something high-level? | 12:53 |
| jamesh | zyga: the main use would be to identify cases where files do not need to be proxied through xdg-document-portal | 12:54 |
| zyga | oh, I see | 12:54 |
| jamesh | so it's alright if it isn't complete | 12:54 |
| zyga | jamesh: would it be ok if it was just a query per path? | 12:54 |
| zyga | jamesh: snap internal is-accessible --pid=123 /path/to/file | 12:55 |
| jamesh | zyga: perhaps. I need to get up to speed with that code base again | 12:55 |
| zyga | ok | 12:55 |
| zyga | thanks for sharing, this is interesting | 12:55 |
| jdstrand | pstolowski: ime you don't want to run apparmor_parser so much on all profiles as much as run it only once at the end | 12:56 |
| jamesh | zyga: also: what is the best cross platform way to detect if a pid is a snap app? | 12:57 |
| jamesh | zyga: the current code is checking AppArmor labels, but that obviously doesn't work for the non AA distros | 12:57 |
| jdstrand | pstolowski: ie, snap.foo.bar has 3 interfaces. apparmor_parser it once after all 3 interfaces are connected instead of each time after one is connectedc | 12:57 |
| jamesh | the aim is to have something quick to check before shelling out to the "snap internal" command we eventually write | 12:57 |
| jdstrand | jamesh: the freezer cgroup atm | 12:58 |
| zyga | jamesh: that's a good question | 12:58 |
| zyga | jamesh: I'd like that to be an API of snapd, not something that is determined externally | 12:58 |
| zyga | jamesh: because e.g. the freezer or apparmor are internal implementation detail | 12:58 |
| zyga | jamesh: and that will change | 12:58 |
| zyga | jamesh: unless we can come up with a robust way to make that without making any problems | 12:58 |
| jamesh | zyga: the flatpak method is to check for a special file in the root directory of the process's mount namespace | 12:58 |
| zyga | jamesh: perhaps /proc/PID/root/meta/snap.yaml presence? | 12:58 |
| zyga | jamesh: that would be reliable today (except for classic snaps) | 12:59 |
| jdstrand | and yes, we should have an api | 12:59 |
| zyga | jdstrand: ^ I might even be happy with that being a stable way to check | 12:59 |
| zyga | regardless of an API | 12:59 |
| jamesh | zyga: treating classic snaps as unconfined is fine for the purposes of xdg-desktop-portal | 12:59 |
| jamesh | they effectively are anyway | 12:59 |
| pstolowski | jdstrand: right. this is kind of already done for auto-connect on install (landed recently, edge only atm) | 12:59 |
| jdstrand | pstolowski: the same goes for snap-seccomp | 13:00 |
| * zyga goes to a meeting | 13:00 | |
| jdstrand | pstolowski: oh! 'kind of'? | 13:00 |
| pstolowski | jdstrand: the case i'm trying to cover now is where we regenerate all profiles on startup when system key or templates changed | 13:00 |
| pstolowski | jdstrand: 'kind of' in a sense that it's only for auto-connect, not connect in general | 13:00 |
| jdstrand | pstolowski: but that includes auto-connect via snap decl too, right? | 13:01 |
| jdstrand | (it would be weird if it didn't, but thought I'd ask) | 13:01 |
| jdstrand | pstolowski: what about app snap refresh? | 13:02 |
| pstolowski | jdstrand: yes, precisely that - when you install a snap, and slots get automatically connected | 13:02 |
| jdstrand | pstolowski: is refresh a special case for install? | 13:02 |
| pstolowski | otp | 13:03 |
| jdstrand | pstolowski: feel free to ping me after | 13:03 |
| mup | PR snapd#7331 closed: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7331> | 13:07 |
| pstolowski | jdstrand: yes, refresh as well, it's special case for install indeed | 13:11 |
| pstolowski | jdstrand: but there is atm no improvement if you manually snap connect multiple plugs/slots in one go. this could benefit from similiar optimization (as you suggested; and similiar to auto-connect), the framework for that is already in place and we can tackle it at some point | 13:15 |
| jdstrand | pstolowski: oh, I didn't know you could do more than one in one go :) indeed, that could be done. I think the key is once per command, not per snap or per batch of snaps and then you get reasonable optimizing with good error reporting | 13:16 |
| jdstrand | pstolowski: doing more than one profile at a time only saves you a fork/exec/tiny overhead which is probably not worth losing the error handling | 13:17 |
| jdstrand | at least note atm | 13:17 |
| jdstrand | not* | 13:17 |
| jdstrand | pstolowski: and this was done for snap-seccomp too? | 13:17 |
| pstolowski | jdstrand: yes, this was done on higher level than specific backends, we basically run setup-profiles just once at the right moment | 13:19 |
| jdstrand | pstolowski: woo nice! :) | 13:19 |
| pstolowski | jdstrand: hmm re apparmor parser, my tests on pi3 suggest we will benefit a lot (3x faster) by running aa parser once over multiple snaps' profiles, did i miss something? see https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909 | 13:21 |
| pstolowski | (re error handling i'm sure we can overcome this, per zyga's suggestions) | 13:22 |
| jdstrand | pstolowski: so apparmor can do some parallelizing and things for sure... but it seems your --cache-loc is wrong | 13:23 |
| jdstrand | pstolowski: it should be /var/cache/apparmor, not /etc/apparmor.d/cache | 13:24 |
| jdstrand | the cache's should be invalidated | 13:24 |
| jdstrand | (though) | 13:24 |
| jamesh | jdstrand: I'll be talking to the freedesktop-sdk folk tomorrow. Is there anything newer than what you wrote at https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153/40?u=jamesh that I should be aware of? | 13:24 |
| jdstrand | jamesh: unfortunately not. since the work is unplanned, it is falling behind some other stuff that is planned | 13:25 |
| jamesh | fair enough | 13:25 |
| jdstrand | jamesh: but, there is a clear path forward | 13:26 |
| jdstrand | it's 'just work' | 13:26 |
| jamesh | getting to that point is half the battle :-) | 13:26 |
| jdstrand | (in terms of implementaion. there are a few process details to sort out, but that isn't a big deal) | 13:26 |
| jdstrand | jamesh: ha, yes :) | 13:26 |
| zyga | mvo: FYI https://github.com/snapcore/snapd/pull/7316#pullrequestreview-279586840 | 13:27 |
| mup | PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316> | 13:27 |
| * zyga goes to rest to avoid the back pain | 13:28 | |
| mvo | zyga: thanks, looking | 13:28 |
| mvo | zyga: nice, thank you! | 13:31 |
| jdstrand | pstolowski: your use of snap.* is not accounting for snap-update-ns.*, no? did you find those aren't getting regenerated with ifacemgr? | 13:32 |
| mup | PR snapd#7173 closed: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7173> | 13:32 |
| pstolowski | jdstrand: indeed, looks like i used the wrong cache path. anyway, that shouldn't matter for the test due to --skip-read-cache, as i was testing the pessimistic scenario only | 13:33 |
| pstolowski | jdstrand: and you're right i haven't tested snap-update-ns* profile (it is covered by snapd code, so code is fine) | 13:34 |
| jdstrand | I think what is happening here is with the single call you are benefiting from parallel processing | 13:35 |
| jdstrand | whereas otherwise it is completely serial | 13:35 |
| jdstrand | gimme a second and I can confirm that | 13:36 |
| mup | PR snapd#7330 closed: tests: fix removal of snaps on ubuntu-core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7330> | 13:36 |
| jdstrand | right, a pi3 has 4 cpus that can be used | 13:37 |
| jdstrand | and so apparmor will used -j4 | 13:37 |
| jdstrand | right, if I use --max-jobs=1 then I get roughly the same performance as serial | 13:39 |
| mup | PR snapcraft#2684 closed: meta: decouple DesktopFile logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2684> | 13:39 |
| jdstrand | 33s vs 35s on amd64 | 13:39 |
| pstolowski | jdstrand: ah, that means it would help on faster machines (originally the problem was reported with fast pc & lots of snaps https://forum.snapcraft.io/t/snapd-causing-lengthy-boot-time/10466), but not on low-end ones that some customers have... | 13:43 |
| jdstrand | pstolowski: I commented: https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909/2 | 13:44 |
| jdstrand | ps | 13:45 |
| pstolowski | jdstrand: thank you, that's useful feedback | 13:45 |
| jdstrand | pstolowski: let me dig up one more tidbit. I recall we had perf bugs in Ubuntu when we took all the CPUs and choked boot | 13:46 |
| zyga | mvo: another failure, daemon user present, test failed to add it | 13:46 |
| ogra | on actual single core HW you will also see I/O saturation that you wont if you use a multicore device and just limit cores | 13:47 |
| jdstrand | pstolowski: also, you may find this handy: getconf _NPROCESSORS_ONLN | 13:47 |
| ijohnson | jdstradn, pstolowski: fwiw the big problem I remember from a customer device about this is that it takes _ages_ on a low-end ARM CPU to finish the first boot because there's a lot of snaps and a lot of service/commands with a lot of plugs | 13:49 |
| mvo | zyga: yeah, I pushed a pr to get to the bottom of this | 13:49 |
| ijohnson | jdstrand: sorry ^ | 13:49 |
| mvo | zyga: its very strange | 13:49 |
| jdstrand | pstolowski: right, I remember now. we could make the parser even faster by using a -j value higher than _NPROCESSORS_ONLN, and that was the problem. In Ubuntu, we use _NPROCESSORS_ONLN. *maybe* you want to use _NPROCESSORS_ONLN-1? (you'd want to measure, etc) | 13:49 |
| ijohnson | note that device only has one CPU core | 13:50 |
| jdstrand | ijohnson: that is already going to be helped tremendously by what pstolowski already did. run the parser once per command rather than once per interface per command | 13:50 |
| pstolowski | jdstrand: interesting. we may try to be conservative and paranoid there to start with | 13:50 |
| ijohnson | right okay, I missed part of this conversation so I wasn't sure what was being discussed right now :-) I'm sure they will be happy to hear that | 13:51 |
| jdstrand | btw | 13:51 |
| * jdstrand hugs pstolowski :) | 13:51 | |
| jdstrand | pstolowski: ok cool. I forgot that the rpi3 had so many cores. parallelizing defintely helps with more cores :) | 13:52 |
| ogra | we should really measure on actual HW that was designed as single core though ... faking it like that will make you miss a lot of aspects | 13:54 |
| abeato | ijohnson, yes, I am happy to hear that :D | 13:55 |
| ogra | (though if the focus is really only on CPU processing thats probably okay ... but for overall performance mesuaring IO should also come into play) | 13:55 |
| pstolowski | jdstrand: thanks for looking at this! | 13:55 |
| jdstrand | ogra: well, note, on a single core it defaults to -j1. apparmor will use -jNUMBER OF CORES by default. My question is do we want to make that 'minus 1' or something | 13:57 |
| jdstrand | no one is suggesting a -j higher than the number of cores (I advocated agaisnt it :) | 13:57 |
| ogra | what would minus 1 achieve ? dynamic picking ? | 13:57 |
| jdstrand | no no | 13:57 |
| ogra | oh, you mean "one less" | 13:58 |
| jdstrand | I'm saying 1 core, -j1. 2 cores, -j1, 3 cores, -j2, etc | 13:58 |
| ogra | yeah | 13:58 |
| jdstrand | yes | 13:58 |
| ogra | got it, sorry, slow today | 13:58 |
| jdstrand | ie, leave at least one for other stuff | 13:58 |
| jdstrand | which is probably quite reasonable for a refresh core scenario | 13:59 |
| ogra | if we can we should surely do that since we might have something running in parallel (we have no real control about systemd here i guess) | 13:59 |
| jdstrand | but I'll let others decide | 13:59 |
| abeato | jdstrand, or maybe change the nice value for the process, as another option? | 14:00 |
| jdstrand | oh, we can do that. calculate the cores (see aforementioned getconf command), add --max-jobs | 14:00 |
| jdstrand | abeato: that is an available option as well | 14:00 |
| * zyga has lots of back pain and stops to do any reviews too | 14:08 | |
| zyga | sorry folks, need to break and get better somehow | 14:08 |
| * ijohnson relocates, back in ~15 min | 14:12 | |
| pedronis | mvo: I got this: https://api.travis-ci.org/v3/job/576683798/log.txt do I need to merge master again? | 14:12 |
| mup | PR snapd#7334 closed: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7334> | 14:13 |
| mvo | pedronis: no, this is still under investigation :( | 14:14 |
| mvo | pedronis: its strange, let me add some more debug | 14:14 |
| cachio | mvo, hey | 14:18 |
| mvo | hey cachio | 14:18 |
| cachio | mvo, taking a look to the error on core18 I see this | 14:18 |
| cachio | https://paste.ubuntu.com/p/9hzczyDQjf/ | 14:18 |
| cachio | 2.41. instead of 2.41~ | 14:18 |
| cachio | is it a bug? | 14:18 |
| cachio | or we will use dot | 14:19 |
| cachio | just to see if I need to change the script | 14:19 |
| mup | PR snapd#7336 opened: tests: add debug section to interfaces-contacts-service <Created by mvo5> <https://github.com/snapcore/snapd/pull/7336> | 14:19 |
| mvo | cachio: thats a bug | 14:19 |
| mvo | cachio: the edge is the correct version | 14:19 |
| mvo | cachio: its just the version number though that is wrong in beta, its the right snapd | 14:20 |
| mvo | cachio: with the next beta/candidate the version shoud be fine | 14:20 |
| cachio | mvo, perfect | 14:20 |
| cachio | thanks! | 14:20 |
| mvo | cachio: once you are happy with the beta I can push a new version. but we need to make sure of course that it includes all fixes you have for 2.41 | 14:21 |
| cachio | mvo, sure, I'll push a fix now | 14:22 |
| cachio | mvo, that + the fix for listing test should be enough | 14:22 |
| cachio | then I have another one but so far I cound't reproduce it | 14:22 |
| mvo | cachio: thanks, let me tag the listing one as 2.41 | 14:25 |
| mup | PR snapd#7332 closed: tests: remove trailing spaces from shell scripts <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7332> | 14:25 |
| zyga | Thank you mvo | 14:25 |
| mup | PR snapd#7337 opened: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337> | 14:31 |
| zyga | mvo: all stuff fails on travis | 14:39 |
| zyga | E: Failed to fetch http://apt.postgresql.org/pub/repos/apt/dists/xenial-pgdg/main/binary-i386/Packages Writing more data than expected (788347 > 787357) | 14:39 |
| zyga | 269 | 14:39 |
| mvo | zyga: yeah, I noticed - I don't think we can do much, this is in the travis setup itself | 14:39 |
| zyga | correct :/ | 14:39 |
| mvo | zyga: I wonder if #travis is a thing to report issues | 14:39 |
| mvo | zyga: but I guess nowdays #twitter is the thing :P | 14:40 |
| zyga | I'm sure they know | 14:40 |
| zyga | yeah | 14:40 |
| zyga | where the kids and crazy world leaders (or is that that same thing) are | 14:40 |
| zyga | mvo: random simple patch from my pile https://github.com/snapcore/snapd/pull/7338 | 14:40 |
| mup | PR #7338: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338> | 14:40 |
| mup | PR snapd#7338 opened: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338> | 14:40 |
| mup | PR snapd#7339 opened: tests: don't look for lxcfs in mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/7339> | 14:42 |
| zyga | mvo: cna we unblock https://github.com/snapcore/snapd/pull/7196 | 14:45 |
| mup | PR #7196: packaging: use passthrough for type:snapd <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196> | 14:45 |
| === ricab|bbl is now known as ricab | ||
| pstolowski | cachio: https://github.com/snapcore/snapd/pull/7110 is green and can land? | 15:32 |
| mup | PR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110> | 15:32 |
| zyga | pstolowski: please hold on | 15:36 |
| pstolowski | ok | 15:36 |
| mup | PR snapd#7340 opened: tests: adding support for arm devices on ubuntu-core-device-reg test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7340> | 15:36 |
| zyga | pstolowski: I asked two questions there | 15:37 |
| zyga | cachio: can you please check those out? | 15:37 |
| cachio | zyga, sure | 15:38 |
| zyga | Thanks | 15:38 |
| zyga | I'm mainly after avoiding network IO | 15:39 |
| cachio | pstolowski, yes | 15:39 |
| cachio | :) | 15:39 |
| cachio | pstolowski, first let me check the questions | 15:40 |
| cachio | zyga, answered | 15:45 |
| cachio | zyga, thanks for the review, I didn't know about those questions | 15:45 |
| zyga | cachio: no worries, I just asked them a moment ago | 15:46 |
| * cachio lunch | 15:49 | |
| zyga | cachio: replied again, sorry for being persistent about this | 15:49 |
| mvo | zyga: anything new in the twitter sphere about travis :) ? | 15:49 |
| zyga | mvo: sadly no | 15:50 |
| zyga | mvo: no status on travis website | 15:50 |
| zyga | as in, all is green there | 15:50 |
| mvo | booo | 15:51 |
| zyga | I'm still in bed so if I don't respond it's me trying to re-orient to get less painful layout | 15:51 |
| mvo | zyga: no worries, was just curious | 16:04 |
| zyga | oh, mvo is gone :) | 16:07 |
| zyga | https://paste.ubuntu.com/p/Pdx9qmqbdH/ | 16:07 |
| zyga | some unexpected stuff here | 16:07 |
| zyga | but I should break now | 16:07 |
| === pstolowski is now known as pstolowski|afk | ||
| cachio | zyga, ok, let me see how could be changed that | 16:22 |
| cachio | zyga, do you know which test is installing a local version of the snap? | 16:26 |
| cachio | I found some but in most of the cases we are building the snap as part of the test | 16:26 |
| zyga | cachio: I don't remember from the top of my head, I recall seeing some that were installing a snap over itself but it was from "snap pack" | 16:26 |
| zyga | yeah | 16:26 |
| cachio | zyga, what do you suggest in this case? | 16:29 |
| zyga | snap install /var/lib/snapd/snap/core_$rev.snap | 16:30 |
| cachio | zyga, ah, ok | 16:30 |
| zyga | rev is read from readlink /snap/core/current | 16:30 |
| cachio | I'll try that | 16:31 |
| * zyga eod | 16:38 | |
| cachio | zyga, updated | 16:42 |
| cachio | :) | 16:42 |
| mup | PR snapd#7341 opened: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341> | 17:32 |
| zyga | travis is back to normal | 17:51 |
| ardaguclu_ | Hi, there are some FIXME comments in various places, is it ok handling some of them. For instance, "// FIXME: this really should be TypeCore" in the types package | 17:56 |
| zyga | ardaguclu_: hey | 17:56 |
| zyga | ardaguclu_: yeah, though it's best to try asking first as some are harder or more tricky than others | 17:56 |
| zyga | ardaguclu_: but we 100% welcome all participation so please feel welcome :-) | 17:56 |
| ardaguclu_ | zyga: thanks | 17:59 |
| ardaguclu_ | creating unit tests and fixing bugs are the best ways to understand snapd codebase efficiently | 18:01 |
| ardaguclu_ | that's why, I am really happy working these stuff :) | 18:01 |
| zyga | There is always something to improve :-) | 18:02 |
| zyga | I’m working on making the integration test suite more robust | 18:02 |
| zyga | Mainly by writing tools that detect misbehavior and adjusting tests not to do bad stuff | 18:03 |
| ardaguclu_ | zyga: you are right, they are definitely not bad stuff. | 18:07 |
| arnatious | Hey all - I'm trying to run the code-insiders snap in an 18.04 lxd container and I'm just getting "dropping privs did not work" | 19:18 |
| arnatious | That look like a snap error or should I look elsewhere? | 19:19 |
| kyrofa | arnatious, it's definitely snap-related (comes from snap-confine if I remember correctly), just not sure what might be causing it. It's not a privileged container, is it? | 19:26 |
| arnatious | kyrofa nope | 19:27 |
| kyrofa | Hmm. zyga, any idea there? ^ | 19:27 |
| arnatious | It has nesting enabled, and is being run from `lxc shell --user 1000 --env SHELL=/bin/bash -- sh -c /bin/bash` | 19:28 |
| kyrofa | arnatious, nesting shouldn't need to be enabled | 19:31 |
| mup | PR snapd#7342 opened: fixme: rename ubuntu*architectures to dpkg*architectures <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7342> | 19:41 |
| mup | PR snapcraft#2686 opened: New app handler (command-chain and no wrappers if command allows for it) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2686> | 19:52 |
| mup | PR snapcraft#2679 closed: colcon plugin: add ability to ignore packages in workspace <Created by danielwangksu> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2679> | 19:58 |
| mup | PR snapcraft#2687 opened: colcon plugin: add ability to ignore packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2687> | 19:58 |
| mup | PR snapd#7343 opened: tests: moving tests to nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7343> | 21:50 |
| mup | PR snapcraft#2688 opened: Build base types <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2688> | 22:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!