[17:38] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/buildstatus-aborted/+merge/176990 does some more useful things with BuildStatus.ABORTED now, although it's also noticeably more complex.


[15:48] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Help Pick a New Logo for Fedora @ https://www.omgubuntu.co.uk/?p=137558 (by Joey Sneddon)
[16:19] -SwissBot:#ubuntu-news- ::Planet:: Jono Bacon: Video: 10 Avoidable Community Management Mistakes @ https://www.jonobacon.com/2019/01/10/video-10-avoidable-community-management-mistakes/
[19:21] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: And Then They Were Gone: GNOME Reverts Back to Brown for Folder Icons @ https://www.omgubuntu.co.uk/?p=137573 (by Joey Sneddon)
[21:34] -SwissBot:#ubuntu-news- ::Planet:: Ted Gould: Texas Linux Fest 2019 in Dallas @ https://gould.cx/ted/blog/2019/01/10/Texas-Linux-Fest-2019-in-Dallas/
[21:34] -SwissBot:#ubuntu-news- ::Planet:: Launchpad News: Git per-branch permissions @ http://blog.launchpad.net/code/git-per-branch-permissions
[22:00] -SwissBot:#ubuntu-news- ::Planet:: Podcast Ubuntu Portugal: S01E19 â Kernel novo procura-se! @ https://podcastubuntuportugal.org/2019/01/10/s01e19-kernel-novo-procura-se/
[22:00] -SwissBot:#ubuntu-news- ::Portugal:: S01E19 – Kernel novo procura-se! @ https://podcastubuntuportugal.org/2019/01/10/s01e19-kernel-novo-procura-se/


[04:24] <_mup_> ensemble/expose-hook-commands r244 committed by<EMAIL_ADDRESS>[04:24] <_mup_> Tests to verify communications between unit agent client and server for port hook commands
[04:31]  * niemeyer off!  Have a good weekend, and see you monday the latest! :-)
[18:22] <koolhead17> hi all


[15:46] <rsalveti> GrueMaster: can you please try the new x-loader at panda, using natty, and at beagle with maverick?
[15:47] <GrueMaster> Sure.  Is it in the pool?
[15:47] <rsalveti> GrueMaster: http://ppa.launchpad.net/rsalveti/armel/ubuntu/pool/main/x/x-loader/
[15:47] <rsalveti> GrueMaster: not yet
[15:47] <GrueMaster> Ok.  I'll pull it and give it a spin.
[15:48] <GrueMaster> As soon as I can get some coffee.  Eyes are still blurry.
[15:48] <rsalveti> x-loader-omap3-beagle_1.4.4+git20101223+6f3a261-1ubuntu1ppa2_armel.deb for beagle and x-loader-omap4-panda_1.4.4+git20101223+6f3a261-1ubuntu1ppa2_armel.deb for panda
[15:48] <rsalveti> I've being testing this with sebjan, and it seems to be ok, but just want to be sure :-)
[15:48] <rsalveti> GrueMaster: sure, np :-)
[15:49]  * rsalveti bbl
[15:49] <rsalveti> thanks
[16:34] <sebjan> rsalveti: I have trouble accessing gitorious right now (DNS issue). Is it only me?
[16:56] <eballetbo> sebjan: no, I've the same problem
[17:08] <rsalveti> sebjan: ouch, same dns issue
[17:16] <GrueMaster> works fine here.
[17:16] <rsalveti> GrueMaster: I get DNS service for this domain has expired with DNS Made Easy
[17:17] <GrueMaster> I am assuming you mean gitourious.org, right?
[17:17] <GrueMaster> oops.  Gitorious.org
[17:17] <rsalveti> http://gitorious.org/
[17:18] <GrueMaster> Oops.  I had tried ping.
[17:18] <GrueMaster> this is bad.
[17:19] <rsalveti> yeah
[17:19] <rsalveti> someone is going to get fired for that for sure hehe
[17:22] <GrueMaster> Well, it wasn't on my list of test stuff.
[21:14] <GrueMaster> rsalveti: Does the new xloader need a new u-boot as well?  I installed it after installing the new kernel, now it hangs.  Will try to get serial output.
[21:42] <GrueMaster> rsalveti: http://paste.ubuntu.com/547047/
[21:43] <rsalveti> GrueMaster: please update your kernel first
[21:43] <rsalveti> GrueMaster: you're not using the latest one available
[21:43] <rsalveti> I believe that will solve this issue
[21:44] <GrueMaster> Uh, it was updated.
[21:44] <GrueMaster> At least that was what was in the pool.
[21:47] <rsalveti> GrueMaster: iirc I requested the kernel team to push a new meta package yesterday
[21:47] <rsalveti> the new kernel was available for quite a while, but needed the meta update
[21:48] <GrueMaster> I updated both pandas simultaneously from the pool, but only updated one system with x-loader.  In looking at the working system, for some reason the new kernel never got installed on mmcblk0p1
[21:48] <GrueMaster> It is installed in /boot.
[21:50] <GrueMaster> Very odd.  The broken image didn't get the new kernel.  Both images are nearly identical.
[21:50] <GrueMaster> Oh, and gnome-panel is now broken.
[22:19] <GrueMaster> rsalveti: Ok, I got it booting.  Not sure why the kernel didn't get pulled down.  I updated both systems simultaneously this morning.


[08:04] <TAFB> can anyone help me get vnc working on my ubuntu vps?
[08:09] <mybalzitch> TAFB: https://www.homedepot.ca/en/home/p.timer-in-wall-4-hr-countdown.1000770177.html
[08:09] <mybalzitch> oops
[08:09] <mybalzitch> TAFB: https://help.ubuntu.com/community/VNC/Servers
[08:10] <mybalzitch> i suggest x11vnc
[08:10] <TAFB> mybalzitch: thanks, I'll give it a go. I installed x11vnc but it always says connection activly refused
[08:15] <TAFB> I followed the Vivid+ instructions, when I try and connected with tightvnc is says the target machine actively refused it :(
[08:16] <mybalzitch> OK
[08:16] <mybalzitch> do you have a firewall?
[08:16] <TAFB> on the vps? I don't think so.
[08:16] <mybalzitch> an/ythin/g show up in/ iptables -Lvn
[08:17] <TAFB> No chain/target/match by that name.
[08:17] <mybalzitch> oh
[08:17] <mybalzitch> iptables -L -v -n
[08:18] <TAFB> http://pastie.org/pastes/10739491/text
[08:18] <mybalzitch> ok thats good
[08:18] <mybalzitch> netstat -nap|pastebinit
[08:19] <TAFB> http://pastebin.com/kWutDYCm
[08:20] <mybalzitch> ok the service isn/'t run/n/in/g
[08:20] <mybalzitch> please try startin/g it
[08:20] <TAFB> systemctl start x11vnc.service
[08:20] <TAFB> ?
[08:21] <mybalzitch> I thin/k so
[08:21] <TAFB> done
[08:21] <mybalzitch> try n/ow?
[08:21] <TAFB> nope, same error, activly refused
[08:22] <mybalzitch> grrr
[08:22] <TAFB> if I had to guess I think x11vnc isn't starting
[08:22] <mybalzitch> yes
[08:24] <TAFB> any way to troubeshoot that?
[08:26] <TAFB> XOpenDisplay failed (:1)
[08:33] <TAFB> it says "Check if you have a ~/.Xauthority directory" ~/.Xauthority is a file, not a directory :(
[09:37] <lordievader> Good morning.
[10:49] <velusunivers-sys> hello is there any way to restrict root access from ssh to a certain ip address?
[10:50] <lordievader> Yes, set up key access and allow that key only to be used from a certain ip.
[10:50] <velusunivers-sys> how do i do that
[10:50] <velusunivers-sys> key as in ssh key?
[10:50] <lordievader> Preferable ssh as a user and use sudo to do root stuff.
[10:50] <lordievader> Preferably*
[10:51] <mybalzitch> don/'t allow root login/s rem;otely
[10:51] <lordievader> velusunivers-sys: Yes, ssh keys.
[10:51] <velusunivers-sys> i want to avoid ssh keys
[10:51] <lordievader> Why?
[10:52] <velusunivers-sys> because i have more than one system that will access them, and there is like 12 servers, i dont want to have 12 keys and hav to put them one like 5 computers and 3 tablets
[10:53] <velusunivers-sys> i just want to restrit root to one ip addess
[10:54] <lordievader> You can reuse keys? I have one to access most of my servers.
[10:54] <velusunivers-sys> but still thats means i would have to put it on 5 computers and on 3 tablets
[10:55] <lordievader> Puppet that stuff ;)
[10:55] <lordievader> Anyhow, if there are no other uses for ssh you could just firewall ssh access.
[10:56] <lordievader> http://www.unixlore.net/articles/five-minutes-to-even-more-secure-ssh.html
[10:56] <velusunivers-sys> ok so just fiewall it to one ip?
[10:56] <lordievader> That, or read the link I just posted.
[10:56] <velusunivers-sys> ok
[10:58] <shauno> another option is to use /etc/security/access.conf  (you'd need to uncomment pam_access.so in /etc/pam.d/sshd )
[10:58] <velusunivers-sys> ok
[10:59] <lordievader> As usual, there are many roads to Rome ;)
[10:59] <velusunivers-sys> but only one which is direct
[11:11] <velusunivers-sys> does caldav and carddav have to be on a ldap? can it be used with mysql?
[14:45] <NwS> Heya guys, would it be ok to use fail2ban on huge log files? 7-8gb size
[14:58] <bekks> NwS: fail to ban is not used on logfiles, it has a totally other purpose. Truncate and compress logfiles using logrotate.
[15:00] <NwS> bekks, I want to use it to ban bruteforce attacks on a few WP sites. So it will check out access_log of each website. Those logs are combined with webalizer and I can't logrotate them hmm
[15:00] <NwS> Unless I am doing something wrong :/
[15:01] <bekks> NwS: If you cannot logrotate them, you are using webalizer the wrong way.
[15:01] <bekks> NwS: webalizer can perfectly handle logrotated logs.
[15:01] <NwS> bekks, hmm fml. I didn't alter anything tbh I was just using webalizer and now I've got a few huge files
[15:02] <bekks> NwS: Yeah, the default config is useless :)
[15:02] <NwS> The rest logs are being logrotated
[15:03] <bekks> So configure your webalizer and logrotate your webserver logs.
[15:03] <NwS> Everything under /var/log works good, the ones I am talking about are under log/virtualmin
[15:03] <bekks> It doesnt matter where the logs are stored.
[15:03] <NwS> I mean they are supposed to logrotate
[15:04] <NwS> But everything under that folder doesn't
[15:04] <bekks> Then configure logrotate, too.
[15:08] <NwS> ty mate I'll look it up
[21:25] <Poindexter_> Is anyone here familiar with ircd-ircd2       ?
[21:26] <Poindexter_> It is actually ircd-irc2     sorry for the mistake.
[21:26] <Poindexter_> It is a Debian IRC server.
[21:27] <bekks> No, we are just meta question experts, and redirecting Debian server support to the the Debian support community.
[21:27] <Poindexter_> Hello again Bekks. Nice to see you again.
[21:27] <mybalzitch> Poindexter_: why not use something like inspircd?
[21:28] <JanC> or any of the 300 other irc servers?  ;)
[21:29] <bekks> Or even Ubuntu? :P
[21:29] <Poindexter_> Mybalzitch I never read about that. Freenode uses ircd-seven
[21:30] <Poindexter_> The server I installed works fine    I did a sudo apt-get install <server> works OK but ran into a crazy problem.
[21:31] <bekks> Poindexter_: And whats the Ubuntu relevance of your Debian server?
[21:31] <JanC> seems like ircd-irc2 is the IRCnet ircd
[21:32] <Poindexter_> Bekks, when logging into 192.168.***.***       the MOTD says it is a Debian based ircd.
[21:32] <RoyK> Poindexter_: perhaps #debian is the place to haunt
[21:32] <bekks> Poindexter_: Whats the relevance of your debian problem to Ubuntu?
[21:33] <bekks> Please seek debian support in #debian
[21:33] <mybalzitch> bekks: I'd hate to see him interrupt the endless waves of joins/parts with his questions :P
[21:33] <JanC> is it running on Debian or does it just say so?
[21:34] <mybalzitch> Poindexter_: you can edit the MOTD you know :)
[21:53] <bekks> So thats the confirmation of your rrefusal to provide information.
[21:54] <Poindexter_> Bekks, my mistake and I will say that I should have made a copy of the original file as a backup. I repent for that error. I should have known better.
[21:54] <bekks> Poindexter_: I dont care anymore.
[21:54] <bekks> You had 5 chances now. You missed them all. Please keep me out of that issue. Thanks.
[21:54] <Poindexter_> Bekks, I bid you a fine day. There is no isssue. It was just a simple oversight on my part not copying a text file. MOTD is nothing but a text file.
[21:54] <Poindexter_> It was a permissions issue.
[21:54] <bekks> Please do not hilight me any further.
[21:54] <Poindexter_> Calm down man. Don't take this so seriously. We are all trying to reach the same goal.
[21:54] <Poindexter_> Have a nice day folks. I bid all here peace.
[21:56] <mybalzitch> lol


