[00:04] <_mup_> txzookeeper/session-and-conn-fail r53 committed by<EMAIL_ADDRESS>[00:04] <_mup_> set with transparent retry (using retry_change), correct doc string to note session timeout value is in milliseconds
[00:17] <_mup_> Bug #879731 was filed: Better error handling for session failure and connection loss <juju:New for hazmat> <txzookeeper:New for hazmat> < https://launchpad.net/bugs/879731 >
[00:25] <_mup_> txzookeeper/session-and-conn-fail r54 committed by<EMAIL_ADDRESS>[00:25] <_mup_> improve retry delay
[03:37] <_mup_> txzookeeper/session-and-conn-fail r55 committed by<EMAIL_ADDRESS>[03:37] <_mup_> simplify retry, add retry delay to watch op retries
[04:09] <_mup_> txzookeeper/session-and-conn-fail r56 committed by<EMAIL_ADDRESS>[04:09] <_mup_> test for core retry & retry watch in isolation
[04:11] <_mup_> txzookeeper/session-and-conn-fail r57 committed by<EMAIL_ADDRESS>[04:11] <_mup_> version increment, and pep8
[04:24] <_mup_> txzookeeper/session-and-conn-fail r58 committed by<EMAIL_ADDRESS>[04:24] <_mup_> update license headers, add author tag
[11:15] <tauren> just discovered juju, looks cool, but have a question
[11:15] <tauren> can I only deploy on AWS?
[11:16] <tauren> is there a way to use my own servers and virtualization?
[11:18] <tauren> nm, found the answer in the FAQ. https://juju.ubuntu.com/docs/faq.html
[16:48] <hazmat> tauren, thats outdated
[16:49] <hazmat> tauren, you can deploy on openstack or directly onto physical machines, or deploy entire environments on a single machine with lxc
[16:49] <tauren> hazmat: sweet! is there a howto somewhere?
[16:50] <hazmat> tauren, which would would you like to do?
[16:50] <hazmat> tauren, we're having some problems updating our docs atm
[16:50] <tauren> probably lxc
[16:50] <hazmat> tauren, i've put up some updated ones at http://charms.kapilt.com/docs/provider-configuration-local.html
[16:50] <tauren> but when you say directly onto physical machines, is there something that will automatically set them up for virtualization?
[16:51] <hazmat> tauren, we deploy openstack with juju onto physical machines
[16:51] <hazmat> tauren, juju uses cobbler/orchestra as a machine provider for that scenario
[16:51] <tauren> hmmm... here's what I want to do...
[16:52] <tauren> I have a single physical server
[16:52] <tauren> and I'd like to configure it to be able to run multiple services.
[16:52] <tauren> currently it has kvm installed
[16:52] <tauren> but i plan to start over.
[16:52] <tauren> what solution would you suggest?
[16:53] <hazmat> tauren, local provider which uses lxc for isolation
[16:53] <hazmat> its lightweight virtualization
[16:53] <tauren> i'm running openvz on another server. i assume it is similar?
[16:53] <hazmat> well its more properly not virtualization.. more like a solaris zone, freebsd jail, or chroot on steroids.
[16:53] <hazmat> tauren, very similiar to openvz
[16:53] <tauren> ok
[16:53] <hazmat> tauren, except in kernel
[16:53] <tauren> nice
[16:55] <tauren> so i could deploy charms for wordpress, etc. onto it then.
[16:55] <tauren> what if i also need to run some java services? my understanding is kvm is preferred over openvz for that. same for lxc?
[16:58] <tauren> hazmat: also, can I scale only locally, or can I expand out to EC2 if my local resources are exhausted?
[17:03] <tauren> hazmat: i need to head out. thanks for your help!
[17:03] <hazmat> tauren, you can only use one provider for a single environment atm
[17:04] <hazmat> tauren, but you can have multiple environments managed by juju
[17:04] <hazmat> ie. test local, deploy ec2
[17:04] <tauren> so I couldn't have a wordpress blog hosted locally and add EC2 resources to scale it?
[17:04] <hazmat> tauren, cheers
[17:04] <hazmat> tauren, no, we don't have public/private bursting, and probably won't for a while
[17:05] <tauren> good to know.
[17:05] <tauren> is openstack something I run on my servers?
[17:05] <hazmat> tauren, yes
[17:05] <tauren> or is that an API that rackspace offers?
[17:05] <tauren> does openstack use lxc, or something else?
[17:06] <hazmat> tauren, openstack is a cloud provider with its own api and a minimal ec2 api, it supports multiple virtualization backends
[17:06] <hazmat> from kvm, xen, lxc, etc ...
[17:06] <tauren> alright... so the link you sent doesn't show how to get openstack going, just plain local with lxc, right?
[17:25] <hazmat> tauren, openstack usage is the same as ec2
[17:25] <hazmat> tauren, google has some answers for juju + openstack + orchestra
[17:25] <hazmat> https://wiki.ubuntu.com/ServerTeam/UbuntuCloudOrchestraJuju
[17:43] <_mup_> Bug #880023 was filed: machine agent disconnects from zoopkeeper on heavy loads <juju:New> < https://launchpad.net/bugs/880023 >


[03:39] <landodano> I'm trying to install lubuntu 14.04.05 onto an eee pc 1000. It seemed to install fine and boots, but the gui fails to start. I can log in using the cli, but neither 'startx' or 'sudo service lightdm restart' brings up the gui. I'd appreciate any help I can get in debugging or otherwise fixing this.
[12:45] <Shaitan> anybody who can help me to bring my menu back? i deleted it by accident when i was playing around with the sidebar stuff and im a linux noob
[12:47] <tsimonq2> Shaitan: are you referring to your panel?
[12:48] <Shaitan> i think it is called "menu"
[12:48] <Shaitan> on the bottom what is set up by fresh install like in windows.
[12:49] <Shaitan> i found a cp terminal line in google, but it didnt work.
[14:48] <Starbuckz> Hello good people, I'm trying to install lubuntu from disk on an ancient laptop but can't get further than setting my keymap. It will "detect hardware" and do some stuff but when it should ask for a computer name (according to the wiki) it just ends up in a blank blue screen with a white cmd where I can type but it won't actually recognize any commands. Any suggestions how to proceed?
[19:25] <Chunkyz> anyone else REALLY looking forward to 16.10? I am right in thinking that's when LXQT is being pushed, right?


 Have you built u-boot?
 I grabbed this repo and build something: https://gitlab.com/ubports/community-ports/pinephone#how-do-i-install-ubuntu-touch-on-my-pinephone
 I don't think it's right.
 Wait, I bet there's a build completed in the gitlab.com/pine64-org/crust-meta repo
 I think i have the .bin file from the latest build.
 One of the 3GB branches has built successfully
 Just need to find out where to put it lol.
 I see the boot.img and loader.img files in the partition
 [Edit] I see the boot.img and loader.img files in the partitions
 You flash that directly to the first partition of your sdk card, called loader
 The.bin file
 flash to partition? With what tool?
 The partition is not labeled though it is 2MB.
 DD probably
 Just slap it on there really
 alrighty we'll see how this goes lol
 must have done it wrong since I still have a red LED.
 the 1MB partition?
 sudo dd if=u-boot-sunxi-with-spl-pinephone.bin of=/dev/mmcblk0p2
 That's what I did
 I might wait for the next image to build.
 No, the first partition
 The second is scr and it contains the boot script
 Not the bootloader
 The first partition can't be used I think
 (Photo, 1280x720) https://irc.ubports.com/lH4Fm9V8.png
 (Photo, 720x1280) https://irc.ubports.com/GAvgCvLT.png
 It boots!
 Mayhe
 [Edit] Maybe
 Yes!
 Sweet
 I'm going to see if this what's stopping Mobian too
 Yes, probably
 The only change needed is that not-upstreamed u-boot patch
