[02:43] <madhens> Minutes posted: https://discourse.ubuntu.com/t/minutes-for-the-2021-05-19-community-council-meeting/22367
[02:45] <Wild_Man> madhens, the timing of the IRC issue is good timing I guess as we were already discussing it
[15:00] <slyon> o/
[15:00] <mclemenceau> o/
[15:00] <waveform> o/
[15:00] <juliank> o/
[15:00] <rbalint> o/
[15:00] <bdmurray> o/
[15:01] <bdmurray> #startmeeting Weekly Ubuntu Foundations team
[15:01] <meetingology> Meeting started at 15:01:00 UTC.  The chair is bdmurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:01] <bdmurray> #topic Lightning Round
[15:01] <bdmurray> echo $(shuf -e vorlon bdmurray doko sil2100 rbalint mwhudson juliank waveform slyon jawnsmith dbungert)
[15:01] <bdmurray> dbungert rbalint vorlon mwhudson waveform jawnsmith bdmurray doko slyon sil2100 juliank
[15:01] <dbungert> * LP: #1925068 - push a workaround
[15:02] <dbungert> * LP: #1928815 - merge with Debian, pending sponsor.  We might need another
[15:02] <dbungert>   for a suggested timezone, add autoinstall config for the same, add unit tests
[15:02] <dbungert>   upload soon in irssi to handle libera.
[15:02] <dbungert> * Subiquity Set Timezone - abstract existing geoip code so that we can use that
[15:02] <dbungert>   around this and similar areas.  WIP.
[15:02] <dbungert> * MoM: ifenslave - learn background on the package and Ubuntu capabilities.  My
[15:02] <dbungert>   recommendation for this package is a status quo answer - merely merge with
[15:02] <dbungert>   Debian and be done for now.  Next action is to smoketest basic capabilities.
[15:02] <dbungert> (done)
[15:02] <rbalint> * merged schroot, dbus, systemd (tested in bileto, about to upload)
[15:02] <rbalint> * partner work
[15:02] <rbalint> * preparations for next glibc upload + sru rounds
[15:02] <rbalint> (done)
[15:02] <bdmurray> vorlon:
[15:03] <bdmurray> how about waveform then
[15:03] <waveform> * Merges for u-boot (LP: #1928777) and lvm2 (LP: #1928973) (twice because ... stupidly forgot there was a pending bit to be dropped due to last initramfs-tools merge)
[15:03] <waveform> * Working on merge for nfs-utils
[15:03] <waveform> * Worked on autopkgtest-web optimizations
[15:03] <waveform> * Reviewed sense HAT libraries (no major pain as rtimulib isn't upstream anyway)
[15:03] <waveform> * Pi meetings
[15:03] <waveform> (done)
[15:03] <JawnSmith> * Re-write ubuntu image in go
[15:03] <JawnSmith>     * Now builds warning free!
[15:03] <JawnSmith> * HiFive Unmatched hardware support
[15:03] <JawnSmith>     * blog post well underway
[15:04] <JawnSmith>         * Explains how to install to NVME and boot from it
[15:04] <JawnSmith>         * Explains how to set up M.2 wifi/bluetooth module
[15:04] <JawnSmith>         * Explains how to set up a graphical desktop interface
[15:04] <JawnSmith> * LP: #1912371 fixing FTBFS in flashrom
[15:04] <JawnSmith> * LP: #1928966 merge procps from Debian
[15:04] <JawnSmith> [done]
[15:04] <bdmurray> special sru-review of cloud-init, google-compute-engine-oslogin
[15:04] <bdmurray> special sru-release of ubuntu-advantage-tools
[15:04] <bdmurray> submitted an upstream lintian PR re impish
[15:04] <bdmurray> submitted MP re sru-review and retrying adding a comment                                                                                https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/retry-bugmessage/+merge/402712
[15:04] <bdmurray> merged, uploaded another update-notifier ESM change
[15:04] <bdmurray> reported LP: #1928392 re lintian and uploaded fixes for it
[15:04] <bdmurray> sru-verification of LP: #1928392 for hirsute
[15:04] <bdmurray> reported, uploaded, sru-verified a fix for LP: #1928397 for Focal
[15:04] <bdmurray> commented on likely duplicates of the above re testing -proposed
[15:04] <bdmurray> force-badtest update-motd for hirsute
[15:04] <bdmurray> ✔ done
[15:05] <bdmurray> doko:
[15:05] <doko> - second part of the first impish merge party, beta squad, where are you? ;)
[15:05] <doko> - PyCon development sprints on Mon and Tue
[15:05] <doko> - GCC 9.4 release candidate
[15:05] <doko> - Python 3.10 and 3.9 backports for focal, groovy, hirsute. 3.8 will follow
[15:05] <doko> - working with upstream on the debugedit release, split out from rpm to better fit non-rpm based dis
[15:05] <doko> tros
[15:05] <doko> - some package removals, syncs and merges
[15:05] <doko> (done)
[15:05] <slyon> - On +1 last week:
[15:05] <slyon>   * atlas, python-pyscss, python-barbicanclient, kpatch, ply, pycparser,
[15:05] <slyon>     cdrkit, db5.3, jack-rack
[15:05] <slyon> - Merged: vim, curl, popularity-contest, user-setup, logrotate
[15:05] <slyon> - Testing & improving NetworkManager snap on UC20, MP#400398
[15:05] <slyon>   * Improving on comments mentioned by Tony
[15:05] <slyon>   * Cleaning up temporary hacks to make the snap build, not needed anymore, now
[15:05] <slyon>     that the SRU is in focal-updates
[15:05] <slyon>   * libnetplan 0.102 now landed in core20/stable \o/
[15:05] <slyon>   * Investigating the flaky Jenkins CI...
[15:05] <slyon>   * small test improvements to the snapd PR (LP: #1926442)
[15:05] <slyon> [15:05] <slyon> - Finalized 0.102 SRU for Groovy & Focal
[15:05] <slyon> - Reviewed systemd/activation-mode PR#171
[15:05] <slyon> - Working on YAML generator, PR#211
[15:05] <slyon> (done)
[15:05]  * vorlon waves
[15:05] <bdmurray> sil2100:
[15:05] <sil2100> I am not ready, please skip! I'll possibly send it over via e-mail if I don't make it in time
[15:06] <bdmurray> juliank:
[15:06] <juliank> may 13 (missed meeting):
[15:06] <juliank> * boot loaders:
[15:06] <juliank>   - verified the fixed grub for xenial arm64 (LP: #1926748). We only reverted src:grub2 in xenial, causing MAAS images and stuff to break over the weekend :/
[15:06] <juliank> * merge party:
[15:06] <juliank>   - synced python-apt 2.2.0
[15:06] <juliank>   - merged xfsprogs
[15:06] <juliank>   - merged rsyncs
[15:06] <juliank> * *apt:
[15:06] <juliank>   - retried python-apt/xenial triggered tests that failed due to grub arm64 install failure
[15:06] <juliank>   - apt: finalized the "TLS handshake errors are transient" test case. Corner cases, ugh.
[15:06] <juliank> * autopkgtest-cloud:
[15:06] <juliank>   - Changed publish-db to use one-off backup rather than incremental (which restarted upon writes); trimmed runtime down from up to 20 mins to 20-ish seconds.
[15:06] <juliank>     Was made possible by switch to WAL; previously it would have blocked writers for too long :)
[15:06] <juliank>   - The autopkgtest.ubuntu.com/packages/<name> pages now take 1/2 second instead of 15 seconds. Just added an index to the database :)
[15:06] <juliank> may 20:
[15:06] <juliank> * short week, was out last (thursday and) friday.
[15:06] <juliank> * merge party:
[15:06] <juliank>  - merged cron 3.0pl1-137ubuntu1
[15:06] <juliank> * apt:
[15:07] <juliank>   - 2.3.5 release: policy: Apply phasing to uninstalled packages too (LP: #1925745)
[15:07] <juliank>   - prepared 2.2.4 update with bug fixes for unstable/bullseye
[15:07] <juliank>   - prepared 2.2.4ubuntu1 with JSON hook 0.2 support
[15:07] <juliank>   - preparing 2.0.6 atm for focal, containing the (applicable) bits from 2.2.3 and 2.2.4ubuntu1, as well as the signal handler change from 2.2.2
[15:07] <juliank> * UEFI shenanigans:
[15:07] <juliank>   - decided with vorlon and xnox upon an approach to fix problems with our new shim: stop mirroring the vendor dbx into MokListXRT variable. Gotta setup testing for that and code it :/
[15:07] <juliank> * filed LP: #1929082 against Launchpad to keep old updates in -updates pocket while phasing new one
[15:07] <juliank> * learned about close_range() being in kernel 5.9
[15:07] <juliank> * copied my freenode settings in weechat to libera.chat ;)
[15:07] <juliank> (done)
[15:07] <bdmurray> vorlon:
[15:07] <vorlon>  * working on fixing a grub packaging regression in < focal due to the grub 2.04 work (LP: #1928674)
[15:07] <vorlon>  * working through how to handle a shim regression on some Apple hardware (LP: #1928434)
[15:07] <vorlon>  * discussions about how to SecureBoot sign a new kernel that won't be in the main archive
[15:08] <vorlon> (done)
[15:08] <bdmurray> sil2100: are you ready now?
[15:08] <sil2100> ...not yet, by e-mail
[15:08] <bdmurray> are there any questions on status?
[15:10] <bdmurray> #topic Release Incoming Bugs
[15:10] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-incoming-bug-tasks.html#foundations-bugs
[15:10] <bdmurray> bug 1928860
[15:11] <bdmurray> That seems incomplete to me
[15:12] <bdmurray> Or rather like its still under discussion
[15:12] <bdmurray> So let's pass on that for now
[15:12] <bdmurray> bug 1927994 I still need to investigate
[15:13] <bdmurray> bug 1929059
[15:14] <bdmurray> Does anybody have an opinion on this?
[15:16] <vorlon> I hadn't seen this "hwmatch" error before, has anyone else?
[15:16] <sil2100> Feels like something we might want to get cleaned up, but not super priority
[15:16] <vorlon> agreed
[15:16] <sil2100> Should we still card that in that case and just keep it in the backlog?
[15:16] <sil2100> I wouldn
[15:17] <sil2100> 't
[15:17] <sil2100> mind a reminder
[15:17] <bdmurray> I thought we were trying to reduce the backlog.
[15:17] <sil2100> (many accidental enter presses)
[15:17] <bdmurray> So let's just leave it tagged incoming
[15:17] <mclemenceau> +1
[15:18] <bdmurray> bug 1921862
[15:18] <sil2100> Oh, this I'd like to get fixed, but I saw the minimal change as per what JB proposed didn't cut it
[15:19] <sil2100> ...and I have no clue about ubuntu-archive-publishing
[15:19] <juliank> +1
[15:19] <bdmurray> Okay, so let's card that
[15:19] <mclemenceau> ok
[15:20] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-incoming-bug-tasks.html
[15:20] <bdmurray> there is nothing there \o/
[15:20] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[15:20] <bdmurray> bug 1926819
[15:22] <bdmurray> I might have merged this, let's card this and assign it to me and I'll dig into it.
[15:22] <mclemenceau> Ok will do
[15:22] <sil2100> +1
[15:24] <bdmurray> #topic Team proposed-migration report
[15:25] <vorlon> #link https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:25] <vorlon> e2fsprogs has a build failure; doko this was your upload, are you looking at this?
[15:26] <vorlon> while waiting for an answer
[15:26] <bdmurray> I'll take update-notifier
[15:27] <vorlon> update-motd has regressed on armhf; I haven't hinted it because that seems like a core package someone should look at the failures on
[15:27] <doko> why does completion on "vorlon" doesn't work here?
[15:27] <doko> I'll have a look at e2fsprogs
 invisible
[15:27] <vorlon> doko: thanks
[15:27] <vorlon> anyone want to look into update-motd/armhf?
[15:28] <vorlon> it's a weird failure
[15:28] <rbalint> i took a quick look i think it regressed with python
[15:28] <vorlon> fcntl shouldn't fail :P
[15:28] <vorlon> rbalint: I didn't see any python uploads in that window, though?
[15:28] <rbalint> yes, it is odd
[15:28] <rbalint> i can take it for next week
[15:28] <vorlon> thanks
[15:28] <vorlon> those are the only two that need looking at currently, then
[15:29] <vorlon> bdmurray:
[15:29] <bdmurray> #topic AOB
[15:29] <slyon> I'm out on Monday, due to a national holiday
[15:29] <JawnSmith> I'll be out from Wednesday May 27 to Monday May 31
[15:30] <JawnSmith> oops, Wednesday May 26*
[15:30] <bdmurray> Okay, if there is nothing else. Thanks everybody!
[15:31] <bdmurray> #endmeeting
[15:31] <meetingology> Meeting ended at 15:31:07 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-05-20-15.01.moin.txt
[15:31] <rbalint> o/
[15:31] <slyon> o/
[15:31] <mclemenceau> o/


[17:52] <desrt> word.
[17:54] <desrt> i found the oddest bug in what i believe to be the libc: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/838975
[17:55] <desrt> i've done a lot of digging/investigating so far but i'd appreciate help from someone more familiar with these things
[17:55] <desrt> since i'm sort of at a dead-end
[20:07]  * desrt steps out for a moment


[03:08] <tiktik> how to download ubuntu touch os latest version on meizu m2 note consisting of inbuilt android lollipop os
[03:09] <tiktik> 16.04  by xenial xerus will it work on my device or not...
[03:10] <tiktik> first upon how to download ubuntu touch os image file...
[03:11] <tiktik> no answers...
[03:14] <tiktik> how to download image file of ubuntu touch os for meizu m2 note android lollipop device...
[03:17] <tiktik_> how to download ubuntu touch os on my android lollipop os for meizu m2 note...
[03:18] <tiktik_> please man.. tell me something... i dont understand as if i am learner...
[03:19] <tiktik_> very much difficult to use open source platform ....
[08:22] <Tm_T> moin
[08:23] <Smurphy> Morning
[08:23] <Tm_T> my ubuntu phone has working vpn connection, I'm happy (:
[08:31] <Smurphy> Tm_T: Nice :) Not needing VPN on my side.
[08:31] <Smurphy> :}
[09:05] <[tj]> moin
[12:55] <mardy> dobey: hi! When you have some time, you are welcome to try https://requests.ci-train.ubuntu.com/#/ticket/1049
[12:55] <mardy> dobey: then please ping me when you are available for a few questions
[13:39] <adfad666> How should I enable ADB? it never comes up on my port
[13:51] <abeato> ogra_, where is the right place to propose changes to initramfs-tools-ubuntu-touch ?
[13:52] <ogra_> abeato, a bug i guess ... with a debdiff ... unless morphis and friends have moved it to CI yet (which would be pointless regarding the workflow)
[13:53] <abeato> ogra_, ok I see... is the init script there too btw?
[13:53] <ogra_> which init script ?
[13:54] <abeato> ogra_, the one that comes in initrd
[13:54] <ogra_> well, /init should come from initramfs-tools ... only the touch script comes from that package
[13:55] <abeato> ogra_, ok, so that one is generic for ubuntu, isn't it?
[13:55] <ogra_> init is, yeah
[13:55] <abeato> got it, thanks
[13:59] <morphis> ogra_: I doubt initramfs-tools is moved yet
[14:02] <ogra_> morphis, yeah, would also be nonsense given you need the binary in an android build first to even test it
[14:15] <krijn_> Hi, I have a question: I don't seem to be able to use the devel-proposed channel: it puts the phone in some eternal bootloop. I can however use rc-proposed with no problem (it just updated neatly to 382 on a Nexus 4)
[14:16] <krijn_> rc-proposed is working very well with Slimport, but I don't seem to be able to use desktop applications in that version, is that correct?
[14:20] <ogra_> devel-öproposed is just a dumpster for code, it is untested and not intended for use ...
[14:21] <mterry> zsombi, hello!  I was looking into adding a test for the grabGesture branch, but was trying to debug a problem and couldn't figure how to see console output during a test.  Is there an environment flag or something for that?
[14:21] <ogra_> rc-proposed has always the latest development (in a tested state)
[14:22] <zsombi> mterry: qDebug() does the console outputs... what do you want exactly?
[14:23] <mterry> zsombi, hrm.  I wasn't seeing them during a make check (or running the test executable directly).  I didn't see qWarning or print() calls either
[14:23] <mterry> printf rather
[14:24] <zsombi> mterry: ok, still no clue what you exactly need :) qDebug() works for any of us w/o touching any env vars
[14:27] <mterry> zsombi, I have a test I'm adding to ubuntu-ui-toolkit for my branch, it didn't work on first go, so I wanted to print the state as various things changed.  I don't see any of the existing qDebug statements print out on the console.  Nor do I see any statements I add (qDebug or not)
[14:28] <zsombi> mterry: weird... as said, we ain't used to do anything that woudl suppress these loggers...
[14:28] <zsombi> do you quild with qmake -r && make?
[14:29] <mterry> zsombi, debuild and then make for incremental changes
[14:29] <mterry> zsombi, which does qmake -r, yes
[14:29] <zsombi> mterry: bahh... no idea ... still, shouldn't be anything to suppress those
[14:31] <mterry> zsombi, OK, I just re-ran the tests and now I'm seeing some output...  So maybe my Friday experiment failures were due to me being tired  :)
[14:31] <zsombi> mterry: dohhh... :D
[14:32] <mterry> zsombi, although I only see my printfs, not the QLogging SA_TRACE calls in ucswipearea.cpp
[14:32] <zsombi> mterry: aaaah... good morning :D
[14:33] <zsombi> mterry: you were not specific on that :D
[14:33] <zsombi> mterry: here we go then
[14:33] <mterry> (those macros just call qCDebug...)
[14:33] <mterry> as warning categories..
[14:33] <zsombi> mterry: check the /tests/Gallery/gallery-logs.config
[14:34] <zsombi> gallery-logging.config
[14:34] <mterry> zsombi, ah...
[14:34] <zsombi> mterry: so
[14:34] <zsombi> mterry: you shoudl set the QT_LOGGING_CONF env var to point to that file, then turn those you are interested in to true in that file
[14:35] <mterry> zsombi, yup, that got it.  Thanks
[15:00] <krijn_> thanks ogra_ I wasn't aware. Well, then I better wait until I have a working bt-keyboard to search for programs like Gimp to work from my phone I suppose ;)
[15:11] <dobey> krijn_: the nexus4 images don't have the container for installing legacy apps, no
[15:11] <dobey> krijn_: a bluetooth keyboard won't bring it to you either
[15:20] <krijn_> hmm. That's unfortunate. The container is only available for newer devices?
[15:20] <krijn_> and the bt-keyboard was not entirely connected to the legacy apps dobey ;)
[15:23] <dobey> krijn_: i think the container bits will be available in the app store, but only installed by default on certain devices
[15:26] <krijn_> ah, ic. I discoverd a way to install programs like firefox etc. (see enabling read/write mode) https://developer.ubuntu.com/en/start/ubuntu-for-devices/installing-ubuntu-for-devices/
[15:27] <dobey> you don't want to do that
[15:27] <krijn_> but i could not disable the read/write mode anymore
[15:27] <krijn_> no, i noticed
[15:27] <krijn_> took some deleting cache/etc. wipe everything before I could do things again
[15:28] <dobey> yeah, you probably filled up /
[15:29] <krijn_> anyway, thanks for the answers, now some 'normal' work, before fiddling around with the old nexus 4 again
[15:38] <peat-psuwit> How to debug call over Bluetooth headset?
[15:54] <davmor2> peat-psuwit: for what reason?
[15:56] <peat-psuwit> davmor2: I'm trying to make a call over my bluetooth headset, but voice doesn't go through the headset (it uses phone's speaker). My device is LG L90 Dual (my port)
[15:57] <mterry> zsombi, ok got tests working, thanks for the help.  Updated branch
[15:57] <davmor2> peat-psuwit: there's a known issue across the board for that so might be related to that
[15:59] <davmor2> peat-psuwit: https://wiki.ubuntu.com/DebuggingBluetooth
[15:59] <davmor2> peat-psuwit: there is a potential fix in silo47
[16:08] <peat-psuwit> davmor2: Thank you. Let me try that.
[17:18] <adfad666> another one! http://imgur.com/Y17tsLY
[17:32] <popey> adfad666: oooh!
[17:33] <sil2100> mariogrip: hey! I will be requesting the removal of linux-manta from our ubuntu archives soonish, not sure how you build the device tarball bits for manta in your system-image server, but if you use packages from this source it's best if you cache it somewhere
[17:38] <popey> adfad666: where'd you find that? or is that your port?
[17:41] <adfad666> popey: my port, pretty much the same as how it's done on Z1
[17:44] <popey> adfad666: nice!
[17:45] <popey> adfad666: is there a page somewhere with the status of the port?
[17:45] <popey> I see a wifi icon which is a good start :)
[17:47] <adfad666> not much else works, most apps don't open, i can't even find how to enable adb
[17:49] <popey> mariogrip may be able to help :)
[17:53] <mariogrip> sil2100: Ok, I got that. It now fetches it from our own servers
[17:54] <mariogrip> adfad666: best way is to start adb at boot
[17:54] <mariogrip> download all there 3 files, and run the adb-install from recovery http://people.ubuntu.com/~mariogrip/Ubuntu-touch/fp2/
[17:58] <mariogrip> adfad666: Just ping me you need help with your port, I'll gladly help :)
[18:23] <adfad666> mariogrip: that didn't help me activate adb unfortunately :(
[18:25] <mariogrip> adfad666: oh, did you use the rootstock installetr?
[18:26] <mariogrip> if yes, you need to replace /data/ubuntu.img with /data/system.img in the adb-install script. sorry i forgot about that
[18:26] <adfad666> I've been building like this: https://wiki.ubuntu.com/Touch/Devices/minato, I adjusted the .conf and install script accordingly
[18:27] <adfad666> it shows up in lsusb fine, but no way to access it
[18:28] <mariogrip> have you tried adb kill-server
[18:29] <adfad666> no change
[18:29] <mariogrip> i would try with replace it with system.img
[18:29] <mariogrip> since that script is made for images from system-server
[18:30] <adfad666> I pushed to the correct place (I did it manually to be sure)
[18:33] <mariogrip> adfad666: I would give it a try
[18:33] <mariogrip> or you can check from recovery if you have ubuntu.img or system.img
[18:36] <adfad666> it's all good
[18:36] <adfad666> http://paste.ubuntu.com/15322611/
[18:36] <mariogrip> adfad666: ok, and adb is still not working?
[18:37] <adfad666> nope
[18:37] <adfad666> but the adbd script must be doing something if I get the corect values in lsusb
[18:38] <mariogrip> maybe we should check the syslogs from recovery (/data/system-data/var/log/syslog)
[18:40] <adfad666> hm, maybe not, it seems the lsusb values come from Android's init.device.usb.rc
[18:41] <mariogrip> oh, maybe try to remove that
[18:42] <mariogrip> *usb.rc have caused problems for me, so I removes it and handles that on ubuntu side
[18:51] <adfad666> ok
[18:58] <dobey> mardy: yikes; that is a huge diff
[19:04] <sil2100> mariogrip: thanks!
[19:07] <ogra_> mariogrip, adfad666, note that some adb implementations need the functionfs mounted ... you also need to make sure that the android container doesnt mess with the settings while you try to get it to run on the ubuntu side, some init.rc scripts doe that
[19:07] <ogra_> *do
[19:09] <dobey> mardy, dbarth__: i expect you want this to land for ota11 perhaps? not ota10, right?
[19:12] <adfad666> can I boot ubuntu.img straight from the /system partition? it seems an awful waste to put the image on /data and boot it from there, it takes about 50% of my /data partition on some devices
[20:21] <Maxr1998> Tassadar: how do I get a built Ubuntu system.img and the preinstalled.tar.gz to a device with multirom without your application or my own image server?
[20:22] <Maxr1998> from what I understand, Ubuntu has an android system image, which then mount the ubuntu system from /data/system.img
[20:22] <Maxr1998> *mounts