[15:59] <larsks> smoser: I think there is a bug in how growpart calls partx, and now partx has better error checking and blows up (see https://bugzilla.redhat.com/show_bug.cgi?id=1327337)
[15:59] <larsks> I am going to submit a fix on launchpad.
[16:02] <smoser> larsks, so partx changed interface ?
[16:02] <smoser> oh. i see your last comment there.
[16:02] <larsks> I don't think so.  I think the previuos command invocation was actually incorrect, based on my reading of the man page (even for earlier versions).
[16:02] <larsks> I think it worked because of luck.
[16:02] <smoser> well, not complete luck
[16:03] <smoser> definitely it would have paid attention to the '1' in that call
[16:03] <larsks> The man page says either "partx disk" or "partx partition [disk]", neither of which is what growpart is doing.
[16:03] <smoser> previously, or growing growing a partition other than '1' would fail.
[16:04] <larsks> The examples in the man page suggest either "partx --update /dev/vda1" or "partix --update --nr 1 /dev/vda" would be correct
[16:04] <smoser> that is wierd. i agree.
[16:04] <smoser> but it definitely does work.
[16:04] <smoser> for lots of things
[16:04] <larsks> Oh yeah, totally :)
[16:10] <larsks> Heck, now I am extra confused...
[16:10] <larsks> ...because looking at the sources we appear to be calling $part $dev, which should be fine.  Ugh, maybe I misread some output somewhere?
[16:11]  * larsks puts on his paying-attention glasses and checks again.
[16:28] <larsks> smoser: okay, patch submitted in lp.
[16:31] <smoser> link ?
[16:31] <smoser> larsks, i'm *that* lazy
[16:32] <larsks> https://bugs.launchpad.net/cloud-utils/+bug/1587971
[16:32] <larsks> It's a...(counts)...5 character change.
[17:09] <harlowja> smoser merge that stuff today righththtttttt
[17:09] <harlowja> lol
[17:10] <harlowja> (not joking, ha)
[17:10] <smoser> harlowja, bzr+ssh://bazaar.launchpad.net/~smoser/cloud-init/trunk.fix-networking/
[17:10] <smoser> er..
[17:10] <smoser> https://code.launchpad.net/~smoser/cloud-init/trunk.fix-networking/
[17:10] <harlowja> whats that
[17:10] <smoser> that is what i'm working on
[17:10] <smoser> that has to et in
[17:10] <harlowja> u broke stuff
[17:10] <smoser> that fixes (soon) openstack config drive
[17:11] <harlowja> kk
[17:11] <harlowja> will look at
[17:20] <harlowja> whats up with the renaming code?
[17:21] <harlowja> does that run everytime cloud-init is ran?
[17:23] <harlowja> that's the only part that seems to concern me :-/
[17:23] <smoser> harlowja, yeah, i know. its scary
[17:23] <harlowja> didn't think that doing `ip set ` was a permeant  change
[17:24] <smoser> so yes. it runs every time.
[17:24] <harlowja> :-/
[17:24] <harlowja> scary
[17:24] <smoser> it has to because of 2 things
[17:25] <smoser> a.) initramfs is out of date with respect to /etc/systemd/network/*.link files
[17:25] <smoser>   this is the case in any fresh instance as the initramfs that booted is either pristine or out of date
[17:25] <smoser> b.) lxc container
[17:26] <harlowja> doesn't everyone use initramfs, i didn't think say centos did and such
[17:26] <smoser>   there are no udev events in a container, so the systemd .link files do not get applied
[17:26] <harlowja> *does everyone
[17:26] <smoser> i'd suspect most things use an initramfs.
[17:26] <harlowja> ah, just the normal initramfs, nothing special to cloudinit
[17:27] <smoser> its possible they do nto in cloud images (where you could feasibly have a 'virtual' kernel that had block device drivers built in for all targetted root devices
[17:27] <smoser> )
[17:27] <smoser> but even then, that means you can't boot with UUID=
[17:27] <smoser> or LABEL=
[17:27] <smoser> as its the initramfs that figures that part out
[17:27] <harlowja> gotcha
[17:27] <smoser> the reason that initramfs-out-of-date is a problem
[17:28] <smoser> is because systemd .link refuses to rename devices that have been renamed
[17:28] <harlowja> lol
[17:28] <smoser> and the initramfs will not have any rules and rename 'eth0' to 'en1p2' or whatever the default is
[17:28] <smoser> its kind of obnoxious really.
[17:28] <harlowja> ya, seems like it
[17:29] <smoser> smoser: please rename the device 'a' to 'b'
[17:29] <smoser> systemd: ok, that sounds great. device 'a' is now 'b'
[17:29] <smoser> smoser: please rename the device 'b' to 'c'
[17:29] <harlowja> no soup for u
[17:29] <harlowja> lol
[17:29] <smoser> systemd: sorry, smoser, you need to think ahead more or update your initramfs and reboot
[17:29] <harlowja> ya, that's stupid
[17:29] <harlowja> lol
[17:30] <smoser> harlowja, it wont run though if networking is disbled in cloud-init though
[17:30] <smoser> so if user wants cloud-init out of the picture, they can disable networking (via cloud-config) and get that.
[17:30] <smoser> on subsequent boots
[17:31] <harlowja> ya, weird stuff, lol
[17:34] <harlowja> i wonder if at some point we can just have the underlying system (sysconfig for example) have the right names in the first place
[17:35] <harlowja> cause from my understanding sysconfig files have a name 'DEVICE=X'  and `HWADDR` fields
[17:35] <harlowja> so whats the point of renaming stuff if those 2 are right (but maybe i not understand something here, ha)
[17:36] <harlowja> so in sysconfig land, is the renaming needed(?)
[17:38] <smoser> so the renaming is to support when the datasource declares the names
[17:38] <smoser> mgagne pointed out that in openstack currently they dont raelly declare the nic name.  (id actually is the host nic's name :)
[17:39] <harlowja> ya, good point, its crap like 'tap-blahblah' or ...
[17:39] <harlowja> not eth0 or ethX
[17:39] <smoser> but on other systems such as smartos and possibly in the future on openstack, the datasource (or even user) would like to declare the names for their nics
[17:39] <smoser> internal0
[17:39] <smoser> or
[17:39] <smoser> external0
[17:39] <smoser> to mean obviously useful things.
[17:40] <harlowja> ya
[17:40] <harlowja> is anyone in openstack (nova) land fixing the names of these things?
[17:40]  * harlowja not it
[17:40] <harlowja> lol
[17:41] <harlowja> to not have host nic junk names
[17:42] <smoser> its not bad, they're just 'ids'. which is fine. they could be uuids
[17:42] <smoser> but conceivably a user would quite possibly want to attach a nic to a system and provide the name that they'd like that thing to appear as.
[17:43] <harlowja> sure, i guess, i like mine called eth0-pink-bunny
[17:43] <harlowja> lol
[17:43] <mgagne> I'm planning on opening a bug/change for that bad behavior
[17:44] <harlowja> cool
[17:50] <harlowja> smoser  only think i can think of is to add more informational logging about what is about to be renamed (and not just the errors that may have resulted from the act of renaming/figuring out what to rename)
[17:50] <smoser> harlowja, yeah, i'm working on that.
[17:50] <harlowja> kk
[17:50] <smoser> it is even more fun now in container
[17:50] <smoser> than i thought
[17:50] <harlowja> :-/
[17:50] <smoser> https://github.com/lxc/lxd/issues/2063
[17:50] <harlowja> is smartos going to use cloudinit now?
[17:50] <smoser> you can't rename a nic that is up
[17:50] <harlowja> now there own cloudinit
[17:50] <harlowja> *not there own
[17:51] <smoser> ubuntu on smartos (guests) have cloud-init
[17:51] <harlowja> k
[17:51] <smoser> since you can't rename a nic that is up
[17:51] <smoser> and nics in containers *start* as up
[17:51] <harlowja> 'why is my network device 'up' when nothing in my init system has configured it so'
[17:51] <harlowja> lol
[17:52] <harlowja> well that shit be weird
[17:52] <smoser> so now i'm re-working that to allow for downing internfaces
[17:52] <harlowja> lol
[17:52] <mgagne> https://bugs.launchpad.net/nova/+bug/1588017
[17:52] <smoser> so it will be able to down it if it does not have any "real" addresses
[17:53] <smoser> mgagne, interesting...
[17:53] <harlowja> mgagne thx
[17:53] <smoser> from the guests perspective, it shoudl be physical always
[17:53] <mgagne> that's not what the spec mentions
[17:53] <mgagne> either we respect spec or we propose an amendment and wait for it to merge before changing implementation details
[17:54] <smoser> where do you see this ?
[17:54] <mgagne> in the spec...
[17:54] <smoser> i see only a single occurance of the word 'virtual'
[17:54] <smoser> at http://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html#rest-api-impact
[17:54] <mgagne> Example of VIF
[17:55] <mgagne> otherwise I don't know what the purpose of vif would be
[18:15] <harlowja> ya, only think i can think of is for ironic, but idk
[18:15] <harlowja> ironic though is different
[18:38] <harlowja> smoser  i guess otherwise, now that i understand that renaming stuff that fix looks ok
[18:38] <harlowja> i can work it into the refactor i had when u merge it
[21:43] <harlowja> smoser in '    def update_byname(bymac):
[21:43] <harlowja>         return {data['name']: data for data in bymac.values()}'
[21:43] <harlowja> that no worky on py26
[21:44] <harlowja> just fyi
[21:44] <harlowja> dict comprhension in 2.7+
[23:57] <smoser> harlowja, oh yeah, i forgot i had to care about py226
[23:57] <smoser> er.. even py26
[23:57] <harlowja> :-P


[02:48] <bashfulrobot> Is there a way to utilizr a bz2 file in the source directive?
[02:48] <bashfulrobot> utilize*
[02:50] <bashfulrobot> I'm working on a snap for restic in which the author prefers that the snap use the "official" binary (hope to change that later). But his releases come out as a bz2 file. When targeting the file I get an error stating that there is no handler for the bz2 file.
[02:51] <bashfulrobot> I'm in the middle of working on it - so was hoping for a quick ping type answer, otherwise I will move this over to the forum.
[02:51] <bashfulrobot> Thanks all.
[03:53] <Son_Goku> bashfulrobot: atm, there's no bz2 support in snapcraft, iirc
[03:53] <Son_Goku> debian doesn't generally encounter bz2 that much anymore, so I would guess they didn't think about it
[04:32] <bashfulrobot> Son_Goku: thanks for the info. I had pretty much came to that same answer. I guess I'll have to figure out the best way to maybe wget the file in the build, and extract, then just use `organize` to getit where it needs to go.
[06:07] <mborzecki> morning
[06:11] <Son_Goku> morning
[06:11]  * Son_Goku needs to sleep
[06:12] <Son_Goku> anyway, if anyone sees robert-ancell, can someone poke him about this? https://github.com/snapcore/snapd-glib/issues/32
[06:24] <zyga-ubuntu> o/
[06:25] <mborzecki> Son_Goku: zyga-ubuntu: morning guys
[06:27] <zyga-ubuntu> hey, good morning
[06:27] <zyga-ubuntu> uefi greeted me today with "ubuntu (disk not present)"
[06:27] <zyga-ubuntu> I think this is not a happy day
[06:29]  * zyga-ubuntu boots from usb and hopes the disk isn't dead yet
[06:32] <mborzecki> zyga-ubuntu: whad did you do? another dead disk?
[06:37] <zyga-ubuntu> mborzecki: no, just booted it again today
[06:37] <zyga-ubuntu> man, I'm not lucky
[06:37] <zyga-ubuntu> it shows up and mounts from live media
[06:38] <zyga-ubuntu> drive not present...
[06:38] <mborzecki> sounds like bad news
[06:39] <bashfulrobot> Hey guys (morning to those of you in Europte, etc)
[06:39] <bashfulrobot> I have a snap that I'm getting ready for snapcrafters.
[06:40] <bashfulrobot> It is going to need classic confinment as it is a backup program.
[06:41] <bashfulrobot> Going through the checklist it states "Convert the snap to `strict` confinement, or `classic` confinement if it qualifies". Is there some sort of qualifier process to allow a classic confiment for hte store?
[06:42] <bashfulrobot> And then a few lines down it states to move it into beta once it has been made either strict or classic. Do others generally just do locally testing in devmode nad hten call the comminuity in for review?
[06:42] <bashfulrobot> once in the beta channel?
[06:43]  * bashfulrobot getting sleepy - almost bed time.
[06:50] <zyga-ubuntu> bashfulrobot: hey
[06:50] <bashfulrobot> hello
[06:50] <zyga-ubuntu> bashfulrobot: you can request classic confinement on the forum (forum.snapcraft.io), there is a process to follow there
[06:51] <bashfulrobot> I'll search it up then.
[06:51] <zyga-ubuntu> bashfulrobot: if you can become a strictly confined snap it is much easier, obviously, but for a backup program it may be challenging, depending on the use-cases
[06:51] <zyga-ubuntu> bashfulrobot: you can test in classic mode as well, though devmode and classic are quite different
[06:51] <bashfulrobot> Well basically you need ot be able to backup any location on the file system
[06:52] <bashfulrobot> I was under the impression classic was the onbly way to do that
[06:52] <zyga-ubuntu> backup and restore, which is read and write anywhere
[06:52] <zyga-ubuntu> yes, I think so
[06:52] <bashfulrobot> exactly
[06:52] <zyga-ubuntu> you *can* do that in devmode
[06:52] <zyga-ubuntu> but it's more tricky
[06:52] <bashfulrobot> ok, I'm going to apply for classic then
[06:52] <zyga-ubuntu> and there's no interface for backup programs yet
[06:52] <bashfulrobot> ah ok.
[06:52] <zyga-ubuntu> sorry for brief answers, I think monday doesn't like me (my computer is not working)
[06:52] <bashfulrobot> hey - nooo worries
[06:53] <bashfulrobot> It's almost 11 pm Sunday for me... so my brain is giving up on me. :-)
[06:54] <zyga-ubuntu> "logical sector size is zero"
[06:54] <zyga-ubuntu> my ESP partition is broken
[06:54] <zyga-ubuntu> ok, that's it
[06:54] <zyga-ubuntu> I'm turning this machine off and I'll go and buy a new computer today
[06:54] <zyga-ubuntu> I'm so so so fed up with it
[06:54] <zyga-ubuntu> bashfulrobot: enjoy your evening and thank you for making snaps!
[06:56] <bashfulrobot> no worries! Last questoin - I see that the requests for classic seem to be in the store category. I'll put my request in there. Appreciate the direction!
[06:56] <bashfulrobot> zyga-ubuntu: hope the day gets better!
[06:58] <zyga-ubuntu> yes, the store category is right
[07:06] <zyga-ubuntu> good mornin mvo
[07:08] <mvo> hey zyga-ubuntu - good monring
[07:08] <mvo> morning even
[07:08] <mvo> zyga-ubuntu: shall we continue with this systemd shared unit today?
[07:08] <bashfulrobot> zyga-ubuntu: appreciate the help. Classic has been requested. Have a good day. I'm off to bed.
[07:09]  * bashfulrobot zzzzzzz
[07:12] <zyga-ubuntu> mvo: yes, let's do that; though please forgive me for being grumpy today as my computer has a broken ESP partition and I'm on the backup laptop without my work
[07:12] <zyga-ubuntu> mvo: I'm throwing the towel on my desktop today
[07:13] <mvo> zyga-ubuntu: "esp"?
[07:13] <mvo> zyga-ubuntu: sorry to hear that things are broken :(
[07:13] <zyga-ubuntu> mvo: the system boot partiotion on efi systems
[07:13] <mvo> zyga-ubuntu: ohhh, ok
[07:13] <zyga-ubuntu> my disks are failing on me :(
[07:14] <mvo> zyga-ubuntu: get ssds :P
[07:14] <zyga-ubuntu> I can boot the live media but I cannot boot the disk anymore
[07:14] <mvo> zyga-ubuntu: when they fail, they fail faaaaster
[07:14] <zyga-ubuntu> mvo: yeah, I'm considering just getting out and going to buy a new computer now
[07:14] <zyga-ubuntu> hahaha
[07:16] <mup> PR snapd#4558 opened: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4558>
[07:16] <mborzecki> mvo: morning
[07:17] <mborzecki> zyga-ubuntu: get intel ssds, they got crazy 5y warranty
[07:17] <mborzecki> already had 2 disks replaced under warranty :) not a single complaint
[07:18] <mvo> mborzecki: goooood morning
[07:20] <mborzecki> yocto segfault thing, i can reproduce it on 2.31 too
[07:21] <mborzecki> a simple fix that resolves/masks the problem is moving progress bar Finished() call in store dowload to happen after checking the errors
[07:21] <mborzecki> good run log with breadcrumbs; https://paste.ubuntu.com/26482312/
[07:22] <mborzecki> otherwise the crash looks like this: https://paste.ubuntu.com/26482304/
[07:22] <mborzecki> 2018/01/29 07:16:11.641340 progress.go:71: progress adapter--- &{task:0x967d8780 unlocked:true label:core total:8.0797696e+07 current:2.784677e+06}
[07:22] <mborzecki> 2018/01/29 07:16:11.641850 task.go:248: -- in task 0xb77006fc set progress, state 0xe3f
[07:24] <mborzecki> these 2 lines are interesting, the first one is pbar.Finished() in store.go, the second is a call to task.SetProgress() inside pbar.Finished()
[07:24] <mborzecki> somehow the pointer to the task changed from 0x967d8780 to 0xb77006fc
[07:25] <zyga-ubuntu> mborzecki: which golang is used on that yocto build?
[07:26] <mborzecki> 1.9
[07:26] <zyga-ubuntu> mborzecki: is it a compiler bug maybe?
[07:26] <zyga-ubuntu> mborzecki: any patches in ubuntu or debian or any patches in yocto that may be relevant?
[07:26] <mborzecki> update to 1.9.3 is on my list, but the interaction cycle is long
[07:27] <mborzecki> looked through commits between 1.9 and 1.9.3 nothing that looks relevant
[07:27] <zyga-ubuntu> mborzecki: do you think this is something in our code?
[07:27] <mborzecki> not sure yet
[07:28] <mborzecki> for instance, no clue why we try to do Kill() on the tomb twice, but the same sequence is visible in the 'good' run :/
[07:28] <mborzecki> albeit in the good run there's no call to pbar.Finished()
[07:29] <mvo> mborzecki: oh, doing the Kill twice sounds wrong, do you have more info?
[07:29] <mvo> mborzecki: also no call to Finish sounds wrong :(
[07:29] <mborzecki> mvo: take a look at the logs i posted
[07:30] <mborzecki> this is the diiff i'm working with: https://paste.ubuntu.com/26482348/
[07:32] <mborzecki> mvo: in taskrunner.Ensure() there's a call to tomb.Kill() for the running task
[07:33] <mborzecki> aiui that kill will trigger cancel on the context
[07:36] <mvo> mborzecki: interessting
[07:43] <mvo> mborzecki: I guess I'm stating the obvious, it looks like task.state is corrupted, might be interessting (no idea how painful it is to do one of those runs) to output the value of the task.state pointer to see when it becomes invalid
[07:45] <kalikiana> morning snappy
[07:46] <zyga-ubuntu> hey kalikiana
[07:46] <mborzecki> kalikiana: morning
[07:54] <mborzecki> zyga-ubuntu: mvo: forcing a static build of snapd makes the problem go away https://paste.ubuntu.com/26482426/
[07:56] <mvo> mborzecki: oh, this is also interessting. how dynmaic is the dynamic build? i.e. what is linked?
[07:57] <zyga-ubuntu> hmm ...
[08:01] <mborzecki> mvo: nothing special, libc and  libstd (that's go)
[08:01] <pstolowski> good morning!
[08:01] <mborzecki> pstolowski: morning
[08:03] <zyga-ubuntu> mborzecki: I wonder if that would fail if you used a ubuntu-build of snapd
[08:03] <mborzecki> btw. also according to the forum post the problem is only on x86, does not appear on x86-64
[08:03] <zyga-ubuntu> mborzecki: I read about some peculiar crash of golang when gentoo used new kernel optimization flag and broke the vsdo
[08:04] <mborzecki> i've tried rebuilding snapd locally, with same flags but no success
[08:04] <zyga-ubuntu> mborzecki: that was a golang bug, assuming too much about kernel behavior
[08:05] <mborzecki> i mean, GOARCH=386 GO386=387 CGO_ENABLED={0,1} all worked fine when deployed to the vm
[08:05] <mborzecki> hoped to use -race but it's 386 ;) so no race for me
[08:06] <zyga-ubuntu> mborzecki: can you try a i386 kernel from ubuntu there?
[08:06] <zyga-ubuntu> and see if the same binary of snapd tests wokrs
[08:06] <zyga-ubuntu> *works
[08:06] <zyga-ubuntu> just a long shot but somethig that could help bisect the area that is broken
[08:18] <mborzecki> zyga-ubuntu: can you take a look at #4558? this is an easy one
[08:18] <mup> PR #4558: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4558>
[08:18] <zyga-ubuntu> yep
[08:19] <zyga-ubuntu> mborzecki: you could use | there
[08:19] <zyga-ubuntu> to make it an ordering-only rule
[08:19] <zyga-ubuntu> mborzecki: just add a | before the new dependency
[08:19] <zyga-ubuntu> either way +1
[08:21] <mborzecki> yocto does out of the source builds by default, and this came up there :)
[08:22] <mborzecki> there's actually a separate class for packages that have broken separation
[09:03] <mborzecki> zyga-ubuntu: mvo: could you take another look at 4487?
[09:07] <mvo> mborzecki: sure
[09:08] <zyga-ubuntu> looking
[09:08] <mvo> mborzecki: heh, sorry that my suggestion to use "internal" error was wrong
[09:11] <mvo> mborzecki: looks good to me! zyga-ubuntu can merge once he finished (unless he has more suggestions of course)
[09:11] <mborzecki> mvo: thanks
[09:12] <zyga-ubuntu> yes, I'm just re-reading
[09:16] <zyga-ubuntu> mborzecki: done, have a look please
[09:16] <zyga-ubuntu> brrr, cold, let me make some more tea
[09:17] <mborzecki> zyga-ubuntu: thanks, good catch
[09:20] <zyga-ubuntu> mvo: I'm juming into lxd issue now
[09:20] <zyga-ubuntu> mvo: I don't have anything to do before 4471 lands
[09:21] <mvo> zyga-ubuntu: cool I'm working on xdg-settings final touches and then ~rc2
[09:21] <mvo> zyga-ubuntu: but let me know if I can do anything to help with that, happy to tweak the packaging
[09:21] <zyga-ubuntu> mvo: land 4471
[09:21] <mvo> zyga-ubuntu: but my feeling is right now the solution is not clear
[09:21] <zyga-ubuntu> I think we're wasting time now
[09:21] <zyga-ubuntu> it's blocking everything related to mount work
[09:22] <mvo> zyga-ubuntu: don't we need gustavo for this?
[09:22] <zyga-ubuntu> well, I am waiting
[09:22] <zyga-ubuntu> I'm just saying it's a bit unreasonable now
[09:23] <zyga-ubuntu> (that branch hasn't been touched in weeks)
[09:27]  * mvo nods
[09:38] <Chipaca> moin moin
[09:39] <zyga-ubuntu> ho ho
[09:39] <Chipaca> zyga-ubuntu: http://i.imgur.com/AAGJvD1.png
[09:40] <mvo> Chipaca: \o/ you made my morning
[09:40] <Chipaca> mvo: woo!
[09:40] <Chipaca> mvo: how tho :-)
[09:40] <mvo> Chipaca: the subway map
[09:41] <Chipaca> it's rather brilliant, isn't it
[09:41] <zyga-ubuntu> neat
[09:41] <mvo> Chipaca: oh yes
[09:41] <mvo> love it
[10:02]  * kalikiana going for a short walk, need a little fresh air
[10:04] <mup> PR snapd#4559 opened: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>
[10:04]  * ikey now unblocks solus sync. :p
[10:16] <zyga-ubuntu> ikey: <bring on the kraken!>
[10:16] <ikey> pretty much lol
[10:16] <ikey> we were gonna sync last night, but i couldnt get the snapd patch (above) working
[10:17] <ikey> turns out i was missing a comma -_-
[10:22] <ackk> mvo, hi, it seems base-18/edge is still missing the distro-info csv that the version you gave me a while ago has. any chance you could push that fix?
[10:23] <zyga-ubuntu> ikey: it's better to miss a comma than to miss the point
[10:24] <ikey> hah
[10:24]  * zyga-ubuntu gets back to being reasonable
[10:24] <niemeyer> zyga-ubuntu: I apologize for the delay. My #1 priority last week was to get our CI in good shape, as that unblocks and improves everybody's daily workflow.
[10:24] <niemeyer> zyga-ubuntu: This week I should get back to reviews and discussions
[10:24] <zyga-ubuntu> niemeyer: I understand that, no apologies needed; I think that code is critical enough to warrant the wait
[10:24] <zyga-ubuntu> niemeyer: I'm trying to get useful in other areas
[10:25] <zyga-ubuntu> niemeyer: and I think the new spread work is brilliant and we will benefit tremendously mid/long term
[10:25] <zyga-ubuntu> niemeyer: (and rest of canonical and anyone who uses it as well)
[10:25] <zyga-ubuntu> I always wished spread either did queueing or do dynamic allocation and now it does
[10:25] <niemeyer> zyga-ubuntu: I hope the benefit is immediate..
[10:26] <zyga-ubuntu> niemeyer: it is, I meant that it's not just short term benefit
[10:26] <niemeyer> zyga-ubuntu: The practical consequence is ~23 minutes runs, and no more limiting on the number of runs, so everybody gets more productive..
[10:26] <niemeyer> I postponed that for quite a while last year, but now it was getting a bit unreasonable..
[10:27] <zyga-ubuntu> and less issues hand holiding systems and re-starting failed tests due to overuse
[10:27] <niemeyer> Anyway, I hope that's now done
[10:27] <ikey> i dont understand how or why my PR failed
[10:28] <zyga-ubuntu> ikey: concurrent non-deterministic software that is connected to the internet has that property a lot
[10:28] <ikey> :D
[10:36]  * kalikiana re
[10:37] <zyga-ubuntu> ohh
[10:37]  * zyga-ubuntu has an insight
[10:38] <ikey> .ubuntu.com?
[10:38] <ikey> >_>
[10:39] <zyga-ubuntu> no, maybe a fix for the bug mvo and me were fighting for a long time
[10:39] <zyga-ubuntu> mvo: no double mounts!
[10:40] <mvo> zyga-ubuntu: tell me more!
[10:40] <zyga-ubuntu> mvo: hold on, just a teaser, let me do more experiments first
[10:43]  * zyga-ubuntu fiddles thumbs while package builds
[10:56] <mvo> if I could get a review for 4342 that would be great. its the last bit of polish I would like to get in for ~rc2
[11:03] <kalikiana> ikey: you drank some punny water this morning? :-P
[11:04] <ikey> perhaps. :p
[11:08] <zyga-ubuntu> mvo: still no double mounts, things look good so far, let me do some more and then try a spread run
[11:09] <mvo> zyga-ubuntu: what is the gist of the alternative idea?
[11:09] <mvo> zyga-ubuntu: I'm really curious
[11:09] <zyga-ubuntu> mvo: well, ... it's silly really
[11:09] <zyga-ubuntu> mvo: one char less than yours probably
[11:09] <mvo> zyga-ubuntu: hu?
[11:10] <mvo> zyga-ubuntu: was there a typo in my unit?
[11:10] <zyga-ubuntu> not really, I don't quite know if you got the double entries because of that
[11:10] <zyga-ubuntu> so so far so good, I'll try to cause the problem by doing what you initially did to confirm
[11:10] <mvo> zyga-ubuntu: so this is a mount unit, we still need all the scaffolding ? i.e. write out from snapd.postinst etc?
[11:10] <zyga-ubuntu> mvo: yes
[11:11] <mvo> zyga-ubuntu: ok - what does this one look like :) please, I'm really curious
[11:11] <zyga-ubuntu> mvo: hold on, one test will tell me if this makes sense,
[11:12] <zyga-ubuntu> hmmmmm
[11:12] <zyga-ubuntu> mvo: so, no double mounts but now I did what you did
[11:12] <zyga-ubuntu> unless lxd is doing something magic
[11:12] <zyga-ubuntu> ok, to be sure I'll just reboot
[11:12] <zyga-ubuntu> brb
[11:12] <zyga-ubuntu> mvo: sorry to keep you waiting, I don't want to say "got it" before it really works and I know *why*
[11:13] <mvo> zyga-ubuntu: no double mounts inside lxd? or no double mounts inside *and* outside of lxd?
[11:16] <zyga-ubuntu> mvo: so, let me check something, I'm on artful now, the container is xenial
[11:16] <zyga-ubuntu> mvo: I disabled reexec to test my build easily
[11:16] <zyga-ubuntu> mvo: (and it works so far)
[11:17] <zyga-ubuntu> mvo: did you do anything different?
[11:17] <zyga-ubuntu> mvo: I'll try to remove the package now, wonder if that will crash like it did before
[11:17] <zyga-ubuntu> but no double mounts, right sharing and snaps can be removed allright
[11:17] <zyga-ubuntu> so that counts as an improvement
[11:17] <zyga-ubuntu> now the last bit is packaging
[11:18] <mvo> zyga-ubuntu: no double mounts outside as well?
[11:20] <zyga-ubuntu> nope
[11:20] <zyga-ubuntu> mvo: actually, I didn't run many snaps and now I see that:
[11:20] <zyga-ubuntu> (though I doubt this is related, probably a bug)
[11:20] <zyga-ubuntu> ubuntu@experiments:~$ hello
[11:20] <zyga-ubuntu> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[11:21] <zyga-ubuntu> but I heard that there was a bug in lxd+apparmor about recently
[11:21]  * zyga-ubuntu looks at loaded profiles
[11:21] <zyga-ubuntu> ha
[11:21] <zyga-ubuntu> indeed
[11:21] <zyga-ubuntu> only snapd-managed profiles are active
[11:22] <zyga-ubuntu> we didn't load the profile for snap confine
[11:22] <zyga-ubuntu> mvo: that's a separate bug manifested if you disable re-exec
[11:22] <zyga-ubuntu> Jan 29 11:15:49 experiments apparmor[85]:  * Not starting AppArmor in container
[11:22] <zyga-ubuntu> Jan 29 11:15:49 experiments apparmor[85]:    ...done.
[11:22] <zyga-ubuntu> jdstrand, stgraber: ^
[11:23] <zyga-ubuntu> is this reported or am I dreaming things?
[11:23] <zyga-ubuntu> mvo: once I load snap-confine's profile manually things are ok
[11:23] <zyga-ubuntu> mvo: also inside process namespace
[11:24] <zyga-ubuntu> mvo: ok, let me get back and make this into a proper patch I can share with you
[11:24] <zyga-ubuntu> mvo: and see if I can run the test I wrote a while back against it
[11:24] <zyga-ubuntu> jdstrand, stgraber: this is with apparmor 2.10.95-0ubuntu2.7
[11:27] <zyga-ubuntu> mvo: this still makes little sense to me, it works but the difference between your branch seems meaningless
[11:33] <zyga-ubuntu> hmmm
[11:33] <zyga-ubuntu> mvo: wow, it even removed the package allright
[11:33]  * zyga-ubuntu is so confused now
[11:33] <zyga-ubuntu> mvo: it only printed tihs
[11:33] <zyga-ubuntu> dpkg: warning: while removing snapd, unable to remove directory '/snap': Device or resource busy - directory may be a mount point?
[11:34] <zyga-ubuntu> and purged cleanly
[11:34] <zyga-ubuntu> :-))
[11:34]  * zyga-ubuntu has a happy monday now
[11:34] <ikey> zyga-ubuntu, https://www.youtube.com/watch?v=SsmVgoXDq2w :)
[11:35] <mvo> zyga-ubuntu: did it actually stop your mount unit?
[11:35] <mvo> zyga-ubuntu: it sounds a bit dubious :)
[11:36] <mvo> zyga-ubuntu: but I'm keen to see your PR
[11:36] <zyga-ubuntu> mvo: yes
[11:36] <mvo> zyga-ubuntu: woah, ok
[11:36] <zyga-ubuntu> mvo: it's totally clean
[11:36] <zyga-ubuntu> mvo: it's so weird
[11:36] <mvo> zyga-ubuntu: looking forward to the diff
[11:36] <mvo> zyga-ubuntu: I have a small test in my PR that will be fun to test against
[11:36] <mvo> zyga-ubuntu: by all means, if we have a solution and I will sing and dance and hug you :)
[11:41] <zyga-ubuntu> me too :)
[11:42] <zyga-ubuntu> I'll build another package that doesn't involve any hand-holding anymore
[11:42] <zyga-ubuntu> and re-test
[11:42] <zyga-ubuntu> and then send a PR
[11:42] <zyga-ubuntu> and then find and cherry pick those tests we wrote
[11:42] <ogra_> you're so unromantic !
[11:42] <zyga-ubuntu> ogra_: ?
 I'll build another package that doesn't involve any hand-holding anymore
[11:43] <zyga-ubuntu> but first, my tea has run out
[11:43] <zyga-ubuntu> mvo: btw I have t otell you
[11:43] <zyga-ubuntu> haha
[11:43] <ikey> banning hand holding, and we're coming up to the 14th soon enough
[11:43] <ikey> sheesh
[11:43] <zyga-ubuntu> ogra_: but there will be hugging instead
[11:43] <ogra_> ah !
[11:43] <zyga-ubuntu> mvo: my favourite tea is in stock again, it is called ...
[11:43] <ogra_> thats an improvement then :)
[11:43] <zyga-ubuntu> sir adalbert's tea, soursop green tea
[11:44] <zyga-ubuntu> it has a big elephan on a decorative green box, not sure if you know it
[11:44] <mvo> zyga-ubuntu: I don't let me search for it
[11:45] <mvo> zyga-ubuntu: the downside of not sharing an office, I would love to try it :)
[11:45] <zyga-ubuntu> it's awesome, I can bring you a bag next time we meet
[11:48] <zyga-ubuntu> mvo: the trick is that fruit they added, soursop
[11:49] <zyga-ubuntu> maybe if you like traditional tea it's "meh flavoured" but there's something really tasty about it
[11:49] <mvo> zyga-ubuntu: I'm a bit of a traditionalist :) but also open so I'm certainly curious
[11:49] <mvo> zyga-ubuntu: *cough* diff *cough* ;)
[11:50] <mvo> zyga-ubuntu: else I'm gone for lunch and will be curious all the time
[11:51] <zyga-ubuntu> mvo: here it is
[11:51] <zyga-ubuntu> https://github.com/zyga/snapd/tree/fix/fix-snap-share-v3
[11:51] <zyga-ubuntu> don't open PR yet please, I didn't touch packaging
[11:52] <zyga-ubuntu> mvo: if you build that and run it, does it show duplicates or misbehaves for you?
[11:52] <zyga-ubuntu> I'll proceed with proper tests now
[11:53] <mvo> zyga-ubuntu: heh
[11:53] <mvo> zyga-ubuntu: ConditionVirtualization=lxc
[11:53] <zyga-ubuntu> that's just making it easy to ship
[11:53] <mvo> zyga-ubuntu: I was thinking something like this this morning, if we should make it conditional
[11:53] <mvo> zyga-ubuntu: and it works fine inside?
[11:53] <zyga-ubuntu> yes
[11:53] <zyga-ubuntu> just try it
[11:53] <mvo> zyga-ubuntu: awesome
[11:53] <zyga-ubuntu> I'll fix packaging and get that spread test that tried it merged
[11:53] <zyga-ubuntu> mvo: note
[11:53] <zyga-ubuntu> mvo: the conditional part is irrelevant
[11:53] <mvo> zyga-ubuntu: thank you
[11:54] <mvo> zyga-ubuntu: hu? how so?
[11:54] <zyga-ubuntu> mvo: there's no difference from what you wrote
[11:54] <zyga-ubuntu> mvo: (your unit was started the same way in the end)
[11:54] <zyga-ubuntu> mvo: I really don't know why this works yet
[11:54] <mvo> zyga-ubuntu: it was, but mine ran on classic as well
[11:54] <zyga-ubuntu> mvo: I used a different wants
[11:54] <zyga-ubuntu> ahhhhh
[11:54] <mvo> zyga-ubuntu: and caused all sorts of problems there
[11:54] <zyga-ubuntu> oh, that's it then
[11:54] <mvo> zyga-ubuntu: yeah, thats it :)
[11:54] <zyga-ubuntu> on classic it's not sane
[11:54] <zyga-ubuntu> heh
[11:54] <mvo> zyga-ubuntu: (I think at least)
[11:54] <zyga-ubuntu> sounds like a good day then :)
[11:54] <mvo> zyga-ubuntu: very nice, thank you!
[11:54] <zyga-ubuntu> ok, let me finish the polish on this
[11:55] <mvo> zyga-ubuntu: good luck, I get dinner now
[11:55] <zyga-ubuntu> enjoy!
[12:04] <ackk> mvo, should I file a bug about that missing file?
[12:05] <zyga-ubuntu> spread running
[12:05] <zyga-ubuntu> kyrofa: IT'S HAPPENING
[12:08]  * zyga-ubuntu thinks about lunch
[12:08] <mup> PR snapd#4560 opened: many: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>
[12:12]  * pstolowski lunch
[12:22] <zyga-ubuntu> hmmm
[12:22] <zyga-ubuntu> - Download snap "lxd" (5522) from channel "stable" (sha3-384 mismatch for "lxd": got 3ed1910ba0d678da4820c74e35f288db4feb6dcad637466ab6c2bee26fca363b1cdb42e6b81e3f4fb834b672c64457c2 but expected 05ca4d0b5cd936beff0323dd786f2787fdf1783fbb7ffb89c09143c49a6e2269aca4a76e12d34422ea59826129f6009f)
[12:22] <zyga-ubuntu> Chipaca: ^
[12:22] <zyga-ubuntu> is this store being funky or do I have a bad day?
[12:25] <sitter> is there a way to switch all of snapd to a different default channel? (e.g. install all future snaps and refresh all existing everything from edge)
[12:25] <mborzecki> zyga-ubuntu: mvo: disabling optimizations and inlining resolves the problem
[12:32] <zyga-ubuntu> sitter: no, not at present
[12:40] <zyga-ubuntu> mvo: things passed in my spread
[12:40] <zyga-ubuntu> mvo: I think it's a winner, let' see how the PR fares
[12:52] <Chipaca> I got called out of physio to go pick up one of the boys who's being sick all over school (apparently)
[12:52] <Chipaca> will miss the standup
[12:52] <Chipaca> ttfn
[12:53] <zyga-ubuntu> mvo: 4560 is ready for review
[12:54] <zyga-ubuntu> brb, see you at the call
[12:56] <zyga-ubuntu> ls
[12:58] <zyga-ubuntu> mvo: that pr needs one more patch, to give the mount unit the right name (following snap mount dir)
[12:58] <zyga-ubuntu> I'll do that
[13:00] <mvo> zyga-ubuntu: ok
[13:28]  * kalikiana going for lunch break in a few minutes
[13:33] <mup> PR snapd#4561 opened: tests: generic detection of gadget and kernel snaps <Created by plars> <https://github.com/snapcore/snapd/pull/4561>
[13:52]  * kalikiana off for lunch now
[13:52] <pstolowski> mvo, hey, any specific reason why we abandoned these build stamp / system key branches?
[13:54] <cachio> mvo, hey
[14:04] <mvo> hey cachio
[14:04] <mvo> pstolowski: no specific reason, happy to pick them up again and/or work with you on them. the main issue was that we had too many open PRs and a lack of reviewers so I closed to postpone
[14:04] <cachio> mvo, is the rc2 comming today?
[14:05] <mvo> cachio: thats my goal, however I need a review for the xdg-settings UI branch
[14:06] <mvo> cachio: https://github.com/snapcore/snapd/pull/4342
[14:06] <mup> PR #4342: userd: add support for a simple UI that can be used from userd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4342>
[14:07] <cachio> mvo, good, I'll take a look
[14:08] <cachio> mvo, I am also working on the test i18n which is failing on master for debian 9 and trusty
[14:13] <pstolowski> mvo, i see. okay, it seems like a requirement now
[14:14] <mvo> cachio: thank you
[14:15] <mvo> pstolowski: yeah, let me finish my current task, then I can merge master and see how bad the conflicts are :)
[14:15] <mvo> pstolowski: there is also a forum discussion - have you seen that one?
[14:17] <pstolowski> mvo, not yet, but I think it's linked in one of the PRs
[14:18] <zyga-ubuntu> mvo: another random failure
[14:18] <zyga-ubuntu> (on lxd / 4560)
[14:18] <zyga-ubuntu> I re-started
[14:18] <kenvandine> mvo, has the ship sailed for 2.31 yet?
[14:18] <zyga-ubuntu> timeout
[14:19] <zyga-ubuntu> kenvandine: no, just initial RCs
[14:19] <kenvandine> great
[14:19]  * zyga-ubuntu goes to cook some lunch and then gets back to mount magic
[14:19] <kenvandine> i thought jamesh's per-user mounts PR would be included
[14:19] <kenvandine> any chance of that?
[14:19] <zyga-ubuntu> kenvandine: that's possible but unlikely
[14:19] <kenvandine> :(
[14:19] <zyga-ubuntu> kenvandine: and even if so it won't be "live"
[14:19] <zyga-ubuntu> kenvandine: it will only be useful once we have interfaces using that
[14:19] <kenvandine> yeah
[14:19] <zyga-ubuntu> kenvandine: I asked jdstrand to review it
[14:20] <kenvandine> can we get a milestone set on the PR?
[14:20] <zyga-ubuntu> kenvandine: and I will jump onto it soon as now (just this minute) I have my review on my only pending work
[14:20] <zyga-ubuntu> kenvandine: no, I think it's premature
[14:20] <zyga-ubuntu> kenvandine: there are things to do there and it's not something that benefits users yet
[14:20] <kenvandine> yeah, but we need it in place for other things that we need for 18.04
[14:20] <zyga-ubuntu> kenvandine: as it will only be used by interfaces and it's not yet, so I can merge it now and it's not changing anything yet
[14:21] <kenvandine> quickly running out of time
[14:21] <kenvandine> yeah
[14:21] <zyga-ubuntu> kenvandine: sure but that's not related to merging
[14:21] <zyga-ubuntu> kenvandine: development, sure
[14:21] <kenvandine> but i'd like to get that stuff in for 2.32
[14:21] <zyga-ubuntu> kenvandine: I will work on that branch (and related branches) this week for sure
[14:21] <zyga-ubuntu> kenvandine: it's aggressive but we'll see what needs to be done
[14:21] <kenvandine> i'll talk to james as well, but I think he's already working on stuff that depends on it
[14:22] <zyga-ubuntu> kenvandine: yes, I'm in contact with james
[14:22] <zyga-ubuntu> kenvandine: and we discussed it (james and me) with niemeyer
[14:23] <mvo> kenvandine: for what? session startup?
[14:23] <kenvandine> freeze is march 1, so we'd really like to land his desktop portal work before then
[14:23] <kenvandine> mvo, this is for portals
[14:23] <mvo> okay
[14:23]  * mvo reads backlog
[14:24] <kenvandine> i'm just trying to make sure all the pieces we need fall into place before feature freeze
[14:24] <kenvandine> or soon after if we can get a freeze exception
[14:24] <zyga-ubuntu> kenvandine: understood
[14:24] <zyga-ubuntu> kenvandine: are those on halt now?
[14:24] <zyga-ubuntu> or can they be deveoped while this gets ready?
[14:24] <kenvandine> but we really don't want an LTS release to pass without the portal work
[14:24] <kenvandine> they can still be worked on
[14:25] <kenvandine> it's just over a month away though, so i'm getting stressed :)
[14:25] <zyga-ubuntu> niemeyer: ^ FYI
[14:25] <kenvandine> we can still fix bugs in anything related after of course
[14:26] <kenvandine> but we prefer not to beg for freeze exceptions for features :)
[14:26] <kenvandine> which are harder to get for an LTS
[14:27] <ackk> what's the $PWD a "daemon: simple" app is run from? is it $SNAP?
[14:28] <zyga-ubuntu> ackk: I think it could be /root but ... I forgot, sorry
[14:29]  * zyga-ubuntu -> kitchen
[14:33] <ackk> a "command: bin/mybinary" works so I had thought it was $$NAP
[14:34] <zyga-ubuntu> ackk: no, those are reslved and that doesn't matter
[14:35] <ackk> ah I see
[14:35] <zyga-ubuntu> ackk: those would work regardless of working directory
[14:35] <ackk> zyga-ubuntu, so if snap run --shell gives you the same env I guess it's /root
[14:37] <zyga-ubuntu> ackk: ok, that's good then
[14:37] <zyga-ubuntu> we tried to be consistent
[14:37] <zyga-ubuntu> but for services we wanted to be a bit special
[14:37] <zyga-ubuntu> HOME depends on user
[14:38] <zyga-ubuntu> anyway,
[14:38] <zyga-ubuntu> lunch is ready now
[14:40] <kalikiana> re
[14:40] <ikey> $HOME is where the <3 is
[14:40]  * ikey ducks
[14:40] <kalikiana> zyga-ubuntu: but are you ready for it? ;-)
[14:41] <kalikiana> ikey: me $HOME es su $HOME
[14:41] <ikey> d'aww
[14:41] <ikey> lol
[14:41] <kalikiana> that shoul've been "mi...", my Spanish spelling is terrible
[14:44] <zyga-ubuntu> HOME is when you don't have to change your namespace
[14:44]  * zyga-ubuntu gets back to lunch
[14:58] <cachio> mvo, how should I make to reproduce the scenario with the ui for xdg-settings?
[14:58] <cachio> mvo, I would like to manually test it
[14:59] <cachio> mvo, is there any snap that I could use?
[14:59] <zyga-ubuntu> mvo: man
[14:59] <zyga-ubuntu> luck hates me today
[14:59] <zyga-ubuntu> /dev/stdin: line 2: `<head><title>504 Gateway Time-out</title></head>
[14:59] <zyga-ubuntu> maybe you can hit the restart button
[15:05] <mup> PR snapcraft#1889 opened: tests: remove plainbox part from plugin tests <Created by jocave> <https://github.com/snapcore/snapcraft/pull/1889>
[15:11] <mvo> cachio: sorry for the delay. you can run "$ go build && ./snap userd" and then install the brave snap
[15:11] <mvo> cachio: and brave will ask you
[15:11] <mvo> cachio: to make itself default browser
[15:12] <cachio> mvo, great, tx
[15:12] <mvo> cachio: you may need to killall snap first if there is one already running in your session
[15:16] <cachio> mvo, ok
[15:16] <jdstrand> kenvandine: you do realize that you got the review of that PR preempted by another PR, right? ;)
[15:16] <jdstrand> I guess now that the reprioritized one is done, it is time to have the other one preempt things :P
[15:17] <jdstrand> anyway, it is on the list. it isn't for 2.31 at this point, so I put it behind the steam one for the moment, but I'll get to it soon
[15:18]  * jdstrand notes that he will be at the snapcraft sprint this week so will likely not get to everything this week
[15:18] <zyga-ubuntu> jdstrand: o/
[15:19] <zyga-ubuntu> jdstrand: did you notice my earlier ping about an apparmor bug in apparmor inside lxdd?
[15:20] <niemeyer> zyga-ubuntu, kenvandine: What are the dependencies for the user mount PR?
[15:20] <zyga-ubuntu> niemeyer: I want jdstrand's ack on it, then we merge and iterate on small chunks
[15:21] <zyga-ubuntu> niemeyer: on specific points to iterate on: maybe handling /media, handling root user, handling updates, etc
[15:21] <jdstrand> I started to look at that pr on friday, but it is massive
[15:21] <niemeyer> Yeah, that's not a good thing
[15:21] <jdstrand> (in terms of interelated changes)
[15:22] <mborzecki> hmm yocto uses `-linkshared ink against installed Go shared libraries (experimental).`
[15:23] <mborzecki> taking snapd and linux_386_dynlink/libstd.so to artful i386 i can reproduce the segfault
[15:24] <mborzecki> the address that ends up replacing task pointer is within a region like:
[15:24] <mborzecki> b770f000-b7753000 rw-p 012cc000 fd:00 1371       /usr/lib/go/pkg/linux_386_dynlink/libstd.so
[15:24] <jdstrand> zyga-ubuntu: I saw your comment re lxd. it sounds like the thing that I mentioned last week and alerted mvo to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1744738/comments/2
[15:24] <mup> Bug #1744738: snapd <IP_ADDRESS> ADT test tests/main/lxd failure with linux-hwe 4.13.0-30.33~16.04.1 <snapd (Ubuntu):New> <https://launchpad.net/bugs/1744738>
[15:25] <mup> PR snapd#4562 opened: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>
[15:25] <jdstrand> zyga-ubuntu: ie https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34. my understanding is that jjohansen sent up a pr for the hwe kernel
[15:25] <jdstrand> zyga-ubuntu: is what you're seeing on an hwe kernel?
[15:32] <zyga-ubuntu> jdstrand: I saw this on artful kernel
[15:33] <zyga-ubuntu> jdstrand: with xenial userspace
[15:33] <jdstrand> zyga-ubuntu: that is essentially the same thing, yes. the hwe kernel is 4.13, like artful
[15:34] <jdstrand> zyga-ubuntu: it should just naturally fix itself once the patch makes it into the Ubuntu kernel
[15:36] <jdstrand> zyga-ubuntu: that said, I don't have the timing of this work. jj is traveling. tyhicks, do you happen to have details on the 4.13 kernel fix for apparmor profiles not loading inside lxd containers?
[15:39] <zyga-ubuntu> jdstrand: ack, thank you!
[15:44] <kenvandine> jdstrand, indeed, totally understand
[15:45] <kenvandine> jdstrand, just getting things lined up so we have no surprises as feature freeze approaches
[15:48] <mvo> zyga-ubuntu: I added some comments on 4560, would be awesome to have for 2.31
[15:49] <mvo> zyga-ubuntu: do we need jamie for 4559?
[15:50] <mvo> can someone please review 4342? it soft blocks 2.31~rc2
[15:51] <zyga-ubuntu> mvo: I saw, thanks
[15:52] <tyhicks> jdstrand: no, I'm not sure how far along the 4.13 kernel fix is
[15:52] <jdstrand> kenvandine: note that snapd is not bound by feature freeze
[15:52] <jdstrand> kenvandine: I'm not sure if the portals side is, but a ffe would certainly be possible
[15:53] <kenvandine> jdstrand, exactly... but the portal work is
[15:53] <kenvandine> yeah, possible
[15:53] <zyga-ubuntu> kenvandine: is the portal work something that is ubuntu specific
[15:53] <jdstrand> and I think that the portals side could continue without it
[15:53] <kenvandine> jdstrand, just trying to plan ahead :)
[15:53] <zyga-ubuntu> kenvandine: we also have to have portals and snaps work on fedora and debian and opensuse and elsewhere
[15:53] <kenvandine> zyga-ubuntu, we're doing it with upstream
[15:53] <jdstrand> kenvandine: sure, I understand. it it just more of the 'everything it critical priority, so nothing is' syndrome
[15:53] <kenvandine> but it's enabling snaps
[15:53] <zyga-ubuntu> kenvandine: there are no freezes upstream!
[15:54] <kenvandine> zyga-ubuntu, but to get it in ubuntu :)
[15:54] <zyga-ubuntu> (kudos to upstream work)
[15:54] <kenvandine> thx
[15:57] <mup> PR snapd#4517 closed: data: add systemd unit that unshares /snap <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4517>
[15:58] <zyga-ubuntu> mvo: yes
[15:58] <zyga-ubuntu> jdstrand: low hanging fruit on https://github.com/snapcore/snapd/pull/4559
[15:58] <mup> PR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>
[15:58] <zyga-ubuntu> literally one line of lstat of unlink to review
[15:58] <mborzecki> disablink -linkshared makes the segfault problem go away
[15:58]  * zyga-ubuntu feels ... sleepy... must coffee
[15:59] <mborzecki> everything else is enabled
[16:00] <zyga-ubuntu> mborzecki: that's something mwhudson may want to know
[16:00] <zyga-ubuntu> he likely wrote it
[16:00] <zyga-ubuntu> niemeyer: please look at https://travis-ci.org/snapcore/snapd/builds/334699893?utm_source=github_status&utm_medium=notification
[16:00] <zyga-ubuntu> niemeyer: linode hicckup
[16:00] <zyga-ubuntu> niemeyer: returning HTML on api request
[16:00] <zyga-ubuntu> Our development team has been alerted to this error.  If you continue to have problems please contact support:
[16:01] <zyga-ubuntu> eee
[16:01] <zyga-ubuntu> gee
[16:01] <zyga-ubuntu> they could _at least_ return that in a RPC response
[16:01] <ackk> mvo hi, around?
[16:01] <mvo> ackk: yes
[16:01] <zyga-ubuntu> with X-Linode-Coupon-Code: header
[16:02] <ackk> mvo any chance you could push the changes to include the distro-info csvs in base-18/edge ?
[16:02] <cachio> mvo, when I set the default browser on brave, then I open a url, it is opened on chrome
[16:03] <niemeyer> zyga-ubuntu: Thanks, this is the issue I mentioned earlier..
[16:03] <niemeyer> zyga-ubuntu: Shouldn't affect the run
[16:03] <mborzecki> haha once linshared is disabled even remote gdb magically started to work
[16:03] <niemeyer> But needs fixing as the machines stay around
[16:04] <mvo> ackk: yes, its tiny, let me add it
[16:04] <mvo> cachio: oh? what do you get with "xdg-settings get default-web-browser" ?
[16:05] <cachio> google-chrome.desktop
[16:05] <cachio> mvo,
[16:05] <mvo> cachio: did you get the dialog from snap userd asking for confirmation? it sounds for some reason it did not work. are you on the edge core?
[16:06] <cachio> mvo, beta
[16:07] <cachio> mvo, using the one I just built
[16:07] <mvo> cachio: hm, you *might* need edge, I'm not 100% certain
[16:07] <cachio> mvo, updating
[16:07] <mvo> cachio: you can check if you have /snap/core/current/usr/bin/xdg-settings - it should consists of a bunch of dbus- calls
[16:07] <cachio> refreshing
[16:07] <mvo> cachio: but updating is easier :)
[16:07] <mvo> ackk: pushed, let me trigger a built
[16:07] <cachio> mvo, in progress
[16:08] <cachio> mvo, tx
[16:08] <ackk> mvo, thanks!
[16:10] <mvo> ackk: I pulled in distro-info-data (so just the csv) should be availalbe in ~30min (once the build is finished)
[16:10] <ackk> mvo, is it automatically published?
[16:10] <mvo> ackk: it should be, yes
[16:10] <ackk> ah, cool
[16:10] <ackk> thanks
[16:15] <zyga-ubuntu> kyrofa: https://github.com/snapcore/snapd/pull/4560
[16:15] <mup> PR #4560: many: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>
[16:23] <ackk> mvo, it seems some builds failed
[16:29] <mvo> ackk: yeah, the ports nameserver lookup failed, looks very internal to me
[16:29] <mvo> ackk: meh, all failed
[16:30] <mvo> ackk: looking at it now
[16:32]  * zyga-ubuntu afk but will be back, needs to refresh
[16:52] <niemeyer> lxd pr reviewed
[17:00] <mup> PR snapcraft#1889 closed: tests: remove plainbox part from plugin tests <bug> <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1889>
[17:00] <kyrofa> zyga-ubuntu, yeeeeesssssss
[17:01] <zyga-ubuntu> kyrofa: indeed
[17:01] <zyga-ubuntu> kyrofa: we're just polishing the details
[17:01] <zyga-ubuntu> but it works for real
[17:02] <kyrofa> zyga-ubuntu, no security review yet, does it have security implications?
[17:02] <zyga-ubuntu> kyrofa: nope
[17:02] <zyga-ubuntu> kyrofa: it's all good
[17:02] <kyrofa> So happy to hear it, thanks for sticking with it zyga-ubuntu
[17:02] <zyga-ubuntu> kyrofa: it will be in 2.31 for sure (next RC)
[17:02]  * kyrofa subscribes to PR
[17:02] <zyga-ubuntu> kyrofa: I only did that because I had a terrible morning where another HDD broke and it was monday and it was raining and kids were crazy about returning back to school
[17:03] <zyga-ubuntu> kyrofa: it turned out to be a good day after all :)
[17:03] <kyrofa> Haha, good!
[17:03] <stgraber> zyga-ubuntu: there is a bug with apparmor in containers when running on some > 4.4 ubuntu kernel, tyhicks is aware and jj was supposed to look into it
[17:04] <tyhicks> stgraber: that's the bug that he's referring to
[17:04] <jdstrand> stgraber: I pointed him to the relevant conversation
[17:04] <zyga-ubuntu> yes, thank you everyone!
[17:05] <stgraber> perfect :)
[17:05] <tyhicks> jdstrand: now that I think about it, didn't jj say that he had test kernels available for testing?
[17:05] <zyga-ubuntu> it's not an immediate probem because snapd manages its own profiles and reexecs but it will bite some people sooner or later
[17:05] <tyhicks> jdstrand: does that ring any bells for you? if so, I can try to dig up the conversation
[17:09] <jdstrand> tyhicks: well, yes, it does, but I couldn't remember the deatils so came to you :)
[17:09] <jdstrand> tyhicks: I don't even know if there is a bug tbh
[17:11] <zyga-ubuntu> jdstrand: the error message seems like it's a deliberate thing
[17:11] <zyga-ubuntu> jdstrand: but unexpected
[17:11] <zyga-ubuntu> jdstrand: it looks like apparmor thinks the container is privileged and doesn't do apparmor stacking
[17:11]  * kalikiana wrapping up after a frustrating day of debugging symlink issues
[17:12] <zyga-ubuntu> kalikiana: ln -s kalikiana /dev/bed
[17:12] <zyga-ubuntu> or was it the other way around
[17:12] <zyga-ubuntu> I hate "ln -s" syntax
[17:13] <kalikiana> zyga-ubuntu: haha. you know, I've written a love poem about it, because that command annoys me so much (not a joke in fact)
[17:13] <jdstrand> zyga-ubuntu, tyhicks: what I recall is that lxd is using a funky way to detect things because libapparmor doesn't provide something better. the kernel never meant to have what lxd is currently checking be depended on. the kernel changed this for some other reason and the check broke
[17:13] <stgraber> jdstrand: the problem is that the broken kernel return an empty string at /sys/kernel/security/apparmor/.ns_name rather than the profile name
[17:13] <stgraber> jdstrand: and the apparmor init script uses that string being non-empty as a way to detect stacking and so fails
[17:14] <jdstrand> zyga-ubuntu, tyhicks: so jj was going to fix the kernel for now. I suspect he is going to also provide a libapparmor change, but I don't know that for a fact
[17:14] <jdstrand> stgraber: right
[17:14] <stgraber> jdstrand: the LXD side of the detection actually does work fine, LXD does setup stacking and everything but the container itself can't detect it
[17:14] <jdstrand> and that was never meant to be 'the right check'
[17:14] <jdstrand> but it is all you have
[17:15] <jdstrand> ok, right, it was /lib/apparmor/functions that was wrong
[17:15] <stgraber> jdstrand: so it's either a kernel bug that this string is now empty or it's an apparmor init script bug that it's relying on something which is meant to be empty :)
[17:15] <jdstrand> but it was changed for lxd. anyway...
[17:15] <jdstrand> stgraber: I think I said as much
[17:15] <stgraber> yep
[17:19] <pstolowski> niemeyer, pedronis I'd be useful to conclude #4401 (but #4400 first) as it will clear the way for interface hooks PR (and will help me a bit with resolving the issue of running hooks on refresh). AFAIR the most problematic point in 4401 was conflict resoluton, I've improved it and looking forward for feedback
[17:19] <mup> PR #4401: snapstate/ifacestate: auto-connect tasks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
[17:19] <mup> PR #4400: tests/main/searching: handle changes in featured snaps list <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4400>
[17:20] <zyga-ubuntu> jdstrand: quoting linus, "fu... nvidia"^H^H "never break userspace" :-)
[17:20] <zyga-ubuntu> I'm sure it will be resolved quickly
[17:20] <pstolowski> niemeyer, pedronis ah, mistake, not after 4400, but after #4440
[17:20] <mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
[17:27] <niemeyer> pstolowski: #4440 LGTM
[17:27] <mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
[17:32] <pstolowski> niemeyer, thanks
[17:40] <kyrofa> zyga-ubuntu, have you messed with snapd in docker lately?
[17:47] <zyga-ubuntu> kyrofa: no, never
[17:47] <zyga-ubuntu> kyrofa: like literally never ever
[17:47] <kyrofa> Yeah me neither, but I seem to remember other people running into issues
[17:47] <zyga-ubuntu> kyrofa: is docker the deb something that I can try to use? or should I use docker the snap
[17:47] <zyga-ubuntu> guess I should try today
[17:48] <kyrofa> zyga-ubuntu, no idea :D
[17:48]  * zyga-ubuntu handles some important errand at home and will be back to snapd in a moment
[18:36] <mup> PR snapcraft#1890 opened: Fixed typo <Created by chrisglass> <https://github.com/snapcore/snapcraft/pull/1890>
[18:49] <zyga-ubuntu> niemeyer: can you please look at 4560 again please?
[18:49] <zyga-ubuntu> too much pleasure ;-)
[18:49] <zyga-ubuntu> niemeyer: I changed how I generate the unit and made the name dynamic
[18:49] <zyga-ubuntu> and fixed some silly things in that makefile while I was at it
[18:49] <zyga-ubuntu> spread is in progress, local testing was ok
[18:50] <zyga-ubuntu> man, where is everyone, no chipaca, no mvo :/ I should sleep at night and work during the day more
[19:01] <bashfulrobot> Question - staged packages in a confined snap.. are they updated when apt is run? Or only when the snap package is refreshed/
[19:05] <kyrofa> bashfulrobot, anything in the snap is only updated when the snap is updated
[19:05] <kyrofa> Remember the snap is read-only
[19:07] <bashfulrobot> I suspected. I have a use case for a snap at my work, but I know it will likely have to be classic (display related - remoting protocol). But the base software does not need to be updated often. So I was trying to figure out if there si a negative aspect to snapping it.
 zyga-ubuntu, about the hidraw interface
 zyga-ubuntu, I cannot see it as part of the interfaces in my machine
 zyga-ubuntu, do you
 ?
[19:08] <cachio> zyga-ubuntu, I got disconnected
[19:16] <zyga-ubuntu> cachio: re
[19:17] <zyga-ubuntu> cachio: AFAIK it's juts added in gadget snaps, it's not implicit
[19:17] <zyga-ubuntu> bashfulrobot: snaps can be updated as often as you want
[19:17] <zyga-ubuntu> bashfulrobot: you just have to do the update
[19:17] <zyga-ubuntu> bashfulrobot: snapcraft.io can help, you can just rebuild your pacakge
[19:17] <zyga-ubuntu> *package
[19:18] <cachio> zyga-ubuntu, ok, tx
[19:18] <bashfulrobot> Ah ok, so you almost need to rebuild regularly in this case regardless of the packaged software itself.
[19:38]  * ikey issued "normal" updates for the lsi edge snaps..
[19:54] <bashfulrobot> Thanks for the info zyga-ubuntu
[20:09] <mup> PR snapcraft#1891 opened: lifecycle: use in-snap mksquashfs if running from snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1891>
[20:12] <roadmr> jdstrand: hi there! would it be OK for me to update the reviewer tools to r978? or would that need the extra packages for the resquash work? my reason for asking: there's at least one snap using a 2.30 interface which is failing review because said interface is not yet known by tools r950 which is what the store has
[20:13] <ackk> there is a typo in base-18 Makefile: s,curren/t,current/
[20:13] <ackk> * s,curren/t,current/,
[20:13] <ackk> mvo ^ in case you're around
[20:18] <ackk> FTR: https://github.com/snapcore/base-18/pull/36
[20:18] <mup> PR base-18#36: Makefile: fix typo in base URL <Created by albertodonato> <https://github.com/snapcore/base-18/pull/36>
[20:23] <zyga-ubuntu> ackk: looking
[20:25] <zyga-ubuntu> ackk: I cannot merge it, tests failed, I'm looking at why but this looks like something mvo knows better
[20:31] <ackk> zyga-ubuntu, ok. it's probably not related to this change, though
[20:33] <ackk> zyga-ubuntu, can you kick a build on current master to see if it hits the same error?
[20:35] <zyga-ubuntu> ackk: I restarted that test
[20:36] <zyga-ubuntu> chroot: failed to run command ‘/tmp/999-clean-resolv-conf.chroot’: Permission denied
[20:37] <zyga-ubuntu> hmm hmm
[20:37] <zyga-ubuntu> ackk: is this https://github.com/snapcore/base-18/blob/master/hooks/999-clean-resolv-conf.chroot file +x in your branch?
[20:37] <zyga-ubuntu> cna you please check that
[20:41] <ackk> zyga-ubuntu, it's not
[20:41] <ackk> nor in master
[20:41] <ackk> zyga-ubuntu, should I chmod it?
[20:42]  * ackk tries
[20:42] <ackk> let's see if tests pass now
[20:45] <zyga-ubuntu> yes
[20:48] <niemeyer> zyga-ubuntu: First comment wasn't addressed or responded
[20:50] <ackk> zyga-ubuntu, tests passed
[20:50] <zyga-ubuntu> niemeyer: oh, let me check
[20:51] <zyga-ubuntu> hmm, that's odd, I responded but my response is gone now
[20:52] <zyga-ubuntu> niemeyer: let me respond again, I certainly didn't ignore it
[20:52] <zyga-ubuntu> and odd
[20:52] <zyga-ubuntu> I cannot respnd to the thread there
[20:52]  * zyga-ubuntu reloads
[20:52] <zyga-ubuntu> niemeyer: anyway, let's do it here so that we can reach an agreement
[20:53] <zyga-ubuntu> my initial response was that I'd prefer to fail close and early rather than notice the situation we don't support and fail open later when snap is refreshed or removed
[20:53] <zyga-ubuntu> if you think this is too grave concern we can reomve that whole section now, it's not doing anything apart from checking and failing when the externally satisfied precondition is not met
[20:57] <zyga-ubuntu> niemeyer: let me know what you think
[20:57] <niemeyer> zyga-ubuntu: Yeah, I found it awkward that there's no way to add comments there indeed
[20:58] <niemeyer> zyga-ubuntu: My concern (and mvo's I think) is not that it's better to fail one way or the other, but rather that we have existing logic and no clue whether people are depending on it today or not
[20:58] <zyga-ubuntu> niemeyer: yes, that's a valid concern, as I said I responded to the comment (somehow) and I wanted to discuss it more hence no changes
[20:59] <niemeyer> zyga-ubuntu: Before, there was nothing there.. then, in an automatic update, we go from "no worries!" to "BOOM!"
[20:59] <zyga-ubuntu> niemeyer: I think for now we can make the die go away and land this, to the happiness of LXD uses
[20:59] <zyga-ubuntu> and we could look at a way for snapd to measure the environment say "gee, I cnanot work here" perhaps
[21:00] <niemeyer> zyga-ubuntu: And we need some kind of heads up before we do hard changes
[21:00] <niemeyer> zyga-ubuntu: So we have a clue if we're breaking any existing environment for which we don't currently have tests for
[21:01] <zyga-ubuntu> niemeyer: shall we printf something or just do nothing at all now?
[21:02] <zyga-ubuntu> (as in rip that code path out)
[21:06] <niemeyer> zyga-ubuntu: I would not touch that kind of logic right now
[21:06] <niemeyer> zyga-ubuntu: There's just too much going on
[21:06] <niemeyer> zyga-ubuntu: Just add a note of what the intention is for the near future and why
[21:06] <niemeyer> zyga-ubuntu: Then, when everything else settles, we can poke at it and see what happens
[21:07] <niemeyer> zyga-ubuntu: Certainly with a warning before we do anything aggressive
[21:07] <zyga-ubuntu> ok
[21:14] <zyga-ubuntu> niemeyer: updated
[21:16]  * zyga-ubuntu doesn't like old make :/
[21:18] <cachio> zyga-ubuntu, I see the error 'runtime/cgo: ' when we run the i18n test
[21:18] <niemeyer> zyga-ubuntu: Looking again
[21:19] <cachio> zyga-ubuntu, any idea if it is an error or a message that could be discarded?
[21:19] <zyga-ubuntu> cachio: that looks like one of those go bugs we had
[21:19] <zyga-ubuntu> I thought those were fixed
[21:19] <zyga-ubuntu> are those on 14.04?
[21:20] <niemeyer> zyga-ubuntu: Can we please not touch that logic right now instead?
[21:20] <cachio> zyga-ubuntu, yes, it is making the i18n test fail
[21:20] <zyga-ubuntu> niemeyer: no
[21:20] <zyga-ubuntu> niemeyer: that logic as it was was broken
[21:20] <zyga-ubuntu> niemeyer: it was either inactive or it was broken
[21:20] <zyga-ubuntu> niemeyer: (see the original bug description from stgraber)
[21:20] <niemeyer> zyga-ubuntu: Why?
[21:20] <zyga-ubuntu> niemeyer: it was running to late, creating mirror entries
[21:20] <cachio> zyga-ubuntu, it is also failing on debian-9
[21:21] <niemeyer> zyga-ubuntu: I won't re-read the *whole* bug right now trying to guess hints of this :)
[21:21] <zyga-ubuntu> cachio: so on 14.04 and on debian-9 we probably have the bug still, I don't know really
[21:21] <zyga-ubuntu> niemeyer: essentially the self-bind mount would duplicate existing mount entries
[21:21] <zyga-ubuntu> niemeyer: and then apply sharing over them
[21:21] <zyga-ubuntu> niemeyer: but keep the old entries intact
[21:21] <cachio> zyga-ubuntu, do you remember in which PR it was fixed for the other systems? so I can take a look
[21:21] <zyga-ubuntu> niemeyer: there were two lines there: a rbind and a rshare
[21:22] <zyga-ubuntu> niemeyer: the rbind gives us a thing that can control sharing (sharing is per mount entry not per directory)
[21:22] <zyga-ubuntu> niemeyer: and the sharing is obvious
[21:22] <zyga-ubuntu> niemeyer: but at that time /snap was already populated
[21:22] <zyga-ubuntu> niemeyer: the result confuses systemd and mount units cannot stop correctly
[21:22] <zyga-ubuntu> niemeyer: that's about it
[21:23] <zyga-ubuntu> cachio: it was a (perhaps more than one) update to the golang compiler, but perhaps I don't recall correctly; mwhudson would know
[21:23]  * zyga-ubuntu will snap ancient make for self-punishment and testing
[21:24] <niemeyer> zyga-ubuntu: Yes, I get that.. I thought that was exactly what was fixed
[21:24] <niemeyer> zyga-ubuntu: and this path shouldn't be reachable given that
[21:24] <zyga-ubuntu> niemeyer: yes!
[21:24] <zyga-ubuntu> niemeyer: that's why I used die
[21:24] <zyga-ubuntu> and argued we could rip it out
[21:24] <niemeyer> zyga-ubuntu: Well.. now you are saying that if we preserve the logic we have a bug..
[21:25] <zyga-ubuntu> no no, sorry, we have a comms problem over irc
[21:25] <zyga-ubuntu> if we keep the old bind mount + share code there we will have problems on systems that the new snap.mount unit doesn't fix (e.g. on a non-container with that behavior)
[21:25] <zyga-ubuntu> essentially, that whole code was wrong and it should be removed regardless
[21:26] <zyga-ubuntu> but for initial version of this patch in the morning I used die to see if it would fail anywhere
[21:26] <zyga-ubuntu> one place we could perhaps explore is 14.04 as a non-container
[21:26] <niemeyer> zyga-ubuntu: If we have code that the change doens't fix, then you'd be blowing it up with die()
[21:26] <zyga-ubuntu> yes
[21:26] <mwhudson> zyga-ubuntu: hmmm
[21:27] <zyga-ubuntu> niemeyer: but 14.04 is using a different mechanism to fix it
[21:27] <zyga-ubuntu> niemeyer: so nothing (apart from build failure now with make) was broken
[21:27] <zyga-ubuntu> niemeyer: either way, I would leave: printf (as it is now) or nothing; I would not keep that mount rbind, mount rshare code as we used to have
[21:28] <zyga-ubuntu> we *could* keep it
[21:28] <zyga-ubuntu> and it would not alter behavior
[21:28] <zyga-ubuntu> *behaviour
[21:28] <zyga-ubuntu> but I think it's just buggy
[21:28] <mwhudson> zyga-ubuntu: +?
[21:28] <zyga-ubuntu> we can do that on another iteration if you are worried about something unanticipated
[21:28] <zyga-ubuntu> mwhudson: hmm?
[21:28] <mwhudson> zyga-ubuntu: "mwhudson should know" -- know what? :)
[21:28] <niemeyer> zyga-ubuntu: I've been saying that for some time :)
[21:28] <zyga-ubuntu> mwhudson: ah, sorry, cachio saw "cgo runtime" thing again
[21:29] <mwhudson> zyga-ubuntu: cgo runtime?
[21:29] <zyga-ubuntu> mwhudson: and asked if we there was a patch for that somewhere
[21:29] <zyga-ubuntu> 22:18 < cachio> zyga-ubuntu, I see the error 'runtime/cgo: ' when we run the i18n test
[21:29] <mwhudson> zyga-ubuntu: i'm just back from leave so have no context at all
[21:29] <niemeyer> zyga-ubuntu: We have several concurrent ideas of what's supposed to happen:
[21:29] <niemeyer> 1. Nobody will ever reach this logic
[21:29] <niemeyer> 2. We want to kill those who reach this logic
[21:29] <zyga-ubuntu> niemeyer: sure, I just wanted to explain the motivation of the patches I sent so far so that my ideas are clear
[21:29] <niemeyer> 3. We want to preserve the behavior of those reaching this logic
[21:30] <niemeyer> Those are all incompatible with each other
[21:30] <zyga-ubuntu> I agree
[21:30] <cachio> mwhudson, hey
[21:30] <cachio> mwhudson, https://travis-ci.org/snapcore/snapd/builds/334699893#L2129
[21:30] <mup> PR snapcraft#1890 closed: Fixed typo <Created by chrisglass> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1890>
[21:30] <zyga-ubuntu> niemeyer: 1 can still happen on systems that don't use systemd to boot but we don't support that
[21:31] <mwhudson> zyga-ubuntu: i don't know what that means
[21:31] <cachio> mwhudson, when we run a test that tries the different languages with the command snap
[21:31] <zyga-ubuntu> mwhudson: I was under the impression that we ran into a bug in golang where exec + fork were racing
[21:31] <zyga-ubuntu> mwhudson: but perhaps that was fixed in the kernel, I don't recall
[21:31] <niemeyer> zyga-ubuntu: I don't want to go hunting that sort of bugs *right now*
[21:31] <cachio> mwhudson, we can see an error "runtime/cgo:"
[21:31] <niemeyer> zyga-ubuntu: Or to burn mvo with late releases to fix serious issues in unexpected environments
[21:31] <zyga-ubuntu> niemeyer: understood
[21:32] <niemeyer> zyga-ubuntu: We need to focus on delivering the few things which are high prio at the moment.. layouts, interface hooks, etc
[21:32] <zyga-ubuntu> I'll restore the code and leave a todo to remove this after the release
[21:32] <niemeyer> Thanks!
[21:32] <mwhudson> cachio: oh well i18n is disabled entirely in debian
[21:32] <zyga-ubuntu> niemeyer: thank you! :)
[21:32] <cachio> mwhudson, it is just happening on debian-9 and ubuntu-14.04
[21:32] <mwhudson> zyga-ubuntu: aaah the fork/exec thing
[21:33] <mwhudson> wait one version of that is just a warning
[21:33] <zyga-ubuntu> cachio: was it failing or just printing and you noticed?
[21:33] <cachio> zyga-ubuntu, it is printing
[21:33] <niemeyer> zyga-ubuntu: Why was the unit file embedded in the makefile?
[21:33] <cachio> zyga-ubuntu, If I reexec it doesn't fail
[21:33] <mwhudson> hmmm i thought that was fixed in debian though
[21:34] <niemeyer> zyga-ubuntu: That sounds a bit less nice than what you had there earlier
[21:34] <mwhudson> oh wait, probably only in buster
[21:34] <zyga-ubuntu> niemeyer: it was nice when it worked, no need to sed, just expand variables
[21:34] <cachio> mwhudson, zyga-ubuntu if I exec the command that failed in a debug session, it works well
[21:34] <zyga-ubuntu> niemeyer: but given that old make sucks I think I must go back to sed
[21:34] <mwhudson> cachio: it's only ever a 1 in a 1000 type thing, it's a race
[21:34] <zyga-ubuntu> niemeyer: the advantage was that we didn't have to duplicate a rule for a file with variable target name
[21:35] <zyga-ubuntu> niemeyer: anyway, I'll sort it out
[21:35] <cachio> mwhudson, it seems so
[21:35] <mwhudson> there is also the kernel bug where a setuid executable doesn't get uid=0, no idea if that's fixed in debian yet
[21:35] <niemeyer> zyga-ubuntu: I don't see the relationship
[21:35] <niemeyer> zyga-ubuntu: Embedding everything in the Makefile isn't so nice, whether make rocks or not
[21:36] <zyga-ubuntu> niemeyer: it was nice for this case IMO, because I could didn't have to duplicate rules that sed the vars in and get the new filename I had to use
[21:38] <zyga-ubuntu> almost there...
[21:39] <cachio> mwhudson, something that I already tried is to add a sleep between different tries and the issue also happened
[21:40] <cachio> mwhudson, any idea where I could start looking at to fix it?
[21:40] <mwhudson> cachio: it's a race within the go start up routines
[21:41] <cachio> mwhudson, ah, ok
[21:43] <cachio> zyga-ubuntu, is it ok if we ignore these kind of errors or set this to manual?
[21:46] <cachio> zyga-ubuntu, also we could skip the failing systems until the issue is resolved
[21:46] <cachio> mwhudson, how did you deal with these kind of issues in the past?
[21:47] <zyga-ubuntu> cachio: well, it's not really honest, we should get the relevant fixes to those systems if that makes snapd work better
[21:48] <jdstrand> roadmr: it is probably ok but I haven't fully verified it
[21:48] <roadmr> jdstrand: oh ok... I'd rather wait until you greenlight it properly then
[21:48] <cachio> zyga-ubuntu, of course, but the fixes should go in snapd?
[21:48] <jdstrand> roadmr: right now most of that is behind env vars
[21:49] <roadmr> jdstrand: what can cachio do in the meanwhile, with that interface he wants to use that the old tools don't grok?
[21:49] <jdstrand> roadmr: but we/I can be responsive to the queue for now too
[21:49] <zyga-ubuntu> cachio: no
[21:49] <roadmr> jdstrand: ok... hm this snap was marked as "failed review", not as "held for manual review", whic was odd
[21:49] <zyga-ubuntu> cachio: to kernel/golang AFAIK
[21:49] <jdstrand> roadmr: he can request a manual review
[21:50] <roadmr> cachio: ^^ oh yay!
[21:50] <mwhudson> cachio: hm the fix for this is https://go-review.googlesource.com/c/go/+/33894 which is in go 1.8 which i thought was what stretch had...
[21:51] <mwhudson> ah no 1.7
[21:51] <cachio> mwhudson, ok
[21:52] <zyga-ubuntu> niemeyer: I think this is it
[21:52] <zyga-ubuntu> lets see if tests pass
[21:53] <cachio> roadmr, sure, I'll do
[21:53] <cachio> roadmr, done
[21:53] <roadmr> whee :0 cachio that way no need to wait for the tools upgrade because it might be a bit longer than expected
[21:53] <roadmr> cachio: great, that puts it in the queue and someone will look shortly.
[21:54] <cachio> roadmr, I'll have to request also for all the other arquitectures
[21:54] <cachio> architectures
[21:54] <cachio> roadmr, np, thanks
[21:55] <jdstrand> cachio: if it is test-snapd-gpio-memory-control, I just approved it, but you'll need to publish
[21:55] <cachio> jdstrand, yes, thanks
[21:56] <cachio> zyga-ubuntu, i18n is making snapd fail 1/3 executions, so, what do you think is the best idea to deal with this one
[21:56] <zyga-ubuntu> cachio: well, it depends, we could just ignore that result, ideally we'd try to get the fix released if the frequency is that high people will also hit that bug often
[21:58] <cachio> zyga-ubuntu, it is often because the test is going through all the langs and trying LANG=xxx snap
[21:58] <zyga-ubuntu> I see
[21:58] <zyga-ubuntu> well
[21:58] <zyga-ubuntu> I don't think that changes anything
[21:59]  * zyga-ubuntu reads about dell vmware merger
[22:00] <zyga-ubuntu> imagine a laptop with "vmware" logo on it :)
[22:00] <zyga-ubuntu> on the other hand vmware metal servers would be fun
[22:00] <niemeyer> zyga-ubuntu: LGTM assuming it works :)
[22:00] <zyga-ubuntu> thank you!
[22:01] <zyga-ubuntu> I'll get the other branch working now
[22:02] <zyga-ubuntu> and in some alternative universe we're all running dell VMs using dell workstation which is a program
[22:02] <zyga-ubuntu> ....
[22:02] <zyga-ubuntu> dell and vmware watch too many mirror universe trek episodes
[22:03] <roadmr> haha
[22:03] <roadmr> good one
[22:07] <zyga-ubuntu> but, at least dell fusion makes sense, with vmware, that is
[22:24] <zyga-ubuntu> niemeyer: tests are green :)
[22:24] <zyga-ubuntu> we need a 2nd review
[22:24] <zyga-ubuntu> I'll ask mvo for one in the morning
[22:36] <zyga-ubuntu> hmm, no vmware would probably not be affected
[22:36] <zyga-ubuntu> that's curious, I wonder if I could reproduce that
[22:37] <zyga-ubuntu> kyrofa: it looks like I will have clean plate soon (I will work on per-user mounts with jamesh and on layout policy with jdstrand) but this can be my backburner task
[22:38] <kyrofa> zyga-ubuntu, no problem, just comment on that issue when you're able, I'll leave it open
[22:39] <zyga-ubuntu> kyrofa: actually, with my gazillion tabs lost on my desktop
[22:39] <zyga-ubuntu> do you have a link?
[22:39] <jamesh> zyga-ubuntu: fwiw, I'm in UTC-8 this week (rather than UTC+8)
[22:39] <kyrofa> zyga-ubuntu, https://github.com/nextcloud/nextcloud-snap/issues/425
[22:39] <kyrofa> Haha, no problem
[22:39] <roadmr> jamesh: oh what happened :( who multiplied you by -1?
[22:39] <zyga-ubuntu> jamesh: oh, cool, sprinting?
[22:39] <zyga-ubuntu> kyrofa: thank you
[22:40] <zyga-ubuntu> roadmr: LOL
[22:40] <jamesh> zyga-ubuntu: yeah.  At the Snapcraft Summit with kyrofa and others
[22:42] <zyga-ubuntu> cool, is jdstrand there too?
[22:42] <zyga-ubuntu> jamesh please talk to jdstrand about your PR, if he acks it I'll merge and we can iterate
[22:42] <jamesh> zyga-ubuntu: I think he's arriving later in the week
[22:43] <zyga-ubuntu> excellent, don't let him leave without that :)
[22:43] <zyga-ubuntu> ;-)
[22:43] <jdstrand> zyga-ubuntu, jamesh: fyi, I just reviewed it
[22:43] <kyrofa> jamesh, yeah, Thursday
[22:43] <zyga-ubuntu> ooooh
[22:43]  * zyga-ubuntu is looking
[22:44] <jdstrand> I'll be there Wed and Thu
[22:44] <jdstrand> (leaving tomorrow)
[22:44] <mwhudson> what https://paste.ubuntu.com/26486123/
[22:45] <mwhudson> (tldr snapcraft.storeapi.errors.StoreReleaseError: <exception str() failed>)
[22:45] <zyga-ubuntu> jdstrand: nice, thank you!
[22:45] <zyga-ubuntu> kyrofa: ^
[22:45] <kyrofa> Oh right, was thinking Thursday/Friday
[22:45] <kyrofa> Glad you said something :P
[22:47] <mwhudson> hm i tried running snapcraft login again and now it's just hanging
[22:48] <kyrofa> mwhudson, hmm... what version
[22:48] <kyrofa> ?
[22:48] <mwhudson> 2.35 (stable channel)
[22:49] <mwhudson> ... because snap install --edge --classic snapcraft was failing too :)
[22:49] <mwhudson> clearly i shouldn't be near computers today
[22:49] <kyrofa> Huh, sounds like the store is having issues then
[22:49] <zyga-ubuntu> mwhudson: snap install weekend -> EMONDAY
[22:50] <mwhudson> kyrofa: could be
[22:50] <zyga-ubuntu> where is that apt thing
[22:50] <zyga-ubuntu> where it prints something odd once in blue moon
[22:50] <zyga-ubuntu> when something else fails
[22:50] <zyga-ubuntu> it's a bit insane
[22:50] <zyga-ubuntu> ah, past midnight something
[22:51] <mwhudson> zyga-ubuntu: it's a 'man after midnight' think i think
[22:51] <mwhudson> (and cj-watson's fault)
[22:51] <zyga-ubuntu> ah :D
[22:51] <zyga-ubuntu> it was man
[22:52] <mwhudson> https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030
[22:53] <mwhudson> kyrofa: it's working now
[22:55] <kyrofa> Weird


[11:56] <mup> Bug #1993289 opened: Pod storage pool path can't be blank <MAAS:In Progress by ack> <MAAS 3.1:In Progress by ack> <MAAS 3.2:In Progress by ack> <https://launchpad.net/bugs/1993289>
[11:59] <mup> Bug #1993289 changed: Pod storage pool path can't be blank <MAAS:In Progress by ack> <MAAS 3.1:In Progress by ack> <MAAS 3.2:In Progress by ack> <https://launchpad.net/bugs/1993289>
[12:02] <mup> Bug #1993289 opened: Pod storage pool path can't be blank <MAAS:In Progress by ack> <MAAS 3.1:In Progress by ack> <MAAS 3.2:In Progress by ack> <https://launchpad.net/bugs/1993289>
[13:44] <shubjero> Hey all. I've got some servers to deploy which have 2x1TB nvme drives which I'd like to deploy as raid-1 w/ lvm on top and efi boot. I can configure what I think is a valid config in MaaS but upon server deployment it fails to apply that storage config.
[13:44] <shubjero> Anyone know of any guides on this?
[13:44] <shubjero> I can provide more detail / screenshots / logs
[13:50] <shubjero> https://imgur.com/a/qlwJWmu - here is the disk layout I am attempting
[13:50] <shubjero> im deploying it now just so i can get the error message again
[13:58] <shubjero> https://paste.openstack.org/show/bbVUQqH123FJeFNvhngy/
[13:58] <shubjero> there's the error
[14:00] <shubjero> this happened on maas 2.8 and so i thought it was prudent to upgrade to newer maas but still happens on 3.2
[14:56] <ahasenack> you have /boot/efi in lvm? Is that allowed?
[14:57] <ahasenack> I don't think the BIOS understand lvm
[17:15] <shubjero> ahasenack: ive also tried /boot/efi outside of lvm as a regular partition. I will try that again, screenshot, and check logs too
[17:15] <shubjero> give me a few
[18:03] <ahasenack> I thought maas would take care of /boot/efi, I don't recall in detail
[18:03] <ahasenack> maybe it doesn't
[18:25] <shubjero> maas seems to let you do varying storage schemes that just dont work