[00:17] <flexiondotorg> kyrofa, I notice there is a newer Debian package of python-debian that upstream tarball
[00:17] <flexiondotorg> https://packages.debian.org/sid/python-debian
[00:18] <flexiondotorg> https://pypi.python.org/pypi/python-debian
[00:19] <flexiondotorg> Nothing significant.
[00:24] <flexiondotorg> kyrofa, Could it be you just need python3-chardet?
[00:24] <flexiondotorg> https://pypi.python.org/pypi/chardet
[00:25] <flexiondotorg> https://travis-ci.org/snapcore/snapcraft/jobs/180859624#L1178
[00:27] <flexiondotorg> Hmm, that should be pulled in.
[00:28] <flexiondotorg> pip install python-debian into a clean virtual env doesn't pull in chardet.
[00:29] <flexiondotorg> By the python3-debian deb does list python3-chardet as Depends:
[00:33] <flexiondotorg> kyrofa, Might worth putting 'chardet' in one of the requirements files.
[00:34] <flexiondotorg> https://github.com/romlok/python-debian/blob/master/lib/debian/deb822.py#L35
[02:33] <mup> PR snapcraft#987 closed: pluginhandler: prepare scriptlet support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/987>
[05:24] <mup> PR snapcraft#988 closed: pluginhandler: build scriptlet support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/988>
[05:27] <mup> PR snapcraft#981 closed: Support download and validate on branded stores <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/981>
[05:30] <mup> PR snapcraft#982 closed: parser - Use the same version method as 'snapcraft' <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/982>
[05:36] <mup> PR snapcraft#974 closed: Updated maven plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/974>
[05:36] <mup> PR snapcraft#975 closed: Updated gradle plugin to use get_build_properties()  <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/975>
[05:39] <mup> PR snapcraft#978 closed: Updated cmake plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/978>
[05:39] <mup> PR snapcraft#979 closed: Updated waf plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/979>
[05:45] <mup> PR snapcraft#983 closed: Updated scons plugin to use get_build_properties() <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/983>
[06:39] <mup> PR snapcraft#990 opened: Fix snaps tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/990>
[06:58] <shuduo> hello, is there a way like web interface to manage the keys I created and registered?
[09:17] <mup> Bug #1641631 opened: Raspberry Pi images do not support boot from USB <Snappy:Fix Committed by alfonsosanchezbeato> <https://launchpad.net/bugs/1641631>
[09:36] <kalikiana_> Hrm. Isn't "stable" supposed to imply snaps in there were tested? I discovered "tmx" by chance, installed it and find myself unable to run it. It quits with "Error opening terminal: " regardless of what my TERM is. I kind of want a "snap report-broken tmx" command.
[09:38] <kalikiana_> The name 'caozhen' shown in "snap list" doesn't help me either
[09:48] <mcphail> kalikiana_: "stable" just means it was uploaded to that part of the store and passed some automatic security checks. There's no guarantee the snap actually works
[09:51] <shuduo> ogra_: hi, may i know if audio including micphone recording and playback working on any reference board with latest UC16?
[09:52] <ogra_> shuduo, i must admit., i dont know ... i know there is pulseaudio support (so playback should be fine) but i dont kbnow about recording
[09:53] <ogra_> perhaps morphis can tell :)
[09:54] <shuduo> ogra_: good to know playback works. morphis, hello, may i know what status audio function on UC16 now?
[09:56] <kalikiana_> mcphail: Well, I can see that much. Doesn't make it a good experience, though
[09:57] <kalikiana_> Considering stable has requirements like 'no devmode' it seems futile if "in working condition" isn't part of those
[09:57] <kalikiana_> Or, as I said, if I could at least manually intervene. For all I know the developer is able to run the snap on their machine. But I can't ask them
[10:09] <marrek22> hi i try to install ubuntu core on my pi but it says no ssh key to my account
[10:10] <ogra_> did you upload one on login.ubuntu.com ?
[10:11] <marrek22> no where can I find the key
[10:11] <ogra_> https://help.ubuntu.com/community/SSH/OpenSSH/Keys
[10:12] <marrek22> but how can I generate a key when I can't login to the pi
[10:12] <ogra_> generate one ... upload the public part to login.u.c and make sure the machine you try to log in from later has the private bit
[10:13] <ogra_> (this is all between your PC and login.ubuntu.com ... the pi only comes into play later)
[10:14] <longsleep> ogra_: hey do you know if the snap-confine changes related to aa confinment have landed in snapd and if those are available now through edge channel? It was this https://github.com/snapcore/snap-confine/tree/use-aa-support tree but its no longer there :/
[10:15] <ogra_> longsleep, if they landed in 2.20 they are most likely not in edge yet (2.20 only landed and there was no auto-build of the edge core snap since i think)
[10:15] <ogra_> ICBW though ... and mvo did a re-spin
[10:16] <longsleep> ogra_: ok, how does one check what actually is in edge channel?
[10:17] <ogra_> hmm, not sure if uappexplorer shows the version
[10:17] <ogra_> ah, well, it wouldnt show edge anyway
[10:17] <ogra_> one sec
[10:18] <ogra_> longsleep, http://people.canonical.com/~ogra/core-builds/ has logs and versions of the auto-builds (but no manual ones so it could be there is something newer if someone did a manual build via LP)
[10:19] <longsleep> ogra_: ok cool, let me see if i can actually find the change
[10:19] <ogra_> oh
[10:19] <ogra_> and i see snapd 2.20 in the manifest !
[10:20] <longsleep> ogra_: in the last build it logs snapd	2.20~ppa2
[10:20] <ogra_> yeah
[10:20] <ogra_> so if that fis is in 2.20 you should have it in edge then
[10:20] <longsleep> ogra_: yeah - so that would be good if the aa change has actually been merged
[10:20] <ogra_> right
[10:22] <longsleep> ogra_: zyga is on holidays already? Would be easiest if i could just ask him :P
[10:22] <ogra_> i think he is, yeah
[11:36] <ara> is there a way for "snap list" to return the channel as well?
[11:37] <ogra_> probably in snap info
[11:38] <ogra_> yeah
[11:38] <ogra_> ogra@pi3:~$ snap info htop |grep tracking
[11:38] <ogra_> tracking:    stable
[11:38] <ogra_> ogra@pi3:~$
[12:00] <mup> Bug #1650520 opened: Qt's bearer needs access to NetworkManager APIs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1650520>
[12:02] <kalikiana_> ara: It's always stable if you can see it in "snap list"
[12:02] <ara> kalikiana_, I guess you are saying "can't"?
[12:02] <ara> kalikiana_, thanks!
[12:03] <ogra_> ara, well, you could grab the list and loop over it with snap info (see above)
[12:04] <kalikiana_> Oh, maybe I misunderstood. I thought this was looking for installable snaps - obviously the ones already on the system can be from any source
[12:04] <ogra_> kalikiana_, my install tracks edge completely ... with that theory i wouldntz see anything in snap list ;)
[12:04] <ara> ogra_, ah, ok :) I guess we could file a UX bug :)
[12:04] <kalikiana_> ogra_: I tend to mixup snap list/find because they're so similar
[12:05] <ogra_> ah, yeah, find only shows stable
[12:15] <mup> PR snapd#2497 opened: Clean mount namespace when mount changes <Created by tsdgeos> <https://github.com/snapcore/snapd/pull/2497>
[12:27] <rvr> fgimenez: Hi
[12:27] <rvr> fgimenez: Did anything change to run spread tests?
[12:27] <rvr> fgimenez: I get this: error: $(HOST: ./generate-packaging-dir ubuntu 14.04) in project environment returned error: ./generate-packaging-dir: 12: ./generate-packaging-dir: git: not found; ./generate-packaging-dir: 13: ./generate-packaging-dir: git: not found
[12:38] <mup> PR snapd#2497 closed: Clean mount namespace when mount changes <Created by tsdgeos> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2497>
[12:56] <fgimenez> hey rvr, looking
[12:58] <rvr> fgimenez: I commented this line
[12:58] <rvr>     # slight abuse
[12:58] <rvr>     # GENERATE_14_04: "$(HOST: ./generate-packaging-dir ubuntu 14.04)"
[12:58] <rvr> fgimenez: in spread.yaml
[13:17] <fgimenez> rvr, yes, that should be enough, it seems that failed because git is not available on your host, is that the case?
[13:30] <rvr> fgimenez: Nope, it is available
[13:30] <rvr> fgimenez: I am running the tests on the git-cloned directory
[13:33] <fgimenez> rvr, mm the error you pasted is pretty clear "./generate-packaging-dir: 13: ./generate-packaging-dir: git: not found" maybe it is not available in $PATH during the script execution, what is the output of "which git"?
[13:34] <rvr> fgimenez: /usr/bin/git :P
[13:34] <fgimenez> rvr, or better, git remote | grep upstream
[13:35] <fgimenez> rvr, and git remote add upstream https://github.com/snapcore/snapd
[13:35] <rvr> $ git remote | grep upstream --> No output
[13:36] <rvr> fgimenez: What is that expected?
[13:36] <rvr> Sorry, why
[13:37] <fgimenez> rvr, that is the command that seems to fail for you in generate-packaging-dir
[13:37] <rvr> I mean, why is git needed to run the tests?
[13:48] <cachio> jdstrand, hey?
[13:49] <cachio> jdstrand, is the dbus interface in http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/?
[13:50] <fgimenez> rvr, not sure, it seems that some test needs that packaging dir in place
[13:51] <ogra_> cachio, if you know the deb versions you need http://people.canonical.com/~ogra/core-builds/ has links to the manifest files for the core snaps
[13:52] <cachio> ogra_, nice, thanks
[13:54] <jdstrand> cachio: I don't know. 2.20~ppa2 has it according to https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
[13:55] <jdstrand> cachio: https://launchpadlibrarian.net/288335774/core_16.04.1_amd64.manifest has 2.16
[13:55] <jdstrand> oh, hold on
[13:55] <jdstrand> https://launchpadlibrarian.net/298419516/core_16.04.1_amd64.manifest shows 2.20, so yes, it should have it
[13:55] <ogra_> 2.20 is in the last core ...
[13:56] <ogra_> but i'm not 100% sure the last core is also in the last image yet, you might need to snap refresh it
[13:56] <ogra_> will definitely be in tomorrows daily
[13:58] <cachio> ogra_, ok, I'll update the core in that case
[13:59] <ogra_> just check with snap list first :)
[14:01] <cachio> ogra_, sure, tx
[14:08] <mup> PR snapcraft#991 opened: Updated ant plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/991>
[14:08] <mup> PR snapcraft#992 opened: Updated make plugin to use get_build_properties()  <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/992>
[14:12] <rvr> fginther: Three failures in the candidate image (custom built) http://paste.ubuntu.com/23638197/
[14:12] <rvr> Oops
[14:12] <rvr> fgimenez: ^
[14:16] <fgimenez> rvr, it seems that you are using an outdated version of spread, that should explain the two errors about "/bin/bash: line 54: MATCH: command not found"
[14:17] <fgimenez> rvr, you had before the tests/main/ubuntu-core-reboot error, the service doesn't comes up on time after reboot, i haven't been able to reproduce
[14:19] <rvr> fgimenez: I did a git pull just before running the tests
[14:19] <fgimenez> rvr, the tests/main/interfaces-mount-observe error is strange, an EOF in the middle of a test can be caused by an unexpected reboot or a lost of connection
[14:19] <fgimenez> rvr, i mean the spread executable
[14:19] <rvr> fgimenez: Oh, I see
[14:20] <rvr> Ok, upgraded
[14:21] <rvr> fgimenez: Yes, seems the connection was lost
[14:26] <rvr> fgimenez: System is in initramfs prompt :P
[14:26] <mup> PR snapcraft#993 opened: Updated qmake to use get_build_properties and get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/993>
[14:26] <rvr> I remember we had this problem before
[14:38] <fgimenez> rvr, this is executed on a dragonboard, right?
[14:38] <rvr> fgimenez: Right
[14:41] <fgimenez> rvr, we had problems before with the tests/main/ubuntu-core-upgrade test, it seems that some state is left behind after the cycle of checks and the system believes that it needs to reboot to finish an upgrade, because the core snap version that is supposed to be upgraded to is not actually there, the system crashes
[14:41] <fgimenez> rvr, that would explain the EOF you had too
[14:42] <rvr> fgimenez: Yes, because it cannot connect to the system anymore
[14:42] <rvr> But it also breaks it completely, that's ugly :(
[14:43] <fgimenez> rvr, this test problem should be already fixed, we need to verify, anyway, could you please execute the suite again removing tests/main/ubuntu-core-upgrade folder from snapd's tree? you should need to reflash the image too
[14:43] <rvr> fgimenez: Sure, and will use the available images
[14:44] <fgimenez> rvr, great, thanks!
[15:35] <cachio> jdstrand, to use that interface, should I do something special?
[15:35] <cachio> jdstrand, I rat the tests and those are still getting the same erroro
[15:36] <cachio> jdstrand,  dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name 'com.canonical.kpi.signal': no such name
[15:37] <mup> PR snapd#2499 opened: tests: add super simple classic confinement test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2499>
[15:38] <cachio> jdstrand, this is the config file that I am using http://paste.ubuntu.com/23638496/
[15:38] <jdstrand> cachio: yes, you need to declare what you are going to use
[15:39] <jdstrand> https://github.com/snapcore/snapd/wiki/Interfaces#dbus has the details
[15:39] <jdstrand> cachio: but essentially add this to your yaml:
[15:39] <jdstrand> slots:
[15:39] <mup> Bug #1650520 changed: Qt's bearer needs access to NetworkManager APIs <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1650520>
[15:39] <jdstrand>   kpi-dbus:
[15:39] <jdstrand>     interface: dbus
[15:39] <jdstrand>     bus: system
[15:39] <jdstrand>     name: com.canonical.kpi.signal
[15:40] <cachio> jdstrand, ok, make sense
[15:40] <jdstrand> cachio: that should give you a bus policy very similar to what you pasted
[15:41] <jdstrand> cachio: similar, becuase 'default' doesn't allow 'own'
[15:41] <cachio> ok, so i dont need to copy the config file anymore, right?
[15:41] <jdstrand> no
[15:41] <jdstrand> cachio: depending on how your snap is written, it may even work in strict mode
[15:42] <jdstrand> cachio: but if you have a complicated dbus api, you might still need to use devmode
[15:42] <cachio> ok, I'll try with this new conf, thanks!!
[15:42] <jdstrand> (see the documentation for what I mean by that)
[15:50] <mup> PR snapcraft#994 opened: Updated kbuild plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/994>
[15:53] <mup> PR snapcraft#995 opened: Updated kernel plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/995>
[15:53] <mup> PR snapd#2500 opened: tests: run snap confine tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2500>
[15:56] <mup> PR snapcraft#996 opened: Updated nodejs plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/996>
[15:59] <mup> PR snapcraft#997 opened: Updated gulp plugin to use get_build_properties() and get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/997>
[16:02] <mup> PR snapcraft#998 opened: Updated gulp plugin to use get_build_properties() and get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/998>
[16:05] <rvr> fgimenez: spread -v -reuse external:ubuntu-core-16-arm-64 doesn't work as command line now
[16:05] <rvr> error: invalid project name: ""
[16:06] <rvr> And --help doesn't help X-)
[16:08] <mup> PR snapcraft#999 opened: Updated autotools plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/999>
[16:20] <rvr> This error is familiar to me
[16:20] <rvr> It used to happen before, and we were force to use another version of spread
[16:21] <rvr> Is it not solved yet?
[16:24] <fgimenez> rvr, iirc that was happening before because spread wasn't installed with the --devmode option
[16:24] <rvr> fgimenez: Hmmm
[16:24] <rvr> fgimenez: I did a refresh
[16:24] <rvr> Hmmm
[16:24] <rvr> Does it keep the --devmode?
[16:25] <fgimenez> rvr you can check with snap list
[16:27] <rvr> fgimenez: Thanks, you were right. I reinstalled with --devmode and it works now.
[16:28] <fgimenez> rvr, np :) good to know
[16:29] <kyrofa> flexiondotorg, yeah that would probably work, but doesn't that mean that python-debian doesn't specify all of ITS dependencies?
[16:30] <kyrofa> flexiondotorg, by the way, the debian package python3-debian works fine. But in our baby steps toward snapping it, we're trying to make sure it works from pip as much as possible
[16:33] <kyrofa> barry, you know all there is to know about python-debian, right? ;)
[16:33] <barry> kyrofa: oh sure ;)
[16:34] <barry> kyrofa: what's up?
[16:34] <kyrofa> barry, any idea why the debian package depends upon chardet, but pip doesn't (and fails as a result)?
[16:35] <mup> PR snapd#2501 opened: tests: enable the ppc64el tests again <Created by mvo5> <https://github.com/snapcore/snapd/pull/2501>
[16:36] <barry> kyrofa: it all has to do with vendorizing (long explanation follows)
[16:36] <barry> upstream pip "vendors" several packages, meaning it comes with its own private copies of things.  other packages do this, e.g. requests
[16:36] <kyrofa> Ah, but you can't do that in debian packages
[16:36] <barry> this violates debian policy because say there were a security vulnerability in chardet, fixing python-chardet wouldn't fix pip's use of it
[16:37] <barry> so we devendorize, meaning adjust those packages to use system versions intsead of their private copies.  which is easier for some packages and harder for others
[16:37] <barry> pip upstream is friendly to our needs, so pip is rather easy to devendorize
[16:38] <barry> and when we build pip we "rewheel" a bunch of packages, meaning we turn their debian layout back into a wheel, and then arrange for the wheel to be used by pip.  we label these with Built-Using in pip's d/control
[16:38] <barry> chardet is one of the rewheel'd packages
[16:38] <barry> kyrofa: exactly
[16:38] <kyrofa> barry, okay, that makes perfect sense
[16:39] <kyrofa> barry, though it doesn't explain the failure I'm seeing: https://travis-ci.org/snapcore/snapcraft/jobs/180859624
[16:39] <kyrofa> (scroll to the bottom)
[16:39] <kyrofa> I added python-debian to the requirements.txt, and that's the result
[16:39] <barry> let me check something
[16:41] <barry> kyrofa: that's interesting because python3-debian definitely Depends explicitly on python3-chardet
[16:41] <barry> (at least in unstable)
[16:41] <kyrofa> barry, that failure isn't installing the deb though-- that one is using the requirements.txt to install it
[16:42] <longsleep> I still fail to register my key with snapcraft, 'account-key-request' assertion failed - anyone here to help now?
[16:42] <kyrofa> barry, it's worth noting that, if I use python3-debian instead of the pip package for all tests, everything works fine
[16:43] <kyrofa> barry, this is the PR corresponding to that test run, by the way: https://github.com/snapcore/snapcraft/pull/941/files#diff-b4ef698db8ca845e5845c4618278f29aR19
[16:43] <mup> PR snapcraft#941: Support symlinks within deb sources <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
[16:43] <barry> so that would get it through pypi, which looks relatively up-to-date (it's a version behind the unstable version)
[16:46] <barry> kyrofa: so i think the problem is that pypi's python-debian 0.1.28 doesn't have an install_requires on chardet, and chardet isn't in your requirements.txt, so pip never thinks it needs to install it.  that sounds like a bug in the upstream package setup.py
[16:46] <kyrofa> barry, indeed, my thoughts as well
[16:47] <kyrofa> barry, shall I report that?
[16:47] <barry> kyrofa: no need :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838695
[16:48] <kyrofa> Ha!
[16:48]  * barry sees if he can commit the fix to $vcs
[16:49] <kyrofa> barry, so adding chardet to my requirements.txt is a satisfactory workaround? Just use the latest version?
[16:49] <barry> kyrofa: yep, that should work
[16:49] <kyrofa> barry, okay thank you, and thanks for taking a look at that bug!
[16:50] <barry> kyrofa: np!  that's what i'm here for :)
[16:52] <barry> yep, nope, i can't push to its repo, so i'll just follow up on the bug
[16:56] <mup> PR snapcraft#1000 opened: Updated godeps plugin to use get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/1000>
[17:02] <mup> PR snapcraft#977 closed: Prefer in-snap libraries to system libraries <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/977>
[17:05] <mup> PR snapcraft#1001 opened: Updated catkin plugin to use get_pull_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/1001>
[17:11] <mup> PR snapcraft#1002 opened: Updated python plugin to support get_pull_properties <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/1002>
[17:14] <mup> PR snapcraft#1003 opened: Release changelog for 2.24 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1003>
[17:20] <mfeatherston> I'm working on an ubuntu core image and I need to include some system firwmare.  Is there some way for me to overlay files in /lib/firwmare?
[17:21] <ogra_> mfeatherston, in the gadget snap
[17:23] <mfeatherston> This is what I was trying: https://paste.ee/p/zMQFX
[17:23] <ogra_> (or alternatively you can roll your own kernel snap and ship them there)
[17:23] <mfeatherston> I'm also doing that, but I didn't see a way to pack the firmware in the kernel
[17:24] <ogra_> if /lib/firmware is in there it gets used
[17:25] <mfeatherston> /lib/firmware is missing from the filesystem as far as I can tell, but they show up in /writable/system-data/snap/tsimx6-gadget/x1/firmware/ and /snap/tsimx6-gadget/x1/firmware/
[17:26] <mfeatherston> well, I should rephrase that, the contents in /lib/firwmare I expect are missing
[17:26] <mfeatherston> the standard /lib/firwmare is there
[17:35] <kyrofa> flexiondotorg, I've updated bugfix/1634813/support_debs_containing_symlinks bringing it up to date with master and also adding chardet to the requirements. This should pass tests as soon as I propose it, though I'm waiting to do that so I don't steal adt resources from release
[17:35] <flexiondotorg> kyrofa, Thanks for the update :-)
[17:36] <rvr> fgimenez: http://paste.ubuntu.com/23639009/
[17:36] <mfeatherston> ogra_, thanks packing it in the kernel will work for me.  I see others from my build present there.
[18:04] <fgimenez> rvr, seems that the connection was lost again, but without EOF this time, i'll try to reproduce
[18:12] <robertkowalski> hi
[18:12] <robertkowalski> i'm on the apache couchdb project
[18:12] <robertkowalski> and want to register the snap "couchdb"
[18:12] <robertkowalski> it says the name is registered
[18:12] <robertkowalski> and the text mentiones one can request the name, but i don't find instructions where to go for that anywhere
[18:15] <robertkowalski> i found it out, the button changes to "request resverd name"
[18:15] <kyrofa> robertkowalski, does it say it's already registered, or that it's reserved?
[18:17] <kyrofa> nessita, can you help with the couchdb name? ^^
[18:17] <mup> PR snapcraft#994 closed: Updated kbuild plugin to use get_build_properties() <Created by ZenHarbinger> <Closed by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/994>
[18:17] <flexiondotorg> robertkowalski, If you scroll down the page, you;ll notice the button text has changed.
[18:18] <flexiondotorg> robertkowalski, I was working with another project and they had the same issue.
[18:19] <flexiondotorg> They didn't notice that the 'Register and proceed to upload' button had also changed to 'Submit name dispute' because that button is rendered off-screen even on a 1080p display.
[18:19] <flexiondotorg> So add a comment to support you name claim and click Submit name dispute :-)
[18:19] <kyrofa> flexiondotorg, I bet it's rendered offscreen on my 4k screen too due to the scaling I have to apply to see anything :P
[18:20] <flexiondotorg> It is. I have that issue. First world problems ;-)
[18:20] <kyrofa> Hahaha
[18:24] <flexiondotorg> Night snappers, time for the pub :-)
[18:24] <robertkowalski> thank you!
[18:24] <robertkowalski> solved!
[18:24] <robertkowalski> yes the button was hard to find
[18:27] <kyrofa> Night flexiondotorg, have a good weekend!
[18:35] <mup> PR snapcraft#941 opened: Support symlinks within deb sources <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/941>
[18:41] <mup> PR snapcraft#1004 opened: Add aliases integration test <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1004>
[18:41] <kyrofa> seb128, if you're interested: https://github.com/snapcore/snapcraft/pull/989
[18:41] <mup> PR snapcraft#989: Add support for disabling system library migration <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/989>
[18:47] <knight__> So with Ubuntu Core there's no deb package support, correct?
[18:47] <mup> PR snapcraft#1003 closed: Release changelog for 2.24 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1003>
[18:48] <madhatter05> hello i am trying to set up ssh keys for my Ubuntu core. the website just has a box on where to import the key.
[18:48] <madhatter05> how do i gen one on windows
[18:49] <mfeatherston> knight__, correct
[18:50] <knight__> So if I want to install something that does not yet have a snap, I have to either 1) install compilers and any required libs, then compile the app, or 2) step #1 and make a snap... is that right?
[18:53] <mfeatherston> what target are you looking to build for?
[18:53] <mfeatherston> I think in most cases you need to end up actually building a snap to run an application on ubuntu core
[18:56] <knight__> target is raspberry pi 3
[18:56] <knight__> (arm)
[18:58] <mfeatherston> You'll probably be cross compiling everything you need from a host pc.  It's not really set up to do development on the unit.
[18:59] <knight__> Ok. Are there docker or Parallels images that can do the snap development?
[18:59] <mfeatherston> I don't know if there are any premade vm images but you could just put Ubuntu in a VM for development
[18:59] <nacc> you can do `snapcraft cleanbuild` as well using lxd
[19:00] <ssweeny> knight__: you can use the classic snap to essentially create a classic ubuntu container
[19:00] <ssweeny> from there you can install debs and go nuts
[19:01] <knight__> ssweeny, but you don't recommend that for core on embedded right? that's just for a dev environment
[19:01] <ssweeny> knight__: I use it to build arm snaps
[19:01] <knight__> gotcha, right, because the environment more closely matches
[19:01] <knight__> nacc, snapcraft cleanbuild?
[19:02] <ssweeny> cleanbuild creates a lxc container on the fly and does the build from scratch
[19:03] <ssweeny> it's good for ensuring that you didn't miss any dependencies (like build-packages) because they were already on your host
[19:03] <knight__> ah ha
[21:00] <Mritunjai> Hi All
[21:05] <mup> Bug #1650671 opened: Content sharing from snap common is broken <Snappy:New> <https://launchpad.net/bugs/1650671>
[21:32] <jdstrand> roadmr, nessita: hey, fyi, there are several snaps in the review queue that seem stuck between upload and being reviews. 'task state unknown', 'Automated review for version 0.1: invalid'
[21:33] <roadmr> jdstrand: nessita is off today and I'm almost EOD :( which ones? :(
[21:33] <roadmr> jdstrand: recent uploads?
[21:33] <jdstrand> https://myapps.developer.ubuntu.com/dev/click-apps/6525/rev/1/
[21:33] <jdstrand> https://myapps.developer.ubuntu.com/dev/click-apps/5243/rev/12/
[21:34] <roadmr> jdstrand: do you know if this uses classic confinement?
[21:34] <jdstrand> roadmr: they are both clicks
[21:34] <roadmr> jdstrand: so not classic :)
[21:35] <jdstrand> no :)
[21:35] <knight__> Is there a way to define some command line steps that have to take place before the plugin (make in this case) kicks in?
[21:35] <roadmr> jdstrand: ok... yes, we had an issue with clicks trying to check the package_declaration (not there for clicks!) for classic allowance. We fixed one, didn't know about these two, but the timing seems about right.
[21:36] <roadmr> jdstrand: I think they need manual fixing :( I'll see what I can do but it may need to wait for Monday :(
[21:37] <jdstrand> roadmr: well, I don't know your procedures for that, but I just wanted to make sure you guys knew about them
[21:37] <roadmr> jdstrand: I don't think we did, or we would have fixed them yesterday :( thanks for the heads-up
[21:39] <jdstrand> roadmr: well, you know now :)
[21:39] <roadmr> many thanks :)
[21:44] <jdstrand> lool: hey, so you have 26 revisions of elasticsearch-smb all with the same error: package contains external symlinks: usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts lint-snap-v2_external_symlinks
[21:45] <jdstrand> lool: I'm pretty sure that is going to make the snap's ssl connections fail. can you remove/withdraw r1-r26 and then upload an r27 with that fixed?
[21:46] <knight__> A part I am trying to build requires a directory to be made before the make is run, and I can't quite figure out how to run arbitrary commands before the make plugin builds the source.
[21:56] <roadmr> jdstrand: the queue looks quite clean, so I'm going to venture saying there weren't any other packages in that "invalid" state? (I'm working on fixing these two, wanted to check if there are more I can process at the same time)
[22:22] <knight__> Can you specify commands that need to run in a snapcraft.yaml?
[22:47] <jdstrand> robertkowalski: just those two
[22:48] <jdstrand> robertkowalski: sorry, nm
[23:01] <lool> jdstrand: elasticsearch-smb: yup, actually rmescandon has sent a fix, I told him to push it to master for LP to pick it up; the snap is owned by me but LP pushes the builds; note that this is probably an issue for all snaps with default-jre-headless
[23:06] <jdstrand> lool: it used to always be (that is how I know that the ssl doesn't work), but a recent package I did had snapcraft fixing it up. please file a bug
[23:07] <jdstrand> I know sergiusens is aware of this issue
[23:07] <lool> jdstrand: is that a fix in a jre package in z or a fix in snapcraft?
[23:07] <lool> rmescandon pushed a workaround in the snap, but didn't merge i
[23:07] <lool> it
[23:08] <jdstrand> lool: snapcraft afaik
[23:08] <jdstrand> there is a symlink in the jre package that gets created and snapcraft I think attempts to clean it up
[23:09] <lool> yeah, it's supposed to
[23:09] <lool> I see some fairly old commits around this in the snapcraft history
[23:09] <lool> I'll file a new bug against snapcraft
[23:14] <lool> jdstrand: https://bugs.launchpad.net/snapcraft/+bug/1650686
[23:14] <mup> Bug #1650686: Some symlinks not properly fixed up <Snapcraft:New> <https://launchpad.net/bugs/1650686>
[23:14] <lool> jdstrand: thanks for attempting a review and have a good WE
[23:15] <jdstrand> lool: it's weird. it worked for my minecraft snap. I stage-packages both openjdk-8-jre-headless and ca-certificates-java
[23:15] <lool> jdstrand: ah maybe I need ca-certificates-java
[23:16] <lool> jdstrand: BTW we should arrange for this lint checks to be run in local snapcraft runs somehow
[23:16] <jdstrand> I imagine when both are snaps that will be more feasible
[23:17] <lool> yeah
[23:24] <mup> Bug #1650688 opened: timedatectl set-timezone fails on UC16 <Snappy:New> <https://launchpad.net/bugs/1650688>
[23:30] <mup> Bug #1650689 opened: snap refresh with a channel arg should offer a way to switch the channel w/out a snap update being available <Snappy:New> <https://launchpad.net/bugs/1650689>