[00:14] <tannewt> maxb: ah, I see, is it because versions are compared alphabetically?
[00:17] <johanbr> tannewt: if you're doing this automatically, you may want to do it via git, since that'll carry all the version tags
[00:17] <johanbr> both ubuntu + upstream
[00:17] <JanC> tannewt: basically alphabetically with some added quirks  ;)
[00:19] <tannewt> johanbr: hmm, I just do it based on tarballs for the kernel.  I can't spend too much time on it because I'm tracking all packages not just the kernel
[00:19] <johanbr> oh, I see
[00:20] <tannewt> johanbr: probably not the smartest decision I've made :-)
[00:20] <tannewt> johanbr: for 8 distributions at this point too, oswatershed.org
[00:21] <johanbr> wow :)
[00:21] <johanbr> sounds like a pretty ambitious project
[00:21] <tannewt> johanbr: yeah, it is, its pretty cool data though
[00:21] <johanbr> "Parse error: syntax error, unexpected $end, expecting ')' in /var/www/oswatershed.org/htdocs/gen/data_2009032523.php on line 3"
[00:22] <tannewt> johanbr: hmm, let me look
[00:23] <tannewt> johanbr: I've been messing with things :-)
[00:23] <johanbr> :)
[00:23] <tannewt> johanbr: not much to see, I'm redoing it anyway
[00:23] <tannewt> johanbr: http://abstract.cs.washington.edu/~tannewt/ is another copy of it going
[00:24] <johanbr> alright
[00:25] <dtchen> how does it account for different distributions' stable/development release policies?
[00:28] <tannewt> dtchen: it compares stable releases versus different stable releases
[00:29] <tannewt> dtchen: in other words, it crawls multiple repos and classifies them as different branches of a single distro
[00:29] <tannewt> dtchen: past, lts, current, future and experimental are the current branch classifications
[00:31] <tannewt> dtchen: however, there is no independent notion of when a distro is stable
[10:55] <domas> hi! I'm staring at 2.6.24-18-server being idiotic: http://p.defau.lt/?WB6QRUQKJK19nVoZNQlNCA ;-)
[10:55] <domas> it swapped out a working process for 2G of 'cache' that isn't really used in any way
[11:11] <soren> domas: From here it looks like you're used all your RAM.
[11:11] <soren> 47048k free is not much, and you have less than 1 MB cached?
[11:14] <domas> soren: thats 1G cached
[11:22] <soren> In swap.
[11:24] <IntuitiveNipple> domas: 2G (almost) cached :)  ... can you show the complete ps -efly - we can see mysqld is using almost all RAM already, so it wouldn't be surprising if it swaps, especially if the vm's 'optimistic' allocation has been caught out
[11:24] <domas> mysql is using 15G on 16G machine
[11:24] <domas> see, on most machines you'd say "1G for OS is enough"
[11:24] <domas> if I had _lots_ of processes eating 1G each, it wouldn't be an issue
[11:25] <domas> but it seems to be an issue with single big process
[11:25] <IntuitiveNipple> how big are the databases mysqld is handling?
[11:26] <domas> 200G
[11:26] <domas> (thats why I prefer mysqld to handle the dataset, not OS :)
[11:27] <IntuitiveNipple> Is it using temporary tables during processing?
[11:27] <domas> nope, none at all
[11:27] <domas> just writing few logs
[11:27] <domas> append-only operation, but they seem to take a fair share in the cache :)
[11:27] <domas> I can probably flush any cache with fadvise(MDONTNEED) :)
[11:28] <mdz> apw: I just got a new false positive with the apport suspend check
[11:29] <mdz> apw: is there anything I can check to help diagnose?
[11:29] <IntuitiveNipple> mdz: Is it because the resume took slightly over 5 seconds?
[11:30] <IntuitiveNipple> mdz: grep 'PM: resume devices took' /var/log/kern.log usually identifies that
[11:31] <soren> domas: "ps -efly" would still be convenient...
[11:32] <domas> http://p.defau.lt/?J_3IkiT90__D6PXxReo_EA
[11:36] <IntuitiveNipple> domas: the xargs -P 16 spawning the simultaneous jobs would explain the cache usage because all those gzip jobs need memory
[11:37] <domas> few megs each
[11:37] <domas> each
[11:37] <domas> but that would be not 'cached: 1G'
[11:38] <IntuitiveNipple> how much data is being sent in as a result of those?
[11:38] <domas> ~1MB packets
[11:43] <IntuitiveNipple> how many threads is mysqld using?
[11:43] <domas> 16
[11:47] <IntuitiveNipple> what does this report: SHOW STATUS LIKE '%key_read%';
[11:47] <domas> this is innodb mostly
[11:47] <domas> all i/o is single file
[11:48] <domas> 10000 for key_read ;-)
[11:48] <IntuitiveNipple> ok.
[11:49] <IntuitiveNipple> what does it show for mem usage then? SHOW INNODB STATUS;
[11:50] <domas> Total memory allocated<PHONE_NUMBER>4; in additional pool allocated 7059968
[11:51] <domas> thats 14.8G
[11:53] <IntuitiveNipple> domas: I saw a reference to that which said "...Note that the real usage is maybe 2 - 4 times bigger than what it reports..."
[11:53] <domas> probably bad reference then
[11:53] <IntuitiveNipple> domas: in reference to the reported additional pool value
[11:53] <IntuitiveNipple> I doubt it, it was from one of the innodb dev's
[11:54] <domas> additional pool doesn't matter much
[11:54] <IntuitiveNipple> It will when the memory limit is hitting the RAM limit... if the additional pool is larger than that value it would explain the swap
[11:55] <domas> no, it is not
[11:55] <domas> :)
[11:55] <domas> mysql real rss should be ~15G
[11:55] <soren> I'm still not completely sure what the problem is. free says you've used all your RAM, so naturally, there's some swapping going on.
[11:55] <domas> yup, but then there's lots of caching
[11:55] <domas> which isn't needed
[11:55] <domas> I don't want that to have any VM pressure :)
[11:55] <soren> Swap caching.
[11:56] <soren> It's not caching files from the filesystem.
[11:56] <domas> Cached:         637916 kB
[11:56] <domas> SwapCached:      76608 kB
[11:56] <domas> well, I changed swapiness to 1 now
[11:57] <soren> domas: I'm still looking at http://p.defau.lt/?WB6QRUQKJK19nVoZNQlNCA
[11:57] <domas> thats file cache
[11:57] <soren> No.
[11:58] <soren> Well.. "that"?
[11:58] <soren> Which "that"?
[11:58] <domas> the 2G number
[11:58] <soren> I disagree.
[11:58] <domas> I checked meminfo, it was in 'cached:' line, not 'swapcached'
[11:58] <soren> Mind you, this is ancient knowledge, so it might have changed, but back in the good old days, what was reported as cached in swap was stuff that had been in swap recently, but was loaded back in to RAM, but hadn't been written to, so if it  were to be swapped back out, it wouldn't have to be rewritten to disk.
[11:59] <domas> mhm
[11:59] <soren> I'm happy to be corrected if that's not the case anymore.
[12:01] <IntuitiveNipple> That is my understanding of it too
[12:02] <domas> right now after the swapiness decreased it seems that swap usage has fallen down, so does kswapd weirdness
[12:02] <domas> it is max 33% cpu now
[12:03] <domas> though the workload changed a bit
[12:04] <domas> ghm, maybe I didn't set O_DIRECT :)
[12:04] <IntuitiveNipple> what does vmstat show? lots of active swapping?
[12:04] <domas> nah
[12:04] <domas> around ~1MB/s swap-oin
[12:04] <domas> swap-in
[12:05] <domas> occasional swapout
[12:06] <IntuitiveNipple> O_DIRECT would help
[12:06] <IntuitiveNipple> soren: interesting overview: http://feedblog.org/2007/09/29/using-o_direct-on-linux-and-innodb-to-fix-swap-insanity/
[12:06] <domas> I'm usually using O_DIRECT, the problem is that filesystems are stupid a bit
[12:07] <domas> only XFS allows parallel writing to O_DIRECT files, and even then it has limits (there have to be _no_ cached pages for that file at all)
[12:07] <domas> so you have to either flush oages with fadvise() or remount filesystems
[12:08] <domas> gotta patch mysql to do that for me
[12:09] <domas> btw, when process really goes oom, linux panics nowaday
[12:09] <domas> instead of killing the process
[12:11] <soren> domas: You can flush caches using /proc/sys/vm/drop_caches
[12:11] <domas> yep, not selective though
[12:11] <domas> (on the other hand, who cares about selectivity ;-)
[12:12] <domas> I have seen few more problems with kswapd behavior - especially with LVM. it seems that LVM marks some data required for snapshots as 'reclaimable', so kswapd goes crazy when gets some VM pressure and tries to free them up
[12:24] <IntuitiveNipple> I've just been looking at the Innodb tuning stuff, and the discussion of this particular issue. There it says, "...Make sure however the swapping is not happening ie your VMSTAT “si/so” columns are zero on Linux. Couple of swaps per minute would not hurt bad but if you’re doing 100+ pages per second of swap IO you’re in trouble."
[12:24] <IntuitiveNipple> See: http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/
[12:29] <domas> IntuitiveNipple: I know that :) but I want OS not to swap my reasonably sized buffers
[12:30] <domas> I just want that 15G dataset would stay in memory :)
[12:30] <domas> on 16GB machine
[12:31] <domas> (or 30GB dataset on 32GB machine)
[12:34] <IntuitiveNipple> The recommendation suggests 14G for a 16G machine, so maybe your expectations aren't realistic
[12:34] <domas> this is 13G btw
[12:34] <Kano> hi rtg , could you build a 2.6.29 server kernel?
[12:35] <domas> IntuitiveNipple: I have worked on InnoDB memory consumption more than actual InnoDB devs, or mysqlperformanceblog people, or nearly anyone in the industry
[12:35] <dandel> domas, read this... http://www.novell.com/coolsolutions/feature/18990.html
[12:35] <domas> dandel: that link has too simplistic information
[12:36] <dandel> what does cat /proc/sys/vm/swappiness reveal tho?
[12:36] <domas> for now I solved it way easier, my process does not do any non O_DIRECT operation
[12:36] <domas> dandel: right now it is at 1
[12:36] <domas> our default is 10
[12:37] <dandel> could always do a ramdisk swap instead of hd based swap.
[12:37] <domas> dandel: the problem is not actual swapping, but kswapd taking extra cycles to manage the buffers
[12:41] <amitk> rtg: is the -11.37 tag set correctly?
[12:42] <rtg> amitk: checking
[12:42] <domas> IntuitiveNipple: actually, if anyone would set 14G buffer pool, they'd definitely go OOM
[12:42] <apw> Kano, cna't you build that from the karmic tree?
[12:42] <domas> IntuitiveNipple: that setting made sense on earlier versions, which didn't have high per-page mutex overhead :)
[12:42] <Kano> apw: i could only build the generic one
[12:43] <rtg> amitk:  it looks close, why?
[12:43] <apw> Kano, why so?
[12:43] <Kano> i always got errors with the server one, not finding some modules or so
[12:43] <rtg> Kano: I'm running 2.6.29-1-server
[12:43] <amitk> rtg: 'close' ? I am tracking some regression in ARM flavours (versatile) due to AA being enabled.
[12:44] <Kano> rtg: hmm, maybe i need more free space then, but i deleted already much...
[12:44] <rtg> amitk: AFAICT the tag is planted right on the commit message that I would expect.
[12:45] <Kano> will test again.
[12:45] <amitk> rtg: but the commit after it (updateconfigs) was required
[12:46] <rtg> amitk: hmm, you might be right. I don't actually remember doing that, but I might have. (wouldn't be the first time)
[12:46] <rtg> amitk: I'm about to push some other stuff, so I'll fix the tag.
[12:47] <amitk> rtg: thanks.
[12:47] <amitk> rtg: any uploads planned?
[12:48] <rtg> amitk: yeah, I'd like to get one uploaded today.
[12:50] <rtg> amitk: ok, fixed the tag. the other commits I'm still testing.
[12:51] <amitk> rtg: could I push this trivial fix to linux-meta onto you then when you upload? https://bugs.edge.launchpad.net/ubuntu/+source/linux-meta/+bug/345992
[12:51] <ubot3> Malone bug 345992 in linux-meta "The one-line package description for the linux-image-imx51 and linux-image-versatile meta-packages appears wrong" [Undecided,Confirmed]
[12:51] <rtg> sure
[13:35] <domas> right, once all I/O is O_DIRECT, no swapping/caching is done
[14:55] <rtg> amitk: were you wanting to get something in today's upload?
[14:58] <amitk> rtg: I'm not done yet. Please go ahead. I'll commit tomorrow
[14:58] <rtg> amitk: I'm out tomorrow, so smb_tp will have to help if its something urgent. Otherwise, Monday
[14:58] <amitk> sure
[14:58] <smb_tp> Yessir :)
[14:59] <rtg> amitk: I'm doing a scorched earth Jaunty update on  my dev box, so perhaps Monday is optimistic :)
[15:08] <amitk> rtg: :)
[15:23] <BUGabundo> apw: so I don't keep confusing things
[15:23] <BUGabundo> what's is different with backports kernel?
[15:23] <apw> backports modules not kernel
[15:23] <BUGabundo> ahh
[15:23] <apw> its a collection of updated drivers for things.  currently wireless things which are moving fast
[15:24] <BUGabundo> so that's it
[15:24] <BUGabundo> so just about any one needs to have it?
[15:24] <BUGabundo> or only ppl with modules not compiled into kernel?
[15:25] <apw> people only need it if they have trouble with the main kernel drivers, or there is none
[15:25] <rtg> BUGabundo: only ppl that want the features offered by 2.6.29 wireless drivers and protocols
[15:25] <BUGabundo> ah so when I installe it my self without the need for it, am I doing it wrong?
[15:26] <apw> wrong is a relative term, you are putting together things which are less suited to each other
[15:26] <apw> they may work better or worse, better than nothing clearly
[15:27] <rtg> apw: actually, I think 2.6.29 wireless is beginning to work pretty well.
[15:27] <BUGabundo> since I have and intel 4965
[15:28] <BUGabundo> I guess the kernel support should be fine
[15:28] <apw> yeah i am more saying that your mixing things, that is likely to add risk, but is the only way for people who need it
[15:28] <BUGabundo> no great changes recently
[15:28] <rtg> BUGabundo: if the 2.6.28 driver is working for you, then why change?
[15:28] <BUGabundo> ehe
[15:28] <BUGabundo> don't fix what aint broken
[15:29] <apw> indeed
[15:29]  * BUGabundo looks at installed stuff
[15:29] <BUGabundo> 'cause I remember that change to kernel to fix kill_switch
[15:29] <BUGabundo> came on backports
[15:29] <apw> that'd be the definition of not working for you
[15:30] <laga> jau
[15:30] <laga> oops
[15:30] <laga> wrong window, sorry
[15:30] <BUGabundo> actually haven't tested the soft switch
[15:49] <kees> amitk: if you need help with AA, ask jjohansen on #apparmor on oftc, he's usually around and very helpful.
[15:53] <amitk> kees: we got it fixed for now. Thanks
[15:53] <amitk> kees: I did get in touch with him btw.
[16:30] <kees> amitk: ah, excellent
[17:16] <apw> dtchen, those two alsa write pointer fixes ... do they fix up the issues with pa and glitch-free do you know?
[18:42] <bradf> bradf: test
[18:43] <bradf> bradf: another
[18:43] <bradf> bradf: another
[22:18] <dtchen> apw: yes
[22:18] <apw> dtchen, most excellent
[22:18] <dtchen> apw: note that jaunty's pulseaudio version is a bit dated, so performance will be less optimal than with 0.9.15ish (or whatever Fedora 11 will have)
[22:19] <dtchen> still, users have been reporting markedly improved stability and performance
[22:20] <TheMuso> It seems that Lennart aims his releases for Fedora's release schedule, which is always going to mean we're behind the 8 ball so to speak.
[22:21] <TheMuso> As far as I understand things anyway.
[22:22] <dtchen> right, unless we obtain an exception for PA similar to what the GNOME desktop has
[22:22] <dtchen> of course that would mean updating the ALSA stack, too, which uh...
[22:23] <dtchen> anyhow, happy with what we're given
[22:26] <TheMuso> dtchen: Yep totally agree.
[22:26] <TheMuso> cd
[22:26] <TheMuso> woops wrong tab


