| Hilikus | how can i configure my wireless adapter in ubuntu core? in the initial setup i wanted to use the ethernet port but now i want to configure wifi | 02:50 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| zyga | morphis: hey | 06:16 |
| morphis | zyga: hey! | 06:17 |
| morphis | zyga: nice talk :-) | 06:17 |
| zyga | morphis: thank you :) | 06:20 |
| morphis | zyga: feedback was positive too? | 06:20 |
| zyga | morphis: yes, though there were specific issues raised as well | 06:21 |
| morphis | interesting :-) | 06:21 |
| zyga | morphis: we need to get snapd into factory, piece by piece | 06:21 |
| mup | PR snapd#3404 opened: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3404> | 06:21 |
| zyga | morphis: from there we can go to tumbleweed and SLE | 06:21 |
| morphis | you heard any response on the question for vendoring? | 06:22 |
| zyga | no | 06:22 |
| zyga | but the people packaging go were not present, we should reach out to them | 06:22 |
| zyga | my suspicion is that we may have to devendorize | 06:22 |
| morphis | zyga: you have any contacts at hand? | 06:25 |
| zyga | no, but I know how to find them | 06:26 |
| zyga | suse employee now manages all of golang, I just need a google to find ihm | 06:26 |
| mup | PR snapd#3404 closed: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3404> | 06:28 |
| morphis | zyga: great | 06:29 |
| morphis | zyga: any other interesting things? | 06:30 |
| zyga | morphis: btw, is it expected that socket and services are off after installation? | 06:30 |
| morphis | yes | 06:30 |
| morphis | we don't have a preset | 06:30 |
| zyga | morphis: yes, plenty but I need to write down some things first | 06:30 |
| morphis | same problem as on fedora | 06:30 |
| morphis | zyga: see https://snapcraft.io/docs/core/install-opensuse | 06:31 |
| morphis | you need to call: $ sudo systemctl enable --now snapd.socket | 06:31 |
| zyga | oh | 06:31 |
| zyga | those instructions | 06:31 |
| zyga | need to patch them to include -r | 06:31 |
| zyga | or something likethat | 06:31 |
| zyga | to automatically refresh that repo | 06:31 |
| zyga | otherwise you get stuck on stale | 06:31 |
| morphis | -r for what? | 06:31 |
| morphis | systemctl? | 06:31 |
| zyga | no | 06:31 |
| zyga | zypper addrepo | 06:32 |
| zyga | run that with --help | 06:32 |
| mup | PR snapd#3405 opened: tests: fix for upgrade test when it is repeated <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3405> | 06:32 |
| morphis | zyga: I see | 06:33 |
| abeato | zyga, hey, waiting for you input in https://github.com/snapcore/snapd/pull/3353 | 06:35 |
| mup | PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353> | 06:35 |
| mup | PR snapd#3406 opened: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406> | 06:41 |
| morphis | zyga: ^^ | 06:41 |
| zyga | abeato: hey, I'm traveling today so I think I will only get to that tomorrow, sorry | 06:41 |
| abeato | zyga, ack, nw | 06:42 |
| === JanC_ is now known as JanC | ||
| abeato | ogra_, hi, is https://github.com/snapcore/core-build/pull/13 good now or you need to do some further review? | 08:10 |
| mup | PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13> | 08:10 |
| ogra_ | abeato, approved | 08:26 |
| * zyga heads to the airport | 08:26 | |
| zyga | ttyl | 08:26 |
| abeato | ogra_, thanks! | 08:27 |
| ogra_ | mvo, when exactly do we copy the kernel to the vfat on arm core images, is that in prepare-image when building the img or only later in firstboot ? (there is still quite a slowdown on arm boards before console-conf comes up on first boot) | 10:01 |
| mup | PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all} <Created by mvo5> <https://github.com/snapcore/core/pull/48> | 10:02 |
| mvo | ogra_: pretty sure we do it in prepare-image, what kind of slowdown do you still see? minutes? | 10:03 |
| ogra_ | mvo, i worked on a new bbb gadget on the weekend and there it is about 1.5-2min sitting there before "please press enter"" shows up | 10:04 |
| mvo | ogra_: ok, I need to look, pretty sure we skip unpacking the kenrel itself, but there is probably copying of snap from seed to disk, iirc we optimized this away but maybe I misremember | 10:06 |
| mvo | ogra_: lets talk after lunch | 10:06 |
| ogra_ | yeah | 10:06 |
| ogra_ | mvo, btw ... new shiny https://github.com/ogra1/beaglebone-gadget ... ;) (builds everything completely from source from upstream u-boot) | 10:07 |
| zyga | o/ | 10:47 |
| zyga | mvo: hey, how's everything? | 10:48 |
| zyga | morphis: are you subscribed to the factory mailing lisdt? | 10:52 |
| morphis | zyga: no | 10:52 |
| morphis | zyga: you have a link? | 10:52 |
| zyga | morphis: sure, one sec | 10:52 |
| zyga | https://lists.opensuse.org/opensuse-factory/ | 10:53 |
| zyga | let's say hi there and announce our intent to package snapd golang dependencies | 10:53 |
| zyga | snapd by itself will land last because of extra security review needs/ | 10:53 |
| ogra_ | hmm ... | 10:54 |
| * ogra_ looks at https://sourceforge.net/p/tuxbox-cvs/boot/ci/321c664f88011fa152031d7fbb22b68893daa320/tree/u-boot-tuxbox/fs/ ... | 10:54 | |
| zyga | I think that we want to have a feeling of how opensuse golang packages look like today | 10:54 |
| ogra_ | too mbad thats for a very old uboot version and also only uses squashfs 2.x | 10:54 |
| zyga | and come up with a leaf package that can be sent out | 10:54 |
| ogra_ | but it could save us from kernel-in-vfat on arm ... | 10:55 |
| morphis | zyga: sounds like a plan | 10:55 |
| zyga | morphis: I asked on IRC but I'll keep looking | 10:56 |
| zyga | morphis: I'm away from my suse machines now (and this laptop has not enough memory to run VMs for real :-( so I won't be able to try until tomorrow | 10:56 |
| * zyga will be home at 23:00 :-( | 10:56 | |
| morphis | zyga: ok | 10:56 |
| zyga | morphis: have you seen jamie bennett today? | 10:57 |
| morphis | zyga: I saw mails from him :-) | 10:57 |
| zyga | https://en.opensuse.org/openSUSE:Packaging_guidelines and https://en.opensuse.org/openSUSE:Packaging_Go | 10:59 |
| morphis | zyga: yeah, I know these | 11:02 |
| zyga | morphis: also https://lists.opensuse.org/opensuse-factory/2017-02/msg00002.html | 11:03 |
| morphis | :-) | 11:04 |
| morphis | smells like a world with no written rules yet | 11:04 |
| pstolowski | mvo, hey, i need your help. i'm having issues with spread tests on my machine, they fail even in master when building the deb with 'dh_install: usr/bin/uboot-go exists in debian/tmp but is not installed to anywhere' | 11:36 |
| pstolowski | mvo, evidence says you may know something about this package ;) (and I've it in my vendor/) | 11:37 |
| mvo | pstolowski: have you merged master? could you please double check that your vendor is clean | 11:37 |
| mvo | pstolowski: the uboot-go stuff recently got moved from something external to an internal thing so probably you see fallout from that | 11:37 |
| pstolowski | mvo, git clean -fd would do it right? | 11:39 |
| mvo | pstolowski: -x but its quite dangerous, rm -rf vendor/githhub.com might be easier. and then ./get-deps.sh | 11:40 |
| pstolowski | mvo, ok, will try that, thanks | 11:41 |
| mvo | pstolowski: good luck, please keep me update | 11:41 |
| mvo | d | 11:41 |
| morphis | mvo, pstolowski: I saw the same this morning, fetching deps again helped to solve that issue | 11:55 |
| pstolowski | mvo, morphis yay, thanks, removing vendor and refreshing it helped | 11:59 |
| mvo | great | 12:00 |
| mvo | sorry for the trouble | 12:00 |
| morphis | mvo: you have time for a review on https://github.com/snapcore/snapd/pull/3365 ? | 12:16 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 12:16 |
| morphis | fgimenez: ^^ | 12:16 |
| fgimenez | morphis: sure, i'll take a look | 12:19 |
| morphis | fgimenez: thanks! | 12:22 |
| mup | PR snapd#3407 opened: interfaces: move seecomp profiles to /var/lib/snapd/seccomp/profiles-v2/ <Created by mvo5> <https://github.com/snapcore/snapd/pull/3407> | 12:24 |
| mvo | morphis: I can look in a bit, a bit busy with the 2.24->2.25->2.24 revert problem. quick question - can we share code with snap-mgmnt.sh and snapd.postrm purge? it seems there is a bit of duplication and given that this is realy non-trivial it worries me a little bit that we duplicate it currently | 12:27 |
| morphis | mvo: yes, but would like to do that in another PR | 12:28 |
| morphis | mvo: as there are a few differences too | 12:28 |
| mvo | morphis: aha, interessting, sure a different PR is totally fine. curious about the differences. just because of different paths? /snap vs /var/lib/snap ? | 12:29 |
| morphis | mvo: no, not just the paths, but the Ubuntu variant does a rm -rf /var/lib/snapd where as the rpm pkg relies on rpm removing that etc. | 12:29 |
| morphis | nothing fancy but small differences | 12:29 |
| morphis | and actually Son_Goku wanted to do that if I remember right | 12:29 |
| mvo | morphis: aha interessting, | 12:29 |
| mvo | morphis: so rpm will remove even untracked files in there? | 12:30 |
| morphis | no, the script as to clean those | 12:30 |
| mvo | morphis: aha, I see its only removing things that are not tracked, we could do the same in the postrm | 12:30 |
| morphis | but rpm isn't happy if the dir is removed by something else | 12:30 |
| mvo | morphis: anyways, this should not be a blocker for unification :) | 12:31 |
| morphis | jepp, we have that on the list and will unite those things, makes only sense and becomes easier now that we have all packaging bits together | 12:31 |
| mvo | morphis: +1 - thank you! | 12:32 |
| niemeyer | Morning all | 12:33 |
| morphis | niemeyer: morning! | 12:34 |
| niemeyer | morphis: Heya | 12:34 |
| niemeyer | morphis: How's that SuSE machine going? Do you want to give it a shot again? | 12:34 |
| morphis | niemeyer: I didn't had time to clean it up yet again | 12:34 |
| morphis | but will do that in the afternoon | 12:35 |
| mvo | hey niemeyer, good morning | 12:35 |
| morphis | niemeyer: time for a review on https://github.com/snapcore/snapd/pull/3365 and https://github.com/snapcore/snapd/pull/3394 today? | 12:38 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 12:39 |
| mup | PR snapd#3394: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3394> | 12:39 |
| niemeyer | morphis: Looking now | 12:39 |
| morphis | niemeyer: thanks! | 12:39 |
| niemeyer | morphis, Son_Goku: One thing I was wondering about last week was that purging logic. It looks like we have a lot of duplicated logic between the deb package and the rpm package. This logic looks pretty easy to get wrong, and twice is twice the chances.. | 12:40 |
| morphis | niemeyer: I've just talked about the same thing with mvo minutes before you joined | 12:41 |
| mvo | jdstrand: when you around I would love to talk about 3407 | 12:41 |
| morphis | niemeyer: the unification of that logic is the goal but that requires a few more small steps to do that right and refactorings | 12:41 |
| morphis | niemeyer: actually Son_Goku wanted to do that | 12:41 |
| mvo | jdstrand: i.e. something to do short term to unblock us and then I think a schema that makes seccomp similar to apparmor with cache etc would be cool | 12:42 |
| morphis | niemeyer: I would leave that up to another PR and concentrate on the spread bits for fedora here but unification of that logic is definitely one of the next steps | 12:42 |
| niemeyer | morphis, Son_Goku: Aha, okay.. yeah, not suggesting it to be done in this PR | 12:42 |
| jdstrand | mvo: hey, I commented. I don't really think new directories are the path forward. have we seen this as a real issue people are facing (again, this is something that was there all along) | 12:49 |
| jdstrand | ? | 12:49 |
| mvo | jdstrand: yes, CE found this while doing testing on a real device and we have a reproducer, the particular issue is the network-manager snap which starts early and if it fails there is no networking | 12:50 |
| mvo | jdstrand: I agree with your concerns, however I have a hard time finding a way to fix this issue without introducing a new path, i.e. violating this design contrain for this one time | 12:51 |
| jdstrand | mvo: but it won't be for this one time. if you add the directory, then it will be there forever, no? | 12:52 |
| mvo | jdstrand: yeah, the old dir will be phased out but yes, its ugly | 12:53 |
| jdstrand | but it can't be phased out, right? I mean, you can revert to anywhere | 12:53 |
| jdstrand | I'd much rather drop the mknod and reintroduce it later than add a directory | 12:54 |
| mvo | jdstrand: correct, we can never remove it. however noone will see the old dir if the device starts out with snapd 2.26.X because only older versions would ever write it | 12:54 |
| jdstrand | sure, but then we have -v2 there | 12:54 |
| jdstrand | (icky) | 12:54 |
| jdstrand | I mean, don't get me wrong, I understand why, just it's icky | 12:55 |
| jdstrand | mvo: what are the requirements for this fix? | 12:55 |
| mvo | jdstrand: yeah, I will not fight for it, I think its ugly too, I'm keen to find something better :) | 12:55 |
| mvo | jdstrand: the fix would allow us to go 2.24->2.25->2.24 (and also other version like 2.21->2.26->2.21) without breaking, this is why I'm not sure that reverting the mknod one really helps that much as we will have to re-introduce it at some point and then we write an incompatilbe profile again and have the same issue as now (?) | 12:57 |
| mvo | jdstrand: I have the standup now, so if you have time we can continue to brainstorm in ~45min ? | 12:58 |
| jdstrand | ok | 12:58 |
| mvo | jdstrand: fwiw, I'm also working on a seccomp-profile -> bpf tool that should also help but it won't help with 2.24 as that does not know anything about this yet (following your suggestions to model it after apparmor and its txt->cache) | 13:00 |
| * jdstrand nods | 13:00 | |
| === om26er_ is now known as om26er | ||
| pstolowski | mvo, one more think i'm having issue with.. any idea where does a bizzare version number such as 'Get:1 /home/gopath/snapd_1337.2.26.3_amd64.deb snapd amd64 1337.2.26.3' may be coming from? that's what makes my tests fail still | 13:16 |
| ogra_ | but it is leet ! | 13:16 |
| Son_Goku | mrgh? | 13:17 |
| Son_Goku | I seem to have been mentioned a lot in the last few hours... | 13:19 |
| Son_Goku | mvo, niemeyer: the creation of snap-mgmt.sh is because there was a bug filed about how snapd couldn't clean itself up on uninstall in the Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1444422 | 13:20 |
| mvo | Son_Goku: yeah, the script is great, we would just like to share some more code but morphis_ assured us its already on the list | 13:25 |
| Son_Goku | it took quite a few tries to generalize it :) | 13:26 |
| morphis_ | Son_Goku: :-) | 13:26 |
| morphis_ | Son_Goku: do you want to generalize is a bit more so it's usable on Debian/Ubuntu too? | 13:26 |
| Son_Goku | there's really only one thing that has to be done: make it so that snapd.postrm's SNAP_MOUNT_DIR is taken into account | 13:27 |
| Son_Goku | rest of it should work | 13:27 |
| Son_Goku | and the postrm needs to be a prerm | 13:27 |
| Son_Goku | the Debian packaging is quite hard to get right for file/folder tracking, though | 13:28 |
| Son_Goku | as there's no concept of a file list in Debian source control packaging like there is in spec packaging | 13:28 |
| Son_Goku | my snap-mgmt.sh is intended to be run by a package manager that actually can track files properly | 13:29 |
| Son_Goku | as far as I know, the only files dpkg fully tracks are conffiles | 13:29 |
| Son_Goku | mvo, unless I've missed something? | 13:29 |
| mvo | Son_Goku: in a meeting right now so a bit slow. I think we can talk about details, dpkg does track files (not dirs which can be surprising) so things should work out, but lets look at the details in a little bit | 13:31 |
| pstolowski | mvo, http://pastebin.ubuntu.com/24703100/ | 13:46 |
| pstolowski | mvo, it looks like we expect "unknown" keyword in the version, but for some reason I've this 1337... number | 13:46 |
| pstolowski | mvo, I'm not sure what we're trying to test there | 13:46 |
| mvo | pstolowski: hm, this is odd, could you add a bit more lines to the pastebin please? | 13:52 |
| mvo | pstolowski: I see something like this in tests/lib/prepare.sh but the error does not match the pastebin so maybe it is something else? | 13:53 |
| pstolowski | mvo, http://pastebin.ubuntu.com/24703148/ | 13:54 |
| pstolowski | mvo, i've this session opened for debugging.. and indeed I see snap 1337.2.26.3 | 13:54 |
| pstolowski | snapd 1337.2.26.3 | 13:54 |
| mvo | pstolowski: that should be ok, what does `snap changes` and especially the last change (the one about the refresh-schedule) show? that seems to be the root cause, we need to figure out why that fails | 13:57 |
| mvo | pstolowski: aha! snap set core refresh.schedule=Wed@12:00-14:00 | 13:57 |
| mvo | pstolowski: the "weekday@something" is not supported currently, only refresh schedules in a single day | 13:57 |
| mvo | pstolowski: where does that come from? | 13:57 |
| pstolowski | mvo, it's my branch, in sync with master; but I haven't added or touched that | 13:58 |
| pstolowski | mvo, prepare has it: snap set core refresh.schedule="$(date +%a --date=2days)@12:00-14:00" | 13:59 |
| pstolowski | prepare.sh | 13:59 |
| niemeyer | morphis_: snapd#3365 reviewed | 14:00 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 14:00 |
| morphis_ | niemeyer: thanks | 14:00 |
| pstolowski | mvo, what happens if you try this unsupported syntax? it ignores all that and refreshes during the test? | 14:01 |
| mvo | pstolowski: is that maybe based on some older branch? could you merge master please? | 14:03 |
| mvo | pstolowski: this syntax will lead to an error | 14:03 |
| pstolowski | mvo, i'm up-to-date with master, and master has it too | 14:05 |
| mvo | pstolowski: let me check, thats slightly odd | 14:06 |
| mvo | pstolowski: I see it here as well | 14:07 |
| mvo | pstolowski: interessting bug | 14:09 |
| mvo | pstolowski: definitely something wrong with this test setup, the interessting question is of course why only you hit it | 14:10 |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | mvo, indeed. i'm hitting it also with master | 14:23 |
| fgimenez | pstolowski: are you executing from a clean (just cloned) master on a linode backend? to reproduce the exact conditions of a working environment you could also get the spread binary as travis does https://github.com/snapcore/snapd/blob/master/run-checks#L178 | 14:36 |
| pstolowski | thanks fgimenez, i will try that | 14:37 |
| niemeyer | morphis_: 3394 reviewed as well | 14:45 |
| morphis_ | niemeyer: nice! | 14:47 |
| mup | PR snapd#3408 opened: tests: add alsa interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3408> | 15:00 |
| niemeyer | Week 22 report is out, and lunch is out too.. biab | 15:15 |
| niemeyer | Erm.. week 21 I mean.. | 15:15 |
| niemeyer | Week 22 is the one we're in.. feel free to send topics in | 15:16 |
| jdstrand | mvo: are you able to discuss now? | 15:23 |
| ogra_ | wohoo | 15:24 |
| * ogra_ just had two different initrd.img files loaded in u-boot and they are merged! | 15:24 | |
| ogra_ | firsdt step towards modules-only initrd | 15:25 |
| ogra_ | *first | 15:25 |
| mvo | jdstrand: I updated the forum topic, I need to step out for 10min and soon dinner | 15:28 |
| mvo | jdstrand: I put my thoughts into https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-revert-race-condition/722/6 - feedback welcome. also happy to hear if you or niemeyer have some more ideas what we can do short term | 15:28 |
| jdstrand | mvo: I think we should remove the mknod calls in a 25 point release, then discuss how to handle 25 to 26 | 15:29 |
| jdstrand | mvo: I commented in the pr | 15:33 |
| mvo | jdstrand: thank you! | 15:47 |
| mvo | niemeyer: you mentioned you would like to talk about it some more, do you want a hangout or some more forum discussion? I'm happy either way, just today is inconvinient, I will have to run in some minutes to play hockey, tomorrow will be fine though | 15:48 |
| niemeyer | mvo: SOunds good, let's do it | 15:49 |
| niemeyer | mvo: tomorrow, that is | 15:49 |
| mvo | niemeyer: thanks | 15:49 |
| niemeyer | mvo: As mentioned there, the immediate solution is starting to sound a lot like the long term one, so we should at least brainstorm a bit to see how to these two play together | 15:49 |
| mvo | niemeyer: yeah, it sounds like they converge nicely, i.e. our hash could simply be "seccomp-syntax: v2|hash" and thats all the inputs we do for now, we just need to tweak snap-confine so that it knows from what dir to read, i.e. something in snapd needs to tell snap-confine (it used to be hardcoded) | 15:51 |
| mvo | (our initial hash I mean) | 15:51 |
| mvo | niemeyer: actually given that this is the *only* input we have currently we could even cheat in snap-confine and hardcode the result of the hash (as we know its input already) - not sure if that is worth it though | 15:52 |
| niemeyer | mvo: As I just stated in the forum thread, stating the version explicitly won't do a lot for solving this particular case | 15:53 |
| niemeyer | It's a good practice and we should do regardless, but we know the profile is incompatible.. knowing it via a different field wouldn't really sort the problem out for us | 15:53 |
| niemeyer | mvo: Sorry.. I mixed stuff up | 15:54 |
| niemeyer | mvo: Precisely because I was talking in the forum about something else very close it it.. :/ | 15:54 |
| niemeyer | mvo: Yes, we might do something along those lines | 15:54 |
| mvo | niemeyer: yeah, I think I did not express myself well :) I meant specially the profile/<digest>/ input | 15:54 |
| niemeyer | mvo: It was really my brain that was hovering over a different part of the idea.. | 15:55 |
| mvo | niemeyer: excellent, I think we are on the same page, lets talk tomorrow, maybe jdstrand can join us too if he wants? | 15:55 |
| niemeyer | mvo: Yeah, let's discuss this tomorrow | 15:55 |
| mvo | niemeyer: thank you! | 15:56 |
| niemeyer | mvo: I don't think it makes sense to ask snapd to tell snap-cofnine what to read.. | 15:56 |
| niemeyer | mvo: This is part of the problem we have today | 15:56 |
| niemeyer | mvo: snap-confine can tell what it _can_ read | 15:56 |
| mvo | niemeyer: I see, yes | 15:57 |
| === cachio is now known as cachio_lunch | ||
| mvo | niemeyer: we will need two digest generators then, right? one in C and one in go? or we could use the go one and just popen() it (not really popen, but the concept) | 15:58 |
| niemeyer | mvo: Anyway, enjoy hockey! Let's catch up tomorrow | 15:58 |
| niemeyer | mvo: Yeah, not sure of the details.. | 15:58 |
| mvo | niemeyer: yeah, need to run, but an exciting problem to solve :) see you tomorrow | 15:58 |
| mvo | jdstrand: I'm also quite excited about the bpf generator, I think this will be superfun | 15:58 |
| === cachio_lunch is now known as cachio | ||
| mup | PR snapd#3409 opened: tests: fix snap confine from core test to check the restart was done <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3409> | 16:56 |
| morphis_ | niemeyer: 1.2G ok for you? | 17:03 |
| niemeyer | morphis_: Let's try that out to see how much it looks like in practice when doing the block-level resize | 17:04 |
| morphis_ | ok | 17:04 |
| morphis_ | niemeyer: Spread-53 it is | 17:06 |
| niemeyer | morphis_: On it | 17:06 |
| morphis_ | thanks! | 17:06 |
| cachio | niemeyer, is there any way to monitor the connections queue in the store? | 17:11 |
| niemeyer | cachio: Hmm.. which queue? | 17:11 |
| niemeyer | morphis_: This is still 1.86GB | 17:12 |
| cachio | niemeyer, is there any inbound connection request queue? | 17:12 |
| morphis_ | df shows me 1.2G | 17:12 |
| cachio | niemeyer, that the store processes? | 17:12 |
| niemeyer | That's the TCP queue I assume? | 17:12 |
| cachio | yes | 17:13 |
| niemeyer | morphis_: Right.. that's file-used data, vs. block-level usage | 17:13 |
| morphis_ | yes | 17:13 |
| niemeyer | morphis_: The image is block-level | 17:13 |
| cachio | niemeyer, I see some connection refuse comming from the store | 17:13 |
| morphis_ | could be that this is the whole btrfs snapshot thing suse uses to keep the system state around | 17:13 |
| niemeyer | morphis_: Or perhaps some big dependency tree on something in the system? | 17:14 |
| niemeyer | morphis_: Like a graphics stack or whatever | 17:14 |
| morphis_ | no | 17:14 |
| morphis_ | I removed all of that | 17:14 |
| niemeyer | cachio: noise][ or nessita might be able to help | 17:14 |
| morphis_ | https://paste.ubuntu.com/24705005/ | 17:14 |
| cachio | niemeyer, ok, tx | 17:15 |
| morphis_ | a `$ rpm -qa --queryformat="%{NAME} %{SIZE}\n" | sort -k 2 -n` is pretty handy for that | 17:15 |
| niemeyer | morphis_: What is du -sh showing? Where' the bulk of the data? | 17:15 |
| morphis_ | niemeyer: the system is now powered off | 17:15 |
| mup | Bug #1672740 opened: Netplan replug function is incompatible with ath9k_htc module <verification-done> <netplan:Fix Released by cyphermox> <Snappy:New> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1672740> | 17:15 |
| niemeyer | morphis_: Turning it back on | 17:15 |
| morphis_ | thanks | 17:15 |
| niemeyer | Argh | 17:16 |
| niemeyer | morphis_: We've got run over by Spread :( | 17:16 |
| morphis_ | :-) | 17:16 |
| niemeyer | Should have taken the machien out of rotation first | 17:16 |
| niemeyer | This used to be safe, but not anymore | 17:16 |
| niemeyer | morphis_: We'll need a new run, sorry about that | 17:17 |
| morphis_ | niemeyer: np, getting a routine in doing that :-) | 17:17 |
| cachio | nessita, I saw some of these https://paste.ubuntu.com/24705022/ last week | 17:18 |
| cachio | nessita, is there any way to monitor that and see what's going on? | 17:18 |
| niemeyer | morphis_: Good thing it's automated | 17:18 |
| morphis_ | niemeyer: according to du -hs back to 1.2G | 17:23 |
| morphis_ | and just checked, it doesn't use any btrfs snapshots | 17:23 |
| niemeyer | morphis_: So where is the size coming from? | 17:26 |
| niemeyer | morphis_: I wonder if we could try defragmenting to at least push the size down | 17:26 |
| morphis_ | I am looking into that already | 17:27 |
| niemeyer | morphis_: I expected that to happen automatically as a side effect of resizing, but I'm surprised at the amount of space lost | 17:27 |
| niemeyer | morphis_: Is there a place with tons of small files? | 17:27 |
| morphis_ | no | 17:28 |
| morphis_ | niemeyer: let me remove a few more packages if I can as there is still a bit too mcuh in /usr/share | 17:31 |
| morphis_ | but there is no good separation into single packages that it's obvious what to remove in Suse (like in debian we have -docs etc.) | 17:32 |
| niemeyer | morphis_: let me know | 17:38 |
| === om26er_ is now known as om26er | ||
| morphis_ | niemeyer: down to 1.1G on spread-42, can you check the size on your side without powering the node off? | 18:00 |
| mup | PR snapcraft#1336 opened: HACKING: make running from virtualenv more obvious <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1336> | 18:55 |
| morphis_ | niemeyer: otherwise feel free to snapshot spread-42 now, that is the smallest (1.1G) I could get it | 18:56 |
| captine1 | hi all. I am trying to find the snap refered to in this article | 18:56 |
| captine1 | https://insights.ubuntu.com/2017/02/22/an-ubuntu-snap-based-solution-for-enterprises-to-control-their-data/ | 18:56 |
| niemeyer | morphis_: Sorry.. missed your previous message | 18:56 |
| captine1 | anyone able to assist? | 18:56 |
| niemeyer | morphis_: Running on it now | 18:56 |
| morphis_ | thanks | 18:56 |
| === captine1 is now known as captine | ||
| niemeyer | morphis_: All done | 19:06 |
| morphis_ | niemeyer: awesome! thanks | 19:07 |
| niemeyer | morphis_: Ended up at 1.5GB | 19:07 |
| niemeyer | morphis_: Machine is back up | 19:07 |
| morphis_ | ok | 19:08 |
| mup | PR snapd#3333 closed: vendor: refresh everything <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3333> | 19:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!