[06:00] <mborzecki> morning
[06:44] <mwhudson> (answer: snapd in the core snap is newer than snapd in bioinic today)
[07:08] <zyga-ubuntu> good morning
[07:09] <zyga-ubuntu> mwhudson: can you give me the denial please
[07:09] <zyga-ubuntu> mwhudson: grep for DENIED in dmesg
[07:09] <mborzecki> zyga-ubuntu: mornings
[07:09] <mwhudson> zyga-ubuntu: i think it's the more or less known thing about apparmor and overlayfs not being friends
[07:10] <zyga-ubuntu> mwhudson: ah, so it's still the version witohut overrlay support?
[07:10] <zyga-ubuntu> mwhudson: can you pastebin /var/lib/snapd/system-key
[07:10] <mwhudson> zyga-ubuntu: i'm going to wait for 2.32 until i get bothersome about it
[07:10] <mwhudson> zyga-ubuntu: don't have a vm up know
[07:10] <zyga-ubuntu> that's ok
[07:10] <zyga-ubuntu> I thought that patch was out already
[07:11] <mwhudson> zyga-ubuntu: i think xenial is on 2.23.1 or something
[07:12] <mwhudson> hm that's what xenial-proposed has anyway
[07:12] <mwhudson> so does the stable core snap have snapd from xenial-proposed in it?
[07:12] <mwhudson> that seems surprising
[07:12]  * zyga-ubuntu doesn't know
[07:12] <zyga-ubuntu> I was a little detached yesterday
[07:30] <mup> PR snapd#4844 opened: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
[07:36] <pstolowski> mornings
[07:37] <mborzecki> pstolowski: hey
[07:38] <mborzecki> pstolowski: can you take a look at #4826?
[07:38] <mup> PR #4826: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4826>
[07:53] <pstolowski> mborzecki: yep
[07:59] <kalikiana> moin moin
[08:15] <mborzecki> pstolowski: thanks for the review
[08:16] <pstolowski> np
[08:18] <mup> PR snapd#4826 closed: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4826>
[08:37] <mup> PR snapd#4845 opened: snap, store: store version numbers in the commands database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4845>
[08:38] <mvo> mborzecki: could you please create a 2.32 version of 4826 (if there isn't one already)?
[08:39] <mborzecki> mvo: coming up
[08:39] <mvo> ta
[08:49] <mup> PR snapd#4846 opened: [2.32] wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4846>
[08:50] <mborzecki> mvo: ^^
[08:53] <mvo> mborzecki: ta
[08:53] <Chipaca> *yawn*
[08:53] <Chipaca> just five more minutes
[08:58] <pedronis> hello
[08:59] <Chipaca> pedronis: hi
[08:59] <pedronis> Chipaca: hi,  I need to update a PR after let me know when you want to chat about puritan
[09:00] <Chipaca> pedronis: knee-deep in the hash cache mash atm
[09:00] <pedronis> Chipaca: I saw you discussing that,    did you notice that some of those helpers are used when there's no state
[09:01] <pedronis> StateCache need to be optional
[09:01] <Chipaca> pedronis: yes I did
[09:01] <pedronis> I mean snapasserts exist to hold stuff at the intersection of  snap files and assertions (but not needing state)
[09:02] <pedronis> or at least not requiring state
[09:02]  * Chipaca nods
[09:04] <pedronis> Chipaca: are you looking  also into the download case? I though the idea was to fix firstboot first
[09:04] <pedronis> store has its own ways to keep state at distance
[09:04] <Chipaca> pedronis: firstboot first, but with my eye on download to make the followup easy (or trivial)
[09:05] <pedronis> easier sounds fair, trivial unlikely
[09:05] <Chipaca> it's all a bit messy though
[09:05] <Chipaca> pedronis: did you see the thing about the extra extra hashing during download delta?
[09:05] <pedronis> yes, I was aware of that
[09:05] <pedronis> we also check the hash of the delta itself
[09:06] <Chipaca> i guess i'd forgotten :-)
[09:06] <Chipaca> that's fine
[09:06] <pedronis> seems a bit orthogonal
[09:06] <pedronis> except that we should have picked a different hash for those
[09:06] <Chipaca> anyhoo, that's  what i'm in
[09:06] <pedronis> no sense being super expensive
[09:06] <pedronis> given that we need to recheck the whole thing anyhow
[09:06] <pedronis> but it's as it is
[09:07] <Chipaca> pedronis: we can fix that though :-)
[09:07] <pedronis> yes, it's fixable
[09:07] <Chipaca> not today
[09:07] <Chipaca> also, store is a mess, and daemon is a mess
[09:07] <Chipaca> ¯\_(ツ)_/¯
[09:07] <pedronis> store was worse
[09:07] <Chipaca> oh, totally
[09:07] <Chipaca> baby steps
[09:07] <pedronis> it's improving (slowly)
[09:08] <pedronis> daemon, no, I don't think we rearchitected much of it yet
[09:08] <pedronis> let me know if I can help, also happy to review
[09:09]  * pedronis back to his high prio stuff
[09:09] <mup> PR snapd#4847 opened: osutil: add symlinkat(2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4847>
[09:20] <pedronis> grumble, the PR that had a consistently failing spread test now passed once I added a some debug stanza :/ I'm quite sure there is something fragile after the change but who knows now
[09:23] <Chipaca> pedronis: i'm feeling rather dumb here, but I can't figure out where the second hashing in firstboot is happening
[09:24] <Chipaca> pedronis: derive side info does one, but the second one...?
[09:24] <mborzecki> it'd be so nice if i didn't have to fire up a vm with fedora/suse just to check what `rpm -E %configure` expands to
[09:24] <pedronis> Chipaca: verify-snap
[09:24] <Chipaca> pedronis: that's not run for firstboot
[09:24] <pedronis> ?
[09:24] <Chipaca> pedronis: firstboot does InstallPath
[09:24] <Chipaca> pedronis: which means the snap is local, so gets no validate-snap task
[09:25] <pedronis> really
[09:25] <pedronis> I'm confused
[09:25] <Chipaca> that's how i read it, but see: dumb
[09:25] <pedronis> I thought we always did that
[09:25] <pedronis> if we don't there is nothing to fix
[09:25] <pedronis> but might be problematic for other reasons
[09:25]  * Chipaca takes the rest of the day off
[09:25] <Chipaca> :-)
[09:26] <pedronis> that's a recent chnage
[09:27] <Chipaca> pedronis: 2016
[09:27] <pedronis> nothing to do afaict
[09:28] <pedronis> now I'll discover it's by me
[09:28] <mup> PR snapd#4846 closed: [2.32] wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4846>
[09:29] <Chipaca> pedronis: you'd only discover that if you went looking
[09:30] <Chipaca> pedronis: I say don't
[09:30] <pedronis> it's by me
[09:30] <pedronis> so we never did double hashing
[09:30] <Chipaca> so the symlink fix should make all the difference we can make
[09:31] <pedronis> I mean at firstboot
[09:31]  * Chipaca too
[09:32] <pedronis> mmh
[09:32] <pedronis> yes, avoiding the copy is as good as it gets
[09:33] <pedronis> unless we go back to the cheating script
[09:33] <pedronis> same also for core btw
[09:33] <Chipaca> pedronis: well, core links
[09:33] <Chipaca> pedronis: the symlink only happens if the link fails
[09:33] <pedronis> yea, there's not win to be had on core
[09:33] <Chipaca> ah. yeah.
[09:34] <Chipaca> but
[09:34] <Chipaca> i do feel that if we had a central place to do hashing this would've not taken so long to figure out
[09:34] <Chipaca> but, not work for today
[09:35] <pedronis> not sure how we can achieve that
[09:35] <pedronis> unless you mean one codeline, not conceptually
[09:35] <Chipaca> magic ヽ(｀Д´)⊃━☆ﾟ. * ･ ｡ﾟ,
[09:36] <Chipaca> wishful thinking mostly
[09:36] <pedronis> we would need unify DeriveSideInfo and doValidateSnap, seems worthwhile but not sure how to attack that
[09:37] <pedronis> it's probably possible, bit of a code pretzel though
[09:37]  * Chipaca nods
[09:37] <Chipaca> meanwhile I'll do the cheap thing and skip the extra hash in download after successful applyDelta
[09:37] <Chipaca> then that'll stop bugging me
[09:39] <Chipaca> pedronis: can we talk about puritan in ~2h
[09:40] <pedronis> yes
[09:46] <zyga-ubuntu> mborzecki: can you please look at 4847 again
[09:46] <zyga-ubuntu> I added one more syscall
[09:56] <mvo> mborzecki: go vet is fully happy now again on 1.10, right?
[09:57] <mborzecki> mvo: yes, it's passing
[09:57] <mborzecki> mvo: cachio's bionic PR failed in InstallDate() unit test, probably outdated mksquashfs with the bug that you fixed
[10:00] <ackk> sergiusens, mvo I see that https://github.com/snapcore/snapcraft/commit/10509d590658f1c417b91d66a356700483997d75 has landed now, is there any plan to rename base-18 to core18 soon?
[10:08] <mvo> mborzecki: yeah, the issue here is that squashfs has not transitioned to bionic yet iirc the autopkgtest for lxd failed
[10:08] <mvo> ackk: yes, we want to rename it soon, right now a snapcraft issue prevents us from building, this will get fixed this week, then we will do the rename (once we can build again)
[10:09] <ackk> mvo, ah, cool, thanks
[10:10] <pedronis> pstolowski: hi, I think I still owe you a bunch of reviews, I will try to have a reviews day tomorrow
[10:12] <pstolowski> pedronis: hi! no worries, and thanks in advance! I think you can focus on #4358 for now and ignore the rest
[10:12] <mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
[10:12] <pstolowski> as they are stacked on top of 4358
[10:15] <mup> PR snapd#4848 opened: many: cherry-pick relevent `go vet` 1.10 fixes to 2.32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4848>
[10:18] <Chipaca> mvo: you'll also want to cherry pick 19a1dc929b89bf8dd5d6ad22bb36942b5a2508c4
[10:19] <mup> PR snapcraft#1994 closed: docker: add the architecture <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1994>
[10:19] <Chipaca> mvo: for bubonic i mean
[10:19] <Chipaca> bah, for bubonic to pass
[10:19] <Chipaca> bionic*
[10:20] <mvo> Chipaca: thank you
[10:20] <Chipaca> there's a go 1.10's behaviour change that breaks our tests (explained in that commit)
[10:20] <mborzecki> Chipaca: bubonic ;)
[10:21] <mvo> Chipaca: its not in master yet, is it?
[10:21] <Chipaca> mvo: no
[10:21] <mborzecki> hope it's not about the plague
[10:21] <mvo> Chipaca, mborzecki lol
[10:21] <Chipaca> mvo: it's pushed to #4835
[10:21] <mup> PR #4835: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
[10:22] <Chipaca> but that fails to be green because the google archive mirror doesn't have the new bionic squashfstools
[10:22] <mvo> Chipaca: we need to enable bionic-proposed there
[10:22] <mvo> Chipaca: but I can cherry-pick into my 2.32 pr
[10:22]  * Chipaca nods
[10:22] <Chipaca> this is why i mention it :-)
[10:22] <mvo> ta
[10:24] <mborzecki> Chipaca: can you take a look at #4841?
[10:24] <mup> PR #4841: snap/pack, cmd/snap: add `snap pack --check-skeleton` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4841>
[10:25] <mvo> hey stgraber ! the autopkgtests for squashfs-tools fail in the lxd testing right now (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#squashfs-tools), is there a know issue with autopkgtest and lxd? the failures do not look related to the squashfs change
[10:25] <Chipaca> mborzecki: I can do 4831, and 4861, but not 4841 sorry
[10:26]  * Chipaca lies
[10:27] <mborzecki> at least 4861 gives the nice tatooine-ish 404 :P
[10:28] <mup> PR snapcraft#1996 closed: tests: add SNAPCRAFT_KEEP_DATA to debug <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1996>
[10:28] <cachio> mvo, the problem of enabling bionic-proposed is that I need to doit suring the prepare, is it ok?
[10:29] <pedronis> #4829 and #4849 also needs reviews
[10:29] <mup> PR #4829: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store <Created by pedronis> <https://github.com/snapcore/snapd/pull/4829>
[10:29] <mup> PR #4849: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/4849>
[10:29] <mup> PR snapd#4849 opened: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/4849>
[10:30] <cachio> mvo, it will be temporal until is it enabled by default
[10:32] <mvo> cachio: yeah, I think thats ok
[10:34] <Chipaca> mvo: how would you feel about sliding 4834 into .32?
[10:34] <Chipaca> #4834
[10:34] <mup> PR #4834: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <https://github.com/snapcore/snapd/pull/4834>
[10:35] <mup> PR snapd#4834 closed: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4834>
[10:36] <mvo> Chipaca: let me look
[10:36] <ondra> zyga-ubuntu ping
[10:36] <mvo> Chipaca: absolutely
[10:36] <Chipaca> mvo: cd7a41b921446bff4ad02ceacf1811c1a6319cc7 fwiw
[10:36] <mvo> Chipaca: I cherry-pick
[10:37] <zyga-ubuntu> Hey ondra
[10:37] <ondra> zyga-ubuntu hey, I have asked this before, but when using layouts, what was the process to read original file?
[10:38] <mvo> Chipaca: ta
[10:41] <zyga-ubuntu> ondra: you can attempt to use hostfs
[10:43] <ondra> zyga-ubuntu any how to do that?
[10:48] <pedronis> Chipaca: having early lunch, we can chat in ~40 ?
[10:49] <Chipaca> pedronis: sure
[10:50] <zyga-ubuntu> ondra: re, sorry, I was afk
[10:50] <zyga-ubuntu> ondra: so, you can look at the file in /var/lib/snapd/hostfs/$F
[10:50] <zyga-ubuntu> ondra: but you will need an interface for t hat
[10:50] <mup> PR snapd#4850 opened: many: fix shellcheck warnings in bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4850>
[10:51] <ondra> zyga-ubuntu which interface is that?
[10:51] <zyga-ubuntu> none exists now
[10:51] <Chipaca> mvo: the spellcheck check is also broken in xenial, fwiw, we just don't run it
[10:51] <zyga-ubuntu> it would depend on $F for sure
[10:51] <ondra> zyga-ubuntu :)
[10:51] <zyga-ubuntu> as otherwise it would let  you read any file
[10:51] <ondra> zyga-ubuntu right
[10:52] <mvo> Chipaca: spellcheck or shellcheck? I don't mind so much about the spellcheck, we might as well disable it and only run it via a nightly job
[10:52] <Chipaca> shellcheck
[10:52] <Chipaca> ah
[10:52] <Chipaca> sorry
[10:52] <Chipaca> :-)
[10:52] <mvo> oh, ok
[10:52] <zyga-ubuntu> sheepcheck
[10:52]  * Chipaca shellchecks his spellchecker
[10:52] <mvo> shellshock
[10:52] <ondra> zyga-ubuntu wouldn't be easier to allow hook to run before bind mount, and then we can rely on existing permissions?
[10:52] <Chipaca> ah wait, yes, shellcheck, we're talking of the same thing
[10:52] <zyga-ubuntu> ondra: no, it's not easy in any way
[10:53] <ondra> zyga-ubuntu right
[10:53] <zyga-ubuntu> ondra: and it would still need an interface
[10:53] <Chipaca> mvo: shellcheck does not run as part of tests; it's not installed on the images
[10:53] <zyga-ubuntu> ondra: as this way you could read abritrary files
[10:53] <zyga-ubuntu> ondra: our current design assumes that applications cannot observe pre-layout filesystem at any stage
[10:53] <zyga-ubuntu> so no partial state is expsed
[10:53] <ondra> zyga-ubuntu ok, so hostfs it is then
[10:53] <zyga-ubuntu> as our apparmor profile assumes the layout is in place
[10:53] <zyga-ubuntu> and grants permissions to the places affected by the layout
[10:53] <ondra> zyga-ubuntu ah, OK that makes sense
[10:54] <mborzecki> zyga-ubuntu: regarding #4571 we could move configure.ac/autogen.sh to the top of snapd tree
[10:54] <mup> PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
[10:54] <zyga-ubuntu> ondra: my advice is to open a thread to request an interface for reading hostfs file (specific file) so that we can grant this
[10:54] <zyga-ubuntu> mvo: what do you think about mborzecki's proposal?
[10:54] <zyga-ubuntu> I'm okay but we had a discussion with that and this is how we ended up with "autotools is hidden in cmd/"
[10:55] <ondra> zyga-ubuntu OK will do
[11:00] <cachio> zyga-ubuntu, that should be fixed? https://travis-ci.org/snapcore/snapd/builds/353519499#L5247
[11:00] <cachio> zyga-ubuntu, or it is still in progress
[11:00] <zyga-ubuntu> cachio: no, not yet. I'm working on that now
[11:01] <cachio> zyga-ubuntu, ah, ok, thanks
[11:04] <mvo> zyga-ubuntu: I think to think but to me autotools is just something I dislike whereever it lifes
[11:04] <mvo> zyga-ubuntu: I mean "I need to think"
[11:04] <zyga-ubuntu> mvo: any ideas as to what to do then?
[11:04] <zyga-ubuntu> should we move away from autotools
[11:04] <zyga-ubuntu> or just use it consistently
[11:06] <mvo> zyga-ubuntu: sorry, I know my comment was not helpful. but yeah, either consistently or switch but switching must be worth it, mesons seems to be popular but I'm not sure its sufficiently better
[11:07] <mvo> (to justify the cost)
[11:08] <mborzecki> mvo: xenial version of meson is outdated, and afaik it's not available in trusty at all
[11:11] <ondra> zyga-ubuntu mvo any idea what could be causing "run hook "post-refresh": execv failed: No such file or directory"
[11:11] <zyga-ubuntu> hmmm,
[11:12] <zyga-ubuntu> ondra: what does the hook look like?
[11:12] <ondra> zyga-ubuntu https://pastebin.ubuntu.com/p/w22S3q9Y2D/
[11:12] <ondra> zyga-ubuntu :)
[11:13] <ondra> zyga-ubuntu I trimmed it down, as I can't figure out what is the problem
[11:13] <zyga-ubuntu> so you refresh a snap and the hook fails to run?
[11:13] <zyga-ubuntu> is it reproducible?
[11:14] <ondra> zyga-ubuntu I have install hook which runs just fine I did sym link as I usually do and it failed to run
[11:14] <ondra> zyga-ubuntu install works
[11:14] <zyga-ubuntu> symlink?
[11:14] <ondra> zyga-ubuntu happening all the time
[11:14] <ondra> zyga-ubuntu that was before
[11:14] <zyga-ubuntu> pstolowski: ^ wanna look?
[11:14] <ondra> zyga-ubuntu so I replaced sym link with file, and still same
[11:16] <pstolowski> ondra: can you share that snap?
[11:16] <ondra> pstolowski yeah preparing to share it
[11:22] <ondra> pstolowski zyga-ubuntu damn, I did clean build and now it works, and I did same before
[11:22] <zyga-ubuntu> do you have the old snap?
[11:22] <ondra> so can't reproduce it now
[11:22] <zyga-ubuntu> maybe look inside
[11:23] <ondra> zyga-ubuntu so I was using snap try
[11:23] <ondra> zyga-ubuntu and without rebuild I was modifying prime/meta/hook
[11:25] <mup> PR snapd#4848 closed: many: cherry-pick relevent `go vet` 1.10 fixes to 2.32 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4848>
[11:30] <pedronis> Chipaca: I'm back
[11:31] <Chipaca> pedronis: wb :)
[11:31] <Chipaca> pedronis: so, if I understand your point of view, using puritan for everything stringish isn't a sustainable practice
[11:31] <ondra> zyga-ubuntu pstolowski http://people.canonical.com/~okubik/git_2.7.4_amd64.snap
[11:32] <ondra> zyga-ubuntu so I'm using snap try, so unsquash it first
[11:32] <pedronis> Chipaca: indeed
[11:32] <pstolowski> ondra: could this be a missing -x on the hook script?
[11:32] <ondra> zyga-ubuntu pstolowski so now I have different problem, it will install, but if I try to run I get execv failed: No such file or directory
[11:32] <Chipaca> pedronis: OTOH my point of view is that unless we do something for every stringish thinig, we're going to eventually miss one we shouldn't
[11:33] <ondra> zyga-ubuntu pstolowski do $ snap try <>; it will run, call $ snap try <> on same directory and it will break
[11:33] <Chipaca> pedronis: would you be happier with using a lot more types, for example?
[11:33] <pedronis> Chipaca: no in general
[11:34] <pedronis> Chipaca: we need  tooling and a way to mark things
[11:34] <pedronis> Chipaca: I find needing a special type for snap-id very suspect
[11:34] <pedronis> it feels very cargo cultish
[11:34] <Chipaca> pedronis: when you say tooling, do you mean a static checker, or do you mean a json decoder replacement?
[11:34] <pedronis> whatever works
[11:34] <pstolowski> ondra: what core are you running with?
[11:35] <pedronis> Chipaca: atm we are just making a bit of code uglier without clear path forward
[11:35] <ondra> pstolowski 16-2.31.2+git610.7a79b84 (4243)
[11:36] <Chipaca> pedronis: what would you do?
[11:36] <pedronis> Chipaca: also whatevedr is problematic with the store is likely problematic with snap.yaml
[11:36] <pedronis> as well
[11:36] <pedronis> Chipaca: I don't know, I'm not even sure I agree with your premise
[11:36] <pedronis> that we really need to worry about everything
[11:37] <pedronis> but if we do need to worry about everything the current approach alone doesn't cut it
[11:38] <Chipaca> pedronis: because of the lack of a static checker?
[11:38] <pstolowski> ondra: ok, same core here. I un-suqashed it, did snap try twice, it worked. can you do 'snap changes' to find changes correspondin to your snap-try commands, and then 'snap change <ID of the change>' for both to see more info about the failure?
[11:38] <pedronis> Chipaca: it seems we need to mark all structs with json or yaml tags as either risky or not and then decide what to do with each
[11:39] <mborzecki> zyga-ubuntu: mvo: tried having just cmd/configure.ac and doing AC_CONFIG_FILES([../data/Makefile ..]) but that doesn't work, the resulting makefiles do some silly thing and try to cd one level above snapd checkout
[11:39] <pedronis> though sometimes we use map[string]interface{} directly, maybe not on input
[11:39] <pedronis> not sure
[11:40] <zyga-ubuntu> mborzecki: thank you for confirming that
[11:41] <mborzecki> zyga-ubuntu: mvo: just moving configure.ac and autogen.sh to the top level dir (plus adjusting paths) is enough, it will clutter the directory once you autoreconf but at least both cmd and data are built using autohell
[11:41] <zyga-ubuntu> mborzecki: yeah,
[11:41] <zyga-ubuntu> you have my +1 but convince gustavo as he was opposing it before
[11:42] <Chipaca> pedronis: that's a mountain of work, but it does seem the logical conclusion
[11:42] <mborzecki> zyga-ubuntu: we could easily say with the hack that's right now in the PR :P works too, and does not clutter the directory
[11:42] <pedronis> Chipaca: well, the non logical solution is say we need to care about everything but then leaving it up to reviewers
[11:43] <mborzecki> Chipaca: could we do a silly hack with reflection and field tags perhaps?
[11:44] <ondra> pstolowski https://paste.ubuntu.com/p/7J8yPTrmBG/
[11:44]  * cachio afk
[11:45] <mborzecki> Chipaca: then have an unmarshaller that wraps json and goes to inspect all the strings to clean them up, unless there's a tag that says to leave the string as it is
[11:45] <mborzecki> pedronis: ^^
[11:45] <pedronis> there are probably a few possible approaches
[11:46] <pedronis> there are also concerns about runtime speed
[11:46] <pedronis> also personally don't think we should write a full new json decoder
[11:48] <mborzecki> agreed, i'm not propsing to write a json decoder, just sanitize the structs when they come out of the decoder somehow, in a separate call perhaps
[11:48] <ondra> pstolowski here you have whole test https://paste.ubuntu.com/p/2q7PH8cqk4/
[11:48] <ondra> pstolowski from snap remove
[11:49] <pedronis> Chipaca: now we also need to understand what everything means,  I suppose you mean that for example store generated error messages are also a concern?
[11:49] <ondra> pstolowski exactly same error I was getting before about configure hook
[11:49] <pedronis> Chipaca: I mean is our attacker a user of the store, or the store?
[11:49] <ondra> pstolowski need to run for lunch, but will be available later
[11:50] <pedronis> (there are blurry lines there but it still make a difference where to spend our energy)
[11:50] <Chipaca> pedronis: if it's the store itself i think things fall apart
[11:51] <Chipaca> pedronis: but, the problem is bugs
[11:51] <pedronis> I understand
[11:51] <pedronis> but there are all sorts of bugs
[11:51] <Chipaca> pedronis: I mean, #1750527 is the bug
[11:51] <mup> Bug #1750527: dashboard does not validate text fields <review-tools:Triaged by jdstrand> <Snapcraft:New> <snapd:In Progress by chipaca> <Snap Store:Fix Released by matiasb> <https://launchpad.net/bugs/1750527>
[11:52] <Chipaca> pedronis: even with that change, it's not clear to me everything textish from the store is validated
[11:52] <pedronis> Chipaca: I'm not arguing for doing nothing, but I'm also not happy to do something cargo cultish and unbounded
[11:53] <Chipaca> pedronis: I understand, but if the alternative to cargo culting something is having to make a decision about every single field, cargo culting starts to look good
[11:53] <pedronis> Chipaca: you are saying we should use the store data without knowing what it is / what it is about
[11:54] <Chipaca> pedronis: "is this something that can be edited by third parties, and is it going to be shown to the user" seemed to be the question
[11:54] <Chipaca> the first half we can probably answer easily
[11:55] <pedronis> Chipaca: and snap-id is dubious?
[11:55] <pedronis> anyway  at this point as I said even if we continue to use string for some things
[11:55] <pedronis> as I said we need to worry about all the json and all the yaml
[11:55] <Chipaca> I don't think snap-id is dubious, no
[11:55] <pedronis> but you made a puritan.SimpleString
[11:56] <Chipaca> but if you make everything not be a string, you can write a really silly static checker
[11:56] <Chipaca> the alternative is tagging, which isn't hard (but I hadn't thought of it in this context)
[11:56] <pedronis> I'm skeptical of that
[11:57] <pedronis> (the silly part)
[11:58] <Chipaca> pedronis: it'd be only a little more work than the check in daemon for commands
[11:58] <pedronis> ?
[11:58] <pedronis> we define local types sometimes to parse json
[11:59] <Chipaca> ok
[11:59] <Chipaca> pedronis: so what do we do
[12:00] <pedronis> it seems like we need to introduce safejson and safeyaml,   and not use json and yaml, as thin wrappers and go from there
[12:01] <pedronis> with a silly check that we don't use the other diretly in non-tests
[12:01] <Chipaca> pedronis: what are safejson and safeyaml?
[12:01] <pedronis> Chipaca: packages with a subset of what is offered by json and yaml
[12:02] <pedronis> we can probably then make them have different behavior at test time vs runtime
[12:02] <pedronis> and at test time they could check the rules that we make for target types
[12:05] <pedronis> Chipaca: it seems the only approach to make sure we cover all the ground  (I'm a bit worried about the messiness of dealing with our various uses of json statically)
[12:05] <pedronis> though yaml is probably worse, all of it comes from the user
[12:05] <pedronis> by definition
[12:06] <pedronis> if we don't trust snapcraft
[12:06] <pedronis> otoh we have validation there
[12:06] <pedronis> Chipaca: are you saying that we should do validation for snap.yaml but not trust any string from the store?
[12:07] <pedronis> it seems asymmetric, but maybe there's a good reason
[12:07] <Chipaca> pedronis: aborting a 'snap find' because one of the results had a bogus entry seemed a poor choice
[12:07] <Chipaca> pedronis: aborting a 'snap install' because of the same seems fine
[12:08] <pedronis> yea, but validation doesn't check all the fields at the moment
[12:08] <pedronis> does it?
[12:08] <Chipaca> it does not
[12:08] <pedronis> we might print a non-validated field
[12:08] <pedronis> (for reasons)
[12:08] <Chipaca> yes
[12:08] <Chipaca> but it'd be fairly straightforward to fix that
[12:08] <pedronis> Chipaca: I fear you opened a can of worms
[12:09] <Chipaca> pedronis: it was already open :-) i might've kicked it a little
[12:10] <pedronis> Chipaca: anyway  you mighe decide to go validation only for snap.yaml (but we have also other yaml files, like gadget yaml)
[12:10] <pedronis> but we still need a scalable solution for all the json from the store
[12:11] <Chipaca> pedronis: (just to keep things interesting, what should it do if the snap yaml ini the json fromo the store is invalid? :) )
[12:12] <pedronis> are we not validating it?
[12:12] <Chipaca> pedronis: the one in details? probably not
[12:12] <pedronis> anyway it's a corner case that shows cargo culting with naive types is not great
[12:12] <pedronis> false security effect
[12:13] <pedronis> anyway I think we validate it
[12:13] <pedronis> and if it's invalid we ignore it
[12:13] <pedronis> or maybe not
[12:13] <pedronis> let me check
[12:14] <pstolowski> ondra, ah wait, the execv error comes from running the app, it's not hooks
[12:15] <pedronis> Chipaca: no, it's not validated atm
[12:15] <pedronis> just parsed
[12:15] <pedronis> we ignore it on "parse" errors but not validation (that we don't do)
[12:16] <pstolowski> ondra: but ok, i can reproduce what you pasted, investigating
[12:18] <pedronis> Chipaca: so what I would do is have a way to enforce needing to tag all json fields as either  "user" or something else, all user fields need one of the special dedicated types
[12:19] <pedronis> (for values of all)
[12:21] <pedronis> Chipaca: still would need  a plan about how to make sure we validate all snap.yaml fields
[12:22] <Chipaca> pedronis: would something like puritan still be useful in this context?
[12:22] <pedronis> Chipaca: yes,   as I said we would String and Paragrah
[12:22] <pedronis> for some of the user fields
[12:22] <Chipaca> pedronis: and in particular, if I just used puritan for the known-problematic fields today would that be a reasonable zeroth step
[12:23] <pedronis> Chipaca: yes,  starting with just a few fields  would an accetable first step
[12:23] <pedronis> we probably don't need or shouldn't need SimpleString though
[12:23] <pedronis> for that step
[12:23] <pedronis> unless I'm confused
[12:23] <Chipaca> ok, I'll prune puritan back to just those, and nuke everthing but paragraph and string
[12:23] <Chipaca> (they can easily be brought back -- i'll leave the flags in the underlying code)
[12:24] <pedronis> Chipaca: I'm also not sure puritan will not offende somebody as a name
[12:24]  * Chipaca grins
[12:24] <Chipaca> it's a silly name, but I don't think there are puritans left
[12:24] <Chipaca> i might be wrong though
[12:28] <Chipaca> pedronis: i could call it 'safejson', and then also use it to house the tag checker
[12:28] <pedronis> seems reasonable (to me)
[12:28] <Chipaca> although this is a particular brand of safe (but then, safe always is)
[12:29] <Chipaca> safe-against-global-thermonuclear-war
[12:29] <Chipaca> termite-safe vs thermite-safe, etc
[12:29] <Chipaca> (also, does termite-safe mean termites can eat it, or won't eat it?)
[12:30]  * Chipaca needs lunch
[12:30] <pedronis> mvo: Chipaca: do we have a fix now with test layout and /etc?  do I just need ot merge master
[12:30] <Chipaca> pedronis: AFAIK the layout test is still a flake
[12:30] <pedronis> fun not :/
[12:31] <pstolowski> ondra: I installed your snap normally, then uninstalled, then snap try works. something is fishy here...
[12:31] <Chipaca> pstolowski: what's going on?
[12:32] <pedronis> Chipaca: contact(_url) is intersteting btw, it seems we need a type that validates urls or blanks them
[12:32] <Chipaca> ungh
[12:33] <Chipaca> pedronis: have you seen the data in contact
[12:33] <pedronis> it's random?
[12:33] <pedronis> I thought it was supposed to be a http: or mailto: url
[12:33] <mborzecki> hm there's a govalidator package that can do some of this magic
[12:34] <mborzecki> you basically set validate tags in struct fields and then call ValidateStruct()
[12:34] <mborzecki> Chipaca: pedronis: https://godoc.org/github.com/asaskevich/govalidator
[12:34] <pedronis> interesting but seems not what we want (speedwise)
[12:34] <mborzecki> we've used it in mender for some of the APIs
[12:35] <pedronis> if I understood Chipaca's worries
[12:35] <pedronis> we need more of a metavalidator than a validator
[12:35] <mborzecki> speedwise is subjective, my guess would be the i/o part of working with store will be longer than the validation :)
[12:36] <pedronis> that's not what I gathered from John at the sprint
[12:36] <pedronis> he was worried about double decoding utf8 basically
[12:36] <mborzecki> the github page has some nice examples https://github.com/asaskevich/govalidator
[12:36] <pedronis> anyway our current problem is not so much validation (we have the code), is make sure all the fields
[12:36] <pedronis> are setup properly for it
[12:37] <mborzecki> pedronis: yes, that's what i recall to, but looks like we're moving towards verifying the contents/structure of respective fields
[12:37] <Chipaca> pedronis: mborzecki: well... i wasn't worried about the double utf8 decode, per se
[12:37] <Chipaca> pedronis: mborzecki: but i needed to do most of the work anyway
[12:37] <pedronis> it might be underasting for snap.yaml
[12:38] <Chipaca> that's why it ended up doing it directly
[12:38] <pedronis> heh
[12:38] <pedronis> I meant "interesting"
[12:38] <pedronis> otoh unless is perfect not sure we want one more dep
[12:39] <pedronis> mborzecki: for  store json we have more of cleaning up problem, than a validation one
[12:39] <pedronis> if I understand
[12:39] <zyga-ubuntu> mvo: I have the first and harder half of the layouts fix
[12:39] <zyga-ubuntu> shall I push it to 4847 so that it can be squashed
[12:39] <zyga-ubuntu> or would you like to see separate commits
[12:39] <Chipaca> pedronis: mborzecki: we can also decide to drop invalid json on the floor
[12:39] <zyga-ubuntu> I haven't pushed the fix there yet, just the prerequisite helpers
[12:39] <Chipaca> pedronis: mborzecki i'd be fine with taht if we can do it at the snap level
[12:40] <Chipaca> that is, in a search result, drop individual results
[12:40] <Chipaca> but then... a typo in a description would stop a snap refresh
[12:40] <Chipaca> not sure we want that
[12:40] <Chipaca> (granted you'd really need to work hard to get a typo now the store is fixed)
[12:41] <pedronis> Chipaca: doesn't that apply to snap.yaml too though?
[12:41] <pedronis> if the description  comes from the snap.yaml then we clean from the store, but fail when we install anyway?
[12:41] <Chipaca> pedronis: indeed. and even more vocally.
[12:42]  * Chipaca turns up the 'everything is terrible' dial another notch, and goes to get some tea
[12:42] <zyga-ubuntu> Chipaca: hey, sorry for being late with that patch; could you look at 4847, this adds the symlinkat and realinkat functions
[12:42] <zyga-ubuntu> and some testing helpers
[12:42] <zyga-ubuntu> it's used in upcoming fix
[12:43] <Chipaca> zyga-ubuntu: realinkat?
[12:43] <pedronis> zyga-ubuntu: it's "cannot update snap namespace: cannot create writable mimic over "/etc": no such file or directory" fixed or are you working on that still?
[12:43] <Chipaca> but yes, after tea is brewed
[12:43]  * pedronis has lost track
[12:43] <zyga-ubuntu> I meant to say readlinkat
[12:43] <zyga-ubuntu> Thank you!
[12:44] <Chipaca> pedronis: that's the fix he's talking about
[12:44] <Chipaca> right now :-)
[12:46] <pstolowski> ondra: ah, ignore my earlier comment, second snap try breaks it
[12:47] <zyga-ubuntu> pedronis: that's what I fixed just now, it will be a PR in a moment
[12:47] <zyga-ubuntu> pedronis: just trying to coordinate that with mvo for release (one PR, many PRs, squash or not, etc)
[12:48] <mup> PR snapd#4836 closed: tests: force profile re-generation via system-key <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4836>
[12:48] <pedronis> zyga-ubuntu: that's fine, just trying to understand whether I needed to re-run the tests or merge master first
[12:49] <zyga-ubuntu> re run now
[12:51] <mup> PR snapd#4838 closed: snapstate: put layout feature behind feature flag <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4838>
[12:51] <mup> PR snapd#4851 opened: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
[12:51] <zyga-ubuntu> mvo: I've opened https://github.com/snapcore/snapd/pull/4851 to get a feel of the fix in the wild
[12:51] <mup> PR #4851: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
[12:52] <zyga-ubuntu> after standup I need to go to the doctor again but the 2nd fix for layouts is easier so I will push the PR after returning
[12:56] <pstolowski> zyga-ubuntu: can you remind me/brief me on how do I inspect namespaces of a snap?
[12:56] <mup> PR snapd#4809 closed: cmd/snap: tweak and polish help strings <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4809>
[12:56] <zyga-ubuntu> pstolowski: use nsenter
[12:56] <zyga-ubuntu> nsenter -m/run/snapd/ns/foo.mnt
[13:01] <mup> PR snapd#4852 opened: snapstate: put layout feature behind feature flag <Created by mvo5> <https://github.com/snapcore/snapd/pull/4852>
[13:02] <pstolowski> niemeyer: having network issues, will join in a few moments
[13:27] <soee_> hey are there any plans to fix the ugly looking snap apps their icons in launchers etc?
[13:28] <zyga-ubuntu> pstolowski: can you please pastebin the meta/snap.yaml
[13:28] <zyga-ubuntu> pstolowski: I have a suspicion I know what's going on
[13:28] <pstolowski> zyga-ubuntu: https://pastebin.ubuntu.com/p/8tCdGtRTcp/
[13:29] <zyga-ubuntu> pstolowski: aha, that's curious
[13:29] <zyga-ubuntu> that's not what I assumed
[13:29] <zyga-ubuntu> can you paste the URL of the snap pelase
[13:29] <zyga-ubuntu> *please
[13:29] <zyga-ubuntu> I'll pull and explore
[13:30] <pstolowski> zyga-ubuntu: http://people.canonical.com/~okubik/git_2.7.4_amd64.snap
[13:30] <pstolowski> zyga-ubuntu: unsquash and snap try twice
[13:31] <zyga-ubuntu> thanks
[13:41] <pstolowski> zyga-ubuntu: ty! let me know what's the outcome
[13:42] <zyga-ubuntu> I will only check after my doctor appointment though
[13:45] <pstolowski> sure
[13:56] <mborzecki> Chipaca: are you fixing snap info output?
[13:56] <Chipaca> mborzecki: yes
[13:57] <mborzecki> Chipaca: idk why, but even `fmt.Fprint(w, formatDescr(both.Description, termWidth))` tries to expand %
[13:57] <Chipaca> mborzecki: it's not formatDescr
[13:57] <Chipaca> mborzecki: it's strutil.WordWrap
[13:57] <Chipaca> mborzecki: which is the same one munging the indents
[13:57] <Chipaca> mborzecki: so guess who's throwing it away
[13:58] <Chipaca> <- this guy
[13:58] <Chipaca> :-)
[13:59] <mborzecki> Chipaca:
[14:00] <ondra> pstolowski hey
[14:00] <mborzecki> Chipaca: https://paste.ubuntu.com/p/qXH3Bk4Zkt/ pff poor man's fix, but if it's WordWrap breaking it then strutil is probably better place to fix it
[14:00] <ondra> pstolowski back now, I saw you can reproduce it now
[14:00] <ondra> pstolowski anything else I can assist with?
[14:02] <pstolowski> ondra: yeah, I got to the point where I can point my finger at what breaks and handed it over to zyga as it's his domain, he will look at it
[14:02] <zyga-ubuntu> I'm going to see a doc now, I'll check it out after that ondra
[14:02] <zyga-ubuntu> definitely feels like my type of problem
[14:04] <ondra> zyga-ubuntu yeah no time pressure from me, it's not blocking me personally, just found it as very interesting problem, so happy to help if there need
[14:04] <zyga-ubuntu> I know what to look at, I'll let you know when I understand the problem
[14:06] <Chipaca> mborzecki: yeah, by the time formatDescr gets it it's already happened
[14:07] <mborzecki> Chipaca: http://paste.ubuntu.com/p/F3y8NcpYQZ/
[14:07] <ondra> zyga-ubuntu thanks bunch :)
[14:07] <Chipaca> mborzecki: pretty much yes, but as I said on the list, the indent munging needs to die
[14:08] <mborzecki> Chipaca: death by 1000 tabs
[14:08] <Chipaca> :-)
[14:09] <pedronis> niemeyer: #4825 is the PR that needs a 2nd look
[14:09] <mup> PR #4825: overlord/snapstate:  implement policy of holding refreshes for 2h since seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4825>
[14:10] <zyga-ubuntu> ondra: I know what the problem is, something for me to fix in do-undo logic for mounts
[14:10] <zyga-ubuntu> thanks for bringing this to my attention, I will focus on it ASAP
[14:11] <ondra> zyga-ubuntu happy to help :)
[14:20] <mborzecki> off to pick up the kids
[14:28] <mup> PR snapd#4825 closed: overlord/snapstate:  hold refreshes for 2h after seeding on classic <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4825>
[14:47] <MincePies> Question: After installing spotify snap in Elementary OS - How Do I Start It ?
[14:53] <kyrofa> MincePies, if they don't pick up the desktop file, check in /snap/bin
[14:53] <kyrofa> There should be an executable in there you can run
[14:54] <Chipaca> MincePies: if you just installed snapd, you might need to log out before it has the paths set up right, but you should be able to do 'snap run spotify' (or /snap/bin/spotify if elementary ships it as /snap)
[14:54] <Chipaca> brb, rebooting
[15:41] <mup> PR snapd#4853 opened: overlord/snapstate: hold refreshes for 2h after seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4853>
[15:41] <pedronis> mvo: ^  I made the backport for that bit
[15:41] <jjohansen> zyga-ubuntu: I'm building test kernels, is there one you would like in particular
[15:51] <cachio> niemeyer, hey
[15:52] <cachio> remember the spread issue that I told you during the standup?
[15:52] <niemeyer> cachio: Hey, sure
[15:52] <cachio> niemeyer, well, the real problem was different
[15:52] <niemeyer> cachio: Not surprised ;)
[15:53] <cachio> debian is killing the networking before the ssh sessions
[15:53] <cachio> it is a known issue
[15:53] <niemeyer> cachio: What does that mean in more detail?
[15:55] <cachio> when we reboot
[15:56] <cachio> systemd is stopping the network services
[15:56] <cachio> in this debian
[15:56] <cachio> it is stopping first the network connection and then the ssh sessions
[15:57] <niemeyer> How's that an issue?
[15:58] <cachio> in that case spread is not getting that the session is closed
[15:58] <cachio> so then when it tries to connect to detect the machine is rebooted
[15:58] <cachio> it is to late
[15:58] <cachio> the machine is up again
[15:59] <cachio> bebian is taking between 7 and 8 seconds to start
[15:59] <cachio> ubuntu is taking + than 12
[15:59] <niemeyer> Ah, I see.. the connection is silently dropped
[15:59] <cachio> yes
[16:00] <niemeyer> Okay, that makes more sense
[16:00] <cachio> I created a service to force to stop the ssh sessions before the network
[16:00] <cachio> when we reboot
[16:00] <cachio> and the problem is gone
[16:00] <niemeyer> I'd prefer to workaround it in a way that makes spread more resilient
[16:00] <niemeyer> Hmm
[16:01] <cachio> otherwise I could add a keepalive in spread when we reboot
[16:01] <cachio> to detect if the ssh session is gone
[16:01] <niemeyer> cachio: Won't work.. too short a time
[16:02] <niemeyer> cachio: I suggest the following: let's drop all the waits, and make spread look at the actual uptime
[16:02] <cachio> niemeyer, ok
[16:02] <niemeyer> cachio: Instead of waiting for the disconnection, it disconnects by itself automatically when asking for the reboot
[16:02] <niemeyer> cachio: And then immediately tries to reconnect and check the uptime
[16:03] <niemeyer> cachio: Repeat until timeout
[16:03] <cachio> niemeyer, ok, makes sense
[16:03] <cachio> I'll try that
[16:03] <niemeyer> cachio: WE need to make this logic resilient as we'll often see errors mid-routine
[16:04] <cachio> which errors?
[16:04] <cachio> you mean the failed attempts?
[16:05] <cachio> niemeyer,
[16:05] <cachio> I'll try that and push it
[16:05] <cachio> after lunch :)
[16:06] <cachio> niemeyer, thanks
[16:07] <niemeyer> cachio: np, thanks for figuring it out
[16:12] <niemeyer> cachio: I suggest using this to figure the latest boot time:
[16:12] <niemeyer> date -u --iso-8601=seconds -d "`cut -f1 -d. /proc/uptime` seconds ago"
[16:12] <niemeyer> cachio: There are backticks in that message, which hopefully your IRC client did not interpret
[16:13] <niemeyer> cachio: Ah, even better:
[16:13] <niemeyer>  date -u --iso-8601=seconds -d "$(cut -f1 -d' ' /proc/uptime) seconds ago"
[16:15] <niemeyer> cachio: Then, we need to tolerate a delta of up to, say, 3 seconds, since there will be a difference between the time we read the uptime from the time date makes the syscall to pick up the time
[16:15] <Chipaca> niemeyer: cachio: or, you know, 'uptime -s'
[16:15] <Chipaca> :)
[16:17] <Chipaca> i'm going to go offline for a while, will bbl
[16:17] <niemeyer> Chipaca: Does it use utmp or proc?
[16:17]  * niemeyer checks
[16:17] <niemeyer> (we want proc)
[16:17] <Chipaca> should still be able to push the fix for snap info tonight
[16:19] <niemeyer> Apparently proc, so that's nicer indeed, thanks!
[16:19] <Chipaca> niemeyer: proc; utmp for who's logged in
[16:19]  * Chipaca vanishes in a cloud of []rune
[16:20] <niemeyer> Except cut and date come from coreutils, and uptime comes from procps
[16:20] <niemeyer> Probably good enough
[16:25] <MincePies> well that worked - only just! https://paste.ubuntu.com/p/Dj5nxS7t8g/
[16:26] <MincePies> Where can I find a list of snaps to test ?
[16:37] <cachio> niemeyer, ok, so I'll use 'uptime -s'
[16:37] <niemeyer> cachio: Sounds good, thanks
[16:40] <MincePies> Where can I find a list of snaps to test ?
[16:40] <MincePies> I have a 1 teraByte SSD
[16:44] <pedronis> I'm getting again  Job for snapd.service canceled.  on 14.04
[16:45] <pedronis> did we find what was it about?
[16:45] <cachio> pedronis, do you have a log?
[16:45] <cachio> to see where is it failing
[16:46] <pedronis> cachio:  https://travis-ci.org/snapcore/snapd/builds/353848109?utm_source=github_status&utm_medium=notification  3 prepares on 14.04 are failing with that
[16:46] <cachio> pedronis, it was giving that error when we tried to stop it and it was not in running state
[16:48] <cachio> pedronis, it is failig in another place now
[16:49] <cachio> pedronis, a solution is to encapsulate the stop into a function and there check before the status and then stop the service
[16:50] <pedronis> it's failing like this on a couple of my branches
[16:50] <pedronis> that have very different changes
[16:52] <cachio> pedronis, so, perhaps it is something new
[16:52] <pedronis> master is also red
[16:52] <pedronis> trying to see which way
[16:53] <cachio> same error on master
[16:53] <cachio> something changed
[16:53] <pedronis> yes
[16:53] <cachio> pedronis, I'll take a look
[16:53] <cachio> right now
[16:54] <cachio> thanks for the headsup
[17:01] <mup> PR snapd#4854 opened: devicestate: introduce DeviceManager.Registered returning a channel closed when the device is known to be registered <Created by pedronis> <https://github.com/snapcore/snapd/pull/4854>
[17:01] <zyga-ubuntu> re
[17:01]  * zyga-ubuntu needs more examinations
[17:08] <zyga-ubuntu> aww, pushed go fmt fixes
[17:16] <MincePies> question, Where can I find a list of snaps for testing, please ?
[17:26] <mcphail> https://snapcraft.io/store ?
[17:27] <mcphail> https://uappexplorer.com/snaps
[17:29] <MincePies> mcphail: how do I get this to go? https://uappexplorer.com/snap/ubuntu/software-boutique
[17:31] <mcphail> MincePies: I've never used that snap. I think it is fairly specific for Ubuntu Mate. flexiondotorg may be able to clarify for you
[17:32] <MincePies> Who is he ?
[17:32] <zyga-ubuntu> MincePies: he's affiliated with Ubuntu Mate
[17:32] <mcphail> He's the creator of that snap
[17:32] <MincePies> Lets see if he shows-up, then (?)
[17:33] <mcphail> Generally, if you have a snap installed, "snap info name_of_snap" will tell you which commands can be run
[17:36] <MincePies> Brilliant & Its my first snap install! https://imgur.com/CHByC6U
[17:39] <ogra_>  oh zyga-ubuntu ....
[17:39] <ogra_> zyga-ubuntu, will you take pictures of the crowd with pitchforks in fromt of your house ?
[17:39] <ogra_> "Because flatpak is not the future ..."
[17:40] <zyga-ubuntu> ogra_: in poland? they will be lost at the train station
[17:40] <ogra_> lol
[17:40] <zyga-ubuntu> "track 6 at platform 4 in sector 8"
[17:40] <zyga-ubuntu> all said in gibberish polish with poor speakers
[17:40] <zyga-ubuntu> and once they come here they will become infected
[17:41] <zyga-ubuntu> and then half of them will oppose the other half
[17:41] <zyga-ubuntu> and they will discuss a substitute topic instead
[17:41] <zyga-ubuntu> wanna do a code review?
[18:09] <MincePies> zyga-ubuntu: > wanna do a code review? Answer: Yeah.
[18:09] <zyga-ubuntu> MincePies: hey
[18:10] <zyga-ubuntu> I have two related PRs
[18:10] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4847
[18:10] <mup> PR #4847: osutil,testutil: add symlinkat(2) and readlinkat(2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4847>
[18:10] <zyga-ubuntu> and https://github.com/snapcore/snapd/pull/4851
[18:10] <mup> PR #4851: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
[18:11] <zyga-ubuntu> I will happily take feedback
[18:12] <MincePies> zyga-ubuntu: I don't Like this: https://paste.ubuntu.com/p/H944SV4kc3/
[18:12] <zyga-ubuntu> can you be more specific?
[18:13] <MincePies> Will it work on debian ?
[18:13] <zyga-ubuntu> yes, why would you worry about that?
[18:13] <zyga-ubuntu> this is an unit test for a testing helper
[18:13] <zyga-ubuntu> it will work on any system
[18:14] <MincePies> zyga-ubuntu:  > it will work on any system | That's abit 'headed' there.
[18:14] <zyga-ubuntu> ?
[18:14] <MincePies> Have you tried Rosa ?
[18:14] <zyga-ubuntu> it will work on windows and macos and plan9
[18:15] <zyga-ubuntu> because it's totally unrelated to the system
[18:15] <zyga-ubuntu> because it's a mocking helper for testing other parts of the code
[18:15] <MincePies> What is a mocking helper, then, when its at home?
[18:15] <zyga-ubuntu> sorry, I'm looking for people who can review my code
[18:16] <MincePies> he doesn't know.
[18:16] <zyga-ubuntu> internet is a funny place
[18:25] <zyga-ubuntu> jjohansen: hey, do you have a patch I could pull and try out?
[18:37] <mup> PR snapd#4839 closed: errtracker: respect the /etc/whoopsie configuration <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4839>
[18:37] <mup> PR snapd#4853 closed: overlord/snapstate: hold refreshes for 2h after seeding on classic (2.32) <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4853>
[18:39] <mup> PR snapd#4285 closed: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4285>
[19:17] <mup> PR snapd#4855 opened: Translate polkit strings <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4855>
[19:49] <mup> PR snapd#4852 closed: snapstate: put layout feature behind feature flag (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4852>
[19:56] <oSoMoN> sergiusens, is https://forum.snapcraft.io/t/custom-environment-variables-for-parts/1639/9 being planned / worked on yet?
[19:57] <oSoMoN> (I might be able to take a stab at it if not)
[20:04] <zyga-ubuntu> hmmm
[20:04] <zyga-ubuntu> I'm getting consistent failures
[20:04]  * zyga-ubuntu wonders what changed
[20:06] <zyga-ubuntu> + systemctl stop snapd.service snapd.socket
[20:06] <zyga-ubuntu> Job for snapd.service canceled.
[20:06] <cachio> zyga-ubuntu, I have fixed that
[20:06] <zyga-ubuntu> mvo: if you are around, do you have any idea what may have changed?
[20:06] <zyga-ubuntu> oh
[20:06] <zyga-ubuntu> cachio: shall I pull master?
[20:07]  * zyga-ubuntu hugs cachio :-)
[20:07] <cachio> no yet
[20:07] <zyga-ubuntu> what do I need?
[20:07] <cachio> I was testing that
[20:07] <cachio> I'll push in 5 minutes
[20:07] <zyga-ubuntu> excellent, thank you
[20:07] <zyga-ubuntu> I will send kids to bed in the meantime
[20:08] <sergiusens> oSoMoN: no, not on the roadmap; we could plan for it in Berlin.
[20:09] <mvo> zyga-ubuntu: hey
[20:09] <mvo> zyga-ubuntu: I am around, what is the question
[20:11] <oSoMoN> sergiusens, please do :) I won't be in Berlin but I'll be tracking it
[20:13] <mup> PR snapd#4856 opened: release: 2.32~pre2 changelogs <Created by mvo5> <https://github.com/snapcore/snapd/pull/4856>
[20:17] <sergiusens> oSoMoN: if you want to implement I would not be against that either ;-)
[20:17] <mwhudson> zyga-ubuntu: morning
[20:18] <mwhudson> zyga-ubuntu: "We can check that we are on an overlayfs, look at the upperdir and check if it is a tmpfs." <- does this mean parsing /proc/mounts or something else?
[20:18] <mwhudson> if so, does snapd already have code for this?
[20:19] <cachio> zyga-ubuntu, #4857
[20:19] <mup> PR #4857: tests: adding checks before stop snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[20:19] <mup> PR snapd#4857 opened: tests: adding checks before stop snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[20:19] <cachio> is not a super elegant solution but should work
[20:20] <cachio> We already used that in the past to fix the same problem in the reset
[20:20] <mwhudson> mmm osutil/mountinfo.go looks like a good start ;)
[20:20] <mup> PR snapd#4855 closed: data: translate polkit strings (2.32) <Created by gunnarhj> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4855>
[20:24] <zyga-ubuntu> re
[20:24] <zyga-ubuntu> hey good morning
[20:24] <zyga-ubuntu> mwhudson: we have code for this already
[20:24] <zyga-ubuntu> mwhudson: please look at ... (one sec)
[20:25] <zyga-ubuntu> https://github.com/snapcore/snapd/blob/master/osutil/overlay.go#L44
[20:25] <zyga-ubuntu> I believe this can be modified to return both upper and lower dir
[20:25] <zyga-ubuntu> and then we can inspect the upper dir path to find the fstype
[20:26] <mwhudson> oh heh that code looks installer relevant
[20:26] <zyga-ubuntu> it is referenced from ..
[20:27] <zyga-ubuntu> https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend.go#L114 and https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend.go#L441
[20:27] <zyga-ubuntu> which means it ends up in both snap-confine and per-snap profiles
[20:27] <zyga-ubuntu> er
[20:27] <oSoMoN> sergiusens, I haven't looked into implementation details yet, but it looks like it shouldn't be too much work
[20:27] <zyga-ubuntu> per app snap profiles
[20:27] <mwhudson> yeah that makes sense
[20:27] <zyga-ubuntu> we could use it as a starting point
[20:27] <zyga-ubuntu> I think rather than doing elaborate mountinfo analysis just find upperdir and then fstatfs it
[20:28] <mwhudson> i guess we should change code around here: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/autorefresh.go#L134
[20:28] <mwhudson> (which seems very fresh, hi pedronis)
[20:36] <zyga-ubuntu> mwhudson: not sure, ask pedronis via the forum
[20:36] <mwhudson> zyga-ubuntu: ack
[20:49] <mvo> cachio: we might have a new 2.32~pre for amd64/i386 soon in beta
[20:49] <mvo> cachio: arm seems to be a bit slow to build though
[20:49] <cachio> mvo, perfect
[20:49] <cachio> tomorrow afternoon I'll be off
[20:49] <mvo> cachio: no worries
[20:49] <cachio> mvo, but I can make the tests run
[20:49] <mvo> cachio: getting it into beta and bionic is the key here, all else is bonus :)
[20:50] <cachio> so should not be a problem
[20:50] <mvo> cachio: thank you! that is great
[20:52] <cachio> np
[20:53] <zyga-ubuntu> cachio: so, what can I do to unblock PRs?
[20:54] <cachio> zyga-ubuntu, we need to merge #4857  first
[20:54] <mup> PR #4857: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[20:54] <cachio> it is the first part of the solution
[20:54] <zyga-ubuntu> ok, reading
[20:54] <zyga-ubuntu> what's next?
[20:55] <cachio> then I'll apply that to the other tests and scripts
[20:55] <cachio> zyga-ubuntu, I just applied that for those tests that were failing
[20:55] <cachio> basically it fails in tests with script which are stopping snapd in the first line
[20:56] <cachio> in the prepare
[20:56] <cachio> it happens because in the prepare-each the last line is starting the snapd.service and socket
[20:56] <cachio> and for some reason now the start is taking more time than before
[20:57] <zyga-ubuntu> cachio: can we use systemctl is-active?
[20:57] <cachio> well, the problem is that the status "activating" makes the mess
[20:57] <cachio> is-active returns true
[20:58] <cachio> but it is not fully ready
[20:58] <cachio> it is just happening in 14.04
[20:58] <cachio> perhaps we could try to make a change in systemd to prevent that
[20:59] <cachio> and/or see why the systemd service is taking more time to be active (running)
[20:59] <zyga-ubuntu> hmm
[20:59] <zyga-ubuntu> I mean
[20:59] <zyga-ubuntu> it prints "active"
[20:59] <zyga-ubuntu> I mainly ask because it looks cleaer than doing status and grepping
[21:00] <zyga-ubuntu> *cleaner
[21:01] <cachio> zyga-ubuntu, is-active is not enough
[21:02] <cachio> zyga-ubuntu, that's the problem
[21:03] <cachio> zyga-ubuntu, perhaps I am not getting you well, please add a comment in the PR
[21:03] <zyga-ubuntu> nah, that's ok
[21:03] <cachio> this solution is temporal
[21:03] <zyga-ubuntu> I'm fine with good is better than perfect if it ships
[21:03] <cachio> I think we need to figure out why it is happening now, and not before
[21:04] <cachio> but I did that to unblock all the other PRs
[21:06] <cachio> zyga-ubuntu, let's see if all the tests pass
[21:06] <cachio> zyga-ubuntu, I just tested completion
[21:06] <cachio> with repeat 50
[21:07] <oSoMoN> I'm not finding any documentation on build-snaps. how does snapcraft expose the contents of the build-snaps once they are installed?
[21:09] <mvo> cachio: i386 is in beta now
[21:10] <mvo> cachio: looks like you need to shepherd amd64/arm* into beta, it takes a long time today :/
[21:12] <mvo> cachio: or will do the rest in my morning, need to sleep now. cu
[21:12] <oSoMoN> sergiusens, ^
[21:16] <cachio> zyga-ubuntu, well, no errors for 14.04
[21:16] <cachio> still missing to finish one test
[21:16] <zyga-ubuntu> ok
[21:21] <cachio> zyga-ubuntu, in green
[22:12] <Chipaca> niemeyer: ping
[22:12] <niemeyer> Chipaca: pong but on a call
[22:13] <Chipaca> niemeyer: ah, give me a shout when you get off, i'll prepare some examples meanwhile
[22:22] <zyga-ubuntu> Chipaca: wow, you're working late
[22:23] <zyga-ubuntu> cnk
[22:23] <zyga-ubuntu> cachio: is it merged?
[22:23] <Chipaca> zyga-ubuntu: i don't work tomorrow, and i want to fix this snap info description thing
[22:23] <cachio> zyga-ubuntu, let me check
[22:24] <zyga-ubuntu> Chipaca: I understand the feeling
[22:24] <zyga-ubuntu> plus
[22:24] <zyga-ubuntu> I had coffee
[22:24] <zyga-ubuntu> that wasn't a smart thing
[22:24] <cachio> zyga-ubuntu, no reviews yet
[22:24] <zyga-ubuntu> but it was leftover after some cake we made
[22:24] <zyga-ubuntu> and now I'm here and looking at a bug
[22:27] <cachio> Chipaca, zyga-ubuntu #4857
[22:27] <mup> PR #4857: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[22:27] <cachio> please take a look before merging it
[22:36] <Chipaca> zyga-ubuntu: oooh, i have cake too
[22:36] <Chipaca> but … it's downstairs
[22:39] <zyga-ubuntu> Chipaca: let's review 4857
[22:39] <zyga-ubuntu> it shoud fix master
[22:39] <Chipaca> i'm looking at it
[22:39] <Chipaca> and scritching my head
[22:39] <Chipaca> is systemd really this broken
[22:39] <zyga-ubuntu> why
[22:39] <zyga-ubuntu> heh
[22:40] <zyga-ubuntu> that's a good question
[22:40] <zyga-ubuntu> I'm inclined to slap a TODO on it and merge it because it's green
[22:40] <zyga-ubuntu> and red sucks
[22:40] <zyga-ubuntu> actually
[22:40] <zyga-ubuntu> maybe we are just silly
[22:40] <zyga-ubuntu> maybe the "cancelled" error just means
[22:40] <zyga-ubuntu> yeah, it's off
[22:40] <Chipaca> zyga-ubuntu: ?
[22:40] <zyga-ubuntu> but returns an error
[22:41] <Chipaca> ah, no
[22:41] <Chipaca> zyga-ubuntu: cancelled means 'i couldn't queue that job you asked me to do'
[22:41] <zyga-ubuntu> ah
[22:41] <zyga-ubuntu> hmmm
[22:41] <Chipaca> where 'that job' is stopping the thing
[22:41] <zyga-ubuntu> did we report it upstream?
[22:41] <Chipaca> zyga-ubuntu: AIUI it's fixed in a new enough systemd
[22:42] <zyga-ubuntu> but not in 18.04
[22:42] <Chipaca> also if we describe what we're doing to systemd in trusty i suspect pottering will weep
[22:42] <Chipaca> zyga-ubuntu: isn't this 14.04 fix?
[22:42] <zyga-ubuntu> but this was affecting 16.04 and others
[22:42] <zyga-ubuntu> hmm
[22:42] <zyga-ubuntu> one sec
[22:42] <cachio> it is affecting just 14.04
[22:42] <Chipaca> if we can catch it on a new enough  one, yes please let's report it
[22:43] <Chipaca> i thought it was always trusty
[22:43] <zyga-ubuntu> ah
[22:43] <zyga-ubuntu> yes, just 14.04
[22:43] <zyga-ubuntu> so...
[22:43] <zyga-ubuntu> meh but yes
[22:43] <zyga-ubuntu> I wonder why now it became so apparent
[22:43] <zyga-ubuntu> did something change
[22:43] <zyga-ubuntu> or is it just google cloud being "better"
[22:44] <Chipaca> races are racy
[22:44] <zyga-ubuntu> I have a feeling we are "winning" more often now
[22:44] <Chipaca> niemeyer: depending on how busy your call is, if you want, take a look at http://people.canonical.com/~john/wrappers.txt
[22:45] <Chipaca> niemeyer: bottom line the current formatDescr is very buggy, so  i rewrote it, but before pushing i thought i'd compare it with formatDescr and with go/doc's ToText
[22:45] <Chipaca> niemeyer: in my book, i win
[22:46] <Chipaca> niemeyer: but i thought i'd check with you
[22:46]  * zyga-ubuntu -> Zzz
[22:47] <niemeyer> Chipaca: Which one is yours? Top?
[22:47] <Chipaca> niemeyer: the one labeled 'wordwrap'
[22:47] <Chipaca> yes, top
[22:47] <mup> PR snapd#4857 closed: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4857>
[22:47] <niemeyer> Chipaca: A bit strange on acestreamplayer
[22:48] <Chipaca> niemeyer: that's the 'respecting existing \n' thing
[22:49] <niemeyer> Chipaca: Even worse on autopilot-qt
[22:49] <niemeyer> Chipaca: I wonder if we should fold
[22:49] <niemeyer> Chipaca: and respect empty lines instead
[22:49] <Chipaca> niemeyer: knowing when to fold is hard
[22:49] <niemeyer> Chipaca: Empty lines?
[22:49] <Chipaca> niemeyer: look at firefox for an example of folding
[22:49] <zyga-ubuntu> just buy 100 nvidia GPUs and have them AI the problem away
[22:50] <Chipaca> zyga-ubuntu: Zzz
[22:50] <niemeyer> Chipaca: I see..
[22:50] <Chipaca> zyga-ubuntu: (in reading this i saw there's a gpu-enabled terminal, and i wondered why a terminal would use the gpu for the terminal and not for ai)
[22:50] <niemeyer> Chipaca: Empty lines and non letters at start, maybe..
[22:50] <niemeyer> Chipaca: I think it's going into a good direction.. and the exercise you're doing is great
[22:51] <niemeyer> Chipaca: Thanks for that!
[22:51] <niemeyer> Chipaca: Let's see if we can do some conservative folding, starting on the cases we're pretty sure is fine.. that might be better than to figure when *not* to fold
[22:51] <Chipaca> niemeyer: if knowing when to fold were easy there wouldn't be a Common Mark :-)
[22:52] <niemeyer> Anyway
[22:52] <Chipaca> but, sure
[22:52] <niemeyer> I need to run
[22:52] <Chipaca> niemeyer: aw
[22:52] <Chipaca> you're no fun any more :-)
[22:52] <Chipaca> niemeyer: I'll push this, as it's an improvement over formatDescr, and we can loop back next week
[22:52] <Chipaca> i'm not here tomorrow :-)
[22:52] <niemeyer> Thank you!
[22:52] <niemeyer> Me neither
[22:52] <niemeyer> :)
[22:52] <niemeyer> Or maybe not anyway ;)
[22:52] <zyga-ubuntu> haha
[22:52] <niemeyer> ... nothing to see here ... o/
[22:52] <zyga-ubuntu> so "see you all tomorrow"
[22:53] <zyga-ubuntu> this team is so predictibly terrible at not working
[22:53]  * zyga-ubuntu goes to sleep
[22:57] <Chipaca> niemeyer: btw in that .txt the "has \n\n" and "has \r" is to help figure out folding heuristics, if they exist
[22:57] <cachio> zyga-ubuntu, good night
[22:57] <Chipaca> the "has \t" is because i refuse to care if it looks bad because somebody put tabs in there
[23:17] <mwhudson> how long should booting ubuntu core on a dragonboard take?
[23:18] <mwhudson> i haven't booted this one in a long time so it's possible the hardware has died
[23:18] <mwhudson> but it's hanging at "failed to load macaddress file, using random one instead"
[23:20] <mwhudson> or it's possible i hadn't inserted the sd card fully
[23:27] <zyga-ubuntu> mwhudson: hmm, it should boot pretty quickly
[23:27] <zyga-ubuntu> mwhudson: I had to reflash my SD card after loooong inactivty, not sure why
[23:27] <zyga-ubuntu> maybe that other card just failed
[23:27] <mwhudson> zyga-ubuntu: nah i just hadn't pushed the card i was booting off in fully :)
[23:28] <zyga-ubuntu> ah :)
[23:28]  * zyga-ubuntu cannot sleep after that coffee
[23:29] <mwhudson> ok now time to try to remember how to make an ubuntu core image
[23:29] <zyga-ubuntu> ctrl-r ubuntu-image ;-)
[23:29] <zyga-ubuntu> you need a model assertion
[23:29] <zyga-ubuntu> the rest is easy-ish
[23:29] <mwhudson> yes exactly :)
[23:31] <mwhudson> uh i also need to download an arm64 core snap
[23:32] <mup> PR snapd#4858 opened: strutil, cmd/snap: drop strutil.WordWrap, first pass at replacement <Created by chipaca> <https://github.com/snapcore/snapd/pull/4858>
[23:32] <Chipaca> zyga-ubuntu: ^ special rune-wrangling pr for curing insomnia
[23:33] <mwhudson> uhh my board rebooted and snapd paniced with "sync: unlock of unlocked mutex"
[23:33] <zyga-ubuntu> uh
[23:33] <zyga-ubuntu> not fun
[23:33] <zyga-ubuntu> what did it do before
[23:33] <zyga-ubuntu> I recall we had some issues when error cases would panic
[23:33] <zyga-ubuntu> s/cases/paths/
[23:33] <zyga-ubuntu> but not deliberatly, more by accident really
[23:34] <mwhudson> https://www.dropbox.com/s/y2svocouxp7o1h2/IMG_20180316_123326990.jpg?dl=0
[23:35] <mwhudson> hm not extremely readable
[23:35] <zyga-ubuntu> no, not much
[23:35] <zyga-ubuntu> can you focus on the screen and send another one
[23:35] <zyga-ubuntu> oh
[23:36] <zyga-ubuntu> invalid memory address or nil pointer dereference
[23:36] <zyga-ubuntu> looks like pedronis-land
[23:36] <zyga-ubuntu> I don't know that code much
[23:36] <zyga-ubuntu> but please drop this in the forum
[23:36] <zyga-ubuntu> looks like something to fix for the release
[23:40] <mwhudson> https://forum.snapcraft.io/t/panic-on-dragonboard/4490
[23:41] <zyga-ubuntu> Chipaca: replied
[23:41] <zyga-ubuntu> Thank you mwhudson
[23:41] <zyga-ubuntu> you can drop the image into the forum
[23:41] <zyga-ubuntu> it is more long-lived than a dropbox URL
[23:41] <zyga-ubuntu> just drag the image over to the edit field
[23:41] <zyga-ubuntu> and wow
[23:41] <zyga-ubuntu> you have a big office :D
[23:42] <mwhudson> haha i can't work at home any more
[23:42] <zyga-ubuntu> why not?
[23:42] <zyga-ubuntu> Chipaca: https://travis-ci.org/snapcore/snapd/builds/354083470?utm_source=github_status&utm_medium=notification
[23:43] <zyga-ubuntu> this build is done but still "running" on travis
[23:43] <zyga-ubuntu> it will fail on timeout any moment now
[23:44] <zyga-ubuntu> ok
[23:45] <zyga-ubuntu> I will now exercise "can I keep my eyes closed" game
[23:49] <Chipaca> ok, i'm out of here
[23:49] <Chipaca> see you all when i see you all


