| === ads20000_ is now known as ads20000 | ||
| mborzecki | morning | 06:15 |
|---|---|---|
| mup | PR snapd#4901 opened: cmd/snap-confine: nvidia: add tls/libnvidia-tls.so* glob <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4901> | 06:38 |
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 07:08 |
| mborzecki | zyga: hey | 07:09 |
| mborzecki | zyga: take a look at 4901 please | 07:09 |
| zyga | ohhh | 07:09 |
| zyga | I see now | 07:09 |
| zyga | man, is that it? | 07:09 |
| mborzecki | yeah | 07:09 |
| mborzecki | 'magic' | 07:09 |
| zyga | man :) | 07:10 |
| zyga | that's insane | 07:10 |
| mborzecki | zyga: left a note here https://forum.snapcraft.io/t/nvidia-acceleration-on-chrome-and-firefox/4532/16 , there's 2 copies of these libraries | 07:10 |
| zyga | but also brittle on our part, I wonder how can we make sure to pick the right set in general | 07:10 |
| zyga | I think that should be a snap | 07:10 |
| zyga | and that snapcraft should prevent people from shipping those | 07:10 |
| * zyga reads | 07:10 | |
| mborzecki | we already pick up libnvidia-tls.so*, bu there's another one under tls/libnvidia-tls.so*, no clue how the second one gets loaded | 07:10 |
| zyga | are they identical? | 07:11 |
| mborzecki | yup | 07:11 |
| mborzecki | aah w8, | 07:12 |
| mborzecki | no, damn, looked wrong | 07:12 |
| mborzecki | they're different | 07:12 |
| mborzecki | need to correct the post | 07:12 |
| zyga | Ah | 07:13 |
| zyga | This makes more sense now | 07:13 |
| zyga | Ok | 07:14 |
| zyga | Still +1 | 07:14 |
| mborzecki | note to self, make sure to sort the inputs | 07:14 |
| zyga | Are they coming out of nvidia private build? | 07:14 |
| zyga | Or out of libglvnd | 07:14 |
| mborzecki | zyga: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/nvidia-utils#n114 nvidia | 07:14 |
| mborzecki | zyga: it even works the arch glvnd libs now | 07:15 |
| zyga | Ok | 07:16 |
| zyga | Can you please do a small experiment | 07:17 |
| zyga | Take the nvidia build from their website | 07:17 |
| zyga | Unpack it | 07:17 |
| zyga | And correlate the files inside with our patterns | 07:17 |
| zyga | Are we missing anything | 07:17 |
| zyga | mborzecki: I'll review and perhaps land the makefile change today | 07:27 |
| zyga | but can you please look at this: https://github.com/snapcore/snapd/pull/4891 | 07:28 |
| mup | PR #4891: tests: add support for phased prepare-restore logic <Created by zyga> <https://github.com/snapcore/snapd/pull/4891> | 07:28 |
| zyga | I have some nice follow-ups | 07:28 |
| zyga | and I wanted to get the foundation in place | 07:28 |
| mborzecki | zyga: hm i think we might be doing something silly with those globs | 07:31 |
| === chihchun is now known as chihchun_afk | ||
| mborzecki | on the host I have both paths /usr/lib/libnvidia-tls.so.390.42 and /usr/lib/tls/libnvidia-tls.so.390.42, but in the mount ns only one appears | 07:32 |
| mborzecki | then readme in the drivers states this: The nvidia-tls libraries (/usr/lib/libnvidia-tls.so.390.42 and /usr/lib/tls/libnvidia-tls.so.390.42); these files provide thread local storage support for the NVIDIA OpenGL libraries (libGL, libnvidia-glcore, and libglx). Each nvidia-tls library provides support for a particular thread local storage model (such as ELF TLS), and the one appropriate for your system will | 07:33 |
| mborzecki | be loaded at run time. | 07:33 |
| zyga | mborzecki: look at the snap-confine code there, we probably don't look at tls/* at all | 07:35 |
| zyga | mborzecki: my idea is to convert the nvidia tarball into a snap | 07:36 |
| zyga | and mount it | 07:36 |
| zyga | ignore anything the host does | 07:36 |
| mborzecki | you'd need a tarball for each version of the drivers | 07:36 |
| zyga | we only need to support each family, not each version | 07:37 |
| zyga | there are about 3 at most | 07:37 |
| zyga | and yes, I agree | 07:37 |
| zyga | although I don't know if all families support libglvnd | 07:37 |
| zyga | what is the layout of the working setup at runtime, what is in /var/lib/snapd/lib/gl | 07:38 |
| zyga | (can you ls -lR there please?) | 07:38 |
| mborzecki | just a sec, got some changes in place | 07:39 |
| zyga | kk | 07:39 |
| zyga | great work btw! this is very promising | 07:39 |
| mborzecki | zyga: https://paste.ubuntu.com/p/jHSFhjbjV9/ | 07:42 |
| mborzecki | zyga: we have this: libnvidia-tls.so.390.42 -> /var/lib/snapd/hostfs/usr/lib/tls/libnvidia-tls.so.390.42, but the symlink should be to var/lib/snapd/hostfs/usr/lib/libnvidia-tls.so.390.42 and we should have directory tls with symlink to respecive libs inside | 07:43 |
| mborzecki | same for vdpau | 07:43 |
| zyga | hmm | 07:44 |
| zyga | this will require small changes there | 07:44 |
| zyga | but yeah | 07:44 |
| zyga | and can you pastebin the tree of files that is in the nvidia tarball? | 07:45 |
| mborzecki | zyga: the correct layout https://paste.ubuntu.com/p/NHHHpNCrVY/, seems to work fine too | 07:45 |
| zyga | hmm | 07:47 |
| zyga | a bit magic | 07:47 |
| zyga | since you said those libnvidia-tls.so files are not the same | 07:47 |
| mborzecki | zyga: files in the driver package pulled from nvidia's site: https://paste.ubuntu.com/p/zDFygPwSQ2/ | 07:48 |
| mborzecki | yeah the readme says: 'the one appropriate for your system will be loaded at run time.' | 07:49 |
| zyga | drwxr-xr-x 2 maciek maciek 4096 03-03 14:03 tls | 07:53 |
| zyga | they have a tls dir | 07:53 |
| zyga | I need to run | 07:53 |
| zyga | my son forgot his homework (yeah) | 07:53 |
| zyga | and just called me | 07:53 |
| zyga | AFK | 07:53 |
| zyga | and then I will work from a coffee shop because I planned to move anyway | 07:54 |
| zyga | mvo: good morning, I'll be back soon, please ping me if urgent | 07:54 |
| mvo | zyga: ok | 07:55 |
| mup | PR snapd#4901 closed: cmd/snap-confine: nvidia: add tls/libnvidia-tls.so* glob <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4901> | 08:01 |
| mborzecki | mvo: can you cherrypick it to 2.32? | 08:02 |
| mvo | mborzecki: already done | 08:02 |
| mvo | mborzecki: thank you | 08:02 |
| mborzecki | mvo: thanks | 08:02 |
| kalikiana | moin moin | 08:12 |
| pstolowski | morning | 08:16 |
| mup | PR snapd#4902 opened: cmd/snap-confine: nvidia: preserve globbed file prefix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4902> | 08:46 |
| mborzecki | zyga: ^^ https://paste.ubuntu.com/p/NSWPHDrNBd/ | 08:46 |
| zyga | Almost back | 09:04 |
| zyga | re | 09:11 |
| zyga | sorry for being late | 09:11 |
| zyga | mvo: hey, I'm ready to assist in any way I can | 09:12 |
| zyga | mvo: I was thinking about the trespassing bug | 09:12 |
| zyga | mvo: and I think we can postpone that for 2.33 | 09:12 |
| zyga | mvo: since the impact is not serious and this is a beta feature | 09:12 |
| zyga | mvo: I will work on cleaning it up to have proper data path from main all the way down | 09:12 |
| zyga | mvo: and this will lessen the impact on the release | 09:13 |
| zyga | mvo: I would only like to merge the symlink fixes | 09:13 |
| zyga | mvo: and do more more more testing to see if we can reproduce the issue again | 09:13 |
| mvo | zyga: that sounds great. I'm working right now on the snap run fixes we talked about yesterday | 09:13 |
| zyga | mvo: I also have a tiny PR to add (I can add it to the symlink PR) to add something to debug: there | 09:13 |
| zyga | mvo: thank you sounds good | 09:13 |
| zyga | mvo: I moved downtown to meet with an old colleague | 09:13 |
| zyga | super smart guy, I wonder if he would consider joining our team :) | 09:14 |
| mvo | zyga: heh, ok | 09:15 |
| zyga | he's an old lisp hacker, not sure if he'd want to use go ;-) | 09:15 |
| mvo | zyga: ha! a sage | 09:17 |
| zyga | I think he needs to upgrade his beard a few times for that ;D | 09:17 |
| mvo | zyga: CE testing found that 2.32 would not work correct on caracalla because the security profile re-generation. I am curretnly trying to write up how this happens, do you remember in what way we modify the security profiles between 2.31->2.32 that would trigger this? | 09:18 |
| zyga | yes | 09:18 |
| mvo | zyga: please tell me then :) | 09:18 |
| zyga | mvo: we now require a new profile snap-update-ns.$SNAP_NAME on startup | 09:18 |
| zyga | in the past whenever we changed profiles and the changes were not huge we would just start with the old profile | 09:19 |
| zyga | and replace the profile in place as soon as snapd woke up | 09:19 |
| mvo | zyga: what requires this? snap-confine? | 09:19 |
| mborzecki | zyga: please take a look at 4902 when you can | 09:19 |
| zyga | now we cannot start apps because w ecannot complete the profile transition from snap-confine to snap-update-ns | 09:19 |
| zyga | mborzecki: ack | 09:19 |
| zyga | mvo: in 2.31 we had one profile for snap-update-ns | 09:19 |
| zyga | one that was very open because of layouts | 09:19 |
| mvo | zyga: that is excellent, this also means that without system-key this would not even possible? | 09:19 |
| mborzecki | i'll be looking at 4891 in a while and then will try nvidia & bionic | 09:20 |
| mvo | zyga: is it snap-confine that loads these extra profiles? | 09:20 |
| zyga | in 2.32 we have one profile per snap, that is tailored to construct the layout | 09:20 |
| zyga | mvo: no, it's not snap-confine | 09:20 |
| mvo | zyga: what is loading those? | 09:20 |
| zyga | mvo: snap confine doesn't even check if they exist, it just requests transition on the next exec | 09:20 |
| zyga | mvo: normally they are loaded by apparmor init script on early boot | 09:20 |
| zyga | mvo: those are stored just like snap application profiles, in /var/lib/snapd/apparmor/profiles | 09:20 |
| mvo | zyga: hm, I'm puzzled then, so part of the new profile (that require these extra things) are on disk already? | 09:21 |
| zyga | mvo: no | 09:21 |
| zyga | mvo: they will be created by snapd after core reboots to 2.32 | 09:21 |
| mvo | zyga: what am I missing :) | 09:21 |
| zyga | mvo: in 2.31 they were not a thing | 09:21 |
| pedronis | but in 2.31 -> 2.32 transition they will not be there until after reboot and start of snapd, no? | 09:21 |
| zyga | mvo: so we hit a hard transition when a profile is missing | 09:21 |
| zyga | yes pedronis, exactly right | 09:21 |
| zyga | mvo: this will become less of an issue once we have snapd.snap | 09:22 |
| zyga | and snapd can restart itself without rebooting the box | 09:22 |
| mvo | zyga: what bit falls over? I mean, if the old profiles are there until we run snapd one would assume that network-manager would run happily with the old profiles? | 09:22 |
| zyga | then the profiles will show up in phase 2 | 09:22 |
| zyga | mvo: you miss one fact | 09:22 |
| zyga | mvo: it's a brand new profile | 09:22 |
| zyga | not one that existed in 2.31 at all | 09:22 |
| pedronis | mvo: well after reboot there's a profile that requires a profile that is not there | 09:23 |
| pedronis | not quite sure how the profile transition work | 09:23 |
| zyga | mvo: the name is snap-update-ns.network-manager | 09:23 |
| zyga | mvo: we never had that profile in 2.31 | 09:23 |
| zyga | mvo: note that this can happen even if we take snap-update-ns out of the picture | 09:23 |
| mvo | zyga,pedronis: why the mismatch, I mean, if there is a new profile after reboot then the other profile should also be written. and if its an old profile it does not reference the new profile. what am I missing :) ? | 09:23 |
| mvo | zyga: sorry for being a bit slow today | 09:24 |
| zyga | mvo: 2.31 doesn't write snap-update-ns.network-manager | 09:24 |
| zyga | mvo: 2.32 does and requires it to start network-manager process | 09:24 |
| mvo | zyga: but does 2.31 references this profile in any way? | 09:24 |
| zyga | mvo: no | 09:24 |
| zyga | mvo: do you want to HO to have me explain this in person? | 09:25 |
| mvo | zyga: yes | 09:25 |
| zyga | kk | 09:25 |
| zyga | one sec | 09:25 |
| mvo | sure, I'm sure there is some tiny details I'm missing, but I don't know yet what | 09:25 |
| * zyga hopes background coffee shop music won't be an issue | 09:25 | |
| mvo | zyga: I'm in the stadnup HO | 09:26 |
| zyga | mvo: one moment, I don't have chrome here | 09:26 |
| zyga | normally I HO from my desktop | 09:26 |
| * mvo nods | 09:26 | |
| zyga | 2 minutes to download | 09:26 |
| zyga | uh, I should visit that telco store and get a modem for my sim :( | 09:27 |
| mvo | zyga: we could also have a old-fashioned phone call if you want :) | 09:28 |
| zyga | installing chrome now | 09:29 |
| mvo | ok | 09:29 |
| zyga | if this fails, yeah | 09:29 |
| zyga | I'll call you | 09:29 |
| mwhudson | pedronis: can you read Laney's comments on https://bugs.launchpad.net/snapd/+bug/1723094 and reply on the bug? | 09:37 |
| mup | Bug #1723094: Live images should be able to turn off Snap updates <snapd:Confirmed> <casper (Ubuntu):Triaged by jibel> <casper (Ubuntu Bionic):Triaged by jibel> <https://launchpad.net/bugs/1723094> | 09:38 |
| pedronis | mwhudson: I tried to answer, does it make sense? | 09:44 |
| mwhudson | pedronis: it makes sense to me at least :) | 09:45 |
| Laney | thanks! | 09:46 |
| zyga | mborzecki: done | 09:54 |
| * Chipaca afk for a bit | 10:05 | |
| zyga | mvo: can we merge https://github.com/snapcore/snapd/pull/4899 | 10:06 |
| mup | PR #4899: many: backported fixes for layouts and symlinks (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4899> | 10:06 |
| mborzecki | when i'm running bionic from usb stick, are the changes preserver accross reboots? | 10:06 |
| zyga | mborzecki: dunno | 10:06 |
| zyga | it used to be (some) | 10:06 |
| zyga | but not sure | 10:06 |
| * Chipaca really afk now | 10:10 | |
| zyga | o/ | 10:10 |
| Chipaca | mborzecki: it depends on whether, when you created the thing, you told it to leave some rw space | 10:10 |
| mborzecki | Chipaca: I dd'ed iso to usb stick | 10:11 |
| Chipaca | hmm, i can't see where on usb-creator-gtk there was that option, but i'm sure it was there before | 10:12 |
| zyga | I think it may have been removed now | 10:13 |
| mborzecki | Chipaca: dd is the only usb-creator i ever use :) | 10:13 |
| zyga | because that code evolved a lot | 10:13 |
| mvo | zyga: let me look at it. in the meantime: 4882 is updated | 10:13 |
| zyga | mborzecki: install ubuntu on some spare hdd | 10:13 |
| zyga | mvo: thank you, looking | 10:13 |
| Chipaca | usb-creator (0.3.0) xenial; urgency=medium | 10:14 |
| Chipaca | [ Marc Deslauriers ] | 10:14 |
| Chipaca | * Rework the whole imaging process for writing to devices: | 10:14 |
| Chipaca | - Use an equivalent of dd to make an exact copy of the image to the device | 10:14 |
| Chipaca | - This also breaks persistence. | 10:14 |
| Chipaca | that last line there? boom. no more persistence. | 10:14 |
| mborzecki | damn | 10:14 |
| mvo | godd! | 10:14 |
| mvo | just saying :) | 10:14 |
| Chipaca | mvo: does that do persistence | 10:14 |
| Chipaca | :-) | 10:14 |
| mvo | its persistently nice, if that is what you mean ;) | 10:15 |
| Chipaca | mborzecki: get your hands on usb-creator-gtk 0.2.68 :-) | 10:15 |
| Chipaca | mvo: dunno, seems unmaintained, i proposed a pr ages ago and got no feedback | 10:15 |
| * Chipaca runs | 10:15 | |
| mborzecki | Chipaca: i'll try installing to a usb stick (while running the installer from another usb stick) | 10:15 |
| Chipaca | mborzecki: usb-creator-gtk from trusty should do it | 10:16 |
| Chipaca | mborzecki: https://packages.ubuntu.com/trusty-updates/amd64/usb-creator-gtk/download | 10:16 |
| zyga | Chipaca, mborzecki: I would not trust that :) | 10:18 |
| Chipaca | zyga: 'course you can trust it, it's got 'trusty' in the name! | 10:18 |
| * Chipaca really needs to afk for a bit now | 10:18 | |
| zyga | hahaah | 10:20 |
| zyga | :-) | 10:20 |
| * zyga bakes a few more patches in google | 10:20 | |
| zyga | while on the go, google is a nice place to test | 10:20 |
| zyga | we should update the reference tag to get smaller deltas | 10:20 |
| mvo | zyga: hm, one test missing, sorry for this, will push a new 4882 in some minutes | 10:21 |
| zyga | ok | 10:21 |
| pedronis | mvo: do we know if for some reasons network-manager needs to start before snapd on those machines? (I suppose not, we write the all the relevant units and there's no such dep) | 10:22 |
| zyga | pedronis: I think that on those machines n-m manages all networking | 10:23 |
| zyga | pedronis: and it just starts as early as it can | 10:23 |
| zyga | it's not strictly "before snapd" but not explicitly linked to through dependencies | 10:23 |
| zyga | pedronis: and if we go and change the units now we'd have issues in the field as there's no easy way to change any systemd units | 10:23 |
| pedronis | that's fine as long as snapd doesn't wait for that, and the timeout on starting that service is within the time it takes for snapd to do its job | 10:23 |
| zyga | (we don't have equivalent of ensure there) | 10:23 |
| pedronis | in terms of profile writing | 10:24 |
| mborzecki | hm the installer does something funny, there's 'Erase disk and install Ubuntu' option, but I have 5 disks plugged in at the moment, so which one will it erase? | 10:24 |
| zyga | pedronis: that's a good point | 10:24 |
| zyga | mborzecki: choose manual partitioning | 10:24 |
| zyga | mborzecki: 18.04 or 16.04? | 10:24 |
| zyga | I'm used to 16.04 installer but I think that 18 changed a lot | 10:24 |
| mborzecki | 18.04 | 10:25 |
| zyga | mborzecki: one more "hint" detach other disks :D | 10:25 |
| zyga | it's surprisingly low tech robust solution for this problem | 10:26 |
| zyga | also helps if you install windows or other OS with silly installer that just overwrites everything agressively | 10:26 |
| mborzecki | i'm clicking, but franly i'm minutes away from debootstrapping the thing | 10:26 |
| zyga | mborzecki: you can do it, just a bit more patience :) | 10:29 |
| mborzecki | slightly worrying, wonder wher grub efi will get installed, i've made a partition for efi and set the bootloader to be installed to that disk | 10:41 |
| mborzecki | aaannd it installed grub to the wrong drive | 10:44 |
| mborzecki | inistaller finished, now i can start fixing the system :/ | 10:55 |
| zyga | mborzecki: is it booting? | 10:57 |
| zyga | what's up? | 10:57 |
| zyga | mborzecki: sorry :/ | 10:57 |
| mborzecki | zyga: the installer hijacked the ESP on the main nvme drive, heh so the system i got now is ubuntu/efi on nvme and rootfs on usb stick | 10:59 |
| mborzecki | got to install ubuntu's grub in efi partition of usb stick and make arch boot again | 10:59 |
| Chipaca | mborzecki: are you having fun yet | 11:00 |
| mup | PR snapd#4899 closed: many: backported fixes for layouts and symlinks (2.32) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4899> | 11:04 |
| zyga | woot | 11:04 |
| zyga | thanks mvo | 11:04 |
| zyga | mvo: I forgot to push that debug branch so I'll add a debug PR to 2.32 as well | 11:04 |
| zyga | mvo: in 15 minutes, busy with some topics | 11:05 |
| mvo | zyga: 4882 is ready to review. this and your debug pr are the last bits, right? | 11:05 |
| zyga | yes | 11:05 |
| zyga | well | 11:05 |
| zyga | 4882 not sure | 11:05 |
| zyga | I forgot which PR that was | 11:05 |
| mvo | zyga: snap run --system-key | 11:05 |
| zyga | ay | 11:05 |
| zyga | +1 | 11:06 |
| zyga | yes | 11:06 |
| zyga | I left the debug bits at home so I'll just make a new PR | 11:06 |
| mborzecki | zyga: fwiw bionic boots now | 11:09 |
| mborzecki | and from the right drive | 11:10 |
| zyga | mborzecki: cool :) | 11:10 |
| zyga | did you have to update bootloader layout? | 11:12 |
| mborzecki | zyga: yes, mount proper partiion under /boot/efi, edit fstab to make it work after reboot, install grub x86_64-efi | 11:15 |
| mborzecki | i'll deal with arch later, i have a slightly convoluted luks+lvm there | 11:16 |
| mup | PR snapd#4903 opened: tests: split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <https://github.com/snapcore/snapd/pull/4903> | 11:29 |
| zyga | hey mborzecki-ubuntu :) | 11:33 |
| ogra_ | Chipaca, shouldn't whatever needs /var/cache/snapd/commands.db create it if it is none-existent ? (see https://forum.snapcraft.io/t/var-cache-snapd-commands-db-permission-denied/4590 ) | 11:33 |
| mborzecki-ubuntu | zyga: hey | 11:33 |
| Chipaca | ogra_: if it doesn't exist there's nothing to do, so it should just move on | 11:33 |
| ogra_ | well, it doesn't | 11:34 |
| Chipaca | ogra_: IKR | 11:34 |
| Chipaca | ogra_: I think at least two things need fixing: one, which i think mvo is already on, is to make _command_not_found hide stderr from snap advise-snap (or maybe make snap advise-snap not error on no db) | 11:38 |
| Chipaca | ogra_: the other is to make the classic snap grab the commands.db from host :-) | 11:38 |
| ogra_ | yeah, obviously | 11:39 |
| ogra_ | i only noticed after i wrote the first comment that it seems to be created on first boot | 11:39 |
| Chipaca | ogra_: if you've got classic installed somewhere, could you see if you could just cp it from hostfs? | 11:39 |
| ogra_ | so we need a cp in the classic setup script | 11:39 |
| ogra_ | err, yes, see my last post there | 11:39 |
| Chipaca | ogra_: no, from _inside_ | 11:40 |
| Chipaca | ogra_: maybe it's fixable inside :-) | 11:40 |
| ogra_ | ah, nop, that wont work | 11:40 |
| Chipaca | aw | 11:40 |
| ogra_ | we're in a chroot | 11:40 |
| Chipaca | ogra_: i thought the classic snap had crazy privs | 11:40 |
| ogra_ | and dont do fancy hostfs bind mounting or anything | 11:40 |
| ogra_ | its a simple chroot :) | 11:40 |
| ogra_ | but it is no prob to simply add it to the chroot setup script | 11:41 |
| Chipaca | ogra_: given core can be size constrained, maybe ln || cp (or is there a better way to do that) | 11:41 |
| * Chipaca knows nothing | 11:41 | |
| zyga | mvo: 2.32 debug PR https://github.com/snapcore/snapd/pull/4904 | 11:42 |
| mup | PR #4904: tests: change debug for layout test (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4904> | 11:42 |
| mup | PR snapd#4904 opened: tests: change debug for layout test (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4904> | 11:42 |
| mvo | zyga: ta | 11:43 |
| ogra_ | Chipaca, linking wont work (and bind mounting adds complexity i'd like to avoid) ... cp will do | 11:44 |
| mborzecki-ubuntu | well, nvidia doesn't work in snaps on bionic | 11:44 |
| mborzecki-ubuntu | i'll try my branch | 11:44 |
| zyga | OMG!!!! git checkout - | 11:46 |
| mborzecki-ubuntu | is tehre a command i can use to install all build deps listed in debian/control? | 11:46 |
| zyga | my favourite command | 11:46 |
| mborzecki-ubuntu | zyga: yeah, it's like cd - ;) | 11:46 |
| mvo | mborzecki-ubuntu: sudo apt build-dep ./ | 11:46 |
| zyga | yes | 11:46 |
| zyga | I just complained I wish there was something like that | 11:46 |
| mvo | mborzecki-ubuntu: if you are inside the unpacked deb | 11:46 |
| zyga | and suddenly my colleague shows me this | 11:46 |
| mborzecki-ubuntu | mvo: ta | 11:47 |
| zyga | oops, pushed to wrong PR | 11:49 |
| zyga | PRs corrected | 11:55 |
| zyga | mborzecki-ubuntu: https://github.com/snapcore/snapd/pull/4903 | 11:55 |
| mup | PR #4903: tests: [WIP] split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <https://github.com/snapcore/snapd/pull/4903> | 11:55 |
| zyga | no need to review yet before the other one lands | 11:55 |
| zyga | but this is what I was thinking about | 11:55 |
| zyga | there's lots of room to improve from this state | 11:56 |
| zyga | but it's already much more approachable than the big one we have now | 11:56 |
| zyga | is there a spread variable that holds the name of the current test? | 11:57 |
| mvo | zyga: meh, the system-key stuff is actually more work because snap run needs to read the build-id of snapd not of snap | 11:58 |
| zyga | oohh | 11:58 |
| zyga | yeah | 11:58 |
| zyga | and great catch :/ | 11:58 |
| zyga | mvo: and now it needs to know which snapd to read | 11:58 |
| zyga | mvo: /o\ | 11:59 |
| mvo | zyga: make the whole thing more complicated. exactly, re-exec and all that :( | 11:59 |
| zyga | mvo: maybe | 11:59 |
| zyga | mvo: maybe we drop the tailored profiles | 11:59 |
| zyga | mvo: use the old profile for 2.32 | 11:59 |
| mvo | zyga: that sounds wise | 11:59 |
| zyga | mvo: and at least 2.32 ships with the new profile on disk | 11:59 |
| zyga | mvo: and 2.33 won't have massive issues | 11:59 |
| mvo | zyga: how much work is it? | 11:59 |
| zyga | not a solution much but yeah | 11:59 |
| zyga | mvo: drop a few lines of C from snap-confine | 11:59 |
| mvo | zyga: \o/ | 11:59 |
| mvo | zyga: lets do that | 12:00 |
| zyga | mvo: restore child profile for snap-confine.apparmor.in | 12:00 |
| zyga | mvo: and it _should_ work | 12:00 |
| mvo | zyga: much safer and we look at this problem again with more time and less presure | 12:00 |
| zyga | mvo: we'll still make the snap-update-ns.$SNAP_NAME profiles and load them but they will be unused | 12:00 |
| zyga | yes | 12:00 |
| zyga | mvo: I'll prepare a PR | 12:00 |
| zyga | mvo: and you can get fewer gray hair :) | 12:00 |
| mvo | zyga: heh, indeed | 12:00 |
| mvo | zyga: I have way too many of those already | 12:00 |
| zyga | mvo: ok, let me do this quickly | 12:01 |
| ogra_ | mvo, https://github.com/snapcore/classic-snap/pull/16 | 12:01 |
| mup | PR classic-snap#16: fix breakage of command-not-found <Created by ogra1> <https://github.com/snapcore/classic-snap/pull/16> | 12:01 |
| * Chipaca switches tasks, from improving test coverage to improving lunch coverage | 12:03 | |
| zyga | hahaha | 12:03 |
| * zyga hugs Chipaca | 12:03 | |
| Chipaca | zyga: how're your breaks coming? | 12:03 |
| * zyga looks the other way to avoid eye contact | 12:04 | |
| zyga | I'm not at home | 12:04 |
| zyga | that's an improvement | 12:04 |
| mvo | ogra_: thank you | 12:04 |
| zyga | but relaease rush | 12:04 |
| zyga | so ... you know | 12:04 |
| zyga | *release even | 12:04 |
| Chipaca | yeah | 12:04 |
| zyga | mvo: ok, running locally now | 12:14 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/4905 | 12:15 |
| mup | PR #4905: cmd/snap-confine: don't use per-snap s-u-n profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4905> | 12:15 |
| mup | PR snapd#4905 opened: cmd/snap-confine: don't use per-snap s-u-n profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4905> | 12:15 |
| zyga | not tested yet | 12:15 |
| mborzecki-ubuntu | zyga: failed to create prefix path: /tmp/snap.rootfs_jW5tpa/var/lib/snapd/lib/vulkan/icd.d: Permission denied | 12:17 |
| diddledan | a bit of fun: "how to make package managers cry" https://www.youtube.com/watch?v=kguJ1ihOyV8 | 12:19 |
| zyga | mborzecki-ubuntu: dmesg | grep DENIED | 12:25 |
| zyga | I suspect we need some apparmor love there | 12:25 |
| mborzecki-ubuntu | zyga: switched it to aa-complain atm | 12:26 |
| zyga | good, that will let you see all the access patterns | 12:26 |
| zyga | please collect the denials though | 12:26 |
| zyga | diddledan: good one! | 12:37 |
| diddledan | :-) | 12:38 |
| mborzecki-ubuntu | zyga: hmm multiarch is broken, we're trying to bind mount the wrong paths | 12:40 |
| zyga | oh | 12:40 |
| zyga | on 18.04? | 12:40 |
| mborzecki-ubuntu | zyga: yes | 12:40 |
| zyga | on 18.04 all of nvidia is broken for us | 12:40 |
| zyga | :/ | 12:41 |
| mborzecki-ubuntu | we ought to do the same as for biarch, as the libs are under /usr/lib/<arch-tuple> now | 12:41 |
| zyga | yes | 12:41 |
| zyga | you can disable reexec and just build snapd with that option | 12:42 |
| zyga | and see what breaks | 12:42 |
| zyga | we can use this experience to later do this at runitme | 12:42 |
| zyga | *runtime | 12:42 |
| mborzecki-ubuntu | is there a command line tool that would return the arch tuple of current host? | 12:47 |
| mborzecki-ubuntu | i mean the default one | 12:47 |
| pedronis | mborzecki: I think mvo I had a PR about the exposing full triplet at some point, but was closed | 12:48 |
| zyga | mborzecki-ubuntu: gcc -dumpmachine | 12:48 |
| zyga | mborzecki-ubuntu: everything else disagrees | 12:48 |
| zyga | mborzecki-ubuntu: dpkg --print-architecture is one more but not the same | 12:49 |
| zyga | mborzecki-ubuntu: can that be a compile-time constant? | 12:53 |
| mvo | mborzecki-ubuntu: https://github.com/snapcore/snapd/pull/4477/files#diff-fb91c6071604836b89ba2de46c45a56fR56 is what I did | 12:56 |
| mup | PR #4477: snapenv: add SNAP_ARCH_TRIPLET <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4477> | 12:56 |
| mup | PR snapd#4906 opened: polkit: Pass caller uid to PolicyKit authority <Created by chrisccoulson> <https://github.com/snapcore/snapd/pull/4906> | 13:03 |
| mup | PR snapd#4905 closed: cmd/snap-confine: don't use per-snap s-u-n profile (2.32 only) <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4905> | 13:07 |
| mup | PR snapd#4903 closed: tests: [WIP] split prepare-restore.sh into prepare-restore.d modules <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4903> | 13:08 |
| jdstrand | zyga (cc mvo): you're backing out the hardening? that is terribly unfortunate cause I only conditionally acked layouts on the promise that the hardening would be there | 13:08 |
| jdstrand | zyga (cc mvo): for 2.32 | 13:08 |
| zyga | jdstrand: we're backing out of 2.32 split profile | 13:08 |
| jdstrand | zyga: yes, the hardening that I said was required cause the child profile was way too open | 13:09 |
| mvo | jdstrand: the split profiles cause deep issues | 13:09 |
| zyga | jdstrand: yes, we may axe the feature for now so that we can do it properly | 13:09 |
| mvo | jdstrand: happy to have a HO if you want maybe after the standup | 13:09 |
| jdstrand | I'll not do a conditional ack like this again | 13:09 |
| zyga | (that would break layouts entirely for 2.32) | 13:09 |
| mvo | jdstrand: I think the alternative is to disabled this entirely | 13:09 |
| jdstrand | of course, I said I wouldn't do it yesterday | 13:09 |
| jdstrand | mvo: that was understood with the conditional ack | 13:10 |
| zyga | I think we can axe it and do it for 2.33 | 13:10 |
| zyga | where it will be all done | 13:10 |
| zyga | (both the hardening and the feature) | 13:10 |
| jdstrand | allow it to be committed to test things out and if the hardening wasn't there, back out the feature | 13:10 |
| mvo | jdstrand: ok, lets have a HO then, we are in the middle of the standup right now so not the best time to discuss. would you be able to make it to a hangout at the top of the hour (in 49min)? | 13:11 |
| jdstrand | I'm not sure a hangout is needed-- my position is that with s-u-n profiles, we may as well not confine snap-confine | 13:11 |
| jdstrand | but I think I can do a hangout then | 13:12 |
| mvo | jdstrand: might be easiest just to ensure we are all on the same page. we won't do anything that you do not ACK | 13:12 |
| jdstrand | zyga: are you in said hangout out? I'd like to understan the 'deep issues' | 13:12 |
| jdstrand | hangout out? | 13:12 |
| jdstrand | said standup? | 13:12 |
| mvo | jdstrand: well, its not that deep. basic there is a race: when snapd refresehes and reboots on core then snapd start before the new snapd is run | 13:13 |
| mvo | jdstrand: so these snaps will not find the needed profiles | 13:13 |
| mvo | jdstrand: and fail to start | 13:14 |
| mvo | jdstrand: and of course thats bad(tm) for things like network-manager | 13:14 |
| jdstrand | isn't that what the system-key 'wait on me' stuff is for? we did that somewhere else recently | 13:14 |
| mvo | jdstrand: https://github.com/snapcore/snapd/pull/4882 - correct, implementing this is tricky | 13:14 |
| mup | PR #4882: snap: make `snap run` look at the system-key for security profiles <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4882> | 13:14 |
| mvo | jdstrand: and we are under some pressure to release 2.32 | 13:15 |
| mvo | jdstrand: anyway, might be easiest in a HO, then we can discuss options and maybe come to different conclusions | 13:16 |
| zyga | mvo, jdstrand: yeah, let's reuse the HO after standup | 13:18 |
| zyga | and discuss the problem, our approach so far and the plans we had | 13:18 |
| zyga | and what we actually want to do after discussing this | 13:18 |
| * zyga would prefer to merge the hardening but it doesn't change the other problem we had | 13:18 | |
| zyga | mvo, jdstrand: if we need to back out layouts and undo the un-hardening so that we are back to 2.31 profile I can do that quickly | 13:26 |
| zyga | though we have the experimental flag now and we need to remove that as well | 13:26 |
| jdstrand | zyga, mvo: another idea: https://github.com/snapcore/snapd/pull/4905#issuecomment-375306343 | 13:32 |
| mup | PR #4905: cmd/snap-confine: don't use per-snap s-u-n profile (2.32 only) <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4905> | 13:32 |
| zyga | ack | 13:32 |
| zyga | jdstrand: that's an interesting idea | 13:32 |
| zyga | jdstrand: so we keep a strict profile for s-u-n | 13:32 |
| zyga | jdstrand: and if there's a good profile we transition | 13:33 |
| zyga | and if not we use the strict profile | 13:33 |
| zyga | jdstrand: how can we check if a profile with given name is loaded? | 13:33 |
| jdstrand | there is probably libapparmor api for that, but a look in sysfs is sufficient (eg, /sys/kernel/security/apparmor/profiles or /sys/kernel/security/apparmor/policy/profiles/) | 13:35 |
| jdstrand | zyga: ^ | 13:38 |
| zyga | yes, I was trying to avoid having to parse it now | 13:39 |
| zyga | but sure | 13:39 |
| jdstrand | zyga: so you can either parse /sys/kernel/security/apparmor/profiles or do a smart glob on a directory name existence in /sys/kernel/security/apparmor/policy/profiles/ | 13:45 |
| jdstrand | zyga: you could aa_query_label() for a file that is expected to be allowed and check for ENOENT | 13:47 |
| jdstrand | zyga: could also adjust the logic a bit to look for ENOENT on the aa_change_onexec, and if it fails, aa_change_onexec to the child profile instead (thus removing the Cx rules, but adding a change_profile rule for the child) | 13:50 |
| jdstrand | zyga: that last suggestion is probably clearest in terms of intent wrt fallback | 13:51 |
| zyga | yes | 13:52 |
| zyga | I think that's sensible | 13:52 |
| zyga | let's discuss this soon | 13:52 |
| jdstrand | then no parsing | 13:52 |
| zyga | yes | 13:53 |
| Trevinho | Hey.. question, if I close a channel (say candidate), the people will be moved to stable version... But, if a new revision is released to candidate, all the people who were tracking it will keep it or not? Do they manually to go back to track it? | 13:57 |
| Trevinho | I mean when we say that people will be moved to the safest risk level, is that related to the snap revision or also to the track itself? | 13:58 |
| * zyga relocates | 14:01 | |
| Chipaca | Trevinho: they're tracking candidate, if you reopen candidate and release something into it, they'll get it | 14:01 |
| Trevinho | Chipaca: ok good.. That was what I was assuming, but just to double-check | 14:01 |
| Chipaca | Trevinho: that's the "tracking" field in "snap info" | 14:01 |
| Trevinho | as docs didn't mention it | 14:01 |
| Chipaca | ogra_: ooh, ooh, could you copy _everything_ from cache to the inside? | 14:03 |
| Chipaca | ogra_: another question: how do you update it | 14:03 |
| Chipaca | ogra_: ie those cache files should get updated periodically... | 14:03 |
| jdstrand | mvo: where is the hangout? | 14:03 |
| mvo | jdstrand: https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1 but zyga is looking for a quiet place to join right now | 14:05 |
| mvo | jdstrand: so we may need to wait ~2 more minutes | 14:05 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | Chipaca, we never update the chroot (any of it ...) it is really only to provide you apt/dpkg for development, not for any other use | 14:28 |
| Chipaca | ogra_: hmmmm | 14:28 |
| ogra_ | so it is really only a snapshot of the moment you create the chroot | 14:28 |
| Chipaca | ogra_: could we have a .bashrc saying "Your classic environ is now XYZ days old, time to nuke it"? | 14:29 |
| ogra_ | (it wont allow to run any services or inbteract with snapd on the host or anything either) | 14:29 |
| Chipaca | ogra_: somebody, somewhere is building an IoT device gateway on top of that :-) | 14:42 |
| Chipaca | (that's not a fact, just statistics) | 14:42 |
| ogra_ | someone should stop him then ;) | 14:42 |
| ogra_ | it might be really hard to do that though ... given that you can not automatically run anything from classic after a reboot | 14:43 |
| ogra_ | if you need a real classic setup on top of core to run a product you'd hopefully use lxd or docker | 14:44 |
| ogra_ | and not some developer tool | 14:44 |
| ogra_ | (that is clearly marked as such) | 14:45 |
| Chipaca | ogra_: I'm 93% joking | 14:45 |
| ogra_ | yeah, but there are these 7% ! | 14:45 |
| ogra_ | :) | 14:45 |
| Chipaca | 5% wry cynicism, 2% other | 14:46 |
| Chipaca | :-) | 14:46 |
| ogra_ | (and there *is* at least one person trying to abuse it so you are not that far off ... https://github.com/snapcore/classic-snap/issues/15 ) | 14:47 |
| ogra_ | (havent found the time to answer yet ) | 14:47 |
| Chipaca | oh man, just two sentences into the bug and i'm already noped out | 14:47 |
| Chipaca | three sentences if you count 'hello there!' | 14:48 |
| ogra_ | heh | 14:48 |
| * Chipaca replies with "you should install expect" | 14:48 | |
| Chipaca | or maybe “run "/sbin/agetty -n --noclear -l /snap/bin/classic tty1" and then ...” | 14:50 |
| * Chipaca shuts up | 14:50 | |
| ogra_ | heh | 14:52 |
| Chipaca | ogra_: I mean, I've used mplayer as a filter to lpd to have a networked music player | 14:54 |
| Chipaca | ogra_: the above wouldn't frighten me in the least :-D | 14:54 |
| ogra_ | me neither ... but it isnt what classic is designed for ... | 14:55 |
| * Chipaca goes for a walk | 14:55 | |
| ogra_ | mplayer as filter to lpd ... to do what ? print song texts ? | 14:55 |
| ogra_ | (or is there some other lpd i dont know) | 14:56 |
| sergiusens | ogra_: where is the snapcraft project definition for the current build of `core`? | 14:58 |
| ogra_ | sergiusens, "sapcraft project definition" ? you mean snapcraft.yaml ? | 14:59 |
| sergiusens | yes | 14:59 |
| ogra_ | https://github.com/snapcore/core | 14:59 |
| sergiusens | ogra_: do you know where that is mirrored to on launchpad? core is such a generic name | 15:00 |
| ogra_ | scroll down ;) | 15:00 |
| ogra_ | it's in the README | 15:00 |
| sergiusens | thanks | 15:00 |
| jdstrand | mvo: since you are going forward with hardened profiles, it sounds like I do not need to be present in the followup hangout (I've got a number of things I need to do today) | 15:02 |
| cachio | Saviq, there? | 15:02 |
| jdstrand | mvo: I can make myself available to be pulled in if that is useful though (I may have a conflict, someone is trying to schedule a meeting today with a partner that I've been asked to attend) | 15:03 |
| mvo | jdstrand: corret | 15:03 |
| mvo | jdstrand: I think its fine | 15:03 |
| mvo | jdstrand: we needed your input on the security questions, thanks for providing it | 15:03 |
| jdstrand | mvo: np. thanks to you, zyga and niemeyer on working through this | 15:05 |
| mup | PR snapcraft#2021 opened: Only mangle elf app <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2021> | 15:06 |
| mup | PR snapd#4907 opened: advisor: deal with missing commands.db file <Created by mvo5> <https://github.com/snapcore/snapd/pull/4907> | 15:09 |
| mup | PR snapd#4904 closed: tests: change debug for layout test (2.32) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4904> | 15:10 |
| Saviq | cachio: hey | 15:13 |
| cachio | Saviq, 2 things | 15:14 |
| cachio | first, the image for fedoras was renamed, so yo dont need to add the image anymore | 15:15 |
| cachio | Saviq, 2nd I found the problem with resizing, but I need to agree how to fix it, if you need a temporal workaround, you can add these 2 lines to your tests (at the beginind) | 15:16 |
| cachio | sudo growpart /dev/sda 1 | 15:16 |
| cachio | sudo resize2fs /dev/sda1 | 15:16 |
| cachio | that will force the partition resizing | 15:16 |
| cachio | niemeyer, I have a fix for spread to force the resizing that be default is not being done in fedora or centos | 15:17 |
| cachio | niemeyer, it is automatic on ubuntu/debian but you need to do it manually for other deistros | 15:17 |
| cachio | I made a fix for spread, addthis these 2 lines to the googleStartupScript | 15:18 |
| cachio | and it works | 15:18 |
| cachio | niemeyer, this is the PR https://github.com/snapcore/spread/pull/54 | 15:23 |
| mup | PR spread#54: Add the resize of the partition on the googleStartupScript <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/54> | 15:23 |
| Saviq | cachio: I'll wait, we're fine on linode for now | 15:24 |
| niemeyer | cachio: What does it automatically in Debian and Ubuntu? | 15:25 |
| cachio | niemeyer, resize the partition | 15:26 |
| cachio | and the disk as well | 15:26 |
| Saviq | cloud-init | 15:26 |
| cachio | but, in centos or fedora it is not happening | 15:26 |
| cachio | in the forums other people is facing the same problem | 15:27 |
| niemeyer | cachio: Yes, *what* is doing it | 15:27 |
| cachio | gogole compute init | 15:27 |
| Saviq | cachio: you sure it's not cloud-init http://cloudinit.readthedocs.io/en/latest/topics/examples.html?#grow-partitions ? | 15:28 |
| cachio | google-compute-engine-init | 15:28 |
| niemeyer | cachio: If it's the same software, why does it do in one image and not the other? | 15:28 |
| cachio | google-compute-init calls to cloud init | 15:28 |
| cachio | niemeyer, I don't know | 15:29 |
| cachio | can't find the code yet | 15:29 |
| niemeyer | cachio: OK, so that's what we need to find out | 15:30 |
| cachio | niemeyer, ok | 15:30 |
| cachio | Saviq, is it running resize2fs as well? | 15:31 |
| cachio | or just growpart? | 15:31 |
| Saviq | cachio: both | 15:33 |
| ogra_ | iirc growpart is a python script that shells out to a ton of shell binaries ... | 15:33 |
| ogra_ | (resize2fs among them) | 15:33 |
| cachio | Saviq, ok, tx | 15:34 |
| mup | PR snapd#4908 opened: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908> | 15:35 |
| mborzecki-ubuntu | zyga: ^^ a little experiment, at least I see the 'nvidia segfault' now | 15:36 |
| Chipaca | niemeyer: snapshots pr has all local changes other than tests (and even some of those, but i'm adding more right now) | 15:42 |
| niemeyer | Chipaca: Super, thank you | 15:43 |
| mborzecki-ubuntu | zyga: aaand got it working now :P | 15:48 |
| mborzecki-ubuntu | zyga: and ohmygiraffe works now | 15:59 |
| zyga | Sweet | 16:00 |
| zyga | The way we discussed? | 16:00 |
| mborzecki-ubuntu | adding a note in the forum topic | 16:00 |
| mborzecki-ubuntu | zyga: take a look at the PR | 16:01 |
| mborzecki-ubuntu | need to wrap it up for today, still have to make arch boot again :/ | 16:02 |
| zyga | I will back home | 16:04 |
| zyga | I’m on a bus now | 16:04 |
| zyga | Thank you! | 16:04 |
| pedronis | mvo: after discussion, what's the plan/timing about releasing 2.32 now ? | 16:15 |
| mvo | pedronis: release to candidate asap (ideally today), keep in candidate for a week is the current plan | 16:16 |
| pedronis | ok | 16:17 |
| pedronis | thx for the update | 16:17 |
| mvo | pedronis: yw - given the short time between that and the relase I think there will be a .1 and no .33 for 18.04-final. the .33 will then be a normal SRU | 16:18 |
| mvo | pedronis: does that sounds reasonable? i.e. the delay registraion prs will need to be ported | 16:18 |
| pedronis | mvo: ok, will need to discuss what goes into .1, ideally delay of registration | 16:18 |
| mvo | pedronis: yeah, we can put everything important in there, it just feels risky to do full .33 before the bionic final release | 16:19 |
| cachio | niemeyer, I fixed the problem | 16:37 |
| cachio | it was a dependency missing | 16:37 |
| niemeyer | cachio: Oh, tell me more | 16:37 |
| cachio | niemeyer, for fedora we need to install gce-disk-expand | 16:38 |
| cachio | which has conflicts with cloud-utils-growpart | 16:38 |
| cachio | so we need to remove cloud-utils-growpart and then install gce-disk-expand | 16:38 |
| cachio | this is in charged of making the resize | 16:39 |
| cachio | cloud init is not used for that | 16:39 |
| cachio | I am gonna upload a new image | 16:39 |
| cachio | and deprecate the old one | 16:39 |
| niemeyer | cachio: After you're done with this, can you please send a message to the forum with all the details of how to get the image in place and working? | 16:40 |
| cachio | niemeyer, sure | 16:40 |
| cachio | niemeyer, just for fedora or all the images that we use? | 16:41 |
| niemeyer | cachio: In N months I'm sure we'll be creating an image for a different distro, or for a new release of an existing distro, and will try to remember these details | 16:41 |
| niemeyer | cachio: It can even be something more high-level | 16:41 |
| cachio | niemeyer, sure, I am going to add also those scripts to spread-cron soon | 16:41 |
| niemeyer | cachio: For no particular distro.. just the process of how to cook the image and make sure it's working | 16:41 |
| cachio | niemeyer, ahh, ok | 16:41 |
| niemeyer | cachio: It may end up as a mix of the different images.. e.g. maybe there's a detail that is needed for Fedora, and another one for OpenSUSE.. we want both of these details, but no need to repeat what is the same for both | 16:42 |
| cachio | niemeyer, ok | 16:42 |
| niemeyer | cachio: Yeah, the script is important as we don't want to build those images by hand.. but since all of that is so fresh in your mind, it's good to put down in text so we can easily digest in several months | 16:43 |
| cachio | niemeyer, yes, totally agree | 16:44 |
| cachio | niemeyer, months or weeks :) | 16:44 |
| niemeyer | cachio: Thanks! | 16:44 |
| niemeyer | Yes :) | 16:44 |
| zyga | re | 16:46 |
| zyga | I'm back now | 16:46 |
| zyga | I'll unpack and I can return to work in a few minutes | 16:46 |
| * kalikiana pipes zyga into `tar -xJf` | 17:04 | |
| zyga | haha | 17:08 |
| zyga | now I need to go on a diet, I'm so much bigger than before :D | 17:08 |
| kalikiana | :-D | 17:08 |
| * kalikiana wrapping up for the day and looking forward to getting a little bigger over dinner as well | 17:09 | |
| niemeyer | mvo, zyga: Ready when you are | 17:10 |
| zyga | niemeyer: [m]vo went for dinner just now | 17:11 |
| zyga | let's wait for him to be back | 17:11 |
| niemeyer | zyga: Sounds good | 17:11 |
| * Chipaca going offline for a while | 17:21 | |
| cachio | zyga, when you have a minute, could you plese take a look to #4778 | 17:28 |
| mup | PR #4778: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778> | 17:28 |
| cachio | ? | 17:28 |
| cachio | mvo, today is comming new beta, right? | 17:28 |
| zyga | +1 | 17:29 |
| zyga | cachio: yes, hopefully ;) | 17:29 |
| cachio | zyga, tx | 17:29 |
| mup | PR snapd#4778 closed: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4778> | 17:30 |
| zyga | OHHH | 17:34 |
| zyga | I just had a mini-heart-attack | 17:34 |
| zyga | I checked out release/2.23 by accident | 17:34 |
| zyga | and was looking at the set of patches to backport | 17:34 |
| zyga | and OMG what's wrong | 17:34 |
| cachio | zyga, heart-attack are delayed for 2.34 | 17:37 |
| cachio | :) | 17:37 |
| zyga | man :) | 17:37 |
| zyga | 2.23 | 17:37 |
| zyga | 2.32 | 17:37 |
| zyga | so silly | 17:37 |
| zyga | :) | 17:37 |
| cachio | zyga, similar happened to me last week | 17:40 |
| cachio | :) | 17:40 |
| mup | PR snapd#4909 opened: interfaces: harden snap-update-ns profile (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4909> | 17:41 |
| mup | PR snapd#4910 opened: interfaces/apparmor: simplify UpdateNS internals <Created by zyga> <https://github.com/snapcore/snapd/pull/4910> | 17:42 |
| zyga | jdstrand: stuff from the sprint ^ | 17:43 |
| zyga | I just recall this existed because I remembe writing it but coudn't see it in master | 17:47 |
| zyga | comitted 16 days ago, I forgot to propose it | 17:49 |
| jdstrand | zyga: I recall this being called out in a previous PR. thanks! approved, but please do the requested comment change | 17:58 |
| zyga | ook | 17:58 |
| jdstrand | it is so easy to forget to update the comments. I did it the other day... | 17:59 |
| flexiondotorg | davdunc o/ | 18:03 |
| davdunc | thanks. | 18:03 |
| zyga | niemeyer: I think we can have that call soon | 18:04 |
| niemeyer | zyga: Still here | 18:04 |
| niemeyer | Just waiting for you and mvo | 18:04 |
| mvo | niemeyer: ready | 18:05 |
| niemeyer | Ok, let's go | 18:05 |
| === pstolowski is now known as pstolowski|afk | ||
| mup | PR snapcraft#2021 closed: pluginhandler: only resort to elf mangling if the snap type is app <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2021> | 18:47 |
| mup | PR snapd#4819 closed: interfaces/serial: change pattern not to exclude valid devices <Created by bergotorino> <Closed by bergotorino> <https://github.com/snapcore/snapd/pull/4819> | 19:10 |
| mup | PR snapd#4819 opened: interfaces/serial: change pattern not to exclude valid devices <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819> | 19:27 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#4911 opened: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911> | 19:53 |
| mup | PR snapd#4906 closed: polkit: Pass caller uid to PolicyKit authority <Critical> <Created by chrisccoulson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4906> | 19:55 |
| mup | PR snapd#4910 closed: interfaces/apparmor: simplify UpdateNS internals <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4910> | 20:03 |
| mwhudson | Laney: re testing casper changes i have this script that mounts an iso, creates an overlay over it, drops you into a shell the repacks a new iso when you exit the shell | 20:23 |
| mwhudson | (and does some other stuff) | 20:23 |
| mwhudson | would that be useful for this sort of thing? | 20:23 |
| cachio | niemeyer, well, gce-disk-expand package does not work well in fedora | 21:09 |
| cachio | it works well in CentOS, redhat, RHEL and cloudlinux | 21:10 |
| cachio | but fails to start in fedora | 21:10 |
| cachio | ubuntu and debian automatically resize the partition when the disk has been resized | 21:10 |
| cachio | bet the other OSs are not doing that | 21:10 |
| cachio | this project creates a service which makes the resize after reboot, so you can resize a disk for an instance which is already running | 21:12 |
| cachio | Pharaoh_Atem, hey | 21:20 |
| cachio | I am trying to make fedora resize the partition /dev/sda1 when the system starts in google | 21:20 |
| cachio | most of the sytems are resizing the partition when the disk sda is resized | 21:21 |
| cachio | but in fedora it is not happening | 21:21 |
| cachio | any idea how to do it? | 21:21 |
| cachio | the only way I could make it work was adding the resize command as part of the machine init script | 21:22 |
| cachio | I am using the fedora cloud image + some google dependecies | 21:22 |
| pedronis | mvo: what's the plan with #4911, will it mean we need snapd running (always) for snap run? feel free to answer tomorrow, just asking/wondering before I forget | 21:33 |
| mup | PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911> | 21:33 |
| mvo | pedronis: we discussed this with zyga and niemeyer and the idea is that if snap run detects a system-key change it should talk to snapd to double check what is going on | 21:35 |
| pedronis | I see, so a 2nd line of check | 21:35 |
| mvo | pedronis: so this communication would only happen in the (rare) case when the system-key that snap run calculates and that is on disk mismatch | 21:35 |
| mvo | pedronis: exactly | 21:35 |
| pedronis | thanks for the answer | 21:36 |
| mvo | pedronis: I think there are still some corners to think about, what if its a local build of snapd run for testing, how should snapd behave. but I think all the open questions are really the developer case, i.e. you run snapd or snap from a local build | 21:36 |
| pedronis | mvo: I'm probably confused, are you off tomorrow? or starting monday? | 21:40 |
| mvo | pedronis: technically tomorrow but the amount of fires make it unlikely | 21:43 |
| mvo | pedronis: so I will swap that day with another day | 21:44 |
| pedronis | ok, makes (sadly) sense | 21:44 |
| mvo | pedronis: yes | 21:54 |
| mvo | 4882 is a fun PR to review if someone feels inclined to do so :) | 21:55 |
| Laney | mwhudson: that sounds nice, you should make it available | 22:54 |
| Laney | mwhudson: for the casper scripts you have to update the initramfs and then make that available in casper/initrd.lz (iirc) too | 22:55 |
| cachio | niemeyer, please tell me if this makes sense https://github.com/snapcore/spread/pull/55 | 23:00 |
| mup | PR spread#55: Make possible to add an initialization script for custom images <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/55> | 23:00 |
| mup | PR snapd#4912 opened: overlord/configstate: change how ssh is stopped/started <Created by zyga> <https://github.com/snapcore/snapd/pull/4912> | 23:52 |
| zyga | niemeyer: ^ | 23:55 |
| bashingboi | has anyone tried the firefox snap in debian/centos? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!