| mup | PR snapcraft#1524 opened: Yarn lock record <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1524> | 03:54 |
|---|---|---|
| zyga-ubuntu | good morning | 06:28 |
| zyga-ubuntu | mvo: my network is better than ever, I've reinstalled xenial | 06:29 |
| zyga-ubuntu | mvo: if you want to have that call I'm available and eager to test | 06:29 |
| mvo | zyga-ubuntu: hey, good morning - please check the latest bits I wrote in 3625, I'm available in some minutes (just want to finish two small review feedback tasks) | 06:33 |
| zyga-ubuntu | mvo: great, I'll read your feedback and grab a coffee, let's chat soon | 06:35 |
| zyga-ubuntu | mwhudson: hello, I made git happy, shall I dput or do you want to do that yourself? | 07:10 |
| zyga-ubuntu | mvo: let me take your branch and look at some possiblity to make it more uniform, I won't push to your PR but will have something as a base for discussion, ok? | 07:20 |
| * zyga-ubuntu is still sleepy, needs to transition to waking up at 6AM | 07:20 | |
| mvo | zyga-ubuntu: sure | 07:21 |
| greyback | ogra_: hey, I'm having trouble bringing up Mir on the edge/daily RPi3 image (and I tried your images too, no diff). I'm suspect https://pastebin.ubuntu.com/25443549/ Is this a known issue? | 08:10 |
| mvo | pedronis: this might be interessting for you: httputil/logger.go:108: assignment copies lock value to transport: net/http.Transport contains sync.Mutex (from go vet 1.7) | 08:10 |
| pedronis | mvo: that is annoying, the rule is A Mutex must not be copied after first use, I think the current code isn't quite right, even reasonably code will not make vet happy there :/ | 08:21 |
| pedronis | though | 08:21 |
| pedronis | mvo: more correct code would be like this: https://pastebin.canonical.com/197306/ don't think it make vet happier though | 08:24 |
| mvo | pedronis: yeah, I think there is a open bug about that vet is not smart about this :/ | 08:27 |
| mvo | pedronis: the alternative of creating a transport with the same values as default trnasport is very much not DRY, so maybe best to ignore/silence this vet message | 08:28 |
| pedronis | that's what I had the problem is that the exact params change between 1.6, 1.7, 1.8 | 08:29 |
| pedronis | so params are new in each | 08:29 |
| pedronis | so we would need multiple versions of that code | 08:29 |
| pedronis | mvo: I don't think there's a way to supress single warnings | 08:34 |
| pedronis | unless we do it from the outside? | 08:34 |
| pedronis | mvo: what's your thinking? | 08:38 |
| mvo | pedronis: yeah, I was thinking to grep -v on the outside | 08:41 |
| mvo | zyga-ubuntu: ready when you are, sorry that things took a bit longer | 08:41 |
| pedronis | mvo: this is how they look in the versions btw: http://pastebin.ubuntu.com/25443642/ | 08:42 |
| mvo | pedronis: meh, really annoying | 08:42 |
| pedronis | mvo: we can probably get away with 2 version 1.6 and 1.7+ at least for a bit | 08:52 |
| ogra_ | greyback, that output looks normal to me (these bind errors have always been there IIRC) | 08:57 |
| greyback | ogra_: ok. I'll try to figure out why Mir is sad then. | 08:58 |
| ogra_ | i guess /dev/dri/card0 exists ? | 08:58 |
| greyback | ogra_: yep | 08:58 |
| ogra_ | then he device should technically be initialized properly ... | 08:58 |
| ogra_ | there was a change regarding famebuffer handling in the kernel though | 08:59 |
| greyback | ogra_: is it a custom kernel? | 08:59 |
| ogra_ | it is based on our 4.4 tree i think with broadcom patches on top ... you have to ask ppisati for more details ... mir worked fine in the past though ... | 09:00 |
| ogra_ | the framebuffer thing is https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1708417 | 09:00 |
| mup | Bug #1708417: Board hangs with 'dtoverlay=vc4-kms-v3d' while writing to /dev/fb0 <patch> <verification-done-xenial> <linux-raspi2 (Ubuntu):New> <linux-raspi2 (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1708417> | 09:00 |
| ogra_ | (the patch is attached there) | 09:01 |
| ogra_ | not sure if that can have any impact on mir | 09:01 |
| ogra_ | greyback, also ... remembering the forum...did you try a reboot ? :) | 09:02 |
| greyback | ogra_: yep :) | 09:02 |
| greyback | ok, well I know where to start, thanks | 09:03 |
| ogra_ | greyback, FYI i just installed mir-libs and mir-kiosk from edge and have a mouse cursor now on a pi2 | 09:08 |
| greyback | ogra_: ack, thanks for that. I didn't think pi3 was that different... | 09:08 |
| ogra_ | the kernel and rootfs are identical ... the bootloader setup differs slightly | 09:09 |
| ogra_ | (bootloader binaries should also be identical nowadays, it is really only config diffs in the gadget) | 09:10 |
| pedronis | mvo: I'll propose something using the 2 versions | 09:11 |
| mvo | pedronis: thanks a lot, i have a look | 09:12 |
| ogra_ | pedronis, hmm, could your recent changes to serial handling have introduced a race ? i just had the second installl in a week where installing my first snap on a device ended up in installing core first ... (which indicates that firstboot or key setup failed) | 09:26 |
| pedronis | ogra_: that sounds more like a firstboot issue | 09:28 |
| ogra_ | k | 09:28 |
| pedronis | serial doesn't play a role there | 09:28 |
| pedronis | I mean you have no core | 09:28 |
| ogra_ | sadly the card is already messed up and i'm re-flashing | 09:28 |
| pedronis | serial starts after seeeding | 09:28 |
| ogra_ | but i guess that will happen again | 09:28 |
| pedronis | I'm sure there's an issue, don't think it's related to serial | 09:29 |
| ogra_ | well, the images were pretty reliable until recently so it is definitely a recent change, serial just came to my mind as first thing here :) | 09:29 |
| pedronis | those changes should not have modified behavior on core | 09:30 |
| pedronis | also as I said they trigger after seed is set | 09:30 |
| pedronis | we need a log | 09:31 |
| ogra_ | ogra@localhost:~$ snap changes | 09:32 |
| ogra_ | error: no changes found | 09:32 |
| ogra_ | ogra@localhost:~$ snap list | 09:32 |
| ogra_ | No snaps are installed yet. Try "snap install hello-world". | 09:32 |
| ogra_ | ogra@localhost:~$ | 09:32 |
| ogra_ | ok ... seems reliably broken | 09:32 |
| pedronis | that seems very broken | 09:32 |
| pedronis | there not even a try to seed | 09:33 |
| ogra_ | pedronis, http://paste.ubuntu.com/25443792/ looks relevant | 09:34 |
| ogra_ | pedronis, note that i have only seen it on wlan-only boards ... which come up without any networking (because WPA isnt set up indeed) | 09:35 |
| pedronis | you r image as a strange time: 2016/02/11 16:28:15.328983 | 09:35 |
| ogra_ | hmm, true | 09:35 |
| pedronis | that's the problem | 09:35 |
| ogra_ | damn | 09:35 |
| cjwatson | upgrading launchpad-buildd to 148; please let me know if you see new oddities with snap building on LP | 09:36 |
| cjwatson | (yes, I'll announce it on the forum once it's done) | 09:36 |
| ogra_ | pedronis, thanks, i know wheer to look then | 09:36 |
| pedronis | yea, something with the rtc fixing code or the filesystem times | 09:37 |
| ogra_ | right and i just merged abeato's initrd changes at the start of the week | 09:37 |
| ogra_ | i guess something broke there | 09:37 |
| * zyga-ubuntu has fun with system | 09:39 | |
| zyga-ubuntu | "fun" | 09:39 |
| ogra_ | argh ... no, even worse ... | 09:39 |
| ogra_ | xenail had a new initramfs-tools superseding ours in the PPA | 09:39 |
| abeato | ogra_, pedronis, that seems like systemd built date when date is seen by it as older than that | 09:39 |
| abeato | (systemd changes the date in that case) | 09:40 |
| ogra_ | abeato, yeah, sorry, not your fault ... | 09:40 |
| abeato | not yet probably ;) | 09:40 |
| ogra_ | theer were other initrd fixes that the upload to xenial-proposed did override | 09:40 |
| ogra_ | in initramfs-tools itself | 09:40 |
| Chipaca | hmm | 09:40 |
| Chipaca | pedronis, mvo, why is it called “snap-repair.service” and not “snapd-repair.service”? | 09:41 |
| ogra_ | because it repairs snaps ? | 09:41 |
| ogra_ | or does it repair snapd ? | 09:41 |
| Chipaca | snap- is what we use for units associated with a snap | 09:42 |
| mup | PR snapd#3836 opened: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <https://github.com/snapcore/snapd/pull/3836> | 09:42 |
| Chipaca | snapd. is what we're using for units associated with snapd itself | 09:42 |
| Chipaca | so it should probably snapd.repair.service | 09:42 |
| pedronis | Chipaca: I don't know, that's a mvo question | 09:42 |
| pedronis | mvo: #3836 | 09:43 |
| mup | PR #3836: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <https://github.com/snapcore/snapd/pull/3836> | 09:43 |
| mvo | Chipaca: the tool is called snap-repair, we could rename it I guess | 09:43 |
| pedronis | but all our tools are snap- | 09:43 |
| ogra_ | ppisati, we have a problem ... fixrtc in the generic initrd is broken, i need to re-upload the fix and re-spin core and then we would need a no-change rebuild of the kernel snaps (for all devices without rtc battery at least) | 09:44 |
| pedronis | Chipaca, mvo: we risk a clash there right? | 09:45 |
| Chipaca | mvo: tbh it's probably not a huge deal, we already have snap.mount.service which breaks the pattern | 09:45 |
| pedronis | ah, no, because revision | 09:46 |
| Chipaca | mvo: and for this, snap.mount.service needs special treatment -- so i need to do the same for the other i think? maybe | 09:46 |
| mvo | Chipaca: yeah, its slightly inconsistent but we can fix it still, so maybe we should and rename it if its the only one that sticks out | 09:46 |
| ppisati | ogra_: ok | 09:47 |
| ogra_ | missing this fix http://paste.ubuntu.com/23175211/ | 09:47 |
| ogra_ | (i really need to SRU this so such issues cant happen anymore :/ ) | 09:47 |
| mvo | Chipaca: I guess we go all the way and rename snap-repair to snapd-repair as well? | 09:48 |
| ppisati | ogra_: i've been testing 4.13 with ubuntu core, and the serial console is completely trashed | 09:48 |
| ogra_ | ppisati, on what devices ? | 09:49 |
| ppisati | ogra_: the funny thing is that, the same exact kernel works fine in ubuntu classic | 09:49 |
| ppisati | ogra_: raspi3 | 09:49 |
| ogra_ | ppisati, differences in config.txt ? | 09:49 |
| ppisati | ogra_: on raspi2, the boot doesn't complete, it hangs during usb bus init, again perfectly fine in ubuntu classic | 09:49 |
| ogra_ | (and did you copy the dtbs over to the gadget path ?) | 09:49 |
| ppisati | ogra_: uhm, none i think | 09:49 |
| pedronis | mvo: I don't like snapd-repair a lot for the tool, given our snap- pattern there | 09:50 |
| ppisati | ogra_: i would i do that? (copy the dtb to the gadget path) | 09:50 |
| ppisati | *how | 09:50 |
| mvo | pedronis, Chipaca: hm, hm, snapd-repair.service but snap-repair as the tool sounds also inconsistent to me. so maybe keep as is (snap-repair.service and snap-repair tool)? | 09:51 |
| ogra_ | ppisati, well, from the kernel snap /lib/firmware/.../device-tree to /boot/uboot/ (and to the overlays subdir) | 09:51 |
| Chipaca | mvo: snapd.snap-repair.service ? | 09:51 |
| ogra_ | ppisati, else you will indeed boot with a 4.4 dtb | 09:51 |
| ogra_ | (the old issue on the pi) | 09:51 |
| ppisati | ogra_: i thought ubuntu image would pick the dtb from the kernel snap nowadays | 09:51 |
| ogra_ | not on the pi3 | 09:52 |
| ppisati | that might explain why i only have problems with ubuntu core | 09:52 |
| pedronis | mvo: should I mark my go vet fix for 2.28 ? | 09:52 |
| mvo | pedronis: please | 09:52 |
| mvo | Chipaca: that sounds ok | 09:52 |
| ogra_ | the pi bootloader needs the dtb in the toplevel of the vfat and we cant really load it from uboot anymore | 09:52 |
| ogra_ | thats why it is still shipped in the gadget unlike on all other boards | 09:53 |
| pedronis | Chipaca: quick (maybe) review to please the go vet gods: #3836 | 09:53 |
| mup | PR #3836: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <https://github.com/snapcore/snapd/pull/3836> | 09:53 |
| ppisati | ogra_: me checks that | 09:54 |
| ogra_ | hmm, i dont get it ... how did the breakage make it into the current pi2-kernel snap ... the deb only landed yesterday, the broken initrd.img only showed up in todays build of the core snap ... but the kernel snap was built 3 days ago | 10:07 |
| xnox | Hello, i have a python3 build-dependency which is not on pypi =( it's only a package in ubuntu. I've added "build-packages" stanza, but it seems to me that it is failing to import none-the-less. | 10:09 |
| xnox | https://launchpadlibrarian.net/335415335/buildlog_snap_ubuntu_xenial_amd64_xnox-subiquity_BUILDING.txt.gz | 10:09 |
| xnox | Setting up python3-distutils-extra (2.39-1) ... | 10:09 |
| ogra_ | are you using the python3 plugin for it ? | 10:09 |
| xnox | ImportError: No module named 'DistUtilsExtra' | 10:09 |
| xnox | ogra_, oh, i have "plugin: python" should it be "python3" ? | 10:09 |
| ogra_ | it think "python" has a version property | 10:10 |
| xnox | everything is calling python3 as far as I can see | 10:10 |
| xnox | let me check the docs | 10:10 |
| Chipaca | i think it was python3 earlier, but it's been renamed | 10:10 |
| xnox | - python-version: | 10:11 |
| xnox | (string; default: python3) | 10:11 |
| xnox | The python version to use. Valid options are: python2 and python3 | 10:11 |
| xnox | so yes i am using python3 | 10:11 |
| Chipaca | xnox: I don't know snapcraft well at all, but if it's python i assume the problem is that it's not being included in the snap? as there is no build phase? | 10:13 |
| Chipaca | or no compile in the build at least | 10:13 |
| Chipaca | xnox: so maybe it should be a stage-package, not a build-package? | 10:14 |
| ogra_ | yeah | 10:15 |
| xnox | Chipaca, no i don't need to stage distutils-extra at all. distutils-extra are helper functions to use in setup.py which build extra things (translations in my case) and is only needed during building | 10:15 |
| Chipaca | ah alright | 10:15 |
| ogra_ | xnox, if you use snapcraft cleanbuild locally, does it work ? | 10:16 |
| xnox | Chipaca, my problem is that system installed python modules (from build-packages, normal ubuntu package) are not available inside the pyenv / during the pip call | 10:16 |
| Chipaca | xnox: if you wait a little bit, sergiusens would be around | 10:17 |
| Chipaca | should, could | 10:17 |
| Chipaca | xnox: distutils-extra was a problem until recently at least, as per https://forum.snapcraft.io/t/week-31-of-2017-in-snapcraft/1598/3 | 10:17 |
| Chipaca | xnox: maybe kalikiana found how to work with it? | 10:18 |
| mvo | Chipaca: do you want me to look at the rename of snapd.snap-repair.service after lunch? or are you at it already? | 10:21 |
| Chipaca | mvo: I'm not on it, but I can glom it into this huge packaging pr | 10:21 |
| Chipaca | mvo: unless it's time-sensitive? | 10:21 |
| mvo | Chipaca: we should probably do it before 2.28 just to avoid that it hit -updates | 10:22 |
| mvo | Chipaca: I have a look after lunch | 10:22 |
| Chipaca | ok | 10:22 |
| Chipaca | mvo: changing subjects, do you remember where it was that you had an io.Reader and you needed to write it atomically? | 10:23 |
| * Chipaca is thinking about that while waiting for spread | 10:24 | |
| === ShalokShalom_ is now known as ShalokShalom | ||
| mvo | Chipaca: I don't remember where this was, sorry. | 10:53 |
| Chipaca | no probs | 10:53 |
| xnox | is there a way for me to see the contents of the just built snap somehow? | 10:55 |
| Chipaca | xnox: unsquashfs -ls | 10:56 |
| xnox | snap info --show-me-contents-like-dpkg-deb-c subiquity_0+git.3c5c5a5-dirty_amd64.snap | 10:56 |
| xnox | hm, ok. | 10:56 |
| Chipaca | xnox: or --lls | 10:56 |
| ogra_ | xnox, did you use cleanbuild or did you build natively ? | 10:56 |
| Chipaca | xnox: if you're in snapcraft, I think the 'prime' directory is the contents of the snap | 10:57 |
| ogra_ | the prime dir should have the conten in the latter case | 10:57 |
| ogra_ | *content | 10:57 |
| Chipaca | xnox: (and you don't need the snap to try the snap -- 'snap try' can run it, uncompressed, from the prime dir) | 10:57 |
| xnox | ogra_, i do not understand what you mean; and it sounds too many too similar terms | 10:57 |
| xnox | i did snapcraft | 10:57 |
| xnox | so i don't like how things look | 10:58 |
| Chipaca | xnox: snapcraft on its own does build, not cleanbuild -- cleanbuild builds it in a vm | 10:58 |
| ogra_ | xnox, "snapcraft cleanbuild" is the command you should use to get a build similar to what lp does (in-container, properly using xenial repos) | 10:58 |
| ogra_ | xnox, while just calling "snapcraft" will just use your host for all build deps etc | 10:58 |
| xnox | right..... but why is it a separate command instead of e.g. "build --vm"? | 10:58 |
| xnox | becuase there is "clean" and "build" subcommands, i assumed "cleanbuild" subcommand does the previous two in order, just an alias/shortcut | 10:59 |
| ogra_ | (so running "snapcraft on artful will never get you what lp builds) | 10:59 |
| xnox | not like a brand new behariouv. | 10:59 |
| xnox | .. | 10:59 |
| xnox | anyway | 10:59 |
| xnox | .. | 10:59 |
| ogra_ | clean and build are steps ... | 10:59 |
| ogra_ | clanbuild is a special type of building | 10:59 |
| ogra_ | *cleanbuild | 10:59 |
| xnox | my python modules are installed into /lib/python3.5 instead of /usr/lib/python3.5 i find that confusing | 10:59 |
| xnox | it's as if --prefix=/usr was not passed to setup.py | 11:00 |
| xnox | is this normal? | 11:00 |
| xnox | especially when binaries are in /usr/bin/ | 11:00 |
| * ogra_ honestly doesnt know ... i usually stay away from pythjon snaps :P ... and i guess you might have better chances to find the snapcrafters in rocketschat | 11:01 | |
| ogra_ | i'm sure they have a ton of examples you could look at | 11:02 |
| Chipaca | my only python snap predates snapcraft ¯\_(ツ)_/¯ | 11:02 |
| ogra_ | heh | 11:02 |
| Chipaca | (and I think the way it does things is frowned upon :-) ) | 11:03 |
| Chipaca | it does result in a 1MB snap though :-D | 11:03 |
| Chipaca | arch: all, to boot | 11:03 |
| Chipaca | or was it any | 11:03 |
| * Chipaca forgets | 11:04 | |
| * Chipaca goes back to work | 11:04 | |
| ogra_ | greyback, did you use your pi on a wired network when first booting it ? seems there was actually a bug in the image where the clock is wrong on first boot and thus the snaps are not properly initialized (results in ""core" bein installed if you install the first snap) | 11:05 |
| ogra_ | greyback, if your system behaved like this that might cause issues with mir too | 11:05 |
| ogra_ | (actually with any snaps) | 11:06 |
| davidcalle | pstolowski: ping | 11:15 |
| pstolowski | davidcalle, hey! | 11:15 |
| davidcalle | pstolowski: hey, I'm working on examples for the hooks doc page, and I'm wondering if you have any | 11:16 |
| greyback | ogra_: hmm, not in my first tests (those were wifi only), but subsequent tests were on wired, and yes I did see an oddity with core snap update leaving things in a weird state (snapd at 100% cpu too). A reboot seemed to fix it | 11:16 |
| ogra_ | that just looks like it fixed it :) | 11:17 |
| davidcalle | pstolowski: install hook | 11:17 |
| ogra_ | greyback, there are images with rolled back kernel snap in my people.u.c page now ... just re-flash | 11:17 |
| mvo | pedronis: build failure in your latest Transport branch in debian-unstable and fedora that it cannot find Transport, I guess those already have go > 1.7 maybe? | 11:18 |
| greyback | ogra_: ack, will test. I didn't bring my Pi3 into my office today, so will try tonight/over weekend | 11:18 |
| ogra_ | ah, ok | 11:18 |
| pstolowski | davidcalle, not really. install and refresh are very new hooks. but i'm happy to answer any questions. | 11:19 |
| mvo | niemeyer (and anyone else interessed): i updated 3556 (the license branch) with a slightly different validator, please let me know | 11:19 |
| * mvo would love to see this merged | 11:19 | |
| greyback | ogra_: sorry | 11:19 |
| pstolowski | davidcalle, nb, install hook is run only on fresh install of a snap | 11:19 |
| ogra_ | greyback, heh, what for ... thanks for making me look and finding the bug | 11:19 |
| greyback | ogra_: well immediate feedback is nice :) | 11:20 |
| ogra_ | :) | 11:20 |
| davidcalle | pstolowski: ok, so if I create a snap with an "install" hook, a simple sh executable that echoes a string. Here is what happens on snap install "error: cannot perform the following tasks: | 11:20 |
| davidcalle | - Run install hook of "playground" snap if present (run hook "install": cannot snap-exec: cannot find hook "install" in "playground")" | 11:20 |
| davidcalle | pstolowski: and I can't really make sense of the error message. | 11:21 |
| pstolowski | davidcalle, is 'install' actually present in meta/hooks/ ? exec bit set? | 11:22 |
| ogra_ | ppisati, initramfs tools fix is in the PPA ... can you re-build the pi2-kernel and dragonboard kernel snaps ? | 11:22 |
| ppisati | ogra_: me kicks a build | 11:23 |
| ogra_ | thx | 11:24 |
| davidcalle | pstolowski: it doesn't install the snap at all. But it's in my "prime" dir, in meta/hooks with the exec bit set. | 11:24 |
| ogra_ | ppisati, did the copying of the dtbs help btw ? | 11:24 |
| zyga-ubuntu | mvo: is LIBEXECDIR set there for a particular reason? https://github.com/snapcore/snapd/pull/3625#discussion_r136512808 | 11:25 |
| mup | PR #3625: many: end-to-end support for the bare base snap <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625> | 11:25 |
| davidcalle | pstolowski: and if I remove the install file, it installs just fine and the configure hook it ships works | 11:25 |
| ogra_ | zyga-ubuntu, why did you mark #3807 blocked ? the fix is in my comment | 11:31 |
| mup | PR #3807: cmd/snap-confine,packaging: import snapd-generated policy <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/3807> | 11:31 |
| pstolowski | davidcalle, are you running current stable release? | 11:33 |
| zyga-ubuntu | ogra_: it's blocked for now, I want to try to make that change but would rather not do it for 2.28 (too soon, too uncertain) | 11:33 |
| pstolowski | (of snapd) | 11:33 |
| zyga-ubuntu | ogra_: after 2.28 we can do that and see what happens | 11:33 |
| zyga-ubuntu | ogra_: it's blocked in the terms that it cannot land yet | 11:33 |
| ogra_ | zyga-ubuntu, the fix has to happen in the core snap, not in snapd | 11:33 |
| ogra_ | zyga-ubuntu, and it is trivial ... (identical to https://github.com/snapcore/core-build/pull/17 ... i can add your path in the PR if you want) | 11:34 |
| mup | PR core-build#17: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17> | 11:34 |
| zyga-ubuntu | ogra_: right, I know, | 11:36 |
| davidcalle | pstolowski: 2.27.5+17.10 | 11:36 |
| zyga-ubuntu | ogra_: hmm, that's tempting | 11:36 |
| zyga-ubuntu | ogra_: when do you plan to land that change? | 11:36 |
| zyga-ubuntu | ogra_: have you tested it? | 11:36 |
| pstolowski | davidcalle, good. can you push or email your snap somewhere so I can give it a shot? | 11:37 |
| ogra_ | zyga-ubuntu, we use synced in other dirs (and switched them on the fly) so i dont expect any particular breakage ... | 11:37 |
| zyga-ubuntu | ogra_: in that case, when do you plan to land your PR? | 11:39 |
| zyga-ubuntu | ogra_: don't get me wrong, I'd love to try | 11:39 |
| ogra_ | as soon as it gets appoved :) | 11:39 |
| zyga-ubuntu | ogra_: did you test upgrades from older layout | 11:40 |
| ogra_ | no, thats hat edge is for ... i'd land it and test in edge | 11:40 |
| ogra_ | perhaps not today though ... i dont want to have to roll back on the weekend :) | 11:41 |
| ogra_ | zyga-ubuntu, how about we land it on monday | 11:41 |
| ogra_ | manually upgrading core doesnt really reflect the behaviour so i'd prefer to use the store here | 11:42 |
| cjwatson | We're rolling back launchpad-buildd 148 due to some unexpected networking issues with LXD | 11:43 |
| pedronis | mvo: sorry, will fix, build flags are annoying this way | 11:43 |
| zyga-ubuntu | re, mailman | 11:44 |
| zyga-ubuntu | ogra_: on monday after mvo branches off 2.28 is fine | 11:45 |
| ogra_ | cool | 11:45 |
| ogra_ | i'll ping you about it then | 11:45 |
| zyga-ubuntu | ogra_: I mainly worry about the build logic where it would be good to be able to do 2.28.1 without this change | 11:45 |
| zyga-ubuntu | ogra_: thank you! | 11:45 |
| mvo | pedronis: yeah, no worries, just wanted to let you know | 12:18 |
| mup | PR snapd#3837 opened: overlord/snapstate: remove superfluous/misleading check from All <Created by pedronis> <https://github.com/snapcore/snapd/pull/3837> | 12:20 |
| pedronis | tiny cleanup there with open question | 12:21 |
| mvo | ta | 12:23 |
| davidcalle | pstolowski: sorry, I was in a meeting, yes, sending you something, thanks! | 12:26 |
| abeato | lool, hey, is there a repo for flash-device or I need a debdiff to submit a patch? | 12:27 |
| lool | abeato: I dont think there's an Ubuntu repo; the Debian repo is under d-i project at git.d.o | 12:28 |
| abeato | lool, ok, should I then submit the change to debian directly? | 12:28 |
| lool | abeato: we typically land Ubuntu changes directly in Ubuntu and then send a patch to Debian if applicable there | 12:34 |
| abeato | lool, alright, will do that | 12:34 |
| lool | abeato: what's your change :) | 12:34 |
| lool | abeato: seeing version in Ubuntu is ubuntu65, it has not been rebased in a reallllly long time | 12:34 |
| ogra_ | pfft ... whats 64 revisions :P | 12:36 |
| lool | ogra_: 65! | 12:36 |
| ogra_ | we always have ubuntu1 :) | 12:36 |
| lool | with a delta already! | 12:36 |
| abeato | lool, adding one device to the database : http://paste.ubuntu.com/25444576/ | 12:37 |
| ogra_ | well, only the maintainer address :) | 12:37 |
| jdstrand | mvo: hi! I'm seeing this inside an lxd container (ie, my dev environment is in an lxdcontainer): http://paste.ubuntu.com/25444561/ | 12:39 |
| lool | abeato: is it an officially supported flavor in Ubuntu? | 12:39 |
| zyga-ubuntu | jdstrand: hey | 12:39 |
| jdstrand | hey zyga-ubuntu :) | 12:39 |
| lool | abeato: in which case, I suggest you add a Kernel-Flavor header as well | 12:39 |
| jdstrand | mvo: wondering if there is anything there that might ring a bell | 12:40 |
| abeato | lool, well, it is for a commercial device | 12:40 |
| lool | abeato: if there's no kernel in Debian supporting the hardware, I suggest you only upload it to Ubuntu | 12:40 |
| mvo | jdstrand: not right now, I can check inside lxd | 12:40 |
| mvo | jdstrand: to see if I see the same | 12:40 |
| abeato | lool, I guess not supported by debian, right | 12:40 |
| lool | abeato: Kernel-Flavor is basically an extra check to make sure the right kernel unames are allowed and you don't accidentally write a -generic kernel to your flash that wont boot | 12:40 |
| lool | so it's a nice safety net if that works for your hardware | 12:41 |
| jdstrand | zyga-ubuntu: fyi, re snap-update-ns, I've got an exploratory PR that shuffles some stuff around to address much of the import issues I mentioned in snap-update-ns | 12:41 |
| zyga-ubuntu | jdstrand: thank you, do you want to talk about it? | 12:41 |
| zyga-ubuntu | jdstrand: I also added an idea to the PR, to use a remote API to talk to snapd to call update-ns | 12:41 |
| jdstrand | zyga-ubuntu: yes, but not right this second. let me finish the tests and send it up | 12:41 |
| zyga-ubuntu | jdstrand: ok | 12:41 |
| zyga-ubuntu | jdstrand: thanks, I'll be here, my network works now | 12:41 |
| pedronis | mvo: pushed the rename there | 12:42 |
| jdstrand | zyga-ubuntu: oh, that is an interesting idea too | 12:42 |
| lool | abeato: I guess it's a for a xenial based install? BTW since this is not snappy specific, we should probably be discussing this somewhere else | 12:42 |
| jdstrand | it would add ipc to exec... | 12:42 |
| zyga-ubuntu | jdstrand: it _might_ be even IPC-less but in a very convoluted way | 12:42 |
| zyga-ubuntu | jdstrand: but yes, IPC is the way to go | 12:43 |
| jdstrand | anyway, let me finish this and send it up | 12:43 |
| zyga-ubuntu | jdstrand: ok | 12:43 |
| mvo | pedronis: ta | 12:43 |
| jdstrand | mvo: thanks! | 12:43 |
| cachio | mvo, I updated the pc-kernel snap in staging using the one in prod but seems to bring many issues | 12:46 |
| cachio | mvo, I see many of this ones https://paste.ubuntu.com/25444618/ | 12:46 |
| cachio | I need to update the kernel because the lxd test needs a new kernel to work | 12:47 |
| cachio | mvo, any Idea? | 12:47 |
| mvo | cachio: hm, device session errorin https://paste.ubuntu.com/25444618/ that might be something for pedronis | 12:47 |
| zyga-ubuntu | cachio: whick kernel are you on? | 12:48 |
| cachio | zyga-ubuntu, 4.4.0-83 | 12:48 |
| pedronis | cachio: that's look like a prod snapd trying to talk to staging | 12:49 |
| pedronis | cachio: d-Jc... is a prod key | 12:49 |
| cachio | pedronis, yes | 12:49 |
| zyga-ubuntu | cachio: it's definitely not too old IMO | 12:49 |
| pedronis | that doesn't work | 12:49 |
| cachio | pedronis, so I should build the snap spacially for staging? | 12:50 |
| pedronis | cachio: yes, I think as I said that already, and you need to set the env vars | 12:50 |
| pedronis | you need both | 12:51 |
| cachio | pedronis, the env vars are already set | 12:52 |
| cachio | and the tests working but I need to update the pc-kernel snap to make the lxd test pass in stagnig | 12:52 |
| pedronis | well something is not using a snapd for staging or the env var are not set | 12:53 |
| pedronis | that key there is a prod key | 12:53 |
| pedronis | that's why staging says what | 12:53 |
| pedronis | or it might be that we don't switch to staging early | 12:54 |
| pedronis | enough | 12:54 |
| pedronis | that's a new potential problem | 12:54 |
| pedronis | with master | 12:54 |
| cachio | I ran the cron-job that already was passing for all the tests but now with the new pc-kernel that I got from prod | 12:54 |
| pedronis | the kernel alone shouldn't make a difference | 12:55 |
| cachio | pedronis, that cron-job was working against staging | 12:55 |
| cachio | pedronis, I though the same, that's why I updated that | 12:55 |
| pedronis | something else has changed | 12:56 |
| cachio | but after I updated it a lot of these errors appeared | 12:56 |
| pedronis | how did you update it? | 12:56 |
| pedronis | update it in the store? | 12:56 |
| cachio | I downloadede manually from prod and uploaded to the staging store | 12:56 |
| pedronis | ok, something else is going on here | 12:57 |
| mup | PR snapd#3838 opened: systemd: rename snap-repair.{service,timer} to snapd.snap-repair.{service,timer} <Created by mvo5> <https://github.com/snapcore/snapd/pull/3838> | 13:00 |
| cachio | niemeyer, I'll be few minutes late | 13:01 |
| zyga-ubuntu | pedronis: standup? | 13:04 |
| niemeyer | pedronis: pingous | 13:04 |
| jdstrand | mvo: fyi, if I comment out that test, it gets a lot farther, but fails with: http://paste.ubuntu.com/25444693/ | 13:09 |
| jdstrand | mvo: SNAP_EXEC is "0" instead of "" | 13:09 |
| jdstrand | SNAP_REEXEC* | 13:09 |
| jdstrand | oh frak | 13:09 |
| jdstrand | I have SNAP_REXEC=0 in /etc/environment. why in the world is that there? | 13:10 |
| jdstrand | ok, that does not affect cmd_test.go | 13:11 |
| jdstrand | meh, yes it does | 13:11 |
| jdstrand | mvo: ok, please disregard. hopefully I didn't waste your time. I had SNAP_REEXEC=0 in /etc/environment. remove that, log out and back in and it is fine. that said, perhaps the testsuite shouldn't be affected by that... | 13:13 |
| ogra_ | probably because you added it when testing a snapd deb change | 13:13 |
| jdstrand | I don't run snapd in the container. I must have fat fingered something and accidentally added it there | 13:13 |
| zyga-ubuntu | jdstrand: I think each one of us ran into this since we introduced this feature | 13:15 |
| jdstrand | zyga-ubuntu: hehe | 13:17 |
| * jdstrand adds to ~/.bashrc: | 13:17 | |
| jdstrand | if [ -n "$SNAP_REEXEC" ]; then | 13:17 |
| jdstrand | echo "WARNING: SNAP_REEXEC is set to '$SNAP_REEXEC'. This may affect the snapd testsuite" | 13:17 |
| jdstrand | fi | 13:17 |
| ogra_ | heh | 13:18 |
| jdstrand | I hate bothering people when the issue was my fault. this will *not* happen again :P | 13:18 |
| mvo | jdstrand: yay, thank you. but good point | 13:19 |
| zyga-ubuntu | oh, that's nice | 13:20 |
| zyga-ubuntu | jdstrand: stolen! | 13:20 |
| === JoshStrobl|AFK is now known as JoshStrobl | ||
| zyga-ubuntu | jdstrand: it should be a part on snapd thing in /etc/profile ;) | 13:20 |
| zyga-ubuntu | just couple that wiht $LOGNAME switch | 13:20 |
| jdstrand | heh | 13:21 |
| ogra_ | pfft ... push it to upstream into /etc/skel ... | 13:21 |
| zyga-ubuntu | jdstrand: it should also sleep and play yankie-doodle | 13:24 |
| jdstrand | hehe | 13:25 |
| ogra_ | nah, we live in modern times ... it should send you a tweet that plays yankee-doodle | 13:25 |
| * ogra_ would really like to know why travis doesnt work anymore in core-build | 13:26 | |
| ogra_ | "Automatic restarts limited: Please try restarting this job later or contact support@travis-ci.com." | 13:26 |
| ogra_ | not really helpful when there is no further output | 13:27 |
| zyga-ubuntu | ogra_: throw more monies at the screen | 13:28 |
| zyga-ubuntu | ogra_: offtopic, I got the pi drive for my hate of SD cards outgrew the discounted price of the smaller drive, did you play with it? | 13:29 |
| ogra_ | doesnt stick ... i tried | 13:29 |
| ogra_ | zyga-ubuntu, pi-drive ? never heard of it | 13:29 |
| zyga-ubuntu | ogra_: wd labs pidrive | 13:29 |
| zyga-ubuntu | ogra_: I got the one with 314GB | 13:29 |
| ogra_ | the one thats shipped with the nextcloud box ? | 13:30 |
| zyga-ubuntu | ogra_: I bet | 13:30 |
| zyga-ubuntu | ogra_: I just got it now because they shut the progrma down | 13:30 |
| zyga-ubuntu | *program | 13:30 |
| ogra_ | (i have a nextcloud box here but never even unpacked it) | 13:30 |
| zyga-ubuntu | and the drives are cheap | 13:30 |
| zyga-ubuntu | aha | 13:30 |
| ogra_ | well, you would still need the SD to booot | 13:30 |
| zyga-ubuntu | it includes a berry boot SD card | 13:31 |
| ogra_ | so boot, and run through console-conf to hve the Sd completely set up ... | 13:31 |
| zyga-ubuntu | but it's also optional once you put the right stuff into your fuses, I hear | 13:31 |
| ogra_ | then dd the second partition to the USB disk and remove the label from the SD second partition | 13:31 |
| ogra_ | that should be all | 13:31 |
| ogra_ | after reboot you should be in core booted from /writable on the USB disk | 13:32 |
| ogra_ | (and writable should have been properly resized to the full disk size) | 13:32 |
| ogra_ | (you might need to manually create an msdos partition table on the USB disk first though) | 13:33 |
| ogra_ | zyga-ubuntu, blowing the fuse and usb-booting should work in edge ... but in stable (as usual) the kernel and gadget are to old | 13:34 |
| * ogra_ needs to go afk for some errands ... back soon | 13:34 | |
| zyga-ubuntu | ogra_: thanks | 13:34 |
| ahasenack | hi guys, quick question. When reverting to a previous revision of a classic snap, why do I need to pass --classic again? | 13:35 |
| zyga-ubuntu | ahasenack: because snaps can confinement flip/flop across revisions and I think we are very paranoid about being explicit for that one | 13:36 |
| ahasenack | the revert command works without --classic, but the snap then doesn't, and it can be baffling at first, because snap refresh (forced upgrade) doesn't need --classic | 13:36 |
| ahasenack | zyga-ubuntu: but the previous one is already installed: you know if it was a classic one or not | 13:36 |
| zyga-ubuntu | ahasenack: yes, but you may have installed it with --jailmode | 13:37 |
| ahasenack | which you would know too | 13:37 |
| zyga-ubuntu | ahasenack: I think it's just "because", I think Chipaca has deeper insight | 13:37 |
| * zyga-ubuntu checks familiy before jumping into another call | 13:39 | |
| ahasenack | do you guys know if a reverted snap will be automatically upgraded? | 13:40 |
| ahasenack | in other words, if the current stable snap is broken, and I have reverted to the previous one which is fine, will I have to keep doing that all day long? | 13:40 |
| Chipaca | ahasenack: the revision that you revert away from is blacklisted locally | 13:40 |
| ahasenack | nice | 13:41 |
| ahasenack | thx | 13:41 |
| Chipaca | ahasenack: that's the main difference between revert and refresh --revision=<something you have locally> | 13:41 |
| Chipaca | ahasenack: bah. Two main differences: the blacklisting, and revert using the old data whereas refresh copies new data in place | 13:41 |
| ahasenack | I used revert --revision | 13:42 |
| Chipaca | and nice red uniforms | 13:42 |
| Chipaca | ahasenack: that's fine (although should be unnecessary) | 13:42 |
| mup | PR snapd#3836 closed: httputil: more naive per go version way to recreate a default transport for tls reconfig <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3836> | 13:44 |
| mup | PR snapd#3839 opened: docs: use abolute path in PULL_REQUEST_TEMPLATE.md <Created by mvo5> <https://github.com/snapcore/snapd/pull/3839> | 13:45 |
| mup | PR snapd#3840 opened: Snap update ns intial refactor for setuid [EXPLORATORY, DO NOT COMMIT] <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3840> | 13:48 |
| Chipaca | ahasenack: about requiring --classic, we had good reasons for doing it at the time, which revolved around what the user would expect as things evolved, but I think we could probably revisit that sometime (as we recently revisited devmode) | 13:54 |
| ahasenack | Chipaca: it was unexpected to me: http://pastebin.ubuntu.com/25444749/ | 13:55 |
| ahasenack | Chipaca: *specially* because after the revert, snap list shows the snap as classic still | 13:55 |
| ahasenack | so for a while I was thinking the problem was something else | 13:56 |
| Chipaca | wait | 13:56 |
| ahasenack | until dmesg confirmed the apparmor DENIED messages | 13:56 |
| Chipaca | ahasenack: you're saying it was saying classic but wasn't? | 13:56 |
| Chipaca | if so that's a Bug | 13:56 |
| ahasenack | Chipaca: yep, after the revert | 13:56 |
| ahasenack | it was 209 before | 13:56 |
| ahasenack | I still have the list --all output from before the revert, let me expand that pastebin | 13:57 |
| Chipaca | I'll dig into this in a moment | 13:57 |
| * zyga-ubuntu looks at jdstrand's idae | 13:58 | |
| Chipaca | ahasenack: to be clear, it should have either done it (leaving it as classic) or not done it (telling you you needed to say --classic), depending on the codepath | 13:58 |
| ahasenack | Chipaca: http://pastebin.ubuntu.com/25444883/ | 13:59 |
| zyga-ubuntu | mhm | 14:01 |
| zyga-ubuntu | jdstrand: shall I prepare a small RPC idea as well? | 14:01 |
| sergiusens | zyga-ubuntu: what does this error mean Setup snap "core" (2462) security profiles (cannot setup udev for snap "core": cannot reload udev rules: exit status 2 ? It seems sporadic as eventually core was installed by means of a different test https://travis-ci.org/snapcore/snapcraft/jobs/270814907 | 14:06 |
| zyga-ubuntu | sergiusens: hmm, it means that we cannot re-trigger udev | 14:07 |
| zyga-ubuntu | I would have to look it up | 14:08 |
| zyga-ubuntu | sergiusens: note that just until yesterday we had a bug in master that would generate broken rules for the opengl interface | 14:08 |
| zyga-ubuntu | sergiusens: so it may be related | 14:08 |
| zyga-ubuntu | sergiusens: but those would not show up for core | 14:08 |
| zyga-ubuntu | sergiusens: so not really related | 14:08 |
| zyga-ubuntu | unfortunately udev was vey terse :/ | 14:09 |
| sergiusens | zyga-ubuntu: so there are around 8 tests that would need to setup core in order to get build-snaps tested, seems one failed and the following test dtrt | 14:09 |
| sergiusens | also, this is in a container | 14:09 |
| jdstrand | zyga-ubuntu: I don't think it is required. that is easy to understand. Knowing how much work was involved in the refactor was more key since it was unknown and a bit scary sounding | 14:12 |
| jdstrand | niemeyer, zyga-ubuntu: fyi, https://github.com/snapcore/snapd/pull/3621#discussion_r136583426 | 14:12 |
| mup | PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 14:12 |
| niemeyer | jdstrand: I'd prefer to continue the conversation on a hangout if that's okay | 14:12 |
| jdstrand | niemeyer: well, I would want you and zyga to have the context that I wrote up before having that conversation. note that I'm not sure the hangout is strictly necessary for all of us (see bottom of my comment) | 14:14 |
| jdstrand | niemeyer: if you decide it is necessary after reading the comment, that's fine too | 14:14 |
| niemeyer | jdstrand: I would really prefer to have a chat about it | 14:15 |
| niemeyer | jdstrand: This has been coming for a while, and the back and forth in the PR is also indicative that getting together and actually talking is worth the timing | 14:15 |
| jdstrand | niemeyer: that's fine, but please read my context in prepration of the conversation | 14:15 |
| zyga-ubuntu | jdstrand: I just read your comment | 14:16 |
| Chipaca | hmm | 14:16 |
| Chipaca | linode his having some issues | 14:17 |
| Chipaca | so, 30 minutes in, 48/1320 tests done | 14:17 |
| Chipaca | :-( | 14:17 |
| zyga-ubuntu | Chipaca: that's modern market economy | 14:18 |
| zyga-ubuntu | Chipaca: and virtualizatoin | 14:18 |
| zyga-ubuntu | Chipaca: let me sell you some virtual land | 14:18 |
| ogra_ | Chipaca, cool, you will be done in just 13h | 14:18 |
| Chipaca | ogra_: and 50 minutes travis says "right! everybody out of the pool!" | 14:19 |
| Chipaca | zyga-ubuntu: let's go back to barter | 14:19 |
| ogra_ | well, your tests actually start ... mine are dead in the water before even starting | 14:19 |
| zyga-ubuntu | Chipaca: travis said that because linode peed into the pool | 14:19 |
| niemeyer | jdstrand: Okay, we've both read it.. what's the best time for a call today? | 14:19 |
| ogra_ | https://travis-ci.org/snapcore/core-build/builds/270465829 | 14:20 |
| jdstrand | niemeyer: I can do it in 40 minutes or after | 14:20 |
| zyga-ubuntu | sounds good to me | 14:20 |
| * zyga-ubuntu is sleepy with the weather, I'll get a qucik nap and see you then | 14:21 | |
| Chipaca | darn, now i have _two_ reviews without a +1 :-) | 14:45 |
| ogra_ | jdstrand, is there any reason why i dont see thw wayland interface on my ubuntu core devices ? (shouldnt it be secure enough to allow it on core as well) | 14:45 |
| Chipaca | ogra_: psh, that "wayland" thing is never going to take off. DirectFB is where it's at. | 14:48 |
| ogra_ | ! | 14:49 |
| pedronis | Chipaca: wasn't /names fixed to be sorted? | 14:49 |
| ogra_ | i'd live directfb with full GLES :) | 14:49 |
| Chipaca | pedronis: I filed a bug for it to be sorted | 14:49 |
| Chipaca | pedronis: wishlist bug, filed last tuesday, accepted by nessita the very same day, status confirmed, no way in anything is that going to be live for a while yet | 14:50 |
| Chipaca | bug#1714023 | 14:50 |
| Chipaca | bug 1714023 | 14:50 |
| mup | Bug #1714023: please make names endpoint sorted <Snap Store:Confirmed for nataliabidart> <https://launchpad.net/bugs/1714023> | 14:50 |
| Chipaca | i mean, even if it were an important bug, it wouldn't even be on staging yet i reckon | 14:51 |
| pedronis | ok, I was just confused, I saw long funny discussions on it | 14:51 |
| Chipaca | :-) | 14:51 |
| pedronis | I thought it would have been fixed | 14:51 |
| pedronis | in the mean time | 14:51 |
| Chipaca | pedronis: those long discussions were last tuesday dude | 14:51 |
| pedronis | Chipaca: anyway given that I see little point in trying to get this into 2.28 | 14:53 |
| Chipaca | pedronis: because the sort won't be needed down the line? | 14:55 |
| pedronis | Chipaca: yes, and because I cannot give a +1 right now, all the SetRootDir changes need extra concetration that I don't have | 14:55 |
| Chipaca | ah, ok | 14:56 |
| pedronis | not to look at that, but to ignore them carefully | 14:56 |
| pedronis | s/that/them/ | 14:56 |
| pedronis | also refreshMisc is not a great name | 14:56 |
| Chipaca | pedronis: “The worst part of this is probably the names of the ensure bits. I'll leave you all to decide that.” | 14:57 |
| pedronis | refreshCatalogs ? | 14:58 |
| pedronis | I don't know | 14:58 |
| niemeyer | mvo: #3556 has a review.. | 15:02 |
| mup | PR #3556: client,daemon,snap,store: add license field <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/3556> | 15:02 |
| niemeyer | Needs a second one | 15:03 |
| Chipaca | pedronis: i might retract the PR, do the setrootdir, and then redo this one | 15:03 |
| Chipaca | it's going to be a nightmare of conflicts, which is why it's probably going to be a redo and not a rebase, but ¯\_(ツ)_/¯ | 15:04 |
| pedronis | maybe you can find higher stamina people | 15:04 |
| Chipaca | pedronis: it's been two weeks, so no | 15:04 |
| * zyga-ubuntu is ready for the call | 15:05 | |
| niemeyer | jdstrand, zyga-ubuntu: I can do in ~1h | 15:05 |
| mup | PR snapd#3748 closed: many: fetch & cache remote snaps and sections; complete from there <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3748> | 15:05 |
| jdstrand | ok | 15:05 |
| zyga-ubuntu | niemeyer: ok | 15:06 |
| === cachio is now known as cachio_lunch | ||
| pedronis | mvo: what's the status of #3379, does it need a jdstrand review? | 15:18 |
| mup | PR #3379: cmd/snap,tests: show the snap id if available in snap info <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3379> | 15:18 |
| pedronis | heh sorry | 15:18 |
| pedronis | mvo: what's the status of #3779, does it need a jdstrand review? | 15:19 |
| mup | PR #3779: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3779> | 15:19 |
| Chipaca | i'm going offline for a bit, have a good weekend all if i don't make it back before eod | 15:19 |
| Chipaca | o/ | 15:19 |
| jdstrand | pedronis: it is on my list after 3621 | 15:20 |
| pedronis | Chipaca: o/ | 15:20 |
| jdstrand | pedronis: but I was waiting on another PR to be committed that it is based on iirc | 15:20 |
| pedronis | jdstrand: #3502 was merged | 15:21 |
| mup | PR #3502: snap-seccomp: add in-kernel bpf tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3502> | 15:21 |
| jdstrand | yeah, that one | 15:21 |
| pedronis | jdstrand: so, yes should be ready to look at (master merged, other review addressed afaict) | 15:22 |
| * jdstrand nods | 15:22 | |
| jdstrand | I should be able to get to it today | 15:22 |
| nacc | is it possible to install the recommends of stage-package automatically? | 15:23 |
| ogra_ | yes, if you list them in stage-packages ;) | 15:24 |
| nacc | ogra_: not true :/ | 15:24 |
| nacc | ogra_: oh you mean explicitly? :) | 15:24 |
| nacc | ogra_: that bypasses my "automatically" (although not clear how i phrased it) | 15:25 |
| nacc | ogra_: i want a package and all it's depends and recommends to be staged | 15:25 |
| ogra_ | yeah, then you need to manually list them to have them automatically installed :) | 15:25 |
| ogra_ | iirc only actual depends are processed | 15:26 |
| ogra_ | (and the debs are also only unpacked, not installed (i.e. none of the maintainer scripts get run) | 15:26 |
| ogra_ | ) | 15:26 |
| mvo | niemeyer: thanks a lot for your review, I address the points now | 15:30 |
| mvo | pedronis: a jamie review would be good but I think we could merge even without one, he was much in favour of the in-kernel tests that I implemented over the bpf.VM | 15:30 |
| * zyga-ubuntu feels so so today | 15:32 | |
| roadmr | :/ | 15:32 |
| jdstrand | mvo: fwiw, I don't consider my review essential for that. I'm fine with the concept of it (just using the kernel). I did notice it would be good to comment why you aren't testing PR_SET_ENDIAN above the PR_ for loop. if it is helpful for me to review, that's fine, if not, let me know and I won't | 15:34 |
| * zyga-ubuntu resumes fixing stuff | 15:38 | |
| jdstrand | zyga-ubuntu: sorry you aren't feeling well :\ | 15:38 |
| zyga-ubuntu | jdstrand: weather | 15:38 |
| zyga-ubuntu | jdstrand: spain.read returns EOF | 15:39 |
| jdstrand | yeah.. | 15:39 |
| zyga-ubuntu | jdstrand: I guess the weather outside will forece me to watch that popular series with sex, death and snow people | 15:39 |
| zyga-ubuntu | I can smell snow in a few weeks | 15:39 |
| zyga-ubuntu | ah, thrones something | 15:39 |
| jdstrand | I was surprised how cool it was in Warsaw | 15:40 |
| zyga-ubuntu | I think it just ended, right? | 15:40 |
| ppisati | ogra_: manually copying the dtbs fixed it | 15:40 |
| zyga-ubuntu | cool as in cold? | 15:40 |
| jdstrand | zyga-ubuntu: yes | 15:40 |
| jdstrand | zyga-ubuntu: no, cool as in pleasant (at the product sprint) | 15:40 |
| ogra_ | ppisati, thanks for the freedback ! | 15:40 |
| zyga-ubuntu | haha :) | 15:40 |
| zyga-ubuntu | I see :) | 15:40 |
| jdstrand | I was then imaging how cold it must get in the winter if it was that pleasant in the summer | 15:40 |
| ogra_ | ppisati, so same probleam as always ... | 15:40 |
| jdstrand | imagining* | 15:40 |
| zyga-ubuntu | jdstrand: I think -5/-15C is common | 15:40 |
| zyga-ubuntu | it's more that it's cold for a long time | 15:41 |
| zyga-ubuntu | and that it's dark | 15:41 |
| zyga-ubuntu | I don't like the lack of sunlight | 15:41 |
| jdstrand | brrr | 15:41 |
| roadmr | haha yes, dark at 4 PM is so weird | 15:42 |
| === cachio_lunch is now known as cachio | ||
| zyga-ubuntu | jdstrand, niemeyer: ready if you are | 16:14 |
| ogra_ | ogra@localhost:~$ snap list | 16:16 |
| ogra_ | Name Version Rev Developer Notes | 16:16 |
| ogra_ | core 16-2.27.5+git352.186fdc0 2793 canonical core | 16:16 |
| ogra_ | pi2-kernel 4.4.0.1071.71 41 canonical kernel | 16:16 |
| ogra_ | pi3 16.04-0.5 22 canonical gadget | 16:16 |
| ogra_ | PHEW! | 16:16 |
| jdstrand | me too | 16:17 |
| * ogra_ hugs pedronis for the help and ppisati for the kernel re-spins | 16:17 | |
| ogra_ | all back to normal now | 16:17 |
| zyga-ubuntu | jdstrand: standup HO? | 16:18 |
| ogra_ | (such a little fix ... so time consuming ...) | 16:18 |
| * zyga-ubuntu looks for headset | 16:19 | |
| niemeyer | zyga-ubuntu: Grabing a cup of coffee and will be with you | 16:20 |
| mup | PR snapcraft#1525 opened: typo: replace occured with occurred <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1525> | 16:24 |
| ogra_ | ondra, jdstrand http://paste.ubuntu.com/25445729/ i see that on my pi3 now after installing avahi | 16:24 |
| ogra_ | greyback, FYI ... http://paste.ubuntu.com/25445732/ (mir-kiosk not starting here either on pi3, even with the fixed image, reboot doesnt change anything) | 16:28 |
| mup | PR snapd#3779 closed: snap-seccomp: remove use of x/net/bpf from tests <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3779> | 16:42 |
| zyga-ubuntu | okay, let me finish the fixes quickly | 16:45 |
| jdstrand | niemeyer, zyga-ubuntu: I'll summarize the outcome in the PR | 16:45 |
| zyga-ubuntu | thank you! | 16:46 |
| zyga-ubuntu | I have a few more things to sort out there, I'll write a dedicated message to signal I'm done with the requested changes | 16:47 |
| mvo | niemeyer: addressed your review comments for 3556, thanks again for those | 16:50 |
| mvo | niemeyer: I get dinner but check back later | 16:50 |
| mvo | zyga-ubuntu: if you could check 3625 and (formally) approve, that would be nice | 16:53 |
| om26er | When will the new snappy images release ? (Not talking about updates, rather new img files) | 16:53 |
| zyga-ubuntu | mvo: sure | 16:55 |
| ogra_ | om26er, given that you get an update of all snaps immediately after install, does that really matter ? | 16:55 |
| zyga-ubuntu | one | 16:56 |
| ogra_ | two | 16:56 |
| zyga-ubuntu | *done | 16:56 |
| zyga-ubuntu | :-) | 16:56 |
| niemeyer | mvo: Responded to your question.. still +1 with or without it | 16:57 |
| om26er | ogra_: thats true but wouldnt that also bring device specfic changes that are only available in edge right now. (Once new images spin) | 16:58 |
| ogra_ | om26er, no, stable images only update from stable | 16:58 |
| ogra_ | (and gadgets do not update any bootloader bits, only snap.yaml (interface definitions etc) | 16:59 |
| ogra_ | ) | 16:59 |
| ogra_ | (no matter which channel) | 16:59 |
| * om26er processes | 17:00 | |
| jdstrand | zyga-ubuntu, niemeyer: whoops I accidentally hit 'Comment' rather than 'Preview'-- I'm still finetuning the plan of action. I'll edit the comment and ping you when done | 17:11 |
| zyga-ubuntu | sue | 17:11 |
| zyga-ubuntu | sure | 17:11 |
| jdstrand | zyga-ubuntu, niemeyer: ok, read away! :) | 17:24 |
| * zyga-ubuntu reads | 17:24 | |
| zyga-ubuntu | jdstrand: I think this is all fine | 17:31 |
| zyga-ubuntu | jdstrand: note that we may choose to opt-out of go-flags | 17:31 |
| zyga-ubuntu | jdstrand: to limit the surface to only the standard library and code in the repository | 17:31 |
| ogra_ | would they be stay-flags then (if you opt-out) ? | 17:32 |
| zyga-ubuntu | jdstrand: sounds super good | 17:32 |
| zyga-ubuntu | jdstrand: one suggestion/question, shall you just push extra features into this branch so that we can both work on one location or would you rather land this in stages and use separate branches? | 17:33 |
| === JanC is now known as Guest2554 | ||
| === JanC_ is now known as JanC | ||
| === cachio is now known as cachio_afk | ||
| zyga-ubuntu | jdstrand: updated | 18:07 |
| zyga-ubuntu | jdstrand: do you plan to write the child profile now? | 18:07 |
| zyga-ubuntu | jdstrand: if no I will take a break to help my son and I'll be back to write a quick prototype and see how that operates | 18:08 |
| mup | PR snapcraft#1526 opened: catkin plugin: don't assume catkin is in underlay <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1526> | 18:09 |
| mup | PR snapd#3841 opened: Do not emit cloud-init.disabled; cloud-init only runs if datasource is present <Created by raharper> <https://github.com/snapcore/snapd/pull/3841> | 18:12 |
| jdstrand | zyga-ubuntu: sorry, I'm not working on this right this second. I noticed a bug in the recent big udev PR that affects 2.28 and nvidia | 18:13 |
| jdstrand | zyga-ubuntu: I'd like to chase that done a bit | 18:14 |
| jdstrand | mvo: hey, are you tracking 2.28 issues anywhere? | 18:14 |
| jdstrand | zyga-ubuntu: if you are wanting to write the child profile (I just saw your PR comment), feel free. I'll of course review it deeply | 18:15 |
| pedronis | jdstrand: given the outcome in that PR, should we close (at least for now) #3840 ? | 18:45 |
| mup | PR #3840: snap-update-ns intial refactor for setuid [EXPLORATORY, DO NOT COMMIT] <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3840> | 18:45 |
| zyga-ubuntu | jdstrand: thank you, that was my intent | 18:47 |
| zyga-ubuntu | jdstrand: curious about nvidia issue | 18:47 |
| jdstrand | pedronis: yes. I'll do that | 18:49 |
| mup | PR snapd#3720 closed: cmd,interfaces: add initial support for Solus <Created by ikeydoherty> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3720> | 18:49 |
| zyga-ubuntu | jdstrand: about the RPC approach, the actual update-ns tool could be woken up by systemd | 18:49 |
| zyga-ubuntu | jdstrand: not by snapd | 18:49 |
| zyga-ubuntu | jdstrand: not perfect but possible | 18:49 |
| zyga-ubuntu | jdstrand: I'm not proposing that we do it, I just wanted to say that, thinking about our conversation earlier | 18:50 |
| mup | PR snapd#3838 closed: systemd: rename snap-repair.{service,timer} to snapd.snap-repair.{service,timer} <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3838> | 18:50 |
| jdstrand | zyga-ubuntu: so, apparently only GPL modules can use sysfs. sysfs is integral to udev tagging it seems (I need to look a little further). nvidia is proprietry, so no sysfs. therefore it doesn't show up in the udev query to add it to the device cgroup. since opengl now uses the device cgroup, no nvidia | 18:51 |
| zyga-ubuntu | hmmmm | 18:51 |
| zyga-ubuntu | well, that certainly hairy | 18:52 |
| zyga-ubuntu | can we just add predictable things to the cgroup? | 18:52 |
| zyga-ubuntu | I'll let you poke and check back soon, still helping my son with his stuff | 18:52 |
| mup | PR snapd#3840 closed: snap-update-ns intial refactor for setuid [EXPLORATORY, DO NOT COMMIT] <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3840> | 18:55 |
| jdstrand | zyga-ubuntu: we add some devices automatically to the cgroup now (eg, /dev/zero). I was thinking worst case just add these nvidia devices to the cgroup if they exist, then rely on apparmor for access | 18:56 |
| jdstrand | zyga-ubuntu: if we are encountering a lot of things like nvidia, we might manage a file of things to add or come up with something different | 18:57 |
| jdstrand | it could get hairy with hotpluggable proprietary devices, but there are things we could do there too | 18:58 |
| mup | PR snapd#3842 opened: store: have an ad-hoc method on cfg to get its list of uris for tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/3842> | 19:08 |
| mup | PR snapd#3843 opened: cmd/snap: SetRootDir from SetUpTest, not in just some individual tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/3843> | 19:10 |
| mup | PR snapd#3844 opened: overlord/snapstate: SetRootDir from SetUpTest, not in just some tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/3844> | 19:12 |
| Chipaca | hello from webchat :-) | 19:15 |
| Chipaca | zyga-ubuntu: thank you for the speedy reviews! | 19:15 |
| Chipaca | and next stop is mine, so i'm off again o/ | 19:17 |
| zyga-ubuntu | :) | 19:23 |
| === cachio_afk is now known as cachio | ||
| jdstrand | sigh, the device cgroups aren't working right. I'll need to investigate that first before nvidia | 19:54 |
| jdstrand | mvo: fyi, ^ | 19:54 |
| jdstrand | mvo: I'll file bugs/etc when have complete info | 19:54 |
| jdstrand | basically, if there are more than one command in /etc/udev/rules.d/70-snap.foo.rules, only one of the commands gets a device cgroup. and if it gets a device cgroup, snap-confine isn't putting it into it | 19:56 |
| jdstrand | s/are more/is more/ | 19:56 |
| mvo | jdstrand: uh, meh :/ | 19:57 |
| mvo | jdstrand: is that a regression? | 19:57 |
| jdstrand | mvo: not in 2.28. it is a regression somewhere (it used to work :) | 19:58 |
| jdstrand | I need to figure out when it occurred. I also need to look at the spread test for this | 19:58 |
| jdstrand | I suspect a) it isn't doing enough to test an actual denial and b) it isn't doing multiple commands within the same snap | 19:59 |
| jdstrand | I'll get this all fixed up with updated spread tests. won't have it today, will do it first thing next week | 19:59 |
| jdstrand | well, sorta first thing-- monday is a US holiday | 20:00 |
| jdstrand | anyhoo, I' figure it out | 20:00 |
| jdstrand | mvo: ^ | 20:00 |
| jdstrand | I'll* | 20:00 |
| mvo | jdstrand: ok, thanks a bunch. if you put infos how to reproduce e.g. into the forum I can check monday. its not a holiday in my part of the world | 20:01 |
| mvo | jdstrand: if its not too hard I could e.g. bisect to see when things went wrong | 20:02 |
| jdstrand | mvo: as such, there is no problem with nvidia and the udev PR. cgroups are being created but not used so nothing can break ;P | 20:02 |
| mvo | jdstrand: aha, ok | 20:02 |
| jdstrand | mvo: I'd really like to dig in on this and then document how to debug this stuff so others can do it in the future | 20:04 |
| jdstrand | mvo: I'm sure you're busy enough. plus, there should be no user facing regression for the 2.28 release (2.27.5 seems affected too) | 20:04 |
| mup | PR snapd#3843 closed: cmd/snap: SetRootDir from SetUpTest, not in just some individual tests <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3843> | 20:05 |
| mvo | jdstrand: ok, if there is no user facing fallout I'm fine with waiting, I mostly offering monday as it sounded very urgent. yeah, I have plenty else to work on :) | 20:05 |
| mvo | jdstrand: thanks for looking into it! | 20:05 |
| jdstrand | np | 20:05 |
| jdstrand | mvo: if there is a user facing regression (again, I'm not seeing it), but the time it is discovered I will be on it, so I think we're good. thanks for the offer | 20:06 |
| jdstrand | s/but the/by the/ | 20:06 |
| mvo | jdstrand: thank you as well. I will call it a day now, have a great (long) weekend | 20:10 |
| mup | PR snapcraft#1520 closed: tour: remove the tour assets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1520> | 22:13 |
| mup | PR snapcraft#1521 closed: python plugin: always record constraints and requirements contents <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1521> | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!