[07:56]  * enyc meows
[07:57] <enyc> sdeziel sarnold : fwi there is now  https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1949605   ... the snap and in any case  .deb package will need to go up to 91.3.x and be backported (looks like given ubuntu packaging that should be straightforward to at least focal).
[07:57] <enyc> err fwiw,  thankyou for previous replies anyhow!
[18:09] <sarnold> enyc: thanks


[00:09] <arooni> is there an ubuntu terminal that supports the OSC 52 ;; would allow set-clipborad in terminal
[00:21] <sarnold> probably xterm does; maybe urxvt ..
[00:27] <nacc> rbasak: not sure if you want to just land that fixlet, or try and build it locally to sanity check it is ok? I suppose in the edge channel it's ok to just land it
[00:28] <nacc> ahasenack: as to the error messages, remember when running from the snap it is only looking in the snap's env, so your system packages are irrelevant
[00:28] <nacc> ahasenack: it's just a generic message, which implies that it wasn't able to load pygit2 successfully
[00:28] <nacc> s/load/import/
[01:00] <xamithan> Just joined to grab topic links and say cheers it fixed my issue~
[06:01] <lordievader> Good morning
[09:12] <^kiokoman^> wellcome2
[09:12] <^kiokoman^> wrong chat sorry
[10:10] <rbasak> cpaelzer, ahasenack: git-ubuntu edge fixed I believe
[10:10] <cpaelzer> rbasak: rev 429 or newer?
[10:12] <cpaelzer> rbasak: yep working on 429 now
[10:12] <cpaelzer> thank
[10:12] <cpaelzer> s
[11:39] <DK2> hello, im trying to setup a hostroute on ubuntu 18.04
[11:39] <DK2> http://pastebin.centos.org/782911/
[11:40] <DK2> is the relevant snippet, however when trying to access the 10th subnet im getting no route to host
[11:40] <DK2> it works perfectly fine when i set a <IP_ADDRESS>/24 ip on the server, however i need the ip to be <IP_ADDRESS>/24
[11:40] <DK2> any ideas?
[11:42] <Ool> DK2: you need to have a gateway in the network
[11:42] <DK2> it is on-link
[11:42] <DK2> both subnet are in the same vlan
[11:43] <Ool> same vlan perhaps but not in the same network
[11:43] <DK2> but shouldnt hostroutes work for exactly cases like this?
[11:43] <Ool> how can you can to the <IP_ADDRESS>/24 where is your gateway from <IP_ADDRESS>/24 ?
[11:43] <Ool> how can you go *
[11:44] <DK2> there is no gateway, it should use <IP_ADDRESS>
[11:48] <Ool> for me, or the dest is on the same network => no gateway, or is another network => gateway
[11:52] <DK2> https://netplan.io/examples#directly-connected-gateway
[12:05] <DK2> but doesnt seem to work
[12:17] <frickler> thedac: coreycb: any update on https://bugs.launchpad.net/bugs/1750121 ? my suspicion is that this is somehow dependent on your CI/charms setup
[13:12] <DK2> so, http://pastebin.centos.org/782951/
[13:12] <DK2> how can i add a second route here?
[13:12] <DK2> i also want <IP_ADDRESS>/24 to go trough .254
[13:59] <sveinse> How strong is the recommendation to keep ubuntu-server on a server? I'd like to remove some of the packages this packages depends on a smaller server.
[14:07] <ahasenack> rbasak: I thought there was a way to pass extra arguments when using git-ubuntu build-source, like genchange's -v<version>, but I don't see that in the --help output. Is there a way?
[14:10] <ahasenack> ah, I think it's anything at the end that is not recognized as a git-ubuntu flag?
[14:10] <ahasenack>     if len(args.rem_args) != 0:
[14:10] <ahasenack>         logging.warning(
[14:10] <ahasenack>             "Appending specified flags (%s) to `dpkg-buildpackage %s`. "
[14:11]  * ahasenack tries that
[14:37] <runelind_q> I'm running 16.04.4.  Whenever I reboot after a kernel upgrade, I run apt autoremove, then it makes me reboot again :|
[14:37] <runelind_q> any way to get around that?
[14:45] <genii> Run the autoremove after the kernel upgrade but before rebooting the first time
[15:18] <runelind_q> good point
[15:50] <RoyK> runelind_q: seems like an apt bug if you ask me
[15:50] <runelind_q> I agree, it shouldn't need to happen.
[15:50] <runelind_q> there were bugs filed about it in 2015
[15:52] <RoyK> runelind_q: well, ubuntu doesn't really have a medal in bug fixing
[15:53] <runelind_q> why fix bugs when you can add more features? ;p
[16:09] <RoyK> runelind_q: exactly
[16:09] <RoyK> runelind_q: I don't use ubuntu much on servers anymore - I went back to debian
[16:10]  * RoyK knows he's swearing in church
[16:14] <nacc> ahasenack: -- ...
[16:14] <nacc> ahasenack: (cf. `git ubuntu build --help`)
[16:15] <runelind_q> I do feel like there are much more kernel security updates in Ubuntu compared to CentOS/RH, maybe they're just not fixing them ;p
[16:16] <nacc> ahasenack: i'm not sure if i've tested buildsource -- , tbh
[16:16] <nacc> ahasenack: but i think it does work, and needs a MP to add that to the help epilogue
[16:17] <RoyK> nacc: -- ... means "MS" ;)
[16:18] <nacc> RoyK: I don't know what you're talking about.
[16:18] <nacc> RoyK: you mean morse code?
[16:19] <RoyK> :)
[16:38] <nacc> rbasak: ok, looks like git-ubuntu.self-test now passes in edge?
[16:38] <nacc> ahasenack: --^ fyi
[16:52] <ahasenack> nacc: it worked (-- ...)
[16:57] <thedac> frickler: We still see that problem. By chance are you at the OpenStack Summit? I'd love to show you what we are seeing.
[16:58] <thedac> We are not doning anything special in our CI setup. And again the intial peering setup works. It is only after restarting the neutron-bgp-dragent that we see the error.
[17:00] <nacc> ahasenack: cool
[17:11] <frickler> thedac: yes, that's because the original bug also doesn't appear in the default initial setup. I only discovered it when setting up a second network node with another dr-agent
[17:11] <frickler> thedac: and no, I'm not at the summit
[17:12] <thedac> frickler: what info can I provide to move forward? I can tar up neutron.conf etc
[17:15] <frickler> thedac: a description how to reproduce would be good. or would there be a way to hold a failed CI node and let me debug it? like we could do on openstack CI? ;)
[17:17] <thedac> frickler: oK, I'll do a completely manual setup based on the testing documentation (what our CI automation is built on) and see there is any difference.
[17:17] <thedac> The CI env is inaccessible, unfortunately.
[17:18] <frickler> thedac: is the testing doc public?
[17:19] <thedac> frickler: yes, https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html
[17:20] <thedac> Our CI scripting is almost exactly that ^^^
[17:20] <thedac> Only point to highlight is the neutron-bgp-dragent is on its own node.
[17:23] <frickler> thedac: ah, that's one of the things I asked on LP. you need to install the same pkg version of the bgp agent on the neutron server, because it serves the RPC call from there
[17:23] <frickler> my patch changes both sides and if they are not in sync, you get that error
[17:24] <thedac> frickler: they both have the same version of python-neutron-dynamic-routing
[17:29] <nacc> ahasenack: cool, can you file a bug that build-source's help doesn't mention it, and fix it? :)
[17:45] <frickler> thedac: hmm, o.k., so I guess it's best if you try to reproduce it manually. for me, the only attempt where I saw your error was when I upgraded from current pkgs to proposed and didn't restart neutron-server. maybe you could try that restart anyway, just to confirm that you don't have the same situation
[17:46] <thedac> frickler: ok, I'll do a few more tests and report back on the bug
[17:51] <Nik736> Hi guys, I am struggling with converting my network config to netplan, anyone around that could assist? Would appreciate it, thanks :) Old Config: https://pastebin.com/YjMRhhAa New Netplan Config that does not work: https://pastebin.com/2msq7hYV
[17:54] <ahasenack> rbasak: would you be interested in this mysql 18.04 bug https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1772337 that has apparmor DENIED messages in dmesg? (https://launchpadlibrarian.net/371151468/Dmesg.txt)
[18:16] <sarnold> name="/etc/my.cnf"
[18:16] <sarnold> first, that's a silly path mysql, and you should feel bad for using it.. second, that has the look of something that ought ot have been included in profiles ages ago..
[18:17] <teward> wait, that path looks wrong...
[18:17] <teward> shouldn't it be pulling from the mysql conf roots?
[18:17] <teward> (mysql i mean)
[18:18] <teward> ahasenack: rbasak: ^
[18:18] <ahasenack> apyes, it looks wrong, I commented as such in the bug
[18:18] <sarnold> that last line is a bit funny too, mysqld running with fsuid 1001??
[18:18] <ahasenack> it looks like a heavily modified install, even the initscript was changed
[18:19] <teward> sounds less like a package bug and more of a "PEBKAC User Error" bug
[18:19] <sarnold> wow
[18:21] <teward> is "This system is so heavily modified from the defaults it's not supportable by us" a viable response?  (Just saying)
[18:22] <teward> either of you know if it's possible to get details out of an autopkgtest run?
[18:22] <teward> beyond the logs that it gives normally
[18:22] <ahasenack> teward: a local run?
[18:23] <teward> ahasenack: no, autopkgtest.u.c
[18:23] <teward> but if i have to do a local run of this package I will be displeased
[18:23] <ahasenack> teward: there are artifacts you can download, but that's it
[18:23] <teward> searx breaks with the nginx upload, but the error is uwsgi-level
[18:23] <teward> ahasenack: where?
[18:24] <teward> found it nevermind
[18:24] <teward> grrr yeah the artifacts won't help me here...
[18:25] <teward> ahasenack: if I were to do a local run of this, I have two questions:
[18:25] <teward> (1) how would i do that, and
[18:25] <teward> (2) is there a way to get into the environment if it fails to actually get debugging info?
[18:25] <ahasenack> teward: http://autopkgtest.ubuntu.com/ and go find your package there
[18:25] <swein> on a 18.04 server install. When the ISO is booting some services take forever to start and hangs. Snap server, kernel message of scsi_eh blocked for 120 seconds
[18:25] <swein> anyone seen that
[18:25] <ahasenack> (it's not loading here, btw)
[18:25] <ahasenack> swein: the first time you boot it? And it's the "live server" install?
[18:25] <swein> ahasenack: yes liv eserver install and on first ISO boot
[18:25] <ahasenack> I haven't seen that, sorry
[18:25] <ahasenack> but scsi_eh blocked could be a hardware problem, everything ok with your disks?
[18:25] <teward> yay net lag >.<
[18:25] <ahasenack> teward: (2) not that I know of
[18:26] <ahasenack> teward: (1) is doable, is that in cosmic?
[18:26] <swein> nothing is connected to the megaraid sas controller, it's just plugged in
[18:26] <teward> ahasenack: yes, though my system here is Xenial
[18:26] <teward> ahasenack: TL;DR I need systemctl status -l output
[18:26] <ahasenack> teward: do you know if the test needs a vm, or if it can run in a container? What does d/t/control say?
[18:26] <teward> ahasenack: E: Unknown, not my package
[18:26] <teward> still digging
[18:26] <teward> ahasenack: if you want to help I'd gladly welcome it
[18:26] <ahasenack> which package is it?
[18:27] <teward> ahasenack: searx, its autopkgtests were triggered by NGINX uploads.
[18:27] <teward> somehow
[18:27] <ahasenack> sure, sounds more exciting than a pile of 10 apache bugs from 200x
[18:27] <teward> ahasenack: the nginx direct autopkgtests all succeed
[18:27] <teward> so it's not an nginx-level issue
[18:27] <teward> digging into the failed tests the error is in the uwsgi package when it tries to load
[18:27] <teward> and because of systemd its error message is suppressed saying "Run systemctl status uwsgi for details"
[18:28] <ahasenack> it's usual, I half lost my mind chasing down triggered tests when I uploaded snmp once
[18:28] <ahasenack> got all the way down to bind9 even
[18:28] <teward> heh
[18:28] <teward> well I value a second set of eyes
[18:28] <teward> actually oddly enough
[18:28] <ahasenack> ok, so isolation-container, looks like a lxd is fine
[18:28] <teward> it looks like the test has always-failed since 2018-05-05
[18:28] <ahasenack> I'll run the tests, but just so you know,
[18:29] <ahasenack> you would first run autopkgtest-build-lxd to prepare a lxd image for autopkgtest to use
[18:29] <ahasenack> and then autopkgtest -s -U /path/to/package (or package name) -- lxd <lxd-image-name>
[18:29] <ahasenack> more or less
[18:29] <ahasenack> going from memory
[18:29] <ahasenack> -s is for it to stop when it fails and give you a shell
[18:30] <ahasenack> -U is to run apt-upgrade, since the image you prepared earlier could have been prepared weeks ago
[18:30] <teward> ahasenack: indeed.  Though Xenial won't work for it.
[18:30] <teward> i'll need to use my bionic box
[18:30] <ahasenack> it should work on xenial
[18:30] <teward> those scripts don't exist in Xenial
[18:30] <ahasenack> it probably has the old name, that's all
[18:30] <ahasenack> adt<tab> I think
[18:30] <teward> there it is
[18:30] <ahasenack> don't ask
[18:30] <ahasenack> I wouldn't know why
[18:30] <teward> not going to :p
[18:31] <teward> heh lol
[18:31] <teward> ahasenack: doesn't work with snapped LXD 3.x
[18:31] <teward> apparently
[18:31] <ahasenack> the build-lxd one?
[18:31] <teward> mhm
[18:31] <teward> at least, not on Xenial
[18:31] <ahasenack> do you have a cosmic image already?
[18:32] <ahasenack> you need to give it the name of an image
[18:32] <teward> ahasenack: ah, well, there's no Cosmic images for me to pull
[18:32] <ahasenack> it will boot it, make modifications, and give you a new one
[18:32] <teward> i already tried
[18:32] <teward> so
[18:32] <ahasenack> lxc image copy ubuntu-daily:cosmic local:
[18:32] <ahasenack> try that
[18:32] <teward> *now* it works
[18:32] <teward> when was taht turned on?
[18:32] <teward> it didn't work last week o.O
[18:32] <ahasenack> yesterday I think
[18:32] <ahasenack> or fri
[18:33] <ahasenack> correct
[18:33] <teward> ah that explains it
[18:33] <teward> *waits for the image to copy down*
[18:34] <teward> (autopkgtests annoy me a little but meh)
[18:38] <teward> hmm i think my system derped, gonna reboot
[18:54] <teward> ahasenack: any idea how long it takes for autopkgtests to build the LXD?  Seems to be taking a while, even though I already copied down the image :/
[18:55] <teward> and as soon as I say that it completed :/
[18:55] <teward> *kicks self*
[18:56] <Blueking> what memory stick tool you use to format for dos boot to do bios upgrade ?
[19:00] <sarnold> last time I needed a dos boot disk I think I found a freedos image somewhere that worked
[19:01] <Blueking> hmm,, what format tool ? :P
[19:02] <sarnold> I just used dd to write the thing to a usb stick
[19:02] <sarnold> if you actually have to *format* something, maybe the mtools package can help
[19:02] <sarnold> I hope we still package it, any way ;)
[19:06] <ahasenack> teward: I reproduced the failure locally: https://pastebin.ubuntu.com/p/BZDCmwgcX4/
[19:06] <teward> ahasenack: it looks like it's a uwsgi failure
[19:06] <teward> not an nginx one
[19:07] <ahasenack> is libapache2-uwsgi involved?
[19:07] <teward> it shouldn't be
[19:07]  * ahasenack checks
[19:07] <teward> ahasenack: can you pull `systemctl -l status uwsgi`?
[19:07] <ahasenack> right, not installed
[19:07] <ahasenack> teward: https://pastebin.ubuntu.com/p/D3fk24tVwJ/
[19:07] <ahasenack> super helpful
[19:08] <teward> ahasenack: no, but that points at the issue not being an NGINX related issue
[19:08] <teward> and probably a package-level issue
[19:08] <teward> what's odd is it only fails on three archs
[19:09] <teward> ahasenack: it's interesting to note, too, that searx's autopkgtest has been failing for a while
[19:09] <teward> this is the first time it's on my radar though, the last time it worked was prior to may 5th
[19:11] <ahasenack> I have no idea how these things work
[19:16] <ahasenack> teward: I get a core dump, actually
[19:16] <ahasenack> ERROR: apport (pid 10684) Tue May 22 16:16:15 2018: apport: report /var/crash/_usr_bin_uwsgi-core.0.crash already exists and unseen, doing nothing to avoid disk usage DoS
[19:18] <teward> interesting.
[19:18] <teward> ahasenack: maybe this needs to be opened as a critical level bug against searx
[19:19] <ahasenack> searx or uwsgi?
[19:19] <teward> since the searx tests have failed for everything since may 5th
[19:19] <teward> ahasenack: searx
[19:19] <teward> unless uwsgi's autopkgtests also fail
[19:20] <teward> though i don't see any
[19:20] <teward> ahasenack: nginx wouldn't have any effect on uwsgi
[19:20] <ahasenack> well, what crashed was uwsgi
[19:20] <ahasenack> I'm checking with debug packages to see if the backtrace shows another library
[19:20] <teward> ack
[19:20] <teward> ahasenack: if we can rule out nginx as the cause, then I can rest easy, but I'll have to ask the release team to force ignore those tests for this run
[19:21] <ahasenack> hm, no debug packages for searx
[19:21] <teward> ahasenack: are there any for uwsgi?
[19:21] <ahasenack> yes, I installed them, but the backtrace is still invisible in the critical area
[19:21] <ahasenack> let me paste
[19:21] <teward> hmm
[19:21] <ahasenack> teward: https://pastebin.ubuntu.com/p/8DYQSxg93t/
[19:23] <teward> ahasenack: it sounds to me then like this is a searx bug
[19:23] <teward> let me check something
[19:23] <teward> i have an example uwsgi somewhere, and a container that i can test with heh
[19:24] <teward> ahasenack: if this simple 'hello world' uwsgi app works, then we can blame the searx package
[19:24] <teward> if it fails as well, then we can blame uwsgi
[19:24] <teward> either way, nginx is not an issue
[19:25] <ahasenack> teward: still, that was never enough of an excuse to not chase dep8 failures :)
[19:26] <ahasenack> it's all part of making ubuntu better :)
[19:26] <teward> indeed
[19:28] <teward> ahasenack: happen to have the old commands for adt to run autopkgtests in LXD?  Or should I get a Bionic environment sooner than later :P
[19:28] <ahasenack> try adt<tab><tab>
[19:28] <ahasenack> I think the arguments did not change
[19:29] <teward> dumps me this: https://paste.ubuntu.com/p/64TkTfWDC8/
[19:29] <teward> so adt isn't an app, but there's adt-sub apps so IDK
[19:32] <ahasenack> I'm almost thinking it's a permission problem
[19:32] <ahasenack> teward: right, so first adt-build-lxd
[19:32] <teward> ahasenack: i did
[19:32] <teward> it completed
[19:32] <ahasenack> I think it's just adt-build-lxd <your-cosmic-image>
[19:32] <ahasenack> then do lxc image list, see if you have an autopkgtest specific image now
[19:33] <teward> adt/ubuntu/cosmic/amd64 is there, yes
[19:33] <ahasenack> cool
[19:33] <ahasenack> now we want adt-run
[19:33] <ahasenack> I use:
[19:34] <ahasenack> -U -s -o ../dep8-output --apt-pocket=proposed source-package-name -- lxd adt/ubuntu/cosmic/amd64
[19:34] <ahasenack> try that
[19:34] <ahasenack> -U: upgrade
[19:34] <ahasenack> -s: stops on fail
[19:34] <ahasenack> -o: output report
[19:34] <ahasenack> --apt-pocket: tell it to use proposed, like ubuntu does
[19:34] <ahasenack> -- lxd: virt type
[19:34] <ahasenack> and the last is the lxd image to use
[19:34] <genii> <cough pastebin cough>
[19:34] <ahasenack> I was typing, not copying and pasting :)
[19:35] <ahasenack> loophole!
[19:35]  * genii eye-rolls
[19:35] <sarnold> haha
[19:37] <teward> ahasenack: worked with adt-run -U -s -u somefilepath --apt-pocket=proposed source-pkg-name --- lxd adt/ubuntu/cosmic/amd64
[19:37] <teward> triple dash o.O
[19:37] <ahasenack> oh, right
[19:37] <ahasenack> why not
[19:38] <ahasenack> "-u somefilepath" seems wrong, -u is for user
[19:38] <teward> typo
[19:38] <teward> -o
[19:38] <ahasenack> unless that changed between adt and what we have now
[19:38] <ahasenack> ok
[19:41] <teward> ahasenack: confirmed it's not an uwsgi segfault, a simple uwsgi app works
[19:41] <teward> so the issue is searx
[19:49] <teward> ahasenack: it looks like this was synced in from Debian directly
[19:49] <teward> what would you suggest for filing the bug against this?
[19:50] <ahasenack> did your test finish?
[19:50] <ahasenack> the adt one
[19:50] <ahasenack> I'm trying to start it manually in a terminal, to see when it segfaults, but am having a hard time with that
[19:50] <teward> actually looks like LXD exploded
[19:50] <teward> hang on
[19:51] <ahasenack> it's not a simple initscript
[19:51] <ahasenack> traced it to this
[19:51] <ahasenack> May 22 16:44:30 autopkgtest uwsgi[6741]: + start-stop-daemon --start --quiet --pidfile /run/uwsgi/app/searx/pid --exec /usr/bin/uwsgi -- --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini --daemonize /var/log/uwsgi/app/searx.log
[19:51] <ahasenack> but that incurs in other errors
[19:57] <teward> ahasenack: running local test now, lxd decided to fubar initially
[19:58] <ahasenack> ok
[19:58] <teward> also troubleshooting some major chaos with a VPN tunnel at work so, split-attention
[19:59]  * ahasenack fetches a snack
[20:05] <teward> ahasenack: i think we have to contact the Debian people on that
[20:05] <teward> because why they do taht in the test
[20:06] <teward> instead of install uwsgi, drop it in the app area, and then call the uwsgi command which runs this as a daemon, (not sure if it can?) it is failing on that command
[20:06] <teward> which is unique to the test
[20:09] <teward> let me poke this a bit more
[20:10] <teward> ahhhhh interesting
[20:19] <ahasenack> back
[20:37] <teward> ahasenack: hmm i found something interesting
[20:37] <teward> i need to do some debugging thoguh
[20:38] <teward> ahasenack: i think i found the breakage
[20:38] <ahasenack> sounds good
[20:38] <ahasenack> do tell
[20:38] <teward> possibly.
[20:39] <teward> ahasenack: the problem is I can't find the explicit init.d to call
[20:39] <teward> but when I try and run uwsgi directly things're not being placed in there proper
[20:39] <teward> so it might not be the proper 'test'
[20:40] <teward> is there a way to see the CLI call made to execute uwsgi by systemd or start-stop-daemon?
[20:40] <ahasenack> I tried
[20:40] <ahasenack> closest I got was to insert a "set -x" in /etc/init.d/uwsgi just before the do_* call for start
[20:40] <ahasenack> and then follow in /var/log/syslog
[20:41] <ahasenack> I got to the start-stop-daemon line I pasted above, at 19:51:15 utc
[20:41] <ahasenack> but that line in itself didn't segfault
[20:42] <teward> hmm
[20:43] <teward> ahhh i think i know what's going on...
[20:43] <ahasenack> sounds even better
[20:45] <teward> ahasenack: i manually tried the same command to start uwsgi
[20:45] <teward> and found this in syslog: May 22 20:44:35 adt-virt-lxd-dxnxve systemd[1]: uwsgi.service: Failed to reset devices.list: Operation not permitted
[20:45] <ahasenack> I see that all the time in lxds
[20:45] <teward> and when it tries to start apport crash handler it fails too
[20:45] <teward> ahasenack: the problem is, that's the only 'error' i can see
[20:45] <teward> it doesn't actually start the process
[20:45] <teward> now, when I call the start-stop-daemon line directly?
[20:45] <teward> it errors with missing file/folder in the python app
[20:46] <teward> ahasenack: can we call the package broken and blacklist it?
[20:46] <teward> i don't think there's any rdeps
[20:46] <teward> and this is a 'new' package
[20:46] <teward> new as of Bionic
[20:46] <ahasenack> teward: I get this in a vm: https://pastebin.ubuntu.com/p/r7D9thcbwK/
[20:46] <teward> ahasenack: i got that too
[20:46] <teward> check /var/log/uwsgi/app/searx.log
[20:46] <teward> what do yo usee?
[20:46] <ahasenack> I have no clue how uwsgi is supposed to work
[20:47] <teward> ahasenack: neither do I, but if any of the python underneath fails to launch uwsgi itself explodes
[20:47] <teward> and that could trigger a segfault with a core dump
[20:47] <ahasenack> teward: I get this: https://pastebin.ubuntu.com/p/P34n2BVckK/
[20:47] <ahasenack> but note this is running as root, a normal user cannot create that log file
[20:47] <ahasenack> I was thinking that had something to do with it
[20:48] <teward> it could
[20:48] <ahasenack> whatever happened, those vars didn't get expanded looks like
[20:48] <teward> yeah it didn't
[20:48] <teward> which it wouldn't from a shell
[20:48] <ahasenack> I have /run/uwsgi/app/searx/ but it's empty
[20:49] <teward> well from a shell it drops you into it might not
[20:49] <ahasenack> deb-confnamespace comes from /usr/share/uwsgi/conf/default.ini
[20:50] <teward> and that's not being expanded, it seems, by uwsgi properly.
[20:54] <teward> aha
[20:54] <teward> ahasenack: ran the uwsgi command that should start uwsgi properly
[20:54] <teward> getting a permission denied on a bind
[20:55] <teward> underneath gdb
[20:55] <ahasenack> teward: it seems to be failing in debian too: https://ci.debian.net/packages/s/searx/
[20:55] <teward> ahasenack: should we raise a 'critical' or equivalent bug in Debian?
[20:55] <teward> because it's not fit to exist
[20:55] <teward> if autopkgtests are dying
[20:55] <teward> and it's going to block other things here in Ubuntu from migrating from proposed
[20:55] <teward> nginx included
[20:55] <ahasenack> I think a bug is ok. debian doesn't yet gate on dep8 tests like we do
[20:55] <teward> ahasenack: bug on it here?
[20:56] <teward> (Ubuntu)
[20:56] <ahasenack> I'd suggest a bug over there, and you can use that bug to ask an AA to let it pass for now
[20:56] <ahasenack> a bug here too also works, having both linked
[20:58] <teward> ahasenack: so, serious-level bug on Debian about autopkgtest failures which suggest the application doesn't work?
[20:58] <teward> 'cause that's where i'm at now
[20:59] <ahasenack> I don't know enough to say if the app doesn't work or not, but a segfault is bad
[20:59] <ahasenack> but I didn't check debian to see if it segfaults there too
[20:59] <teward> ahasenack: i'm inclined to open it here in Ubuntu and say it segfaults horribly
[20:59] <ahasenack> the fact that the test fails in the same place is suggestive, though
[20:59] <teward> and the autopkgtests make it fail horrible.
[20:59] <ahasenack> ok
[20:59] <ahasenack> do you have the crash file too?
[20:59] <ahasenack> in /var/crash?
[21:00] <teward> ahasenack: no but I have gdb trace when you have the application run under uwsgi directly
[21:00] <teward> so see if this works for you...
[21:01] <ahasenack> how did you run it?
[21:01] <teward> gdp --args "uwsgi -s 4000 --ini /usr/share/uwsgi/conf/default.ini --ini /etc/uwsgi/apps-enabled/searx.ini"
[21:01] <teward> gdb*
[21:01] <teward> which has uwsgi directly run the application as configured on port 4000
[21:02] <teward> that gave a permission denied in gdb
[21:02] <teward> after dropping root privs to uid/gid 33
[21:02] <ahasenack> I start that as root and it exits after failing to write to that /run directory
[21:03] <teward> let me replicate again
[21:04] <yee__> dose anyone have a solution how to fix this problem? https://askubuntu.com/questions/1002933/vmware-dhcp-no-internet-access, same problem in here as well https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
[21:05] <teward> ahasenack: i'm getting the 'no such file or directory' error myself... except when I set the env vars manually
[21:05] <teward> so...
[21:05] <ahasenack> which vars?
[21:06] <teward> UWSGI_DEB_CONFNAME and UWSGI_DEB_CONFNAMESPACE
[21:06] <teward> UWSGI_DEB_CONFNAME='searx', UWSGI_DEB_CONFNAMESPACE='app'
[21:06] <teward> which uwsgi conf says it uses to populate the 'fake' options
[21:07] <ahasenack> that's all way over my head :)
[21:07] <teward> the workers all segv
[21:07] <teward> *but* if I run the same command under gdb...
[21:07] <teward> oooh actually
[21:08] <teward> i don't get any usable traceback this time
[21:08] <teward> ahasenack: interesting to note though that i get all the segfault calls, and it constantly respawns
[21:08] <ahasenack> systemd would do that, but if you started it directly, I don't know what would do it then
[21:09] <teward> ahasenack: if I start uwsgi directly, I replicate the segfaults
[21:09] <teward> replicating what systemd does to populate those vars
[21:09] <teward> and it segfaults
[21:09] <teward> i'm going to open a critical bug here that has to do with the segv
[21:09] <teward> because both of us are getting crash dumps
[21:10] <teward> yep i get a crash dump for uwsgi as well
[21:10] <teward> in the autopkgtests area
[21:11] <ahasenack> cool, upload the crash dump too then
[21:13] <teward> ahasenack: do you think using 'Critical' as the bug importance would be a bad thing?
[21:13] <teward> this autopkgtest breaks a lot of things...
[21:14] <ahasenack> probably. I tend to reserve critical bugs sparingly
[21:14] <teward> well the package simply doesn't work
[21:14] <ahasenack> someone in #ubuntu-release can let it pass, but that's why having a bug is important, so when they add it to their script they can link to the bug
[21:14] <teward> indeed
[21:15] <ahasenack> also link to https://ci.debian.net/packages/s/searx/ saying it's failing there as well
[21:15] <teward> ahasenack: should I just upload the crash file direct or should I apport-collect the bug number?
[21:15] <ahasenack> try apport-bug first
[21:15] <ahasenack> it might pick up the crash file
[21:17] <Blueking> flashed bios... now I am missing interface em2   the other em1 are there
[21:17] <teward> ahasenack: nope, fails.
[21:17] <ahasenack> fails because no network?
[21:18] <teward> apport-bug says no pending crash reports
[21:18] <Blueking> shouldn't interface be visible with ifconfig -a ?
[21:18] <ahasenack> Blueking: probably, try also "ip -l" to be sure
[21:18] <teward> ahasenack: unless you know how I can put this crash right into the proper package
[21:18] <teward> because it's crashing uwsgi not searx so it'd pick up as an uwsgi bug
[21:19] <Blueking> another thing.. when I look into bios  bios tells me I can have 1,2,3 all cores enabled, I've set 'all'  but only 2 cores visible in ubuntu ?
[21:19] <ahasenack> teward: try https://pastebin.ubuntu.com/p/BQNwmkdC8y/
[21:19] <Blueking> ip -l
[21:19] <ahasenack> it's fine if it picks it up as a uwsgi bug, that can be changed
[21:19] <teward> mmkay.  though i already filed the searx bug
[21:19] <ahasenack> then just attach the crash file
[21:20] <ahasenack> Blueking: you checked by looking in /proc/cpuinfo or what?
[21:20] <Blueking> ahasenack yes
[21:20] <teward> aaand now I can't close out of this :/
[21:20] <Blueking> munin reports 2 core too
[21:21] <ahasenack> Blueking: counted "processor" lines?
[21:21] <Blueking> processor 0 processor 1
[21:22] <Blueking> Intel(R) Xeon(R) CPU E3-1230L v3 @ 1.80GHz
[21:22] <ahasenack> Blueking: check output of dmesg
[21:22] <ahasenack> there are many messages related to cpus and cores
[21:23] <ahasenack> look perhaps for "smpboot"
[21:23] <ahasenack> or "CPU"
[21:25] <Blueking> how I filter out cpu on dmesg ?
[21:26] <ahasenack> type dmesg|less
[21:26] <ahasenack> then use the "/" key and type CPU
[21:26] <ahasenack> "/" is to search
[21:26] <ahasenack> when done, use "q" to quit
[21:26] <Blueking> dmesg | cpu
[21:26] <ahasenack> "dmesg | less" means send the output of dmesg to the input of less
[21:26] <ahasenack> no
[21:26] <Blueking> like this ?
[21:26] <ahasenack> dmesg | less
[21:27] <ahasenack> dmesg and less are different programs
[21:27] <ahasenack> we are using | to connect them
[21:27] <Blueking> shorewall spams..
[21:27] <ahasenack> then you can use the arrow keys, page up/down keys, to navigate over the contents of dmesg
[21:27] <ahasenack> what's the first line you have?
[21:28] <ahasenack> it should be something like
[21:28] <ahasenack> [    0.000000] Linux version 4.15.0-22-generic (buildd@lgw01-amd64-013) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 (Ubuntu 4.15.0-22.24-generic 4.15.17)
[21:31] <ahasenack> teward: I gotta go
[21:31] <ahasenack> see you tomorrow
[21:32] <teward> ahasenack: yep, no problem.
[21:32] <Blueking> ahasenack [    0.166957] x86: Booting SMP configuration:
[21:32] <Blueking> [    0.166962] .... node  #0, CPUs:      #1
[21:32] <Blueking> [    0.182986] x86: Booted up 1 node, 2 CPUs
[21:32] <teward> bugs're filed though you were pinged in another room
[21:33] <teward> !pastebin
[21:33] <ahasenack> teward: I subscribed to them
[21:33] <teward> Blueking: FYI, use a pastebin for multiline.  ahasenack is also having to leave right now.
[21:33] <teward> ahasenack: ack
[21:33] <teward> i also poked -release
[21:33] <teward> to see if they can handwave the failures for nginx
[21:33] <Blueking> :/
[21:33] <ahasenack> teward: someone can, might not even have to be an archive admin
[21:33] <ahasenack> I'm never sure about those permissions
[21:33] <teward> ahasenack: indeed, they'd [robably be in -release anyways
[21:33] <teward> or point me where I need to go
[21:33] <ahasenack> yep
[21:34] <teward> i know infinity and others have power :P
[21:34] <teward> anyways, i'm off myself
[21:34] <ahasenack> cya
[21:35] <nacc> Blueking: what is your question?
[21:35] <Blueking> nacc  my mobo's bios tells me I have 4 core  where I can define how many core that can be used 1,2,3 or all
[21:36] <Blueking> I've defined 'all'
[21:36] <Blueking> so why ubuntu only see 2 core ?
[21:38] <nacc> Blueking: what motherboard and cpu is it?
[21:38] <Blueking> nacc : [    0.162663] smpboot: CPU0: Intel(R) Xeon(R) CPU E3-1230L v3 @ 1.80GHz (fam: 06, model: 3c, stepping: 03)
[21:39] <Blueking> https://www.supermicro.com/products/motherboard/Xeon/C220/X10SLM_-F.cfm
[21:40] <nacc> Blueking: can you pastebin the output of `hwloc` ?
[21:40] <Blueking> hwloc not installed
[21:40] <nacc> Blueking: ok, install it :)
[21:41] <Blueking> no connection to net right now :/
[21:41] <Blueking> just updated bios and some issue with one of interfaces
[21:44] <Blueking> one got to do something after installing new bios ?
[21:44] <Blueking> on ubuntu
[21:45] <nacc> not usually
[21:53] <Blueking> nacc: in /dev I see i2c-0 i2c-1 i2c2... i2c-7     total eight.. are these about cores/threads ?
[21:54] <nacc> Blueking: no
[21:54] <nacc> Blueking: those are i2c devices https://en.wikipedia.org/wiki/I%C2%B2C
[21:54] <Blueking> ok
[22:10] <jose-phillips> hey any idea
[22:10] <nacc> jose-phillips: about what?
[22:11] <nacc> Blueking: it's relatively rare these days for Linux to not see all the resources on a system
[22:11] <jose-phillips> i have this sceneario
[22:11] <jose-phillips> im trying to setup a network where
[22:11] <jose-phillips> interface eno1 and eno2 are iscsi multipath
[22:12] <jose-phillips> and i need create a bonding to reach nfs of both interfaces
[22:12] <jose-phillips> if i leaave the ip configured on eno1 the bonding driver kill automatically the network on eno 1
[22:13] <jose-phillips> or at least i need one vlan interface that can choose use one interface or anther one
[22:13] <jose-phillips> using ububtu 18.04
[22:13] <jose-phillips> ubuntu server
[22:20] <jose-phillips> complicated eh..
[22:21] <nacc> "interface eno1 and eno2 are iscsi multipath" seems incorrect to me
[22:21] <nacc> iscsi is for disk storage
[22:21] <jose-phillips> i know
[22:21] <jose-phillips> the server is 100% diskless
[22:21] <sarnold> iirc you'd use corosync or pacemaker to do your interface failover
[22:23] <jose-phillips> so they depend to keep alive eno1 and eno2
[22:23] <jose-phillips> or at least eno1 or eno2
[22:23] <jose-phillips> now i need to set a extra interface that can manage anther subnet for nfs and should be active-backup
[22:23] <jose-phillips> in case the target can't be reached for example eno1
[22:24] <jose-phillips> use eno2
[22:24] <jose-phillips> with the same ip address
[22:24] <jose-phillips> bonding not work because when i do bond on the interface kill the interfaces that is using
[22:24] <jose-phillips> oto take it in the bond0 interface
[22:36] <Blueking> nacc ubuntu server back online
[22:37] <nacc> Blueking: cool
[22:38] <Blueking> hmm hwloc does what ?
[22:39] <nacc> Blueking: prints detailed info about the hardware topology
[22:40] <Blueking> installed hwloc   tries it  says no command ?
[22:40] <nacc> Blueking: sorry, try `lstopo`
[22:41] <Blueking> no cpu info there
[22:42] <Blueking> nacc http://paste.ubuntu.com/p/s9GXrnVwth/
[22:43] <Blueking> nacc http://paste.ubuntu.com/p/vSw2gghjr6/
[22:44] <Blueking> nacc http://paste.ubuntu.com/p/dTgxRCp5k3/
[22:47] <sarnold> xnox: hey any chance you still have access to the Better ARK? Blueking here's got a processor that shows up as 4c8t on ARK, but linux only ever sees two cores
[22:48] <Blueking> sarnold: supermicro mobo's bios I can define how many core to be active  1,2,3, all  this implies 4 core ?
[22:49] <sarnold> Blueking: what happens if you fiddle with that setting? :)
[22:49] <sarnold> set it to 1, boot, see what happens, set it to two, tec..
[22:49] <Blueking> tried set to 3 core no changes
[22:49] <Blueking> I can test 1 core
[23:00] <Blueking> 1 active core (bios)  ubuntu still replied 2 core
[23:04] <Blueking> any idea nacc sarnold ?
[23:04] <sarnold> no :(
[23:07] <Blueking> never seen more than 2 core on this xeon cpu...   could it be early versions of this cpu came out with only 2 core ?
[23:29] <JanC> Blueking: I looked into that yesterday, and this model is always 4-core as far as I could tell
[23:29] <JanC> there is a E3-1220 or something like that which only had 2 cores
[23:31] <JanC> maybe your BIOS is hacked and it hides 2 cores used by some bitcoin farm  ;-)
[23:32] <sarnold> I did vaguely consider it might be counterfeit cpu .. but does anyone do that any more?
[23:36] <JanC> I'm pretty sure these CPUs are too expensive to design a clone of for that to be lucrative
[23:37] <JanC> (or even something close enough that it isn't obvious)
[23:38] <JanC> if anything, a batch that got the wrong fuses blown and identifies incorrectly seems more likely then
[23:42] <sarnold> ahhh yes that's far more plausible
[23:42] <JanC> or just some bad firmware
[23:43] <JanC> I guess trying a firmware (UEFI) upgrade (if available) would be a good idea
[23:44] <sarnold> JanC: heh I think that was yesterday's project
[23:44] <Blueking> I'll post a question to shop where I bought mobo and cpu
[23:45] <JanC> Blueking: are you using an Ubuntu kernel?
[23:45] <JanC> or something you compiled yourself?
[23:45] <Blueking> ubuntu kernel
[23:47] <JanC> I suddenly wonder if Intel disabled cores to fix meltdown/spectre issues?  :P
[23:49] <sarnold> disabling HT was rumoured to help with something or other.. but cores? I think it'd take disabling all-but-one to make a difference
[23:49] <Blueking> just checked billing note from shop -> Intel Xeon Quad-Core E3-1230Lv3 1.8GHz 8MB, 25W, LGA1150
[23:49] <Blueking> bios says 1,2,3,all
[23:49] <JanC> sarnold: depending on how the cache is shared
[23:50] <Blueking> could it be bad connect between cpu and socket ?
[23:50] <JanC> I doubt it would work at all then
[23:51] <JanC> I wonder if you have accidentally set a kernel parameter or something
[23:51] <Blueking> I don't have experience to do so..
[23:51] <sarnold> ohho, what's /proc/cmdline look like?
[23:52] <Blueking> hmm /proc/cmdline ?
[23:52] <Blueking> I might have to test with windows OS ..
[23:52] <JanC> ?
[23:53] <Blueking> see if windows can access all 4 cores
[23:53] <JanC> is there anything unusual in /proc/cmdline ?
[23:54] <Blueking> http://paste.ubuntu.com/p/PMr3bYJcGy/
[23:54] <sarnold> that's /proc not /proc/cmdline :)
[23:55] <Blueking> http://paste.ubuntu.com/p/mh5T6PqVZP/
[23:55] <JanC> hm
[23:55] <Blueking> I uploaded new intel microcode recently
[23:58] <JanC> I wonder why this has intel_pstate=disable
[23:58] <sarnold> well, it was a good theory. bummer.
[23:58] <Blueking> something suspicious ?
[23:58] <JanC> not suspicious
[23:59] <Blueking> intel_pstate=disable ?


[00:30] <huwshimi> Hello. I have a snap that installs, but doesn't expose the command. I can see the file for the command in places like stage/usr/bin, but once the snap is installed the command does not exist. Snap here: http://paste.ubuntu.com/23105293/
[00:30] <huwshimi> Any guidance appreciated!
[05:48] <mup> PR snapd#1772 opened: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/1772>
[05:51] <mup> Bug #1617890 opened: 2.12 crashes with latest ubuntu-core snap due to re-exec <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1617890>
[05:57] <mup> PR snapd#1773 opened: firstboot: disable firstboot on classic for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/1773>
[06:27] <mup> PR snapd#1774 opened: tests: add test for current snapd with ubuntu-core/edge interactions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1774>
[06:37] <dholbach> hey hey
[06:38] <liuxg> I have python as plugin in both parts, when building the projects, some files are copying to the same locatiton, resulting conflicts like http://paste.ubuntu.com/23106210/. how can I avoid this issue?
[06:43] <tvoss> good morning :)
[07:05] <dholbach> liuxg, maybe file a bug report on snapcraft?
[07:05] <liuxg> dholbach, yeah, I think so. I will do that, thanks
[07:05] <dholbach> thanks
[07:13] <liuxg> dholbach, I have reported it at https://bugs.launchpad.net/snapcraft/+bug/1617907
[07:14] <mup> Bug #1617907: Two python parts in the same snapcraft.yaml result in not installing the python correctly <Snapcraft:New> <https://launchpad.net/bugs/1617907>
[07:14] <dholbach> great
[07:16] <mvo> pitti: hi, quick question - we have the netplan config in snapd now, its great. its also static, so I would like to ship it just in the ubuntu-core-config (which is only installed on ubuntu-core devices)  package as a static /etc/netplan/00-default.yaml  package
[07:17] <mvo> pitti: eh, static file of course. any reason not to do that?
[08:03] <pitti> mvo: what does it contain?
[08:03] <zyga> good morning
[08:03] <pitti> mvo: I'm not a big fan of constant config files in /etc, I must say
[08:03] <pitti> mvo: if we start doing that, I'd rather add support for /lib/netplan/*.yaml
[08:16] <mup> PR snapd#1769 closed: snap: add export-key --account= option <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1769>
[08:33] <tvoss> mvo: hey, did you have a chance to raise the topic of vendorizing go build deps for snapd?
[08:50] <mvo> pitti: support for /lib/netplan/*.yaml sounds great, if its not too much work, I can also look at it if you are too busy
[08:50] <pitti> mvo: already at it
[08:50] <mvo> tvoss: not explicitely, we talked about it in the team recently and the concensus was that we want to do it
[08:51] <mvo> pitti: cool, thanks! for context: https://github.com/snapcore/snapd/pull/1765/files#diff-7c06ac92ab14c8f3ece674037573ceddR14 is the config we want to ship by default
[08:51] <mup> PR snapd#1765: many: move network initialization to a separate service <Created by mwhudson> <Conflict> <https://github.com/snapcore/snapd/pull/1765>
[08:51] <pitti> mvo:/url 2
[08:51] <pitti> mvo: oh - DON'T ever ship that in a package
[08:52] <pitti> mvo: this means that you cannot ever reconfigure any device, as 00-* is always the first match
[08:52] <tvoss> mvo: ack, will join your standup today then (if I can make it)
[08:53] <mvo> pitti: ok, so this needs to be 99-ubuntu-core-defaults if we move it to a package?
[08:53] <pitti> mvo: mwhudson discussed that with slangasek and me recently; AFAIR the idea was to only create that file in /run/ if there is no actual config (i. e. before running console-conf), and as soon as there is some /etc/netplan/* then not generate it any more
[08:53] <mvo> pitti: and it would be in a package that is only installed on core systems, is that ok?
[08:53] <mvo> pitti: oh, I see /run - hm
[08:54] <pitti> mvo: actually, the name of the *.yaml is not that relevant
[08:54] <pitti> there is no natural order in the yaml definitions
[08:55] <pitti> other than that later definitions override previous ones
[08:55] <mvo> pitti: hmhm, ok, let me ponder a bit if we only want this in /run under these conditions that changes the picture a little bit
[08:55] <pitti> mvo: I suggest talking to mwhudson, he is also working on this and it seems that there is a lot of overlap and not enough coordination
[08:56] <mvo> pitti: yeah, I started talking to him and he directed me to you :) thanks, I think I know all I need to know for now
[09:04] <pitti> mvo: anyway, suport for /lib/netplan/ committed, it would also be useful for things like lxc (bridge configs)
[09:08] <mvo> pitti: \o/
[09:13]  * ogra_ grins about https://github.com/snapcore/snapd/pull/1573
[09:13] <mup> PR snapd#1573: asserts/tool,cmd/snap: introduce hidden "snap sign" <Created by pedronis> <https://github.com/snapcore/snapd/pull/1573>
[09:14] <ogra_> we have a secret handshake !
[09:16] <ogra_> cjwatson, is there any known way for me to find out a revision number for a snap that was auto-uploaded by LP ?
[09:17] <ogra_> (would be nice to be able to map a revision to a build number and log)
[09:29] <ogra_> i see i get a "manage this package in the store" link after successful upload on the UI page, but i dont see anything in the LP api that would map to this
[10:04] <zyga> ogra_: do you have a 3.4 based kernel around on any device?
[10:04] <pitti> ogra_: manual wifi bringup with wpasupplicant and networkd works fine; now it's a SMOP :)
[10:04] <zyga> ogra_: would you mind doing ls -ld /proc/$$/ns/mnt for me?
[10:04] <ogra_> zyga, snappy device ? no, i dont
[10:04] <pitti> ogra_: (and SMOWTC)
[10:05] <zyga> ogra_: no, any device
[10:05] <zyga> ogra_: (phone is good)
[10:05]  * ogra_ hugs pitti and looks up acronyms :)
[10:05] <pitti> ogra_: I just made it up -- SMO writing test cases :)
[10:05] <ogra_> :)
[10:06] <pitti> ogra_: oh, "simple matter of programming" (but that's rather common)
[10:06] <zyga> hah
[10:06] <zyga> it's all doable, it's all software ;)
[10:07] <ogra_> zyga, i only have 3.10 :/
[10:08] <cpaelzer> Hi, I was asked by elopio to move some bits out of my waf integration test belonging to PR 716 to be an external part
[10:08] <zyga> ogra_: that's actually good, is that ubuntu phone?
[10:08] <ogra_> yes
[10:08] <cpaelzer> I thought I updated https://wiki.ubuntu.com/snapcraft/parts the right way, but something is missing
[10:08] <ogra_> ooh ...
[10:08] <zyga> ogra_: thanks, I was worried that older kernels are still around
[10:08] <cpaelzer> is there any update cycle or anything I have to wait until I can discover a part there?
[10:08]  * ogra_ just found one machine in his network running 2.6.37
[10:09] <ogra_> i guess its time to upgrade that one
[10:09] <ogra_> zyga, they are ... u just dont have any active phone with them anymore
[10:09] <ogra_> s/u/i/
[10:09] <ogra_> zyga, only the last two devices had 3.10
[10:10] <ogra_> nexus and the bq phones are all 3.4
[10:10] <cpaelzer> no matter if the part is already right yet (not sure on that part) I'd have expected that "snapcraft update && snapcraft search wafdemo" gets me something, but it doesn't
[10:17] <mup> PR snapd#1775 opened: Add thumbnailer interface <Created by fkaleo> <https://github.com/snapcore/snapd/pull/1775>
[10:59] <ogra_> cjwatson, there is an update on bug 1608432 for you
[10:59] <zyga> mwhudson: around?
[10:59] <mup> Bug #1608432: snaps with type: os should allow publishing of .manifest files <launchpad-buildd:New> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432>
[11:08] <mup> PR snapd#1773 closed: firstboot: disable firstboot on classic for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1773>
[11:20] <Son_Goku> morning
[11:22] <zyga> Son_Goku: hey
[11:23] <Son_Goku> hello
[11:33] <Son_Goku> zyga, so, did you get anywhere on the path relocation?
[11:43] <zyga> Son_Goku: yes, it basically works now, I need to work on selinux support in systemd to let the service start now
[11:55] <ogra_> mvo, btw, not sure you have seen https://github.com/snapcore/classic-snap/pull/4
[11:55] <mup> PR classic-snap#4: merge recent changes that are in the store, improve bin/classic <Created by ogra1> <https://github.com/snapcore/classic-snap/pull/4>
[11:55] <ogra_> (sorry for the ping in the wrong channel before)
[12:05] <Son_Goku> zyga, you might want to look at the abrt service policy as an example
[12:05] <Son_Goku> https://github.com/fedora-selinux/selinux-policy/tree/rawhide-contrib
[12:22] <mvo> ogra_: checking
[12:23] <mup> Bug #1618004 opened: Need a classic-bin interface to see classic binaries <Snappy:New> <https://launchpad.net/bugs/1618004>
[12:23] <mvo> ogra_: thanks, nice one, merge - I assume you alrady pushed it?
[12:24] <ogra_> mvo, not yet, doing so now (i didnt know how you wanted to handle the missing bits)
[12:25] <mvo> ogra_: I think its was a forgoten push on my side, sorry for that
[12:25] <ogra_> NP
[12:42] <mup> PR snapd#1683 closed: osutil: fix create-user on classic <Reviewed> <Created by jaymell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1683>
[12:42] <mup> PR snapcraft#763 opened: Include /sbin and usr/sbin in wrappers <Created by lool> <https://github.com/snapcore/snapcraft/pull/763>
[12:51] <arges> elopio: I see bug 1616157 has been verified, should I tag it 'verification-done'? And mvo is it ready for release into xenial?
[12:51] <mup> Bug #1616157: [SRU] 2.13 <verification-needed> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1616157>
[12:56] <mup> PR snapd#1776 opened: image: snap assertions into image <Created by pedronis> <https://github.com/snapcore/snapd/pull/1776>
[12:57] <mup> PR snapd#1723 closed: image: prepare-image: import snap assertions as well <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1723>
[12:57] <mup> PR snapd#1777 opened: osutil: tweak the createUserTests a bit and extract common code <Created by mvo5> <https://github.com/snapcore/snapd/pull/1777>
[13:03] <mvo> arges: I have a look, in a meeting right now
[13:03] <Kaleo> zyga, hey :) thanks for the review
[13:04] <Kaleo> zyga, looks like I forgot a commit :)
[13:05] <ogra_> hmm, no sergio today ?
[13:05] <Kaleo> zyga, please ignore the entire PR until I add that commit :)
[13:06] <Kaleo> zyga, and voila
[13:06] <Kaleo> zyga, I'm sorry I wasted your time
[13:08] <Kaleo> zyga, about the snap/implicit.go, is there some documentation of what it means?
[13:11] <zyga> Kaleo: I'll check it after the meeting
[13:11] <Kaleo> thanks
[13:11] <zyga> Kaleo: look at snap/implicit.go and look what's there, there's no docs but I have a blog post about it on zygoon.pl (the lastest one)
[13:11] <zyga> Kaleo: please check it out
[13:12] <Kaleo> cheers
[13:14] <jdstrand> lool, tianon: hey I read lool's status on the docker PR progress. I thought there were still some open questions that needed to be addressed before another review and I got the impression one of you would be working on the kernel modules backend.
[13:15] <lool> jdstrand: I actually got the impression you would be coming back to the review after a while
[13:15] <lool> jdstrand: :-)
[13:16] <jdstrand> well, I planned to come back to the review, but thought people were working on the kernel modules backend
[13:16] <lool> jdstrand: I'm not sure who if anyone has time to work on the kernel module backend
[13:16] <jdstrand> if it makes sense for me to do another round of reviews, I can
[13:16] <jdstrand> hrmm
[13:16] <lool> I dont know if I can ask tianon to work on this, if he can't I imagined I'd end up doing it
[13:17] <lool> but I was hoping someone from the core team would come to it first
[13:17] <jdstrand> lool: this might be a question to have with JamieBennett
[13:17] <jdstrand> err
[13:17] <jdstrand> a conversation to have with him
[13:17] <lool> Yes
[13:17] <lool> jdstrand: it would be helpful to know how much other things are needed for this to get in
[13:18] <lool> how many / how much work
[13:20] <jdstrand> I was assigned some high priority (snappy) work a week and half ago so I've been trying to get through all that while (I thought) the other issues with docker were being worked on. if you're saying you're blocked on me, I can try to get through that review today
[13:21] <lool> jdstrand: I think we're blocked on your next review + this kernel module feature which isn't docker specific but that docker seems to need first
[13:21] <lool> jdstrand: I dont know of other work on the snap / interface that was requested in the pull request and wasn't done
[13:22] <jdstrand> lool: fwiw, that feature is needed by firewall-control for the GA release for a customer requirement. it's also needed by ppp interface
[13:22] <jdstrand> I guess I'll take a look at that. I'll try to get to that today
[13:22] <lool> jdstrand: cool; I'm currently debugging other issues with the docker snap on classic (works on core but not on classic with weird errosr)
[13:22] <zyga> jdstrand: before 3.8 /proc/$PID/ns/mnt did not exist
[13:24] <jdstrand> zyga: sounds like that is a patch to add to the list. I wonder how intrusive it is. I suspect very-- we've said in the past 3.4 kernels can't be used to run lxd/docker
[13:25]  * jdstrand is recalling from memory. ogasawara would probably have the definitive answer
[13:25] <lool> I thought 3.10 was needed for systemd anyway?
[13:27] <zyga> jdstrand: we have a few options for that
[13:27] <zyga> jdstrand: one easy one is that this feature is not supported on 3.4
[13:27] <zyga> jdstrand: a more complex one could usee a zygote process
[13:27] <zyga> jdstrand: and a backport for this patch could be a third approach
[13:27] <zyga> lool: I'm not sure
[13:28] <zyga> lool: if so, then this discussion is moot, I guess this is about defining a baseline kernel for snappy
[13:28] <tedg> Is there a recommended way to get $HOME back to the correct value?
[13:28] <tedg> Tried with getent, but don't have permissions.
[13:28] <zyga> tedg: I don't believe there is
[13:28] <lool> I believe the oldest we provide for apparmor patches is 3.10
[13:29] <tedg> Uhg, it makes the open/close dialog in Inkscape mostly unusable :-(
[13:29] <lool> we probably had older patchsets, but we haven't updated them
[13:29] <jdstrand> zyga: I really don't like the zygote approach in general. it depends on how it is implemented
[13:29] <zyga> tedg: snappy could easily set a variable like SNAPPY_OLD_HOME
[13:29] <stokachu> im trying to get my systemd bridge service working and not able to get an ip assigned to it, https://paste.ubuntu.com/23107318/
[13:29] <lool> actually systemd requires >= 3.4
[13:29] <zyga> jdstrand: I think we agree on this
[13:29] <jdstrand> lool: apparmor isn't the probelm-- we have patches for 3.4 kernel for touch
[13:29] <jdstrand> I'm not sure how up to date they are as of this second, but that is certainly possible.
[13:30] <lool> jdstrand: in the snappy kernel templates, we only offer 3.10 and onwards
[13:30] <mvo> arges: yeah 2.13 looks good, the issues that elopio mentioned with gnome-software is a bug in 2.12, we are working on a fix
[13:30] <jdstrand> lool: ogasawara maintins a list somewhere
[13:30] <Son_Goku> lool, afaik, newest systemd requires kernel >= 3.14, iirc
[13:30] <tedg> zyga: Sure, but then I'd need a specific version of ubuntu-core, which I can't depend on.
[13:30] <jdstrand> lool: that may be because other things have made them say that 3.4 is not possible, so we said "well, then we don't have to produce apparmor backports"
[13:30] <lool> jdstrand: https://docs.google.com/document/d/1LOqrSty2yTsUtQ4nFehaisZc4XmKKsK_E_tz-O1hU-M/edit
[13:31] <jdstrand> sure, it is a cause and effect thing
[13:31] <jdstrand> the effect of not supporting snappy on 3.4 is that it causes the security team to not provide backports to 3.4 :)
[13:32] <lool> jdstrand: yup; I'm just trying to be realistic; I believe the oldest we consider maintainable is 3.10, but of course everything is possible  :-)
[13:32] <ogra_> tedg, just use /home/$USER ?
[13:32] <jdstrand> sure. I'm just saying that *apparmor* is not why it isn't maintainable
[13:33] <lool> jdstrand: sorry it's just the first thing we're missing when we're applying the ubuntu patches
[13:33] <lool> (over vanilla / bsp kernels)
[13:33] <zyga> tedg: you can, there's a mechanism for that
[13:33] <tedg> ogra_: Yeah, can try that as a work around. Good idea.
[13:33] <lool> didn't
[13:33] <lool> didn't mean to pick on these patches specifically
[13:33] <lool> it's all our ubuntu sauce
[13:33] <zyga> tedg: assume (or somethng like that) you can put this into your snapcraft.yaml
[13:33] <lool> jdstrand: this was an earlier effort of mine to capture the reqs https://docs.google.com/document/d/1W9TJDTWevnxARYaE3w7fahXeCgjv_9xJ2RTZ6nN0Va4/edit
[13:33] <zyga> tedg: in general it feels like a bug to fix
[13:34] <lool> which was after internal consultation
[13:34] <ogra_> zyga, but rarher in the desktop launcher than in snapcraft
[13:34] <ogra_> err
[13:34] <ogra_> snapd
[13:34] <ogra_> after all it is the launcher wrapper script that forces $HOME
[13:35] <tedg> zyga: Hmm, I see that in the snapcraft schema, but I don't see what the string needs to look like. "ubuntu-core>x.y.z" ?
[13:43] <zyga> tedg: it's a list of strings
[13:43] <zyga> tedg: each string is a feature flag you can request from snapd
[13:43] <zyga> tedg: e.g. old-home-env
[13:43] <zyga> tedg: snapd knows which flags it supports
[13:44] <zyga> ogra_: no, that's actually in snapd itself
[13:44] <tedg> zyga: Oh, so it's not requesting a specific version as much as a set of features.
[13:44] <zyga> ogra_: the launcher doesn't change home AFAIR
[13:44] <zyga> tedg: exactly
[13:44] <zyga> ogra_: the wrapper script is made by snapd
[13:44] <ogra_> i thought it has HOME="$SNAP_USER_DATA"
[13:44] <zyga> ogra_: and since 2.14 those are gone
[13:44] <zyga> ogra_: so this is all managed internally in snapd
[13:44] <zyga> ogra_: (no more wrappers!
[13:45] <ogra_> (talking about the desktop wrapper here)
[13:45] <zyga> ogra_: that's all snapd
[13:45] <zyga> ogra_: snapd can now set environment in the started app processes
[13:47] <tedg> Wait, so how is snapd launching the process? Spawning from its own then?
[13:48] <ogra_> zyga, yeah, i just checked, it doesnt touch HOME ... only creates a ton for XDG dirs in SNAP_USER_DATA
[13:48] <tedg> Or is the CLI starting the application.
[13:48] <ogra_> s/for/of/
[13:48] <zyga> tedg: it's complex, the app name, say "foo", is a symlink to snap-run
[13:48] <zyga> tedg: snap-run does some stuff, run snap-confine, which does some more and runs snap-exec which does some more and exec's the command associated with the snap
[13:49] <tedg> zyga: So for starting apps I should be calling that symlink still? Or calling snap-run?
[13:49] <zyga> tedg: nothing changes for the user
[13:49] <zyga> tedg: this is all an internal change
[13:49] <zyga> tedg: and snap-run is not on PATH AFAIK
[13:49] <tedg> zyga: Well, I'm kinda a special user here :-)
[13:50] <zyga> tedg: why?
[13:50] <zyga> tedg: I mean, this should not be visible to anyone in practice
[13:50] <tedg> zyga: Becuase we're setting up the exec in Upstart for desktop apps
[13:50] <zyga> tedg: it's just an optimization that gives us some more control
[13:50] <zyga> tedg: that should just run the command as it in the desktop file
[13:51] <tedg> zyga: Ideally, but the desktop files aren't that useful.
[13:51] <tedg> (the ones generated by snapd)
[13:51] <zyga> tedg: perhaps what you want to do should be managed by snapd itself
[13:51] <zyga> tedg: I'm not sure what this is exactly, feel free to ask for more information if that helps you
[13:52] <tedg> zyga: I am :-)
[13:52]  * ogra_ thought we are drooping Üpstart this cycle from desktop
[13:52] <stokachu> when i install a snap it runs both command and stop-command via oneshot
[13:52] <stokachu> https://paste.ubuntu.com/23107384/
[13:52] <tedg> zyga: Seems like the symlink should work fine for now.
[13:52] <stokachu> i just need it to run the start command and then the stop command on uninstall
[13:52] <tedg> ogra_: Trying for Unity7, not for Unity8.
[13:52] <stokachu> not at once
[13:52] <ogra_> ah
[13:52] <zyga> anyone, what's the glib-way to rm -rf a directory?
[13:52] <zyga> (this is for unit test code)
[13:54] <ogra_> stokachu, i would imaggine running stop-command on install is a bug ... but nontheless your script should check if what it wants to stop is actually running
[13:54] <stokachu> ogra_, huh? there is nothing running
[13:54] <stokachu> the start command runs some ip/iptables commands
[13:54] <ogra_> so it should exit gracefully
[13:56] <ogra_> hmm, actuall running the stop command makes indeed sense on upgrades
[13:56] <ogra_> so iits probably not a bug at all
[13:56] <stokachu> it runs the start command then stop-command right after
[13:56] <stokachu> running the stop-command before the command makes sense
[13:57] <zyga> stokachu: note, this is all systemd stuff
[13:57] <zyga> stokachu: nothing is done by snapd here
[13:57] <zyga> stokachu: whatever you are experiencing is systemd related
[13:57] <zyga> stokachu: we just start/stop units
[13:57] <zyga> stokachu: (we do stop and start the units on upgrades)
[13:57] <stokachu> you call stop-command after the start command?
[13:57] <ogra_> zyga, well, you can define stop-command for a daemon
[13:58] <ogra_> snapd should make sure what it generates can be run in the desired order
[13:58] <lool> elopio: are the snapcraft integration tests usually passing? I get an error on snapcraft-parser
[13:58] <ogra_> stop-command should be only run on shutdown or uninstall of the package ... or before an upgrade wants to start the daemon newly
[13:59] <stokachu> which it's not doing now
[13:59] <ogra_> right
[14:00] <zyga> ogra_: snapd just generates a systemd unit file, all the running is done by systemd
[14:00] <ogra_> zyga, well, but if snapd allows us to define a stop-command for a daemon it should not "just run"
[14:00] <ogra_> only for stopping the daemon
[14:01] <ogra_> so imho something is generated wrongly
[14:01] <ogra_> probably a Chipaca topic
[14:02] <zyga> ogra_: check the systemd unit, does it look good or bad?
[14:02] <ogra_> no idea ... its stokachu's unit :)
[14:02] <stokachu> where is that located
[14:03] <ogra_> but it is clear that tthe two units run in the wrong oorder on package install
[14:06] <stokachu> ogra_, zyga https://paste.ubuntu.com/23107454/
[14:07] <stokachu> so my oneshot daemon runs command, then stop-command directly after
[14:07] <lool> elopio: well they are passing on travis; not sure why it fails here
[14:08] <zyga> stokachu: looking now
[14:08] <zyga> stokachu: can you pastebin the snap.conjure-up.bridge.service file
[14:09] <zyga> stokachu: it should be easy to find in /etc
[14:09] <stokachu> zyga, https://paste.ubuntu.com/23107463/
[14:18] <stub> Given I can do both, should I create my daemon simple or forking?
[14:18] <lool> kyrofa: travis completed on the /sbin branch
[14:18] <stub> Any advantages of one over the other?
[14:18] <lool> (successfully)
[14:19] <ogra_> zyga, stokachu, hmm, i wonder if it should actually be oneshot if it has a stop command defined
[14:19] <lool> kyrofa: I couldn't open the autopkgtests links
[14:19] <cmars> zyga, hi, i was following your blog post on writing an interface. i'd like to write one for libvirt, so that snaps can control it on a classic host
[14:19] <mup> PR snapd#1772 closed: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1772>
[14:19] <stokachu> ogra_, should i just put the tear down of iptables etc in the same start script
[14:19] <stokachu> and handle it logically
[14:20] <cmars> zyga, i got the socket part working, but the snap i'm working on wants to see stuff in /var/lib/libvirt, such as dnsmasq
[14:20] <ogra_> you could indeed do that ...
[14:20] <cmars> zyga, how would i expose that through the interface? (or is this even a good idea?)
[14:20] <stokachu> ogra_, what about snap remove?
[14:21] <ogra_> that would call stop
[14:21] <stokachu> so maybe just a bridge script that'll accept an argument
[14:21] <cmars> zyga, i tried adding /var/lib/libvirt/** to the aa profile, but the plugged-in snap doesn't seem to see it. is there some mounting that would need to happen?
[14:24] <mvo> a new ubuntu-core stable got just released, it is based on 2.13, please do let me know if you notice any issues
[14:24] <sergiusens> good morning
[14:24] <mvo> arges: there was some talk about command not found hanlding? do you have some details for me?
[14:26] <josepht> good morning sergiusens
[14:26] <zyga> cmars: if you explore the environment you will see that /var/lib/libvirt just doesn't exist in the core snap
[14:26] <zyga> cmars: as a easy workaround please look at snap-confine and at quirks.c therein (look for lxd quirk)
[14:27] <zyga> cmars: note that this is only for a devmode snap as no interface allows any snap to use /var/lib/lxd
[14:27] <zyga> cmars: I would recommend you to create an interface that bind mounts /var/lib/lxd from the host into a snap-specifc directory
[14:28] <zyga> cmars: I'm not familar with libvirt, does it need just a socket or the whole directory tree
[14:29] <cmars> zyga, the socket, but also parts of the tree, such as /var/lib/libvirt/dnsmasq, if you want to read the IP addresses of VMs for example
[14:29] <zyga> cmars: I would recommend you to also report a bug tagged with snapd-interface and ask jdstrand for advice
[14:29] <zyga> cmars: I see
[14:29] <cmars> zyga, ok, will do
[14:30] <zyga> cmars: we can use the mount backend to bind mount /var/lib/lxd to a directory in the snap (relative to $SNAP_DATA)
[14:30] <stokachu> i thought interfaces was a last resort and that we should be packaging every requirement in the same snap
[14:30] <zyga> cmars: then you can patch or config libvirt inside the snap to assume that libvirt is in that directory
[14:30] <zyga> stokachu: interfaces allow to shape the sandbox in which apps execute
[14:31] <zyga> stokachu: if you want to have a snap that talks to something in the classic world or talks to another snap you can use an interface for this
[14:31] <stokachu> snaps have no notion of dependencies though
[14:31] <zyga> stokachu: it feels perfectly fine to have a snap with libvirt or libvirt installed on classic and an interface that allows another snap to talk to libvirt (wherever it is)
[14:33] <stokachu> how would someone know that libvirt is a requirement for cmars snap?
[14:35] <zyga> stokachu: the snap would declare a plug of type 'libvirt'
[14:35] <zyga> stokachu: we have no syntax for this but plugs will have a way to say "I have to be connected before this snap can be used"
[14:36] <mhall119> zyga: is somebody working on adding the content interface details to the existing docs?
[14:36] <elopio> lool: hello. What error are you getting locally?
[14:36] <zyga> stokachu: then however that libvirt is provided (could be from the core snap, could be from another snap)
[14:36] <cmars> i imagine it's a similar situation for snaps that need to plug into mir & x11
[14:36] <zyga> mhall119: not that I'm aware of, I'll do this after snap-confine features for 1.0.41 are implemented
[14:36] <zyga> cmars: yes
[14:36] <stokachu> cmars, read the docs for now?
[14:37] <elopio> cpaelzer: maybe josepht can help you with the wiki entry. I get no parsing errors, but I also don't get the new part.
[14:39] <cpaelzer> elopio: ok, thanks for the update
[14:39] <cpaelzer> elopio: that is why I opened the bug on LP to give people some time to really look at it
[14:39] <lool> elopio: I couldn't reproduce it after rerunning; here's the one I get locally right now:
[14:39] <lool> elopio: http://paste.ubuntu.com/23107571/
[14:42] <cmars> zyga, thanks for the advice, snap-confine sources are clearing things up for me :)
[14:42] <jdstrand> zyga (cc cmars): fyi, a libvirt interface is going to be super-privileged, like docker and lxd
[14:42] <zyga> jdstrand: I agree, note that it seems that it is just the plug-side of libvirt for now
[14:42] <jdstrand> session:/// wouldn't need to be. but no one uses session:///
[14:44] <lool> elopio: python3 -m unittest -b integration_tests.test_parser is passing for me now, sorry; it failed a couple of times even when rerunning manually
[14:44] <lool> perhaps wiki issue or something
[14:44] <camako> I think snappy-playpen CI is having infrastructure issues ("No CMAKE_C_COMPILER could be found") on more than one PRs. Does anyone know why it's failing? Is there anyway to re-kick it (without updating the branch)?
[14:46] <lool> elopio: ah I know what's going on
[14:46] <lool> elopio: install: error writing '/tmp/tmpe3p0e0r9/simple-rust/parts/simple-rust/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc
[14:46] <lool> _llvm-39b92f95.so': No space left on device
[14:46] <lool> elopio: /tmp is in memory, the vm has 2G and that's apparently not enough
[14:47] <josepht> cpaelzer: it looks like it's because your part is named 'waf-project' in your snapcraft.yaml and 'wafdemo' in the wiki.  The wiki entry needs to use the part name, not the project name.
[14:48] <arges> mvo: not sure what you mean exactly
[14:48] <elopio> lool: oh, that makes sense. The tests use tmp a lot, the real build doesn't.
[14:48] <lool> elopio: yeah
[14:48] <mup> PR snapcraft#764 opened: add support for snap-build grade parameter in snapcraft.yaml <Created by caio1982> <Conflict> <https://github.com/snapcore/snapcraft/pull/764>
[14:49] <lool> elopio: this also explains why it transients (running other things took memory / disk space)
[14:49] <lool> *was
[14:49] <mvo> arges: sorry, if you don't know about command-not-found that is fine, it was in a google doc and I was referenced
[14:49] <mvo> arges: I will find out, I thought the context was kernel stuff
[14:49] <mvo> arges: in any case 2.13 should be good to go
[14:50] <arges> mvo: i see it now, it was to ensure /snap/bin is in $PATH, that should probably be filed as a bug if it isn't already
[14:50] <josepht> cpaelzer: fyi, the wiki is processed once an hour.
[14:50] <lool> Error: Node Sass does not yet support your current environment: Linux Unsupported architecture (arm) with Node.js 4.x
[14:50] <lool> damn it
[14:50] <arges> mvo: and shouldn't block 2.13 regardless so I'm happy to release if there aren't any other issues
[14:50] <elopio> josepht: shouldn't that print a warning on parse?
[14:51] <mvo> arges: cool, no other issues
[14:51] <cpaelzer> josepht: thanks a lot, trying that then
[14:51] <josepht> elopio: yes, I'll update the bug so we can fix that
[14:51] <mvo> arges: we pushed a fix for /snap/bin, let me search for the bug reference, one sec
[14:51] <josepht> cpaelzer: I already updated the wiki
[14:51] <mvo> arges: https://launchpad.net/ubuntu/+source/sudo/1.8.16-0ubuntu1.2
[14:52] <arges> mvo: awesome thanks
[14:52] <elopio> josepht: thank you.
[14:53] <ogra_> mvo, any idea when this will land ? that must sit in -propsed since a month now
[14:54] <ogra_> ah, well, 11 days ... my sense of time seems to be off :P
[14:56] <mvo> ogra_: someone *cough* needs to do the verification, could be anone expect me (as I uploaded it)
[14:56] <mvo> ogra_: help appreciated :)
[14:56] <ogra_> on it
[14:57] <mvo> \o/
[14:57] <mvo> I'm sure arges will let it in once its verified
[14:57] <arges> which package?
[14:57] <mup> Bug #1618085 opened: snap run fails to run, cannot find app "me" in "me" <Snappy:New> <https://launchpad.net/bugs/1618085>
[14:58] <ogra_> done
[14:58] <mvo> arges: sudo itself
[14:58] <ogra_> that wasnt actually hard :)
[14:58] <mvo> arges: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1595558
[14:59] <mup> Bug #1595558: sudo doesn't have /snap/bin in PATH <verification-done> <snapd (Ubuntu):Won't Fix> <sudo (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Won't Fix> <sudo (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1595558>
[14:59] <mvo> ogra_: :)
[14:59] <ogra_> mvo, what about shadow ? we still have it sitting in the PPA
[14:59] <ogra_> did you plan to push the fixes to debian ?
[15:00] <mvo> ogra_: thats the --extrausers fixes?
[15:00] <ogra_> yeah
[15:00] <ogra_> i cant remember if sergiusens pushed the former changes to debian or if we did a distro patch for that
[15:00] <mvo> ogra_: I don't remember :/ I think I did send some patches some time ago and vaguely remember them sitting in the bts forever, but I may be wrong
[15:00] <ogra_> we should get the PPA empty for RTM ... or at least between RTM and GA
[15:01] <ogra_> so that we dont release any ubuntu-core into stable that cant be built from the archhive
[15:02] <ogra_> (/me has already worked a bit on the cleanup, but there is still a lot to do)
[15:06] <mup> Bug #1618095 opened: [SRU] 2.0.14 <Snappy:New> <https://launchpad.net/bugs/1618095>
[15:09] <zyga> slangasek: around?
[15:09] <ogra_> sergiusens, bug 1618019 seems like an easy fix
[15:09] <mup> Bug #1618019: builds of "type: kernel" add obsolete options to snap.yaml <Snapcraft:New> <https://launchpad.net/bugs/1618019>
[15:16] <ogra_> (or kyrofa ^^)
[15:18] <kyrofa> ogra_, why are those keys no longer required?
[15:19] <ogra_> kyrofa, because the kernel snap now is defined ... bits need to sit in the right paths inside it so you dont need any meta info anymore
[15:19] <kyrofa> ogra_, "don't need" and "fail review because" seem slightly different. Everything is always so out of sync :(
[15:20] <ogra_> kyrofa, i cant find the link to the final kernel.yaml doc anymore (as usual with gdoc ...) but all options except "type: kernel" and "version:" are gone
[15:21] <ogra_> the snapcraft.yaml can indeed still use them for the kernel plugin ... but the snap.yaml should not have any of these anymore since the content is in pre-defined paths now
[15:21] <ogra_> s/is in/has to be in/
[15:21] <kyrofa> ogra_, isn't that the stuff that was just recently finalized?
[15:21] <ogra_> (and dont blame me, i didnt define the kernel yaml :P )
[15:22] <ogra_> afaik it was finalized in heidelberd
[15:22] <ogra_> *heidelberg
[15:22] <kyrofa> Oh I don't blame you, but I'd like to start doing this stuff with cross-project bugs instead of each project changing independently and making the others sprint to catch up
[15:23] <ogra_> kyrofa, see pm
[15:26] <sergiusens> ogra_ there is a really old card for extra users where mvo was supposed to add it to debian
[15:26] <mvo> I think I did
[15:26] <sergiusens> kyrofa ogra_ wrt kernel plugin, I asked for the spec on Wednesday, didn't get it
[15:26]  * sergiusens is being short on words as he has a feverish kid up in arms
[15:27] <ogra_> sergiusens, there is a gdoc from heidelberg that defines that only type and version are needed in snap.yaml
[15:27] <ogra_> the rest is defined via pre-defined paths the binary stuff needs to be
[15:28] <sergiusens> ogra_ link it to the bug please so I can check if everything required is being done
[15:28] <sergiusens> ogra_ does this include the init chainloading?
[15:28] <kyrofa> sergiusens, huh, mine has a fever this morning too
[15:28] <ogra_> sergiusens, chainloading ?
[15:28] <sergiusens> ogra_ initrd from os and kernel snap
[15:29] <sergiusens> chainloading, munging, aggregation, ... whatever it is called
[15:29] <ogra_> sergiusens, not defined anywhere ... but also not relevant
[15:29] <ogra_> there will be an initrd in the kernel snap ... that wont change
[15:29] <sergiusens> ok, just wondering if I can kill the logic that downloads the kernel snap
[15:29] <ogra_> the changes are in gadget then
[15:29] <sergiusens> the os snap
[15:29] <ogra_> ah, not yet
[15:29] <ogra_> i'll ping you ...
[15:30] <ogra_> but thats for between RTM and GA
[15:31] <ogra_> the logic will sit in the bootloader scripts and in the initrd build scripts ... neither needs anything from the kernel snap or from snapcraft atm
[15:37] <ogra_> sergiusens, doc link added to the bug
[16:00] <mup> PR snapcraft#756 closed: Use block style for multiline YAML values <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/756>
[16:07] <stokachu> is the lxd interface auto connect?
[16:12] <eldarkg> kyrofa: hello
[16:12] <kyrofa> eldarkg, hey, welcome!
[16:13] <eldarkg> kyrofa: I was talking with about kicad-snap
[16:14] <cmars> that new snapd 2.13 release.. does that enable snaps to be installed in a lxd container?
[16:14] <kyrofa> eldarkg, so I dug into this issue a bit, but not quite as much as I would have liked. It does actually seem to find your lib, but when it comes time to link it can't find the lib. I suspect the Findngspice.cmake is looking in an odd place
[16:14] <kyrofa> Rather, it seems to find the includes, but not the lib
[16:14] <kyrofa> eldarkg, but my lack of familiarity with the project started to get in the way at that point
[16:15] <eldarkg> kyrofa: mmm
[16:15] <la_juyis`> hi, question. i have an app installed as a deb in my system. I built a snap, installed it, but when I call the app by the name it still calls the deb in /usr/bin - in this case to try if the snap runs ok I should call it by the /snap/ bin, right?
[16:15] <eldarkg> kyrofa: Is it bug of Findngspice.cmake script?
[16:16] <kyrofa> eldarkg, maybe, but I'm not sure. It requires some digging into it, the time for which I'm afraid I don't have right now. I'd definitely start there with further investigation, though
[16:17] <kyrofa> la_juyis`, yeah, /snap/bin comes later in the path
[16:17] <la_juyis`> kyrofa roger, thanks!
[16:18] <eldarkg> kyrofa: ok. how I can to simulate LP building on my PC?
[16:19] <kyrofa> eldarkg, I'd fire up a clean container for it (I use lxc)
[16:20] <eldarkg> kyrofa: thank you. I'll try digging
[16:20] <mup> PR snapd#1778 opened: daemon: make socket split backward-compatible <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1778>
[16:33] <stub> Where does my daemon send its logs? Or do I need to log to $SNAP_COMMON or similar and handle log rotation myself?
[16:38] <eldarkg> stub: check cat /var/log/syslog
[16:38] <eldarkg> stub: good tail -f /var/log/syslog
[16:39] <stub> eldarkg: I mean where should it send its logs. I guess I could dump them all to syslog and let the operator work it out from there.
[16:40] <eldarkg> stub: sorry I'm new
[16:42] <stub> I'm at the point I'm dealing with the rough edges. Currently also trying to figure out locale handling. I only seem to have the C locale available.
[16:43] <eldarkg> stub: Look at my try to work with i18n https://github.com/eldarkg/kicad-snap/blob/master/kicad.wrapper#L10
[16:46] <stub> eldarkg: I see. So you are generating the locales yourself, rather than relying on locales-all or something to have then embedded in the snap.
[16:48] <eldarkg> stub: I found only this solve maybe exist the right one
[16:48] <eldarkg> stub: ping me if you find the right way
[16:57] <derjasper> What is the state of Ubuntu Snappi on the Raspberry Pi 3 ? Is there a development or inofficial build available?
[17:00] <mup> PR snapd#1669 closed: interface: add usb device support to serial-port <Blocked> <Critical> <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1669>
[17:02] <ogra_> derjasper, http://people.canonical.com/~ogra/snappy/all-snaps/
[17:03] <ogra_> arges, do you plan to do raspi2 and dragonboard kernel SRUs too today ?
[17:04] <ogra_> (just asking because i need to make the snap packages pick that up then)
[17:04] <elopio> nessita: I've just requested a reserved name, cf. Can you please approve it?
[17:04] <derjasper> Thanks! Is this already 64 bit? And does it receive updates?
[17:04] <mup> PR snapd#1696 closed: interfaces: add hidraw-device interface <Blocked> <Critical> <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1696>
[17:06] <ogra_> derjasper, no, not 64bit (and i'm not sure we'll do 64bit before the pi foundation doesnt announce all firmware blobs are ready for that)
[17:06] <ogra_> but it receives updates indeed
[17:07] <derjasper> thanks!
[17:07] <ogra_> (nopte also that binaries for 64bit eat about 2/3 extra ram, they are a lot bigger)
[17:07] <stub> eldarkg: It seems to be working if I have locales-all in my stage-packages, and set the LOCPATH environment variable to $SNAP/usr/lib/locale
[17:08] <stub> eldarkg: I need all locales available (the user can choose at runtime), so this might not be appropriate for your use case
[17:09] <eldarkg> stub: thank you
[17:10] <ogra_> ubuntu@pi3:~$ ps ax -o rss,cmd |grep snapd
[17:10] <ogra_> 12864 /usr/lib/snapd/snapd
[17:10] <ogra_> ubuntu@dragonboard:~$ ps ax -o rss,cmd |grep snapd
[17:10] <ogra_> 27248 /usr/lib/snapd/snapd
[17:10] <ogra_> derjasper, ^^^
[17:10] <ogra_> same binary from the same source ...
[17:10] <ogra_> (teh pi3 is armhf ... the dragonboard is arm64)
[17:11] <alextn> Hello all. I've been working with Snappy Core on the Samsung ARTIK 10 and I was wondering if the "gadget snap" or anything that I might use to produce a custom image is available.
[17:11] <ogra_> the only real advantage you get with arm64 is on systems with a lot of ram
[17:11] <ogra_> which the pi3 really isnt
[17:13] <derjasper> okay, didn't thought about that ^^
[17:13] <ogra_> :)
[17:14] <tbr> as if ARMv7 couldn't do LPAE...
[17:15] <mup> PR snapcraft#757 closed: Export important project variables <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/757>
[17:18] <ogra_> tbr, does LPAE help gimp to use a 64bit address space ? :)
[17:24] <tbr> sure, if you want to run Chrome or Firefox with more than two tabs or anything else, you'll need 64bit address space :)
[17:24] <ogra_> heh, well ...
[17:26] <alextn> What if you want to virtualize something... ARMv8.x is better for virtualization..
[17:26] <ogra_> what i meant is that the larger 64bit binaries can actually have a benefit ... but that will only make sense if their functions can actually also address 64bit blocks and have enough ram for that
[17:27] <arges> ogra_: re: rpi/snapdragon kernels that's something ppisati handles
[17:27] <ogra_> but yeah, in general armhf is the better choice and LPAE will allow you to use more than 3GB
[17:28] <ogra_> arges, i have no idea, i only noticed you spammed my changes mailboxes everywhere with these other kernels (new pc-kernel snap with your SRU is already in the store btw) :)
[17:28] <arges> ogra_: yup its kernel release day today
[17:28] <ogra_> and i try to be fast with the snaps when an ABI bump happens
[17:29] <ogra_> (i'll soon automate that so a script can notice a new meta in -updates/-security and it re-builds teh snap automatically)
[17:30] <ogra_> (maintenance free = win :) )
[17:39] <jdstrand> roadmr: hey, can you pull r726?
[17:46] <nessita> elopio, hi! so transfering a snap name is not trivial, and will not be for some time until that is scheduled and added to our roadmap. We usually recommend to not take the upstream names and use suffixes like cf-elopio. Have you consider that?
[17:48] <elopio> nessita: yes, but then less people will install it and it will get worse stats. My hope is that by the time upstream is ready to take ownership, all the issues in the transfer would be solved.
[17:48] <elopio> 3 months from now maybe?
[17:49] <nessita> elopio, ok, I will try to have it approved by EOD today (need to confirm a few things first). Is that ok?
[17:52] <elopio> nessita: yes it is. Thank you :)
[17:59] <jdstrand> ogra_: hey, I see a bunch of kernels in the store. do you have an updated list of kernel and gadget snaps that should not be blocked?
[18:01] <ogra_> jdstrand, heh, nothing changed, no ... all kernels we use auto-land fine
[18:01] <jdstrand> maybe these are old names
[18:01] <jdstrand> one has canonical-* at the beginning
[18:01] <ogra_> they likely are ... i wish i could delete packages
[18:01] <ogra_> yeah, thats alll dead beef
[18:02] <ogra_> only pc-kernel, pi2-kernel and dragonboard-kernel are relevant ...
[18:02] <ogra_> the rest is old cruft
[18:02] <ogra_> (and these three are fine)
[18:02] <jdstrand> ok, those are the ones I have
[18:02] <jdstrand> ogra_: is there a list of gadget snaps?
[18:03] <ogra_> pc, pi2, pi3 and dragonboard
[18:04] <ogra_> but we are updating them rarely enough that manual approval is fine
[18:04] <ogra_> especially since it is always a manual process ... we dont have any snapcraft integration for our gadgets yet
[18:08] <jdstrand> ogra_: ok, thank you
[18:10] <jdstrand> roadmr: if you are so inclined, r728 instead (whitelists a few gadget snaps). if you already pulled r726, it can wait
[18:32] <roadmr> jdstrand: will do. I'd just pulled r721 :)
[18:32] <wililupy> is there an example of how to use the dump plugin? Not urgent since copy is still working, but would like to learn it. ;)
[18:32] <roadmr> jdstrand: (but not deployed yet, so it's a good time)
[18:32] <jdstrand> great, thanks!
[18:33] <mup> PR snapcraft#765 opened: Use a recursive iglob for filesets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/765>
[18:36] <mup> PR snapcraft#754 closed: Use in plugin code to remove unwanted files <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/754>
[18:59] <dobey> how does one start the snapd service inside an lxc container?
[18:59] <dobey> error: daemon does not handle 0 listeners right now, just one
[19:00] <dobey> ^^ i get this if i try to just run "sudo /usr/lib/snapd/snapd"
[19:00] <dobey> and i can't seem to use systemctl
[19:08] <sergiusens> dobey it doesn't work in a container; there are bugs that I don't have handy related to the kernel/apparmor that the security team is working on for this
[19:08] <sergiusens> I think it was jjohansen
[19:11] <dobey> sergiusens: oh right. is there no way to run it completely unconfined?
[19:12] <sergiusens> dobey the container itself? Maybe with profiles and such, but that is outside my area of expertise
[19:14] <dobey> sergiusens: snapd
[19:15] <dobey> hrmm, maybe i can just bind mount /run/snapd.socket instead
[19:17] <dobey> err, i guess not because /run is tmpfs
[19:32] <jjohansen> sergiusens: can you try the xenial proposed kernel? Ubuntu-4.4.0-37.56 has more than a dozen apparmor fixes in it
[19:33] <sergiusens> jjohansen that would be for dobey ^
[19:34] <dobey> installed in host or container?
[19:35] <kyrofa> dobey, container uses host, no?
[19:39] <dobey> kyrofa: well, the running kernel is on the host of course, but the container doesn't necessarily use other files from the host
[19:39] <dobey> if i could just bind mount the socket though, that'd be best
[19:48] <jjohansen> dobey: host
[20:03] <kgunn> stgraber: hey there, i discovered this means "image not found" ...but shouldn;t there be an arm64 xenial image?
[20:03] <kgunn> kg@kg-MacBookPro:~$ sudo lxc launch images:ubuntu/xenial/aarch64 xen-arm64
[20:03] <kgunn> error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias)
[20:04] <kgunn> or am i doing it wrong?
[20:06] <ogra_> kgunn, as a fallback (if you cant get lxc to work) https://github.com/snapcore/classic-snap ...
[20:06] <kgunn> ogra_:  :-P
[20:06] <ogra_> :)
[20:07] <kgunn> how do you know i want to cross compile ?
[20:07] <ogra_> mindwaves ;)
[20:07] <kgunn> lol
[20:08] <stgraber> kgunn: lxc launch images:ubuntu/xenial/arm64
[20:08] <stgraber> kgunn: though based on your hostname, that's not going to work as it will only run on an arm64 system
[20:18] <dobey> why can't i bind mount anything in tmp/ or run/ in an lxc any more? :(
[21:02] <mup> PR snapd#1779 opened: miscellaneous policy updates:  <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1779>
[21:10] <tvoss> jdstrand: o/
[21:11] <jdstrand> hey tvoss :)
[21:11] <mup> PR snapd#1778 closed: daemon: make socket split backward-compatible <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1778>
[21:11] <tvoss> jdstrand: would you find a few to review the very recent locationd upload?
[21:11] <jdstrand> tvoss: sure-- though I did approve a bunch earlier today
[21:12] <jdstrand> I see you uploaded a few more
[21:12] <tvoss> jdstrand: yup, thanks for that -- I had to correct a minor issue for two of the commands
[21:15] <jdstrand> tvoss: ok done
[21:15] <tvoss> jdstrand: ack and thx
[21:18] <mup> PR snapcraft#766 opened: Better file conflict message <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/766>
[21:21] <jcastro> What would cause this error: error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
[21:21] <tvoss> jcastro: running in container or chroot?
[21:22] <jcastro> no, normal xenial desktop
[21:22] <jcastro> I did a refresh to ubuntu-core --edge earlier today, but that wouldn't be related I think?
[21:23] <tvoss> wouldn't think so, I usually ran into the issue in a chroot or container
[21:31] <tvoss> nessita: o/ I'm running into a publishing problem with locationd. packages are auto-uploaded from launchpad, and even after review, there does not seem to be a way to publish the new packages except for unpublishing/publishing. Wondering if I'm missing something
[21:31] <jdstrand> jcastro: sabdfl mentioned a bug in edge's core snap
[21:31] <jdstrand> jcastro: I think SNAP_REEXEC=0 in /etc/environment was the workaround
[21:32] <jdstrand> yes
[21:32] <jdstrand> https://lists.ubuntu.com/archives/snapcraft/2016-August/000862.html
[21:33] <jdstrand> jcastro: ^
[21:34] <kyrofa> jdstrand, jcastro should be fixed with today's daily build, whenever that happens
[21:34] <jcastro> ah thanks for that guys, missed that post
[21:36] <nessita> elopio, cf name approved!
[21:36] <nessita> tvoss, checking
[21:36] <elopio> nessita: :) thanks!
[21:37] <nessita> tvoss, if you go to a revision page, like https://myapps.developer.ubuntu.com/dev/click-apps/5666/rev/11/, scroll down to the bottom
[21:37] <nessita> tvoss, there is a "Publish" button which is per revision
[21:38] <nessita> tvoss, the one at the top is "package wide", the one at the bottom is "per revision" (yes, we have a bug to improve the UX there_
[21:38] <nessita> )
[21:47] <tvoss> nessita: ack, let me see
[22:16] <mup> Bug #1618239 opened: console-conf uses 20+MB memory at rest on embedded systems <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1618239>
[22:56] <ahoneybun> popey: it built now!
[22:56] <ahoneybun> \o/
[23:10] <popey> ahoneybun: yay
[23:12] <ahoneybun> thanks to you lol
[23:14] <popey> np
[23:14] <popey> glad i could help
[23:14] <popey> it's way more fun when stuff works :)
[23:15] <ahoneybun> it is lol
[23:15] <ahoneybun> can LP builds run like Travis CI?
[23:15] <ahoneybun> auto refreshing the page
[23:16] <popey> lp can build snaps
[23:16] <popey> and autobuild too
[23:46] <ahoneybun> no
[23:46] <ahoneybun> the way Travis auto loads the new state of the build
[23:47] <ahoneybun> showing the progress without a refresh of the page like LP does
[23:47] <ahoneybun> or needs
[23:55] <mup> PR snapcraft#764 closed: Implementing 'grade' support in snapcraft.yaml <Created by caio1982> <Closed by caio1982> <https://github.com/snapcore/snapcraft/pull/764>


[12:43] <CrazyLemon> guys does anyone know whats the deal with this signon-ui on 16.10?! keeps poping up windows and closing them.. at least 10x in a minute or so