[11:05] <yharrow_> Hey peoples
[14:18] <yharrow> hey :D
[14:18] <yharrow> sorry I missed your message yesterday. Went to bed early
[14:31] <Interruptus> howdy ho
[19:23] <yharrow> aww, missed your answer man. I'll try again tomorrow :P
[19:33] <Interruptus> yo ho


[01:12] <pedro_r_marques> Hello... i've a package that has a build-depends on a java lib that is in "universe"... how can i build this package using sbuild ?
[01:13] <pedro_r_marques> The sbuild chroot only has main installed as repo.
[01:13] <pedro_r_marques> is there any way for control file to specify that i need the universe repo as build dependency ?
[10:42] <DanChapman> Good Morning
[12:57] <rpadovani> hey all :-) Quickly question: there is already a basic support for NFC?
[13:06] <daker> rpadovani: i don't think so
[13:07] <rpadovani> daker, mhh, ok, thanks
[13:08] <daker> rpadovani: maybe try the QT/QML implementation and see if it works
[13:08] <daker> http://qt-project.org/doc/qt-5/qtnfc-poster-poster-qml.html
[13:08] <rpadovani> daker, this is a good idea


[00:00] -queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.1~rc1-3~ubuntu18.04.3 => 4.1~rc1-3~ubuntu18.04.4] (core)
[00:21] <xnox> cascardo:  i'm making dkms upload into focal, and hopefully it will make the virtualbox dkms test go green.
[00:21] <xnox> cascardo:  imho it should be ok if one installs dkms module, and kernel shims them already, and all is good.
[00:22] <xnox> cascardo:  however it seems like our kernel only ships like 3 out of 4 virtualbox modules. Why no ship video too?
[00:31] <RikMills> vorlon: could you remove the armhf/arm64 julia binaries from -release please? LP: #1856531
[00:31] <RikMills> removed in debian
[01:32] <xnox> cascardo:  apw: promote-to-release: Pending -- ready to cop
[01:32] <xnox> y
[01:32] <xnox> https://bugs.launchpad.net/kernel-sru-workflow/+bug/1856701
[05:15] -queuebot:#ubuntu-release- New binary: librcsb-core-wrapper [s390x] (focal-proposed/universe) [1.005-8] (no packageset)
[05:16] -queuebot:#ubuntu-release- New binary: librcsb-core-wrapper [ppc64el] (focal-proposed/universe) [1.005-8] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: librcsb-core-wrapper [amd64] (focal-proposed/universe) [1.005-8] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: librcsb-core-wrapper [arm64] (focal-proposed/universe) [1.005-8] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: librcsb-core-wrapper [armhf] (focal-proposed/universe) [1.005-8] (no packageset)
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [arm64] (focal-proposed) [1.005-7]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [amd64] (focal-proposed) [1.005-8]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [armhf] (focal-proposed) [1.005-8]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [s390x] (focal-proposed) [1.005-8]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [armhf] (focal-proposed) [1.005-7]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [ppc64el] (focal-proposed) [1.005-8]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [arm64] (focal-proposed) [1.005-8]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [amd64] (focal-proposed) [1.005-7]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [s390x] (focal-proposed) [1.005-7]
[06:03] -queuebot:#ubuntu-release- New: accepted librcsb-core-wrapper [ppc64el] (focal-proposed) [1.005-7]
[06:03] -queuebot:#ubuntu-release- New: accepted pbbam [amd64] (focal-proposed) [1.0.6+dfsg-2]
[07:39] <RikMills> libgit2 migrating. thanks!
[08:46] <LocutusOfBorg> vorlon, hello, cmake was not a bad upload
[08:46] <LocutusOfBorg> it was just needing the fixed qtbase-opensource-src from Debian...
[08:46] <LocutusOfBorg> I reuploaded it :)
[08:46] <LocutusOfBorg> (it should fix pango sadness, e.g. linphone and ettercap and other pango using cmake projects
[10:43] <LocutusOfBorg> apw, Laney autopkgtest for libapache2-mod-auth-openidc/unknown: s390x: Regression ♻
[10:43] <LocutusOfBorg> can you please hint it? it is NBS from source, not sure why it gets in that state
[10:44] <LocutusOfBorg> same for autopkgtest for debos/unknown: arm64: Regression ♻ , armhf: Always failed, i386: Regression ♻ , ppc64el: Always failed, s390x: Always failed
[14:18] <vorlon> LocutusOfBorg: fair enough; it was blocking other builds at the time on armhf and you weren't around to consult
[15:36] <RikMills> vorlon: your abi-compliance-checker oom-exec-helper.patch seems to have some bade perl?
[15:36] <RikMills> £"Can't "next" outside a loop block at /usr/bin/abi-compliance-checker line 10171."
[15:37] <RikMills> https://perldoc.perl.org/functions/do.html
[15:38] <RikMills> "do BLOCK does not count as a loop, so the loop control statements next, last, or redo cannot be used to leave or restart the block. See perlsyn for alternative strategies."
[17:03] <vorlon> RikMills: oh?  was it bad perl when I wrote it?
[17:05] <vorlon> do does not count as a loop despite having a while at the end, great
[17:06] <vorlon> not sure why I used a do {} while(1) instead of while(1) {} anyway :)
[17:10] <RikMills> vorlon: not sure. my perl is limited to what help pages google can land me on. lol
[17:10] <vorlon> :)
[21:34] -queuebot:#ubuntu-release- Packageset: Added libunibreak to i386-whitelist in focal
[22:14] <locutus_> vorlon, thanks for doing it, I understand what happened, I wasn't complaining, just reporting that the upload was "good" but I fell asleep before the autosync was kicking :D
[23:16] -queuebot:#ubuntu-release- New binary: guava-mini [amd64] (focal-proposed/universe) [0.1.2-1] (no packageset)
[23:49] -queuebot:#ubuntu-release- Packageset: Removed lbfgsb from i386-whitelist in focal