[07:37] <ubptgbot> dermenschrolf was added by: dermenschrolf
 @fredldotme [The first Jolla phone used BTRFS, the second didn't. There was a reason for that …], btrfs was to young, <16GB emmc was to less for the btrfs. Thats all.
 anyone knows how to fix push notification when it stops working after transferring data to another device? … it was working at first but now TELEports or even the push test app doesn't work
 to be fair, I've transferred my data at least 3 times already...is there something I need to reset or delete? 😅
 @Javacookies [to be fair, I've transferred my data at least 3 times already...is there somethi …], Well you are basically cloning the device. You need to make sure only one device is active at a time. Idk where the push ID is saved and how it could be regenerated. But its possible a problem coming from this, though my last move went fine
[07:55] <ubptgbot> and I get notifications
 yeah it was working but maybe it got broken when I booted my old phone a few days ago
 I usually copy files from `.local` and `.config` with some exclusion for system stuffs to avoid conflicts like this 😅
 The only case I know is if both devices are online at the same time. Push should go back to OK after one device has been powered down, they are just fighting for the registrations
 maybe I should boot it again..
 or maybe because I booted my 2 old phones the last few days... it got confused real bad 😂
 haha
 yes
 weird, my other phone's wifi seems to have ipv6 … is that already supported by UT? well, it says it's connected but I can't actually do anything with the internet
 I'm not even sure if ipv6 is enabled in our router 😅
 @Javacookies [weird, my other phone's wifi seems to have ipv6 … is that already supported by UT? …], Ipv6 comes with ota 13 yes
 this one's still on OTA-12 though
 I toggled the wifi and now it has ipv4
 anyway,now I can confirm that push notification works on my previous phone (MX4) … but it's not working on my current (Xperia X) and more previous (Nexus 5)
 [Edit] anyway,now I can confirm that push notification works on my previous phone (MX4) … but it's not working on my current (Xperia X) and older (Nexus 5)
[10:36] <ubptgbot> Andrea Gus was added by: Andrea Gus
 Is it possible to use zram in RAM instead of SWAP.img on emmc? … How can I disable swap permanently somewhere …  in the system?
 I don't like swap images on flash memory.
 @dohbee [i don't think ubuntu is switching to btrfs by default?], I think ubuntu desktop is going in the ZFS direction, not sure if they'll use it as default in the future though
 @gischpelino [Is it possible to use zram in RAM instead of SWAP.img on emmc? … How can I disable …], I don't think UT uses swap … it uses zram on low RAM devices though like bq E4.5/5
 @Javacookies [I don't think UT uses swap … it uses zram on low RAM devices though like bq E4.5/5], I think the opposite is true ^^
 zram is used on devices where it was enabled by Android. That's only the low-RAM Bq's. If we could get some help with the implementation on other devices, it would work on other devices.
 I tried playing with the swap.img on my note 4 a bit, there was no difference from what I could tell, and zRAM can be enabled for it on android, not sure if its enabled under UT, how would one go about enabling it (assuming all underlying work for it is there)
 @Flohack [I think the opposite is true ^^], technically we use both but the swap is like 32MB
[13:44] <ubptgbot> EmpanadaDTaco was added by: EmpanadaDTaco
 swapon tells: /userdata/SWAP.img …   only!
 yes
 and there is no /dev/zram?
 no question, its a wildcard
 zram is not controlled by swapon/swapoff iirc
 then I did it always wrong. :-)
[14:26] <ubptgbot> <Jose Canales> (Photo, 526x660) https://irc.ubports.com/CAP3r7eE.png
 @wayneoutthere
 @exar_kun your online too
 Spam
 Nothing happened here anymore xD
[15:59] <str1ngs> Hello, I have a new pinephone postmarketos edition I want to use uports.  But this image does not boot. https://ci.ubports.com/job/rootfs/job/rootfs-pinephone-systemimage. my serial cable still has not been shipped by pinestore so hard to test. basically all I get is a red light booting this image. should this image work?
 do you have the convergence version? … because I think some patches are needed for it to work there
 yeah, the 3GB model needs a uboot change
[16:08] <str1ngs> what is the convergence version?
 the 3GB/32GB model
[16:08] <str1ngs> mine is the 3G model yes
 that includes the USB-C hub
[16:08] <str1ngs> err 3GB 32GB emmc with hub
[16:09] <str1ngs> does not help pinestore had taken months to ship my serial cable :(
 I see, so you have to wait a bit for UT to work on your device. I believe there's already work in progress 😄
[16:11] <str1ngs> okay, so it's not as simple a installing another uboot at this time?
[16:12] <str1ngs> it's kinda a PITA because I missed the uports community edition by a day. and all my development happens on ubuntu/debian. so I'm stuck with apk etc.
[16:12] <str1ngs> I think my phone almost caught fire building guile-2.2.7 :P
 Lol
 One day i'll get me an connvergence edition. Geh do i hope i'll make it
[19:20] <ubptgbot> John Chongbang was added by: John Chongbang
[19:30] <ubptgbot> readytochat was added by: readytochat
 Does usbmuxd work in libertine for idevicerestore?
 probably not?
 at least, probably not on android based phones?
 @UniversalSuperBox sorry to bug you but I'm not 100% sure how to get the jumpdrive thing to work to install it to the eMMC.
 Hold the power and volume up buttons to boot into the recovery image. The screen should say "Awaiting command". Plug the phone into your PC with USB and you should see the 'JumpDrive eMMC' and 'JumpDrive SD' storages appear.
 It just boots to postmarketOS. I don't have the SD card installed since I'm still trying to build the Jumpdrive image.
 You could insert the SD card that has the Ubuntu Touch image you were playing with yesterday
 Most likely need that I'm flashing it again.


[14:14]  * bregma looks around and tries to act non-chalant
[14:14]  * Satoris whistles.
[14:16] <bregma> well, standups, but I think people are either busy or getting ready to travel
[14:16] <bregma> I know I am (getting ready, that is)
[14:17] <bregma> I SRUd 4 fixes for utouch-geis on Friday, I'm still waiting for approvals from the SRU team
[14:18] <Satoris> Getting ready for Sprint. Presentations done.
[14:18] <bregma> well, I guess I'll see everyone on Wednesday in clammy California, then
[14:20] <Satoris> I'll arrive on Tuesday evening.
[14:21] <Satoris> Assuming there won't be conf call either, even though Google Calendar thoughtfully sent me an email about it.
[16:55] <cnd> xerent, in 12.04 it depends on whether the device has been reported to work
[16:55] <cnd> upstream currently uses essentially a whitelist, and many drivers require quirks to function properly
[16:55] <cnd> in the future, all Win7 HID multitouch compliant devices will work automatically, unless they need quirks
[16:55] <cnd> that will probably come in 12.10


[15:28] <ekimus> hello I just created https://help.ubuntu.com/community/FirefoxMandatoryPreferences could some native english speaker have a quick readthru for mistakes/things that aren't understandable, the steps do work on at least 7.10.... thanks.
[23:16] <seisen> is bzr always this slow
[23:17] <dsas> seisen: yes.
[23:17] <seisen> ok
[23:17] <seisen> just wondering
[23:17] <dsas> seisen: are you doing a full branch or a lightweight checkout?
[23:18] <seisen> full branch I think
[23:18] <seisen> for xubuntu documentation
[23:18] <dsas> seisen: Yeah, that can take ages then. apparently bzr 1.0 is faster.
[23:21] <seisen> I was wondering because its slow as molassas and I have a fast connection
[23:22] <dsas> seisen: it took me ages to do it as well. once you've done it once, it's fast enough to keep it updated though.
[23:22] <seisen> good


[04:00] <mup> PR snapcraft#1943 closed: Release/2.39.2+18.04 (DO NOT MERGE) <do-not-merge-yet> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1943>
[04:18] <mup> PR snapcraft#2078 opened: Release/2.41+18.04 <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2078>
[04:34] <pbek> zyga: thanks a lot for your patience. so the most common way for a download tool like https://github.com/pbek/lmdownload is to tell the user that they only can download files to their home folder if they are installing the snap package?
[05:10] <mborzecki> morning
[05:44] <zyga> good morning
[05:44] <mborzecki> zyga: hello
[05:45] <zyga> pbek: I'm not sure I understand, is the download tool itsel a snap?
[05:45] <zyga> hey :)
[05:45]  * zyga is a bit hurt today :)
[05:45] <pbek> good morning, zyga
[05:46] <pbek> yes, the tool downloads pdfs to the current folder and is snapped
[05:46] <pbek> https://github.com/pbek/lmdownload/blob/develop/snap/snapcraft.yaml
[05:47] <pbek> but of course downloading just works in the /home folder when the tool is started as snap
[05:47] <zyga> pbek: you can check if you are in /var/lib/snapd/void, if so, tell the user to do something else
[05:48] <zyga> pbek: that directory is used if the original working directory cannot be represented in a snap
[05:49] <zyga> mvo: some good news, the leak is gone
[05:49] <zyga> mvo: but the case is not fully cloesd, we need to talk to the kernel team
[05:51] <pbek> zyga: strange, the tool never told me that it was in that directory (I print out the directory where the tool wants to strore the pdf file). the directory was always the one I really was in bash, but I got a write permissions error when I was storing the file. the tool is written in go
[05:51] <zyga> pbek: it only does so if it is in a directory that cannot be represented
[05:51] <zyga> pbek: it may be in a directory that is represented but cannot be written to
[05:54] <pbek> zyga: ok, I can output a more propper error message then,  but I cannot get around the fact that the tool can only write to the home-folder while in snap confinement, right?
[05:54] <zyga> pbek: that's correct
[05:55] <zyga> pbek: snaps should wite to $SNAP_USER_DATA or $SNAP_USER_COMMON
[05:55] <pbek> thank you again for your patience, zyga!
[05:55] <zyga> pbek: eventually you may use xdg portals to write to more places
[05:55] <pbek> yes, I found that out already (and am using using it for storing settings)
[05:55] <mvo> zyga: hey, good morning. yeah, I saw the mail
[06:37] <mup> PR snapd#5050 opened:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5050>
[06:40]  * zyga tries to get through his inbox today
[06:54] <mup> PR snapd#5051 opened: snap,wrappers: address review feedback from #5043 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5051>
[07:01] <mup> PR snapd#5044 closed: 'system' nickname for 'core' in snap get/set (2.32) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5044>
[07:02] <mup> PR snapd#5045 closed: overlord/snapstate:  poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5045>
[07:16] <pstolowski> morning
[07:20] <zyga> hey pawel
[07:20]  * zyga spent all of saturday and sunday outdoors, walking and biking a lot
[07:20] <zyga> and now endures the pain in all kinds of places :)
[07:25] <mborzecki> if anyone feels like doing some reading https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001
[07:27] <zyga> mborzecki: yeah
[07:28] <mborzecki> btw. i think there's a bug in nm, some signal not emitted at the right time/place
[07:28] <mborzecki> at least when switching connection to metered from the cli, you don't see the Metered property changed on the main NM object
[07:28] <mborzecki> had to restart NM and then it got updated
[07:32] <ackk> hi, is there a fix for the pip error when building a python package with snacraft: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmp7036_63f', '/home/ack/canonical/src/gitlptools/parts/gitlptools/install/usr/bin/python3', '-m', 'pip']' returned non-zero exit status 1
[07:39] <zyga> mborzecki: replied
[07:39] <mborzecki> zyga: good points
[07:40] <kalikiana> good morning
[07:41] <zyga> Pharaoh_Atem: snap-confine package contains all kinds of things in fedora
[07:42] <zyga> Pharaoh_Atem: we should really disband that package and move those files over to snapd
[07:43] <mborzecki> disband ;) reminds me of civ
[07:50] <zyga> mborzecki: ha, yeah
[07:50] <zyga> disband militia in 2050 :)
[08:14] <Chipaca> moin moin
[08:15] <mborzeck1> wow, my network is flaky today
[08:16] <zyga> mvo: I will update the GitHub release page
[08:16] <zyga> although I plan to skip the .1 and .2 tarballs
[08:16] <zyga> just go to .4
[08:16] <zyga> I will use it to make the openSUSE release now
[08:19] <pedronis> mvo: hi, are you going to create .5 today?
[08:29] <mvo> pedronis: yes, I will do that hopefully ready around lunch time. do you have anything pending?
[08:30] <pedronis> no
[08:31] <pedronis> I saw you merged the doMountSanp/readInfo stuff
[08:32] <zyga> pedronis: can you update https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954 to include the latest status of that issue please
[08:33] <mvo> pedronis: yeah, I looked over it and it looked like a good idea to have it
[08:36] <pedronis> I'll update it in a bit
[08:36] <mborzecki> #3 is wontfix, #4 has had some error-catching fixes, #5 is almost fixed right?
[08:50] <mborzecki> any prs needing reviews?
[08:52] <zyga> Can you look at my trespassing pr
[08:53] <mborzecki> zyga: #4889 ? already did
[08:53] <mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
[08:53] <zyga> Ah, then no idea :-)
[08:53] <mborzecki> zyga: btw. it needs deconflicting
[08:53] <zyga> Oh thanks. I’ll do that shortly
[09:05] <mborzecki> #4983 needs a second review
[09:05] <mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
[09:12] <Chipaca> can't linux mint run classic snaps?
[09:14] <mborzecki> is there a way to tell what type of confinement is supported by the system, other than running `snap debug confinement` ?
[09:17] <pedronis> zyga: updated
[09:17] <zyga> thanks!
[09:18] <Chipaca> mborzecki: what do you mean?
[09:20] <Chipaca> mborzecki: http snapd:///v2/system-info | jq .result.confinement
[09:20] <Chipaca> mborzecki: ?
[09:20] <mborzecki> Chipaca: when you run `snap debug confinement` you actually see the confinement mode supported on the host (strict|partial), but I don't see a way to get this information using cli and not 'debug' command (which is hidden btw)
[09:22] <Chipaca> mborzecki: AFAIK there isn't
[09:22] <Chipaca> mborzecki: i mean, not via 'snap'
[09:22] <Chipaca> mborzecki: maybe we want it in 'snap version' or sth?
[09:23] <Chipaca> mborzecki: (what for?)
[09:23] <mborzecki> Chipaca: when the user runs hello-world.evil they will on unconfined system they will see the message 'If you see this line the confinement is not working correctly, please file a bug', but they may not have confinement in the first place
[09:24] <Chipaca> mborzecki: 'please file a bug with your distribution' :-p
[09:24] <mborzecki> i was thinking that we could update the message with eg. 'Try running snap version to check if your system supports confinement blah blah'
[09:25] <Chipaca> mborzecki: why not make .evil run 'snap debug confinement' or equivalent itself?
[09:26] <mborzecki> Chipaca: hm doable, but snap debug is hidden (or pretends to be at least), snap version would be nicer, https://paste.ubuntu.com/p/JRn57pP99Q/
[09:26] <Chipaca> mborzecki: is this on arch btw?
[09:27] <mborzecki> Chipaca: yes
[09:33] <Chipaca> mborzecki: is there any info we could put next to 'arch' in the output of 'snap version'?
[09:34] <Chipaca> i know it's rolling, but maybe, the time of the last update?
[09:34] <Chipaca> dunno
[09:34] <Chipaca> mborzecki: we could add confinement to distro info instead of as a new line if the new line is frowned on
[09:34] <mborzecki> Chipaca: - ?
[09:36] <mborzecki> Chipaca: https://paste.ubuntu.com/p/CGJZ9XPnSv/
[09:37] <Chipaca> mborzecki: aw :-) ok
[09:38] <zyga> IMO putting this on the distribution version is silly
[09:38] <zyga> let's just do it properly
[09:38] <zyga> confinement: seccomp(...), cgroup(device, freezer), namespace(mount), apparmor(...)
[09:41] <Chipaca> zyga: note that that's not exposed via system info yet
[09:41] <Chipaca> +1 to it or something like it if it were
[09:42] <mup> PR snapd#5050 closed:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5050>
[09:42] <mborzecki> zyga: seccomp(...) as in actions?
[09:42] <zyga> yeah, some version details there
[09:49] <mborzecki> hmm maybe we should have a separate `snap confinement` command or some --verbose switch to snap version, this is getting a bit verbose
[09:50] <mborzecki> then we could print apparmor features, seccomp actions, available cgroups (those that are mounted), and namespaces (those listed under /proc/$$/ns of snapd daemon)
[09:57] <zyga> mvo: updated https://github.com/snapcore/snapd/releases/tag/2.32.4
[09:57] <zyga> mborzecki: I think we have too many commands but I agree we should have some way to s how this
[09:58] <zyga> mborzecki: I doubt most users will undertstand more than I said initially on a single-line confinement value
[09:58] <mborzecki> ok, so maybe `confinement: (strict|partial)` in snap version is all that we need
[09:59] <mvo> zyga: thanks! .5 is rolling forward
[10:01] <pedronis> mvo: so .5 doesn't include 5051 ?
[10:02] <mup> PR snapd#5052 opened: cmd/snap: handle distros with no version ID <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>
[10:02] <mborzecki> Chipaca: ^^
[10:02] <mvo> pedronis: no, I think its fine, its cosmetic but if you feel strongly about it I can include it too
[10:04] <zyga> mvo: that's odd, we had that patched before
[10:04] <Chipaca> mborzecki: +1
[10:04] <zyga> ah
[10:04] <zyga> I see what the patch does now
[10:04] <zyga> mvo: ping me when .5 tarball is up
[10:05] <popeycore> diddledan: you havint trouble with irccloud today?
[10:05] <popeycore> fails to launch here on core stable, and I just get 3 dots in the screen constantly
[10:06] <pedronis> mvo: mostly fearing a bit of confusion  about the log,  and if we need to do a .6
[10:06]  * zyga does /o\
[10:06] <zyga> why would we need a 6?
[10:06] <pedronis> exactly, we don't know
[10:06] <pedronis> that's how that stuff happens
[10:09] <mvo> zyga: what is odd?
[10:09] <zyga> mvo: nothing, I misunderstood the output
[10:09] <zyga> mvo: - vs ""
[10:09] <mvo> pedronis: ok, I will pull it into release/2.32 just in case we need a .6
[10:09] <mvo> pedronis: it does make sense
[10:09] <zyga> mvo: https://github.com/snapcore/snapd/pull/5053
[10:09] <mup> PR #5053: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>
[10:10] <mvo> zyga: ta, I have a look. .5 is available in the ppa, one sec, I look for a direct link for you
[10:10] <zyga> mvo: FYI I have tested jj's fix and it's stable over extended periods of time
[10:10] <zyga> mvo: oh, neat
[10:10] <zyga> just push the tag, I'll do the rest :)
[10:10] <mvo> zyga: tag is pushed as well
[10:10] <mup> PR snapd#5051 closed: snap,wrappers: address review feedback from #5043 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5051>
[10:10] <mup> PR snapd#5053 opened: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>
[10:10] <mvo> zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8990918/+listing-archive-extra has the build
[10:10] <zyga> Son_Goku: good morning
[10:12] <popeycore> diddledan: must have been corrupted config, removed and reinstalled the snap and it's fine \o/
[10:12] <mup> PR snapd#5054 opened: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>
[10:15] <mup> PR snapd#5055 opened: release: 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5055>
[10:20] <zyga> mvo: https://github.com/snapcore/snapd/releases/tag/2.32.5
[10:21] <zyga> can you please check if I got the refresh/stop mode bits right
[10:23] <zyga> mvo: .5 failed to build for ppc
[10:23] <mvo> zyga: looking, I suspect a stray failure
[10:24] <zyga> pedronis: https://bugs.launchpad.net/snappy/+bug/1764069
[10:25] <mup> Bug #1764069: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:New> <https://launchpad.net/bugs/1764069>
[10:32]  * zyga -> walk
[10:32] <zyga> popey: notepad++ looks bad on high-dpi system
[10:32] <zyga> not sure if there's anything we can do to tell wine" hide"
[10:32] <zyga> "hidpi"
[10:32] <popey> Indeed
[10:33] <popey> We don't pass through pixel doubling in some apps
[10:33] <popey> not just WINE
[10:37] <Chipaca> popey: do you know what we need to pass through?
[10:37] <popey> i dont think there is anything we can do for WINE, but for some other apps, Wimpress mentioned looked bad on his hidpi machine, i think he knows
[10:38]  * Chipaca tries to make a joke about sulphites, and fails
[10:46] <mup> PR snapd#5052 closed: cmd/snap: handle distros with no version ID <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>
[10:46] <mborzecki> 5052 for 2.32 in case we do a .6 release? ;)
[10:48] <Chipaca> mborzecki: too much regression potential
[10:49] <Chipaca> :-p
[10:49] <pedronis> zyga: afaict that's a DNS problem
[10:53] <zyga> Ok
[10:59] <pedronis> mvo: this changelog line looks strange:   daemon: support 'system' as nickname of the core snapchange it is
[10:59] <pedronis> +      possible to do:
[11:00] <pedronis> change it is ...  seems spurious
[11:03] <mborzecki> pedronis: my fault, i tend to include how the command output looks like in the commit messages
[11:04] <pedronis> I'm not sure, the whitespace is wrong either way
[11:08] <mvo> pedronis: yeah, the whitespace there is incorrect. good catch
[11:08] <mvo> pedronis: look like the script that generates them has a bug there, I look into it
[11:16] <mup> PR snapd#5056 opened: cmd/snap: make confinement mode part of `snap version` output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5056>
[11:17]  * Chipaca trundles off in search of something to lunch
[11:23] <zyga> re
[11:23]  * zyga works on .5 release for opensuse
[11:25] <Chipaca> zyga: .6 is where it's at
[11:25]  * Chipaca runs
[11:25] <zyga> Chipaca: what?!?
[11:25] <zyga> are we doing a .6 now
[11:26] <zyga> is this what "eventually released" software is like?
[11:32] <pedronis> .<IP_ADDRESS>.1
[11:33] <mborzecki> approximating towards 2.33
[11:34] <zyga> Chipaca: should we use LazyUnmount= in our .mount units?
[11:34] <pedronis> effectively :)
[11:34] <pedronis> (that was about approx 2.33)
[11:35] <cachio> mvo, should I start testing .5 or I should wait for a .6?
[11:35] <pedronis> cachio: I don't think we plan a .6 atm
[11:36] <cachio> pedronis, ah, ok
[11:36] <cachio> thanks, I'll run beta validation for .5 in that case
[11:37] <cachio> mborzecki, hey, amazon linux image is ready
[11:37] <cachio> but you just can use it
[11:37] <cachio> if you use this spread
[11:37] <zyga> 2.32.4 is building for all opensuse systems now
[11:37] <cachio> mborzecki, https://github.com/snapcore/spread/pull/57
[11:37] <mup> PR spread#57: Adding preserve option for systems to keep the default image size <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/57>
[11:37] <cachio> mborzecki, beasuse the filesystem cannot be resized
[11:38] <mborzecki> cachio: what's the system name in spread.yaml?
[11:38] <cachio> mborzecki, basically it is not possible to shrink xfs filesystems
[11:39] <cachio>             - amazon-linux-2-64:
[11:39] <cachio>                 workers: 1
[11:39] <cachio>                 preserve: true
[11:39] <cachio> mborzecki, you can add that
[11:39] <cachio> with that branch
[11:41] <mborzecki> ok
[11:41] <cachio> mborzecki, I'll going the the kinesiology now, I'll explain better during the standup
[11:41] <mborzecki> cachio: i'll try to run it, thanks
[11:42] <cachio> mvo, there is not changelog for 2.32.4 -> 2.32.5
[11:45] <zyga> cachio: I made "some" changelog
[11:45] <zyga> cachio: https://github.com/snapcore/snapd/releases/2.32.5
[11:51] <zyga> Caelum: I updated snapd twice to 2.32.4 and now to 2.32.5
[11:51] <zyga> Caelum: let me know if you run into any issues
[11:51] <zyga> Caelum: although this release should be very stable now
[11:58] <zyga> mvo: maybe I could look at updating the debian package
[11:59] <zyga> Pharaoh_Atem: I will have a small selinux patch for you to review soon
[12:01] <zyga> does anyone know what networkd-dispatcher is for?
[12:02] <zyga> mvo: how is our upload to bionic like?
[12:02] <zyga> mvo: can we upload .5 now?
[12:02] <zyga> and similar question about xenial SRU
[12:03] <mborzecki> off to get the kids
[12:08] <popey> mborzecki: when you return - did you have any luck with nvidia on 18.04? I got from zyga  that it's somewhat of a lost cause?
[12:09] <zyga> popey: with classic snaps
[12:09] <zyga> popey: otherwise it should work
[12:09] <zyga> popey: with classic snaps it can work but the snap needs to understand the particular layout of the host
[12:09] <popey> This needs documenting somewhere.
[12:13] <zyga> popey: yes, no disagreement there
[12:15] <zyga> mvo: when we have more bases and more core18 things
[12:16] <zyga> mvo: I was thinking that we should drop the "series 16" line from snap version
[12:16] <zyga> we could show it on core devices
[12:16] <zyga> and actually show the name of the bootable base
[12:16] <zyga> I think right now it's not a very useful/informative thing
[12:18] <mup> Bug #1764069 changed: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:Invalid> <https://launchpad.net/bugs/1764069>
[12:18] <zyga> mvo: hey, is issue #5 solved with 2.32.5 now?
[12:20] <mup> PR snapd#4833 closed: tests: add a detector for kernel bug https://pad.lv/1755563 <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4833>
[12:23] <zyga> mvo: given that #5043 is for 2.32.x, do you still plan to make additional release (that is, .6)?
[12:23] <mup> PR #5043: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode <Critical> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5043>
[12:28] <mvo> zyga: reading backlog now
[12:30] <mvo> cachio: http://people.canonical.com/~mvo/core-changes/html/beta/2.32.4r4443_2.32.5r4486.html <- that looks ok (modulo missing space)
[12:31] <pstolowski|lunch> Son_Goku: hey! I've proposed go-udev https://bugzilla.redhat.com/show_bug.cgi?id=1567819 but just got a comment there that go packaging has been revamped? haven't yet looked at the guidelines
[12:32] <mvo> zyga: 5043 has lnaded in .5, no?
[12:32] <mvo> zyga: or what am I missing?
[12:32]  * kalikiana lunch
[12:33] <zyga> mvo: has it? the branch is open
[12:33] <zyga> ah
[12:33] <zyga> sorry
[12:33] <zyga> I mean 5054
[12:34] <zyga> mvo: I think my question was about the status of the forum post, if issue #5 is fixed let's mark it as solved
[12:34] <mvo> zyga: checking
[12:34] <Son_Goku> pstolowski|lunch, I think he's talking about this new form: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/blob/master/f/golang-gopkg-yaml.spec
[12:35] <mvo> mup #5054
[12:35] <mup> PR #5054: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>
[12:35] <zyga> mvo: offtopic, remember those 100s of threads? my bionic shows 11 threads in .5
[12:35] <mvo> zyga: 5054 is just cosmetic, but given the amount of questions about it I should have included it. its now in release/2.32 so *if* there is anohter one it will be in
[12:35] <mvo> zyga: I do remember that
[12:35] <zyga> mvo: understood now, thanks
[12:35] <pstolowski|lunch> Son_Goku: okay, i'll dig into the new guideline after lunch
[12:36] <mvo> zyga: thank you! so the 100s threads I don't see on my two bionic machines
[12:36] <mvo> zyga: so not sure what is going on there
[12:36] <Chipaca> huh, gnome software has a 'restart and install' button
[12:36] <mvo> zyga: #5 *should* be fixed in beta but I hope to get confirmation from a real world test case later today
[12:36] <mvo> Chipaca: for installing updates?
[12:37] <zyga> Chipaca: yes, for some years now :)
[12:37] <mvo> cachio: thanks for the sru validation!
[12:37] <Chipaca> mvo: I'm guessing what it describes as firmware is a bios update
[12:37] <zyga> Chipaca: it's a very old systemd/fedora/pkgkit feature
[12:37] <mvo> cachio: also yeah beta validation for .5 sounds great!
[12:37] <zyga> it's not related to firmware
[12:38] <zyga> it's related to a mode where all updates are downloaded but not installed, the machine reboots and goes into a special boot mode where systemd installs all updates and reboots back to normal mode
[12:39] <Son_Goku> pstolowski|lunch, guideline in question is documented here: https://fedoraproject.org/wiki/More_Go_packaging
[12:39] <Chipaca> zyga: I don't open gnome-software often (i've only recently had enough memory to keep it installed at all)
[12:41] <mvo> zyga: what is the link to the 18.04 post again? then I can update #5
[12:41] <zyga> mvo: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954
[12:42] <mvo> zyga: ta!
[12:43] <mvo> zyga: funny pr 4954 is also a fix for 2.32 as is the above forum topic (ok, maybe not that funny). i update it now
[12:43] <mup> PR #4954: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4954>
[12:44] <mvo> zyga: updated, thanks you
[12:46] <zyga> mvo: we have new pam and netplan
[12:48] <mvo> zyga: yeah, changelog looks mostly harmless
[12:48] <zyga> yes
[13:32] <kalikiana> re
[13:32] <popey> zyga: to be clear, the snap which I am having trouble with is _not_ a classic snap.
[13:36] <mborzecki> arch updated to 2.32.5
[13:36] <popey> I'll speak to snapcraft chaps, as it could be that.
[13:37] <mborzecki> popey: still mame thing?
[13:37] <popey> yeah
[13:37] <mborzecki> i posted the logs from friday in the LP bug report
[13:37] <popey> you mentioned rpath, but I dont know what *I* am doing wrong here
[13:37] <popey> yeah, I saw.
[14:04] <pstolowski> niemeyer: will you have some time to talk about hotplug after your current meeting?
[14:29] <tyhicks> mvo, zyga: hello! would you all be alright with the apparmor memory leak bug (bug #1750594) being fixed in the first SRU kernel of 18.04 or do you feel it is urgent enough that the 18.04 kernel be respun again before the release?
[14:29] <mup> Bug #1750594: Eventual OOM with profile reloads <AppArmor:Fix Committed> <https://launchpad.net/bugs/1750594>
[14:30] <zyga> tyhicks: I think it's not that critical, it only affects systems that run our test suite as far as we are aware
[14:30] <mup> PR snapcraft#2074 closed: Release changelog for 2.41 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2074>
[14:30] <zyga> it's annoying but not user-critical from my POV
[14:30] <zyga> mvo: ^
[14:30] <zyga> tyhicks: will live kernel patches fix it?
[14:30] <tyhicks> that's my understanding of the bug, as well
[14:30] <tyhicks> zyga: no, we don't plan to do a livepatch for it
[14:31] <tyhicks> we'd really only want to respin if it affected installs or made the out of box experience bad but, AFAIK, this bug doesn't show up in normal use cases
[14:32] <mvo> tyhicks: hi, in a meeting right now
[14:32] <mvo> tyhicks: let me reply as quick as I can
[14:32] <tyhicks> thanks
[14:35] <niemeyer> pstolowski: I'm just off and have a few minutes before lunch.. can you talk now?
[14:36] <pstolowski> niemeyer: yes
[14:36] <niemeyer> pstolowski: Ok, standup then
[14:47] <mup> PR snapd#5057 opened: tests: bring back one missing test in snap-service-stop-mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5057>
[14:53] <Chipaca> niemeyer: 10MB unaccounted for after creating a bolt db. Will continue digging.
[14:53] <Chipaca> RSS of a simple thing goes from 4MB to 14MB
[14:54] <niemeyer> Chipaca: That sounds very promising
[14:55] <niemeyer> Chipaca: One data point worth gathering is what happens if we open that same file in RO mode
[14:57] <Chipaca> niemeyer: 8MB rss
[14:57] <pstolowski> pedronis: hey, will you find some time this week to make another pass on iterface hooks PR? i've addressed your last comments
[14:58] <niemeyer> Chipaca: Unaccounted or total? That is, 4 to 12, or 4 to 8?
[14:58] <Chipaca> niemeyer: actually 10MB if the code to create it is still there, just not used
[14:58] <Chipaca> niemeyer: total
[14:58]  * Chipaca needs to step away for a bit, will bbl
[15:02] <Chipaca> niemeyer: time.Sleep -> 4MB, ro bolt: 8MB, ro bolt and rw code unused: 10MB; rw bolt: 14MB
[15:02]  * Chipaca afk
[15:04] <cachio> mvo, https://paste.ubuntu.com/p/Z59BDC4VWq/
[15:04] <cachio> running beta validation for 64 bits
[15:05] <cachio> mvo, it is like the system was rebooted after line 53
[15:05] <cachio> but it shouldn't
[15:06] <mvo> cachio: yeah, this is stange, anything in syslog?
[15:06] <mborzecki> Chipaca: hacked a small tool that prints package sizes (*.a that end up in the binary, unless go does some lto at the end) https://gist.github.com/bboozzoo/a363e591075cb4d4faae39b4066ac411
[15:06] <cachio> mvo, this is from syslog
[15:07] <cachio> mvo, I already saw that doing refresh from stable too
[15:07] <cachio> similar problem
[15:08] <mvo> cachio: uh uh
[15:08] <mvo> cachio: is this on a core device? or 16.04?
[15:09] <cachio> mvo, from journalctl https://paste.ubuntu.com/p/DsqmKfDGNv/
[15:10] <cachio> it is core-16-64
[15:10] <cachio> a vm
[15:10] <mvo> this is very uncommon
[15:10] <mvo> Apr 16 14:31:53 localhost.localdomain snapd[993]:  ERROR cannot open snap: open /tmp/snapd-sideload-pkg-105860667: no such file or directory
[15:10] <mup> PR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>
[15:10] <cachio> mvo, yes, first time I see this
[15:12] <mvo> cachio: confusing
[15:13] <cachio> mvo, this has more info https://paste.ubuntu.com/p/2ty37JM39W/
[15:15] <mvo> cachio: yeah, more info but still very confusing. I wonder what change from .4 -> .5 might cause this :(
[15:15] <niemeyer> Chipaca: Hmm.. are we keeping the file open? If we close the database and discard the structure, does the extra RSS memory go away?
[15:15] <oSoMoN> the latest build of the chromium snap on launchpad failed automated review in the store ("checksums do not match"), is that a known issue with the store/snapcraft, or could it be just that specific snap?
[15:15] <mvo> cachio: is it reproducible?
[15:15] <niemeyer> Chipaca: If it doesn't, that must be a bug
[15:15] <niemeyer> Chipaca: If it does, then we should probably just do that for the release
[15:15] <cachio> mvo, I don't know
[15:15] <cachio> I'll try
[15:15] <mvo> cachio: thank you!
[15:16] <niemeyer> Chipaca: Or at least keep it RO, if it impacts runtime of advice too much
[15:16] <mvo> cachio: it looks very fishy, is this in a VM ? or on real HW?
[15:16]  * niemeyer lunch
[15:16] <cachio> mvo, it is a vm
[15:16] <mvo> cachio: hm, hm, then that is double confusing
[15:17] <mvo> cachio: I was wondering if there might be some HW issue that triggered the reboot but not in a VM
[15:17] <mvo> (usually)
[15:17] <cachio> in parallel I was running i386
[15:17] <cachio> and it worked fine
[15:17] <mvo> cachio: it *might* be the oom issue but given that we have not seen that beforre on non !i386 its unlikely
[15:17] <mvo> cachio: ok, cool. at least that is good to know
[15:36] <oSoMoN> I just rebuilt the chromium snap again on launchpad, and got the same error (checksums do not match) : https://code.launchpad.net/~chromium-team/+snap/chromium-snap-stable/+build/193033
[15:36] <oSoMoN> known issue?
[15:37] <oSoMoN> ah, apparently it is bug #1763641
[15:37] <mup> Bug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>
[15:42] <oSoMoN> however the bug says that this shouldn't happen with snapcraft 2.40, but the chromium snap is built on LP and the log says it's using snapcraft 2.40 (deb)
[15:42] <mup> PR snapcraft#2079 opened: repo: catch error updating the package cache <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2079>
[15:43] <Caelum> zyga: nice, will look in a bit, and also post to factory list
[15:51] <zyga> Thanks!
[15:54] <pedronis> mvo: that's the new checking code in doMountSnap
[15:55] <mup> PR snapd#5055 closed: release: 2.32.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5055>
[15:57] <mvo> pedronis: oh, so it already caught a case where things did not quite work correctly?
[15:57] <mup> PR snapd#5058 opened: packaging: fix incorrectly auto-generated changelog entry for 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5058>
[15:57] <pedronis> mvo: maybe, or we are misunderstanding something
[15:58] <mvo> cachio: -^
[15:58] <cachio> mvo, not yet
[15:59] <mvo> pedronis: cool, I need to leave in a wee bit to play hockey but I will read backlog, would be great to learn if we introduced a regression
[15:59] <cachio> working on that
[15:59] <mvo> cachio: thank you
[15:59] <sergiusens> zyga, jdstrand any insight on https://paste.ubuntu.com/p/ZP6R7WM4Kz/ ?
[15:59] <mvo> cachio: just wanted to let you know that pedronis  has an idea where the error comes from but its not clear yet if it is just making an existing error visible or if its something new
[16:00] <cachio> mvo, ok
[16:00] <cachio> mvo, perhaps it is not new but it is cannot be reproduced easily
[16:01] <cachio> mvo, I'll make many executions today to see if I can reproduce it
[16:01] <cachio> mvo, pedronis  I'll keep you updated in case I find something
[16:02] <mvo> cachio: thank you!
[16:03] <mvo> cachio: thanks to pedronis we have much improved error checking around this area of code now, so maybe it surfaces something that existed before. I will read backlog, need to play hockey now
[16:03] <cachio> mvo, nice, enjoy it
[16:04] <mvo> cachio: thank you! yeah, I am excited
[16:10] <pedronis> cachio: it's strange because it seems we are rebooting in the middle of installing a local snap
[16:11] <pedronis> Chipaca: what happens if we reboot when installing a local snap?  it seems the snap is copied into /tmp, but tmp will be cleared on reboot
[16:13] <pedronis> cachio: am I misreading that there's a reboot going on at the start of that test?
[16:14] <pedronis> cachio: do we have a bug about stopping refreshes during some of the core tests?
[16:17]  * kalikiana eod
[16:19] <cachio> pedronis, I don't think so, but let me re-check
[16:28] <Chipaca> pedronis: AFAIK it fails if it happens before the (snap.Container).Install, otherwise it succeeds
[16:28] <Chipaca> pedronis: (that's the bit that copies the local snap into /var/lib/snapd/snaps iirc)
[16:28] <pedronis> it seems we are hitting the scenario in a test
[16:28] <Chipaca> hehe
[16:29] <pedronis> but I'm not sure why there is rebooting going on though
[16:30] <pedronis> Chipaca: do you agree that there is some system restarting going on here:  https://paste.ubuntu.com/p/DsqmKfDGNv/ ?
[16:31] <pedronis> there's too much starting, early, stuff and systemd talking about early boot stuff
[16:31] <Chipaca> niemeyer: we are not keeping the file open, and we do a commit and close on the db
[16:31] <pedronis> Chipaca: another theory is that snapd and the test starts before the cleaning of tmp happens
[16:31] <Chipaca> niemeyer: the only reason snapd uses boltdb is to write that databse, having it ro is like not having it
[16:32] <niemeyer> That's pretty awkward. Why would the memory stay resident
[16:32] <Chipaca> pedronis: looking
[16:32] <pedronis> bu that makes sense only if tmp is not a tmpfs
[16:32] <Chipaca> niemeyer: ＭＡＧＩＣ
[16:32] <niemeyer> Chipaca: I guess Go's GC
[16:33] <niemeyer> Chipaca: There is (was?) a method in the runtime package to "encourage" the GC to give memory back to the system
[16:34] <Chipaca> pedronis: no that doesn't look like early boot stuff
[16:34] <Chipaca> pedronis: it looks like snapd starts, and systemd says 'ok i'm done'
[16:34] <Chipaca> niemeyer: runtime.GC()?
[16:36] <niemeyer> Chipaca: No, that just kicks the GC.. let me check
[16:36] <pedronis> Chipaca: but we are after a reboot, right?
[16:37] <pedronis> Chipaca: otherewise there would not be that Reached target stuff
[16:37] <Chipaca> niemeyer: runtime/debug's FreeOSMemory?
[16:37] <niemeyer> Yes!
[16:38] <cachio> pedronis, now error on i386 https://paste.ubuntu.com/p/hkxVgZDZgk/
[16:39] <pedronis> I don't see an "error" in that log
[16:40] <Chipaca> niemeyer: it helps a little (14 -> 12 for rw, 10->9 for ro w/unused rw)
[16:40] <cachio> pedronis, this is for 64 bits https://paste.ubuntu.com/p/5MHzmfjJP8/
[16:41] <cachio> pedronis, no errors
[16:41] <cachio> but suddenly rebooted
[16:41] <pedronis> ah
[16:41] <pedronis> so we are getting reboots
[16:41] <cachio> pedronis, yes
[16:42] <pedronis> I don't see anything about "core" in those logs
[16:42] <pedronis> not sure what would provoke reboots
[16:42] <pedronis> that is new
[16:42] <pedronis> I understand why reboot would make other things fail
[16:42] <pedronis> but not what make us reboot
[16:42]  * pedronis -> dinner
[16:49] <Chipaca> blame spectre
[16:50] <oSoMoN> jdstrand, have you seen my comment on bug #1763641 ? If I read the bug correctly I shouldn't be seeing this error with snapcraft 2.40, but I am
[16:50] <mup> Bug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>
[16:50] <oSoMoN> I ran reviews-tool from edge on the snap and got no such error
[16:56] <zyga> sergiusens: did corebird work before?
[16:56] <zyga> PAM got updated recently but I don’t think we’d break abi
[16:58] <diddledan> I might have told the build to not prime libkrb5
[17:13] <pedronis> zyga: we are getting random reboots on .5
[17:13] <pedronis> cachio: we didn't see these reboots with .4 ?
[17:14] <zyga> Hmmmm
[17:14] <zyga> What do we know?
[17:14] <cachio> not for beta scenario at least
[17:14] <zyga> .5 has new PAM and nplan
[17:14] <diddledan> danke popey
[17:15] <popey> I didnt know we had source-checksum!
[17:15] <popey> TIL
[17:15] <diddledan> inorite
[17:15] <cachio> pedronis, I just saw some problems but for factory release to beta
[17:15] <zyga> Changelog from for .5 is not extensive, mainly new API and a bugfix
[17:16] <zyga> Is there any chance this is caused by new stop restart mode
[17:16]  * Chipaca afk
[17:16] <cachio> pedronis, zyga perhaps something else in the beta image it is causing this
[17:16] <cachio> new kernel
[17:16] <zyga> Oh
[17:16] <zyga> Which one?
[17:18] <zyga> I will be home soon
[17:21] <zyga> pedronis: who reported this and how?
[17:21] <pedronis> cachio
[17:21] <pedronis> running the validation
[17:21] <cachio> zyga, at least for dragonboard there was a new one
[17:22] <cachio> pedronis, there are 2 scenarios, first is to create a beta image  and run  the tests for that image
[17:22] <cachio> last execution I didn't see any error
[17:22] <cachio> pedronis, this time I saw this reboot
[17:23] <cachio> pedronis, but it is not failing 100% of the cases
[17:23] <cachio> so, perhaps the same error was present in the previous validation and I did not reproduce it
[17:24] <cachio> but today first exec I saw the errror
[17:24] <cachio> for core-16-64
[17:24] <cachio> and core-16-32 worked properly
[17:24] <cachio> 100% pass
[17:25] <zyga> cachio: on what hardware?
[17:25] <cachio> then I rexecuted both and both failed
[17:25] <cachio> I am running those on vms
[17:25] <pedronis> probably worth trying  a couple runs with .4 I suppose
[17:25] <zyga> So amd64/kvm
[17:25] <pedronis> to see if it's really .5
[17:25] <zyga> Yes
[17:25] <zyga> Let’s test .4 in the same host
[17:26] <cachio> ok
[17:26] <cachio> I'll do that
[17:26] <zyga> Thank you
[17:27] <pedronis> of course if it's new kernel we need to separate that somehow
[17:29] <zyga> It could also be the oom bug
[17:30] <pedronis> does it provokes reboots though?
[17:30] <zyga> It is disabled on 32bit systems but also happens on 64 big systems the same,  just takes longer
[17:30] <pedronis> or only errors?
[17:30] <zyga> It eats all ram over time till kernel crashes
[17:30] <zyga> With swap it’s a slow painful death
[17:30] <zyga> Without swap it is quick and clear
[17:32] <zyga> As an option we can do .6 with one of my workarounds
[17:47] <diddledan> for the coders among us, Brenden Eich on Javascript's evolution: https://www.youtube.com/watch?v=3-9fnjzmXWA
[17:54] <ogra_> there are coders among us ?
[17:57]  * popey steps back
[17:58] <kyrofa> Yes, but I heard the word "javascript" and ran
[17:58] <diddledan> :-p
[17:59]  * zyga looks at the reboot issue
[17:59] <zyga> pedronis, cachio: we have a forum thread for the problem?
[18:09] <cachio> zyga, no yet
[18:10] <cachio> zyga, I'll create it
[18:10] <zyga> thank you
[18:15] <zyga> the pastebin I read looks very weird, I doubt that's OOM
[18:16] <zyga> it looks like we really trigger a graceful shutdown shomehow
[18:16] <zyga> cachio: does it happen in one spot or in some random place during testing
[18:17] <cachio> the pattern that I saw in the syslog is
[18:18] <cachio> https://paste.ubuntu.com/p/DVJNqD5yHP/
[18:18] <cachio> in all the cases I saw something like this before the reboot
[18:19] <nacc> how can i change the owner of a snap in the store
[18:20] <cachio> zyga, and then this
[18:20] <cachio> https://paste.ubuntu.com/p/vTM3bYx2Ph/
[18:21] <cachio> I am running now 16-2.32.4 to see if I can reproduce it
[18:23] <cachio> zyga, I thinks  2/3 cases happened installing snapd
[18:23] <cachio> snaps
[18:23]  * zyga dinner, I will check soon
[18:26] <nacc> i specifically need to adjust the ownership of git-ubuntu, git-ubuntu-stable and git-ubuntu-beta away from my user
[18:41] <sergiusens> nacc: to canonical, snapcrafters or another individual user?
[18:45] <popey> nacc: post on the forum in the store category
[19:06] <kyrofa> Hey niemeyer, I can't get the LXD backend of spread to ever work for 17.10 or 18.04, they always end up failing with "2018-04-16 19:01:30 Discarding lxd:ubuntu-17.10 (spread-8-ubuntu-17-10), cannot connect: cannot connect to lxd:ubuntu-17.10 (spread-8-ubuntu-17-10): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain"
[19:06] <kyrofa> Any ideas?
[19:09] <om26er> popey: up ?
[19:09] <popey> om26er: yo!
[19:09] <om26er> oh boy you are always online, cool.
[19:10] <om26er> popey: sublime is broken and I hope we can land its fix ASAP.
[19:10] <om26er> we do have it published in edge channel but it won't start
[19:10] <popey> ok, let me take a look now.
[19:10] <popey> oh, it's classic. Are you on nvidia?
[19:11] <om26er> popey: no, Intel
[19:11] <popey> ok, lemme see
[19:14] <popey> ok, merged your PR, lets see what that builds
[19:14] <om26er> great stuff.
[19:14] <om26er> thanks popey
[19:14] <popey> np
[19:17] <zyga> cachio: any news
[19:18] <cachio> I ran 2.32.4 and I didn't see any error yet
[19:18] <cachio> zyga, I am re-executing now
[19:19] <zyga> can you upload the manifest
[19:19] <cachio> I created images using candidate
[19:19] <cachio> channel
[19:19] <cachio> and ran the tests
[19:19] <cachio> zyga, but no errors yet
[19:19] <cachio> zyga, the same it is failing 66% of the times on beta
[19:19] <zyga> cachio: so mvo suggested some ideas
[19:19] <zyga> can you upload the manifests somewhere
[19:20] <cachio> zyga, sure
[19:20] <zyga> mvo said it would be in /usr/share/dpkg/snap* something
[19:20] <zyga> also how big is the image
[19:20] <zyga> can you upload the failing image as you got it now
[19:21] <cachio> zyga, sure
[19:21] <zyga> thanks!
[19:21] <cachio> it is also very easy to generate it
[19:21] <cachio> and faster
[19:21] <cachio> with my wifi it could take long to upload
[19:21] <cachio> zyga, clone git@github.com:sergiocazzolato/validator.git
[19:21] <cachio> and then run
[19:22] <cachio> ./create.sh beta pc-amd64
[19:22] <cachio> ./create.sh beta pc-i386
[19:22] <zyga> trying
[19:22] <cachio> that will be faster
[19:23] <zyga> which ubuntu-image are you using?
[19:23] <zyga> from deb/snap
[19:23] <zyga> and which version
[19:23] <cachio> deb
[19:24] <cachio> ubuntu-image 1.3+16.04ubuntu2
[19:25] <zyga> I'm on 1.3+18.04ubuntu2
[19:25] <zyga> but I'll make an image and try this way first
[19:25] <zyga> if my image works can you upload your image
[19:25] <zyga> we can compare binary stuff inside
[19:25] <cachio> zyga, sure
[19:26] <zyga> maybe overnight
[19:26] <zyga> so we can analyze tomorrow
[19:31] <niemeyer> kyrofa: I think there is a patch from Saviq that fixes that, from long ago.. sorry for not having merged it yet.. will try to have a look today still
[19:31] <kyrofa> niemeyer, ah, excellent, okay thank you
[19:31] <zyga> cachio: my dpkg.list from /usr/share/snappy/dpkg.list http://paste.ubuntu.com/p/JWPqJFWH7D/
[19:31] <zyga> cachio: can you check if you have the same one
[19:32] <zyga> cachio: I'm running kernel 4.4.0-121-generic
[19:32] <kyrofa> Yep, that looks like it
[19:32] <cachio> ok
[19:39] <zyga> cachio: are you running the same thing on your test machine?
[19:40] <cachio> zyga, checking
[19:42] <cachio> zyga, the kernel is the same
[19:43] <cachio> zyga, same
[19:43] <cachio> the list is the same
[19:43] <zyga> ok, thanks
[19:43] <cachio> zyga, I am running again now
[20:01] <mvo> cachio: I just chatted with zyga and he told me about the reboot issues (and you did so as well earlier). I just checked, might be worth running with the kernel from stable, looks like the kernel in beta got released just today
[20:02] <cachio> mvo, you mean the kernel snap?
[20:03] <zyga> yes
[20:03] <mvo> cachio: yes
[20:03] <cachio> let me cehck that
[20:03] <mvo> cachio: I was just looking at the things that changed recently and noticed that this might be something
[20:04] <mvo> cachio: I will also run the testsuite against a freshly build image to see if I can find any clues
[20:04] <cachio> mvo, I just created a new image 20 minutes ago
[20:04] <cachio> and I am running again against this new one
[20:05] <cachio> so far no errors
[20:05] <cachio> mvo, but just 31/199 yes
[20:05] <cachio> yet
[20:06] <cachio> mvo, I am in i386 and I have  pc-kernel  4.4.0-120.144  111   beta      canonical  kernel
[20:07] <cachio> there is a new one in beta
[20:07] <cachio> 4.4.0-121.145
[20:07] <cachio> I'll regenerate also i386 image to see if the problem persist
[20:10] <mvo> cachio: thanks. I just build an amd64 image, is that correct?
[20:10] <mvo> cachio: aha, nice if you have an i386 image with an older kernel its interessting to see if the new kernel changes anything
[20:11] <cachio> mvo, :(
[20:11] <cachio> I just delete it
[20:11] <cachio> overwrite it
[20:12] <mvo> cachio: no worries
[20:26] <om26er> popey: https://github.com/snapcrafters/sublime-text/pull/10
[20:26] <mup> PR snapcrafters/sublime-text#10: Remove architectures stanza as it breaks auto builds <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/10>
[20:29] <om26er> ...and this https://github.com/snapcrafters/android-studio/pull/20 (though not urgent)
[20:29] <mup> PR snapcrafters/android-studio#20: remove architectures stanza <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/20>
[20:30] <popey> om26er: merged both
[20:30] <popey> thank you!
[20:31] <om26er> super!
[20:33] <om26er> we probably need to define some kind of "trust" chain (equivalent of MOTU/Core dev ?), so that we don't always have to bug you to get things landed.
[20:33] <popey> there are others who have access :)
[20:36] <om26er> apart from Martin, ev and you ? talking about snapcrafters repos only
[20:36] <popey> yeah, currently the three of us
[20:36] <om26er> its generally difficult to get a hold of flexiondotorg
[20:37] <popey> he's Wimpress  now :)
[20:37] <om26er> ev, I am not sure if he hangs around here.
[20:37] <popey> he doesn't
[20:37] <om26er> aah
[20:37] <popey> he hates irc
[20:37] <popey> like, passionately :)
[20:37] <Wimpress> It is I
[20:38] <Wimpress> And popey will burn in the embers of the heat death of the universe for being a lying #&$%
[20:38] <om26er> alright, its the two of you then ;-)
[20:38] <mvo> cachio: tests with stable kernel still going strong, I had one issue with python3 /nsap/network-bind-consumer/x1/bin/consumer eating all cpu and producing log messages I think we need to ensure in the relevant test that we kill it
[20:39] <Wimpress> I see the reference to hating IRC was not attributed to me.
[20:39] <Wimpress> #carryon
[20:39] <om26er> popey: Wimpress still when snaps take over the world, MOTU/Core dev like access may be necessary.
[20:39] <cachio> mvo, which is the test?
[20:39] <popey> om26er: well, ideally these would all be gone from snapcrafters and owned upstream :)
[20:39] <om26er> not today, but hopefully soon -__-
[20:39] <popey> :)
[20:40] <cachio> mvo, I am rnnning refresh scenario too
[20:40] <cachio> mvo, let's see how it goes
[20:41] <mvo> cachio: I'm not sure what test triggers this, just noticed
[20:41] <cachio> mvo, ok, I'll check it
[20:42] <om26er> popey: sublime text is good now
[20:42] <om26er> \o/
[20:42] <om26er> zyga: ^ its in edge
[20:42] <zyga> thanks!
[20:42] <zyga> mvo: I have a helper snap for redirecting systemctl
[20:43] <popey> om26er: alias works too?
[20:43] <om26er> popey: yep, subl
[20:43] <popey> wow, that launches fast
[20:43] <popey> om26er: released. thanks so much for all your work on this!
[20:43] <popey> Sorry it took so long.
[20:44] <popey> https://snapcraft.io/sublime-text
[20:44] <mvo> cachio: and I noticed sometihng interessting too, when I log into the VM while the test is running I see a "system is going gown" message, so there is a planned reboot triggered by a test, for me the planned reboot message starts at 22:38 and the following tests run then http://paste.ubuntu.com/p/d3xsB4KQMP/ so one of these tests triggers a change that includes core/kernel which triggers the reboot
[20:44] <om26er> popey: no problem, lets see if the upstream wants it now
[20:45] <cachio> mvo, weird
[20:45] <popey> maybe wait till we promote it and get more installs :)
[20:45] <cachio> I didn't see any reboot scheduled
[20:45] <cachio> well, there is a reboot schedulet but for a really long time
[20:46] <cachio> which should not be affecting the testst
[20:46] <om26er> sure
[20:46] <mvo> cachio: if you ssh into the machine, do you get Broadcasting messages as well?
[20:46] <cachio> mvo, no
[20:46] <cachio> I just saw in the logs
[20:46] <cachio> in the vm I didn't see any broadcastig message
[20:54] <zyga> mvo, cachio: sudo snap install systemctl-redirector --beta
[20:54] <cachio> zyga, what's this?
[20:54] <zyga> then touch /var/log/systemctl.fake.log
[20:55] <zyga> then sudo /snap/systemctl-redirector/current/bin/install
[20:55] <zyga> then run all tests
[20:55] <zyga> in the end collect the log file
[20:55] <zyga> this logs all invocations of systemctl
[20:55] <mup> PR snapd#5059 opened: tests: add pending shutdown detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/5059>
[20:55] <zyga> (reboot and all kinds of systemctl commands)
[20:55] <zyga> mvo: ideas for improvement welcome
[20:57] <mvo> zyga: thanks, I also pushed the above pR to break when we detect something that triggered a shutdown
[20:57] <zyga> yeah
[20:57] <zyga> looks good
[20:57] <mvo> zyga: lets attack it from multiple angles
[20:58] <mvo> cachio: iif you cherry pick the change from 5059 into your tree hopefully this also gives you an error when the shutdown is triggered
[20:58] <mvo> cachio: when running -debug maybe it gives us clues
[20:58] <zyga> cachio: if you run tests with this snap installed and with the install script invoked we should collect more info about what is going on
[20:58] <cachio> mvo, zyga, ok
[20:59] <cachio> I'll run it now
[20:59] <mvo> ta
[20:59] <zyga> thanks
[20:59] <mvo> I will soon need to crahs :/
[20:59] <mvo> but I start the tests now to see if I also notice anything
[20:59] <zyga> me too
[20:59] <mvo> and also login the VM to see any wall messages
[20:59] <cachio> with the last kernel seems to be working better
[20:59] <cachio> I didn't see any reboot yet}
[21:02] <zyga> cachio: I refreshed the systemctl-redirector snap to improve the log messages
[21:04] <cachio> ok, I'll start a run in 10 minutes
[21:04] <cachio> zyga, could you reproduce the error?
[21:04] <cachio> with the new kernel snap?
[21:05] <zyga> I didn't run full test run yet
[21:05] <cachio> zyga, I regenerated the image with the new kernel snap and I couldn't reproduce it anymore
[21:06] <cachio> zyga, wait
[21:06] <cachio> I did :)
[21:07] <zyga> did you install and configure my snap on your VM
[21:08] <cachio> zyga, https://paste.ubuntu.com/p/KMR33JvpyG/
[21:08] <cachio> not for this run
[21:08] <cachio> I'll do it for next one
[21:09] <zyga> Apr 16 20:45:41 localhost kernel: [ 3071.152512] modprobe: page allocation failure: order:7, mode:0x2080024
[21:09] <mup> PR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>
[21:09] <cachio> zyga, because if I install it during execution it is gonna be deleted on reset
[21:09] <cachio> zyga, yes
[21:09] <zyga> on reset?
[21:09] <zyga> ah
[21:09] <zyga> snaps are removed :/
[21:09] <zyga> looks like we ran out of ram
[21:09] <cachio> zyga, I am configuring vms with -m 1500
[21:10] <cachio> zyga so far it was enough
[21:11] <zyga> cachio, mvo: the allocation that failed was for 524288 bytes
[21:11] <zyga> not a lot
[21:11] <zyga> it looks like we ran out of ram, plain and simple
[21:11] <mvo> zyga: I also run with a 1500m VM, interessting
[21:11] <zyga> cachio: which kernel is that?
[21:11] <mvo> I keep it running
[21:13] <zyga> 4.4
[21:13] <cachio> zyga, pc-kernel                         4.4.0-121.145  113   beta
[21:14] <zyga> right, I see
[21:14] <zyga> guys, I need to go to sleep
[21:14] <zyga> cachio: before you EOD write what you know on the forum
[21:14] <cachio> zyga, sure
[21:14] <cachio> zyga, go to bed :)
[21:16] <zyga> Thank you. Good night!
[21:17] <mvo> zyga, cachio I need to crash as well, I will keep the tests running and check in my morning, I run with beta kernel and the shutdown detection patch from the PR above
[21:17]  * mvo waves
[21:37] <kyrofa> nacc, any idea why building git-ubuntu on arm64 would fail unable to find ffi.h? libffi-dev seems to be in stage-packages
[21:38] <kyrofa> Does it need to be a build-package as well?
[21:38] <kyrofa> Not sure how this is setup
[21:43] <nacc> kyrofa: log?
[21:45] <kyrofa> nacc, https://pastebin.ubuntu.com/p/mGjrtbBdfJ/
[21:50] <kyrofa> nacc, note that this worked fine on amd64
[21:51] <nacc> kyrofa: otp, looking now
[21:51] <kyrofa> No problem
[21:54] <nacc> kyrofa: i have no idea :/
[21:54] <nacc> kyrofa: i've never tried to build on arm64
[21:54] <kyrofa> nacc, ah, that's what I was going to ask
[21:54] <kyrofa> Okay, that's not unusual


[00:27] <Nivex> what's the bot/system/pony that runs Ubuntu IRC meetings with agenda items and todos and whatnot?