[08:27] <xubuntu29w> Hello, I've installed Xubuntu 18.04 on a new laptop. I had to use nomodeset in order for it to boot on the live USB. Now it has installed, I can get to the login screen fine, but after that I just have the desktop wallpaper and mouse. That's all I can see. Any ideas?
[08:28] <xubuntu29w> I assume this could be a graphics problem. I have an NVIDIA 1050 and integrated Intel graphics too?
[08:29] <diogenes_> xubuntu29w, open a terminal ctrl+alt+t
[08:29] <xubuntu29w> diogenes_: on the login screen?
[08:30] <xubuntu29w> I'm in the process of reinstalling so will let you know once done
[08:31] <diogenes_> ok
[08:32] <diogenes_> xubuntu29w, btw do you have a separate /home and preserved data on it from the previous installations?
[08:35] <xubuntu29w> diogenes_ no, I'm using a whole disk and doing a clean install
[08:35] <xubuntu29w> it's a Dell G3 3779 if that helps also
[08:36] <diogenes_> ok let's see what you get after the installation.
[08:37] <xubuntu29w> almost done:)
[08:40] <xubuntu29w> diogenes_ okay it has now installed, I've logged in and there's just the wallpaper showing with the mouse cursor
[08:41] <xubuntu29w> after logging in, I can't Ctrl Alt T
[08:41] <diogenes_> ctrl+alt+f1
[08:42] <xubuntu29w> Neither work at the login screen
[08:42] <xubuntu29w> diogenes_ f1 after logging in?
[08:42] <xubuntu29w> no that doesn't appear to do anything either
[08:43] <diogenes_> ok go to the login screen and see the session chooser, what do you have there? xsession, xfce-session?
[08:43] <xubuntu29w> Xfce session and Xubuntu session
[08:44] <diogenes_> which on is default?
[08:44] <xubuntu29w> Xubuntu is the default
[08:44] <diogenes_> ok try the other one.
[08:44] <xubuntu29w> done so, that still doesn't work
[08:45] <diogenes_> ok then reboot and at grub menu ress 'e'
[08:45] <diogenes_> press*
[08:45] <xubuntu29w> GRUB menu doesn't come up at boot, it seems to boot straight in
[08:45] <xubuntu29w> Is this normal? I'll try pressing e on  the keyboard
[08:46] <xubuntu29w> nope no GRUB menu or access to it
[08:47] <diogenes_> turn off pc, then turn on again and keep the shift key pressed while it's booting, grub should be shown.
[08:50] <xubuntu29w> diogenes_ tried twice, still no GRUB
[08:51] <diogenes_> xubuntu29w, ok then as soon as you reach the login screen try these: ctrl+alt+f1/f2/f3/f4/f5 see which one will bring you the TTY.
[08:52] <xubuntu29w> diogenes_ none of them wor
[08:52] <xubuntu29w> my keyboard works
[08:52] <xubuntu29w> but they don't bring up anything
[08:52] <diogenes_> xubuntu29w, do you still have the installation usb?
[08:53] <xubuntu29w> It's not the .iso or USB as I've written this 3 times in rufus as dd, even tried an older iso of 18.04, same problem
[08:53] <xubuntu29w> diogenes_ yep
[08:53] <diogenes_> ok boot the live usb.
[08:54] <xubuntu29w> diogenes_ booted, using the nomodeset option in GRUB
[08:54] <diogenes_> ok now open a terminal.
[08:55] <xubuntu29w> ctrl alt t'd
[08:55] <xubuntu29w> it's open
[08:55] <diogenes_> lsblk
[08:56] <diogenes_> see which one is your root partition of your HDD not USB.
[08:56] <diogenes_> usually /dev/sda1
[08:56] <xubuntu29w> nvme0n1p1 is the disk
[08:57] <xubuntu29w> nvme0n1
[08:57] <xubuntu29w> then a 512MB partition on nvme0np1
[08:57] <xubuntu29w> and the rest of the disk is on nvme0np2
[08:57] <diogenes_> hmm did you disable secure boot in bios?
[08:59] <diogenes_> ok let's try this
[08:59] <diogenes_> mkdir chroot
[08:59] <xubuntu29w> secure boot is disabled
[08:59] <diogenes_> sudo mount nvme0n1p1 chroot/
[08:59] <diogenes_> sudo mount --bind /dev chroot/dev
[08:59] <diogenes_> sudo mount --bind /sys chroot/sys
[08:59] <diogenes_> sudo mount --bind /proc chroot/proc
[09:01] <xubuntu29w> first command says mount point does not exist
[09:01] <xubuntu29w> "chroot/: mount point does not exist"
[09:02] <diogenes_> first command is mkdir chroot
[09:02] <diogenes_> then sudo mount nvme0n1p1 chroot/
[09:03] <xubuntu29w> ah missed that
[09:04] <xubuntu29w> it's saying special device nvme0n1p1 does not exist
[09:04] <xubuntu29w> it shows in lsblk
[09:05] <diogenes_> sudo mount /dev/nvme0n1p1 chroot/
[09:05] <xubuntu29w> worked
[09:06] <diogenes_> now the other 3
[09:06] <diogenes_> sudo mount --bind /dev chroot/dev ...
[09:06] <xubuntu29w> third doesn't work
[09:06] <xubuntu29w> mount point does not exist
[09:07] <diogenes_> paste here what you run as the 3rd.
[09:07] <xubuntu29w> chroot/dev: mount point does.....
[09:07] <xubuntu29w> sudo mount --bind /dev chroot/dev
[09:07] <diogenes_> the entire command i mean.
[09:13] <xubuntu29w> Debian and openSUSE have installed fine
[09:13] <xubuntu29w> just was having issues with NVIDIA prime
[09:14] <xubuntu29w> which doesn't seem to be implemented too well in Linux at this time
[09:14] <diogenes_> well i use nvidia optimus too and i got no problems at all, using the oss nouveau driver instead on nvidia.
[09:42] <jatt> after upgrading from disco to eoan the restart and shutdown buttons are grayed out. what could be the reason?
[09:44] <jatt> the power manager says there is no authorization to shutdown: http://dpaste.com/197484T
[14:22] <Regor> how to enable  links in terminal ?
[14:29] <sublevel> Regor:  you can ctrl+click, or right click them
[14:29] <Kumool> depends on the terminal
[14:30] <sublevel> well xubuntu has a default terminal
[14:30] <Regor> 18.04 default
[14:31] <Regor> yeah.got it
[14:32] <Regor> actually on weechat it needs shift key with mouse enabled
[14:32] <sublevel> aha, I'm not surprised weechat's mouse mode affects it
[14:33] <Regor> yeah
[14:33] <sublevel> if you want to use alt+number to change weechat buffers I found out how to stop xfce4-terminal hogging that shortcut recently
[14:34] <Regor> yeah :)
[14:34] <sublevel> I'll find it for you in a bit
[14:34] <Regor> :)
[14:40] <salamanderrake> Is there a way to install the testing xubuntu 19.10 without a new install?
[14:41] <sublevel> Regor: here it is  https://docs.xfce.org/apps/terminal/start   (I'd tried commenting out those lines with no luck, setting them to "" was the key)
[14:42] <Regor> sublevel: thanks :D
[14:43] <sublevel> I wonder if my programming skills would be up to making a patch that adds a GUI preferences option
[15:49] <Spass> salamanderrake, if you're using 19.04 right now you could probably change the main repos from "disco" to "eoan" and full-upgrade, but don't do that on your non-testing installation, since it may cause some issues and you may end with a non-working system
[15:57] <Regor> how to set  transmission  minimized while closing the window?
[17:29] <Spass> Regor, minimized to tray? there's an option for that in the preferences window, Desktop tab, enable "Show Transmission icon in the notification area"
[17:31] <Regor> thanks i found  it
[17:41] <ilovetrump> hello nice people
[17:41] <ilovetrump> i love you all
[17:41] <ilovetrump> how are you doing today?
[19:13] <swift110> htey
[19:39] <sublevel> 18.04,  I have my laptop set to just switch off display when lid is closed, that works as expected but if the screen is locked it goes into suspend instead.  Where might I begin looking for a way to prevent that?
[19:40] <sublevel> Had a look at the light-locker man pages
[19:51] <tomreyn> hmm maybe energy settings?
[19:55] <sublevel> Power Manager settings? I've checked all the tabs there
[19:57] <tomreyn> yes that's what i meant- i don't have a better suggestion.
[19:58] <sublevel> perhaps it's down to systemd config, in journalctl I have systemd-logind[988]: Lid closed.   then  systemd-logind[988]: Suspending...
[19:58] <tomreyn> you can generally configure how the lid closing event is handled there
[19:59] <tomreyn> but i don't think it has a means to handle it differently based on whether or not the screen is locked
[19:59] <sublevel> Indeed, but it only seems to affect when my screen is unlocked
[19:59] <tomreyn> i.e. man page logind.conf(5)
[20:00] <sublevel> good plan
[20:04] <sublevel> HandleLidSwitch=ignore  works and doesn't appear to break anything else, hurrah


  Thank you for using freenode!