[04:52] <lulwutz> Anybody here use Acer Aspire One and successfully got their wireless to work?
[06:31] <Guest34476> Anybody here using Acer Aspire One successfully get their wireless to work?


[06:43] <noaXess> hey at all specially @lordievader and @Mamarok ;) long time ago
[07:03] <lordievader> Good morning
[08:07] <linuxjoergen> Good day, Kubuntu users...
[08:08] <linuxjoergen> For the past week I have experienced very high CPU usage on plasmashell on both my computers. Both are running Kubuntu 21.10 with latest updates.
[08:08] <linuxjoergen> Anyone else seeing the same?
[08:09] <linuxjoergen> top reveals a CPU usage of up to 600%
[12:01] <linsux> how do i convert kubuntu to mate desktop enviroment
[12:01] <linsux> need kubuntu completely gone
[12:09] <alkisg> sudo apt install mate-desktop
[12:09] <alkisg> Then when you're sure that everything works, sudo apt purge --auto-remove kubuntu-desktop
[12:40] <oerheks> Adding and switch desktop is no problem, removing one is interesting
[12:40] <oerheks> i would reinstall
 me too (re @IrcsomeBot: <oerheks> i would reinstall)
[14:09] <BluesKaj> 'Morning folks
[14:22] <Mamarok> noaXess: hi, long time no see :-)
[14:22] <noaXess> yeah.... busy, special time and and and..
[14:22] <noaXess> aha hey @BluesKaj
[14:23] <noaXess> i remember there where some known people here.. and still here.. NICE
[14:27] <BluesKaj> hi noaXess
[14:28] <BluesKaj> hi Mamarok
[14:33] <Mamarok> hi BluesKaj
[14:35] <BluesKaj> Mamarok, LTNS, how are you?
[14:52] <Mamarok> fine, feeling great, despite my booster shot yesterday. Actually because of it probably :)
[14:54] <BluesKaj> heh, right, I'll be getting mine in Jan which is 6mos after my 2nd shot
[15:05] <Mamarok> my 6 months were early Nov, but I am in a high-risk category. Mind you, if you can get it earlier, the better, especially if you plan to visit Germany (or Switzerland or Austria)...
[15:13] <mybalzitch> when I'm prompted to give my password to unlock "default keyring" Why doesn't it tell me what app is requesting it
[15:16] <oerheks> mybalzitch, seahorse/keyring is; i think you login automaticly?
[15:16] <mybalzitch> it says "An application" and I have a feeling its for backups
[15:16] <mybalzitch> or some trojan
[15:16] <mybalzitch> ¯\_(ツ)_/¯
[15:16] <oerheks> nope
[15:19] <brandoneliza> I am having trouble with shotcut as an appimage on my kubuntu host using 20.04.3. The funny thing is I do not experience the same problem with a kubuntu 20.04.3 KVM guest. When I change the fonts (bold italic etc) on the host they don't update correctly. But in the guest they.
[15:19] <brandoneliza> I tried resetting the configuration of shotcut but no luck. Also the vm guest seems to be running the kernel 5.11 but my host with the latest updates has ther kernel version 5.4.x
[15:20] <brandoneliza> can someone help me understand why the difference
[15:20] <brandoneliza> can't find a shotcut irc channel so not sure how to ask program specific questions but wondering if there is anything on kubuntu I can check
[15:20] <oerheks> brandoneliza, custom fonts in shotcut snap? install the apt version
[15:20] <brandoneliza> oerheks: not only with custom font with the stock ubuntu font
[15:21] <brandoneliza> but ony on the host not on the guest. THe guest cannot use the integrated gpu and uses opengl 3 1 instead of the hosts's 4 6 but tand 1 two plugins dont load in the guest as per the log
[15:22] <brandoneliza> the stock ubuntu fint has many weights so it is a good test
[15:23] <brandoneliza> oerheks: wonder how the guest is running a much newer kernel too since the host and guest use the same ubuntu version
[15:24] <brandoneliza> oerheks: let me remove the snap and try the repo version again as you suggested
[15:26] <oerheks> probably HWE kernel
[15:26] <oerheks> !hwe
[15:31] <brandoneliza> oerheks: yes the VM is using an HEW kernel the host is not
[15:31] <brandoneliza> *HWE
[15:40] <brandoneliza> oerheks: https://paste.opensuse.org/add10b20 is the screenshot. The right is the vm kubuntu 20.04.3 the left is the host kubuntu 20.04.3  both are shotcut snaps and the same version. The guest has the horizontal fit etc. options and the fonts are updating correctly the host is not
[15:46] <oerheks> weird result, but i suggested the apt version, fonts issues are known with snap
[16:54] <brandoneliza> oerheks: but the issue is identiical on the host too with the appimage. I am testing the apt version
[17:13] <brandoneliza> oerheks: I think I know what is wrong. in the vm the snapcraft base is based off "core18" but on the host it is based off "core" how do I switch the base to core18. THe guest has a "core18 and a snapd in the snap list"
[17:16] <brandoneliza> hmm probably i can't I guess I need to reformat root with a new OS to get that I think
[17:28] <brandoneliza> oerheks: the apt installed shotcut segfaults the moment I drag a clip to the timeline
[17:29] <brandoneliza> and the font bug is present in the apt version too
[17:29] <brandoneliza> since it is much older I am wondering if the bug is somewhere else in my kubuntu install in some other config file or something
[22:38] <genii> !18.04