[05:09] <mborzecki> morning
[05:18] <mvo> hey mborzecki
[05:19] <mborzecki> mvo: hey
[05:20] <mup> PR snapd#8777 closed: packaging: disable buildmode=pie for riscv64 <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8777>
[05:22] <mborzecki> mvo: there is no docs for the snapd API besides the code, right? i recall we discussed tools to use for documenting it nicely, but i don't recall seeing any readmes or whatnot
[06:19] <mvo> mborzecki: sorry for the delay, did not see the msg - here are the docs https://github.com/snapcore/snapd/wiki/REST-API
[06:20] <mvo> mborzecki: but very outdated
[06:23] <mborzecki> mvo: thanks!
[06:24] <mborzecki> mvo: hm maybe we should move that to the forum
[06:35] <mborzecki> mvo: added the snapd REST API docs page in the forum  https://forum.snapcraft.io/t/snapd-rest-api/17954 we'll need to update it though
[06:37] <mvo> mborzecki: oh, nice
[06:38] <mvo> mborzecki: yes, it needs updating but having it here is a good step, I wonder if we can delete the wiki version or if we can redirect it or something
[06:38] <mborzecki> funny, i've never looked in the wiki section in the snapd repo, immediately assumed that forums is where it would live since we have all the docs there
[06:39] <mborzecki> mvo: perhaps we can discuss that quickly during the standup?
[06:40] <mvo> mborzecki: +1
[06:41] <mvo> mborzecki: yeah, the issue was that we always wanted to move it but there was never time and the perfect was (maybe) the enemey of the good
[06:41] <mvo> mborzecki: i.e. just moving it to the forum as is not that much work and beneficial but we always wanted to do more (like auto-generating it) hence the delay :/
[06:41] <mvo> mborzecki: anyway, thanks for doing this!
[06:42] <mborzecki> mvo: with gh actions, maybe we could update the forum doc automatically? :)
[06:42] <mvo> mborzecki: heh - nice idea!
[06:58] <zyga> o/
[06:58] <mvo> good morning zyga
[06:58] <zyga> mborzecki: actions can trigger on directories
[06:58] <zyga> good morning
[06:59] <zyga> though it's bad, I can barely stand :/
[06:59] <mvo> zyga: oh no :(
[07:00] <mborzecki> zyga: nice, so we'd need to agree on a format of the doc, swagger or maybe just plain markdown, and then push that to the forum automatically from master?
[07:01] <mborzecki> same markdown should work on github wiki if we want to keep maintaining that
[07:02] <pstolowski> morning
[07:12] <zyga> eh, thinkpad died on the spot again
[07:13] <pedronis> mvo: mborzecki: what is this https://forum.snapcraft.io/t/snapd-rest-api/17954 ?
[07:16] <mborzecki> pedronis: tried moving the snapd api docs from github wiki to the forum where they can be found, quick HO to discuss what to do with this?
[07:16] <mvo> pedronis: it's the old rest API from the wiki, mborzecki  moved it over to the forum this morning
[07:16] <pedronis> I would really like to involved in this kind of things
[07:17] <pedronis> mvo: there are bit that we probably don't want to document anymore at all
[07:17] <mborzecki> pedronis: sorry, maybe i was a bit quick to move that
[07:19] <mvo> pedronis: sure, what do you recommend? hiding the post? or "fixing", i.e. marking the bits we don't want as obsolete or removing them?
[07:19] <pedronis> mvo: did we plan to work on this right now?
[07:20] <pedronis> but yes, moving it over without a plan of how to improve it doesn't seem a great idea to me, but my 2cts
[07:20] <mvo> pedronis: we did not plan this
[07:21] <mup> PR snapd#8520 closed: data: fix shellcheck warnings in snapd.sh.in <Simple 😃> <Created by jelovac> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8520>
[07:21] <mvo> pedronis: if you think it's a net-negative we can just hide/remove it again
[07:21] <pedronis> mvo: did you at least talk with Graham?
[07:22] <mborzecki> pedronis: i'm happy to have a chat about that, the reason i moved it was that it was not easy to find them, so if they're in the forum could start updating them incrementally
[07:23] <pedronis> mborzecki: the problem is, we should discuss what to simply scrub before moving it over at least
[07:23] <mvo> pedronis: I did not, this happend this morning. but I think the intention is good and give us a chance to improve things. I understand your concerns though, maybe we can hide it and tweak it with the help of graham and then add it back? how does that sound?
[07:24] <pedronis> mvo: it should have been put in some place easier to edit at least initially
[07:25] <mborzecki> pedronis: ok, let me find out where degville keeps the pages for editing, move it to that location and we can take it from ther, wdyt?
[07:26] <mup> PR snapd#8767 closed: snap: (small) refactor of `snap download` code for testing/extending <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8767>
[07:33] <mborzecki> mvo: small tweak https://github.com/snapcore/snapd/pull/8722#discussion_r434363214
[07:33] <mup> PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
[07:36] <mvo> mborzecki: let's do that then, move into degville queue and hide until it's a bit nicer (we need to remove some bits like "buy")
[07:36] <mborzecki> ack
[07:37] <zyga> mvo: https://github.com/snapcore/snapd/pull/8722#pullrequestreview-423293055
[07:37] <mup> PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>
[07:46] <degville> mborzecki / mvo / pedronis: (morning!) it's great we're updating those API docs (thanks mborzecki!) - they've been on my mind for a long time. I think it's ok marking them WIP on the forum for now until we can go over them. They won't be published outside the forum until we add the page to the whitelist. They're currently only as broken as the GH wiki version :)
[07:49] <mborzecki> degville: hi, thanks for the tip, was about to add the header you have in other docs but i see you're already editing the page
[07:50] <degville> mborzecki: yeah, I just expanded on your note a little.
[07:51] <mborzecki> degville: great, thank you
[07:54] <pedronis> degville: there are really some things that we want to stop documenting, that's the part I'm unhappy about
[07:55] <pedronis> becaue they are again in fron of people
[07:56] <degville> pedronis: ok. would you rather I unlist the page? or would you simply prefer us to move it to a google doc for now?
[07:57] <pedronis> degville: well unlist for now and we talk in the standup about what needs removing and we decide how to proceed?
[07:57] <degville> pedronis: yep, np.
[07:57] <degville> done
[07:59] <mborzecki> pedronis: should we unlist the wiki page too? https://github.com/snapcore/snapd/wiki/REST-API
[08:03] <mborzecki> mvo: playing with your gdbserver branch, i think i've hit: https://sourceware.org/bugzilla/show_bug.cgi?id=18945
[08:05] <mborzecki> mvo: maybe it'd also be nice to pass a port number in --gdbserver[=<port>], otherwise the gdb command is different for each invocation
[08:08] <mvo> mborzecki: looking, sorry
[08:09] <pedronis> mborzecki: we can do that once we have decided what to do with the moving to the forum
[08:09] <mborzecki> pedronis: ok
[08:16] <mup> PR snapd#8773 closed: overlord/configstate: add sysctl option <Created by EthanHsieh> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8773>
[08:18] <mvo> mborzecki: reading this bug makes me wonder if the approach is doomed
[08:18] <mvo> mborzecki: actually, hm
[08:18] <mvo> mborzecki: maybe a quick ho?
[08:18] <mborzecki> mvo: ok
[08:18] <mborzecki> standup?
[08:19] <mvo> mborzecki: yeah, 1min
[08:19] <mvo> mborzecki: ready when you are
[09:48] <zyga> pedronis: can you look at https://github.com/snapcore/snapd/pull/8778 again please
[09:48] <mup> PR #8778: tests: modernize and use snapd.tool <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8778>
[09:48] <pedronis> zyga: not now, just mark it unblocked I suppose
[09:48] <zyga> ok
[09:48] <zyga> I put it on PATH
[09:48] <zyga> I guess that's okay
[09:55] <mborzecki> mvo: pushed some tweaks to https://github.com/snapcore/snapd/pull/8784 please take a look when you have a slot
[09:55] <mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
[09:57] <mvo> mborzecki: \o/ thank you, looking
[09:58] <mvo> mborzecki: thanks for https://github.com/snapcore/snapd/pull/8784#discussion_r434384356 - I like this idea a lot
[09:58] <mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
[10:00] <mvo> mborzecki: I really like your idea of breaking at exec and avoid the raise(SIGTRAP) but that's for later I guess :)
[10:30] <mborzecki> hmm actually surprised, i'm looking at the backtrace from a segfault in snap-store
[10:31] <mborzecki> target:/snap/snap-store/467/gnome-platform/usr/lib/x86_64-linux-gnu/libgdk-3.so.0 gtk3 in gnome platform snap are built with symbols?
[10:31] <mborzecki> the entries in backtrace are pretty detailed, eg `#5  0x00007f473cedab04 in gtk_label_get_preferred_layout_size (label=0x5612253d4ef0, smallest=0x7ffcf00c89b0, widest=0x7ffcf00c89a0) at ../gtk/gtklabel.c:3725`
[10:32] <mborzecki> heh, info sharedlibrary definitely lists some of the libraries in snap-store & gnome snaps are cotnainig debug symbols
[10:42] <zyga> pedronis: do you have a moment to summarize what you want to do about snapd tools?
[10:43] <zyga> pedronis: you said you want them to behave more like in classic
[10:43] <zyga> are you thinking about making whatever tools we have available in the initial mount ns and then just inheriting all of that (and change propagation) into snap namespaces?
[10:44] <pedronis> zyga: probably better to chat tomorrow
[10:44] <zyga> pedronis: I may be off tomorrow for a medical visit, if you have the time just summarize this in an email and share that when you have the time
[10:44] <zyga> pedronis: but that's fine, I have things to do
[10:44] <zyga> just wanted to understand your ideas better
[10:46] <mup> PR snapd#8796 opened: tests: modernize retry tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8796>
[10:48] <mborzecki> zyga: https://forum.snapcraft.io/t/gimp-broken/17958
[10:49] <zyga> hmm
[10:49]  * zyga tries
[10:50] <zyga> mborzecki: I wonder if we released robust mount namespace updates?
[10:51] <mborzecki> wasn't that in 2.44 already?
[10:52] <mborzecki> ah no, it was but disabled, 2.45 made it default in https://github.com/snapcore/snapd/commit/716ec3de3526e7c6eb1b22e3d077b4fc48d69a6e
[10:54] <zyga> mborzecki: works on my machine :/
[10:56] <mborzecki> heh ;)
[10:56] <mborzecki> quick errand, back in 30
[11:29] <mborzecki> re
[11:45] <zyga> pstolowski: follow up from the parsed security tag branch https://github.com/snapcore/snapd/pull/8797
[11:45] <mup> PR #8797: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <https://github.com/snapcore/snapd/pull/8797>
[11:46] <pstolowski> zyga: ty!
[11:47] <mup> PR snapd#8797 opened: snap/naming: add helpers to parse app and hook security tags <Created by zyga> <https://github.com/snapcore/snapd/pull/8797>
[11:51] <mborzecki> zyga: something is wrong with the spread jobs, ther's a bunch of queued jobs, some from 15h ago
[11:52] <zyga> mborzecki: checking
[11:53] <zyga> hmmm
[11:53] <zyga> odd
[11:53] <mborzecki> zyga: https://github.com/snapcore/snapd/actions?query=workflow%3ATests
[11:53] <zyga> yeah, I looked
[11:53] <zyga> I saw something similar yesterda
[11:53] <zyga> when after a unit test job was finished
[11:53] <zyga> all of a sudden *all* the spread jobs started
[11:54] <zyga> maybe it's somehow related to slot allocation
[11:56] <pedronis> mborzecki: I did a pass on #8775, it's a bit unclear what should happen with the recovery partition scripts
[11:56] <mup> PR #8775: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
[11:56] <pedronis> it seems to support updates but not installing
[11:56] <pedronis> but then updates are called install
[11:57] <zyga> mborzecki: ha, it just happened
[11:57] <zyga> brb
[12:03] <mborzecki> pedronis: thanks, will check the comments
[12:03] <mborzecki> zyga: anything interesting there? did the spread jobs start?
[12:04] <jdstrand> mvo, pstolowski: is tests/lib/nested.sh supposed to be shellcheck clean on bionic?
[12:05] <pstolowski> jdstrand: it should be clean everywhere, yes
[12:06] <jdstrand> let me get you a paste
[12:06] <jdstrand> (me dev container is still bionic)
[12:07] <jdstrand> my*
[12:07] <jdstrand> pstolowski: https://paste.ubuntu.com/p/wPYVVt4VdX/
[12:08] <jdstrand> pstolowski: you did touch that line recently, but if I change it back, more errors are unconvered
[12:10] <pstolowski> jdstrand: that's unexpected, should have been caught on travis; thanks, i'll check it
[12:11] <jdstrand> pstolowski: thank you. note, it had been a while (weeks?) since I last ran run-checks (tasked with work that didn't involve submitting PRs), so not sure when it was introduced
[12:14] <zyga> hmmm
[12:14] <zyga> mborzecki: lxd refreshed and we ran out of memory
[12:14] <zyga> we allocated all the memory and the system was in limbo state after oom killer went hunting
[12:15] <pstolowski> jdstrand: ok,  weird.. even recently i had a shellcheck error there and it was preventing merging. very weird it get through
[12:15] <pstolowski> *got
[12:15] <mborzecki> zyga: hm, w8, how much mem does this system have?
[12:15] <zyga> I'm looking though the logs now
[12:15] <zyga> 8GB
[12:15] <zyga> mborzecki: but it's not usually staturated, it's happened the moment lxd refresh ran
[12:16] <zyga> https://usercontent.irccloud-cdn.com/file/DTVVZl9c/overnight%20lxd%20refresh%20crash
[12:16] <zyga> load average approaching 1K?
[12:17] <mborzecki> hmm auto update ;)
[12:17] <zyga> maybe I should configure lxd with memory limits
[12:17] <mborzecki> zyga: can you see what got killed by oom?
[12:18] <zyga> https://usercontent.irccloud-cdn.com/file/j5i39wAk/dashboard%20over%20last%20two%20weeks
[12:27] <jdstrand> pstolowski: I noticed that shellcheck is only conditionally run on if it is installed. not sure if that helps track things down for you...
[12:28] <pstolowski> jdstrand: interesting.. thanks!
[12:34] <pedronis> pstolowski: should we re-run things to land #8567? or do you want to see #8780 green first?
[12:34] <mup> PR #8567: o/devicestate: core20 early config from gadget defaults <UC20> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[12:34] <mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
[12:36] <pstolowski> pedronis: restarted. i don't think it needs to wait for 8780
[12:36] <pedronis> ok
[12:37] <mup> PR snapd#8798 opened: data/selinux: allow checking /var/cache/app-info <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>
[12:37] <mup> PR snapd#8799 opened: interfaces/system-packages-doc: fix typo in variable names <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8799>
[12:46] <pedronis> jdstrand: I tried to answer your questions in a couple of open PRs
[12:47] <xnox> mvo:  what needs to happen to have https://github.com/snapcore/bolt/pull/1 merged & then vendorized version updated?
[12:47] <mup> PR bolt#1: Enable riscv64 build <Created by xnox> <https://github.com/snapcore/bolt/pull/1>
[12:47] <xnox> given it is #1 i fear this has never been excercised =)
[12:50] <zyga> pedronis: updated the parsed tag PR
[12:50] <zyga> I need to reboot, my thinkpad is acting up again, x input broke
[12:50] <zyga> eh
[12:51] <jdstrand> mvo: fyi, https://github.com/snapcore/snapd/pull/8398#issuecomment-638175977 (I deconflicted but there are cla-check issues still)
[12:51] <mup> PR #8398: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
[12:54] <zyga> jdstrand: o/ 8788 is not more strict (the hwcaps PR)
[12:54] <zyga> is *now* more strict
[12:59] <jdstrand> pe
[12:59] <mvo> xnox: merged now, now it just needs an update to the vendor.json in snapd, I can do that after the meeting
[13:00] <jdstrand> pedronis: thanks! I responded to PR 8789 (note, that isn't urgent so if you're busy, feel free to circle back)
[13:00] <mup> PR #8789: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8789>
[13:00] <zyga> mvo: I don't really feel able to attend the meeting today
[13:00] <xnox> mvo:  tah. I don't know how to correctly do govendor stuff. and plus then the ci will run against this bolt change for the first time.
[13:00] <xnox> it better not regress anything on non-riscv64!
[13:01] <mborzecki> pstolowski: https://github.com/snapcore/snapd/blob/master/.github/workflows/test.yaml#L74-L78
[13:02] <mborzecki> maybe we should use --edge there
[13:02] <mvo> zyga: no worries, get well!
[13:02] <mvo> xnox: no worries
[13:03] <pstolowski> mborzecki: thanks, is it run only on 16.04 or am I reading it wrong?
[13:08] <pstolowski> jdstrand: turns out we run shellcheck from a snap (which is shellcheck 0.7.0). bionic has shellcheck 0.4.6
[13:10] <pstolowski> jdstrand: can you try with the version from snap?
[13:17] <jdstrand> oh!
[13:17] <mup> PR snapd#8800 opened: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open - 2.45 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8800>
[13:18] <jdstrand> pstolowski: absolutely yes. I was thinking I needed to backport shellcheck from focal, but then when you said it was supposed to work everywhere, I stopped
[13:20] <jdstrand> mvo: ok, sorry to keep pinging you. as mentioned, I deconflicted PR 8398. The submitter signed the cla (see my PR comment) but cla-check is still failing. so I milestoned that to 2.46 and then created PR 8800 for 2.45 with 'Original-Author: troyready<EMAIL_ADDRESS>[13:20] <mup> PR #8398: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open <Created by troyready> <https://github.com/snapcore/snapd/pull/8398>
[13:20] <mup> PR #8800: usersession/userd: add "slack" to the white list of URL schemes handled by xdg-open - 2.45 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8800>
[13:20] <jdstrand> mvo: but it failed with<EMAIL_ADDRESS>(https://api.launchpad.net/1.0/~troyready) has NOT signed the CLA'
[13:20] <pstolowski> jdstrand: ok, good; so for clarity, we only care about latest shellcheck
[13:21] <jdstrand> mvo: oh, actually, I see troyready signed the code of conduct, I don't know about the cla, but he has a screenshot in the original PR
[13:21] <jdstrand> mvo: so, yeah, I'll defer to you on how to proceed
[13:27] <jdstrand> pstolowski: yep, understood
[13:35] <zyga> gah, another sudden power off
[14:01] <mvo> xnox: I pushed 8801 with the bolt update
[14:02] <mvo> jdstrand: thanks, I have a look why the cla is acting up, it's unfortunately a constant hassle :(
[14:02] <mup> PR snapd#8801 opened: vendor: update to latest github.com/snapcore/bolt for riscv64 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8801>
[14:05] <jdstrand> mvo: :\
[14:20]  * cachio afk
[14:41] <zyga> cmatsuoka: when would be a good time to update spread?
[14:41] <zyga> do you need the new master deployed?
[14:42] <cmatsuoka> zyga: let me update the yaml and prepare a PR to update the secure-boot attribute
[14:42] <zyga> cmatsuoka: I think we should burn through the current queue first
[14:43] <zyga> cmatsuoka: can we agree on a a time, perhaps tonight when europe stops working
[14:43] <cmatsuoka> zyga: sounds good, I'll leave the PR ready and then we can switch at any convenient time
[14:43] <zyga> ok
[14:51] <cmatsuoka> zyga: https://github.com/snapcore/snapd/pull/8802
[14:51] <mup> PR #8802: spread.yaml: update secure boot attribute name <Simple 😃> <Skip spread> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8802>
[14:52] <zyga> hmm perhaps skip spread is undesired :)
[14:52] <zyga> but I think we can close and reopen without it
[14:52] <zyga> that's fine, I'll do this late at night when there is less activity
[14:52] <mup> PR snapd#8802 opened: spread.yaml: update secure boot attribute name <Simple 😃> <Skip spread> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8802>
[14:53] <cmatsuoka> zyga: it will fail with the current spread, but we can remove the skip tag after spread is updated
[14:53] <zyga> ok
[14:53] <zyga> yeah, we learned that the tags tend to stick though :)
[14:53] <zyga> that's fine
[14:53] <zyga> we can use the close / open trick
[14:53] <cmatsuoka> oh really? well ok then
[14:53]  * zyga breaks for some time to just rest and avoid pain
[14:53] <zyga> yeah, we noticed when the tag was first used in actions but perhaps this was not common knowledge in the team yet
[14:56] <cmatsuoka> if everything else fails we can close it and open another PR :)
[14:57] <zyga> or run it manually and land :)
[15:10] <pstolowski> cachio: could you take a look at the new spread test in https://github.com/snapcore/snapd/pull/8780  ?
[15:10] <mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
[15:13] <mup> PR snapcraft#3154 opened: cmake v2 plugin: take source-subdir into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3154>
[15:46] <pedronis> ijohnson: you froze for me
[15:47] <ijohnson> yes rejoingin one moemnt sorry
[15:50]  * cjp256 laughed at`Download snap "snapcraft" (4852) from channel "latest/edge"  0%  0B/s ages!`
[15:51] <cjp256> Specifically at the 'ages!', not the fact it's not downloading anything :)
[15:53] <mup> PR snapd#8803 opened: tests: port interfaces-many-core-provided to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8803>
[16:03] <cachio> pstolowski, sorry, I was with the doctor
[16:03] <cachio> pstolowski, I'll check it now
[16:06] <cmatsuoka> cjp256: at 0B/s it should really be never, not ages
[16:06] <pstolowski> cjp256: haha, i've never seen this; interestingly i've just checked, and we have a TODO there saying "// TODO: figure out exactly what overflow causes the ==0"
[16:07] <cjp256> cmatsuoka: I think it is being optimistic ;)
[16:07] <cjp256> hah
[16:07] <pstolowski> yeah, it wants to give hope
[16:17] <cachio> pstolowski, review done
[16:17] <cachio> just minor changes required.
[16:17] <pstolowski> cachio: thanks!
[16:17] <cachio> pstolowski, yaw
[16:43] <zyga> the day of constant pain is not a good day
[16:52] <zyga> hrm
[16:52] <zyga> I have a patch I cannot find
[16:52] <zyga> where did I put it
[16:53] <mup> PR snapd#8804 opened: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>
[16:56] <zyga> I'll make some coffee and get painkillers
[16:56] <zyga> and then do one more PR
[16:56] <zyga> and maybe help drain the queue by running more workers
[16:56] <zyga> afk
[17:11] <zyga> re
[17:13] <pstolowski> cachio: hey, re your comment for " 2 functions: 1 for unsign and 1 for sign "
[17:14] <pstolowski> cachio: do you think just one function that does sbattach --remove & sbsign would be ok? i'm not sure we need more granularity
[17:15] <cachio> pstolowski, yes
[17:15] <pstolowski> ok
[17:15] <cachio> the idea is to have that as a function so the tests are more easy to read / understand
[17:15] <cachio> in the future
[17:15] <cachio> thanks
[17:28] <zyga> https://github.com/snapcore/snapd/pull/8805 is the last one :)
[17:28] <mup> PR #8805: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8805>
[17:28] <mup> PR snapd#8805 opened: tests: port interfaces-calendar-service to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8805>
[17:28] <zyga> please look at the two "test robustness" PRs
[17:28] <zyga> no more leaking dbus
[17:30] <om26er> Is there a place to track progress of UbuntuCore 20, its "what's new" and an expected timeline for its release ?
[17:32] <zyga> om26er: good question
[17:32] <zyga> om26er: it's a bit hazy, apart from what's in the PRs that are landing
[17:33] <zyga> om26er: I heard that beta is coming soon but there are still some TODOs in the code
[17:34] <om26er> maybe there is a public kanban I could look at ?
[17:35] <zyga> nope
[17:35] <zyga> I wish we used github projects for the public side but that didn't go far
[17:35] <zyga> you can expect ongoing releases to broaden core20 support
[17:43] <mup> PR snapd#8806 opened: tests: install/run the lzo test snap too <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8806>
[17:48]  * cachio -> app with doctor part 2
[17:50] <pstolowski> cachio: updated #8780
[17:50] <mup> PR #8780: tests: core20 early defaults spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8780>
[18:13] <zyga> hmm
[18:13] <zyga> I will fight the pain and go and turn on some extra workers
[18:13] <zyga> this queue is not shrinking fast enough
[18:45] <cmatsuoka> hmm, tests stalled again
[18:47] <zyga> sorry, I was not able to go down
[18:48] <zyga> back hurts badly and affects leg
[18:49] <cmatsuoka> ah ugh, yeah, don't do anything that could make it worse
[19:34] <mup> PR snapcraft#3155 opened: storeapi: specify Content-Type for icon <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3155>
[19:44] <mup> PR snapcraft#3156 opened: log: trace HTTP connections with developer debug <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3156>
[19:53] <cachio> zyga, any idea why jobs for #8790 are queued?
[19:53] <mup> PR #8790: tests: update the file used to detect the boot path on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8790>
[19:53] <zyga> because we are burning through this backlog: https://github.com/snapcore/snapd/actions?query=is%3Aqueued
[19:56] <cachio> zyga, I see
[20:19] <jdstrand> degville (cc emitorino): hi! is https://github.com/snapcore/snapd/wiki/REST-API the right place to look at the rest api of /run/snapd.socket? I expected something more like https://api.snapcraft.io/docs/info.html but for snapd's socket (also, what about a similar page for snapctl?)
[20:21] <degville> jdstrand: unfortunately, yes, right now. Moving it to somewhere more appropriate is on our immediate to do list, and we're meeting this week to discuss it.
[20:21] <degville> And of course updating it and the process to keep it updated.
[20:22] <jdstrand> degville: oh, heh. nice. AIUI, the snapctl api could probably live on the same page since it will largely be a subset of the snapd api
[20:23] <emitorino> ack jdstrand
[20:23] <jdstrand> degville: but emitorino and I were talking about how there is a lack of documentation on the security properties of /run/snapd.socket (snap) vs /run/snapd-snap.socket (snapctl), so perhaps some verbiage on that could be included? 2 cents
[20:26] <jdstrand> degville: thanks for all your doc work btw :)
[20:26] <degville> jdstrand / emitorino: yes, definitely. after we've sorted its location and how we'll keep it updated, maybe i could ping you for your thoughts. Also, thanks for the snapctl api (oh, thanks :) still lots to do!)
[20:29] <jdstrand> degville: perhaps add userd's DBus API to the list as well (along with its security properties, if it makes sense there)? (sorry, that is the last one I had in my mind)
[20:29] <jdstrand> degville: and yes, emitorino and I would be happy to chat about the security aspects whenever it makes sense for you
[20:30] <degville> jdstrand: ok. Thank you!
[20:58] <zyga> I managed to get downstaris and I lit up 32 more nodes
[20:58] <zyga> we should eat the rest of the queue quickly now
[20:58] <cachio> zyga, awesome, thaks a lot
[21:01] <cmatsuoka> zyga: thanks, but be careful, the impact will be much larger if you get worse
[21:01] <zyga> cmatsuoka: thank you, I really want to get better
[21:01]  * cmatsuoka just ordered a new NAS
[21:02] <zyga> neat :)
[21:02] <zyga> degville: I bought SC-D70 earlier today
[21:02] <zyga> cmatsuoka: I joined the midi party
[21:03] <cmatsuoka> zyga: oh haha, what did you get there?
[21:03] <zyga> cmatsuoka: a vintage roland midi module
[21:03] <cmatsuoka> the canvas? or mt?
[21:03] <zyga> the canvas
[21:03] <zyga> canvas D70
[21:03] <cmatsuoka> oh nice!
[21:04] <zyga> it's the most modern of the pack
[21:04] <cmatsuoka> haha, that's great
[21:04] <zyga> and does a bit more than the older guys
[21:04] <degville> zyga: awesome!
[21:09] <zyga> all the workers are lit up but they are not receiving jobs from github
[21:10] <cmatsuoka> humm, that's odd
[23:00] <mup> PR snapd#8807 opened: Revert "Enable riscv64 builds in the edge PPA without PIE" <Created by xnox> <https://github.com/snapcore/snapd/pull/8807>
[23:45] <mup> PR snapd#8808 opened: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>