[06:19] <Shadix> * -
[06:19] <Shadix> * End of /MOTD command.
[06:19] <Shadix> -NickServ- This nickname is owned by someone else
[06:19] <Shadix> -NickServ- If this is your nickname, type /msg NickServ IDENTIFY <password>
[06:19] <nalioth> what are you trying to install?
[06:19] <Shadix> * Received a CTCP VERSION from freenode-connect
[06:19] <Shadix> * #ubuntu+2 #ubuntu+1 :Forwarding to another channel
[06:20] <Shadix> Barry
[06:20] <nalioth> !info barry
[06:20] <ubotu> Package barry does not exist in gutsy
[06:20] <nalioth> what exactly is it?
[06:20] <Shadix> http://netdirect.ca/software/packages/barry/install.php
[06:20] <Shadix> to sync my blackberry
[06:21] <nalioth> ah crackberry
[06:21] <Shadix> yep
[06:21] <nalioth> in your synaptic, search for "opensync" and install whatever it said was missing
[06:21] <nalioth> make sure what you install has a -dev on the end of the package name
[06:24] <Shadix> ok
[06:24] <nalioth> find it?
[06:24] <Shadix> done
[06:24] <Shadix> yah
[06:24] <nalioth> now try your ./configure again
[06:24] <nalioth> do you have checkinstall installed?
[06:24] <Shadix> do what
[06:24] <Shadix> dunno
[06:25] <nalioth> !checkinstall
[06:25] <ubotu> checkinstall is a wrapper to "make install", useful for installing programs you compiled. It will create a .deb package, which will be listed in the APT database and can be uninstalled like other packages. See https://help.ubuntu.com/community/CheckInstall - Read the warnings at the top and bottom of that web page, and DO NOT interrupt CheckInstall while it's running!
[06:25] <nalioth> it is recommended you use checkinstall instead of 'make install'
[06:28] <Shadix> well i don't have it installed
[06:29] <Shadix> I take it you mean i should adjust the commands by removing  "make install" and replacing them with  checkinstall
[06:30] <nalioth> yes
[06:31] <nalioth> it'll make your experience much easier
[06:31] <Shadix> where do I get checkinstall?
[06:32] <Shadix> sudo apt-get checkinstall?
[06:36] <nalioth> yep
[06:36] <nalioth> apt-get install
[06:36] <nalioth> synaptic
[06:36] <nalioth> aptitude
[06:36] <nalioth> adept
[06:36] <nalioth> whatever you like
[06:45] <Shadix> ok here is what happened http://paste.ubuntu-nl.org/45092/
[06:46] <nalioth> so write a description
[06:46] <Shadix> ok what am i describing?
[06:46] <nalioth>  Barry is a GPL C++ library to interface with USB BlackBerry handheld devices on Linux.
[06:47] <nalioth> c++ blackberry interface
[06:47] <nalioth> whatever you put, will show up in synaptic and be looked at during searches
[06:50] <Shadix> errr http://paste.ubuntu-nl.org/45093/
[06:52] <nalioth> guess we have to fall back to "make install"
[06:52] <Shadix> k
[06:53] <Shadix> grrr did it again
[06:53] <Shadix> http://paste.ubuntu-nl.org/45094/
[06:54] <Shadix> wat the devil is with opensync
[06:56] <Shadix> why do these thing have to be so difficult could there just be a click and drool method lol
[06:56] <nalioth> ubotu: find opensync
[06:56] <ubotu> Found: libopensync0, libopensync0-dbg, libopensync0-dev, opensync-plugin-evolution, opensync-plugin-file (and 9 others)
[06:57] <nalioth> did you install all the **opensync***-dev  pkgs?
[06:57] <Shadix> maybe not
[06:58] <nalioth> libopensync0-dev is one of 'em
[06:58] <Shadix> any others that don't start with "open"
[07:00] <Shadix> yah didn;t have liopensync
[07:04] <Shadix> nalioth, just these issues http://paste.ubuntu-nl.org/45096/
[07:04] <Shadix> opensynce worked
[07:05] <nalioth> "sudo make install"
[07:05] <nalioth> if checkinstall doesn't work
[07:05] <Shadix> ok
[07:11] <Shadix> nalioth, http://paste.ubuntu-nl.org/45098/ same isssue i think
[07:11] <Shadix> getting a command unknown
[07:12] <nalioth> Shadix: look at line 19
[07:12] <Shadix> ok what does that mean?
[07:12] <nalioth> means you need to install g++
[07:13] <Shadix> oh ok
[07:13] <nalioth> Shadix: have you installed "build-essential"  ?
[07:13] <Shadix> what is that?
[07:14] <nalioth> it has g++ and other tools for compiling software
[07:14] <nalioth> saves you from installing 3 dozen individual packages
[07:14] <Shadix> ok
[07:17] <Shadix> looks good so far...
[07:20] <Shadix> ok done now some of the commands are bcharge, btool, breset, and berrybackup where do I enter those commands to use this?
[07:20] <nalioth> in the terminal is a good start
[07:21] <Shadix> hmmm  jose@ubuntu:~$ barrybackup
[07:21] <Shadix> barrybackup: error while loading shared libraries: libbarry.so.0: cannot open shared object file: No such file or directory
[07:21] <Shadix> jose@ubuntu:~$
[07:22] <nalioth> now that we've got everything installed
[07:23] <Shadix> yep
[07:23] <nalioth>  why don't you delete the directory, and unpack the archive and start over?
[07:23] <Shadix> ........
[07:23] <Shadix> O.o
[07:23] <Shadix> good idea lol make sure it's done right eh?
[07:24] <nalioth> well, when you run configure/make/ more than once, it changes the files
[07:24] <Shadix> oh
[07:27] <nalioth> you can run "make clean" but not every developer includes that in their makefiles
[07:28] <nalioth> easier (and more sure) to just wipe the directory and unpack it again from the archive
[07:28] <nalioth> and i am off to bed now
[07:29] <Shadix> Well thank you very much for your help
[07:30] <Shadix> I could never have done it alone
[07:31] <nalioth> spread the love  (help someone else)  :)
[07:32] <Shadix> doh didn't work
[07:32] <Shadix> but GN
[07:32] <Shadix> and i will


