[00:04] <zyga> ijohnson: I'll update the data tables to be correct and push
[00:06] <ijohnson> zyga great but also feel free to wait until tomorrow :-)
[00:07] <zyga> ijohnson: small review on renameat2 https://github.com/snapcore/snapd/pull/8044#pullrequestreview-347688118
[00:08] <mup> PR #8044: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
[00:12] <ijohnson> zyga: thanks for the review, tldr is that it's not a big deal if the random source is poor, as it's just being super extra super safe anyways
[00:14] <zyga> ijohnson: and the renameat part?
[00:15] <ijohnson> zyga: the paths are absolute so the fds are ignored
[00:15] <zyga> hmm
[00:16] <ijohnson> I would have used rename2 but the only way to get atomicity is to use renameat2
[00:16] <ijohnson> (with the RENAME_EXCHANGE flag)
[00:18] <zyga> ijohnson: I think that's okay but I would still use the special value, technically the 0 descriptor is valid and means something but the code that ensures arguments are absolute is not close to the call
[00:18]  * zyga nods
[00:19] <ijohnson> zyga I'll add a comment where it's used
[00:20] <zyga> I think using the special value is preferred
[00:20] <zyga> even with a comment
[00:20] <zyga> it's more like what you wanted
[00:25] <ijohnson> Okay I'll use that then
[00:27] <zyga> ijohnson: double check with jdstrand but I think that's safer
[00:28] <ijohnson> Okay, the man page says the FD is supposed to be ignored when it's an absolute path
[00:30] <zyga> yes, that's true
[00:30] <zyga> my point is not that this is incorrect
[00:30] <zyga> it's just that it can be safer
[00:31] <ijohnson> Sure
[06:44] <mborzecki> morning
[06:58] <mup> PR snapcraft#2889 closed: meta: always generate snapcraft-runner to workaround classic PATH bug <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2889>
[07:03] <mborzecki> zyga: interesting forum topic https://forum.snapcraft.io/t/permission-denied-in-general-ubuntu-19-10-snap-2-42-5/15161
[07:10] <mborzecki> hmm not sure anything happend on the desktop front, snaps still render with boxes instead of actual fonts: https://i.imgur.com/V3mKUt8.png
[07:54] <__chip__> 👋
[08:00] <geodb27> People : hi ! I have 9 machines (ubuntu LTS 18.04 server) that are split into 3 lxd clusters. Yesterday, at 15:13 all nine decided to update the snap lxd package. They are all stuck at task "Copying datas from the snap lxd package".
[08:01] <geodb27> So, since yesterday, the "lxc" commands provided by this snap are not available anymore, and I can't do anything. I don't want (and can't) lose all my lxd containers. What can I do to have snap lxd package up-to-date ?
[08:05] <zyga> Hey
[08:05] <zyga> Outside
[08:05] <zyga> Back soon
[08:05] <mborzecki> zyga: __chip__: hey
[08:05] <mborzecki> geodb27: can you collect the output of `snap change --last=refresh` from one of the machines?
[08:05] <pstolowski> morning
[08:05] <mborzecki> pstolowski: hey
[08:05] <geodb27> Thanks for your answer mborzecki. I'll check this right now.
[08:07] <geodb27> Well, it remains the same as "snap changes" followed by "snap tasks nn" with nn the id of the change. And this leads to the step that is waiting since yesterday 15:13 as I said before.
[08:11] <geodb27> I've just checked all my 9 machines. 6 are OK. But 3 (the three of one same cluster) are in the same state. Stuck at :
[08:11] <geodb27> Doing  yesterday at 15:13 CET  -                       Copier les données du paquet Snap "lxd"
[08:14] <mborzecki> geodb27: weird, iirc lxd keeps container data under the location shared by all revisions
[08:15] <mborzecki> geodb27: can you check whether there any any files under /var/snap/lxd/current/ ?
[08:16] <geodb27> there is no /var/snap/lxd/current. All I have is /var/snap/lxd/{12317,12631,common}
[08:16] <geodb27> (On the first machine).
[08:16] <mborzecki> geodb27: try /var/snap/lxd/12317/
[08:16] <zyga> re
[08:17] <geodb27> On the two others I have /var/snap/lxd/{12317,12631,13073,common). But the last two are stuck at "Doing  yesterday at 15:12 CET  -                       Démarrer les services du paquet Snap "lxd" (13073)"
[08:17] <zyga> ha
[08:17] <mborzecki> geodb27: anything in there? can you run `du -sch /var/snap/lxd/12317/` ?
[08:17] <zyga> I saw this
[08:17] <zyga> last night
[08:17] <zyga> mborzecki: lxd cannot be stopped
[08:17] <zyga> it sticks around forever
[08:18] <zyga> I noticed this yesterday when rebooting
[08:18] <zyga> systemd eventually kills it after 10 minutes and just reboots
[08:18] <mborzecki> zyga: w8, so it hits all the timeouts, systemd still doesn't stop it?
[08:18] <zyga> but when I noticed the messages it was not able to unmount cleanly
[08:18] <mborzecki> zyga: but sunce we moved to the next task, systemd must have reported it stopped
[08:18] <zyga> mborzecki: it seems there are no timeouts for lxd
[08:18] <zyga> maybe it's something special it does
[08:18] <geodb27> On the first machine, the /var/snap/lxd/12317 folder is empty.
[08:18] <zyga> mborzecki: for me the reproducer case was ubuntu 19.10 (now 20.04) with lxd and a container
[08:19] <zyga> stopping lxd doesn't work
[08:19] <mborzecki> geodb27: right, as zyga mentioend, maybe it's related to lxd not stopping
[08:19] <mborzecki> geodb27: can you ps -ef|grep lxd ?
[08:19] <geodb27> Indeed, it could be. Let me check.
[08:19] <geodb27> root        1518       1  1 janv.10 ?      05:36:05 [lxd] <defunct>
[08:20] <mborzecki> zyga: ^^
[08:20] <zyga> ha
[08:21] <geodb27> What now ? If I reboot, will lxd complete it's upgrade and will I get all my containers back up and running ?
[08:22] <zyga> geodb27: I'd not test in production, cannot say for sure
[08:22] <zyga> geodb27: I suspect that snapd will recover
[08:22] <zyga> geodb27: and carry on with the update
[08:22] <zyga> geodb27: but depending on how your time works I'd evaluate this separately
[08:23] <geodb27> Thanks for your help zyga. Anyhow, I have backups of my machines (fortunately, the containers are hosted on a ceph cluster)... I'll give it a try and give a feedback here as the reboot completes.
[08:24] <zyga> geodb27: thank you
[08:24] <zyga> mborzecki: we should check this out
[08:24] <mborzecki> zyga: any clue whether stgraber and his team noticed this too?
[08:24] <zyga> no idea
[08:27] <mborzecki> hmm `Instance name is: on-jackass`
[08:28] <zyga> is there a way to wait for a change?
[08:28] <zyga> from command line
[08:28] <zyga> snap watch --last
[08:28] <zyga> ah
[08:29] <mborzecki> zyga: if you're addressing the commnents in your PR then retry-tool probably makes more sense in case the change does not complete
[08:29] <zyga> ish
[08:29] <zyga> I must be doing it wrong
[08:29] <zyga> while snap changes | grep Doing; do sleep 1; done
[08:29] <zyga> this failed just now
[08:29] <zyga> with snap changes showing a change that is Doing
[08:29] <zyga> wtf?
[08:30] <zyga> https://www.irccloud.com/pastebin/pc7zuZZX/
[08:30] <zyga> but I'm very suspect of the test itself
[08:30] <zyga> it happily REBOOTS
[08:30] <zyga> without any synchronization on async snapd activity
[08:30] <zyga> I suspect it need to have snap watch --last=... in each stage
[08:30] <zyga> as otherwise nothing is certain
[08:33] <geodb27> Well... Fyi : I rebooted only one machine of the lxd cluster... It took some time (the reboot process had to kill a process related to filesystem mounted)... And... Tada : all three machines are up-to-date and running fine. Thanks for your kind help !
[08:34] <geodb27> I do not have time (and it is anyhow too late) to investigate further to find out what was hanging the system. One could suspect some lock (maybe on the cephfs side or on the lxd database at some point) that was holding things stalled.
[08:43] <mborzecki> we should write down the reasons for avoiding golang.org/x/sys/unix
[09:04] <zyga> mborzecki: I'll grab some food and make tea
[09:04] <zyga> mborzecki: I'm iterating on the wait/reboot problem
[09:15] <mborzecki> zyga: heh any ideas why /etc/apparmor.d/usr.bin.snap might exist?
[09:21] <mborzecki> zyga: meh, reading renameat2 implementation, not sure whether we need to sync the directory too
[09:22] <zyga> mborzecki: yes
[09:22] <zyga> mborzecki: I read about a case where someone had it
[09:23] <zyga> mborzecki: _something_ definitely creates it
[09:23] <zyga> mborzecki: not snapd
[09:23] <zyga> mborzecki: I cannot recall the details of the case I remember but it was probably on the forum too, let me check
[09:23] <zyga> hmm, not on the forum
[09:24] <mborzecki> zyga: so this guy got both snap and usr.bin.snap in apparmor profiles in case you missed it https://forum.snapcraft.io/t/permission-denied-in-general-ubuntu-19-10-snap-2-42-5/15161
[09:24] <zyga> yeah
[09:24] <zyga> I read
[09:43] <zyga> + snap watch --last=revert
[09:43] <zyga> error: no changes of type "revert" found
[09:43] <zyga> + snap changes
[09:43] <zyga> 9    Done    today at 09:39 UTC  today at 09:41 UTC  Revert "core" snap
[09:43] <zyga> sigh
[09:43] <zyga> that's such a crappy behavior
[09:44] <zyga> ah, it's called revert-snap
[09:44] <zyga> oh well
[09:47] <mup> PR snapcraft#2891 opened: meta: always generate snapcraft-runner to workaround classic (#2889) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2891>
[09:52] <zyga> and I found a small bug
[09:52] <zyga> https://www.irccloud.com/pastebin/JBOzGPsz/
[09:53] <zyga> ok, one more run
[09:53] <zyga> brrr
[09:53] <zyga> cooold
[10:05] <zyga> iteration on this is painful
[10:09] <zyga> mborzecki: I wonder if that denial was from snap-store
[10:09] <zyga> maybe it does something weird
[10:10] <mborzecki> zyga: that diff loos like we could use a helper of sorts
[10:15] <zyga> mborzecki: I changed https://github.com/snapcore/snapd/pull/8039
[10:15] <mup> PR #8039: tests: remove revision leaking from ubuntu-core-refresh <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8039>
[10:15] <zyga> pstolowski: ^ can you look again
[10:15] <pstolowski> k
[10:15] <zyga> I mainly added the snap watch --last=...
[10:16] <zyga> as otherwise we just race
[10:18] <zyga> I'm running a small loop of this to see if it is stable
[10:45] <zyga> back with coffee
[10:45] <zyga> tests going
[10:45] <zyga> still good
[10:50] <zyga> passed
[10:50] <zyga> ok onto more branches
[11:03] <zyga> guys, please don't merge any of the test fixes yet
[11:03] <zyga> I'm iterating on comments and even though some are green and +2 I'll adjust them
[11:27] <zyga> heh
[11:27] <zyga> weird failure
[11:27] <zyga> https://www.irccloud.com/pastebin/SIB7x6zG/
[11:27] <zyga> snapd is not installable
[11:33] <mup> PR snapd#8045 opened: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
[11:36] <zyga> mborzecki: ^ I  think AtomicRename without replace/not-replace is unsafe
[11:36] <zyga> as it's easy to use it to nuke stuff
[11:36] <mborzecki> zyga: isn't rename the same?
[11:36] <zyga> yes, but that's my point
[11:37] <mup> PR snapd#8046 opened: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[11:37] <zyga> it depends on how it is used obviously
[11:48] <zyga> hmm
[11:49] <zyga> why is kernel remodeling so slooooow
[11:49] <zyga> it's 10 per test
[11:49] <zyga> 10 minutes
[11:49] <mborzecki> unexpected failure https://paste.ubuntu.com/p/D6n2g4MfwD/
[11:50] <zyga> hmmm
[11:50] <zyga> no idea,
[11:50] <zyga> I am really wondering if we do things right
[11:50] <zyga> we pull the rug from under snapd in teardown
[11:50] <zyga> not wait for things
[11:53] <__chip__> zyga: the kernel is very prima donna about its hair, so remodeling takes ages
[11:53]  * __chip__ in Friday mode
[11:53] <zyga> __chip__: we should ... shave a few minutes
[11:54] <__chip__> zyga: rimshot
[11:54] <__chip__> zyga: google 'rimshot pirates gif' for the right thing
[11:54] <__chip__> mah interwebs are slow so i can only do meta-gifs
[11:55] <zyga> __chip__: how's Friday?
[11:55] <zyga> __chip__: I was super happy yesterday
[11:55] <__chip__> zyga: what happened yesterday? (let's do it more!)
[11:55] <zyga> __chip__: I fixed the three tests leaking stuff on core167
[11:55] <zyga> some lessons learned as well
[11:56] <zyga> __chip__: now mount-ns can run on core
[11:56] <zyga> _ages_
[11:56] <__chip__> is that core based on ubuntu 2167.04?
[11:56] <zyga> it took years to do this
[11:56] <zyga> hahaha
[11:56] <zyga> star trek
[11:56] <zyga> the next remodel
[11:56] <zyga> these are the changes of the packaging systems
[11:56] <zyga> to explore ... channels
[11:56] <zyga> yada yada
[11:59] <__chip__> zyga: sudo apt install xscreensaver-gl-extra, and then /usr/lib/xscreensaver/starwars -program 'cat stufftxt'
[12:08]  * zyga iterates on another PR
[12:22] <cmatsuoka> mborzecki: #8045 failed on a travis test with a random store error so I restarted it
[12:22] <mup> PR #8045: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
[12:22] <mborzecki> cmatsuoka: thanks!
=== ricab is now known as ricab|lunch
[12:51] <zyga> hmm
[12:51] <zyga> is the store all right
[12:51] <zyga> my tests are timing out on super slow traffice
[12:52] <zyga> downloading core takes close to an hour
[12:53] <zyga> 10KB/s
[12:53] <zyga> 20-60
[12:57] <zyga> brb
[12:59] <zyga> re
[13:41] <zyga> degville: did you find anything interesting in the content interface?
[13:43] <degville> zyga: I'm still working on it - but I did get my own slot/plug snaps working with it, and I've mostly added the details you suggested/linked to.
[13:43] <zyga> cool! :)
[13:44] <zyga> I think the thing I've learned is that simple stuff tends to work
[13:44] <zyga> but is surprising when you start being very creative
[13:45] <degville> ok, sounds sensible. I'll make a note of it. Certainly, my own snaps are simple, but they were just for my own understanding.
[13:45] <ijohnson> morning folks
[13:45] <zyga> - Download snap "ubuntu-image" (161) from channel "edge" (received an unexpected http response code (504) when trying to download https://canonical-lcy01.cdn.snapcraft.io/download-origin/canonical-lgw01/4RW78vIax8JW5S8HkYsa8lNbv68uPaYX_161.snap?token=1579885200_4dbf2a807d9b9a8d56cb263d6e7dcc6e61a45952)
[13:45] <zyga> ijohnson: hey
[13:45] <ijohnson> hey
[13:45] <zyga> ijohnson: store is wonky
[13:45] <ijohnson> does that mean I can just go back to bed
[13:45] <ijohnson> :-)
[13:45] <mborzecki> it is :/
[13:46] <mborzecki> error: cannot perform the following tasks:
[13:46] <mborzecki> - Download snap "core" (8268) from channel "stable" (Get https://canonical-bos01.cdn.snapcraft.io/download-origin/canonical-lgw01/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_8268.snap?token=1579881600_d8a5fae185f0cf6884a96c15c566fc6876922512: EOF)
[13:46] <zyga> ijohnson: or play in the snow
[13:46] <zyga> yeah
[13:46] <ijohnson> mborzecki: so what's the story behind this AtomicRename ?
[13:46] <ijohnson> mborzecki: is my implementation flawed? I see your comment about the dir syncing
[13:46] <mborzecki> ijohnson: want to talk before the standup?
[13:47] <ijohnson> sure, like now?
[13:47] <mborzecki> or after/or during :P doesn't matter, it's only 5 of us today
[13:47] <zyga> btw, I'm next to lucy
[13:47] <zyga> she's sleeping
[13:47] <zyga> I may join standup and listen on very quiet level
[13:47] <zyga> either I swap with my wife or it's silent standup for me :)
[13:47] <mborzecki> ijohnson: zyga: let's do it
[13:47] <zyga> no no
[13:47] <zyga> I mean leater
[13:47] <zyga> I'm working on stuff now
[13:48] <zyga> go chat!
[13:48] <ijohnson> mborzecki: I'll join in just a minute
=== ricab|lunch is now known as ricab
[14:35] <ijohnson> zyga: why use `snap watch` instead of `retry-tool` ?
[14:36] <zyga> ijohnson: because snap watch does exactly what I need
[14:36] <zyga> and retry tool would have to do snap changes and grep
[14:36] <ijohnson> I'm still just a little worried that it will block forever
[14:36] <zyga> exactly what snap watch does inside
[14:36] <zyga> I wish we had a way to make retry-tool ask snapd something directly
[14:37] <zyga> retry-tool snap debug settled
[14:37] <zyga> or something
[14:37] <zyga> I see your point, it's just lesser evil right now (out of two choices this one is more robust in being precise)
[14:37] <zyga> not that the other would just grep Doing
[14:37] <zyga> which doesn't catch Undoing
[14:38] <zyga> and is fooled by "Done Doing stuff"
[14:45] <ijohnson> zyga: ok, it's fine for now then I guess
[14:45] <ijohnson> I'll approve in a little bit
[14:45] <zyga> I think "snap debug settle" would be good
[14:45] <zyga> I'll ask about it next week
[14:45] <zyga> also the shell code after reboot-causing activity
[14:45] <zyga> that scans logs
[14:45] <zyga> to know when it can REBOOT
[14:45] <zyga> yuck
[14:45] <zyga> we should have a better way
[14:46] <zyga> not calling REBOOT is not good because then spread was not anticipating it
[14:46] <zyga> it would be good to have ANTICIPATE_REBOOT
[14:46] <zyga> and then just do what normally happens
[14:46] <zyga> but there is no channel to send that information today
[14:46] <zyga> (sadly)
[14:47] <ijohnson> Afk for little bit
[14:47] <zyga> - Download snap "core20" (331) from channel "edge" (Get https://canonical-bos01.cdn.snapcraft.io/download-origin/canonical-lgw01/DLqre5XGLbDqg9jPtiAhRRjDuPVa5X1q_331.snap?token=1579888800_379b23e2fe4d0bd8d7152c92943200e95a92deb0: EOF)
[14:47] <zyga> I think today is early EOD land
[14:48] <zyga> I will do reviews
[14:59] <zyga> mborzecki, ijohnson: -1 on https://github.com/snapcore/snapd/pull/8045#pullrequestreview-348005564
[14:59] <mup> PR #8045: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
[15:02] <pstolowski> ijohnson: i joined tgif the second you left
[15:03] <ijohnson> pstolowski: sorry be there in a minute
[15:03] <ijohnson> irl thing
[15:03] <pstolowski> no worries
[15:05] <zyga> ijohnson: what does zsys stand for?
[15:07] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/8043#pullrequestreview-348015574 + but please check my comment
[15:07] <mup> PR #8043: osutil: add Renameat2() <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8043>
[15:32] <ijohnson> zyga: zsys is just what the go sources use for those definitions
[15:32] <ijohnson> i.e. https://github.com/golang/sys/blob/1a3b71a79e4aff00d87e69e0744746d7d67a3f8f/unix/zsysnum_linux_arm.go
[15:33] <ijohnson> zyga: what do you think about my implementation vs mborzecki ?
[15:37] <ijohnson> zyga: mborzecki: I think I will push to 8045 a change to do try creating the symlink in a loop and then refactor my grub PR to use mborzecki's implementation and drop the osutil.Renameat2. we can always refactor to use that later if we find os.Rename it's not safe enough
[15:40] <zyga> ijohnson: I think the looping should be in maciek's pr but otherwise I agree
[15:40] <zyga> ijohnson: ah
[15:40] <zyga> ok
[15:40] <zyga> (about zsys)
[15:40] <zyga> - Download snap "core18" (1668) from channel "edge" (received an unexpected http response code (404) when trying to download https://canonical-lcy01.cdn.snapcraft.io/download-origin/canonical-lgw01/CSO04Jhav2yK0uz97cr0ipQRyqg0qQL6_1668.snap?token=1579892400_a96a7203408107730307613e718e90209628f548)
[15:40] <zyga> store is so down
[16:02] <ijohnson> zyga: okay sounds good
[16:03] <roadmr> zyga: wait 404?
[16:03] <roadmr> zyga: is that reproducible?
[16:03] <mborzecki> ijohnson: pushing in a bit
[16:03] <roadmr> it should NOT 404 (no found) on you - I might expect a 50x but not a 404
[16:03] <ijohnson> mborzecki: ah okay if you're already doing that I'll wait for you
[16:04] <roadmr> zyga: wfm fwiw
[16:11] <mborzecki> ijohnson: zyga: pushed
[16:12] <mborzecki> time to wrap it up
[16:17] <mup> PR snapd#8043 closed: osutil: add Renameat2() <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8043>
[16:24] <zyga> re
[16:42] <ijohnson> zyga: are your leaky mount ns PR fixes all ready? if so I can merge them this PM after I review them
[16:42] <ijohnson> trying to finish UC20 things this morning
[16:47] <sdhd-sascha> hi, sorry to mention you. I already ask at #openstack and #ubuntu-kernel.
[16:47] <sdhd-sascha> Should a bond which is member of a bridge has a mac-address ? And if so, should it be the same mac ? (netplan use automatically the same mac)
[17:08] <ijohnson> sdhd-sascha: I don't know the answer myself, but there's also the #netplan channel
[17:14] <sdhd-sascha> ijohnson: thank you :-) meanwhile i found #lxc-dev, too.
[17:14] <ijohnson> sdhd-sascha: glad to help
[17:42] <zyga> ijohnson: no, not ready
[17:42] <zyga> ijohnson: close but not yet, I'm wrapping up another branch and will return to get through feedback and do tests
[17:42] <ijohnson> zyga: ack, np
[17:42] <zyga> ijohnson: but I'm still up here
[17:43] <zyga> so I'll try to merge them if possible by EOD
[17:43] <ijohnson> zyga: sure np
[18:05] <sdhd-sascha> Is it possible to approve this classic-snap : https://build.snapcraft.io/user/sd-hd/termite-snap . (I already asked in the forum for a `classicmode` track )
[18:05] <zyga> sdhd-sascha: does it have required votes?
[18:06] <sdhd-sascha> zyga: just talk today, per email, with someone who has requested support from me.
[18:06] <sdhd-sascha> What are required votes ?
[18:07] <zyga> sdhd-sascha: it must go through the review process
[18:07] <zyga> sdhd-sascha: and get enough votes
[18:07] <sdhd-sascha> I published it as strict before, with ssh and byobu. But didn't had the time to test and use it in production.
[18:08] <sdhd-sascha> zyga: Ok, understood. No problem. I told the reviewer, that he could build the snap himself. (He knows how to strace it ;-) )
[18:10] <sdhd-sascha> zyga: is this enough: ? https://forum.snapcraft.io/t/termite-classicmode-track/15169
[18:11] <zyga> no
[18:11] <zyga> please look at the process requirements
[18:11] <zyga> it's documented on the forum
[18:11] <zyga> you must justify it
[18:11] <zyga> there are requirements and it's not always granted
[18:11] <zyga> it also takes some time so don't expect instant replies
[18:16] <sdhd-sascha> zyga: hmm
[18:31] <sdhd-sascha> zyga: https://forum.snapcraft.io/t/termite-classicmode-track/15169/2
[18:37] <zyga> sdhd-sascha: I'm sorry it's too late for me to focus on that
[18:37] <zyga> I'm trying to wrap up some fixes and spend some time away from work
[18:38] <sdhd-sascha> zyga: no problem - i just try to look at github actions... maybe i can create it there, for now
[18:38] <zyga> sdhd-sascha: someone recently tweeted about using github actions for snaps
[18:39] <zyga> but I'm off now, need to take the dog out
[18:39] <sdhd-sascha> i know... christmas presend ;-) i remember ;-)
[18:39] <sdhd-sascha> no problem ;-)
[18:55] <sdhd-sascha> Hey folks - did you ever had a remote tree-tag on github. But no branch. How can i fetch this ?
[18:55] <sdhd-sascha> /me i know, i wish too, i had had people in the past to ask ;-)
[19:22] <zyga> ijohnson: updated differential PR
[19:23] <zyga> switching to the fixes
[19:23] <ijohnson> zyga: ack thanks
[20:03]  * zyga checks on tests
[20:22] <sdhd-sascha> markstos: welcome :-)
[20:26] <sdhd-sascha> markstos: well, termite on sway launched on my system
[20:27] <sdhd-sascha> Yes, it runs on strict ... But you didn't have access on outher applications. Except you use some remote login, to another system
[20:28] <sdhd-sascha> markstos: the most folks, here are gone, and be on gmt+3 back ;-)
[20:28] <sdhd-sascha> or, so
[20:28] <sdhd-sascha> But, if i say something wrong, than they can criticism me
[20:29] <sdhd-sascha> If i understand you, then, you would like to have some terminal which is strict protected with apparmor and seccomp. But its usable ?
[20:30] <markstos> Ah, so it's good for SSH, but not for accessing the filesystem. That's a lot less useful.
[20:30] <markstos>  I'm not surprised Sway works, since Sway uses Wayland and Wayland seems to work as the default for Termite.
[20:32] <sdhd-sascha> :-)
[20:32] <sdhd-sascha> No, no -- the most guys said to me, that `classic mode` with full filesystem (not only home) makes more sense
[20:32] <markstos> My primary interest was simply to have a package that I could install on Ubuntu.
[20:32] <sdhd-sascha> I read, in your mail signature, that you have a security company - or you are freelance ?
[20:33] <sdhd-sascha> hmm - ... maybe it was the easiest, if i create a `ppa` for you ? and termite plus libvte-ng
[20:33] <sdhd-sascha> then there is no snap needed ?
[20:34] <sdhd-sascha> Firstly, i thought you would like to have a snap.
[20:35] <sdhd-sascha> markstos: What OS are you use ?
[20:36] <markstos> I'm using Ubuntu 18.04, but plan to soon convert a new persona laptop laptop to Ubuntu 20.04 alpha. I'll run containers to support 18.04 apps until  20.04 is released.
[20:36] <sdhd-sascha> Oh, you just said them. I'm sorry
[20:36]  * sdhd-sascha just remember
[20:37]  * sdhd-sascha also have to try to use slack.... (thanks for the tip)
[20:38] <markstos> Yes, a PPA would also be welcome. As much as possible I'm trying to automate my environment with Ansible, so whichever format it is, I'll automate installing and next time upgrades will just about as easy either way.
[20:42] <sdhd-sascha> hey, markstos - my wife is come back. And yes, i can create a ppa the next days ;-)
[20:42] <sdhd-sascha> But mention, that libvte-ng and libvte can be different version. (i try to do my best to resolve this ;-) )
[20:43] <sdhd-sascha> see us - tomorrow ;-)
[20:43] <markstos> Thanks!
[20:44] <sdhd-sascha> markstos: of course, i'm glad to help (sometimes, i didn't have the time, for an one-person ... ;-) )
[22:10] <mup> PR snapcraft#2892 opened: Add snapcraft plugin for Qt Build Suite (qbs) <Created by bjorn> <https://github.com/snapcore/snapcraft/pull/2892>
[22:24]  * zyga alters a test and spawns another run
[22:42] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/8038 updated
[22:42] <mup> PR #8038: tests: fix gadget-update-pc test leaking snaps <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8038>
[22:42] <zyga> 4 is enough
[22:44]  * zyga notices LXD test is broken
[22:44] <zyga> eh
[22:44] <zyga> I guess that's not a good way to end the week
[22:44] <zyga> something to fight on Monday
[22:44] <zyga> ttyl
[22:44]  * zyga eods
[22:45] <ijohnson> Have a good weekend zyga!
[22:45] <zyga> thank you, you too
[22:46] <zyga> (lxd is not broken, installing snapd in lxd doesn't pass through dpkg, some deps are wrong, perhaps the test starts to suffer from the build-on-A-and-install-on-B problem)
[22:46]  * zyga goes to watch Picard pilot