[04:19] <mup> Bug #1609883 changed: Add an interface to allow access to /var/lock and/or /run/lock/ <cpc> <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1609883>
[04:19] <mup> Bug #1620693 changed: Permission denied to access /sys/kernel/mm/hugepages/ <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1620693>
[04:19] <mup> Bug #1638529 changed: Auto-connect is not working for connection between network-manager and modem-manager <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1638529>
[08:52] <pshod> " kernel needs apparmor 2.4 compatibility patch " for snap install on ubuntu mate for pi3
[08:52] <pshod> help1
[08:52] <pshod> help1
[08:52] <pshod> help!
[09:37] <pshod_> anyone answered pshod?
[09:39] <mup> PR snapd#2983 closed: Support spread testing with proxy <Created by nuclearbob> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2983>
[10:29] <torusJKL> Hi
[10:29] <torusJKL> I'm creating a Snap which contains 2 parts. The second part needs files that have been created in the first part otherwise it will not build.
[10:30] <torusJKL> I tried to use a relative path, starting in the root directory of the current part, but libtool does not accept it. If I use the absolute path it builds but now the snapcraft.yaml is not portable anymore.
[10:30] <torusJKL> This is what I have now:
[10:30] <torusJKL> build: |
[10:30] <torusJKL>   ./autogen.sh && ./configure LDFLAGS='-L/home/snapcraft/mySnap/parts/libdb4.8/install/usr/local/BerkeleyDB.4.8/lib/' CPPFLAGS='-I/home/snapcraft/mySnap/parts/libdb4.8/install/usr/local/BerkeleyDB.4.8/include/'
[10:30] <torusJKL> Is there an environmental variable that holds the absolute path of previous parts? Or is there any other way to do this?
[10:31] <torusJKL> I have also asked this here: http://askubuntu.com/questions/890448/snapcraft-how-do-i-use-an-absolute-path-to-files-of-a-previous-part
[10:33] <joedborg> o/
[10:34] <joedborg> hi torusJKL, have you used the stage and prime directives to keep the files?
[10:34] <joedborg> torusJKL, you can check by looking into the prime and stage directories
[10:43] <torusJKL> hi joedborg. How would I active the stage and prime directives?
[10:44] <joedborg> torusJKL, have a look at https://snapcraft.io/docs/reference/plugins/common and focus on the 'stage' and 'snap' sections (but replace 'snap' with 'prime in your yaml, or you'll get warnings)
[10:44] <joedborg> torusJKL, I'm still pretty new to snaps as well, so I hope i've understood what you mean
[10:52] <torusJKL> joedborg. So I could copy the files from the first part to the stage area and then point to them. is there an environment variable for the stage area path?
[10:57] <torusJKL> joedborg. I will try the following $SNAPCRAFT_STAGE
[11:01] <joedborg> torusJKL, you could do it manually, but it'll make repeatably a bit difficult
[11:02] <torusJKL> joedborg, I will try it. Thanks!
[11:03] <joedborg> torusJKL, no problem; good luck.  feel free to ping me if you have any other problems (I might not be able to help, but can always try)
[11:05] <mup> PR snapd#2992 opened: hookstate: run the right "snap" command in the hookmanager <Created by mvo5> <https://github.com/snapcore/snapd/pull/2992>
[11:12] <alf_> Hi all! I am trying to install a snap on trusty on a system with limited network connectivity, and I get:
[11:13] <alf_> Get
[11:13] <alf_> https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2
[11:13] <alf_> Cconfinement: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
[11:14] <alf_> Which is expected since the network may not be working. However, and here is the issue, I get the same error when trying to install the same snap from a local copy (.snap/.assert)
[11:14] <alf_> Any idea what could be going on?
[12:16] <mup> Bug #1670662 opened: snap refresh modem-manager returns always that it has been refreshed (and it hasn't) <Snappy:New> <https://launchpad.net/bugs/1670662>
[13:15] <ogra_> ppisati, hey ... did our apparmor patches actually make it into the 96boards kernel tree or is that only in ours ?
[13:19] <mcphail> Wonder if it is just coincidence my "core" snap is at revision "1337"? :p
[13:20] <ogra_> mcphail, magic ;)
[13:25] <mup> PR snapd#2985 closed: hookstate: disable configure hook for core on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2985>
[13:29] <ppisati> ogra_: only our, and we keep getting new patches
[13:47] <mup> Bug #1670662 changed: snap refresh modem-manager always returns that it has been refreshed (and it hasn't) <Snappy:Invalid by pedronis> <https://launchpad.net/bugs/1670662>
[14:54] <qengho> for a tarball source with one directory in its root, autotools should start within that child dir as root, yes?
[15:45] <kyrofa> qengho, where is the configure.ac file (or similar)?
[15:47] <qengho> kyrofa: foo/configure.ac
[15:48] <kyrofa> qengho, then yeah, if you're talking about snapcraft, you probably need to set source-subdir to foo
[15:49] <qengho> kyrofa: Is that new behavior? I thought a single dir out of a tarball was a special case, for which the curdir of the upcoming "automake" was different.
[15:55] <kyrofa> qengho, I'm not sure I understand what you're asking. No, source-subdir is not new behavior. It just sets the working directory for the plugin's build process
[15:59] <daker> Question : is there a way to decompress a .snap file without installing it ? renaming it to .zip doesn't help
[16:00] <qengho> daker: It's "unsquashfs"
[16:00] <qengho> It's not a zipfile.
[16:00] <nacc> daker: and to be clear, extensions in linux mean nothing
[16:00] <nacc> daker: so that doesn't make any sense. this isn't windows! :)
[16:00] <qengho> ...except to zip programs.
[16:00] <qengho> seriously, they're dumb.
[16:00] <daker> nacc: for zip programs it does
[16:01] <nacc> i believe that is no longer true
[16:01] <daker> qengho: yes i did forget about this one (y)
[16:01] <nacc> "If no matches are found, the specification is assumed to be a literal filename; and if that  also  fails,  thesuffix  .zip  is  appended."
[16:01] <nacc> that is, the tooling hides that stupidity from you
[16:01] <qengho> daker: "file foo" will tell you the format of a file named foo, btw.
[16:02] <nacc> but in any case, one could assume that if it were a .zip file and it needed to be *.zip to be useful, it would be named *.zip
[16:03] <daker> qengho: thanks it did work
[16:05] <qengho> Lots of things are zipfiles, nacc, not meant to be opened by humans. some Python modules, Jarfiles, Chrome extensions, none will be named .zip, but renaming to .zip will let you unzip them with the command line tools that have existed since 1992.
[16:06] <nacc> qengho: interesting
[16:06] <nacc> qengho: i still stand by my initial response of extensions are dumb on linux :)
[16:06] <qengho> Okay then.
[16:07] <nacc> qengho: but i see why .zip might make sense (using `file` first still seems sane)
[16:18] <mup> Bug #1670165 changed: alsa interface can't see microphones <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1670165>
[16:21] <mup> Bug #1639095 changed: On archlinux, /snap/bin is not added to the $PATH <archlinux> <snapd:New> <https://launchpad.net/bugs/1639095>
[16:23] <mup> PR snapd#2993 opened: interfaces: fix default content attribute value <Created by mvo5> <https://github.com/snapcore/snapd/pull/2993>
[16:27] <mup> Bug #1670749 opened: classic confinement requires manually setting PATH and PYTHONPATH <Snappy:New> <https://launchpad.net/bugs/1670749>
[16:33] <elopio> ppisati: can you please take a look at this? https://github.com/snapcore/snapcraft/pull/1148#pullrequestreview-25426337
[16:33] <mup> PR snapcraft#1148: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1148>
[16:49] <mup> PR snapd#2993 closed: interfaces: fix default content attribute value <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2993>
[16:49] <jdstrand> ogra_: hey, fyi my comments in bug #1670475. it seems to only affect dragonboard
[16:49] <mup> Bug #1670475: apt-secure complaints with classic snap on arm64 (dragonboard) <Snappy:New> <https://launchpad.net/bugs/1670475>
[16:58] <Odd_Bloke> We have a snap that we only want to be available to a few select users (i.e. the people who publish the snap, and a bot account which is auth'd on our production systems).  Are we able to upload a snap in such a way that it can't be installed by Jane Random but can be by a subset of people?
[16:59] <Odd_Bloke> (I know a lot of work has happened on collaboration since I was last looking at this last year, but I haven't kept track closely enough to answer my own question. :p)
[17:00] <pedronis> Odd_Bloke: yes, private snaps work like that
[17:00] <Odd_Bloke> Sweet; and we can have the full channels experience with them?
[17:01] <Odd_Bloke> (We only really need channels 1.0; we won't have more than a single major release for quite some time.)
[17:03] <pedronis> Odd_Bloke: afair yes, they get published to channels etc, just that only the people with access can get them
[17:03] <kyrofa> Odd_Bloke, pedronis that's my understanding as well
[17:12] <mup> PR snapd#2994 opened: interfaces: fix default content attribute value <Created by mvo5> <https://github.com/snapcore/snapd/pull/2994>
[17:17] <Odd_Bloke> OK, great.
[17:18] <Odd_Bloke> And, last question, I think: how do I make a snap private?  None of the snapcraft commands appear to refer to either public or private (and I think the default is public?).
[17:29] <kyrofa> Odd_Bloke, indeed, I'm not sure that's exposed in snapcraft very well, but it's definitely on myapps.developer.ubuntu.com
[17:29] <kyrofa> There's a "Make private" button
[17:34] <Odd_Bloke> Coolio.
[18:11] <cachio_> tyhicks, ping
[18:14] <tyhicks> cachio_: hey - no progress on the dbus perf testing yet
[19:25] <cachio_> tyhicks, ok, thanks
[19:48] <jdstrand> niemeyer: hey, I sent 3 messages to snapcraft@ today, but they aren't showing up. I sent something to the internal list and it did. are my emails to snapcraft@ being moderated?
[19:48] <kyrofa> jdstrand, yeah, last email I see from you was on the 3rd
[19:50] <jdstrand> yeah, I sent two yesterday and they aren't there
[19:51] <jdstrand> it shouldn't be my client. it is sending to the canonical smtp server for the internal list as well as the external, and the ones to the internal are going through
[19:52] <kyrofa> jdstrand, SOMEONE didn't like what you had to say...
[19:52] <kyrofa> :P
[19:52] <jdstrand> I guess so :)
[19:53] <kyrofa> Maybe barry is secretly putting anti-jdstrand filters into mailman and it's only been deployed to snapcraft.io so far
[19:53] <jdstrand> heh
[19:54] <jdstrand> I don't *think* he'd do that to me :)
[19:56] <barry> kyrofa: SSSH!! you're not supposed to tell anyone
[19:57] <kyrofa> Haha
[19:58] <jdstrand> hehe
[20:29] <mup> PR snapd#2995 opened: Extend out-of-process provider support <Created by vosst> <https://github.com/snapcore/snapd/pull/2995>
[20:38] <mwhudson> kyrofa: hey, i think https://github.com/snapcore/snapcraft/pull/1170 is waiting for you?
[20:38] <mup> PR snapcraft#1170: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170>
[20:40] <kyrofa> mwhudson, +1 from me, but I'm not clear if elopio is supposed to do something before it merges
[20:41] <mwhudson> kyrofa: fair enough, but could you change your review? i don't know who is waiting for who either :)
[20:41] <kyrofa> mwhudson, oh I did!
[20:41] <kyrofa> mwhudson, thanks for the ping, I was waiting to see what happened there and didn't notice I was still requesting changes
[20:41] <mwhudson> kyrofa: oh sorry, thanks, the mail took a while to arrive
[21:28] <mup> PR snapcraft#1174 opened: copy, dump plugin: ignore symlinks to libc <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1174>
[21:47] <bdmurray> ubuntu core includes a file /usr/share/snappy/dpkg.list, is that available somewhere outside of the Ubuntu Core system?
[21:48] <bdmurray> Like the manifest file on cdimage
[22:08] <mup> Bug #1670852 opened: python entry_points not installed into /snap/<snap>/current/bin <Snappy:New> <https://launchpad.net/bugs/1670852>
[22:23] <mup> PR snapd#2994 closed: interfaces: fix default content attribute value <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2994>
[22:40] <mup> PR snapcraft#1173 closed: demos, tests: add a message to exit the mosquitto subscriber <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1173>
[22:50] <mup> PR snapd#2992 closed: hookstate: run the right "snap" command in the hookmanager <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2992>
[22:51] <kyrofa> Huh... jdstrand I just realized MY emails to snapcraft aren't going through either!
[22:51] <kyrofa> jdstrand, the last one in the archive from me is from the 1st
[22:51] <jdstrand> the saga continues
[22:52] <jdstrand> niemeyer: fyi, ^
[22:52] <kyrofa> jdstrand, even though I see the email I sent in the list on thunderbird
[22:52] <mup> PR snapcraft#1170 closed: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1170>
[22:53] <kyrofa> jdstrand, suddenly all our emails will show up and we'll both look like we're waaaay behind the times
[23:12] <jdstrand> kyrofa: if it is both of us, it is likely others
[23:38] <dasjoe> I'm having some trouble getting my apu2c4 to boot snappy 16 off a USB stick, is ttyS0 disabled after grub?