[05:19] <mborzecki> morning
[05:34] <mup> PR snapd#8874 opened: spread: use find rather than recursive ls, skip mounted snaps <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8874>
[05:39] <mup> PR snapd#8875 opened: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[06:37] <mborzecki> heh, debian sets secure_path too
[06:58] <mborzecki> wierd things happening in google:centos-8-64:tests/main/selinux-clean
[06:59] <zyga> Good morning
[06:59] <zyga> Hey Maciek
[06:59] <mup> PR snapd#8859 closed: tests: enable snap-auto-mount test on core20 <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8859>
[06:59] <zyga> Ha, is the spread test immediately useful?
[07:00] <zyga> I just took meds, should be able to work in 30 minutes
[07:02] <mborzecki> zyga: there's some denials coming from systemd-logind trying to read 'linger' file (whcih we created?)
[07:02] <mborzecki> trying to make sure it's not us doing something wrong
[07:04] <pstolowski> morning
[07:06] <zyga> Heh
[07:06] <zyga> Linger is tests.session
[07:07] <zyga> It is a systemd feature
[07:07] <zyga> But probably underused and missing in selinux profiles
[07:08] <mborzecki> pstolowski: hello sir
[07:08] <zyga> Hey Paweł :-)
[07:21] <mborzecki> zyga: hm i'm seeing this:
[07:21] <mborzecki> type=SYSCALL msg=audit(1592291609.858:541): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=55ce2c1a6420 a2=f0000 a3=0 items=0 ppid=1 pid=39430 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(d-logind)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null)
[07:21] <mborzecki> type=AVC msg=audit(1592291609.858:541): avc:  denied  { read } for  pid=39430 comm="(d-logind)" name="linger" dev="sda2" ino=17559683 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:systemd_logind_var_lib_t:s0 tclass=dir permissive=1
[07:21] <mborzecki> H
[07:22] <zyga> which os is this?
[07:23] <mborzecki> which seems fine, because /var/lib/systemd/linger is labeled as systemd_logind_var_lib_t (correct & confimed with semanage fcontext), the pid is systemd-logind, which has systemd_logind_t and policy allows modifing that location
[07:23] <mborzecki> zyga: centos-8
[07:23] <mborzecki> zyga: so for some short while, init_t (systemd itself?) tries to read the linger directory
[07:23] <zyga> hmmmm
[07:24] <mborzecki> afair yesterday centos 8.2 was released, and looking at dnf log, the test pulled in a bunch of upgrades
[07:24] <mborzecki>      9 | -y --refresh install /us | 2020-06-16 07:03 | I, U           |   35 EE
[07:24] <mborzecki>      8 | -y --refresh install --s | 2020-06-16 07:01 | I, U           |  278 EE
[07:24] <mborzecki> perhaps the policy changed, and we just need to update the image
[07:25] <zyga> grep for linger in systemd shows only logind and related things
[07:25] <mborzecki> and the selinux-policy package got updated too
[07:25] <zyga> though
[07:26] <zyga> login also uses it
[07:26] <mborzecki> hm i'll try adding daemon-reexec in test prepare
[07:26] <zyga> not surem, maybe it just is used in init itself too
[07:28] <mborzecki> zyga: btw. debian uses sudo secure_path
[07:28] <zyga> mborzecki: commented on https://github.com/snapcore/snapd/pull/8875/files
[07:28] <mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[07:29] <zyga> su -l is nearly always dangerous
[07:29] <mborzecki> zyga: ha, ok will fix that
[07:34] <mup> PR snapd#8872 closed: tests/lib/prepare-restore.sh: if we failed to purge snapd deb, ls /var/lib/snapd <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8872>
[07:34] <mup> PR snapd#8873 closed: interfaces: misc small interface updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8873>
[07:34] <mup> PR snapd#8874 closed: spread: use find rather than recursive ls, skip mounted snaps <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8874>
[07:34] <pedronis> mborzecki: should we close or try to land #7414 ? it seems ok to me, one question is whether should we purge packages or just remove them?
[07:34] <mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[07:37] <pedronis> mborzecki: I commented in it directly
[07:37] <mborzecki> pedronis: thanks, will chekc in a minute
[07:39] <mup> PR snapd#8871 closed: tests/prepare-restore.sh: reset-failed systemd-journald before restarting <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8871>
[07:40] <zyga> mvo is on a merging spree :)
[07:43] <mvo> zyga: I was shocked to see 80(!) open PRs when I woke up
[07:43] <mvo> zyga: and figured I need to do something :)
[07:43] <zyga> :D
[07:44] <mup> PR snapd#7417 closed: interfaces/wayland: on classic systems only consider the OS slot for auto-connect <Needs Samuele review> <⛔ Blocked> <Created by AlanGriffiths> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7417>
[07:44] <mup> PR snapd#8789 closed: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <⛔ Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8789>
[07:56] <mborzecki> zyga: hm this looks like a bug in the policy or our setup, what happens is that we set StateDirectory=systemd/linger, then systemd tries to set up (create?) that directory for systemd-logind, but gets blocked by the policy
[07:56] <mvo> pedronis: in 8870 the interface name "gconf" is uncontroversial I assume? or is that something you want to review ?
[07:56] <zyga> hmm
[07:56] <zyga> mborzecki: up-to-date systemd has StateDirecty=systemd/linger
[07:57] <zyga> maybe centos-8 is just too old
[07:57] <zyga> it works fine on fedora
[07:57] <mvo> pedronis: other than the name 8870 is ready to get merged
[07:57] <zyga> I mean, the policy is probably too old
[07:57] <pedronis> mvo: I probably need to double check it
[07:58] <mvo> pedronis: sure thing, added the label
[08:01] <mvo> zyga: I updated 8865, it's a bit annoying that we can't use a pre-canned action but it should be simple enough, hopefully the comment explains enough
[08:01] <zyga> thanks, I'll check it in a moment
[08:01] <zyga> digging into some kernel bit for uinput
[08:01] <mvo> pedronis: I assume you also want to double check 8867 (uinput) ? if so I will add the label
[08:01] <mvo> zyga: oh, nice
[08:02] <pedronis> mvo: yes
[08:08] <mvo> a second review for 8857 would be great, should be quick and an easy win
[08:21] <zyga> mvo: added some comments there
[08:21]  * zyga small break
[08:26] <mborzecki> heh, so one of the tests moves xdg-open aside
[08:27] <mborzecki> zyga: and for now i have no clear solution for that selinux problem, feels like a policy bug, maybe if i can procure the ame state on rhel8 i could file a bug
[08:28] <mvo> zyga: nice, thanks!
[08:30] <mup> PR snapd#8855 closed: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8855>
[08:36] <mborzecki> zyga: do i need tests.session {prepare,restore} if i don't need anything or can i just tests.session exec in the test?
[08:37] <zyga> I would do it just in case
[08:37] <zyga> you probably just want restore
[08:37] <zyga> as using test.session without prepare still gives you a session
[08:37] <zyga> just makes it die briefly
[08:37] <zyga> I found it more reliably with prepare restore
[08:37] <zyga> as otherwise stuff starts and stops and may overrun
[08:41] <zyga> Gah thinkpad died again
[08:41] <mborzecki> i think i see the problem with xdg-open disappearing
[08:41] <zyga> I will use this as an excuse to eat breakfast
[08:41] <zyga> Hmmm?
[08:43] <mborzecki> zyga: xdg-open-compat overwrites /usr/bin/xdg-open, and then removes it
[08:49] <zyga> Ahhh
[08:49] <zyga> Nice catch!
[08:54] <mborzecki> i know we're not supposed to open new PRs but this one is super simple and fixes the problem ijohnson found https://github.com/snapcore/snapd/pull/8876
[08:54] <mup> PR #8876: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8876>
[08:55] <mborzecki> zyga: mvo: ^^
[08:55] <mup> PR snapd#8876 opened: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple 😃> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8876>
[08:56] <mvo> mborzecki: thanks
[08:58] <zyga> Looking
[09:00] <mup> PR snapd#8846 closed: tests: move update-related tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8846>
[09:00] <pstolowski> mvo: thank you! 🙏
[09:01] <mvo> pstolowski: thank you!
[09:02] <pedronis> pstolowski: I'm looking at it to, it needs a follow up
[09:05] <pstolowski> pedronis: thank you. it's quite possible i overlooked something, or some tests can be re-ordered
[09:06] <pedronis> pstolowski: https://github.com/snapcore/snapd/pull/8846#issuecomment-644637199
[09:06] <mup> PR #8846: tests: move update-related tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8846>
[09:07] <pedronis> pstolowski: yes, the order is a bit weird of some tests, but not sure is the main worry at this point
[09:07] <pstolowski> pedronis: right, i was pondering about sequence tests in the PR description
[09:07] <pstolowski> pedronis: will prep a followup
[09:08] <pedronis> thank you
[09:10] <pedronis> pstolowski: once we have split more we can consider if reordering is worth it, I agree is a bit strange that for example TestInstallTasks or TestUpdateTasks are not among the first tests one encouters in those files, same more the main run through ones
[09:11] <pedronis> more of an issue for people reading these for the first tiem
[09:13] <pstolowski> sounds good
[09:16] <zyga> I will work on existing PRs and reviews today
[09:16] <zyga> Need to relocate to another room though
[09:33] <mborzecki> zyga:  i've updated https://github.com/snapcore/snapd/pull/8875
[09:33] <mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[09:33] <zyga> ack
[09:35] <mup> PR snapd#8814 closed: sanity: check for unsynchronized real time clock <⛔ Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8814>
[09:35] <zyga> hmm
[09:36] <mborzecki> hm?
[09:38] <zyga> mborzecki: commented
[09:38] <zyga> I missed that you are running sudo to become root, not the test user
[09:38] <zyga> lets merge it
[09:38] <zyga> and if it shows up in any scans we can react
[09:39] <zyga> we MIGHT enable disable linger for root
[09:39] <zyga> but tests.session -u root restore does not do the same as it does for test user
[09:39] <zyga> so the protection is weaker
[09:39] <mborzecki> zyga: mhm, fwiw it needs to be run via sudo, otherwise that part of the test does not make sense
[09:40] <zyga> yeah, I understand
[09:52] <mvo> zyga: sorry for being pushy but a quick look at 8865 would be appreciated
[09:52] <zyga> sure
[09:53] <zyga> done
[09:53] <zyga> I think this is fine for now, we can look for how to support this better but it is not high priority
[09:54] <mvo> zyga: \o/
[09:55] <mup> PR snapd#8865 closed: workflow: test PR title as part of the static checks again <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8865>
[09:55] <mup> PR snapd#8876 closed: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8876>
[09:58] <mborzecki> yay
[10:14] <zyga> degville: hi
[10:17] <zyga> degville: I wasn't sure how to covey this otherwise
[10:17] <mborzecki> zyga: unexpected failure in the PR with sudo env: https://paste.ubuntu.com/p/85m38SNbGm/ idk if it's related though
[10:17] <zyga> there are three new pull requests that add interfaces
[10:17] <zyga> I "assigned" them to you to make sure you are at least aware
[10:17] <zyga> mborzecki: looking
[10:19] <zyga> mborzecki: interesting, let me try
[10:20] <degville> zyga: yes, I saw - and did a little +1 on your comments to let you know. I think it's a great idea and I'll make sure they're documented when they land.
[10:29] <zyga> mborzecki: checking some more
[10:39] <zyga> sigh
[10:42] <mborzecki> zyga: hm?
[10:45] <zyga> wifi range
[10:45] <zyga> I don't know what's in the walls here
[10:45] <zyga> but feels like tinfoiil
[10:51] <mborzecki> zyga: lots of reinforced concrete maybe?
[10:51] <zyga> I think so
[10:51] <zyga> so
[10:51] <zyga> I managed to get a debug shell
[10:51] <zyga> I started simple
[10:51] <zyga> tests.session -u prepare
[10:52] <zyga> then tests.session -u test exec id
[10:52] <zyga> then
[10:52] <zyga> tests.session -u test exec sudo id
[10:52] <zyga> so that all worked
[10:52] <zyga> I wonder if the OS matters, I picked xenial
[10:52] <zyga> I also tried sudo env
[10:52] <zyga> what was broken was sudo -l, right?
[10:53] <zyga> hmm
[10:53] <zyga> and that gave odd output
[10:53] <zyga> it just printed /usr/bin/id (I ran sudo -l id)
[10:53] <mborzecki> zyga: no it failed in a different test
[10:53] <mborzecki> zyga: but that sudo-env PR nonetheless
[10:53] <zyga> hmm?
[10:54] <zyga> can you remind me please
[10:54] <zyga> mborzecki: but sudo --login works
[10:54] <zyga> sudo -l doesn't
[10:54] <zyga> WTH?
[10:54] <mborzecki> zyga: thoght you're looking into https://paste.ubuntu.com/p/85m38SNbGm/ in the context of that sudo-env pr
[10:55] <mborzecki> zyga: sudo --login != sudo -d
[10:55] <mborzecki> pff -l
[10:55] <mborzecki> sudo --login == sudo -i :)
[10:55] <zyga> ah
[10:55] <zyga> stupid font
[10:55] <zyga> sorry!
[10:56] <zyga> I didn't notice
[10:57] <zyga> mborzecki: sorry, I was confused, i see what you mean now
[11:11] <mborzecki> we should land https://github.com/snapcore/snapd/pull/8761 once it's green
[11:11] <mup> PR #8761: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
[11:25] <mup> PR snapd#8877 opened: tests: move a few more tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8877>
[11:26] <pstolowski> pedronis: ^ i'll handle sequence tests separately
[11:27] <pedronis> pstolowski: yes, should probably wait until we have closed more PRs
[11:27] <pstolowski> 👍
[11:35] <zyga> Heh, debugged my x240 shutdown problem
[11:35] <zyga> There is a “emergency reset hole” on the bottom
[11:36] <zyga> Which instantly powers of the unit
[11:36] <zyga> With a physical button
[11:36] <zyga> Those tiny clicker type
[11:36] <zyga> Squeezing the unit close to the right hinge just puts enough pressure to press it
[11:37] <zyga> Let me see about that
[11:37] <zyga> And I didn’t invent the name https://support.lenovo.com/us/en/solutions/pd029569
[11:41] <zyga> i will be around shortly, my wife is removing that button
[11:51] <zyga> done
[11:51] <zyga> no more emergency reset hole
[11:51] <zyga> no more annoying shutdowns
[11:51] <zyga> just popped that button off the motherboard
[11:51] <zyga> sorry, mborzecki back to your review
[11:53] <mvo> second review for 8857 would be nice, should be an easy win, thanks to mborzecki  for the tweaks
[11:54] <zyga> mvo: in a moment
[11:56] <zyga> mvo: added a comment
[11:56] <zyga> but LGTm
[11:57] <zyga> back to https://github.com/snapcore/snapd/pull/7414
[11:57] <mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[12:09] <ijohnson> morning folks
[12:09] <ijohnson> in the interest of merging small PR's, could I get a review on https://github.com/snapcore/snapd/pull/8519 ?
[12:09] <mup> PR #8519: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8519>
[12:10] <ijohnson> the only test failure there is the current ongoing one about not being able to prepare uc20 systems due to failure to cleanup after snapd
[12:11] <zyga> mborzecki: added comments to 7414 that I think should be changed, I'll review the rest so please hold on :)
[12:14]  * zyga needs painkillers, brb
[12:16] <ijohnson> mvo: 8519 is ready for a sudo git merge and will take us back to the 60's (in terms of open PR's, time travel side effects are unknown)
[12:25] <pstolowski> hi ijohnson !
[12:26] <ijohnson> o/ pstolowski
[12:26] <ijohnson> I updated the install hook spread test PR btw
[12:26] <ijohnson> please have a look when you have a chance
[12:29] <pstolowski> +1
[12:41] <mup> PR snapd#7982 closed: o/snapstate, wrappers: enable services on start <Complex> <⛔ Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7982>
[12:50] <pedronis> pstolowski: I looked again at #8812, and I have a few more questions there
[12:50] <mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[12:54] <pstolowski> pedronis: ty
[12:56] <mup> PR snapd#8519 closed: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <⚠ Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8519>
[13:02] <mup> PR snapcraft#3169 closed: package-repositories: allow empty component list <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3169>
[13:06] <mup> PR snapd#8878 opened: tests: fix how gadget pc is detected when the snap does not exist and ls fails <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8878>
[13:11] <mborzecki> zyga: looks like deskto portal activation is failing quite consistently now in 18.04 https://github.com/snapcore/snapd/pull/8875/checks?check_run_id=776173782
[13:11] <mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[13:11] <zyga> mborzecki: looking
[13:13] <zyga> mborzecki: I think we should silence that line, it's just a fact that we kill dbus-monitor from awk when we see the stuff we care about
[13:13] <zyga> mborzecki: wonder how it didn't show up before
[13:18]  * zyga lunch
[13:41] <mup> PR snapd#7414 closed: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[13:41] <mup> PR snapd#8857 closed: tests/lib/prepare: increase the size of the uc16/uc18 partitions <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8857>
[13:46] <mup> PR snapd#8366 closed: cmd/snap-bootstrap/initramfs-mounts: verify the seed snap matches bootloader env <Needs Samuele review> <UC20> <⛔ Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8366>
[13:57] <mborzecki> mvo: shall we land https://github.com/snapcore/snapd/pull/8761 or do we need more input from jdstrand?
[13:57] <mup> PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
[14:01] <mup> PR snapd#8856 closed: [RFC] tests/main/install-fontconfig-cache-gen: for bionic, focal use broken font <Precious Logs> <Test Robustness> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8856>
[14:06] <jdstrand> mborzecki: fyi, I'd like jamesh to comment on https://github.com/snapcore/snapd/pull/8761#issuecomment-639674545 for the xdg-desktop-portal code since he was involved in PR 8269's review
[14:06] <mup> PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
[14:06] <mup> PR #8269: apparmor: use rw for uuidd request to default and remove from elsewhere <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8269>
[14:06] <jdstrand> mborzecki: but aside from that PR 8761 has a LGTM for allowedURLSchemes so it doesn't need to wait on me
[14:07] <mborzecki> jdstrand: got it
[14:07] <jdstrand> also, do we expect centos-8-64 to pass atm?
[14:08] <jdstrand> I keep mashing retry but that one doesn't seem to pass
[14:08] <ijohnson> jdstrand: I think centos 8 has some selinux problems right now
[14:08] <jdstrand> ok, I'll stop mashing retry then :)
[14:11] <mborzecki> jdstrand: there's some pending updates on centos, and the recent batch of package updates they pushed broke systemd/systemd-logind/selinux-policy
[14:12] <jdstrand> mborzecki: yikes
[14:12] <mborzecki> jdstrand: i hope that when cachio updates the image this may go away, but from what i could tell going through selinux policy and systemd it's bug
[14:13] <cachio> mborzecki,  when I update the image the test still fails
[14:13] <cachio> mborzecki, this is the error I see https://paste.ubuntu.com/p/Z9KRsbh7vG/
[14:14] <mborzecki> cachio: ok, let's push the image image then, and i'll try to make the test smarter
[14:14] <cachio> mborzecki, sure, thanks
[14:14] <mborzecki> cachio: thank you!
[14:16] <mborzecki> time to run some errands
[14:36] <cachio> mborzecki, image updated
[14:36] <ogra> zyga, hmm, cn layouts live in /run ?
[14:36] <ogra> File: /run/utmp (read)
[14:36] <ogra> Suggestions:
[14:36] <ogra> * adjust program to use $SNAP_DATA
[14:36] <ogra> * adjust program to use /run/shm/snap.$SNAP_NAME.*
[14:36] <ogra> * adjust program to use /run/snap.$SNAP_NAME.*
[14:36] <ogra> * adjust snap to use snap layouts (https://forum.snapcraft.io/t/snap-layouts/7207)
[14:37] <ogra> (i thought they could not)
[14:37] <zyga> no
[14:37] <ogra> then snappy-debug should perhaps not suggest it 🙂
[14:46] <pstolowski> pedronis: it seems you were somehow involved already in https://bugs.launchpad.net/snapd/+bug/1882665 ; do you know if the length restriction for snap name is ok on our side and will be fixed in the store?
[14:46] <mup> Bug #1882665: single-letter snaps are available in the store, but not installable <snapd:Triaged> <Snap Store:Confirmed> <https://launchpad.net/bugs/1882665>
[14:47] <pedronis> pstolowski: there's a conversation going on with the store about that
[14:49] <ijohnson> mvo: https://github.com/snapcore/snapd/pull/8866 is ready to be merged, but note that it failed on other tests in interesting ways so I have saved the logs in a pastebin
[14:49] <mup> PR #8866: tests/main: add spread test for running svc from install hook <Services ⚙> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8866>
[14:50] <ijohnson> mvo: specifically we got a little bit of info on what is left behind preparing uc20 sometimes insofar as there is still stuff in the /var/lib/snapd dir when purging the snapd deb
[14:51] <ijohnson> mvo: and your google:ubuntu-core-20-64:tests/core/snap-auto-mount changes seem to not have worked
[14:51] <ijohnson> mvo: it seems that the imported assertion was not trusted or was wrong? I'm not sure, the test failure output is quite unclear
[14:51] <ijohnson> mvo: the full log is in https://pastebin.ubuntu.com/p/NbKty2yd3k/
[14:53] <mvo> ijohnson: thank you, I have a look in a wee bit, in a meeting right now
[14:53] <ijohnson> ok, no rush
[15:01] <mvo> ijohnson: looking at the log now, strange that snap-auto-mount does not work - oh well
[15:01] <mup> PR snapd#8866 closed: tests/main: add spread test for running svc from install hook <Services ⚙> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8866>
[15:01] <mvo> ijohnson: woah, this is very confusing, the /var/lib/snapd is stull of stuff
[15:02] <ijohnson> mvo: yes I'm not sure how it's leftover tbh
[15:02] <mvo> ijohnson: yeah, that looks more like it was not run at all or something
[15:02] <ijohnson> unless somehow because the google-cloud-sdk snap is classic it breaks things ?
[15:03] <ijohnson> or possibly the lxd snap too because the lxd snap is effectively classic as well
[15:06] <mvo> ijohnson: yeah, I'm poking at it now
[15:09] <mvo> ijohnson: same failure in 8877 it seems, fun
[15:09] <ijohnson> mmm at least we can see some stuff now
[15:11] <mvo> ijohnson: yeah but we run the apt-get remove -y --purge snapd with quiet so we loose some information :(
[15:11] <ijohnson> oh yeah maybe we shouldn't do that ...
[15:11] <mup> PR snapd#8877 closed: tests: move a few more tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8877>
[15:12] <mvo> ijohnson: yeah, it looks like this is the next step
[15:31] <mup> PR snapd#8879 opened: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8879>
[15:47] <mup> PR snapd#8608 closed: configcore: issue a warning on core16 when journal.persistent option is set <Squash-merge> <⛔ Blocked> <Created by stolowski> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8608>
[15:47] <mup> PR snapd#8609 closed:  Adds missing paths to desktop, solves lp:1876804 <⛔ Blocked> <Created by sklei4> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8609>
[15:48]  * cachio lunch
[15:53] <mup> PR snapcraft#3171 opened: snap: debug enabled by default <do-not-merge> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3171>
[15:58] <pstolowski> cachio: #8558 has a conflict
[15:58] <mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
[16:07] <mup> PR snapd#8880 opened: tests/lib/prepare.sh: adjust comment about sgdisk <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8880>
[16:27] <mup> PR snapd#8878 closed: tests: fix how gadget pc is detected when the snap does not exist and ls fails <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8878>
[16:48] <mup> PR core18#155 opened: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <https://github.com/snapcore/core18/pull/155>
[16:51] <mup> PR core20#73 opened: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <https://github.com/snapcore/core20/pull/73>
[16:53] <mup> PR snapcraft#3172 opened: cli: restore --target-arch with warning for LXD and Multipass <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3172>
[16:54] <ijohnson> pedronis: #8794 is ready for re-review (I added the requested unit tests)
[16:54] <mup> PR #8794: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8794>
[16:57] <mup> PR snapd#8761 closed: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8761>
[16:57] <mup> PR snapd#8880 closed: tests/lib/prepare.sh: adjust comment about sgdisk <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8880>
[17:06] <mup> PR core20#74 opened: .travis.yml: use snapcraft w/ lxd to build the snap <Created by anonymouse64> <https://github.com/snapcore/core20/pull/74>
[17:47] <mup> PR snapd#8869 closed: asserts/internal: expand errors about invalid serialized grouping labels <Bulk assert refresh :scroll::scroll::scroll:> <Skip spread> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8869>
[18:02] <mup> PR snapd#8881 opened: interfaces: simplify rules of multiple connected iio plugs <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
[18:32] <Intelo> Hi
[18:32] <Intelo> I connected to vnc, all fine, firefox from console opens. I installed chromium-browser but when run, it says 'Client is not authorized to connect to server. Unable to open x display
[18:42] <mup> PR snapd#8576 closed: tests/main/lxd: add test for snaps inside nested lxd containers not working <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8576>
[19:05] <roadmr> hi jdstrand  :) we got a write request for system-files, for /run/lock. Is this covered by another interface maybe?
[19:07] <jdstrand> roadmr: no, but that is a directory. you wouldn't want to grant it for /run/lock, but rather for /run/lock/something /run/lock/somethingelse
[19:07] <jdstrand> roadmr: but really their snap should be updated to use SNAP_COMMON/lock or similar
[19:07] <mup> PR snapd#8875 closed: tests/main/sudo-env: check snap path under sudo <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
[19:08] <roadmr> jdstrand: right, I think the advice they themselves posted pointed in that direction
[19:08] <jdstrand> roadmr: of even better<EMAIL_ADDRESS>[19:08] <jdstrand> or*
[19:09] <roadmr> jdstrand: ok, I'll try to nudge them in that direction (it also suggested using layouts) and leave system-files as a last resort if they can point me to the specific files they need
[19:12] <jdstrand> roadmr: a layout won't work for /run
[19:12] <roadmr> ok, noted :( bummer heh
[19:13] <cachio> cmatsuoka, ijohnson thanks for the review on #8879, I already update the test
[19:13] <mup> PR #8879: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple 😃> <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8879>
[19:13] <jdstrand> roadmr: but they can use /run/snap.<snapname>.something all day every day :)
[19:13] <ijohnson> cachio: thanks I'll look again
[19:16] <cmatsuoka> cachio: thanks, checking again
[19:16] <cachio> ijohnson, just matching 0600 0000 01
[19:16] <ijohnson> cachio: why can't you match the whole pattern ?
[19:17] <cachio> ijohnson, I did it just to avoid to check too much
[19:17] <ijohnson> if there was garbage data for example xxd could output something like `0600 0000 0000 0600 0000 01` and the test would be wrong
[19:17] <cachio> not sure if the format could change
[19:17] <ijohnson> cachio: the correct format should not change it's in the UEFI spec IIRC
[19:17] <cachio> MATCH "00000000: 0600 0000 01\s+....."
[19:17] <cachio> ijohnson, that should be the correct one?
[19:17] <cachio> the match
[19:18] <ijohnson> cachio: yes that should be correct
[19:18] <cachio> ok
[19:19] <cachio> ijohnson, updated
[19:19] <ijohnson> thanks let me look again
[19:20] <cachio> ijohnson, thanks for checking
[19:20] <ijohnson> cachio: can you also specify the full SecureBoot variable name ?
[19:21] <cachio> ijohnson, is it fixed?
[19:21] <ijohnson> cachio: because there could be devices with random uefi firmware implementations that also define some kind of SecureBoot variable, but those will never be the same as SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
[19:21] <ijohnson> cachio: I really would like to see us be as specific as possible here
[19:22] <ijohnson> cachio: so instead of doing `SecureBoot-*` I think we should do `SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c`
[19:22] <cachio> ijohnson, sure
[19:22] <ijohnson> thank you
[19:23] <cachio> ijohnson, so the filename SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c is not gonna change right?
[19:23] <ijohnson> cachio: yes that name is part of the spec
[19:23] <cachio> ijohnson, ah, ok
[19:23] <cachio> in that case makes sense
[19:23] <cachio> thanks for the explanation
[19:24] <cmatsuoka> the uuid is the vendor uuid and in this case it's the EFI consortium or something like that
[19:24] <ijohnson> yes
[19:31] <cmatsuoka> cachio: I think there's an extra space in the middle of the file name now
[19:31] <cmatsuoka> SecureBoot-8be4df61-93ca-11d2 <space> -aa0d-00e098032b8c
[19:35] <roadmr> wow
[19:36] <cmatsuoka> cachio: please ignore the comment about the shell expansion
[19:39] <cachio> cmatsuoka, nice
[19:39] <cachio> I am wating for test results for the latest change yet
[19:40] <cmatsuoka> my mistake there, I tested the regexp using plain grep but then I noticed that MATCH uses grep -E
[19:40] <cmatsuoka> so the match didn't work in my first test
[19:41] <cmatsuoka> but with grep -E it's fine
[20:10] <pedronis> ijohnson: sorry about https://github.com/snapcore/snapd/pull/8340#discussion_r434490285 but basically my original comment/proposal wasn't possible, I probably misread some bit of the code and then the change applied was something else
[20:11] <mup> PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
[20:11] <ijohnson> pedronis: no worries
[20:11] <ijohnson> I mean with large PR's that are open for months there's bound to be back and forth
[20:11] <ijohnson> I'm almost done addressing feedback for that PR and will push up the changes in a little bit
[20:30] <ijohnson> pedronis: PR is updated if you're still around and want to look at it
[20:30]  * ijohnson small break
[20:33] <mup> PR snapd#8794 closed: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too <Test Robustness> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8794>
[20:33] <mup> PR snapd#8879 closed: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple 😃> <Skip spread> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8879>
[21:26] <cmatsuoka> ijohnson: when a new kernel snap is installed on arm, where do we trigger kernel extraction?
[21:28] <cmatsuoka> ijohnson: never mind, I just found it :)
[21:28] <mup> PR snapcraft#3173 opened: cli: use snap pack instead of mksquashfs <maintenance> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3173>
[22:24] <ijohnson> cmatsuoka: you found the ExtractKernelAssets functions?
[22:26] <ijohnson> Whoops
[22:27] <cmatsuoka> ijohnson: yes, I followed it to backend/setup
[22:27] <cmatsuoka> ijohnson: now I'm thinking how to get model information from there
[22:28] <cmatsuoka> but I'll continue tomorrow
[22:28]  * cmatsuoka EODs