From timo.jyrinki at gmail.com Wed Feb 1 06:52:22 2017 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Wed, 1 Feb 2017 08:52:22 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: 2017-01-31 18:29 GMT+02:00 Olivier Tilloy : > On Tue, Jan 31, 2017 at 4:56 PM, Leo Arias wrote: >> Isn't this what Kyle fixed by adding build-attributes: [no-system-libraries] ? >> >> http://snapcraft.io/docs/build-snaps/syntax#parts > > Yes, that seems to be it, indeed. Thanks for the pointer Leo, I wasn’t > aware of this new feature. With this, no need to artificially add > stage packages. Neat! Excellent, thanks Leo and Kyle! -Timo From didier.roche at canonical.com Wed Feb 1 08:38:04 2017 From: didier.roche at canonical.com (Didier Roche) Date: Wed, 1 Feb 2017 09:38:04 +0100 Subject: Changing default snapcraft behavior and erroring on missing libraries In-Reply-To: <7g3ysh.oknnf9.1hge9g2-qmf@smtp.googlemail.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> <7g3ysh.oknnf9.1hge9g2-qmf@smtp.googlemail.com> Message-ID: <83321ee6-d36b-85d7-8fa2-4c3fd2020643@canonical.com> Le 31/01/2017 à 18:33, Sergio Schvezov a écrit : > On Tue, 31 Jan 2017 17:40:09 +0100, Didier Roche wrote: >> Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : >>> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >>>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >>>> wrote: >>>>>> Do we have a clear understanding of why this happens? Qt apps are >>>>>> supposed to be binary compatible against newer releases. >>>>>> One exception could be if the app itself is shipping some plugins, >>>>>> specific Qt version. >>>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >>>>> Qt version which should not be the case when the platform snap is >>>>> used. >>>> This is a bit tricky: when packaging a Qt application that uses the >>>> platform snap, snapcraft will use ldd to crawl the app’s binaries and >>>> will automagically add the libraries that it depends on to the >>>> resulting snap (those libs are taken from the host system). >>> unless you tell it is ok. >>> >> (first, sorry for the bad control+enter on my previous email) >> >> I'm a little bit uncomfortable with that statement for mainly 2 reasons: >> * Changing default behavior is always cumbersome to developers who just >> wants to work on their app. Here, we are introducing a breaking change >> (snaps that used to build won't build anymore, especially those on >> core). It's annoying also for people who did hook up their CI to >> autopublish a snap. >> >> This is why we need to justify and carefully explain the change, in a >> clear, defined way. I would suggest coordinating with David for a blog >> post that we promote here and on the developer website: >> 1. Why are we changing this? -> we are not doing this just to bother >> you, developer, here is the technical reason why we are doing it. > The reason is simple, we are leaking libraries by default, like libsupersecrect.so.1 and you won't even know about it. > > I do fully understand the reason, don't worry ;), the first point was more "this needs to be planned out, synchronised, and well explained to the world". So, if we go to that breaking changes, please ensure that we have all content with all points and examples for an easy transition path. This is how we can allievate some unhappiness to developers about a breaking changes and make them part of it, while helping them transitionning. From didrocks at ubuntu.com Wed Feb 1 08:40:03 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 1 Feb 2017 09:40:03 +0100 Subject: Changing default snapcraft behavior and erroring on missing libraries In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> Message-ID: <9f761ae1-c2c2-7a5f-2f82-e900d0efcca7@ubuntu.com> Le 31/01/2017 à 18:02, Kyle Fazzari a écrit : > > On 01/31/2017 08:40 AM, Didier Roche wrote: >> Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : >>> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >>>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >>>> wrote: >>>>>> Do we have a clear understanding of why this happens? Qt apps are >>>>>> supposed to be binary compatible against newer releases. >>>>>> One exception could be if the app itself is shipping some plugins, >>>>>> because in that case I believe that these plugins are somehow bound to a >>>>>> specific Qt version. >>>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >>>>> Qt version which should not be the case when the platform snap is >>>>> used. >>>> This is a bit tricky: when packaging a Qt application that uses the >>>> platform snap, snapcraft will use ldd to crawl the app’s binaries and >>>> will automagically add the libraries that it depends on to the >>>> resulting snap (those libs are taken from the host system). >>> This will be disabled by default and snapcraft will error on missing libraries >>> unless you tell it is ok. >>> >> (first, sorry for the bad control+enter on my previous email) >> >> I'm a little bit uncomfortable with that statement for mainly 2 reasons: >> * Changing default behavior is always cumbersome to developers who just >> wants to work on their app. Here, we are introducing a breaking change >> (snaps that used to build won't build anymore, especially those on >> core). It's annoying also for people who did hook up their CI to >> autopublish a snap. >> >> This is why we need to justify and carefully explain the change, in a >> clear, defined way. I would suggest coordinating with David for a blog >> post that we promote here and on the developer website: >> 1. Why are we changing this? -> we are not doing this just to bother >> you, developer, here is the technical reason why we are doing it. >> 2. A small and minimal snippet of code of before/after so that people >> aren't lost and know what to do >> 3. When is it going to be released. Version, date, upgrade process. >> >> As this default behavior changes a lot of things, we need to ensure as >> well that all our code snippet and tutorials are updated. So >> coordinating all the way, please! > I completely agree. > >> * The second one is that it seems there is a disable mechanism, mainly >> telling "I know what I'm doing". I think this isn't what we want to >> achieve and it's not fine-grained enough. > Without knowing much about this change, I figure something like this > would fit into build-attributes, which is per-part at least. > >> A common use-case I can see is an app depending on a platform snap and >> embedding additional libraries for some functionality. If we have to >> disable the check for not erroring out on the platform snap libs, we may >> miss, on snap creation, or upgrade or more… additional library checks. >> It seems we shouldn't use a big hammer like this (if it's really what >> I'm understanding from this statement), but rather trying to get a way >> more fine-grained and precise approach. > You mean like asking the snap developer to provide an explicit list of > libraries to error on? Or an explicit list of libraries to pull from the > system if missing? Anything more fine-grained sounds messy to maintain > from a snap developer perspective. And this applies to either direction: > automatically pulling in dependencies from the system, or erroring on > missing libraries. > > Note that, in your example, the consumer app should likely be built with > the providing snap unpacked into the staging area. This guarantees that > the consumer is build with the libraries etc. actually contained in the > providing snap. Using this workflow, snapcraft doesn't do anything > special with the libs contained in the staging area, even if they're > filtered out of the final snap via the `prime` keyword. Where "anything > special" is defined as trying to pull them in from the system, etc. I > figure the "error on missing libs" would follow the same logic, and not > error if the libs are satisfied in stage. Thanks for the answer Kyle! Indeed, if libs in stage are treated as you described (and the ldd isn't done in prime/ thus), this would totally work, and avoid having this manifest libs (that I didn't see each snaps having, but as a fallback, only the platform snaps to generate it). I guess it's just a matter of confirming the behavior will be this one to iremove my second point of concern :) Cheers, Didier From didrocks at ubuntu.com Wed Feb 1 08:43:33 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 1 Feb 2017 09:43:33 +0100 Subject: glGetUniformLocation fails in confinement mode In-Reply-To: <1485891337.10013.193.camel@canonical.com> References: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> <1485787151.10013.118.camel@canonical.com> <407c502a-a7bf-6d79-6f64-75504d2db57d@canonical.com> <1485891337.10013.193.camel@canonical.com> Message-ID: <3fab3ee5-b1e0-c79f-94e4-6a334925456a@ubuntu.com> Le 31/01/2017 à 20:35, Jamie Strandboge a écrit : > On Tue, 2017-01-31 at 17:04 +0100, Didier Roche wrote: >> Le 30/01/2017 à 15:39, Jamie Strandboge a écrit : >>> On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote: >>>> On 2017-01-30 01:56 AM, Spencer Parkin wrote: >>> While harmless, it is also confusing. I'm not super familiar with the >>> desktop >>> part and wonder how we can improve this. Didier or Seb, would the >>> bootstrapping >>> process work ok if we allowed read on the /usr/share/glib-2.0/schemas/ >>> directory >>> in the unity7 (and maybe the x11) transitional classic interfaces? >>> >> The issue is indeed that there is classic confinement vs core only. I >> thought that it makes sense to read all traditional glib schema paths, >> test that they exists, and if they exist, compile the gsetting schemas >> alongside the snap specific ones. >> >> /usr/share/glib-2.0/schemas/, as Jamie told, don't exist on core, so we >> just skip it and don't have that denial. On classic however, it does. >> >> I'm surprised thought hat there is even a denial: I thought classic gave >> you access to your whole host system and this kind of things won't >> happen, do you mind giving some precisions Jamie to fix my twisted >> perception? >> > 'classic' is an overloaded term. There is 'classic distro' (eg Ubuntu Desktop) > and there is 'classic confinement' (ie, 'confinement: classic'). What the above > denial is about is 'confinement: strict' on classic Ubuntu and my question was > if the desktop part would work ok if we allowed /usr/share/glib-2.0/schemas/ > with 'confinement: strict'. Based on your comment, it sounds like 'yes', but can > you confirm? Ah got it :) So yes, you can add this path. Note that we'll have the same denials if others paths (like /usr/loca/share/glib-2.0/schemas) happens to have some schema files for whatever reason. So, I don't know if you should add all paths (see below) or just the one logically containing schemas. Not that the first element of XDG_DATA_DIRS is based on session name (here, under unity7, we are in the ubuntu session, hence /usr/share/ubuntu, unity8 would be something like /usr/share/unity8 for now…), making this more complex. We don't expect for now (contrary to gconf days), for those to have schema files. > >> For the paths we are checking, we are basing ourself on $XDG_DATA_DIRS, >> appending glib-2.0/schemas to each of them. >> On 16.04 LTS, this is: >> $ echo $XDG_DATA_DIRS >> /usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snap >> d/desktop >> >> As you can see, quite some paths are involved (even if in practice, only >> /usr/share/glib-2.0/schemas/ would exist in general). > I'll keep these in mind. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Wed Feb 1 09:11:23 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 01 Feb 2017 06:11:23 -0300 Subject: Changing default snapcraft behavior and erroring on missing =?iso-8859-1?Q?libraries?= In-Reply-To: <9f761ae1-c2c2-7a5f-2f82-e900d0efcca7@ubuntu.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> Message-ID: <13c39b65-0ac5-41ee-b5c0-64c529a99d14@canonical.com> El miércoles, 1 de febrero de 2017 05h'40:03 ART, Didier Roche escribió: > Le 31/01/2017 à 18:02, Kyle Fazzari a écrit : >> >> On 01/31/2017 08:40 AM, Didier Roche wrote: >>> Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : >>>> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >>>>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >>>>> wrote: >>> * The second one is that it seems there is a disable mechanism, mainly >>> telling "I know what I'm doing". I think this isn't what we want to >>> achieve and it's not fine-grained enough. >> Without knowing much about this change, I figure something like this >> would fit into build-attributes, which is per-part at least. >> >>> A common use-case I can see is an app depending on a platform snap and >>> embedding additional libraries for some functionality. If we have to >>> disable the check for not erroring out on the platform snap libs, we may >>> miss, on snap creation, or upgrade or more… additional library checks. >>> It seems we shouldn't use a big hammer like this (if it's really what >>> I'm understanding from this statement), but rather trying to get a way >>> more fine-grained and precise approach. >> You mean like asking the snap developer to provide an explicit list of >> libraries to error on? Or an explicit list of libraries to pull from the >> system if missing? Anything more fine-grained sounds messy to maintain >> from a snap developer perspective. And this applies to either direction: >> automatically pulling in dependencies from the system, or erroring on >> missing libraries. >> >> Note that, in your example, the consumer app should likely be built with >> the providing snap unpacked into the staging area. This guarantees that >> the consumer is build with the libraries etc. actually contained in the >> providing snap. Using this workflow, snapcraft doesn't do anything >> special with the libs contained in the staging area, even if they're >> filtered out of the final snap via the `prime` keyword. Where "anything >> special" is defined as trying to pull them in from the system, etc. I >> figure the "error on missing libs" would follow the same logic, and not >> error if the libs are satisfied in stage. > > Thanks for the answer Kyle! > Indeed, if libs in stage are treated as you described (and the ldd isn't > done in prime/ thus), this would totally work, and avoid having this > manifest libs (that I didn't see each snaps having, but as a fallback, > only the platform snaps to generate it). > > I guess it's just a matter of confirming the behavior will be this one > to iremove my second point of concern :) https://github.com/snapcore/snapcraft/blob/master/integration_tests/test_library_precedence.py#L28 -- Enviado con Dekko desde mi dispositivo Ubuntu From luca.dionisi at gmail.com Wed Feb 1 10:22:07 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Wed, 1 Feb 2017 11:22:07 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. Message-ID: I did my homework, but to no avail. I found other snapcraft.yaml files with a Vala part using a Vala library staged by another part. Those I found (eg https://github.com/fenryxo/nuvola-snap) seem to apply some workaround that involve modifications to the build scripts of the projectcs themselves. For instance, this build script (https://github.com/tiliado/nuvolaplayer/blob/master/wscript) does a lot of work to construct a 'vapi_dirs' variable to pass to the compiler; thus the snapcraft.yaml can pass some configflags to the autotools plugin to do the tricks. (i.e. build the "nuvola" part with configflags: [ --prefix=/usr, "!--snapcraft", "!--with-unity" ]) This sort of 'workaround' I could also use. But I wonder if snapcraft could find the "right thing to do" on its own in some way. Currently the build-system configuration files for the software that I want to snap is very simple and it expects to find the library in the directory where the compiler searches by default. Then I noticed that the snapcraft.yaml file for pantheon-mail seems not to use any particular configflags for the "snapcraft" case. So I was curious to see how it worked. I installed a fresh 16.04, updated it, then copied in an empty dir the snapcraft.yaml file (from the pantheon-mail branch of snappy-playpen). Then I gave command "snapcraft" and got this error (obviously after a lot of other successful doings): Preparing to build mail Building mail cmake /home/luca/mail/parts/mail/src -DCMAKE_INSTALL_PREFIX= -DCMAKE_INSTALL_PREFIX=/usr -- The C compiler identification is GNU 5.4.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Icon cache will be updated -- Desktop database will be updated -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") -- Found Vala: /usr/bin/valac -- checking for Vala version of 0.22.1 -- found Vala, version 0.30.1 -- Found vapigen: /usr/bin/vapigen -- Unity launcher support: ON -- Targeting WebKitGTK 2.4 -- GTK+ 3.12 support: ON -- Vala fatal warnings: ON -- Checking for modules 'granite;gthread-2.0;glib-2.0>=2.40.0;gio-2.0>=2.28.0;gtk+-3.0>=3.10.0;gee-0.8>=0.8.5;libcanberra>=0.28;sqlite3>=3.7.4;gmime-2.6>=2.6.17;libsecret-1>=0.11;libxml-2.0>=2.7.8;gcr-3>=3.10.1;gobject-introspection-1.0;libaccounts-glib;libgsignon-glib;unity;webkitgtk-3.0>=2.3.0' -- No package 'libaccounts-glib' found -- No package 'libgsignon-glib' found CMake Error at /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:367 (message): A required package was not found Call Stack (most recent call first): /usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:532 (_pkg_check_modules_internal) src/CMakeLists.txt:518 (pkg_check_modules) So I am stuck and couldn't see if/how the Vala compiler finds its way in the example that you gave. Can you help? From ogra at ubuntu.com Wed Feb 1 10:31:16 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 01 Feb 2017 11:31:16 +0100 Subject: Currernt config hook implementation scales very badly Message-ID: <1485945076.25932.40.camel@ubuntu.com> hi, after we recently added a config hook [1] to the core snap it is now possible to disable ssh if you require [2] ... there is a long standing request to do the same for syslog for systems running from SD card, which is why i looked into trying to extend the existing configure script for this, which made me notice some issue... when you call "snap set core foo=bar", there is no indication at all for the script which variable changes a value, neither in the shell environment nor in the argument list. the only way to get your value is to call snapctl for every existing variable [3]. since you dont know what specific variable was requested to change the only way to reliably write it is to write *all* existing variables ...  now, if you package something with a more complex config that you want completely handled via snap config this gets ugly very fast... imagine something like postfix with can potentially have 100s of config options. instead of atomically changing a single option you will regenerate the full config from scratch. this takes a lot longer, bringing the risk of a completely broken config in case of a power loss, beyond resulting an an awful config hook script with a large block of "snapctl get" calls at the top. can we extend the config hook implementation minimally so a "snap set core foo=bar" would at least have something like "SNAP_OPTION=foo" in the environment that the generating script or binary could read to avoid the unnecessary processing or would that break some design concept ? ciao oli [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ hooks/configure [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref erence/core-configuration.md [3] https://github.com/snapcore/snapd/wiki/hooks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From luca.dionisi at gmail.com Wed Feb 1 10:34:56 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Wed, 1 Feb 2017 11:34:56 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: This is another solution that I thought of. I want to put the library mylib-y (the one that is needed by mylib-x) both in the ./stage tree and in the /usr/ prefix of the host system where I prepare the snap. Is there a way to tell snapcraft to do so? It should be similar to the way one can use 'build-packages' to install deb packages on the build host. --Luca From mark at ubuntu.com Wed Feb 1 11:53:59 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 1 Feb 2017 11:53:59 +0000 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1485945076.25932.40.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> Message-ID: <9a4439c6-f924-62a9-d44f-b13a8fab4f3f@ubuntu.com> We definitely want some sort of "dry-run" capability, where you could present a snippet of YAML covering a subset of config and learn whether that would result in a healthy config, and what changes it would actually imply. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From gustavo.niemeyer at canonical.com Wed Feb 1 12:05:52 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 1 Feb 2017 10:05:52 -0200 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1485945076.25932.40.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> Message-ID: Yes, that's in the plans for configuration support already. The idea is to extend snapctl with the ability to introspect exactly which settings have changed since the last successful run of the script, and perhaps which values it used to hold before. For the time being, I suggest not worrying much about that. Just go ahead and implement the semantics you want the user of the snap to experience. Inside the configure hook, check to see if the requested value is already in place and do nothing in that case. This makes the script idempotent, resilient because it ensures the desired state is indeed in place, and also cheap to execute in the common case. On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert wrote: > hi, > > after we recently added a config hook [1] to the core snap it is now > possible to disable ssh if you require [2] ... > > there is a long standing request to do the same for syslog for systems > running from SD card, which is why i looked into trying to extend the > existing configure script for this, which made me notice some issue... > > when you call "snap set core foo=bar", there is no indication at all > for the script which variable changes a value, neither in the shell > environment nor in the argument list. > > the only way to get your value is to call snapctl for every existing > variable [3]. since you dont know what specific variable was requested > to change the only way to reliably write it is to write *all* existing > variables ... > > now, if you package something with a more complex config that you want > completely handled via snap config this gets ugly very fast... imagine > something like postfix with can potentially have 100s of config > options. instead of atomically changing a single option you will > regenerate the full config from scratch. this takes a lot longer, > bringing the risk of a completely broken config in case of a power > loss, beyond resulting an an awful config hook script with a large > block of "snapctl get" calls at the top. > > can we extend the config hook implementation minimally so a "snap set > core foo=bar" would at least have something like "SNAP_OPTION=foo" in > the environment that the generating script or binary could read to > avoid the unnecessary processing or would that break some design > concept ? > > ciao > oli > > [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ > hooks/configure > [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref > erence/core-configuration.md > [3] https://github.com/snapcore/snapd/wiki/hooks > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Wed Feb 1 12:12:44 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 1 Feb 2017 10:12:44 -0200 Subject: Currernt config hook implementation scales very badly In-Reply-To: <9a4439c6-f924-62a9-d44f-b13a8fab4f3f@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <9a4439c6-f924-62a9-d44f-b13a8fab4f3f@ubuntu.com> Message-ID: The current behavior is to present the full configuration every time, so it'll definitely result in a healthy configuration every time no matter what subset has changed, assuming the whole configuration is actually valid, because changing 2 or 10 options at once results in the same behavior on the script end. This was one of the important changes we pursued during the reimplementation last year. What we need now is adding some features to help with the complex cases, when there are hundreds of options and you want to optimize the implementation having in mind exactly which pieces have changed. That optimization may actually be implemented completely internally to the configure script, if we had an urgent use case today, since we can always cache the last valid configuration and diff it. But it'll be nice to have that as a standard feature instead. Also, a good problem to have. On Wed, Feb 1, 2017 at 9:53 AM, Mark Shuttleworth wrote: > > We definitely want some sort of "dry-run" capability, where you could > present a snippet of YAML covering a subset of config and learn whether > that would result in a healthy config, and what changes it would > actually imply. > > Mark > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Wed Feb 1 12:29:48 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 1 Feb 2017 10:29:48 -0200 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: Yeah, besides "build-packages" there's also "stage-packages" which does exactly that. Please let us know how it goes. On Wed, Feb 1, 2017 at 8:34 AM, Luca Dionisi wrote: > This is another solution that I thought of. > I want to put the library mylib-y (the one that is needed by mylib-x) > both in the ./stage tree and in the /usr/ prefix of the host system > where I prepare the snap. > Is there a way to tell snapcraft to do so? > It should be similar to the way one can use 'build-packages' to > install deb packages on the build host. > > --Luca > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Wed Feb 1 12:31:46 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 01 Feb 2017 06:31:46 -0600 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1485945076.25932.40.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> Message-ID: <1485952306.10013.210.camel@canonical.com> On Wed, 2017-02-01 at 11:31 +0100, Oliver Grawert wrote: > hi, > > after we recently added a config hook [1] to the core snap it is now > possible to disable ssh if you require [2] ... > > there is a long standing request to do the same for syslog for systems > running from SD card, which is why i looked into trying to extend the > existing configure script for this, which made me notice some issue... > There is also https://bugs.launchpad.net/snappy/+bug/1504645 for remote syslogging. Is this something that might be implemented as part of this work? (sorry to hijack the thread, feel free to comment in the bug). -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From james.henstridge at canonical.com Wed Feb 1 12:33:50 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Wed, 1 Feb 2017 20:33:50 +0800 Subject: Snap security questions Message-ID: Hi, On our team we've been working to snap the thumbnailer project. While there are some problems that are probably specific to this package, there were a few that I suspect might affect other packages too: 1. Intra-snap D-Bus communication The thumbnailer D-Bus service exposes a number of methods that were intended for use by the "thumbnailer-admin" helper program, but not by outside clients. The generic "dbus" snappy interface does a good job of making sure clients can't call these privileged methods, but I'm left needing a way to get thumbnailer-admin working again. I noticed that the default AppArmor rules allow communication via unix domain sockets with other apps from the same snap, so one easy way to solve my problem would be to also allow applications to send and receive arbitrary messages over the session bus to/from other applications from the same snap. This would let me get thumbnailer-admin working without having to expose the same abilities to third party snaps through a slot. I filed a bug about this one here: https://bugs.launchpad.net/snappy/+bug/1659724 2. Use of the libapparmor aa_is_enabled and aa_query_label APIs When deciding whether to do work on behalf of a client, thumbnailer-service uses a couple libapparmor API calls to determine whether the client has access to a file. Neither of these are working under snappy confinement. The first call we use is aa_is_enabled(), but it seems the policy is to strict to let us determine whether AppArmor is enabled or not. Next we use aa_query_label() to perform the file access check. This fails when trying to read /proc/$pid/mounts to determine where securityfs is mounted. If that is fixed, it will likely fail when trying to access the "/sys/kernel/security/apparmor/.access" file within. I've filed a bug for this one here: https://bugs.launchpad.net/snappy/+bug/1660957 3. QNetworkAccessManager wants to access NetworkManager We use QNetworkAccessManager as our HTTP library. This results in a number of denials for D-Bus method calls to NetworkManager. I can make these denials go away by plugging in to the ":network-manager" slot, but a quick look at that interface shows that it grants a lot more permissions than I need or want (i.e. permission to reconfigure the network). I imagine that a lot of snaps will use QNetworkAccessManager, so it would be nice if the calls it makes were allowed by some auto-connectable interface. If not as part of ":network", then something similar. James. From ogra at ubuntu.com Wed Feb 1 12:53:59 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 01 Feb 2017 13:53:59 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1485952306.10013.210.camel@canonical.com> References: <1485945076.25932.40.camel@ubuntu.com> <1485952306.10013.210.camel@canonical.com> Message-ID: <1485953639.26112.34.camel@ubuntu.com> hi, On Mi, 2017-02-01 at 06:31 -0600, Jamie Strandboge wrote: > On Wed, 2017-02-01 at 11:31 +0100, Oliver Grawert wrote: > > > > hi, > > > > after we recently added a config hook [1] to the core snap it is > > now > > possible to disable ssh if you require [2] ... > > > > there is a long standing request to do the same for syslog for > > systems > > running from SD card, which is why i looked into trying to extend > > the > > existing configure script for this, which made me notice some > > issue... > > > There is also https://bugs.launchpad.net/snappy/+bug/1504645 for > remote > syslogging. Is this something that might be implemented as part of > this work? > > (sorry to hijack the thread, feel free to comment in the bug). > oh, thanks, i had totally forgotten about that one !  i guess adding this  alongside is indeed possible (if the core-support interface allows me writing to /etc/rsyslog.d/, i havent checked yet) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From andreas at canonical.com Wed Feb 1 13:27:19 2017 From: andreas at canonical.com (Andreas Hasenack) Date: Wed, 1 Feb 2017 11:27:19 -0200 Subject: snapcraft cleanbuild proxy support Message-ID: Hi, is there a way to inject the proxy variables into snapcraft buildclean? I tried the usual exports (lower case and upper case), but the lxd that snapcraft creates doesn't get any of those. I checked /etc/environment and /etc/apt/apt.conf.d/*, and I also don't see any hits on my proxy. lxd itself has proxy configured: $ lxc config show config: core.https_address: '[::]' core.proxy_http: http://10.0.100.180:3128/ core.proxy_https: http://10.0.100.180:3128/ core.proxy_ignore_hosts: localhost,127.0.0.1 storage.zfs_pool_name: nsn7/lxd Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Wed Feb 1 13:54:51 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 1 Feb 2017 14:54:51 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: References: <1485945076.25932.40.camel@ubuntu.com> Message-ID: Le 01/02/2017 à 13:05, Gustavo Niemeyer a écrit : > > Yes, that's in the plans for configuration support already. The idea > is to extend snapctl with the ability to introspect exactly which > settings have changed since the last successful run of the script, and > perhaps which values it used to hold before. > > For the time being, I suggest not worrying much about that. Just go > ahead and implement the semantics you want the user of the snap to > experience. Inside the configure hook, check to see if the requested > value is already in place and do nothing in that case. This makes the > script idempotent, resilient because it ensures the desired state is > indeed in place, and also cheap to execute in the common case. > If someone is interested, I have implemented this kind of idempotent configure hook example. It can be found at https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure as part of the christmas snap demo. It features: - support key=value formatting - ignoring, but not erasing unknown keys, comment lines, empty ones. - preserving formatting and ordering, even when changing an existing key. - only snap set arguments will be modified if a value is set. If the value assigned to it is empty, removing the key line - new elements not present in existing configuration file are simply appended. Supporting new keys (like here "foo") is just a matter of adding: update_opt_in_config foo at the end of the file. I hope this helps! (note that the issue is still "what's the supported keys for this snap?") Cheers, Didier > > > On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert > wrote: > > hi, > > after we recently added a config hook [1] to the core snap it is now > possible to disable ssh if you require [2] ... > > there is a long standing request to do the same for syslog for systems > running from SD card, which is why i looked into trying to extend the > existing configure script for this, which made me notice some issue... > > when you call "snap set core foo=bar", there is no indication at all > for the script which variable changes a value, neither in the shell > environment nor in the argument list. > > the only way to get your value is to call snapctl for every existing > variable [3]. since you dont know what specific variable was requested > to change the only way to reliably write it is to write *all* existing > variables ... > > now, if you package something with a more complex config that you want > completely handled via snap config this gets ugly very fast... imagine > something like postfix with can potentially have 100s of config > options. instead of atomically changing a single option you will > regenerate the full config from scratch. this takes a lot longer, > bringing the risk of a completely broken config in case of a power > loss, beyond resulting an an awful config hook script with a large > block of "snapctl get" calls at the top. > > can we extend the config hook implementation minimally so a "snap set > core foo=bar" would at least have something like "SNAP_OPTION=foo" in > the environment that the generating script or binary could read to > avoid the unnecessary processing or would that break some design > concept ? > > ciao > oli > > [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ > hooks/configure > > [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref > erence/core-configuration.md > > [3] https://github.com/snapcore/snapd/wiki/hooks > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > gustavo @ http://niemeyer.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Wed Feb 1 14:46:08 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 01 Feb 2017 08:46:08 -0600 Subject: Snap security questions In-Reply-To: References: Message-ID: <1485960368.10013.235.camel@canonical.com> On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote: > Hi, > > On our team we've been working to snap the thumbnailer project.  While > there are some problems that are probably specific to this package, > there were a few that I suspect might affect other packages too: > > 1. Intra-snap D-Bus communication > > The thumbnailer D-Bus service exposes a number of methods that were > intended for use by the "thumbnailer-admin" helper program, but not by > outside clients.  The generic "dbus" snappy interface does a good job > of making sure clients can't call these privileged methods, but I'm > left needing a way to get thumbnailer-admin working again. > > I noticed that the default AppArmor rules allow communication via unix > domain sockets with other apps from the same snap, so one easy way to > solve my problem would be to also allow applications to send and > receive arbitrary messages over the session bus to/from other > applications from the same snap.  This would let me get > thumbnailer-admin working without having to expose the same abilities > to third party snaps through a slot. > > I filed a bug about this one here: > > https://bugs.launchpad.net/snappy/+bug/1659724 > I was thinking about this one myself. Thanks for filing the bug. I've assigned it to me. > > 2. Use of the libapparmor aa_is_enabled and aa_query_label APIs > > When deciding whether to do work on behalf of a client, > thumbnailer-service uses a couple libapparmor API calls to determine > whether the client has access to a file.  Neither of these are working > under snappy confinement. > > The first call we use is aa_is_enabled(), but it seems the policy is > to strict to let us determine whether AppArmor is enabled or not. > > Next we use aa_query_label() to perform the file access check.  This > fails when trying to read /proc/$pid/mounts to determine where > securityfs is mounted.  If that is fixed, it will likely fail when > trying to access the "/sys/kernel/security/apparmor/.access" file > within. > > I've filed a bug for this one here: > > https://bugs.launchpad.net/snappy/+bug/1660957 This needs some more thought since only "trusted helpers" that are doing some form of mediation themselves need this access. Adding it to the dbus interface by default isn't correct since, for example, ktuberling shouldn't be asking about the security contexts of other snaps (not to mention, this doesn't really have anything to do with the dbus interface). I've assigned it to me and will think about it and will comment in the bug/propose a PR where we can discuss further. > > 3. QNetworkAccessManager wants to access NetworkManager > > We use QNetworkAccessManager as our HTTP library.  This results in a > number of denials for D-Bus method calls to NetworkManager. > > I can make these denials go away by plugging in to the > ":network-manager" slot, but a quick look at that interface shows that > it grants a lot more permissions than I need or want (i.e. permission > to reconfigure the network). > > I imagine that a lot of snaps will use QNetworkAccessManager, so it > would be nice if the calls it makes were allowed by some > auto-connectable interface.  If not as part of ":network", then > something similar. The network-manager API is highly privileged (and messy) and should not be auto- connected. Most applications that use network manager are only trying to figure out if they are online or not, but the way to do that in the network manager API is to query a ton of things a confined app shouldn't typically have. This is what Qt does by default and this is why the connectivity-api was developed and used on Touch[1]. connectivity-api is proxy that can answer questions like "am I online" on behalf of the application. On Touch, iirc, Qt was modified to use connectivity-api so Touch apps transparently used connectivity-api behind the scenes. AIUI, the Personal team is in the process of creating the connectivity- api snap and I suspect this'll work when using ubuntu-platform content snap (Personal team, please correct me if I mispoke). Once connectivity-api works as a snap, the plan is to make the connectivity-api accesses in an interface that is auto-connectable (you might check with the Personal team on the status of all this connectivity-api work).   [1]GNOME has recently created the Network Monitor portal for this as well. It isn't snapped yet, but I see no reason why why it couldn't be with an interface created for it -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mhall119 at ubuntu.com Wed Feb 1 14:48:47 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Wed, 1 Feb 2017 09:48:47 -0500 Subject: Currernt config hook implementation scales very badly In-Reply-To: References: <1485945076.25932.40.camel@ubuntu.com> Message-ID: <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> On a related note, does anybody have a suggestion on a lightweight way of programmatically modifying configs in .ini, XML or JSON? I have a couple of use-cases (erlang-based nosql databases) where the server updates the the local configuration, so I can't just overwrite the whole thing every time. Didier's example will work for a very basic key=value config file, but not something more structured, and I'd hate to introduce Python, Perl or Java just for this. Michael Hall mhall119 at ubuntu.com On 02/01/2017 08:54 AM, Didier Roche wrote: > Le 01/02/2017 à 13:05, Gustavo Niemeyer a écrit : >> >> Yes, that's in the plans for configuration support already. The idea >> is to extend snapctl with the ability to introspect exactly which >> settings have changed since the last successful run of the script, and >> perhaps which values it used to hold before. >> >> For the time being, I suggest not worrying much about that. Just go >> ahead and implement the semantics you want the user of the snap to >> experience. Inside the configure hook, check to see if the requested >> value is already in place and do nothing in that case. This makes the >> script idempotent, resilient because it ensures the desired state is >> indeed in place, and also cheap to execute in the common case. >> > > If someone is interested, I have implemented this kind of idempotent > configure hook example. It can be found at > https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure > as part of the christmas snap demo. > It features: > - support key=value formatting > - ignoring, but not erasing unknown keys, comment lines, empty ones. > - preserving formatting and ordering, even when changing an existing key. > - only snap set arguments will be modified if a value is set. If the > value assigned to it is empty, removing the key line > - new elements not present in existing configuration file are simply > appended. > > Supporting new keys (like here "foo") is just a matter of adding: > update_opt_in_config foo > > at the end of the file. > > I hope this helps! (note that the issue is still "what's the supported > keys for this snap?") > Cheers, > Didier > >> >> >> On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert > > wrote: >> >> hi, >> >> after we recently added a config hook [1] to the core snap it is now >> possible to disable ssh if you require [2] ... >> >> there is a long standing request to do the same for syslog for systems >> running from SD card, which is why i looked into trying to extend the >> existing configure script for this, which made me notice some issue... >> >> when you call "snap set core foo=bar", there is no indication at all >> for the script which variable changes a value, neither in the shell >> environment nor in the argument list. >> >> the only way to get your value is to call snapctl for every existing >> variable [3]. since you dont know what specific variable was requested >> to change the only way to reliably write it is to write *all* existing >> variables ... >> >> now, if you package something with a more complex config that you want >> completely handled via snap config this gets ugly very fast... imagine >> something like postfix with can potentially have 100s of config >> options. instead of atomically changing a single option you will >> regenerate the full config from scratch. this takes a lot longer, >> bringing the risk of a completely broken config in case of a power >> loss, beyond resulting an an awful config hook script with a large >> block of "snapctl get" calls at the top. >> >> can we extend the config hook implementation minimally so a "snap set >> core foo=bar" would at least have something like "SNAP_OPTION=foo" in >> the environment that the generating script or binary could read to >> avoid the unnecessary processing or would that break some design >> concept ? >> >> ciao >> oli >> >> [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ >> hooks/configure >> >> [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref >> erence/core-configuration.md >> >> [3] https://github.com/snapcore/snapd/wiki/hooks >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> >> >> >> >> -- >> gustavo @ http://niemeyer.net >> >> > > > From luca.dionisi at gmail.com Wed Feb 1 15:01:16 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Wed, 1 Feb 2017 16:01:16 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 1:29 PM, Gustavo Niemeyer wrote: > Yeah, besides "build-packages" there's also "stage-packages" which does > exactly that. I think you misunderstood. "build-packages" puts a deb package in the build host, "stage-packages" puts a deb package in stage. But I don't have a deb package of mylib-y. I want snapcraft to build both mylib-y and mylib-x, where mylib-x depends on mylib-y being installed. What I want is snapcraft to put the "install" pieces of the part "mylib-y" in the build host too (other than in stage). Is that doable? Or... wait, are you telling me that I can put the name of another "part" in "build-packages" instead of the name of a deb? > On Wed, Feb 1, 2017 at 8:34 AM, Luca Dionisi wrote: >> >> This is another solution that I thought of. >> I want to put the library mylib-y (the one that is needed by mylib-x) >> both in the ./stage tree and in the /usr/ prefix of the host system >> where I prepare the snap. >> Is there a way to tell snapcraft to do so? >> It should be similar to the way one can use 'build-packages' to >> install deb packages on the build host. >> >> --Luca From didrocks at ubuntu.com Wed Feb 1 15:08:02 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 1 Feb 2017 16:08:02 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> Message-ID: <595ef15b-7267-55cf-1a09-ec20bda76aca@ubuntu.com> Le 01/02/2017 à 15:48, Michael Hall a écrit : > On a related note, does anybody have a suggestion on a lightweight way > of programmatically modifying configs in .ini, XML or JSON? > > I have a couple of use-cases (erlang-based nosql databases) where the > server updates the the local configuration, so I can't just overwrite > the whole thing every time. Didier's example will work for a very basic > key=value config file, but not something more structured, and I'd hate > to introduce Python, Perl or Java just for this. That's exactly why I limited for now to simple key=value (and sourceable) files, while keeping comments and other formats (so .ini file should work if you scaffold it). I wanted to limit the hook to shell script to be architecture independant and not adding a dep on some runtime language. I don't know if it's sane to have more structured one in dash-compatible shell. Introducing helpers written in Go means that you have to compile your (potential arch-all snap like a nodejs webserver) to be arch-dependant. Thoughts? Didier > > > Michael Hall > mhall119 at ubuntu.com > > On 02/01/2017 08:54 AM, Didier Roche wrote: >> Le 01/02/2017 à 13:05, Gustavo Niemeyer a écrit : >>> Yes, that's in the plans for configuration support already. The idea >>> is to extend snapctl with the ability to introspect exactly which >>> settings have changed since the last successful run of the script, and >>> perhaps which values it used to hold before. >>> >>> For the time being, I suggest not worrying much about that. Just go >>> ahead and implement the semantics you want the user of the snap to >>> experience. Inside the configure hook, check to see if the requested >>> value is already in place and do nothing in that case. This makes the >>> script idempotent, resilient because it ensures the desired state is >>> indeed in place, and also cheap to execute in the common case. >>> >> If someone is interested, I have implemented this kind of idempotent >> configure hook example. It can be found at >> https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure >> as part of the christmas snap demo. >> It features: >> - support key=value formatting >> - ignoring, but not erasing unknown keys, comment lines, empty ones. >> - preserving formatting and ordering, even when changing an existing key. >> - only snap set arguments will be modified if a value is set. If the >> value assigned to it is empty, removing the key line >> - new elements not present in existing configuration file are simply >> appended. >> >> Supporting new keys (like here "foo") is just a matter of adding: >> update_opt_in_config foo >> >> at the end of the file. >> >> I hope this helps! (note that the issue is still "what's the supported >> keys for this snap?") >> Cheers, >> Didier >> >>> >>> On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert >> > wrote: >>> >>> hi, >>> >>> after we recently added a config hook [1] to the core snap it is now >>> possible to disable ssh if you require [2] ... >>> >>> there is a long standing request to do the same for syslog for systems >>> running from SD card, which is why i looked into trying to extend the >>> existing configure script for this, which made me notice some issue... >>> >>> when you call "snap set core foo=bar", there is no indication at all >>> for the script which variable changes a value, neither in the shell >>> environment nor in the argument list. >>> >>> the only way to get your value is to call snapctl for every existing >>> variable [3]. since you dont know what specific variable was requested >>> to change the only way to reliably write it is to write *all* existing >>> variables ... >>> >>> now, if you package something with a more complex config that you want >>> completely handled via snap config this gets ugly very fast... imagine >>> something like postfix with can potentially have 100s of config >>> options. instead of atomically changing a single option you will >>> regenerate the full config from scratch. this takes a lot longer, >>> bringing the risk of a completely broken config in case of a power >>> loss, beyond resulting an an awful config hook script with a large >>> block of "snapctl get" calls at the top. >>> >>> can we extend the config hook implementation minimally so a "snap set >>> core foo=bar" would at least have something like "SNAP_OPTION=foo" in >>> the environment that the generating script or binary could read to >>> avoid the unnecessary processing or would that break some design >>> concept ? >>> >>> ciao >>> oli >>> >>> [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ >>> hooks/configure >>> >>> [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref >>> erence/core-configuration.md >>> >>> [3] https://github.com/snapcore/snapd/wiki/hooks >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/snapcraft >>> >>> >>> >>> >>> >>> -- >>> gustavo @ http://niemeyer.net >>> >>> >> >> From stgraber at ubuntu.com Wed Feb 1 15:32:29 2017 From: stgraber at ubuntu.com (=?iso-8859-1?Q?St=E9phane?= Graber) Date: Wed, 1 Feb 2017 16:32:29 +0100 Subject: snapcraft cleanbuild proxy support In-Reply-To: References: Message-ID: <20170201153229.uekbmvg7wsfbgi7l@castiana> On Wed, Feb 01, 2017 at 11:27:19AM -0200, Andreas Hasenack wrote: > Hi, > > is there a way to inject the proxy variables into snapcraft buildclean? > > I tried the usual exports (lower case and upper case), but the lxd that > snapcraft creates doesn't get any of those. I checked /etc/environment and > /etc/apt/apt.conf.d/*, and I also don't see any hits on my proxy. > > lxd itself has proxy configured: > $ lxc config show > config: > core.https_address: '[::]' > core.proxy_http: http://10.0.100.180:3128/ > core.proxy_https: http://10.0.100.180:3128/ > core.proxy_ignore_hosts: localhost,127.0.0.1 Those apply to the LXD daemon itself, as in, for things like downloading LXD images and the like. They're not propagated to the containers as they may be on an interely different network from the host. > storage.zfs_pool_name: nsn7/lxd > > Thanks! Does setting the following container keys help (you can set them on the default profile to have them applied to all containers): environment.http_proxy environment.https_proxy environment.no_proxy Those will simply make sure that LXD always sets those environment variables during all "lxc exec" sessions, as well as pass those to the init process (which unfortunately is likely to discard them). If that doesn't work, then configuring /etc/environment in the container is your best bet. There may be a cloud-init way of doing this, which would be the preferred way of handling all this. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From simon.fels at canonical.com Wed Feb 1 15:50:30 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 1 Feb 2017 16:50:30 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1485953639.26112.34.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <1485952306.10013.210.camel@canonical.com> <1485953639.26112.34.camel@ubuntu.com> Message-ID: <28d3af8d-7d36-fc0f-2d43-e08e15345b7c@canonical.com> On 01.02.2017 13:53, Oliver Grawert wrote: > hi, > On Mi, 2017-02-01 at 06:31 -0600, Jamie Strandboge wrote: >> On Wed, 2017-02-01 at 11:31 +0100, Oliver Grawert wrote: >>> >>> hi, >>> >>> after we recently added a config hook [1] to the core snap it is >>> now >>> possible to disable ssh if you require [2] ... >>> >>> there is a long standing request to do the same for syslog for >>> systems >>> running from SD card, which is why i looked into trying to extend >>> the >>> existing configure script for this, which made me notice some >>> issue... >>> >> There is also https://bugs.launchpad.net/snappy/+bug/1504645 for >> remote >> syslogging. Is this something that might be implemented as part of >> this work? >> >> (sorry to hijack the thread, feel free to comment in the bug). >> > > oh, thanks, i had totally forgotten about that one ! > i guess adding this alongside is indeed possible (if the core-support > interface allows me writing to /etc/rsyslog.d/, i havent checked yet) It doesn't. But I am pretty sure we can add that. regards, Simon From mabnhdev at gmail.com Wed Feb 1 16:09:01 2017 From: mabnhdev at gmail.com (MikeB) Date: Wed, 1 Feb 2017 11:09:01 -0500 Subject: daemon ordering Message-ID: This question has been asked before but never answered. I find myself having to write start scripts for daemon applications to (poorly) emulate the systemd service 'After' functionality for several of my snap applications. Is there any effort to add daemon ordering support to snapcraft/snapd? I think it would be generally useful. Cheers, Mike From ogra at ubuntu.com Wed Feb 1 16:10:12 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 01 Feb 2017 17:10:12 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: <28d3af8d-7d36-fc0f-2d43-e08e15345b7c@canonical.com> References: <1485945076.25932.40.camel@ubuntu.com> <1485952306.10013.210.camel@canonical.com> <1485953639.26112.34.camel@ubuntu.com> <28d3af8d-7d36-fc0f-2d43-e08e15345b7c@canonical.com> Message-ID: <1485965412.25932.45.camel@ubuntu.com> hi, Am Mittwoch, den 01.02.2017, 16:50 +0100 schrieb Simon Fels: >  > > oh, thanks, i had totally forgotten about that one !  > > i guess adding this  alongside is indeed possible (if the core- > > support > > interface allows me writing to /etc/rsyslog.d/, i havent checked > > yet) > It doesn't. But I am pretty sure we can add that. ok, let me start with making the dir writable in the image ;) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From howard at badger-technologies.com Wed Feb 1 17:08:10 2017 From: howard at badger-technologies.com (Howard Cochran) Date: Wed, 1 Feb 2017 12:08:10 -0500 Subject: daemon ordering In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 11:09 AM, MikeB wrote: > I find myself having to write start scripts for daemon applications to > (poorly) emulate the systemd service 'After' functionality for several > of my snap applications. > > Is there any effort to add daemon ordering support to snapcraft/snapd? > I think it would be generally useful. More generally, what is the correct way to specify any arbitrary systemd directives that a daemon may need, such as User= for a service that should run as non-root? Other common examples include ConditionPathExists= EnvironmentFile= KillMode= ExecStartPre=, etc. Thanks, Howard From gustavo at niemeyer.net Wed Feb 1 17:17:23 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 1 Feb 2017 15:17:23 -0200 Subject: daemon ordering In-Reply-To: References: Message-ID: There isn't effort right now, but it sounds like a very reasonable request. We'll have a look into this. On Wed, Feb 1, 2017 at 2:09 PM, MikeB wrote: > This question has been asked before but never answered. > > I find myself having to write start scripts for daemon applications to > (poorly) emulate the systemd service 'After' functionality for several > of my snap applications. > > Is there any effort to add daemon ordering support to snapcraft/snapd? > I think it would be generally useful. > > Cheers, Mike > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Wed Feb 1 17:22:27 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 1 Feb 2017 15:22:27 -0200 Subject: daemon ordering In-Reply-To: References: Message-ID: We'll probably not support completely arbitrary passthrough options as it removes our ability to properly map the functionality into the confined world. One instructive example is the commands that are already supported. They can't be just blindly executed as it might allow the snap to leave their confined space. That said, it already supports several options today, and it's easy to implement additional ones as required and sensible. On Wed, Feb 1, 2017 at 3:08 PM, Howard Cochran < howard at badger-technologies.com> wrote: > On Wed, Feb 1, 2017 at 11:09 AM, MikeB wrote: > > I find myself having to write start scripts for daemon applications to > > (poorly) emulate the systemd service 'After' functionality for several > > of my snap applications. > > > > Is there any effort to add daemon ordering support to snapcraft/snapd? > > I think it would be generally useful. > > More generally, what is the correct way to specify any arbitrary systemd > directives that a daemon may need, such as User= for a service that > should run as non-root? Other common examples include > ConditionPathExists= EnvironmentFile= KillMode= ExecStartPre=, etc. > > Thanks, > Howard > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhall119 at gmail.com Wed Feb 1 17:39:44 2017 From: mhall119 at gmail.com (Michael Hall) Date: Wed, 1 Feb 2017 12:39:44 -0500 Subject: Currernt config hook implementation scales very badly In-Reply-To: <595ef15b-7267-55cf-1a09-ec20bda76aca@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> <595ef15b-7267-55cf-1a09-ec20bda76aca@ubuntu.com> Message-ID: If we made some generic config helpers in Go, they could be part of the core snap instead of being included in each individual one. However, it's actually very hard to have an arch-independent snap, in my experience, due to the number of dependencies you typically need to bundle which are often arch-dependent. Michael Hall mhall119 at gmail.com On 02/01/2017 10:08 AM, Didier Roche wrote: > Le 01/02/2017 à 15:48, Michael Hall a écrit : >> On a related note, does anybody have a suggestion on a lightweight way >> of programmatically modifying configs in .ini, XML or JSON? >> >> I have a couple of use-cases (erlang-based nosql databases) where the >> server updates the the local configuration, so I can't just overwrite >> the whole thing every time. Didier's example will work for a very basic >> key=value config file, but not something more structured, and I'd hate >> to introduce Python, Perl or Java just for this. > > That's exactly why I limited for now to simple key=value (and > sourceable) files, while keeping comments and other formats (so .ini > file should work if you scaffold it). I wanted to limit the hook to > shell script to be architecture independant and not adding a dep on some > runtime language. > > I don't know if it's sane to have more structured one in dash-compatible > shell. Introducing helpers written in Go means that you have to compile > your (potential arch-all snap like a nodejs webserver) to be arch-dependant. > Thoughts? > > Didier >> >> >> Michael Hall >> mhall119 at ubuntu.com >> >> On 02/01/2017 08:54 AM, Didier Roche wrote: >>> Le 01/02/2017 à 13:05, Gustavo Niemeyer a écrit : >>>> Yes, that's in the plans for configuration support already. The idea >>>> is to extend snapctl with the ability to introspect exactly which >>>> settings have changed since the last successful run of the script, and >>>> perhaps which values it used to hold before. >>>> >>>> For the time being, I suggest not worrying much about that. Just go >>>> ahead and implement the semantics you want the user of the snap to >>>> experience. Inside the configure hook, check to see if the requested >>>> value is already in place and do nothing in that case. This makes the >>>> script idempotent, resilient because it ensures the desired state is >>>> indeed in place, and also cheap to execute in the common case. >>>> >>> If someone is interested, I have implemented this kind of idempotent >>> configure hook example. It can be found at >>> https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure >>> as part of the christmas snap demo. >>> It features: >>> - support key=value formatting >>> - ignoring, but not erasing unknown keys, comment lines, empty ones. >>> - preserving formatting and ordering, even when changing an existing key. >>> - only snap set arguments will be modified if a value is set. If the >>> value assigned to it is empty, removing the key line >>> - new elements not present in existing configuration file are simply >>> appended. >>> >>> Supporting new keys (like here "foo") is just a matter of adding: >>> update_opt_in_config foo >>> >>> at the end of the file. >>> >>> I hope this helps! (note that the issue is still "what's the supported >>> keys for this snap?") >>> Cheers, >>> Didier >>> >>>> >>>> On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert >>> > wrote: >>>> >>>> hi, >>>> >>>> after we recently added a config hook [1] to the core snap it is now >>>> possible to disable ssh if you require [2] ... >>>> >>>> there is a long standing request to do the same for syslog for systems >>>> running from SD card, which is why i looked into trying to extend the >>>> existing configure script for this, which made me notice some issue... >>>> >>>> when you call "snap set core foo=bar", there is no indication at all >>>> for the script which variable changes a value, neither in the shell >>>> environment nor in the argument list. >>>> >>>> the only way to get your value is to call snapctl for every existing >>>> variable [3]. since you dont know what specific variable was requested >>>> to change the only way to reliably write it is to write *all* existing >>>> variables ... >>>> >>>> now, if you package something with a more complex config that you want >>>> completely handled via snap config this gets ugly very fast... imagine >>>> something like postfix with can potentially have 100s of config >>>> options. instead of atomically changing a single option you will >>>> regenerate the full config from scratch. this takes a lot longer, >>>> bringing the risk of a completely broken config in case of a power >>>> loss, beyond resulting an an awful config hook script with a large >>>> block of "snapctl get" calls at the top. >>>> >>>> can we extend the config hook implementation minimally so a "snap set >>>> core foo=bar" would at least have something like "SNAP_OPTION=foo" in >>>> the environment that the generating script or binary could read to >>>> avoid the unnecessary processing or would that break some design >>>> concept ? >>>> >>>> ciao >>>> oli >>>> >>>> [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ >>>> hooks/configure >>>> >>>> [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref >>>> erence/core-configuration.md >>>> >>>> [3] https://github.com/snapcore/snapd/wiki/hooks >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/snapcraft >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> gustavo @ http://niemeyer.net >>>> >>>> >>> >>> > > > From howard at badger-technologies.com Wed Feb 1 18:37:38 2017 From: howard at badger-technologies.com (Howard Cochran) Date: Wed, 1 Feb 2017 13:37:38 -0500 Subject: daemon ordering In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 12:22 PM, Gustavo Niemeyer wrote: > We'll probably not support completely arbitrary passthrough options as it > removes our ability to properly map the functionality into the confined > world. > > One instructive example is the commands that are already supported. They > can't be just blindly executed as it might allow the snap to leave their > confined space. This makes sense for certain use cases (such as cloud services built on snappy core). But another market that Canonical appears to be targeting for snappy core is embedded systems. In this context, the device developer is generally more interested in snappy for its software deployment & updating features than for keeping one service within the embedded device completely confined from another service on the same device. Indeed, a great deal of control over service configuration may be required in order to build a complete embedded system. -- Howard From gustavo at niemeyer.net Wed Feb 1 19:02:02 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 1 Feb 2017 17:02:02 -0200 Subject: daemon ordering In-Reply-To: References: Message-ID: Such embedded devices are still computers on the network. We'll all be much better off if they are running their applications confined and secured. That said, we understand that it takes some time and effort until most software is properly confined, which is why we support snaps with classic and devmode confinement. Even there, though, we're keen to ensure that the general model supports a comfortable migration towards proper confinement, as that's where we'll all want to be in the end, so we shouldn't just go loose and implement features that we know will break confinement unnecessarily. On Wed, Feb 1, 2017 at 4:37 PM, Howard Cochran wrote: > On Wed, Feb 1, 2017 at 12:22 PM, Gustavo Niemeyer > wrote: > > We'll probably not support completely arbitrary passthrough options as it > > removes our ability to properly map the functionality into the confined > > world. > > > > One instructive example is the commands that are already supported. They > > can't be just blindly executed as it might allow the snap to leave their > > confined space. > > This makes sense for certain use cases (such as cloud services built > on snappy core). But another market that Canonical appears to be > targeting for snappy core is embedded systems. In this context, the > device developer is generally more interested in snappy for its > software deployment & updating features than for keeping one service > within the embedded device completely confined from another service on > the same device. Indeed, a great deal of control over service > configuration may be required in order to build a complete embedded > system. > > -- Howard > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard at badger-technologies.com Wed Feb 1 20:29:26 2017 From: howard at badger-technologies.com (Howard Cochran) Date: Wed, 1 Feb 2017 15:29:26 -0500 Subject: daemon ordering In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 2:02 PM, Gustavo Niemeyer wrote: > > Such embedded devices are still computers on the network. We'll all be much > better off if they are running their applications confined and secured. > > That said, we understand that it takes some time and effort until most > software is properly confined, which is why we support snaps with classic > and devmode confinement. > > Even there, though, we're keen to ensure that the general model supports a > comfortable migration towards proper confinement, as that's where we'll all > want to be in the end, so we shouldn't just go loose and implement features > that we know will break confinement unnecessarily. Those are all very good points, and I agree with them. It appears, to me, though, that systemd has many features that can enhance confinement and/or tailor it in very targeted ways. It would be nice to be able to leverage those features. And many of its directives don't break confinement (especially some very common ones like Condition* and ExecStartPre/Post, Before, After, PartOf, Wants, Conflicts, RuntimeDirectory, and others. Perhaps snapcraft could have a whitelist of allowed directives when confinement mode is strict? Thanks, Howard From till.kamppeter at gmail.com Wed Feb 1 20:56:08 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Wed, 1 Feb 2017 18:56:08 -0200 Subject: Creating system users and system groups Message-ID: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> Hi, I want to snap CUPS and for that also to snap avahi-daemon. A problem I am running into is that these services use special system users and groups. avahi-daemon uses the user "avahi" and CUPS uses the user "lp", and the groups "lp" and "lpadmin". How can I make my snap create such users and groups on install and remove them on uninstall? Till From joe.talbott at canonical.com Wed Feb 1 21:19:19 2017 From: joe.talbott at canonical.com (Joe Talbott) Date: Wed, 1 Feb 2017 16:19:19 -0500 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: I think you'll want something along the lines of: parts: mylib-x: ... mylib-y: ... after: [mylib-x] This will include both mylib-x and mylib-y in your snap and ensure that mylib-x is built before mylib-y is. Joe On Wed, Feb 1, 2017 at 10:01 AM, Luca Dionisi wrote: > On Wed, Feb 1, 2017 at 1:29 PM, Gustavo Niemeyer wrote: >> Yeah, besides "build-packages" there's also "stage-packages" which does >> exactly that. > > I think you misunderstood. "build-packages" puts a deb package in the > build host, "stage-packages" puts a deb package in stage. > But I don't have a deb package of mylib-y. > I want snapcraft to build both mylib-y and mylib-x, where mylib-x > depends on mylib-y being installed. > What I want is snapcraft to put the "install" pieces of the part > "mylib-y" in the build host too (other than in stage). > Is that doable? > Or... wait, are you telling me that I can put the name of another > "part" in "build-packages" instead of the name of a deb? > > >> On Wed, Feb 1, 2017 at 8:34 AM, Luca Dionisi wrote: >>> >>> This is another solution that I thought of. >>> I want to put the library mylib-y (the one that is needed by mylib-x) >>> both in the ./stage tree and in the /usr/ prefix of the host system >>> where I prepare the snap. >>> Is there a way to tell snapcraft to do so? >>> It should be similar to the way one can use 'build-packages' to >>> install deb packages on the build host. >>> >>> --Luca > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From luca.dionisi at gmail.com Wed Feb 1 22:29:07 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Wed, 1 Feb 2017 23:29:07 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: I am already doing "after: [mylib-x]". Snapcraft builds correctly mylib-x and stages it. Then snacraft tries to build mylib-y with the valac compiler. The compiler valac looks by default in /usr/share/vala/vapi for a vapi file that is produced by mylib-x. The problem is that that file now is in .../stage/usr/share/vala/vapi. The makefile should add a "--vapidir" flag to the compiler. This was not needed before because I was always installing mylib-x in the host. Now I want to create a snap and I am struggling with this issue. I realize that I don't know how to tell to autotools (in Makefile.am) that it has to add this flag when the package is being built with snapcraft. Maybe I should check DESTDIR, because I see [here https://snapcraft.io/docs/reference/plugins/autotools] that the autotools plugin of snapcraft uses DESTDIR by default as a mean to redirect installation. But I am afraid that this thing could be a ugly workaround, not very manageable. What do you think? On Wed, Feb 1, 2017 at 10:19 PM, Joe Talbott wrote: > I think you'll want something along the lines of: > > parts: > mylib-x: > ... > mylib-y: > ... > after: [mylib-x] > > This will include both mylib-x and mylib-y in your snap and ensure > that mylib-x is built before mylib-y is. > > Joe > > On Wed, Feb 1, 2017 at 10:01 AM, Luca Dionisi wrote: >> On Wed, Feb 1, 2017 at 1:29 PM, Gustavo Niemeyer wrote: >>> Yeah, besides "build-packages" there's also "stage-packages" which does >>> exactly that. >> >> I think you misunderstood. "build-packages" puts a deb package in the >> build host, "stage-packages" puts a deb package in stage. >> But I don't have a deb package of mylib-y. >> I want snapcraft to build both mylib-y and mylib-x, where mylib-x >> depends on mylib-y being installed. >> What I want is snapcraft to put the "install" pieces of the part >> "mylib-y" in the build host too (other than in stage). >> Is that doable? >> Or... wait, are you telling me that I can put the name of another >> "part" in "build-packages" instead of the name of a deb? >> >> >>> On Wed, Feb 1, 2017 at 8:34 AM, Luca Dionisi wrote: >>>> >>>> This is another solution that I thought of. >>>> I want to put the library mylib-y (the one that is needed by mylib-x) >>>> both in the ./stage tree and in the /usr/ prefix of the host system >>>> where I prepare the snap. >>>> Is there a way to tell snapcraft to do so? >>>> It should be similar to the way one can use 'build-packages' to >>>> install deb packages on the build host. >>>> >>>> --Luca >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From joseph.wakeling at webdrake.net Wed Feb 1 22:47:26 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 1 Feb 2017 23:47:26 +0100 Subject: Using docker for clean builds of classic snaps Message-ID: Hello all, Curious question. Since snapcraft cleanbuild support is still a work-in-progress for classic snaps, has anyone tried using Docker to provide a clean build environment for them? If so -- can you advise on what you did? I'm not super Docker-experienced, so while I imagine setting up the basic environment wouldn't be too difficult -- I don't imagine the dockerfile would need much more than FROM ubuntu:16.04 and the installation of snapcraft -- I'm not sure how to run the actual snapcraft command via Docker. Can anyone suggest how to do this? No worries if no one can advise -- if not, assuming cleanbuild support isn't close in the pipeline, I will try to look into this further myself in the next weeks. Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Wed Feb 1 23:51:59 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 2 Feb 2017 00:51:59 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: References: Message-ID: On 31/01/17 14:01, Jamie Bennett wrote: > Hi, > > The team are pleased to announce that, after extensive testing in proposed, snapd is officially available in the Trusty Tahr updates archive [1]. If you are running a 14.04 system we encourage you to give it a try and report any issues [2]. Thanks to all involved in making this happen. > > Regards, > Jamie. > > [1] https://launchpad.net/ubuntu/trusty/+source/snapd > [2] https://bugs.launchpad.net/ubuntu/+source/snapd I tried this earlier today on a Trusty machine and ran into some difficulties installing. `sudo apt install snapd` resulted in the following error message: snapd: Depends: systemd (>= 204-5ubuntu20.20) but it is not going to be installed Attempting to install systemd directly (to work out what was wrong) resulted in something similar: gnome-control-center: Depends: libcheese-gtk23 (>= 3.4.0) but it is not going to be installed libcheese7 (>= 3.0.1) ... ubuntu-control-center: Depends: libcheese-gtk23 (>= 3.4.0) ... libcheese7 (>= 3.0.1) ... Any thoughts on what could be wrong here? From elfgoh at yahoo.com Thu Feb 2 01:35:18 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Thu, 2 Feb 2017 01:35:18 +0000 (UTC) Subject: Using docker for clean builds of classic snaps In-Reply-To: References: Message-ID: <187485051.727071.1485999318208@mail.yahoo.com> I am new to Docker too but these few steps got me going If you are running on armhf, you may try using this https://hub.docker.com/r/elfgoh/armhf-ubuntu-snapcraft/ $ docker run -it -v $(pwd):/usr/me/ spdigital/armhf-ubuntu-snapcraft /bin/bash # Above gets you a shell in your docker container, from which you can run $ snapcraft $ docker ps -a #find container id $ docker rm -- Luther On Thursday, February 2, 2017 6:48 AM, Joseph Rushton Wakeling wrote: Hello all, Curious question. Since snapcraft cleanbuild support is still a work-in-progress for classic snaps, has anyone tried using Docker to provide a clean build environment for them? If so -- can you advise on what you did? I'm not super Docker-experienced, so while I imagine setting up the basic environment wouldn't be too difficult -- I don't imagine the dockerfile would need much more than FROM ubuntu:16.04 and the installation of snapcraft -- I'm not sure how to run the actual snapcraft command via Docker. Can anyone suggest how to do this? No worries if no one can advise -- if not, assuming cleanbuild support isn't close in the pipeline, I will try to look into this further myself in the next weeks. Thanks & best wishes, -- Joe -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From seth.arnold at canonical.com Thu Feb 2 02:49:31 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Wed, 1 Feb 2017 18:49:31 -0800 Subject: snapd available in Trusty Tahr In-Reply-To: References: Message-ID: <20170202024931.GE14909@hunt> On Thu, Feb 02, 2017 at 12:51:59AM +0100, Joseph Rushton Wakeling wrote: > snapd: Depends: systemd (>= 204-5ubuntu20.20) but it is not going to be > installed Not just any systemd will do, make sure you get one with 'deputy' mentioned somewhere in the changelogs: https://bugs.launchpad.net/ubuntu/trusty/+source/systemd/+bug/1656280 Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From stuart.bishop at canonical.com Thu Feb 2 03:16:43 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Thu, 2 Feb 2017 10:16:43 +0700 Subject: Currernt config hook implementation scales very badly In-Reply-To: <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> Message-ID: On 1 February 2017 at 21:48, Michael Hall wrote: > On a related note, does anybody have a suggestion on a lightweight way > of programmatically modifying configs in .ini, XML or JSON? > > I have a couple of use-cases (erlang-based nosql databases) where the > server updates the the local configuration, so I can't just overwrite > the whole thing every time. Didier's example will work for a very basic > key=value config file, but not something more structured, and I'd hate > to introduce Python, Perl or Java just for this. > Really? I thought Python was an excellent choice, and built and staged all my wrappers as a Python part. 'core' already has Python3, so it isn't bloating the snap size. And it makes it a doddle to manipulate json, yaml or ini files, when this sort of thing requires an expert to do correctly in bash or dash. (but look at 'jq' if you insist on shell scripts - it seemed very helpful for dealing with json) -- Stuart Bishop -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.morelli at evidence.eu.com Thu Feb 2 06:55:49 2017 From: b.morelli at evidence.eu.com (Bruno Morelli) Date: Thu, 2 Feb 2017 07:55:49 +0100 Subject: ERROR cannot deliver device serial request: unexpected status 400 Message-ID: I've created kernel and gadget snaps for my new board. I successfully deployed the image created by ubuntu-image into the emmc of my board. I can complete the device configuration (console-conf terminates with the message "Congratulations! This device is now registered to" ...). Logging into my device and typing: snap changes I obtain the following output: ID Status Spawn Ready Summary 1 Done 2017-01-30T09:02:08Z 2017-01-30T09:04:08Z Initialize system state 2 Doing 2017-01-30T09:02:18Z - Initialize device The system change with ID 2 ("Initialize device") seems to be in progress. More in detail with the command: snap change 2 I obtain: Status Spawn Ready Summary Done 2017-01-30T09:02:18Z 2017-01-30T09:04:08Z Generate device key Doing 2017-01-30T09:02:18Z - Request device serial ...................................................................... Request device serial 2017-01-30T09:24:06Z ERROR cannot deliver device serial request: unexpected status 400 2017-01-30T09:25:09Z ERROR cannot deliver device serial request: unexpected status 400 2017-01-30T09:26:12Z ERROR cannot deliver device serial request: unexpected status 400 2017-01-30T09:27:15Z ERROR cannot deliver device serial request: unexpected status 400 [...] Am I missing something in my gadget snap implementation? Is only an Ubuntu server side problem? Regards, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.voss at canonical.com Thu Feb 2 07:38:18 2017 From: thomas.voss at canonical.com (Thomas =?iso-8859-1?B?Vm/f?=) Date: Thu, 2 Feb 2017 08:38:18 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: References: Message-ID: <20170202073818.b2heyissfeo2tulw@x250> On Thu, Feb 02, 2017 at 12:51:59AM +0100, Joseph Rushton Wakeling wrote: > On 31/01/17 14:01, Jamie Bennett wrote: > > Hi, > > > > The team are pleased to announce that, after extensive testing in proposed, snapd is officially available in the Trusty Tahr updates archive [1]. If you are running a 14.04 system we encourage you to give it a try and report any issues [2]. Thanks to all involved in making this happen. > > > > Regards, > > Jamie. > > > > [1] https://launchpad.net/ubuntu/trusty/+source/snapd > > [2] https://bugs.launchpad.net/ubuntu/+source/snapd > > I tried this earlier today on a Trusty machine and ran into some > difficulties installing. `sudo apt install snapd` resulted in the following > error message: > > snapd: Depends: systemd (>= 204-5ubuntu20.20) but it is not going to be > installed > > Attempting to install systemd directly (to work out what was wrong) resulted > in something similar: > > gnome-control-center: Depends: libcheese-gtk23 (>= 3.4.0) but it is not > going to be installed > libcheese7 (>= 3.0.1) ... > > ubuntu-control-center: Depends: libcheese-gtk23 (>= 3.4.0) ... > libcheese7 (>= 3.0.1) ... > > Any thoughts on what could be wrong here? > Yup, you are hit by the issue described in here: http://askubuntu.com/questions/878750/snapd-package-conflicts-with-xorg-packages/878770#878770 In summary, we are waiting for an SRU (see [1]) for the xorg xenial lts stack to arrive in -updates. The short term fix is to enable -proposed. If that does not solve your issue, please report a bug against https://launchpad.net/snapd tagging it with trusty. Thanks for trying out snapd on trusty, Thomas [1] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1619142 > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From simon.fels at canonical.com Thu Feb 2 08:36:09 2017 From: simon.fels at canonical.com (Simon Fels) Date: Thu, 2 Feb 2017 09:36:09 +0100 Subject: Creating system users and system groups In-Reply-To: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> Message-ID: Hey Till, That is (as far as I know) not possible today. Those groups and users have to exist beforehand. A similar problem also exists for LXD. There is a bug at https://bugs.launchpad.net/snappy/+bug/1606510 which has a few more details. regards, Simon On Wed, Feb 1, 2017 at 9:56 PM, Till Kamppeter wrote: > Hi, > > I want to snap CUPS and for that also to snap avahi-daemon. > > A problem I am running into is that these services use special system > users and groups. avahi-daemon uses the user "avahi" and CUPS uses the user > "lp", and the groups "lp" and "lpadmin". > > How can I make my snap create such users and groups on install and remove > them on uninstall? > > Till > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ara.pulido at canonical.com Thu Feb 2 09:01:49 2017 From: ara.pulido at canonical.com (Ara Pulido) Date: Thu, 2 Feb 2017 10:01:49 +0100 Subject: ERROR cannot deliver device serial request: unexpected status 400 In-Reply-To: References: Message-ID: On Thu, Feb 2, 2017 at 7:55 AM, Bruno Morelli wrote: > I've created kernel and gadget snaps for my new board. > I successfully deployed the image created by ubuntu-image into the emmc of > my board. > > I can complete the device configuration (console-conf terminates with the > message "Congratulations! This device is now registered to" ...). > > Logging into my device and typing: > > snap changes > > I obtain the following output: > ID Status Spawn Ready Summary > 1 Done 2017-01-30T09:02:08Z 2017-01-30T09:04:08Z Initialize system > state > 2 Doing 2017-01-30T09:02:18Z - Initialize device > > The system change with ID 2 ("Initialize device") seems to be in progress. > More in detail with the command: > > snap change 2 > > I obtain: > > Status Spawn Ready Summary > Done 2017-01-30T09:02:18Z 2017-01-30T09:04:08Z Generate device key > Doing 2017-01-30T09:02:18Z - Request device serial > ...................................................................... > Request device serial > 2017-01-30T09:24:06Z ERROR cannot deliver device serial request: > unexpected status 400 > 2017-01-30T09:25:09Z ERROR cannot deliver device serial request: > unexpected status 400 > 2017-01-30T09:26:12Z ERROR cannot deliver device serial request: > unexpected status 400 > 2017-01-30T09:27:15Z ERROR cannot deliver device serial request: > unexpected status 400 > [...] > > > Am I missing something in my gadget snap implementation? > Is only an Ubuntu server side problem? > > Your device is trying to get a serial assertion from the Ubuntu servers, but your model is not one of the Ubuntu official ones, so that is not possible. If you want your device to get a proper serial assertion (for example, if you want to create a production ready device), you will need to deploy your own service to issue those signed serial assertions and add a prepare-device hook to your gadget snap. If you are not planning to create a production device, you can safely ignore those errors. But I agree that the error from the store should give more information. Thanks, Ara. [1] https://docs.ubuntu.com/core/en/guides/build-device/config-hooks > Regards, > Bruno > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Thu Feb 2 10:16:57 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Feb 2017 10:16:57 +0000 Subject: Currernt config hook implementation scales very badly In-Reply-To: References: <1485945076.25932.40.camel@ubuntu.com> <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> Message-ID: <4cce3ccd-edb2-0ddb-ac85-47cb89c3d48c@ubuntu.com> On 02/02/17 03:16, Stuart Bishop wrote: > > > On 1 February 2017 at 21:48, Michael Hall > wrote: > > On a related note, does anybody have a suggestion on a lightweight way > of programmatically modifying configs in .ini, XML or JSON? > > I have a couple of use-cases (erlang-based nosql databases) where the > server updates the the local configuration, so I can't just overwrite > the whole thing every time. Didier's example will work for a very > basic > key=value config file, but not something more structured, and I'd hate > to introduce Python, Perl or Java just for this. > > > Really? I thought Python was an excellent choice, and built and staged > all my wrappers as a Python part. 'core' already has Python3, so it > isn't bloating the snap size. And it makes it a doddle to manipulate > json, yaml or ini files, when this sort of thing requires an expert to > do correctly in bash or dash. > > (but look at 'jq' if you insist on shell scripts - it seemed very > helpful for dealing with json) I would strongly +1 python3 from the core snap for general hook authorship. It's always there, it's perfectly fast for one-time operations, it's comfortable for text handling, it's architecture-independent with small files. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Thu Feb 2 10:19:45 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 02 Feb 2017 11:19:45 +0100 Subject: Creating system users and system groups In-Reply-To: References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> Message-ID: <1486030785.25932.54.camel@ubuntu.com> hi, Am Donnerstag, den 02.02.2017, 09:36 +0100 schrieb Simon Fels: > Hey Till, > > That is (as far as I know) not possible today. Those groups and users > have to exist beforehand. A similar problem also exists for LXD. > There is a bug at https://bugs.launchpad.net/snappy/+bug/1606510 > which has a few more details. on a side note this is also not necessary, all your services can run as root thanks to confinement, the user will not matter since other processes can only access your services through interfaces that shield them. running as root is fine here ...  (that doesnt mean that we wont ever add such a feature (especially for lxd who needs it for HW interaction outside of the snap, but this is a very special case), but for non lxd snaps this is really not needed since the user would be useless anyway) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Thu Feb 2 10:23:43 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 02 Feb 2017 11:23:43 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: <4cce3ccd-edb2-0ddb-ac85-47cb89c3d48c@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> <4cce3ccd-edb2-0ddb-ac85-47cb89c3d48c@ubuntu.com> Message-ID: <1486031023.25932.58.camel@ubuntu.com> hi, Am Donnerstag, den 02.02.2017, 10:16 +0000 schrieb Mark Shuttleworth: >  > > Really? I thought Python was an excellent choice, and built and > > staged all my wrappers as a Python part. 'core' already has > > Python3, so it isn't bloating the snap size. And it makes it a > > doddle to manipulate json, yaml or ini files, when this sort of > > thing requires an expert to do correctly in bash or dash. > > > > (but look at 'jq' if you insist on shell scripts - it seemed very > > helpful for dealing with json) >   > I would strongly +1 python3 from the core snap for general hook > authorship. It's always there, it's perfectly fast for one-time > operations, it's comfortable for text handling, it's architecture- > independent with small files. > just as a side note, this works for all basic python stuff (wrappers/config etc), but not if you use any complex modules.  in that case you should indeed ship python in your snap using a python plugin in snapcraft.yaml and include the necessary modules in your snap. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Thu Feb 2 10:27:19 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 02 Feb 2017 11:27:19 +0100 Subject: ERROR cannot deliver device serial request: unexpected status 400 In-Reply-To: References: Message-ID: <1486031239.25932.61.camel@ubuntu.com> hi, Am Donnerstag, den 02.02.2017, 10:01 +0100 schrieb Ara Pulido: >  > Your device is trying to get a serial assertion from the Ubuntu > servers, but your model is not one of the Ubuntu official ones, so > that is not possible. AFAIK it is possible if both, gadget and kernel snaps are in the store and signed by the same key that was used by the model assertion (i.e. owned by the same user). at least that is my experience with the beaglebone black image that i produce. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From mark at ubuntu.com Thu Feb 2 10:32:42 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Feb 2017 10:32:42 +0000 Subject: ERROR cannot deliver device serial request: unexpected status 400 In-Reply-To: <1486031239.25932.61.camel@ubuntu.com> References: <1486031239.25932.61.camel@ubuntu.com> Message-ID: <67d00797-1eb5-a904-7eda-ee73f54d2940@ubuntu.com> On 02/02/17 10:27, Oliver Grawert wrote: > hi, > Am Donnerstag, den 02.02.2017, 10:01 +0100 schrieb Ara Pulido: >> >> Your device is trying to get a serial assertion from the Ubuntu >> servers, but your model is not one of the Ubuntu official ones, so >> that is not possible. > AFAIK it is possible if both, gadget and kernel snaps are in the store > and signed by the same key that was used by the model assertion (i.e. > owned by the same user). at least that is my experience with the > beaglebone black image that i produce. Am not sure what's causing the specific issue you see, but Ogra is describing the expected behaviour, which is that you can push a kernel and gadget snap and then your own model assertion which binds those together and is the basis for the image builder. We are working with the hardware companies to ensure that building a kernel snap is trivial for their hardware. Certified board will have official kernel snaps that anybody can "just use". Of course, if you want to modify the kernel for an official board you can also just build your own kernel snap. I know there is some work outstanding to get all of those pieces working. There are some tricky corner cases (for example, what if you want to change kernel snap entirely by issuing a new revision of your model-assertion?) but it shouldn't be long before everything is in place to enable all of that for straightforward cases. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From mark at ubuntu.com Thu Feb 2 10:49:13 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Feb 2017 10:49:13 +0000 Subject: Creating system users and system groups In-Reply-To: References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> Message-ID: <375d4d08-49e4-03e3-2f3e-1d85be06435f@ubuntu.com> Our general thinking is that we will maintain a standard list of those, and approve user creation for specific snaps. Would you be willing to go with _avahi and _lp and _lpadmin? Backward-looking names might get grandfathered, but we'd prefer newer software to use a qualifier like _ to disambiguate such system users from end users. Mark On 02/02/17 08:36, Simon Fels wrote: > Hey Till, > > That is (as far as I know) not possible today. Those groups and users > have to exist beforehand. A similar problem also exists for LXD. There > is a bug at https://bugs.launchpad.net/snappy/+bug/1606510 which has a > few more details. > > regards, > Simon > > On Wed, Feb 1, 2017 at 9:56 PM, Till Kamppeter > > wrote: > > Hi, > > I want to snap CUPS and for that also to snap avahi-daemon. > > A problem I am running into is that these services use special > system users and groups. avahi-daemon uses the user "avahi" and > CUPS uses the user "lp", and the groups "lp" and "lpadmin". > > How can I make my snap create such users and groups on install and > remove them on uninstall? > > Till > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Thu Feb 2 11:01:17 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Feb 2017 11:01:17 +0000 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1486031023.25932.58.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <90501494-1ae7-d04b-3a60-581c3bb4d783@ubuntu.com> <4cce3ccd-edb2-0ddb-ac85-47cb89c3d48c@ubuntu.com> <1486031023.25932.58.camel@ubuntu.com> Message-ID: <08e23be1-a829-320b-3d31-44eb4720743c@ubuntu.com> On 02/02/17 10:23, Oliver Grawert wrote: > just as a side note, this works for all basic python stuff > (wrappers/config etc), but not if you use any complex modules. > in that case you should indeed ship python in your snap using a python > plugin in snapcraft.yaml and include the necessary modules in your > snap. Yes, my primary point was that if we are going to offer some standard helper modules, I would suggest those be in Python3 using only the pieces available in the core which is always available. That way, with minimal overhead, config capabilities can be improving constantly for all snapcrafters. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From jenny.murphy at episensor.com Thu Feb 2 12:40:06 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 2 Feb 2017 12:40:06 +0000 Subject: Use of ppp interface in Strict Mode Message-ID: Hi, I am seeking advice regarding the use pf the ppp interface a provided by core Version 16.04.1 (Rev 888). If I connect my snap using the ppp interface, what does this give me permission to do? Can I invoke a ppp daemon from inside my snap? Do I have write access to an area for config files. If there are any examples, I would appreciate it. Jenny -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Thu Feb 2 12:53:33 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Thu, 2 Feb 2017 15:53:33 +0300 Subject: my qt app hello-world Message-ID: Please, help me. I have qt-app HelloWorld. I create HelloWorld in QtCreator. /sp/qt1/ $ tree qtprogram1 qtprogram1 ├── qt1 │ ├── main.cpp │ ├── mainwindow.cpp │ ├── mainwindow.h │ ├── mainwindow.ui │ ├── qt1.pro │ └── qt1.pro.user └── qt1-build-desktop ├── Makefile ├── moc_mainwindow.cpp └── ui_mainwindow.h 2 directories, 9 files ----------------------------------- snapcraft.yaml contain name: qt1 version: "1" summary: My first Qt app description: Qt Hello World confinement: strict architectures: [amd64] apps: qt1: command: desktop-launch $SNAP/opt/myapp/qt1 plugs: [home, unity7, x11] parts: project-files: plugin: qmake source: . qt-version: qt5 project-files: [qtprogram1/qt1/qt1.pro] after: [integration] integration: plugin: nil stage-packages: - libc6 - libstdc++6 - libc-bin after: [desktop-qt5] --------------------------- After "snapcraft" I find only one binary file qt1 /sp/qt1# find . -name "qt1" -type f ./parts/project-files/build/qt1 How to locate qt1 in opt/myapp/qt1 (for example)? -- Best regards, vasilisc From sergio.schvezov at canonical.com Thu Feb 2 13:07:56 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 2 Feb 2017 13:07:56 +0000 Subject: my qt app hello-world In-Reply-To: References: Message-ID: On Thu, 2 Feb 2017 15:53:33 +0300, Vasilisc wrote: > Please, help me. I have qt-app HelloWorld. I create HelloWorld in QtCreator. > > /sp/qt1/ $ tree qtprogram1 > qtprogram1 > ├── qt1 > │ ├── main.cpp > │ ├── mainwindow.cpp > │ ├── mainwindow.h > │ ├── mainwindow.ui > │ ├── qt1.pro > │ └── qt1.pro.user > └── qt1-build-desktop > ├── Makefile > ├── moc_mainwindow.cpp > └── ui_mainwindow.h > > 2 directories, 9 files > ----------------------------------- > > snapcraft.yaml contain > > name: qt1 > version: "1" > summary: My first Qt app > description: Qt Hello World > confinement: strict > architectures: [amd64] > > apps: > qt1: > command: desktop-launch $SNAP/opt/myapp/qt1 > plugs: [home, unity7, x11] > > parts: > project-files: > plugin: qmake > source: . > qt-version: qt5 > project-files: [qtprogram1/qt1/qt1.pro] > after: [integration] > > integration: > plugin: nil > stage-packages: > - libc6 > - libstdc++6 > - libc-bin > after: [desktop-qt5] > --------------------------- > > After "snapcraft" I find only one binary file qt1 > > /sp/qt1# find . -name "qt1" -type f > ./parts/project-files/build/qt1 > > How to locate qt1 in opt/myapp/qt1 (for example)? The best approach is to make qtprogram1/qt1/qt1.pro do that. If you want snapcraft to do this you can use `organize` such that... parts: project-files: plugin: qmake source: . qt-version: qt5 project-files: [qtprogram1/qt1/qt1.pro] organize: qt1: opt/myapp/qt1 after: [integration] But give our result in `find` you have no install rule at all so instead would need to do something like: parts: project-files: plugin: qmake source: . qt-version: qt5 project-files: [qtprogram1/qt1/qt1.pro] install: | install -d $SNAPCRAFT_PART_INSTALL/opt/myapp install qt1 $SNAPCRAFT_PART_INSTALL/opt/myapp/qt1 after: [integration] More about this here https://snapcraft.io/docs/build-snaps/scriptlets -- Sent using Dekko from my Ubuntu device From simos.lists at googlemail.com Thu Feb 2 13:11:50 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Thu, 2 Feb 2017 15:11:50 +0200 Subject: Testing a snap for lnav (log file navigator), publishing Message-ID: Hi All, I created a snap for lnav and I attach the snapcraft.yaml file. I plan to use the "classic" confinement in the final version. Would that be advisable or should I change to permit only to open log files from /var/log/? According to the documentation, I am asking here for comments (so as to appear later in the stable channel). Simos -------------- next part -------------- A non-text attachment was scrubbed... Name: snapcraft.yaml Type: application/x-yaml Size: 776 bytes Desc: not available URL: From mark at ubuntu.com Thu Feb 2 13:14:16 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Feb 2017 13:14:16 +0000 Subject: Testing a snap for lnav (log file navigator), publishing In-Reply-To: References: Message-ID: <3a1cf4fe-7a28-2030-f8c4-a84ef7c9ac05@ubuntu.com> In general, strict confinement is better. In this case, if you are confident that the logs which matter will be in /var/log, then yes it would be better to have strict confinement with an interface that allows reading from that location. Mark On 02/02/17 13:11, Simos Xenitellis wrote: > Hi All, > > I created a snap for lnav and I attach the snapcraft.yaml file. > > I plan to use the "classic" confinement in the final version. > Would that be advisable or should I change to permit only to open log > files from /var/log/? > > According to the documentation, I am asking here for comments (so as > to appear later in the stable channel). > > Simos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Thu Feb 2 13:16:21 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Thu, 2 Feb 2017 16:16:21 +0300 Subject: my qt app hello-world In-Reply-To: References: Message-ID: <1fe44a2f-a981-146c-03a4-a51251eca217@gmail.com> 02.02.2017 16:07, Sergio Schvezov пишет: > On Thu, 2 Feb 2017 15:53:33 +0300, Vasilisc wrote: >> Please, help me. I have qt-app HelloWorld. I create HelloWorld in QtCreator. >> >> /sp/qt1/ $ tree qtprogram1 >> qtprogram1 >> ├── qt1 >> │ ├── main.cpp >> │ ├── mainwindow.cpp >> │ ├── mainwindow.h >> │ ├── mainwindow.ui >> │ ├── qt1.pro >> │ └── qt1.pro.user >> └── qt1-build-desktop >> ├── Makefile >> ├── moc_mainwindow.cpp >> └── ui_mainwindow.h >> >> 2 directories, 9 files >> ----------------------------------- >> >> snapcraft.yaml contain >> >> name: qt1 >> version: "1" >> summary: My first Qt app >> description: Qt Hello World >> confinement: strict >> architectures: [amd64] >> >> apps: >> qt1: >> command: desktop-launch $SNAP/opt/myapp/qt1 >> plugs: [home, unity7, x11] >> >> parts: >> project-files: >> plugin: qmake >> source: . >> qt-version: qt5 >> project-files: [qtprogram1/qt1/qt1.pro] >> after: [integration] >> >> integration: >> plugin: nil >> stage-packages: >> - libc6 >> - libstdc++6 >> - libc-bin >> after: [desktop-qt5] >> --------------------------- >> >> After "snapcraft" I find only one binary file qt1 >> >> /sp/qt1# find . -name "qt1" -type f >> ./parts/project-files/build/qt1 >> >> How to locate qt1 in opt/myapp/qt1 (for example)? > > The best approach is to make qtprogram1/qt1/qt1.pro do that. If you want snapcraft to do this you can use `organize` such that... > > parts: > project-files: > plugin: qmake > source: . > qt-version: qt5 > project-files: [qtprogram1/qt1/qt1.pro] > organize: > qt1: opt/myapp/qt1 > after: [integration] > > But give our result in `find` you have no install rule at all so instead would need to do something like: > > parts: > project-files: > plugin: qmake > source: . > qt-version: qt5 > project-files: [qtprogram1/qt1/qt1.pro] > install: | > install -d $SNAPCRAFT_PART_INSTALL/opt/myapp > install qt1 $SNAPCRAFT_PART_INSTALL/opt/myapp/qt1 > after: [integration] > > More about this here https://snapcraft.io/docs/build-snaps/scriptlets > Sergio, thank you very much!!!!! It's work! =) thx thx thx -- Best regards, vasilisc From ogra at ubuntu.com Thu Feb 2 13:25:08 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 02 Feb 2017 14:25:08 +0100 Subject: Testing a snap for lnav (log file navigator), publishing In-Reply-To: References: Message-ID: <1486041908.25932.81.camel@ubuntu.com> hi, Am Donnerstag, den 02.02.2017, 15:11 +0200 schrieb Simos Xenitellis: > Hi All, > > I created a snap for lnav and I attach the snapcraft.yaml file. > > I plan to use the "classic" confinement in the final version. > Would that be advisable or should I change to permit only to open log > files from /var/log/? > > According to the documentation, I am asking here for comments (so as > to appear later in the  stable channel). > there is a log-observe interface that should give you access, so you should be able to use strict confinement and this interface. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jamie.bennett at canonical.com Thu Feb 2 13:40:11 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Thu, 2 Feb 2017 13:40:11 +0000 Subject: Using docker for clean builds of classic snaps In-Reply-To: References: Message-ID: Hi Joe, We have this page that explains how to build using Docker containers (the url name is wrong but the contents are right). * https://snapcraft.io/docs/build-snaps/trusty Regards, Jamie. > On 1 Feb 2017, at 22:47, Joseph Rushton Wakeling wrote: > > Hello all, > > Curious question. Since snapcraft cleanbuild support is still a work-in-progress for classic snaps, has anyone tried using Docker to provide a clean build environment for them? If so -- can you advise on what you did? > > I'm not super Docker-experienced, so while I imagine setting up the basic environment wouldn't be too difficult -- I don't imagine the dockerfile would need much more than FROM ubuntu:16.04 and the installation of snapcraft -- I'm not sure how to run the actual snapcraft command via Docker. Can anyone suggest how to do this? > > No worries if no one can advise -- if not, assuming cleanbuild support isn't close in the pipeline, I will try to look into this further myself in the next weeks. > > Thanks & best wishes, > > -- Joe > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From gustavo at niemeyer.net Thu Feb 2 13:50:09 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Thu, 2 Feb 2017 11:50:09 -0200 Subject: daemon ordering In-Reply-To: References: Message-ID: Is there any particular missing feature you're blocked on today? Can you please provide a bit more detail about that particular case? We'd be happy to work through that with you and make sure you're not blocked. On Wed, Feb 1, 2017 at 6:29 PM, Howard Cochran < howard at badger-technologies.com> wrote: > On Wed, Feb 1, 2017 at 2:02 PM, Gustavo Niemeyer > wrote: > > > > Such embedded devices are still computers on the network. We'll all be > much > > better off if they are running their applications confined and secured. > > > > That said, we understand that it takes some time and effort until most > > software is properly confined, which is why we support snaps with classic > > and devmode confinement. > > > > Even there, though, we're keen to ensure that the general model supports > a > > comfortable migration towards proper confinement, as that's where we'll > all > > want to be in the end, so we shouldn't just go loose and implement > features > > that we know will break confinement unnecessarily. > > Those are all very good points, and I agree with them. It appears, to > me, though, that systemd has many features that can enhance > confinement and/or tailor it in very targeted ways. It would be nice > to be able to leverage those features. And many of its directives > don't break confinement (especially some very common ones like > Condition* and ExecStartPre/Post, Before, After, PartOf, Wants, > Conflicts, RuntimeDirectory, and others. Perhaps snapcraft could have > a whitelist of allowed directives when confinement mode is strict? > > Thanks, > Howard > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From till.kamppeter at gmail.com Thu Feb 2 14:05:06 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Thu, 2 Feb 2017 12:05:06 -0200 Subject: Creating system users and system groups In-Reply-To: References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> Message-ID: On 02/02/2017 06:36 AM, Simon Fels wrote: > Hey Till, > > That is (as far as I know) not possible today. Those groups and users > have to exist beforehand. A similar problem also exists for LXD. There > is a bug at https://bugs.launchpad.net/snappy/+bug/1606510 which has a > few more details. > OK, I have added my user/group wishes to that bug report now. Till ---------- Comment to the bug report: I also would need some system users/groups in Ubuntu Core: User "avahi" and group "avahi" for an avahi-daemon snap (needed for CUPS and cups-browsed) Group "lpadmin" for CUPS snap (Group "lp" and user "lp" are already there) From till.kamppeter at gmail.com Thu Feb 2 14:18:24 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Thu, 2 Feb 2017 12:18:24 -0200 Subject: Creating system users and system groups In-Reply-To: <1486030785.25932.54.camel@ubuntu.com> References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> <1486030785.25932.54.camel@ubuntu.com> Message-ID: <9cda9625-f5c7-2175-ba61-33b48a096c9b@gmail.com> On 02/02/2017 08:19 AM, Oliver Grawert wrote: > on a side note this is also not necessary, all your services can run as > root thanks to confinement, the user will not matter since other > processes can only access your services through interfaces that shield > them. running as root is fine here ... > Did not kow about that. Interesting to know. Needs to be added to the docs. The addition of "lpadmin" in CUPS serves for making users print queue admins, as members of this group can add, modify, and delete print queues. CUPS builds and runs without this group, making queue administration root-only, but how will print queue administration work then? How do I control who can do it and who not. In DEB-based Ubuntu the first (and any admin) user is in the "lpadmin" group and using the command line utilities of CUPS or printer setup tools like system-config-printer he can add/modify/delete print queues and also modify /etc/cups/cupsd.conf (but not /etc/cups/cups-files.conf) without needing to enter a password. avahi-daemon runs as the user "avahi" in the DEB package. By simple ./configure option manipulation (like setting system user to "root") I did not yet get it to build without erroring out on missing "avahi" user/group. Will check again, but perhaps here a system user/group is needed. Perhaps one can hi-jack an existing one. Till From till.kamppeter at gmail.com Thu Feb 2 14:22:57 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Thu, 2 Feb 2017 12:22:57 -0200 Subject: Creating system users and system groups In-Reply-To: <375d4d08-49e4-03e3-2f3e-1d85be06435f@ubuntu.com> References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> <375d4d08-49e4-03e3-2f3e-1d85be06435f@ubuntu.com> Message-ID: On 02/02/2017 08:49 AM, Mark Shuttleworth wrote: > > Our general thinking is that we will maintain a standard list of those, > and approve user creation for specific snaps. Would you be willing to go > with _avahi and _lp and _lpadmin? Backward-looking names might get > grandfathered, but we'd prefer newer software to use a qualifier like _ > to disambiguate such system users from end users. > > Mark I think that avahi-daemon and CUPS are well-established operating system components, so that we can add the user "avahi" and the groups "avahi" and "lpadmin" to the standard range of Ubuntu Core. Group and user "lp" are already in the standard range. Till From cjwatson at ubuntu.com Thu Feb 2 14:52:23 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Thu, 2 Feb 2017 14:52:23 +0000 Subject: Creating system users and system groups In-Reply-To: <375d4d08-49e4-03e3-2f3e-1d85be06435f@ubuntu.com> References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> <375d4d08-49e4-03e3-2f3e-1d85be06435f@ubuntu.com> Message-ID: <20170202145223.GA4135@riva.ucam.org> On Thu, Feb 02, 2017 at 10:49:13AM +0000, Mark Shuttleworth wrote: > Our general thinking is that we will maintain a standard list of those, > and approve user creation for specific snaps. Would you be willing to go > with _avahi and _lp and _lpadmin? Backward-looking names might get > grandfathered, but we'd prefer newer software to use a qualifier like _ > to disambiguate such system users from end users. You might like to use https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames as part of this; d-i and ubiquity both use that as a way of saying "you can't use that username because it'll conflict with well-known system users". It doubtless won't be complete (it doesn't currently contain avahi, for instance), but it should be a useful starting point. -- Colin Watson [cjwatson at ubuntu.com] From mark at ubuntu.com Thu Feb 2 15:01:33 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Feb 2017 15:01:33 +0000 Subject: Creating system users and system groups In-Reply-To: <20170202145223.GA4135@riva.ucam.org> References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> <375d4d08-49e4-03e3-2f3e-1d85be06435f@ubuntu.com> <20170202145223.GA4135@riva.ucam.org> Message-ID: On 02/02/17 14:52, Colin Watson wrote: > You might like to use > https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames > as part of this; d-i and ubiquity both use that as a way of saying "you > can't use that username because it'll conflict with well-known system > users". It doubtless won't be complete (it doesn't currently contain > avahi, for instance), but it should be a useful starting point. > Let's definitely use that as a definitive reference, thanks Colin. I think we may want to go further and assign specific UIDs, too. Mark From ogra at ubuntu.com Thu Feb 2 15:12:45 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 02 Feb 2017 16:12:45 +0100 Subject: Creating system users and system groups In-Reply-To: References: <8023f5b1-3d5d-c6bf-891d-931924ea4927@gmail.com> <375d4d08-49e4-03e3-2f3e-1d85be06435f@ubuntu.com> <20170202145223.GA4135@riva.ucam.org> Message-ID: <1486048365.25932.109.camel@ubuntu.com> hi, Am Donnerstag, den 02.02.2017, 15:01 +0000 schrieb Mark Shuttleworth: > On 02/02/17 14:52, Colin Watson wrote: > > > > You might like to use > > https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-us > > ernames > > as part of this; d-i and ubiquity both use that as a way of saying > > "you > > can't use that username because it'll conflict with well-known > > system > > users".  It doubtless won't be complete (it doesn't currently > > contain > > avahi, for instance), but it should be a useful starting point. > > > Let's definitely use that as a definitive reference, thanks Colin. > > I think we may want to go further and assign specific UIDs, too. > please note that our setup is also particulary special due to the mix of readonly and readwrite parts of the core images and the fact that the core snap is used as rootfs there. we require a readonly password database with fixed UID/GID numbers that can never change (else you run into filesystem permission issues) if we use a generic mechanism to allow snaps to add users and groups in classic installs this design will have to be different for snaps used on core images where we can only use the writable extrausers db to add anything and can not use already taken IDs that are hardcoded in the readonly password db.  so an implementation that allows adding system users will have to be done twice in two different ways for both of these use cases. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From luca.dionisi at gmail.com Thu Feb 2 15:22:52 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Thu, 2 Feb 2017 16:22:52 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: Maybe I found my error. It is in (lack of) usage of data from pkg-config files. Thus it is not strictly related to snapcraft. When mylib-x is built (and staged) by snapcraft the corresponding mylib-x.pc file is saved in [...]/stage/[...]/pkgconfig and it states that "prefix" variable is [...]/stage/usr. When building mylib-y, which depends on mylib-x, the configure part read this pc file. Now, the makefile should use this "prefix" variable and add this line to the valac command: --vapidir=$prefix/share/vala/vapi Since usually I install with prefix=/usr and the directory /usr/share/vala/vapi is searched by default by valac, the lack of this line was not a problem until now. I need some trial and error test now. I'll keep you posted on progress. On Wed, Feb 1, 2017 at 11:29 PM, Luca Dionisi wrote: > I am already doing "after: [mylib-x]". > Snapcraft builds correctly mylib-x and stages it. > Then snacraft tries to build mylib-y with the valac compiler. > The compiler valac looks by default in /usr/share/vala/vapi for a vapi > file that is produced by mylib-x. > The problem is that that file now is in .../stage/usr/share/vala/vapi. > The makefile should add a "--vapidir" flag to the compiler. This was > not needed before because I was always installing mylib-x in the host. > Now I want to create a snap and I am struggling with this issue. > I realize that I don't know how to tell to autotools (in Makefile.am) > that it has to add this flag when the package is being built with > snapcraft. > Maybe I should check DESTDIR, because I see [here > https://snapcraft.io/docs/reference/plugins/autotools] that the > autotools plugin of snapcraft uses DESTDIR by default as a mean to > redirect installation. > > But I am afraid that this thing could be a ugly workaround, not very > manageable. What do you think? > > On Wed, Feb 1, 2017 at 10:19 PM, Joe Talbott wrote: >> I think you'll want something along the lines of: >> >> parts: >> mylib-x: >> ... >> mylib-y: >> ... >> after: [mylib-x] >> >> This will include both mylib-x and mylib-y in your snap and ensure >> that mylib-x is built before mylib-y is. >> >> Joe >> >> On Wed, Feb 1, 2017 at 10:01 AM, Luca Dionisi wrote: >>> On Wed, Feb 1, 2017 at 1:29 PM, Gustavo Niemeyer wrote: >>>> Yeah, besides "build-packages" there's also "stage-packages" which does >>>> exactly that. >>> >>> I think you misunderstood. "build-packages" puts a deb package in the >>> build host, "stage-packages" puts a deb package in stage. >>> But I don't have a deb package of mylib-y. >>> I want snapcraft to build both mylib-y and mylib-x, where mylib-x >>> depends on mylib-y being installed. >>> What I want is snapcraft to put the "install" pieces of the part >>> "mylib-y" in the build host too (other than in stage). >>> Is that doable? >>> Or... wait, are you telling me that I can put the name of another >>> "part" in "build-packages" instead of the name of a deb? >>> >>> >>>> On Wed, Feb 1, 2017 at 8:34 AM, Luca Dionisi wrote: >>>>> >>>>> This is another solution that I thought of. >>>>> I want to put the library mylib-y (the one that is needed by mylib-x) >>>>> both in the ./stage tree and in the /usr/ prefix of the host system >>>>> where I prepare the snap. >>>>> Is there a way to tell snapcraft to do so? >>>>> It should be similar to the way one can use 'build-packages' to >>>>> install deb packages on the build host. >>>>> >>>>> --Luca >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From sergio.schvezov at canonical.com Thu Feb 2 15:55:18 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 2 Feb 2017 15:55:18 +0000 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: On Thu, 2 Feb 2017 16:22:52 +0100, Luca Dionisi wrote: > Maybe I found my error. It is in (lack of) usage of data from > pkg-config files. Thus it is not strictly related to snapcraft. > When mylib-x is built (and staged) by snapcraft the corresponding > mylib-x.pc file is saved in [...]/stage/[...]/pkgconfig and it states > that "prefix" variable is [...]/stage/usr. > When building mylib-y, which depends on mylib-x, the configure part > read this pc file. Now, the makefile should use this "prefix" variable > and add this line to the valac command: > --vapidir=$prefix/share/vala/vapi > Since usually I install with prefix=/usr and the directory > /usr/share/vala/vapi is searched by default by valac, the lack of this > line was not a problem until now. Does your configure have something like ./configure --with-extra-vapi-dir ? If so, try doing parts: my-part: source: ... plugin: autotools configflags: - --with-extra-vapi-dir=$SNAPCRAFT_STAGE/usr/share/vala/vapi -- Sent using Dekko from my Ubuntu device From leo.arias at canonical.com Thu Feb 2 16:50:08 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 2 Feb 2017 10:50:08 -0600 Subject: Ubuntu Core testing days, and 96boards crossover Message-ID: Hello! We are happy to resume our Ubuntu testing days, and for February and March our focus will be Ubuntu Core. The first one is tomorrow, Friday 3rd, at 16:00 UTC: http://ubuntuonair.com/ Michael Vogt and Federico Giménez from the snappy team will join us to talk about Ubuntu Core and the test images for QEMU. And we have good news from our friends working on 96boards at Linaro. They have a nice show every Thursday with Robert Wolff, called open hours. Check it out: http://www.96boards.org/OpenHours/ We will have some shared sessions with them in which we'll be talking about dragonboard 410c, snaps, snapcraft, and more. It will be great, like when Alf appeared in Blossom [1] :D I'll be sending here the details and reminders as the dates approach. For more information about the testing days: https://wiki.ubuntu.com/Testing/UbuntuTestingDay pura vida [1] https://metrouk2.files.wordpress.com/2015/04/blossomalf.png?w=524&h=370 -- ¡paz y baile! http://www.ubuntu.com From simos.lists at googlemail.com Thu Feb 2 17:00:35 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Thu, 2 Feb 2017 19:00:35 +0200 Subject: Testing a snap for lnav (log file navigator), publishing In-Reply-To: <1486041908.25932.81.camel@ubuntu.com> References: <1486041908.25932.81.camel@ubuntu.com> Message-ID: On Thu, Feb 2, 2017 at 3:25 PM, Oliver Grawert wrote: > hi, > Am Donnerstag, den 02.02.2017, 15:11 +0200 schrieb Simos Xenitellis: >> Hi All, >> >> I created a snap for lnav and I attach the snapcraft.yaml file. >> >> I plan to use the "classic" confinement in the final version. >> Would that be advisable or should I change to permit only to open log >> files from /var/log/? >> >> According to the documentation, I am asking here for comments (so as >> to appear later in the stable channel). >> > there is a log-observe interface that should give you access, so you > should be able to use strict confinement and this interface. > Thanks both for the replies. Here is my attempt to confine "lnav" into the "strict" confinement (attached file). I added the interface "log-observe". Once the snap has been installed, it is required to run once the following command: sudo snap connect lnav:log-observe core:log-observe Then, "lnav" works just fine. In addition, I added the interface "network". This is due to to lnav opening a UNIX domain socket, and using the "sendto()" system call. The logs were: = Seccomp = Time: Feb 2 15:31:51 Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=15616 comm="lnav" exe="/snap/lnav/x1/bin/lnav" sig=31 arch=c000003e 44(sendto) compat=0 ip=0x7f6d8a5d699d code=0x0 Syscall: sendto Suggestion: * add one of 'avahi-observe, cups-control, firewall-control, gsettings, libvirt, modem-manager, mpris, network, network-bind, network-control, network-manager, ofono, openvswitch, pulseaudio, screen-inhibit-control, shutdown, system-observe, time-control, timeserver-control, timezone-control, unity7, upower-observe' to 'plugs' On Thu, Feb 2, 2017 at 3:14 PM, Mark Shuttleworth wrote: > > In general, strict confinement is better. In this case, if you are confident > that the logs which matter will be in /var/log, then yes it would be better > to have strict confinement with an interface that allows reading from that > location. > I had a better look into "lnav". As a tool, it has all sort of features. For example, Options: -I path An additional configuration directory. -i Install the given format files and exit. Pass 'extra' to install the default set of third-party formats. -u Update formats installed from git repositories. Both "-i extra" and "-u" are spawning "git", which means there is a dependency on git. Here is how it looks: $ lnav -u Updating formats in /home/user/snap/lnav/x2/.lnav/formats/* sh: 1: git: not found In terms of security, lnav is a tool for system administrators. Therefore, it is good if lnav could work confined. A specially crafted logfile might be able to execute code. All in all, I am all for making a confined "lnav" snap with reduced functionality (no git, no "home" interface to store settings). My big question is, is it possible to get sudo snap connect lnav:log-observe core:log-observe to autoexecute upon the installation of the snap? Simos -------------- next part -------------- A non-text attachment was scrubbed... Name: snapcraft.yaml Type: application/x-yaml Size: 961 bytes Desc: not available URL: From jamie at canonical.com Thu Feb 2 17:35:01 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 02 Feb 2017 11:35:01 -0600 Subject: Testing a snap for lnav (log file navigator), publishing In-Reply-To: References: <1486041908.25932.81.camel@ubuntu.com> Message-ID: <1486056901.10013.248.camel@canonical.com> On Thu, 2017-02-02 at 19:00 +0200, Simos Xenitellis wrote: > In addition, I added the interface "network". This is due to to lnav > opening a UNIX domain socket, > and using the "sendto()" system call. Is this a socket for IPC between commands in your snap or for something else? -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From b.morelli at evidence.eu.com Thu Feb 2 17:48:35 2017 From: b.morelli at evidence.eu.com (Bruno Morelli) Date: Thu, 2 Feb 2017 18:48:35 +0100 Subject: ERROR cannot deliver device serial request: unexpected status 400 In-Reply-To: <67d00797-1eb5-a904-7eda-ee73f54d2940@ubuntu.com> References: <1486031239.25932.61.camel@ubuntu.com> <67d00797-1eb5-a904-7eda-ee73f54d2940@ubuntu.com> Message-ID: Thank you very much, now it's clearer than before. Regards, Bruno 2017-02-02 11:32 GMT+01:00 Mark Shuttleworth : > On 02/02/17 10:27, Oliver Grawert wrote: > > hi, > > Am Donnerstag, den 02.02.2017, 10:01 +0100 schrieb Ara Pulido: > >> > >> Your device is trying to get a serial assertion from the Ubuntu > >> servers, but your model is not one of the Ubuntu official ones, so > >> that is not possible. > > AFAIK it is possible if both, gadget and kernel snaps are in the store > > and signed by the same key that was used by the model assertion (i.e. > > owned by the same user). at least that is my experience with the > > beaglebone black image that i produce. > > Am not sure what's causing the specific issue you see, but Ogra is > describing the expected behaviour, which is that you can push a kernel > and gadget snap and then your own model assertion which binds those > together and is the basis for the image builder. > > We are working with the hardware companies to ensure that building a > kernel snap is trivial for their hardware. Certified board will have > official kernel snaps that anybody can "just use". Of course, if you > want to modify the kernel for an official board you can also just build > your own kernel snap. > > I know there is some work outstanding to get all of those pieces > working. There are some tricky corner cases (for example, what if you > want to change kernel snap entirely by issuing a new revision of your > model-assertion?) but it shouldn't be long before everything is in place > to enable all of that for straightforward cases. > > Mark > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simos.lists at googlemail.com Thu Feb 2 17:50:57 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Thu, 2 Feb 2017 19:50:57 +0200 Subject: Testing a snap for lnav (log file navigator), publishing In-Reply-To: <1486056901.10013.248.camel@canonical.com> References: <1486041908.25932.81.camel@ubuntu.com> <1486056901.10013.248.camel@canonical.com> Message-ID: On Thu, Feb 2, 2017 at 7:35 PM, Jamie Strandboge wrote: > On Thu, 2017-02-02 at 19:00 +0200, Simos Xenitellis wrote: > >> In addition, I added the interface "network". This is due to to lnav >> opening a UNIX domain socket, >> and using the "sendto()" system call. > > Is this a socket for IPC between commands in your snap or for something else? > It is for IPC only. Here is the relevant lsof output: lnav 25190 myuser 5u unix 0x0000000000000000 0t0 98775 type=STREAM lnav 25203 myuser 6u unix 0x0000000000000000 0t0 98776 type=STREAM Simos From luca.dionisi at gmail.com Thu Feb 2 17:52:02 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Thu, 2 Feb 2017 18:52:02 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: On Thu, Feb 2, 2017 at 4:55 PM, Sergio Schvezov wrote: > Does your configure have something like > > ./configure --with-extra-vapi-dir > > ? > > If so, try doing > > parts: > my-part: > source: ... > plugin: autotools > configflags: > - --with-extra-vapi-dir=$SNAPCRAFT_STAGE/usr/share/vala/vapi > No it doesn't. I was thinking to try adding this in configure.ac of mylib-y: PKG_CHECK_VAR([LIBX_PREFIX], [mylib-x], [prefix]) Then adding this in Makefile.am of mylib-y to mylib_y_VALAFLAGS: --vapidir $(LIBX_PREFIX)/share/vala/vapi Then my guess is that snapcraft will find its way without the aid of particular configflags. From luca.dionisi at gmail.com Thu Feb 2 18:18:07 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Thu, 2 Feb 2017 19:18:07 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: Yes. It is indeed doing the trick. Probably better yet, I should add a "vapidir" variable to the *.pc file of my Vala libraries and use it in dependent projects. That is, in configure.ac: PKG_CHECK_VAR([LIBX_VAPIDIR], [mylib-x], [vapidir]) and in VALAFLAGS of Makefile.am: --vapidir $(LIBX_VAPIDIR) On Thu, Feb 2, 2017 at 6:52 PM, Luca Dionisi wrote: > On Thu, Feb 2, 2017 at 4:55 PM, Sergio Schvezov > wrote: >> Does your configure have something like >> >> ./configure --with-extra-vapi-dir >> >> ? >> >> If so, try doing >> >> parts: >> my-part: >> source: ... >> plugin: autotools >> configflags: >> - --with-extra-vapi-dir=$SNAPCRAFT_STAGE/usr/share/vala/vapi >> > > No it doesn't. > > I was thinking to try adding this in configure.ac of mylib-y: > PKG_CHECK_VAR([LIBX_PREFIX], [mylib-x], [prefix]) > > Then adding this in Makefile.am of mylib-y to mylib_y_VALAFLAGS: > --vapidir $(LIBX_PREFIX)/share/vala/vapi > > Then my guess is that snapcraft will find its way without the aid of > particular configflags. From jamie at canonical.com Thu Feb 2 18:26:07 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 02 Feb 2017 12:26:07 -0600 Subject: Testing a snap for lnav (log file navigator), publishing In-Reply-To: References: <1486041908.25932.81.camel@ubuntu.com> <1486056901.10013.248.camel@canonical.com> Message-ID: <1486059967.10013.254.camel@canonical.com> On Thu, 2017-02-02 at 19:50 +0200, Simos Xenitellis wrote: > On Thu, Feb 2, 2017 at 7:35 PM, Jamie Strandboge wrote: > > > > On Thu, 2017-02-02 at 19:00 +0200, Simos Xenitellis wrote: > > > > > > > > In addition, I added the interface "network". This is due to to lnav > > > opening a UNIX domain socket, > > > and using the "sendto()" system call. > > Is this a socket for IPC between commands in your snap or for something > > else? > > > It is for IPC only. > > Here is the relevant lsof output: > > lnav      25190                   myuser    5u     unix > 0x0000000000000000       0t0      98775 type=STREAM > lnav      25203                   myuser    6u     unix > 0x0000000000000000       0t0      98776 type=STREAM > Ok thanks. I'm working through detangling some of the network, network-bind and unix socket policy and will add this as a test case. In the meantime, feel free to continue to use 'network' as a workaround. Thanks! -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Thu Feb 2 18:51:33 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 2 Feb 2017 18:51:33 +0000 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: On Thu, 2 Feb 2017 18:52:02 +0100, Luca Dionisi wrote: > On Thu, Feb 2, 2017 at 4:55 PM, Sergio Schvezov > wrote: >> Does your configure have something like >> >> ./configure --with-extra-vapi-dir >> >> ? >> >> If so, try doing >> >> parts: >> my-part: >> source: ... >> plugin: autotools >> configflags: >> - --with-extra-vapi-dir=$SNAPCRAFT_STAGE/usr/share/vala/vapi >> > > No it doesn't. > > I was thinking to try adding this in configure.ac of mylib-y: > PKG_CHECK_VAR([LIBX_PREFIX], [mylib-x], [prefix]) > > Then adding this in Makefile.am of mylib-y to mylib_y_VALAFLAGS: > --vapidir $(LIBX_PREFIX)/share/vala/vapi > > Then my guess is that snapcraft will find its way without the aid of > particular configflags. Sorry, but the layer up to which I can offer help is up to ./configure, anything inside that is out of my knowledgebase. I am one of the many that switched to cmake for these things :-) -- Sent using Dekko from my Ubuntu device From sergio.schvezov at canonical.com Thu Feb 2 19:19:54 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 2 Feb 2017 19:19:54 +0000 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: On Thu, 2 Feb 2017 19:18:07 +0100, Luca Dionisi wrote: > Yes. It is indeed doing the trick. > Probably better yet, I should add a "vapidir" variable to the *.pc > file of my Vala libraries and use it in dependent projects. > That is, in configure.ac: > PKG_CHECK_VAR([LIBX_VAPIDIR], [mylib-x], [vapidir]) > and in VALAFLAGS of Makefile.am: > --vapidir $(LIBX_VAPIDIR) pkg-config and having your build system depend on that package is the way to go wrt common practice in this ecosystem we live in, so yeah, +1. -- Sent using Dekko from my Ubuntu device From joseph.wakeling at webdrake.net Thu Feb 2 20:18:55 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 2 Feb 2017 21:18:55 +0100 Subject: Using docker for clean builds of classic snaps In-Reply-To: References: Message-ID: On 02/02/17 14:40, Jamie Bennett wrote: > We have this page that explains how to build using Docker containers (the url name is wrong but the contents are right). > > * https://snapcraft.io/docs/build-snaps/trusty Hi Jamie -- thanks for the pointer. Unfortunately it doesn't work with classic snaps :-( $ sudo docker run -v $PWD:$PWD -w $PWD snapcore/snapcraft snapcraft Unable to find image 'snapcore/snapcraft:latest' locally latest: Pulling from snapcore/snapcraft 2f0243478e1f: Pull complete d8909ae88469: Pull complete 820f09abed29: Pull complete 01193a8f3d88: Pull complete 22802091ea0e: Pull complete Digest: sha256:a1c3ddcfd7d8af5a9ad5762f3d014389ef6db718a848ce59c5add791b65036a4 Status: Downloaded newer image for snapcore/snapcraft:latest Issues while validating snapcraft.yaml: The 'confinement' property does not match the required schema: 'classic' is not one of ['devmode', 'strict'] From michael.hudson at canonical.com Thu Feb 2 20:39:57 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Fri, 3 Feb 2017 09:39:57 +1300 Subject: please try my golang snap Message-ID: Prompted by some upstream discussion, I've made a snap of Go (just 1.7.4 for now): $ sudo snap install --edge --classic go-17-mwhudson It has aliases for go-17 (which will probably be the final snap of the snap if this ends up being official) and go (the thinking being that there will also be go-16, go-18 etc snaps and users can select which they use by selecting an alias). The source is at https://code.launchpad.net/~mwhudson/+git/gosnap/+ref/master. Please let me know how this works for you! Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Thu Feb 2 21:03:43 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Feb 2017 21:03:43 +0000 Subject: please try my golang snap In-Reply-To: References: Message-ID: On 02/02/17 20:39, Michael Hudson-Doyle wrote: > sudo snap install --edge --classic go-17-mwhudson ZOMG, perfect timing :) From loic.minier at ubuntu.com Thu Feb 2 21:35:19 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Thu, 2 Feb 2017 22:35:19 +0100 Subject: Using docker for clean builds of classic snaps In-Reply-To: References: Message-ID: There are a bunch of Docker images providing snapcraft , unfortunately they are all behind. These should be autobuilt instead of manually updated, in the mean time I suggest you build your own (relatively easy) . Otherwise, Didier's image is only a month old and should include a snapcraft with experimental support for classic snaps. Cheers, - Loïc On Thu, Feb 2, 2017 at 9:18 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 02/02/17 14:40, Jamie Bennett wrote: > >> We have this page that explains how to build using Docker containers (the >> url name is wrong but the contents are right). >> >> * https://snapcraft.io/docs/build-snaps/trusty >> > > Hi Jamie -- thanks for the pointer. Unfortunately it doesn't work with > classic snaps :-( > > $ sudo docker run -v $PWD:$PWD -w $PWD snapcore/snapcraft snapcraft > Unable to find image 'snapcore/snapcraft:latest' locally > latest: Pulling from snapcore/snapcraft > 2f0243478e1f: Pull complete > d8909ae88469: Pull complete > 820f09abed29: Pull complete > 01193a8f3d88: Pull complete > 22802091ea0e: Pull complete > Digest: sha256:a1c3ddcfd7d8af5a9ad5762f3d014389ef6db718a848ce59c5add > 791b65036a4 > Status: Downloaded newer image for snapcore/snapcraft:latest > Issues while validating snapcraft.yaml: The 'confinement' property does > not match the required schema: 'classic' is not one of ['devmode', 'strict'] > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From espy at canonical.com Thu Feb 2 22:22:28 2017 From: espy at canonical.com (espy) Date: Thu, 2 Feb 2017 17:22:28 -0500 Subject: Snap security questions In-Reply-To: <1485960368.10013.235.camel@canonical.com> References: <1485960368.10013.235.camel@canonical.com> Message-ID: On 02/01/2017 09:46 AM, Jamie Strandboge wrote: > On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote: >> Hi, [...] >> 3. QNetworkAccessManager wants to access NetworkManager >> >> We use QNetworkAccessManager as our HTTP library. This results in a >> number of denials for D-Bus method calls to NetworkManager. >> >> I can make these denials go away by plugging in to the >> ":network-manager" slot, but a quick look at that interface shows that >> it grants a lot more permissions than I need or want (i.e. permission >> to reconfigure the network). >> >> I imagine that a lot of snaps will use QNetworkAccessManager, so it >> would be nice if the calls it makes were allowed by some >> auto-connectable interface. If not as part of ":network", then >> something similar. > > The network-manager API is highly privileged (and messy) and should not be auto- > connected. Most applications that use network manager are only trying to figure > out if they are online or not, but the way to do that in the network manager API > is to query a ton of things a confined app shouldn't typically have. This is > what Qt does by default and this is why the connectivity-api was developed and > used on Touch[1]. connectivity-api is proxy that can answer questions like "am I > online" on behalf of the application. On Touch, iirc, Qt was modified to use > connectivity-api so Touch apps transparently used connectivity-api behind the > scenes. AFAIK, the Touch version of Qt was never modified to use the connectivity-api (which is part of indicator-network), as the API was never fully fleshed out. It really only offered two public properties 'Status' ( Offline | Connecting | Online ) and a boolean flag which indicated whether or not the connection was bandwidth-limited. As such, it really wasn't enough to support the internal Qt network Bearer API. > AIUI, the Personal team is in the process of creating the connectivity- > api snap and I suspect this'll work when using ubuntu-platform content snap > (Personal team, please correct me if I mispoke). Once connectivity-api works as > a snap, the plan is to make the connectivity-api accesses in an interface that > is auto-connectable (you might check with the Personal team on the status of all > this connectivity-api work). Interesting... Anyone from the Personal team care to comment on the status of this work? Has any work gone into re-working the original API? Regards, /tony From jamie at canonical.com Thu Feb 2 22:58:37 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 02 Feb 2017 16:58:37 -0600 Subject: Snap security questions In-Reply-To: References: <1485960368.10013.235.camel@canonical.com> Message-ID: <1486076317.10013.259.camel@canonical.com> On Thu, 2017-02-02 at 17:22 -0500, espy wrote: > > On 02/01/2017 09:46 AM, Jamie Strandboge wrote: > > > > On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote: > > > > > > Hi, > [...] > > > > > > > > > 3. QNetworkAccessManager wants to access NetworkManager > > > > > > We use QNetworkAccessManager as our HTTP library.  This results in a > > > number of denials for D-Bus method calls to NetworkManager. > > > > > > I can make these denials go away by plugging in to the > > > ":network-manager" slot, but a quick look at that interface shows that > > > it grants a lot more permissions than I need or want (i.e. permission > > > to reconfigure the network). > > > > > > I imagine that a lot of snaps will use QNetworkAccessManager, so it > > > would be nice if the calls it makes were allowed by some > > > auto-connectable interface.  If not as part of ":network", then > > > something similar. > > The network-manager API is highly privileged (and messy) and should not be > > auto- > > connected. Most applications that use network manager are only trying to > > figure > > out if they are online or not, but the way to do that in the network manager > > API > > is to query a ton of things a confined app shouldn't typically have. This is > > what Qt does by default and this is why the connectivity-api was developed > > and > > used on Touch[1]. connectivity-api is proxy that can answer questions like > > "am I > > online" on behalf of the application. On Touch, iirc, Qt was modified to use > > connectivity-api so Touch apps transparently used connectivity-api behind > > the > > scenes. > AFAIK, the Touch version of Qt was never modified to use the  > connectivity-api (which is part of indicator-network), as the API was  > never fully fleshed out.  It really only offered two public properties  > 'Status' ( Offline | Connecting | Online ) and a boolean flag which  > indicated whether or not the connection was bandwidth-limited. > > As such, it really wasn't enough to support the internal Qt network  > Bearer API. > Lorn created a bearer plugin: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1404188/com ments/28 https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1404188/com ments/30 but it looks like it wasn't finished: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1404188/com ments/34 Perhaps someone from the Personal team can comment? -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From menno.smits at canonical.com Fri Feb 3 03:02:48 2017 From: menno.smits at canonical.com (Menno Smits) Date: Fri, 3 Feb 2017 16:02:48 +1300 Subject: please try my golang snap In-Reply-To: References: Message-ID: On 3 February 2017 at 09:39, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > Prompted by some upstream discussion, I've made a snap of Go (just 1.7.4 > for now): > > $ sudo snap install --edge --classic go-17-mwhudson > Nice! ​Building Juju and running some tests with the race detector enabled both worked fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Fri Feb 3 05:42:52 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Fri, 3 Feb 2017 08:42:52 +0300 Subject: LibreOffice in snap can't open file Message-ID: Uh, if path contain non-English characters than LO can't open file. http://imgur.com/a/VdhwV -- Best regards, vasilisc From shuduo.sang at canonical.com Fri Feb 3 08:52:33 2017 From: shuduo.sang at canonical.com (Shuduo Sang) Date: Fri, 3 Feb 2017 16:52:33 +0800 Subject: please try my golang snap In-Reply-To: References: Message-ID: Hi, I got following output after run it: $ go-17-mwhudson.go-17 /snap/go-17-mwhudson/2/gowrapper: line 3: /snap/go-17-mwhudson/2/bin/go: No such file or directory My snap version is: $ snap version snap 2.21 snapd 2.21 series 16 ubuntu 16.04 Please let me know what mistake I have. Thanks, On Fri, Feb 3, 2017 at 4:39 AM, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > Prompted by some upstream discussion, I've made a snap of Go (just 1.7.4 > for now): > > $ sudo snap install --edge --classic go-17-mwhudson > > It has aliases for go-17 (which will probably be the final snap of the > snap if this ends up being official) and go (the thinking being that there > will also be go-16, go-18 etc snaps and users can select which they use by > selecting an alias). > > The source is at https://code.launchpad.net/~mwhudson/+git/gosnap/+ref/ > master. > > Please let me know how this works for you! > > Cheers, > mwh > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Fri Feb 3 10:20:11 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 3 Feb 2017 11:20:11 +0100 Subject: dlopen cannot load shared library Message-ID: <07b6697f-3488-dd56-11bc-39712987278a@canonical.com> Hi, I'm having a problem with a snap which start certain daemon when installed. This daemon tries to load certain shared library but it's not able to do it even in devmode [1]. However it loads it well in classic mode. The library is in a rw path, provided directly to a dlopen method [1]. Have anybody hit this kind of issue before? Thanks. [1] Failed to load /var/snap/loolwsd/x1/opt/collaboraoffice5.1/program/libmergedlo.so: libX11.so.6: cannot open shared object file: No such file or directory [2] line 1764 in https://cgit.freedesktop.org/libreoffice/online/tree/kit/Kit.cpp?h=distro%2Fcollabora%2Fcollabora-online-2-0 From roberto.escandon at canonical.com Fri Feb 3 10:24:51 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 3 Feb 2017 11:24:51 +0100 Subject: daemon launches another shell Message-ID: Hey, Does anybody knows if openning a new shell from a daemon startup script will be allowed in confined mode?. The case is this: the daemon starts as root and tries to execute certain script as another user su otheruser --shell=/bin/sh -c "$SNAP/bin/thescript" in devmode, apparmor is giving me some ALLOWED traces that i'm not confident will be allowed when confined... Cheers. From sergio.schvezov at canonical.com Fri Feb 3 11:57:10 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 3 Feb 2017 08:57:10 -0300 Subject: snapcraft 2.26 has been released Message-ID: Hello snapcrafters! We are pleased to announce the release of version `2.26` of snapcraft has been released: https://launchpad.net/snapcraft/+milestone/2.26 This release is now available on xenial-updates, yakkety-updates and zesty. What follows are the full release notes (the prettier version can be read at https://github.com/snapcore/ snapcraft/releases/tag/2.26 ) # Contributions This release has seen some contributions from outside of the snapcraft core team, so we want to give a shout out to these folks, here's a team thank you for: - Björn Tillenius - Marco Trevisan - Matthew Aguirre - Olivier Tilloy - Shawn Wang # New in this release ## Snap directory now in place All the snapcraft specific asset handling has been moved to the `snap` directory as the preferred location for the following: - `snapcraft.yaml` - `setup/gui` - `parts/plugins` This adds up to the already existing location for `hooks` introduced in 2.25. On `snapcraft init`, snapcraft will now create a `snap/snapcraft.yaml` file. Keep in mind that the existing `snapcraft.yaml` and `.snapcraft.yaml` are still valid and *not* deprecated. However, use of `parts/plugins` will print a deprecation message with a link to https://snapcraft.io/docs/deprecation-notices/dn2 and use of `setup/gui` will behave in a similar way but linking to https://snapcraft.io/docs/deprecation-notices/dn3. ## stage packages The experience for using multi-architecture package entries in `stage-packages` has been refined. This should provide a better experience for when someone wants to; to illustrate image that on an `arm64` you would want to include an `armhf` package, e.g.; ```yaml parts: packages: plugin: nil stage-packages: - libfoo:armhf ``` ## Desktop file support enhancements Snapcraft 2.25 introduced support for `desktop` file entries in as part of an app entry in `apps`. There have been improvements to this functionality for when the app entry in `apps` matches the snap `name` as well as polishing in the assembly of the resutling snap. ## godeps plugin The `godeps` plugin until this release fetched all the dependencies defined in `dependencies.tsv` or that defined in the part by the `godeps-file` entry and proceeded to build all `package main` sources found in the tree. This can now be limited to only build certain packages by use of the `go-packages` entry. As an example let's use `juju`. It currently as at the time of this writing: - `github.com/juju/juju/cmd/juju` - `github.com/juju/juju/cmd/jujud` - `github.com/juju/juju/cmd/plugins/juju-metadata` - `github.com/juju/juju/cmd/plugins/juju-upgrade-mongo` Without the `go-packages` entry you would end up with 4 binaries in your snap `juju`. `jujud`. `juju-metadata` and `juju-upgrade-mongo`. If for example you wanted to only build `juju` something like this would do the trick: ```yaml parts: juju: https://github.com/juju/juju go-importpath: github.com/juju/juju go-packages: - github.com/juju/juju/cmd/juju ``` ## catkin plugin The `catkin` plugin has been optimized under the hood to work better with the compiler meant to be used with the chosen ROS release. ## gradle plugin The `gradle` plugin has been enhanced to also work with `gradle` transparently when `gradlew` is not provided with the `sources` of that part. ## python plugin The `python` plugin will now do the right thing when setting up a `requirements` entry and having an `install_requires` entry in `setup.py`. ## General polishing Some nice polishing that is part of ongoing work is showing up in this release: - schema errors related to text length limits now display an error a human can parse. - incorrect spacing issues have been fixed in some prompts. - some projects that are part of the tour had missing `build-packages added to them. - colors have been fixed for failed logins to the store. ## Others For the full list of things available on 2.26 feel free to check https://launchpad.net/snapcraft/+milestone/2.26 # Final Notes To get the source for this release check it out at https://github.com/snapcore/snapcraft/releases/tag/2.26 A great place to collaborate and discuss features, bugs and ideas on snapcraft is snapcraft at lists.snapcraft.io mailing list or on the snapcraft channel on Rocket Chat https://rocket.ubuntu.com/channel/snapcraft To file bugs, please go to https://bugs.launchpad.net/snapcraft/+filebug. Happy snapcrafting! -- Sergio and the team -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at jamesh.id.au Fri Feb 3 11:59:15 2017 From: james at jamesh.id.au (James Henstridge) Date: Fri, 3 Feb 2017 19:59:15 +0800 Subject: Snap security questions In-Reply-To: <1485960368.10013.235.camel@canonical.com> References: <1485960368.10013.235.camel@canonical.com> Message-ID: On 1 February 2017 at 22:46, Jamie Strandboge wrote: > On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote: >> 2. Use of the libapparmor aa_is_enabled and aa_query_label APIs >> >> When deciding whether to do work on behalf of a client, >> thumbnailer-service uses a couple libapparmor API calls to determine >> whether the client has access to a file. Neither of these are working >> under snappy confinement. >> >> The first call we use is aa_is_enabled(), but it seems the policy is >> to strict to let us determine whether AppArmor is enabled or not. >> >> Next we use aa_query_label() to perform the file access check. This >> fails when trying to read /proc/$pid/mounts to determine where >> securityfs is mounted. If that is fixed, it will likely fail when >> trying to access the "/sys/kernel/security/apparmor/.access" file >> within. >> >> I've filed a bug for this one here: >> >> https://bugs.launchpad.net/snappy/+bug/1660957 > > This needs some more thought since only "trusted helpers" that are doing some > form of mediation themselves need this access. Adding it to the dbus interface > by default isn't correct since, for example, ktuberling shouldn't be asking > about the security contexts of other snaps (not to mention, this doesn't really > have anything to do with the dbus interface). I've assigned it to me and will > think about it and will comment in the bug/propose a PR where we can discuss > further. Since it looked like we'd need a specialised snappy interface for thumbnailer, I had a go adding the rules necessary to enable aa_query_label() there. If thumbnailer turns out to be the only snap needing this API, or the other snaps needing it also require custom interfaces, then perhaps this is a reasonable place to put the rules. Of course, once I got my interface up and running, I ran into https://bugs.launchpad.net/apparmor/+bug/1620635 again. I've put my in-progress branch up for review here: https://github.com/snapcore/snapd/pull/2783 >> 3. QNetworkAccessManager wants to access NetworkManager >> >> We use QNetworkAccessManager as our HTTP library. This results in a >> number of denials for D-Bus method calls to NetworkManager. >> >> I can make these denials go away by plugging in to the >> ":network-manager" slot, but a quick look at that interface shows that >> it grants a lot more permissions than I need or want (i.e. permission >> to reconfigure the network). >> >> I imagine that a lot of snaps will use QNetworkAccessManager, so it >> would be nice if the calls it makes were allowed by some >> auto-connectable interface. If not as part of ":network", then >> something similar. > > The network-manager API is highly privileged (and messy) and should not be auto- > connected. Most applications that use network manager are only trying to figure > out if they are online or not, but the way to do that in the network manager API > is to query a ton of things a confined app shouldn't typically have. This is > what Qt does by default and this is why the connectivity-api was developed and > used on Touch[1]. connectivity-api is proxy that can answer questions like "am I > online" on behalf of the application. On Touch, iirc, Qt was modified to use > connectivity-api so Touch apps transparently used connectivity-api behind the > scenes. AIUI, the Personal team is in the process of creating the connectivity- > api snap and I suspect this'll work when using ubuntu-platform content snap > (Personal team, please correct me if I mispoke). Once connectivity-api works as > a snap, the plan is to make the connectivity-api accesses in an interface that > is auto-connectable (you might check with the Personal team on the status of all > this connectivity-api work). As Tony noted, there was no Qt patch on Touch. In retrospect it is obvious why I hadn't seen the denials there though: we hadn't yet tried to confine the daemon there. A quick scan through the log files on my phone shows instances of the denial for other confined apps, so I guess this is probably harmless. I suspect this will cause other people confusion though: if your app starts spitting out warnings about not being able to talk to NetworkManager, the first instinct is going to be to plug into the "network-manager" interface, and that is going to be the wrong option most of the time. James. From andrew at nocturnal.net.au Fri Feb 3 12:06:04 2017 From: andrew at nocturnal.net.au (Andrew Mason) Date: Fri, 03 Feb 2017 22:36:04 +1030 Subject: Generic Snap questions Message-ID: <4001728.f4fN6ktkGB@lincoln> Hi All, I have been listening to Alan Pope plugging snaps for a while now on the LUP podcast and decided to try it out by installing a popular snap on a remote VM. I ran into a few problems which had I installed this with a debian package or from source I would know how to solve; however these being snaps I wasn't immediately confident in what I could or shouldn't do. Rather than trying to work through my particular problem I was hoping to get a better sense (as a developer / sysadmin) as to how I should build my own snaps and administer snaps others have created. I haven't found the answers to my questions in the FAQ but apologies if I have missed some documentation which answers these. 1. This particular snap was a collection of used a combination of Apache httpd + MySQL and a few other utilities. I presume that if I wanted to use something like nginx instead of apache and MariaDB instead of mysql I would need to rebuild the snap my self ? Is the source / build instructions (.yml file?) available in some form that I can access? 2. This snap in particular seemed to be configured to listen on the IP address of machine it was running on. As this was deployed in Azure the VM is deployed with a private 10.x IP address and sits behind a foobarqux.cloudapp.net so it was not possible to visit the IP address directly; I ended up using an SSH tunnel to address this, but conceptually if I wanted to change a configuration element like this, what is the correct way to do so ? 3. Say a bunch of people want their own instance of this snappified service. How are / should additional instances handled from an installation perspective ? Also how would multiple instances be configured with regards to TCP port access ? 4. There was some attempt by the package to install a Let's encrypt certificate however that failed due (possibly) to the aforementioned IP address issue.. Is there any provision to be able to execute certain parts of the post-install / pre-install scripts like there is with a debian package ? i.e -reconfigure Assuming I am able to get a certificate manually...e.g I have an EV cert for the domain; how would I go about installing the Certificate into my new snap. I understand they are mounted images but from my understanding these are read only. Do I just mount -o remount,rw ? 5. Prior to the installation of the aforementioned snap, I used UFW to add a firewall restricting access to all but the SSH port. After installing this snap it did not seem to automatically open a port. Is this the correct behaviour ? If I am building a snap of my own application how would I go about informing the user that this additional task is necessary ? Can I prompt them to perform this action ? If you have made it this far I really appreciate that you have taken the time to consider the questions and any answers would be greatly valued. Kind regards Andrew From loic.minier at ubuntu.com Fri Feb 3 12:41:04 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Fri, 3 Feb 2017 13:41:04 +0100 Subject: dlopen cannot load shared library In-Reply-To: <07b6697f-3488-dd56-11bc-39712987278a@canonical.com> References: <07b6697f-3488-dd56-11bc-39712987278a@canonical.com> Message-ID: Hi, On Fri, Feb 3, 2017 at 11:20 AM, Roberto Mier Escandón  < roberto.escandon at canonical.com> wrote: > I'm having a problem with a snap which start certain daemon when > installed. This daemon tries to load certain shared library but it's not > able to do it even in devmode [1]. However it loads it well in classic > mode. The library is in a rw path, provided directly to a dlopen method > [1]. Have anybody hit this kind of issue before? > In classic mode, you see libraries from your classic Ubuntu system including X11; in devmode/confined mode, you only see system libraries from the core snap which doesn't contain X11. I suggest you embed X11 and other libs that your dlopen-ed library depends on. Cheers, - Loïc Minier -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Fri Feb 3 12:50:08 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 3 Feb 2017 12:50:08 +0000 Subject: dlopen cannot load shared library In-Reply-To: References: <07b6697f-3488-dd56-11bc-39712987278a@canonical.com> Message-ID: On 03/02/17 12:41, Loïc Minier wrote: > Hi, > > On Fri, Feb 3, 2017 at 11:20 AM, Roberto Mier Escandón  > > wrote: > > I'm having a problem with a snap which start certain daemon when > installed. This daemon tries to load certain shared library but > it's not > able to do it even in devmode [1]. However it loads it well in classic > mode. The library is in a rw path, provided directly to a dlopen > method > [1]. Have anybody hit this kind of issue before? > > > In classic mode, you see libraries from your classic Ubuntu system > including X11; in devmode/confined mode, you only see system libraries > from the core snap which doesn't contain X11. > > I suggest you embed X11 and other libs that your dlopen-ed library > depends on. Loic is correct, but let me give a slightly less compressed answer :) The snap sees a filesystem that is constructed specially for it, out of a bunch of other filesystems. Just like you can mount a set of disks at particular paths, for the snap, a set of "disks" are mounted at particular locations. So what the snap processes "see" as their disk is specially constructed just for that snap. In the case of a devmode or strictly confined snap, the root of the filesystem ("/") is the core snap. That is a tiny heart of Ubuntu (in future could be Fedora or Debian too) that just has the very core libraries and binaries. It does not have X11 or any desktop libraries. So when you switched to devode, your snap processes stop seeing your "normal hard disk" at / and start seeing the minimal core snap at /. If you 'ls -l /snap/core/current' on a classic desktop you will see the filesystem that your snap sees at /. There are no X libraries there :) That's why you need either: * to bundle your X libraries. snapcraft will try to do this for you automatically. if you are handcrafting your snap then you need to pay attention to the files in the snap and the loading paths that the linker uses. * to use libraries from another snap which might have shared content that lots of snaps reuse, in which case if that other snap changes you might break Hope that's clearer, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.henstridge at canonical.com Fri Feb 3 12:51:03 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Fri, 3 Feb 2017 20:51:03 +0800 Subject: dlopen cannot load shared library In-Reply-To: References: <07b6697f-3488-dd56-11bc-39712987278a@canonical.com> Message-ID: On 3 February 2017 at 20:41, Loïc Minier wrote: > Hi, > > On Fri, Feb 3, 2017 at 11:20 AM, Roberto Mier Escandón  > wrote: >> >> I'm having a problem with a snap which start certain daemon when >> installed. This daemon tries to load certain shared library but it's not >> able to do it even in devmode [1]. However it loads it well in classic >> mode. The library is in a rw path, provided directly to a dlopen method >> [1]. Have anybody hit this kind of issue before? > > > In classic mode, you see libraries from your classic Ubuntu system including > X11; in devmode/confined mode, you only see system libraries from the core > snap which doesn't contain X11. > > I suggest you embed X11 and other libs that your dlopen-ed library depends > on. Another alternative is to use the ubuntu-app-platform snap, as described here: https://insights.ubuntu.com/2016/12/08/using-the-ubuntu-app-platform-content-interface-in-app-snaps/ Together with the desktop-launch script, this takes care of getting a number of common desktop libraries to work under confinement. James. From mark at ubuntu.com Fri Feb 3 12:59:42 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 3 Feb 2017 12:59:42 +0000 Subject: dlopen cannot load shared library In-Reply-To: References: <07b6697f-3488-dd56-11bc-39712987278a@canonical.com> Message-ID: On 03/02/17 12:41, Loïc Minier wrote: > In classic mode, you see libraries from your classic Ubuntu system > including X11; in devmode/confined mode, you only see system libraries > from the core snap which doesn't contain X11. One more point. If you try this command you will be running a shell "inside the snap", in other words, you will be experiencing the filesystem exactly as your snap sees it. $ snap run --shell Now you are living inside the container that is setup just for that snap. It's using the same sorts of mechanisms as LXD and Docker to keep processes apart, but it is also setup in such a way that files can be shared across snaps. You can see the environment variables that snapd has setup so snap processes can find out where they can write data etc: $ set | grep SNAP SNAP=/snap/etcd/x5 SNAP_ARCH=amd64 SNAP_COMMON=/var/snap/etcd/common SNAP_DATA=/var/snap/etcd/x5 SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl: SNAP_NAME=etcd SNAP_REEXEC= SNAP_REVISION=x5 SNAP_USER_COMMON=/home/mark/snap/etcd/common SNAP_USER_DATA=/home/mark/snap/etcd/x5 SNAP_VERSION=2.3.7 And if you start using 'ls' to poke around the filesystem, you quickly see that you are in your own special world: $ ls / ls: cannot open directory '/': Permission denied $ sudo ls / bash: /usr/bin/sudo: Permission denied $ ls -l /lib/ total 74 drwxr-xr-x 2 root root 52 Jan 13 20:41 apparmor drwxr-xr-x 2 root root 57 Jan 13 20:41 bridge-utils drwxr-xr-x 2 root root 40 Jan 13 20:41 cgmanager drwxr-xr-x 3 root root 89 Jan 13 20:41 crda drwxr-xr-x 2 root root 3 Jan 13 20:40 firmware drwxr-xr-x 2 root root 1032 Jan 13 20:41 i386-linux-gnu drwxr-xr-x 2 root root 59 Jan 13 20:41 ifupdown drwxr-xr-x 2 root root 51 Jan 13 20:41 init -rwxr-xr-x 1 root root 70952 Sep 22 18:34 klibc-k3La8MUnuzHQ0_kG8hokcGAC0PA.so lrwxrwxrwx 1 root root 25 Nov 16 22:51 ld-linux.so.2 -> i386-linux-gnu/ld-2.23.so drwxr-xr-x 3 root root 61 Jan 13 20:41 lsb drwxr-xr-x 2 root root 35 Jan 13 20:41 modprobe.d drwxr-xr-x 6 root root 4096 Jan 26 10:15 modules drwxr-xr-x 2 root root 31 Jan 13 20:41 netplan drwxr-xr-x 2 root root 35 Jan 13 20:41 resolvconf drwxr-xr-x 8 root root 1057 Jan 13 20:41 systemd drwxr-xr-x 15 root root 132 Jan 13 20:41 terminfo drwxr-xr-x 4 root root 298 Jan 13 20:41 udev drwxr-xr-x 3 root root 4281 Jan 13 20:41 x86_64-linux-gnu drwxr-xr-x 2 root root 2531 Jan 13 20:41 xtables So you see, this is a super-minimal "core" with just a few libraries. You can find your snap at $SNAP: $ echo $SNAP /snap/foo/7 $ ls -lR $SNAP /snap/foo/x5: ... Hope that's a useful introduction. It's a lot of fun once you realise that you have TOTAL control over your snap, but everything else is very structured for you. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simos.lists at googlemail.com Fri Feb 3 13:03:30 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Fri, 3 Feb 2017 15:03:30 +0200 Subject: Channel switching issue Message-ID: Hi All, When trying to switch channel for a snap, it fails of both channels have an identical snap. The channel switching is controlled with 'snap refresh', so if a refresh is not needed (are same), it does not change the tracking to the requested channel. Bug report: https://bugs.launchpad.net/snappy/+bug/1650689 Simos From simos.lists at googlemail.com Fri Feb 3 13:09:51 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Fri, 3 Feb 2017 15:09:51 +0200 Subject: When launching a snap from Ubuntu Software, it may not pick our intended command (if are many) Message-ID: Hi All, When launching a snap from Ubuntu Software ('Launch' button), there is the issue which command (from snapcraft.yaml) it should use to start the program. The intuitive way would be to use the first command specified in snapcraft.yaml. However, it appears that somehow the list of commands is sorted, so the intended command may not get selected. It could be a bug in Ubuntu Software as well but does not look like. If you try to run 'snap info libreoffice' several times (assumed you already installed the snap), you notice that the order of the commands is different every time. commands: - libreoffice.writer - libreoffice.base - libreoffice.calc - libreoffice.draw - libreoffice.impress - libreoffice - libreoffice.math then commands: - libreoffice.math - libreoffice.writer - libreoffice.base - libreoffice.calc - libreoffice.draw - libreoffice.impress - libreoffice Bug report: https://bugs.launchpad.net/snappy/+bug/1661590 It happens also with the LibreOffice snap, see the update at https://blog.simos.info/how-to-install-libreoffice-5-3-on-ubuntu-16-04-from-snap/ Simos From ted at ubuntu.com Fri Feb 3 14:49:10 2017 From: ted at ubuntu.com (Ted Gould) Date: Fri, 3 Feb 2017 14:49:10 +0000 Subject: When launching a snap from Ubuntu Software, it may not pick our intended command (if are many) In-Reply-To: References: Message-ID: On Fri, 3 Feb 2017 15:09:51 +0200, Simos Xenitellis wrote: > The intuitive way would be to use the first command specified > in snapcraft.yaml. It seems to be the better choice would be the one with the same name as the package. Ted -- From george.gundry at 4dml.com Fri Feb 3 15:08:39 2017 From: george.gundry at 4dml.com (George Gundry) Date: Fri, 3 Feb 2017 15:08:39 -0000 Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core Message-ID: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> I followed the instructions here: https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 I have created a Ubuntu SSO account uploaded my SSH public key, used Win32DiskImager to burn the Ubuntu Core Pi3 image ubuntu-core-16-pi3.img to an SD card, booted the Pi3 connected to Ethernet, correctly get the "Press Enter to Configure" message, pass Network Config, entered my SSO account, got the "Contacting Store" message, got the success reply back from the store saying the key had been stored on the Pi and I can use ssh @ Try to connect to pi over ssh as instructed, private key auth fails . Things I have tried: Different terminal emulators - putty; Remote Terminal; TokenShell/MD; command line ssh from another Pi; forcing use of specific private key with -I option Different SSH key pairs - known good pair that we use elsewhere; new keygen generated keys with passphrase; new keygen generated keys without passphrase Different Pi's - Work and home Different Ubuntu SSO accounts - created a new account from scratch, same result. In desperation, I tried to load 16.04 LTS, and this was successful so I am confident the kit (Pi, SD card, network connection) is good. Nothing I have tried makes any difference, the private key is never accepted by the Ubuntu Core device. I am keen to investigate migrating our IoT product from Raspbian Lite to Core, but can't seem to get beyond step one ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.seidel at hamburg.de Fri Feb 3 15:20:08 2017 From: matthias.seidel at hamburg.de (Matthias Seidel) Date: Fri, 3 Feb 2017 16:20:08 +0100 Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> Message-ID: <4f25ccaf-aa63-e475-979f-bdbf43c46968@hamburg.de> Hi, I had the same problem. If you get some error like "Permission denied (publickey)" the following page did the trick for me: https://help.ubuntu.com/community/SSH/OpenSSH/Keys Kind regards Matthias Seidel Am 03.02.2017 um 16:08 schrieb George Gundry: > > I followed the instructions here: > https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 > > I have created a Ubuntu SSO account > > uploaded my SSH public key, > > used Win32DiskImager to burn the Ubuntu Core Pi3 image > *ubuntu-core-16-pi3.img* to an SD card, > > booted the Pi3 connected to Ethernet, > > correctly get the “Press Enter to Configure” message, > > pass Network Config, > > entered my SSO account, > > got the ”Contacting Store” message, > > got the success reply back from the store saying the key had been > stored on the Pi and I can use *ssh @* > > Try to connect to pi over ssh as instructed, private key auth fails … > > Things I have tried: > > Different terminal emulators – putty; Remote Terminal; TokenShell/MD; > command line ssh from another Pi; forcing use of specific private key > with -I option > > Different SSH key pairs – known good pair that we use elsewhere; new > keygen generated keys with passphrase; new keygen generated keys > without passphrase > > Different Pi’s – Work and home > > Different Ubuntu SSO accounts – created a new account from scratch, > same result. > > In desperation, I tried to load 16.04 LTS, and this was successful so > I am confident the kit (Pi, SD card, network connection) is good. > > *Nothing I have tried makes any difference, the private key is never > accepted by the Ubuntu Core device.* > > I am keen to investigate migrating our IoT product from Raspbian Lite > to Core, but can’t seem to get beyond step one ! > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: From luca.dionisi at gmail.com Fri Feb 3 15:25:36 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 3 Feb 2017 16:25:36 +0100 Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> Message-ID: Just a couple of hints. 1. Double check username. It might be different than that of the email you use to signon at Ubuntu. E.g. my mail is luca.dionisi at gmail.com while user on my RPi is luca-dionisi. 2. Try flag "-v" with ssh. Check the id_rsa* files that it tries with. On Fri, Feb 3, 2017 at 4:08 PM, George Gundry wrote: > I followed the instructions here: > https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 > > I have created a Ubuntu SSO account > > uploaded my SSH public key, > > used Win32DiskImager to burn the Ubuntu Core Pi3 image > ubuntu-core-16-pi3.img to an SD card, > > booted the Pi3 connected to Ethernet, > > correctly get the “Press Enter to Configure” message, > > pass Network Config, > > entered my SSO account, > > got the ”Contacting Store” message, > > got the success reply back from the store saying the key had been stored on > the Pi and I can use ssh @ > > Try to connect to pi over ssh as instructed, private key auth fails … > > Things I have tried: > > Different terminal emulators – putty; Remote Terminal; TokenShell/MD; > command line ssh from another Pi; forcing use of specific private key with > -I option > > Different SSH key pairs – known good pair that we use elsewhere; new keygen > generated keys with passphrase; new keygen generated keys without passphrase > > Different Pi’s – Work and home > > Different Ubuntu SSO accounts – created a new account from scratch, same > result. > > In desperation, I tried to load 16.04 LTS, and this was successful so I am > confident the kit (Pi, SD card, network connection) is good. > > Nothing I have tried makes any difference, the private key is never accepted > by the Ubuntu Core device. > > I am keen to investigate migrating our IoT product from Raspbian Lite to > Core, but can’t seem to get beyond step one ! > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From gregory.lutostanski at canonical.com Fri Feb 3 15:40:24 2017 From: gregory.lutostanski at canonical.com (Gregory Lutostanski) Date: Fri, 3 Feb 2017 09:40:24 -0600 Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> Message-ID: And since it is a rpi... you can just pop out the sdcard, and put in a different computer and see which ssh-key is in the second-partition at user-data/*/.ssh/authorized_keys if you are really curious (although since you are on windows, reading that partition which is ext4 might be more difficult). On Fri, Feb 3, 2017 at 9:25 AM, Luca Dionisi wrote: > Just a couple of hints. > > 1. Double check username. > It might be different than that of the email you use to signon at Ubuntu. > E.g. my mail is luca.dionisi at gmail.com while user on my RPi is > luca-dionisi. > > 2. Try flag "-v" with ssh. Check the id_rsa* files that it tries with. > > > > > On Fri, Feb 3, 2017 at 4:08 PM, George Gundry > wrote: > > I followed the instructions here: > > https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 > > > > I have created a Ubuntu SSO account > > > > uploaded my SSH public key, > > > > used Win32DiskImager to burn the Ubuntu Core Pi3 image > > ubuntu-core-16-pi3.img to an SD card, > > > > booted the Pi3 connected to Ethernet, > > > > correctly get the “Press Enter to Configure” message, > > > > pass Network Config, > > > > entered my SSO account, > > > > got the ”Contacting Store” message, > > > > got the success reply back from the store saying the key had been stored > on > > the Pi and I can use ssh @ > > > > Try to connect to pi over ssh as instructed, private key auth fails … > > > > Things I have tried: > > > > Different terminal emulators – putty; Remote Terminal; TokenShell/MD; > > command line ssh from another Pi; forcing use of specific private key > with > > -I option > > > > Different SSH key pairs – known good pair that we use elsewhere; new > keygen > > generated keys with passphrase; new keygen generated keys without > passphrase > > > > Different Pi’s – Work and home > > > > Different Ubuntu SSO accounts – created a new account from scratch, same > > result. > > > > In desperation, I tried to load 16.04 LTS, and this was successful so I > am > > confident the kit (Pi, SD card, network connection) is good. > > > > Nothing I have tried makes any difference, the private key is never > accepted > > by the Ubuntu Core device. > > > > I am keen to investigate migrating our IoT product from Raspbian Lite to > > Core, but can’t seem to get beyond step one ! > > > > > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.gundry at 4dml.com Fri Feb 3 16:37:37 2017 From: george.gundry at 4dml.com (George Gundry) Date: Fri, 3 Feb 2017 16:37:37 -0000 Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> Message-ID: <004501d27e3b$d5467360$7fd35a20$@4dml.com> Hi Gregory, Luca & Mattias for your generous help. I was able to look at user-data/*/.ssh/authorized_keys (I mounted the SD card in Windows using ExtFS from Paragon Software) The key does not look right – a space has been inserted after every 80 characters ??? – see partial screenshot below. These space characters are not present when I open the source id_rsa.pub in Sublime … Unfortunately, I can only mount the drive as read-only, so can’t make the changes, save and try again :( Clearly, you guys HAVE been able to work, and I have double checked username and all other details – it’s driving me mad ! Regards, George From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Gregory Lutostanski Sent: 03 February 2017 15:40 To: Snapcraft Subject: Re: Unable to ssh to RPi3 after initial configuration of Ubuntu Core And since it is a rpi... you can just pop out the sdcard, and put in a different computer and see which ssh-key is in the second-partition at user-data/*/.ssh/authorized_keys if you are really curious (although since you are on windows, reading that partition which is ext4 might be more difficult). On Fri, Feb 3, 2017 at 9:25 AM, Luca Dionisi > wrote: Just a couple of hints. 1. Double check username. It might be different than that of the email you use to signon at Ubuntu. E.g. my mail is luca.dionisi at gmail.com while user on my RPi is luca-dionisi. 2. Try flag "-v" with ssh. Check the id_rsa* files that it tries with. On Fri, Feb 3, 2017 at 4:08 PM, George Gundry > wrote: > I followed the instructions here: > https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 > > I have created a Ubuntu SSO account > > uploaded my SSH public key, > > used Win32DiskImager to burn the Ubuntu Core Pi3 image > ubuntu-core-16-pi3.img to an SD card, > > booted the Pi3 connected to Ethernet, > > correctly get the “Press Enter to Configure” message, > > pass Network Config, > > entered my SSO account, > > got the ”Contacting Store” message, > > got the success reply back from the store saying the key had been stored on > the Pi and I can use ssh @ > > Try to connect to pi over ssh as instructed, private key auth fails … > > Things I have tried: > > Different terminal emulators – putty; Remote Terminal; TokenShell/MD; > command line ssh from another Pi; forcing use of specific private key with > -I option > > Different SSH key pairs – known good pair that we use elsewhere; new keygen > generated keys with passphrase; new keygen generated keys without passphrase > > Different Pi’s – Work and home > > Different Ubuntu SSO accounts – created a new account from scratch, same > result. > > In desperation, I tried to load 16.04 LTS, and this was successful so I am > confident the kit (Pi, SD card, network connection) is good. > > Nothing I have tried makes any difference, the private key is never accepted > by the Ubuntu Core device. > > I am keen to investigate migrating our IoT product from Raspbian Lite to > Core, but can’t seem to get beyond step one ! > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 26486 bytes Desc: not available URL: From gregory.lutostanski at canonical.com Fri Feb 3 18:08:32 2017 From: gregory.lutostanski at canonical.com (Gregory Lutostanski) Date: Fri, 3 Feb 2017 12:08:32 -0600 Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: <004501d27e3b$d5467360$7fd35a20$@4dml.com> References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> <004501d27e3b$d5467360$7fd35a20$@4dml.com> Message-ID: Looks like somehow your editor broke up the lines with spaces (at 80 characters), so when you copied it into the textfield on https://launchpad.net/~/+editsshkeys it was broken at 80 characters. I would suggest removing the offending key and adding it again. To make sure it doesn't happen again, (on windows) I would open it with notepad and turn off word wrap and copy and paste to there again. If you have any issues, let me know what your launchpad id is. That way I can pull your public key and see if anything else makes sense. Hopefully that will sort you out! On Fri, Feb 3, 2017 at 10:37 AM, George Gundry wrote: > Hi Gregory, Luca & Mattias for your generous help. > > > > I was able to look at *user-data/*/.ssh/authorized_keys* (I mounted the > SD card in Windows using *ExtFS* from Paragon Software) > > > > The key does not look right – a space has been inserted after every 80 > characters ??? – see partial screenshot below. These space characters are > not present when I open the source *id_rsa.pub* in Sublime … > > > > > > Unfortunately, I can only mount the drive as read-only, so can’t make the > changes, save and try again L > > > > Clearly, you guys HAVE been able to work, and I have double checked > username and all other details – it’s driving me mad ! > > > > Regards, > > > > George > > > > *From:* snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces@ > lists.snapcraft.io] *On Behalf Of *Gregory Lutostanski > *Sent:* 03 February 2017 15:40 > *To:* Snapcraft > *Subject:* Re: Unable to ssh to RPi3 after initial configuration of > Ubuntu Core > > > > And since it is a rpi... you can just pop out the sdcard, and put in a > different computer and see which ssh-key is in the second-partition at > user-data/*/.ssh/authorized_keys if you are really curious (although > since you are on windows, reading that partition which is ext4 might be > more difficult). > > > > > > On Fri, Feb 3, 2017 at 9:25 AM, Luca Dionisi > wrote: > > Just a couple of hints. > > 1. Double check username. > It might be different than that of the email you use to signon at Ubuntu. > E.g. my mail is luca.dionisi at gmail.com while user on my RPi is > luca-dionisi. > > 2. Try flag "-v" with ssh. Check the id_rsa* files that it tries with. > > > > > > On Fri, Feb 3, 2017 at 4:08 PM, George Gundry > wrote: > > I followed the instructions here: > > https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 > > > > I have created a Ubuntu SSO account > > > > uploaded my SSH public key, > > > > used Win32DiskImager to burn the Ubuntu Core Pi3 image > > ubuntu-core-16-pi3.img to an SD card, > > > > booted the Pi3 connected to Ethernet, > > > > correctly get the “Press Enter to Configure” message, > > > > pass Network Config, > > > > entered my SSO account, > > > > got the ”Contacting Store” message, > > > > got the success reply back from the store saying the key had been stored > on > > the Pi and I can use ssh @ > > > > Try to connect to pi over ssh as instructed, private key auth fails … > > > > Things I have tried: > > > > Different terminal emulators – putty; Remote Terminal; TokenShell/MD; > > command line ssh from another Pi; forcing use of specific private key > with > > -I option > > > > Different SSH key pairs – known good pair that we use elsewhere; new > keygen > > generated keys with passphrase; new keygen generated keys without > passphrase > > > > Different Pi’s – Work and home > > > > Different Ubuntu SSO accounts – created a new account from scratch, same > > result. > > > > In desperation, I tried to load 16.04 LTS, and this was successful so I > am > > confident the kit (Pi, SD card, network connection) is good. > > > > Nothing I have tried makes any difference, the private key is never > accepted > > by the Ubuntu Core device. > > > > I am keen to investigate migrating our IoT product from Raspbian Lite to > > Core, but can’t seem to get beyond step one ! > > > > > > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 26486 bytes Desc: not available URL: From kyle.fazzari at canonical.com Fri Feb 3 19:11:56 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Fri, 3 Feb 2017 11:11:56 -0800 Subject: Generic Snap questions In-Reply-To: <4001728.f4fN6ktkGB@lincoln> References: <4001728.f4fN6ktkGB@lincoln> Message-ID: <2a9934c6-5f8b-631c-025f-88bf6e9a3e6f@canonical.com> On 02/03/2017 04:06 AM, Andrew Mason wrote: > Hi All, > I have been listening to Alan Pope plugging snaps for a while now on the LUP > podcast and decided to try it out by installing a popular snap on a remote VM. Hey, thanks for giving it a shot! > 1. This particular snap was a collection of used a combination of Apache httpd > + MySQL and a few other utilities. > > I presume that if I wanted to use something like nginx instead of apache and > MariaDB instead of mysql I would need to rebuild the snap my self ? Is the > source / build instructions (.yml file?) available in some form that I can > access? Yeah this really depends on the snap. Indeed, if the snap in question embeds these things, unless the snap itself supports swapping things out somehow, your best path may be to rebuild the snap yourself using the components you desire. Whether or not you can do this also depends on the snap, e.g. it may not be open source. Figuring that out and/or finding the snap sources is a bit of a challenge right now since nothing shows you that information[1]. > 2. This snap in particular seemed to be configured to listen on the IP address > of machine it was running on. As this was deployed in Azure the VM is deployed > with a private 10.x IP address and sits behind a foobarqux.cloudapp.net so it > was not possible to visit the IP address directly; I ended up using an SSH > tunnel to address this, but conceptually if I wanted to change a configuration > element like this, what is the correct way to do so ? That would also be up to the snap in question. snapd supports a configure hook[2] that the snap can implement to support such things, but implementing that hook (and what exactly can be changed with it) is still up to the snap. The snap could also expose such functionality with its own app, if the developer chose to do so. > 3. Say a bunch of people want their own instance of this snappified service. > How are / should additional instances handled from an installation perspective > ? > > Also how would multiple instances be configured with regards to TCP port > access ? I'm not 100% sure I understand this question. Snaps aren't per-user (they're installed system-wide), so if you're asking how multiple users on the same machine would install this snap, the answer is "they wouldn't" I suppose. Please clarify this question if I didn't answer it. > 4. There was some attempt by the package to install a Let's encrypt > certificate however that failed due (possibly) to the aforementioned IP > address issue.. > > Is there any provision to be able to execute certain parts of the post-install > / pre-install scripts like there is with a debian package ? i.e -reconfigure > > Assuming I am able to get a certificate manually...e.g I have an EV cert for > the domain; how would I go about installing the Certificate into my new snap. > > I understand they are mounted images but from my understanding these are read > only. Do I just mount -o remount,rw ? I'm afraid not. They're not only mounted read-only, they're squashfs images which by definition ARE read-only. You cannot write to them. However, if the snap in question is fetching certs from Let's Encrypt, it's not writing to the snap either-- it must be placing those in a writable area (e.g. /var/snap//current/). I see no reason why you can't do the same with your certs, but again: the snap in question must support this. For example, the Nextcloud snap in stable only supports generating self-signed certificates or fetching certificates from Let's Encrypt, but the one in candidate has support for adding custom ones. > 5. Prior to the installation of the aforementioned snap, I used UFW to add a > firewall restricting access to all but the SSH port. > > After installing this snap it did not seem to automatically open a port. Is > this the correct behaviour ? If I am building a snap of my own application how > would I go about informing the user that this additional task is necessary ? > Can I prompt them to perform this action ? Unless the snap has firewall access (available as an interface), it won't have permission to touch it. So no, in most cases, the snap will not automatically open a port in your firewall. This is a good thing, in my opinion! If you're building a snap of your own application, I assume this would be in its documentation (either online or available as a --help option). > If you have made it this far I really appreciate that you have taken the time > to consider the questions and any answers would be greatly valued. Thanks for reaching out! I hope I helped-- please ask for clarification where that isn't the case. [1]: https://bugs.launchpad.net/snappy/+bug/1624829 [2]: https://github.com/snapcore/snapd/wiki/hooks#configure -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From george.gundry at 4dml.com Fri Feb 3 20:03:09 2017 From: george.gundry at 4dml.com (George Gundry 4D) Date: Fri, 3 Feb 2017 20:03:09 +0000 (UTC) Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> <004501d27e3b$d5467360$7fd35a20$@4dml.com> Message-ID: That certainly sounds plausible Gregory !I'll give it a try over the weekend - thanks again for your help 😀Regards,George _____________________________ From: Gregory Lutostanski Sent: Friday, February 3, 2017 18:09 Subject: Re: Unable to ssh to RPi3 after initial configuration of Ubuntu Core To: Snapcraft Looks like somehow your editor broke up the lines with spaces (at 80 characters), so when you copied it into the textfield on https://launchpad.net/~/+editsshkeys it was broken at 80 characters. I would suggest removing the offending key and adding it again. To make sure it doesn't happen again, (on windows) I would open it with notepad and turn off word wrap and copy and paste to there again. If you have any issues, let me know what your launchpad id is. That way I can pull your public key and see if anything else makes sense. Hopefully that will sort you out! On Fri, Feb 3, 2017 at 10:37 AM, George Gundry wrote: Hi Gregory, Luca & Mattias for your generous help.   I was able to look at user-data/*/.ssh/authorized_keys (I mounted the SD card in Windows using ExtFS from Paragon Software)   The key does not look right – a space has been inserted after every 80 characters ??? – see partial screenshot below. These space characters are not present when I open the source id_rsa.pub in Sublime …     Unfortunately, I can only mount the drive as read-only, so can’t make the changes, save and try again L   Clearly, you guys HAVE been able to work, and I have double checked username and all other details – it’s driving me mad !   Regards,   George   From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Gregory Lutostanski Sent: 03 February 2017 15:40 To: Snapcraft Subject: Re: Unable to ssh to RPi3 after initial configuration of Ubuntu Core   And since it is a rpi... you can just pop out the sdcard, and put in a different computer and see which ssh-key is in the second-partition at user-data/*/.ssh/authorized_keys if you are really curious (although since you are on windows, reading that partition which is ext4 might be more difficult).     On Fri, Feb 3, 2017 at 9:25 AM, Luca Dionisi wrote: Just a couple of hints. 1. Double check username. It might be different than that of the email you use to signon at Ubuntu. E.g. my mail is luca.dionisi at gmail.com while user on my RPi is luca-dionisi. 2. Try flag "-v" with ssh. Check the id_rsa* files that it tries with. On Fri, Feb 3, 2017 at 4:08 PM, George Gundry wrote: > I followed the instructions here: > https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 > > I have created a Ubuntu SSO account > > uploaded my SSH public key, > > used Win32DiskImager to burn the Ubuntu Core Pi3 image > ubuntu-core-16-pi3.img to an SD card, > > booted the Pi3 connected to Ethernet, > > correctly get the “Press Enter to Configure” message, > > pass Network Config, > > entered my SSO account, > > got the ”Contacting Store” message, > > got the success reply back from the store saying the key had been stored on > the Pi and I can use ssh @ > > Try to connect to pi over ssh as instructed, private key auth fails … > > Things I have tried: > > Different terminal emulators – putty; Remote Terminal; TokenShell/MD; > command line ssh from another Pi; forcing use of specific private key with > -I option > > Different SSH key pairs – known good pair that we use elsewhere; new keygen > generated keys with passphrase; new keygen generated keys without passphrase > > Different Pi’s – Work and home > > Different Ubuntu SSO accounts – created a new account from scratch, same > result. > > In desperation, I tried to load 16.04 LTS, and this was successful so I am > confident the kit (Pi, SD card, network connection) is good. > > Nothing I have tried makes any difference, the private key is never accepted > by the Ubuntu Core device. > > I am keen to investigate migrating our IoT product from Raspbian Lite to > Core, but can’t seem to get beyond step one ! > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft   -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 26486 bytes Desc: not available URL: From luca.dionisi at gmail.com Fri Feb 3 20:04:19 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 3 Feb 2017 21:04:19 +0100 Subject: Where to save stuff (in snap-agnostic way) Message-ID: What is the best place to write (and read) a temporary FIFO file from a confined snap application? This is for simple IPC between 2 processes of the same snap. Before attempting to snap the application I was using a fixed filename in /tmp. Admittedly poor solution. The solution should be usable also with another packaging system. --Luca P.S. the problem with Vala library has been solved and I was able to make the snap work in devmode. Now I am trying to move from devmode to strict. From christian.dywan at canonical.com Fri Feb 3 21:19:02 2017 From: christian.dywan at canonical.com (Christian Dywan) Date: Fri, 03 Feb 2017 22:19:02 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: Message-ID: <168E0F67-D8A4-4B82-9329-5633E2C04CC5@canonical.com> Hey Luca, I'll suggest XDG_RUNTIME_DIR i.e. /var/run Regards, Cris Am 3. Februar 2017 21:04:19 MEZ schrieb Luca Dionisi : >What is the best place to write (and read) a temporary FIFO file from >a confined snap application? >This is for simple IPC between 2 processes of the same snap. >Before attempting to snap the application I was using a fixed filename >in /tmp. Admittedly poor solution. >The solution should be usable also with another packaging system. > >--Luca > >P.S. the problem with Vala library has been solved and I was able to >make the snap work in devmode. Now I am trying to move from devmode to >strict. > >-- >Snapcraft mailing list >Snapcraft at lists.snapcraft.io >Modify settings or unsubscribe at: >https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhall119 at ubuntu.com Fri Feb 3 21:41:05 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Fri, 3 Feb 2017 16:41:05 -0500 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <168E0F67-D8A4-4B82-9329-5633E2C04CC5@canonical.com> References: <168E0F67-D8A4-4B82-9329-5633E2C04CC5@canonical.com> Message-ID: <4839280b-0375-50e3-57ba-c95648146303@ubuntu.com> Be sure to use XDG_RUNTIME_DIR and not '/var/run' specifically, as XDG_RUNTIME_DIR is /run/user//snap./ in a snap's runtime. You may also need to create that directory before using it. Michael Hall mhall119 at ubuntu.com On 02/03/2017 04:19 PM, Christian Dywan wrote: > Hey Luca, > > I'll suggest XDG_RUNTIME_DIR i.e. /var/run > > Regards, > Cris > > Am 3. Februar 2017 21:04:19 MEZ schrieb Luca Dionisi > : > > What is the best place to write (and read) a temporary FIFO file from > a confined snap application? > This is for simple IPC between 2 processes of the same snap. > Before attempting to snap the application I was using a fixed filename > in /tmp. Admittedly poor solution. > The solution should be usable also with another packaging system. > > --Luca > > P.S. the problem with Vala library has been solved and I was able to > make the snap work in devmode. Now I am trying to move from devmode to > strict. > > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > > From joseph.wakeling at webdrake.net Fri Feb 3 23:17:30 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 4 Feb 2017 00:17:30 +0100 Subject: snapcraft 2.26 has been released In-Reply-To: References: Message-ID: On 03/02/17 12:57, Sergio Schvezov wrote: > Hello snapcrafters! > > We are pleased to announce the release of version `2.26` of snapcraft has been > released: > https://launchpad.net/snapcraft/+milestone/2.26 Congratulations! :-) > All the snapcraft specific asset handling has been moved to the `snap` directory > as the preferred location for the following: > > - `snapcraft.yaml` > - `setup/gui` > - `parts/plugins` ... and setup/license.txt too, I believe? Question: does this mean that the new location should be in snap/setup/license.txt or just snap/license.txt ... ? I assume the former, by analogy to https://snapcraft.io/docs/deprecation-notices/dn3 Thanks & best wishes, -- Joe From adam.stokes at canonical.com Sat Feb 4 02:13:44 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Sat, 04 Feb 2017 02:13:44 +0000 Subject: [ANN] conjure-up 2.1-beta5 Message-ID: Conjure-up is a power tool for getting started with big software. Conjure-up lets you summon up a big-software stack as a “spell” - a model of the stack, combined with extra know-how to get you from an installed stack to a fully usable one. Start using your big software instead of learning how to deploy it. This release brings in... wait for it... Trusty support! (special shoutout to Sergio and Kyle who've answered my many questions to get this product out the door) You can now run conjure-up which brings in the latest Juju 2.1 beta5 and makes use of the LXD snap (currently version 2.8). This is an exciting milestone as we've now bridged the gap and brought this technology to our longtime Trusty users. There is a small caveat that you have to make sure that your user is part of the LXD group and that you've rebooted your system to make use of the latest HWE kernel for use with snapd. So with that said please give this a try and report any and all bugs to https://github.com/conjure-up/conjure-up/issues To get started: $ sudo apt-get install snapd $ sudo groupadd lxd && sudo usermod -a -G lxd $USER $ sudo reboot $ sudo snap install conjure-up --classic --beta p.s. I am open to suggestions on how to better simplify this experience on Trusty. I do realize it is a couple of extra commands and a reboot before you can use conjure-up. p.s.s I still can not get bash completion working so anyone with some time to check out my snap setup https://github.com/conjure-up/conjure-up/tree/master/snap and provide any insight on what I may be missing would be much appreciated! http://conjure-up.i o Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Sat Feb 4 02:33:20 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Sat, 4 Feb 2017 10:33:20 +0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <4839280b-0375-50e3-57ba-c95648146303@ubuntu.com> References: <168E0F67-D8A4-4B82-9329-5633E2C04CC5@canonical.com> <4839280b-0375-50e3-57ba-c95648146303@ubuntu.com> Message-ID: Hi, I just tried it with my helloworld snap example. It shows: liuxg at liuxg:~/snappy/desktop/ss$ hello.env | grep XDG_RUNTIME XDG_RUNTIME_DIR=/run/user/1000/snap.hello When I tried to run it with: $ sudo snap run --shell hello.env Inside the shell, I find different variable for XDG_RUNTIME_DIR: # env | grep XDG_RUNTIME_DIR XDG_RUNTIME_DIR=/run/user/0/snap.hello I tried to create the above named dir /run/user/1000/snap.hello, but it is not accessible in the shell Thanks. On Sat, Feb 4, 2017 at 5:41 AM, Michael Hall wrote: > Be sure to use XDG_RUNTIME_DIR and not '/var/run' specifically, as > XDG_RUNTIME_DIR is /run/user//snap./ in a snap's > runtime. You may also need to create that directory before using it. > > Michael Hall > mhall119 at ubuntu.com > > On 02/03/2017 04:19 PM, Christian Dywan wrote: > > Hey Luca, > > > > I'll suggest XDG_RUNTIME_DIR i.e. /var/run > > > > Regards, > > Cris > > > > Am 3. Februar 2017 21:04:19 MEZ schrieb Luca Dionisi > > : > > > > What is the best place to write (and read) a temporary FIFO file from > > a confined snap application? > > This is for simple IPC between 2 processes of the same snap. > > Before attempting to snap the application I was using a fixed > filename > > in /tmp. Admittedly poor solution. > > The solution should be usable also with another packaging system. > > > > --Luca > > > > P.S. the problem with Vala library has been solved and I was able to > > make the snap work in devmode. Now I am trying to move from devmode > to > > strict. > > > > > > -- > > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > > gesendet. > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.arnold at canonical.com Sat Feb 4 02:40:24 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Fri, 3 Feb 2017 18:40:24 -0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <168E0F67-D8A4-4B82-9329-5633E2C04CC5@canonical.com> <4839280b-0375-50e3-57ba-c95648146303@ubuntu.com> Message-ID: <20170204024024.GA13677@hunt> On Sat, Feb 04, 2017 at 10:33:20AM +0800, XiaoGuo Liu wrote: > liuxg at liuxg:~/snappy/desktop/ss$ hello.env | grep XDG_RUNTIME > XDG_RUNTIME_DIR=/run/user/1000/snap.hello > $ sudo snap run --shell hello.env > # env | grep XDG_RUNTIME_DIR > XDG_RUNTIME_DIR=/run/user/0/snap.hello Your first command was run as a standard user, probably the first user installed on the system, since it is user 1000. Your second command was run as root via the sudo tool, thus you get a different directory. Every user's data should be stored in a place where it won't collide with other users, and root is no different in this case. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From xiaoguo.liu at canonical.com Sat Feb 4 02:47:32 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Sat, 4 Feb 2017 10:47:32 +0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <20170204024024.GA13677@hunt> References: <168E0F67-D8A4-4B82-9329-5633E2C04CC5@canonical.com> <4839280b-0375-50e3-57ba-c95648146303@ubuntu.com> <20170204024024.GA13677@hunt> Message-ID: Hi Seth, Thanks. You are right. I just created a new dir under the root, and I tried to access it, and it was successful this time. liuxg at liuxg:~/snappy/desktop$ sudo snap run --shell hello.env [sudo] password for liuxg: root at liuxg:/home/liuxg/snappy/desktop# cd /run/user/0/snap.hello root at liuxg:/run/user/0/snap.hello# ls Many thanks Best regards, XiaoGuo On Sat, Feb 4, 2017 at 10:40 AM, Seth Arnold wrote: > On Sat, Feb 04, 2017 at 10:33:20AM +0800, XiaoGuo Liu wrote: > > liuxg at liuxg:~/snappy/desktop/ss$ hello.env | grep XDG_RUNTIME > > XDG_RUNTIME_DIR=/run/user/1000/snap.hello > > $ sudo snap run --shell hello.env > > # env | grep XDG_RUNTIME_DIR > > XDG_RUNTIME_DIR=/run/user/0/snap.hello > > Your first command was run as a standard user, probably the first user > installed on the system, since it is user 1000. > > Your second command was run as root via the sudo tool, thus you get a > different directory. Every user's data should be stored in a place where > it won't collide with other users, and root is no different in this case. > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Sat Feb 4 08:42:43 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sat, 4 Feb 2017 09:42:43 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <168E0F67-D8A4-4B82-9329-5633E2C04CC5@canonical.com> <4839280b-0375-50e3-57ba-c95648146303@ubuntu.com> <20170204024024.GA13677@hunt> Message-ID: Thanks all for the answer. There's a catch, though. I just checked in a classic Ubuntu what the XDG_RUNTIME_DIR env is set to for root. And, surprise, it's not set. So, since my app has to run as root, it seems that I'll have to check this possibility too. --Luca On Sat, Feb 4, 2017 at 3:47 AM, XiaoGuo Liu wrote: > Hi Seth, > > Thanks. You are right. I just created a new dir under the root, and I tried > to access it, and it was successful this time. > > liuxg at liuxg:~/snappy/desktop$ sudo snap run --shell hello.env > [sudo] password for liuxg: > root at liuxg:/home/liuxg/snappy/desktop# cd /run/user/0/snap.hello > root at liuxg:/run/user/0/snap.hello# ls > > Many thanks > Best regards, > XiaoGuo > > On Sat, Feb 4, 2017 at 10:40 AM, Seth Arnold > wrote: >> >> On Sat, Feb 04, 2017 at 10:33:20AM +0800, XiaoGuo Liu wrote: >> > liuxg at liuxg:~/snappy/desktop/ss$ hello.env | grep XDG_RUNTIME >> > XDG_RUNTIME_DIR=/run/user/1000/snap.hello >> > $ sudo snap run --shell hello.env >> > # env | grep XDG_RUNTIME_DIR >> > XDG_RUNTIME_DIR=/run/user/0/snap.hello >> >> Your first command was run as a standard user, probably the first user >> installed on the system, since it is user 1000. >> >> Your second command was run as root via the sudo tool, thus you get a >> different directory. Every user's data should be stored in a place where >> it won't collide with other users, and root is no different in this case. >> >> Thanks >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > > > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From george.gundry at 4dml.com Sat Feb 4 10:39:53 2017 From: george.gundry at 4dml.com (George Gundry 4D) Date: Sat, 4 Feb 2017 10:39:53 +0000 (UTC) Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> <004501d27e3b$d5467360$7fd35a20$@4dml.com> Message-ID: Yep, that worked - now I can start the REAL work ... Thanks 🙏, George _____________________________From: George Gundry 4D Sent: Friday, February 3, 2017 20:04 Subject: Re: Unable to ssh to RPi3 after initial configuration of Ubuntu Core To: Snapcraft That certainly sounds plausible Gregory !I'll give it a try over the weekend - thanks again for your help 😀Regards,George _____________________________ From: Gregory Lutostanski Sent: Friday, February 3, 2017 18:09 Subject: Re: Unable to ssh to RPi3 after initial configuration of Ubuntu Core To: Snapcraft Looks like somehow your editor broke up the lines with spaces (at 80 characters), so when you copied it into the textfield on https://launchpad.net/~/+editsshkeys it was broken at 80 characters. I would suggest removing the offending key and adding it again. To make sure it doesn't happen again, (on windows) I would open it with notepad and turn off word wrap and copy and paste to there again. If you have any issues, let me know what your launchpad id is. That way I can pull your public key and see if anything else makes sense. Hopefully that will sort you out! On Fri, Feb 3, 2017 at 10:37 AM, George Gundry wrote: Hi Gregory, Luca & Mattias for your generous help.   I was able to look at user-data/*/.ssh/authorized_keys (I mounted the SD card in Windows using ExtFS from Paragon Software)   The key does not look right – a space has been inserted after every 80 characters ??? – see partial screenshot below. These space characters are not present when I open the source id_rsa.pub in Sublime …     Unfortunately, I can only mount the drive as read-only, so can’t make the changes, save and try again L   Clearly, you guys HAVE been able to work, and I have double checked username and all other details – it’s driving me mad !   Regards,   George   From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Gregory Lutostanski Sent: 03 February 2017 15:40 To: Snapcraft Subject: Re: Unable to ssh to RPi3 after initial configuration of Ubuntu Core   And since it is a rpi... you can just pop out the sdcard, and put in a different computer and see which ssh-key is in the second-partition at user-data/*/.ssh/authorized_keys if you are really curious (although since you are on windows, reading that partition which is ext4 might be more difficult).     On Fri, Feb 3, 2017 at 9:25 AM, Luca Dionisi wrote: Just a couple of hints. 1. Double check username. It might be different than that of the email you use to signon at Ubuntu. E.g. my mail is luca.dionisi at gmail.com while user on my RPi is luca-dionisi. 2. Try flag "-v" with ssh. Check the id_rsa* files that it tries with. On Fri, Feb 3, 2017 at 4:08 PM, George Gundry wrote: > I followed the instructions here: > https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3 > > I have created a Ubuntu SSO account > > uploaded my SSH public key, > > used Win32DiskImager to burn the Ubuntu Core Pi3 image > ubuntu-core-16-pi3.img to an SD card, > > booted the Pi3 connected to Ethernet, > > correctly get the “Press Enter to Configure” message, > > pass Network Config, > > entered my SSO account, > > got the ”Contacting Store” message, > > got the success reply back from the store saying the key had been stored on > the Pi and I can use ssh @ > > Try to connect to pi over ssh as instructed, private key auth fails … > > Things I have tried: > > Different terminal emulators – putty; Remote Terminal; TokenShell/MD; > command line ssh from another Pi; forcing use of specific private key with > -I option > > Different SSH key pairs – known good pair that we use elsewhere; new keygen > generated keys with passphrase; new keygen generated keys without passphrase > > Different Pi’s – Work and home > > Different Ubuntu SSO accounts – created a new account from scratch, same > result. > > In desperation, I tried to load 16.04 LTS, and this was successful so I am > confident the kit (Pi, SD card, network connection) is good. > > Nothing I have tried makes any difference, the private key is never accepted > by the Ubuntu Core device. > > I am keen to investigate migrating our IoT product from Raspbian Lite to > Core, but can’t seem to get beyond step one ! > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft   -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 26486 bytes Desc: not available URL: From ogra at ubuntu.com Sat Feb 4 10:43:57 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Sat, 04 Feb 2017 11:43:57 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: Message-ID: <1486205037.11948.2.camel@ubuntu.com> hi, Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: > What is the best place to write (and read) a temporary FIFO file from > a confined snap application? > This is for simple IPC between 2 processes of the same snap. > Before attempting to snap the application I was using a fixed > filename > in /tmp. Admittedly poor solution. > The solution should be usable also with another packaging system. > well ... in case of snaps /tmp is a private directory that only your snap can access so it is actually a good place for such stuff ... ... that said ... if you want to use it in other packaging systems where this is not the case it might indeed not be the best choice and using XDG_RUNTIME_DIR might be the better way, as others pointed out. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From mark at ubuntu.com Sat Feb 4 11:00:26 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 4 Feb 2017 11:00:26 +0000 Subject: Unable to ssh to RPi3 after initial configuration of Ubuntu Core In-Reply-To: References: <019001d27e2f$679a64e0$36cf2ea0$@4dml.com> <004501d27e3b$d5467360$7fd35a20$@4dml.com> Message-ID: On 04/02/17 10:39, George Gundry 4D wrote: > Yep, that worked - now I can start the REAL work ... :) Welcome aboard! One piece of unsolicited advice, I hope it's helpful. Ubuntu Core is a very tightly locked-down experience because it is designed for deployments of millions of devices with automated updates and little to no human involvement. It achieves that because every single piece of the system is a snap, which means that every piece can be updated on autopilot (because we can roll back too). But as a developer system, it means that it feels like you are totally locked down when you are logged into Ubuntu Core, because you are totally locked down. So two things are really useful to learn quickly. First, from a developer point of view thinking about how to publish your software to the device, the best journey is to start playing with snaps on a 'classic system', by which I mean a plain old Ubuntu desktop or server or VM. Your snaps can start unconfined ('classic confinement') and then evolve to live inside a rigorous security envelope, through devmode and ultimately strict confinement. We even see people making Ubuntu based devices that they plan to ship as classic (deb based) systems where their own app is a classic snap, because that's the fastest way for them to get into the market, and most familiar to their developers. But once you have a strict snap, you can ship on Ubuntu Core, and at scale that will dramatically reduce your operating costs in the field. Second, if you are on a pure-snap Ubuntu Core system, you can enable a classic-style container. This is called 'classic mode' on a Core device, and it lets you breathe a little if you have to do some work locally (like building code or otherwise). Essentially it's like having a special LXD container handy so you can work in a classic deb-based environment that's 'local' to your Ubuntu Core device. Enjoy, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Sat Feb 4 11:00:31 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sat, 4 Feb 2017 12:00:31 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <1486205037.11948.2.camel@ubuntu.com> References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: On Sat, Feb 4, 2017 at 11:43 AM, Oliver Grawert wrote: > hi, > Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: >> What is the best place to write (and read) a temporary FIFO file from >> a confined snap application? >> This is for simple IPC between 2 processes of the same snap. >> Before attempting to snap the application I was using a fixed >> filename >> in /tmp. Admittedly poor solution. >> The solution should be usable also with another packaging system. >> > well ... in case of snaps /tmp is a private directory that only your > snap can access so it is actually a good place for such stuff ... It's worse than that, Jim! Inside the snap environment I can write files and directories both in /tmp and in $XDG_RUNTIME_DIR. What I cannot do anywhere is create a FIFO. bash-4.3$ mkfifo a bash: /usr/bin/mkfifo: Permission denied What's the problem here? To be honest I should say that my tests have been conducted in LXD containers. I don't know if the situation holds true also in real machines. From luca.dionisi at gmail.com Sat Feb 4 11:02:53 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sat, 4 Feb 2017 12:02:53 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: Well, it seems that the problem is the userspace tool itself. bash-4.3$ mkfifo --help bash: /usr/bin/mkfifo: Permission denied On Sat, Feb 4, 2017 at 12:00 PM, Luca Dionisi wrote: > On Sat, Feb 4, 2017 at 11:43 AM, Oliver Grawert wrote: >> hi, >> Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: >>> What is the best place to write (and read) a temporary FIFO file from >>> a confined snap application? >>> This is for simple IPC between 2 processes of the same snap. >>> Before attempting to snap the application I was using a fixed >>> filename >>> in /tmp. Admittedly poor solution. >>> The solution should be usable also with another packaging system. >>> >> well ... in case of snaps /tmp is a private directory that only your >> snap can access so it is actually a good place for such stuff ... > > It's worse than that, Jim! > > Inside the snap environment I can write files and directories both in > /tmp and in $XDG_RUNTIME_DIR. > What I cannot do anywhere is create a FIFO. > > bash-4.3$ mkfifo a > bash: /usr/bin/mkfifo: Permission denied > > What's the problem here? > > To be honest I should say that my tests have been conducted in LXD > containers. I don't know if the situation holds true also in real > machines. From luca.dionisi at gmail.com Sat Feb 4 11:14:06 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sat, 4 Feb 2017 12:14:06 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: More in context: In a classic Ubuntu (but inside a LXD container) I run: ubuntu at thorough-bear:~$ hello-world.sh This gives me a bash inside a snap environment. There I run: bash-4.3$ mkfifo --help bash: /usr/bin/mkfifo: Permission denied If I run dmesg (outside the snap environment) it reports: [94156.909950] audit: type=1400 audit(1486206367.506:1768): apparmor="DENIED" operation="exec" namespace="root//lxd-thorough-bear_" profile="snap.hello-world.sh" name="/usr/bin/mkfifo" pid=7925 comm="bash" requested_mask="x" denied_mask="x" fsuid=101000 ouid=100000 [94156.910123] audit: type=1400 audit(1486206367.506:1769): apparmor="DENIED" operation="open" namespace="root//lxd-thorough-bear_" profile="snap.hello-world.sh" name="/usr/bin/mkfifo" pid=7925 comm="bash" requested_mask="r" denied_mask="r" fsuid=101000 ouid=100000 On Sat, Feb 4, 2017 at 12:02 PM, Luca Dionisi wrote: > Well, it seems that the problem is the userspace tool itself. > bash-4.3$ mkfifo --help > bash: /usr/bin/mkfifo: Permission denied > > On Sat, Feb 4, 2017 at 12:00 PM, Luca Dionisi wrote: >> On Sat, Feb 4, 2017 at 11:43 AM, Oliver Grawert wrote: >>> hi, >>> Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: >>>> What is the best place to write (and read) a temporary FIFO file from >>>> a confined snap application? >>>> This is for simple IPC between 2 processes of the same snap. >>>> Before attempting to snap the application I was using a fixed >>>> filename >>>> in /tmp. Admittedly poor solution. >>>> The solution should be usable also with another packaging system. >>>> >>> well ... in case of snaps /tmp is a private directory that only your >>> snap can access so it is actually a good place for such stuff ... >> >> It's worse than that, Jim! >> >> Inside the snap environment I can write files and directories both in >> /tmp and in $XDG_RUNTIME_DIR. >> What I cannot do anywhere is create a FIFO. >> >> bash-4.3$ mkfifo a >> bash: /usr/bin/mkfifo: Permission denied >> >> What's the problem here? >> >> To be honest I should say that my tests have been conducted in LXD >> containers. I don't know if the situation holds true also in real >> machines. From luca.dionisi at gmail.com Sat Feb 4 11:20:35 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sat, 4 Feb 2017 12:20:35 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: The results are the very same (apart for "namespace") on a real machine, so the LXD container shouldn't be the cause. On Sat, Feb 4, 2017 at 12:14 PM, Luca Dionisi wrote: > More in context: > > In a classic Ubuntu (but inside a LXD container) I run: > ubuntu at thorough-bear:~$ hello-world.sh > > This gives me a bash inside a snap environment. > There I run: > bash-4.3$ mkfifo --help > bash: /usr/bin/mkfifo: Permission denied > > If I run dmesg (outside the snap environment) it reports: > > [94156.909950] audit: type=1400 audit(1486206367.506:1768): apparmor="DENIED" > operation="exec" > namespace="root//lxd-thorough-bear_" > profile="snap.hello-world.sh" > name="/usr/bin/mkfifo" > pid=7925 > comm="bash" > requested_mask="x" > denied_mask="x" > fsuid=101000 > ouid=100000 > > [94156.910123] audit: type=1400 audit(1486206367.506:1769): apparmor="DENIED" > operation="open" > namespace="root//lxd-thorough-bear_" > profile="snap.hello-world.sh" > name="/usr/bin/mkfifo" > pid=7925 > comm="bash" > requested_mask="r" > denied_mask="r" > fsuid=101000 > ouid=100000 > > > > > On Sat, Feb 4, 2017 at 12:02 PM, Luca Dionisi wrote: >> Well, it seems that the problem is the userspace tool itself. >> bash-4.3$ mkfifo --help >> bash: /usr/bin/mkfifo: Permission denied >> >> On Sat, Feb 4, 2017 at 12:00 PM, Luca Dionisi wrote: >>> On Sat, Feb 4, 2017 at 11:43 AM, Oliver Grawert wrote: >>>> hi, >>>> Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: >>>>> What is the best place to write (and read) a temporary FIFO file from >>>>> a confined snap application? >>>>> This is for simple IPC between 2 processes of the same snap. >>>>> Before attempting to snap the application I was using a fixed >>>>> filename >>>>> in /tmp. Admittedly poor solution. >>>>> The solution should be usable also with another packaging system. >>>>> >>>> well ... in case of snaps /tmp is a private directory that only your >>>> snap can access so it is actually a good place for such stuff ... >>> >>> It's worse than that, Jim! >>> >>> Inside the snap environment I can write files and directories both in >>> /tmp and in $XDG_RUNTIME_DIR. >>> What I cannot do anywhere is create a FIFO. >>> >>> bash-4.3$ mkfifo a >>> bash: /usr/bin/mkfifo: Permission denied >>> >>> What's the problem here? >>> >>> To be honest I should say that my tests have been conducted in LXD >>> containers. I don't know if the situation holds true also in real >>> machines. From ogra at ubuntu.com Sat Feb 4 11:21:44 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Sat, 04 Feb 2017 12:21:44 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: <1486207304.11948.5.camel@ubuntu.com> hi, Am Samstag, den 04.02.2017, 12:02 +0100 schrieb Luca Dionisi: > > > well ... in case of snaps /tmp is a private directory that only > > > your > > > snap can access so it is actually a good place for such stuff ... > > It's worse than that, Jim! > > > > Inside the snap environment I can write files and directories both > > in > > /tmp and in $XDG_RUNTIME_DIR. > > What I cannot do anywhere is create a FIFO. > > aha ! i guess you are hitting  https://bugs.launchpad.net/snappy/+bug/1636540 probably jamie can give a statement where we stand with this... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From luca.dionisi at gmail.com Sat Feb 4 14:53:54 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sat, 4 Feb 2017 15:53:54 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <1486207304.11948.5.camel@ubuntu.com> References: <1486205037.11948.2.camel@ubuntu.com> <1486207304.11948.5.camel@ubuntu.com> Message-ID: Although I wouldn't spend too much on this IPC issue (the IPC task is needed only for a testing tool that I won't deploy anywhere) in order to go ahead I am going to explore other possibilities. I want to try with DBus. Do you know of anything DBus-related that will encounter issues in a snap environment? On Sat, Feb 4, 2017 at 12:21 PM, Oliver Grawert wrote: > hi, > Am Samstag, den 04.02.2017, 12:02 +0100 schrieb Luca Dionisi: >> > > well ... in case of snaps /tmp is a private directory that only >> > > your >> > > snap can access so it is actually a good place for such stuff ... >> > It's worse than that, Jim! >> > >> > Inside the snap environment I can write files and directories both >> > in >> > /tmp and in $XDG_RUNTIME_DIR. >> > What I cannot do anywhere is create a FIFO. >> > > > aha ! i guess you are hitting > https://bugs.launchpad.net/snappy/+bug/1636540 > > probably jamie can give a statement where we stand with this... > > ciao > oli > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From xiaoguo.liu at canonical.com Sun Feb 5 00:04:49 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Sun, 5 Feb 2017 08:04:49 +0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <1486205037.11948.2.camel@ubuntu.com> References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: Hi Oli, Does it mean all of the snaps have the same /tmp or each snap has its own /tmp? I am a little bit confused about this. Thanks & best regards, XiaoGuo On Sat, Feb 4, 2017 at 6:43 PM, Oliver Grawert wrote: > hi, > Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: > > What is the best place to write (and read) a temporary FIFO file from > > a confined snap application? > > This is for simple IPC between 2 processes of the same snap. > > Before attempting to snap the application I was using a fixed > > filename > > in /tmp. Admittedly poor solution. > > The solution should be usable also with another packaging system. > > > well ... in case of snaps /tmp is a private directory that only your > snap can access so it is actually a good place for such stuff ... > > ... that said ... if you want to use it in other packaging systems > where this is not the case it might indeed not be the best choice and > using XDG_RUNTIME_DIR might be the better way, as others pointed out. > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Sun Feb 5 00:19:39 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Sun, 5 Feb 2017 08:19:39 +0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: Sorry, I just found that each snap has its own "tmp" directory created in the /tmp directory of the system. I just created a file, and it looks like: root at liuxg:/tmp/snap.1000_snap.hello.fifo_TovLTW/tmp# ls anothefile Thanks & best regards, XiaoGuo On Sun, Feb 5, 2017 at 8:04 AM, XiaoGuo Liu wrote: > Hi Oli, > > Does it mean all of the snaps have the same /tmp or each snap has its own > /tmp? I am a little bit confused about this. > > Thanks & best regards, > XiaoGuo > > > > On Sat, Feb 4, 2017 at 6:43 PM, Oliver Grawert wrote: > >> hi, >> Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: >> > What is the best place to write (and read) a temporary FIFO file from >> > a confined snap application? >> > This is for simple IPC between 2 processes of the same snap. >> > Before attempting to snap the application I was using a fixed >> > filename >> > in /tmp. Admittedly poor solution. >> > The solution should be usable also with another packaging system. >> > >> well ... in case of snaps /tmp is a private directory that only your >> snap can access so it is actually a good place for such stuff ... >> >> ... that said ... if you want to use it in other packaging systems >> where this is not the case it might indeed not be the best choice and >> using XDG_RUNTIME_DIR might be the better way, as others pointed out. >> >> ciao >> oli >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > XiaoGuo, Liu > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From shuduo.sang at canonical.com Sun Feb 5 13:55:14 2017 From: shuduo.sang at canonical.com (Shuduo Sang) Date: Sun, 5 Feb 2017 21:55:14 +0800 Subject: please try my golang snap In-Reply-To: References: Message-ID: On Fri, Feb 3, 2017 at 4:52 PM, Shuduo Sang wrote: > Hi, > > I got following output after run it: > > $ go-17-mwhudson.go-17 > /snap/go-17-mwhudson/2/gowrapper: line 3: /snap/go-17-mwhudson/2/bin/go: > No such file or directory > > My snap version is: > $ snap version > snap 2.21 > snapd 2.21 > series 16 > ubuntu 16.04 > > Please let me know what mistake I have. > UPDATE: I notice the go binary is referred to library from /snap/core $ file /snap/go-17-mwhudson/current/bin/go /snap/go-17-mwhudson/current/bin/go: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /snap/core/current/lib/x86_64-linux-gnu/ld-2.23.so, for GNU/Linux 2.6.32, BuildID[sha1]=3e694c21430e17b6bba99bd1828696a784ffab8a, not stripped But I have /snap/ubuntu-core only. After refresh ubuntu-core from candidate channel then it transit to /snap/core now go-17 works well. Thanks zyga's help. > > Thanks, > > > > On Fri, Feb 3, 2017 at 4:39 AM, Michael Hudson-Doyle < > michael.hudson at canonical.com> wrote: > >> Prompted by some upstream discussion, I've made a snap of Go (just 1.7.4 >> for now): >> >> $ sudo snap install --edge --classic go-17-mwhudson >> >> It has aliases for go-17 (which will probably be the final snap of the >> snap if this ends up being official) and go (the thinking being that there >> will also be go-16, go-18 etc snaps and users can select which they use by >> selecting an alias). >> >> The source is at https://code.launchpad.net/ >> ~mwhudson/+git/gosnap/+ref/master. >> >> Please let me know how this works for you! >> >> Cheers, >> mwh >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Sun Feb 5 14:13:34 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 5 Feb 2017 15:13:34 +0100 Subject: Using docker for clean builds of classic snaps In-Reply-To: References: Message-ID: <57d53a1f-72e4-5202-9bed-008beff6ebef@webdrake.net> On 02/02/17 22:35, Loïc Minier wrote: > There are a bunch of Docker images providing snapcraft > , > unfortunately they are all behind. These should be autobuilt instead of manually > updated, in the mean time I suggest you build your own (relatively easy) > . Otherwise, > Didier's image is only a > month old and should include a snapcraft with experimental support for classic > snaps. Thanks Loïc :-) Images like the ones you point to match pretty much what I came up with myself, but I ran into difficulties installing the core snap (required for building classic snaps). My Dockerfile was as follows: ################################################## FROM ubuntu:16.04 RUN apt-get update RUN apt-get --assume-yes dist-upgrade RUN apt-get --assume-yes install snapd snapcraft RUN snap install core ################################################## ... and when building the image, it would fall over at the last step: Step 5/5 : RUN snap install core ---> Running in fb52514fbd30 2017/02/05 13:59:56.811387 main.go:220: WARNING: cannot create syslog logger error: cannot communicate with server: Post http://localhost/v2/snaps/core: dial unix /run/snapd-snap.socket: connect: no such file or directory I would get a similar error if I tried deleting the last line of the Dockerfile but running `snap install core` manually in the container: $ sudo docker run -v $PWD:$PWD -w $PWD [my-image-id] snap install core && snapcraft clean && snapcraft 2017/02/05 14:07:35.998824 main.go:220: WARNING: cannot create syslog logger error: cannot communicate with server: Post http://localhost/v2/snaps/core: dial unix /run/snapd-snap.socket: connect: no such file or directory I presume I'm missing something here in terms of setting up sockets for the image/container? Thanks & best wishes, -- Joe From fnatter at gmx.net Sun Feb 5 16:58:10 2017 From: fnatter at gmx.net (Felix Natter) Date: Sun, 05 Feb 2017 17:58:10 +0100 Subject: Gradle Plugin / dump plugin with jre dependency In-Reply-To: <1483036795.3265.2@smtp.gmail.com> (Matthew Aguirre's message of "Thu, 29 Dec 2016 13:39:55 -0500") References: <878tqz9iel.fsf@bitburger.home.felix> <1483031171.3265.0@smtp.gmail.com> <1483031870.3265.1@smtp.gmail.com> <1483036795.3265.2@smtp.gmail.com> Message-ID: <87vasowp5p.fsf@bitburger.home.felix> hello Matthew, I apologize for the very late reply. Many thanks for the gradle.py patch! Matthew Aguirre writes: > Here's a snap + wrapper that seems to work. > It's really messy as it copies the contents of freeplane twice. > https://gist.github.com/ZenHarbinger/cf3aec2d7c6110ab0a0780b315cadc2f Thanks, the wrapper works perfectly! I have got one more question: It looks like with your stage-packages: or with the jdk plugin, the whole jdk is included in the snap, so it is 108Mb (freeplane needs "only" 30Mb). Is there a way (plug/interface) for using the system jdk? I guess I would have to give up sandboxing for this to work. This would be ok [1], because I'm most interested in a normal package, backported to older (i.e. LTS) Debian/Ubuntu versions. (I provide a .deb for Debian main but I want to provide the most current version also for LTS versions) [1] Freeplane can execute scripts contained in maps, but it has its own security layer for containment of scripts. I guess this is not what snap is for and the best way to achieve this is by using a normal but non-main deb, with all jars included? Many Thanks, -- Felix Natter From matt.aguirre at gmail.com Sun Feb 5 17:04:01 2017 From: matt.aguirre at gmail.com (Matthew Aguirre) Date: Sun, 5 Feb 2017 12:04:01 -0500 Subject: Gradle Plugin / dump plugin with jre dependency In-Reply-To: <87vasowp5p.fsf@bitburger.home.felix> References: <878tqz9iel.fsf@bitburger.home.felix> <1483031171.3265.0@smtp.gmail.com> <1483031870.3265.1@smtp.gmail.com> <1483036795.3265.2@smtp.gmail.com> <87vasowp5p.fsf@bitburger.home.felix> Message-ID: Unfortunately, to get the Java dependencies, this is the only way to get them. Snapd doesn't have Java, so it must come in the snap. On Feb 5, 2017 11:58 AM, "Felix Natter" wrote: > hello Matthew, > > I apologize for the very late reply. > > Many thanks for the gradle.py patch! > > Matthew Aguirre writes: > > Here's a snap + wrapper that seems to work. > > It's really messy as it copies the contents of freeplane twice. > > https://gist.github.com/ZenHarbinger/cf3aec2d7c6110ab0a0780b315cadc2f > > Thanks, the wrapper works perfectly! > > I have got one more question: > It looks like with your stage-packages: or with the jdk plugin, > the whole jdk is included in the snap, so it is 108Mb (freeplane needs > "only" 30Mb). Is there a way (plug/interface) for using the system jdk? > > I guess I would have to give up sandboxing for this to work. > This would be ok [1], because I'm most interested in a normal package, > backported to older (i.e. LTS) Debian/Ubuntu versions. > (I provide a .deb for Debian main but I want to provide the most current > version also for LTS versions) > > [1] Freeplane can execute scripts contained in maps, but it has its own > security layer for containment of scripts. > > I guess this is not what snap is for and the best way to achieve this is > by using a normal but non-main deb, with all jars included? > > Many Thanks, > -- > Felix Natter > -------------- next part -------------- An HTML attachment was scrubbed... URL: From loic.minier at ubuntu.com Sun Feb 5 18:33:11 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Sun, 5 Feb 2017 19:33:11 +0100 Subject: Using docker for clean builds of classic snaps In-Reply-To: <57d53a1f-72e4-5202-9bed-008beff6ebef@webdrake.net> References: <57d53a1f-72e4-5202-9bed-008beff6ebef@webdrake.net> Message-ID: Hi Joseph, On Sun, Feb 5, 2017 at 3:13 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > $ sudo docker run -v $PWD:$PWD -w $PWD [my-image-id] snap install core && > snapcraft clean && snapcraft > 2017/02/05 14:07:35.998824 main.go:220: WARNING: cannot create syslog > logger > error: cannot communicate with server: Post http://localhost/v2/snaps/core: > dial unix /run/snapd-snap.socket: connect: no such file or directory > I dont think "snapd" is in the "ubuntu" Docker image which is trimmed down a bit; it's also likely that snapd/snaps would hit some technical issues when inside Docker. (This might be worth researching/debugging if you're tempted.) Cheers, - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Sun Feb 5 22:51:41 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 5 Feb 2017 23:51:41 +0100 Subject: Using docker for clean builds of classic snaps In-Reply-To: References: <57d53a1f-72e4-5202-9bed-008beff6ebef@webdrake.net> Message-ID: On 05/02/17 19:33, Loïc Minier wrote: > I dont think "snapd" is in the "ubuntu" Docker image which is trimmed down a > bit Yes, I gathered that much, which is why my own Dockerfile attempt ensured that snapd would be installed with this line: RUN apt-get --assume-yes install snapd snapcraft ... but as you say: > it's also likely that snapd/snaps would hit some technical issues when > inside Docker. (This might be worth researching/debugging if you're tempted.) It looks to me like the snapd daemon doesn't actually run inside the container. If I try something simple like checking the version of snapd installed, then I get this output: $ sudo docker run -v $PWD:$PWD -w $PWD 592f87a670d0 snap --version 2017/02/05 22:43:59.308309 main.go:220: WARNING: cannot create syslog logger snap 2.21 snapd unavailable series - ... so it's clearly installed in my custom image, but not started. If I _do_ try starting it as part of the command to run in the container, I get the following: $ sudo docker run -v $PWD:$PWD -w $PWD 592f87a670d0 systemctl enable --now snapd.socket && snap install core && snapcraft clean && snapcraft error: access denied (try with sudo) Trying `sudo` (as in `sudo systemctl enable ...`) doesn't seem to make any difference. Any thoughts on what else I could try? I'm happy to keep exploring myself but Docker and sockets aren't really my area of expertise. I would imagine, though, that the kinds of issues I'm running into with Docker are fundamentally the same issues that make it hard for classic snaps to support `snapcraft cleanbuild` using lxd ... ? Thanks & best wishes, -- Joe From sergio.schvezov at canonical.com Sun Feb 5 23:00:14 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 05 Feb 2017 20:00:14 -0300 Subject: snapcraft 2.26 has been released In-Reply-To: References: Message-ID: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> El viernes, 3 de febrero de 2017 20h'17:30 ART, Joseph Rushton Wakeling escribió: > On 03/02/17 12:57, Sergio Schvezov wrote: >> Hello snapcrafters! >> >> We are pleased to announce the release of version `2.26` of >> snapcraft has been >> released: >> https://launchpad.net/snapcraft/+milestone/2.26 > > Congratulations! :-) > >> All the snapcraft specific asset handling has been moved to >> the `snap` directory >> as the preferred location for the following: >> >> - `snapcraft.yaml` >> - `setup/gui` >> - `parts/plugins` > > ... and setup/license.txt too, I believe? > > Question: does this mean that the new location should be in > snap/setup/license.txt or just snap/license.txt ... ? I assume > the former, by > analogy to > https://snapcraft.io/docs/deprecation-notices/dn3 Where did you see this documented? We removed all traces of license.txt from our documentation months ago as snapd made no use of it. That said you are free to drop license file inside the snap wherever you want. -- Enviado con Dekko desde mi dispositivo Ubuntu From sergio.schvezov at canonical.com Sun Feb 5 23:02:11 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 05 Feb 2017 20:02:11 -0300 Subject: [ANN] conjure-up 2.1-beta5 In-Reply-To: Message-ID: <3b854bdc-8a8f-4384-bc9a-043cd849c925@canonical.com> Was fun to put all the pieces together. Anyone else getting stuck or need guidance on classic confined snaps feel free to drop by our rocket channel. El viernes, 3 de febrero de 2017 23h'13:44 ART, Adam Stokes escribió: > Conjure-up is a power tool for getting started with big software. > > Conjure-up lets you summon up a big-software stack as a “spell” - a model > of the stack, combined with extra know-how to get you from an installed > stack to a fully usable one. Start using your big software instead of > learning how to deploy it. > > This release brings in... wait for it... Trusty support! (special shoutout > to Sergio and Kyle who've answered my many questions to get this product > out the door) > > You can now run conjure-up which brings in the latest Juju 2.1 beta5 and > makes use of the LXD snap (currently version 2.8). This is an exciting > milestone as we've now bridged the gap and brought this technology to our > longtime Trusty users. > > There is a small caveat that you have to make sure that your user is part > of the LXD group and that you've rebooted your system to make use of the > latest HWE kernel for use with snapd. > > So with that said please give this a try and report any and all bugs to > https://github.com/conjure-up/conjure-up/issues > > To get started: > > $ sudo apt-get install snapd > $ sudo groupadd lxd && sudo usermod -a -G lxd $USER > $ sudo reboot > > $ sudo snap install conjure-up --classic --beta > > p.s. I am open to suggestions on how to better simplify this experience on > Trusty. I do realize it is a couple of extra commands and a reboot before > you can use conjure-up. > p.s.s I still can not get bash completion working so anyone with some time > to check out my snap setup > https://github.com/conjure-up/conjure-up/tree/master/snap and provide any > insight on what I may be missing would be much appreciated! > > http://conjure-up.i o > Adam > -- Enviado con Dekko desde mi dispositivo Ubuntu From joseph.wakeling at webdrake.net Sun Feb 5 23:04:32 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 6 Feb 2017 00:04:32 +0100 Subject: snapcraft 2.26 has been released In-Reply-To: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> Message-ID: On 06/02/17 00:00, Sergio Schvezov wrote: > Where did you see this documented? We removed all traces of license.txt from our > documentation months ago as snapd made no use of it. That said you are free to > drop license file inside the snap wherever you want. I didn't see it documented anywhere -- I was asking if it was the case (sorry if it wasn't clear) because snapcraft 2.26 kept giving me the deprecation message until I moved it from `setup/license.txt` to `snap/setup/license.txt`. Presumably it was the existence of the `setup` dir it was objecting to, regardless of contents? From joseph.wakeling at webdrake.net Sun Feb 5 23:16:02 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 6 Feb 2017 00:16:02 +0100 Subject: snapcraft 2.26 has been released In-Reply-To: References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> Message-ID: <619a3daf-2274-f9d3-8715-1b7a5dd64aea@webdrake.net> On 06/02/17 00:04, Joseph Rushton Wakeling wrote: > On 06/02/17 00:00, Sergio Schvezov wrote: >> Where did you see this documented? We removed all traces of license.txt from our >> documentation months ago as snapd made no use of it. That said you are free to >> drop license file inside the snap wherever you want. > > I didn't see it documented anywhere -- I was asking if it was the case (sorry if > it wasn't clear) because snapcraft 2.26 kept giving me the deprecation message > until I moved it from `setup/license.txt` to `snap/setup/license.txt`. > > Presumably it was the existence of the `setup` dir it was objecting to, > regardless of contents? BTW if it's not clear why I had `license.txt` in the setup directory: as far as I recall, there was a deprecation message a few releases back that asked for it to be moved from the root dir of the snap package definition to the `setup/` dir. But I suppose it's possible I misunderstood something at that point. From xiaoguo.liu at canonical.com Mon Feb 6 00:15:45 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 6 Feb 2017 08:15:45 +0800 Subject: Snap icon in the Ubuntu Store Message-ID: Hi, I am a little confused about the snap icon in the store. According to the document at: https://snapcraft.io/docs/build-snaps/metadata A package icon is defined by the "icon" field in the snapcraft.yaml. However, my own project at: https://github.com/liu-xiao-guo/ss-qt does not have the "icon" field, and it can be found at: https://uappexplorer.com/app/ss-qt.xiaoguo However, after installation on my desktop, in the snapweb, it does show an snap icon for it. Why is it like this? For some of the apps, if I do not have the icon field defined, it does not show the snap icon in the snapweb at all. Attached please find the picture for it. Thanks & best regards, XiaoGuo -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Selection_085.png Type: image/png Size: 123239 bytes Desc: not available URL: From xiaoguo.liu at canonical.com Mon Feb 6 00:46:35 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 6 Feb 2017 08:46:35 +0800 Subject: Snap icon in the Ubuntu Store In-Reply-To: References: Message-ID: I just found another problem with snapweb. If I change the icon to another picture in the snapcraft.yaml file, after new installation, the package icon in the snapweb is not updated, and the old one is still used. Is this a bug? Thanks & best regards, XiaoGuo On Mon, Feb 6, 2017 at 8:15 AM, XiaoGuo Liu wrote: > Hi, > > I am a little confused about the snap icon in the store. According to the > document at: > > https://snapcraft.io/docs/build-snaps/metadata > > A package icon is defined by the "icon" field in the snapcraft.yaml. > However, my own project at: > > https://github.com/liu-xiao-guo/ss-qt > > does not have the "icon" field, and it can be found at: > > https://uappexplorer.com/app/ss-qt.xiaoguo > > However, after installation on my desktop, in the snapweb, it does show an > snap icon for it. Why is it like this? For some of the apps, if I do not > have the icon field defined, it does not show the snap icon in the snapweb > at all. > > Attached please find the picture for it. > > Thanks & best regards, > XiaoGuo > > > -- > XiaoGuo, Liu > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From michi.henning at canonical.com Mon Feb 6 02:24:01 2017 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 6 Feb 2017 12:24:01 +1000 Subject: Max retries exceeded? Message-ID: I keep getting this error when doing a snapcraft cleanbuild. Any suggestions? I checked name resolution, and my DNS resolves parts.snapcraft.io just fine. Thanks, Michi. Setting up python3-lxml (3.5.0-1build1) ... Setting up python3-petname (2.0-0ubuntu1~16.04) ... Setting up python3-progressbar (2.3-2) ... Setting up python3-pymacaroons (0.9.2-0ubuntu1) ... Setting up python3-requests-toolbelt (0.6.0-2) ... Setting up python3-simplejson (3.8.1-1ubuntu2) ... Setting up python3-tabulate (0.7.5-1) ... Setting up python3-xdg (0.25-4) ... Setting up xdelta3 (3.0.8-dfsg-1ubuntu2) ... Setting up python3-libarchive-c (2.1-3) ... Setting up python3-magic (1:5.25-2ubuntu1) ... Setting up snapcraft (2.26) ... Processing triggers for libc-bin (2.23-0ubuntu5) ... HTTPSConnectionPool(host='parts.snapcraft.io', port=443): Max retries exceeded with url: /v1/parts.yaml (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',)) Stopping snapcraft-merely-model-ewe Command '['lxc', 'exec', 'snapcraft-merely-model-ewe', '--', 'snapcraft', 'snap', '--output', 'thumbnailer_2.4_amd64.snap']' returned non-zero exit status 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.nelson at canonical.com Mon Feb 6 03:47:30 2017 From: michael.nelson at canonical.com (Michael Nelson) Date: Mon, 06 Feb 2017 03:47:30 +0000 Subject: Max retries exceeded? In-Reply-To: References: Message-ID: On Mon, Feb 6, 2017 at 1:25 PM Michi Henning wrote: > I keep getting this error when doing a snapcraft cleanbuild. Any > suggestions? I checked name resolution, and my DNS resolves > parts.snapcraft.io just fine. > > Hi Michi Have you verified your DNS resolution and/or curling from within your container? That is: > Thanks, > > Michi. > > Setting up python3-lxml (3.5.0-1build1) ... > Setting up python3-petname (2.0-0ubuntu1~16.04) ... > Setting up python3-progressbar (2.3-2) ... > Setting up python3-pymacaroons (0.9.2-0ubuntu1) ... > Setting up python3-requests-toolbelt (0.6.0-2) ... > Setting up python3-simplejson (3.8.1-1ubuntu2) ... > Setting up python3-tabulate (0.7.5-1) ... > Setting up python3-xdg (0.25-4) ... > Setting up xdelta3 (3.0.8-dfsg-1ubuntu2) ... > Setting up python3-libarchive-c (2.1-3) ... > Setting up python3-magic (1:5.25-2ubuntu1) ... > Setting up snapcraft (2.26) ... > Processing triggers for libc-bin (2.23-0ubuntu5) ... > HTTPSConnectionPool(host='parts.snapcraft.io', port=443): Max retries exceeded with url: /v1/parts.yaml (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',)) > Stopping snapcraft-merely-model-ewe > Command '['lxc', 'exec', 'snapcraft-merely-model-ewe', '--', 'snapcraft', 'snap', '--output', 'thumbnailer_2.4_amd64.snap']' returned non-zero exit status 1 > > > Can you try: $ lxc exec snapcraft-merely-model-ewe -- curl https://parts.snapcraft.io/v1/parts.yaml ? I can only confirm that curling that from various machines here responds fine (and that there haven't been any alerts for that service for the past day). Thanks -Michael > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.henstridge at canonical.com Mon Feb 6 04:14:56 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Mon, 6 Feb 2017 12:14:56 +0800 Subject: Max retries exceeded? In-Reply-To: References: Message-ID: On 6 February 2017 at 11:47, Michael Nelson wrote: > On Mon, Feb 6, 2017 at 1:25 PM Michi Henning > wrote: >> >> I keep getting this error when doing a snapcraft cleanbuild. Any >> suggestions? I checked name resolution, and my DNS resolves >> parts.snapcraft.io just fine. >> > > Hi Michi > > Have you verified your DNS resolution and/or curling from within your > container? That is: > >> >> Thanks, >> >> Michi. >> >> Setting up python3-lxml (3.5.0-1build1) ... >> Setting up python3-petname (2.0-0ubuntu1~16.04) ... >> Setting up python3-progressbar (2.3-2) ... >> Setting up python3-pymacaroons (0.9.2-0ubuntu1) ... >> Setting up python3-requests-toolbelt (0.6.0-2) ... >> Setting up python3-simplejson (3.8.1-1ubuntu2) ... >> Setting up python3-tabulate (0.7.5-1) ... >> Setting up python3-xdg (0.25-4) ... >> Setting up xdelta3 (3.0.8-dfsg-1ubuntu2) ... >> Setting up python3-libarchive-c (2.1-3) ... >> Setting up python3-magic (1:5.25-2ubuntu1) ... >> Setting up snapcraft (2.26) ... >> Processing triggers for libc-bin (2.23-0ubuntu5) ... >> HTTPSConnectionPool(host='parts.snapcraft.io', port=443): Max retries >> exceeded with url: /v1/parts.yaml (Caused by >> NewConnectionError('> object at 0x7f5537c29ba8>: Failed to establish a new connection: [Errno -3] >> Temporary failure in name resolution',)) >> Stopping snapcraft-merely-model-ewe >> Command '['lxc', 'exec', 'snapcraft-merely-model-ewe', '--', 'snapcraft', >> 'snap', '--output', 'thumbnailer_2.4_amd64.snap']' returned non-zero exit >> status 1 >> >> > > Can you try: > $ lxc exec snapcraft-merely-model-ewe -- curl > https://parts.snapcraft.io/v1/parts.yaml > > ? I can only confirm that curling that from various machines here responds > fine (and that there haven't been any alerts for that service for the past > day). I was able to reproduce Michi's result. I reran the command as "snapcraft cleanbuild -d", which drops to a shell within the container on the failure. Using "getent hosts $hostname", I can get an IP address for archive.ubuntu.com, but not parts.snapcraft.io. Running strace, I disected the DNS communication here: http://paste.ubuntu.com/23938750/ -- it is performing a query with recursion desired, but the response only comes back with the CNAME record and no A records. If I perform the same request against Google's public DNS (8.8.8.8), I get the CNAME and a bunch of A records. I'm guessing this is coming from the system resolver on the host system. I'm on zesty, so this could be a systemd-resolve problem. James. From michi.henning at canonical.com Mon Feb 6 04:17:40 2017 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 6 Feb 2017 14:17:40 +1000 Subject: Max retries exceeded? In-Reply-To: References: Message-ID: > I'm guessing this is coming from the system resolver on the host > system. I'm on zesty, so this could be a systemd-resolve problem. I’m seeing this on xenial + overlay. Michi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michi.henning at canonical.com Mon Feb 6 04:43:08 2017 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 6 Feb 2017 14:43:08 +1000 Subject: Max retries exceeded? In-Reply-To: References: Message-ID: > Can you try: > $ lxc exec snapcraft-merely-model-ewe -- curl https://parts.snapcraft.io/v1/parts.yaml > > ? I can only confirm that curling that from various machines here responds fine (and that there haven't been any alerts for that service for the past day). I rebooted meantime, and the problem magically disappeared :-( Michi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fazzari at canonical.com Mon Feb 6 05:42:46 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Sun, 5 Feb 2017 21:42:46 -0800 Subject: Snap icon in the Ubuntu Store In-Reply-To: References: Message-ID: Any chance the snap in question has an icon set store side? I believe the one in the store takes precedence over the one in the snap itself. Kyle On Feb 5, 2017 4:47 PM, "XiaoGuo Liu" wrote: > I just found another problem with snapweb. If I change the icon to another > picture in the snapcraft.yaml file, after new installation, the package > icon in the snapweb is not updated, and the old one is still used. Is this > a bug? > > Thanks & best regards, > XiaoGuo > > On Mon, Feb 6, 2017 at 8:15 AM, XiaoGuo Liu > wrote: > >> Hi, >> >> I am a little confused about the snap icon in the store. According to the >> document at: >> >> https://snapcraft.io/docs/build-snaps/metadata >> >> A package icon is defined by the "icon" field in the snapcraft.yaml. >> However, my own project at: >> >> https://github.com/liu-xiao-guo/ss-qt >> >> does not have the "icon" field, and it can be found at: >> >> https://uappexplorer.com/app/ss-qt.xiaoguo >> >> However, after installation on my desktop, in the snapweb, it does show >> an snap icon for it. Why is it like this? For some of the apps, if I do not >> have the icon field defined, it does not show the snap icon in the snapweb >> at all. >> >> Attached please find the picture for it. >> >> Thanks & best regards, >> XiaoGuo >> >> >> -- >> XiaoGuo, Liu >> > > > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michi.henning at canonical.com Mon Feb 6 06:53:16 2017 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 6 Feb 2017 16:53:16 +1000 Subject: Package too old for cleanbuild Message-ID: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> I’m trying to get thumbnailer to build with snapcraft cleanbuild. We depend on cmake-extras for the build. I’ve added that to the build-packages list. The version of cmake that gets installed is 0.6, but we need the latest 1.0. Is it possible to add the overlay PPA to cleanbuild somehow? If not, we’d have to SRU cmake-extras I guess? Not sure about the correct process here… Thanks, Michi. From spencertparkin at gmail.com Mon Feb 6 07:05:47 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Mon, 6 Feb 2017 00:05:47 -0700 Subject: Reject snaps that are identical to previous revision? Message-ID: So, I'm sure it comes as no surprise to the readers of this mailing list that I am a complete moron; and as further evidence of that, I recently uploaded a "new" snap that was actually identical to the revision I already had released to my victu...I mean, customers. Does it seem reasonable for the automated snap vetting process to reject the snap or at least warn me about it in the event that it hashes to the exact same hash as that of the previous release? It's just an idea that I thought I might throw out there. Cheers. Beers. And chocolate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.mardegan at canonical.com Mon Feb 6 07:30:18 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Mon, 6 Feb 2017 10:30:18 +0300 Subject: Package too old for cleanbuild In-Reply-To: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: On 06/02/2017 09:53, Michi Henning wrote: > I’m trying to get thumbnailer to build with snapcraft cleanbuild. > > We depend on cmake-extras for the build. I’ve added that to the build-packages list. The version of cmake that gets installed is 0.6, but we need the latest 1.0. > > Is it possible to add the overlay PPA to cleanbuild somehow? If not, we’d have to SRU cmake-extras I guess? A bit hijacking the thread, but: Would it make sense to extend the snapcraft yaml to let the developer specify where build-packages and stage-packages should be taken from? It would be nice to be able to run a "snapcraft cleanbuild" from zesty while effectively using all the packages from xenial+overlay... :-) Ciao, Alberto From michi.henning at canonical.com Mon Feb 6 07:46:10 2017 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 6 Feb 2017 17:46:10 +1000 Subject: Package too old for cleanbuild In-Reply-To: References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: > Would it make sense to extend the snapcraft yaml to let the developer > specify where build-packages and stage-packages should be taken from? > > It would be nice to be able to run a "snapcraft cleanbuild" from zesty > while effectively using all the packages from xenial+overlay... :-) That certainly would be nice, yes. It would also be awesome to be able to point apt inside the container at my apt-cacher-ng cache. As is, every failed attempt to do a cleanbuild downloads ~150 MB and, on a 3 Mbit link, takes 10-15 minutes. For development and debugging, we really need something like this. As is, it’s unbelievably painful. Michi. From geoffroy.vancutsem at intel.com Mon Feb 6 08:16:17 2017 From: geoffroy.vancutsem at intel.com (VanCutsem, Geoffroy) Date: Mon, 6 Feb 2017 08:16:17 +0000 Subject: Using docker for clean builds of classic snaps In-Reply-To: References: <57d53a1f-72e4-5202-9bed-008beff6ebef@webdrake.net> Message-ID: > -----Original Message----- > From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft- > bounces at lists.snapcraft.io] On Behalf Of Joseph Rushton Wakeling > Sent: Sunday, February 5, 2017 11:52 PM > To: snapcraft at lists.snapcraft.io > Subject: Re: Using docker for clean builds of classic snaps > > On 05/02/17 19:33, Loïc Minier wrote: > > I dont think "snapd" is in the "ubuntu" Docker image which is trimmed > > down a bit > > Yes, I gathered that much, which is why my own Dockerfile attempt ensured > that snapd would be installed with this line: > > RUN apt-get --assume-yes install snapd snapcraft > > ... but as you say: > > > it's also likely that snapd/snaps would hit some technical issues when > > inside Docker. (This might be worth researching/debugging if you're > > tempted.) > > It looks to me like the snapd daemon doesn't actually run inside the > container. > If I try something simple like checking the version of snapd installed, then I > get this output: > > $ sudo docker run -v $PWD:$PWD -w $PWD 592f87a670d0 snap --version > 2017/02/05 22:43:59.308309 main.go:220: WARNING: cannot create syslog > logger > snap 2.21 > snapd unavailable > series - > > ... so it's clearly installed in my custom image, but not started. > > If I _do_ try starting it as part of the command to run in the container, I get > the following: > > $ sudo docker run -v $PWD:$PWD -w $PWD 592f87a670d0 systemctl enable - > -now snapd.socket && snap install core && snapcraft clean && snapcraft > error: access denied (try with sudo) > > Trying `sudo` (as in `sudo systemctl enable ...`) doesn't seem to make any > difference. > > Any thoughts on what else I could try? I'm happy to keep exploring myself > but Docker and sockets aren't really my area of expertise. I ran into something similar when trying to build a Docker image that would start services via systemd service files. It turned out that systemd does not run out-of-the-box in Docker containers (this was the best blog post I had found on the topic: https://rhatdan.wordpress.com/2014/04/30/running-systemd-within-a-docker-container/, and a seemingly working mechanism, for Ubuntu 15.xx here: https://github.com/dockerimages/docker-systemd). I actually did not go down that path as I found it easier for me to simply start my daemons/services outside of systemd, from a simple script invoked by CMD in my Dockerfile. This may just work and be sufficient for you. Geoffroy > > I would imagine, though, that the kinds of issues I'm running into with > Docker are fundamentally the same issues that make it hard for classic snaps > to support `snapcraft cleanbuild` using lxd ... ? > > Thanks & best wishes, > > -- Joe > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft From xiaoguo.liu at canonical.com Mon Feb 6 08:43:38 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 6 Feb 2017 16:43:38 +0800 Subject: Snap icon in the Ubuntu Store In-Reply-To: References: Message-ID: Hi Kyle, Thanks for your reply. I cannot remember it exactly whether I set an icon for it or not. But this is definitely a confusing part. I think snapweb may have a bug for it since I change another picture in my package, but it is not reflected at all after the new installation. Best regards, XiaoGuo On Mon, Feb 6, 2017 at 1:42 PM, Kyle Fazzari wrote: > Any chance the snap in question has an icon set store side? I believe the > one in the store takes precedence over the one in the snap itself. > > Kyle > > On Feb 5, 2017 4:47 PM, "XiaoGuo Liu" wrote: > >> I just found another problem with snapweb. If I change the icon to >> another picture in the snapcraft.yaml file, after new installation, the >> package icon in the snapweb is not updated, and the old one is still used. >> Is this a bug? >> >> Thanks & best regards, >> XiaoGuo >> >> On Mon, Feb 6, 2017 at 8:15 AM, XiaoGuo Liu >> wrote: >> >>> Hi, >>> >>> I am a little confused about the snap icon in the store. According to >>> the document at: >>> >>> https://snapcraft.io/docs/build-snaps/metadata >>> >>> A package icon is defined by the "icon" field in the snapcraft.yaml. >>> However, my own project at: >>> >>> https://github.com/liu-xiao-guo/ss-qt >>> >>> does not have the "icon" field, and it can be found at: >>> >>> https://uappexplorer.com/app/ss-qt.xiaoguo >>> >>> However, after installation on my desktop, in the snapweb, it does show >>> an snap icon for it. Why is it like this? For some of the apps, if I do not >>> have the icon field defined, it does not show the snap icon in the snapweb >>> at all. >>> >>> Attached please find the picture for it. >>> >>> Thanks & best regards, >>> XiaoGuo >>> >>> >>> -- >>> XiaoGuo, Liu >>> >> >> >> >> -- >> XiaoGuo, Liu >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From simos.lists at googlemail.com Mon Feb 6 09:56:29 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Mon, 6 Feb 2017 11:56:29 +0200 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 Message-ID: Hi All, I wrote an article about creating a snap for an existing Python program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu Store. I am looking forward to receiving feedback :-) Link: https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ Link to HN submission: https://news.ycombinator.com/item?id=13578034 Simos From david.barth at canonical.com Mon Feb 6 11:42:04 2017 From: david.barth at canonical.com (David Barth) Date: Mon, 6 Feb 2017 12:42:04 +0100 Subject: Snap icon in the Ubuntu Store In-Reply-To: References: Message-ID: On Mon, Feb 6, 2017 at 9:43 AM, XiaoGuo Liu wrote: > Hi Kyle, > > Thanks for your reply. I cannot remember it exactly whether I set an icon > for it or not. But this is definitely a confusing part. > > I think snapweb may have a bug for it since I change another picture in my > package, but it is not reflected at all after the new installation. > Yup, confirmed. The cache is not invalidated properly. I filed https://bugs.launchpad.net/snapweb/+bug/1662149 to track that and get a fix asap. Thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruddick at carbon.ai Sat Feb 4 00:45:33 2017 From: ruddick at carbon.ai (Ruddick Lawrence) Date: Fri, 3 Feb 2017 16:45:33 -0800 Subject: Snapcraft lifecycle documentation? Message-ID: Hi, Is there any documentation on the details of what happens during the different lifecycles (pull, build, stage, prime, snap)? I couldn't find any outside of https://snapcraft.io/docs/reference/snapcraft-command, and there were a few things discovered by trial and error that surprised me (such as shared parts included with "after" are pulled, built, and staged when "snapcraft pull" is called) Thanks! Ruddick -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunny.bhayani at einfochips.com Sat Feb 4 09:20:28 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Sat, 4 Feb 2017 09:20:28 +0000 Subject: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues Message-ID: Hi, We are using Eragon410 board to use the Ubuntu-Core OS on it. The Eragon410 board is based on Dragonboard410c board. We have tried to follow all the steps mentioned by the Canonical Team, to build our gadget snap and kernel snap (based on the Dragonboard410c). Thereby, we are able to generate the Ubuntu Core OS snap. We have applied the security patches to our kernel (for AppArmour, and other security related stuff). Earlier we had issue on the first console-conf setup screen, which we figured out that, IPv4 and IPv6 needs to be setup (in our case DHCP) in order for the first console-conf to be configured successfully. After that we were able to do a ssh and configure the password for the board as below: sudo passwd $USER and we were able to also login to the Eragon410 board natively from serial terminal interface. ISSUE 1: We are not able to get the Wifi interface listed in the ifconfig. We compared our boot logs with the Dragonboard410c (precompiled images) boot log, but were not able to get much difference. Then we extracted the firmware.tar (having the firmware binaries for wcnss, venus, a300_pfp, and a300_pm4, obtained from Dragonboard410c release for linux) to the "/firmware" path, and modifying the firmware plugin of the snapcraft.yaml file as below: firmware: plugin: tar-content source: firmware.tar destination: firmware We are able to see the firmware binaries for Wifi in the rootfs at "/lib/firmware" where they are expected. But we are not able to see the Wifi interface (wlan0). ISSUE 2: When we do "snap list", we are getting the below error: ---- Error Start ---- user at localhost:~$ snap list No snaps are installed yet. Try "snap install hello-world". ---- Error End ---- whereas, in the Dragonboard410c (precompiled binary), we are able to see the Ubuntu core snap, kernel snap and gadget snap listed in the output. ISSUE 3: Installing the hello-world snap gives the below error: http://pastebin.com/h9nDtk06 ISSUE 4: We built the Dragonboard410c kernel source, Gadget snap and thereby created the Ubuntu OS snap. But when we boot the Ubuntu Core, we get this error: http://pastebin.com/h2eJG1yw ISSUE 5: For the "Model Assertion", if we do not rename our Gadget snap to "dragonboard_16.04-0.18_armhf.snap", and Kernel snap to "96boards-kernel_4.4.0_arm64.snap", then we are not able to generate the Ubuntu Core OS snap. It seems that these names (Dragonboard related names) are hardcoded in the "ubuntu-image" tool. It would be great if you can give us pointers for the same. Thanks. Thanks & Regards, Sunny Bhayani Solution Consultant | Solutions [https://gallery.einfochips.com/Sign.png] Tel: - | Cell: 919909705699 Product Engineering Services Software | System | Silicon | Mechanical www.einfochips.com | sunny.bhayani at einfochips.com [https://intranet.einfochips.com/images/newletter_footer/blog.png] [https://intranet.einfochips.com/images/newletter_footer/linkedin.png] [https://intranet.einfochips.com/images/newletter_footer/facebook.png] [https://intranet.einfochips.com/images/newletter_footer/google_plus.png] [https://intranet.einfochips.com/images/newletter_footer/twitter.png] [https://intranet.einfochips.com/images/newletter_footer/youtube.png] [https://intranet.einfochips.com/images/newletter_footer/slideshare.png] 20 Years of Engineering Innovation & Excellence Recognized as 'Leader' in Zinnov's Global Service Providers Rating-2015 ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Mon Feb 6 12:07:54 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 6 Feb 2017 12:07:54 +0000 Subject: Snapcraft lifecycle documentation? In-Reply-To: References: Message-ID: On Fri, 3 Feb 2017 16:45:33 -0800, Ruddick Lawrence wrote: > Hi, > > Is there any documentation on the details of what happens during the > different lifecycles (pull, build, stage, prime, snap)? I couldn't find any > outside of https://snapcraft.io/docs/reference/snapcraft-command, and there > were a few things discovered by trial and error that surprised me (such as > shared parts included with "after" are pulled, built, and staged when > "snapcraft pull" is called) If offline, runnning `snapcraft help plugins` goes over plugins in general and the core keywords a part be tuned with. -- Sent using Dekko from my Ubuntu device From ogra at ubuntu.com Mon Feb 6 12:21:29 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 06 Feb 2017 13:21:29 +0100 Subject: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues In-Reply-To: References: Message-ID: <1486383689.31860.10.camel@ubuntu.com> hi, On Sa, 2017-02-04 at 09:20 +0000, Sunny Bhayani wrote: >  > ISSUE 1: > .. > We are able to see the firmware binaries for Wifi in the rootfs at > "/lib/firmware" where they are expected. But we are not able to see > the Wifi interface (wlan0). > does lsmod show you the module for your wlan device loaded ? do you see any errors in dmesg if you load it manually ? > ISSUE 2: > When we do "snap list", we are getting the below error: > ---- Error Start ---- >     user at localhost:~$ snap list >     No snaps are installed yet. Try "snap install hello-world". > ---- Error End ---- obviously your board has not been initialized correctly, did you properly sign your model assertion with a valid key and are gadget and kernel in the store yet (edge channel will be sufficient for this if you tell ubuntu-image to use the edge channel) and signed with the same key ? >  > Installing the hello-world snap gives the below error: > http://pastebin.com/h9nDtk06 if the image has not been initialized correctly using a signed model assertion snapd thinks you are on a classic install and tries to install a new core snap on top of the running system, this wont work unless the firstboot setup of snapd succeeded. > > ISSUE 4: > We built the Dragonboard410c kernel source, Gadget snap and thereby > created the Ubuntu OS snap. But when we boot the Ubuntu Core, we get > this error: > http://pastebin.com/h2eJG1yw did you properly list the required firmware to be included with the initrd in the "kernel-initrd-fws:" option of your kernel snap snapcraft.yaml ? > > ISSUE 5: > For the "Model Assertion", if we do not rename our Gadget snap to > "dragonboard_16.04-0.18_armhf.snap", and Kernel snap to "96boards- > kernel_4.4.0_arm64.snap", then we are not able to generate the Ubuntu > Core OS snap. It seems that these names (Dragonboard related names) > are hardcoded in the "ubuntu-image" tool. is this with a freshly created model assertion that you signed with a proper key ? there is definitelly no hardcoding of the dragonboard name in ubuntu-image, it just reads your model assertion and checks the keys. > > It would be great if you can give us pointers for the same. >  did you follow  https://docs.ubuntu.com/core/en/guides/build-device/image-building  to create your model assertion ? it might also be helpful to get a pointer to your kernel snap and gadget snap source. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Mon Feb 6 12:26:16 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 06 Feb 2017 13:26:16 +0100 Subject: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues In-Reply-To: <1486383689.31860.10.camel@ubuntu.com> References: <1486383689.31860.10.camel@ubuntu.com> Message-ID: <1486383976.31860.12.camel@ubuntu.com> hi, On Mo, 2017-02-06 at 13:21 +0100, Oliver Grawert wrote: > > we get this error: > > http://pastebin.com/h2eJG1yw > did you properly list the required firmware to be included with the > initrd in the "kernel-initrd-fws:" option of your kernel snap > snapcraft.yaml ? > oops, sorry, the name of the option changed since i looked last ... it is kernel-initrd-firmware: now https://github.com/snapcore/snapcraft/blob/master/demos/96boards-kernel /snap/snapcraft.yaml ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Mon Feb 6 12:55:53 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 06 Feb 2017 13:55:53 +0100 Subject: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues In-Reply-To: <1486383689.31860.10.camel@ubuntu.com> References: <1486383689.31860.10.camel@ubuntu.com> Message-ID: <1486385753.11948.7.camel@ubuntu.com> hi, Am Montag, den 06.02.2017, 13:21 +0100 schrieb Oliver Grawert: >  > > ISSUE 4: > > We built the Dragonboard410c kernel source, Gadget snap and thereby > > created the Ubuntu OS snap. But when we boot the Ubuntu Core, we > > get > > this error: > > http://pastebin.com/h2eJG1yw > did you properly list the required firmware to be included with the > initrd in the "kernel-initrd-fws:" option of your kernel snap > snapcraft.yaml ? looking closer your kernel cmdline seems to also miss all snap settings. they are usually seeded by the snap_ variables from the scripts in uboot.env ... a link to your gadget snap source would be really helpful here. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Mon Feb 6 13:36:27 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 06 Feb 2017 14:36:27 +0100 Subject: the ppp interface (and general renaming/transitioning of interfaces) Message-ID: <1486388187.11948.15.camel@ubuntu.com> hi, on the core images we currently provide a ppp interface that used to be used for pppd access in 15.04 images and also gives access to /dev/tty[0-9]. with series 16 the pppd binary was dropped from the core snap and a pppd snap was added to the store which provides all the ppp functionality, but the interface persisted in the core snap.  i recently got a question from a customer about an interface providing access to /dev/tty0 for certain console messages ...  this made me wonder if we have any forward plans for renaming interfaces in cases like the above ... i.e. it would make sense to rename the ppp interface to "console- access" or "tty-access" and drop the execution bits for the non- existing pppd binary from it... do we have any implementation plans, rules, policies etc for such use-cases yet ? ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sunny.bhayani at einfochips.com Mon Feb 6 14:09:47 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Mon, 6 Feb 2017 14:09:47 +0000 Subject: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues Message-ID: Hi Oliver, Thank you for your time. > > We are using Eragon410 board to use the Ubuntu-Core OS on it. The Eragon410 board is based on Dragonboard410c board. > > > > We have tried to follow all the steps mentioned by the Canonical Team, to build our gadget snap and kernel snap (based on the Dragonboard410c). Thereby, we are able to generate the Ubuntu Core OS snap. We have applied the security patches to our kernel (for AppArmour, and other security related stuff). > > > > Earlier we had issue on the first console-conf setup screen, which we figured out that, IPv4 and IPv6 needs to be setup (in our case DHCP) in order for the first console-conf to be configured successfully. After that we were able to do a ssh and configure the password for the board as below: > > > > sudo passwd $USER > > > > and we were able to also login to the Eragon410 board natively from serial terminal interface. > > > > ISSUE 1: > > > > We are not able to get the Wifi interface listed in the ifconfig. We compared our boot logs with the Dragonboard410c (precompiled images) boot log, but were not able to get much difference. Then we extracted the firmware.tar (having the firmware binaries for wcnss, venus, a300_pfp, and a300_pm4, obtained from Dragonboard410c release for linux) to the "/firmware" path, and modifying the firmware plugin of the snapcraft.yaml file as below: > > > > firmware: > > plugin: tar-content > > source: firmware.tar > > destination: firmware > > > > We are able to see the firmware binaries for Wifi in the rootfs at "/lib/firmware" where they are expected. But we are not able to see the Wifi interface (wlan0). > > > > > does lsmod show you the module for your wlan device loaded ? do you see > > > any errors in dmesg if you load it manually ? > > > lsmod just shows us the squashfs module. We manually tried to copy the Wifi kernel module (wcnss.ko) to the "/home" directory (by re-mounting the "/home" folder with read-write permissions) via scp, and did a insmod of the Wifi Module. It got inserted and we are able to see that in the lsmod. However, we are not getting the wlan0 interface when we use the ifconfig. Dmesg also does not show any initialization logs when the module is inserted. > > > ISSUE 2: > > > > > > When we do "snap list", we are getting the below error: > > > ---- Error Start ---- > > > user at localhost:~$ snap list > > > No snaps are installed yet. Try "snap install hello-world". > > > ---- Error End ---- > > obviously your board has not been initialized correctly, did you > > properly sign your model assertion with a valid key and are gadget and > > kernel in the store yet (edge channel will be sufficient for this if > > you tell ubuntu-image to use the edge channel) and signed with the same > > key ? Yes. We have used our brand-id and authority-id obtained from the Ubuntu store to sign the assertion model. We used the below command to create the Ubuntu OS Image: sudo /snap/bin/ubuntu-image -d --channel edge --image-size 1G --extra-snaps dragonboard_16.04-0.18_armhf.snap --extra-snaps 96boards-kernel_4.4.0_arm64.snap -o dragonboard.img dragonboard.model > > > whereas, in the Dragonboard410c (precompiled binary), we are able to see the Ubuntu core snap, kernel snap and gadget snap listed in the output. > > > > > > ISSUE 3: > > > > > > Installing the hello-world snap gives the below error: > > > http://pastebin.com/h9nDtk06 > > > > > if the image has not been initialized correctly using a signed model > > assertion snapd thinks you are on a classic install and tries to > > install a new core snap on top of the running system, this wont work > > unless the firstboot setup of snapd succeeded. We are successfully able to configure the firstboot screen and got the ssh login details. After that, we did ssh and configured the user password to login to the board natively. Will these steps suffice for the snapd to succeed ? > > > ISSUE 4: > > > We built the Dragonboard410c kernel source, Gadget snap and thereby created the Ubuntu OS snap. But when we boot the Ubuntu Core, we get this error: > > > http://pastebin.com/h2eJG1yw > > did you properly list the required firmware to be included with the > > initrd in the "kernel-initrd-fws:" option of your kernel snap > > snapcraft.yaml ? We have followed the below link for the Dragonboard Gadget snap and the uboot.env.in file: https://github.com/snapcore/dragonboard-gadget Our custom uboot.env.in file is at, which is also based on the above Dragonboard Gadget file: http://pastebin.com/1055z6UA > > > ISSUE 5: > > > For the "Model Assertion", if we do not rename our Gadget snap to "dragonboard_16.04-0.18_armhf.snap", and Kernel snap to "96boards-kernel_4.4.0_arm64.snap", then we are not able to generate the Ubuntu Core OS snap. It seems that these names (Dragonboard related names) are hardcoded in the "ubuntu-image" tool. > > did you follow > > https://docs.ubuntu.com/core/en/guides/build-device/image-building > > to create your model assertion ? > > > > it might also be helpful to get a pointer to your kernel snap and > > gadget snap source. Yes. We followed the link that you have mentioned, and tried to provide different "gadget" and "kernel" names to the model assertion. But when we try to generate the Ubuntu OS Image, we get the below error: http://pastebin.com/fnR700Kr We have followed the below link to generate our snapcraft.yaml: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ Our kernel is version 4.4.23 and is downloaded from: https://builds.96boards.org/releases/dragonboard410c/linaro/debian/16.09/ We have done some custom changes in the kernel for our board. Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Mon Feb 6 14:44:13 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 6 Feb 2017 22:44:13 +0800 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: References: Message-ID: Hi Simos, Thanks! It is really nice to see the tutorial, and it is very detailed. Best regards, XiaoGuo On Mon, Feb 6, 2017 at 5:56 PM, Simos Xenitellis wrote: > Hi All, > > I wrote an article about creating a snap for an existing Python > program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu > Store. > > I am looking forward to receiving feedback :-) > > Link: https://blog.simos.info/how-to-create-a-snap-for-a-python- > app-with-networking-using-snapcraft-in-ubuntu-16-04/ > > Link to HN submission: https://news.ycombinator.com/item?id=13578034 > > Simos > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Mon Feb 6 14:48:01 2017 From: simon.fels at canonical.com (Simon Fels) Date: Mon, 6 Feb 2017 15:48:01 +0100 Subject: the ppp interface (and general renaming/transitioning of interfaces) In-Reply-To: <1486388187.11948.15.camel@ubuntu.com> References: <1486388187.11948.15.camel@ubuntu.com> Message-ID: <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> On 06.02.2017 14:36, Oliver Grawert wrote: > hi, > > on the core images we currently provide a ppp interface that used to be > used for pppd access in 15.04 images and also gives access to > /dev/tty[0-9]. > > with series 16 the pppd binary was dropped from the core snap and a > pppd snap was added to the store which provides all the ppp > functionality, but the interface persisted in the core snap. When was pppd dropped from the core snap? We have a dependency on it from the modem-manager snap which is why we added the ppp interface. It also does a few more things like ensuring that the right kernel modules are loaded etc. > i recently got a question from a customer about an interface providing > access to /dev/tty0 for certain console messages ... That would be more the serial-port interface where we need a slot on the gadget/core snap for. > this made me wonder if we have any forward plans for renaming > interfaces in cases like the above ... Please don't do this. The modem-manager snap defines a plug with this interface so we can't easily remove or rename it. > i.e. it would make sense to rename the ppp interface to "console- > access" or "tty-access" and drop the execution bits for the non- > existing pppd binary from it... do we have any implementation plans, > rules, policies etc for such use-cases yet ? Actually we're in a broken state now. When the ppp interface was implemented the idea was that ppp remains in the core snap. Long term I agree that there are better ways to express portions of the ppp interface (like via serial-port) but the interface itself needs to stay as it triggers loading of the right kernel modules needed for ppp. regards, Simon From simon.fels at canonical.com Mon Feb 6 14:50:28 2017 From: simon.fels at canonical.com (Simon Fels) Date: Mon, 6 Feb 2017 15:50:28 +0100 Subject: the ppp interface (and general renaming/transitioning of interfaces) In-Reply-To: <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> References: <1486388187.11948.15.camel@ubuntu.com> <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> Message-ID: <95d40fb9-4cec-7700-bb68-603e7e150fe2@canonical.com> On 06.02.2017 15:48, Simon Fels wrote: > On 06.02.2017 14:36, Oliver Grawert wrote: >> hi, >> >> on the core images we currently provide a ppp interface that used to be >> used for pppd access in 15.04 images and also gives access to >> /dev/tty[0-9]. >> >> with series 16 the pppd binary was dropped from the core snap and a >> pppd snap was added to the store which provides all the ppp >> functionality, but the interface persisted in the core snap. > > When was pppd dropped from the core snap? We have a dependency on it > from the modem-manager snap which is why we added the ppp interface. It > also does a few more things like ensuring that the right kernel modules > are loaded etc. > >> i recently got a question from a customer about an interface providing >> access to /dev/tty0 for certain console messages ... > > That would be more the serial-port interface where we need a slot on the > gadget/core snap for. > >> this made me wonder if we have any forward plans for renaming >> interfaces in cases like the above ... > > Please don't do this. The modem-manager snap defines a plug with this > interface so we can't easily remove or rename it. > >> i.e. it would make sense to rename the ppp interface to "console- >> access" or "tty-access" and drop the execution bits for the non- >> existing pppd binary from it... do we have any implementation plans, >> rules, policies etc for such use-cases yet ? > > Actually we're in a broken state now. When the ppp interface was > implemented the idea was that ppp remains in the core snap. Long term I > agree that there are better ways to express portions of the ppp > interface (like via serial-port) but the interface itself needs to stay > as it triggers loading of the right kernel modules needed for ppp. I've just checked this and all pppd things are still in core. See https://paste.ubuntu.com/23941360/ regards, Simon From ogra at ubuntu.com Mon Feb 6 14:58:29 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 06 Feb 2017 15:58:29 +0100 Subject: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues In-Reply-To: References: Message-ID: <1486393109.11948.43.camel@ubuntu.com> hi, Am Montag, den 06.02.2017, 14:09 +0000 schrieb Sunny Bhayani: >  > > > > does lsmod show you the module for your wlan device loaded ? do > you see > > > > any errors in dmesg if you load it manually ? > > > >  > lsmod just shows us the squashfs module. > We manually tried to copy the Wifi kernel module (wcnss.ko) to the > "/home" directory (by re-mounting the "/home" folder with read-write > permissions) hmm, the home dir for the user you create using console-conf is actually readwrite, you should not need to make anything writable, but it might be fallout of a broken uboot.env setup (and missing kernel cmdline args)... > via scp, and did a insmod of the Wifi Module. It got inserted and we > are able to see that in the lsmod. However, we are not getting the > wlan0 interface when we use the ifconfig. Dmesg also does not show > any initialization logs when the module is inserted. this is kind of weird, what if you include it properly in your kernel snap instead ? > > > if the image has not been initialized correctly using a signed > model > > > assertion snapd thinks you are on a classic install and tries to > > > install a new core snap on top of the running system, this wont > work > > > unless the firstboot setup of snapd succeeded. > > We are successfully able to configure the firstboot screen and got > the ssh login details. After that, we did ssh and configured the user > password to login to the board natively. Will these steps suffice for > the snapd to succeed ? no, that is just the user and network setup, the firstboot initialization of snapd happens during the boot process, way before the console-conf UI tool starts ... you should actually see (red flagged) errors during boot on the console during boot if this bit fails. > > > > > ISSUE 4: > > > > We built the Dragonboard410c kernel source, Gadget snap and > thereby created the Ubuntu OS snap. But when we boot the Ubuntu Core, > we get this error: > > > > http://pastebin.com/h2eJG1yw > > > > did you properly list the required firmware to be included with > the > > > initrd in the "kernel-initrd-fws:" option of your kernel snap > > > snapcraft.yaml ? > > We have followed the below link for the Dragonboard Gadget snap and > the uboot.env.in file: > https://github.com/snapcore/dragonboard-gadget did you also regenerate the uboot.env file from the uboot.env.in file as described in the README ? it does not look like all the bits from the snappy_boot script are run to set the cmdline properly. a typical snappy commmand line on a dragonboard looks like: ogra at dragon:~$ cat /proc/cmdline   androidboot.emmc=true androidboot.serialno=25af71aa androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: console=ttyMSM0,115200n8 console=tty0 root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snap_core=core_551.snap snap_kernel=dragonboard-kernel_16.snap (i.e. it is a lot longer) it looks like the "setenv mmcroot" and "run mmcargs" commands in your snappy_boot script do not get executed or your kernel does not want to read them. this might be the source of all your problems and should be the first thing to attack before you look at anything else. (did you set something like CONFIG_CMDLINE_OVERRIDE or CONFIG_CMDLINE_FORCE in your kernel config that would prevent it using the bootloader cmdline at all ?) > > Our custom uboot.env.in file is at, which is also based on the above > Dragonboard Gadget file: > http://pastebin.com/1055z6UA > ... > > > it might also be helpful to get a pointer to your kernel snap and > > > gadget snap source. > > Yes. We followed the link that you have mentioned, and tried to > provide different "gadget" and "kernel" names to the model assertion. > But when we try to generate the Ubuntu OS Image, we get the below > error: > http://pastebin.com/fnR700Kr well, there seems to be a CRC error with one of your snaps or the assertion ...  ... eragon-kernel already prepared, skipping error: bad CRC: 1869570677 != 1876078605 ERROR:ubuntu-image:COMMAND FAILED: ... > > We have followed the below link to generate our snapcraft.yaml: > http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ well, this blog post is nearly a year old i would suspect that the kernel team made some changes to the kernel plugin meanwhile ... perhaps someone from the kernel team can jump in here and take a look ? ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Mon Feb 6 15:06:50 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 06 Feb 2017 16:06:50 +0100 Subject: the ppp interface (and general renaming/transitioning of interfaces) In-Reply-To: <95d40fb9-4cec-7700-bb68-603e7e150fe2@canonical.com> References: <1486388187.11948.15.camel@ubuntu.com> <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> <95d40fb9-4cec-7700-bb68-603e7e150fe2@canonical.com> Message-ID: <1486393610.11948.47.camel@ubuntu.com> hi, Am Montag, den 06.02.2017, 15:50 +0100 schrieb Simon Fels: >  > I've just checked this and all pppd things are still in core. See > https://paste.ubuntu.com/23941360/ > wow, this is weird, yes, it is indeed still in there, i was 100% sure it was dropped together with the watchdog package when i got a ping from you guys to drop both after 15.04 ... but i just checked the respecting seed diff and noticed only watchdog was actually dropped ... so please ignore this ... yet, we probably still want an interface that allows access to console devices only. and also plan some process in case we need to rename interfaces if their backend changes. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From tonny.tzeng at gmail.com Mon Feb 6 15:10:34 2017 From: tonny.tzeng at gmail.com (Tonny Tzeng) Date: Mon, 6 Feb 2017 23:10:34 +0800 Subject: Which interface exposes user folder to root Message-ID: Hi, The 'home' interface provides non-hidden files access to the snap defined commands, but what if specific commands need to be run with 'sudo', how can I read files from my user folder? For example, from below syslog, I run my snap with 'sudo' to enable the bluetooth, but once I run the snap with root, it can't access $HOME: audit: type=1400 audit(1486391164.744:1219): apparmor="DENIED" operation="open" profile="snap.iotivity-smarthome-demo.node" name="/home/tzeng/Workspace/node-examples/bluetooth/central-ess.js" pid=6991 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 Any pointers would be very appreciated. Thanks. Best Regards, Tonny -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.manrique at canonical.com Mon Feb 6 15:27:31 2017 From: daniel.manrique at canonical.com (Daniel Manrique) Date: Mon, 6 Feb 2017 10:27:31 -0500 Subject: Reject snaps that are identical to previous revision? In-Reply-To: References: Message-ID: On Mon, Feb 6, 2017 at 2:05 AM, Spencer Parkin wrote: > So, I'm sure it comes as no surprise to the readers of this mailing list > that I am a complete moron; and as further evidence of that, I recently > uploaded a "new" snap that was actually identical to the revision I already > had released to my victu...I mean, customers. Does it seem reasonable for > the automated snap vetting process to reject the snap or at least warn me > about it in the event that it hashes to the exact same hash as that of the > previous release? It's just an idea that I thought I might throw out there. > Cheers. Beers. And chocolate. Hello, The store will warn you and not accept an upload which has the same content (determined by the hash) as any existing upload. If you use the web UI to upload, you'll get: "binary_sha3_384: A file with this exact same content has already been uploaded" If you use snapcraft: > snapcraft push hello-uptest-1_2_amd64.snap Uploading hello-uptest-1_2_amd64.snap [===================================] 100% Ready to release!| Revision 1 of 'hello-uptest-1' created. > snapcraft push hello-uptest-1_2_amd64.snap Uploading hello-uptest-1_2_amd64.snap [====================================================] 100% Error while processing...| Uploaded 'hello-uptest-1' There has been a problem while analyzing the snap, check the snap and try to push again. This message can be improved to give a clearer report (like the web UI does) and perhaps some tips on how to overcome the problem, I requested the improvement here: https://bugs.launchpad.net/snapcraft/+bug/1662206 Cheers, - Daniel > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From ogra at ubuntu.com Mon Feb 6 15:39:35 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 06 Feb 2017 16:39:35 +0100 Subject: unity8-session snap on pi2 Message-ID: <1486395575.11948.50.camel@ubuntu.com> hi, far from being usable or anything ...  but...  http://imgur.com/a/ddqjQ shows the unity8-session snap running on top of Ubuntu Core 16 on a pi2 on todays edge image :) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Mon Feb 6 17:13:43 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 06 Feb 2017 11:13:43 -0600 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: <1486401223.26371.5.camel@canonical.com> On Sat, 2017-02-04 at 12:00 +0100, Luca Dionisi wrote: > On Sat, Feb 4, 2017 at 11:43 AM, Oliver Grawert wrote: > > > > hi, > > Am Freitag, den 03.02.2017, 21:04 +0100 schrieb Luca Dionisi: > > > > > > What is the best place to write (and read) a temporary FIFO file from > > > a confined snap application? > > > This is for simple IPC between 2 processes of the same snap. > > > Before attempting to snap the application I was using a fixed > > > filename > > > in /tmp. Admittedly poor solution. > > > The solution should be usable also with another packaging system. > > > > > well ... in case of snaps /tmp is a private directory that only your > > snap can access so it is actually a good place for such stuff ... > It's worse than that, Jim! > > Inside the snap environment I can write files and directories both in > /tmp and in $XDG_RUNTIME_DIR. > What I cannot do anywhere is create a FIFO. > > bash-4.3$ mkfifo a > bash: /usr/bin/mkfifo: Permission denied > > What's the problem here? See https://github.com/snapcore/snapd/pull/2749 which adds support for mkfifo At the lowest levels, mkfifo and mknod are (currently) blocked because they use the mknod syscall and the mknod syscall can be used to create devices. If we allowed the use of mknod, a snap could create a device in SNAP_DATA and talk to the kernel through the device (eg, raw access to your disk). The above referenced PR limits how mknod can be used to create regular files, pipes and sockets but not block and character devices. As such, we are adding the mknod and mkfifo commands as part of that PR and this should be available for use in snapd 2.23. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Mon Feb 6 17:19:14 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 06 Feb 2017 11:19:14 -0600 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> <1486207304.11948.5.camel@ubuntu.com> Message-ID: <1486401554.26371.9.camel@canonical.com> On Sat, 2017-02-04 at 15:53 +0100, Luca Dionisi wrote: > Although I wouldn't spend too much on this IPC issue (the IPC task is > needed only for a testing tool that I won't deploy anywhere) in order > to go ahead I am going to explore other possibilities. I want to  try > with DBus. Do you know of anything DBus-related that will encounter > issues in a snap environment? Today, you'll have the same issue with dbus. You could use the 'dbus interface' in your snap, but you'd need to have this bug fixed for applications within your snap to use it: https://bugs.launchpad.net/snappy/+bug/1659724 The fix for this should be in snapd 2.23[1]. I would actually recommend using UNIX domain sockets for this though. The easiest is to put a named socket in SNAP_DATA. [1]https://github.com/snapcore/snapd/pull/2768 -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Mon Feb 6 17:21:42 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 06 Feb 2017 11:21:42 -0600 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> Message-ID: <1486401702.26371.11.camel@canonical.com> On Sun, 2017-02-05 at 08:04 +0800, XiaoGuo Liu wrote: > Hi Oli, > > Does it mean all of the snaps have the same /tmp or each snap has its own > /tmp? I am a little bit confused about this. > You might be confused because the behavior changed. For a long time, each snap *command* had its own /tmp directory. That was changed late last year so that all commands with the same snap share the same /tmp directory such that each snap has its own /tmp directory. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kyle.fazzari at canonical.com Mon Feb 6 17:25:16 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 6 Feb 2017 09:25:16 -0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <1486401702.26371.11.camel@canonical.com> References: <1486205037.11948.2.camel@ubuntu.com> <1486401702.26371.11.camel@canonical.com> Message-ID: <29863c04-2861-a6a4-a859-ba5bb5717185@canonical.com> On 02/06/2017 09:21 AM, Jamie Strandboge wrote: > On Sun, 2017-02-05 at 08:04 +0800, XiaoGuo Liu wrote: >> Hi Oli, >> >> Does it mean all of the snaps have the same /tmp or each snap has its own >> /tmp? I am a little bit confused about this. >> > > You might be confused because the behavior changed. For a long time, each snap > *command* had its own /tmp directory. That was changed late last year so that > all commands with the same snap share the same /tmp directory such that each > snap has its own /tmp directory. This is good to know, I thought each command *still* had its own /tmp. Any chance you know the snapd version in which this change was introduced? -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From victor.ruiz at canonical.com Mon Feb 6 17:33:30 2017 From: victor.ruiz at canonical.com (=?UTF-8?B?VsOtY3RvciBSLiBSdWl6?=) Date: Mon, 6 Feb 2017 17:33:30 +0000 Subject: unity8-session snap on pi2 In-Reply-To: <1486395575.11948.50.camel@ubuntu.com> References: <1486395575.11948.50.camel@ubuntu.com> Message-ID: Hi: On Mon, Feb 6, 2017 at 3:39 PM, Oliver Grawert wrote: > far from being usable or anything ... > but... > http://imgur.com/a/ddqjQ > > shows the unity8-session snap running on top of Ubuntu Core 16 on a pi2 > on todays edge image :) Oh, this is really nice. Congratulations, Oliver! Looking forward to check it :) Greetings, -- Víctor R. Ruiz | - All this moments will be lost victor.ruiz at canonical.com | like tears in the rain From jamie at canonical.com Mon Feb 6 17:50:46 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 06 Feb 2017 11:50:46 -0600 Subject: Which interface exposes user folder to root In-Reply-To: References: Message-ID: <1486403446.26371.33.camel@canonical.com> On Mon, 2017-02-06 at 23:10 +0800, Tonny Tzeng wrote: > Hi, > > The 'home' interface provides non-hidden files access to the snap defined > commands, but what if specific commands need to be run with 'sudo', how can > I read files from my user folder? For example, from below syslog, I run my > snap with 'sudo' to enable the bluetooth, but once I run the snap with > root, it can't access $HOME: > > audit: type=1400 audit(1486391164.744:1219): apparmor="DENIED" > operation="open" profile="snap.iotivity-smarthome-demo.node" > name="/home/tzeng/Workspace/node-examples/bluetooth/central-ess.js" > pid=6991 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 > > Any pointers would be very appreciated. Thanks. > What is happening is that the home interface uses an AppArmor rule like this: owner @{HOME}/** rwk, The @{HOME} AppArmor variable expands to include /home/ and /root so the file paths aren't an issue, but the 'owner' match requires that the process' uid and the file's uid match, so the issue you are seeing is that the ownership is not matching[1]. Keep in mind that while useful, the home interface grants a lot of access to the snap and in general for strict confinement, best practice would have you use SNAP_USER_DATA for data that is specific to a particular user (and use 'sudo -H' instead of 'sudo' so that the $HOME env var is set to /root). For data that is written by root but readable by others, use SNAP_DATA since it accessible by everything in your snap. It appears this is a demo snap-- I suggest putting your example files in your snap (ie, in $SNAP) and have all your commands look for them in $SNAP (you'll need to do this anyway since /home/tzeng/Workspace/node-examples/... only exists on your machine). For things that need read/write, put them in SNAP_DATA or SNAP_USER_DATA and have all your commands look for them there. If you want to share data between commands for different users, either put the files in /tmp (it is snap-specific and cleared on reboot) or create a persistent snap-specific shared directory in $SNAP_DATA (eg, mkdir -m 1777 $SNAP_DATA/tmp) and put them there. Hope this helps! [1]In general, it is best practice to avoid processing files that are under another user's control since those files could potentially be used to alter the behavior of the running process -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From luca.dionisi at gmail.com Mon Feb 6 18:01:12 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Mon, 6 Feb 2017 19:01:12 +0100 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <1486401554.26371.9.camel@canonical.com> References: <1486205037.11948.2.camel@ubuntu.com> <1486207304.11948.5.camel@ubuntu.com> <1486401554.26371.9.camel@canonical.com> Message-ID: On Mon, Feb 6, 2017 at 6:19 PM, Jamie Strandboge wrote: > On Sat, 2017-02-04 at 15:53 +0100, Luca Dionisi wrote: >> Although I wouldn't spend too much on this IPC issue (the IPC task is >> needed only for a testing tool that I won't deploy anywhere) in order >> to go ahead I am going to explore other possibilities. I want to try >> with DBus. Do you know of anything DBus-related that will encounter >> issues in a snap environment? > > Today, you'll have the same issue with dbus. You could use the 'dbus interface' > in your snap, but you'd need to have this bug fixed for applications within your > snap to use it: > https://bugs.launchpad.net/snappy/+bug/1659724 > > The fix for this should be in snapd 2.23[1]. > > I would actually recommend using UNIX domain sockets for this though. The > easiest is to put a named socket in SNAP_DATA. > > [1]https://github.com/snapcore/snapd/pull/2768 > > -- > Jamie Strandboge | http://www.canonical.com Thank you Jamie, very useful. --Luca From jamie at canonical.com Mon Feb 6 18:02:01 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 06 Feb 2017 12:02:01 -0600 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <29863c04-2861-a6a4-a859-ba5bb5717185@canonical.com> References: <1486205037.11948.2.camel@ubuntu.com> <1486401702.26371.11.camel@canonical.com> <29863c04-2861-a6a4-a859-ba5bb5717185@canonical.com> Message-ID: <1486404121.26371.35.camel@canonical.com> On Mon, 2017-02-06 at 09:25 -0800, Kyle Fazzari wrote: > > On 02/06/2017 09:21 AM, Jamie Strandboge wrote: > > > > On Sun, 2017-02-05 at 08:04 +0800, XiaoGuo Liu wrote: > > > > > > Hi Oli, > > > > > > Does it mean all of the snaps have the same /tmp or each snap has its own > > > /tmp? I am a little bit confused about this. > > > > > You might be confused because the behavior changed. For a long time, each > > snap > > *command* had its own /tmp directory. That was changed late last year so > > that > > all commands with the same snap share the same /tmp directory such that each > > snap has its own /tmp directory. > This is good to know, I thought each command *still* had its own /tmp. > Any chance you know the snapd version in which this change was introduced? > It looks like it was fixed in upstream (pre-merge with snapd) snap-confine 1.0.41. It didn't make it into series 16 until 1.0.43-0ubuntu1~16.04.1 until Oct 10[1]. [1]https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1630040 -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From spencertparkin at gmail.com Mon Feb 6 18:46:25 2017 From: spencertparkin at gmail.com (Spencer) Date: Mon, 6 Feb 2017 11:46:25 -0700 Subject: Reject snaps that are identical to previous revision? In-Reply-To: References: Message-ID: Okay, then the snaps were different for some reason on my end. Good to know this check is already in place. Sent from my iPhone > On Feb 6, 2017, at 8:27 AM, Daniel Manrique wrote: > >> On Mon, Feb 6, 2017 at 2:05 AM, Spencer Parkin wrote: >> So, I'm sure it comes as no surprise to the readers of this mailing list >> that I am a complete moron; and as further evidence of that, I recently >> uploaded a "new" snap that was actually identical to the revision I already >> had released to my victu...I mean, customers. Does it seem reasonable for >> the automated snap vetting process to reject the snap or at least warn me >> about it in the event that it hashes to the exact same hash as that of the >> previous release? It's just an idea that I thought I might throw out there. >> Cheers. Beers. And chocolate. > > Hello, > > The store will warn you and not accept an upload which has the same > content (determined by the hash) as any existing upload. > > If you use the web UI to upload, you'll get: > > "binary_sha3_384: A file with this exact same content has already been uploaded" > > If you use snapcraft: > >> snapcraft push hello-uptest-1_2_amd64.snap > Uploading hello-uptest-1_2_amd64.snap [===================================] 100% > Ready to release!| > Revision 1 of 'hello-uptest-1' created. >> snapcraft push hello-uptest-1_2_amd64.snap > Uploading hello-uptest-1_2_amd64.snap > [====================================================] 100% > Error while processing...| > Uploaded 'hello-uptest-1' > There has been a problem while analyzing the snap, check the snap and > try to push again. > > > This message can be improved to give a clearer report (like the web UI > does) and perhaps some tips on how to overcome the problem, I > requested the improvement here: > https://bugs.launchpad.net/snapcraft/+bug/1662206 > > Cheers, > > - Daniel > > >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From mabnhdev at gmail.com Mon Feb 6 19:04:58 2017 From: mabnhdev at gmail.com (MikeB) Date: Mon, 6 Feb 2017 14:04:58 -0500 Subject: Issue with oneshot daemon Message-ID: In my snapcraft.yaml, I define a oneshot daemon. opx-init: command: usr/bin/opx-init daemon: oneshot When I install the snap on Ubuntu-Core, I see the following in the syslog... Feb 6 18:46:49 localhost systemd[1]: snap.openswitch-x870.opx-init.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusing. Can anyone explain what is going wrong? I expect Snapcraft/Snapd to handle the systemd interactions behind the scenes... Thanks, Mike From sergio.schvezov at canonical.com Mon Feb 6 19:10:28 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 6 Feb 2017 19:10:28 +0000 Subject: Issue with oneshot daemon In-Reply-To: References: Message-ID: <3nj9wk.okyvxk.31oq9f-qmf@smtp.googlemail.com> On Mon, 6 Feb 2017 14:04:58 -0500, MikeB wrote: > In my snapcraft.yaml, I define a oneshot daemon. > > > opx-init: > command: usr/bin/opx-init > daemon: oneshot > > When I install the snap on Ubuntu-Core, I see the following in the syslog... > > Feb 6 18:46:49 localhost systemd[1]: > snap.openswitch-x870.opx-init.service: Service has Restart= setting > other than no, which isn't allowed for Type=oneshot services. > Refusing. > > Can anyone explain what is going wrong? I expect Snapcraft/Snapd to > handle the systemd interactions behind the scenes... Sorry for the inconvenience, this seems to be a snapd bug, mind logging it here: https://bugs.launchpad.net/snapd/+filebug -- Sent using Dekko from my Ubuntu device From jamie at canonical.com Mon Feb 6 19:23:05 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 06 Feb 2017 13:23:05 -0600 Subject: Issue with oneshot daemon In-Reply-To: References: Message-ID: <1486408985.26371.54.camel@canonical.com> On Mon, 2017-02-06 at 14:04 -0500, MikeB wrote: > In my snapcraft.yaml, I define a oneshot daemon. > > >   opx-init: >     command: usr/bin/opx-init >     daemon: oneshot > > When I install the snap on Ubuntu-Core, I see the following in the syslog... > > Feb  6 18:46:49 localhost systemd[1]: > snap.openswitch-x870.opx-init.service: Service has Restart= setting > other than no, which isn't allowed for Type=oneshot services. > Refusing. > > Can anyone explain what is going wrong?  I expect Snapcraft/Snapd to > handle the systemd interactions behind the scenes... > You are right, snapd should handle this properly but at the moment it doesn't. This is this bug: https://bugs.launchpad.net/snappy/+bug/1647169 Perhaps Jamie Bennett or someone from the Snappy team could comment on its status? -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mila at fl-sales.com Mon Feb 6 19:42:10 2017 From: mila at fl-sales.com (Mila Hannah) Date: Mon, 6 Feb 2017 19:42:10 +0000 Subject: Network Administrator In-Reply-To: References: Message-ID: Did you get a chance to review my previous email? Let me know if we can schedule a call to discuss further. Look forward to hearing back Regards, Mila From: Mila Hannah Sent: Thursday, February 2, 2017 1:21 PM To: snapcraft at lists.snapcraft.io Subject: Network Administrator Hi, Would you be interested in an email leads of Network Administrators? We can help you reach out to. Title includes: > Network Administrator > Network Engineer > Network Security > Network Operations Manager > Network Manager > CIO > CTO The list comes with complete contact information like Contact name, Email address, Title, Company name, Phone number, Mailing address, etc. I'd be happy to send over few sample records if you could throw some light on your target audience, and set up a time to discuss further. If there is someone else in your organization that I need to speak with, I'd be grateful if you would forward this email to the appropriate contact and help me with the introduction. Have a great day! Regards, Mila Hannah / INF Solutions / 302-250-4336 If you don't wish to receive emails from us reply back with "Unsubscribe". -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Mon Feb 6 20:13:42 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 06 Feb 2017 14:13:42 -0600 Subject: Snap security questions In-Reply-To: References: <1485960368.10013.235.camel@canonical.com> Message-ID: <1486412022.26371.67.camel@canonical.com> On Fri, 2017-02-03 at 19:59 +0800, James Henstridge wrote: > On 1 February 2017 at 22:46, Jamie Strandboge wrote: > > > > On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote: > > > > > > 2. Use of the libapparmor aa_is_enabled and aa_query_label APIs > > > > > > When deciding whether to do work on behalf of a client, > > > thumbnailer-service uses a couple libapparmor API calls to determine > > > whether the client has access to a file.  Neither of these are working > > > under snappy confinement. > > > > > > The first call we use is aa_is_enabled(), but it seems the policy is > > > to strict to let us determine whether AppArmor is enabled or not. > > > > > > Next we use aa_query_label() to perform the file access check.  This > > > fails when trying to read /proc/$pid/mounts to determine where > > > securityfs is mounted.  If that is fixed, it will likely fail when > > > trying to access the "/sys/kernel/security/apparmor/.access" file > > > within. > > > > > > I've filed a bug for this one here: > > > > > > https://bugs.launchpad.net/snappy/+bug/1660957 > > This needs some more thought since only "trusted helpers" that are doing > > some > > form of mediation themselves need this access. Adding it to the dbus > > interface > > by default isn't correct since, for example, ktuberling shouldn't be asking > > about the security contexts of other snaps (not to mention, this doesn't > > really > > have anything to do with the dbus interface). I've assigned it to me and > > will > > think about it and will comment in the bug/propose a PR where we can discuss > > further. > Since it looked like we'd need a specialised snappy interface for > thumbnailer, I had a go adding the rules necessary to enable > aa_query_label() there.  If thumbnailer turns out to be the only snap > needing this API, or the other snaps needing it also require custom > interfaces, then perhaps this is a reasonable place to put the rules. > > Of course, once I got my interface up and running, I ran into > https://bugs.launchpad.net/apparmor/+bug/1620635 again.  I've put my > in-progress branch up for review here: > > https://github.com/snapcore/snapd/pull/2783 Thumbnailer isn't the only one that needs this, but I suspect putting the rules in a specialized interface like you did in this PR will be the way to do this. There is an effort to refactor the way interface policy is put together and when doing that we'll do something like 'give me all the seccomp rules needed for connecting to a dbus service'. We can do something similar for the libapparmor access such that each interface that needs libapparmor in this manner can say 'give me all the apparmor rules needed for using libapparmor as a trusted helper'. Thanks for the PR! :) -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie.bennett at canonical.com Mon Feb 6 20:14:16 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Mon, 6 Feb 2017 20:14:16 +0000 Subject: the ppp interface (and general renaming/transitioning of interfaces) In-Reply-To: <1486393610.11948.47.camel@ubuntu.com> References: <1486388187.11948.15.camel@ubuntu.com> <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> <95d40fb9-4cec-7700-bb68-603e7e150fe2@canonical.com> <1486393610.11948.47.camel@ubuntu.com> Message-ID: <20170206201416.GA23184@orwell.home> On 06/02/17 at 04:06P, Oliver Grawert wrote: > hi, > Am Montag, den 06.02.2017, 15:50 +0100 schrieb Simon Fels: > >  > > I've just checked this and all pppd things are still in core. See > > https://paste.ubuntu.com/23941360/ > > > wow, this is weird, yes, it is indeed still in there, i was 100% sure > it was dropped together with the watchdog package when i got a ping > from you guys to drop both after 15.04 ... but i just checked the > respecting seed diff and noticed only watchdog was actually dropped ... > > so please ignore this ... > > yet, we probably still want an interface that allows access to console > devices only. and also plan some process in case we need to rename > interfaces if their backend changes. Access to serial tty-only devices makes sense and a dedicated interface makes sense. > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From michael.hudson at canonical.com Mon Feb 6 20:25:17 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Tue, 7 Feb 2017 09:25:17 +1300 Subject: please try my golang snap In-Reply-To: References: Message-ID: On 6 February 2017 at 02:55, Shuduo Sang wrote: > > > On Fri, Feb 3, 2017 at 4:52 PM, Shuduo Sang > wrote: > >> Hi, >> >> I got following output after run it: >> >> $ go-17-mwhudson.go-17 >> /snap/go-17-mwhudson/2/gowrapper: line 3: /snap/go-17-mwhudson/2/bin/go: >> No such file or directory >> >> My snap version is: >> $ snap version >> snap 2.21 >> snapd 2.21 >> series 16 >> ubuntu 16.04 >> >> Please let me know what mistake I have. >> > > UPDATE: I notice the go binary is referred to library from /snap/core > $ file /snap/go-17-mwhudson/current/bin/go > /snap/go-17-mwhudson/current/bin/go: ELF 64-bit LSB executable, x86-64, > version 1 (SYSV), dynamically linked, interpreter > /snap/core/current/lib/x86_64-linux-gnu/ld-2.23.so, for GNU/Linux 2.6.32, > BuildID[sha1]=3e694c21430e17b6bba99bd1828696a784ffab8a, not stripped > > But I have /snap/ubuntu-core only. > > After refresh ubuntu-core from candidate channel then it transit to > /snap/core now go-17 works well. Thanks zyga's help. > Ah good, glad you got it working. I think this makes sense as a way to distribute Go to people who want to use Go on their machines. I maintain a PPA with backports of new versions of Go to older releases of Ubuntu but it's a bit fiddly and snaps would be better (and also get cross distro coverage). I think to get to the point of it being a good general distribution mechanism, we need: 1) testing (so that's everyone who's downloaded it so far) 2) pick a better snap name, or set of snap names (go-16, go-17, go-18 or go16, go17, go18 or something else?) 3) get it into the stable channel 4) building in Launchpad would surely be nice to get better architecture coverage Have I missed anything? Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Mon Feb 6 22:09:04 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 6 Feb 2017 23:09:04 +0100 Subject: license.txt and snap/ directory In-Reply-To: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> Message-ID: <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> On 06/02/17 00:00, Sergio Schvezov wrote: > We removed all traces of license.txt from our > documentation months ago as snapd made no use of it. That said you are free to > drop license file inside the snap wherever you want. Just to follow up a little here: I'm honestly not sure I like this change. It may not be used by snapd but it makes sense that there should be an expectation that each snap package will contain a license file in a standardized location, and there should be a standardized way of providing it. Related to the 2.26 changes: I notice that as of 2.26 any generated package now includes a `snap/` directory, even though the `gui` and `snap.yaml` files included with the generated package still wind up in the `meta/` directory. Is this a transitional change (with `snap/` being the intended long-term location for metadata) or just a bug? From sergio.schvezov at canonical.com Mon Feb 6 22:40:46 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 6 Feb 2017 22:40:46 +0000 Subject: license.txt and snap/ directory In-Reply-To: <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> Message-ID: On Mon, 6 Feb 2017 23:09:04 +0100, Joseph Rushton Wakeling wrote: > On 06/02/17 00:00, Sergio Schvezov wrote: >> We removed all traces of license.txt from our >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> drop license file inside the snap wherever you want. > > Just to follow up a little here: I'm honestly not sure I like > this change. It > may not be used by snapd but it makes sense that there should > be an expectation > that each snap package will contain a license file in a > standardized location, > and there should be a standardized way of providing it. If it is not defined anywhere though, this is just a de-facto standard as it really is upto each person creating there snap about where to put it. > Related to the 2.26 changes: I notice that as of 2.26 any > generated package now > includes a `snap/` directory, even though the `gui` and `snap.yaml` files > included with the generated package still wind up in the `meta/` directory. > > Is this a transitional change (with `snap/` being the intended long-term > location for metadata) or just a bug? Files owned by snapcraft will go in snap, files owned by snapd will go in snapd. All the command wrappers that snapcraft creates will also go in here. -- Sent using Dekko from my Ubuntu device From joseph.wakeling at webdrake.net Mon Feb 6 23:03:02 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 7 Feb 2017 00:03:02 +0100 Subject: license.txt and snap/ directory In-Reply-To: References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> Message-ID: <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> On 06/02/17 23:40, Sergio Schvezov wrote: > If it is not defined anywhere though, this is just a de-facto standard as it really is upto each person creating there snap about where to put it. Well, that's what I'm saying -- IMO it should be defined (as I believe it used to be). > Files owned by snapcraft will go in snap, files owned by snapd will go in snapd. All the command wrappers that snapcraft creates will also go in here. Just to make sure I understand what you're saying, are you talking here about the directory layout of the snap package definition, or the generated snap package? I'm talking about the directory layout in the generated snap package. Currently an empty `snap/` directory gets created in there and I don't see the point of it if it does not contain anything. From kyle.fazzari at canonical.com Mon Feb 6 23:24:54 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 6 Feb 2017 15:24:54 -0800 Subject: license.txt and snap/ directory In-Reply-To: <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> Message-ID: <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> On 02/06/2017 03:03 PM, Joseph Rushton Wakeling wrote: > On 06/02/17 23:40, Sergio Schvezov wrote: >> If it is not defined anywhere though, this is just a de-facto standard >> as it really is upto each person creating there snap about where to >> put it. > > Well, that's what I'm saying -- IMO it should be defined (as I believe > it used to be). > >> Files owned by snapcraft will go in snap, files owned by snapd will go >> in snapd. All the command wrappers that snapcraft creates will also go >> in here. > > Just to make sure I understand what you're saying, are you talking here > about the directory layout of the snap package definition, or the > generated snap package? > > I'm talking about the directory layout in the generated snap package. > Currently an empty `snap/` directory gets created in there and I don't > see the point of it if it does not contain anything. The fact that an empty directory is created here is a bug[1]. It should only create that directory if there's something to put in there. What Sergio is saying is this: Snapcraft-specific things, like hooks from snapcraft parts, command wrappers (eventually, not yet) will end up in the snap/ directory of the built snap. This has no bearing on the snap format, it's something internal to snapcraft (it could just as easily have chosen to place those things in the foo/ directory). The things in meta/ are specific to snapd. This directory is literally what defines "this random squashfs image" to be a snap. [1]: https://bugs.launchpad.net/snapcraft/+bug/1660890 -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From joseph.wakeling at webdrake.net Tue Feb 7 00:46:04 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 7 Feb 2017 01:46:04 +0100 Subject: license.txt and snap/ directory In-Reply-To: <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> Message-ID: <87658715-83e8-5746-f6ca-165196463cb1@webdrake.net> On 07/02/17 00:24, Kyle Fazzari wrote: > The fact that an empty directory is created here is a bug[1]. It should > only create that directory if there's something to put in there. What > Sergio is saying is this: > > Snapcraft-specific things, like hooks from snapcraft parts, command > wrappers (eventually, not yet) will end up in the snap/ directory of the > built snap. This has no bearing on the snap format, it's something > internal to snapcraft (it could just as easily have chosen to place > those things in the foo/ directory). > > The things in meta/ are specific to snapd. This directory is literally > what defines "this random squashfs image" to be a snap. OK, makes sense. BTW, I hope I didn't come over as overly negative in my reply to Sergio: if so it wasn't intended. Can I however raise a plea that `meta/` should contain licensing information as a requirement? Even if it's not actively used by snapd right now, it makes sense as a location and it would also make sense (in future) to be able to do things like snap license whatever to check the available licensing information. More generally, it seems like a good idea to me that (i) snap packages must contain licensing information, (ii) it will be available in a standardized location both in the snap package definition and the generated snap package, and (iii) this will be enforced/guaranteed by snapcraft. From joseph.wakeling at webdrake.net Tue Feb 7 00:52:59 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 7 Feb 2017 01:52:59 +0100 Subject: license.txt and snap/ directory In-Reply-To: <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> Message-ID: <0b9a90c1-658c-7eb1-eddb-51315e9559f0@webdrake.net> On 07/02/17 00:24, Kyle Fazzari wrote: > The fact that an empty directory is created here is a bug[1]. > > [1]: https://bugs.launchpad.net/snapcraft/+bug/1660890 BTW, talking of empty directories, it's not the only example I've come across: in my ldc2 snap, I wind up with an empty dir: usr/lib/gcc/x86_64-linux-gnu/6/ ... whose origin is a bit opaque, but which I presume comes out of something to do with linking against libc? From xiaoguo.liu at canonical.com Tue Feb 7 04:04:14 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 7 Feb 2017 12:04:14 +0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <1486401702.26371.11.camel@canonical.com> References: <1486205037.11948.2.camel@ubuntu.com> <1486401702.26371.11.camel@canonical.com> Message-ID: Hi Jamie, For my sample app at https://github.com/liu-xiao-guo/helloworld-fifo, I tried to use the /tmp file to create a file, and finally I get a file on my Desktop like: root at liuxg:/tmp/snap.1000_snap.hello.fifo_TovLTW/tmp# ls anothefile It seems to me that the path is still related to the command name "fifo". Does this conflict with your saying? Currently, my snapd version on 16.04 desktop is: liuxg at liuxg:~$ snap version snap 2.22.1 snapd 2.22.1 series 16 ubuntu 16.04 Thanks & best regards, XiaoGuo On Tue, Feb 7, 2017 at 1:21 AM, Jamie Strandboge wrote: > On Sun, 2017-02-05 at 08:04 +0800, XiaoGuo Liu wrote: > > Hi Oli, > > > > Does it mean all of the snaps have the same /tmp or each snap has its own > > /tmp? I am a little bit confused about this. > > > > You might be confused because the behavior changed. For a long time, each > snap > *command* had its own /tmp directory. That was changed late last year so > that > all commands with the same snap share the same /tmp directory such that > each > snap has its own /tmp directory. > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonny.tzeng at gmail.com Tue Feb 7 04:27:26 2017 From: tonny.tzeng at gmail.com (Tonny Tzeng) Date: Tue, 7 Feb 2017 12:27:26 +0800 Subject: Which interface exposes user folder to root In-Reply-To: <1486403446.26371.33.camel@canonical.com> References: <1486403446.26371.33.camel@canonical.com> Message-ID: Hi Jamie, Thanks for the detailed explanation, it's really helpful! However, I am hesitated to package my example files in the snap, just curious, what's the proper way to package a "development snap" which reads user given files and requires root permission? For example, I'd like to package necessary node.js components in a snap for developers to design their node.js based BLE apps, I've add node, bleno and noble modules in a snap, so the idea is to let the users create their own node.js sample apps (under their $HOME) and invoke the node command in my snap to run their sample apps. Since the bleno/noble node modules require root privilege for accessing BLE, I used "sudo mysnap.node " to run the snap command. But as you pointed out, the fsuid=0 but ouid=1000 which prevents the sample file being read from the snap command? Best Regards, Tonny On Tue, Feb 7, 2017 at 1:50 AM, Jamie Strandboge wrote: > On Mon, 2017-02-06 at 23:10 +0800, Tonny Tzeng wrote: > > Hi, > > > > The 'home' interface provides non-hidden files access to the snap defined > > commands, but what if specific commands need to be run with 'sudo', how > can > > I read files from my user folder? For example, from below syslog, I run > my > > snap with 'sudo' to enable the bluetooth, but once I run the snap with > > root, it can't access $HOME: > > > > audit: type=1400 audit(1486391164.744:1219): apparmor="DENIED" > > operation="open" profile="snap.iotivity-smarthome-demo.node" > > name="/home/tzeng/Workspace/node-examples/bluetooth/central-ess.js" > > pid=6991 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 > > > > Any pointers would be very appreciated. Thanks. > > > > What is happening is that the home interface uses an AppArmor rule like > this: > > owner @{HOME}/** rwk, > > The @{HOME} AppArmor variable expands to include /home/ and /root so > the > file paths aren't an issue, but the 'owner' match requires that the > process' uid > and the file's uid match, so the issue you are seeing is that the > ownership is > not matching[1]. > > Keep in mind that while useful, the home interface grants a lot of access > to the > snap and in general for strict confinement, best practice would have you > use > SNAP_USER_DATA for data that is specific to a particular user (and use > 'sudo -H' > instead of 'sudo' so that the $HOME env var is set to /root). For data > that is > written by root but readable by others, use SNAP_DATA since it accessible > by > everything in your snap. > > It appears this is a demo snap-- I suggest putting your example files in > your > snap (ie, in $SNAP) and have all your commands look for them in $SNAP > (you'll > need to do this anyway since /home/tzeng/Workspace/node-examples/... only > exists > on your machine). For things that need read/write, put them in SNAP_DATA or > SNAP_USER_DATA and have all your commands look for them there. If you want > to > share data between commands for different users, either put the files in > /tmp > (it is snap-specific and cleared on reboot) or create a persistent > snap-specific > shared directory in $SNAP_DATA (eg, mkdir -m 1777 $SNAP_DATA/tmp) and put > them > there. > > Hope this helps! > > [1]In general, it is best practice to avoid processing files that are under > another user's control since those files could potentially be used to > alter the > behavior of the running process > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Tue Feb 7 07:13:28 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Tue, 7 Feb 2017 08:13:28 +0100 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: References: Message-ID: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> Le 06/02/2017 à 10:56, Simos Xenitellis a écrit : > Hi All, > > I wrote an article about creating a snap for an existing Python > program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu > Store. > > I am looking forward to receiving feedback :-) > > Link: https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ > > Link to HN submission: https://news.ycombinator.com/item?id=13578034 > > Simos > Excellent work Simos! I think this kind of content would make an excellent official "pratical" tutorials on https://tutorials.ubuntu.com. Are you interested into contributing there? If you want more context on tutorials, the phisolophy and how to contribute, I wrote a blog post some time ago about it: https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/. I'm also available for any help, Cheers, Didier From anton at huge.geek.nz Tue Feb 7 07:33:13 2017 From: anton at huge.geek.nz (Anton Smith) Date: Tue, 7 Feb 2017 20:33:13 +1300 Subject: MMAL/RPI libraries needed for snappy Message-ID: <3EF2B3F5-35C8-416A-884A-D06A7A158F5B@huge.geek.nz> Hi, I'm not 100% sure this is the root cause, but: I am trying to compile a version of ffmpeg on snappy (building a snap), that will take advantage of the raspberry pi accelerated h264 decode/encoding. While doing this, I get MMAL not found by ffmpeg. This leads me to believe that MMAL is not present in snappy to compile against - this works perfectly on raspian. I can't find any deb package in apt that fixes this. So I think the root cause is that ubuntu core for RPI is not distributed the MMAL dev environment the same way that raspian is, and either I'm unaware/unable to find where to get those, or that they don't exist. On raspian they live under /opt/vc. Anyone know if I'm just missing something or if this is a "bug" in ubuntu core on rpi? Cheers, Anton From simos.lists at googlemail.com Tue Feb 7 08:16:24 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Tue, 7 Feb 2017 10:16:24 +0200 Subject: How to create a snap for how2 (stackoverflow from the terminal) in Ubuntu 16.04 Message-ID: Hi All, This is a complete tutorial on snapping "how2", a nodejs command-line tool that searches for you on StackOverflow, and just outputs what was selected as the correct answer. Being a nodejs program, it is messy to install with all the dependencies. So it was a very good candidate for snapping. There is a plugin for nodejs in snapcraft, so the whole process looks very easy to understand Also, the app only requires networking, so it is another example to only allow the "network" plug. Ideas for improvement and questions: 1. If we wanted to adapt the "network" plug to only allow access to specific IP addresses. etc, is it currently possible? 2. "how2" currently works over stackoverflow. It should be elemental to make it work over AskUbuntu. Link: https://blog.simos.info/how-to-create-a-snap-for-how2-stackoverflow-from-the-terminal-in-ubuntu-16-04/ HN submission: https://news.ycombinator.com/item?id=13587869 Simos From ogra at ubuntu.com Tue Feb 7 09:53:57 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 07 Feb 2017 10:53:57 +0100 Subject: the ppp interface (and general renaming/transitioning of interfaces) In-Reply-To: <20170206201416.GA23184@orwell.home> References: <1486388187.11948.15.camel@ubuntu.com> <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> <95d40fb9-4cec-7700-bb68-603e7e150fe2@canonical.com> <1486393610.11948.47.camel@ubuntu.com> <20170206201416.GA23184@orwell.home> Message-ID: <1486461237.11948.57.camel@ubuntu.com> hi, Am Montag, den 06.02.2017, 20:14 +0000 schrieb Jamie Bennett: > On 06/02/17 at 04:06P, Oliver Grawert wrote: > > > > hi, > > Am Montag, den 06.02.2017, 15:50 +0100 schrieb Simon Fels: > > > > > >   > > > I've just checked this and all pppd things are still in core. See > > > https://paste.ubuntu.com/23941360/ > > > > > wow, this is weird, yes, it is indeed still in there, i was 100% > > sure > > it was dropped together with the watchdog package when i got a ping > > from you guys to drop both after 15.04 ... but i just checked the > > respecting seed diff and noticed only watchdog was actually dropped > > ... > > > > so please ignore this ... > > > > yet, we probably still want an interface that allows access to > > console > > devices only. and also plan some process in case we need to rename > > interfaces if their backend changes. > Access to serial tty-only devices makes sense and a dedicated > interface makes > sense. note this is about tty not ttyS ... no serial involved just local console device access :) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Tue Feb 7 10:26:14 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 7 Feb 2017 10:26:14 +0000 Subject: license.txt and snap/ directory In-Reply-To: <87658715-83e8-5746-f6ca-165196463cb1@webdrake.net> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> <87658715-83e8-5746-f6ca-165196463cb1@webdrake.net> Message-ID: On Tue, 7 Feb 2017 01:46:04 +0100, Joseph Rushton Wakeling wrote: > On 07/02/17 00:24, Kyle Fazzari wrote: >> The fact that an empty directory is created here is a bug[1]. It should >> only create that directory if there's something to put in there. What >> Sergio is saying is this: >> >> Snapcraft-specific things, like hooks from snapcraft parts, command >> wrappers (eventually, not yet) will end up in the snap/ directory of the >> built snap. This has no bearing on the snap format, it's something >> internal to snapcraft (it could just as easily have chosen to place >> those things in the foo/ directory). >> >> The things in meta/ are specific to snapd. This directory is literally >> what defines "this random squashfs image" to be a snap. > > OK, makes sense. BTW, I hope I didn't come over as overly > negative in my reply > to Sergio: if so it wasn't intended. > > Can I however raise a plea that `meta/` should contain > licensing information as > a requirement? Even if it's not actively used by snapd right now, it makes > sense as a location and it would also make sense (in future) to > be able to do > things like > > snap license whatever > > to check the available licensing information. > > More generally, it seems like a good idea to me that (i) snap packages must > contain licensing information, (ii) it will be available in a standardized > location both in the snap package definition and the generated > snap package, and > (iii) this will be enforced/guaranteed by snapcraft. Can you log a bug against snapd? https://bugs.launchpad.net/snapd/+filebug -- Sent using Dekko from my Ubuntu device From timo.jyrinki at canonical.com Tue Feb 7 11:21:33 2017 From: timo.jyrinki at canonical.com (Timo Jyrinki) Date: Tue, 7 Feb 2017 13:21:33 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: On Wed, Feb 1, 2017 at 8:52 AM, Timo Jyrinki wrote: >>> Isn't this what Kyle fixed by adding build-attributes: [no-system-libraries] ? >>> >>> http://snapcraft.io/docs/build-snaps/syntax#parts >> >> Yes, that seems to be it, indeed. Thanks for the pointer Leo, I wasn’t >> aware of this new feature. With this, no need to artificially add >> stage packages. Neat! > > Excellent, thanks Leo and Kyle! Ok, Dekko is fixed in the store and I tested that the Terminal app would be fixed in bzr. Could someone with rights push a new build of ubuntu-terminal-app to the store, please? Is anyone aware of any other apps that print out "Cannot mix incompatible Qt library (version 0x50602) with this library (version 0x50601)" when tried to be started with the edge version of ubuntu-app-platform? If not, I will put the promotion of new ubuntu-app-platform to stable channel forward via QA later this week. -Timo From sunny.bhayani at einfochips.com Tue Feb 7 11:47:00 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Tue, 7 Feb 2017 11:47:00 +0000 Subject: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues In-Reply-To: <1486393109.11948.43.camel@ubuntu.com> References: , <1486393109.11948.43.camel@ubuntu.com> Message-ID: Hi Oliver, Please find our answers inline below: > hi, > Am Montag, den 06.02.2017, 14:09 +0000 schrieb Sunny Bhayani: > > > > > > > does lsmod show you the module for your wlan device loaded ? do > > you see > > > > > any errors in dmesg if you load it manually ? > > > > > > > lsmod just shows us the squashfs module. > > We manually tried to copy the Wifi kernel module (wcnss.ko) to the > > "/home" directory (by re-mounting the "/home" folder with read-write > > permissions) > > hmm, the home dir for the user you create using console-conf is > actually readwrite, you should not need to make anything writable, but > it might be fallout of a broken uboot.env setup (and missing kernel > cmdline args)... You are correct. Home directory is not required to remount in-order to copy files there. > > via scp, and did a insmod of the Wifi Module. It got inserted and we > > are able to see that in the lsmod. However, we are not getting the > > wlan0 interface when we use the ifconfig. Dmesg also does not show > > any initialization logs when the module is inserted. > > this is kind of weird, what if you include it properly in your kernel > snap instead ? We tried to put the wifi config define (CONFIG_USB_NET_WCN36XX) in the snapcraft.yaml and also in the kernel defconfig as '=y'. But still we do not see the Wifi initialization logs. > > > > if the image has not been initialized correctly using a signed > > model > > > > assertion snapd thinks you are on a classic install and tries to > > > > install a new core snap on top of the running system, this wont > > work > > > > unless the firstboot setup of snapd succeeded. > > > > We are successfully able to configure the firstboot screen and got > > the ssh login details. After that, we did ssh and configured the user > > password to login to the board natively. Will these steps suffice for > > the snapd to succeed ? > > no, that is just the user and network setup, the firstboot > initialization of snapd happens during the boot process, way before the > console-conf UI tool starts ... you should actually see (red flagged) > errors during boot on the console during boot if this bit fails. We did not see any errors related to snapd during the first time boot, when we get the console-conf UI. Please see the logs at: http://pastebin.com/h2eJG1yw It would be great if you can point to a snapd error in the above logs. > > > > > ISSUE 4: > > > > > We built the Dragonboard410c kernel source, Gadget snap and > > thereby created the Ubuntu OS snap. But when we boot the Ubuntu Core, > > we get this error: > > > > > http://pastebin.com/h2eJG1yw > > > > > > did you properly list the required firmware to be included with > > the > > > > initrd in the "kernel-initrd-fws:" option of your kernel snap > > > > snapcraft.yaml ? > > > > We have followed the below link for the Dragonboard Gadget snap and > > the uboot.env.in file: > > https://github.com/snapcore/dragonboard-gadget > > did you also regenerate the uboot.env file from the uboot.env.in file > as described in the README ? Yes. We have generated the uboot.env file from the uboot.env.in file as described in the https://github.com/snapcore/dragonboard-gadget link. > it does not look like all the bits from > the snappy_boot script are run to set the cmdline properly. > a typical snappy commmand line on a dragonboard looks like: > > ogra at dragon:~$ cat /proc/cmdline > androidboot.emmc=true androidboot.serialno=25af71aa > androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: > console=ttyMSM0,115200n8 console=tty0 root=/dev/disk/by-label/writable > net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc > snap_core=core_551.snap snap_kernel=dragonboard-kernel_16.snap > > (i.e. it is a lot longer) Our cat /proc/cmdline is below: androidboot.emmc=true androidboot.serialno=dae85161 androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: console=ttyMSM0,115200n8 console=tty0 root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snap_core=core_1118.snap snap_kernel=410boards-kernel_x1.snap The difference is in "androidboot.serialno", "snap_core" and the "snap_kernel" variables. Rest there is no difference. > it looks like the "setenv mmcroot" and "run mmcargs" commands in your > snappy_boot script do not get executed or your kernel does not want to > read them. this might be the source of all your problems and should be > the first thing to attack before you look at anything else. >From the cat /proc/cmdline output, it seems that the "setenv mmcroot" and "run mmcargs" commands from snappy_boot are executed correctly. Please share your views. Our uboot.env.in file is at: http://pastebin.com/aNrrVZif > (did you set something like CONFIG_CMDLINE_OVERRIDE or > CONFIG_CMDLINE_FORCE in your kernel config that would prevent it using > the bootloader cmdline at all ?) We confirmed from the kernel .config file, that the CONFIG_CMDLINE_OVERRIDE or CONFIG_CMDLINE_FORCE are not defined. The .config file is located at the below path: /parts/kernel/build/.config > > > > Our custom uboot.env.in file is at, which is also based on the above > > Dragonboard Gadget file: > > http://pastebin.com/1055z6UA > > > ... > > > > it might also be helpful to get a pointer to your kernel snap and > > > > gadget snap source. > > > > Yes. We followed the link that you have mentioned, and tried to > > provide different "gadget" and "kernel" names to the model assertion. > > But when we try to generate the Ubuntu OS Image, we get the below > > error: > > http://pastebin.com/fnR700Kr > > well, there seems to be a CRC error with one of your snaps or the > assertion ... > ... > eragon-kernel already prepared, skipping > error: bad CRC: 1869570677 != 1876078605 > ERROR:ubuntu-image:COMMAND FAILED: > ... We have tried to pull the 96boards Debian release 16.09 for Dragonboard from https://builds.96boards.org/releases/dragonboard410c/linaro/debian/16.09/. We tried to build the Ubuntu OS image by building the kernel snap (applied the AppArmour Patches) and gadget snap. But for the dragonboard also we are getting the above CRC error. So it would be great if you can give pointers to how the dragonboard pre-built image is built. We have followed the kernel snapcraft.yaml and the gadget snapcraft.yaml from this link: https://github.com/snapcore/dragonboard-gadget > > We have followed the below link to generate our snapcraft.yaml: > > http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ > > well, this blog post is nearly a year old i would suspect that the > kernel team made some changes to the kernel plugin meanwhile ... > perhaps someone from the kernel team can jump in here and take a look ? It would be great if you can also point us to someone who has built the kernel and gadget snap from the 96board website. We have found a new issue while building sources (kernel, gadget and Ubuntu Image) for Dragonboard. But we will post it in another thread, since this thread is already having other issues. Thanks, Sunny ________________________________ From: snapcraft-bounces at lists.snapcraft.io on behalf of Oliver Grawert Sent: Monday, February 6, 2017 8:28 PM To: Snapcraft Subject: Re: Custom Kernel and Gadged Snap Issue for Eragon410 board based on Dragonboard410c and other build related issues hi, Am Montag, den 06.02.2017, 14:09 +0000 schrieb Sunny Bhayani: > > > > > does lsmod show you the module for your wlan device loaded ? do > you see > > > > any errors in dmesg if you load it manually ? > > > > > lsmod just shows us the squashfs module. > We manually tried to copy the Wifi kernel module (wcnss.ko) to the > "/home" directory (by re-mounting the "/home" folder with read-write > permissions) hmm, the home dir for the user you create using console-conf is actually readwrite, you should not need to make anything writable, but it might be fallout of a broken uboot.env setup (and missing kernel cmdline args)... > via scp, and did a insmod of the Wifi Module. It got inserted and we > are able to see that in the lsmod. However, we are not getting the > wlan0 interface when we use the ifconfig. Dmesg also does not show > any initialization logs when the module is inserted. this is kind of weird, what if you include it properly in your kernel snap instead ? > > > if the image has not been initialized correctly using a signed > model > > > assertion snapd thinks you are on a classic install and tries to > > > install a new core snap on top of the running system, this wont > work > > > unless the firstboot setup of snapd succeeded. > > We are successfully able to configure the firstboot screen and got > the ssh login details. After that, we did ssh and configured the user > password to login to the board natively. Will these steps suffice for > the snapd to succeed ? no, that is just the user and network setup, the firstboot initialization of snapd happens during the boot process, way before the console-conf UI tool starts ... you should actually see (red flagged) errors during boot on the console during boot if this bit fails. > > > > > ISSUE 4: > > > > We built the Dragonboard410c kernel source, Gadget snap and > thereby created the Ubuntu OS snap. But when we boot the Ubuntu Core, > we get this error: > > > > http://pastebin.com/h2eJG1yw > > > > did you properly list the required firmware to be included with > the > > > initrd in the "kernel-initrd-fws:" option of your kernel snap > > > snapcraft.yaml ? > > We have followed the below link for the Dragonboard Gadget snap and > the uboot.env.in file: > https://github.com/snapcore/dragonboard-gadget did you also regenerate the uboot.env file from the uboot.env.in file as described in the README ? it does not look like all the bits from the snappy_boot script are run to set the cmdline properly. a typical snappy commmand line on a dragonboard looks like: ogra at dragon:~$ cat /proc/cmdline androidboot.emmc=true androidboot.serialno=25af71aa androidboot.baseband=apq mdss_mdp.panel=0:dsi:0: console=ttyMSM0,115200n8 console=tty0 root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc snap_core=core_551.snap snap_kernel=dragonboard-kernel_16.snap (i.e. it is a lot longer) it looks like the "setenv mmcroot" and "run mmcargs" commands in your snappy_boot script do not get executed or your kernel does not want to read them. this might be the source of all your problems and should be the first thing to attack before you look at anything else. (did you set something like CONFIG_CMDLINE_OVERRIDE or CONFIG_CMDLINE_FORCE in your kernel config that would prevent it using the bootloader cmdline at all ?) > > Our custom uboot.env.in file is at, which is also based on the above > Dragonboard Gadget file: > http://pastebin.com/1055z6UA > ... > > > it might also be helpful to get a pointer to your kernel snap and > > > gadget snap source. > > Yes. We followed the link that you have mentioned, and tried to > provide different "gadget" and "kernel" names to the model assertion. > But when we try to generate the Ubuntu OS Image, we get the below > error: > http://pastebin.com/fnR700Kr well, there seems to be a CRC error with one of your snaps or the assertion ... ... eragon-kernel already prepared, skipping error: bad CRC: 1869570677 != 1876078605 ERROR:ubuntu-image:COMMAND FAILED: ... > > We have followed the below link to generate our snapcraft.yaml: > http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/ well, this blog post is nearly a year old i would suspect that the kernel team made some changes to the kernel plugin meanwhile ... perhaps someone from the kernel team can jump in here and take a look ? ciao oli ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunny.bhayani at einfochips.com Tue Feb 7 12:36:37 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Tue, 7 Feb 2017 12:36:37 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support Message-ID: Hi, We are using Dragonboard410C to build kernel snap, gadget snap and Ubuntu OS Image. We got the linux kernel (Debian release 16.09) from: https://builds.96boards.org/releases/dragonboard410c/linaro/debian/16.09/ Kernel snapcraft.yaml is at: http://pastebin.com/DcPe1TT2 and the gadget from: https://github.com/snapcore/dragonboard-gadget Gadget gadget.yaml is at: http://pastebin.com/ciygRRfC Here we have done the below changes: - name, version and architecture changed to eragon. - after "volumes", changed the name to eragon. - changed the name of "sdappsboot.mdn" to "emmc_appsboot.mdn". Gadget snapcraft.yaml is at: http://pastebin.com/QcLFF319 Ubuntu OS Image Bootlog is at: http://pastebin.com/vwbMKPiS ISSUE 1: When we try to generate the Ubuntu OS Image, by giving the Kernel and Gadget snaps as input, we get the CRC error as below: ---- Error Start ---- 96boards-kernel already prepared, skipping error: bad CRC: 1869570677 != 1876078605 ERROR:ubuntu-image:COMMAND FAILED: ---- Error End ---- However, we are able to create the Ubuntu OS Image, if we rename our Gadget snap to "dragonboard_16.04-0.18_armhf.snap", and Kernel snap to "96boards-kernel_4.4.0_arm64.snap". ISSUE 2: Once we boot the above Ubuntu OS Image, and run "snap list", we get the below output: ---- Error Start ---- localhost:~$ snap list No snaps are installed yet. Try "snap install hello-world". ---- Error End ---- _OR_ we get the below output: ---- Error Start ---- localhost:~$ snap list error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: EOF ---- Error End ---- We get list of snaps (kernel, gadget, core), when we flash the pre-built Dragonboard Ubuntu Core image. ISSUE 3: We do not get any firmware files at: /lib/firmware We get list of firmware files when we flash the pre-built Dragonboard Ubuntu Core image. ISSUE 4: We do not get any kernel modules at: /lib/modules We get list of kernel modules when we flash the pre-built Dragonboard Ubuntu Core image. ISSUE 5: When we run "snap install hello-world", we get the below error: ---- Error Start ---- @localhost:~$ snap install hello-world error: cannot communicate with server: Post http://localhost/v2/snaps/hello-world: EOF ---- Error End ---- We can "snap install hello-world" when we flash the pre-built Dragonboard Ubuntu Core image. OBSERVATION(S): When we prepare the Linux Bootimage from the below 96boards source for Dragonboard410c: https://builds.96boards.org/releases/dragonboard410c/linaro/debian/16.09/ we are able to get the Ethernet, Wifi properly. But when we use the same kernel source to generate the Ubuntu OS Image, we see the above mentioned ISSUES(S). Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From simos.lists at googlemail.com Tue Feb 7 13:05:37 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Tue, 7 Feb 2017 15:05:37 +0200 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> References: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> Message-ID: On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche wrote: > Le 06/02/2017 à 10:56, Simos Xenitellis a écrit : >> Hi All, >> >> I wrote an article about creating a snap for an existing Python >> program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu >> Store. >> >> I am looking forward to receiving feedback :-) >> >> Link: https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ >> >> Link to HN submission: https://news.ycombinator.com/item?id=13578034 >> >> Simos >> > Excellent work Simos! > > I think this kind of content would make an excellent official "pratical" > tutorials on https://tutorials.ubuntu.com. Are you interested into > contributing there? > > If you want more context on tutorials, the phisolophy and how to > contribute, I wrote a blog post some time ago about it: > https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/. > > I'm also available for any help, Thanks Didier! I had a look at https://github.com/ubuntudesign/tutorials.ubuntu.com/issues and the direction that tutorials.ubuntu.com wants to take. It looks good. It requires planning in terms of the writing of the tutorials so that they are gradually incremental, and some basic tutorials can referenced by the more complex ones. It's a lot of dedicated work. I'll give it a go and try to write a couple of tutorials for tutorials.ubuntu.com. We will see how it goes :-) I think I'll start with the baseline tutorial for snapcraft. Simos From simos.lists at googlemail.com Tue Feb 7 13:11:33 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Tue, 7 Feb 2017 15:11:33 +0200 Subject: How to create a snap with snapcraft for howdoi (CLI utilility for stackoverflow) Message-ID: Hi All! This is another tutorial for snapcraft. It reinforces the content of the previous how2 tutorial since they are both for similar tools, that require only the "network" plug. No GUI complexities yet. It's quite simple and helps to deal now with package management details on the Ubuntu Store. To run howdoi, $ snap install howdoi $ howdoi how to format the date in bash DATE=`date +%Y-%m-%d` Link: https://blog.simos.info/how-to-create-a-snap-with-snapcraft-for-howdoi-cli-utilility-for-stackoverflow/ Simos From didrocks at ubuntu.com Tue Feb 7 13:54:16 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Tue, 7 Feb 2017 14:54:16 +0100 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: References: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> Message-ID: <0dc231f8-26fc-d929-faef-7f28e1b8850d@ubuntu.com> Le 07/02/2017 à 14:05, Simos Xenitellis a écrit : > On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche wrote: >> Le 06/02/2017 à 10:56, Simos Xenitellis a écrit : >>> Hi All, >>> >>> I wrote an article about creating a snap for an existing Python >>> program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu >>> Store. >>> >>> I am looking forward to receiving feedback :-) >>> >>> Link: https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ >>> >>> Link to HN submission: https://news.ycombinator.com/item?id=13578034 >>> >>> Simos >>> >> Excellent work Simos! >> >> I think this kind of content would make an excellent official "pratical" >> tutorials on https://tutorials.ubuntu.com. Are you interested into >> contributing there? >> >> If you want more context on tutorials, the phisolophy and how to >> contribute, I wrote a blog post some time ago about it: >> https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/. >> >> I'm also available for any help, > Thanks Didier! > > I had a look at https://github.com/ubuntudesign/tutorials.ubuntu.com/issues > and the direction that tutorials.ubuntu.com wants to take. It looks good. > It requires planning in terms of the writing of the tutorials so that > they are gradually incremental, > and some basic tutorials can referenced by the more complex ones. It's > a lot of dedicated work. > > I'll give it a go and try to write a couple of tutorials for > tutorials.ubuntu.com. We will see how it goes :-) > I think I'll start with the baseline tutorial for snapcraft. Excellent news! You can as well convert some of yours to this format! I give you the direct link to the guidelines to have some coherences between the tutorials in term of tones and content: https://docs.google.com/document/d/1u5qmSNIcE8SjuAg6aKjTxOBGWIjBW0kYf01t4Dfw6-U/edit. Keep in touch! Cheers, Didier From jamie at canonical.com Tue Feb 7 13:58:12 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 07 Feb 2017 07:58:12 -0600 Subject: Snap security questions In-Reply-To: <1485960368.10013.235.camel@canonical.com> References: <1485960368.10013.235.camel@canonical.com> Message-ID: <1486475892.3367.3.camel@canonical.com> On Wed, 2017-02-01 at 08:46 -0600, Jamie Strandboge wrote: > On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote: > > > > Hi, > > > > On our team we've been working to snap the thumbnailer project.  While > > there are some problems that are probably specific to this package, > > there were a few that I suspect might affect other packages too: > > > > 1. Intra-snap D-Bus communication > > > > The thumbnailer D-Bus service exposes a number of methods that were > > intended for use by the "thumbnailer-admin" helper program, but not by > > outside clients.  The generic "dbus" snappy interface does a good job > > of making sure clients can't call these privileged methods, but I'm > > left needing a way to get thumbnailer-admin working again. > > > > I noticed that the default AppArmor rules allow communication via unix > > domain sockets with other apps from the same snap, so one easy way to > > solve my problem would be to also allow applications to send and > > receive arbitrary messages over the session bus to/from other > > applications from the same snap.  This would let me get > > thumbnailer-admin working without having to expose the same abilities > > to third party snaps through a slot. > > > > I filed a bug about this one here: > > > > https://bugs.launchpad.net/snappy/+bug/1659724 > > > I was thinking about this one myself. Thanks for filing the bug. I've assigned > it to me. > This is merged in trunk and will be in snapd 2.23. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kyle.nitzsche at canonical.com Tue Feb 7 14:36:40 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Tue, 7 Feb 2017 09:36:40 -0500 Subject: connecting a non-auto interface, automatically Message-ID: <3cd689a6-cb72-1563-a054-292af2a0a49c@canonical.com> What is the approach to connect interfaces that are not auto-connecting without user intervention? That is, there's a snap (built into an image) that declares the log-observe plug. Log-observe interface does not auto-connect [1]. In this product, the user does not have a console, so they cannot connect the snap plug/interface. So, how does one configure the system to connect sthis? Via the gadget snap prepare-device hook script perhaps? Cheers, kyleN [1] https://docs.ubuntu.com/core/en/reference/interfaces/index From simon.fels at canonical.com Tue Feb 7 14:40:48 2017 From: simon.fels at canonical.com (Simon Fels) Date: Tue, 7 Feb 2017 15:40:48 +0100 Subject: [System Enablement] New releases Feb 2017 Message-ID: Hey everyone, new releases of the alsa-utils, network-manager, upower and wifi-ap snaps were pushed into the candidate channel. alsa-utils 1.1.2-2: * First official release supported by Canonical * Aliases for all exported commands are available * Set of automated and manual test cases guarantee quality of each release network-manager 1.2.2-11: * Wake-on-WLAN can be configured via snap confiration / nmcli * Automatic reconfiguration of network devices when devices wakes up * Alias support for nmcli command * WiFi powersave is now configurable via snap configuration * Network-Manager tests are using tests-extras repository to fetch the image creating scripts rather than embed them. upower 0.99.4-2: * First release * Integration with systemd to suspend the system on low battery events wifi-ap 13: * Configuration command accepts multiple key/value pairs * AP can be disabled on installation via configuration option --- An overview of which revisions / versions of the particular snaps are available in which channel is available at https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# The snaps have passed our engineering QA and will now be tested by the platform and commercial QA teams before the new versions are pushed to the stable channel. Bileto requests are: - alsa-utils: https://bileto.ubuntu.com/#/ticket/2441 - network-manager: https://bileto.ubuntu.com/#/ticket/2442 - upower: https://bileto.ubuntu.com/#/ticket/2445 - wifi-ap: https://bileto.ubuntu.com/#/ticket/2444 If you have any questions feel free to ping me. regards, Simon From simon.fels at canonical.com Tue Feb 7 14:43:03 2017 From: simon.fels at canonical.com (Simon Fels) Date: Tue, 7 Feb 2017 15:43:03 +0100 Subject: connecting a non-auto interface, automatically In-Reply-To: <3cd689a6-cb72-1563-a054-292af2a0a49c@canonical.com> References: <3cd689a6-cb72-1563-a054-292af2a0a49c@canonical.com> Message-ID: On 07.02.2017 15:36, knitzsche wrote: > What is the approach to connect interfaces that are not auto-connecting > without user intervention? > > That is, there's a snap (built into an image) that declares the > log-observe plug. Log-observe interface does not auto-connect [1]. In > this product, the user does not have a console, so they cannot connect > the snap plug/interface. > > So, how does one configure the system to connect sthis? Via the gadget > snap prepare-device hook script perhaps? You can ask at the store level to get a snap-declaration for the snap which allows auto-connection of particular plugs just for your snap. I am not sure if this can be store/brand/model specific. regards, Simon From ted at ubuntu.com Tue Feb 7 14:52:51 2017 From: ted at ubuntu.com (Ted Gould) Date: Tue, 07 Feb 2017 08:52:51 -0600 Subject: snapcraft 2.26 has been released In-Reply-To: References: Message-ID: <1486479171.28239.7.camel@ubuntu.com> On Fri, 2017-02-03 at 08:57 -0300, Sergio Schvezov wrote: > We are pleased to announce the release of version `2.26` of snapcraft > has been released: > https://launchpad.net/snapcraft/+milestone/2.26 Lots of cool stuff landing in Snapcraft. Can we get a "snapcraft- version" key in the snapcraft.yaml file? When I use the newer features people who have the old version get a schema error. I'd rather they get something like "Snapcraft 2.26 required" so they know how to fix it. Thanks, Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From florian.boucault at canonical.com Tue Feb 7 15:00:45 2017 From: florian.boucault at canonical.com (Florian Boucault) Date: Tue, 07 Feb 2017 15:00:45 +0000 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: Hey Timo and al, I thought I fixed the terminal last week. At least the terminal available on the edge channel now is working for me. Does it work for you? I made sure that the stage-packages only contain packages that are not in ubuntu-app-platform and also used build-attributes: [no-system-libraries] Florian Le mar. 7 févr. 2017 à 12:22, Timo Jyrinki a écrit : > On Wed, Feb 1, 2017 at 8:52 AM, Timo Jyrinki > wrote: > >>> Isn't this what Kyle fixed by adding build-attributes: > [no-system-libraries] ? > >>> > >>> http://snapcraft.io/docs/build-snaps/syntax#parts > >> > >> Yes, that seems to be it, indeed. Thanks for the pointer Leo, I wasn’t > >> aware of this new feature. With this, no need to artificially add > >> stage packages. Neat! > > > > Excellent, thanks Leo and Kyle! > > Ok, Dekko is fixed in the store and I tested that the Terminal app > would be fixed in bzr. Could someone with rights push a new build of > ubuntu-terminal-app to the store, please? > > Is anyone aware of any other apps that print out "Cannot mix > incompatible Qt library (version 0x50602) with this library (version > 0x50601)" when tried to be started with the edge version of > ubuntu-app-platform? If not, I will put the promotion of new > ubuntu-app-platform to stable channel forward via QA later this week. > > -Timo > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Tue Feb 7 15:05:36 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 7 Feb 2017 15:05:36 +0000 Subject: connecting a non-auto interface, automatically In-Reply-To: References: <3cd689a6-cb72-1563-a054-292af2a0a49c@canonical.com> Message-ID: <4d05c225-adc4-9533-4122-399ea64006bf@ubuntu.com> On 07/02/17 14:43, Simon Fels wrote: > On 07.02.2017 15:36, knitzsche wrote: >> What is the approach to connect interfaces that are not auto-connecting >> without user intervention? >> >> That is, there's a snap (built into an image) that declares the >> log-observe plug. Log-observe interface does not auto-connect [1]. In >> this product, the user does not have a console, so they cannot connect >> the snap plug/interface. >> >> So, how does one configure the system to connect sthis? Via the gadget >> snap prepare-device hook script perhaps? > You can ask at the store level to get a snap-declaration for the snap > which allows auto-connection of particular plugs just for your snap. > > I am not sure if this can be store/brand/model specific. ...and IIRC the intent is that the gadget snap should allow you to specify this behavior on your own device, regardless of store policy. In short: * if you made the device, you decide * if you own the device (you have root), you decide * otherwise, the store sets default behavior Mark From leo.arias at canonical.com Tue Feb 7 15:06:49 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 7 Feb 2017 09:06:49 -0600 Subject: snapcraft 2.26 has been released In-Reply-To: <1486479171.28239.7.camel@ubuntu.com> References: <1486479171.28239.7.camel@ubuntu.com> Message-ID: On Tue, Feb 7, 2017 at 8:52 AM, Ted Gould wrote: > On Fri, 2017-02-03 at 08:57 -0300, Sergio Schvezov wrote: > > We are pleased to announce the release of version `2.26` of snapcraft has > been released: > https://launchpad.net/snapcraft/+milestone/2.26 > > > Lots of cool stuff landing in Snapcraft. Can we get a "snapcraft-version" > key in the snapcraft.yaml file? When I use the newer features people who > have the old version get a schema error. I'd rather they get something like > "Snapcraft 2.26 required" so they know how to fix it. +1. Can you please report a bug so we discuss it there? -- ¡paz y baile! http://www.ubuntu.com From alan.pope at canonical.com Tue Feb 7 16:07:03 2017 From: alan.pope at canonical.com (Alan Pope) Date: Tue, 7 Feb 2017 16:07:03 +0000 Subject: Building for different architectures Message-ID: Hi, Suppose I have a snap which requires a couple of non-archive debs as stage packages. Typically I'd have a part for each which uses the source: of a url directly to the deb using the dump plugin. This works fine building on my amd64 laptop (or wherever) and I end up with an amd64 snap. However, if I get a request for an i386 (or indeed armhf) snap, it will break because my i386 snapcraft run will pull an amd64 deb. If I was pulling archive packages then of course the build can run in launchpad and it will do the Right Thing. However, if my yaml contains hard coded arch-specific (non-archive) debs, that breaks, pulling in amd64 deb on an i386 builder. I could have separate yamls per arch of course, but that seems needlessly messy. What have others done in this case? Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From jamie at canonical.com Tue Feb 7 16:07:35 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 07 Feb 2017 10:07:35 -0600 Subject: Which interface exposes user folder to root In-Reply-To: References: <1486403446.26371.33.camel@canonical.com> Message-ID: <1486483655.3367.27.camel@canonical.com> On Tue, 2017-02-07 at 12:27 +0800, Tonny Tzeng wrote: > Hi Jamie, > > Thanks for the detailed explanation, it's really helpful! > > However, I am hesitated to package my example files in the snap, just > curious, what's the proper way to package a "development snap" which reads > user given files and requires root permission? For example, I'd like to > package necessary node.js components in a snap for developers to design > their node.js based BLE apps, I've add node, bleno and noble modules in a > snap, so the idea is to let the users create their own node.js sample apps > (under their $HOME) and invoke the node command in my snap to run their > sample apps. Since the bleno/noble node modules require root privilege for > accessing BLE, I used "sudo mysnap.node " to run the > snap command. But as you pointed out, the fsuid=0 but ouid=1000 which > prevents the sample file being read from the snap command? As mentioned before: "In general, it is best practice to avoid processing files that are under another user's control since those files could potentially be used to alter the behavior of the running process" If the user experience must be what you described where the files must live in the user's home and the command accessing them must run as root, then you can do: $ sudo chown -R root:root  $ sudo mysnap.node Alternatively, create a shared directory in SNAP_DATA. Eg: $ sudo mkdir -m 1777 /var/snap/mysnap/current/examples # this could be done by your snap $ ln -s /var/snap/mysnap/current/examples $ sudo mysnap.node Alternatively, you can change how you think about this and you can put the files in /root/ and use 'sudo -H'. Alternatively, you can change the work flow and do: $ sudo mkdir -m 1777 /var/snap/mysnap/current/examples # this could be done by your snap $ sudo mysnap.node Lastly, one thing I'm working on is how to allow dropping privileges. Once this is in place you could adjust 'mysnap.node' to drop privileges to the real user to read/copy/whatever the files such that this works: $ sudo mysnap.node -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Tue Feb 7 16:20:50 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 07 Feb 2017 17:20:50 +0100 Subject: Building for different architectures In-Reply-To: References: Message-ID: <1486484450.30264.1.camel@ubuntu.com> hi, On Di, 2017-02-07 at 16:07 +0000, Alan Pope wrote: > Hi, > > Suppose I have a snap which requires a couple of non-archive debs as > stage packages. Typically I'd have a part for each which uses the > source: of a url directly to the deb using the dump plugin. This > works > fine building on my amd64 laptop (or wherever) and I end up with an > amd64 snap. > > However, if I get a request for an i386 (or indeed armhf) snap, it > will break because my i386 snapcraft run will pull an amd64 deb. If I > was pulling archive packages then of course the build can run in > launchpad and it will do the Right Thing. However, if my yaml > contains > hard coded arch-specific (non-archive) debs, that breaks, pulling in > amd64 deb on an i386 builder. > > I could have separate yamls per arch of course, but that seems > needlessly messy. What have others done in this case? > do you mean https://bugs.launchpad.net/snapcraft/+bug/1655797 ? looks like is was just fixed last week though... not sure how/if that works for "non-archive debs" though ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Tue Feb 7 16:21:02 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 07 Feb 2017 10:21:02 -0600 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: References: <1486205037.11948.2.camel@ubuntu.com> <1486401702.26371.11.camel@canonical.com> Message-ID: <1486484462.3367.32.camel@canonical.com> On Tue, 2017-02-07 at 12:04 +0800, XiaoGuo Liu wrote: > Hi Jamie, > > For my sample app at https://github.com/liu-xiao-guo/helloworld-fifo, I > tried to use the /tmp file to create a file, and  finally I get a file on > my Desktop like: > > root at liuxg:/tmp/snap.1000_snap.hello.fifo_TovLTW/tmp# ls > anothefile > > It seems to me that the path is still related to the command name "fifo". > Does this conflict with your saying? It does not. That directory is what is bind mounted into mount namespace and that is remembered for subsequent invocations of that command or other commands from the same snap. Try it: create a snap with two commands, have one create a file in /tmp and another to read the same file in /tmp-- it will work and the temporary directory in the system's /tmp will be /tmp/snap.0_snap.$SNAP_NAME._... will have the file you created in it. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kyle.fazzari at canonical.com Tue Feb 7 16:28:22 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 7 Feb 2017 08:28:22 -0800 Subject: Building for different architectures In-Reply-To: <1486484450.30264.1.camel@ubuntu.com> References: <1486484450.30264.1.camel@ubuntu.com> Message-ID: On 02/07/2017 08:20 AM, Oliver Grawert wrote: > hi, > On Di, 2017-02-07 at 16:07 +0000, Alan Pope wrote: >> Hi, >> >> Suppose I have a snap which requires a couple of non-archive debs as >> stage packages. Typically I'd have a part for each which uses the >> source: of a url directly to the deb using the dump plugin. This >> works >> fine building on my amd64 laptop (or wherever) and I end up with an >> amd64 snap. >> >> However, if I get a request for an i386 (or indeed armhf) snap, it >> will break because my i386 snapcraft run will pull an amd64 deb. If I >> was pulling archive packages then of course the build can run in >> launchpad and it will do the Right Thing. However, if my yaml >> contains >> hard coded arch-specific (non-archive) debs, that breaks, pulling in >> amd64 deb on an i386 builder. >> >> I could have separate yamls per arch of course, but that seems >> needlessly messy. What have others done in this case? >> > do you mean https://bugs.launchpad.net/snapcraft/+bug/1655797 ? > looks like is was just fixed last week though... > not sure how/if that works for "non-archive debs" though It doesn't, I'm afraid. That fix (and another coming soon[1]) are specific to stage-packages, whereas it sounds like popey is using `source` directly. I don't think there's a way to do this today, but we were discussing implementing something similar for sources in the future. [1]: https://github.com/snapcore/snapcraft/pull/1059 -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sergio.schvezov at canonical.com Tue Feb 7 16:33:36 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 7 Feb 2017 13:33:36 -0300 Subject: Building for different architectures In-Reply-To: References: Message-ID: On Tue, Feb 7, 2017 at 1:07 PM, Alan Pope wrote: > Hi, > > Suppose I have a snap which requires a couple of non-archive debs as > stage packages. Typically I'd have a part for each which uses the > source: of a url directly to the deb using the dump plugin. This works > fine building on my amd64 laptop (or wherever) and I end up with an > amd64 snap. > > However, if I get a request for an i386 (or indeed armhf) snap, it > will break because my i386 snapcraft run will pull an amd64 deb. If I > was pulling archive packages then of course the build can run in > launchpad and it will do the Right Thing. However, if my yaml contains > hard coded arch-specific (non-archive) debs, that breaks, pulling in > amd64 deb on an i386 builder. > > I could have separate yamls per arch of course, but that seems > needlessly messy. What have others done in this case? > I am wanting to support the new stage-packages grammar for sources as well (still not agreed upon though). Take a look at https://github.com/snapcore/snapcraft/pull/1059 for how it would look like -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Tue Feb 7 16:34:24 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 7 Feb 2017 13:34:24 -0300 Subject: Building for different architectures In-Reply-To: <1486484450.30264.1.camel@ubuntu.com> References: <1486484450.30264.1.camel@ubuntu.com> Message-ID: On Tue, Feb 7, 2017 at 1:20 PM, Oliver Grawert wrote: > hi, > On Di, 2017-02-07 at 16:07 +0000, Alan Pope wrote: > > Hi, > > > > Suppose I have a snap which requires a couple of non-archive debs as > > stage packages. Typically I'd have a part for each which uses the > > source: of a url directly to the deb using the dump plugin. This > > works > > fine building on my amd64 laptop (or wherever) and I end up with an > > amd64 snap. > > > > However, if I get a request for an i386 (or indeed armhf) snap, it > > will break because my i386 snapcraft run will pull an amd64 deb. If I > > was pulling archive packages then of course the build can run in > > launchpad and it will do the Right Thing. However, if my yaml > > contains > > hard coded arch-specific (non-archive) debs, that breaks, pulling in > > amd64 deb on an i386 builder. > > > > I could have separate yamls per arch of course, but that seems > > needlessly messy. What have others done in this case? > > > do you mean https://bugs.launchpad.net/snapcraft/+bug/1655797 ? > looks like is was just fixed last week though... > not sure how/if that works for "non-archive debs" though > This is somewhat different, the bugfix there was about bringing in other arches for current arch ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.pope at canonical.com Tue Feb 7 16:43:50 2017 From: alan.pope at canonical.com (Alan Pope) Date: Tue, 7 Feb 2017 16:43:50 +0000 Subject: Building for different architectures In-Reply-To: References: <1486484450.30264.1.camel@ubuntu.com> Message-ID: Hi Kyle, On 7 February 2017 at 16:28, Kyle Fazzari wrote: > It doesn't, I'm afraid. That fix (and another coming soon[1]) are > specific to stage-packages, whereas it sounds like popey is using > `source` directly. I don't think there's a way to do this today, but we > were discussing implementing something similar for sources in the future. > That is what I am after, sorry if it was unclear. > [1]: https://github.com/snapcore/snapcraft/pull/1059 > That does look like the kind of thing I'm after, thanks. Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From gustavo.niemeyer at canonical.com Tue Feb 7 18:55:34 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Tue, 7 Feb 2017 16:55:34 -0200 Subject: Spread Tests with proxy (mostly go get) In-Reply-To: References: Message-ID: Hi Max, The problem isn't spread itself, as it won't try to communicate out of the host by itself. The problem is that snapd's test suite expects to be able to talk to the network. Someone would have to go through and fix all such cases to go through the proxy, which is perhaps more troubling than connecting the VM itself into the network? On Mon, Jan 23, 2017 at 8:01 PM, Max Brustkern wrote: > I'm trying to run spread tests on an ubuntu core VM in a lab that needs to > use a proxy for web access. The mirrors are redirected, so the package > installations work as expected, but I run into problems with go get: > > ++ classic 'GOPATH=/home/gopath go get ../../home/gopath/src/github.c > om/snapcore/snapd/tests/lib/snapbuild' > Cannot determine calling user, logging into classic as root > mount: devpts is already mounted or /dev/pts busy > devpts is already mounted on /dev/pts > package gopkg.in/yaml.v2: unrecognized import path "gopkg.in/yaml.v2" > (https fetch: Get https://gopkg.in/yaml.v2?go-get=1: dial tcp > 45.33.69.124:443: i/o timeout) > package gopkg.in/check.v1: unrecognized import path "gopkg.in/check.v1" > (https fetch: Get https://gopkg.in/check.v1?go-get=1: dial tcp > 45.33.69.124:443: i/o timeout) > ++ sysctl -w net.ipv6.conf.all.disable_ipv6=0 > net.ipv6.conf.all.disable_ipv6 = 0 > ----- > 2017/01/23 16:46:54 Restoring project on external:ubuntu-core-16-64... > 2017/01/23 16:46:55 Successful tasks: 0 > 2017/01/23 16:46:55 Aborted tasks: 107 > 2017/01/23 16:46:55 Failed project prepare: 1 > - external:ubuntu-core-16-64:project > 2017/01/23 16:46:55 Keeping external:ubuntu-core-16-64 at 127.0.0.1:54323 > error: unsuccessful run > > I'm using the following spread commands to run on the local VM: > export SPREAD_EXTERNAL_ADDRESS=127.0.0.1:$PORT > ./tests/lib/external/prepare-ssh.sh 127.0.0.1 $PORT $USER > spread -v -reuse external:ubuntu-core-16-64 | tee $WORKSPACE/spread-output > > How should I configure spread to make go aware of the proxy? > > Thanks, > Max > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.voss at canonical.com Tue Feb 7 20:17:43 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Tue, 7 Feb 2017 21:17:43 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: <20170202073818.b2heyissfeo2tulw@x250> References: <20170202073818.b2heyissfeo2tulw@x250> Message-ID: https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 was released to the updates pocket today. Cheers, Thomas On Thu, Feb 2, 2017 at 8:38 AM, Thomas Voß wrote: > On Thu, Feb 02, 2017 at 12:51:59AM +0100, Joseph Rushton Wakeling wrote: >> On 31/01/17 14:01, Jamie Bennett wrote: >> > Hi, >> > >> > The team are pleased to announce that, after extensive testing in proposed, snapd is officially available in the Trusty Tahr updates archive [1]. If you are running a 14.04 system we encourage you to give it a try and report any issues [2]. Thanks to all involved in making this happen. >> > >> > Regards, >> > Jamie. >> > >> > [1] https://launchpad.net/ubuntu/trusty/+source/snapd >> > [2] https://bugs.launchpad.net/ubuntu/+source/snapd >> >> I tried this earlier today on a Trusty machine and ran into some >> difficulties installing. `sudo apt install snapd` resulted in the following >> error message: >> >> snapd: Depends: systemd (>= 204-5ubuntu20.20) but it is not going to be >> installed >> >> Attempting to install systemd directly (to work out what was wrong) resulted >> in something similar: >> >> gnome-control-center: Depends: libcheese-gtk23 (>= 3.4.0) but it is not >> going to be installed >> libcheese7 (>= 3.0.1) ... >> >> ubuntu-control-center: Depends: libcheese-gtk23 (>= 3.4.0) ... >> libcheese7 (>= 3.0.1) ... >> >> Any thoughts on what could be wrong here? >> > > Yup, you are hit by the issue described in here: > > http://askubuntu.com/questions/878750/snapd-package-conflicts-with-xorg-packages/878770#878770 > > In summary, we are waiting for an SRU (see [1]) for the xorg xenial lts stack to > arrive in -updates. The short term fix is to enable -proposed. If that > does not solve your issue, please report a bug against > https://launchpad.net/snapd tagging it with trusty. > > Thanks for trying out snapd on trusty, > > Thomas > > [1] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1619142 > >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From mark at ubuntu.com Tue Feb 7 20:36:48 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 7 Feb 2017 20:36:48 +0000 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> Message-ID: On 07/02/17 20:17, Thomas Voß wrote: > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 > was released to the updates pocket today. Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, cloud or desktop, would be welcome. Pick a favorite snap and take it for a spin. Mark From manik at canonical.com Tue Feb 7 21:31:30 2017 From: manik at canonical.com (Manik Taneja) Date: Tue, 7 Feb 2017 13:31:30 -0800 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> Message-ID: On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth wrote: > On 07/02/17 20:17, Thomas Voß wrote: > > https://bugs.launchpad.net/ubuntu/+source/xorg-server- > lts-xenial/+bug/1655724 > > was released to the updates pocket today. > > Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, > cloud or desktop, would be welcome. Pick a favorite snap and take it for > a spin. > The experience is very clean now. I just tried on AWS and have RocketChat up and running- [image: Inline image 1] Kudos to everyone involved in delivering this! Cheers, Manik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 86667 bytes Desc: not available URL: From mark at ubuntu.com Tue Feb 7 21:52:51 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 7 Feb 2017 21:52:51 +0000 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> Message-ID: On 07/02/17 21:31, Manik Taneja wrote: > > > On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth > wrote: > > On 07/02/17 20:17, Thomas Voß wrote: > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 > > > was released to the updates pocket today. > > Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, > cloud or desktop, would be welcome. Pick a favorite snap and take > it for > a spin. > > The experience is very clean now. I just tried on AWS and have > RocketChat up and > running- > > Inline image 1 > Kudos to everyone involved in delivering this! > Also my favorite snap :) Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 86667 bytes Desc: not available URL: From xiaoguo.liu at canonical.com Wed Feb 8 01:27:54 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 8 Feb 2017 09:27:54 +0800 Subject: Where to save stuff (in snap-agnostic way) In-Reply-To: <1486484462.3367.32.camel@canonical.com> References: <1486205037.11948.2.camel@ubuntu.com> <1486401702.26371.11.camel@canonical.com> <1486484462.3367.32.camel@canonical.com> Message-ID: Hi Jamie, Thanks for your explanation. You are right. The directory name takes the very first execution of the command. After that, when accessing the /tmp directory, it uses the directory created earlier if it is running from another command. I have updated my example code at https://github.com/liu-xiao-guo/helloworld-fifo When I firstly run "hello.fifo", the directory name takes something "like snap.1000_snap.hello.fifo_5BpMiB". When trying to write to it using "hello.fifo1", the same directory is used. When I firstly run "hello.fifo1", the directory name takes something "snap.1000_snap.hello.fifo1_6MJX5m". When trying to write to it using "hello.fifo", the same directory is used. Thanks & best regards, XiaoGuo On Wed, Feb 8, 2017 at 12:21 AM, Jamie Strandboge wrote: > On Tue, 2017-02-07 at 12:04 +0800, XiaoGuo Liu wrote: > > Hi Jamie, > > > > For my sample app at https://github.com/liu-xiao-guo/helloworld-fifo, I > > tried to use the /tmp file to create a file, and finally I get a file on > > my Desktop like: > > > > root at liuxg:/tmp/snap.1000_snap.hello.fifo_TovLTW/tmp# ls > > anothefile > > > > It seems to me that the path is still related to the command name "fifo". > > Does this conflict with your saying? > > It does not. That directory is what is bind mounted into mount namespace > and > that is remembered for subsequent invocations of that command or other > commands > from the same snap. Try it: create a snap with two commands, have one > create a > file in /tmp and another to read the same file in /tmp-- it will work and > the > temporary directory in the system's /tmp will be > /tmp/snap.0_snap.$SNAP_NAME._... will have the > file you > created in it. > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From pengliu.mail at gmail.com Wed Feb 8 03:43:38 2017 From: pengliu.mail at gmail.com (Peng Liu) Date: Tue, 7 Feb 2017 21:43:38 -0600 Subject: Error to call "docker" command in a snap Message-ID: Hi Folks, I built a snap which needs to call "docker" command instead of using bindings like docker-py to get logs from a container. Unfortunately, the command reported an error with messages "support process for mount namespace capture exited abnormally". >From the snap, I can use docker-py to do the similar thing successfully. I can also login to the machine with the all-snap image including docker snap and run "docker" command successfully. What could be the root cause that I can not run "docker" command inside my snap? Thanks. Peng -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.arnold at canonical.com Wed Feb 8 03:46:28 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Tue, 7 Feb 2017 19:46:28 -0800 Subject: Error to call "docker" command in a snap In-Reply-To: References: Message-ID: <20170208034628.GE18682@hunt> On Tue, Feb 07, 2017 at 09:43:38PM -0600, Peng Liu wrote: > I built a snap which needs to call "docker" command instead of using > bindings like docker-py to get logs from a container. Unfortunately, the > command reported an error with messages "support process for mount > namespace capture exited abnormally". Are there any hints in dmesg or more detailed log files that might provide a direction to start looking? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From pengliu.mail at gmail.com Wed Feb 8 03:56:04 2017 From: pengliu.mail at gmail.com (Peng Liu) Date: Tue, 7 Feb 2017 21:56:04 -0600 Subject: Error to call "docker" command in a snap In-Reply-To: <20170208034628.GE18682@hunt> References: <20170208034628.GE18682@hunt> Message-ID: Hi Seth, Yes, thanks for your reminder. I found a kernel panic! The logs are below: ============================================================ [ 3629.333366] audit: type=1400 audit(1486525969.972:2717): apparmor="ALLOWED" operation="create" profile="snap.paradrop-daemon.paradrop//null-/usr/bin/snap" pid=2475 comm="docker" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create" [ 3629.712878] BUG: unable to handle kernel paging request at fffffffffffffff3 [ 3629.796735] IP: [] strlen+0x0/0x20 [ 3629.856430] *PGD 1e0d067 PUD 1e0f067 PMD 0 * [ 3629.906140] Oops*: 0000 [#4] SMP * [ 3629.945243] Modules linked in*: xt_nat xt_tcpudp veth xt_comment ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc overlay aufs arc4 ath10k_pci ath9k ath10k_core ath9k_common ath9k_hw ath mac80211 kvm_amd kvm uas irqbypass cfg80211 k10temp sp5100_tco r8169 i2c_piix4 mii shpchp mac_hid iptable_filter ip_tables ip6table_filter ip6_tables x_tables autofs4 mmc_block sdhci_acpi sdhci_pci sdhci virtio_scsi nls_iso8859_1 usb_storage ahci libahci* [ 3630.543640] CPU*: 0 PID: 2479 Comm: snap-confine Tainted: G D 4.4.0-59-generic #80-Ubuntu* [ 3630.654077] Hardware name*: PC Engines APU/APU, BIOS 4.0 09/08/2014* [ 3630.728123] task*: ffff88007a338000 ti: ffff88007a388000 task.ti: ffff88007a388000* [ 3630.817768] RIP*: 0010:[] [] strlen+0x0/0x20* [ 3630.906581] RSP*: 0018:ffff88007a38ba20 EFLAGS: 00010246* [ 3630.970226] RAX*: ffff88007a38bb20 RBX: fffffffffffffff3 RCX: 0000000000000000* [ 3631.055710] RDX*: 0000000000000151 RSI: fffffffffffffff3 RDI: fffffffffffffff3* [ 3631.141195] RBP*: ffff88007a38ba38 R08: ffff880060a4c93b R09: ffff88007a38ba94* [ 3631.226679] R10*: 000000000000000e R11: ffff880060a4c934 R12: ffff88007a701240* [ 3631.312163] R13*: ffff88007a338000 R14: ffffffff8139b3d0 R15: 00000000fffffff3* [ 3631.397650] FS*: 00007f0e8d98b740(0000) GS:ffff88007de00000(0000) knlGS:0000000000000000* [ 3631.494574] CS*: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033* [ 3631.563417] CR2*: fffffffffffffff3 CR3: 000000006719a000 CR4: 00000000000006f0* [ 3631.648901] *Stack:* [ 3631.673030] * ffffffff8112333a ffff88007a701240 ffff88007a38bb00 ffff88007a38ba60* [ 3631.762464] * ffffffff8139b438 ffff88007a701240 ffff88007a38bb00 ffff88007a338000* [ 3631.851901] * ffff88007a38bad8 ffffffff81370498 ffffffff81229680 ffff88007a38baf0* [ 3631.941337] *Call Trace:* [ 3631.970675] * [] ? audit_log_untrustedstring+0x1a/0x30* [ 3632.049919] * [] audit_cb+0x68/0x3f0* [ 3632.110444] * [] common_lsm_audit+0x1b8/0x740* [ 3632.180330] * [] ? alloc_inode+0x50/0x90* [ 3632.245011] * [] ? prepend_path+0xc6/0x2a0* [ 3632.311779] * [] aa_audit+0x5f/0x170* [ 3632.372300] * [] audit_mount+0x152/0x160* [ 3632.436988] * [] match_mnt_path_str+0x1dd/0x490* [ 3632.508951] * [] ? dentry_path+0x18/0x70* [ 3632.573638] * [] match_mnt+0xda/0x150* [ 3632.635203] * [] aa_bind_mount+0x100/0x180* [ 3632.701969] * [] wrap_apparmor_sb_mount+0x1c0/0x270* [ 3632.778095] * [] security_sb_mount+0x57/0x80* [ 3632.846939] * [] do_mount+0xab/0xda0* [ 3632.907468] * [] ? __kmalloc_track_caller+0x1b4/0x250* [ 3632.985668] * [] ? hrtimer_try_to_cancel+0xd1/0x130* [ 3633.061798] * [] ? memdup_user+0x42/0x70* [ 3633.126479] * [] SyS_mount+0x9f/0x100* [ 3633.188050] * [] entry_SYSCALL_64_fastpath+0x16/0x71* [ 3633.265205] Code*: 89 f8 48 89 e5 f6 82 e0 0d a5 81 20 74 10 48 83 c0 01 0f b6 10 f6 82 e0 0d a5 81 20 75 f0 5d c3 90 66 2e 0f 1f 84 00 00 00 00 00 <80> 3f 00 55 48 89 e5 74 11 48 89 f8 48 83 c0 01 80 38 00 75 f7 * [ 3633.504601] RIP [] strlen+0x0/0x20 [ 3633.565335] * RSP * [ 3633.607143] CR2*: fffffffffffffff3* [ 3633.646880] *---[ end trace 23ca1e52db270fbd ]---* ============================================================ Thanks. Peng On Tue, Feb 7, 2017 at 9:46 PM, Seth Arnold wrote: > On Tue, Feb 07, 2017 at 09:43:38PM -0600, Peng Liu wrote: > > I built a snap which needs to call "docker" command instead of using > > bindings like docker-py to get logs from a container. Unfortunately, the > > command reported an error with messages "support process for mount > > namespace capture exited abnormally". > > Are there any hints in dmesg or more detailed log files that might provide > a direction to start looking? > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.arnold at canonical.com Wed Feb 8 04:01:47 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Tue, 7 Feb 2017 20:01:47 -0800 Subject: Error to call "docker" command in a snap In-Reply-To: References: <20170208034628.GE18682@hunt> Message-ID: <20170208040147.GF18682@hunt> On Tue, Feb 07, 2017 at 09:56:04PM -0600, Peng Liu wrote: > Yes, thanks for your reminder. I found a kernel panic! The logs are below: Thanks Peng; could you please file a bug with "ubuntu-bug linux"? (At least I think that should work.) If that doesn't work, please include at least uname -a output. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From pengliu.mail at gmail.com Wed Feb 8 04:11:55 2017 From: pengliu.mail at gmail.com (Peng Liu) Date: Tue, 7 Feb 2017 22:11:55 -0600 Subject: Error to call "docker" command in a snap In-Reply-To: <20170208040147.GF18682@hunt> References: <20170208034628.GE18682@hunt> <20170208040147.GF18682@hunt> Message-ID: Sure! I have reported a bug for it. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1662754 Thanks Peng On Tue, Feb 7, 2017 at 10:01 PM, Seth Arnold wrote: > On Tue, Feb 07, 2017 at 09:56:04PM -0600, Peng Liu wrote: > > Yes, thanks for your reminder. I found a kernel panic! The logs are > below: > > Thanks Peng; could you please file a bug with "ubuntu-bug linux"? (At > least I think that should work.) If that doesn't work, please include > at least uname -a output. > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pengliu.mail at gmail.com Wed Feb 8 04:22:03 2017 From: pengliu.mail at gmail.com (Peng Liu) Date: Tue, 7 Feb 2017 22:22:03 -0600 Subject: Is there any way to disable snap-confine of the all-snap image? Message-ID: Hi Folks, A Linux kernel issue related to snap-confine (kernel panic!) haunts me quite a while. Is there any way to disable it for now? Thanks. Peng -------------- next part -------------- An HTML attachment was scrubbed... URL: From pengliu.mail at gmail.com Wed Feb 8 05:53:49 2017 From: pengliu.mail at gmail.com (Peng Liu) Date: Tue, 7 Feb 2017 23:53:49 -0600 Subject: Is there any way to disable snap-confine of the all-snap image? In-Reply-To: References: Message-ID: Is it possible to enable "classic" confinement policy for all-snap (Ubuntu core system) image? Thanks. Peng On Tue, Feb 7, 2017 at 10:22 PM, Peng Liu wrote: > Hi Folks, > > A Linux kernel issue related to snap-confine (kernel panic!) haunts me > quite a while. Is there any way to disable it for now? > > Thanks. > > Peng > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Wed Feb 8 06:14:23 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 8 Feb 2017 14:14:23 +0800 Subject: Is there any way to list all of the configure options for a snap application? Message-ID: Hi, According to the article at https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/snapctl-hooks/meta/hooks/configure, we can configure a snap using "snap get/set" command. Is there any way to list all of the configuration options for a snap app so that an end user can fine-tune the app. Thanks & best regards, XiaoGuo -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik.taneja at canonical.com Wed Feb 8 06:20:22 2017 From: manik.taneja at canonical.com (Manik Taneja) Date: Tue, 7 Feb 2017 22:20:22 -0800 Subject: Is there any way to list all of the configure options for a snap application? In-Reply-To: References: Message-ID: <3EFB3E88-2588-4B66-BB6D-DF84CCB1D664@canonical.com> > On Feb 7, 2017, at 10:14 PM, XiaoGuo Liu wrote: > > Hi, > > According to the article at https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/snapctl-hooks/meta/hooks/configure, we can configure a snap using "snap get/set" command. Is there any way to list all of the configuration options for a snap app so that an end user can fine-tune the app. No, this is in the roadmap but not implemented yet! > > Thanks & best regards, > XiaoGuo > > -- > XiaoGuo, Liu > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.arnold at canonical.com Wed Feb 8 06:31:00 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Tue, 7 Feb 2017 22:31:00 -0800 Subject: Error to call "docker" command in a snap In-Reply-To: References: <20170208034628.GE18682@hunt> <20170208040147.GF18682@hunt> Message-ID: <20170208063100.GA1804@hunt> On Tue, Feb 07, 2017 at 10:11:55PM -0600, Peng Liu wrote: > Sure! I have reported a bug for it. > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1662754 Hi Peng, could you try the kernel in http://people.canonical.com/~jj/linux+jj/ and report back? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From xiaoguo.liu at canonical.com Wed Feb 8 07:00:09 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 8 Feb 2017 15:00:09 +0800 Subject: Is there any way to list all of the configure options for a snap application? In-Reply-To: <3EFB3E88-2588-4B66-BB6D-DF84CCB1D664@canonical.com> References: <3EFB3E88-2588-4B66-BB6D-DF84CCB1D664@canonical.com> Message-ID: Yeah, I think this is much needed. For example, I really want to know what are the configuration options for the core snap. One use case could be that I want to stop the autopilot upgrade feature.. Thanks & best regards, XiaoGuo On Wed, Feb 8, 2017 at 2:20 PM, Manik Taneja wrote: > > > On Feb 7, 2017, at 10:14 PM, XiaoGuo Liu > wrote: > > Hi, > > According to the article at https://github.com/snapcore/snapd/blob/master/ > tests/lib/snaps/snapctl-hooks/meta/hooks/configure, we can configure a > snap using "snap get/set" command. Is there any way to list all of the > configuration options for a snap app so that an end user can fine-tune the > app. > > No, this is in the roadmap but not implemented yet! > > > Thanks & best regards, > XiaoGuo > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Wed Feb 8 09:26:44 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 08 Feb 2017 10:26:44 +0100 Subject: Is there any way to list all of the configure options for a snap application? In-Reply-To: References: <3EFB3E88-2588-4B66-BB6D-DF84CCB1D664@canonical.com> Message-ID: <1486546004.11948.81.camel@ubuntu.com> hi, Am Mittwoch, den 08.02.2017, 15:00 +0800 schrieb XiaoGuo Liu: > Yeah, I think this is much needed. For example, I really want to know > what are the configuration options for the core snap. One use case > could be that I want to stop the autopilot upgrade feature.. > https://docs.ubuntu.com/core/en/reference/core-configuration there isnt much fully done yet, the the core snap in the edge channel has additionally: snap set core service.rsyslog.disable=true/false snap set core service.systemd-timesyncd.disable=true/false in the works are: options to set timeserver and remote syslog server, support for sysctl.d, forced module loading, module options and management of some power features of logind (configurable power button behaviour) the auto-upgrade feature is currently being completely re-worked to be handled in snapd itself, until this is fully done we wont have a config option for it. all config options will be listed on the above page before they hit the stable channel. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sunny.bhayani at einfochips.com Wed Feb 8 11:55:12 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Wed, 8 Feb 2017 11:55:12 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support Message-ID: Hi, We did one experiment today, wherein, we built the Kernel (Debian release 16.09) from: https://builds.96boards.org/releases/dragonboard410c/linaro/debian/16.09/ On top of that we applied the Ubuntu Core (AppArmour patches). Flashed this kernel along with the Rootfs (alip) from the 96boards. With this combination, the Wifi (WCN) is working fine. So, we are suspecting that, somehow, the Ubuntu-Core RootFS is not able to kickstart the remoteproc for WCN. Moreover, the /lib/modules is also not having any kernel modules. I hope this pointer can help to investigate further for our issue. Requesting the Canonical team to kindly let us know, if they are able to build and make the Wifi (WCN) working. Awaiting reply. Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Wed Feb 8 12:07:34 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 08 Feb 2017 13:07:34 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: Message-ID: <1486555654.30264.8.camel@ubuntu.com> hi, On Mi, 2017-02-08 at 11:55 +0000, Sunny Bhayani wrote: >  > So, we are suspecting that, somehow, the Ubuntu-Core RootFS is not > able to kickstart the remoteproc for WCN. Moreover, the /lib/modules > is also not having any kernel modules. yes, i belive the snapcraft team together with the kernel team are working on a fix for this [1], the snapcraft kernel plugin seems to put the modules and firmware in a /lib subdir in the snap package which is wrong [2] and will not make them end up in the final place on the filesystem. > > I hope this pointer can help to investigate further for our issue. > > Requesting the Canonical team to kindly let us know, if they are able > to build and make the Wifi (WCN) working. > > Awaiting reply. > ogra at dragon:~$ lsmod|grep wcn wcn36xx                77824  0 wcn36xx_platform       16384  0 ogra at dragon:~$ ifconfig wlan wlan0     Link encap:Ethernet  HWaddr 02:00:25:af:71:aa             inet addr:192.168.2.46  Bcast:192.168.2.255  Mask:255.255.255.0           inet6 addr: fe80::25ff:feaf:71aa/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:96274 errors:0 dropped:4 overruns:0 frame:0           TX packets:47920 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000            RX bytes:21179590 (21.1 MB)  TX bytes:22684403 (22.6 MB) this works just fine using the official ubuntu core 16 images from [3] as well as the daily edge images from [4] ... (note that we do not support any non-SD card installs with the default setup at the moment) ciao oli [1] https://bugs.launchpad.net/bugs/1658177 [2] https://github.com/snapcore/snapd/wiki/Kernel-snap [3] http://releases.ubuntu.com/ubuntu-core/16/ [4] http://people.canonical.com/~ogra/snappy/all-snaps/daily/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From timo.jyrinki at gmail.com Wed Feb 8 13:19:57 2017 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Wed, 8 Feb 2017 15:19:57 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: 2017-02-07 17:00 GMT+02:00 Florian Boucault : > I thought I fixed the terminal last week. At least the terminal available on > the edge channel now is working for me. Does it work for you? > I made sure that the stage-packages only contain packages that are not in > ubuntu-app-platform and also used build-attributes: [no-system-libraries] It does not work if I upgrade to the edge version of ubuntu-app-platform (and uninstall and reinstall ubuntu-terminal-app). So yes you fixed it, and I tested the fix but the fixed version needs to be uploaded to the store by someone with rights. Maybe Bill? The current 33 version in the store still has the bundled Qt libraries - see $ ls /snap/ubuntu-terminal-app/33/usr/lib/x86_64-linux-gnu/ -Timo From andrew at miniatureworldmaker.com.au Tue Feb 7 21:35:45 2017 From: andrew at miniatureworldmaker.com.au (Andrew Mason) Date: Tue, 07 Feb 2017 21:35:45 +0000 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> Message-ID: <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Awesome, i am going to give this a try! On 8 February 2017 8:01:30 am ACDT, Manik Taneja wrote: >On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth >wrote: > >> On 07/02/17 20:17, Thomas Voß wrote: >> > https://bugs.launchpad.net/ubuntu/+source/xorg-server- >> lts-xenial/+bug/1655724 >> > was released to the updates pocket today. >> >> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, >> cloud or desktop, would be welcome. Pick a favorite snap and take it >for >> a spin. >> >The experience is very clean now. I just tried on AWS and have >RocketChat >up and >running- > >[image: Inline image 1] >Kudos to everyone involved in delivering this! > >Cheers, >Manik -- Sent from my mobile device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwinter at opensourcerouting.org Wed Feb 8 14:00:06 2017 From: mwinter at opensourcerouting.org (Martin Winter) Date: Wed, 08 Feb 2017 21:00:06 +0700 Subject: Anyone seen this? Snap fails to mount as /run fills up Message-ID: So I’ve noticed something unusual on my CI system (which installs/uninstalls debian packages and snap packages all the time as part of testing): I couldn’t install snap’s anymore - (only had the ubuntu-core loaded at this time) dut:~# snap install --force-dangerous ./frr_2.1-dev-20170207.191620-git.03bf19b_amd64.snap error: cannot perform the following tasks: - Mount snap "frr" (unset) ([start snap-frr-x1.mount] failed with exit status 1: Warning: snap-frr-x1.mount changed on disk. Run 'systemctl daemon-reload' to reload units. A dependency job for snap-frr-x1.mount failed. See 'journalctl -xe' for details.) root at ci-comp19-dut:~# and looking at “journalctl -xe” -- The start-up result is done. Feb 07 06:26:18 ci-comp19-dut systemd-logind[1561]: New session 3160 of user root. -- Subject: A new session 3160 has been created for user root -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat -- -- A new session with the ID 3160 has been created for the user root. -- -- The leading process of the session is 17387. Feb 07 06:26:18 ci-comp19-dut systemd-logind[1561]: Failed to save user data /run/systemd/users/0: No space l Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17397]: failed to create db file '/run/udev/data/+cgroup:task_str Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17396]: failed to create db file '/run/udev/data/+cgroup:proc_ino Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17401]: failed to create db file '/run/udev/data/+cgroup:sighand_ Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17402]: failed to create db file '/run/udev/data/+cgroup:signal_c Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17403]: failed to create db file '/run/udev/data/+cgroup:mm_struc Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17404]: failed to create db file '/run/udev/data/+cgroup:anon_vma Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17395]: failed to create db file '/run/udev/data/+cgroup:dentry(4 Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17399]: failed to create db file '/run/udev/data/+cgroup:anon_vma Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17394]: failed to create db file '/run/udev/data/+cgroup:cred_jar Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17400]: failed to create db file '/run/udev/data/+cgroup:files_ca Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17397]: failed to create db file '/run/udev/data/+cgroup:pid(4365 Feb 07 06:26:18 ci-comp19-dut systemd-udevd[17403]: failed to create db file '/run/udev/data/+cgroup:kmalloc- —> /run filesystem full! dut:~# df Filesystem 1K-blocks Used Available Use% Mounted on udev 1003440 0 1003440 0% /dev tmpfs 204812 204812 0 100% /run /dev/vda1 6060608 3362132 2367572 59% / tmpfs 1024048 0 1024048 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 1024048 0 1024048 0% /sys/fs/cgroup /dev/loop0 78080 78080 0 100% /snap/ubuntu-core/1411 /dev/loop1 76800 76800 0 100% /snap/ubuntu-core/423 tmpfs 204812 0 204812 0% /run/user/0 These are my versions: dut:~# snap --version snap 2.21 snapd 2.21 series 16 ubuntu 16.04 Anyone seen this before? This is a basic Ubuntu 16.04 (server) install After a reboot I don’t seem to have more space, so not sure if I should reconfig something to add more space to /run or if this is some bug. Thoughts? - Martin Winter From paolo.pisati at canonical.com Wed Feb 8 14:40:20 2017 From: paolo.pisati at canonical.com (Paolo Pisati) Date: Wed, 8 Feb 2017 15:40:20 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: <1486555654.30264.8.camel@ubuntu.com> References: <1486555654.30264.8.camel@ubuntu.com> Message-ID: <20170208144020.GA23217@harukaze> On Wed, Feb 08, 2017 at 01:07:34PM +0100, Oliver Grawert wrote: > > yes, i belive the snapcraft team together with the kernel team are > working on a fix for this [1], the snapcraft kernel plugin seems to put > the modules and firmware in a /lib subdir in the snap package which is > wrong [2] and will not make them end up in the final place on the > filesystem. I hit [1] too when rebuilding an image for the dragonboard410c yesterday, and i wrote a snapcraft patch that creates symlinks from /lib/modules to /modules and from /lib/firmware to /firmware but it wasn't enough, because during the staging phase, snapcraft complains that: ... IsADirectoryError: [Errno 21] Is a directory: '/home/flag/canonical/snapcraft/demos/96boards-kernel/snap/stage/modules' And that is problably because symlinks are not maintained from build to stage (and afterward). Here is the python call trace and full log: http://pastebin.ubuntu.com/23954641/ 1: https://bugs.launchpad.net/snapcraft/+bug/1658177 -- bye, p. From ogra at ubuntu.com Wed Feb 8 14:49:33 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 08 Feb 2017 15:49:33 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: <20170208144020.GA23217@harukaze> References: <1486555654.30264.8.camel@ubuntu.com> <20170208144020.GA23217@harukaze> Message-ID: <1486565373.11948.91.camel@ubuntu.com> hi, Am Mittwoch, den 08.02.2017, 15:40 +0100 schrieb Paolo Pisati: > On Wed, Feb 08, 2017 at 01:07:34PM +0100, Oliver Grawert wrote: > > > > > > yes, i belive the snapcraft team together with the kernel team are > > working on a fix for this [1], the snapcraft kernel plugin seems to > > put > > the modules and firmware in a /lib subdir in the snap package which > > is > > wrong [2] and will not make them end up in the final place on the > > filesystem. > I hit [1] too when rebuilding an image for the dragonboard410c > yesterday, and i > wrote a snapcraft patch that creates symlinks from /lib/modules to > /modules and > from /lib/firmware to /firmware but it wasn't enough, because during > the staging > phase, snapcraft complains that: > > ... > IsADirectoryError: [Errno 21] Is a directory: > '/home/flag/canonical/snapcraft/demos/96boards- > kernel/snap/stage/modules' > > And that is problably because symlinks are not maintained from build > to stage > (and afterward). the work is going on here: https://github.com/snapcore/snapcraft/pull/1115 ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From roberto.escandon at canonical.com Wed Feb 8 15:54:10 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Wed, 8 Feb 2017 16:54:10 +0100 Subject: chroot into a snap Message-ID: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> Hey engineers, I need some ideas to solve this: I'm trying to snap collaboraoffice online but that's not being easy at all. FYI: this is a kind of Google Drive stuff so that when you request in your browser certain document, it is rendered and can be edit by many at the same time, etc.. Though I've been able to build from sources a snap package, that is only working in classic confinement but not in devmode or strict. The reason is because the way it works: - There is a server listening for documents requests - for every new document requested an instance of a document manager is started in a chrooted environment - If requested n documents there will be n different chroot jails based in same certain template - document manager has certain linux capabilities to create the needed roots (cap_fowner,cap_mknod,cap_sys_chroot...) - the way of packaging the snap, currently, is by setting those caps and call mksquashfs skipping -no-attrs option set by default by snapcraft I thought about a solution of having server in a snap and document manager in another, but still there would be needed calling chroot for every new document... ideas? BR. From florian.boucault at canonical.com Wed Feb 8 15:54:31 2017 From: florian.boucault at canonical.com (Florian Boucault) Date: Wed, 08 Feb 2017 15:54:31 +0000 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: Indeed, sorry about that. The latest version with no Qt bundled is released now. Florian Le mer. 8 févr. 2017 à 14:20, Timo Jyrinki a écrit : > 2017-02-07 17:00 GMT+02:00 Florian Boucault < > florian.boucault at canonical.com>: > > I thought I fixed the terminal last week. At least the terminal > available on > > the edge channel now is working for me. Does it work for you? > > I made sure that the stage-packages only contain packages that are not in > > ubuntu-app-platform and also used build-attributes: > [no-system-libraries] > > It does not work if I upgrade to the edge version of > ubuntu-app-platform (and uninstall and reinstall ubuntu-terminal-app). > > So yes you fixed it, and I tested the fix but the fixed version needs > to be uploaded to the store by someone with rights. Maybe Bill? > > The current 33 version in the store still has the bundled Qt libraries > - see $ ls /snap/ubuntu-terminal-app/33/usr/lib/x86_64-linux-gnu/ > > -Timo > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Wed Feb 8 16:15:12 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 8 Feb 2017 17:15:12 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> Message-ID: <85ef37a8-e9e1-dfaa-a58e-8a702314afe0@webdrake.net> On 07/02/17 21:17, Thomas Voß wrote: > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 > was released to the updates pocket today. Thanks! I'll hopefully be able to report back to you tomorrow whether all works as expected. From loic.minier at ubuntu.com Wed Feb 8 16:22:38 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Wed, 8 Feb 2017 17:22:38 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: References: Message-ID: Hi! Awesome! Would be nice if this goodness would also be built for arm64: libseccomp in xenial/xenial-updates wasn't attempted on arm64 albeit xenial-backports carries an arm64 build, and snapd is blocked on that. Cheers, - Loïc On Tue, Jan 31, 2017 at 2:01 PM, Jamie Bennett wrote: > Hi, > > The team are pleased to announce that, after extensive testing in > proposed, snapd is officially available in the Trusty Tahr updates archive > [1]. If you are running a 14.04 system we encourage you to give it a try > and report any issues [2]. Thanks to all involved in making this happen. > > Regards, > Jamie. > > [1] https://launchpad.net/ubuntu/trusty/+source/snapd > [2] https://bugs.launchpad.net/ubuntu/+source/snapd > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.tilloy at canonical.com Wed Feb 8 16:37:32 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Wed, 8 Feb 2017 17:37:32 +0100 Subject: connecting a non-auto interface, automatically In-Reply-To: References: <3cd689a6-cb72-1563-a054-292af2a0a49c@canonical.com> Message-ID: On Tue, Feb 7, 2017 at 3:43 PM, Simon Fels wrote: > On 07.02.2017 15:36, knitzsche wrote: >> What is the approach to connect interfaces that are not auto-connecting >> without user intervention? >> >> That is, there's a snap (built into an image) that declares the >> log-observe plug. Log-observe interface does not auto-connect [1]. In >> this product, the user does not have a console, so they cannot connect >> the snap plug/interface. >> >> So, how does one configure the system to connect sthis? Via the gadget >> snap prepare-device hook script perhaps? > > You can ask at the store level to get a snap-declaration for the snap > which allows auto-connection of particular plugs just for your snap. Where can this be requested? I’m thinking that this might be useful for the 0ad snap that needs the process-control interface. Without it, the game won’t run. Alternatively, is there a common practice for detecting that a required interface isn't connected and displaying a useful error message to the user? Thanks, Olivier From joseph.wakeling at webdrake.net Wed Feb 8 16:45:12 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 8 Feb 2017 17:45:12 +0100 Subject: license.txt and snap/ directory In-Reply-To: References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> <87658715-83e8-5746-f6ca-165196463cb1@webdrake.net> Message-ID: <0a6bfef8-678a-3637-8597-601ef1e979da@webdrake.net> On 07/02/17 11:26, Sergio Schvezov wrote: > Can you log a bug against snapd? https://bugs.launchpad.net/snapd/+filebug Done :-) https://bugs.launchpad.net/snapd/+bug/1662951 From gustavo at niemeyer.net Wed Feb 8 16:52:12 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 8 Feb 2017 14:52:12 -0200 Subject: license.txt and snap/ directory In-Reply-To: <87658715-83e8-5746-f6ca-165196463cb1@webdrake.net> References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> <87658715-83e8-5746-f6ca-165196463cb1@webdrake.net> Message-ID: Hi Joseph, The discussion above felt like painting an incorrect picture of what we're aiming at. We *definitely* want to track license information inside the snap format in a proper location. We want to support both basic cases such as just listing a well known name, custom licenses, and all the way up to requiring an explicit agreement with the provided text. We're not there yet, but this is in our short to medium term roadmap for sure. On Mon, Feb 6, 2017 at 10:46 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 07/02/17 00:24, Kyle Fazzari wrote: > >> The fact that an empty directory is created here is a bug[1]. It should >> only create that directory if there's something to put in there. What >> Sergio is saying is this: >> >> Snapcraft-specific things, like hooks from snapcraft parts, command >> wrappers (eventually, not yet) will end up in the snap/ directory of the >> built snap. This has no bearing on the snap format, it's something >> internal to snapcraft (it could just as easily have chosen to place >> those things in the foo/ directory). >> >> The things in meta/ are specific to snapd. This directory is literally >> what defines "this random squashfs image" to be a snap. >> > > OK, makes sense. BTW, I hope I didn't come over as overly negative in my > reply to Sergio: if so it wasn't intended. > > Can I however raise a plea that `meta/` should contain licensing > information as a requirement? Even if it's not actively used by snapd > right now, it makes sense as a location and it would also make sense (in > future) to be able to do things like > > snap license whatever > > to check the available licensing information. > > More generally, it seems like a good idea to me that (i) snap packages > must contain licensing information, (ii) it will be available in a > standardized location both in the snap package definition and the generated > snap package, and (iii) this will be enforced/guaranteed by snapcraft. > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Wed Feb 8 17:09:38 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 8 Feb 2017 18:09:38 +0100 Subject: license.txt and snap/ directory In-Reply-To: References: <44f43546-b4d1-4465-b7cc-9cbda0e2da2b@canonical.com> <1b5cad96-fe13-e3fc-c587-e033abdd1190@webdrake.net> <9d099781-d8a8-6759-5360-aac128275355@webdrake.net> <65c2af95-c933-b974-5425-681d09a6dc55@canonical.com> <87658715-83e8-5746-f6ca-165196463cb1@webdrake.net> Message-ID: <7a59d799-d429-c432-2873-8f9f673a5fc0@webdrake.net> On 08/02/17 17:52, Gustavo Niemeyer wrote: > The discussion above felt like painting an incorrect picture of what we're > aiming at. We *definitely* want to track license information inside the snap > format in a proper location. We want to support both basic cases such as just > listing a well known name, custom licenses, and all the way up to requiring an > explicit agreement with the provided text. > > We're not there yet, but this is in our short to medium term roadmap for sure. Sounds good! Thanks for the clarification :-) From claudioandre.br at gmail.com Wed Feb 8 19:12:48 2017 From: claudioandre.br at gmail.com (=?UTF-8?Q?Claudio_Andr=C3=A9?=) Date: Wed, 8 Feb 2017 17:12:48 -0200 Subject: connecting a non-auto interface, automatically In-Reply-To: References: <3cd689a6-cb72-1563-a054-292af2a0a49c@canonical.com> Message-ID: 2017-02-08 14:37 GMT-02:00 Olivier Tilloy : > On Tue, Feb 7, 2017 at 3:43 PM, Simon Fels > wrote: > Where can this be requested? > > +1. Sorry, this is a hijack. I would like to see an interfaces revamp/discussion. E. g.: - my snap is useless without process-control, but works without home [1]. The previous is mandatory, the later is optional [2]. - why not document if an non-auto interface is mandatory? And, as Olivier said, a mechanism to say: a required interface isn't connected. I am, as an user, interested in using **some** snaps as 1st class software: a 'turbo' text editor, a better archiver, GIMP, ... - No alien "home", no need to copy files around to open them. Claudio [1] it is ok if the user wants to copy files from/to $SNAP_DIRs. [2] In fact, auto-connecting home might be a bad idea. PS: - extending this, what about a filesystem interface: - a text editor snap (or an archiver) can run confined without problems. But, the user might want to open /etc/fstab or a file in a removable media. Sorry if this is offensive, I REALLY apologize. Recently in planet GNOME we was able to read about flatpak "FileChooser portal". To me, it seems to be the needed solution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pengliu.mail at gmail.com Wed Feb 8 20:27:20 2017 From: pengliu.mail at gmail.com (Peng Liu) Date: Wed, 8 Feb 2017 14:27:20 -0600 Subject: Error to call "docker" command in a snap In-Reply-To: <20170208063100.GA1804@hunt> References: <20170208034628.GE18682@hunt> <20170208040147.GF18682@hunt> <20170208063100.GA1804@hunt> Message-ID: Hi Seth, Do you have documents about how to replace my current installed kernel on my desktop with the development kernels you provide? Or do you have the kernel snap for Ubuntu Core image? That would be easier for me to try. Thanks. Peng On Wed, Feb 8, 2017 at 12:31 AM, Seth Arnold wrote: > On Tue, Feb 07, 2017 at 10:11:55PM -0600, Peng Liu wrote: > > Sure! I have reported a bug for it. > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1662754 > > Hi Peng, could you try the kernel in > http://people.canonical.com/~jj/linux+jj/ > and report back? > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.brustkern at canonical.com Wed Feb 8 21:01:52 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Wed, 8 Feb 2017 16:01:52 -0500 Subject: Spread Tests with proxy (mostly go get) In-Reply-To: References: Message-ID: I was able to get most of the tests working by configuring the classic environment to use the proxy. I think long-term the correct solution is still system-wide proxy support on ubuntu core, and there's already a bug open for that, so I'll keep working with the current methods and propose changes for the tests if those are reasonable to make without affecting other functionality. Since the VMs are all in the lab, getting full network connections for them would be difficult to get approved by IS, and I think having most of the testing working behind the proxy is a pretty good state for now. On Tue, Feb 7, 2017 at 1:55 PM, Gustavo Niemeyer < gustavo.niemeyer at canonical.com> wrote: > Hi Max, > > The problem isn't spread itself, as it won't try to communicate out of the > host by itself. The problem is that snapd's test suite expects to be able > to talk to the network. > > Someone would have to go through and fix all such cases to go through the > proxy, which is perhaps more troubling than connecting the VM itself into > the network? > > On Mon, Jan 23, 2017 at 8:01 PM, Max Brustkern < > max.brustkern at canonical.com> wrote: > >> I'm trying to run spread tests on an ubuntu core VM in a lab that needs >> to use a proxy for web access. The mirrors are redirected, so the package >> installations work as expected, but I run into problems with go get: >> >> ++ classic 'GOPATH=/home/gopath go get ../../home/gopath/src/github.c >> om/snapcore/snapd/tests/lib/snapbuild' >> Cannot determine calling user, logging into classic as root >> mount: devpts is already mounted or /dev/pts busy >> devpts is already mounted on /dev/pts >> package gopkg.in/yaml.v2: unrecognized import path "gopkg.in/yaml.v2" >> (https fetch: Get https://gopkg.in/yaml.v2?go-get=1: dial tcp >> 45.33.69.124:443: i/o timeout) >> package gopkg.in/check.v1: unrecognized import path "gopkg.in/check.v1" >> (https fetch: Get https://gopkg.in/check.v1?go-get=1: dial tcp >> 45.33.69.124:443: i/o timeout) >> ++ sysctl -w net.ipv6.conf.all.disable_ipv6=0 >> net.ipv6.conf.all.disable_ipv6 = 0 >> ----- >> 2017/01/23 16:46:54 Restoring project on external:ubuntu-core-16-64... >> 2017/01/23 16:46:55 Successful tasks: 0 >> 2017/01/23 16:46:55 Aborted tasks: 107 >> 2017/01/23 16:46:55 Failed project prepare: 1 >> - external:ubuntu-core-16-64:project >> 2017/01/23 16:46:55 Keeping external:ubuntu-core-16-64 at 127.0.0.1:54323 >> error: unsuccessful run >> >> I'm using the following spread commands to run on the local VM: >> export SPREAD_EXTERNAL_ADDRESS=127.0.0.1:$PORT >> ./tests/lib/external/prepare-ssh.sh 127.0.0.1 $PORT $USER >> spread -v -reuse external:ubuntu-core-16-64 | tee $WORKSPACE/spread-output >> >> How should I configure spread to make go aware of the proxy? >> >> Thanks, >> Max >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.mardegan at canonical.com Wed Feb 8 21:31:12 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Thu, 9 Feb 2017 00:31:12 +0300 Subject: Semaphores and access to /dev/shm Message-ID: <594992a2-8e8d-805b-6ebb-459ff3f229e4@canonical.com> Hi all! I'm working on a snap of a python2 utility which is using the Pool class from the multiprocessing module. But this gets blocked by apparmor: Log: apparmor="DENIED" operation="mknod" profile="snap.bundler-mardy.bundler-py" name="/dev/shm/8sszOM" pid=17782 comm="python2" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 File: /dev/shm/8sszOM (write) Suggestion: * adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.* Unfortunately, the suggestion is not really helpful, because the filename is not decided by the client code. But even if somehow we fixed the python implementation to generate a proper name, it looks like sem_open() is behaving in a very peculiar way: please have a look at this strace log, obtained on an *unconfined* process: ================= statfs("/dev/shm/", {...}) = 0 futex(0x7f1b658f9310, FUTEX_WAKE_PRIVATE, 2147483647) = 0 lstat("/dev/shm/ApjbNj", 0x7ffe9cefff20) = -1 ENOENT open("/dev/shm/ApjbNj", O_RDWR|O_CREAT|O_EXCL, 0600) = 6 write(6, "\1\0\0\0\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 32) = 32 mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x7f1b65a5d000 link("/dev/shm/ApjbNj", "/dev/shm/sem.mp18207-15353487325820441356") = 0 fstat(6, {st_mode=S_IFREG|0600, st_size=32, ...}) = 0 unlink("/dev/shm/ApjbNj") = 0 close(6) = 0 ================= That is, it looks like sem_open() is first creating a temporary file, and then linking it to a file with the proper name (the python code is using "/mp%ld-%lu" as semaphore filename). This also seems confirmed by a quick look at glibc's source code: http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/sem_open.c;h=a80e5b8e9b15090c2ecacb1c1e587c501cf20ffb;hb=HEAD#l277 So, it looks like sem_open() can't possibly work under confinement, or am I missing something here? Ciao, Alberto From jamie at canonical.com Wed Feb 8 23:22:51 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 08 Feb 2017 17:22:51 -0600 Subject: Semaphores and access to /dev/shm In-Reply-To: <594992a2-8e8d-805b-6ebb-459ff3f229e4@canonical.com> References: <594992a2-8e8d-805b-6ebb-459ff3f229e4@canonical.com> Message-ID: <1486596171.3367.49.camel@canonical.com> On Thu, 2017-02-09 at 00:31 +0300, Alberto Mardegan wrote: > Hi all! >   I'm working on a snap of a python2 utility which is using the Pool > class from the multiprocessing module. But this gets blocked by apparmor: > > Log: apparmor="DENIED" operation="mknod" > profile="snap.bundler-mardy.bundler-py" name="/dev/shm/8sszOM" pid=17782 > comm="python2" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 > File: /dev/shm/8sszOM (write) > Suggestion: > * adjust program to create files and directories in > /dev/shm/snap.$SNAP_NAME.* > > > Unfortunately, the suggestion is not really helpful, because the > filename is not decided by the client code. But even if somehow we fixed > the python implementation to generate a proper name, it looks like > sem_open() is behaving in a very peculiar way: please have a look at > this strace log, obtained on an *unconfined* process: > > ================= > statfs("/dev/shm/", {...}) = 0 > futex(0x7f1b658f9310, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > lstat("/dev/shm/ApjbNj", 0x7ffe9cefff20) = -1 ENOENT > open("/dev/shm/ApjbNj", O_RDWR|O_CREAT|O_EXCL, 0600) = 6 > write(6, > "\1\0\0\0\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", > 32) = 32 > mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x7f1b65a5d000 > link("/dev/shm/ApjbNj", "/dev/shm/sem.mp18207-15353487325820441356") = 0 > fstat(6, {st_mode=S_IFREG|0600, st_size=32, ...}) = 0 > unlink("/dev/shm/ApjbNj")               = 0 > close(6)                                = 0 > ================= > > That is, it looks like sem_open() is first creating a temporary file, > and then linking it to a file with the proper name (the python code is > using "/mp%ld-%lu" as semaphore filename). This also seems confirmed by > a quick look at glibc's source code: > > http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/sem_open.c;h=a80e5b8e9b15 > 090c2ecacb1c1e587c501cf20ffb;hb=HEAD#l277 > > So, it looks like sem_open() can't possibly work under confinement, or > am I missing something here? > sem_open() is https://bugs.launchpad.net/snappy/+bug/1653955 and snapd 2.21 added support to allow /{dev,run}/shm/sem.snap.@{SNAP_NAME}.*. This is sufficient to make use of sem_open() possible. The python code is, as you've indicated, is choosing to use "/mp%ld-%lu" instead of '"/snap.%s.%ld-%lu" % os.getenv("SNAP_NAME")'. However, reading the shm_open() implementation in glibc you gave, if O_CREAT or O_EXCL are specified then a temporary file is created that doesn't conform to the name, but if the file exists you can use it. I confirmed this works fine under confinement (return code checking omitted for clarity):    char *name = "/dev/shm/sem.snap.foo.bar";    open(name, O_CREAT | O_EXCL | O_RDRW, S_IRUSR | S_IWUSR);    sem_open("snap.foo.bar", 0); As such, sem_open() can work under confinement, but the application needs to be written to work within it. Sergio put together snapcraft-preload: https://github.com/sergiusens/snapcraft-preload It doesn't seem to have sem_open() support yet, but it certainly could. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From xiaoguo.liu at canonical.com Thu Feb 9 02:28:16 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 10:28:16 +0800 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: These days, I tried to make use of ubuntu-app-platform. I have upgraded the snap to the latest version 34 from the edge channel. Still I get an error like: This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". Reinstalling the application may fix this problem. Aborted (core dumped) What could be the problem for it? Thanks & best regards, XiaoGuo On Wed, Feb 8, 2017 at 11:54 PM, Florian Boucault < florian.boucault at canonical.com> wrote: > Indeed, sorry about that. The latest version with no Qt bundled is > released now. > > Florian > > Le mer. 8 févr. 2017 à 14:20, Timo Jyrinki a > écrit : > >> 2017-02-07 17:00 GMT+02:00 Florian Boucault > com>: >> > I thought I fixed the terminal last week. At least the terminal >> available on >> > the edge channel now is working for me. Does it work for you? >> > I made sure that the stage-packages only contain packages that are not >> in >> > ubuntu-app-platform and also used build-attributes: >> [no-system-libraries] >> >> It does not work if I upgrade to the edge version of >> ubuntu-app-platform (and uninstall and reinstall ubuntu-terminal-app). >> >> So yes you fixed it, and I tested the fix but the fixed version needs >> to be uploaded to the store by someone with rights. Maybe Bill? >> >> The current 33 version in the store still has the bundled Qt libraries >> - see $ ls /snap/ubuntu-terminal-app/33/usr/lib/x86_64-linux-gnu/ >> >> -Timo >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/snapcraft >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Feb 9 02:43:18 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 10:43:18 +0800 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: I am now trying to snap a html5 webapp. My source code is here at: https://github.com/liu-xiao-guo/wuziqi Currently, my Qt version on my desktop is Qt 5.6.2: ======================================== QMake version 3.0 Using Qt version 5.6.2 in /usr/lib/x86_64-linux-gnu ======================================== I installed ubuntu-app-platform from the edge channel. $ snap info ubuntu-app-platform name: ubuntu-app-platform summary: "Ubuntu app platform for running apps on a shared platform of libraries" publisher: canonical description: | Ubuntu app platform is an optional package your app can use to minimize the disk space the app takes. The platform offers you shared content which includes Qt 5.6.2 with Ubuntu's backported fixes, Ubuntu UI Toolkit, PIM libraries and Oxide web browser engine among else. It is recommended to use the associated cloud part desktop-ubuntu-app-platform to make the usage easy. Note that for developing a package targeting to use ubuntu-app-platform, you will need to use Ubuntu 16.04 LTS added with the "stable-phone-overlay" PPA which includes the newer Qt and other packages! tracking: edge installed: 1 (34) 216MB - refreshed: 2017-02-08 21:34:47 +0800 CST channels: stable: 1 (22) 154MB - candidate: 1 (34) 216MB - beta: 1 (34) 216MB - edge: 1 (34) 216MB - When running my app, it comes the error like: =============================================== $ wuziqi This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". Reinstalling the application may fix this problem. Aborted (core dumped) ================================================ What could be the reason for it? Thanks & best regards, XiaoGuo On Thu, Feb 9, 2017 at 10:28 AM, XiaoGuo Liu wrote: > These days, I tried to make use of ubuntu-app-platform. I have upgraded > the snap to the latest version 34 from the edge channel. Still I get an > error like: > > This application failed to start because it could not find or load the Qt > platform plugin "xcb" > in "". > > Reinstalling the application may fix this problem. > Aborted (core dumped) > > What could be the problem for it? > > Thanks & best regards, > XiaoGuo > > On Wed, Feb 8, 2017 at 11:54 PM, Florian Boucault < > florian.boucault at canonical.com> wrote: > >> Indeed, sorry about that. The latest version with no Qt bundled is >> released now. >> >> Florian >> >> Le mer. 8 févr. 2017 à 14:20, Timo Jyrinki a >> écrit : >> >>> 2017-02-07 17:00 GMT+02:00 Florian Boucault < >>> florian.boucault at canonical.com>: >>> > I thought I fixed the terminal last week. At least the terminal >>> available on >>> > the edge channel now is working for me. Does it work for you? >>> > I made sure that the stage-packages only contain packages that are not >>> in >>> > ubuntu-app-platform and also used build-attributes: >>> [no-system-libraries] >>> >>> It does not work if I upgrade to the edge version of >>> ubuntu-app-platform (and uninstall and reinstall ubuntu-terminal-app). >>> >>> So yes you fixed it, and I tested the fix but the fixed version needs >>> to be uploaded to the store by someone with rights. Maybe Bill? >>> >>> The current 33 version in the store still has the bundled Qt libraries >>> - see $ ls /snap/ubuntu-terminal-app/33/usr/lib/x86_64-linux-gnu/ >>> >>> -Timo >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > XiaoGuo, Liu > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.henstridge at canonical.com Thu Feb 9 04:02:25 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Thu, 9 Feb 2017 12:02:25 +0800 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: On 9 February 2017 at 10:43, XiaoGuo Liu wrote: > I am now trying to snap a html5 webapp. My source code is here at: > > https://github.com/liu-xiao-guo/wuziqi Looking at the snapcraft.yaml file, you don't seem to be using the launcher shell script provided by the part. Without that, LD_LIBRARY_PATH and other environment variables won't be set up correctly to use libraries provided by ubuntu-app-platform. James. From xiaoguo.liu at canonical.com Thu Feb 9 04:02:48 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 12:02:48 +0800 Subject: snapd available in Trusty Tahr In-Reply-To: <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> References: <20170202073818.b2heyissfeo2tulw@x250> <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Message-ID: Hi, I just tried to install the snapd and installed a hello-world snap app on 14.04 desktop. However, I found a problem. When I un the hello-world, it shows: liuxg at liuxg:/snap/bin$ hello-world hello-world: command not found Which means that /snap/bin path is not added to the path after installing the core. Also, when I run it under the /snap/bin, it shows: liuxg at liuxg:/snap/bin$ ./hello-world ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. Hello World! My desktop info is: liuxg at liuxg:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty liuxg at liuxg:~$ snap list Name Version Rev Developer Notes core 16.04.1 888 canonical - hello-world 6.3 27 canonical - Thanks & best regards, XiaoGuo On Wed, Feb 8, 2017 at 5:35 AM, Andrew Mason < andrew at miniatureworldmaker.com.au> wrote: > Awesome, i am going to give this a try! > > On 8 February 2017 8:01:30 am ACDT, Manik Taneja > wrote: >> >> >> >> On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth >> wrote: >> >>> On 07/02/17 20:17, Thomas Voß wrote: >>> > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts- >>> xenial/+bug/1655724 >>> > was released to the updates pocket today. >>> >>> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, >>> cloud or desktop, would be welcome. Pick a favorite snap and take it for >>> a spin. >>> >> The experience is very clean now. I just tried on AWS and have RocketChat >> up and >> running- >> >> [image: Inline image 1] >> Kudos to everyone involved in delivering this! >> >> Cheers, >> Manik >> > > -- > Sent from my mobile device. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Feb 9 04:12:41 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 12:12:41 +0800 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: Hi James, Thanks for your reply. Yeah, it could be reason for it. I used to have a Qt project, and the app was launched by desktop-launch: https://github.com/liu-xiao-guo/rssreader_platform For my case, it is a html5 app. I do not know what is the correct way to launch the app. Do you know what should be set up correctly? I may have my own script to set them up. Thanks & best regards, XiaoGuo On Thu, Feb 9, 2017 at 12:02 PM, James Henstridge < james.henstridge at canonical.com> wrote: > On 9 February 2017 at 10:43, XiaoGuo Liu > wrote: > > I am now trying to snap a html5 webapp. My source code is here at: > > > > https://github.com/liu-xiao-guo/wuziqi > > Looking at the snapcraft.yaml file, you don't seem to be using the > launcher shell script provided by the part. Without that, > LD_LIBRARY_PATH and other environment variables won't be set up > correctly to use libraries provided by ubuntu-app-platform. > > James. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunny.bhayani at einfochips.com Thu Feb 9 06:13:15 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Thu, 9 Feb 2017 06:13:15 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support Message-ID: Hi Oliver / Paolo, Thank you for your time. > the work is going on here: > > https://github.com/snapcore/snapcraft/pull/1115 Is there a way, that we can come to know about an official fix, apart from the above link that you mentioned. Also, how did the build for the Dragonboard410C succeed for the pre-built Ubuntu Core OS image ? Since that is working properly, /lib/modules have the kernel modules and /lib/firmware has the firmware binaries. Also, the wifi interface (wlan0) is working. Sorry, but I was just curious to know this. Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Thu Feb 9 06:25:53 2017 From: simon.fels at canonical.com (Simon Fels) Date: Thu, 9 Feb 2017 07:25:53 +0100 Subject: [System Enablement] New releases Feb 2017 In-Reply-To: References: Message-ID: <1cac512e-992d-21cc-f6e7-f1c8470f1efc@canonical.com> On 07.02.2017 15:40, Simon Fels wrote: > Hey everyone, > > new releases of the alsa-utils, network-manager, upower and wifi-ap > snaps were pushed into the candidate channel. > > alsa-utils 1.1.2-2: > > * First official release supported by Canonical > * Aliases for all exported commands are available > * Set of automated and manual test cases guarantee quality of each release > > network-manager 1.2.2-11: > > * Wake-on-WLAN can be configured via snap confiration / nmcli > * Automatic reconfiguration of network devices when devices wakes up > * Alias support for nmcli command > * WiFi powersave is now configurable via snap configuration > * Network-Manager tests are using tests-extras repository to fetch the > image creating scripts rather than embed them. > > upower 0.99.4-2: > > * First release > * Integration with systemd to suspend the system on low battery events We found a problem with upower which causes its plugs/slots not correctly connected/specified. This is now fixed and new revisions are uploaded into the candidate channel. The following revisions are now available for testing: 22 (amd64) 25 (arm64) 24 (armhf) 23 (i386) regards, Simon From james.henstridge at canonical.com Thu Feb 9 06:26:06 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Thu, 9 Feb 2017 14:26:06 +0800 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: On 9 February 2017 at 12:12, XiaoGuo Liu wrote: > Hi James, > > Thanks for your reply. Yeah, it could be reason for it. I used to have a Qt > project, and the app was launched by desktop-launch: > > https://github.com/liu-xiao-guo/rssreader_platform > > For my case, it is a html5 app. I do not know what is the correct way to > launch the app. Do you know what should be set up correctly? I may have my > own script to set them up. The webapp-helper part you're using looks like it provides a bin/webapp-launcher helper script that would do what you want. It looks like it might be what you're after. James. From xiaoguo.liu at canonical.com Thu Feb 9 06:36:03 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 14:36:03 +0800 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: Hi James, Thanks for your help. Yes, you are right! Now I do a new version of it, and I used a wrapper to launch it. This time, the app can be launched successfully, but still there is an error like: ** (process:29208): WARNING **: Unable to register app: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.467" (uid=1000 pid=29208 comm="webapp-container www/index.html ") interface="com.canonical.hud" member="RegisterApplication" error name="(unset)" requested_reply="0" destination=":1.36" (uid=1000 pid=2741 comm="/usr/lib/x86_64-linux-gnu/hud/hud-service ") XmbTextListToTextProperty result code -2 XmbTextListToTextProperty result code -2 qml: [JS] (file:///snap/wuziqi/x1/www/js/app.js:1) Uncaught ReferenceError: UbuntuUI is not defined My code is at https://github.com/liu-xiao-guo/wuziqi1 I think it is another error. Thanks & best regards, XiaoGuo On Thu, Feb 9, 2017 at 2:26 PM, James Henstridge < james.henstridge at canonical.com> wrote: > On 9 February 2017 at 12:12, XiaoGuo Liu > wrote: > > Hi James, > > > > Thanks for your reply. Yeah, it could be reason for it. I used to have a > Qt > > project, and the app was launched by desktop-launch: > > > > https://github.com/liu-xiao-guo/rssreader_platform > > > > For my case, it is a html5 app. I do not know what is the correct way to > > launch the app. Do you know what should be set up correctly? I may have > my > > own script to set them up. > > The webapp-helper part you're using looks like it provides a > bin/webapp-launcher helper script that would do what you want. It > looks like it might be what you're after. > > James. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.mardegan at canonical.com Thu Feb 9 07:48:22 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Thu, 9 Feb 2017 10:48:22 +0300 Subject: Semaphores and access to /dev/shm In-Reply-To: <1486596171.3367.49.camel@canonical.com> References: <594992a2-8e8d-805b-6ebb-459ff3f229e4@canonical.com> <1486596171.3367.49.camel@canonical.com> Message-ID: <04ab067d-4516-a26a-5fc4-0687ddec2fb6@canonical.com> On 09/02/2017 02:22, Jamie Strandboge wrote: > I confirmed this works fine under confinement (return code checking omitted for > clarity): > > char *name = "/dev/shm/sem.snap.foo.bar"; > open(name, O_CREAT | O_EXCL | O_RDRW, S_IRUSR | S_IWUSR); > sem_open("snap.foo.bar", 0); > > As such, sem_open() can work under confinement, but the application needs to be > written to work within it. Thanks Jamie, this is helpful! > Sergio put together snapcraft-preload: > https://github.com/sergiusens/snapcraft-preload > > It doesn't seem to have sem_open() support yet, but it certainly could. Cool, I didn't know about this project. I submitted https://github.com/sergiusens/snapcraft-preload/issues/2 Ciao, Alberto -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From thomas.voss at canonical.com Thu Feb 9 08:39:55 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Thu, 9 Feb 2017 09:39:55 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Message-ID: On Thu, Feb 9, 2017 at 5:02 AM, XiaoGuo Liu wrote: > Hi, > > I just tried to install the snapd and installed a hello-world snap app on > 14.04 desktop. However, I found a problem. When I un the hello-world, it > shows: > > liuxg at liuxg:/snap/bin$ hello-world > hello-world: command not found > > This is expected behavior right now. PATH is adjusted in /etc/profile.d/apps-bin-path.sh (comes with the snapd package). /etc/profile and the entries in /etc/profile.d/* are only considered for login shells. With that, a reboot, logout/login, or sourcing /etc/profile in your current shell will give you the correct PATH setup. We are looking into letting the user know when installing the debian package (as opposed to the situation where snapd is already part of the image). See https://github.com/snapcore/snapd/pull/2819 for reference. Thanks for testing, Thomas > Which means that /snap/bin path is not added to the path after installing > the core. Also, when I run it under the /snap/bin, it shows: > > liuxg at liuxg:/snap/bin$ ./hello-world > ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot > be preloaded (cannot open shared object file): ignored. > ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot > be preloaded (cannot open shared object file): ignored. > Hello World! > > My desktop info is: > > liuxg at liuxg:~$ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 14.04.5 LTS > Release: 14.04 > Codename: trusty > > liuxg at liuxg:~$ snap list > Name Version Rev Developer Notes > core 16.04.1 888 canonical - > hello-world 6.3 27 canonical - > > Thanks & best regards, > XiaoGuo > > > On Wed, Feb 8, 2017 at 5:35 AM, Andrew Mason com.au> wrote: > >> Awesome, i am going to give this a try! >> >> On 8 February 2017 8:01:30 am ACDT, Manik Taneja >> wrote: >>> >>> >>> >>> On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth >>> wrote: >>> >>>> On 07/02/17 20:17, Thomas Voß wrote: >>>> > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xe >>>> nial/+bug/1655724 >>>> > was released to the updates pocket today. >>>> >>>> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, >>>> cloud or desktop, would be welcome. Pick a favorite snap and take it for >>>> a spin. >>>> >>> The experience is very clean now. I just tried on AWS and have >>> RocketChat up and >>> running- >>> >>> [image: Inline image 1] >>> Kudos to everyone involved in delivering this! >>> >>> Cheers, >>> Manik >>> >> >> -- >> Sent from my mobile device. >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Feb 9 09:02:14 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 17:02:14 +0800 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Message-ID: Hi Thomas, So, an end user needs to manually add the path, right? It is not a little bit straightforward though. I think it would be good to come with detailed instructions. Thanks & best regards, XiaoGuo On Thu, Feb 9, 2017 at 4:39 PM, Thomas Voß wrote: > > > On Thu, Feb 9, 2017 at 5:02 AM, XiaoGuo Liu > wrote: > >> Hi, >> >> I just tried to install the snapd and installed a hello-world snap app on >> 14.04 desktop. However, I found a problem. When I un the hello-world, it >> shows: >> >> liuxg at liuxg:/snap/bin$ hello-world >> hello-world: command not found >> >> > This is expected behavior right now. PATH is adjusted in > /etc/profile.d/apps-bin-path.sh (comes with the snapd package). > /etc/profile and the entries in /etc/profile.d/* are only considered for > login shells. With that, a reboot, logout/login, or sourcing /etc/profile > in your current shell will give you the correct PATH setup. > > We are looking into letting the user know when installing the debian > package (as opposed to the situation where snapd is already part of the > image). See https://github.com/snapcore/snapd/pull/2819 for reference. > > Thanks for testing, > > Thomas > > > >> Which means that /snap/bin path is not added to the path after installing >> the core. Also, when I run it under the /snap/bin, it shows: >> >> liuxg at liuxg:/snap/bin$ ./hello-world >> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot >> be preloaded (cannot open shared object file): ignored. >> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot >> be preloaded (cannot open shared object file): ignored. >> Hello World! >> >> My desktop info is: >> >> liuxg at liuxg:~$ lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description: Ubuntu 14.04.5 LTS >> Release: 14.04 >> Codename: trusty >> >> liuxg at liuxg:~$ snap list >> Name Version Rev Developer Notes >> core 16.04.1 888 canonical - >> hello-world 6.3 27 canonical - >> >> Thanks & best regards, >> XiaoGuo >> >> >> On Wed, Feb 8, 2017 at 5:35 AM, Andrew Mason < >> andrew at miniatureworldmaker.com.au> wrote: >> >>> Awesome, i am going to give this a try! >>> >>> On 8 February 2017 8:01:30 am ACDT, Manik Taneja >>> wrote: >>>> >>>> >>>> >>>> On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth >>>> wrote: >>>> >>>>> On 07/02/17 20:17, Thomas Voß wrote: >>>>> > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xe >>>>> nial/+bug/1655724 >>>>> > was released to the updates pocket today. >>>>> >>>>> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, >>>>> cloud or desktop, would be welcome. Pick a favorite snap and take it >>>>> for >>>>> a spin. >>>>> >>>> The experience is very clean now. I just tried on AWS and have >>>> RocketChat up and >>>> running- >>>> >>>> [image: Inline image 1] >>>> Kudos to everyone involved in delivering this! >>>> >>>> Cheers, >>>> Manik >>>> >>> >>> -- >>> Sent from my mobile device. >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> >> -- >> XiaoGuo, Liu >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Thu Feb 9 09:04:22 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Thu, 9 Feb 2017 10:04:22 +0100 Subject: One snap to connect them all (or: the plugin story) Message-ID: Ok, sorry for the catchy email title but couldn't resist :) So, I'm in the situation where one snap would need to get configuration and access to some files from other snaps. It's really similar to our plugin story: even if in that case, we are talking about optional configuration and files from one or multiple snaps shared with a single one collecting them all. I can see 2 options in the snapd philosophy: - Content sharing. Sounds like it matches exactly the purpose of it. However, even disregarding the manual connection that will be needed, we are stuck on the fact that it's limited to one connection for a given slot. If I want to share configuration and files from 3 snaps to the master one, I can't do 3 times: $ snap connect snap1:config my-master-snap:config $ snap connect snap2:config my-master-snap:config $ snap connect snap2:config my-master-snap:config One way would be to create different slot names: $ snap connect snap1:config my-master-snap:config1 $ snap connect snap2:config my-master-snap:config2 $ snap connect snap2:config my-master-snap:config3 But this doesn't help on the ease of use (the notice is then for people "find the first available slot"… Not really user-friendly) nor in the scalibity (fixed number of slots…) - A dedicated interface which will handle multiple TCP connections and DTRT. However, a dedicated interface suffers from the same issue than previously and need to be hardcoded in snapd itself as AFAIK, there is no way still as of today to have custom interfaces developped outside of the snapd code itself. Other ideas or plans for this? Cheers, didier From jamie.bennett at canonical.com Thu Feb 9 09:05:48 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Thu, 9 Feb 2017 09:05:48 +0000 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Message-ID: The simplest way is to log out and back in again. We are looking at other options on how to make this easier. Regards, Jamie. > On 9 Feb 2017, at 09:02, XiaoGuo Liu wrote: > > Hi Thomas, > > So, an end user needs to manually add the path, right? It is not a little bit straightforward though. I think it would be good to come with detailed instructions. > > Thanks & best regards, > XiaoGuo > > > On Thu, Feb 9, 2017 at 4:39 PM, Thomas Voß > wrote: > > > On Thu, Feb 9, 2017 at 5:02 AM, XiaoGuo Liu > wrote: > Hi, > > I just tried to install the snapd and installed a hello-world snap app on 14.04 desktop. However, I found a problem. When I un the hello-world, it shows: > > liuxg at liuxg:/snap/bin$ hello-world > hello-world: command not found > > > This is expected behavior right now. PATH is adjusted in /etc/profile.d/apps-bin-path.sh (comes with the snapd package). /etc/profile and the entries in /etc/profile.d/* are only considered for login shells. With that, a reboot, logout/login, or sourcing /etc/profile in your current shell will give you the correct PATH setup. > > We are looking into letting the user know when installing the debian package (as opposed to the situation where snapd is already part of the image). See https://github.com/snapcore/snapd/pull/2819 for reference. > > Thanks for testing, > > Thomas > > > Which means that /snap/bin path is not added to the path after installing the core. Also, when I run it under the /snap/bin, it shows: > > liuxg at liuxg:/snap/bin$ ./hello-world > ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. > ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. > Hello World! > > My desktop info is: > > liuxg at liuxg:~$ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 14.04.5 LTS > Release: 14.04 > Codename: trusty > > liuxg at liuxg:~$ snap list > Name Version Rev Developer Notes > core 16.04.1 888 canonical - > hello-world 6.3 27 canonical - > > Thanks & best regards, > XiaoGuo > > > On Wed, Feb 8, 2017 at 5:35 AM, Andrew Mason > wrote: > Awesome, i am going to give this a try! > > On 8 February 2017 8:01:30 am ACDT, Manik Taneja > wrote: > > > On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth > wrote: > On 07/02/17 20:17, Thomas Voß wrote: > > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 > > was released to the updates pocket today. > > Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, > cloud or desktop, would be welcome. Pick a favorite snap and take it for > a spin. > The experience is very clean now. I just tried on AWS and have RocketChat up and > running- > > > Kudos to everyone involved in delivering this! > > Cheers, > Manik > > -- > Sent from my mobile device. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > XiaoGuo, Liu > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Feb 9 09:09:35 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 17:09:35 +0800 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Message-ID: Hi Jamie, For my case, right now, after I log out and login again (in fact, I rebooted my machine). the /snap/bin path is still not added. Everything is still the same. I cannot execute the "hello-word" snap app. I do not know where I did wrongly. Thanks & bestt regards, XiaoGuo On Thu, Feb 9, 2017 at 5:05 PM, Jamie Bennett wrote: > The simplest way is to log out and back in again. We are looking at other > options on how to make this easier. > > Regards, > Jamie. > > On 9 Feb 2017, at 09:02, XiaoGuo Liu wrote: > > Hi Thomas, > > So, an end user needs to manually add the path, right? It is not a little > bit straightforward though. I think it would be good to come with detailed > instructions. > > Thanks & best regards, > XiaoGuo > > > On Thu, Feb 9, 2017 at 4:39 PM, Thomas Voß > wrote: > >> >> >> On Thu, Feb 9, 2017 at 5:02 AM, XiaoGuo Liu >> wrote: >> >>> Hi, >>> >>> I just tried to install the snapd and installed a hello-world snap app >>> on 14.04 desktop. However, I found a problem. When I un the hello-world, it >>> shows: >>> >>> liuxg at liuxg:/snap/bin$ hello-world >>> hello-world: command not found >>> >>> >> This is expected behavior right now. PATH is adjusted in >> /etc/profile.d/apps-bin-path.sh (comes with the snapd package). >> /etc/profile and the entries in /etc/profile.d/* are only considered for >> login shells. With that, a reboot, logout/login, or sourcing /etc/profile >> in your current shell will give you the correct PATH setup. >> >> We are looking into letting the user know when installing the debian >> package (as opposed to the situation where snapd is already part of the >> image). See https://github.com/snapcore/snapd/pull/2819 for reference. >> >> Thanks for testing, >> >> Thomas >> >> >> >>> Which means that /snap/bin path is not added to the path after >>> installing the core. Also, when I run it under the /snap/bin, it shows: >>> >>> liuxg at liuxg:/snap/bin$ ./hello-world >>> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload >>> cannot be preloaded (cannot open shared object file): ignored. >>> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload >>> cannot be preloaded (cannot open shared object file): ignored. >>> Hello World! >>> >>> My desktop info is: >>> >>> liuxg at liuxg:~$ lsb_release -a >>> No LSB modules are available. >>> Distributor ID: Ubuntu >>> Description: Ubuntu 14.04.5 LTS >>> Release: 14.04 >>> Codename: trusty >>> >>> liuxg at liuxg:~$ snap list >>> Name Version Rev Developer Notes >>> core 16.04.1 888 canonical - >>> hello-world 6.3 27 canonical - >>> >>> Thanks & best regards, >>> XiaoGuo >>> >>> >>> On Wed, Feb 8, 2017 at 5:35 AM, Andrew Mason < >>> andrew at miniatureworldmaker.com.au> wrote: >>> >>>> Awesome, i am going to give this a try! >>>> >>>> On 8 February 2017 8:01:30 am ACDT, Manik Taneja >>>> wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth >>>>> wrote: >>>>> >>>>>> On 07/02/17 20:17, Thomas Voß wrote: >>>>>> > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xe >>>>>> nial/+bug/1655724 >>>>>> > was released to the updates pocket today. >>>>>> >>>>>> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, >>>>>> cloud or desktop, would be welcome. Pick a favorite snap and take it >>>>>> for >>>>>> a spin. >>>>>> >>>>> The experience is very clean now. I just tried on AWS and have >>>>> RocketChat up and >>>>> running- >>>>> >>>>> [image: Inline image 1] >>>>> Kudos to everyone involved in delivering this! >>>>> >>>>> Cheers, >>>>> Manik >>>>> >>>> >>>> -- >>>> Sent from my mobile device. >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> >>> >>> -- >>> XiaoGuo, Liu >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > XiaoGuo, Liu > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.barth at canonical.com Thu Feb 9 09:11:24 2017 From: david.barth at canonical.com (David Barth) Date: Thu, 9 Feb 2017 10:11:24 +0100 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: On Thu, Feb 9, 2017 at 7:36 AM, XiaoGuo Liu wrote: > Hi James, > > Thanks for your help. Yes, you are right! Now I do a new version of it, > and I used a wrapper to launch it. This time, the app can be launched > successfully, but still there is an error like: > > ** (process:29208): WARNING **: Unable to register app: > GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy > prevents this sender from sending this message to this recipient; > type="method_call", sender=":1.467" (uid=1000 pid=29208 > comm="webapp-container www/index.html ") interface="com.canonical.hud" > member="RegisterApplication" error name="(unset)" requested_reply="0" > destination=":1.36" (uid=1000 pid=2741 comm="/usr/lib/x86_64-linux-gnu/hud/hud-service > ") > This indicates that the webapp runtime is trying to bind to the HUD desktop service. This is an outdated binding. The htmlt-app-launcher is normally retired now or should point to webapp-container. Can you check with using mardy's webapp-helper part ? -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.voss at canonical.com Thu Feb 9 09:11:38 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Thu, 9 Feb 2017 10:11:38 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Message-ID: On Thu, Feb 9, 2017 at 10:09 AM, XiaoGuo Liu wrote: > Hi Jamie, > > For my case, right now, after I log out and login again (in fact, I > rebooted my machine). the /snap/bin path is still not added. Everything is > still the same. I cannot execute the "hello-word" snap app. I do not know > where I did wrongly. > > ​In this case, please file a bug against launchpad.net/snapd, and tag it with trusty. /snap/bin should be in your PATH after a reboot. Thanks, Thomas​ > Thanks & bestt regards, > XiaoGuo > > On Thu, Feb 9, 2017 at 5:05 PM, Jamie Bennett > wrote: > >> The simplest way is to log out and back in again. We are looking at other >> options on how to make this easier. >> >> Regards, >> Jamie. >> >> On 9 Feb 2017, at 09:02, XiaoGuo Liu wrote: >> >> Hi Thomas, >> >> So, an end user needs to manually add the path, right? It is not a little >> bit straightforward though. I think it would be good to come with detailed >> instructions. >> >> Thanks & best regards, >> XiaoGuo >> >> >> On Thu, Feb 9, 2017 at 4:39 PM, Thomas Voß >> wrote: >> >>> >>> >>> On Thu, Feb 9, 2017 at 5:02 AM, XiaoGuo Liu >>> wrote: >>> >>>> Hi, >>>> >>>> I just tried to install the snapd and installed a hello-world snap app >>>> on 14.04 desktop. However, I found a problem. When I un the hello-world, it >>>> shows: >>>> >>>> liuxg at liuxg:/snap/bin$ hello-world >>>> hello-world: command not found >>>> >>>> >>> This is expected behavior right now. PATH is adjusted in >>> /etc/profile.d/apps-bin-path.sh (comes with the snapd package). >>> /etc/profile and the entries in /etc/profile.d/* are only considered for >>> login shells. With that, a reboot, logout/login, or sourcing /etc/profile >>> in your current shell will give you the correct PATH setup. >>> >>> We are looking into letting the user know when installing the debian >>> package (as opposed to the situation where snapd is already part of the >>> image). See https://github.com/snapcore/snapd/pull/2819 for reference. >>> >>> Thanks for testing, >>> >>> Thomas >>> >>> >>> >>>> Which means that /snap/bin path is not added to the path after >>>> installing the core. Also, when I run it under the /snap/bin, it shows: >>>> >>>> liuxg at liuxg:/snap/bin$ ./hello-world >>>> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload >>>> cannot be preloaded (cannot open shared object file): ignored. >>>> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload >>>> cannot be preloaded (cannot open shared object file): ignored. >>>> Hello World! >>>> >>>> My desktop info is: >>>> >>>> liuxg at liuxg:~$ lsb_release -a >>>> No LSB modules are available. >>>> Distributor ID: Ubuntu >>>> Description: Ubuntu 14.04.5 LTS >>>> Release: 14.04 >>>> Codename: trusty >>>> >>>> liuxg at liuxg:~$ snap list >>>> Name Version Rev Developer Notes >>>> core 16.04.1 888 canonical - >>>> hello-world 6.3 27 canonical - >>>> >>>> Thanks & best regards, >>>> XiaoGuo >>>> >>>> >>>> On Wed, Feb 8, 2017 at 5:35 AM, Andrew Mason < >>>> andrew at miniatureworldmaker.com.au> wrote: >>>> >>>>> Awesome, i am going to give this a try! >>>>> >>>>> On 8 February 2017 8:01:30 am ACDT, Manik Taneja >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth >>>>>> wrote: >>>>>> >>>>>>> On 07/02/17 20:17, Thomas Voß wrote: >>>>>>> > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xe >>>>>>> nial/+bug/1655724 >>>>>>> > was released to the updates pocket today. >>>>>>> >>>>>>> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, >>>>>>> cloud or desktop, would be welcome. Pick a favorite snap and take it >>>>>>> for >>>>>>> a spin. >>>>>>> >>>>>> The experience is very clean now. I just tried on AWS and have >>>>>> RocketChat up and >>>>>> running- >>>>>> >>>>>> [image: Inline image 1] >>>>>> Kudos to everyone involved in delivering this! >>>>>> >>>>>> Cheers, >>>>>> Manik >>>>>> >>>>> >>>>> -- >>>>> Sent from my mobile device. >>>>> >>>>> -- >>>>> Snapcraft mailing list >>>>> Snapcraft at lists.snapcraft.io >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/snapcraft >>>>> >>>>> >>>> >>>> >>>> -- >>>> XiaoGuo, Liu >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> >> -- >> XiaoGuo, Liu >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Feb 9 09:18:36 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 9 Feb 2017 17:18:36 +0800 Subject: snapd available in Trusty Tahr In-Reply-To: References: <20170202073818.b2heyissfeo2tulw@x250> <6556B122-2762-4DB5-A37B-349EEAE94447@miniatureworldmaker.com.au> Message-ID: Hi Thomas, Thanks. I have reported a bug at https://bugs.launchpad.net/snapd/+bug/1663174 Best regards, XiaoGuo On Thu, Feb 9, 2017 at 5:11 PM, Thomas Voß wrote: > > > On Thu, Feb 9, 2017 at 10:09 AM, XiaoGuo Liu > wrote: > >> Hi Jamie, >> >> For my case, right now, after I log out and login again (in fact, I >> rebooted my machine). the /snap/bin path is still not added. Everything is >> still the same. I cannot execute the "hello-word" snap app. I do not know >> where I did wrongly. >> >> > ​In this case, please file a bug against launchpad.net/snapd, and tag it > with trusty. /snap/bin should be in your PATH after a reboot. > > Thanks, > > Thomas​ > > > >> Thanks & bestt regards, >> XiaoGuo >> >> On Thu, Feb 9, 2017 at 5:05 PM, Jamie Bennett < >> jamie.bennett at canonical.com> wrote: >> >>> The simplest way is to log out and back in again. We are looking at >>> other options on how to make this easier. >>> >>> Regards, >>> Jamie. >>> >>> On 9 Feb 2017, at 09:02, XiaoGuo Liu wrote: >>> >>> Hi Thomas, >>> >>> So, an end user needs to manually add the path, right? It is not a >>> little bit straightforward though. I think it would be good to come with >>> detailed instructions. >>> >>> Thanks & best regards, >>> XiaoGuo >>> >>> >>> On Thu, Feb 9, 2017 at 4:39 PM, Thomas Voß >>> wrote: >>> >>>> >>>> >>>> On Thu, Feb 9, 2017 at 5:02 AM, XiaoGuo Liu >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I just tried to install the snapd and installed a hello-world snap app >>>>> on 14.04 desktop. However, I found a problem. When I un the hello-world, it >>>>> shows: >>>>> >>>>> liuxg at liuxg:/snap/bin$ hello-world >>>>> hello-world: command not found >>>>> >>>>> >>>> This is expected behavior right now. PATH is adjusted in >>>> /etc/profile.d/apps-bin-path.sh (comes with the snapd package). >>>> /etc/profile and the entries in /etc/profile.d/* are only considered for >>>> login shells. With that, a reboot, logout/login, or sourcing /etc/profile >>>> in your current shell will give you the correct PATH setup. >>>> >>>> We are looking into letting the user know when installing the debian >>>> package (as opposed to the situation where snapd is already part of the >>>> image). See https://github.com/snapcore/snapd/pull/2819 for reference. >>>> >>>> Thanks for testing, >>>> >>>> Thomas >>>> >>>> >>>> >>>>> Which means that /snap/bin path is not added to the path after >>>>> installing the core. Also, when I run it under the /snap/bin, it shows: >>>>> >>>>> liuxg at liuxg:/snap/bin$ ./hello-world >>>>> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload >>>>> cannot be preloaded (cannot open shared object file): ignored. >>>>> ERROR: ld.so: object '/lib/$LIB/liblsp.so' from /etc/ld.so.preload >>>>> cannot be preloaded (cannot open shared object file): ignored. >>>>> Hello World! >>>>> >>>>> My desktop info is: >>>>> >>>>> liuxg at liuxg:~$ lsb_release -a >>>>> No LSB modules are available. >>>>> Distributor ID: Ubuntu >>>>> Description: Ubuntu 14.04.5 LTS >>>>> Release: 14.04 >>>>> Codename: trusty >>>>> >>>>> liuxg at liuxg:~$ snap list >>>>> Name Version Rev Developer Notes >>>>> core 16.04.1 888 canonical - >>>>> hello-world 6.3 27 canonical - >>>>> >>>>> Thanks & best regards, >>>>> XiaoGuo >>>>> >>>>> >>>>> On Wed, Feb 8, 2017 at 5:35 AM, Andrew Mason < >>>>> andrew at miniatureworldmaker.com.au> wrote: >>>>> >>>>>> Awesome, i am going to give this a try! >>>>>> >>>>>> On 8 February 2017 8:01:30 am ACDT, Manik Taneja >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth >>>>>>> wrote: >>>>>>> >>>>>>>> On 07/02/17 20:17, Thomas Voß wrote: >>>>>>>> > https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xe >>>>>>>> nial/+bug/1655724 >>>>>>>> > was released to the updates pocket today. >>>>>>>> >>>>>>>> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems, >>>>>>>> cloud or desktop, would be welcome. Pick a favorite snap and take >>>>>>>> it for >>>>>>>> a spin. >>>>>>>> >>>>>>> The experience is very clean now. I just tried on AWS and have >>>>>>> RocketChat up and >>>>>>> running- >>>>>>> >>>>>>> [image: Inline image 1] >>>>>>> Kudos to everyone involved in delivering this! >>>>>>> >>>>>>> Cheers, >>>>>>> Manik >>>>>>> >>>>>> >>>>>> -- >>>>>> Sent from my mobile device. >>>>>> >>>>>> -- >>>>>> Snapcraft mailing list >>>>>> Snapcraft at lists.snapcraft.io >>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>>> an/listinfo/snapcraft >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> XiaoGuo, Liu >>>>> >>>>> -- >>>>> Snapcraft mailing list >>>>> Snapcraft at lists.snapcraft.io >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/snapcraft >>>>> >>>>> >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> >>> >>> -- >>> XiaoGuo, Liu >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> >> -- >> XiaoGuo, Liu >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Thu Feb 9 09:27:19 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 9 Feb 2017 10:27:19 +0100 Subject: IPC between snaps Message-ID: <883133f4-7678-f006-de4f-3acd48159ed7@canonical.com> Hi, Is there any way to communicate processes in different snaps using pipes?. How can it be done in this or other way? Cheers. From thomas.voss at canonical.com Thu Feb 9 09:32:35 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Thu, 9 Feb 2017 10:32:35 +0100 Subject: chroot into a snap In-Reply-To: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> Message-ID: Hey Roberto, On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  wrote: > Hey engineers, > > I need some ideas to solve this: I'm trying to snap collaboraoffice > online but that's not being easy at all. FYI: this is a kind of Google > Drive stuff so that when you request in your browser certain document, > it is rendered and can be edit by many at the same time, etc.. > > Though I've been able to build from sources a snap package, that is only > working in classic confinement but not in devmode or strict. > > The reason is because the way it works: > - There is a server listening for documents requests > - for every new document requested an instance of a document manager is > started in a chrooted environment > - If requested n documents there will be n different chroot jails based > in same certain template > - document manager has certain linux capabilities to create the needed > roots (cap_fowner,cap_mknod,cap_sys_chroot...) > - the way of packaging the snap, currently, is by setting those caps and > call mksquashfs skipping -no-attrs option set by default by snapcraft > Could you please elaborate what is not working and how it fails? System logs, apparmor denials and seccomp messages would be needed here for further debugging. What is going wrong in the devmode case? Thanks, Thomas > I thought about a solution of having server in a snap and document > manager in another, but still there would be needed calling chroot for > every new document... ideas? > > BR. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From loic.minier at ubuntu.com Thu Feb 9 10:18:18 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Thu, 9 Feb 2017 11:18:18 +0100 Subject: IPC between snaps In-Reply-To: <883133f4-7678-f006-de4f-3acd48159ed7@canonical.com> References: <883133f4-7678-f006-de4f-3acd48159ed7@canonical.com> Message-ID: Hi, Yes, this is typically how you allow a snap to talk to snapd or docker daemon or lxd. You need a new interface to grant access to this socket path. If you'd like some examples or look at existing ones, grep for socket under github.com/snapcore/snapd/interfaces. Cheers, - Loïc On Thu, Feb 9, 2017 at 10:27 AM, Roberto Mier Escandón  < roberto.escandon at canonical.com> wrote: > Hi, > > Is there any way to communicate processes in different snaps using > pipes?. How can it be done in this or other way? > > > Cheers. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Thu Feb 9 10:35:41 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 9 Feb 2017 11:35:41 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> Message-ID: <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> Hey Thomas, You can find the snap at [1] Atttached are traces for: Devmode: - service.txt are the logs of the service - syslog.txt and snappy-debug.security.txt are the logs to see apparmor denials (warnings in this case). I cannot see more than ptrace ones. Classic: - service.classic.txt here i don't see any denial The only error shown is that the document has not been found. But the url is the same in classic or devmode, so that's not the reason of the problem. [1] https://github.com/rmescandon/loolwsd-snap BR. On 09/02/17 10:32, Thomas Voß wrote: > Hey Roberto, > > On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  > wrote: >> Hey engineers, >> >> I need some ideas to solve this: I'm trying to snap collaboraoffice >> online but that's not being easy at all. FYI: this is a kind of Google >> Drive stuff so that when you request in your browser certain document, >> it is rendered and can be edit by many at the same time, etc.. >> >> Though I've been able to build from sources a snap package, that is only >> working in classic confinement but not in devmode or strict. >> >> The reason is because the way it works: >> - There is a server listening for documents requests >> - for every new document requested an instance of a document manager is >> started in a chrooted environment >> - If requested n documents there will be n different chroot jails based >> in same certain template >> - document manager has certain linux capabilities to create the needed >> roots (cap_fowner,cap_mknod,cap_sys_chroot...) >> - the way of packaging the snap, currently, is by setting those caps and >> call mksquashfs skipping -no-attrs option set by default by snapcraft >> > > Could you please elaborate what is not working and how it fails? > System logs, apparmor denials > and seccomp messages would be needed here for further debugging. > > What is going wrong in the devmode case? > > Thanks, > > Thomas > >> I thought about a solution of having server in a snap and document >> manager in another, but still there would be needed calling chroot for >> every new document... ideas? >> >> BR. >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- Feb 9 11:20:17 lohengrin loolwsd[11923]: cmd.go:105: DEBUG: restarting into "/snap/core/current/usr/bin/snap" Feb 9 11:20:29 lohengrin kernel: [ 7751.981735] audit_printk_skb: 1536 callbacks suppressed Feb 9 11:20:29 lohengrin kernel: [ 7751.981747] audit: type=1400 audit(1486635629.848:55032): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libdl-2.23.so" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.017977] audit: type=1400 audit(1486635629.884:55033): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.020319] audit: type=1400 audit(1486635629.884:55034): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libgcc_s.so.1" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.020377] audit: type=1400 audit(1486635629.884:55035): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libpthread-2.23.so" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.020418] audit: type=1400 audit(1486635629.884:55036): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libc-2.23.so" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.116685] audit: type=1400 audit(1486635629.980:55037): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libcap.so.2.24" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.122184] audit: type=1400 audit(1486635629.988:55038): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libdl-2.23.so" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.122321] audit: type=1400 audit(1486635629.988:55039): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.122377] audit: type=1400 audit(1486635629.988:55040): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libgcc_s.so.1" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:29 lohengrin kernel: [ 7752.122423] audit: type=1400 audit(1486635629.988:55041): apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libpthread-2.23.so" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Feb 9 11:20:35 lohengrin kernel: [ 7757.158476] audit_printk_skb: 3 callbacks suppressed Feb 9 11:20:35 lohengrin kernel: [ 7757.158488] audit: type=1400 audit(1486635635.024:55043): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158530] audit: type=1400 audit(1486635635.024:55044): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158556] audit: type=1400 audit(1486635635.024:55045): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158580] audit: type=1400 audit(1486635635.024:55046): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158604] audit: type=1400 audit(1486635635.024:55047): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158626] audit: type=1400 audit(1486635635.024:55048): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158649] audit: type=1400 audit(1486635635.024:55049): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158674] audit: type=1400 audit(1486635635.024:55050): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158698] audit: type=1400 audit(1486635635.024:55051): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:35 lohengrin kernel: [ 7757.158721] audit: type=1400 audit(1486635635.024:55052): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179417] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:20:40 lohengrin kernel: [ 7762.179419] audit: type=1400 audit(1486635640.044:55545): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179460] audit: type=1400 audit(1486635640.044:55546): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179485] audit: type=1400 audit(1486635640.044:55547): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179509] audit: type=1400 audit(1486635640.044:55548): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179531] audit: type=1400 audit(1486635640.044:55549): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179553] audit: type=1400 audit(1486635640.044:55550): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179576] audit: type=1400 audit(1486635640.044:55551): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179598] audit: type=1400 audit(1486635640.044:55552): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179621] audit: type=1400 audit(1486635640.044:55553): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:40 lohengrin kernel: [ 7762.179645] audit: type=1400 audit(1486635640.044:55554): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198583] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:20:45 lohengrin kernel: [ 7767.198595] audit: type=1400 audit(1486635645.064:56047): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198637] audit: type=1400 audit(1486635645.064:56048): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198662] audit: type=1400 audit(1486635645.064:56049): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198686] audit: type=1400 audit(1486635645.064:56050): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198709] audit: type=1400 audit(1486635645.064:56051): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198732] audit: type=1400 audit(1486635645.064:56052): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198755] audit: type=1400 audit(1486635645.064:56053): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198778] audit: type=1400 audit(1486635645.064:56054): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198803] audit: type=1400 audit(1486635645.064:56055): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:45 lohengrin kernel: [ 7767.198825] audit: type=1400 audit(1486635645.064:56056): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223398] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:20:50 lohengrin kernel: [ 7772.223401] audit: type=1400 audit(1486635650.088:56549): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223444] audit: type=1400 audit(1486635650.088:56550): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223470] audit: type=1400 audit(1486635650.088:56551): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223495] audit: type=1400 audit(1486635650.088:56552): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223519] audit: type=1400 audit(1486635650.088:56553): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223543] audit: type=1400 audit(1486635650.088:56554): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223566] audit: type=1400 audit(1486635650.088:56555): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223590] audit: type=1400 audit(1486635650.088:56556): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223614] audit: type=1400 audit(1486635650.088:56557): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:50 lohengrin kernel: [ 7772.223639] audit: type=1400 audit(1486635650.088:56558): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243096] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:20:55 lohengrin kernel: [ 7777.243100] audit: type=1400 audit(1486635655.108:57051): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243167] audit: type=1400 audit(1486635655.108:57052): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243209] audit: type=1400 audit(1486635655.108:57053): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243246] audit: type=1400 audit(1486635655.108:57054): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243282] audit: type=1400 audit(1486635655.108:57055): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243316] audit: type=1400 audit(1486635655.108:57056): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243352] audit: type=1400 audit(1486635655.108:57057): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243390] audit: type=1400 audit(1486635655.108:57058): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243427] audit: type=1400 audit(1486635655.108:57059): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:20:55 lohengrin kernel: [ 7777.243464] audit: type=1400 audit(1486635655.108:57060): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271788] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:21:00 lohengrin kernel: [ 7782.271801] audit: type=1400 audit(1486635660.137:57553): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271844] audit: type=1400 audit(1486635660.137:57554): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271872] audit: type=1400 audit(1486635660.137:57555): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271896] audit: type=1400 audit(1486635660.137:57556): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271920] audit: type=1400 audit(1486635660.137:57557): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271945] audit: type=1400 audit(1486635660.137:57558): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271969] audit: type=1400 audit(1486635660.137:57559): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.271993] audit: type=1400 audit(1486635660.137:57560): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.272016] audit: type=1400 audit(1486635660.137:57561): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:00 lohengrin kernel: [ 7782.272040] audit: type=1400 audit(1486635660.137:57562): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292488] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:21:05 lohengrin kernel: [ 7787.292501] audit: type=1400 audit(1486635665.157:58055): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292546] audit: type=1400 audit(1486635665.157:58056): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292572] audit: type=1400 audit(1486635665.157:58057): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292597] audit: type=1400 audit(1486635665.157:58058): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292620] audit: type=1400 audit(1486635665.157:58059): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292642] audit: type=1400 audit(1486635665.157:58060): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292664] audit: type=1400 audit(1486635665.157:58061): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292687] audit: type=1400 audit(1486635665.157:58062): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292710] audit: type=1400 audit(1486635665.157:58063): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:05 lohengrin kernel: [ 7787.292732] audit: type=1400 audit(1486635665.157:58064): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316409] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:21:10 lohengrin kernel: [ 7792.316422] audit: type=1400 audit(1486635670.181:58557): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316484] audit: type=1400 audit(1486635670.181:58558): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316525] audit: type=1400 audit(1486635670.181:58559): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316573] audit: type=1400 audit(1486635670.181:58560): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316621] audit: type=1400 audit(1486635670.181:58561): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316667] audit: type=1400 audit(1486635670.181:58562): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316714] audit: type=1400 audit(1486635670.181:58563): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316761] audit: type=1400 audit(1486635670.181:58564): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316807] audit: type=1400 audit(1486635670.181:58565): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:10 lohengrin kernel: [ 7792.316863] audit: type=1400 audit(1486635670.181:58566): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339245] audit_printk_skb: 1476 callbacks suppressed Feb 9 11:21:15 lohengrin kernel: [ 7797.339257] audit: type=1400 audit(1486635675.205:59059): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339299] audit: type=1400 audit(1486635675.205:59060): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339325] audit: type=1400 audit(1486635675.205:59061): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339349] audit: type=1400 audit(1486635675.205:59062): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339372] audit: type=1400 audit(1486635675.205:59063): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339394] audit: type=1400 audit(1486635675.205:59064): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339416] audit: type=1400 audit(1486635675.205:59065): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339439] audit: type=1400 audit(1486635675.205:59066): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339461] audit: type=1400 audit(1486635675.205:59067): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:15 lohengrin kernel: [ 7797.339483] audit: type=1400 audit(1486635675.205:59068): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365154] audit_printk_skb: 1494 callbacks suppressed Feb 9 11:21:20 lohengrin kernel: [ 7802.365166] audit: type=1400 audit(1486635680.229:59567): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365211] audit: type=1400 audit(1486635680.229:59568): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365237] audit: type=1400 audit(1486635680.229:59569): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365260] audit: type=1400 audit(1486635680.229:59570): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365283] audit: type=1400 audit(1486635680.229:59571): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365306] audit: type=1400 audit(1486635680.229:59572): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365328] audit: type=1400 audit(1486635680.229:59573): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365350] audit: type=1400 audit(1486635680.229:59574): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365374] audit: type=1400 audit(1486635680.229:59575): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" Feb 9 11:21:20 lohengrin kernel: [ 7802.365398] audit: type=1400 audit(1486635680.229:59576): apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" -------------- next part -------------- = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libdl-2.23.so" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libdl-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libgcc_s.so.1" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libgcc_s.so.1 (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libpthread-2.23.so" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libpthread-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libc-2.23.so" pid=11946 comm="loolwsd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libc-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libcap.so.2.24" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libcap.so.2.24 (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libdl-2.23.so" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libdl-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libgcc_s.so.1" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libgcc_s.so.1 (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:29 Log: apparmor="ALLOWED" operation="open" profile="snap.loolwsd.loolwsd" name="/snap/core/888/lib/x86_64-linux-gnu/libpthread-2.23.so" pid=11954 comm="loolforkit" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /snap/core/888/lib/x86_64-linux-gnu/libpthread-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:35 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11969 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:40 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11973 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:45 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11979 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:50 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11983 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:20:55 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11987 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:00 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11994 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:05 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=11998 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:10 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12003 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:15 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12015 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:20 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12019 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" = AppArmor = Time: Feb 9 11:21:25 Log: apparmor="ALLOWED" operation="ptrace" profile="snap.loolwsd.loolwsd" pid=12023 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined" ^C -------------- next part -------------- sudo loolwsd + mkdir -p -m 750 /var/snap/loolwsd/common/cache + rm -rf /var/snap/loolwsd/common/cache/* + mkdir -p -m 750 /var/snap/loolwsd/x2/log + rm -rf /var/snap/loolwsd/x2/opt/lool + mkdir -p -m 750 /var/snap/loolwsd/x2/opt/lool/child-roots + mkdir -p -m 750 /var/snap/loolwsd/x2/etc /var/snap/loolwsd/x2/usr/share + [ -d /var/snap/loolwsd/x2/etc/loolwsd ] + [ -d /var/snap/loolwsd/x2/usr/share/loolwsd ] + [ -d /var/snap/loolwsd/x2/opt/collaboraoffice5.1 ] + rm -rf /var/snap/loolwsd/x2/opt/collaboraoffice5.1 + cp -r -p /snap/loolwsd/x2/opt/collaboraoffice5.1 /var/snap/loolwsd/x2/opt + [ -d /var/snap/loolwsd/x2/opt/lool/systemplate ] + cp -r -p /snap/loolwsd/x2/systemplate /var/snap/loolwsd/x2/opt/lool + export FONTCONFIG_PATH=/var/snap/loolwsd/x2/opt/lool/systemplate/etc/fonts + export FONTCONFIG_FILE=/var/snap/loolwsd/x2/opt/lool/systemplate/etc/fonts/fonts.conf + export LD_LIBRARY_PATH=/var/lib/snapd/lib/gl::/snap/loolwsd/x2/usr/lib:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu/mesa::/snap/loolwsd/x2/lib:/snap/loolwsd/x2/usr/lib:/snap/loolwsd/x2/lib/x86_64-linux-gnu:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu/mesa:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu/mesa-egl:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu/dri:/var/lib/snapd/lib/gl:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu/qt4:/snap/loolwsd/x2/usr/lib:/snap/loolwsd/x2/lib:/snap/loolwsd/x2/lib/x86_64-linux-gnu:/snap/loolwsd/x2/usr/lib/x86_64-linux-gnu + /snap/loolwsd/x2/usr/bin/loolwsd --o:sys_template_path=/var/snap/loolwsd/x2/opt/lool/systemplate --o:lo_template_path=/var/snap/loolwsd/x2/opt/collaboraoffice5.1 --o:child_root_path=/var/snap/loolwsd/x2/opt/lool/child-roots --o:file_server_root_path=/snap/loolwsd/x2/usr/share/loolwsd --config-file=/var/snap/loolwsd/x2/etc/loolwsd/loolwsd.xml wsd-11946-11946 10:20:29.970550 [ loolwsd ] INF Initializing wsd wsd-11946-11946 10:20:29.970615 [ loolwsd ] INF Log level is [7]. wsd-11946-11946 10:20:29.970646 [ loolwsd ] WRN SSL support: SSL is disabled.| wsd/LOOLWSD.cpp:1644 wsd-11946-11946 10:20:29.970704 [ loolwsd ] INF Open Documents Limit: 10| wsd/LOOLWSD.cpp:1674 wsd-11946-11946 10:20:29.970722 [ loolwsd ] INF Client Connections Limit: 20| wsd/LOOLWSD.cpp:1677 wsd-11946-11946 10:20:29.970847 [ loolwsd ] INF Command trace dumping enabled to file: /tmp/looltrace.gz| wsd/LOOLWSD.cpp:1701 wsd-11946-11946 10:20:29.970882 [ loolwsd ] INF Adding trusted WOPI host: [localhost].| wsd/Storage.cpp:82 wsd-11946-11946 10:20:29.970908 [ loolwsd ] INF Adding trusted WOPI host: [10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 wsd-11946-11946 10:20:29.970931 [ loolwsd ] INF Adding trusted WOPI host: [172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 wsd-11946-11946 10:20:29.970953 [ loolwsd ] INF Adding trusted WOPI host: [172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 wsd-11946-11946 10:20:29.970976 [ loolwsd ] INF Adding trusted WOPI host: [172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 wsd-11946-11946 10:20:29.970999 [ loolwsd ] INF Adding trusted WOPI host: [192\.168\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 wsd-11946-11946 10:20:29.971020 [ loolwsd ] INF Adding blocked WOPI host: [192\.168\.1\.1].| wsd/Storage.cpp:87 Launch this in your browser: http://localhost:9980/loleaflet/ba37507/loleaflet.html?file_path=file:///snap/loolwsd/x2/usr/bin/test/data/hello-world.odt wsd-11946-11946 10:20:29.971233 [ loolwsd ] DBG FileServerRoot: /snap/loolwsd/x2/usr/share/loolwsd| wsd/LOOLWSD.cpp:1992 wsd-11946-11946 10:20:29.971560 [ loolwsd ] INF Starting prisoner server listening on 9981| wsd/LOOLWSD.cpp:2024 wsd-11946-11946 10:20:29.971626 [ loolwsd ] INF Launching forkit process: /snap/loolwsd/x2/usr/bin/loolforkit --losubpath=lo --systemplate=/var/snap/loolwsd/x2/opt/lool/systemplate --lotemplate=/var/snap/loolwsd/x2/opt/collaboraoffice5.1 --childroot=/var/snap/loolwsd/x2/opt/lool/child-roots/ --clientport=9980 --masterport=9981| wsd/LOOLWSD.cpp:1912 wsd-11946-11946 10:20:29.971867 [ loolwsd ] INF Forkit process launched: 11954| wsd/LOOLWSD.cpp:1923 wsd-11946-11946 10:20:29.971905 [ loolwsd ] INF AdminModel ctor. wsd-11946-11946 10:20:29.971967 [ loolwsd ] INF Admin ctor. wsd-11946-11946 10:20:29.971986 [ loolwsd ] DBG Memory stat ctor wsd-11946-11946 10:20:29.972011 [ loolwsd ] DBG Cpu stat ctor frk-11954-11954 10:20:30.002904 [ loolforkit ] INF Initializing frk frk-11954-11954 10:20:30.002964 [ loolforkit ] INF Log level is [7]. frk-11954-11954 10:20:30.002986 [ loolforkit ] INF Have capability cap_sys_chroot| kit/ForKit.cpp:157 frk-11954-11954 10:20:30.003001 [ loolforkit ] INF Have capability cap_mknod| kit/ForKit.cpp:157 frk-11954-11954 10:20:30.003013 [ loolforkit ] INF Have capability cap_fowner| kit/ForKit.cpp:157 frk-11954-11954 10:20:31.356837 [ loolforkit ] INF Preinit stage OK.| kit/ForKit.cpp:392 frk-11954-11954 10:20:31.356878 [ loolforkit ] DBG Forking a loolkit process.| kit/ForKit.cpp:209 frk-11954-11954 10:20:31.358394 [ loolforkit ] INF Forked kit [11961].| kit/ForKit.cpp:244 frk-11954-11954 10:20:31.358440 [ loolforkit ] INF ForKit process is ready.| kit/ForKit.cpp:403 kit-11961-11961 10:20:31.358602 [ loolkit ] INF Initializing kit kit-11961-11961 10:20:31.358708 [ loolkit ] INF Log level is [7]. kit-11961-11961 10:20:31.358746 [ loolkit ] DBG Process started.| kit/Kit.cpp:1494 kit-11961-11961 10:20:31.358792 [ loolkit ] INF Jail path: /var/snap/loolwsd/x2/opt/lool/child-roots/11961/| kit/Kit.cpp:1508 kit-11961-11961 10:20:31.358957 [ loolkit ] DBG symlink("../../../../../lo","/var/snap/loolwsd/x2/opt/lool/child-roots/11961/var/snap/loolwsd/x2/opt/collaboraoffice5.1")| kit/Kit.cpp:265 kit-11961-11961 10:20:31.435275 [ loolkit ] DBG Initialized jail files.| kit/Kit.cpp:1565 kit-11961-11961 10:20:31.435387 [ loolkit ] INF chroot("/var/snap/loolwsd/x2/opt/lool/child-roots/11961/")| kit/Kit.cpp:1582 kit-11961-11961 10:20:31.435516 [ loolkit ] DBG Initialized jail nodes, dropped caps.| kit/Kit.cpp:1599 kit-11961-11961 10:20:31.473638 [ loolkit ] INF Process is ready.| kit/Kit.cpp:1626 wsd-11946-11947 10:20:31.474665 [ prsnr_req_hdl ] INF Request from 127.0.0.1:46964: GET /loolws/newchild?pid=11961&version=%7B%20%22ProductName%22:%20%22Collabora%20Office%22,%20%22ProductVersion%22:%20%225.1%22,%20%22ProductExtension%22:%20%22.10.18%22,%20%22BuildId%22:%20%22586626676b0aa697e153c6693a1e1407f7746989%22%20%7D HTTP/1.0 / Connection: Upgrade / Upgrade: websocket / Sec-WebSocket-Version: 13 / Sec-WebSocket-Key: SzlvDFCa9yZNBY8uvT8UKQ== / Host: 127.0.0.1:9981 wsd-11946-11947 10:20:31.474735 [ prsnr_req_hdl ] INF New child [11961].| wsd/LOOLWSD.cpp:1312 wsd-11946-11947 10:20:31.474837 [ prsnr_req_hdl ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 kit-11961-11961 10:20:31.474905 [ loolkit ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 it-11961-11961 10:20:31.474979 [ loolkit ] INF SocketProcessor [child_ws_11961] starting.| common/IoUtil.cpp:49 39mwsd-11946-11947 10:20:31.474944 [ prsnr_req_hdl ] INF ChildProcess ctor [11961].| wsd/DocumentBroker.hpp:51 wsd-11946-11966 10:20:31.475005 [ docbrk_ws_11961 ] INF SocketProcessor [docbrk_ws_11961] starting.| common/IoUtil.cpp:49 wsd-11946-11947 10:20:31.475171 [ prsnr_req_hdl ] INF Have 1 child.| wsd/LOOLWSD.cpp:401 wsd-11946-11946 10:20:31.475380 [ loolwsd ] INF Starting master server listening on 9980| wsd/LOOLWSD.cpp:2048 wsd-11946-11948 10:21:10.932088 [ client_req_hdl ] INF Request from 127.0.0.1:42408: GET /loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / Upgrade-Insecure-Requests: 1 wsd-11946-11948 10:21:10.932246 [ client_req_hdl ] DBG Preprocessing file: /snap/loolwsd/x2/usr/share/loolwsd//loleaflet/dist/loleaflet.html wsd-11946-11949 10:21:11.871704 [ client_req_hdl ] INF Request from 127.0.0.1:42410: GET /lool/file%3A%2F%2F%2Ftmp%2Fcv.odt%3Fpermission%3Dedit/ws HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Sec-WebSocket-Version: 13 / Origin: http://localhost:9980 / Sec-WebSocket-Extensions: permessage-deflate / Sec-WebSocket-Key: 6zCnjOwk/sT14X2RxOszCw== / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive, Upgrade / Pragma: no-cache / Cache-Control: no-cache / Upgrade: websocket wsd-11946-11949 10:21:11.871800 [ client_ws_0001 ] DBG Thread started.| wsd/LOOLWSD.cpp:1141 wsd-11946-11949 10:21:11.871820 [ client_ws_0001 ] DBG Handling: /lool/file%3A%2F%2F%2Ftmp%2Fcv.odt%3Fpermission%3Dedit/ws| wsd/LOOLWSD.cpp:1144 wsd-11946-11949 10:21:11.871923 [ client_ws_0001 ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 wsd-11946-11949 10:21:11.871954 [ client_ws_0001 ] INF Starting GET request handler for session [0001].| wsd/LOOLWSD.cpp:763 wsd-11946-11949 10:21:11.872029 [ client_ws_0001 ] DBG No DocumentBroker with docKey [/tmp/cv.odt] found. New Child and Document.| wsd/LOOLWSD.cpp:853 wsd-11946-11949 10:21:11.872066 [ client_ws_0001 ] DBG getNewChild: Have 1 children, forking 1| wsd/LOOLWSD.cpp:430 wsd-11946-11949 10:21:11.872103 [ client_ws_0001 ] DBG MasterToForKit: spawn 1| wsd/LOOLWSD.cpp:310 wsd-11946-11949 10:21:11.872135 [ client_ws_0001 ] DBG getNewChild: Returning new child [11961].| wsd/LOOLWSD.cpp:442 wsd-11946-11949 10:21:11.872147 [ client_ws_0001 ] DBG New DocumentBroker for docKey [/tmp/cv.odt].| wsd/LOOLWSD.cpp:885 wsd-11946-11949 10:21:11.872174 [ client_ws_0001 ] INF DocumentBroker [file:///tmp/cv.odt?permission=edit] created. DocKey: [/tmp/cv.odt]| wsd/DocumentBroker.cpp:172 wsd-11946-11949 10:21:11.872213 [ client_ws_0001 ] DBG Query param: permission, value: edit| wsd/LOOLWSD.cpp:908 wsd-11946-11949 10:21:11.872243 [ client_ws_0001 ] INF ClientSession ctor [ToClient-0001]. wsd-11946-11949 10:21:11.872363 [ client_ws_0001 ] INF Loading [/tmp/cv.odt] for session [0001] and jail [11961].| wsd/DocumentBroker.cpp:198 wsd-11946-12006 10:21:11.872361 [ client_ws_0001 ] DBG ToClient-0001 SenderThread started| wsd/ClientSession.cpp:468 wsd-11946-11949 10:21:11.872391 [ client_ws_0001 ] DBG Loading from URI: file:///tmp/cv.odt?permission=edit| wsd/DocumentBroker.cpp:214 wsd-11946-11949 10:21:11.872424 [ client_ws_0001 ] INF jailPath: /user/docs/11961, jailRoot: /var/snap/loolwsd/x2/opt/lool/child-roots/11961| wsd/DocumentBroker.cpp:229 wsd-11946-11949 10:21:11.872443 [ client_ws_0001 ] DBG Creating new storage instance for URI [file:///tmp/cv.odt?permission=edit].| wsd/DocumentBroker.cpp:236 wsd-11946-11949 10:21:11.872462 [ client_ws_0001 ] INF Public URI [file:///tmp/cv.odt?permission=edit] is a file.| wsd/Storage.cpp:156 wsd-11946-11949 10:21:11.872487 [ client_ws_0001 ] DBG Storage ctor: file:///tmp/cv.odt?permission=edit wsd-11946-11949 10:21:11.872503 [ client_ws_0001 ] INF LocalStorage ctor with localStorePath: [/var/snap/loolwsd/x2/opt/lool/child-roots/11961], jailPath: [/user/docs/11961], uri: [file:///tmp/cv.odt?permission=edit]. wsd-11946-11949 10:21:11.872528 [ client_ws_0001 ] DBG Getting info for local uri [file:///tmp/cv.odt?permission=edit], path [/tmp/cv.odt]. frk-11954-11954 10:21:11.873006 [ loolforkit ] INF ForKit command: [spawn 1].| kit/ForKit.cpp:93 frk-11954-11954 10:21:11.873049 [ loolforkit ] INF Spawning 1 child per request.| kit/ForKit.cpp:101 frk-11954-11954 10:21:11.873066 [ loolforkit ] INF Creating 1 new child.| kit/ForKit.cpp:419 frk-11954-11954 10:21:11.873079 [ loolforkit ] DBG Forking a loolkit process.| kit/ForKit.cpp:209 frk-11954-11954 10:21:11.875637 [ loolforkit ] INF Forked kit [12007].| kit/ForKit.cpp:244 kit-12007-12007 10:21:11.875881 [ loolkit ] INF Initializing kit kit-12007-12007 10:21:11.875954 [ loolkit ] INF Log level is [7]. kit-12007-12007 10:21:11.875995 [ loolkit ] DBG Process started.| kit/Kit.cpp:1494 kit-12007-12007 10:21:11.876024 [ loolkit ] INF Jail path: /var/snap/loolwsd/x2/opt/lool/child-roots/12007/| kit/Kit.cpp:1508 kit-12007-12007 10:21:11.876313 [ loolkit ] DBG symlink("../../../../../lo","/var/snap/loolwsd/x2/opt/lool/child-roots/12007/var/snap/loolwsd/x2/opt/collaboraoffice5.1")| kit/Kit.cpp:265 wsd-11946-11949 10:21:11.885162 [ client_ws_0001 ] ERR Error in client request handler: File not found| wsd/LOOLWSD.cpp:1038 wsd-11946-11949 10:21:11.885283 [ client_ws_0001 ] INF Finished GET request handler for session [0001].| wsd/LOOLWSD.cpp:1060 wsd-11946-11949 10:21:11.885319 [ client_ws_0001 ] INF ~ClientSession dtor [ToClient-0001]. wsd-11946-12006 10:21:11.885377 [ client_ws_0001 ] DBG SenderQueue: stopping| wsd/SenderQueue.hpp:177 wsd-11946-12006 10:21:11.885651 [ client_ws_0001 ] DBG ToClient-0001 SenderThread finished| wsd/ClientSession.cpp:495 wsd-11946-11949 10:21:11.885746 [ client_ws_0001 ] DBG Already sent response!?| wsd/LOOLWSD.cpp:1251 wsd-11946-11949 10:21:11.885922 [ client_ws_0001 ] DBG Thread finished.| wsd/LOOLWSD.cpp:1262 kit-12007-12007 10:21:11.983161 [ loolkit ] DBG Initialized jail files.| kit/Kit.cpp:1565 kit-12007-12007 10:21:11.983311 [ loolkit ] INF chroot("/var/snap/loolwsd/x2/opt/lool/child-roots/12007/")| kit/Kit.cpp:1582 kit-12007-12007 10:21:11.983450 [ loolkit ] DBG Initialized jail nodes, dropped caps.| kit/Kit.cpp:1599 kit-12007-12007 10:21:12.027157 [ loolkit ] INF Process is ready.| kit/Kit.cpp:1626 wsd-11946-11947 10:21:12.027467 [ prsnr_req_hdl ] INF Request from 127.0.0.1:46982: GET /loolws/newchild?pid=12007 HTTP/1.0 / Connection: Upgrade / Upgrade: websocket / Sec-WebSocket-Version: 13 / Sec-WebSocket-Key: ZMFATdFAmVUG2+VqurJiIQ== / Host: 127.0.0.1:9981 wsd-11946-11947 10:21:12.027508 [ prsnr_req_hdl ] INF New child [12007].| wsd/LOOLWSD.cpp:1312 wsd-11946-11947 10:21:12.027572 [ prsnr_req_hdl ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 kit-12007-12007 10:21:12.027623 [ loolkit ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57wsd-11946-11947 10:21:12.027627 [ prsnr_req_hdl ] INF ChildProcess ctor [12007].| wsd/DocumentBroker.hpp:51 wsd-11946-11947 10:21:12.027647 [ prsnr_req_hdl ] INF Have 1 child.| wsd/LOOLWSD.cpp:401 sd-11946-12012 10:21:12.027648 [ docbrk_ws_12007 ] INF SocketProcessor [docbrk_ws_12007] starting.| common/IoUtil.cpp:49390mkit-12007-12007 10:21:12.027658 [ loolkit ] INF SocketProcessor [child_ws_12007] starting.| common/IoUtil.cpp:49 -------------- next part -------------- Feb 9 11:28:36 lohengrin /usr/bin/snap[12798]: cmd.go:105: DEBUG: restarting into "/snap/core/current/usr/bin/snap" Feb 9 11:28:36 lohengrin snap[12798]: + mkdir -p -m 750 /var/snap/loolwsd/common/cache Feb 9 11:28:36 lohengrin snap[12798]: + rm -rf /var/snap/loolwsd/common/cache/* Feb 9 11:28:36 lohengrin snap[12798]: + mkdir -p -m 750 /var/snap/loolwsd/x4/log Feb 9 11:28:36 lohengrin snap[12798]: + rm -rf /var/snap/loolwsd/x4/opt/lool Feb 9 11:28:36 lohengrin /usr/lib/snapd/snapd[1144]: taskrunner.go:353: DEBUG: Running task 2140 on Do: Remove data for snap "loolwsd" (x1) Feb 9 11:28:36 lohengrin snap[12798]: + mkdir -p -m 750 /var/snap/loolwsd/x4/opt/lool/child-roots Feb 9 11:28:36 lohengrin snap[12798]: + mkdir -p -m 750 /var/snap/loolwsd/x4/etc /var/snap/loolwsd/x4/usr/share Feb 9 11:28:36 lohengrin snap[12798]: + [ -d /var/snap/loolwsd/x4/etc/loolwsd ] Feb 9 11:28:36 lohengrin snap[12798]: + [ -d /var/snap/loolwsd/x4/usr/share/loolwsd ] Feb 9 11:28:36 lohengrin snap[12798]: + [ -d /var/snap/loolwsd/x4/opt/collaboraoffice5.1 ] Feb 9 11:28:36 lohengrin snap[12798]: + rm -rf /var/snap/loolwsd/x4/opt/collaboraoffice5.1 Feb 9 11:28:37 lohengrin snap[12798]: + cp -r -p /snap/loolwsd/x4/opt/collaboraoffice5.1 /var/snap/loolwsd/x4/opt Feb 9 11:28:37 lohengrin /usr/lib/snapd/snapd[1144]: taskrunner.go:353: DEBUG: Running task 2141 on Do: Remove snap "loolwsd" (x1) from the system Feb 9 11:28:37 lohengrin systemd[1]: Unmounted Mount unit for loolwsd. Feb 9 11:28:37 lohengrin systemd[1]: Reloading. Feb 9 11:28:37 lohengrin systemd[1]: apt-daily.timer: Adding 3h 16min 7.611454s random time. Feb 9 11:28:37 lohengrin systemd[1]: snapd.refresh.timer: Adding 5h 49min 44.828983s random time. Feb 9 11:28:37 lohengrin systemd[1]: Started CUPS Scheduler. Feb 9 11:28:37 lohengrin systemd[1]: Started ACPI event daemon. Feb 9 11:28:37 lohengrin systemd[1]: Reloading. Feb 9 11:28:37 lohengrin systemd[1]: apt-daily.timer: Adding 11h 1min 43.433803s random time. Feb 9 11:28:37 lohengrin systemd[1]: snapd.refresh.timer: Adding 4h 15min 57.134664s random time. Feb 9 11:28:37 lohengrin systemd[1]: Started CUPS Scheduler. Feb 9 11:28:37 lohengrin systemd[1]: Started ACPI event daemon. Feb 9 11:28:37 lohengrin /usr/lib/snapd/snapd[1144]: taskrunner.go:353: DEBUG: Running task 2142 on Do: Clean up "loolwsd" (unset) install Feb 9 11:28:37 lohengrin /usr/lib/snapd/snapd[1144]: taskrunner.go:353: DEBUG: Running task 2143 on Do: Run configure hook of "loolwsd" snap if present Feb 9 11:28:37 lohengrin /usr/lib/snapd/snapd[1144]: daemon.go:176: DEBUG: uid=1000;@ GET /v2/snaps 1.512741ms 200 Feb 9 11:28:48 lohengrin snap[12798]: + [ -d /var/snap/loolwsd/x4/opt/lool/systemplate ] Feb 9 11:28:48 lohengrin snap[12798]: + cp -r -p /snap/loolwsd/x4/systemplate /var/snap/loolwsd/x4/opt/lool Feb 9 11:29:01 lohengrin snap[12798]: + export FONTCONFIG_PATH=/var/snap/loolwsd/x4/opt/lool/systemplate/etc/fonts Feb 9 11:29:01 lohengrin snap[12798]: + export FONTCONFIG_FILE=/var/snap/loolwsd/x4/opt/lool/systemplate/etc/fonts/fonts.conf Feb 9 11:29:01 lohengrin snap[12798]: + export LD_LIBRARY_PATH=/var/lib/snapd/lib/gl::/snap/loolwsd/x4/usr/lib:/snap/loolwsd/x4/usr/lib/x86_64-linux-gnu:/snap/loolwsd/x4/usr/lib/x86_64-linux-gnu/mesa:/snap/core/current/lib:/snap/core/current/usr/lib:/snap/core/current/lib/x86_64-linux-gnu:/snap/core/current/usr/lib/x86_64-linux-gnu:/snap/loolwsd/x4/lib:/snap/loolwsd/x4/usr/lib:/snap/loolwsd/x4/lib/x86_64-linux-gnu:/snap/loolwsd/x4/usr/lib/x86_64-linux-gnu:/snap/loolwsd/x4/usr/lib:/snap/loolwsd/x4/lib:/snap/loolwsd/x4/lib/x86_64-linux-gnu:/snap/loolwsd/x4/usr/lib/x86_64-linux-gnu Feb 9 11:29:01 lohengrin snap[12798]: + /snap/loolwsd/x4/usr/bin/loolwsd --o:sys_template_path=/var/snap/loolwsd/x4/opt/lool/systemplate --o:lo_template_path=/var/snap/loolwsd/x4/opt/collaboraoffice5.1 --o:child_root_path=/var/snap/loolwsd/x4/opt/lool/child-roots --o:file_server_root_path=/snap/loolwsd/x4/usr/share/loolwsd --config-file=/var/snap/loolwsd/x4/etc/loolwsd/loolwsd.xml Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.255447 [ loolwsd ] INF Initializing wsd Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.255499 [ loolwsd ] INF Log level is [7]. Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.255512 [ loolwsd ] WRN SSL support: SSL is disabled.| wsd/LOOLWSD.cpp:1644 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.255557 [ loolwsd ] INF Open Documents Limit: 10| wsd/LOOLWSD.cpp:1674 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.255567 [ loolwsd ] INF Client Connections Limit: 20| wsd/LOOLWSD.cpp:1677 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256257 [ loolwsd ] INF Command trace dumping enabled to file: /tmp/looltrace.gz| wsd/LOOLWSD.cpp:1701 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256294 [ loolwsd ] INF Adding trusted WOPI host: [localhost].| wsd/Storage.cpp:82 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256315 [ loolwsd ] INF Adding trusted WOPI host: [10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256333 [ loolwsd ] INF Adding trusted WOPI host: [172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256351 [ loolwsd ] INF Adding trusted WOPI host: [172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256366 [ loolwsd ] INF Adding trusted WOPI host: [172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256382 [ loolwsd ] INF Adding trusted WOPI host: [192\.168\.[0-9]{1,3}\.[0-9]{1,3}].| wsd/Storage.cpp:82 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256398 [ loolwsd ] INF Adding blocked WOPI host: [192\.168\.1\.1].| wsd/Storage.cpp:87 Feb 9 11:29:01 lohengrin snap[12798]: Launch this in your browser: Feb 9 11:29:01 lohengrin snap[12798]: http://localhost:9980/loleaflet/ba37507/loleaflet.html?file_path=file:///snap/loolwsd/x4/usr/bin/test/data/hello-world.odt Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.256750 [ loolwsd ] DBG FileServerRoot: /snap/loolwsd/x4/usr/share/loolwsd| wsd/LOOLWSD.cpp:1992 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.257107 [ loolwsd ] INF Starting prisoner server listening on 9981| wsd/LOOLWSD.cpp:2024 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.257171 [ loolwsd ] INF Launching forkit process: /snap/loolwsd/x4/usr/bin/loolforkit --losubpath=lo --systemplate=/var/snap/loolwsd/x4/opt/lool/systemplate --lotemplate=/var/snap/loolwsd/x4/opt/collaboraoffice5.1 --childroot=/var/snap/loolwsd/x4/opt/lool/child-roots/ --clientport=9980 --masterport=9981| wsd/LOOLWSD.cpp:1912 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.257398 [ loolwsd ] INF Forkit process launched: 12865| wsd/LOOLWSD.cpp:1923 Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.257433 [ loolwsd ] INF AdminModel ctor. Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.257501 [ loolwsd ] INF Admin ctor. Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.257516 [ loolwsd ] DBG Memory stat ctor Feb 9 11:29:01 lohengrin snap[12798]: wsd-12857-12857 10:29:01.257537 [ loolwsd ] DBG Cpu stat ctor Feb 9 11:29:01 lohengrin snap[12798]: frk-12865-12865 10:29:01.311211 [ loolforkit ] INF Initializing frk Feb 9 11:29:01 lohengrin snap[12798]: frk-12865-12865 10:29:01.311300 [ loolforkit ] INF Log level is [7]. Feb 9 11:29:01 lohengrin snap[12798]: frk-12865-12865 10:29:01.311345 [ loolforkit ] INF Have capability cap_sys_chroot| kit/ForKit.cpp:157 Feb 9 11:29:01 lohengrin snap[12798]: frk-12865-12865 10:29:01.311358 [ loolforkit ] INF Have capability cap_mknod| kit/ForKit.cpp:157 Feb 9 11:29:01 lohengrin snap[12798]: frk-12865-12865 10:29:01.311366 [ loolforkit ] INF Have capability cap_fowner| kit/ForKit.cpp:157 Feb 9 11:29:02 lohengrin snap[12798]: frk-12865-12865 10:29:02.210800 [ loolforkit ] INF Preinit stage OK.| kit/ForKit.cpp:392 Feb 9 11:29:02 lohengrin snap[12798]: frk-12865-12865 10:29:02.210838 [ loolforkit ] DBG Forking a loolkit process.| kit/ForKit.cpp:209 Feb 9 11:29:02 lohengrin snap[12798]: frk-12865-12865 10:29:02.212140 [ loolforkit ] INF Forked kit [12869].| kit/ForKit.cpp:244 Feb 9 11:29:02 lohengrin snap[12798]: frk-12865-12865 10:29:02.212190 [ loolforkit ] INF ForKit process is ready.| kit/ForKit.cpp:403 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.212353 [ loolkit ] INF Initializing kit Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.212421 [ loolkit ] INF Log level is [7]. Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.212455 [ loolkit ] DBG Process started.| kit/Kit.cpp:1494 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.212493 [ loolkit ] INF Jail path: /var/snap/loolwsd/x4/opt/lool/child-roots/12869/| kit/Kit.cpp:1508 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.212742 [ loolkit ] DBG symlink("../../../../../lo","/var/snap/loolwsd/x4/opt/lool/child-roots/12869/var/snap/loolwsd/x4/opt/collaboraoffice5.1")| kit/Kit.cpp:265 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.283754 [ loolkit ] DBG Initialized jail files.| kit/Kit.cpp:1565 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.283862 [ loolkit ] INF chroot("/var/snap/loolwsd/x4/opt/lool/child-roots/12869/")| kit/Kit.cpp:1582 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.283989 [ loolkit ] DBG Initialized jail nodes, dropped caps.| kit/Kit.cpp:1599 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.325303 [ loolkit ] INF Process is ready.| kit/Kit.cpp:1626 Feb 9 11:29:02 lohengrin snap[12798]: wsd-12857-12858 10:29:02.326106 [ prsnr_req_hdl ] INF Request from 127.0.0.1:47042: GET /loolws/newchild?pid=12869&version=%7B%20%22ProductName%22:%20%22Collabora%20Office%22,%20%22ProductVersion%22:%20%225.1%22,%20%22ProductExtension%22:%20%22.10.18%22,%20%22BuildId%22:%20%22586626676b0aa697e153c6693a1e1407f7746989%22%20%7D HTTP/1.0 / Connection: Upgrade / Upgrade: websocket / Sec-WebSocket-Version: 13 / Sec-WebSocket-Key: Fi5tHh6qD0LZQzUBVGMTew== / Host: 127.0.0.1:9981 Feb 9 11:29:02 lohengrin snap[12798]: wsd-12857-12858 10:29:02.326169 [ prsnr_req_hdl ] INF New child [12869].| wsd/LOOLWSD.cpp:1312 Feb 9 11:29:02 lohengrin snap[12798]: wsd-12857-12858 10:29:02.326279 [ prsnr_req_hdl ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 Feb 9 11:29:02 lohengrin snap[12798]: wsd-12857-12858 10:29:02.326333 [ prsnr_req_hdl ] INF ChildProcess ctor [12869].| wsd/DocumentBroker.hpp:51 Feb 9 11:29:02 lohengrin snap[12798]: wsd-12857-12858 10:29:02.326346 [ prsnr_req_hdl ] INF Have 1 child.| wsd/LOOLWSD.cpp:401 Feb 9 11:29:02 lohengrin snap[12798]: wsd-12857-12857 10:29:02.326443 [ loolwsd ] INF Starting master server listening on 9980| wsd/LOOLWSD.cpp:2048 Feb 9 11:29:02 lohengrin snap[12798]: wsd-12857-12874 10:29:02.326517 [ docbrk_ws_12869 ] INF SocketProcessor [docbrk_ws_12869] starting.| common/IoUtil.cpp:49 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.327038 [ loolkit ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 Feb 9 11:29:02 lohengrin snap[12798]: kit-12869-12869 10:29:02.327074 [ loolkit ] INF SocketProcessor [child_ws_12869] starting.| common/IoUtil.cpp:49 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.507072 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / Upgrade-Insecure-Requests: 1 / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.507217 [ client_req_hdl ] DBG Preprocessing file: /snap/loolwsd/x4/usr/share/loolwsd//loleaflet/dist/loleaflet.html Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.560455 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/ba37507/branding.css HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: text/css,*/*;q=0.1 / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Fri, 13 Jan 2017 11:27:37 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12860 10:29:04.561902 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/ba37507/branding.js HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Thu, 12 Jan 2017 10:19:23 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12860 10:29:04.598192 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/ba37507/toolbar/w2ui.min.js HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.598193 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/ba37507/bundle.js HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:46:56 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12863 10:29:04.599092 [ client_req_hdl ] INF Request from 127.0.0.1:42482: GET /loleaflet/ba37507/images/toolbar-bg.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/ba37507/branding.css / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Thu, 12 Jan 2017 10:19:23 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12877 10:29:04.615133 [ client_req_hdl ] INF Request from 127.0.0.1:42484: GET /loleaflet/ba37507/toolbar/toolbar.js HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.834664 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/ba37507/l10n/help-localizations.json HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.857226 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/ba37507/l10n/uno-localizations.json HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.874844 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/ba37507/l10n/styles-localizations.json HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:04 lohengrin snap[12798]: wsd-12857-12859 10:29:04.897072 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/ba37507/l10n/localizations.json HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12859 10:29:05.184229 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/dist/images/lc_save.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.185603 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/lc_undo.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12877 10:29:05.186699 [ client_req_hdl ] INF Request from 127.0.0.1:42484: GET /loleaflet/dist/images/lc_redo.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12863 10:29:05.188044 [ client_req_hdl ] INF Request from 127.0.0.1:42482: GET /loleaflet/dist/images/lc_backward.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.241265 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/lc_italic.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12862 10:29:05.241410 [ client_req_hdl ] INF Request from 127.0.0.1:42480: GET /loleaflet/dist/images/lc_strikeout.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12861 10:29:05.241693 [ client_req_hdl ] INF Request from 127.0.0.1:42478: GET /loleaflet/dist/images/lc_color.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12877 10:29:05.242073 [ client_req_hdl ] INF Request from 127.0.0.1:42484: GET /loleaflet/dist/images/lc_backcolor.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12861 10:29:05.242324 [ client_req_hdl ] INF Request from 127.0.0.1:42478: GET /loleaflet/dist/images/lc_alignleft.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.242359 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/lc_alignhorizontalcenter.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12862 10:29:05.242560 [ client_req_hdl ] INF Request from 127.0.0.1:42480: GET /loleaflet/dist/images/lc_alignright.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12859 10:29:05.241263 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/dist/images/lc_bold.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12863 10:29:05.241263 [ client_req_hdl ] INF Request from 127.0.0.1:42482: GET /loleaflet/dist/images/lc_underline.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12861 10:29:05.243099 [ client_req_hdl ] INF Request from 127.0.0.1:42478: GET /loleaflet/dist/images/lc_alignblock.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.243117 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/lc_wraptext.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12877 10:29:05.243325 [ client_req_hdl ] INF Request from 127.0.0.1:42484: GET /loleaflet/dist/images/lc_togglemergecells.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12863 10:29:05.243350 [ client_req_hdl ] INF Request from 127.0.0.1:42482: GET /loleaflet/dist/images/lc_currencyfield.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12862 10:29:05.243540 [ client_req_hdl ] INF Request from 127.0.0.1:42480: GET /loleaflet/dist/images/lc_numberformatpercent.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12859 10:29:05.243565 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/dist/images/lc_numberformatdecimal.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12861 10:29:05.244012 [ client_req_hdl ] INF Request from 127.0.0.1:42478: GET /loleaflet/dist/images/lc_datefield.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.244030 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/lc_numberformatincdecimals.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12877 10:29:05.244249 [ client_req_hdl ] INF Request from 127.0.0.1:42484: GET /loleaflet/dist/images/lc_numberformatdecdecimals.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12863 10:29:05.244287 [ client_req_hdl ] INF Request from 127.0.0.1:42482: GET /loleaflet/dist/images/lc_sortascending.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12862 10:29:05.244489 [ client_req_hdl ] INF Request from 127.0.0.1:42480: GET /loleaflet/dist/images/lc_sortdescending.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12859 10:29:05.244513 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/dist/images/lc_defaultbullet.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12861 10:29:05.244924 [ client_req_hdl ] INF Request from 127.0.0.1:42478: GET /loleaflet/dist/images/lc_defaultnumbering.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.244945 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/lc_decrementlevel.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12877 10:29:05.245143 [ client_req_hdl ] INF Request from 127.0.0.1:42484: GET /loleaflet/dist/images/lc_decrementindent.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12863 10:29:05.245171 [ client_req_hdl ] INF Request from 127.0.0.1:42482: GET /loleaflet/dist/images/lc_inserttable.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12862 10:29:05.245365 [ client_req_hdl ] INF Request from 127.0.0.1:42480: GET /loleaflet/dist/images/lc_showannotations.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12859 10:29:05.245389 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/dist/images/lc_gallery.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12861 10:29:05.245787 [ client_req_hdl ] INF Request from 127.0.0.1:42478: GET /loleaflet/dist/images/lc_insertsymbol.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.245808 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/lc_downsearch.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12877 10:29:05.245999 [ client_req_hdl ] INF Request from 127.0.0.1:42484: GET /loleaflet/dist/images/lc_autosum.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12863 10:29:05.246035 [ client_req_hdl ] INF Request from 127.0.0.1:42482: GET /loleaflet/dist/images/lc26049.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12862 10:29:05.246219 [ client_req_hdl ] INF Request from 127.0.0.1:42480: GET /loleaflet/dist/images/lc_upsearch.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12859 10:29:05.246242 [ client_req_hdl ] INF Request from 127.0.0.1:42474: GET /loleaflet/dist/images/lc_view100.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12860 10:29:05.246696 [ client_req_hdl ] INF Request from 127.0.0.1:42476: GET /loleaflet/dist/images/plus.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12861 10:29:05.250738 [ client_req_hdl ] INF Request from 127.0.0.1:42478: GET /loleaflet/dist/images/minus.png HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: */* / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Referer: http://localhost:9980/loleaflet/dist/loleaflet.html?file_path=file:///tmp/cv.odt / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive / If-Modified-Since: Wed, 08 Feb 2017 13:43:20 GMT / Cache-Control: max-age=0 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352061 [ client_req_hdl ] INF Request from 127.0.0.1:42486: GET /lool/file%3A%2F%2F%2Ftmp%2Fcv.odt%3Fpermission%3Dedit/ws HTTP/1.1 / Host: localhost:9980 / User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 / Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 / Accept-Language: en-US,en;q=0.5 / Accept-Encoding: gzip, deflate / Sec-WebSocket-Version: 13 / Origin: http://localhost:9980 / Sec-WebSocket-Extensions: permessage-deflate / Sec-WebSocket-Key: fuB6ZZEdHKGGFR7YKzNVhQ== / Cookie: nc_sameSiteCookielax=true; nc_sameSiteCookiestrict=true / Connection: keep-alive, Upgrade / Pragma: no-cache / Cache-Control: no-cache / Upgrade: websocket Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352132 [ client_ws_0001 ] DBG Thread started.| wsd/LOOLWSD.cpp:1141 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352147 [ client_ws_0001 ] DBG Handling: /lool/file%3A%2F%2F%2Ftmp%2Fcv.odt%3Fpermission%3Dedit/ws| wsd/LOOLWSD.cpp:1144 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352244 [ client_ws_0001 ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352271 [ client_ws_0001 ] INF Starting GET request handler for session [0001].| wsd/LOOLWSD.cpp:763 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352341 [ client_ws_0001 ] DBG No DocumentBroker with docKey [/tmp/cv.odt] found. New Child and Document.| wsd/LOOLWSD.cpp:853 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352374 [ client_ws_0001 ] DBG getNewChild: Have 1 children, forking 1| wsd/LOOLWSD.cpp:430 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.352409 [ client_ws_0001 ] DBG MasterToForKit: spawn 1| wsd/LOOLWSD.cpp:310 Feb 9 11:29:05 lohengrin snap[12798]: frk-12865-12865 10:29:05.352457 [ loolforkit ] INF ForKit command: [spawn 1].| kit/ForKit.cpp:93 Feb 9 11:29:05 lohengrin snap[12798]: frk-12865-12865 10:29:05.352490 [ loolforkit ] INF Spawning 1 child per request.| kit/ForKit.cpp:101 Feb 9 11:29:05 lohengrin snap[12798]: frk-12865-12865 10:29:05.352501 [ loolforkit ] INF Creating 1 new child.| kit/ForKit.cpp:419 Feb 9 11:29:05 lohengrin snap[12798]: frk-12865-12865 10:29:05.352510 [ loolforkit ] DBG Forking a loolkit process.| kit/ForKit.cpp:209 Feb 9 11:29:05 lohengrin snap[12798]: frk-12865-12865 10:29:05.354315 [ loolforkit ] INF Forked kit [12879].| kit/ForKit.cpp:244 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.354511 [ loolkit ] INF Initializing kit Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354546 [ client_ws_0001 ] DBG getNewChild: Returning new child [12869].| wsd/LOOLWSD.cpp:442 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.354563 [ loolkit ] INF Log level is [7]. Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354572 [ client_ws_0001 ] DBG New DocumentBroker for docKey [/tmp/cv.odt].| wsd/LOOLWSD.cpp:885 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.354598 [ loolkit ] DBG Process started.| kit/Kit.cpp:1494 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354613 [ client_ws_0001 ] INF DocumentBroker [file:///tmp/cv.odt?permission=edit] created. DocKey: [/tmp/cv.odt]| wsd/DocumentBroker.cpp:172 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.354648 [ loolkit ] INF Jail path: /var/snap/loolwsd/x4/opt/lool/child-roots/12879/| kit/Kit.cpp:1508 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354680 [ client_ws_0001 ] DBG Query param: permission, value: edit| wsd/LOOLWSD.cpp:908 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354703 [ client_ws_0001 ] INF ClientSession ctor [ToClient-0001]. Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12880 10:29:05.354767 [ client_ws_0001 ] DBG ToClient-0001 SenderThread started| wsd/ClientSession.cpp:468 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354800 [ client_ws_0001 ] INF Loading [/tmp/cv.odt] for session [0001] and jail [12869].| wsd/DocumentBroker.cpp:198 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354818 [ client_ws_0001 ] DBG Loading from URI: file:///tmp/cv.odt?permission=edit| wsd/DocumentBroker.cpp:214 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354840 [ client_ws_0001 ] INF jailPath: /user/docs/12869, jailRoot: /var/snap/loolwsd/x4/opt/lool/child-roots/12869| wsd/DocumentBroker.cpp:229 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354853 [ client_ws_0001 ] DBG Creating new storage instance for URI [file:///tmp/cv.odt?permission=edit].| wsd/DocumentBroker.cpp:236 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354866 [ client_ws_0001 ] INF Public URI [file:///tmp/cv.odt?permission=edit] is a file.| wsd/Storage.cpp:156 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354883 [ client_ws_0001 ] DBG Storage ctor: file:///tmp/cv.odt?permission=edit Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.354881 [ loolkit ] DBG symlink("../../../../../lo","/var/snap/loolwsd/x4/opt/lool/child-roots/12879/var/snap/loolwsd/x4/opt/collaboraoffice5.1")| kit/Kit.cpp:265 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354892 [ client_ws_0001 ] INF LocalStorage ctor with localStorePath: [/var/snap/loolwsd/x4/opt/lool/child-roots/12869], jailPath: [/user/docs/12869], uri: [file:///tmp/cv.odt?permission=edit]. Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354909 [ client_ws_0001 ] DBG Getting info for local uri [file:///tmp/cv.odt?permission=edit], path [/tmp/cv.odt]. Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.354941 [ client_ws_0001 ] DBG Setting username [Local Host #0] and userId [localhost] for session [0001]| wsd/DocumentBroker.cpp:306 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.355049 [ client_ws_0001 ] INF Public URI [/tmp/cv.odt] jailed to [/var/snap/loolwsd/x4/opt/lool/child-roots/12869/user/docs/12869/cv.odt].| wsd/Storage.cpp:216 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.355068 [ client_ws_0001 ] INF Linking /tmp/cv.odt to /var/snap/loolwsd/x4/opt/lool/child-roots/12869/user/docs/12869/cv.odt| wsd/Storage.cpp:226 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.355160 [ client_ws_0001 ] INF TileCache ctor for uri [file:///tmp/cv.odt?permission=edit] modifiedTime=1486636145 getLastModified()=0 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.355410 [ loolkit ] DBG child_ws_12869: recv [session 0001 /tmp/cv.odt].| kit/Kit.cpp:1663 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.355433 [ loolkit ] INF New session [0001] request on url [/tmp/cv.odt].| kit/Kit.cpp:1678 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.355463 [ loolkit ] INF Document ctor for url [/tmp/cv.odt] on child [12869].| kit/Kit.cpp:460 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.355494 [ loolkit ] INF Creating first session for url: /tmp/cv.odt for sessionId: 0001 on jailId: 12869| kit/Kit.cpp:494 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.355512 [ loolkit ] INF ChildSession ctor [ToMaster-0001].| kit/ChildSession.cpp:46 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.355529 [ loolkit ] DBG Sessions: 1| kit/Kit.cpp:499 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.355565 [ client_ws_0001 ] DBG Added admin document [/tmp/cv.odt].| wsd/AdminModel.cpp:247 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.361196 [ lok_handler ] DBG Thread started.| kit/Kit.cpp:1309 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.381858 [ client_ws_0001 ] INF PrisonerSession ctor [ToPrisoner-0001].| wsd/PrisonerSession.cpp:44 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.381993 [ client_ws_0001 ] INF SocketProcessor [client_ws_0001] starting.| common/IoUtil.cpp:49 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.449716 [ loolkit ] DBG Initialized jail files.| kit/Kit.cpp:1565 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.449863 [ loolkit ] INF chroot("/var/snap/loolwsd/x4/opt/lool/child-roots/12879/")| kit/Kit.cpp:1582 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.449988 [ loolkit ] DBG Initialized jail nodes, dropped caps.| kit/Kit.cpp:1599 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.487716 [ loolkit ] INF Process is ready.| kit/Kit.cpp:1626 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12858 10:29:05.488360 [ prsnr_req_hdl ] INF Request from 127.0.0.1:47058: GET /loolws/newchild?pid=12879 HTTP/1.0 / Connection: Upgrade / Upgrade: websocket / Sec-WebSocket-Version: 13 / Sec-WebSocket-Key: wi6SF6XTa1xaNHkJZ3ffQA== / Host: 127.0.0.1:9981 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12858 10:29:05.488414 [ prsnr_req_hdl ] INF New child [12879].| wsd/LOOLWSD.cpp:1312 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12858 10:29:05.488487 [ prsnr_req_hdl ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12858 10:29:05.488539 [ prsnr_req_hdl ] INF ChildProcess ctor [12879].| wsd/DocumentBroker.hpp:51 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12858 10:29:05.488561 [ prsnr_req_hdl ] INF Have 1 child.| wsd/LOOLWSD.cpp:401 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.488564 [ loolkit ] INF Send buffer size for web socket set to minimum: 4608| ./wsd/LOOLWebSocket.hpp:57 Feb 9 11:29:05 lohengrin snap[12798]: kit-12879-12879 10:29:05.488616 [ loolkit ] INF SocketProcessor [child_ws_12879] starting.| common/IoUtil.cpp:49 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12889 10:29:05.488688 [ docbrk_ws_12879 ] INF SocketProcessor [docbrk_ws_12879] starting.| common/IoUtil.cpp:49 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.499479 [ client_ws_0001 ] INF Requesting document load from child. Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.499608 [ client_ws_0001 ] INF Could not open /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/partpagerectangles.txt Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.499708 [ loolkit ] DBG child_ws_12869: recv [child-0001 load url=file:///tmp/cv.odt?permission=edit jail=file:///user/docs/12869/cv.odt authorid=localhost author=Loc...].| kit/Kit.cpp:1663 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.499812 [ loolkit ] DBG child_ws_12869: recv [child-0001 partpagerectangles].| kit/Kit.cpp:1663 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.499898 [ lok_handler ] INF Loading session [0001] on url [file:///user/docs/12869/cv.odt] is loading. 1 views loaded.| kit/Kit.cpp:912 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.499916 [ lok_handler ] INF Loading new document from URI: [file:///user/docs/12869/cv.odt] for session [0001].| kit/Kit.cpp:1126 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.499933 [ lok_handler ] DBG Calling lokit::documentLoad.| kit/Kit.cpp:1141 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.770878 [ lok_handler ] DBG Returned lokit::documentLoad.| kit/Kit.cpp:1143 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.842933 [ lok_handler ] INF Document [/tmp/cv.odt] view [0] loaded. Have 1 view.| kit/Kit.cpp:1247 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.842983 [ lok_handler ] INF Created new view with viewid: [0] for username: [Local Host #0] in session: [0001].| kit/ChildSession.cpp:339 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.845928 [ lok_handler ] DBG Sending status after loading view 0.| kit/ChildSession.cpp:352 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12881 10:29:05.846361 [ lok_handler ] INF Loaded session 0001| kit/ChildSession.cpp:370 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.849976 [ client_ws_0001 ] INF Could not open /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/cmdValues.uno:StyleApply.txt Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12878 10:29:05.850107 [ client_ws_0001 ] INF Could not open /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/cmdValues.uno:CharFontName.txt Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.850287 [ loolkit ] DBG child_ws_12869: recv [child-0001 commandvalues command=.uno:StyleApply].| kit/Kit.cpp:1663 Feb 9 11:29:05 lohengrin snap[12798]: kit-12869-12869 10:29:05.850388 [ loolkit ] DBG child_ws_12869: recv [child-0001 commandvalues command=.uno:CharFontName].| kit/Kit.cpp:1663 Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12874 10:29:05.853347 [ docbrk_ws_12869 ] INF Saving 'commandvalues: {...' to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/cmdValues.uno:StyleApply.txt Feb 9 11:29:05 lohengrin snap[12798]: wsd-12857-12874 10:29:05.882045 [ docbrk_ws_12869 ] INF Saving 'commandvalues: {...' to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/cmdValues.uno:CharFontName.txt Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168001 [ client_ws_0001 ] DBG Subscribing to tile (0,0,0) which has no subscribers. Subscribing for ver: 1. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168057 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,0) which has no subscribers. Subscribing for ver: 2. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168092 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,0) which has no subscribers. Subscribing for ver: 3. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168126 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,0) which has no subscribers. Subscribing for ver: 4. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168158 [ client_ws_0001 ] DBG Subscribing to tile (0,0,3840) which has no subscribers. Subscribing for ver: 5. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168194 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,3840) which has no subscribers. Subscribing for ver: 6. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168228 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,3840) which has no subscribers. Subscribing for ver: 7. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168261 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,3840) which has no subscribers. Subscribing for ver: 8. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168290 [ client_ws_0001 ] DBG Subscribing to tile (0,0,7680) which has no subscribers. Subscribing for ver: 9. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168325 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,7680) which has no subscribers. Subscribing for ver: 10. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168360 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,7680) which has no subscribers. Subscribing for ver: 11. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168397 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,7680) which has no subscribers. Subscribing for ver: 12. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168432 [ client_ws_0001 ] DBG Subscribing to tile (0,0,11520) which has no subscribers. Subscribing for ver: 13. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168467 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,11520) which has no subscribers. Subscribing for ver: 14. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168503 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,11520) which has no subscribers. Subscribing for ver: 15. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168540 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,11520) which has no subscribers. Subscribing for ver: 16. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168575 [ client_ws_0001 ] DBG Subscribing to tile (0,0,15360) which has no subscribers. Subscribing for ver: 17. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168621 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,15360) which has no subscribers. Subscribing for ver: 18. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168660 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,15360) which has no subscribers. Subscribing for ver: 19. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168696 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,15360) which has no subscribers. Subscribing for ver: 20. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12878 10:29:06.168786 [ client_ws_0001 ] DBG Sending residual tilecombine: tilecombine part=0 width=256 height=256 tileposx=0,3840,7680,11520,0,3840,7680,11520,0,3840,7680,11520,0,3840,7680,11520,0,3840,7680,11520 tileposy=0,0,0,0,3840,3840,3840,3840,7680,7680,7680,7680,11520,11520,11520,11520,15360,15360,15360,15360 imgsize=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 tilewidth=3840 tileheight=3840 ver=21| wsd/DocumentBroker.cpp:800 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12869 10:29:06.168936 [ loolkit ] DBG child_ws_12869: recv [tilecombine part=0 width=256 height=256 tileposx=0,3840,7680,11520,0,3840,7680,11520,0,3840,7680,11520,0,3840,7680,11520...].| kit/Kit.cpp:1663 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.190392 [ lok_handler ] DBG paintTile (combined) at (0, 0), (15360, 7680) ver: 21 rendered in 19.637 ms (26.699 MP/s).| kit/Kit.cpp:729 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.190887 [ lok_handler ] DBG PNG cache with hash 9712167148528605515 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.202662 [ lok_handler ] DBG PNG cache with hash 5375204921831389920 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.212194 [ lok_handler ] DBG PNG cache with hash 8838533397317759422 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.220192 [ lok_handler ] DBG PNG cache with hash 10692850087684826188 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.226422 [ lok_handler ] DBG PNG cache with hash 15330085162921022575 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.235903 [ lok_handler ] DBG PNG cache with hash 1906680050116964276 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.246365 [ lok_handler ] DBG PNG cache with hash 11809193835048112672 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.253729 [ lok_handler ] DBG PNG cache with hash 2170911108350901704 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.260345 [ docbrk_ws_12869 ] DBG Handling tile combined: tilecombine: part=0 width=256 height=256 tileposx=0,3840,7680,11520,0,3840,7680,11520 tileposy=0,0,0,0,3840,3840,3840,3840 imgsize=26466,10021,919,1324,15599,17295,11018,896 tilewidth=3840 tileheight=3840 ver=21 renderid=12869/0| wsd/DocumentBroker.cpp:847 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.260588 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,0.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,0.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.260610 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=0 tilewidth=3840 tileheight=3840 ver=21 imgsize=26466| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.260803 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 92 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.260934 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,0.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,0.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.260956 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=0 tilewidth=3840 tileheight=3840 ver=21 imgsize=10021| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261028 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 92 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261112 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,0.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,0.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261132 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=0 tilewidth=3840 tileheight=3840 ver=21 imgsize=919| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261160 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 93 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261231 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,0.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,0.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261250 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=0 tilewidth=3840 tileheight=3840 ver=21 imgsize=1324| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261276 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 93 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261355 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,3840.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,3840.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261375 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=3840 tilewidth=3840 tileheight=3840 ver=21 imgsize=15599| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261535 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 93 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261645 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,3840.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,3840.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261668 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=3840 tilewidth=3840 tileheight=3840 ver=21 imgsize=17295| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261769 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 93 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261851 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,3840.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,3840.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261871 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=3840 tilewidth=3840 tileheight=3840 ver=21 imgsize=11018| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.261959 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 93 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.262033 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,3840.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,3840.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.262054 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=3840 tilewidth=3840 tileheight=3840 ver=21 imgsize=896| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.262080 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 93 ms. Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.288255 [ lok_handler ] DBG paintTile (combined) at (0, 7680), (15360, 7680) ver: 21 rendered in 25.165 ms (20.834 MP/s).| kit/Kit.cpp:729 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.288813 [ lok_handler ] DBG PNG cache with hash 2646321053188888293 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.295717 [ lok_handler ] DBG PNG cache with hash 3757904219815825003 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.305291 [ lok_handler ] DBG PNG cache with hash 10909034931695436007 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.313637 [ lok_handler ] DBG PNG cache with hash 2170911108350901704 hit.| kit/Kit.cpp:347 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.314130 [ lok_handler ] DBG PNG cache with hash 14394097024650258994 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.320337 [ lok_handler ] DBG PNG cache with hash 5107058110142708513 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.327945 [ lok_handler ] DBG PNG cache with hash 15795988371708573852 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.336448 [ lok_handler ] DBG PNG cache with hash 2170911108350901704 hit.| kit/Kit.cpp:347 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.336914 [ docbrk_ws_12869 ] DBG Handling tile combined: tilecombine: part=0 width=256 height=256 tileposx=0,3840,7680,11520,0,3840,7680,11520 tileposy=7680,7680,7680,7680,11520,11520,11520,11520 imgsize=2710,23372,15890,896,4399,19888,9919,896 tilewidth=3840 tileheight=3840 ver=21 renderid=12869/1| wsd/DocumentBroker.cpp:847 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337115 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,7680.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,7680.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337144 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=7680 tilewidth=3840 tileheight=3840 ver=21 imgsize=2710| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337218 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 168 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337324 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,7680.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,7680.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337346 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=7680 tilewidth=3840 tileheight=3840 ver=21 imgsize=23372| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337504 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 169 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337588 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,7680.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,7680.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337608 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=7680 tilewidth=3840 tileheight=3840 ver=21 imgsize=15890| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337715 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 169 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337791 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,7680.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,7680.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337811 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=7680 tilewidth=3840 tileheight=3840 ver=21 imgsize=896| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337837 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 169 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337909 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,11520.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,11520.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337929 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=11520 tilewidth=3840 tileheight=3840 ver=21 imgsize=4399| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.337973 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 169 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338056 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,11520.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,11520.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338075 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=11520 tilewidth=3840 tileheight=3840 ver=21 imgsize=19888| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338212 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 169 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338292 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,11520.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,11520.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338312 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=11520 tilewidth=3840 tileheight=3840 ver=21 imgsize=9919| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338386 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 169 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338456 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,11520.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,11520.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338476 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=11520 tilewidth=3840 tileheight=3840 ver=21 imgsize=896| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.338501 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 169 ms. Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.345535 [ lok_handler ] DBG paintTile (combined) at (0, 15360), (15360, 3840) ver: 21 rendered in 8.538 ms (30.7032 MP/s).| kit/Kit.cpp:729 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.346031 [ lok_handler ] DBG PNG cache with hash 10505744066348076843 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.352227 [ lok_handler ] DBG PNG cache with hash 16900252638374234549 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.360388 [ lok_handler ] DBG PNG cache with hash 6229477877247138204 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: kit-12869-12881 10:29:06.369404 [ lok_handler ] DBG PNG cache with hash 15724308129877544220 missed.| kit/Kit.cpp:365 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.374597 [ docbrk_ws_12869 ] DBG Handling tile combined: tilecombine: part=0 width=256 height=256 tileposx=0,3840,7680,11520 tileposy=15360,15360,15360,15360 imgsize=7320,5331,4046,1800 tilewidth=3840 tileheight=3840 ver=21 renderid=12869/2| wsd/DocumentBroker.cpp:847 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.374797 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,15360.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,15360.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.374822 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=15360 tilewidth=3840 tileheight=3840 ver=21 imgsize=7320| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.374886 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 206 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.374967 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,15360.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,15360.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.374989 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=15360 tilewidth=3840 tileheight=3840 ver=21 imgsize=5331| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.375037 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 206 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.375110 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,15360.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,15360.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.375131 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=15360 tilewidth=3840 tileheight=3840 ver=21 imgsize=4046| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.375173 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 206 ms. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.375245 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,15360.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,15360.3840x3840.png OK. Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.375265 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=15360 tilewidth=3840 tileheight=3840 ver=21 imgsize=1800| wsd/TileCache.cpp:175 Feb 9 11:29:06 lohengrin snap[12798]: wsd-12857-12874 10:29:06.375297 [ docbrk_ws_12869 ] DBG STATISTICS: tile 21 internal roundtrip 206 ms. Feb 9 11:29:08 lohengrin snap[12798]: kit-12869-12869 10:29:08.818935 [ loolkit ] DBG child_ws_12869: recv [child-0001 clientzoom tilepixelwidth=256 tilepixelheight=256 tiletwipwidth=3840 tiletwipheight=3840].| kit/Kit.cpp:1663 Feb 9 11:29:08 lohengrin snap[12798]: kit-12869-12869 10:29:08.819017 [ loolkit ] DBG child_ws_12869: recv [child-0001 mouse type=move x=60 y=7410 count=1 buttons=0 modifier=0].| kit/Kit.cpp:1663 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.149211 [ client_ws_0001 ] DBG Subscribing to tile (0,0,19200) which has no subscribers. Subscribing for ver: 22. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.149331 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,19200) which has no subscribers. Subscribing for ver: 23. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.149404 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,19200) which has no subscribers. Subscribing for ver: 24. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.149472 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,19200) which has no subscribers. Subscribing for ver: 25. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.149537 [ client_ws_0001 ] DBG Subscribing to tile (0,0,23040) which has no subscribers. Subscribing for ver: 26. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.149606 [ client_ws_0001 ] DBG Sending residual tilecombine: tilecombine part=0 width=256 height=256 tileposx=0,3840,7680,11520,0 tileposy=19200,19200,19200,19200,23040 imgsize=0,0,0,0,0 tilewidth=3840 tileheight=3840 ver=27| wsd/DocumentBroker.cpp:800 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12869 10:29:13.149796 [ loolkit ] DBG child_ws_12869: recv [tilecombine part=0 width=256 height=256 tileposx=0,3840,7680,11520,0 tileposy=19200,19200,19200,19200,23040 imgsize=0,0,...].| kit/Kit.cpp:1663 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.185756 [ lok_handler ] DBG paintTile (combined) at (0, 19200), (15360, 7680) ver: 27 rendered in 34.6 ms (15.1528 MP/s).| kit/Kit.cpp:729 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.186210 [ lok_handler ] DBG PNG cache with hash 11119669237860120804 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.191555 [ lok_handler ] DBG PNG cache with hash 11094071415730301235 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.197106 [ lok_handler ] DBG PNG cache with hash 1102989368401265608 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.201989 [ lok_handler ] DBG PNG cache with hash 2170911108350901704 hit.| kit/Kit.cpp:347 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.202353 [ lok_handler ] DBG PNG cache with hash 10686991279997590558 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.207534 [ docbrk_ws_12869 ] DBG Handling tile combined: tilecombine: part=0 width=256 height=256 tileposx=0,3840,7680,11520,0 tileposy=19200,19200,19200,19200,23040 imgsize=6457,14152,4840,896,7747 tilewidth=3840 tileheight=3840 ver=27 renderid=12869/3| wsd/DocumentBroker.cpp:847 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.207713 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,19200.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,19200.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.207736 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=19200 tilewidth=3840 tileheight=3840 ver=27 imgsize=6457| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.207803 [ docbrk_ws_12869 ] DBG STATISTICS: tile 27 internal roundtrip 58 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.207894 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,19200.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,19200.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.207915 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=19200 tilewidth=3840 tileheight=3840 ver=27 imgsize=14152| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208015 [ docbrk_ws_12869 ] DBG STATISTICS: tile 27 internal roundtrip 58 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208093 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,19200.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,19200.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208113 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=19200 tilewidth=3840 tileheight=3840 ver=27 imgsize=4840| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208158 [ docbrk_ws_12869 ] DBG STATISTICS: tile 27 internal roundtrip 58 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208230 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,19200.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,19200.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208250 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=19200 tilewidth=3840 tileheight=3840 ver=27 imgsize=896| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208275 [ docbrk_ws_12869 ] DBG STATISTICS: tile 27 internal roundtrip 58 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208347 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,23040.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,23040.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208366 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=23040 tilewidth=3840 tileheight=3840 ver=27 imgsize=7747| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.208428 [ docbrk_ws_12869 ] DBG STATISTICS: tile 27 internal roundtrip 58 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.896214 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,23040) which has no subscribers. Subscribing for ver: 28. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.896269 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,23040) which has no subscribers. Subscribing for ver: 29. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.896307 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,23040) which has no subscribers. Subscribing for ver: 30. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.896342 [ client_ws_0001 ] DBG Subscribing to tile (0,0,26880) which has no subscribers. Subscribing for ver: 31. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.896377 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,26880) which has no subscribers. Subscribing for ver: 32. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12878 10:29:13.896417 [ client_ws_0001 ] DBG Sending residual tilecombine: tilecombine part=0 width=256 height=256 tileposx=3840,7680,11520,0,3840 tileposy=23040,23040,23040,26880,26880 imgsize=0,0,0,0,0 tilewidth=3840 tileheight=3840 ver=33| wsd/DocumentBroker.cpp:800 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12869 10:29:13.896529 [ loolkit ] DBG child_ws_12869: recv [tilecombine part=0 width=256 height=256 tileposx=3840,7680,11520,0,3840 tileposy=23040,23040,23040,26880,26880 imgsize=0...].| kit/Kit.cpp:1663 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.917192 [ lok_handler ] DBG paintTile (combined) at (0, 23040), (15360, 7680) ver: 33 rendered in 19.566 ms (26.7959 MP/s).| kit/Kit.cpp:729 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.917996 [ lok_handler ] DBG PNG cache with hash 17569713208664305702 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.925859 [ lok_handler ] DBG PNG cache with hash 129086385362671159 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.933154 [ lok_handler ] DBG PNG cache with hash 2170911108350901704 hit.| kit/Kit.cpp:347 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.933603 [ lok_handler ] DBG PNG cache with hash 3152672712916257042 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: kit-12869-12881 10:29:13.938903 [ lok_handler ] DBG PNG cache with hash 12228791994959456585 missed.| kit/Kit.cpp:365 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945204 [ docbrk_ws_12869 ] DBG Handling tile combined: tilecombine: part=0 width=256 height=256 tileposx=3840,7680,11520,0,3840 tileposy=23040,23040,23040,26880,26880 imgsize=15413,10781,896,911,17437 tilewidth=3840 tileheight=3840 ver=33 renderid=12869/4| wsd/DocumentBroker.cpp:847 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945366 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,23040.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,23040.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945383 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=23040 tilewidth=3840 tileheight=3840 ver=33 imgsize=15413| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945458 [ docbrk_ws_12869 ] DBG STATISTICS: tile 33 internal roundtrip 49 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945539 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,23040.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,23040.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945554 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=23040 tilewidth=3840 tileheight=3840 ver=33 imgsize=10781| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945607 [ docbrk_ws_12869 ] DBG STATISTICS: tile 33 internal roundtrip 49 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945773 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,23040.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,23040.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945789 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=23040 tilewidth=3840 tileheight=3840 ver=33 imgsize=896| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945809 [ docbrk_ws_12869 ] DBG STATISTICS: tile 33 internal roundtrip 49 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945869 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,26880.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,26880.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945882 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=26880 tilewidth=3840 tileheight=3840 ver=33 imgsize=911| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945901 [ docbrk_ws_12869 ] DBG STATISTICS: tile 33 internal roundtrip 49 ms. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945967 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,26880.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,26880.3840x3840.png OK. Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.945981 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=26880 tilewidth=3840 tileheight=3840 ver=33 imgsize=17437| wsd/TileCache.cpp:175 Feb 9 11:29:13 lohengrin snap[12798]: wsd-12857-12874 10:29:13.946056 [ docbrk_ws_12869 ] DBG STATISTICS: tile 33 internal roundtrip 49 ms. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12878 10:29:14.643472 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,26880) which has no subscribers. Subscribing for ver: 34. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12878 10:29:14.643525 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,26880) which has no subscribers. Subscribing for ver: 35. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12878 10:29:14.643560 [ client_ws_0001 ] DBG Subscribing to tile (0,0,30720) which has no subscribers. Subscribing for ver: 36. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12878 10:29:14.643595 [ client_ws_0001 ] DBG Subscribing to tile (0,3840,30720) which has no subscribers. Subscribing for ver: 37. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12878 10:29:14.643637 [ client_ws_0001 ] DBG Subscribing to tile (0,7680,30720) which has no subscribers. Subscribing for ver: 38. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12878 10:29:14.643675 [ client_ws_0001 ] DBG Sending residual tilecombine: tilecombine part=0 width=256 height=256 tileposx=7680,11520,0,3840,7680 tileposy=26880,26880,30720,30720,30720 imgsize=0,0,0,0,0 tilewidth=3840 tileheight=3840 ver=39| wsd/DocumentBroker.cpp:800 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12869 10:29:14.643776 [ loolkit ] DBG child_ws_12869: recv [tilecombine part=0 width=256 height=256 tileposx=7680,11520,0,3840,7680 tileposy=26880,26880,30720,30720,30720 imgsize=0...].| kit/Kit.cpp:1663 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.649898 [ lok_handler ] DBG paintTile (combined) at (0, 26880), (15360, 7680) ver: 39 rendered in 5.706 ms (91.8836 MP/s).| kit/Kit.cpp:729 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.650274 [ lok_handler ] DBG PNG cache with hash 15658114225871157833 missed.| kit/Kit.cpp:365 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.656003 [ lok_handler ] DBG PNG cache with hash 2170911108350901704 hit.| kit/Kit.cpp:347 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.656602 [ lok_handler ] DBG PNG cache with hash 13039921347291818375 missed.| kit/Kit.cpp:365 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.663555 [ lok_handler ] DBG PNG cache with hash 12534685607669096278 missed.| kit/Kit.cpp:365 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.668295 [ lok_handler ] DBG cache 29 items total size 267925 current hits 34, total hit rate 14.7059% at balance start| kit/Kit.cpp:310 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.668332 [ lok_handler ] DBG cache 28 items total size 257144 after balance| kit/Kit.cpp:332 Feb 9 11:29:14 lohengrin snap[12798]: kit-12869-12881 10:29:14.668624 [ lok_handler ] DBG PNG cache with hash 16123289684237073737 missed.| kit/Kit.cpp:365 Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.673857 [ docbrk_ws_12869 ] DBG Handling tile combined: tilecombine: part=0 width=256 height=256 tileposx=7680,11520,0,3840,7680 tileposy=26880,26880,30720,30720,30720 imgsize=3477,896,1838,6659,2111 tilewidth=3840 tileheight=3840 ver=39 renderid=12869/5| wsd/DocumentBroker.cpp:847 Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674072 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,26880.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,26880.3840x3840.png OK. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674095 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=26880 tilewidth=3840 tileheight=3840 ver=39 imgsize=3477| wsd/TileCache.cpp:175 Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674150 [ docbrk_ws_12869 ] DBG STATISTICS: tile 39 internal roundtrip 30 ms. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674229 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,26880.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,26880.3840x3840.png OK. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674248 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=26880 tilewidth=3840 tileheight=3840 ver=39 imgsize=896| wsd/TileCache.cpp:175 Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674278 [ docbrk_ws_12869 ] DBG STATISTICS: tile 39 internal roundtrip 30 ms. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674346 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,30720.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.0,30720.3840x3840.png OK. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674366 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=0 tileposy=30720 tilewidth=3840 tileheight=3840 ver=39 imgsize=1838| wsd/TileCache.cpp:175 Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674401 [ docbrk_ws_12869 ] DBG STATISTICS: tile 39 internal roundtrip 30 ms. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674473 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,30720.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.3840,30720.3840x3840.png OK. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674492 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=3840 tileposy=30720 tilewidth=3840 tileheight=3840 ver=39 imgsize=6659| wsd/TileCache.cpp:175 Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674561 [ docbrk_ws_12869 ] DBG STATISTICS: tile 39 internal roundtrip 30 ms. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674647 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,30720.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.7680,30720.3840x3840.png OK. Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674666 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=7680 tileposy=30720 tilewidth=3840 tileheight=3840 ver=39 imgsize=2111| wsd/TileCache.cpp:175 Feb 9 11:29:14 lohengrin snap[12798]: wsd-12857-12874 10:29:14.674699 [ docbrk_ws_12869 ] DBG STATISTICS: tile 39 internal roundtrip 31 ms. Feb 9 11:29:15 lohengrin snap[12798]: wsd-12857-12878 10:29:15.391557 [ client_ws_0001 ] DBG Subscribing to tile (0,11520,30720) which has no subscribers. Subscribing for ver: 40. Feb 9 11:29:15 lohengrin snap[12798]: wsd-12857-12878 10:29:15.391610 [ client_ws_0001 ] DBG Sending render request for tile (0,11520,30720).| wsd/DocumentBroker.cpp:740 Feb 9 11:29:15 lohengrin snap[12798]: kit-12869-12869 10:29:15.391744 [ loolkit ] DBG child_ws_12869: recv [tile part=0 width=256 height=256 tileposx=11520 tileposy=30720 tilewidth=3840 tileheight=3840 ver=40].| kit/Kit.cpp:1663 Feb 9 11:29:15 lohengrin snap[12798]: kit-12869-12881 10:29:15.393131 [ lok_handler ] DBG PNG cache with hash 14922582126874601880 missed.| kit/Kit.cpp:365 Feb 9 11:29:15 lohengrin snap[12798]: wsd-12857-12874 10:29:15.397666 [ docbrk_ws_12869 ] DBG Handling tile: tile: part=0 width=256 height=256 tileposx=11520 tileposy=30720 tilewidth=3840 tileheight=3840 ver=40 renderid=12869/6| wsd/DocumentBroker.cpp:820 Feb 9 11:29:15 lohengrin snap[12798]: wsd-12857-12874 10:29:15.397803 [ docbrk_ws_12869 ] DBG Renaming /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,30720.3840x3840.png.temp to /var/snap/loolwsd/common/cache/5/1/3/1c53ab8305e70bd41237d24b701fb708ae811/0_256x256.11520,30720.3840x3840.png OK. Feb 9 11:29:15 lohengrin snap[12798]: wsd-12857-12874 10:29:15.397820 [ docbrk_ws_12869 ] DBG Sending tile message to 1 subscribers: tile: part=0 width=256 height=256 tileposx=11520 tileposy=30720 tilewidth=3840 tileheight=3840 ver=40| wsd/TileCache.cpp:175 Feb 9 11:29:15 lohengrin snap[12798]: wsd-12857-12874 10:29:15.397850 [ docbrk_ws_12869 ] DBG STATISTICS: tile 40 internal roundtrip 6 ms. From roberto.escandon at canonical.com Thu Feb 9 10:36:45 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 9 Feb 2017 11:36:45 +0100 Subject: IPC between snaps In-Reply-To: References: <883133f4-7678-f006-de4f-3acd48159ed7@canonical.com> Message-ID: Thanks Löic. I'll take a look On 09/02/17 11:18, Loïc Minier wrote: > Hi, > > Yes, this is typically how you allow a snap to talk to snapd or docker > daemon or lxd. You need a new interface to grant access to this socket > path. If you'd like some examples or look at existing ones, grep for socket > under github.com/snapcore/snapd/interfaces. > > Cheers, > - Loïc > > On Thu, Feb 9, 2017 at 10:27 AM, Roberto Mier Escandón  < > roberto.escandon at canonical.com> wrote: > >> Hi, >> >> Is there any way to communicate processes in different snaps using >> pipes?. How can it be done in this or other way? >> >> >> Cheers. >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/snapcraft >> > > > > > From roberto.escandon at canonical.com Thu Feb 9 10:38:58 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 9 Feb 2017 11:38:58 +0100 Subject: dlopen cannot load shared library In-Reply-To: References: <07b6697f-3488-dd56-11bc-39712987278a@canonical.com> Message-ID: <7003aa49-7e88-5a58-7ec5-18a92b4ae45a@canonical.com> Thanks, The problem was, indeed, a fail in the path to a library. Your answers were key to solve it. The dlopen() now works ok. On 03/02/17 13:59, Mark Shuttleworth wrote: > On 03/02/17 12:41, Loïc Minier wrote: >> In classic mode, you see libraries from your classic Ubuntu system >> including X11; in devmode/confined mode, you only see system libraries >> from the core snap which doesn't contain X11. > > One more point. If you try this command you will be running a shell > "inside the snap", in other words, you will be experiencing the > filesystem exactly as your snap sees it. > > $ snap run --shell > > Now you are living inside the container that is setup just for that > snap. It's using the same sorts of mechanisms as LXD and Docker to keep > processes apart, but it is also setup in such a way that files can be > shared across snaps. You can see the environment variables that snapd > has setup so snap processes can find out where they can write data etc: > > $ set | grep SNAP > SNAP=/snap/etcd/x5 > SNAP_ARCH=amd64 > SNAP_COMMON=/var/snap/etcd/common > SNAP_DATA=/var/snap/etcd/x5 > SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl: > SNAP_NAME=etcd > SNAP_REEXEC= > SNAP_REVISION=x5 > SNAP_USER_COMMON=/home/mark/snap/etcd/common > SNAP_USER_DATA=/home/mark/snap/etcd/x5 > SNAP_VERSION=2.3.7 > > And if you start using 'ls' to poke around the filesystem, you quickly > see that you are in your own special world: > > $ ls / > ls: cannot open directory '/': Permission denied > > $ sudo ls / > bash: /usr/bin/sudo: Permission denied > > $ ls -l /lib/ > total 74 > drwxr-xr-x 2 root root 52 Jan 13 20:41 apparmor > drwxr-xr-x 2 root root 57 Jan 13 20:41 bridge-utils > drwxr-xr-x 2 root root 40 Jan 13 20:41 cgmanager > drwxr-xr-x 3 root root 89 Jan 13 20:41 crda > drwxr-xr-x 2 root root 3 Jan 13 20:40 firmware > drwxr-xr-x 2 root root 1032 Jan 13 20:41 i386-linux-gnu > drwxr-xr-x 2 root root 59 Jan 13 20:41 ifupdown > drwxr-xr-x 2 root root 51 Jan 13 20:41 init > -rwxr-xr-x 1 root root 70952 Sep 22 18:34 > klibc-k3La8MUnuzHQ0_kG8hokcGAC0PA.so > lrwxrwxrwx 1 root root 25 Nov 16 22:51 ld-linux.so.2 -> > i386-linux-gnu/ld-2.23.so > drwxr-xr-x 3 root root 61 Jan 13 20:41 lsb > drwxr-xr-x 2 root root 35 Jan 13 20:41 modprobe.d > drwxr-xr-x 6 root root 4096 Jan 26 10:15 modules > drwxr-xr-x 2 root root 31 Jan 13 20:41 netplan > drwxr-xr-x 2 root root 35 Jan 13 20:41 resolvconf > drwxr-xr-x 8 root root 1057 Jan 13 20:41 systemd > drwxr-xr-x 15 root root 132 Jan 13 20:41 terminfo > drwxr-xr-x 4 root root 298 Jan 13 20:41 udev > drwxr-xr-x 3 root root 4281 Jan 13 20:41 x86_64-linux-gnu > drwxr-xr-x 2 root root 2531 Jan 13 20:41 xtables > > So you see, this is a super-minimal "core" with just a few libraries. > > You can find your snap at $SNAP: > > $ echo $SNAP > /snap/foo/7 > $ ls -lR $SNAP > /snap/foo/x5: > ... > > Hope that's a useful introduction. It's a lot of fun once you realise > that you have TOTAL control over your snap, but everything else is very > structured for you. > > Mark > > > From thomas.voss at canonical.com Thu Feb 9 13:04:37 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Thu, 9 Feb 2017 14:04:37 +0100 Subject: chroot into a snap In-Reply-To: <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> Message-ID: On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón  wrote: > > Hey Thomas, > > You can find the snap at [1] > Atttached are traces for: > > Devmode: > - service.txt are the logs of the service > - syslog.txt and snappy-debug.security.txt are the logs to see apparmor > denials (warnings in this case). I cannot see more than ptrace ones. > > Classic: > - service.classic.txt > here i don't see any denial > > The only error shown is that the document has not been found. But the > url is the same in classic or devmode, so that's not the reason of the > problem. > Okay, so I don't see the chroot setup failing at all (according to your logs). Where is the document located in the local file system? If your snap works with classic confinement, it might live outside of the snap itself. > > [1] https://github.com/rmescandon/loolwsd-snap > > BR. > > On 09/02/17 10:32, Thomas Voß wrote: >> Hey Roberto, >> >> On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  >> wrote: >>> Hey engineers, >>> >>> I need some ideas to solve this: I'm trying to snap collaboraoffice >>> online but that's not being easy at all. FYI: this is a kind of Google >>> Drive stuff so that when you request in your browser certain document, >>> it is rendered and can be edit by many at the same time, etc.. >>> >>> Though I've been able to build from sources a snap package, that is only >>> working in classic confinement but not in devmode or strict. >>> >>> The reason is because the way it works: >>> - There is a server listening for documents requests >>> - for every new document requested an instance of a document manager is >>> started in a chrooted environment >>> - If requested n documents there will be n different chroot jails based >>> in same certain template >>> - document manager has certain linux capabilities to create the needed >>> roots (cap_fowner,cap_mknod,cap_sys_chroot...) >>> - the way of packaging the snap, currently, is by setting those caps and >>> call mksquashfs skipping -no-attrs option set by default by snapcraft >>> >> >> Could you please elaborate what is not working and how it fails? >> System logs, apparmor denials >> and seccomp messages would be needed here for further debugging. >> >> What is going wrong in the devmode case? >> >> Thanks, >> >> Thomas >> >>> I thought about a solution of having server in a snap and document >>> manager in another, but still there would be needed calling chroot for >>> every new document... ideas? >>> >>> BR. >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From roberto.escandon at canonical.com Thu Feb 9 13:26:15 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 9 Feb 2017 14:26:15 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> Message-ID: <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> awsome Thomas!. You got it!. Having the doc in any snap path can be rendered. So, that answers the point of chroot working ok, but now there is another problem: How can I access documents in other snaps? Can content interface solve this? (I'll try) On 09/02/17 14:04, Thomas Voß wrote: > On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón  > wrote: >> >> Hey Thomas, >> >> You can find the snap at [1] >> Atttached are traces for: >> >> Devmode: >> - service.txt are the logs of the service >> - syslog.txt and snappy-debug.security.txt are the logs to see apparmor >> denials (warnings in this case). I cannot see more than ptrace ones. >> >> Classic: >> - service.classic.txt >> here i don't see any denial >> >> The only error shown is that the document has not been found. But the >> url is the same in classic or devmode, so that's not the reason of the >> problem. >> > > Okay, so I don't see the chroot setup failing at all (according to > your logs). Where is the document located in the local file system? > If your snap works with classic confinement, it might live outside of > the snap itself. > >> >> [1] https://github.com/rmescandon/loolwsd-snap >> >> BR. >> >> On 09/02/17 10:32, Thomas Voß wrote: >>> Hey Roberto, >>> >>> On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  >>> wrote: >>>> Hey engineers, >>>> >>>> I need some ideas to solve this: I'm trying to snap collaboraoffice >>>> online but that's not being easy at all. FYI: this is a kind of Google >>>> Drive stuff so that when you request in your browser certain document, >>>> it is rendered and can be edit by many at the same time, etc.. >>>> >>>> Though I've been able to build from sources a snap package, that is only >>>> working in classic confinement but not in devmode or strict. >>>> >>>> The reason is because the way it works: >>>> - There is a server listening for documents requests >>>> - for every new document requested an instance of a document manager is >>>> started in a chrooted environment >>>> - If requested n documents there will be n different chroot jails based >>>> in same certain template >>>> - document manager has certain linux capabilities to create the needed >>>> roots (cap_fowner,cap_mknod,cap_sys_chroot...) >>>> - the way of packaging the snap, currently, is by setting those caps and >>>> call mksquashfs skipping -no-attrs option set by default by snapcraft >>>> >>> >>> Could you please elaborate what is not working and how it fails? >>> System logs, apparmor denials >>> and seccomp messages would be needed here for further debugging. >>> >>> What is going wrong in the devmode case? >>> >>> Thanks, >>> >>> Thomas >>> >>>> I thought about a solution of having server in a snap and document >>>> manager in another, but still there would be needed calling chroot for >>>> every new document... ideas? >>>> >>>> BR. >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > From thomas.voss at canonical.com Thu Feb 9 13:33:01 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Thu, 9 Feb 2017 14:33:01 +0100 Subject: chroot into a snap In-Reply-To: <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> Message-ID: I think you want: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/home.go Why would you need to access documents in other snaps? On Thu, Feb 9, 2017 at 2:26 PM, Roberto Mier Escandón  wrote: > awsome Thomas!. You got it!. Having the doc in any snap path can be > rendered. > So, that answers the point of chroot working ok, but now there is > another problem: How can I access documents in other snaps? Can content > interface solve this? (I'll try) > > On 09/02/17 14:04, Thomas Voß wrote: >> On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón  >> wrote: >>> >>> Hey Thomas, >>> >>> You can find the snap at [1] >>> Atttached are traces for: >>> >>> Devmode: >>> - service.txt are the logs of the service >>> - syslog.txt and snappy-debug.security.txt are the logs to see apparmor >>> denials (warnings in this case). I cannot see more than ptrace ones. >>> >>> Classic: >>> - service.classic.txt >>> here i don't see any denial >>> >>> The only error shown is that the document has not been found. But the >>> url is the same in classic or devmode, so that's not the reason of the >>> problem. >>> >> >> Okay, so I don't see the chroot setup failing at all (according to >> your logs). Where is the document located in the local file system? >> If your snap works with classic confinement, it might live outside of >> the snap itself. >> >>> >>> [1] https://github.com/rmescandon/loolwsd-snap >>> >>> BR. >>> >>> On 09/02/17 10:32, Thomas Voß wrote: >>>> Hey Roberto, >>>> >>>> On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  >>>> wrote: >>>>> Hey engineers, >>>>> >>>>> I need some ideas to solve this: I'm trying to snap collaboraoffice >>>>> online but that's not being easy at all. FYI: this is a kind of Google >>>>> Drive stuff so that when you request in your browser certain document, >>>>> it is rendered and can be edit by many at the same time, etc.. >>>>> >>>>> Though I've been able to build from sources a snap package, that is only >>>>> working in classic confinement but not in devmode or strict. >>>>> >>>>> The reason is because the way it works: >>>>> - There is a server listening for documents requests >>>>> - for every new document requested an instance of a document manager is >>>>> started in a chrooted environment >>>>> - If requested n documents there will be n different chroot jails based >>>>> in same certain template >>>>> - document manager has certain linux capabilities to create the needed >>>>> roots (cap_fowner,cap_mknod,cap_sys_chroot...) >>>>> - the way of packaging the snap, currently, is by setting those caps and >>>>> call mksquashfs skipping -no-attrs option set by default by snapcraft >>>>> >>>> >>>> Could you please elaborate what is not working and how it fails? >>>> System logs, apparmor denials >>>> and seccomp messages would be needed here for further debugging. >>>> >>>> What is going wrong in the devmode case? >>>> >>>> Thanks, >>>> >>>> Thomas >>>> >>>>> I thought about a solution of having server in a snap and document >>>>> manager in another, but still there would be needed calling chroot for >>>>> every new document... ideas? >>>>> >>>>> BR. >>>>> >>>>> -- >>>>> Snapcraft mailing list >>>>> Snapcraft at lists.snapcraft.io >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >>>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >>> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From roberto.escandon at canonical.com Thu Feb 9 13:38:35 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 9 Feb 2017 14:38:35 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> Message-ID: <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> Because this will use nextcloud documents, and they are internal to nextcloud snap On 09/02/17 14:33, Thomas Voß wrote: > I think you want: > > https://github.com/snapcore/snapd/blob/master/interfaces/builtin/home.go > > Why would you need to access documents in other snaps? > > On Thu, Feb 9, 2017 at 2:26 PM, Roberto Mier Escandón  > wrote: >> awsome Thomas!. You got it!. Having the doc in any snap path can be >> rendered. >> So, that answers the point of chroot working ok, but now there is >> another problem: How can I access documents in other snaps? Can content >> interface solve this? (I'll try) >> >> On 09/02/17 14:04, Thomas Voß wrote: >>> On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón  >>> wrote: >>>> >>>> Hey Thomas, >>>> >>>> You can find the snap at [1] >>>> Atttached are traces for: >>>> >>>> Devmode: >>>> - service.txt are the logs of the service >>>> - syslog.txt and snappy-debug.security.txt are the logs to see apparmor >>>> denials (warnings in this case). I cannot see more than ptrace ones. >>>> >>>> Classic: >>>> - service.classic.txt >>>> here i don't see any denial >>>> >>>> The only error shown is that the document has not been found. But the >>>> url is the same in classic or devmode, so that's not the reason of the >>>> problem. >>>> >>> >>> Okay, so I don't see the chroot setup failing at all (according to >>> your logs). Where is the document located in the local file system? >>> If your snap works with classic confinement, it might live outside of >>> the snap itself. >>> >>>> >>>> [1] https://github.com/rmescandon/loolwsd-snap >>>> >>>> BR. >>>> >>>> On 09/02/17 10:32, Thomas Voß wrote: >>>>> Hey Roberto, >>>>> >>>>> On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  >>>>> wrote: >>>>>> Hey engineers, >>>>>> >>>>>> I need some ideas to solve this: I'm trying to snap collaboraoffice >>>>>> online but that's not being easy at all. FYI: this is a kind of Google >>>>>> Drive stuff so that when you request in your browser certain document, >>>>>> it is rendered and can be edit by many at the same time, etc.. >>>>>> >>>>>> Though I've been able to build from sources a snap package, that is only >>>>>> working in classic confinement but not in devmode or strict. >>>>>> >>>>>> The reason is because the way it works: >>>>>> - There is a server listening for documents requests >>>>>> - for every new document requested an instance of a document manager is >>>>>> started in a chrooted environment >>>>>> - If requested n documents there will be n different chroot jails based >>>>>> in same certain template >>>>>> - document manager has certain linux capabilities to create the needed >>>>>> roots (cap_fowner,cap_mknod,cap_sys_chroot...) >>>>>> - the way of packaging the snap, currently, is by setting those caps and >>>>>> call mksquashfs skipping -no-attrs option set by default by snapcraft >>>>>> >>>>> >>>>> Could you please elaborate what is not working and how it fails? >>>>> System logs, apparmor denials >>>>> and seccomp messages would be needed here for further debugging. >>>>> >>>>> What is going wrong in the devmode case? >>>>> >>>>> Thanks, >>>>> >>>>> Thomas >>>>> >>>>>> I thought about a solution of having server in a snap and document >>>>>> manager in another, but still there would be needed calling chroot for >>>>>> every new document... ideas? >>>>>> >>>>>> BR. >>>>>> >>>>>> -- >>>>>> Snapcraft mailing list >>>>>> Snapcraft at lists.snapcraft.io >>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >>>>> >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >>>> >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From thomas.voss at canonical.com Thu Feb 9 16:08:30 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Thu, 9 Feb 2017 17:08:30 +0100 Subject: chroot into a snap In-Reply-To: <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> Message-ID: On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  wrote: > Because this will use nextcloud documents, and they are internal to > nextcloud snap > In that case, content-sharing would help, yes. > On 09/02/17 14:33, Thomas Voß wrote: >> I think you want: >> >> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/home.go >> >> Why would you need to access documents in other snaps? >> >> On Thu, Feb 9, 2017 at 2:26 PM, Roberto Mier Escandón  >> wrote: >>> awsome Thomas!. You got it!. Having the doc in any snap path can be >>> rendered. >>> So, that answers the point of chroot working ok, but now there is >>> another problem: How can I access documents in other snaps? Can content >>> interface solve this? (I'll try) >>> >>> On 09/02/17 14:04, Thomas Voß wrote: >>>> On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón  >>>> wrote: >>>>> >>>>> Hey Thomas, >>>>> >>>>> You can find the snap at [1] >>>>> Atttached are traces for: >>>>> >>>>> Devmode: >>>>> - service.txt are the logs of the service >>>>> - syslog.txt and snappy-debug.security.txt are the logs to see apparmor >>>>> denials (warnings in this case). I cannot see more than ptrace ones. >>>>> >>>>> Classic: >>>>> - service.classic.txt >>>>> here i don't see any denial >>>>> >>>>> The only error shown is that the document has not been found. But the >>>>> url is the same in classic or devmode, so that's not the reason of the >>>>> problem. >>>>> >>>> >>>> Okay, so I don't see the chroot setup failing at all (according to >>>> your logs). Where is the document located in the local file system? >>>> If your snap works with classic confinement, it might live outside of >>>> the snap itself. >>>> >>>>> >>>>> [1] https://github.com/rmescandon/loolwsd-snap >>>>> >>>>> BR. >>>>> >>>>> On 09/02/17 10:32, Thomas Voß wrote: >>>>>> Hey Roberto, >>>>>> >>>>>> On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  >>>>>> wrote: >>>>>>> Hey engineers, >>>>>>> >>>>>>> I need some ideas to solve this: I'm trying to snap collaboraoffice >>>>>>> online but that's not being easy at all. FYI: this is a kind of Google >>>>>>> Drive stuff so that when you request in your browser certain document, >>>>>>> it is rendered and can be edit by many at the same time, etc.. >>>>>>> >>>>>>> Though I've been able to build from sources a snap package, that is only >>>>>>> working in classic confinement but not in devmode or strict. >>>>>>> >>>>>>> The reason is because the way it works: >>>>>>> - There is a server listening for documents requests >>>>>>> - for every new document requested an instance of a document manager is >>>>>>> started in a chrooted environment >>>>>>> - If requested n documents there will be n different chroot jails based >>>>>>> in same certain template >>>>>>> - document manager has certain linux capabilities to create the needed >>>>>>> roots (cap_fowner,cap_mknod,cap_sys_chroot...) >>>>>>> - the way of packaging the snap, currently, is by setting those caps and >>>>>>> call mksquashfs skipping -no-attrs option set by default by snapcraft >>>>>>> >>>>>> >>>>>> Could you please elaborate what is not working and how it fails? >>>>>> System logs, apparmor denials >>>>>> and seccomp messages would be needed here for further debugging. >>>>>> >>>>>> What is going wrong in the devmode case? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Thomas >>>>>> >>>>>>> I thought about a solution of having server in a snap and document >>>>>>> manager in another, but still there would be needed calling chroot for >>>>>>> every new document... ideas? >>>>>>> >>>>>>> BR. >>>>>>> >>>>>>> -- >>>>>>> Snapcraft mailing list >>>>>>> Snapcraft at lists.snapcraft.io >>>>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >>>>>> >>>>> >>>>> -- >>>>> Snapcraft mailing list >>>>> Snapcraft at lists.snapcraft.io >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >>>>> >>>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From kyle.fazzari at canonical.com Thu Feb 9 16:12:14 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 9 Feb 2017 08:12:14 -0800 Subject: One snap to connect them all (or: the plugin story) In-Reply-To: References: Message-ID: <97130291-0945-88d5-284d-f65b68118a27@canonical.com> On 02/09/2017 01:04 AM, Didier Roche wrote: > Ok, sorry for the catchy email title but couldn't resist :) > > So, I'm in the situation where one snap would need to get configuration > and access to some files from other snaps. It's really similar to our > plugin story: even if in that case, we are talking about optional > configuration and files from one or multiple snaps shared with a single > one collecting them all. > > I can see 2 options in the snapd philosophy: > > - Content sharing. Sounds like it matches exactly the purpose of it. > However, even disregarding the manual connection that will be needed, we > are stuck on the fact that it's limited to one connection for a given > slot. If I want to share configuration and files from 3 snaps to the > master one, I can't do 3 times: > $ snap connect snap1:config my-master-snap:config > $ snap connect snap2:config my-master-snap:config > $ snap connect snap2:config my-master-snap:config > > One way would be to create different slot names: > $ snap connect snap1:config my-master-snap:config1 > $ snap connect snap2:config my-master-snap:config2 > $ snap connect snap2:config my-master-snap:config3 > > But this doesn't help on the ease of use (the notice is then for people > "find the first available slot"… Not really user-friendly) nor in the > scalibity (fixed number of slots…) Does https://bugs.launchpad.net/snapd/+bug/1655125 cover this case? -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From kyle.nitzsche at canonical.com Thu Feb 9 16:40:03 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Thu, 9 Feb 2017 11:40:03 -0500 Subject: launchpad snap recipe fails with classic confinement Message-ID: <95199d1d-02f5-9356-9e8d-92b0a39f08be@canonical.com> Is building a snap with *classic* confinement from a recipe supported on lp? I created a snap recipe for my imported git branch and tried to build, and the builds fail with: Preparing to pull env classic confinement requires the core snap to be installed. Install it by running `snap install core`. Traceback (most recent call last): File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 199, in main builder.pull() File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 136, in pull env=env) File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 92, in run_build_command self.chroot(["/bin/sh", "-c", command], echo=echo) File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 66, in chroot "/usr/bin/sudo", "/usr/sbin/chroot", self.chroot_path] + args) File "/usr/lib/python2.7/subprocess.py", line 541, in check_call raise CalledProcessError(retcode, cmd) CalledProcessError: Command '['/usr/bin/sudo', '/usr/sbin/chroot', '/home/buildd/build-SNAPBUILD-21071/chroot-autobuild', 'linux32', '/bin/sh', '-c', 'cd /build/make-system-user && env LANG=C.UTF-8 https_proxy=http://snap-proxy.launchpad.net:3128 http_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 snapcraft pull']' returned non-zero exit status 1 cheers, kyleN From paolo.pisati at canonical.com Thu Feb 9 16:50:38 2017 From: paolo.pisati at canonical.com (Paolo Pisati) Date: Thu, 9 Feb 2017 17:50:38 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: Message-ID: <20170209165038.GA5655@harukaze> On Thu, Feb 09, 2017 at 06:13:15AM +0000, Sunny Bhayani wrote: > > > the work is going on here: > > > > https://github.com/snapcore/snapcraft/pull/1115 > > Is there a way, that we can come to know about an official fix, apart from the > above link that you mentioned. If you don't want to wait for a release, you can clone the snapcraft repository[1] and apply the above fix locally: git clone https://github.com/snapcore/snapcraft.git > Also, how did the build for the Dragonboard410C succeed for the pre-built > Ubuntu Core OS image ? > > Since that is working properly, /lib/modules have the kernel modules and > /lib/firmware has the firmware binaries. > > Also, the wifi interface (wlan0) is working. > > Sorry, but I was just curious to know this. The kernel snaps for the dragonboard (and the raspberry and pc), are generated from the deb packages in our archive, using this script: https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial Starting from the snapdragon branch, the snapcraft.yaml there invokes the Makefile in the master branch. This was done to use the x86 signed kernels (required for trusted boot), and the same mechanism was reused for arm. But for development, snapcratf and the kernel plugin are the way to go. 1: https://github.com/snapcore/snapcraft -- bye, p. From sergio.schvezov at canonical.com Thu Feb 9 17:09:49 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 09 Feb 2017 14:09:49 -0300 Subject: launchpad snap recipe fails with classic confinement In-Reply-To: <95199d1d-02f5-9356-9e8d-92b0a39f08be@canonical.com> Message-ID: El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche escribió: > Is building a snap with *classic* confinement from a recipe > supported on lp? > > I created a snap recipe for my imported git branch and tried to build, > and the builds fail with: Even though LP will be adding support for this, snapcraft 2.27 adds the required support for a generic ci solution. This will be released early next week. -- Enviado con Dekko desde mi dispositivo Ubuntu From max.brustkern at canonical.com Thu Feb 9 17:19:36 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Thu, 9 Feb 2017 12:19:36 -0500 Subject: Spread linode backend Message-ID: I'm attempting to use the spread linode backend with this system stanza, as described in the documentation: backends: linode: key: $(HOST:echo $LINODE_API_KEY) systems: - 'ubuntu-16.04' I'm getting this error: 2017/02/09 11:00:18 Error packing project content for delivery: cannot pack project tree: ----- tar: snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/expected.classic.ubuntu-core.linode.i386.json: file name is too long (max 99); not dumped tar: snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/expected.classic.ubuntu-core.qemu.amd64.json: file name is too long (max 99); not dumped tar: snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/expected.classic.ubuntu-core.linode.amd64.json: file name is too long (max 99); not dumped tar: Exiting with failure status due to previous errors ----- 2017/02/09 11:00:19 Successful tasks: 0 2017/02/09 11:00:19 Aborted tasks: 9 error: cannot pack project content for delivery Any suggestions? Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fazzari at canonical.com Thu Feb 9 18:45:31 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 9 Feb 2017 10:45:31 -0800 Subject: Package too old for cleanbuild In-Reply-To: References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: On 02/05/2017 11:46 PM, Michi Henning wrote: >> Would it make sense to extend the snapcraft yaml to let the developer >> specify where build-packages and stage-packages should be taken from? >> >> It would be nice to be able to run a "snapcraft cleanbuild" from zesty >> while effectively using all the packages from xenial+overlay... :-) > > That certainly would be nice, yes. It would also be awesome to be able to point apt inside the container at my apt-cacher-ng cache. As is, every failed attempt to do a cleanbuild downloads ~150 MB and, on a 3 Mbit link, takes 10-15 minutes. For development and debugging, we really need something like this. As is, it’s unbelievably painful. While I don't disagree with the suggestions here, if I may suggest a workaround: If you find yourself using cleanbuild a lot (it makes a new ephemeral container, builds, then destroys the container), you might find some workflow improvements by simply developing the snap in a container. You can even bind-mount the source from the host, if you want. This is the workflow I use personally. It allows for one to fully customize the apt sources while also utilizing Snapcraft's built-in stage package cache*, and it doesn't clutter the development environment on the host. * In snapcraft 2.27, coming early next week -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From joseph.wakeling at webdrake.net Thu Feb 9 19:13:03 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 9 Feb 2017 20:13:03 +0100 Subject: launchpad snap recipe fails with classic confinement In-Reply-To: References: Message-ID: <31713050-4664-d29a-097a-a3f3097ef88d@webdrake.net> On 09/02/17 18:09, Sergio Schvezov wrote: > El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche > escribió: >> Is building a snap with *classic* confinement from a recipe supported on lp? >> >> I created a snap recipe for my imported git branch and tried to build, and the >> builds fail with: > > Even though LP will be adding support for this, snapcraft 2.27 adds the required > support for a generic ci solution. This will be released early next week. Oh awesome! That's great news to hear, looking forward to trying this out :-) From cjwatson at ubuntu.com Thu Feb 9 19:23:34 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Thu, 9 Feb 2017 19:23:34 +0000 Subject: launchpad snap recipe fails with classic confinement In-Reply-To: References: <95199d1d-02f5-9356-9e8d-92b0a39f08be@canonical.com> Message-ID: <20170209192334.GA5496@riva.ucam.org> On Thu, Feb 09, 2017 at 02:09:49PM -0300, Sergio Schvezov wrote: > El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche > escribió: > >Is building a snap with *classic* confinement from a recipe supported on > >lp? > > > >I created a snap recipe for my imported git branch and tried to build, and > >the builds fail with: > > Even though LP will be adding support for this, This is https://bugs.launchpad.net/launchpad-buildd/+bug/1650946. I've been snowed under with another urgent snappy-related project, but I'm planning to attack this tomorrow. > snapcraft 2.27 adds the required support for a generic ci solution. > This will be released early next week. Oh, in fact, that looks just about perfect for us. With that patch I think LP could just export SNAPCRAFT_SETUP_CORE=1 when building snaps, right? -- Colin Watson [cjwatson at ubuntu.com] From thomas.voss at canonical.com Thu Feb 9 19:26:43 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Thu, 9 Feb 2017 20:26:43 +0100 Subject: Spread linode backend In-Reply-To: References: Message-ID: Hey Max, as a quick test, would you mind trying to set TAR_OPTIONS='--format=posix' in the environment you run spread in? Thanks, Thomas On Thu, Feb 9, 2017 at 6:19 PM, Max Brustkern wrote: > I'm attempting to use the spread linode backend with this system stanza, as > described in the documentation: > backends: > linode: > key: $(HOST:echo $LINODE_API_KEY) > systems: > - 'ubuntu-16.04' > I'm getting this error: > 2017/02/09 11:00:18 Error packing project content for delivery: cannot pack > project tree: > ----- > tar: > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/expected.classic.ubuntu-core.linode.i386.json: > file name is too long (max 99); not dumped > tar: > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/expected.classic.ubuntu-core.qemu.amd64.json: > file name is too long (max 99); not dumped > tar: > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/expected.classic.ubuntu-core.linode.amd64.json: > file name is too long (max 99); not dumped > tar: Exiting with failure status due to previous errors > ----- > 2017/02/09 11:00:19 Successful tasks: 0 > 2017/02/09 11:00:19 Aborted tasks: 9 > error: cannot pack project content for delivery > > Any suggestions? > > Thanks, > Max > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From sergio.schvezov at canonical.com Thu Feb 9 19:43:33 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 09 Feb 2017 16:43:33 -0300 Subject: launchpad snap recipe fails with classic confinement In-Reply-To: <20170209192334.GA5496@riva.ucam.org> References: <95199d1d-02f5-9356-9e8d-92b0a39f08be@canonical.com> Message-ID: El jueves, 9 de febrero de 2017 16h'23:34 ART, Colin Watson escribió: > On Thu, Feb 09, 2017 at 02:09:49PM -0300, Sergio Schvezov wrote: >> El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche >> escribió: >> >Is building a snap with *classic* confinement from a recipe supported on >> >lp? >> > >> >I created a snap recipe for my imported git branch and tried >> to build, and >> >the builds fail with: >> >> Even though LP will be adding support for this, > > This is https://bugs.launchpad.net/launchpad-buildd/+bug/1650946. I've > been snowed under with another urgent snappy-related project, but I'm > planning to attack this tomorrow. > >> snapcraft 2.27 adds the required support for a generic ci solution. >> This will be released early next week. > > Oh, in fact, that looks just about perfect for us. With that patch I > think LP could just export SNAPCRAFT_SETUP_CORE=1 when building snaps, > right? Absolutely correct. If you enable this in staging I can give it some test runs. -- Enviado con Dekko desde mi dispositivo Ubuntu From alan.pope at canonical.com Thu Feb 9 20:02:05 2017 From: alan.pope at canonical.com (Alan Pope) Date: Thu, 9 Feb 2017 20:02:05 +0000 Subject: Package too old for cleanbuild In-Reply-To: References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: Hi Kyle (and Sergio!) On 9 February 2017 at 18:45, Kyle Fazzari wrote: > If you find yourself using cleanbuild a lot (it makes a new ephemeral > container, builds, then destroys the container), you might find some > workflow improvements by simply developing the snap in a container. You > can even bind-mount the source from the host, if you want. This is the > workflow I use personally. It allows for one to fully customize the apt > sources while also utilizing Snapcraft's built-in stage package cache*, > and it doesn't clutter the development environment on the host. > > * In snapcraft 2.27, coming early next week > You guys! I love reading these teases of what's coming in the next snapcraft. Your fast iterating and understanding of user requirements is making snapcraft a real pleasurable tool to use on a daily basis. Thank you! -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From kyle.fazzari at canonical.com Thu Feb 9 20:33:40 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 9 Feb 2017 12:33:40 -0800 Subject: Package too old for cleanbuild In-Reply-To: References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: On 02/09/2017 12:02 PM, Alan Pope wrote: > Hi Kyle (and Sergio!) > > On 9 February 2017 at 18:45, Kyle Fazzari wrote: >> If you find yourself using cleanbuild a lot (it makes a new ephemeral >> container, builds, then destroys the container), you might find some >> workflow improvements by simply developing the snap in a container. You >> can even bind-mount the source from the host, if you want. This is the >> workflow I use personally. It allows for one to fully customize the apt >> sources while also utilizing Snapcraft's built-in stage package cache*, >> and it doesn't clutter the development environment on the host. >> >> * In snapcraft 2.27, coming early next week >> > > You guys! I love reading these teases of what's coming in the next > snapcraft. Your fast iterating and understanding of user requirements > is making snapcraft a real pleasurable tool to use on a daily basis. > Thank you! Well thanks Alan! That's nice to hear :) . -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alberto.mardegan at canonical.com Thu Feb 9 21:37:44 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Fri, 10 Feb 2017 00:37:44 +0300 Subject: Semaphores and access to /dev/shm In-Reply-To: <1486596171.3367.49.camel@canonical.com> References: <594992a2-8e8d-805b-6ebb-459ff3f229e4@canonical.com> <1486596171.3367.49.camel@canonical.com> Message-ID: <5491d4c2-86b4-dbac-df39-62a987f53bed@canonical.com> On 09/02/2017 02:22, Jamie Strandboge wrote: > I confirmed this works fine under confinement (return code checking omitted for > clarity): > > char *name = "/dev/shm/sem.snap.foo.bar"; > open(name, O_CREAT | O_EXCL | O_RDRW, S_IRUSR | S_IWUSR); > sem_open("snap.foo.bar", 0); > Argh, it doesn't work :-( I modified Sergio's preloader (my branch is at [1]) but unfortunately the situation is more complicated than that: yes, the code you wrote above works, but it doesn't create a valid semaphore. Calling sem_post on such a semaphore generates a bus error, because sem_open() properly initializes the semaphore structure on the shm file only when O_CREAT is passed. I now understand why glic's implementation first creates a tmp file and then links it: it's a way to atomically initialise the semaphore data. The data gets first written into the tmp file, and the link happens when it's ready. I guess a solution to workaround the confinement would be to modify glibc's code to not just use a completely random filename mkstemp, but rather __mktemp("sem.snap.foo.bar.XXXXXX") Though, even if this gets accepted upstream, it will take time to appears in distros, and snaps using this feature will not work under confinement in those distros where this has not been released yet. Just wondering, how many kittens would die if we added a rule to allow every snap to create/read/write files named /dev/shm/...... (six chars)? I will try to embed a "fixed" version of glibc's sem_open into Sergio's preloader, but I wonder if we should try to find a solution even for those programs that don't use it. Ciao, Alberto [1]: https://github.com/mardy/snapcraft-preload/tree/sem_open -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From mark at ubuntu.com Thu Feb 9 22:05:02 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 9 Feb 2017 22:05:02 +0000 Subject: launchpad snap recipe fails with classic confinement In-Reply-To: References: <95199d1d-02f5-9356-9e8d-92b0a39f08be@canonical.com> Message-ID: <15b8c4f3-89c4-88a0-782d-4ef74b6c6def@ubuntu.com> On 09/02/17 19:43, Sergio Schvezov wrote: >> Oh, in fact, that looks just about perfect for us. With that patch I >> think LP could just export SNAPCRAFT_SETUP_CORE=1 when building snaps, >> right? > > Absolutely correct. If you enable this in staging I can give it some > test runs. > Somehow I think this will rock :) Mark From leo.arias at canonical.com Thu Feb 9 23:12:17 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 9 Feb 2017 17:12:17 -0600 Subject: Package too old for cleanbuild In-Reply-To: References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: Hello, We have a few cleanbuild bugs open: https://bugs.launchpad.net/snapcraft/+bugs?field.tag=cleanbuild Some of them are related to what you are asking, so I would appreciate if you go in there and add your comments with the ideal solution for your use case. If you don't find any bug that asks for what you need, please report a new one. Also note that some bugs are not confirmed. It's really useful for us when we are planning the work for the next sprint to look at the bugs that affect more than one person. So if you would like to see one bug fixed soon, mark it as affecting you, we'll hear it. Our planning meeting is tomorrow :) pura vida. From michael.hudson at canonical.com Fri Feb 10 00:44:32 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Fri, 10 Feb 2017 13:44:32 +1300 Subject: a little script: snapdiff Message-ID: Very much inspired by debdiff, I wrote a little script to compare two snaps. It looks like this: (master)mwhudson at aeglos:/opt/opensource/snaps/go$ snapdiff go-17-mwhudson_1.snap go-17-mwhudson_2.snap Only in second snap, go-17-mwhudson_2.snap: -rw-rw-r-- root/root 839 2017-02-03 11:14 test/fixedbugs/issue16331.go -rw-rw-r-- root/root 686 2017-02-03 11:14 test/fixedbugs/issue18410.go Differences in meta directory: diff -Nur meta1/snap.yaml meta2/snap.yaml --- meta1/snap.yaml 2017-01-11 11:49:30.000000000 +1300 +++ meta2/snap.yaml 2017-02-03 11:16:07.000000000 +1300 @@ -13,4 +13,4 @@ grade: devel name: go-17-mwhudson summary: Go programming language compiler, linker, stdlib -version: 1.7.4 +version: 1.7.5 It's implemented in perl (for no very good reason) and you can get it here: http://paste.ubuntu.com/23963902/ Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruddick at carbon.ai Fri Feb 10 04:47:25 2017 From: ruddick at carbon.ai (Ruddick Lawrence) Date: Thu, 9 Feb 2017 20:47:25 -0800 Subject: 'organize' affects 'stage-packages' Message-ID: I just discovered that a part with: organize: '*': opt/ stage-packages: - some-great-package moves the contents of the stage-packages into opt in addition to the output of the plugin. Is this the intended behavior, and if so, is there a way to move only the plugin output into a subfolder? Thanks, Ruddick -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Fri Feb 10 05:56:15 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Fri, 10 Feb 2017 13:56:15 +0800 Subject: 'organize' affects 'stage-packages' In-Reply-To: References: Message-ID: I think you may point a folder name there in the organize something like: organize: 'usr/share/ubuntu-html5-ui-toolkit/': www/ubuntu-html5-ui-toolkit Basically, the folder "usr/share/ubuntu-html5-ui-toolkit" will be moved to directory "www/ubuntu-html5-ui-toolkit" in the snap. Best regards, xiaoguo On Fri, Feb 10, 2017 at 12:47 PM, Ruddick Lawrence wrote: > I just discovered that a part with: > > organize: > '*': opt/ > stage-packages: > - some-great-package > > moves the contents of the stage-packages into opt in addition to the > output of the plugin. Is this the intended behavior, and if so, is there a > way to move only the plugin output into a subfolder? > > Thanks, > Ruddick > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Fri Feb 10 06:15:06 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 10 Feb 2017 07:15:06 +0100 Subject: IPC between snaps In-Reply-To: References: <883133f4-7678-f006-de4f-3acd48159ed7@canonical.com> Message-ID: <78e705be-b7ca-cf65-e8ff-c6502ccca37f@canonical.com> On 09.02.2017 11:36, Roberto Mier Escandón  wrote: > Thanks Löic. > I'll take a look > > On 09/02/17 11:18, Loïc Minier wrote: >> Hi, >> >> Yes, this is typically how you allow a snap to talk to snapd or docker >> daemon or lxd. You need a new interface to grant access to this socket >> path. If you'd like some examples or look at existing ones, grep for socket >> under github.com/snapcore/snapd/interfaces. >> >> Cheers, >> - Loïc >> >> On Thu, Feb 9, 2017 at 10:27 AM, Roberto Mier Escandón  < >> roberto.escandon at canonical.com> wrote: >> >>> Hi, >>> >>> Is there any way to communicate processes in different snaps using >>> pipes?. How can it be done in this or other way? If you want to use a unix domain socket you can easily share the socket file via the content interface between too snaps. Tony created two really good example snaps to showcase this: * https://github.com/tonyespy/unix-domain-server * https://github.com/tonyespy/unix-domain-client Server side uses the network-bind and client side uses just the network interface. Also have a look at https://github.com/snapcore/snapd/wiki/Content-Interface which explains the details a bit more. For named pipes I am not sure if both interfaces already allow the relevant things but its worth a try and otherwise we can easily add the necessary things. I hope that helps. regards, Simon From simon.fels at canonical.com Fri Feb 10 06:16:37 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 10 Feb 2017 07:16:37 +0100 Subject: a little script: snapdiff In-Reply-To: References: Message-ID: <699928dd-7aee-85db-90dd-6a94211c000c@canonical.com> On 10.02.2017 01:44, Michael Hudson-Doyle wrote: > Very much inspired by debdiff, I wrote a little script to compare two > snaps. It looks like this: > > (master)mwhudson at aeglos:/opt/opensource/snaps/go$ snapdiff > go-17-mwhudson_1.snap go-17-mwhudson_2.snap > Only in second snap, go-17-mwhudson_2.snap: > > -rw-rw-r-- root/root 839 2017-02-03 11:14 > test/fixedbugs/issue16331.go > -rw-rw-r-- root/root 686 2017-02-03 11:14 > test/fixedbugs/issue18410.go > > Differences in meta directory: > > diff -Nur meta1/snap.yaml meta2/snap.yaml > --- meta1/snap.yaml2017-01-11 11:49:30.000000000 +1300 > +++ meta2/snap.yaml2017-02-03 11:16:07.000000000 +1300 > @@ -13,4 +13,4 @@ > grade: devel > name: go-17-mwhudson > summary: Go programming language compiler, linker, stdlib > -version: 1.7.4 > +version: 1.7.5 > > It's implemented in perl (for no very good reason) and you can get it > here: http://paste.ubuntu.com/23963902/ That is really nice! Having a classic snap for it would be awesome :-) regards, Simon From simon.fels at canonical.com Fri Feb 10 06:21:09 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 10 Feb 2017 07:21:09 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> Message-ID: <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> On 09.02.2017 17:08, Thomas Voß wrote: > On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  > wrote: >> Because this will use nextcloud documents, and they are internal to >> nextcloud snap >> > > In that case, content-sharing would help, yes. Is that always the case? I thought we talked a while back about using the removable-media interface also as an option in the nextcloud snap to allow users placing their data on an external hardware driver or different partition. Not sure if this was ever implemented. regards, Simon From kyle.fazzari at canonical.com Fri Feb 10 07:05:33 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 9 Feb 2017 23:05:33 -0800 Subject: chroot into a snap In-Reply-To: <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> Message-ID: On Feb 9, 2017 10:21 PM, "Simon Fels" wrote: On 09.02.2017 17:08, Thomas Voß wrote: > On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  > wrote: >> Because this will use nextcloud documents, and they are internal to >> nextcloud snap >> > > In that case, content-sharing would help, yes. Is that always the case? I thought we talked a while back about using the removable-media interface also as an option in the nextcloud snap to allow users placing their data on an external hardware driver or different partition. Not sure if this was ever implemented. Simon is correct, this is indeed supported. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Fri Feb 10 07:12:37 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 10 Feb 2017 07:12:37 +0000 Subject: Is there any way to list all of the configure options for a snap application? In-Reply-To: <1486546004.11948.81.camel@ubuntu.com> References: <3EFB3E88-2588-4B66-BB6D-DF84CCB1D664@canonical.com> <1486546004.11948.81.camel@ubuntu.com> Message-ID: I think the intent is that a snap has a config schema which can be used for both validation and self-documentation of config items. Doing that tastefully is worth the wait :) Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From thomas.voss at canonical.com Fri Feb 10 07:16:44 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Fri, 10 Feb 2017 08:16:44 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> Message-ID: On Fri, Feb 10, 2017 at 8:05 AM, Kyle Fazzari wrote: > > On Feb 9, 2017 10:21 PM, "Simon Fels" wrote: > > On 09.02.2017 17:08, Thomas Voß wrote: >> On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  >> wrote: >>> Because this will use nextcloud documents, and they are internal to >>> nextcloud snap >>> >> >> In that case, content-sharing would help, yes. > > Is that always the case? I thought we talked a while back about using > the removable-media interface also as an option in the nextcloud snap to > allow users placing their data on an external hardware driver or > different partition. Not sure if this was ever implemented. > > > Simon is correct, this is indeed supported. > Ah, that's interesting. So Roberto's snap could make good use of removable-media, too. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From james.henstridge at canonical.com Fri Feb 10 07:34:33 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Fri, 10 Feb 2017 15:34:33 +0800 Subject: Problems using GLib's DBus implementation with dbus interface Message-ID: I was snapping up a D-Bus service I'm responsible for, and had it crash with a "Bad System Call" error, and the following in the dmesg output: [2054724.068967] audit: type=1326 audit(1486700103.228:2687): auid=1000 uid=1000 gid=1000 ses=2 pid=29311 comm="mediascanner-se" exe="/snap/mediascanner2/x1/bin/mediascanner-service-2.0" sig=31 arch=c000003e syscall=45 compat=0 ip=0x7f28d037866d code=0x0 This appears to be the recvfrom system call. The snap was configured with a slot using the generic "dbus" interface, but not the "network" plug. If I add "network", the problem goes away. Looking at the seccomp filters for "dbus" interface definition in snapd it allows recvmsg and sendmsg, but the D-Bus library this code uses (GLib's GDBus) uses recvfrom() (at least it does while initialising the connection). My first thought was that these extra system calls to the dbus interface's seccomp filter. But then I took another look at what calls were enabled for the base policy, which showed socket(), connect(), {get,set}sockopt, and a few others. The only thing preventing the default policy from creating IP sockets is the AppArmor policy. Given that the default policy nominally allows communication via unix domain sockets within a snap, I wonder if it would make sense to move the other socket related syscalls from the network interface to the default? I've created the following bug report to help track this problem: https://bugs.launchpad.net/snappy/+bug/1663177 James. From didrocks at ubuntu.com Fri Feb 10 08:01:50 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 10 Feb 2017 09:01:50 +0100 Subject: One snap to connect them all (or: the plugin story) In-Reply-To: <97130291-0945-88d5-284d-f65b68118a27@canonical.com> References: <97130291-0945-88d5-284d-f65b68118a27@canonical.com> Message-ID: <9065e317-1dac-4c8a-f5c1-3681f741077e@ubuntu.com> Le 09/02/2017 à 17:12, Kyle Fazzari a écrit : > > On 02/09/2017 01:04 AM, Didier Roche wrote: >> Ok, sorry for the catchy email title but couldn't resist :) >> >> So, I'm in the situation where one snap would need to get configuration >> and access to some files from other snaps. It's really similar to our >> plugin story: even if in that case, we are talking about optional >> configuration and files from one or multiple snaps shared with a single >> one collecting them all. >> >> I can see 2 options in the snapd philosophy: >> >> - Content sharing. Sounds like it matches exactly the purpose of it. >> However, even disregarding the manual connection that will be needed, we >> are stuck on the fact that it's limited to one connection for a given >> slot. If I want to share configuration and files from 3 snaps to the >> master one, I can't do 3 times: >> $ snap connect snap1:config my-master-snap:config >> $ snap connect snap2:config my-master-snap:config >> $ snap connect snap2:config my-master-snap:config >> >> One way would be to create different slot names: >> $ snap connect snap1:config my-master-snap:config1 >> $ snap connect snap2:config my-master-snap:config2 >> $ snap connect snap2:config my-master-snap:config3 >> >> But this doesn't help on the ease of use (the notice is then for people >> "find the first available slot"… Not really user-friendly) nor in the >> scalibity (fixed number of slots…) > Does https://bugs.launchpad.net/snapd/+bug/1655125 cover this case? > > Rereading today with fresh eyes and brain, yeah, that exactly covers it. Thanks Kyle for pointing the discussion out! From roberto.escandon at canonical.com Fri Feb 10 08:16:59 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 10 Feb 2017 09:16:59 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> Message-ID: I tried content sharing and works fine in this case, Nextcloud exposing a slot to its documents folder. I think I saw somewhere this is only valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the same time. Is that correct? Can removable-media improve this? On 10/02/17 08:05, Kyle Fazzari wrote: > On Feb 9, 2017 10:21 PM, "Simon Fels" wrote: > > On 09.02.2017 17:08, Thomas Voß wrote: >> On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  >> wrote: >>> Because this will use nextcloud documents, and they are internal to >>> nextcloud snap >>> >> >> In that case, content-sharing would help, yes. > > Is that always the case? I thought we talked a while back about using > the removable-media interface also as an option in the nextcloud snap to > allow users placing their data on an external hardware driver or > different partition. Not sure if this was ever implemented. > > > Simon is correct, this is indeed supported. > > > From simon.fels at canonical.com Fri Feb 10 08:38:32 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 10 Feb 2017 09:38:32 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> Message-ID: On 10.02.2017 09:16, Roberto Mier Escandón  wrote: > I tried content sharing and works fine in this case, Nextcloud exposing > a slot to its documents folder. I think I saw somewhere this is only > valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the > same time. Is that correct? Can removable-media improve this? There can be multiple plugs using the slot. The removable-media interfaces allows access to the host /media directory. That is everything. So unless nextcloud places its data files there this doesn't help you. regards, Simon From roberto.escandon at canonical.com Fri Feb 10 08:48:51 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 10 Feb 2017 09:48:51 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> Message-ID: <0374d127-68a6-e4ff-d5b3-7916d7ffc2b7@canonical.com> Ah, thanks. I'd better use content then. On 10/02/17 09:38, Simon Fels wrote: > On 10.02.2017 09:16, Roberto Mier Escandón  wrote: >> I tried content sharing and works fine in this case, Nextcloud exposing >> a slot to its documents folder. I think I saw somewhere this is only >> valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the >> same time. Is that correct? Can removable-media improve this? > > There can be multiple plugs using the slot. > > The removable-media interfaces allows access to the host /media > directory. That is everything. So unless nextcloud places its data files > there this doesn't help you. > > regards, > Simon > > From simon.fels at canonical.com Fri Feb 10 10:34:16 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 10 Feb 2017 11:34:16 +0100 Subject: chroot into a snap In-Reply-To: <0374d127-68a6-e4ff-d5b3-7916d7ffc2b7@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> <0374d127-68a6-e4ff-d5b3-7916d7ffc2b7@canonical.com> Message-ID: I think you have to support both as otherwise you may miss certain setups of nextcloud. One may be configured to use $SNAP_DATA/$SNAP_COMMON to store its data, another one may use /media/.. to do that. In the end there needs to be some kind of communication happen between both snaps. Either the nextcloud snap shares the data directory via the content interface, regardless where it is. However for that case I am not sure if the security rules of the content interface would allow such a case (effectively sharing /media to another snap via the content interface). The other way would be that the nextcloud snap somehow exposes a pointer for the office snap where to look for its data and then it can either use the path connected via the content or via the removable-media plug. regards, Simon On Fri, Feb 10, 2017 at 9:48 AM, Roberto Mier Escandón  < roberto.escandon at canonical.com> wrote: > Ah, thanks. I'd better use content then. > > On 10/02/17 09:38, Simon Fels wrote: > > On 10.02.2017 09:16, Roberto Mier Escandón  wrote: > >> I tried content sharing and works fine in this case, Nextcloud exposing > >> a slot to its documents folder. I think I saw somewhere this is only > >> valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the > >> same time. Is that correct? Can removable-media improve this? > > > > There can be multiple plugs using the slot. > > > > The removable-media interfaces allows access to the host /media > > directory. That is everything. So unless nextcloud places its data files > > there this doesn't help you. > > > > regards, > > Simon > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Fri Feb 10 13:08:46 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Fri, 10 Feb 2017 16:08:46 +0300 Subject: start engine before client Message-ID: The program "app1" is not mine. It consists of two parts. I create snapcraft.yaml -------------------------------- apps: engine: command: $SNAP/opt/app1/engine --start plugs: [home, unity7, x11, pulseaudio, network, network-bind] player: command: $SNAP/opt/app1/player "$@" plugs: [home, unity7, x11, pulseaudio, network, network-bind] -------------------------------- If to launch an engine (app1.engine) and then the client (app1.player), then everything works perfectly. How to make that start of the client automatically launched an engine? Sorry for my english. -- Best regards, vasilisc From roberto.escandon at canonical.com Fri Feb 10 13:44:18 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 10 Feb 2017 14:44:18 +0100 Subject: chroot into a snap In-Reply-To: References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> <0374d127-68a6-e4ff-d5b3-7916d7ffc2b7@canonical.com> Message-ID: <6e451f22-4555-4d3c-bf2f-30e48d462cf8@canonical.com> That's interesting, Simon. Good idea having available both $SNAP_DATA and /media. We'll do. But now, let's back to original topic: chroot into snap. After solving the issue Thomas found related with the path of the document, I see now there are two operations not allowed in strict confinement: mknod and chroot. Here is what the snappy-debug.security log shows: = Seccomp = Time: Feb 10 12:31:31 Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=31983 comm="loolkit" exe="/snap/loolwsd/x16/usr/bin/loolforkit" sig=31 arch=c000003e 133(mknod) compat=0 ip=0x7f6a6d6450fd code=0x0 Syscall: mknod = Seccomp = Time: Feb 10 12:31:42 Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c000003e 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 Syscall: chroot I've solved that by plugging docker-support and all works fine. But that interface gives a lot of permissions, and the name maybe is not the most accurate for a case like this. Shouldn't we have an interface allowing mknod, chroot and maybe ptrace for snaps creating their own chroot jails?. BR. On 10/02/17 11:34, Simon Fels wrote: > I think you have to support both as otherwise you may miss certain setups > of nextcloud. One may be configured to use $SNAP_DATA/$SNAP_COMMON to store > its data, another one may use /media/.. to do that. In the end there needs > to be some kind of communication happen between both snaps. > > Either the nextcloud snap shares the data directory via the content > interface, regardless where it is. However for that case I am not sure if > the security rules of the content interface would allow such a case > (effectively sharing /media to another snap via the content interface). > > The other way would be that the nextcloud snap somehow exposes a pointer > for the office snap where to look for its data and then it can either use > the path connected via the content or via the removable-media plug. > > regards, > Simon > > On Fri, Feb 10, 2017 at 9:48 AM, Roberto Mier Escandón  < > roberto.escandon at canonical.com> wrote: > >> Ah, thanks. I'd better use content then. >> >> On 10/02/17 09:38, Simon Fels wrote: >>> On 10.02.2017 09:16, Roberto Mier Escandón  wrote: >>>> I tried content sharing and works fine in this case, Nextcloud exposing >>>> a slot to its documents folder. I think I saw somewhere this is only >>>> valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the >>>> same time. Is that correct? Can removable-media improve this? >>> >>> There can be multiple plugs using the slot. >>> >>> The removable-media interfaces allows access to the host /media >>> directory. That is everything. So unless nextcloud places its data files >>> there this doesn't help you. >>> >>> regards, >>> Simon >>> >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/snapcraft >> > > > From michael.terry at canonical.com Fri Feb 10 13:57:18 2017 From: michael.terry at canonical.com (Michael Terry) Date: Fri, 10 Feb 2017 08:57:18 -0500 Subject: 'organize' affects 'stage-packages' In-Reply-To: References: Message-ID: You can use a separate part for the stage packages: parts: part1: ... organize: '*': opt/ part2: plugin: nil stage-packages: - some-great-package On Thu, Feb 9, 2017 at 11:47 PM, Ruddick Lawrence wrote: > I just discovered that a part with: > > organize: > '*': opt/ > stage-packages: > - some-great-package > > moves the contents of the stage-packages into opt in addition to the > output of the plugin. Is this the intended behavior, and if so, is there a > way to move only the plugin output into a subfolder? > > Thanks, > Ruddick > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- -mt -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.brustkern at canonical.com Fri Feb 10 14:32:41 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Fri, 10 Feb 2017 09:32:41 -0500 Subject: Spread linode backend In-Reply-To: References: Message-ID: I tried exporting that before running spread, and that didn't change the result. Thanks, Max On Thu, Feb 9, 2017 at 2:26 PM, Thomas Voß wrote: > Hey Max, > > as a quick test, would you mind trying to set > > TAR_OPTIONS='--format=posix' > > in the environment you run spread in? > > Thanks, > > Thomas > > On Thu, Feb 9, 2017 at 6:19 PM, Max Brustkern > wrote: > > I'm attempting to use the spread linode backend with this system stanza, > as > > described in the documentation: > > backends: > > linode: > > key: $(HOST:echo $LINODE_API_KEY) > > systems: > > - 'ubuntu-16.04' > > I'm getting this error: > > 2017/02/09 11:00:18 Error packing project content for delivery: cannot > pack > > project tree: > > ----- > > tar: > > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/ > expected.classic.ubuntu-core.linode.i386.json: > > file name is too long (max 99); not dumped > > tar: > > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/ > expected.classic.ubuntu-core.qemu.amd64.json: > > file name is too long (max 99); not dumped > > tar: > > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/ > expected.classic.ubuntu-core.linode.amd64.json: > > file name is too long (max 99); not dumped > > tar: Exiting with failure status due to previous errors > > ----- > > 2017/02/09 11:00:19 Successful tasks: 0 > > 2017/02/09 11:00:19 Aborted tasks: 9 > > error: cannot pack project content for delivery > > > > Any suggestions? > > > > Thanks, > > Max > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simos.lists at googlemail.com Fri Feb 10 16:30:44 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Fri, 10 Feb 2017 18:30:44 +0200 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: <0dc231f8-26fc-d929-faef-7f28e1b8850d@ubuntu.com> References: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> <0dc231f8-26fc-d929-faef-7f28e1b8850d@ubuntu.com> Message-ID: On Tue, Feb 7, 2017 at 3:54 PM, Didier Roche wrote: > Le 07/02/2017 à 14:05, Simos Xenitellis a écrit : >> On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche wrote: >>> Le 06/02/2017 à 10:56, Simos Xenitellis a écrit : >>>> Hi All, >>>> >>>> I wrote an article about creating a snap for an existing Python >>>> program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu >>>> Store. >>>> >>>> I am looking forward to receiving feedback :-) >>>> >>>> Link: https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ >>>> >>>> Link to HN submission: https://news.ycombinator.com/item?id=13578034 >>>> >>>> Simos >>>> >>> Excellent work Simos! >>> >>> I think this kind of content would make an excellent official "pratical" >>> tutorials on https://tutorials.ubuntu.com. Are you interested into >>> contributing there? >>> >>> If you want more context on tutorials, the phisolophy and how to >>> contribute, I wrote a blog post some time ago about it: >>> https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/. >>> >>> I'm also available for any help, >> Thanks Didier! >> >> I had a look at https://github.com/ubuntudesign/tutorials.ubuntu.com/issues >> and the direction that tutorials.ubuntu.com wants to take. It looks good. >> It requires planning in terms of the writing of the tutorials so that >> they are gradually incremental, >> and some basic tutorials can referenced by the more complex ones. It's >> a lot of dedicated work. >> >> I'll give it a go and try to write a couple of tutorials for >> tutorials.ubuntu.com. We will see how it goes :-) >> I think I'll start with the baseline tutorial for snapcraft. > > Excellent news! > You can as well convert some of yours to this format! I give you the > direct link to the guidelines to have some coherences between the > tutorials in term of tones and content: > https://docs.google.com/document/d/1u5qmSNIcE8SjuAg6aKjTxOBGWIjBW0kYf01t4Dfw6-U/edit. > I managed to complete the conversion and the tutorial is ready :-). Here it is, https://docs.google.com/document/d/1Nk-kw79lt84YJNEKS_WpnGzVSjrmCUVd1TsAx5aRoOA/ Feel free to add to tutorials.ubuntu.com or make a copy in order to edit. Overall, the experience in converting to the format required by codelabs was interesting. I still need more practice before I would be able to write a tutorial in one go in the codelab style. Simos From ruddick at carbon.ai Fri Feb 10 17:00:12 2017 From: ruddick at carbon.ai (Ruddick Lawrence) Date: Fri, 10 Feb 2017 09:00:12 -0800 Subject: 'organize' affects 'stage-packages' Message-ID: Thanks, that's what I ended up doing. It just surprised me that the stage-packages were subject to organization. Ruddick On Fri, Feb 10, 2017 at 5:57 AM, Michael Terry wrote: > > > You can use a separate part for the stage packages: > > parts: > part1: > ... > organize: > '*': opt/ > part2: > plugin: nil > stage-packages: > - some-great-package > > > On Thu, Feb 9, 2017 at 11:47 PM, Ruddick Lawrence > wrote: > > > I just discovered that a part with: > > > > organize: > > '*': opt/ > > stage-packages: > > - some-great-package > > > > moves the contents of the stage-packages into opt in addition to the > > output of the plugin. Is this the intended behavior, and if so, is there > a > > way to move only the plugin output into a subfolder? > > > > Thanks, > > Ruddick > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > mailman/listinfo/snapcraft > > > > > > > -- > -mt > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170210/ef7683db/attachment-0001.html> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge.borovkov at gmail.com Fri Feb 10 17:35:09 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Fri, 10 Feb 2017 20:35:09 +0300 Subject: Exposing dbus interface and using it inside the same snap Message-ID: Hi, I've been struggling with getting dbus interface exposed. I am getting this error during runtime: GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.1160" is not allowed to own the service "com.screenly.playlist" due to security policies in the configuration file (9) jdstrand helped me on IRC, and told me I need to have a slot and a plug in my snap. I am doing something wrong though, can someone help out with how it's correctly supposed to be used? apps: playlist: command: usr/bin/playlist-service.sh daemon: simple plugs: [network-bind, network, playlist-dbus] websocket: command: usr/bin/websocket-service.sh daemon: simple plugs: [network-bind, network, dbus] slots: [websocket-dbus] slots: playlist-dbus: interface: dbus name: com.screenly bus: system plugs: websocket-dbus: interface: dbus name: com.screenly bus: system -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjwatson at ubuntu.com Fri Feb 10 18:28:43 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Fri, 10 Feb 2017 18:28:43 +0000 Subject: launchpad snap recipe fails with classic confinement In-Reply-To: References: <95199d1d-02f5-9356-9e8d-92b0a39f08be@canonical.com> Message-ID: <20170210182843.GB10757@riva.ucam.org> On Thu, Feb 09, 2017 at 04:43:33PM -0300, Sergio Schvezov wrote: > El jueves, 9 de febrero de 2017 16h'23:34 ART, Colin Watson > escribió: > >Oh, in fact, that looks just about perfect for us. With that patch I > >think LP could just export SNAPCRAFT_SETUP_CORE=1 when building snaps, > >right? > > Absolutely correct. If you enable this in staging I can give it some test > runs. This is on our dogfood instance now and I've been able to get a successful run out of it: https://dogfood.paddev.net/~cjwatson/+snap/helloworld-classic/+build/413 The ticket to deploy this is (internal link): https://portal.admin.canonical.com/99787 ... so I expect that this will be rolled out by the time you release snapcraft 2.27. Cheers, -- Colin Watson [cjwatson at ubuntu.com] From joseph.wakeling at webdrake.net Fri Feb 10 19:39:28 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 10 Feb 2017 20:39:28 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: <85ef37a8-e9e1-dfaa-a58e-8a702314afe0@webdrake.net> References: <20170202073818.b2heyissfeo2tulw@x250> <85ef37a8-e9e1-dfaa-a58e-8a702314afe0@webdrake.net> Message-ID: <580c7404-9ab8-8062-5ad2-ba2447d45ec6@webdrake.net> On 08/02/17 17:15, Joseph Rushton Wakeling wrote: > On 07/02/17 21:17, Thomas Voß wrote: >> https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 >> was released to the updates pocket today. > > Thanks! I'll hopefully be able to report back to you tomorrow whether all works > as expected. Just to confirm: today I was able to successfully install snapd on Ubuntu 14.04, with just the regular repositories enabled (no -proposed). I was then able to successfully install and run snap packages (after a restart to ensure the PATH variable included /snap/bin). Unfortunately being able to do this revealed some rather fundamental problems with the 'universality' of my LDC snap, but more on that in another thread ... ;-) Thanks to everyone who got snapd ported successfully to 14.04! From thomas.voss at canonical.com Fri Feb 10 20:00:03 2017 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Fri, 10 Feb 2017 21:00:03 +0100 Subject: snapd available in Trusty Tahr In-Reply-To: <580c7404-9ab8-8062-5ad2-ba2447d45ec6@webdrake.net> References: <20170202073818.b2heyissfeo2tulw@x250> <85ef37a8-e9e1-dfaa-a58e-8a702314afe0@webdrake.net> <580c7404-9ab8-8062-5ad2-ba2447d45ec6@webdrake.net> Message-ID: On Fri, Feb 10, 2017 at 8:39 PM, Joseph Rushton Wakeling wrote: > On 08/02/17 17:15, Joseph Rushton Wakeling wrote: >> >> On 07/02/17 21:17, Thomas Voß wrote: >>> >>> >>> https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 >>> was released to the updates pocket today. >> >> >> Thanks! I'll hopefully be able to report back to you tomorrow whether all >> works >> as expected. > > > Just to confirm: today I was able to successfully install snapd on Ubuntu > 14.04, with just the regular repositories enabled (no -proposed). I was > then able to successfully install and run snap packages (after a restart to > ensure the PATH variable included /snap/bin). > \o/, thanks for your feedback :) > Unfortunately being able to do this revealed some rather fundamental > problems with the 'universality' of my LDC snap, but more on that in another > thread ... ;-) > Watching the list, curious what you found out. Thanks, Thomas > Thanks to everyone who got snapd ported successfully to 14.04! > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft From joseph.wakeling at webdrake.net Fri Feb 10 20:41:52 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 10 Feb 2017 21:41:52 +0100 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) Message-ID: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> Hi all, So, earlier today I tried out my ldc2 snap on an Ubuntu 14.04 system for the first time. sudo snap install --classic --edge ldc2 worked just fine, but I ran into problems as soon as I tried to compile a simple 'hello world' program: void main() { import std.stdio : writeln; writeln("Hello, D!"); } Attempting to compile this program resulted in a segfault in GCC (which LDC invokes in order to link programs). Running `ldc -v` for verbose output, the precise call that segfaulted was: /usr/bin/gcc hello.o -o hello -L/snap/ldc2/3/bin/../lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 My suspicion is that that `libphobos2-ldc` and `libdruntime-ldc`, which are provided as precompiled static libraries in the snap package, are not ABI compatible with 14.04, hence the segfault. What do people reckon, and any advice on how to address it? This is a case where I don't see bundling GCC with the snap as really fixing things, because if my ABI suspicion is right, it would surely still result in incompatibility with any host-system libraries the user might want to link against. It's possible I might be able to address this by supplying druntime and phobos as source-only libraries (not a problem since D compilation is extremely fast), but that's not going to solve things for other people facing a similar issue, so I'm happy to help testing things if a more robust solution seems possible. Anyway, does anyone have any thoughts? Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Fri Feb 10 20:45:25 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 10 Feb 2017 21:45:25 +0100 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) In-Reply-To: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> Message-ID: <3e2b48ce-b0c9-d847-a9b2-7e33561bab96@webdrake.net> On 10/02/17 21:41, Joseph Rushton Wakeling wrote: > Running `ldc -v` for verbose output, the precise call that segfaulted was: > > /usr/bin/gcc hello.o -o hello -L/snap/ldc2/3/bin/../lib -lphobos2-ldc > -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 > > My suspicion is that that `libphobos2-ldc` and `libdruntime-ldc`, which are > provided as precompiled static libraries in the snap package, are not ABI > compatible with 14.04, hence the segfault. For the avoidance of doubt: none of the other linked libraries are provided in the snap itself, only libdruntime-ldc and libphobos2-ldc. From seth.arnold at canonical.com Fri Feb 10 23:48:42 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Fri, 10 Feb 2017 15:48:42 -0800 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) In-Reply-To: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> Message-ID: <20170210234842.GC28439@hunt> On Fri, Feb 10, 2017 at 09:41:52PM +0100, Joseph Rushton Wakeling wrote: > Attempting to compile this program resulted in a segfault in GCC (which LDC > invokes in order to link programs). [...] > Anyway, does anyone have any thoughts? Hi Joe, can you grab the dmesg output that might include DENIED lines as well as the kernel's segfault report? This may give enough information for someone to suggest the next step. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mark at ubuntu.com Sat Feb 11 15:02:24 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 11 Feb 2017 15:02:24 +0000 Subject: Git commit+ Message-ID: <684260f1-1fe8-8564-590f-dcfbd348d72c@ubuntu.com> Hi folks In a branch with a snap/snapcraft.yaml I am seeing that git reports a version with a dirty commit (suffix+) for snaps built from the branch. Is there a way to prevent this, or is snapcraft doing something during the snapping process which will cause git to think the checkout is dirty? Mark From joseph.wakeling at webdrake.net Sat Feb 11 16:31:40 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 11 Feb 2017 17:31:40 +0100 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) In-Reply-To: <20170210234842.GC28439@hunt> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> <20170210234842.GC28439@hunt> Message-ID: <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> On 11/02/17 00:48, Seth Arnold wrote: > Hi Joe, can you grab the dmesg output that might include DENIED lines as > well as the kernel's segfault report? Sure -- thanks for the thought! :-) I just reproduced the issue in a VirtualBox install of 14.04 to get these details. Kernel report in kern.log: Feb 11 17:16:19 vb1404 kernel: [ 534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000] And `dmesg | grep -i gcc` gave this output: [ 0.000000] Linux version 4.4.0-62-generic (buildd at lcy01-33) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 (Ubuntu 4.4.0-62.83~14.04.1-generic 4.4.40) [ 534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000] > This may give enough information for someone to suggest the next step. I'm not very experienced at interpreting these kinds of messages, but if I understand right they would suggest a libc compatibility issue ... ? Thanks & best wishes, -- Joe From leo.arias at canonical.com Sat Feb 11 16:34:19 2017 From: leo.arias at canonical.com (Leo Arias) Date: Sat, 11 Feb 2017 10:34:19 -0600 Subject: Git commit+ In-Reply-To: <684260f1-1fe8-8564-590f-dcfbd348d72c@ubuntu.com> References: <684260f1-1fe8-8564-590f-dcfbd348d72c@ubuntu.com> Message-ID: Hello! This is bug: https://bugs.launchpad.net/snapcraft/+bug/1662388 We will discuss if removing the yaml is needed at all. But in the meantime, add source-type: git. pura vida. From joseph.wakeling at webdrake.net Sat Feb 11 16:35:41 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 11 Feb 2017 17:35:41 +0100 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) In-Reply-To: <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> <20170210234842.GC28439@hunt> <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> Message-ID: <19d5eab1-8991-c8ed-52d7-7092fec693fb@webdrake.net> On 11/02/17 17:31, Joseph Rushton Wakeling wrote: > And `dmesg | grep -i gcc` gave this output: Slightly more detailed dmesg output from `dmesg | grep -e "gcc" -e "ldc2"`: [ 0.000000] Linux version 4.4.0-62-generic (buildd at lcy01-33) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 (Ubuntu 4.4.0-62.83~14.04.1-generic 4.4.40) [ 249.403368] audit: type=1400 audit(1486829494.212:33): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldc-profdata" pid=5600 comm="apparmor_parser" [ 249.409009] audit: type=1400 audit(1486829494.220:34): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldc-prune-cache" pid=5602 comm="apparmor_parser" [ 249.413008] audit: type=1400 audit(1486829494.220:35): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldc2" pid=5604 comm="apparmor_parser" [ 249.426591] audit: type=1400 audit(1486829494.240:36): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.ldc2.ldmd2" pid=5606 comm="apparmor_parser" [ 534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000] From mark at ubuntu.com Sat Feb 11 16:56:13 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 11 Feb 2017 16:56:13 +0000 Subject: Git commit+ In-Reply-To: References: <684260f1-1fe8-8564-590f-dcfbd348d72c@ubuntu.com> Message-ID: OK, glad it's a known issue. The 'source-type: git' piece didn't fix anything for me, though, I still see the dirty-commit version number. snap/snapcraft.yaml contains this: parts: keepalived: plugin: autotools source: . source-type: git What am I missing? Mark On 11/02/17 16:34, Leo Arias wrote: > Hello! > > This is bug: https://bugs.launchpad.net/snapcraft/+bug/1662388 > We will discuss if removing the yaml is needed at all. But in the > meantime, add source-type: git. > > pura vida. > From leo.arias at canonical.com Sat Feb 11 17:01:26 2017 From: leo.arias at canonical.com (Leo Arias) Date: Sat, 11 Feb 2017 11:01:26 -0600 Subject: Git commit+ In-Reply-To: References: <684260f1-1fe8-8564-590f-dcfbd348d72c@ubuntu.com> Message-ID: On Sat, Feb 11, 2017 at 10:56 AM, Mark Shuttleworth wrote: > What am I missing? It's not you, it's us. I was just playing with mosh and I see that copying the snapcraft.yaml to the part/src dir is not enough. It also needs to be in part/build. I don't have a workaround for that, we'll need to change some code. -- ¡paz y baile! http://www.ubuntu.com From gregory.lutostanski at canonical.com Sat Feb 11 18:05:37 2017 From: gregory.lutostanski at canonical.com (Gregory Lutostanski) Date: Sat, 11 Feb 2017 12:05:37 -0600 Subject: Non-http git submodules with launchpad builders Message-ID: So I've got a snapcraft.yaml that builds fine locally, but it has submodules from a remote git:// repo (rather than https://), this means the HTTP and HTTPS proxies don't help -- which leads to errors on launchpad builders. I tried to change the submodule url in the prepare step, but snapcraft already does a git clone --recursive, so this is a step too late. (git:// anongit.freedesktop.org/xcb/util-common-m4.git, to https://anongit.freedesktop.org/git/xcb/util-common-m4.git) Is there any way I can let the git source from snapcraft not pull recusively? Or might we be able to have launchpad builders have a git proxy (perhaps via GIT_PROXY_COMMAND, like in https://stackoverflow.com/questions/783811/getting-git-to-work-with-a-proxy-server/21136254#21136254 ) Otherwise I will have to have a mirror of the upstream repo, with just submodules changed, which seems a bit hacky. Snapcraft.yaml is here: https://github.com/lutostag/easy2fa/blob/master/snap/snapcraft.yaml Has anyone else hit this issue? Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjwatson at ubuntu.com Sat Feb 11 18:42:06 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Sat, 11 Feb 2017 18:42:06 +0000 Subject: Non-http git submodules with launchpad builders In-Reply-To: References: Message-ID: <20170211184206.GA7467@riva.ucam.org> On Sat, Feb 11, 2017 at 12:05:37PM -0600, Gregory Lutostanski wrote: > Is there any way I can let the git source from snapcraft not pull > recusively? Or might we be able to have launchpad builders have a git proxy > (perhaps via GIT_PROXY_COMMAND, like in > https://stackoverflow.com/questions/783811/getting-git-to-work-with-a-proxy-server/21136254#21136254 > ) I think it would be best to arrange for Launchpad builders to have a git proxy; you aren't the first to run into this. Could you file a bug against the launchpad-buildd project on Launchpad to remind us? Thanks, -- Colin Watson [cjwatson at ubuntu.com] From gregory.lutostanski at canonical.com Sat Feb 11 19:08:20 2017 From: gregory.lutostanski at canonical.com (Gregory Lutostanski) Date: Sat, 11 Feb 2017 13:08:20 -0600 Subject: Non-http git submodules with launchpad builders In-Reply-To: <20170211184206.GA7467@riva.ucam.org> References: <20170211184206.GA7467@riva.ucam.org> Message-ID: Of course! https://bugs.launchpad.net/launchpad-buildd/+bug/1663920 Thanks! On Feb 11, 2017 12:42 PM, "Colin Watson" wrote: > On Sat, Feb 11, 2017 at 12:05:37PM -0600, Gregory Lutostanski wrote: > > Is there any way I can let the git source from snapcraft not pull > > recusively? Or might we be able to have launchpad builders have a git > proxy > > (perhaps via GIT_PROXY_COMMAND, like in > > https://stackoverflow.com/questions/783811/getting-git- > to-work-with-a-proxy-server/21136254#21136254 > > ) > > I think it would be best to arrange for Launchpad builders to have a git > proxy; you aren't the first to run into this. Could you file a bug > against the launchpad-buildd project on Launchpad to remind us? > > Thanks, > > -- > Colin Watson [cjwatson at ubuntu.com] > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.hampt at gmail.com Sun Feb 12 09:30:22 2017 From: aaron.hampt at gmail.com (Aaron Hampton) Date: Sun, 12 Feb 2017 04:30:22 -0500 Subject: Is there a way to prompt users to connect a non-auto-connect interface during installation? Message-ID: Hi, I am working on snapping a desktop application that needs access to hardware-observe. Is there a way to prompt the user to connect the interface during the installation of the snap? Or is the only way to have the user run snap connect? I found this comment: " Just to state the plan of record, we intend that store assertions can pre-approve some auto-connection, or cue up a prompt for interactive installations where the user is asked if they want to connect. So in your case, the experience should become something like: $ sudo snap install handbrake Allow 'handbrake' to access DVDs? (Y/N) Y handbrake 1.3.2 installed " In this thread: https://lists.ubuntu.com/archives/snapcraft/2016-October/001281.html That's exactly the type of interaction I'm looking to implement, but I haven't been able to find any more information about it. If that's not available yet, is there any other recommended method for connecting interfaces that might be a little easier for less knowledgeable end users? Thanks again! Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Sun Feb 12 09:58:15 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sun, 12 Feb 2017 09:58:15 +0000 Subject: Is there a way to prompt users to connect a non-auto-connect interface during installation? In-Reply-To: References: Message-ID: <65b90c9d-3966-adcd-b2d7-7b1731655206@ubuntu.com> On 12/02/17 09:30, Aaron Hampton wrote: > I am working on snapping a desktop application that needs access to > hardware-observe. Is there a way to prompt the user to connect the > interface during the installation of the snap? Or is the only way to > have the user run snap connect? > > I found this comment: > > " > Just to state the plan of record, we intend that store assertions can > pre-approve some auto-connection, or cue up a prompt for interactive > installations where the user is asked if they want to connect. > So in your case, the experience should become something like: > > $ sudo snap install handbrake > Allow 'handbrake' to access DVDs? (Y/N) Y > handbrake 1.3.2 installed > " > In this thread: > https://lists.ubuntu.com/archives/snapcraft/2016-October/001281.html > That's exactly the type of interaction I'm looking to implement, but I haven't been able to find any more information about it. > If that's not available yet, is there any other recommended method for connecting interfaces that might be a little easier for less knowledgeable end users? OK, there are three pieces you need, one of which is now in place. We already have a way for the store to tell a device to auto-connect some interfaces. We don't afaik yet have a way for the store to prompt the user (i.e. offer the user a pre-defined CHOICE of connections). That will require some thinking about UX, to define how the interfaces should be offered, what language to use, where the appropriate descriptions of the interfaces should be stored, how we will handle translation etc. This is an interesting problem because we are determined to avoid techno-choices ("connect core:db-access to flubber:funkyjohn?") that don't mean things to end users. That means we need a way to offer the choice which provides a reasonable basis for a correct decision by less-than-average-insightful users. And finally, we need to design and implement how that get expressed in the desktop GUI from a store like GNOME Software or the KDE equivalent. That latter piece will probably use all the hard thinking about UX from the CLI version, but obviously it's a separate bit of work to express it in the GUI. I would look to the core team to lead the CLI UX work, which can be done in a shared google doc. It would be up to the desktop GUI folks to figure out the expression in the desktop. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Mon Feb 13 00:44:09 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 13 Feb 2017 08:44:09 +0800 Subject: start engine before client In-Reply-To: References: Message-ID: I think you can just make a script. Inside the script, launch the engine first, then start the player client. You just need one app which launches your created script. Best regards, xiaoguo On Fri, Feb 10, 2017 at 9:08 PM, Vasilisc wrote: > The program "app1" is not mine. It consists of two parts. > > I create snapcraft.yaml > -------------------------------- > apps: > engine: > command: $SNAP/opt/app1/engine --start > plugs: [home, unity7, x11, pulseaudio, network, network-bind] > > player: > command: $SNAP/opt/app1/player "$@" > plugs: [home, unity7, x11, pulseaudio, network, network-bind] > -------------------------------- > > If to launch an engine (app1.engine) and then the client (app1.player), > then everything works perfectly. How to make that start of the client > automatically launched an engine? > > Sorry for my english. > -- > Best regards, > vasilisc > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From michi.henning at canonical.com Mon Feb 13 02:40:02 2017 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 13 Feb 2017 12:40:02 +1000 Subject: Package too old for cleanbuild In-Reply-To: References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: I’ve opened a bug here for the overlay build: https://launchpad.net/bugs/1664100 Michi. > On 10 Feb 2017, at 9:12 , Leo Arias wrote: > > Hello, > > We have a few cleanbuild bugs open: > https://bugs.launchpad.net/snapcraft/+bugs?field.tag=cleanbuild > > Some of them are related to what you are asking, so I would appreciate > if you go in there and add your comments with the ideal solution for > your use case. If you don't find any bug that asks for what you need, > please report a new one. > > Also note that some bugs are not confirmed. It's really useful for us > when we are planning the work for the next sprint to look at the bugs > that affect more than one person. So if you would like to see one bug > fixed soon, mark it as affecting you, we'll hear it. > > Our planning meeting is tomorrow :) > > pura vida. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From michi.henning at canonical.com Mon Feb 13 02:44:32 2017 From: michi.henning at canonical.com (Michi Henning) Date: Mon, 13 Feb 2017 12:44:32 +1000 Subject: Package too old for cleanbuild In-Reply-To: References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> Message-ID: <03E7FAE1-F775-4CCD-B0BB-776EFCFDC627@canonical.com> > > While I don't disagree with the suggestions here, if I may suggest a > workaround: > > If you find yourself using cleanbuild a lot (it makes a new ephemeral > container, builds, then destroys the container), you might find some > workflow improvements by simply developing the snap in a container. You > can even bind-mount the source from the host, if you want. This is the > workflow I use personally. It allows for one to fully customize the apt > sources while also utilizing Snapcraft's built-in stage package cache*, > and it doesn't clutter the development environment on the host. Thanks Kyle! While this works, I don’t think it meets the pragmatic needs of the developer. It’s already complex enough to learn a new tool chain and figure out an effective edit/debug/test cycle. If I have to set up my own container for this, I end up adding yet more variables and possible sources of errors. We really need the tool to take care of this, otherwise everyone goes through the same pain (and mistakes) over and over. The big bottleneck here is the endless re-downloading of all the packages. If snapcraft could take care of this transparently and use a cache, things would proceed at a tolerable pace, without everyone having to re-invent their own wheel. Cheers, Michi. From xiaoguo.liu at canonical.com Mon Feb 13 02:56:05 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 13 Feb 2017 10:56:05 +0800 Subject: Package too old for cleanbuild In-Reply-To: <03E7FAE1-F775-4CCD-B0BB-776EFCFDC627@canonical.com> References: <85E6992B-274F-4338-89BA-CF8E18C1FAA0@canonical.com> <03E7FAE1-F775-4CCD-B0BB-776EFCFDC627@canonical.com> Message-ID: Will the new release address the issue at https://bugs.launchpad.net/snapcraft/+bug/1662464? Currently, I am using ogra's packageproxy, and it works perfectly. I created a blog at http://blog.csdn.net/ubuntutouch/article/details/54405477 However, nodejs is not a debian package. Instead, it downloads every time after the project is cleaned and rebuilt. This is a really a bad developer experience. Last time, when I had a hackathon event, it was almost impossible for a developer to develop a nodejs at the site since the download took years to get it finished due to the network limitation or other reasons. Even now at home, sometimes it takes quite a while to download the nodejs package. I need to try different combination of VPN. It is really troublesome for me. Best regards, XiaoGuo On Mon, Feb 13, 2017 at 10:44 AM, Michi Henning wrote: > > > > While I don't disagree with the suggestions here, if I may suggest a > > workaround: > > > > If you find yourself using cleanbuild a lot (it makes a new ephemeral > > container, builds, then destroys the container), you might find some > > workflow improvements by simply developing the snap in a container. You > > can even bind-mount the source from the host, if you want. This is the > > workflow I use personally. It allows for one to fully customize the apt > > sources while also utilizing Snapcraft's built-in stage package cache*, > > and it doesn't clutter the development environment on the host. > > Thanks Kyle! > > While this works, I don’t think it meets the pragmatic needs of the > developer. It’s already complex enough to learn a new tool chain and figure > out an effective edit/debug/test cycle. If I have to set up my own > container for this, I end up adding yet more variables and possible sources > of errors. > > We really need the tool to take care of this, otherwise everyone goes > through the same pain (and mistakes) over and over. The big bottleneck here > is the endless re-downloading of all the packages. If snapcraft could take > care of this transparently and use a cache, things would proceed at a > tolerable pace, without everyone having to re-invent their own wheel. > > Cheers, > > Michi. > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.mardegan at canonical.com Mon Feb 13 06:49:44 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Mon, 13 Feb 2017 09:49:44 +0300 Subject: Is there a way to prompt users to connect a non-auto-connect interface during installation? In-Reply-To: References: Message-ID: <3b33b740-b356-9954-4b27-b6a2c58c9131@canonical.com> On 12/02/2017 12:30, Aaron Hampton wrote: > Hi, > > I am working on snapping a desktop application that needs access to > hardware-observe. Is there a way to prompt the user to connect the > interface during the installation of the snap? Or is the only way to > have the user run snap connect? While this feature is missing, you could wrap your programs in a shell script that checks whether the needed permissions are there and, if not, print a message using zenity to inform the user. Ciao, Alberto From vasilisc777 at gmail.com Mon Feb 13 07:02:41 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 13 Feb 2017 10:02:41 +0300 Subject: vlc mpris Message-ID: <420c3cb2-3411-5180-aa5e-7814151e171f@gmail.com> How to allow vlc - "org.mpris.MediaPlayer2.vlc.instance*" ??? [0xd5f358] dbus interface error: Error requesting service name org.mpris.MediaPlayer2.vlc.instance3045: Connection ":1.69" is not allowed to own the service "org.mpris.MediaPlayer2.vlc.instance3045" due to AppArmor policy ------------------------------ I don't see interfaces dbus|mpris # LANG=C apt policy snapd snapd: Installed: 2.21 Candidate: 2.21 Version table: *** 2.21 500 500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 2.0.2 500 500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages # snap interfaces | grep -E "(dbus|mpris)" # -- Best regards, vasilisc From james.henstridge at canonical.com Mon Feb 13 07:30:02 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Mon, 13 Feb 2017 15:30:02 +0800 Subject: vlc mpris In-Reply-To: <420c3cb2-3411-5180-aa5e-7814151e171f@gmail.com> References: <420c3cb2-3411-5180-aa5e-7814151e171f@gmail.com> Message-ID: On 13 February 2017 at 15:02, Vasilisc wrote: > How to allow vlc - "org.mpris.MediaPlayer2.vlc.instance*" ??? > > [0xd5f358] dbus interface error: Error requesting service name > org.mpris.MediaPlayer2.vlc.instance3045: Connection ":1.69" is not allowed > to own the service "org.mpris.MediaPlayer2.vlc.instance3045" due to AppArmor > policy > > ------------------------------ > I don't see interfaces dbus|mpris > > # LANG=C apt policy snapd > snapd: > Installed: 2.21 > Candidate: 2.21 > Version table: > *** 2.21 500 > 500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 > Packages > 100 /var/lib/dpkg/status > 2.0.2 500 > 500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages > > # snap interfaces | grep -E "(dbus|mpris)" > # You should be able to do this by adding a slot to your snap using the "mpris" interface. Something like this: slots: mpris: interface: mpris name: vlc Then make sure the app inside your snap uses this slot. This interface looks like it will work okay for the mpris provider, and okay for unconfined mpris clients on classic systems. It's not clear how you'd write a confined client that could act as a remote for all installed players without defining many duplicate plugs. If you're only interested in use on classic systems though, this should be good enough though. James. From fcole90 at gmail.com Mon Feb 13 09:03:57 2017 From: fcole90 at gmail.com (Fabio Colella) Date: Mon, 13 Feb 2017 09:03:57 +0000 Subject: Mesa 13.0.4 snap? Message-ID: Hi everybody, I have seen that mesa 13.0.4 won't ship on Ubuntu 16.04.2 but that a PPA has been made available for this (e.g. to play with DiRT). I deduct it was a pretty requested update. Would it be technically possible to have a mesa snap for the classical systems? Or a similar approach is restricted only to all snap (like Ubuntu Personal) systems? And, if feasible, what would it require? Cheers, Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Mon Feb 13 09:56:29 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Mon, 13 Feb 2017 10:56:29 +0100 Subject: interfaces composition Message-ID: <5742897f-f0c6-248a-362b-57db48c914bd@canonical.com> Hey, Just an idea. In my last snap I needed docker-support interface for only having access to use mknod and chroot. Compared with the big list of permissions that interface allows and I don't need, I wonder if we could have an internal kind of structure of interfaces so that there are some of them which are the composition of others. One snap could plug docker-support not knowing that is "chroot" interface + "ptrace" interface + whatever. Other snap can plug chroot interface instead since doesn't need the other stuff and so on... BR From vasilisc777 at gmail.com Mon Feb 13 10:56:33 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 13 Feb 2017 13:56:33 +0300 Subject: only english UI Message-ID: <5780129a-f37a-7510-6e59-2e9ba76ff99e@gmail.com> If you install vlc in snap package, then see only English interface. # snap find vlc Name Version Developer Notes Summary vlc daily videolan - The ultimate media player I try to pack the player-vlc-based and too I fail. Earlier I was helped by these lines, but not now #============================= export I18NPATH=$SNAP/usr/share/i18n export LOCPATH=$SNAP_USER_COMMON export LC_ALL=$LANG LANG1=$(echo $LANG | cut -f1 -d.) ENC=UTF-8 LOC="$LANG" # generate a locale so we get properly working charsets and graphics if [ ! -e $SNAP_USER_COMMON/$LOC ]; then $SNAP/usr/bin/localedef --prefix=$SNAP_USER_COMMON -f $ENC -i $LANG1 $SNAP_USER_COMMON/$LOC fi #============================= -- Best regards, vasilisc From luca.dionisi at gmail.com Mon Feb 13 11:34:23 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Mon, 13 Feb 2017 12:34:23 +0100 Subject: tcpdump armhf Message-ID: For debugging my app, I need to run "tcpdump" on my Ubuntu Core based Raspberry Pi. This tool is not installed in the "core" snap. A run of "snap find tcpdump" returns 0 results. What's my best move? Make a snap on my own and use launchpad snap-builders to produce the one for armhf? --Luca From alan.pope at canonical.com Mon Feb 13 11:48:15 2017 From: alan.pope at canonical.com (Alan Pope) Date: Mon, 13 Feb 2017 11:48:15 +0000 Subject: tcpdump armhf In-Reply-To: References: Message-ID: Hi Luca, On 13 February 2017 at 11:34, Luca Dionisi wrote: > This tool is not installed in the "core" snap. A run of "snap find > tcpdump" returns 0 results. > > What's my best move? Make a snap on my own and use launchpad > snap-builders to produce the one for armhf? > One option would be to enable classic [1] on the pi and install it inside that. snap install classic --edge --devmode sudo classic sudo apt update sudo apt install tcpdump [1] https://developer.ubuntu.com/core/get-started/developer-setup Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From luca.dionisi at gmail.com Mon Feb 13 13:17:28 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Mon, 13 Feb 2017 14:17:28 +0100 Subject: tcpdump armhf In-Reply-To: References: Message-ID: Yes, classic. Thanks for the reminder. --Luca On Mon, Feb 13, 2017 at 12:48 PM, Alan Pope wrote: > Hi Luca, > > On 13 February 2017 at 11:34, Luca Dionisi wrote: >> This tool is not installed in the "core" snap. A run of "snap find >> tcpdump" returns 0 results. >> >> What's my best move? Make a snap on my own and use launchpad >> snap-builders to produce the one for armhf? >> > > One option would be to enable classic [1] on the pi and install it inside that. > > snap install classic --edge --devmode > sudo classic > sudo apt update > sudo apt install tcpdump > > > [1] https://developer.ubuntu.com/core/get-started/developer-setup > > Cheers, > -- > Alan Pope > Community Manager > > Canonical - Ubuntu Engineering and Services > +44 (0) 7973 620 164 > alan.pope at canonical.com > http://ubuntu.com/ > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From jamie at canonical.com Mon Feb 13 15:40:54 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 13 Feb 2017 09:40:54 -0600 Subject: chroot into a snap In-Reply-To: <6e451f22-4555-4d3c-bf2f-30e48d462cf8@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> <0374d127-68a6-e4ff-d5b3-7916d7ffc2b7@canonical.com> <6e451f22-4555-4d3c-bf2f-30e48d462cf8@canonical.com> Message-ID: <1487000454.3367.59.camel@canonical.com> On Fri, 2017-02-10 at 14:44 +0100, Roberto Mier Escandón  wrote: > That's interesting, Simon. Good idea having available both $SNAP_DATA > and /media. We'll do. > > But now, let's back to original topic: chroot into snap. > After solving the issue Thomas found related with the path of the > document, I see now there are two operations not allowed in strict > confinement: mknod and chroot. Here is what the snappy-debug.security > log shows: > > = Seccomp = > Time: Feb 10 12:31:31 > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=31983 comm="loolkit" > exe="/snap/loolwsd/x16/usr/bin/loolforkit" sig=31 arch=c000003e > 133(mknod) compat=0 ip=0x7f6a6d6450fd code=0x0 > Syscall: mknod > This is in progress: https://github.com/snapcore/snapd/pull/2749 > = Seccomp = > Time: Feb 10 12:31:42 > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" > exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c000003e > 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 > Syscall: chroot > This may be tricky as the paths  > I've solved that by plugging docker-support and all works fine. But that > interface gives a lot of permissions, and the name maybe is not the most > accurate for a case like this. The docker-support interface should not be used for this. It is a so called 'super-privileged' interface and like you said, grants way more than is needed. > Shouldn't we have an interface allowing mknod, chroot and maybe ptrace > for snaps creating their own chroot jails?. As said, mknod is in progress. Can you file a bug for chroot? ptrace we could allow with 4.8+ kernels or if we add 'seccomp after ptrace' to the list of kernel patches for snappy. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Mon Feb 13 16:02:32 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 13 Feb 2017 10:02:32 -0600 Subject: interfaces composition In-Reply-To: <5742897f-f0c6-248a-362b-57db48c914bd@canonical.com> References: <5742897f-f0c6-248a-362b-57db48c914bd@canonical.com> Message-ID: <1487001752.3367.73.camel@canonical.com> On Mon, 2017-02-13 at 10:56 +0100, Roberto Mier Escandón  wrote: > Hey, > > Just an idea. > In my last snap I needed docker-support interface for only having access > to use mknod and chroot. Compared with the big list of permissions that > interface allows and I don't need, I wonder if we could have an internal > kind of structure of interfaces so that there are some of them which are > the composition of others. One snap could plug docker-support not > knowing that is "chroot" interface +  "ptrace" interface + whatever. > Other snap can plug chroot interface instead since doesn't need the > other stuff and so on... > In general, the security policy is the composition of interfaces. The default template plus interfaces gives you your security policy. There isn't that much overlap between the interfaces (a few seccomp calls notwithstanding, but there are some cleanups to be had there), but there is some, because interfaces are mostly meant to be standalone. The interfaces system is meant to be developer friendly and 'fine-grained enough' for the functionality that is meant to be exposed. chroot or ptrace interfaces aren't necessarily interesting on their own because we have to ask questions like 'chroot to where?' or 'ptrace what and how?' As such, we look at the desired functionality and go from there. Perhaps there is something that can be added to the template or an existing interface, perhaps it is a new interface. How that is expressed internally in snapd is an internal implementation detail, but what we expose to developers and users is very carefully considered. We did just that for the docker-support interface and it is a very special interface that is transitional and exists to make docker work at all. It's a very specific corner-case interface that allows a lot more than what is advertised. The best course of action is to file bugs and/or discuss on this list the functionality you want then the developers can figure out how to expose it. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Mon Feb 13 16:04:13 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 13 Feb 2017 10:04:13 -0600 Subject: chroot into a snap In-Reply-To: <1487000454.3367.59.camel@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> <0374d127-68a6-e4ff-d5b3-7916d7ffc2b7@canonical.com> <6e451f22-4555-4d3c-bf2f-30e48d462cf8@canonical.com> <1487000454.3367.59.camel@canonical.com> Message-ID: <1487001853.3367.74.camel@canonical.com> On Mon, 2017-02-13 at 09:40 -0600, Jamie Strandboge wrote: > On Fri, 2017-02-10 at 14:44 +0100, Roberto Mier Escandón  wrote: > >  > > = Seccomp = > > Time: Feb 10 12:31:42 > > Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" > > exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c000003e > > 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 > > Syscall: chroot > > > This may be tricky as the paths  > Whoops, this got cut off. Basically, just file a bug as I asked later. :) > > > > I've solved that by plugging docker-support and all works fine. But that > > interface gives a lot of permissions, and the name maybe is not the most > > accurate for a case like this. > The docker-support interface should not be used for this. It is a so called > 'super-privileged' interface and like you said, grants way more than is > needed. > > > > > Shouldn't we have an interface allowing mknod, chroot and maybe ptrace > > for snaps creating their own chroot jails?. > As said, mknod is in progress. Can you file a bug for chroot? > > ptrace we could allow with 4.8+ kernels or if we add 'seccomp after ptrace' to > the list of kernel patches for snappy. > > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/s > napcraft -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Mon Feb 13 16:08:04 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 13 Feb 2017 10:08:04 -0600 Subject: Problems using GLib's DBus implementation with dbus interface In-Reply-To: References: Message-ID: <1487002084.3367.75.camel@canonical.com> On Fri, 2017-02-10 at 15:34 +0800, James Henstridge wrote: > I was snapping up a D-Bus service I'm responsible for, and had it > crash with a "Bad System Call" error, and the following in the dmesg > output: > > [2054724.068967] audit: type=1326 audit(1486700103.228:2687): > auid=1000 uid=1000 gid=1000 ses=2 pid=29311 comm="mediascanner-se" > exe="/snap/mediascanner2/x1/bin/mediascanner-service-2.0" sig=31 > arch=c000003e syscall=45 compat=0 ip=0x7f28d037866d code=0x0 > > This appears to be the recvfrom system call.  The snap was configured > with a slot using the generic "dbus" interface, but not the "network" > plug.  If I add "network", the problem goes away. > > Looking at the seccomp filters for "dbus" interface definition in > snapd it allows recvmsg and sendmsg, but the D-Bus library this code > uses (GLib's GDBus) uses recvfrom() (at least it does while > initialising the connection). > > My first thought was that these extra system calls to the dbus > interface's seccomp filter.  But then I took another look at what > calls were enabled for the base policy, which showed socket(), > connect(), {get,set}sockopt, and a few others.  The only thing > preventing the default policy from creating IP sockets is the AppArmor > policy. > > Given that the default policy nominally allows communication via unix > domain sockets within a snap, I wonder if it would make sense to move > the other socket related syscalls from the network interface to the > default? > > I've created the following bug report to help track this problem: > > https://bugs.launchpad.net/snappy/+bug/1663177 FYI, James provided a PR request for this bug (thanks!) and it is committed to master and will be in snapd 2.23. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From roberto.escandon at canonical.com Mon Feb 13 16:27:39 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Mon, 13 Feb 2017 17:27:39 +0100 Subject: chroot into a snap In-Reply-To: <1487001853.3367.74.camel@canonical.com> References: <77661717-5531-7c6c-9183-2c553a6760c4@canonical.com> <34ecf5f5-cc06-eec1-5bbf-0bfb1d730d19@canonical.com> <67681a61-8a3a-d9bf-ca0d-de7166f9b80d@canonical.com> <8a199ed9-1ddf-18dc-c443-3fbe99bacdf8@canonical.com> <5c42bf7b-93d9-f7b2-1aea-e2e8342393dd@canonical.com> <0374d127-68a6-e4ff-d5b3-7916d7ffc2b7@canonical.com> <6e451f22-4555-4d3c-bf2f-30e48d462cf8@canonical.com> <1487000454.3367.59.camel@canonical.com> <1487001853.3367.74.camel@canonical.com> Message-ID: <897dd08a-a5b3-6276-9222-c51d8389b395@canonical.com> Thanks Jamie, I've reopen one [1] that I marked as invalid when I plugged docker-support. [1] https://bugs.launchpad.net/snappy/+bug/1663175 On 13/02/17 17:04, Jamie Strandboge wrote: > On Mon, 2017-02-13 at 09:40 -0600, Jamie Strandboge wrote: >> On Fri, 2017-02-10 at 14:44 +0100, Roberto Mier Escandón  wrote: >>> >>> = Seccomp = >>> Time: Feb 10 12:31:42 >>> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" >>> exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c000003e >>> 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 >>> Syscall: chroot >>> >> This may be tricky as the paths >> > Whoops, this got cut off. Basically, just file a bug as I asked later. :) > >>> >>> I've solved that by plugging docker-support and all works fine. But that >>> interface gives a lot of permissions, and the name maybe is not the most >>> accurate for a case like this. >> The docker-support interface should not be used for this. It is a so called >> 'super-privileged' interface and like you said, grants way more than is >> needed. >> >>> >>> Shouldn't we have an interface allowing mknod, chroot and maybe ptrace >>> for snaps creating their own chroot jails?. >> As said, mknod is in progress. Can you file a bug for chroot? >> >> ptrace we could allow with 4.8+ kernels or if we add 'seccomp after ptrace' to >> the list of kernel patches for snappy. >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/s >> napcraft >> >> From mathieu.trudel-lapierre at canonical.com Mon Feb 13 16:21:57 2017 From: mathieu.trudel-lapierre at canonical.com (Mathieu Trudel-Lapierre) Date: Mon, 13 Feb 2017 11:21:57 -0500 Subject: netplan and post-up/pre-down scripts In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 1:02 AM, Mike Pontillo wrote: > On Mon, Jan 16, 2017 at 7:35 AM, Mark Shuttleworth > wrote: > >> Would 'got-link' and 'lost-link' be good names for this? >> > > I'm not certain a new event name is needed for this functionality; it > seems to me that the current definition of 'up' isn't quite correct.[1] > (But all this might be a moot point depending on what is supported in > networkd, and how it behaves.) > > I understand there have been several attempts to address this in the past, > such as the 'allow-hotplug' option, ifplugd, ifupdown-extra, > NetworkManager, and now networkd. IMHO, no solution is complete unless it > properly separates adminStatus from operStatus, and holds off on confirming > "link up" until both are "up". For backward compatibility, a boolean flag > (similar to "allow-hotplug") should indicate whether or not the system is > allowed to continue booting if the interface is down.[2] > I agree booting should continue for any device that is down even if it's configured and marked as fine to still be down. I think rather than trying to skip a long delay that would happen in some other cases, we should revisit whether it makes sense for it to take 5 minutes; or even make this configurable. 5 minutes is a lot; 1 minute is acceptable in many configurations, 30 seconds is ideal in some. All this only makes sense for DHCP-configured interfaces where the link is up but no DHCP response has been received. If the link is down, there is no point in ever waiting. This may need fixed in networkd and NM to allow configuring the DHCP timeout. I do not know that any of the different network management tools were planned to address administrative status of an interface. It may even in fact require kernel work (I haven't looked yet) to allow its state to be set to administratively down. Please file a bug about this. I'll review and look how we can specify this in netplan, and how we can drive it in the various backends... But I expect it will require work in both networkd and NetworkManager before it does work correctly. Servers aren't typically used in such a way, and setting that option seems like it might be quite intrusive (I mean, of course the default wouldn't be for interfaces to be administratively down, but I can see issues coming up from it. One of them is how to do it in the first place, and another is that it would only happen once the renderer (networkd/NM) is up and running, so potentially you've already sent/received packets on the interfaces... ideally, that shouldn't happen, but maybe I'm overthinking it). > > Another subtle detail is that if an interface is administratively down, > there should be an option to cause the NIC to take its physical link down. > That way, whatever is on the other side of the link doesn't assume its peer > is active. (This is standard behavior on a router or a switch, but may be > atypical for a server... so I think the default behavior should continue be > "leave the physical link up".) > Of course. If something is administratively down, we must think of it in terms of *powered down*. Otherwise it's simply not configured. / Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Mon Feb 13 17:13:08 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Mon, 13 Feb 2017 18:13:08 +0100 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: References: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> <0dc231f8-26fc-d929-faef-7f28e1b8850d@ubuntu.com> Message-ID: <0afec719-2791-b5cd-e138-0d0a68d0b412@ubuntu.com> Le 10/02/2017 à 17:30, Simos Xenitellis a écrit : > On Tue, Feb 7, 2017 at 3:54 PM, Didier Roche wrote: >> Le 07/02/2017 à 14:05, Simos Xenitellis a écrit : >>> On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche wrote: >>>> Le 06/02/2017 à 10:56, Simos Xenitellis a écrit : >>>>> Hi All, >>>>> >>>>> I wrote an article about creating a snap for an existing Python >>>>> program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu >>>>> Store. >>>>> >>>>> I am looking forward to receiving feedback :-) >>>>> >>>>> Link: https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ >>>>> >>>>> Link to HN submission: https://news.ycombinator.com/item?id=13578034 >>>>> >>>>> Simos >>>>> >>>> Excellent work Simos! >>>> >>>> I think this kind of content would make an excellent official "pratical" >>>> tutorials on https://tutorials.ubuntu.com. Are you interested into >>>> contributing there? >>>> >>>> If you want more context on tutorials, the phisolophy and how to >>>> contribute, I wrote a blog post some time ago about it: >>>> https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/. >>>> >>>> I'm also available for any help, >>> Thanks Didier! >>> >>> I had a look at https://github.com/ubuntudesign/tutorials.ubuntu.com/issues >>> and the direction that tutorials.ubuntu.com wants to take. It looks good. >>> It requires planning in terms of the writing of the tutorials so that >>> they are gradually incremental, >>> and some basic tutorials can referenced by the more complex ones. It's >>> a lot of dedicated work. >>> >>> I'll give it a go and try to write a couple of tutorials for >>> tutorials.ubuntu.com. We will see how it goes :-) >>> I think I'll start with the baseline tutorial for snapcraft. >> Excellent news! >> You can as well convert some of yours to this format! I give you the >> direct link to the guidelines to have some coherences between the >> tutorials in term of tones and content: >> https://docs.google.com/document/d/1u5qmSNIcE8SjuAg6aKjTxOBGWIjBW0kYf01t4Dfw6-U/edit. >> > I managed to complete the conversion and the tutorial is ready :-). > > Here it is, > https://docs.google.com/document/d/1Nk-kw79lt84YJNEKS_WpnGzVSjrmCUVd1TsAx5aRoOA/ > Feel free to add to tutorials.ubuntu.com or make a copy in order to edit. > > Overall, the experience in converting to the format required by > codelabs was interesting. > I still need more practice before I would be able to write a tutorial > in one go in the codelab style. This really looks awesome! Thanks Simos :) I'll add some very small tweaking, but after a first look, it's very a nice first shot. Well done :) I would be interested in any comment you have about the codelab format and style, and anything you liked/didn't like. I'll keep you posted with a diff so that you can see what small modifications I made to be more coherent with the other ones. If you have any other to do, do not hesitate to keep us posted! Cheers, Didier From jamie at canonical.com Tue Feb 14 00:01:14 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 13 Feb 2017 18:01:14 -0600 Subject: vlc mpris In-Reply-To: References: <420c3cb2-3411-5180-aa5e-7814151e171f@gmail.com> Message-ID: <1487030474.3367.111.camel@canonical.com> On Mon, 2017-02-13 at 15:30 +0800, James Henstridge wrote: > On 13 February 2017 at 15:02, Vasilisc wrote: > > > > How to allow vlc - "org.mpris.MediaPlayer2.vlc.instance*" ??? > > > > [0xd5f358] dbus interface error: Error requesting service name > > org.mpris.MediaPlayer2.vlc.instance3045: Connection ":1.69" is not allowed > > to own the service "org.mpris.MediaPlayer2.vlc.instance3045" due to AppArmor > > policy > > > > ------------------------------ > > I don't see interfaces dbus|mpris > > > > # LANG=C apt policy snapd > > snapd: > >   Installed: 2.21 > >   Candidate: 2.21 > >   Version table: > >  *** 2.21 500 > >         500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 > > Packages > >         100 /var/lib/dpkg/status > >      2.0.2 500 > >         500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages > > > > # snap interfaces | grep -E "(dbus|mpris)" > > # > You should be able to do this by adding a slot to your snap using the > "mpris" interface.  Something like this: > > slots: >   mpris: >     interface: mpris >     name: vlc > > Then make sure the app inside your snap uses this slot. > > This interface looks like it will work okay for the mpris provider, > and okay for unconfined mpris clients on classic systems. Correct > It's not > clear how you'd write a confined client that could act as a remote for > all installed players without defining many duplicate plugs.  If > you're only interested in use on classic systems though, this should > be good enough though. It works kind of like the dbus interface but is a bit simpler. It is documented here: https://github.com/snapcore/snapd/wiki/Interfaces#mpris Specifically if the providing snap has: name: vlc apps:   vlc:     slots: [mpris] then vlc is allowed to bind to the DBus well-known name 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: name: foo-vlc-controller apps:   foo-vlc-controller:     plugs: [ mpris ] then can be connected with: $ sudo snap connect foo-vlc-controller:mpris vlc:mpris The interface has some flexibility for when you want to use something different than the snap's name in the DBus well-known name. Eg, if the providing snap has: name: forked-vlc slots:   mpris:     interface: mpris # this line not needed since iface name == slot ref     name: vlc then forked-vlc is allowed to bind to the DBus well-known name 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: name: foo-vlc-controller apps:   foo-vlc-controller:     plugs: [ mpris ] Then on install they can be connected with: $ sudo snap connect foo-vlc-controller:mpris forked-vlc:mpris Notice that foo-vlc-controller doesn't care about what is on the other end (vlc, vs forked-vlc vs rhythmbox vs whatever) and it can be connected to multiple slot implementations. This is the beauty of interfaces and how they can be thought of as 'contracts' between slots and plugs. Hope this helps! -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kyle.nitzsche at canonical.com Tue Feb 14 00:57:28 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Mon, 13 Feb 2017 19:57:28 -0500 Subject: Exposing dbus interface and using it inside the same snap In-Reply-To: References: Message-ID: <6c5f06f8-a066-4f29-2719-7d2931c223f0@canonical.com> Hi Jamie, Can you please point out the error in the below? I believe he is getting an error like this (perhaps truncated): Feb 13 19:33:07 ubuntu snap[3207]: GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.49" is not allowed to own the service "com.screenly.playlist" due to security policies in the c Feb 13 19:33:07 ubuntu snap[3207]: 0, timeout_to_glib(timeout), None).unpack() thanks, kyleN On 02/10/2017 12:35 PM, Sergey Borovkov wrote: > Hi, I've been struggling with getting dbus interface exposed. I am > getting this error during runtime: > GLib.Error: g-dbus-error-quark: > GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection > ":1.1160" is not allowed to own the service "com.screenly.playlist" due > to security policies in the configuration file (9) > > jdstrand helped me on IRC, and told me I need to have a slot and a plug > in my snap. I am doing something wrong though, can someone help out with > how it's correctly supposed to be used? > > apps: > playlist: > command: usr/bin/playlist-service.sh > daemon: simple > plugs: [network-bind, network, playlist-dbus] > > websocket: > command: usr/bin/websocket-service.sh > daemon: simple > plugs: [network-bind, network, dbus] > slots: [websocket-dbus] > > slots: > playlist-dbus: > interface: dbus > name: com.screenly > bus: system > > plugs: > websocket-dbus: > interface: dbus > name: com.screenly > bus: system > > From andrew.wilkins at canonical.com Tue Feb 14 01:59:37 2017 From: andrew.wilkins at canonical.com (Andrew Wilkins) Date: Tue, 14 Feb 2017 01:59:37 +0000 Subject: ANN: llgo classic snap Message-ID: Hi folks, A while ago I snapped llgo, the Go frontend for LLVM. At the time, classic snaps were not a thing, and so the snap had limited functionality. I've updated it to use classic confinement, so you can use the compiler toolchain as you would normally. $ sudo snap install --classic llgo $ llgo version go version go1.5.1 llgo version 5.0.0 (go1.4.2) linux/amd64 $ llgo run ... The llgo interpreter is still available, but as it is part of the same snap it is no longer confined: $ llgo.llgoi (llgo) import "fmt" (llgo) fmt.Println("hello, world") hello, world 13 I have also exposed the llgo compiler as "llgo.compiler", so you can generate LLVM IR, for example: $ llgo.compiler -emit-llvm -S -o - main.go ; ModuleID = 'main' source_filename = "main" target datalayout ... Cheers, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Tue Feb 14 02:53:47 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 14 Feb 2017 10:53:47 +0800 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1485945076.25932.40.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> Message-ID: Hi, Today, I just followed the instructions at: https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/reference/core-configuration.md to disable ssh. However, I got the error like: liu-xiao-guo at localhost:~$ sudo snap set core service.ssh.disable=true error: cannot perform the following tasks: - Run configure hook of "core" snap (/snap/core/1177/meta/hooks/configure: 62: /snap/core/1177/meta/hooks/configure: systemctl: Permission denied) Is this a bug? It was tested on Raspberry Pi2 device, and my core system info is like: liu-xiao-guo at localhost:~$ snap version snap 2.23~201702101018.git.979009c~ubuntu16.04.1 snapd 2.23~201702101018.git.979009c~ubuntu16.04.1 series 16 liu-xiao-guo at localhost:~$ snap info core name: core summary: "snapd runtime environment" publisher: canonical description: | The core runtime environment for snapd type: core tracking: edge installed: 16.04.1 (1177) 68MB - refreshed: 2017-02-13 04:42:55 +0000 UTC channels: stable: 16.04.1 (893) 67MB - candidate: 16.04.1 (1083) 68MB - beta: 16.04.1 (1083) 68MB - edge: 16.04.1 (1177) 68MB - Thanks & best regards, xiaoguo On Wed, Feb 1, 2017 at 6:31 PM, Oliver Grawert wrote: > hi, > > after we recently added a config hook [1] to the core snap it is now > possible to disable ssh if you require [2] ... > > there is a long standing request to do the same for syslog for systems > running from SD card, which is why i looked into trying to extend the > existing configure script for this, which made me notice some issue... > > when you call "snap set core foo=bar", there is no indication at all > for the script which variable changes a value, neither in the shell > environment nor in the argument list. > > the only way to get your value is to call snapctl for every existing > variable [3]. since you dont know what specific variable was requested > to change the only way to reliably write it is to write *all* existing > variables ... > > now, if you package something with a more complex config that you want > completely handled via snap config this gets ugly very fast... imagine > something like postfix with can potentially have 100s of config > options. instead of atomically changing a single option you will > regenerate the full config from scratch. this takes a lot longer, > bringing the risk of a completely broken config in case of a power > loss, beyond resulting an an awful config hook script with a large > block of "snapctl get" calls at the top. > > can we extend the config hook implementation minimally so a "snap set > core foo=bar" would at least have something like "SNAP_OPTION=foo" in > the environment that the generating script or binary could read to > avoid the unnecessary processing or would that break some design > concept ? > > ciao > oli > > [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/ > hooks/configure > [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref > erence/core-configuration.md > [3] https://github.com/snapcore/snapd/wiki/hooks > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at jamesh.id.au Tue Feb 14 03:13:32 2017 From: james at jamesh.id.au (James Henstridge) Date: Tue, 14 Feb 2017 11:13:32 +0800 Subject: vlc mpris In-Reply-To: <1487030474.3367.111.camel@canonical.com> References: <420c3cb2-3411-5180-aa5e-7814151e171f@gmail.com> <1487030474.3367.111.camel@canonical.com> Message-ID: On 14 February 2017 at 08:01, Jamie Strandboge wrote: > On Mon, 2017-02-13 at 15:30 +0800, James Henstridge wrote: >> On 13 February 2017 at 15:02, Vasilisc wrote: >> > >> > How to allow vlc - "org.mpris.MediaPlayer2.vlc.instance*" ??? >> > >> > [0xd5f358] dbus interface error: Error requesting service name >> > org.mpris.MediaPlayer2.vlc.instance3045: Connection ":1.69" is not allowed >> > to own the service "org.mpris.MediaPlayer2.vlc.instance3045" due to AppArmor >> > policy >> > >> > ------------------------------ >> > I don't see interfaces dbus|mpris >> > >> > # LANG=C apt policy snapd >> > snapd: >> > Installed: 2.21 >> > Candidate: 2.21 >> > Version table: >> > *** 2.21 500 >> > 500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 >> > Packages >> > 100 /var/lib/dpkg/status >> > 2.0.2 500 >> > 500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages >> > >> > # snap interfaces | grep -E "(dbus|mpris)" >> > # >> You should be able to do this by adding a slot to your snap using the >> "mpris" interface. Something like this: >> >> slots: >> mpris: >> interface: mpris >> name: vlc >> >> Then make sure the app inside your snap uses this slot. >> >> This interface looks like it will work okay for the mpris provider, >> and okay for unconfined mpris clients on classic systems. > > Correct > >> It's not >> clear how you'd write a confined client that could act as a remote for >> all installed players without defining many duplicate plugs. If >> you're only interested in use on classic systems though, this should >> be good enough though. > > It works kind of like the dbus interface but is a bit simpler. It is documented > here: > https://github.com/snapcore/snapd/wiki/Interfaces#mpris > > > Specifically if the providing snap has: > > name: vlc > apps: > vlc: > slots: [mpris] > > then vlc is allowed to bind to the DBus well-known name > 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: > > name: foo-vlc-controller > apps: > foo-vlc-controller: > plugs: [ mpris ] > > then can be connected with: > $ sudo snap connect foo-vlc-controller:mpris vlc:mpris > > > The interface has some flexibility for when you want to use something different > than the snap's name in the DBus well-known name. Eg, if the providing snap has: > > name: forked-vlc > slots: > mpris: > interface: mpris # this line not needed since iface name == slot ref > name: vlc > > then forked-vlc is allowed to bind to the DBus well-known name > 'org.mpris.MediaPlayer2.vlc'. Plugging snaps do: > > name: foo-vlc-controller > apps: > foo-vlc-controller: > plugs: [ mpris ] > > Then on install they can be connected with: > $ sudo snap connect foo-vlc-controller:mpris forked-vlc:mpris > > > Notice that foo-vlc-controller doesn't care about what is on the other end (vlc, vs forked-vlc vs rhythmbox vs whatever) and it can be connected to multiple slot implementations. This is the beauty of interfaces and how they can be thought of as 'contracts' between slots and plugs. I can see how that works if I want to act as an mpris remote for one player. But what happens when we install a second player app and want to be able to control it as well? As I understand it, a plug can only connect to a single slot, so I'd need to define extra plugs: plugs: mpris1: interface: mpris mpris2: interface: mpris ... If I wanted to be able to act as a control for any running player (as indicator-sound does, for instance), then I'd have to hope I defined enough plugs. And that ignores the headaches of connecting everything up after installation. We're facing a similar problem with storage-framework too, where there can be multiple clients and multiple providers. We'll probably solve it there by adding an intermediary between clients and providers (which hasn't yet been started), but it did stand out as another case of many-to-many communication that doesn't neatly fit into snapd's interface model. James. From aaron.hampt at gmail.com Tue Feb 14 03:51:54 2017 From: aaron.hampt at gmail.com (Aaron Hampton) Date: Mon, 13 Feb 2017 22:51:54 -0500 Subject: Is there a way to prompt users to connect a non-auto-connect interface during installation? In-Reply-To: <3b33b740-b356-9954-4b27-b6a2c58c9131@canonical.com> References: <3b33b740-b356-9954-4b27-b6a2c58c9131@canonical.com> Message-ID: Is it possible to check which interfaces a snap is connected to from within the snap? Or, would I have to try accessing the resources an interface exposes to know whether or not it had access? I tried calling snap interfaces from within my program, but I got a permissions error. On Feb 13, 2017 1:50 AM, "Alberto Mardegan" wrote: > On 12/02/2017 12:30, Aaron Hampton wrote: > > Hi, > > > > I am working on snapping a desktop application that needs access to > > hardware-observe. Is there a way to prompt the user to connect the > > interface during the installation of the snap? Or is the only way to > > have the user run snap connect? > > While this feature is missing, you could wrap your programs in a shell > script that checks whether the needed permissions are there and, if not, > print a message using zenity to inform the user. > > Ciao, > Alberto > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Tue Feb 14 04:04:41 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 14 Feb 2017 12:04:41 +0800 Subject: Issue with ubuntu OS snap first time boot. In-Reply-To: References: Message-ID: Today, I had the same problem. I downloaded the Raspberry Pi3 image at: http://cdimage.ubuntu.com/ubuntu-core/16/stable/ The date is: ubuntu-core-16-pi3.img.xz 2017-01-26 20:29316M ------------------------------ After I flashed it, I had the same issue as described in the above email. Attached please find the captured picture. The old image in the Ubuntu Core could not boot, and it stopped at "booting kernel". I thought it was an old image flashed long time ago. I decided to take the new one. Thanks & best regards, XiaoGuo On Tue, Jan 10, 2017 at 9:35 PM, Ajay Pandey wrote: > Hi All, > > > > We are facing issue with the Ubuntu OS snap first time boot console-conf. > > > > We have generated the id_rsa.pub key and put it in the launchpad.net as > well as the login.ubuntu.com profiles. > > > > Please find below the error that we are getting: > > > > > > > > > > > > > > > > > > > > > > > > *Profile setup > Enter an email address from your account in the store. > Email address: xyz at gmail.com > (example) If you do not have an > account, visit https://login.ubuntu.com > to create one. > Creating user failed: > error: while creating user: cannot communicate with server: > Post http://localhost/v2/create-user > : EOF > > Contacting > store... [ > Done ] [ Cancel ] > 40 %* > ************************************************************ > ************************************************************ > ************************************* eInfochips Business Disclaimer: > This e-mail message and all attachments transmitted with it are intended > solely for the use of the addressee and may contain legally privileged and > confidential information. If the reader of this message is not the intended > recipient, or an employee or agent responsible for delivering this message > to the intended recipient, you are hereby notified that any dissemination, > distribution, copying, or other use of this message or its attachments is > strictly prohibited. If you have received this message in error, please > notify the sender immediately by replying to this message and please delete > it from your computer. Any views expressed in this message are those of the > individual sender unless otherwise stated. Company has taken enough > precautions to prevent the spread of viruses. However the company accepts > no liability for any damage caused by any virus transmitted by this email. > ************************************************************ > ************************************************************ > ************************************* > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_20170214_115701.jpg Type: image/jpeg Size: 4199999 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_20170214_115653.jpg Type: image/jpeg Size: 3606298 bytes Desc: not available URL: From woodrow.shen at canonical.com Tue Feb 14 05:04:13 2017 From: woodrow.shen at canonical.com (Woodrow Shen) Date: Tue, 14 Feb 2017 13:04:13 +0800 Subject: Porting Ubuntu-Core In-Reply-To: References: Message-ID: Hi all, As I used new ubuntu-image (0.14+real1) to create my armhf image, I also got the same error as well. In order to try to fit the new spec of gadget.yaml, I modified the gadget.yaml as follows: device-tree: actduino_bubble_gum_sdboot_linux.dtb volumes: roseapple-pi: schema: mbr bootloader: u-boot structure: - name: bootloader size: 4M content: - image: bootloader.bin offset: 2097664 #4097*512 - image: u-boot.bin offset: 3145728 #6144*512 type: bare - name: system-boot type: 0C filesystem: vfat filesystem-label: system-boot offset: 8388608 size: 128M content: - source: boot-assets/ target: / And then this can avoid above the error during image creation. However, the generated image lost the content of bootloader.bin & u-boot.bin at the specific offset. So I think it may not follow the correct spec of gadget.yaml. Can anyone help us to resolve the problem? Thanks. Regards, Woodrow On Wed, Dec 21, 2016 at 11:15 AM, Bo Dong wrote: > Hi Guys, > > We're now porting Ubuntu Core to an ARM64 on-chip computer, Bubblegum-96 > board. (http://www.96boards.org/product/bubblegum-96/) > Here are some issues we got. > > When using ubuntu-image (tag:0.10+real 1 stable), > > *$ sudo /snap/bin/ubuntu-image --channel stable --image-size 2G > --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps > bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model* > > it could make valid image,bubblegum96.img. > > After update ubuntu-image using command *$ sudo snap refresh --beta > --devmode ubuntu-image*, the ubuntu-image will be updated to beta (tag: > 0.12+real 1). We using command > > $ sudo /snap/bin/ubuntu-image --channel beta --image-size 2G --extra-snaps > bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps > bubblegum96-kernel_3.10.0_arm6*4.snap -o bubblegum96.img > bubblegum96.model *again, and it will report failure. It shows "gadget.yaml > parse error: mbr structures cannot be larger than 446 bytes." > > The gadget.yaml file is the same before and after update ubuntu-image. > Here it is: > $ cat gadget.yaml > device-tree: s900-96board.dtb > volumes: > lemaker-guitar: > schema: mbr > bootloader: u-boot > structure: > - name: Bootstrap > type: mbr > size: 8M > content: > - image: bootloader.bin > offset: 2097664 > - image: u-boot.bin > offset: 3145728 > - type: 0C > filesystem: vfat > filesystem-label: system-boot > offset: 8388608 > size: 128M > content: > - source: boot-assets/ > target: / > > If we change the size: 8M directly to size:440, the image we made will be > useless. Actually I don't know how to config offset after change the size. > > If we change the schema: mbr directly to schema: gpt, and change the type: > mbr to type: gpt, it will fail again, and shows "gadget.yaml parse error: > Invalid gadget.yaml @ volumes:lemaker-guitar:structure:0:type" > > I'd appreciate it a lot if there is anyone could help us with this. > > Thanks&&Best Regards > > > > -- > 董波 > uCRobotic > Mobile: +86 15624957162 <+86%20156%202495%207162> > > http://www.ucrobotics.com.cn/ > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- Woodrow Shen Software Engineer, Canonical ltd. Devices | CE | Delivery, Taipei -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Tue Feb 14 05:05:37 2017 From: vasilisc777 at gmail.com (=?UTF-8?B?0JLQsNGB0LjQu9C40Lkg0JDQu9C10LrRgdC10LXQvdC60L4=?=) Date: Tue, 14 Feb 2017 08:05:37 +0300 Subject: solution for "only-english UI" Message-ID: I found solution for only-english UI. https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282 Oliver Grawert (ogra) wrote on 2016-06-09: "help2man ships a little hack (http://paste.ubuntu.com/16923611/) to preload a modified bindtextdomain() over the original one ... while this is ugly, it actually seems to work ... http://paste.ubuntu.com/16925059/" Thx Oliver! From xiaoguo.liu at canonical.com Tue Feb 14 06:37:03 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 14 Feb 2017 14:37:03 +0800 Subject: Issue with ubuntu OS snap first time boot. In-Reply-To: References: Message-ID: It is bad that i cannot console-conf my Pi device for many times. Attached please find my syslog taken from the SD card. Can anyone help me? Now, it always times out after contacting store. Thanks & best regards, xiaoguo On Tue, Feb 14, 2017 at 12:04 PM, XiaoGuo Liu wrote: > Today, I had the same problem. I downloaded the Raspberry Pi3 image at: > > http://cdimage.ubuntu.com/ubuntu-core/16/stable/ > > The date is: ubuntu-core-16-pi3.img.xz > > 2017-01-26 20:29316M > ------------------------------ > > After I flashed it, I had the same issue as described in the above email. > Attached please find the captured picture. > > The old image in the Ubuntu Core could not boot, and it stopped at > "booting kernel". I thought it was an old image flashed long time ago. I > decided to take the new one. > > Thanks & best regards, > XiaoGuo > > > > On Tue, Jan 10, 2017 at 9:35 PM, Ajay Pandey > wrote: > >> Hi All, >> >> >> >> We are facing issue with the Ubuntu OS snap first time boot console-conf. >> >> >> >> We have generated the id_rsa.pub key and put it in the launchpad.net as >> well as the login.ubuntu.com profiles. >> >> >> >> Please find below the error that we are getting: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *Profile setup >> Enter an email address from your account in the store. >> Email address: xyz at gmail.com >> (example) If you do not have an >> account, visit https://login.ubuntu.com >> to create one. >> Creating user failed: >> error: while creating user: cannot communicate with server: >> Post http://localhost/v2/create-user >> : EOF >> >> Contacting >> store... [ >> Done ] [ Cancel ] >> 40 %* >> ************************************************************ >> ************************************************************ >> ************************************* eInfochips Business Disclaimer: >> This e-mail message and all attachments transmitted with it are intended >> solely for the use of the addressee and may contain legally privileged and >> confidential information. If the reader of this message is not the intended >> recipient, or an employee or agent responsible for delivering this message >> to the intended recipient, you are hereby notified that any dissemination, >> distribution, copying, or other use of this message or its attachments is >> strictly prohibited. If you have received this message in error, please >> notify the sender immediately by replying to this message and please delete >> it from your computer. Any views expressed in this message are those of the >> individual sender unless otherwise stated. Company has taken enough >> precautions to prevent the spread of viruses. However the company accepts >> no liability for any damage caused by any virus transmitted by this email. >> ************************************************************ >> ************************************************************ >> ************************************* >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > XiaoGuo, Liu > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: syslog Type: application/octet-stream Size: 168299 bytes Desc: not available URL: From serge.borovkov at gmail.com Tue Feb 14 06:44:18 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Tue, 14 Feb 2017 09:44:18 +0300 Subject: Exposing dbus interface and using it inside the same snap In-Reply-To: <6c5f06f8-a066-4f29-2719-7d2931c223f0@canonical.com> References: <6c5f06f8-a066-4f29-2719-7d2931c223f0@canonical.com> Message-ID: Hi, I am using this code: apps: playlist: command: usr/bin/playlist-service.sh daemon: simple plugs: [network-bind, network] slots: [playlist-dbus-server] websocket: command: usr/bin/websocket-service.sh daemon: simple plugs: [network-bind, network, playlist-dbus-client] slots: playlist-dbus-server: interface: dbus name: com.screenly.playlist bus: system plugs: playlist-dbus-client: interface: dbus name: com.screenly.playlist bus: system After doing snap installl --devmode screenly.snap snapd prints out this error: 2017-02-13T21:48:28Z INFO snap "screenly-client" has bad plugs or slots: dbus (cannot find attribute 'bus') All of this happens with snapd from the proposed repository: root at ubuntu:/home/ubuntu# snap --version snap 2.22.2 snapd 2.22.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.pontillo at canonical.com Tue Feb 14 08:19:01 2017 From: mike.pontillo at canonical.com (Mike Pontillo) Date: Tue, 14 Feb 2017 00:19:01 -0800 Subject: netplan and post-up/pre-down scripts In-Reply-To: References: Message-ID: On Mon, Feb 13, 2017 at 8:21 AM, Mathieu Trudel-Lapierre < mathieu.trudel-lapierre at canonical.com> wrote: > I agree booting should continue for any device that is down even if it's > configured and marked as fine to still be down. I think rather than trying > to skip a long delay that would happen in some other cases, we should > revisit whether it makes sense for it to take 5 minutes; or even make this > configurable. 5 minutes is a lot; 1 minute is acceptable in many > configurations, 30 seconds is ideal in some. All this only makes sense for > DHCP-configured interfaces where the link is up but no DHCP response has > been received. If the link is down, there is no point in ever waiting. This > may need fixed in networkd and NM to allow configuring the DHCP timeout. > Yes; perhaps even a kernel parameter would be good. That way it could be customized depending on the purpose of the deployment. For example, I might want a 1-minute wait time before declaring interfaces "up" if I'm deploying a high availability web proxy with multiple bonded interfaces. Or I might want it to not wait at all if I'm deploying a network infrastructure device, where I would expect that the interface configuration needs to be flexible enough to never prevent me from booting the system. (Though in general I still think we should move toward eliminating the timeout altogether as a long-term goal, though I realize that may be somewhat idealistic.) I do not know that any of the different network management tools were > planned to address administrative status of an interface. It may even in > fact require kernel work (I haven't looked yet) to allow its state to be > set to administratively down. > In my (very limited) testing, I can do something like "ip link set dev " and when I look at "ethtool " I see "Link detected: ". (But I'm not sure what the initial state of the interface is before ifupdown touches it.) > Please file a bug about this. I'll review and look how we can specify this > in netplan, and how we can drive it in the various backends... But I expect > it will require work in both networkd and NetworkManager before it does > work correctly. Servers aren't typically used in such a way, and setting > that option seems like it might be quite intrusive (I mean, of course the > default wouldn't be for interfaces to be administratively down, but I can > see issues coming up from it. One of them is how to do it in the first > place, and another is that it would only happen once the renderer > (networkd/NM) is up and running, so potentially you've already > sent/received packets on the interfaces... ideally, that shouldn't happen, > but maybe I'm overthinking it). > Right; it might make a difference what the initial state of the interface is (before ifupdown, networkd, or NetworkManager take control of it). I'm pretty sure I've observed ifupdown bringing interfaces online, and leaving interfaces offline if they aren't mentioned in /etc/network/interfaces (but I'd have to double check the initial state of the interface). So it might be that this is already happening, at least to some extent. But I agree; ideally the service which renders the network configuration will bring the interfaces online, to avoid the link coming up before it's ready. (But if we were to iterate on this, I would say that the interface coming up in a 'default up' state for a short time would be a small price to pay on the path toward getting this right.) I'll sleep on it and try to get a bug filed tomorrow. Of course. If something is administratively down, we must think of it in > terms of *powered down*. Otherwise it's simply not configured. > Indeed, from the user perspective, it should seem to be powered down (in that if an Ethernet cable is connected which would otherwise show a link light, you would see nothing appear to happen). I think setting the interface link down should be enough to accomplish that; hopefully the driver would know that it could be placed into a power save mode or similar. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From federico.gimenez.nieto at canonical.com Tue Feb 14 09:17:00 2017 From: federico.gimenez.nieto at canonical.com (Federico Gimenez) Date: Tue, 14 Feb 2017 10:17:00 +0100 Subject: Getting involved with the snapd project Message-ID: Hi, Ever wanted to get involved with snapd development but didn't know where to start? Well, in order to make it easier we have recently created a new "Getting involved" section in the snapd wiki [1] with a list of pending tasks that can be picked by anyone willing to help. So far the list includes mainly tests but the team will continue to put more general tasks in there over time. To begin working with any of these tasks just put your github user in the "Assignee" column, drop us a line using any of the communication methods described in [2] and start working on the task! Do not hesitate to contact us in case you need any help during development and we will happily give you support to get it done. Happy hacking! The snapd team. [1] https://github.com/snapcore/snapd/wiki/Getting-involved [2] https://github.com/snapcore/snapd/wiki/Get-in-touch -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge.borovkov at gmail.com Tue Feb 14 09:40:19 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Tue, 14 Feb 2017 12:40:19 +0300 Subject: Exposing dbus interface and using it inside the same snap In-Reply-To: References: <6c5f06f8-a066-4f29-2719-7d2931c223f0@canonical.com> Message-ID: Nvm guys, I figured it out. On 14 February 2017 at 09:44, Sergey Borovkov wrote: > Hi, I am using this code: > > apps: > playlist: > command: usr/bin/playlist-service.sh > daemon: simple > plugs: [network-bind, network] > slots: [playlist-dbus-server] > > websocket: > command: usr/bin/websocket-service.sh > daemon: simple > plugs: [network-bind, network, playlist-dbus-client] > > slots: > playlist-dbus-server: > interface: dbus > name: com.screenly.playlist > bus: system > > plugs: > playlist-dbus-client: > interface: dbus > name: com.screenly.playlist > bus: system > > After doing snap installl --devmode screenly.snap snapd prints out this > error: > 2017-02-13T21:48:28Z INFO snap "screenly-client" has bad plugs or slots: > dbus (cannot find attribute 'bus') > > All of this happens with snapd from the proposed repository: > > root at ubuntu:/home/ubuntu# snap --version > snap 2.22.2 > snapd 2.22.2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Tue Feb 14 09:45:47 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 14 Feb 2017 10:45:47 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: References: <1485945076.25932.40.camel@ubuntu.com> Message-ID: <1487065547.11948.119.camel@ubuntu.com> hi, Am Dienstag, den 14.02.2017, 10:53 +0800 schrieb XiaoGuo Liu: > Hi, > > Today, I just followed the instructions at: > > https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/refer > ence/core-configuration.md > > to disable ssh. However, I got the error like: > > liu-xiao-guo at localhost:~$ sudo snap set core service.ssh.disable=true > error: cannot perform the following tasks: > - Run configure hook of "core" snap > (/snap/core/1177/meta/hooks/configure: 62: > /snap/core/1177/meta/hooks/configure: systemctl: Permission denied) > > Is this a bug? It was tested on Raspberry Pi2 device, and my core > system info is like: hmm, works fine on my pi2 install ... ogra at localhost:~$ snap set core service.ssh.disable=true ogra at localhost:~$ snap set core service.ssh.disable=false ogra at localhost:~$  line 62 calls: "systemctl disable ssh.service" do you get the same error if you call the above (with sudo) manually ? could your SD card be full or have errors (and thus be mounted readonly) ? also check if the core-support interface is properly connected (it should auto-connect, this would definitely be a bug): ogra at localhost:~$ snap interfaces |grep core :core-support                 core ogra at localhost:~$  ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From xiaoguo.liu at canonical.com Tue Feb 14 09:59:00 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 14 Feb 2017 17:59:00 +0800 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1487065547.11948.119.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <1487065547.11948.119.camel@ubuntu.com> Message-ID: Hi Ciao, Thanks! I just upgraded it to edge channel, and now it works as expected. liu-xiao-guo at localhost:~$ snap set core service.ssh.disable=true liu-xiao-guo at localhost:~$ sudo snap set core service.ssh.disable=true liu-xiao-guo at localhost:~$ snap set core service.ssh.disable=true liu-xiao-guo at localhost:~$ snap set core service.ssh.disable=false liu-xiao-guo at localhost:~$ snap interfaces |grep core :core-support core I think the problem could be that the stable channel does not support it. Best regards, XiaoGuo On Tue, Feb 14, 2017 at 5:45 PM, Oliver Grawert wrote: > hi, > Am Dienstag, den 14.02.2017, 10:53 +0800 schrieb XiaoGuo Liu: > > Hi, > > > > Today, I just followed the instructions at: > > > > https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/refer > > ence/core-configuration.md > > > > to disable ssh. However, I got the error like: > > > > liu-xiao-guo at localhost:~$ sudo snap set core service.ssh.disable=true > > error: cannot perform the following tasks: > > - Run configure hook of "core" snap > > (/snap/core/1177/meta/hooks/configure: 62: > > /snap/core/1177/meta/hooks/configure: systemctl: Permission denied) > > > > Is this a bug? It was tested on Raspberry Pi2 device, and my core > > system info is like: > > hmm, works fine on my pi2 install ... > > ogra at localhost:~$ snap set core service.ssh.disable=true > ogra at localhost:~$ snap set core service.ssh.disable=false > ogra at localhost:~$ > > line 62 calls: "systemctl disable ssh.service" > do you get the same error if you call the above (with sudo) manually ? > > could your SD card be full or have errors (and thus be mounted > readonly) ? > > also check if the core-support interface is properly connected (it > should auto-connect, this would definitely be a bug): > > ogra at localhost:~$ snap interfaces |grep core > :core-support core > ogra at localhost:~$ > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Tue Feb 14 10:08:33 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 14 Feb 2017 11:08:33 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: References: <1485945076.25932.40.camel@ubuntu.com> <1487065547.11948.119.camel@ubuntu.com> Message-ID: <1487066913.11948.129.camel@ubuntu.com> hi, Am Dienstag, den 14.02.2017, 17:59 +0800 schrieb XiaoGuo Liu: >  > I think the problem could be that the stable channel does not support > it. > yes, this is definitely the case, this was not released to stable yet, the next stable release will have it.  ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Tue Feb 14 12:23:04 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 14 Feb 2017 09:23:04 -0300 Subject: Currernt config hook implementation scales very badly In-Reply-To: <1487066913.11948.129.camel@ubuntu.com> References: <1485945076.25932.40.camel@ubuntu.com> <1487065547.11948.119.camel@ubuntu.com> Message-ID: <93559d06-55d6-48a7-92f6-692af0fa5d3b@canonical.com> El martes, 14 de febrero de 2017 07h'08:33 ART, Oliver Grawert escribió: > hi, > Am Dienstag, den 14.02.2017, 17:59 +0800 schrieb XiaoGuo Liu: >> >> I think the problem could be that the stable channel does not support >> it. >> > yes, this is definitely the case, this was not released to stable yet, > the next stable release will have it. On the snapcraft side we have started the practice of annotating the version the documented item was introduced in. I guess it would be good to update the documentation in the snapd wiki to have this. Might tie in with `assumes` rather nicely. Cheers -- Enviado con Dekko desde mi dispositivo Ubuntu From ogra at ubuntu.com Tue Feb 14 12:53:20 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 14 Feb 2017 13:53:20 +0100 Subject: Currernt config hook implementation scales very badly In-Reply-To: <93559d06-55d6-48a7-92f6-692af0fa5d3b@canonical.com> References: <1485945076.25932.40.camel@ubuntu.com> <1487065547.11948.119.camel@ubuntu.com> <93559d06-55d6-48a7-92f6-692af0fa5d3b@canonical.com> Message-ID: <1487076800.24504.11.camel@ubuntu.com> hi, On Di, 2017-02-14 at 09:23 -0300, Sergio Schvezov wrote: > El martes, 14 de febrero de 2017 07h'08:33 ART, Oliver Grawert  > escribió: > > > > hi, > > Am Dienstag, den 14.02.2017, 17:59 +0800 schrieb XiaoGuo Liu: > > > > > > > > > I think the problem could be that the stable channel does not > > > support > > > it. > > > > > yes, this is definitely the case, this was not released to stable > > yet, > > the next stable release will have it.  > > On the snapcraft side we have started the practice of annotating the  > version the documented item was introduced in. I guess it would be > good to  > update the documentation in the snapd wiki to have this. Might tie in > with  > `assumes` rather nicely. > well, the problem here is that such a feature spans across many different places, while snapd 2.22 has the interface support (which is actually pointed out in the docs), the additional support bits in the system might need to land in the different packages first and then as a last step in the configure hook.  since we also dont have a generic core revision number for all arches by design it would become quite a table to maintain for each single config option. perhaps just a date stamp might work "this feature is available in the stable core snap released on: ..." ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From esy at ucrobotics.com Wed Feb 15 02:02:35 2017 From: esy at ucrobotics.com (Shengyang E) Date: Wed, 15 Feb 2017 10:02:35 +0800 Subject: Porting Ubuntu-Core In-Reply-To: References: Message-ID: You can look at: https://bugs.launchpad.net/ubuntu-image/+bug/1630769 We modified the gadget.yaml as follows: device-tree: s900-96board.dtb volumes: bubblegum96: schema: mbr bootloader: u-boot structure: - name: Bootstrap type: bare size: 6M offset: 2M content: - image: bootloader.bin offset: 512 - image: u-boot.bin offset: 1048576 - name: system-boot type: 0C filesystem: vfat filesystem-label: system-boot offset: 8388608 size: 128M content: - source: boot-assets/ target: / it works. 2017-02-14 13:04 GMT+08:00 Woodrow Shen : > Hi all, > > As I used new ubuntu-image (0.14+real1) to create my armhf image, I also > got the same error as well. In order to try to fit the new spec of > gadget.yaml, I modified the gadget.yaml as follows: > > device-tree: actduino_bubble_gum_sdboot_linux.dtb > volumes: > roseapple-pi: > schema: mbr > bootloader: u-boot > structure: > - name: bootloader > size: 4M > content: > - image: bootloader.bin > offset: 2097664 #4097*512 > - image: u-boot.bin > offset: 3145728 #6144*512 > type: bare > - name: system-boot > type: 0C > filesystem: vfat > filesystem-label: system-boot > offset: 8388608 > size: 128M > content: > - source: boot-assets/ > target: / > > And then this can avoid above the error during image creation. However, > the generated image lost the content of bootloader.bin & u-boot.bin at > the specific offset. So I think it may not follow the correct spec of > gadget.yaml. Can anyone help us to resolve the problem? Thanks. > > Regards, > Woodrow > > On Wed, Dec 21, 2016 at 11:15 AM, Bo Dong wrote: > >> Hi Guys, >> >> We're now porting Ubuntu Core to an ARM64 on-chip computer, Bubblegum-96 >> board. (http://www.96boards.org/product/bubblegum-96/) >> Here are some issues we got. >> >> When using ubuntu-image (tag:0.10+real 1 stable), >> >> *$ sudo /snap/bin/ubuntu-image --channel stable --image-size 2G >> --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps >> bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model* >> >> it could make valid image,bubblegum96.img. >> >> After update ubuntu-image using command *$ sudo snap refresh --beta >> --devmode ubuntu-image*, the ubuntu-image will be updated to beta (tag: >> 0.12+real 1). We using command >> >> $ sudo /snap/bin/ubuntu-image --channel beta --image-size 2G >> --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps >> bubblegum96-kernel_3.10.0_arm6*4.snap -o bubblegum96.img >> bubblegum96.model *again, and it will report failure. It shows "gadget.yaml >> parse error: mbr structures cannot be larger than 446 bytes." >> >> The gadget.yaml file is the same before and after update ubuntu-image. >> Here it is: >> $ cat gadget.yaml >> device-tree: s900-96board.dtb >> volumes: >> lemaker-guitar: >> schema: mbr >> bootloader: u-boot >> structure: >> - name: Bootstrap >> type: mbr >> size: 8M >> content: >> - image: bootloader.bin >> offset: 2097664 >> - image: u-boot.bin >> offset: 3145728 >> - type: 0C >> filesystem: vfat >> filesystem-label: system-boot >> offset: 8388608 >> size: 128M >> content: >> - source: boot-assets/ >> target: / >> >> If we change the size: 8M directly to size:440, the image we made will be >> useless. Actually I don't know how to config offset after change the size. >> >> If we change the schema: mbr directly to schema: gpt, and change the >> type: mbr to type: gpt, it will fail again, and shows "gadget.yaml parse >> error: Invalid gadget.yaml @ volumes:lemaker-guitar:structure:0:type" >> >> I'd appreciate it a lot if there is anyone could help us with this. >> >> Thanks&&Best Regards >> >> >> >> -- >> 董波 >> uCRobotic >> Mobile: +86 15624957162 <+86%20156%202495%207162> >> >> http://www.ucrobotics.com.cn/ >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > Woodrow Shen > Software Engineer, Canonical ltd. > Devices | CE | Delivery, Taipei > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin.mcpherson at canonical.com Wed Feb 15 06:45:08 2017 From: justin.mcpherson at canonical.com (Justin McPherson) Date: Wed, 15 Feb 2017 16:45:08 +1000 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: I had a chance to take a quick look at this; see here < https://github.com/justincan/snap-gist> The plugin works in this case, with gist. But is not good enough to be a general solution - no native extensions, probably need to clean up the paths, etc. Happy to hear comments. - Justin On Wed, Feb 1, 2017 at 1:49 AM, Leo Arias wrote: > Thanks for the offer Justin! > > Whenever you are ready to start, join us in > https://rocket.ubuntu.com/channel/snapcraft > We will be there in case you need a hand with the API, code style and > tests. > > It would be great if the two of you pair to write the code, or one > writes the code and the other makes the PR review. > We are trying very hard to make hacking in snapcraft a pleasant > experience for all the new contributors, so we'll also appreciate if > you file bugs about any shortcomings there. > > pura vida. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woodrow.shen at canonical.com Wed Feb 15 07:19:17 2017 From: woodrow.shen at canonical.com (Woodrow Shen) Date: Wed, 15 Feb 2017 15:19:17 +0800 Subject: Porting Ubuntu-Core In-Reply-To: References: Message-ID: Hi Shengyang, My board also works now, thanks. On Wed, Feb 15, 2017 at 10:02 AM, Shengyang E wrote: > You can look at: https://bugs.launchpad.net/ubuntu-image/+bug/1630769 > We modified the gadget.yaml as follows: > device-tree: s900-96board.dtb > volumes: > bubblegum96: > schema: mbr > bootloader: u-boot > structure: > - name: Bootstrap > type: bare > size: 6M > offset: 2M > content: > - image: bootloader.bin > offset: 512 > - image: u-boot.bin > offset: 1048576 > - name: system-boot > type: 0C > filesystem: vfat > filesystem-label: system-boot > offset: 8388608 > size: 128M > content: > - source: boot-assets/ > target: / > > it works. > > 2017-02-14 13:04 GMT+08:00 Woodrow Shen : > >> Hi all, >> >> As I used new ubuntu-image (0.14+real1) to create my armhf image, I also >> got the same error as well. In order to try to fit the new spec of >> gadget.yaml, I modified the gadget.yaml as follows: >> >> device-tree: actduino_bubble_gum_sdboot_linux.dtb >> volumes: >> roseapple-pi: >> schema: mbr >> bootloader: u-boot >> structure: >> - name: bootloader >> size: 4M >> content: >> - image: bootloader.bin >> offset: 2097664 #4097*512 >> - image: u-boot.bin >> offset: 3145728 #6144*512 >> type: bare >> - name: system-boot >> type: 0C >> filesystem: vfat >> filesystem-label: system-boot >> offset: 8388608 >> size: 128M >> content: >> - source: boot-assets/ >> target: / >> >> And then this can avoid above the error during image creation. However, >> the generated image lost the content of bootloader.bin & u-boot.bin at >> the specific offset. So I think it may not follow the correct spec of >> gadget.yaml. Can anyone help us to resolve the problem? Thanks. >> >> Regards, >> Woodrow >> >> On Wed, Dec 21, 2016 at 11:15 AM, Bo Dong wrote: >> >>> Hi Guys, >>> >>> We're now porting Ubuntu Core to an ARM64 on-chip computer, Bubblegum-96 >>> board. (http://www.96boards.org/product/bubblegum-96/) >>> Here are some issues we got. >>> >>> When using ubuntu-image (tag:0.10+real 1 stable), >>> >>> *$ sudo /snap/bin/ubuntu-image --channel stable --image-size 2G >>> --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps >>> bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model* >>> >>> it could make valid image,bubblegum96.img. >>> >>> After update ubuntu-image using command *$ sudo snap refresh --beta >>> --devmode ubuntu-image*, the ubuntu-image will be updated to beta (tag: >>> 0.12+real 1). We using command >>> >>> $ sudo /snap/bin/ubuntu-image --channel beta --image-size 2G >>> --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps >>> bubblegum96-kernel_3.10.0_arm6*4.snap -o bubblegum96.img >>> bubblegum96.model *again, and it will report failure. It shows "gadget.yaml >>> parse error: mbr structures cannot be larger than 446 bytes." >>> >>> The gadget.yaml file is the same before and after update ubuntu-image. >>> Here it is: >>> $ cat gadget.yaml >>> device-tree: s900-96board.dtb >>> volumes: >>> lemaker-guitar: >>> schema: mbr >>> bootloader: u-boot >>> structure: >>> - name: Bootstrap >>> type: mbr >>> size: 8M >>> content: >>> - image: bootloader.bin >>> offset: 2097664 >>> - image: u-boot.bin >>> offset: 3145728 >>> - type: 0C >>> filesystem: vfat >>> filesystem-label: system-boot >>> offset: 8388608 >>> size: 128M >>> content: >>> - source: boot-assets/ >>> target: / >>> >>> If we change the size: 8M directly to size:440, the image we made will >>> be useless. Actually I don't know how to config offset after change the >>> size. >>> >>> If we change the schema: mbr directly to schema: gpt, and change the >>> type: mbr to type: gpt, it will fail again, and shows "gadget.yaml >>> parse error: Invalid gadget.yaml @ volumes:lemaker-guitar:structu >>> re:0:type" >>> >>> I'd appreciate it a lot if there is anyone could help us with this. >>> >>> Thanks&&Best Regards >>> >>> >>> >>> -- >>> 董波 >>> uCRobotic >>> Mobile: +86 15624957162 <+86%20156%202495%207162> >>> >>> http://www.ucrobotics.com.cn/ >>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> >> -- >> Woodrow Shen >> Software Engineer, Canonical ltd. >> Devices | CE | Delivery, Taipei >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- Woodrow Shen Software Engineer, Canonical ltd. Devices | CE | Delivery, Taipei -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjwatson at ubuntu.com Wed Feb 15 11:20:06 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Wed, 15 Feb 2017 11:20:06 +0000 Subject: launchpad snap recipe fails with classic confinement In-Reply-To: <20170210182843.GB10757@riva.ucam.org> References: <95199d1d-02f5-9356-9e8d-92b0a39f08be@canonical.com> <20170210182843.GB10757@riva.ucam.org> Message-ID: <20170215112005.GA20566@riva.ucam.org> On Fri, Feb 10, 2017 at 06:28:43PM +0000, Colin Watson wrote: > The ticket to deploy this is (internal link): > > https://portal.admin.canonical.com/99787 > > ... so I expect that this will be rolled out by the time you release > snapcraft 2.27. This is now all rolled out, so it'll start working once snapcraft 2.27 hits -updates. -- Colin Watson [cjwatson at ubuntu.com] From danilo at canonical.com Wed Feb 15 14:05:00 2017 From: danilo at canonical.com (Danilo =?UTF-8?Q?=C5=A0egan?=) Date: Wed, 15 Feb 2017 15:05:00 +0100 Subject: Automatic restart of daemons on snap installation Message-ID: <1487167500.9681.51.camel@canonical.com> Hi all, We are using snaps to deliver software to juju deployed units, and we are hitting a bit of a blocker: upon snap installation, daemons provided by a snap get unconditionally enabled and (re)started. I've filed a bug already:   https://bugs.launchpad.net/bugs/1664163 But I wonder what do people think about making this optional? The code in question that does this seems to be: https://github.com/snapcore/snapd/blob/master/interfaces/systemd/backend.go#L115 This is a problem for us for multiple reasons:  1. Upon original installation, service will attempt to start before we've even written out a configuration file, which means that it will fail to start.     In a charm world, getting details to finish the configuration can take a while (think waiting for DB to become available), and while we could delay snap installation up to a point where we've got all the data available to write the configuration out, it would still result in at least one restart without the configuration present: we can only configure the snap after it is installed.     This would also feel a bit unnatural to me: I'd like to keep flows in the charm as simple as possible because that makes it easier to guarantee and prove correctness: to *install* a snap, the only pre- condition is that the snap is available, and not that everything is there for it to be *configured* (it also makes it faster: waiting for everything to settle would make nodes sit idle while other nodes get brough up and installed).     I understand the desire behind the explicit restart and service enablement: installing a snap should let users actually use the software they installed right away, and we could have snap provide an installation that runs without any configuration for the initial install, but that's where we get to our next issue. 2. We are deploying multiple units of the same service and for HA and/or no-downtime upgrades, we do something along these lines:   a) unit-0: stop daemon, upgrade snap, regenerate config     b) unit-1: stop daemon   c) unit-0: run DB schema upgrade, restart daemon   d) unit-1: restart daemon    This is a bit simplified, but allows us to back off if any of the steps in a) fail, and the downtime is there only after b) the c) step.    However, to achieve this, we need snapd not to attempt to restart services after snap is installed: new version might need configuration or DB schema changes. It would be great if this would be made an option for "daemon" commands in snaps, eg. "restart-daemon-on-snap-install" that I suggest in the bug above.  Or, it is probably even better to optionally not explicitely "enable" the service post installation. Daemons are a bit of a special case already, and their installation is even more so (as evidenced by all the options that apply to them, some of them 1-to-1 mapping of systemd internal behaviour). Cheers, Danilo From kyle.nitzsche at canonical.com Wed Feb 15 15:14:54 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Wed, 15 Feb 2017 10:14:54 -0500 Subject: Issue with ubuntu OS snap first time boot. In-Reply-To: References: Message-ID: <2332344f-3b09-0abd-cd46-f84a56ce588f@canonical.com> probably this bug: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1652270 On 02/13/2017 11:04 PM, XiaoGuo Liu wrote: > Today, I had the same problem. I downloaded the Raspberry Pi3 image at: > > http://cdimage.ubuntu.com/ubuntu-core/16/stable/ > > The date is: ubuntu-core-16-pi3.img.xz > 2017-01-26 > 20:29316M > ------------------------------------------------------------------------ > > After I flashed it, I had the same issue as described in the above > email. Attached please find the captured picture. > > The old image in the Ubuntu Core could not boot, and it stopped at > "booting kernel". I thought it was an old image flashed long time ago. I > decided to take the new one. > > Thanks & best regards, > XiaoGuo > > > > On Tue, Jan 10, 2017 at 9:35 PM, Ajay Pandey > wrote: > > Hi All,____ > > __ __ > > We are facing issue with the Ubuntu OS snap first time boot > console-conf.____ > > __ __ > > We have generated the id_rsa.pub key and put it in the launchpad.net > as well as the login.ubuntu.com > profiles.____ > > __ __ > > Please find below the error that we are getting:____ > > __ __ > > /Profile setup > > Enter an email address from your account in the store. > > Email address: *xyz at gmail.com > (example)* > > If you do not have an account, visit https://login.ubuntu.com > to create one. > > Creating user > failed: > *error: while creating user: cannot communicate with server: > Post > http://localhost/v2/create-user > : EOF* > > > Contacting > store... > > [ Done ] > [ Cancel ] > > > > 40 %____/ > > ************************************************************************************************************************************************************* > eInfochips Business Disclaimer: This e-mail message and all > attachments transmitted with it are intended solely for the use of > the addressee and may contain legally privileged and confidential > information. If the reader of this message is not the intended > recipient, or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any > dissemination, distribution, copying, or other use of this message > or its attachments is strictly prohibited. If you have received this > message in error, please notify the sender immediately by replying > to this message and please delete it from your computer. Any views > expressed in this message are those of the individual sender unless > otherwise stated. Company has taken enough precautions to prevent > the spread of viruses. However the company accepts no liability for > any damage caused by any virus transmitted by this email. > ************************************************************************************************************************************************************* > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > XiaoGuo, Liu > > From simos.lists at googlemail.com Wed Feb 15 15:33:08 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Wed, 15 Feb 2017 17:33:08 +0200 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: <0afec719-2791-b5cd-e138-0d0a68d0b412@ubuntu.com> References: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> <0dc231f8-26fc-d929-faef-7f28e1b8850d@ubuntu.com> <0afec719-2791-b5cd-e138-0d0a68d0b412@ubuntu.com> Message-ID: On Mon, Feb 13, 2017 at 7:13 PM, Didier Roche wrote: > Le 10/02/2017 à 17:30, Simos Xenitellis a écrit : >> On Tue, Feb 7, 2017 at 3:54 PM, Didier Roche wrote: >>> Le 07/02/2017 à 14:05, Simos Xenitellis a écrit : >>>> On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche wrote: >>>>> Le 06/02/2017 à 10:56, Simos Xenitellis a écrit : >>>>>> Hi All, >>>>>> >>>>>> I wrote an article about creating a snap for an existing Python >>>>>> program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu >>>>>> Store. >>>>>> >>>>>> I am looking forward to receiving feedback :-) >>>>>> >>>>>> Link: https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/ >>>>>> >>>>>> Link to HN submission: https://news.ycombinator.com/item?id=13578034 >>>>>> >>>>>> Simos >>>>>> >>>>> Excellent work Simos! >>>>> >>>>> I think this kind of content would make an excellent official "pratical" >>>>> tutorials on https://tutorials.ubuntu.com. Are you interested into >>>>> contributing there? >>>>> >>>>> If you want more context on tutorials, the phisolophy and how to >>>>> contribute, I wrote a blog post some time ago about it: >>>>> https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/. >>>>> >>>>> I'm also available for any help, >>>> Thanks Didier! >>>> >>>> I had a look at https://github.com/ubuntudesign/tutorials.ubuntu.com/issues >>>> and the direction that tutorials.ubuntu.com wants to take. It looks good. >>>> It requires planning in terms of the writing of the tutorials so that >>>> they are gradually incremental, >>>> and some basic tutorials can referenced by the more complex ones. It's >>>> a lot of dedicated work. >>>> >>>> I'll give it a go and try to write a couple of tutorials for >>>> tutorials.ubuntu.com. We will see how it goes :-) >>>> I think I'll start with the baseline tutorial for snapcraft. >>> Excellent news! >>> You can as well convert some of yours to this format! I give you the >>> direct link to the guidelines to have some coherences between the >>> tutorials in term of tones and content: >>> https://docs.google.com/document/d/1u5qmSNIcE8SjuAg6aKjTxOBGWIjBW0kYf01t4Dfw6-U/edit. >>> >> I managed to complete the conversion and the tutorial is ready :-). >> >> Here it is, >> https://docs.google.com/document/d/1Nk-kw79lt84YJNEKS_WpnGzVSjrmCUVd1TsAx5aRoOA/ >> Feel free to add to tutorials.ubuntu.com or make a copy in order to edit. >> >> Overall, the experience in converting to the format required by >> codelabs was interesting. >> I still need more practice before I would be able to write a tutorial >> in one go in the codelab style. > > This really looks awesome! Thanks Simos :) > > I'll add some very small tweaking, but after a first look, it's very a > nice first shot. Well done :) Thanks! > I would be interested in any comment you have about the codelab format > and style, and anything you liked/didn't like. > The environment about the command-line snippets, https://docs.google.com/document/d/1u5qmSNIcE8SjuAg6aKjTxOBGWIjBW0kYf01t4Dfw6-U/edit#heading=h.6e9eqf6ttpj could be enhanced by distinguishing the actual commands that the user is expected to type (and run). That is, if you make "bold" part of a command-line snippet, then the "bold" part will appear differently in order to show that it is about text to be typed by the user. In addition, if a user double-clicks on such user-input, then it should ideally select only the user-input and not the prompt characters. I filed a feature request at https://github.com/googlecodelabs/tools/issues/24 > I'll keep you posted with a diff so that you can see what small > modifications I made to be more coherent with the other ones. > Thanks, looking forward to reading the changes. Cheers, Simos > If you have any other to do, do not hesitate to keep us posted! > Cheers, > Didier > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From facundo.batista at canonical.com Wed Feb 15 16:46:21 2017 From: facundo.batista at canonical.com (Facundo Batista) Date: Wed, 15 Feb 2017 13:46:21 -0300 Subject: Announcing channel tracks for long-term stable snaps Message-ID: Hola! To publish stable snaps of different versions at the same time, like Go 1.6 and 1.7, we now have ‘channel tracks’ in beta. Each track has its own set of risk-based channels: stable, candidate, beta, edge. So for example, you can choose Go 1.7/stable and 1.7/edge. People who switch to a beta channel of 1.7 will get new beta revisions as long as that is open, otherwise they will drop to 1.7/candidate, or 1.7/stable if that’s the only release in the 1.7 track. The implicit track for everybody is ‘latest’. So what we currently call ‘stable’ is now implicitly ‘latest/stable’. Installing a snap --stable is the same as installing --channel=latest/stable and the various tools will be updated to reflect that nomenclature in upcoming releases. On the ‘latest’ track, the major version will change when the publisher switches to the new major version. So if you are on latest/stable for Go then you will get 1.7.x when the publisher chooses to release it into latest/stable, and then 1.8.x when that comes around. You are tracking the latest and greatest stable release. If you switch to a track like 1.7, then the publisher should never change major version underneath you unexpectedly. You can expect to get point releases that fit the ‘1.7’ designation, and you will stop getting updates when the publisher stops releasing new revisions in that older track. Since each track gets stable, candidate, beta and edge revisions, you can run daily builds of your stable branches into the relevant track/edge channel. So something like 1.8/edge should contain a smoke-tested daily automated build of the 1.8.x stable branch. This maintains the ability to release CI builds to edge for each major version. Similarly, you have beta and candidate to push releases to a wider audience before they go to the stable channel. This feature is now available in beta. In addition to the Go snap there is an etcd snap available with tracks for 2.3 and 3.0, and tracks for the MySQL snap are in the works. Please contact us on the #snappy IRC channel on FreeNode or snapcraft at lists.snapcraft.io or https://rocket.ubuntu.com/channel/snapcraft if you'd like to create a track for your snap. To ensure that users don’t get stuck on unmaintained software we will only open tracks for upstream stable releases that are actively maintained in stable branches. We are still making some adjustments to the snap and snapcraft command interactions to fully support tracks, but here's the current CLI user experience to release a revision into a track: snapcraft release [/]stability For example: snapcraft release foo 14 2.0/stable snapcraft release foo 15 2.1/edge The track is ‘latest’ unless provided explicitly. So this will update the release in latest/stable: snapcraft release foo 13 stable To install a snap from a particular track: snap install foo --channel=2.1/candidate `snap info` will in future tell you about the tracks for a particular snap. For now, tell your audience through your blog or mailing lists if you have stable tracks to offer. Hope you enjoy this feature. Feedback welcome and if you have questions, please ask! Regards, - Facundo, on behalf of the Snap Store team . Canonical - Online Services From bret.barker at canonical.com Wed Feb 15 16:53:57 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Wed, 15 Feb 2017 11:53:57 -0500 Subject: Announcing channel tracks for long-term stable snaps In-Reply-To: References: Message-ID: <20170215165357.GC11199@abitrandom.net> On Wed, Feb 15, 2017 at 01:46:21PM -0300, Facundo Batista wrote: > Hola! > > To publish stable snaps of different versions at the same time, like Go 1.6 and 1.7, we now have ‘channel tracks’ in beta. > > Each track has its own set of risk-based channels: stable, candidate, beta, edge. So for example, you can choose Go > 1.7/stable and 1.7/edge. People who switch to a beta channel of 1.7 will get new beta revisions as long as that is open, > otherwise they will drop to 1.7/candidate, or 1.7/stable if that’s the only release in the 1.7 track. > A quick note regarding the golang snap, it is using classic confinement and so install should be like: $ snap install go --classic --channel=1.6/stable and to switch to the 1.7 stable branch: $ snap refresh go --channel=1.7/stable -bret From stgraber at ubuntu.com Wed Feb 15 18:36:18 2017 From: stgraber at ubuntu.com (=?iso-8859-1?Q?St=E9phane?= Graber) Date: Wed, 15 Feb 2017 13:36:18 -0500 Subject: Announcing channel tracks for long-term stable snaps In-Reply-To: References: Message-ID: <20170215183618.nj2yvk7favzmpkfx@castiana> On Wed, Feb 15, 2017 at 01:46:21PM -0300, Facundo Batista wrote: > Hola! > > To publish stable snaps of different versions at the same time, like Go 1.6 and 1.7, we now have ‘channel tracks’ in beta. > > Each track has its own set of risk-based channels: stable, candidate, beta, edge. So for example, you can choose Go > 1.7/stable and 1.7/edge. People who switch to a beta channel of 1.7 will get new beta revisions as long as that is open, > otherwise they will drop to 1.7/candidate, or 1.7/stable if that’s the only release in the 1.7 track. > > The implicit track for everybody is ‘latest’. So what we currently call ‘stable’ is now implicitly ‘latest/stable’. > Installing a snap --stable is the same as installing --channel=latest/stable and the various tools will be updated to > reflect that nomenclature in upcoming releases. > > On the ‘latest’ track, the major version will change when the publisher switches to the new major version. So if you are > on latest/stable for Go then you will get 1.7.x when the publisher chooses to release it into latest/stable, and then > 1.8.x when that comes around. You are tracking the latest and greatest stable release. > > If you switch to a track like 1.7, then the publisher should never change major version underneath you unexpectedly. You > can expect to get point releases that fit the ‘1.7’ designation, and you will stop getting updates when the publisher > stops releasing new revisions in that older track. > > Since each track gets stable, candidate, beta and edge revisions, you can run daily builds of your stable branches into > the relevant track/edge channel. So something like 1.8/edge should contain a smoke-tested daily automated build of the > 1.8.x stable branch. This maintains the ability to release CI builds to edge for each major version. Similarly, you have > beta and candidate to push releases to a wider audience before they go to the stable channel. > > This feature is now available in beta. In addition to the Go snap there is an etcd snap available with tracks for 2.3 > and 3.0, and tracks for the MySQL snap are in the works. > > Please contact us on the #snappy IRC channel on FreeNode or snapcraft at lists.snapcraft.io or > https://rocket.ubuntu.com/channel/snapcraft if you'd like to create a track for your snap. > > To ensure that users don’t get stuck on unmaintained software we will only open tracks for upstream stable releases that > are actively maintained in stable branches. > > We are still making some adjustments to the snap and snapcraft command interactions to fully support tracks, but here's > the current CLI user experience to release a revision into a track: > > snapcraft release [/]stability > > For example: > > snapcraft release foo 14 2.0/stable > snapcraft release foo 15 2.1/edge > > The track is ‘latest’ unless provided explicitly. So this will update the release in latest/stable: > > snapcraft release foo 13 stable > > To install a snap from a particular track: > > snap install foo --channel=2.1/candidate > > `snap info` will in future tell you about the tracks for a particular snap. For now, tell your audience through your > blog or mailing lists if you have stable tracks to offer. > > Hope you enjoy this feature. Feedback welcome and if you have questions, please ask! > > Regards, > > - Facundo, on behalf of the Snap Store team > . > Canonical - Online Services Hey there, Are tracks supported in Launchpad? I'd like to use this feature for the LXD 2.0 (LTS) branch, but we're building and publishing (except for stable) all our snaps through Launchpad as we need support for all architectures. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From aaron.hampt at gmail.com Wed Feb 15 19:38:42 2017 From: aaron.hampt at gmail.com (Aaron Hampton) Date: Wed, 15 Feb 2017 14:38:42 -0500 Subject: Remove revision from store Message-ID: Hi, Is it possible to remove a revision of an application I uploaded? It currently has Manual review pending for its status because I failed to included a .desktop file when one was required. I've since fixed that issue in subsequent revisions, but their reviews are pending a previous review. I'd like to remove the problem snap, but can't see a way to delete a revision in the store. Thanks again. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.manrique at canonical.com Wed Feb 15 20:24:28 2017 From: daniel.manrique at canonical.com (Daniel Manrique) Date: Wed, 15 Feb 2017 15:24:28 -0500 Subject: Remove revision from store In-Reply-To: References: Message-ID: Hello Aaron, We're looking at ways to make the queueish nature of a snap's upload both more visible and more actionable by the developer, since cases like yours where a snap is rejected and the developer uploads a fixed version are starting to pop up, and can be easily solved once the pending upload's status is resolved. For now, if you point me to your application, I can reject the held upload, which will simply cause the next one in the queue to undergo automated review; Since you fixed the automated review issues on subsequent uploads, that should take care of things. Awaiting your info, - Daniel On Wed, Feb 15, 2017 at 2:38 PM, Aaron Hampton wrote: > Hi, > > Is it possible to remove a revision of an application I uploaded? It > currently has Manual review pending for its status because I failed to > included a .desktop file when one was required. I've since fixed that issue > in subsequent revisions, but their reviews are pending a previous review. > I'd like to remove the problem snap, but can't see a way to delete a > revision in the store. > > Thanks again. > Aaron > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From aaron.hampt at gmail.com Wed Feb 15 20:56:02 2017 From: aaron.hampt at gmail.com (Aaron Hampton) Date: Wed, 15 Feb 2017 15:56:02 -0500 Subject: Remove revision from store In-Reply-To: References: Message-ID: Hi, What information do you need? Is the snap ID enough? It is: AW8uZ7ZTD6dC6iD1eboxmPyzGxB0pion Thanks again, Aaron On Feb 15, 2017 3:25 PM, "Daniel Manrique" wrote: > Hello Aaron, > > We're looking at ways to make the queueish nature of a snap's upload > both more visible and more actionable by the developer, since cases > like yours where a snap is rejected and the developer uploads a fixed > version are starting to pop up, and can be easily solved once the > pending upload's status is resolved. > > For now, if you point me to your application, I can reject the held > upload, which will simply cause the next one in the queue to undergo > automated review; Since you fixed the automated review issues on > subsequent uploads, that should take care of things. > > Awaiting your info, > - Daniel > > > > On Wed, Feb 15, 2017 at 2:38 PM, Aaron Hampton > wrote: > > Hi, > > > > Is it possible to remove a revision of an application I uploaded? It > > currently has Manual review pending for its status because I failed to > > included a .desktop file when one was required. I've since fixed that > issue > > in subsequent revisions, but their reviews are pending a previous review. > > I'd like to remove the problem snap, but can't see a way to delete a > > revision in the store. > > > > Thanks again. > > Aaron > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.manrique at canonical.com Wed Feb 15 21:53:37 2017 From: daniel.manrique at canonical.com (Daniel Manrique) Date: Wed, 15 Feb 2017 16:53:37 -0500 Subject: Remove revision from store In-Reply-To: References: Message-ID: On Wed, Feb 15, 2017 at 3:56 PM, Aaron Hampton wrote: > Hi, > > What information do you need? Is the snap ID enough? It is: > AW8uZ7ZTD6dC6iD1eboxmPyzGxB0pion Hi Aaron, I marked your revision 2 as rejected, so the store processed and approved #3 as we discussed. Next, #4 got held for manual review due to automated review failures, perhaps you want to have a look? in any case, you can go ahead and publish #3 anyway if you like. Cheers, - Daniel > > Thanks again, > Aaron > > On Feb 15, 2017 3:25 PM, "Daniel Manrique" > wrote: >> >> Hello Aaron, >> >> We're looking at ways to make the queueish nature of a snap's upload >> both more visible and more actionable by the developer, since cases >> like yours where a snap is rejected and the developer uploads a fixed >> version are starting to pop up, and can be easily solved once the >> pending upload's status is resolved. >> >> For now, if you point me to your application, I can reject the held >> upload, which will simply cause the next one in the queue to undergo >> automated review; Since you fixed the automated review issues on >> subsequent uploads, that should take care of things. >> >> Awaiting your info, >> - Daniel >> >> >> >> On Wed, Feb 15, 2017 at 2:38 PM, Aaron Hampton >> wrote: >> > Hi, >> > >> > Is it possible to remove a revision of an application I uploaded? It >> > currently has Manual review pending for its status because I failed to >> > included a .desktop file when one was required. I've since fixed that >> > issue >> > in subsequent revisions, but their reviews are pending a previous >> > review. >> > I'd like to remove the problem snap, but can't see a way to delete a >> > revision in the store. >> > >> > Thanks again. >> > Aaron >> > >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From aaron.hampt at gmail.com Wed Feb 15 21:56:23 2017 From: aaron.hampt at gmail.com (Aaron Hampton) Date: Wed, 15 Feb 2017 16:56:23 -0500 Subject: Remove revision from store In-Reply-To: References: Message-ID: Thanks. It seems to be the same problem with a missing .desktop file. It should exist, though. Any chance you could reject that one, too, and I'll look into it further before pushing another update. Thanks for all the help, Aaron On Feb 15, 2017 4:54 PM, "Daniel Manrique" wrote: > On Wed, Feb 15, 2017 at 3:56 PM, Aaron Hampton > wrote: > > Hi, > > > > What information do you need? Is the snap ID enough? It is: > > AW8uZ7ZTD6dC6iD1eboxmPyzGxB0pion > > Hi Aaron, > > I marked your revision 2 as rejected, so the store processed and > approved #3 as we discussed. > > Next, #4 got held for manual review due to automated review failures, > perhaps you want to have a look? in any case, you can go ahead and > publish #3 anyway if you like. > > Cheers, > > - Daniel > > > > > Thanks again, > > Aaron > > > > On Feb 15, 2017 3:25 PM, "Daniel Manrique" < > daniel.manrique at canonical.com> > > wrote: > >> > >> Hello Aaron, > >> > >> We're looking at ways to make the queueish nature of a snap's upload > >> both more visible and more actionable by the developer, since cases > >> like yours where a snap is rejected and the developer uploads a fixed > >> version are starting to pop up, and can be easily solved once the > >> pending upload's status is resolved. > >> > >> For now, if you point me to your application, I can reject the held > >> upload, which will simply cause the next one in the queue to undergo > >> automated review; Since you fixed the automated review issues on > >> subsequent uploads, that should take care of things. > >> > >> Awaiting your info, > >> - Daniel > >> > >> > >> > >> On Wed, Feb 15, 2017 at 2:38 PM, Aaron Hampton > >> wrote: > >> > Hi, > >> > > >> > Is it possible to remove a revision of an application I uploaded? It > >> > currently has Manual review pending for its status because I failed to > >> > included a .desktop file when one was required. I've since fixed that > >> > issue > >> > in subsequent revisions, but their reviews are pending a previous > >> > review. > >> > I'd like to remove the problem snap, but can't see a way to delete a > >> > revision in the store. > >> > > >> > Thanks again. > >> > Aaron > >> > > >> > -- > >> > Snapcraft mailing list > >> > Snapcraft at lists.snapcraft.io > >> > Modify settings or unsubscribe at: > >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft > >> > > >> > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.manrique at canonical.com Wed Feb 15 22:09:31 2017 From: daniel.manrique at canonical.com (Daniel Manrique) Date: Wed, 15 Feb 2017 17:09:31 -0500 Subject: Remove revision from store In-Reply-To: References: Message-ID: On Wed, Feb 15, 2017 at 4:56 PM, Aaron Hampton wrote: > Thanks. It seems to be the same problem with a missing .desktop file. It > should exist, though. Any chance you could reject that one, too, and I'll > look into it further before pushing another update. Done! Perhaps the .desktop file is not in the expected location; check if the warning given for the upload helps clarify this. > > Thanks for all the help, No problem, always happy to help. Cheers! - Daniel > Aaron > > On Feb 15, 2017 4:54 PM, "Daniel Manrique" > wrote: >> >> On Wed, Feb 15, 2017 at 3:56 PM, Aaron Hampton >> wrote: >> > Hi, >> > >> > What information do you need? Is the snap ID enough? It is: >> > AW8uZ7ZTD6dC6iD1eboxmPyzGxB0pion >> >> Hi Aaron, >> >> I marked your revision 2 as rejected, so the store processed and >> approved #3 as we discussed. >> >> Next, #4 got held for manual review due to automated review failures, >> perhaps you want to have a look? in any case, you can go ahead and >> publish #3 anyway if you like. >> >> Cheers, >> >> - Daniel >> >> > >> > Thanks again, >> > Aaron >> > >> > On Feb 15, 2017 3:25 PM, "Daniel Manrique" >> > >> > wrote: >> >> >> >> Hello Aaron, >> >> >> >> We're looking at ways to make the queueish nature of a snap's upload >> >> both more visible and more actionable by the developer, since cases >> >> like yours where a snap is rejected and the developer uploads a fixed >> >> version are starting to pop up, and can be easily solved once the >> >> pending upload's status is resolved. >> >> >> >> For now, if you point me to your application, I can reject the held >> >> upload, which will simply cause the next one in the queue to undergo >> >> automated review; Since you fixed the automated review issues on >> >> subsequent uploads, that should take care of things. >> >> >> >> Awaiting your info, >> >> - Daniel >> >> >> >> >> >> >> >> On Wed, Feb 15, 2017 at 2:38 PM, Aaron Hampton >> >> wrote: >> >> > Hi, >> >> > >> >> > Is it possible to remove a revision of an application I uploaded? It >> >> > currently has Manual review pending for its status because I failed >> >> > to >> >> > included a .desktop file when one was required. I've since fixed that >> >> > issue >> >> > in subsequent revisions, but their reviews are pending a previous >> >> > review. >> >> > I'd like to remove the problem snap, but can't see a way to delete a >> >> > revision in the store. >> >> > >> >> > Thanks again. >> >> > Aaron >> >> > >> >> > -- >> >> > Snapcraft mailing list >> >> > Snapcraft at lists.snapcraft.io >> >> > Modify settings or unsubscribe at: >> >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > >> >> >> >> -- >> >> Snapcraft mailing list >> >> Snapcraft at lists.snapcraft.io >> >> Modify settings or unsubscribe at: >> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> > >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From bret.barker at canonical.com Wed Feb 15 22:36:28 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Wed, 15 Feb 2017 17:36:28 -0500 Subject: Bug tracking for the Snap Store Message-ID: <20170215223627.GG11199@abitrandom.net> Just a quick FYI, we now have a Launchpad project for tracking bugs and issues related to all aspects of the Snap Store: https://launchpad.net/snapstore You can also find us in #snappy on Freenode IRC. And a reminder that there are also: https://launchpad.net/snapd - for issues specific to snapd https://launchpad.net/snapcraft - for issues specific to snapcraft Thanks, -bret From joseph.wakeling at webdrake.net Wed Feb 15 23:09:36 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 16 Feb 2017 00:09:36 +0100 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) In-Reply-To: <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> <20170210234842.GC28439@hunt> <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> Message-ID: <44a29966-804c-3a21-c0ad-2235f6964f33@webdrake.net> On 11/02/17 17:31, Joseph Rushton Wakeling wrote: > I just reproduced the issue in a VirtualBox install of 14.04 to get these > details. Kernel report in kern.log: > > Feb 11 17:16:19 vb1404 kernel: [ 534.781526] traps: gcc[6209] general > protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in > libc-2.23.so[7f6632bd8000+1bf000] > > And `dmesg | grep -i gcc` gave this output: > > [ 0.000000] Linux version 4.4.0-62-generic (buildd at lcy01-33) (gcc version > 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #83~14.04.1-Ubuntu SMP Wed Jan 18 > 18:10:30 UTC 2017 (Ubuntu 4.4.0-62.83~14.04.1-generic 4.4.40) > [ 534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee > sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000] > >> This may give enough information for someone to suggest the next step. > > I'm not very experienced at interpreting these kinds of messages, but if I > understand right they would suggest a libc compatibility issue ... ? Folks, could I ping on the above? It seems like a rather severe limitation on the universality of the package (at a minimum it probably restricts the package to working on systems with the same or later libc) so I'm curious if anyone has any thoughts on if and how this could be ameliorated. From manik at canonical.com Thu Feb 16 00:04:17 2017 From: manik at canonical.com (Manik Taneja) Date: Wed, 15 Feb 2017 16:04:17 -0800 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) In-Reply-To: <44a29966-804c-3a21-c0ad-2235f6964f33@webdrake.net> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> <20170210234842.GC28439@hunt> <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> <44a29966-804c-3a21-c0ad-2235f6964f33@webdrake.net> Message-ID: jamie, any insights? /manik On Wed, Feb 15, 2017 at 3:09 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 11/02/17 17:31, Joseph Rushton Wakeling wrote: > >> I just reproduced the issue in a VirtualBox install of 14.04 to get these >> details. Kernel report in kern.log: >> >> Feb 11 17:16:19 vb1404 kernel: [ 534.781526] traps: gcc[6209] general >> protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in >> libc-2.23.so[7f6632bd8000+1bf000] >> >> And `dmesg | grep -i gcc` gave this output: >> >> [ 0.000000] Linux version 4.4.0-62-generic (buildd at lcy01-33) (gcc >> version >> 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #83~14.04.1-Ubuntu SMP Wed Jan 18 >> 18:10:30 UTC 2017 (Ubuntu 4.4.0-62.83~14.04.1-generic 4.4.40) >> [ 534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee >> sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000] >> >> This may give enough information for someone to suggest the next step. >>> >> >> I'm not very experienced at interpreting these kinds of messages, but if I >> understand right they would suggest a libc compatibility issue ... ? >> > > Folks, could I ping on the above? > > It seems like a rather severe limitation on the universality of the > package (at a minimum it probably restricts the package to working on > systems with the same or later libc) so I'm curious if anyone has any > thoughts on if and how this could be ameliorated. > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Feb 16 00:44:38 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 16 Feb 2017 08:44:38 +0800 Subject: Issue with ubuntu OS snap first time boot. In-Reply-To: <2332344f-3b09-0abd-cd46-f84a56ce588f@canonical.com> References: <2332344f-3b09-0abd-cd46-f84a56ce588f@canonical.com> Message-ID: It seems not the problem. My problem is that it cannot finish the last step of console-conf after I type the email address. It awaits from the Ubuntu Store, but finally, I received a timeout message. On Wed, Feb 15, 2017 at 11:14 PM, knitzsche wrote: > probably this bug: https://bugs.launchpad.net/ubu > ntu/+source/linux-raspi2/+bug/1652270 > > > On 02/13/2017 11:04 PM, XiaoGuo Liu wrote: > >> Today, I had the same problem. I downloaded the Raspberry Pi3 image at: >> >> http://cdimage.ubuntu.com/ubuntu-core/16/stable/ >> >> The date is: ubuntu-core-16-pi3.img.xz >> > ntu-core-16-pi3.img.xz>2017-01-26 >> 20:29316M >> ------------------------------------------------------------------------ >> >> After I flashed it, I had the same issue as described in the above >> email. Attached please find the captured picture. >> >> The old image in the Ubuntu Core could not boot, and it stopped at >> "booting kernel". I thought it was an old image flashed long time ago. I >> decided to take the new one. >> >> Thanks & best regards, >> XiaoGuo >> >> >> >> On Tue, Jan 10, 2017 at 9:35 PM, Ajay Pandey > > wrote: >> >> Hi All,____ >> >> __ __ >> >> We are facing issue with the Ubuntu OS snap first time boot >> console-conf.____ >> >> __ __ >> >> We have generated the id_rsa.pub key and put it in the launchpad.net >> as well as the login.ubuntu.com >> profiles.____ >> >> __ __ >> >> Please find below the error that we are getting:____ >> >> __ __ >> >> /Profile setup >> >> Enter an email address from your account in the store. >> >> Email address: *xyz at gmail.com >> (example)* >> >> If you do not have an account, visit https://login.ubuntu.com >> to create one. >> >> Creating user >> failed: >> *error: while creating user: cannot communicate with server: >> Post >> http://localhost/v2/create-user >> : EOF* >> >> >> Contacting >> store... >> >> [ Done ] >> [ Cancel ] >> >> >> >> 40 %____/ >> >> ************************************************************ >> ************************************************************ >> ************************************* >> eInfochips Business Disclaimer: This e-mail message and all >> attachments transmitted with it are intended solely for the use of >> the addressee and may contain legally privileged and confidential >> information. If the reader of this message is not the intended >> recipient, or an employee or agent responsible for delivering this >> message to the intended recipient, you are hereby notified that any >> dissemination, distribution, copying, or other use of this message >> or its attachments is strictly prohibited. If you have received this >> message in error, please notify the sender immediately by replying >> to this message and please delete it from your computer. Any views >> expressed in this message are those of the individual sender unless >> otherwise stated. Company has taken enough precautions to prevent >> the spread of viruses. However the company accepts no liability for >> any damage caused by any virus transmitted by this email. >> ************************************************************ >> ************************************************************ >> ************************************* >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> >> >> >> >> -- >> XiaoGuo, Liu >> >> >> > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hudson at canonical.com Thu Feb 16 00:54:52 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Thu, 16 Feb 2017 13:54:52 +1300 Subject: please try my golang snap In-Reply-To: References: Message-ID: On 7 February 2017 at 09:25, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > > I think this makes sense as a way to distribute Go to people who want to > use Go on their machines. I maintain a PPA with backports of new versions > of Go to older releases of Ubuntu but it's a bit fiddly and snaps would be > better (and also get cross distro coverage). I think to get to the point of > it being a good general distribution mechanism, we need: > > 1) testing (so that's everyone who's downloaded it so far) > More of this would be nice, but... > 2) pick a better snap name, or set of snap names (go-16, go-17, go-18 or > go16, go17, go18 or something else?) > The snap is now called 'go' and makes use of the newly announced 'tracks', with current tracks being 1.6, 1.7 and 1.8. If you don't specify a track you'll get 1.7 for now, but 1.8 soon when that is released (possibly tomorrow). > 3) get it into the stable channel > Now done, for 1.6, 1.7 and latest tracks. Hopefully soon I'll set up autobuilds of tip going to edge. > 4) building in Launchpad would surely be nice to get better architecture > coverage > Not quite there yet, but soon. Cheers, mwh Have I missed anything? > > Cheers, > mwh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik.taneja at canonical.com Thu Feb 16 01:54:01 2017 From: manik.taneja at canonical.com (Manik Taneja) Date: Wed, 15 Feb 2017 17:54:01 -0800 Subject: Issue with ubuntu OS snap first time boot. In-Reply-To: References: <2332344f-3b09-0abd-cd46-f84a56ce588f@canonical.com> Message-ID: <644A68E3-069D-485C-9EEF-BC117E375AF0@canonical.com> Bret, Can you please guide Xiaoguo with what logs you need for debugging? Manik > On Feb 15, 2017, at 4:44 PM, XiaoGuo Liu wrote: > > It seems not the problem. My problem is that it cannot finish the last step of console-conf after I type the email address. It awaits from the Ubuntu Store, but finally, I received a timeout message. > >> On Wed, Feb 15, 2017 at 11:14 PM, knitzsche wrote: >> probably this bug: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1652270 >> >> >>> On 02/13/2017 11:04 PM, XiaoGuo Liu wrote: >>> Today, I had the same problem. I downloaded the Raspberry Pi3 image at: >>> >>> http://cdimage.ubuntu.com/ubuntu-core/16/stable/ >>> >>> The date is: ubuntu-core-16-pi3.img.xz >>> 2017-01-26 >>> 20:29316M >>> ------------------------------------------------------------------------ >>> >>> After I flashed it, I had the same issue as described in the above >>> email. Attached please find the captured picture. >>> >>> The old image in the Ubuntu Core could not boot, and it stopped at >>> "booting kernel". I thought it was an old image flashed long time ago. I >>> decided to take the new one. >>> >>> Thanks & best regards, >>> XiaoGuo >>> >>> >>> >>> On Tue, Jan 10, 2017 at 9:35 PM, Ajay Pandey >> > wrote: >>> >>> Hi All,____ >>> >>> __ __ >>> >>> We are facing issue with the Ubuntu OS snap first time boot >>> console-conf.____ >>> >>> __ __ >>> >>> We have generated the id_rsa.pub key and put it in the launchpad.net >>> as well as the login.ubuntu.com >>> profiles.____ >>> >>> __ __ >>> >>> Please find below the error that we are getting:____ >>> >>> __ __ >>> >>> /Profile setup >>> >>> Enter an email address from your account in the store. >>> >>> Email address: *xyz at gmail.com >>> (example)* >>> >>> If you do not have an account, visit https://login.ubuntu.com >>> to create one. >>> >>> Creating user >>> failed: >>> *error: while creating user: cannot communicate with server: >>> Post >>> http://localhost/v2/create-user >>> : EOF* >>> >>> >>> Contacting >>> store... >>> >>> [ Done ] >>> [ Cancel ] >>> >>> >>> >>> 40 %____/ >>> >>> ************************************************************************************************************************************************************* >>> eInfochips Business Disclaimer: This e-mail message and all >>> attachments transmitted with it are intended solely for the use of >>> the addressee and may contain legally privileged and confidential >>> information. If the reader of this message is not the intended >>> recipient, or an employee or agent responsible for delivering this >>> message to the intended recipient, you are hereby notified that any >>> dissemination, distribution, copying, or other use of this message >>> or its attachments is strictly prohibited. If you have received this >>> message in error, please notify the sender immediately by replying >>> to this message and please delete it from your computer. Any views >>> expressed in this message are those of the individual sender unless >>> otherwise stated. Company has taken enough precautions to prevent >>> the spread of viruses. However the company accepts no liability for >>> any damage caused by any virus transmitted by this email. >>> ************************************************************************************************************************************************************* >>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/snapcraft >>> >>> >>> >>> >>> >>> -- >>> XiaoGuo, Liu >>> >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > XiaoGuo, Liu > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Thu Feb 16 04:10:36 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 16 Feb 2017 01:10:36 -0300 Subject: LDC compiler snap issues on 14.04 (ABI =?iso-8859-1?Q?compatibility=3F)?= In-Reply-To: <44a29966-804c-3a21-c0ad-2235f6964f33@webdrake.net> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> <20170210234842.GC28439@hunt> <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> Message-ID: <7bda09a9-3b23-4f4d-95e4-9d04d6cdb4d0@canonical.com> El miércoles, 15 de febrero de 2017 20h'09:36 ART, Joseph Rushton Wakeling escribió: > On 11/02/17 17:31, Joseph Rushton Wakeling wrote: >> I just reproduced the issue in a VirtualBox install of 14.04 to get these >> details. Kernel report in kern.log: >> >> Feb 11 17:16:19 vb1404 kernel: [ 534.781526] traps: gcc[6209] general >> protection ip:7f6632d1b1ee sp:7fff0a09e2f0 error:0 in >> libc-2.23.so[7f6632bd8000+1bf000] >> >> And `dmesg | grep -i gcc` gave this output: >> >> [ 0.000000] Linux version 4.4.0-62-generic >> (buildd at lcy01-33) (gcc version >> 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #83~14.04.1-Ubuntu SMP Wed Jan 18 >> 18:10:30 UTC 2017 (Ubuntu 4.4.0-62.83~14.04.1-generic 4.4.40) >> [ 534.781526] traps: gcc[6209] general protection ip:7f6632d1b1ee >> sp:7fff0a09e2f0 error:0 in libc-2.23.so[7f6632bd8000+1bf000] >> >>> This may give enough information for someone to suggest the next step. >> >> I'm not very experienced at interpreting these kinds of >> messages, but if I >> understand right they would suggest a libc compatibility issue ... ? > > Folks, could I ping on the above? > > It seems like a rather severe limitation on the universality of > the package (at > a minimum it probably restricts the package to working on > systems with the same > or later libc) so I'm curious if anyone has any thoughts on if > and how this > could be ameliorated. I'll check your snap first thing once I am at a computer again. From experience with classic confinement though, stage-packages to provide runnables are most of the time the root cause. There was discusssion on having ld set --library-path in be core snap to have called binaries not reach out to the system and get confused. Zygmunt, any update on that? -- Enviado con Dekko desde mi dispositivo Ubuntu From sunny.bhayani at einfochips.com Thu Feb 16 10:16:14 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Thu, 16 Feb 2017 10:16:14 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support Message-ID: Hi Paolo, Thank you for your reply. > On Thu, Feb 09, 2017 at 06:13:15AM +0000, Sunny Bhayani wrote: > > > > > the work is going on here: > > > > > > https://github.com/snapcore/snapcraft/pull/1115 > > > > Is there a way, that we can come to know about an official fix, apart from the > > above link that you mentioned. > > If you don't want to wait for a release, you can clone the snapcraft > repository[1] and apply the above fix locally: > > git clone https://github.com/snapcore/snapcraft.git We are able to apply your fix locally, and now we are getting the /lib/firmware and /lib/modules with the required files. We are able to make our Wifi work by doing insmod wcn36xx.ko, and doing the echo start > /sys/kernel/debug/remoteproc/remoteproc2/state. We have a question regarding the above step. In the Dragonboard prebuilt rootfs, there are scripts which actually inserts the Wifi module during boot. Those scripts are located at /lib/systemd/system/wcnss-start.service. These scripts actually start the wifi interface. But in our case, we have to manually do this. So how can we add new scripts to the RootFS in our case as compared to the prebuilt Dragonboard binary ? One more observation is, that due to the above scripts present in the prebuilt Dragonboard binary, during the first boot console config, we get to configure the wifi interface along with the eth0 interface, which is also missing in our case. > > Also, how did the build for the Dragonboard410C succeed for the pre-built > > Ubuntu Core OS image ? > > > > Since that is working properly, /lib/modules have the kernel modules and > > /lib/firmware has the firmware binaries. > > > > Also, the wifi interface (wlan0) is working. > > > > Sorry, but I was just curious to know this. > > The kernel snaps for the dragonboard (and the raspberry and pc), are generated > from the deb packages in our archive, using this script: > > https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial > > Starting from the snapdragon branch, the snapcraft.yaml there invokes the > Makefile in the master branch. > > This was done to use the x86 signed kernels (required for trusted boot), and the same mechanism > was reused for arm. > > But for development, snapcratf and the kernel plugin are the way to go. > > 1: https://github.com/snapcore/snapcraft So we understand the snapcraft and kernel plugin should be used for development. But by applying the patches (fix) that you gave, we still are not able to do "snap list" and "snap install hello-world". It would be really great if you can help for both the RootFS (scripts) and the snap list / install issues. Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Thu Feb 16 10:27:39 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Thu, 16 Feb 2017 13:27:39 +0300 Subject: plugin for browser Message-ID: <0138d661-a40e-6f39-c7d1-fd1358b35db1@gmail.com> Silly idea. Whether it is possible to connect a plugin (in snap) to the browser Firefox (install from deb)? -- Best regards, vasilisc From ogra at ubuntu.com Thu Feb 16 10:42:15 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 16 Feb 2017 11:42:15 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: Message-ID: <1487241735.11011.10.camel@ubuntu.com> hi, Am Donnerstag, den 16.02.2017, 10:16 +0000 schrieb Sunny Bhayani: >  > We are able to make our Wifi work by doing insmod wcn36xx.ko, and > doing the  > echo start > /sys/kernel/debug/remoteproc/remoteproc2/state. > > We have a question regarding the above step. In the Dragonboard > prebuilt rootfs, > there are scripts which actually inserts the Wifi module during boot. > Those  > scripts are located at /lib/systemd/system/wcnss-start.service. > > These scripts actually start the wifi interface. > > But in our case, we have to manually do this. So how can we add new > scripts to  > the RootFS in our case as compared to the prebuilt Dragonboard binary > ? > you should not need to do that, we definitely do not have such scripts in our official images: ogra at dragonboard:~$ ls /lib/systemd/system/wcnss-start.service ls: cannot access '/lib/systemd/system/wcnss-start.service': No such file or directory the module should be auto-loaded during boot (this happens surely for us with the default ubuntu core images). there must be something wrong with your setup ...  here is a boot log from a default ubuntu core dragonboard image http:// paste.ubuntu.com/24006524/ there wcn36xx just gets auto-loaded, perhaps you miss a kernel configuration ? > One more observation is, that due to the above scripts present in the > prebuilt  > Dragonboard binary, during the first boot console config, we get to > configure  > the wifi interface along with the eth0 interface, which is also > missing in our  > case. there is no ethernet device on a dragonboard, do you use an addon board ? ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From facundo.batista at canonical.com Thu Feb 16 14:13:06 2017 From: facundo.batista at canonical.com (Facundo Batista) Date: Thu, 16 Feb 2017 11:13:06 -0300 Subject: Announcing channel tracks for long-term stable snaps In-Reply-To: <20170215183618.nj2yvk7favzmpkfx@castiana> References: <20170215183618.nj2yvk7favzmpkfx@castiana> Message-ID: <296442be-c972-0d1c-f385-55a965f81c6f@canonical.com> El 15/02/17 a las 15:36, Stéphane Graber escribió: > Hey there, > > Are tracks supported in Launchpad? > > I'd like to use this feature for the LXD 2.0 (LTS) branch, but we're > building and publishing (except for stable) all our snaps through > Launchpad as we need support for all architectures. Hey! Not yet, but we'll be working on this very soon. Thanks! Regards, -- . Facundo . Canonical - Online Services From michael.vogt at canonical.com Thu Feb 16 14:55:03 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Thu, 16 Feb 2017 15:55:03 +0100 Subject: New stable "core" and "ubuntu-core" snaps released Message-ID: <20170216145503.GK15361@bod> Hello, The Snappy team is happy to announce the promotion of snapd 2.22.2 from the candidate channel to stable in both the "core" and "ubuntu-core" snaps. It will also be available via the regular apt update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other distributions will follow on their own schedule. As a reminder 2.22.2 brings with it: - automatically transition ubuntu-core snaps to core - support for X-Ayatana-Desktop-Shortcuts in desktop files - improve retry handling on network errors further - support for disabling sshd from the core config - support new "reload-command" in snap.yaml - fix snap try with classic confinement - many more bugfixes - interface improvements: - opengl, default, network-control, network-manager - new interfaces: - unity8-download-manager, evolution, account-control, core-support Due to the power of Ubuntu Core, your device will update and reboot automatically so there is nothing for you to do :) Please let us know if you notice any issues and enjoy the new release! Cheers, Michael (on behalf of the snappy team) From xiaoguo.liu at canonical.com Thu Feb 16 15:12:08 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 16 Feb 2017 23:12:08 +0800 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: <20170216145503.GK15361@bod> References: <20170216145503.GK15361@bod> Message-ID: Thanks. May I know what is the "reload-command" for in the snap.yaml? How to make use of it in the snapcraft.yaml? Best regards, XiaoGuo On Thu, Feb 16, 2017 at 10:55 PM, Michael Vogt wrote: > Hello, > > The Snappy team is happy to announce the promotion of snapd 2.22.2 > from the candidate channel to stable in both the "core" and > "ubuntu-core" snaps. It will also be available via the regular apt > update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other distributions > will follow on their own schedule. > > As a reminder 2.22.2 brings with it: > > - automatically transition ubuntu-core snaps to core > - support for X-Ayatana-Desktop-Shortcuts in desktop files > - improve retry handling on network errors further > - support for disabling sshd from the core config > - support new "reload-command" in snap.yaml > - fix snap try with classic confinement > - many more bugfixes > - interface improvements: > - opengl, default, network-control, network-manager > - new interfaces: > - unity8-download-manager, evolution, account-control, > core-support > > Due to the power of Ubuntu Core, your device will update and reboot > automatically so there is nothing for you to do :) > > Please let us know if you notice any issues and enjoy the new release! > > Cheers, > Michael (on behalf of the snappy team) > > > -- > Devices mailing list > Devices at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.snapcraft.io/ > mailman/listinfo/devices > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.brustkern at canonical.com Thu Feb 16 20:15:13 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Thu, 16 Feb 2017 15:15:13 -0500 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: <20170216145503.GK15361@bod> References: <20170216145503.GK15361@bod> Message-ID: On Thu, Feb 16, 2017 at 9:55 AM, Michael Vogt wrote: > Hello, > > The Snappy team is happy to announce the promotion of snapd 2.22.2 > from the candidate channel to stable in both the "core" and > "ubuntu-core" snaps. It will also be available via the regular apt > update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other distributions > will follow on their own schedule. > > I'd like to trigger tests to run when new core snaps are available in the stable and candidate channels. What's the best way to check that? Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Thu Feb 16 23:11:13 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 16 Feb 2017 17:11:13 -0600 Subject: pro tip: use scriptlets instead of custom plugins Message-ID: Hello! This week I've been cleaning a few of my old snaps, using some of the new features in more recent versions of snapcraft. At first I wasn't convinced about scriptlets, but now I think they are great. Take a look at this diff: 5 additions and 144 deletions https://github.com/elopio/ipfs-snap/commit/06f32696c1b461b1068e803e71e22bad50fe52eb Here is more info: https://insights.ubuntu.com/2017/02/02/run-scripts-during-snapcraft-builds-with-scriptlets/ pura vida. -- ¡paz y baile! http://www.ubuntu.com From joseph.wakeling at webdrake.net Thu Feb 16 23:57:06 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 17 Feb 2017 00:57:06 +0100 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: On 17/02/17 00:11, Leo Arias wrote: > This week I've been cleaning a few of my old snaps, using some of the > new features in more recent versions of snapcraft. At first I wasn't > convinced about scriptlets, but now I think they are great. Take a > look at this diff: Thanks so much for that tip -- the announcement of that feature had passed me by, but I was able to similarly greatly simplify a snap package that had also previously required a custom plugin: https://github.com/WebDrake/dub.snap/pull/5 From casey.marshall at canonical.com Fri Feb 17 01:59:07 2017 From: casey.marshall at canonical.com (Casey Marshall) Date: Thu, 16 Feb 2017 19:59:07 -0600 Subject: Github badges? Message-ID: I'd like to show off snaps for my Github projects with a nifty little badge, like Travis CI, Appveyor, godoc, crates.io. It could have the snap version in it, and link to a nice simple landing page with release history, instructions on to install the snap, stuff like that. Are there any plans for this? Are badges already a thing and I'm just missing out? -Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik at canonical.com Fri Feb 17 03:20:48 2017 From: manik at canonical.com (Manik Taneja) Date: Thu, 16 Feb 2017 19:20:48 -0800 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170216145503.GK15361@bod> Message-ID: On Thu, Feb 16, 2017 at 12:15 PM, Max Brustkern wrote: > > > On Thu, Feb 16, 2017 at 9:55 AM, Michael Vogt > wrote: > >> Hello, >> >> The Snappy team is happy to announce the promotion of snapd 2.22.2 >> from the candidate channel to stable in both the "core" and >> "ubuntu-core" snaps. It will also be available via the regular apt >> update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other distributions >> will follow on their own schedule. >> >> > I'd like to trigger tests to run when new core snaps are available in the > stable and candidate channels. What's the best way to check that? > i suspect that you will like to run tests after installing a newer rev of a snap from the candidate/stable channels. at the moment, i believe your best option is to poll the store for a newer revision. once available, update the device explicitly using snap refresh and than run whatever tests you like. if its a snap that you published yourself, you could run hooks on install automatically that can trigger whatever tests you like. moving forward, we will need to work on a better approach via push-notifications (perhaps) that will tell a device about a new revision and also allow the capability to install it immediately, instead of waiting for the next update-timer to kick in. /manik -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunny.bhayani at einfochips.com Fri Feb 17 10:06:48 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Fri, 17 Feb 2017 10:06:48 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support Message-ID: Hi Ogra, Thank you for your reply. > hi, > Am Donnerstag, den 16.02.2017, 10:16 +0000 schrieb Sunny Bhayani: > > > > We are able to make our Wifi work by doing insmod wcn36xx.ko, and > > doing the > > echo start > /sys/kernel/debug/remoteproc/remoteproc2/state. > > > > We have a question regarding the above step. In the Dragonboard > > prebuilt rootfs, > > there are scripts which actually inserts the Wifi module during boot. > > Those > > scripts are located at /lib/systemd/system/wcnss-start.service. > > > > These scripts actually start the wifi interface. > > > > But in our case, we have to manually do this. So how can we add new > > scripts to > > the RootFS in our case as compared to the prebuilt Dragonboard binary > > ? > > > you should not need to do that, we definitely do not have such scripts > in our official images: > > ogra at dragonboard:~$ ls /lib/systemd/system/wcnss-start.service > ls: cannot access '/lib/systemd/system/wcnss-start.service': No such > file or directory > > the module should be auto-loaded during boot (this happens surely for > us with the default ubuntu core images). there must be something wrong > with your setup ... > here is a boot log from a default ubuntu core dragonboard image http:// > paste.ubuntu.com/24006524/ there wcn36xx just gets auto-loaded, perhaps > you miss a kernel configuration ? Sorry for the wrong information. The above scripts are present in the Linaro (Debian) release of Dragonboard. You are correct that in the prebuilt image (Ubuntu OS) for Dragonboard, the Wifi module is auto-loaded during boot. But in our case, this does not happen. So can you please let us know, that in what part (plugin) of the snapcraft.yaml do we need to mention the kernel modules that needs to be auto-loaded during the kernel boot. We tried to add the kernel module in the snapcraft.yaml as below: kernel-initrd-modules: - squashfs - wcn36xx This did not auto-insert / auto-load the Wifi module during the first boot. Also, we went through the kernel-initrd-modules description: https://snapcraft.io/docs/reference/plugins/kernel and there it is mentioned that the "kernel-initrd-modules" plugin is used to mention the modules required to mount the rootfs. So can you please help us out for the same. Also, if we want to add any scripts to the rootfs while building / compiling the Ubuntu OS Image, is there a way in which we can do that ? > > One more observation is, that due to the above scripts present in the > > prebuilt > > Dragonboard binary, during the first boot console config, we get to > > configure > > the wifi interface along with the eth0 interface, which is also > > missing in our > > case. > It would be great if you can please help us out on this front as well for the snap list / snap install for the Ubuntu OS. > there is no ethernet device on a dragonboard, do you use an addon board > ? Yes. We are using a USB to Ethernet module on dragonboard to use the Ethernet. While using the prebuilt image for Dragonboard, we are able to configure the access point for Wifi interface in the first boot screen, but then while doing ssh to the board, it is asking for password (during first boot). How can we resolve this ? Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Fri Feb 17 10:13:50 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 17 Feb 2017 10:13:50 +0000 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170216145503.GK15361@bod> Message-ID: <6aed4e16-47d0-dda2-1341-d6e93c0c393c@ubuntu.com> We do anticipate being able to send a message to devices that want to know when a new version of a snap is available in a particular channel. We call it 'real-time refresh' because it would enable the subscribing devices to refresh themselves the instant a new version of the snap was released. In this case, what's interesting is that you want to KNOW that the new version is released, but then drive a process which is not simplistically "refresh this device". Still, the message could serve as the trigger - you have a device which is getting these real-time notifications, and you hook into the event to then trigger your test suites. Essentially, you would have a canary device which gets the real-time refresh, and then triggers your test suites. I think it's appropriate that we have an interface to snapd which is a stream of events, like "I just refreshed this snap". You could tap that stream for the new snap notice, and then trigger your test suites. Mark On 17/02/17 03:20, Manik Taneja wrote: > > > On Thu, Feb 16, 2017 at 12:15 PM, Max Brustkern > > wrote: > > > > On Thu, Feb 16, 2017 at 9:55 AM, Michael Vogt > > > wrote: > > Hello, > > The Snappy team is happy to announce the promotion of snapd 2.22.2 > from the candidate channel to stable in both the "core" and > "ubuntu-core" snaps. It will also be available via the regular apt > update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other > distributions > will follow on their own schedule. > > > I'd like to trigger tests to run when new core snaps are available > in the stable and candidate channels. What's the best way to check > that? > > i suspect that you will like to run tests after installing a newer rev > of a snap from the candidate/stable channels. at the moment, i believe > your > best option is to poll the store for a newer revision. once available, > update the device explicitly using snap refresh and than > run whatever tests you like. if its a snap that you published > yourself, you could run hooks on install automatically that can > trigger whatever tests you like. > moving forward, we will need to work on a better approach via > push-notifications (perhaps) that will tell a device about a new > revision and also allow > the capability to install it immediately, instead of waiting for the > next update-timer to kick in. > > /manik > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Feb 17 10:24:15 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 17 Feb 2017 11:24:15 +0100 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: <1487327055.11011.12.camel@ubuntu.com> hi, Am Donnerstag, den 16.02.2017, 17:11 -0600 schrieb Leo Arias: > Hello! > > This week I've been cleaning a few of my old snaps, using some of the > new features in more recent versions of snapcraft. At first I wasn't > convinced about scriptlets, but now I think they are great. Take a > look at this diff: > > 5 additions and 144 deletions > > https://github.com/elopio/ipfs-snap/commit/06f32696c1b461b1068e803e71 > e22bad50fe52eb > > Here is more info: > https://insights.ubuntu.com/2017/02/02/run-scripts-during-snapcraft-b > uilds-with-scriptlets/ > > pura vida. SO SHINY !!!!! ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Fri Feb 17 10:30:33 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 17 Feb 2017 11:30:33 +0100 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170216145503.GK15361@bod> Message-ID: <1487327433.11011.15.camel@ubuntu.com> Am Donnerstag, den 16.02.2017, 15:15 -0500 schrieb Max Brustkern: > > > On Thu, Feb 16, 2017 at 9:55 AM, Michael Vogt .com> wrote: > > Hello, > > > > The Snappy team is happy to announce the promotion of snapd 2.22.2 > > from the candidate channel to stable in both the "core" and > > "ubuntu-core" snaps. It will also be available via the regular apt > > update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other > > distributions > > will follow on their own schedule. > > > I'd like to trigger tests to run when new core snaps are available in > the stable and candidate channels. What's the best way to check that? > this is what "snap refresh --list" can be used for i belive ... turn off the snapd.refresh.timer via systemctl, then have a cron script polling the status with "snap refresh --list" might work (untested) until snapd can provide such a feature on its own. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From evan.dandrea at canonical.com Fri Feb 17 11:01:10 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Fri, 17 Feb 2017 11:01:10 +0000 Subject: Github badges? In-Reply-To: References: Message-ID: On Fri, 17 Feb 2017 at 01:59 Casey Marshall wrote: > I'd like to show off snaps for my Github projects with a nifty little > badge, like Travis CI, Appveyor, godoc, crates.io. > > It could have the snap version in it, and link to a nice simple landing > page with release history, instructions on to install the snap, stuff like > that. > > Are there any plans for this? Are badges already a thing and I'm just > missing out? > Yup! We have plans to create a badge that will take you to the snap builds page, which includes instructions on how to snap install the tip of git master. We'll announce that here when it's ready. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Feb 17 11:27:46 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 17 Feb 2017 12:27:46 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: Message-ID: <1487330866.11011.33.camel@ubuntu.com> hi, Am Freitag, den 17.02.2017, 10:06 +0000 schrieb Sunny Bhayani: >  > > You are correct that in the prebuilt image (Ubuntu OS) for > Dragonboard, the Wifi  > module is auto-loaded during boot. But in our case, this does not > happen. > > So can you please let us know, that in what part (plugin) of the > snapcraft.yaml > do we need to mention the kernel modules that needs to be auto-loaded > during the  > kernel boot. > > We tried to add the kernel module in the snapcraft.yaml as below: > >   kernel-initrd-modules: >              - squashfs >              - wcn36xx this would just pull the module into the initrd which would be useless, since we do not ship any userspace bits for WIFI support in there. if you can modprobe it it is obviously already in the right place in your /lib/modules dir on the booted system, so first of all remove it from the list above. having it already loaded from the initrd on boot might make it miss the right initialization since it wont find all the userspace bits that it needs in the initrd. also make sure you have the firmware in the right place on the booted rootfs, this is how it looks like on the official dragoboard image: http://paste.ubuntu.com/24012991/ > > Also, we went through the kernel-initrd-modules description: > https://snapcraft.io/docs/reference/plugins/kernel > > and there it is mentioned that the "kernel-initrd-modules" plugin is > used to  > mention the modules required to mount the rootfs. this means filesystem or disk controller modules (squashfs, ext4 (if you do not compile it in), mmc support and the like), since your system boots to a rootfs already you should not need anything more than you currently have. > >  > > It would be great if you can please help us out on this front as well > for the  > snap list / snap install for the Ubuntu OS. this definitely means that snapd did not start for some reason, like i mentioned before this could be caused by the firstboot initialization of the board having failed or by some missing feature that snapd expects from your kernel. does sudo journalctl -u snapd.service reveal anything ? do you find anything interesting in syslog in general ? > >  > Yes. We are using a USB to Ethernet module on dragonboard to use the > Ethernet. > did you check if  the behaviour of the WLAN device changes when booting without the USB dongle attached ? > While using the prebuilt image for Dragonboard, we are able to > configure the  > access point for Wifi interface in the first boot screen, but then > while doing  > ssh to the board, it is asking for password (during first boot). How > can we  > resolve this ? > did console-conf (the first boot configuration UI) actually finish the user creation properly (did it tell you about it and give you info about how to ssh into the board) without any errors ? /var/log/console-conf/subiquity-debug.log might be informative here. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jamie.bennett at canonical.com Fri Feb 17 12:04:03 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Fri, 17 Feb 2017 12:04:03 +0000 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: <1487327433.11011.15.camel@ubuntu.com> References: <20170216145503.GK15361@bod> <1487327433.11011.15.camel@ubuntu.com> Message-ID: <20170217120403.jzth2cpc24efr27c@orwell> On 17/02/17 at 11:30am, Oliver Grawert wrote: > Am Donnerstag, den 16.02.2017, 15:15 -0500 schrieb Max Brustkern: > > > > > > On Thu, Feb 16, 2017 at 9:55 AM, Michael Vogt > .com> wrote: > > > Hello, > > > > > > The Snappy team is happy to announce the promotion of snapd 2.22.2 > > > from the candidate channel to stable in both the "core" and > > > "ubuntu-core" snaps. It will also be available via the regular apt > > > update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other > > > distributions > > > will follow on their own schedule. > > > > > I'd like to trigger tests to run when new core snaps are available in > > the stable and candidate channels. What's the best way to check that? > > > > this is what "snap refresh --list" can be used for i belive ... > > turn off the snapd.refresh.timer via systemctl, then have a cron script > polling the status with "snap refresh --list" might work (untested) > until snapd can provide such a feature on its own. The systemd timer has gone away in favour of an internal timer in snapd so this will no longer work. > ciao > oli Regards, Jamie. From sergio.schvezov at canonical.com Fri Feb 17 12:49:11 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 17 Feb 2017 12:49:11 +0000 Subject: snapcraft 2.27 has been released Message-ID: Hello snapcrafters! We are pleased to announce the release of snapcraft `2.27`: https://launchpad.net/snapcraft/+milestone/2.27 This release is now available to users on Xenial Xerus, Yakkety Yak and Zesty Zapus. The pretty version of these notes can be found on https://github.com/snapcore/snapcraft/releases/tag/2.27 # Contributions This release has seen some contributions from outside of the snapcraft core team, so we want to give a shout out to these folks, here's a team thank you for: - Colin Watson - John Lenton - Kit Randel - Loïc Minier - Marco Trevisan - elespike # New in this release ## Faster iteration This release brings in many features to speed up development and iteration, the biggest under the covers improvement is caching of `stage-packages` works correctly again succesive pull steps including a repeated set of stage-packages will be a breeze. The other improvment is that delta uploads are now possible, it is currenly disabled but can be toggled by a feature flag in the environment, just set `DELTA_UPLOADS_EXPERIMENTAL=1` and enjoy the benefits. The tentative plan is for this to be the default in snapcraft 2.28 ## classic confinement Improvements have been made to the experimental `classic` confinement build setup to be more robust and reliable. These improvements allow to build `classic` confined snaps that work across a wider set of OS releases (particularly those with differing glibc versions). An early adopter of this work is *conjure-up* which now sports Trusty Tahr support. Learn more about conjure-up by visiting http://conjure-up.io/ ### python plugin The python plugin has also received some attention with regards to `classic` confinement. Most importantly it now does not leak any variables specific to the plugin into the environment. Another improvement that has been made is that the plugin is now capable of detecting already staged interpreter instances and use that instead of providing one itself. This allows one to choose their own interpreter (which is important for classic confined snaps until the core snap implements use of `--library-path` for `ld`). Making use of your own interpreter is really easy as it uses the common language already implemented in snapcraft (the plugin is just now smarter), here's a snippet: ```yaml parts: my-python-app: source: ... plugin: python after: [python] python: source: https://www.python.org/ftp/python/3.6.0/Python-3.6.0.tar.xz plugin: autotools configflags: [--prefix=/usr] build-packages: [libssl-dev] prime: - -usr/include ``` And with that you get to use python 3.6.0 in your snap! ### CI builds Previous to snapcraft 2.27 it was not possible to build on non `snapd` enabled environments as the core snap needs to be available on the system where the `classic` confined snap is to be built. From this version onwards it should be possible to build `classic` confined snaps either with `cleanbuild` or Launchpad builders as snapcraft is hinted about the environment and sets up `core` accordingly. ## Building on other `lxd` remotes A simple but useful feature is offloading builds to different instances, with that in mind one can now offload `cleanbuild` executions onto other `lxd` remotes. It is as simple as ``` snapcraft cleanbuild --remote my-remote ``` To create `my-remote` just follow the setup instructions on https://linuxcontainers.org/lxd/getting-started-cli/#multiple-hosts ## Setting up environment No more wrapper scripts just to setup on environment entry, this is now tied into an app entry in `apps`. Here's a quick example: ```yaml apps: vim: command: bin/vim environment: VIMRUNTIME: $SNAP/share/vim/vim80 ``` ## Releasing to channel tracks Releasing to tracks worked out of the box, this is a user experience improvement on the result one sees when trying do to so. If you are wondering what tracks are, here's a simple explanation, they are like a Long Term Support channel added to your regular stability level channels (i.e.; `stable`, `candidate`, `beta`, `edge`), this is useful for cases where some users need to stick to a major version number such as the case of `etcd` where some might want to stick to `2.3` while others are happy with tracking `latest` (which is an implicit track). >From a snap developer point of view, here's how to push and release to `edge` on the `0.2` track, ``` $ snapcraft push hello_0.3_amd64.snap --release 0.2/edge Pushing 'hello_0.3_amd64.snap' to the store. Uploading hello_0.3_amd64.snap [==============================================] 100% Ready to release! Revision 3 of 'hello' created. Arch Track Series Channel Version Revision amd64 0.2 16 stable - - candidate - - beta - - edge 0.3 3 ``` And here's how you would release, ``` $ snapcraft release hello 3 0.2/beta Arch Track Series Channel Version Revision amd64 0.2 16 stable - - candidate - - beta 0.3 3 edge 0.3 3 The '0.2/beta' channel is now open. ``` ## Others For the full list of things available on 2.27 feel free to check https://launchpad.net/snapcraft/+milestone/2.27 # Final Notes To get the source for this release check it out at https://github.com/snapcore/snapcraft/releases/tag/2.27 A great place to collaborate and discuss features, bugs and ideas on snapcraft is snapcraft at lists.snapcraft.io mailing list or on the snapcraft channel on Rocket Chat https://rocket.ubuntu.com/channel/snapcraft To file bugs, please go to https://bugs.launchpad.net/snapcraft/+filebug. Happy snapcrafting! -- Sergio and the team -- From ogra at ubuntu.com Fri Feb 17 13:00:01 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 17 Feb 2017 14:00:01 +0100 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: <20170217120403.jzth2cpc24efr27c@orwell> References: <20170216145503.GK15361@bod> <1487327433.11011.15.camel@ubuntu.com> <20170217120403.jzth2cpc24efr27c@orwell> Message-ID: <1487336401.11011.37.camel@ubuntu.com> hi, Am Freitag, den 17.02.2017, 12:04 +0000 schrieb Jamie Bennett: >  > The systemd timer has gone away in favour of an internal timer in > snapd so > this will no longer work. > i dont think that has landed yet [1] ...  ogra at dragonboard:~$ snap get core refresh.schedule error: snap "core" has no "refresh.schedule" configuration option ogra at dragonboard:~$ snap info core|grep tracking tracking:    edge but once it has you should be able to just unset the core config option instead of disabling the systemd timer to not interfere with any cron based bits. ciao oli [1] https://github.com/snapcore/snapd/pull/2833 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jamie.bennett at canonical.com Fri Feb 17 13:21:10 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Fri, 17 Feb 2017 13:21:10 +0000 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: <1487336401.11011.37.camel@ubuntu.com> References: <20170216145503.GK15361@bod> <1487327433.11011.15.camel@ubuntu.com> <20170217120403.jzth2cpc24efr27c@orwell> <1487336401.11011.37.camel@ubuntu.com> Message-ID: Sorry, yes, it will land with snapd 2.23 today hence why the timer should not be relied upon. Regards, Jamie. On Fri, Feb 17, 2017 at 1:00 PM, Oliver Grawert wrote: > hi, > Am Freitag, den 17.02.2017, 12:04 +0000 schrieb Jamie Bennett: >> >> The systemd timer has gone away in favour of an internal timer in >> snapd so >> this will no longer work. >> > > i dont think that has landed yet [1] ... > > ogra at dragonboard:~$ snap get core refresh.schedule > error: snap "core" has no "refresh.schedule" configuration option > ogra at dragonboard:~$ snap info core|grep tracking > tracking: edge > > but once it has you should be able to just unset the core config option > instead of disabling the systemd timer to not interfere with any cron > based bits. > > ciao > oli > > [1] https://github.com/snapcore/snapd/pull/2833 > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From ogra at ubuntu.com Fri Feb 17 13:29:55 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 17 Feb 2017 14:29:55 +0100 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170216145503.GK15361@bod> <1487327433.11011.15.camel@ubuntu.com> <20170217120403.jzth2cpc24efr27c@orwell> <1487336401.11011.37.camel@ubuntu.com> Message-ID: <1487338195.11011.39.camel@ubuntu.com> hi, Am Freitag, den 17.02.2017, 13:21 +0000 schrieb Jamie Bennett: > Sorry, yes, it will land with snapd 2.23 today hence why the timer > should not be relied upon. > well, i just learned on IRC that the timer is already gone but the config option is not there yet, so currently you cant really intercept auto-upgrades i fear. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From maciej.kisielewski at canonical.com Fri Feb 17 14:06:38 2017 From: maciej.kisielewski at canonical.com (Maciej Kisielewski) Date: Fri, 17 Feb 2017 15:06:38 +0100 Subject: Access denied on dbus for MM with plug connected Message-ID: Hey folks! There is a problem when I talk to ModemManager via dbus from Checkbox. At first I thought there was something wrong with how we're controlling the execution from Checkbox, but right now, it boils down to: checkbox-snappy.python3 -c "import dbus; dbus.Interface(dbus.SystemBus().get_object('org.freedesktop.ModemManager1', '/org/freedesktop/ModemManager1'), 'org.freedesktop.DBus.ObjectManager').GetManagedObjects()" raising DBusException [2] That python3 'app' has `modem-manager` plug declared, and connected. The same command run with sudo runs ok. Any thoughts what I'm doing wrong, or is it a genuine bug in snapd? [1] https://bugs.launchpad.net/snapd/+bug/1659272 [2] http://paste.ubuntu.com/24013610/ -- Have a good one, Maciek -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Fri Feb 17 14:30:27 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 17 Feb 2017 15:30:27 +0100 Subject: After last "snap refresh" problem with contents of /writable/system-data/etc/iproute2. Message-ID: Hi all I was in need to modify the file /etc/iproute2/rt_tables, but it was read-only on previous versions of the "core" snap. As a workaround, I was manually doing a bind-mount from the file /writable/system-data/etc/iproute2/rt_tables to the location /etc/iproute2/rt_tables. When I did last "snap refresh" to my ubuntu core it seems to me that there is now a permanent bind-mount from the directory /writable/system-data/etc/iproute2 to the location /etc/iproute2. But now I have only one file in /etc/iproute2. luca-dionisi at localhost:/etc/iproute2$ ls rt_tables Is it normal or is it due to my previous workaround? If so, what are my options to revert things? --Luca From paul.larson at canonical.com Fri Feb 17 14:41:10 2017 From: paul.larson at canonical.com (Paul Larson) Date: Fri, 17 Feb 2017 08:41:10 -0600 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170216145503.GK15361@bod> Message-ID: On Thu, Feb 16, 2017 at 2:15 PM, Max Brustkern wrote: > > > On Thu, Feb 16, 2017 at 9:55 AM, Michael Vogt > wrote: >> >> Hello, >> >> The Snappy team is happy to announce the promotion of snapd 2.22.2 >> from the candidate channel to stable in both the "core" and >> "ubuntu-core" snaps. It will also be available via the regular apt >> update mechanism in Ubuntu 14.04, 16.04 and 16.10. Other distributions >> will follow on their own schedule. >> > > I'd like to trigger tests to run when new core snaps are available in the > stable and candidate channels. What's the best way to check that? We're doing this right now with core on devices, along with other snaps that are relevant to the product. Each time there's an update in candidate, it gets installed with the latest image, all snaps get updated in stable to the latest version, and the candidate snap that we want to test is refreshed with --candidate. We run checkbox for our tests through testflinger, but there's no reason why you couldn't run spread, or anything else you like. What we do to detect the new version in candidate is to simply trigger off of something like this: $ curl -s -H "X-Ubuntu-Series: 16" -H "X-Ubuntu-Architecture: amd64" https://search.apps.ubuntu.com/api/v1/snaps/details/core?fields=name,revision\&channel=candidate | sed -e 's|.*\"revision\": \([0-9]*\)[^0-9]|\1|' You can replace "core" above with any other snap name you want to check, and 'candidate' with another channel if you like. You could run this in jenkins (or even cron) and when this returns a new revision number, the test gets kicked off automagically. From jamie at canonical.com Fri Feb 17 14:45:50 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 17 Feb 2017 08:45:50 -0600 Subject: Access denied on dbus for MM with plug connected In-Reply-To: References: Message-ID: <1487342750.5211.9.camel@canonical.com> On Fri, 2017-02-17 at 15:06 +0100, Maciej Kisielewski wrote: > Hey folks! > > There is a problem when I talk to ModemManager via dbus from Checkbox. > At first I thought there was something wrong with how we're controlling > the execution from Checkbox, but right now, it boils down to: > > checkbox-snappy.python3 -c "import dbus; > dbus.Interface(dbus.SystemBus().get_object('org.freedesktop.ModemManager1', > '/org/freedesktop/ModemManager1'), > 'org.freedesktop.DBus.ObjectManager').GetManagedObjects()" > raising DBusException [2] > > That python3 'app' has `modem-manager` plug declared, and connected. > The same command run with sudo runs ok. > > Any thoughts what I'm doing wrong, or is it a genuine bug in snapd? > > [1] https://bugs.launchpad.net/snapd/+bug/1659272 > [2] http://paste.ubuntu.com/24013610/ > You aren't doing anything wrong. The modem-manager interface has this for its dbus bus policy:                                                                                             This is saying that you must be root to use modem-manager. This is written this way here (and other system services) so that non-root logged in users can't perform privileged operations via the interfaces. The very simplistic policy is a result of polkit not being available in core yet. polkit is something the Personal team is looking at enabling in snappy. Once polkit is available, then that allows for the various fine-grained access controls polkit offers. --  Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From didrocks at ubuntu.com Fri Feb 17 14:47:48 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 17 Feb 2017 15:47:48 +0100 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: References: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> <0dc231f8-26fc-d929-faef-7f28e1b8850d@ubuntu.com> <0afec719-2791-b5cd-e138-0d0a68d0b412@ubuntu.com> Message-ID: Le 15/02/2017 à 16:33, Simos Xenitellis a écrit : > On Mon, Feb 13, 2017 at 7:13 PM, Didier Roche wrote: >> Le 10/02/2017 à 17:30, Simos Xenitellis a écrit : >>> I managed to complete the conversion and the tutorial is ready :-). >>> >>> Here it is, >>> https://docs.google.com/document/d/1Nk-kw79lt84YJNEKS_WpnGzVSjrmCUVd1TsAx5aRoOA/ >>> Feel free to add to tutorials.ubuntu.com or make a copy in order to edit. >>> >>> Overall, the experience in converting to the format required by >>> codelabs was interesting. >>> I still need more practice before I would be able to write a tutorial >>> in one go in the codelab style. >> This really looks awesome! Thanks Simos :) >> >> I'll add some very small tweaking, but after a first look, it's very a >> nice first shot. Well done :) > >> I'll keep you posted with a diff so that you can see what small >> modifications I made to be more coherent with the other ones. >> > Thanks, looking forward to reading the changes. And here we go: https://docs.google.com/document/d/1cvXAZRkmKExNIOXMUQihQrd8dNZK6f8v4wk020NymuI/edit#. I did find your tutorial to be so good, that I changed its destination to be the default "use python plugin" one. Due to that, I removed the "explain what snap/snapcraft is and publish to the store" parts, as they are already covered in other base tutorials (and we want to create a coherent story). I added of course the pre-requisite on them and formatted some stuff to be inline with our current one. Note, this is a draft, I didn't take the time to reread it yet (so probably, a lot of typos and such, but I prefer to reread it on Monday with a clear brain and fresh eye on this). I tried to explain the major difference I've made (and what did divert originaly from the tutorials guidelines) as comments on the doc. Do not hesitate to ask (the document is opened for comments) if anything isn't clear or if you have ideas to improve it. I hope most of my changes and my comments will make sense. If you feel those changes are good, we can publish it next week, and wait eagerly for your next tutorial! (Maybe we can work together on deciding first the layout, main titles and separations if you want) Thanks again for your awesome work here! Cheers, Didier From ogra at ubuntu.com Fri Feb 17 14:49:32 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 17 Feb 2017 15:49:32 +0100 Subject: After last "snap refresh" problem with contents of /writable/system-data/etc/iproute2. In-Reply-To: References: Message-ID: <1487342972.11011.45.camel@ubuntu.com> hi, Am Freitag, den 17.02.2017, 15:30 +0100 schrieb Luca Dionisi: > Hi all > > I was in need to modify the file /etc/iproute2/rt_tables, but it was > read-only on previous versions of the "core" snap. > As a workaround, I was manually doing a bind-mount from the file > /writable/system-data/etc/iproute2/rt_tables to the location > /etc/iproute2/rt_tables. > > When I did last "snap refresh" to my ubuntu core it seems to me that > there is now a permanent bind-mount from the directory > /writable/system-data/etc/iproute2 to the location /etc/iproute2. > > But now I have only one file in /etc/iproute2. >   luca-dionisi at localhost:/etc/iproute2$ ls >   rt_tables > > Is it normal or is it due to my previous workaround? > If so, what are my options to revert things? > this is due to your former tinkering and us making the location writable by default at the same time. back up your changed rt_tables file, then unmount /etc/iproute2 ... the original files of the directory should show up after this ...  now you can cp them to /writable/system-data/etc/iproute2, copy your modified rt_tables there as well and you should be fine after a reboot ... sorry, we dont really have protection against people manually bind- mounting rw files on top of readonly dirs when we make them writable. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From luca.dionisi at gmail.com Fri Feb 17 15:46:36 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 17 Feb 2017 16:46:36 +0100 Subject: After last "snap refresh" problem with contents of /writable/system-data/etc/iproute2. In-Reply-To: <1487342972.11011.45.camel@ubuntu.com> References: <1487342972.11011.45.camel@ubuntu.com> Message-ID: Ok. Thanks. On Fri, Feb 17, 2017 at 3:49 PM, Oliver Grawert wrote: > hi, > Am Freitag, den 17.02.2017, 15:30 +0100 schrieb Luca Dionisi: >> Hi all >> >> I was in need to modify the file /etc/iproute2/rt_tables, but it was >> read-only on previous versions of the "core" snap. >> As a workaround, I was manually doing a bind-mount from the file >> /writable/system-data/etc/iproute2/rt_tables to the location >> /etc/iproute2/rt_tables. >> >> When I did last "snap refresh" to my ubuntu core it seems to me that >> there is now a permanent bind-mount from the directory >> /writable/system-data/etc/iproute2 to the location /etc/iproute2. >> >> But now I have only one file in /etc/iproute2. >> luca-dionisi at localhost:/etc/iproute2$ ls >> rt_tables >> >> Is it normal or is it due to my previous workaround? >> If so, what are my options to revert things? >> > this is due to your former tinkering and us making the location > writable by default at the same time. > > back up your changed rt_tables file, then unmount /etc/iproute2 ... > > the original files of the directory should show up after this ... > > now you can cp them to /writable/system-data/etc/iproute2, copy your > modified rt_tables there as well and you should be fine after a reboot > ... > > sorry, we dont really have protection against people manually bind- > mounting rw files on top of readonly dirs when we make them writable. > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From kirkland at canonical.com Fri Feb 17 16:35:23 2017 From: kirkland at canonical.com (Dustin Kirkland) Date: Fri, 17 Feb 2017 10:35:23 -0600 Subject: Fwd: petname snap bug In-Reply-To: References: Message-ID: Is there something special I need to do to have the "man" binary available to me? My snap ships a manpage in /snap/petname/share/man/man1/petname.1 Perhaps too cleverly, when you run /snap/bin/petname --help, my program tries to "exec man petname", and that fails: $ /snap/bin/petname -h /snap/petname/9/bin/petname: 49: exec: man: not found Please advise. Do I need to include man as a part or something? Dustin Kirkland Ubuntu Product & Strategy Canonical, Ltd. ---------- Forwarded message ---------- From: Charles Butler Date: Thu, Feb 16, 2017 at 9:58 AM Subject: petname snap bug To: Dustin Kirkland Greetings Dustin, I found a minior quibble with petname. Not sure if you'd prefer this as a bug somewhere but the snap for petname in the stable channel breaks when i attempt to get help for petname with 'man not found' 130 charles at Xenial:/media/psf/work/builds⟫ sudo snap install petname [sudo] password for charles: petname 2.6 from 'kirkland' installed charles at Xenial:/media/psf/work/builds⟫ petname --help /snap/petname/9/bin/petname: 49: exec: man: not found 127 charles at Xenial:/media/psf/work/builds⟫ man What manual page do you want? 1 charles at Xenial:/media/psf/work/builds⟫ petname -h /snap/petname/9/bin/petname: 49: exec: man: not found 127 charles at Xenial:/media/psf/work/builds⟫ petname guided-chicken charles at Xenial:/media/psf/work/builds⟫ petname united-collie charles at Xenial:/media/psf/work/builds⟫ petname --help /snap/petname/9/bin/petname: 49: exec: man: not found All the best. Charles Butler - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu install with Conjure and Juju. From louis.bouchard at canonical.com Fri Feb 17 17:35:57 2017 From: louis.bouchard at canonical.com (Louis Bouchard) Date: Fri, 17 Feb 2017 18:35:57 +0100 Subject: sosreport and snaps Message-ID: <3df35514-5323-f788-26f0-092cadde5120@canonical.com> Hello, sosreport is a tool used to collect diagnostic information for offline analysis, most often by support specialists[1]. Canonical uses sosreport extensively with our UA customers. I would like to craft a sosreport plugin that would collect valuable information on snaps running on an system. So what would be the appropriate information that would need to be collected ? If you have to diagnose a bug in the snappy ecosystem, what information will you be asking for ? If some information is sensible, it can be obfuscated at run-time so it is not included in the produced tarball. This plugin would be included in the sosreport package (deb, rpm, etc) Making sosreport available as a snap is a separate effort now made easier by the classic mode, since sosreport needs root access to collect some information. Thanks for your help, Kind regards, ...Louis [1] http://sos.readthedocs.io/en/latest/ -- Louis Bouchard Software engineer, Cloud & Sustaining eng. Canonical Ltd Ubuntu developer Debian Maintainer GPG : 429D 7A3B DD05 B6F8 AF63 B9C4 8B3D 867C 823E 7A61 From charles.butler at canonical.com Fri Feb 17 18:51:27 2017 From: charles.butler at canonical.com (Charles Butler) Date: Fri, 17 Feb 2017 12:51:27 -0600 Subject: petname snap bug In-Reply-To: References: Message-ID: I popped in #snappy and fished up a bug about this with kyrofa's help https://bugs.launchpad.net/snappy/+bug/1575593 Seems like a good one to watch for this. Charles Butler - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu install with Conjure and Juju. On Fri, Feb 17, 2017 at 10:35 AM, Dustin Kirkland wrote: > Is there something special I need to do to have the "man" binary > available to me? > > My snap ships a manpage in /snap/petname/share/man/man1/petname.1 > > Perhaps too cleverly, when you run /snap/bin/petname --help, my > program tries to "exec man petname", and that fails: > > $ /snap/bin/petname -h > /snap/petname/9/bin/petname: 49: exec: man: not found > > Please advise. Do I need to include man as a part or something? > > Dustin Kirkland > Ubuntu Product & Strategy > Canonical, Ltd. > > > > ---------- Forwarded message ---------- > From: Charles Butler > Date: Thu, Feb 16, 2017 at 9:58 AM > Subject: petname snap bug > To: Dustin Kirkland > > > Greetings Dustin, > > I found a minior quibble with petname. Not sure if you'd prefer this > as a bug somewhere but the snap for petname in the stable channel > breaks when i attempt to get help for petname with 'man not found' > > > 130 charles at Xenial:/media/psf/work/builds⟫ sudo snap install petname > [sudo] password for charles: > petname 2.6 from 'kirkland' installed > charles at Xenial:/media/psf/work/builds⟫ petname --help > /snap/petname/9/bin/petname: 49: exec: man: not found > 127 charles at Xenial:/media/psf/work/builds⟫ man > What manual page do you want? > 1 charles at Xenial:/media/psf/work/builds⟫ petname -h > /snap/petname/9/bin/petname: 49: exec: man: not found > 127 charles at Xenial:/media/psf/work/builds⟫ petname > guided-chicken > charles at Xenial:/media/psf/work/builds⟫ petname > united-collie > charles at Xenial:/media/psf/work/builds⟫ petname --help > /snap/petname/9/bin/petname: 49: exec: man: not found > > > All the best. > > Charles Butler - Juju Charmer > Come see the future of modeling your datacenter: http://jujucharms.com > Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu > install with Conjure and Juju. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Fri Feb 17 20:38:06 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 17 Feb 2017 14:38:06 -0600 Subject: Fwd: petname snap bug In-Reply-To: References: Message-ID: <1487363886.5211.31.camel@canonical.com> On Fri, 2017-02-17 at 10:35 -0600, Dustin Kirkland wrote: > Is there something special I need to do to have the "man" binary > available to me? > > My snap ships a manpage in /snap/petname/share/man/man1/petname.1 > > Perhaps too cleverly, when you run /snap/bin/petname --help, my > program tries to "exec man petname", and that fails: > > $ /snap/bin/petname -h > /snap/petname/9/bin/petname: 49: exec: man: not found > > Please advise.  Do I need to include man as a part or something? > Charles gave the bug for this, For something that should work today, I might mention that if you stage-packages man so that you have it in your snap, 'petname -h' could invoke '$SNAP/path/to/man $SNAP/path/to/page'. You could also dump the man page output and save that in your snap and have 'petname -h' 'less /snap/path/to/dumped/page'. I've used this command for that sort of thing: $ PAGER=cat LANG='en_US.UTF-8' MANWIDTH=80 man --warnings \   -E UTF-8 -l ./path/to/page > ./path/to/dumped/page -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kirkland at canonical.com Fri Feb 17 21:22:44 2017 From: kirkland at canonical.com (Dustin Kirkland) Date: Fri, 17 Feb 2017 15:22:44 -0600 Subject: Fwd: petname snap bug In-Reply-To: <1487363886.5211.31.camel@canonical.com> References: <1487363886.5211.31.camel@canonical.com> Message-ID: On Fri, Feb 17, 2017 at 2:38 PM, Jamie Strandboge wrote: > On Fri, 2017-02-17 at 10:35 -0600, Dustin Kirkland wrote: >> Is there something special I need to do to have the "man" binary >> available to me? >> >> My snap ships a manpage in /snap/petname/share/man/man1/petname.1 >> >> Perhaps too cleverly, when you run /snap/bin/petname --help, my >> program tries to "exec man petname", and that fails: >> >> $ /snap/bin/petname -h >> /snap/petname/9/bin/petname: 49: exec: man: not found >> >> Please advise. Do I need to include man as a part or something? >> > Charles gave the bug for this, Great, thanks: https://bugs.launchpad.net/snappy/+bug/1575593 The bug is almost a year old, affects 17 people, and is Triaged and priority Low. I'm glad it's getting a little more attention! > For something that should work today, I might mention that if you stage-packages > man so that you have it in your snap, 'petname -h' could invoke > '$SNAP/path/to/man $SNAP/path/to/page'. > > You could also dump the man page output and save that in your snap and have > 'petname -h' 'less /snap/path/to/dumped/page'. I've used this command for that > sort of thing: > > $ PAGER=cat LANG='en_US.UTF-8' MANWIDTH=80 man --warnings \ > -E UTF-8 -l ./path/to/page > ./path/to/dumped/page Thanks for the suggestions, I can make these work. From joseph.wakeling at webdrake.net Sat Feb 18 00:12:46 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Feb 2017 01:12:46 +0100 Subject: snapcraft 2.27 has been released In-Reply-To: References: Message-ID: On 17/02/17 13:49, Sergio Schvezov wrote: > ## classic confinement > > Improvements have been made to the experimental `classic` confinement build setup to be more robust and reliable. These improvements allow to build `classic` confined snaps that work across a wider set of OS releases (particularly those with differing glibc versions). An early adopter of this work is *conjure-up* which now sports Trusty Tahr support. Learn more about conjure-up by visiting http://conjure-up.io/ I have good news and bad news here. The good news is that `snapcraft cleanbuild` now seems to work with classic snaps (presumably you knew this already;-). The bad news is that running the snapped applications seems to run into trouble. I'm presuming this is a snapcraft issue rather than snapd since already-installed classic snaps built with snapcraft 2.26 seem fine. Specifically, given the snap defined in this branch: https://github.com/WebDrake/dub.snap/pull/5 ... it builds fine (with or without `cleanbuild`), and installs fine, but when I try to run even something simple like dub --version ... then the command hangs. Watching `top` sees CPU jump to 100%, alternating between dub, snap-exec and snap-confine. Running `snappy-debug.security scanlog` reveals the following after the `dub` command is invoked: = AppArmor = Time: Feb 18 01:07:30 Log: apparmor="DENIED" operation="file_inherit" profile="/usr/lib/snapd/snap-confine" name="/dev/tty" pid=7488 comm="snap-confine" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0 File: /dev/tty (write) Suggestion: * add 'serial-port (with gadget or core support)' to 'plugs' ... while the `dub --version` command outputs to console: runtime/cgo: pthread_create failed: Resource temporarily unavailable runtime/cgo: runtime/cgo: runtime/cgo: runtime/cgo: pthread_create failed: Resource temporarily unavailableruntime/cgo: runtime/cgo: pthread_create failed: Resource temporarily unavailable runtime/cgo: runtime/cgo: pthread_create failed: Resource temporarily unavailable runtime/cgo: pthread_create failed: Resource temporarily unavailable runtime/cgo: pthread_create failed: Resource temporarily unavailable runtime/cgo: pthread_create failed: Resource temporarily unavailable runtime/cgo: pthread_create failed: Resource temporarily unavailable runtime/cgo: pthread_create failed: Resource temporarily unavailable ... repeating seemingly endlessly. Note the above results whether or not the snap was built using `cleanbuild`. Possibly relatedly, while running `snapcraft cleanbuild` to build this snap, the following shows up in the scanlog: = AppArmor = Time: Feb 18 00:59:46 Log: apparmor="DENIED" operation="file_perm" namespace="root//lxd-snapcraft-truly-ace-amoeba_" profile="/sbin/dhclient" name="/apparmor/.null" pid=30305 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=165536 ouid=0 File: /apparmor/.null (write) Suggestion: * adjust program to write to $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 18 00:59:46 Log: apparmor="DENIED" operation="file_perm" namespace="root//lxd-snapcraft-truly-ace-amoeba_" profile="/sbin/dhclient" name="/apparmor/.null" pid=30305 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=165536 ouid=0 File: /apparmor/.null (write) Suggestion: * adjust program to write to $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON Any ideas what's up here? Thanks & best wishes, -- Joe From santosh.mahto at canonical.com Sat Feb 18 12:52:28 2017 From: santosh.mahto at canonical.com (Santosh Mahto) Date: Sat, 18 Feb 2017 18:22:28 +0530 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: References: <1484755177.4288.19.camel@ubuntu.com> <1485250565.4288.98.camel@ubuntu.com> Message-ID: Hi All, Same issue happening with me now as faced by Alejandro, H/W : rpi3 I used latest core from edge channel then installed mir-libs(edge, devmode) , mir-kiosk(edge, devmode) and mir-kiosk-apps(edge, devmode) with disconnect/connect/disable/enable mentioned in wiki. But I don't see neither mir-kiosk nor mir-kiosk-apps is recognised as valid command. (just to mention I tried only with mir-kiosk and mir-libs only but no success, and also tried to build locally(on rpi) mir-libs but it fails to find libmiral2 for xenail) Here is the info : *snap list * Name Version Rev Developer Notes amazon-webapp 1.4 x1 devmode *core 16.04.1 1226 canonical -* *mir-kiosk 0.1 28 canonical devmode* *mir-kiosk-apps 0.1 11 canonical -devmode* *mir-libs 0.1 22 canonical devmode* *network-manager 1.2.2-10 72 canonical -* oxide-digitalsignage 1 5 penk devmode pi2-kernel 4.4.0-1030-3 22 canonical - pi3 16.04-0.5 6 canonical - pulseaudio 8.0-3 12 canonical - testdemo 1.0 x1 devmode ubuntu-app-platform 1 36 canonical devmode *$snap interfaces | grep mir* *:network amazon-webapp,mir-kiosk-apps,oxide-digitalsignage,pulseaudio,testdemo,webbrowser-app* *:opengl amazon-webapp,mir-kiosk,mir-kiosk-apps,oxide-digitalsignage,testdemo,webbrowser-app* *mir-kiosk:mir amazon-webapp,mir-kiosk-apps* *mir-libs:mir-libs mir-kiosk,mir-kiosk-apps* - testdemo:mir Initially I was running testdemo and getting following error which lead me to track mir-kiosk $testdemo Loading module: 'libubuntu_application_api_desktop_mirclient.so.3.0.0' [QPA] UbuntuClientIntegration: connection to Mir server failed. Mir returned: "Failed to connect to server socket: No such file or directory" Any suggestion whats going wrong here. Regards Santosh On Wed, Jan 25, 2017 at 1:41 AM, Alejandro J. Cura < alejandro.cura at canonical.com> wrote: > It's all working perfectly on the raspi3, both with an hdmi monitor > plus a mouse, and with the original raspberry pi 7" touchscreen. > > thanks again! > -- > alecu > > On Tue, Jan 24, 2017 at 4:30 PM, Alejandro J. Cura > wrote: > > After installing with --devmode the very latest mir-kiosk that Albert > just > > uploaded to the store in edge, and then reinstalling mir-kiosk-apps with > > devmode as well, I've got it all running on a raspi2. > > alecu at localhost:~$ snap list > > Name Version Rev Developer Notes > > core 16.04.1 976 canonical - > > mir-kiosk 0.1 22 canonical devmode > > mir-kiosk-apps 0.1 11 canonical devmode > > mir-libs 0.1 20 canonical devmode > > pi2 16.04-0.17 36 canonical - > > pi2-kernel 4.4.0-1040-47 26 canonical - > > alecu at localhost:~$ snap interfaces | grep mir > > :network mir-kiosk-apps > > :opengl mir-kiosk,mir-kiosk-apps > > mir-kiosk:mir mir-kiosk-apps > > mir-libs:mir-libs mir-kiosk,mir-kiosk-apps > > alecu at localhost:~$ > > > > I'll give it a try on the raspi3 now. > > > > big thanks to Ogra and Albert that helped me debug this on #snappy. > > > > cheers, > > -- > > alecu > > > > On Tue, Jan 24, 2017 at 6:36 AM, Oliver Grawert wrote: > >> > >> hi, > >> Am Montag, den 23.01.2017, 17:53 -0300 schrieb Alejandro J. Cura: > >> > > >> > ... > >> > Any ideas on what I should try, or how to further debug this? I can > >> > upload the crash report if it helps. > >> > >> first of all make sure to only use the very latest daily edge image > >> (url is in my original mail, the setup only works with the right gadget > >> and kernel, they need to be in sync). > >> > >> all issues with mir were fixed with the most recent mir-kiosk snap so > >> you can just snap install them from the store from the edge channel (i > >> just tested them on two fresh installs on the pi2 and 3) ... > >> > >> there is however the content sharing interface involved in using the > >> mir-libs which still has issues, make sure you did the > >> disable/disconnect/connect/enable dance described on the mir wiki > >> > >> the least you should get is a black screen with a mouse cursor right > >> after (well about 15-30 sec after) boot ... it definitely works for me > >> on both test boards. > >> > >> ciao > >> oli > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > >> > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Sat Feb 18 16:58:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sat, 18 Feb 2017 16:58:00 +0000 Subject: snapcraft 2.27 has been released In-Reply-To: References: Message-ID: <5gfwiw.olkxsv.1hge17a-qmf@smtp.googlemail.com> On Sat, 18 Feb 2017 01:12:46 +0100, Joseph Rushton Wakeling wrote: > On 17/02/17 13:49, Sergio Schvezov wrote: >> ## classic confinement >> >> Improvements have been made to the experimental `classic` >> confinement build setup to be more robust and reliable. These >> improvements allow to build `classic` confined snaps that work >> across a wider set of OS releases (particularly those with >> differing glibc versions). An early adopter of this work is >> *conjure-up* which now sports Trusty Tahr support. Learn more >> about conjure-up by visiting http://conjure-up.io/ > > I have good news and bad news here. > > The good news is that `snapcraft cleanbuild` now seems to work with classic > snaps (presumably you knew this already;-). Still good to know! > The bad news is that running the snapped applications seems to > run into trouble. > I'm presuming this is a snapcraft issue rather than snapd since > already-installed classic snaps built with snapcraft 2.26 seem fine. This is due to the fact that we are not setting up any environment variables from snapcraft for classic snaps to not override anything on the environment you'd want to run. > Specifically, given the snap defined in this branch: > https://github.com/WebDrake/dub.snap/pull/5 added a comment. > ... it builds fine (with or without `cleanbuild`), and installs > fine, but when I > try to run even something simple like > > dub --version > > ... then the command hangs. Watching `top` sees CPU jump to > 100%, alternating > between dub, snap-exec and snap-confine. > > Running `snappy-debug.security scanlog` reveals the following > after the `dub` > command is invoked: > > = AppArmor = > Time: Feb 18 01:07:30 > Log: apparmor="DENIED" operation="file_inherit" > profile="/usr/lib/snapd/snap-confine" name="/dev/tty" pid=7488 > comm="snap-confine" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0 > File: /dev/tty (write) > Suggestion: > * add 'serial-port (with gadget or core support)' to 'plugs' > > ... while the `dub --version` command outputs to console: > > runtime/cgo: pthread_create failed: Resource temporarily unavailable > runtime/cgo: runtime/cgo: runtime/cgo: runtime/cgo: pthread_create failed: > Resource temporarily unavailableruntime/cgo: runtime/cgo: > pthread_create failed: > Resource temporarily unavailable > runtime/cgo: runtime/cgo: pthread_create failed: Resource > temporarily unavailable > runtime/cgo: pthread_create failed: Resource temporarily unavailable > runtime/cgo: pthread_create failed: Resource temporarily unavailable > runtime/cgo: pthread_create failed: Resource temporarily unavailable > runtime/cgo: pthread_create failed: Resource temporarily unavailable > runtime/cgo: pthread_create failed: Resource temporarily unavailable > > ... repeating seemingly endlessly. > > Note the above results whether or not the snap was built using `cleanbuild`. > > > Possibly relatedly, while running `snapcraft cleanbuild` to > build this snap, the > following shows up in the scanlog: > > = AppArmor = > Time: Feb 18 00:59:46 > Log: apparmor="DENIED" operation="file_perm" > namespace="root//lxd-snapcraft-truly-ace-amoeba_" > profile="/sbin/dhclient" name="/apparmor/.null" pid=30305 comm="dhclient" > requested_mask="w" denied_mask="w" fsuid=165536 ouid=0 > File: /apparmor/.null (write) > Suggestion: > * adjust program to write to $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or > $SNAP_USER_COMMON > > = AppArmor = > Time: Feb 18 00:59:46 > Log: apparmor="DENIED" operation="file_perm" > namespace="root//lxd-snapcraft-truly-ace-amoeba_" > profile="/sbin/dhclient" name="/apparmor/.null" pid=30305 comm="dhclient" > requested_mask="w" denied_mask="w" fsuid=165536 ouid=0 > File: /apparmor/.null (write) > Suggestion: > * adjust program to write to $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or > $SNAP_USER_COMMON > > Any ideas what's up here? This is the way exec works. To illustrate, create a file in PATH called, `eternal` $ cat > /usr/local/bin/eternal << EOF #!/bin/sh exec eternal EOF $ chmod +x /usr/local/bin/eternal If you exec that you will see the same behavior (I wish snap-confine added some protections for that though). So in your specific case your snap is called `dub` has an app named `dub` which has a `command: dub`, what ends up happening is that `dub` is called from the entry in `/snap/bin/dub` which links to our internal command wrapper which has `exec dub` and the `dub` which takes precedence in PATH is `/snap/bin/dub`. As I write this I think there is a clever trick we can try on snapcraft. Mind logging a bug for this please? I'll try and solve it for the next release which is next week. -- From joseph.wakeling at webdrake.net Sat Feb 18 20:25:02 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Feb 2017 21:25:02 +0100 Subject: snapcraft 2.27 has been released In-Reply-To: <5gfwiw.olkxsv.1hge17a-qmf@smtp.googlemail.com> References: <5gfwiw.olkxsv.1hge17a-qmf@smtp.googlemail.com> Message-ID: On 18/02/17 17:58, Sergio Schvezov wrote: >> The bad news is that running the snapped applications seems to >> run into trouble. >> I'm presuming this is a snapcraft issue rather than snapd since >> already-installed classic snaps built with snapcraft 2.26 seem fine. > > This is due to the fact that we are not setting up any environment variables from snapcraft for classic snaps to not override anything on the environment you'd want to run. Ah, thanks for the clarification (and your detailed explanation given below). A further effect of this seems to be that libraries included in the snap are not auto-detected (whether built as part of the snap, or included as stage-packages). Can you offer some suggestions for how to deal with this? > As I write this I think there is a clever trick we can try on snapcraft. Mind logging a bug for this please? I'll try and solve it for the next release which is next week. Sure: https://bugs.launchpad.net/snapcraft/+bug/1665927 Thanks & best wishes, -- Joe From cpollock at embarqmail.com Sun Feb 19 01:24:19 2017 From: cpollock at embarqmail.com (Chris) Date: Sat, 18 Feb 2017 19:24:19 -0600 Subject: Can't update snapweb Message-ID: <1487467459.17286.12.camel@embarqmail.com> Through out the day when it comes time for snap refresh to run I've noticed that it can't update snapweb. Running manually shows chris at localhost:~$ sudo snap refresh error: cannot perform the following tasks: - Run configure hook of "snapweb" snap if present (/usr/bin/env: 'python': No such file or directory) I also get this output in my syslog. Mind the extra stuff not pertaining to the update as there is some here and there. https://pastebin.com/i7ffAEuS And what is all this starting here - Feb 18 19:15:07 localhost /usr/lib/gdm3/gdm-x-session[2315] it shows up each time today that snapweb was trying to be updated. -- Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 19:13:54 up 15 days, 11:12, 2 users, load average: 2.48, 2.20, 1.26 Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-62-generic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From joseph.wakeling at webdrake.net Sun Feb 19 11:12:16 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 19 Feb 2017 12:12:16 +0100 Subject: LDC compiler snap issues on 14.04 (ABI compatibility?) In-Reply-To: <7bda09a9-3b23-4f4d-95e4-9d04d6cdb4d0@canonical.com> References: <8aaf985d-21fb-6360-530c-95f6aa269c93@webdrake.net> <20170210234842.GC28439@hunt> <20c5dfb4-0532-5b0c-bc7b-91c3318b7f82@webdrake.net> <7bda09a9-3b23-4f4d-95e4-9d04d6cdb4d0@canonical.com> Message-ID: <31a5f784-9df6-439a-92be-7e0c061c04d1@webdrake.net> On 16/02/17 05:10, Sergio Schvezov wrote: > I'll check your snap first thing once I am at a computer again. From experience > with classic confinement though, stage-packages to provide runnables are most > of the time the root cause. There was discusssion on having ld set > --library-path in be core snap to have called binaries not reach out to the > system and get confused. Just to follow up on this: I was able to rebuild the package using snapcraft 2.27 and `cleanbuild`, and as far as I can tell the result works on 14.04 without a hitch. So thank you for all the great work here! :-) I have an outstanding issue with a linker plugin included in the snap, but that supports an optional feature and I didn't expect it to work with 14.04. In any case I'll follow up on that in a separate thread once I have a clearer picture of exactly what might be the problem. Thanks again & best wishes, -- Joe From mark at ubuntu.com Sun Feb 19 11:21:26 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sun, 19 Feb 2017 11:21:26 +0000 Subject: Determining the set of snapd capabilities Message-ID: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> We have a nice mechanism to ensure that snaps which use newer capabilities don't end up on systems with older snapd's that don't support those capabilities, which is the 'assumes' keyword. This email is a proposal to make that usable. The mechanism is mentioned in the snapcraft docs at https://github.com/snapcore/snapcraft/blob/master/docs/snapcraft-syntax.md which is published at https://snapcraft.io/docs/build-snaps/syntax but not clarified anywhere else that I can see. I have been unable to find a list of the available capabilities that can be assumed. Whatever else is true, the fact that I couldn't find it despite the help of the AIs at Google suggests that we can improve the discoverability and usefulness of this potentially very useful capability :) Step 1, show what capabilities a snapd offers. https://bugs.launchpad.net/snapd/+bug/1665995 'snap --version' is a nice way to know what versions are relevant for a particular system. That would be a good place to show the capabilities that can be assume'd for snaps being installed on that system. It doesn't require a new command and it is in many ways more relevant to developers than the particular version. At least, the intent of capabilities is to have fewer version-specific dependencies, and more capability-specific dependencies! Step 2, reference 'snap version' in the docs The existing docs for snapcraft.yaml and snap.yaml should both make clear reference to 'snap version' as a way to discover these capabilities. Also, there should be express documentation on each of them, organized as such. So the docs should say "use 'snap version' to see what a particular system supports, and see for documentation about each of those capabilities". That documentation should explain any constraints or usage of the capabilities. Step 3, introduce capabilities as 'beta-capability' When we land new features, there are often rough edges. For example, there is a new capability to support direct setting of environment variables in snap.yaml which is super useful (many snaps have wrappers just to do this, so that's one less layer needed in the common case :)). However, there is a bug in the implementation which means you sometimes get a newline on the environment variable, which is unhelpful. I think this should be a beta-capability till we know it is fully fleshed out. Step 4, announce new capabilities on the list In many cases, the existence of a new capability is meaningful for a large number of snapcrafters, lets share the beta documentation on the list when the capability lands in a --proposed or --candidate release of snapd+snapcraft. Step 5, nobody expects the Spanish Inquisition. Mark From joseph.wakeling at webdrake.net Sun Feb 19 12:07:48 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 19 Feb 2017 13:07:48 +0100 Subject: Determining the set of snapd capabilities In-Reply-To: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> References: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> Message-ID: <757aec5c-e4eb-1ec3-a6d6-991f68b10911@webdrake.net> On 19/02/17 12:21, Mark Shuttleworth wrote: > We have a nice mechanism to ensure that snaps which use newer > capabilities don't end up on systems with older snapd's that don't > support those capabilities, which is the 'assumes' keyword. This email > is a proposal to make that usable. This would be super-useful. Conversely, to what extent might it be possible to guide the package developer to a clear understanding of what capabilities a particular snap package assumes? > Step 3, introduce capabilities as 'beta-capability' Sounds good. Working with classic snaps (for example) is obviously chasing a somewhat moving target right now. That was clear up front, but it would be nice to have it explicitly documented. > Step 4, announce new capabilities on the list > > In many cases, the existence of a new capability is meaningful for a > large number of snapcrafters, lets share the beta documentation on the > list when the capability lands in a --proposed or --candidate release of > snapd+snapcraft. Not just capabilities, but any breaking changes in behaviour. For example, while Sergio's support has been great regarding my recent experiences with snapcraft 2.27, I think I could have avoided taking his time if the release notes had mentioned that classic snaps would no longer see environment variables set in app wrapper scripts (and ideally, advised on the changes required to `snapcraft.yaml` files). > Step 5, nobody expects the Spanish Inquisition. But I hope all snapcraft developers have comfy chairs? :-) Thanks & best wishes, -- Joe From andrew at nocturnal.net.au Sun Feb 19 12:52:35 2017 From: andrew at nocturnal.net.au (Andrew Mason) Date: Sun, 19 Feb 2017 23:22:35 +1030 Subject: Generic Snap questions In-Reply-To: <2a9934c6-5f8b-631c-025f-88bf6e9a3e6f@canonical.com> References: <4001728.f4fN6ktkGB@lincoln> <2a9934c6-5f8b-631c-025f-88bf6e9a3e6f@canonical.com> Message-ID: <692d661a-25ca-d8da-8c44-066da8a2d402@nocturnal.net.au> Hey Kyle, Thanks heaps for responding to my questions with so much detail. I am sorry about the late response. I've only just been able to get back to my interest in snaps. > > That would also be up to the snap in question. snapd supports a > configure hook[2] that the snap can implement to support such things, > but implementing that hook (and what exactly can be changed with it) is > still up to the snap. The snap could also expose such functionality with > its own app, if the developer chose to do so. > >> 3. Say a bunch of people want their own instance of this snappified service. >> How are / should additional instances handled from an installation perspective >> ? >> >> Also how would multiple instances be configured with regards to TCP port >> access ? > > I'm not 100% sure I understand this question. Snaps aren't per-user > (they're installed system-wide), so if you're asking how multiple users > on the same machine would install this snap, the answer is "they > wouldn't" I suppose. Please clarify this question if I didn't answer it. Right, so I'll use a better example which might make sense. Say I have a snap of a web application that listens on port 443. The nextcloud one is a great example because I don't share the preferences in some of the choices made in this snap. By default it will use apache and listen on the default IP address for configuration. I have the following scenarios which I can fairly easily accommodate with a regular install of apache + php and the next cloud. # scenario 1: multiple web applications on the same box: I have two users of my machine. One person wants the existing stable, tried and true version of next cloud the other wants the version that's only just been released. Both listen on port 443, both (package apache httpd) # scenario 2: single web app, multiple instances: I install nextcloud on a VM provided by my company. I can do whatever I like, but I only have a single VM. (azure costs $$$). I install nextcloud for the developers but the support team want their own and the accounts team would also like one. How do I go about spinning up multiple instances of the same application but listening on a different hostname via SNI. ? Is this again one of those..it depends on the snap thing ? If so is there a best practice guide for making these? I guess I was hoping for more of a debian style enforcement of packaging rules. Is there a way to find out this information from a snap before installation ? If I felt so inclined, what would be the best way to get some high level instructions around how to implement the feature or even if it's a welcome feature at all. Happy to do the development work but don't want to make something that people don't want or is done in a way that they don't want. I can easily see the use case for snaps on the desktop but I was really hoping to be able to utilise them more on server personally. I have written a small application in Go which I believe should be easy to turn into a snap, so my next task is to go and create a snap to examine the process. Kind regards Andrew From sergio.schvezov at canonical.com Sun Feb 19 14:26:11 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 19 Feb 2017 14:26:11 +0000 Subject: Determining the set of snapd capabilities In-Reply-To: <757aec5c-e4eb-1ec3-a6d6-991f68b10911@webdrake.net> References: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> <757aec5c-e4eb-1ec3-a6d6-991f68b10911@webdrake.net> Message-ID: On Sun, 19 Feb 2017 13:07:48 +0100, Joseph Rushton Wakeling wrote: > On 19/02/17 12:21, Mark Shuttleworth wrote: >> Step 4, announce new capabilities on the list >> >> In many cases, the existence of a new capability is meaningful for a >> large number of snapcrafters, lets share the beta documentation on the >> list when the capability lands in a --proposed or --candidate release of >> snapd+snapcraft. > > Not just capabilities, but any breaking changes in behaviour. For example, > while Sergio's support has been great regarding my recent experiences with > snapcraft 2.27, I think I could have avoided taking his time if the release > notes had mentioned that classic snaps would no longer see > environment variables > set in app wrapper scripts (and ideally, advised on the changes required to > `snapcraft.yaml` files). It was my intention to fully document this. I just did half of the job as I only added information about it under the python plugin update. Sorry about this. I have updated the release notes[1] so the next person doesn't fall into this time sync trap! Cheers Sergio [1] https://github.com/snapcore/snapcraft/releases/tag/2.27 -- From joseph.wakeling at webdrake.net Sun Feb 19 15:21:07 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 19 Feb 2017 16:21:07 +0100 Subject: Determining the set of snapd capabilities In-Reply-To: References: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> <757aec5c-e4eb-1ec3-a6d6-991f68b10911@webdrake.net> Message-ID: On 19/02/17 15:26, Sergio Schvezov wrote: > It was my intention to fully document this. I just did half of the job as I only added information about it under the python plugin update. Sorry about this. I have updated the release notes[1] so the next person doesn't fall into this time sync trap! Oh, no apology needed! FWIW I would suggest maybe giving an example (in the 'classic confinement' section) of how to change the `command:` declaration in order to deal with this change. You give a working example later in 'Setting up environment' but it's not obvious that this is related to classic confinement or a change in snapcraft behaviour. From mark at ubuntu.com Sun Feb 19 15:30:22 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sun, 19 Feb 2017 15:30:22 +0000 Subject: Determining the set of snapd capabilities In-Reply-To: <757aec5c-e4eb-1ec3-a6d6-991f68b10911@webdrake.net> References: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> <757aec5c-e4eb-1ec3-a6d6-991f68b10911@webdrake.net> Message-ID: <96b4c976-2931-09ae-891d-cb229fc5d577@ubuntu.com> On 19/02/17 12:07, Joseph Rushton Wakeling wrote: > This would be super-useful. Conversely, to what extent might it be > possible to guide the package developer to a clear understanding of > what capabilities a particular snap package assumes? Hmm... that's a Turing-complete problem :) However, a useful approach would be to run the snap through an automated test process using a range of supported platforms. For example, spinning up VMs of snapd-supporting distros, and testing the snap there. As a precursor to that we would want to have health mechanism which provide a standard way to know if a snap considers itself healthy. Then we could run a service for developers which screens a snap for health across a wide range of devices and VMs, including the commonly used versions of snapd in those environments, to pick up potential problems and make such recommendations. Mark From james.henstridge at canonical.com Mon Feb 20 02:16:20 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Mon, 20 Feb 2017 10:16:20 +0800 Subject: Experimental Python interpreter snap Message-ID: To learn a bit more about I put together a snap for Python 3.6.0, which can be installed with: snap install --edge python36-jamesh You can then run "python36-jamesh.python3", which will give you the a Python shell running with strict confinement, with the full standard library available. Now I know Snapcraft already has support for packaging Python applications, so what benefits does this package add? There were a few extra points in how I built the package: 1. the interpreter binary and extension modules all have appropriate $ORIGIN relative rpath set. 2. a sitecustomize.py is provided that will add $SNAP/lib/python3.6/site-packages to sys.path. (more on why this is useful later) This makes the interpreter fully relocatable in the file system while still being able to find the bundled libraries. In turn, this means the interpreter is functional when exported to another snap via the content interface. To demonstrate this, I put together a trivial "hello world" snapcraft project here: https://github.com/jhenstridge/python-snap-pkg/tree/master/examples/hello-world After building this package, it can be run after installing and connecting the interface: $ snap install --dangerous hello-world_0.1_amd64.snap hello-world 0.1 installed $ snap connect hello-world:python3 python36-jamesh:python3 $ hello-world Hello world! Since the hello-world snap doesn't actually include Python, it is quite light weight (4 kB, which I think is as small as a squashfs gets). The space savings may not be that great with a single snap (the interpreter snap is almost 20MB), but the space savings increase as you install more snaps using the interface. It also means that we could upgrade to Python 3.6.1 (when it comes out) without rebuilding this snap. And since the interpreter is being run under the hello-world snap's confinement policy, it can do potentially do things the main "python36-jamesh.python3" binary can't. For example, if you add the "network" plug, you'll be able to access the network. And the sitecustomize script will also mean the interpreter can locate packages shipped in the plug snap. I'd be interested in any suggestions or feedback about the snap. Thanks, James. From spencertparkin at gmail.com Mon Feb 20 02:41:37 2017 From: spencertparkin at gmail.com (Spencer) Date: Sun, 19 Feb 2017 19:41:37 -0700 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: <969179B3-D4B3-4AB0-B3CF-E5FADB22F09C@gmail.com> I thought a main feature of snaps was to include all dependencies so that they couldn't be changed out from underneath a package. For example, my script was written for 3.6, but would be incompatible with a future release, say 4.0. Still, the ability to share a dependency like the Python interpreter among python snaps may be a good idea if there are zillions of Python snaps. At my work, we got tired of everyone maintaining their own local python installation, because we all ended up with slightly different versions of various python modules installed. Worse, some modules installed for some while not for others. So we started tracking a shared Python installation in git. One problem we found is that Python is not relocatable. This showed up when people cloned our repository in a different place. Are you sure that your snapped Python is relocatable? If so, I'd like to know how that works. Is the $ORIGIN variable standard? > On Feb 19, 2017, at 7:16 PM, James Henstridge wrote: > > To learn a bit more about I put together a snap for Python 3.6.0, > which can be installed with: > > snap install --edge python36-jamesh > > You can then run "python36-jamesh.python3", which will give you the a > Python shell running with strict confinement, with the full standard > library available. > > Now I know Snapcraft already has support for packaging Python > applications, so what benefits does this package add? There were a > few extra points in how I built the package: > > 1. the interpreter binary and extension modules all have appropriate > $ORIGIN relative rpath set. > > 2. a sitecustomize.py is provided that will add > $SNAP/lib/python3.6/site-packages to sys.path. (more on why this is > useful later) > > This makes the interpreter fully relocatable in the file system while > still being able to find the bundled libraries. In turn, this means > the interpreter is functional when exported to another snap via the > content interface. > > To demonstrate this, I put together a trivial "hello world" snapcraft > project here: > > https://github.com/jhenstridge/python-snap-pkg/tree/master/examples/hello-world > > After building this package, it can be run after installing and > connecting the interface: > > $ snap install --dangerous hello-world_0.1_amd64.snap > hello-world 0.1 installed > $ snap connect hello-world:python3 python36-jamesh:python3 > $ hello-world > Hello world! > > Since the hello-world snap doesn't actually include Python, it is > quite light weight (4 kB, which I think is as small as a squashfs > gets). The space savings may not be that great with a single snap > (the interpreter snap is almost 20MB), but the space savings increase > as you install more snaps using the interface. It also means that we > could upgrade to Python 3.6.1 (when it comes out) without rebuilding > this snap. > > And since the interpreter is being run under the hello-world snap's > confinement policy, it can do potentially do things the main > "python36-jamesh.python3" binary can't. For example, if you add the > "network" plug, you'll be able to access the network. > > And the sitecustomize script will also mean the interpreter can locate > packages shipped in the plug snap. > > I'd be interested in any suggestions or feedback about the snap. > > Thanks, > > James. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From xiaoguo.liu at canonical.com Mon Feb 20 02:45:16 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 20 Feb 2017 10:45:16 +0800 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: Hi James, Nice. This is a nice example showing how to reduce a python snap package. A few days ago, I also made a small example to make use of the python3 coming with the core at: https://github.com/liu-xiao-guo/httpstat In the above example, I in fact do not package the python. It works. Thanks & best regards, XiaoGuo On Mon, Feb 20, 2017 at 10:16 AM, James Henstridge < james.henstridge at canonical.com> wrote: > To learn a bit more about I put together a snap for Python 3.6.0, > which can be installed with: > > snap install --edge python36-jamesh > > You can then run "python36-jamesh.python3", which will give you the a > Python shell running with strict confinement, with the full standard > library available. > > Now I know Snapcraft already has support for packaging Python > applications, so what benefits does this package add? There were a > few extra points in how I built the package: > > 1. the interpreter binary and extension modules all have appropriate > $ORIGIN relative rpath set. > > 2. a sitecustomize.py is provided that will add > $SNAP/lib/python3.6/site-packages to sys.path. (more on why this is > useful later) > > This makes the interpreter fully relocatable in the file system while > still being able to find the bundled libraries. In turn, this means > the interpreter is functional when exported to another snap via the > content interface. > > To demonstrate this, I put together a trivial "hello world" snapcraft > project here: > > https://github.com/jhenstridge/python-snap-pkg/tree/master/examples/hello- > world > > After building this package, it can be run after installing and > connecting the interface: > > $ snap install --dangerous hello-world_0.1_amd64.snap > hello-world 0.1 installed > $ snap connect hello-world:python3 python36-jamesh:python3 > $ hello-world > Hello world! > > Since the hello-world snap doesn't actually include Python, it is > quite light weight (4 kB, which I think is as small as a squashfs > gets). The space savings may not be that great with a single snap > (the interpreter snap is almost 20MB), but the space savings increase > as you install more snaps using the interface. It also means that we > could upgrade to Python 3.6.1 (when it comes out) without rebuilding > this snap. > > And since the interpreter is being run under the hello-world snap's > confinement policy, it can do potentially do things the main > "python36-jamesh.python3" binary can't. For example, if you add the > "network" plug, you'll be able to access the network. > > And the sitecustomize script will also mean the interpreter can locate > packages shipped in the plug snap. > > I'd be interested in any suggestions or feedback about the snap. > > Thanks, > > James. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.henstridge at canonical.com Mon Feb 20 04:09:11 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Mon, 20 Feb 2017 12:09:11 +0800 Subject: Experimental Python interpreter snap In-Reply-To: <969179B3-D4B3-4AB0-B3CF-E5FADB22F09C@gmail.com> References: <969179B3-D4B3-4AB0-B3CF-E5FADB22F09C@gmail.com> Message-ID: On 20 February 2017 at 10:41, Spencer wrote: > I thought a main feature of snaps was to include all dependencies so that they couldn't be changed out from underneath a package. For example, my script was written for 3.6, but would be incompatible with a future release, say 4.0. I've included two content interface slots on my snap: one with the content ID "python3" and the other with the content ID "python3.6". The idea being that a program that doesn't care about getting new versions (e.g. my trivial hello world snap) could use the first, while ones that really want python 3.6.x (e.g. if they contain compiled extensions) could request the second. I don't think there is any point in distinguishing micro releases though, since the Python core developers have a good track record when it comes to releasing security/bug fix updates to their previous releases. > Still, the ability to share a dependency like the Python interpreter among python snaps may be a good idea if there are zillions of Python snaps. > > At my work, we got tired of everyone maintaining their own local python installation, because we all ended up with slightly different versions of various python modules installed. Worse, some modules installed for some while not for others. So we started tracking a shared Python installation in git. One problem we found is that Python is not relocatable. This showed up when people cloned our repository in a different place. Are you sure that your snapped Python is relocatable? If so, I'd like to know how that works. Is the $ORIGIN variable standard? Note that the the only things being shared here is the Python interpreter and the standard library. If one snap includes a bunch of third party Python packages in their $SNAP/lib/python3.6/site-packages directory, they won't be visible to a second snap that has also used the interface. The effect is quite similar to the isolation you get from virtualenv. As far as relocatability goes, part of it is provided by Python proper. Here's sys.path from the interpreter provided by the python36-jamesh snap: $ python36-jamesh.python3 Python 3.6.0 (default, Feb 20 2017, 01:27:20) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/snap/python36-jamesh/7/lib/python36.zip', '/snap/python36-jamesh/7/lib/python3.6', '/snap/python36-jamesh/7/lib/python3.6/lib-dynload'] And here it is when running in the context of my hello-world snap: $ snap run --shell hello-world To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. $ $SNAP/python/bin/python3 Python 3.6.0 (default, Feb 20 2017, 01:27:20) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', '/snap/hello-world/x1/python/lib/python36.zip', '/snap/hello-world/x1/python/lib/python3.6', '/snap/hello-world/x1/python/lib/python3.6/lib-dynload'] What I added was configuring DT_RUNPATH for the executable and extensions. This augments the set of directories the dynamic linker searches for shared library dependencies. If a directory in this list contains the token "$ORIGIN", it will be expanded to the the directory containing the program or library. So by including "$ORIGIN/../lib" in the runpath for bin/python3.6, I can make sure it will find the libpython in the directory next to it, no matter where it happens to be bind mounted. You can find more information about this in the ld.so(8) man page. James. From james.henstridge at canonical.com Mon Feb 20 04:41:35 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Mon, 20 Feb 2017 12:41:35 +0800 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: On 20 February 2017 at 10:45, XiaoGuo Liu wrote: > Hi James, > > Nice. This is a nice example showing how to reduce a python snap package. A > few days ago, I also made a small example to make use of the python3 coming > with the core at: > > https://github.com/liu-xiao-guo/httpstat > > In the above example, I in fact do not package the python. It works. So I guess the main differences are that this makes it easy to use a newer version of Python than existed at the time Xenial was released. I suspect I could also build a Python 2.7 snap using the same techniques, if you want to go in the other direction. The Python in my snap is also set up to automatically use packages included in your own snap without fiddling with environment variables or sys.path. James. From vasilisc777 at gmail.com Mon Feb 20 09:14:56 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 20 Feb 2017 12:14:56 +0300 Subject: xdg-open doesn't work only in xubuntu Message-ID: This test case does not work in Xubuntu. --------------------- name: test2 version: "1" summary: TEst description: | TEST confinement: strict architectures: [amd64] apps: test2: command: xdg-open "http://google.com" plugs: [network, network-bind, x11, home, unity7, gsettings] parts: integration: plugin: nil stage-packages: - bash - xdg-utils after: [desktop-gtk2] --------------------- Output $ test2 /snap/test2/x1/usr/bin/xdg-open: 630: /snap/test2/x1/usr/bin/xdg-open: exo-open: not found System info: $ LANG=C sudo apt policy xfce4 xfce4: Installed: (none) Candidate: 4.12.2 Version table: 4.12.2 500 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe i386 Packages $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial $ LANG=C sudo apt policy exo-utils exo-utils: Installed: 0.10.7-1 Candidate: 0.10.7-1 Version table: *** 0.10.7-1 500 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status $ whereis exo-open exo-open: /usr/bin/exo-open /usr/share/man/man1/exo-open.1.gz I found this bug https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1535471 but there is no solution -- Best regards, vasilisc From vasilisc777 at gmail.com Mon Feb 20 09:29:24 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 20 Feb 2017 12:29:24 +0300 Subject: xdg-open doesn't work only in xubuntu (v2) Message-ID: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> Please ignore my previous letter. This test case does not work in Xubuntu. --------------------- name: test2 version: "1" summary: TEst description: | TEST confinement: strict architectures: [amd64] apps: test2: command: xdg-open "http://google.com" plugs: [network, network-bind, x11, home, unity7, gsettings] parts: integration: plugin: nil stage-packages: - bash - xdg-utils after: [desktop-gtk2] --------------------- Output $ test2 /snap/test2/x1/usr/bin/xdg-open: 630: /snap/test2/x1/usr/bin/xdg-open: exo-open: not found System info: $ LANG=C apt policy libxfce4util-bin libxfce4util-bin: Installed: 4.12.1-2 Candidate: 4.12.1-2 Version table: *** 4.12.1-2 500 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial $ LANG=C sudo apt policy exo-utils exo-utils: Installed: 0.10.7-1 Candidate: 0.10.7-1 Version table: *** 0.10.7-1 500 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status $ LANG=C apt policy snapd-xdg-open snapd-xdg-open: Installed: 0.0.0~16.04 Candidate: 0.0.0~16.04 Version table: *** 0.0.0~16.04 500 500 http://ru.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages 100 /var/lib/dpkg/status $ whereis exo-open exo-open: /usr/bin/exo-open /usr/share/man/man1/exo-open.1.gz I found this bug https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1535471 but there is no solution -- Best regards, vasilisc From konrad.zapalowicz at canonical.com Mon Feb 20 09:53:42 2017 From: konrad.zapalowicz at canonical.com (Konrad Zapalowicz) Date: Mon, 20 Feb 2017 10:53:42 +0100 Subject: [System Enablement] New releases Feb 2017 - week 08 Message-ID: <20170220095342.GA23028@annapurna> Hey everyone, new releases of the following snaps were pushed into the candidate channel. tpm 1.2-5: * Snap aliases for all TPM tools (LP: #1653699) * Fix typo in tpm.restictpubek (LP: #1637251) udisks2 2.1.7-4: * Add automount capabilities via ciborium --- An overview of which revisions / versions of the particular snaps are available in which channel is available at https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# The snaps have passed our engineering QA and will now be tested by the platform and commercial QA teams before the new versions are pushed to the stable channel. Bileto requests are: - tpm: https://bileto.ubuntu.com/#/ticket/2492 - udisks2: https://bileto.ubuntu.com/#/ticket/2490 If you have any questions feel free to ping me. regards, Konrad From david.barth at canonical.com Mon Feb 20 10:09:27 2017 From: david.barth at canonical.com (David Barth) Date: Mon, 20 Feb 2017 11:09:27 +0100 Subject: Can't update snapweb In-Reply-To: <1487467459.17286.12.camel@embarqmail.com> References: <1487467459.17286.12.camel@embarqmail.com> Message-ID: On Sun, Feb 19, 2017 at 2:24 AM, Chris wrote: > Through out the day when it comes time for snap refresh to run I've > noticed that it can't update snapweb. Running manually shows > > chris at localhost:~$ sudo snap refresh > error: cannot perform the following tasks: > - Run configure hook of "snapweb" snap if present (/usr/bin/env: > 'python': No such file or directory) > This is a bug that slipped in the last merge, which is then automatically pushed to edge. We'll have a fix for it in the day. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Mon Feb 20 10:28:39 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 20 Feb 2017 13:28:39 +0300 Subject: The situation with xdg-open Message-ID: <1c8e60ea-84da-813e-378c-e7db91b45671@gmail.com> Snapcraft.yaml --------------------- name: test2 version: "1" summary: TEst description: | TEST confinement: strict architectures: [amd64] apps: test2: command: xdg-open "http://google.com" plugs: [network, network-bind, x11, home, unity7, gsettings] parts: integration: plugin: nil stage-packages: - bash - xdg-utils after: [desktop-gtk2] ----------------------------- Results Xubuntu 16.04.2 /snap/myapp/x1/usr/bin/xdg-open: 630: /snap/myapp/x1/usr/bin/xdg-open: exo-open: not found Ubuntu MATE 16.04.2 /snap/test2/x1/usr/bin/xdg-open: 618: /snap/test2/x1/usr/bin/xdg-open: mate-open: not found Kubuntu 16.04.2 /snap/test2/x1/usr/bin/xdg-open: 566: /snap/test2/x1/usr/bin/xdg-open: kde-open5: not found Ubuntu GNOME 16.04.2 xdg-open work fine. Lubuntu 16.04.2 xdg-open work fine. Ubuntu 16.04.2 xdg-open work fine. -- Best regards, vasilisc From ogra at ubuntu.com Mon Feb 20 10:34:31 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Feb 2017 11:34:31 +0100 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> Message-ID: <1487586871.11011.53.camel@ubuntu.com> hi, Am Montag, den 20.02.2017, 12:29 +0300 schrieb Vasilisc: > Please ignore my previous letter. > This test case does not work in Xubuntu. > --------------------- > name: test2 > version: "1" > summary: TEst > description: | >      TEST > confinement: strict > architectures: [amd64] > > apps: >    test2: >      command: xdg-open "http://google.com" >      plugs: [network, network-bind, x11, home, unity7, gsettings] > > parts: >    integration: >     plugin: nil >     stage-packages: >      - bash >      - xdg-utils >     after: [desktop-gtk2] looks like you explicitly asked for trouble here ... :) adding xdg-open (via xdg-utils) will replace/override the xdg-open that is already shipped in the core snap (which is a dbus service that hands the url to the outside of the confined space). first of all drop the xdg-utils line above and see if it works then, this should at least allow the app to hand it to the outside of the confined area. that said, it might be that snapd-xdg-open needs to learn about exo- open (or the other way around) as well to be able to handle the request on the desktop side ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From vasilisc777 at gmail.com Mon Feb 20 10:54:47 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 20 Feb 2017 13:54:47 +0300 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <1487586871.11011.53.camel@ubuntu.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> <1487586871.11011.53.camel@ubuntu.com> Message-ID: <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> 20.02.2017 13:34, Oliver Grawert пишет: > looks like you explicitly asked for trouble here ... :) > > adding xdg-open (via xdg-utils) will replace/override the xdg-open that > is already shipped in the core snap (which is a dbus service that hands > the url to the outside of the confined space). first of all drop the > xdg-utils line above and see if it works then, this should at least > allow the app to hand it to the outside of the confined area. > > that said, it might be that snapd-xdg-open needs to learn about exo- > open (or the other way around) as well to be able to handle the request > on the desktop side ... without xdg-utils ================== name: test2 version: "1" summary: TEst description: | TEST confinement: strict architectures: [amd64] apps: test2: command: xdg-open "http://google.com" plugs: [network, network-bind, x11, home, unity7, gsettings] parts: integration: plugin: nil stage-packages: - bash # - xdg-utils after: [desktop-gtk2] ================ I got /snap/test2/x1/command-test2.wrapper: 8: exec: xdg-open: not found -- Best regards, vasilisc From ogra at ubuntu.com Mon Feb 20 11:20:28 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Feb 2017 12:20:28 +0100 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> <1487586871.11011.53.camel@ubuntu.com> <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> Message-ID: <1487589628.11011.56.camel@ubuntu.com> hi, Am Montag, den 20.02.2017, 13:54 +0300 schrieb Vasilisc: > I got > /snap/test2/x1/command-test2.wrapper: 8: exec: xdg-open: not found do you see: /snap/core/current/usr/local/bin/xdg-open on your system ? you also dont need to ship bash: /snap/core/current/bin/bash ships it ... looks to me like the inclusion of bash might have broken the default PATH, the latest snap-confine should actually make sure that usr/local/bin is in there. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From vasilisc777 at gmail.com Mon Feb 20 11:44:19 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 20 Feb 2017 14:44:19 +0300 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <1487589628.11011.56.camel@ubuntu.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> <1487586871.11011.53.camel@ubuntu.com> <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> <1487589628.11011.56.camel@ubuntu.com> Message-ID: <70c4a017-b137-0fcf-1431-6e37936cb30f@gmail.com> 20.02.2017 14:20, Oliver Grawert пишет: > hi, > Am Montag, den 20.02.2017, 13:54 +0300 schrieb Vasilisc: >> I got >> /snap/test2/x1/command-test2.wrapper: 8: exec: xdg-open: not found > > do you see: > > /snap/core/current/usr/local/bin/xdg-open > > on your system ? > > you also dont need to ship bash: /snap/core/current/bin/bash ships it > ... > > looks to me like the inclusion of bash might have broken the default > PATH, the latest snap-confine should actually make sure that > usr/local/bin is in there. > > ciao > oli $ LANG=C ll /snap/core/current/usr/local/bin/ total 1 drwxr-xr-x 2 root root 88 Feb 19 23:50 ./ drwxr-xr-x 10 root root 123 Feb 19 23:50 ../ lrwxrwxrwx 1 root root 6 Feb 19 23:49 apt -> no-apt* lrwxrwxrwx 1 root root 6 Feb 19 23:49 apt-cache -> no-apt* lrwxrwxrwx 1 root root 6 Feb 19 23:49 apt-get -> no-apt* -rwxr-xr-x 1 root root 70 Feb 19 23:49 no-apt* -rwxr-xr-x 1 root root 127 Feb 19 23:49 xdg-open* $ echo $PATH /home/vasilisc/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin $ snap list Name Version Rev Developer Notes core 16.04.1 1240 canonical - test2 1 x1 - $ test2 /snap/test2/x1/command-test2.wrapper: 8: exec: xdg-open: not found snapcraft.yaml ------------- name: test2 version: "1" summary: TEst description: | TEST confinement: strict architectures: [amd64] apps: test2: command: xdg-open "http://google.com" plugs: [network, network-bind, x11, home, unity7, gsettings] parts: integration: plugin: nil stage-packages: - libc6 after: [desktop-gtk2] -- Best regards, vasilisc From ogra at ubuntu.com Mon Feb 20 11:59:19 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Feb 2017 12:59:19 +0100 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: References: <1484755177.4288.19.camel@ubuntu.com> <1485250565.4288.98.camel@ubuntu.com> Message-ID: <1487591959.11011.59.camel@ubuntu.com> hi, Am Samstag, den 18.02.2017, 18:22 +0530 schrieb Santosh Mahto: > Hi All, > > Same issue happening with me now as faced by Alejandro, > H/W : rpi3 > I used latest core from edge channel then installed mir-libs(edge, > devmode) , mir-kiosk(edge, devmode) > and mir-kiosk-apps(edge, devmode)  with > disconnect/connect/disable/enable mentioned in wiki. > > But I don't see neither mir-kiosk nor mir-kiosk-apps is recognised as > valid command. > (just to mention I tried only with mir-kiosk and mir-libs only but no > success, and also tried to build locally(on rpi)  mir-libs but it > fails to find libmiral2 for xenail) mir-kiosk is a service it should auto-start (at least after a reboot)  it runs fine for me on a pi2 currently (with mir-libs and mir-kiosk installed following teh wiki, i get a black screen with a movable mouse pointer right after boot), note though that mir tries to read the EDID of the display on startup, if you do not have a HDMI monitor attached it will likely refuse to start ... (not sure if that also applies for input devices) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From gustavo at niemeyer.net Mon Feb 20 12:32:31 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 20 Feb 2017 09:32:31 -0300 Subject: The situation with xdg-open In-Reply-To: <1c8e60ea-84da-813e-378c-e7db91b45671@gmail.com> References: <1c8e60ea-84da-813e-378c-e7db91b45671@gmail.com> Message-ID: Hi there, The problem there is that the confined xdg-open currently depends on snapd-xdg-open, which is a server listening on dbus for the calls. We're changing that mechanism in the short term so snapd will implement that logic internally, precisely to remove that extra moving piece and "flakiness". On Mon, Feb 20, 2017 at 7:28 AM, Vasilisc wrote: > Snapcraft.yaml > --------------------- > name: test2 > version: "1" > summary: TEst > description: | > TEST > confinement: strict > architectures: [amd64] > > apps: > test2: > command: xdg-open "http://google.com" > plugs: [network, network-bind, x11, home, unity7, gsettings] > > parts: > integration: > plugin: nil > stage-packages: > - bash > - xdg-utils > after: [desktop-gtk2] > ----------------------------- > Results > > Xubuntu 16.04.2 > /snap/myapp/x1/usr/bin/xdg-open: 630: /snap/myapp/x1/usr/bin/xdg-open: > exo-open: not found > > Ubuntu MATE 16.04.2 > /snap/test2/x1/usr/bin/xdg-open: 618: /snap/test2/x1/usr/bin/xdg-open: > mate-open: not found > > Kubuntu 16.04.2 > /snap/test2/x1/usr/bin/xdg-open: 566: /snap/test2/x1/usr/bin/xdg-open: > kde-open5: not found > > Ubuntu GNOME 16.04.2 > xdg-open work fine. > > Lubuntu 16.04.2 > xdg-open work fine. > > Ubuntu 16.04.2 > xdg-open work fine. > > > -- > Best regards, > vasilisc > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Feb 20 12:33:40 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 20 Feb 2017 09:33:40 -0300 Subject: xdg-open doesn't work only in xubuntu In-Reply-To: References: Message-ID: Please see the response to your other message on this topic. On Mon, Feb 20, 2017 at 6:14 AM, Vasilisc wrote: > This test case does not work in Xubuntu. > --------------------- > name: test2 > version: "1" > summary: TEst > description: | > TEST > confinement: strict > architectures: [amd64] > > apps: > test2: > command: xdg-open "http://google.com" > plugs: [network, network-bind, x11, home, unity7, gsettings] > > parts: > integration: > plugin: nil > stage-packages: > - bash > - xdg-utils > after: [desktop-gtk2] > --------------------- > Output > $ test2 > /snap/test2/x1/usr/bin/xdg-open: 630: /snap/test2/x1/usr/bin/xdg-open: > exo-open: not found > > > System info: > > $ LANG=C sudo apt policy xfce4 > xfce4: > Installed: (none) > Candidate: 4.12.2 > Version table: > 4.12.2 500 > 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 > Packages > 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe i386 > Packages > > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 16.04.2 LTS > Release: 16.04 > Codename: xenial > > $ LANG=C sudo apt policy exo-utils > exo-utils: > Installed: 0.10.7-1 > Candidate: 0.10.7-1 > Version table: > *** 0.10.7-1 500 > 500 http://ru.archive.ubuntu.com/ubuntu xenial/universe amd64 > Packages > 100 /var/lib/dpkg/status > > $ whereis exo-open > exo-open: /usr/bin/exo-open /usr/share/man/man1/exo-open.1.gz > > > I found this bug > https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1535471 > but there is no solution > > -- > Best regards, > vasilisc > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Feb 20 12:51:15 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 20 Feb 2017 09:51:15 -0300 Subject: Determining the set of snapd capabilities In-Reply-To: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> References: <192c246d-3ec3-96fe-972c-694e7582fba9@ubuntu.com> Message-ID: The intent of assumes features was to try not to overuse, because it becomes hard to use and hard to maintain. The ideal candidate for a custom entry on assumes are those features that can exist in one distribution but not the other, due to constraints which are unrelated to it being merely an old revision of snapd. With that, it will get wild. Every other release of snapd has a new feature, or multiple new features. It becomes unnecessarily messy to maintain that list, and the output of "snap version" will also be wild. Besides those custom entries, we also support a special entry for snapd-proper, spelled as "snapd2.23" for example, This is only satisfied by snapd 2.23 and newer, so it's a better mechanism to establish an ever increasing number of features on snapd. Listing those would be extremely boring, though, because it'd be a list like snapd2.15, snapd2.16, snapd2.17, ... until the current version. This latter mechanism was introduced later into the assumes system, precisely because of the issues with the former approach. Instead of encouraging more use of the former system, my suggestion is to continue reserving it for the special cases, and focus documentation onto the latter. I'd also avoid touching "snap version" for now, until we've explored the system a bit further. We haven't added any new entries on the former assumes system for a long while. We should probably deprecate the existing entries there, until we have cross-environment differences to track (on the same snapd version). On Sun, Feb 19, 2017 at 8:21 AM, Mark Shuttleworth wrote: > > We have a nice mechanism to ensure that snaps which use newer > capabilities don't end up on systems with older snapd's that don't > support those capabilities, which is the 'assumes' keyword. This email > is a proposal to make that usable. > > The mechanism is mentioned in the snapcraft docs at > https://github.com/snapcore/snapcraft/blob/master/docs/snapcraft-syntax.md > which is published at https://snapcraft.io/docs/build-snaps/syntax but > not clarified anywhere else that I can see. I have been unable to find a > list of the available capabilities that can be assumed. Whatever else is > true, the fact that I couldn't find it despite the help of the AIs at > Google suggests that we can improve the discoverability and usefulness > of this potentially very useful capability :) > > > Step 1, show what capabilities a snapd offers. > https://bugs.launchpad.net/snapd/+bug/1665995 > > 'snap --version' is a nice way to know what versions are relevant for a > particular system. That would be a good place to show the capabilities > that can be assume'd for snaps being installed on that system. It > doesn't require a new command and it is in many ways more relevant to > developers than the particular version. At least, the intent of > capabilities is to have fewer version-specific dependencies, and more > capability-specific dependencies! > > > Step 2, reference 'snap version' in the docs > > The existing docs for snapcraft.yaml and snap.yaml should both make > clear reference to 'snap version' as a way to discover these > capabilities. Also, there should be express documentation on each of > them, organized as such. So the docs should say "use 'snap version' to > see what a particular system supports, and see for documentation > about each of those capabilities". That documentation should explain any > constraints or usage of the capabilities. > > > Step 3, introduce capabilities as 'beta-capability' > > When we land new features, there are often rough edges. For example, > there is a new capability to support direct setting of environment > variables in snap.yaml which is super useful (many snaps have wrappers > just to do this, so that's one less layer needed in the common case :)). > However, there is a bug in the implementation which means you sometimes > get a newline on the environment variable, which is unhelpful. I think > this should be a beta-capability till we know it is fully fleshed out. > > > Step 4, announce new capabilities on the list > > In many cases, the existence of a new capability is meaningful for a > large number of snapcrafters, lets share the beta documentation on the > list when the capability lands in a --proposed or --candidate release of > snapd+snapcraft. > > > Step 5, nobody expects the Spanish Inquisition. > > > Mark > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Mon Feb 20 13:13:34 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Feb 2017 14:13:34 +0100 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <70c4a017-b137-0fcf-1431-6e37936cb30f@gmail.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> <1487586871.11011.53.camel@ubuntu.com> <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> <1487589628.11011.56.camel@ubuntu.com> <70c4a017-b137-0fcf-1431-6e37936cb30f@gmail.com> Message-ID: <1487596414.11011.68.camel@ubuntu.com> hi, Am Montag, den 20.02.2017, 14:44 +0300 schrieb Vasilisc: >  > > $ echo $PATH > /home/vasilisc/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin: > /sbin:/bin:/usr/games:/usr/local/games:/snap/bin > this is not the PATH your snap sees at execution time, just your users PATH used at login time on the desktop ...  snap-confine sets the PATH variable when a snap application is executed ...  try the following: $ snap install hello-world $ hello-world.env|grep ^PATH that will show what PATH a snap actually sees... you could try to change your "command:" entry to point directly to the full path of xdg-open inside the core snap, or ship a shell wrapper script that properly extends PATH to point to $SNAP/usr/local/bin like: #!/bin/sh PATH="$PATH:$SNAP/usr/local/bin" xdg-open "http://google.com" and set this as your "command:" ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From vasilisc777 at gmail.com Mon Feb 20 13:16:06 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 20 Feb 2017 16:16:06 +0300 Subject: The situation with xdg-open In-Reply-To: References: <1c8e60ea-84da-813e-378c-e7db91b45671@gmail.com> Message-ID: 20.02.2017 15:32, Gustavo Niemeyer пишет: > Hi there, > > The problem there is that the confined xdg-open currently depends on > snapd-xdg-open, which is a server listening on dbus for the calls. > > We're changing that mechanism in the short term so snapd will implement > that logic internally, precisely to remove that extra moving piece and > "flakiness". Thank you for the detailed response. How long should I wait? > Xubuntu 16.04.2 > /snap/myapp/x1/usr/bin/xdg-open: 630: > /snap/myapp/x1/usr/bin/xdg-open: exo-open: not found > > Ubuntu MATE 16.04.2 > /snap/test2/x1/usr/bin/xdg-open: 618: > /snap/test2/x1/usr/bin/xdg-open: mate-open: not found > > Kubuntu 16.04.2 > /snap/test2/x1/usr/bin/xdg-open: 566: > /snap/test2/x1/usr/bin/xdg-open: kde-open5: not found > > Ubuntu GNOME 16.04.2 > xdg-open work fine. > > Lubuntu 16.04.2 > xdg-open work fine. > > Ubuntu 16.04.2 > xdg-open work fine. > > > -- > Best regards, > vasilisc > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > gustavo @ http://niemeyer.net -- Best regards, vasilisc From ogra at ubuntu.com Mon Feb 20 13:22:45 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Feb 2017 14:22:45 +0100 Subject: The situation with xdg-open In-Reply-To: References: <1c8e60ea-84da-813e-378c-e7db91b45671@gmail.com> Message-ID: <1487596965.11011.71.camel@ubuntu.com> hi, Am Montag, den 20.02.2017, 16:16 +0300 schrieb Vasilisc: > 20.02.2017 15:32, Gustavo Niemeyer пишет: > > > > Hi there, > > > > The problem there is that the confined xdg-open currently depends > > on > > snapd-xdg-open, which is a server listening on dbus for the calls. > > > > We're changing that mechanism in the short term so snapd will > > implement > > that logic internally, precisely to remove that extra moving piece > > and > > "flakiness". > Thank you for the detailed response. How long should I wait? > what gustavo means is that it is being re-designed over the course of the next few releases of snapd, nothing to be fixed "right now". in general the currently mechanism is working (there are many snaps using it) but is awkward to use for developers because you need to have your PATH right and all the right bits need to be inside the core snap as well as outside of the confinement on your desktop (snapd-xdg-open). ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From vasilisc777 at gmail.com Mon Feb 20 13:35:30 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 20 Feb 2017 16:35:30 +0300 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <1487596414.11011.68.camel@ubuntu.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> <1487586871.11011.53.camel@ubuntu.com> <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> <1487589628.11011.56.camel@ubuntu.com> <70c4a017-b137-0fcf-1431-6e37936cb30f@gmail.com> <1487596414.11011.68.camel@ubuntu.com> Message-ID: <2bc6642e-0f62-1e7a-28a1-44aa89250517@gmail.com> 20.02.2017 16:13, Oliver Grawert пишет: > hi, > Am Montag, den 20.02.2017, 14:44 +0300 schrieb Vasilisc: >> >> >> $ echo $PATH >> /home/vasilisc/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin: >> /sbin:/bin:/usr/games:/usr/local/games:/snap/bin >> > this is not the PATH your snap sees at execution time, just your users > PATH used at login time on the desktop ... > > snap-confine sets the PATH variable when a snap application is executed > ... > > try the following: > > $ snap install hello-world > $ hello-world.env|grep ^PATH > > that will show what PATH a snap actually sees... > > you could try to change your "command:" entry to point directly to the > full path of xdg-open inside the core snap, or ship a shell wrapper > script that properly extends PATH to point to $SNAP/usr/local/bin like: > > #!/bin/sh > > PATH="$PATH:$SNAP/usr/local/bin" > xdg-open "http://google.com" > > and set this as your "command:" > > ciao > oli > > > I create new snapcraft.yaml =============================== name: test2 version: "1" summary: TEst description: | TEST confinement: strict architectures: [amd64] apps: test2: command: run.sh plugs: [network, network-bind, x11, home, unity7, gsettings] parts: files: plugin: dump source: files-project integration: plugin: nil stage-packages: - libc6 after: [desktop-gtk2] ================================== $ test2 /snap/test2/x1/bin/run.sh: line 4: xdg-open: command not found $ cat /snap/test2/current/bin/run.sh #!/bin/bash PATH="$PATH:$SNAP/usr/local/bin" xdg-open "http://google.com" ------------------------ I try install/remove snapd-xdg-open ... nothing! -- Best regards, vasilisc From ogra at ubuntu.com Mon Feb 20 13:56:39 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Feb 2017 14:56:39 +0100 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <2bc6642e-0f62-1e7a-28a1-44aa89250517@gmail.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> <1487586871.11011.53.camel@ubuntu.com> <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> <1487589628.11011.56.camel@ubuntu.com> <70c4a017-b137-0fcf-1431-6e37936cb30f@gmail.com> <1487596414.11011.68.camel@ubuntu.com> <2bc6642e-0f62-1e7a-28a1-44aa89250517@gmail.com> Message-ID: <1487598999.11011.75.camel@ubuntu.com> hi, Am Montag, den 20.02.2017, 16:35 +0300 schrieb Vasilisc: >  > $ test2 > /snap/test2/x1/bin/run.sh: line 4: xdg-open: command not found > > $ cat /snap/test2/current/bin/run.sh > > #!/bin/bash > > PATH="$PATH:$SNAP/usr/local/bin" > xdg-open "http://google.com" > ------------------------ > > I try  install/remove snapd-xdg-open ... nothing! ah, sorry, i was wrong about the $SNAP in the PATH ... i grabbed your example and changed it like: http://paste.ubuntu.com/24033840/ this definitely works on a unity desktop, i am not sure about desktops that deliberately replace xdg-open with something non-standard though (this will likely be fixed by the new implementation that gustavo talked about in the other thread). ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From alexandre.abreu at canonical.com Mon Feb 20 14:02:15 2017 From: alexandre.abreu at canonical.com (Alexandre Abreu) Date: Mon, 20 Feb 2017 09:02:15 -0500 Subject: Can't update snapweb In-Reply-To: References: <1487467459.17286.12.camel@embarqmail.com> Message-ID: > On Sun, Feb 19, 2017 at 2:24 AM, Chris wrote: > >> Through out the day when it comes time for snap refresh to run I've >> noticed that it can't update snapweb. Running manually shows >> >> chris at localhost:~$ sudo snap refresh >> error: cannot perform the following tasks: >> - Run configure hook of "snapweb" snap if present (/usr/bin/env: >> 'python': No such file or directory) >> > There is a fix for this, it'll be part of the daily snapweb release to edge, https://github.com/snapcore/snapweb/pull/164 -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.tilloy at canonical.com Mon Feb 20 14:22:11 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Mon, 20 Feb 2017 15:22:11 +0100 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: On Fri, Feb 17, 2017 at 12:11 AM, Leo Arias wrote: > Hello! > > This week I've been cleaning a few of my old snaps, using some of the > new features in more recent versions of snapcraft. At first I wasn't > convinced about scriptlets, but now I think they are great. Take a > look at this diff: > > 5 additions and 144 deletions > > https://github.com/elopio/ipfs-snap/commit/06f32696c1b461b1068e803e71e22bad50fe52eb > > Here is more info: > https://insights.ubuntu.com/2017/02/02/run-scripts-during-snapcraft-builds-with-scriptlets/ Very useful, thanks for highlighting it Leo! I've been able to replace the custom plugin for the 0AD snap with scriptlets, and that simplifies the packaging quite a bit. One thing that bit me is that I was expecting the 'install' scriptlet to replace the `make install` step when using the make plugin, but it doesn't. It runs `make`, `make install`, and then the install scriptlet. Note that the documentation is reasonably clear about it, but it looks a bit counterintuitive to me. One thing I haven't been able to figure out: is the parallel_build_count property exposed to scriptlets as a variable? That would be useful for custom build scripts that call make. Cheers, Olivier From mark at ubuntu.com Mon Feb 20 16:07:05 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 20 Feb 2017 17:07:05 +0100 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: On 20/02/17 15:22, Olivier Tilloy wrote: > One thing that bit me is that I was expecting the 'install' scriptlet > to replace the `make install` step when using the make plugin, but it > doesn't. It runs `make`, `make install`, and then the install > scriptlet. Note that the documentation is reasonably clear about it, > but it looks a bit counterintuitive to me. Right, it seems the scriptlet names should rather be of the form "pre-install" and "post-install" etc, since the plugins still seem to get invoked. When you look at it that way the current scriptlet names are quite misleading. Super-useful, just awkwardly named. It also seems, in that light, that we could have just been been rigorous about giving you the ability to stick a scriptlet before and after each step in the pipeline. Instead it's a bit of ad-hocness. Mark From kyle.fazzari at canonical.com Mon Feb 20 16:55:51 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 20 Feb 2017 08:55:51 -0800 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: On Feb 20, 2017 6:23 AM, "Olivier Tilloy" wrote: On Fri, Feb 17, 2017 at 12:11 AM, Leo Arias wrote: > Hello! > > This week I've been cleaning a few of my old snaps, using some of the > new features in more recent versions of snapcraft. At first I wasn't > convinced about scriptlets, but now I think they are great. Take a > look at this diff: > > 5 additions and 144 deletions > > https://github.com/elopio/ipfs-snap/commit/06f32696c1b461b1068e803e71e22b ad50fe52eb > > Here is more info: > https://insights.ubuntu.com/2017/02/02/run-scripts-during- snapcraft-builds-with-scriptlets/ Very useful, thanks for highlighting it Leo! I've been able to replace the custom plugin for the 0AD snap with scriptlets, and that simplifies the packaging quite a bit. One thing that bit me is that I was expecting the 'install' scriptlet to replace the `make install` step when using the make plugin, but it doesn't. It runs `make`, `make install`, and then the install scriptlet. Note that the documentation is reasonably clear about it, but it looks a bit counterintuitive to me. Note that the lifecycle doesn't have an 'install' step. The install actually happens in the 'build' step, which you can replace via the 'build' scriptlet. The three scriptlet surround the 'build' step: - 'prepare' runs before build - 'build' replaces plugin build (including install) - 'install' runs after build. This is useful e.g. for a Makefile with no installation targets, or copying over some config files after the plugin does its thing. One thing I haven't been able to figure out: is the parallel_build_count property exposed to scriptlets as a variable? That would be useful for custom build scripts that call make. I don't believe so, but I agree it would be useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From loic.minier at ubuntu.com Mon Feb 20 17:12:56 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Mon, 20 Feb 2017 18:12:56 +0100 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: On Mon, Feb 20, 2017 at 5:55 PM, Kyle Fazzari wrote: > > - 'prepare' runs before build > - 'build' replaces plugin build (including install) > - 'install' runs after build. This is useful e.g. for a Makefile with no > installation targets, or copying over some config files after the plugin > does its thing. > I had a case where I wanted to run something before stage-packages were pulled; I worked around the lack of hooks before stage-packages by using a separate part; see: https://github.com/lool/quortus-epc-snap/blob/master/snap/snapcraft.yaml#L23 I dont know how common this is, thought I'd mention it - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.tilloy at canonical.com Mon Feb 20 17:23:53 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Mon, 20 Feb 2017 18:23:53 +0100 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: On Mon, Feb 20, 2017 at 5:55 PM, Kyle Fazzari wrote: > On Feb 20, 2017 6:23 AM, "Olivier Tilloy" > wrote: > > On Fri, Feb 17, 2017 at 12:11 AM, Leo Arias wrote: >> Hello! >> >> This week I've been cleaning a few of my old snaps, using some of the >> new features in more recent versions of snapcraft. At first I wasn't >> convinced about scriptlets, but now I think they are great. Take a >> look at this diff: >> >> 5 additions and 144 deletions >> >> >> https://github.com/elopio/ipfs-snap/commit/06f32696c1b461b1068e803e71e22bad50fe52eb >> >> Here is more info: >> >> https://insights.ubuntu.com/2017/02/02/run-scripts-during-snapcraft-builds-with-scriptlets/ > > Very useful, thanks for highlighting it Leo! > I've been able to replace the custom plugin for the 0AD snap with > scriptlets, and that simplifies the packaging quite a bit. > > One thing that bit me is that I was expecting the 'install' scriptlet > to replace the `make install` step when using the make plugin, but it > doesn't. It runs `make`, `make install`, and then the install > scriptlet. Note that the documentation is reasonably clear about it, > but it looks a bit counterintuitive to me. > > > Note that the lifecycle doesn't have an 'install' step. The install actually > happens in the 'build' step, which you can replace via the 'build' > scriptlet. The three scriptlet surround the 'build' step: > > - 'prepare' runs before build > - 'build' replaces plugin build (including install) > - 'install' runs after build. This is useful e.g. for a Makefile with no > installation targets, or copying over some config files after the plugin > does its thing. > > > One thing I haven't been able to figure out: is the > parallel_build_count property exposed to scriptlets as a variable? > That would be useful for custom build scripts that call make. > > > I don't believe so, but I agree it would be useful. I filed https://launchpad.net/bugs/1666271 to track the feature request. From cpollock at embarqmail.com Mon Feb 20 17:29:24 2017 From: cpollock at embarqmail.com (Chris) Date: Mon, 20 Feb 2017 11:29:24 -0600 Subject: Can't update snapweb In-Reply-To: References: <1487467459.17286.12.camel@embarqmail.com> Message-ID: <1487611764.3519.0.camel@embarqmail.com> On Mon, 2017-02-20 at 11:09 +0100, David Barth wrote: > > > On Sun, Feb 19, 2017 at 2:24 AM, Chris wrote: > > Through out the day when it comes time for snap refresh to run I've > > noticed that it can't update snapweb. Running manually shows > > > > > > > > chris at localhost:~$ sudo snap refresh > > > > error: cannot perform the following tasks: > > > > - Run configure hook of "snapweb" snap if present (/usr/bin/env: > > > > 'python': No such file or directory) > > This is a bug that slipped in the last merge, which is then automatically pushed to edge. > We'll have a fix for it in the day. > > David > > > > Thanks David, matter of fact I got a reply on the bug report this morning. Appreciate the update --  Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 11:28:52 up 2:46, 1 user, load average: 1.40, 0.73, 0.56 Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-63-generic -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From cpollock at embarqmail.com Mon Feb 20 17:30:31 2017 From: cpollock at embarqmail.com (Chris) Date: Mon, 20 Feb 2017 11:30:31 -0600 Subject: Can't update snapweb In-Reply-To: References: <1487467459.17286.12.camel@embarqmail.com> Message-ID: <1487611831.3519.1.camel@embarqmail.com> On Mon, 2017-02-20 at 09:02 -0500, Alexandre Abreu wrote: > > > > > > > On Sun, Feb 19, 2017 at 2:24 AM, Chris wrote: > > > > > > Through out the day when it comes time for snap refresh to run I've > > > noticed that it can't update snapweb. Running manually shows > > > > > > > > > > > > chris at localhost:~$ sudo snap refresh > > > > > > error: cannot perform the following tasks: > > > > > > - Run configure hook of "snapweb" snap if present (/usr/bin/env: > > > > > > 'python': No such file or directory) > > > > > > > > There is a fix for this, it'll be part of the daily snapweb release to edge, > https://github.com/snapcore/snapweb/pull/164  > > > > Thanks Alexandre, appreciate the update. --  Chris KeyID 0xE372A7DA98E6705C 31.11972; -97.90167 (Elev. 1092 ft) 11:29:46 up 2:47, 1 user, load average: 1.03, 0.72, 0.56 Description: Ubuntu 16.04.2 LTS, kernel 4.4.0-63-generic -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From kyle.fazzari at canonical.com Mon Feb 20 17:33:02 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 20 Feb 2017 09:33:02 -0800 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: On Feb 20, 2017 9:14 AM, "Loïc Minier" wrote: On Mon, Feb 20, 2017 at 5:55 PM, Kyle Fazzari wrote: > > - 'prepare' runs before build > - 'build' replaces plugin build (including install) > - 'install' runs after build. This is useful e.g. for a Makefile with no > installation targets, or copying over some config files after the plugin > does its thing. > I had a case where I wanted to run something before stage-packages were pulled; I worked around the lack of hooks before stage-packages by using a separate part; see: https://github.com/lool/quortus-epc-snap/blob/master/snap/snapcraft.yaml#L23 I dont know how common this is, thought I'd mention it Haha, nice hack. If it were me, I would have considered writing a new plugin to hide that from my YAML. I'm a little OCD though, so let's be honest: is a dirtier YAML worth not having to write a plugin? Should we support pre/post scriptlets for the 'pull' step as well? Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From loic.minier at ubuntu.com Mon Feb 20 17:45:14 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Mon, 20 Feb 2017 18:45:14 +0100 Subject: pro tip: use scriptlets instead of custom plugins In-Reply-To: References: Message-ID: I can't really say how common this is; it's the first time I had to hack around stage-packages; it could indeed have been addressed through a plugin I was just thinking that if you add pre- post- hooks for every step of the lifecycle, then one before pull would have worked for me here; I have a solution in place, so this was just FYI On Mon, Feb 20, 2017 at 6:33 PM, Kyle Fazzari wrote: > On Feb 20, 2017 9:14 AM, "Loïc Minier" wrote: > > > > On Mon, Feb 20, 2017 at 5:55 PM, Kyle Fazzari > wrote: > >> >> - 'prepare' runs before build >> - 'build' replaces plugin build (including install) >> - 'install' runs after build. This is useful e.g. for a Makefile with no >> installation targets, or copying over some config files after the plugin >> does its thing. >> > > I had a case where I wanted to run something before stage-packages were > pulled; I worked around the lack of hooks before stage-packages by using a > separate part; see: > https://github.com/lool/quortus-epc-snap/blob/master/snap/ > snapcraft.yaml#L23 > > I dont know how common this is, thought I'd mention it > > > Haha, nice hack. If it were me, I would have considered writing a new > plugin to hide that from my YAML. I'm a little OCD though, so let's be > honest: is a dirtier YAML worth not having to write a plugin? Should we > support pre/post scriptlets for the 'pull' step as well? > > Kyle > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From selene.scriven at canonical.com Mon Feb 20 20:55:01 2017 From: selene.scriven at canonical.com (Selene Scriven) Date: Mon, 20 Feb 2017 13:55:01 -0700 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170216145503.GK15361@bod> Message-ID: <20170220205501.GA26919@mutt.xyzz.org> * Manik Taneja wrote: > * Max Brustkern wrote: > > I'd like to trigger tests to run when new core snaps are > > available in the stable and candidate channels. What's the > > best way to check that? > > i suspect that you will like to run tests after installing a > newer rev of a snap from the candidate/stable channels. at the > moment, i believe your best option is to poll the store for a > newer revision. once available, update the device explicitly > using snap refresh and than run whatever tests you > like. if its a snap that you published yourself, you could run > hooks on install automatically that can trigger whatever tests > you like. > moving forward, we will need to work on a better approach via > push-notifications (perhaps) that will tell a device about a > new revision and also allow the capability to install it > immediately, instead of waiting for the next update-timer to > kick in. What's happening is a host server is checking for updates to everything in a default install. When updates are found, the host builds a brand new set of images, flashes them to every supported device, and runs a large test suite on each. After the test suite is done, the device is considered dirty and not used again until it's reflashed. In some cases, the devices are virtual and get deleted after the tests finish. Automatic updates (snap refresh timer) generally invalidate the test results, and should be disabled. For now, I suspect we'll just do a lot of polling. -- Selene From joseph.wakeling at webdrake.net Mon Feb 20 21:12:25 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 20 Feb 2017 22:12:25 +0100 Subject: Position-independent code and Ubuntu 16.10 Message-ID: <24567486-8e88-9c3e-5db3-20fd4610af94@webdrake.net> Hello all, Turns out my ldc2 compiler snap fails to work correctly on Ubuntu 16.10. When linking programs it falls over with the following message: /usr/bin/ld: /snap/ldc2/4/bin/../lib/libdruntime-ldc.a(errno.c.o): relocation R_X86_64_PC32 against symbol `__errno_location@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 There's an upstream fix for this in progress, but I wanted to check my understanding of the situation regarding cleanbuild and classic snaps. First, I'd thought that Ubuntu 16.04's GCC already generated position-independent code by default, but was this in fact only introduced with 16.10 ... ? Second, is this something that could be solved by snapcraft itself? It's a bit unintuitive that one could do a `snapcraft cleanbuild` and find that in fact the snap won't work on a later Ubuntu release. Thanks & best wishes, -- Joe From konrad.zapalowicz at canonical.com Tue Feb 21 07:32:20 2017 From: konrad.zapalowicz at canonical.com (=?UTF-8?Q?Konrad_Zapa=C5=82owicz?=) Date: Tue, 21 Feb 2017 08:32:20 +0100 Subject: [System Enablement] New releases Feb 2017 - week 08 In-Reply-To: <20170220095342.GA23028@annapurna> References: <20170220095342.GA23028@annapurna> Message-ID: Hey everyone, We have found a problem with udisks2 snap which makes it fail to perform auto-mount on a systems with big number of mount points. This is fixed now and following revisions are available for testing in candidate channel: udisks2 - 2.1.7-5: * Fix automount failed on system with huge amount of mount points LP #1666179 --- An overview of which revisions / versions of the particular snaps are available in which channel is available at https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# The snaps have passed our engineering QA and will now be tested by the platform and commercial QA teams before the new versions are pushed to the stable channel. Bileto requests are: - udisks2 -2.1.7-5: https://bileto.ubuntu.com/#/ticket/2501 If you have any questions feel free to ping me. regards, Konrad On Mon, Feb 20, 2017 at 10:53 AM, Konrad Zapalowicz wrote: > Hey everyone, > > new releases of the following snaps were pushed into the candidate > channel. > > tpm 1.2-5: > > * Snap aliases for all TPM tools (LP: #1653699) > * Fix typo in tpm.restictpubek (LP: #1637251) > > udisks2 2.1.7-4: > > * Add automount capabilities via ciborium > > --- > > An overview of which revisions / versions of the particular snaps are > available in which channel is available at > https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# > > The snaps have passed our engineering QA and will now be tested by the > platform and commercial QA teams before the new versions are pushed to > the stable channel. > > Bileto requests are: > > - tpm: https://bileto.ubuntu.com/#/ticket/2492 > - udisks2: https://bileto.ubuntu.com/#/ticket/2490 > > > If you have any questions feel free to ping me. > > regards, > Konrad From stuart.bishop at canonical.com Tue Feb 21 08:57:05 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Tue, 21 Feb 2017 15:57:05 +0700 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: On 20 February 2017 at 11:41, James Henstridge wrote: > On 20 February 2017 at 10:45, XiaoGuo Liu wrote: >> Hi James, >> >> Nice. This is a nice example showing how to reduce a python snap package. A >> few days ago, I also made a small example to make use of the python3 coming >> with the core at: >> >> https://github.com/liu-xiao-guo/httpstat >> >> In the above example, I in fact do not package the python. It works. > > So I guess the main differences are that this makes it easy to use a > newer version of Python than existed at the time Xenial was released. > I suspect I could also build a Python 2.7 snap using the same > techniques, if you want to go in the other direction. Yes. I love the idea of being able to use 3.6 or 3.7, and not have to rebuild and release my snaps every time there is a point release. I also like the idea of having easy access to nightly builds of the development branch, and antique versions. I think having old versions packaged in snaps is nicer than the current approach of the deadsnakes ppa. > The Python in my snap is also set up to automatically use packages > included in your own snap without fiddling with environment variables > or sys.path. You could probably also get the pip in your snap to install packages to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs would stick to using virtualenvs outside of the snap for this, assuming a modern enough Python. -- Stuart Bishop From vasilisc777 at gmail.com Tue Feb 21 09:31:07 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 21 Feb 2017 12:31:07 +0300 Subject: xdg-open doesn't work only in xubuntu (v2) In-Reply-To: <1487598999.11011.75.camel@ubuntu.com> References: <94ee5c88-7556-8d30-e6c7-fecf0783fa25@gmail.com> <1487586871.11011.53.camel@ubuntu.com> <8168d044-4f8c-9a0e-57f5-858d7ea563fe@gmail.com> <1487589628.11011.56.camel@ubuntu.com> <70c4a017-b137-0fcf-1431-6e37936cb30f@gmail.com> <1487596414.11011.68.camel@ubuntu.com> <2bc6642e-0f62-1e7a-28a1-44aa89250517@gmail.com> <1487598999.11011.75.camel@ubuntu.com> Message-ID: 20.02.2017 16:56, Oliver Grawert пишет: > ah, sorry, i was wrong about the $SNAP in the PATH ... > > i grabbed your example and changed it like: > > http://paste.ubuntu.com/24033840/ > > this definitely works on a unity desktop, i am not sure about desktops > that deliberately replace xdg-open with something non-standard though > (this will likely be fixed by the new implementation that gustavo > talked about in the other thread). Thx! Your solution works. -- Best regards, vasilisc From james.henstridge at canonical.com Tue Feb 21 11:35:29 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Tue, 21 Feb 2017 19:35:29 +0800 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: On 21 February 2017 at 16:57, Stuart Bishop wrote: > On 20 February 2017 at 11:41, James Henstridge > wrote: >> On 20 February 2017 at 10:45, XiaoGuo Liu wrote: >>> Hi James, >>> >>> Nice. This is a nice example showing how to reduce a python snap package. A >>> few days ago, I also made a small example to make use of the python3 coming >>> with the core at: >>> >>> https://github.com/liu-xiao-guo/httpstat >>> >>> In the above example, I in fact do not package the python. It works. >> >> So I guess the main differences are that this makes it easy to use a >> newer version of Python than existed at the time Xenial was released. >> I suspect I could also build a Python 2.7 snap using the same >> techniques, if you want to go in the other direction. > > Yes. I love the idea of being able to use 3.6 or 3.7, and not have to > rebuild and release my snaps every time there is a point release. > > I also like the idea of having easy access to nightly builds of the > development branch, and antique versions. I think having old versions > packaged in snaps is nicer than the current approach of the > deadsnakes ppa. It probably wouldn't be too difficult to build a snap tracking 3.7 development, yeah. >> The Python in my snap is also set up to automatically use packages >> included in your own snap without fiddling with environment variables >> or sys.path. > > You could probably also get the pip in your snap to install packages > to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs > would stick to using virtualenvs outside of the snap for this, > assuming a modern enough Python. With the snap as it stands, it is most useful as a runtime for other snaps rather than for interactive use or for development. If you install my package with --devmode to disable confinement, it could be useful for development, but there isn't really an opportunity for a shared site-packages directory ($SNAP_DATA for the python snap won't be accessible to other snaps). And if you are trying to package up a Python app that will be running under snap confinement, do you want writable locations in the default sys.path? Maybe there is room for some compromise: we could enable a site-packages dir in $SNAP_DATA/$SNAP_USER_DATA when running the interpreter under the python snap's context, but not when running under a different package's confinement. James. > > -- > Stuart Bishop > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From luca.dionisi at gmail.com Tue Feb 21 11:39:16 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Tue, 21 Feb 2017 12:39:16 +0100 Subject: network namespaces Message-ID: Are network namespaces supported in snaps? In my RaspberryPi3 I have a snap which has been installed with --devmode. Inside the snap I have exposed the command 'bash'. I exec that bash as root. Then I try to create a network namespace. It fails. $ sudo myapp.bash # ip netns add ns0 open("/proc/self/ns/net"): Permission denied # Trying to debug this issue, 'dmesg' reports: [ 202.210399] audit_printk_skb: 9 callbacks suppressed [ 202.210424] audit: type=1400 audit(1487674887.359:141): apparmor="ALLOWED" operation="exec" profile="snap.myapp.bash" name="/bin/ip" pid=1440 comm="bash" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="snap.myapp.bash//null-/bin/ip" [ 202.213971] audit: type=1400 audit(1487674887.363:142): apparmor="ALLOWED" operation="open" profile="snap.myapp.bash//null-/bin/ip" name="/etc/ld.so.cache" pid=1440 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 202.214143] audit: type=1400 audit(1487674887.363:143): apparmor="ALLOWED" operation="open" profile="snap.myapp.bash//null-/bin/ip" name="/lib/arm-linux-gnueabihf/libdl-2.23.so" pid=1440 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 202.214578] audit: type=1400 audit(1487674887.363:144): apparmor="ALLOWED" operation="open" profile="snap.myapp.bash//null-/bin/ip" name="/lib/arm-linux-gnueabihf/libc-2.23.so" pid=1440 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 202.215355] audit: type=1400 audit(1487674887.363:145): apparmor="ALLOWED" operation="file_mprotect" profile="snap.myapp.bash//null-/bin/ip" name="/bin/ip" pid=1440 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 202.215462] audit: type=1400 audit(1487674887.363:146): apparmor="ALLOWED" operation="file_mprotect" profile="snap.myapp.bash//null-/bin/ip" name="/lib/arm-linux-gnueabihf/ld-2.23.so" pid=1440 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 [ 202.215924] audit: type=1400 audit(1487674887.367:147): apparmor="ALLOWED" operation="create" profile="snap.myapp.bash//null-/bin/ip" pid=1440 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create" [ 202.216035] audit: type=1400 audit(1487674887.367:148): apparmor="ALLOWED" operation="setsockopt" profile="snap.myapp.bash//null-/bin/ip" pid=1440 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="setopt" denied_mask="setopt" [ 202.216087] audit: type=1400 audit(1487674887.367:149): apparmor="ALLOWED" operation="setsockopt" profile="snap.myapp.bash//null-/bin/ip" pid=1440 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="setopt" denied_mask="setopt" [ 202.216145] audit: type=1400 audit(1487674887.367:150): apparmor="ALLOWED" operation="bind" profile="snap.myapp.bash//null-/bin/ip" pid=1440 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="bind" denied_mask="bind" And 'snappy-debug.security scanlog' reports: = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="exec" profile="snap.myapp.bash" name="/bin/ip" pid=1572 comm="bash" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="snap.myapp.bash//null-/bin/ip" File: /bin/ip (exec) Suggestions: * adjust snap to ship 'ip' * adjust program to use relative paths if the snap already ships 'ip' = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="open" profile="snap.myapp.bash//null-/bin/ip" name="/etc/ld.so.cache" pid=1572 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /etc/ld.so.cache (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="open" profile="snap.myapp.bash//null-/bin/ip" name="/lib/arm-linux-gnueabihf/libdl-2.23.so" pid=1572 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /lib/arm-linux-gnueabihf/libdl-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="open" profile="snap.myapp.bash//null-/bin/ip" name="/lib/arm-linux-gnueabihf/libc-2.23.so" pid=1572 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /lib/arm-linux-gnueabihf/libc-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="file_mprotect" profile="snap.myapp.bash//null-/bin/ip" name="/bin/ip" pid=1572 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /bin/ip (read) Suggestions: * adjust snap to ship 'ip' * adjust program to use relative paths if the snap already ships 'ip' = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="file_mprotect" profile="snap.myapp.bash//null-/bin/ip" name="/lib/arm-linux-gnueabihf/ld-2.23.so" pid=1572 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 File: /lib/arm-linux-gnueabihf/ld-2.23.so (read) Suggestion: * adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="create" profile="snap.myapp.bash//null-/bin/ip" pid=1572 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create" Suggestion: * add one of 'account-control, network-control' to 'plugs' = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="setsockopt" profile="snap.myapp.bash//null-/bin/ip" pid=1572 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="setopt" denied_mask="setopt" Suggestion: * add one of 'account-control, network-control' to 'plugs' = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="setsockopt" profile="snap.myapp.bash//null-/bin/ip" pid=1572 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="setopt" denied_mask="setopt" Suggestion: * add one of 'account-control, network-control' to 'plugs' = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="bind" profile="snap.myapp.bash//null-/bin/ip" pid=1572 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="bind" denied_mask="bind" Suggestion: * add one of 'account-control, network-control' to 'plugs' = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="getsockname" profile="snap.myapp.bash//null-/bin/ip" pid=1572 comm="ip" family="netlink" sock_type="raw" protocol=0 requested_mask="getattr" denied_mask="getattr" Suggestion: * add one of 'account-control, network-control' to 'plugs' = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.myapp.bash//null-/bin/ip" name="" pid=1572 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 = AppArmor = Time: Feb 21 11:17:49 Log: apparmor="ALLOWED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 profile="snap.myapp.bash//null-/bin/ip" name="dev/pts/0" pid=1572 comm="ip" requested_mask="r" denied_mask="r" fsuid=0 ouid=1000 My environment (from snap list): Name Version Rev Developer Notes core 16.04.1 1083 canonical - pi2-kernel 4.4.0-1030-3 22 canonical - pi3 16.04-0.5 6 canonical - snappy-debug 0.29 27 canonical - Regards --Luca From jenny.murphy at episensor.com Tue Feb 21 12:08:49 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Tue, 21 Feb 2017 12:08:49 +0000 Subject: the ppp interface (and general renaming/transitioning of interfaces) In-Reply-To: <1486461237.11948.57.camel@ubuntu.com> References: <1486388187.11948.15.camel@ubuntu.com> <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> <95d40fb9-4cec-7700-bb68-603e7e150fe2@canonical.com> <1486393610.11948.47.camel@ubuntu.com> <20170206201416.GA23184@orwell.home> <1486461237.11948.57.camel@ubuntu.com> Message-ID: Hi, Just about this ppp interface. I would like to use it from the snap I have developed myself. So how to I invoke it ? At the moment I am calling the command line pppd from my snap java code. However I think I should be doing something different to invoke ppp from within the core snap ? I am not asking about use of ppp in general, I have plently of experience with that. It is the use of ppp in the containerized format that I ask about. Here is the sort of denials I am getting : Time: Feb 20 10:20:44 Log: apparmor="ALLOWED" operation="exec" profile="snap.gateway.main" name="/usr/sbin/pppd" pid=10089 comm="java" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="snap.gateway.main// null-/usr/sbin/pppd" File: /usr/sbin/pppd (exec) Suggestions: * adjust snap to ship 'pppd' * adjust program to use relative paths if the snap already ships 'pppd' Thanks in advance for any help. Jenny On 7 February 2017 at 09:53, Oliver Grawert wrote: > hi, > Am Montag, den 06.02.2017, 20:14 +0000 schrieb Jamie Bennett: > > On 06/02/17 at 04:06P, Oliver Grawert wrote: > > > > > > hi, > > > Am Montag, den 06.02.2017, 15:50 +0100 schrieb Simon Fels: > > > > > > > > > > > > I've just checked this and all pppd things are still in core. See > > > > https://paste.ubuntu.com/23941360/ > > > > > > > wow, this is weird, yes, it is indeed still in there, i was 100% > > > sure > > > it was dropped together with the watchdog package when i got a ping > > > from you guys to drop both after 15.04 ... but i just checked the > > > respecting seed diff and noticed only watchdog was actually dropped > > > ... > > > > > > so please ignore this ... > > > > > > yet, we probably still want an interface that allows access to > > > console > > > devices only. and also plan some process in case we need to rename > > > interfaces if their backend changes. > > Access to serial tty-only devices makes sense and a dedicated > > interface makes > > sense. > > note this is about tty not ttyS ... no serial involved just local > console device access :) > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.bishop at canonical.com Tue Feb 21 12:53:31 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Tue, 21 Feb 2017 19:53:31 +0700 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: On 21 February 2017 at 18:35, James Henstridge wrote: >> You could probably also get the pip in your snap to install packages >> to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs >> would stick to using virtualenvs outside of the snap for this, >> assuming a modern enough Python. > > With the snap as it stands, it is most useful as a runtime for other > snaps rather than for interactive use or for development. If you > install my package with --devmode to disable confinement, it could be > useful for development, but there isn't really an opportunity for a > shared site-packages directory ($SNAP_DATA for the python snap won't > be accessible to other snaps). I think I was thinking that the main snap could use classic confinement, allowing you to use it as the interpreter for scripts located anywhere. And snaps using the interface would remain contained as they are. Assuming we are allowed to mix interfaces and classic confinement :) But now I think on it further, its probably not a good idea to pollute the main python snap when it is being used as a dependency. -- Stuart Bishop From james at jamesh.id.au Tue Feb 21 13:30:42 2017 From: james at jamesh.id.au (James Henstridge) Date: Tue, 21 Feb 2017 21:30:42 +0800 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: On 21 February 2017 at 20:53, Stuart Bishop wrote: > On 21 February 2017 at 18:35, James Henstridge > wrote: > >>> You could probably also get the pip in your snap to install packages >>> to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs >>> would stick to using virtualenvs outside of the snap for this, >>> assuming a modern enough Python. >> >> With the snap as it stands, it is most useful as a runtime for other >> snaps rather than for interactive use or for development. If you >> install my package with --devmode to disable confinement, it could be >> useful for development, but there isn't really an opportunity for a >> shared site-packages directory ($SNAP_DATA for the python snap won't >> be accessible to other snaps). > > I think I was thinking that the main snap could use classic > confinement, allowing you to use it as the interpreter for scripts > located anywhere. And snaps using the interface would remain contained > as they are. Assuming we are allowed to mix interfaces and classic > confinement :) As I understand it, this should be fine: when you connect two snaps with the content interface, all it does is bind mounts a directory from the slot-side snap to a mount point within the plug-side snap. It shouldn't matter what confinement policies the two snaps are using. And since the snap data is a read-only squashfs, neither side can alter the content that is being shared. > But now I think on it further, its probably not a good idea to pollute > the main python snap when it is being used as a dependency. Well, it should be pretty easy to detect whether we're running in the context of the Python snap: checking if sys.prefix is equal to $SNAP would probably be enough (from a different snap, the interpreter will be mounted somewhere else). It wouldn't be difficult to add extra directories to sys.path in this case, and with confinement disabled I suspect we'd pick up the standard "user site" directory automatically. So we might be able to do a single package that can both serve as a runtime for other snaps and as a useful Python development environment. James. From sergio.schvezov at canonical.com Tue Feb 21 13:44:11 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 21 Feb 2017 13:44:11 +0000 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: <5tphju.olq8tt.1hge15f-qmf@smtp.googlemail.com> On Tue, 21 Feb 2017 19:53:31 +0700, Stuart Bishop wrote: > On 21 February 2017 at 18:35, James Henstridge > wrote: > >>> You could probably also get the pip in your snap to install packages >>> to $SNAP_USER_DATA or $SNAP_DATA if run as root. Although most devs >>> would stick to using virtualenvs outside of the snap for this, >>> assuming a modern enough Python. >> >> With the snap as it stands, it is most useful as a runtime for other >> snaps rather than for interactive use or for development. If you >> install my package with --devmode to disable confinement, it could be >> useful for development, but there isn't really an opportunity for a >> shared site-packages directory ($SNAP_DATA for the python snap won't >> be accessible to other snaps). > > I think I was thinking that the main snap could use classic > confinement, allowing you to use it as the interpreter for scripts > located anywhere. And snaps using the interface would remain contained > as they are. Assuming we are allowed to mix interfaces and classic > confinement :) > > But now I think on it further, its probably not a good idea to pollute > the main python snap when it is being used as a dependency. While I was fixing our python plugin in snapcraft (released in 2.27) to detect interpreters that might have been staged and reuse those (mostly to support classic confined snaps), Zygmunt was busy playing with python as classic confined snaps... not sure what the progress is with other versions, but `snap find` can take you back in time: python0 0.9.1 zygoon classic Ancient version of Python for programming archeologists Some may call this duplication of effort, but I call it independent confirmation, we all took a similar path to enable this even though the final purpose may differ. -- From ogra at ubuntu.com Tue Feb 21 14:06:54 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 21 Feb 2017 15:06:54 +0100 Subject: the ppp interface (and general renaming/transitioning of interfaces) In-Reply-To: References: <1486388187.11948.15.camel@ubuntu.com> <33c0aa07-e5e1-6b66-a82e-5f0925e6a037@canonical.com> <95d40fb9-4cec-7700-bb68-603e7e150fe2@canonical.com> <1486393610.11948.47.camel@ubuntu.com> <20170206201416.GA23184@orwell.home> <1486461237.11948.57.camel@ubuntu.com> Message-ID: <1487686014.29003.2.camel@ubuntu.com> hi, On Di, 2017-02-21 at 12:08 +0000, Jenny Murphy wrote: > Hi, >  Just about this ppp interface. > I would like to use it from the snap I have developed myself. > So how to I invoke it ? > At the moment I am calling the command line pppd from my snap java > code. > However I think I should be doing something different to invoke ppp > from within the core snap ? the ppp interface allows you to just call /usr/bin/pppd and also to write and modify files in /etc/ppp. so if your management snap is connected to the ppp interface it should just be able to use everything directly [1]. ciao oli [1] https://github.com/snapcore/snapd/blob/master/interfaces/builtin/pp p.go -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From barry at ubuntu.com Tue Feb 21 15:31:03 2017 From: barry at ubuntu.com (Barry Warsaw) Date: Tue, 21 Feb 2017 10:31:03 -0500 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: <20170221103103.01507a6c@subdivisions.wooz.org> On Feb 21, 2017, at 07:35 PM, James Henstridge wrote: >It probably wouldn't be too difficult to build a snap tracking 3.7 >development, yeah. Now that CPython development has moved to GitHub, I wonder if this isn't something we could automate, with a mirror on Launchpad. On Feb 21, 2017, at 07:53 PM, Stuart Bishop wrote: On 21 February 2017 at 18:35, James Henstridge >I think I was thinking that the main snap could use classic >confinement, allowing you to use it as the interpreter for scripts >located anywhere. And snaps using the interface would remain contained >as they are. Assuming we are allowed to mix interfaces and classic >confinement :) > >But now I think on it further, its probably not a good idea to pollute >the main python snap when it is being used as a dependency. An important feature would be allowing those other snaps which use the interpreter snap to "install" extension modules. Pure Python package are generally no problem, but the shared libraries of extension modules have to be compiled with the same flags as the interpreter they'll be dynamically loaded into, and they are of course specific to the platform's architecture. Something else that would be kind of cool to experiment, from a platform point of view, is an idea many of us who work on various Linux distros have wanted for a while: a Python interpreter for system operations separate from one for general user consumption (i.e. developers and application administrators). For the OS, we want an interpreter that's more locked down, that won't be influenced by a user's $PATH, $PYTHONPATH, $PYTHONSTARTUP, or whatever stuff someone might have randomly pip installed. So I muse that if the safe system interpreter (not called /usr/bin/python3) were a classic snap, with a locked down, but still extensible through third party modules in a controlled way, then system scripts would use that (e.g. /usr/bin/spython perhaps). The regular /usr/bin/python3 then would be more flexible for end users because they would know that they can't break their system by messing with that interpreter's environment. (Yes, they could break their own apps, but caveat emptor). Cheers, -Barry From barry at ubuntu.com Tue Feb 21 15:37:12 2017 From: barry at ubuntu.com (Barry Warsaw) Date: Tue, 21 Feb 2017 10:37:12 -0500 Subject: Experimental Python interpreter snap In-Reply-To: References: Message-ID: <20170221103712.71207030@subdivisions.wooz.org> On Feb 21, 2017, at 09:30 PM, James Henstridge wrote: >So we might be able to do a single package that can both serve as a >runtime for other snaps and as a useful Python development >environment. It would be interesting to see, but my tendency is to want separate interpreter environments for different purposes. See my previous post re: a locked down system interpreter for /usr/bin scripts. The problem with one-size-fits-all (and we have this problem today with deb-based /usr/bin/python{2,3}) is that people sudo pip install all kinds of crazy things into their {site,dist}-packages, and that can break things, which are difficult to debug (though we're adding some useful features to 3.7 to help with that). So I think it makes some sense to separate these concerns: OS platform use, confined snap application use, developer playground. Virtualenvs are the typical "Pythonic" way of doing that, but snaps provide another opportunity for confinement. (Of course "/usr/bin/python{,2,3}" is the long-established ui for that developer playground.) Cheers, -Barry From dev at tobostudio.com Tue Feb 21 16:03:05 2017 From: dev at tobostudio.com (Dev Dev) Date: Tue, 21 Feb 2017 11:03:05 -0500 Subject: snap connect myapp:camera out-of-the-box Message-ID: Hi, Anyone can give me more information (ETA, how it will works) about the connection to camera. Right now, I need to ask my users who installed myapp via the Software Center to open a terminal and run: sudo snap connect myapp:camera It needs to be automagically connected. I reported this issue here: https://bugs.launchpad.net/snapcraft/+bug/1609577 Thanks From ogra at ubuntu.com Tue Feb 21 16:15:30 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 21 Feb 2017 17:15:30 +0100 Subject: snap connect myapp:camera out-of-the-box In-Reply-To: References: Message-ID: <1487693730.11513.35.camel@ubuntu.com> hi, Am Dienstag, den 21.02.2017, 11:03 -0500 schrieb Dev Dev: > Hi, > > Anyone can give me more information (ETA, how it will works) about > the > connection to camera. Right now, I need to ask my users who installed > myapp via the Software Center to open a terminal and run: > sudo snap connect myapp:camera > > It needs to be automagically connected. if that was the case, what would keep me from creating "myapp-so-much- more-shiny" that then quietly and constantly streams the camera pic to some website without the user knowing ? (and also since i used the myapp name in my snap your company might even get the blame for the spying as well as the bad press around it) the manual connection of some risky interfaces is exactly what keeps the users safe from bad stuff happening, we would not need interfaces if we connected all of them automatically. i agree that having a more interactive way is the way to go here ... i.e. if you install a gui app it should ask for the connection on first access (and only on first) ... or when installing from cmdline it might offer the connection at install time, but such potentially security critical interfaces should really not auto-connect. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From gustavo at niemeyer.net Tue Feb 21 16:23:37 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Tue, 21 Feb 2017 13:23:37 -0300 Subject: snap connect myapp:camera out-of-the-box In-Reply-To: <1487693730.11513.35.camel@ubuntu.com> References: <1487693730.11513.35.camel@ubuntu.com> Message-ID: Actually, we do have a mechanism that enables the automatic connections in those cases, and we can enable it in sensible cases, even for the camera. The question we should ask here is this: what is the snap purpose? Is it clear from the snap name and description that this is using a camera? If the answer yes, then I think it's fine to auto-connect. In this particular case, the snap name is called "webcam-webui". IMO, it'd be fine to auto-connect it. Jamie? On Tue, Feb 21, 2017 at 1:15 PM, Oliver Grawert wrote: > hi, > Am Dienstag, den 21.02.2017, 11:03 -0500 schrieb Dev Dev: > > Hi, > > > > Anyone can give me more information (ETA, how it will works) about > > the > > connection to camera. Right now, I need to ask my users who installed > > myapp via the Software Center to open a terminal and run: > > sudo snap connect myapp:camera > > > > It needs to be automagically connected. > > if that was the case, what would keep me from creating "myapp-so-much- > more-shiny" that then quietly and constantly streams the camera pic to > some website without the user knowing ? (and also since i used the > myapp name in my snap your company might even get the blame for the > spying as well as the bad press around it) > > the manual connection of some risky interfaces is exactly what keeps > the users safe from bad stuff happening, we would not need interfaces > if we connected all of them automatically. > > i agree that having a more interactive way is the way to go here ... > i.e. if you install a gui app it should ask for the connection on first > access (and only on first) ... or when installing from cmdline it might > offer the connection at install time, but such potentially security > critical interfaces should really not auto-connect. > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Tue Feb 21 17:12:32 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 21 Feb 2017 11:12:32 -0600 Subject: snap connect myapp:camera out-of-the-box In-Reply-To: References: <1487693730.11513.35.camel@ubuntu.com> Message-ID: <1487697152.3972.16.camel@canonical.com> On Tue, 2017-02-21 at 13:23 -0300, Gustavo Niemeyer wrote: > Actually, we do have a mechanism that enables the automatic connections in > those cases, and we can enable it in sensible cases, even for the camera. > > The question we should ask here is this: what is the snap purpose?  Is it > clear from the snap name and description that this is using a camera? > > If the answer yes, then I think it's fine to auto-connect. > > In this particular case, the snap name is called "webcam-webui". IMO, it'd > be fine to auto-connect it.  Jamie? > In general, I agree with what you described for special cases where it is obvious what the snap is and its functionality can be deduced. Personally, I think that where it is obvious should be the snap name, not the description, because people tend to only see the snap name and the description can change at a later date to not meet our review criteria. While the bug refers to 'webcam-webui', I spoke with the 'Dev Dev' on irc and the snap in question is actually 'Bayam' and the description in the store is "Bayam, jeux, découvertes et activités pour enfants" which google translate tells me is "Bayam, games, discoveries and activities for children". Nothing in that would give me the expectation that the snap would have access to the camera. I then explained how interfaces work and why and did not grant the snap declaration. I then advised the conversation should be taken here in part to ask "What are the plans for making snap connections easier for cli, snapweb and gnome-software installs and what is the timeline of that work?" > On Tue, Feb 21, 2017 at 1:15 PM, Oliver Grawert wrote: > > > > > hi, > > Am Dienstag, den 21.02.2017, 11:03 -0500 schrieb Dev Dev: > > > > > > Hi, > > > > > > Anyone can give me more information (ETA, how it will works) about > > > the > > > connection to camera. Right now, I need to ask my users who installed > > > myapp via the Software Center to open a terminal and run: > > > sudo snap connect myapp:camera > > > > > > It needs to be automagically connected. > > if that was the case, what would keep me from creating "myapp-so-much- > > more-shiny" that then quietly and constantly streams the camera pic to > > some website without the user knowing ? (and also since i used the > > myapp name in my snap your company might even get the blame for the > > spying as well as the bad press around it) > > > > the manual connection of some risky interfaces is exactly what keeps > > the users safe from bad stuff happening, we would not need interfaces > > if we connected all of them automatically. > > > > i agree that having a more interactive way is the way to go here ... > > i.e. if you install a gui app it should ask for the connection on first > > access (and only on first) ... or when installing from cmdline it might > > offer the connection at install time, but such potentially security > > critical interfaces should really not auto-connect. > > > > ciao > >         oli > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > mailman/listinfo/snapcraft > > > > > > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/s > napcraft -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gustavo at niemeyer.net Tue Feb 21 17:24:54 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Tue, 21 Feb 2017 14:24:54 -0300 Subject: snap connect myapp:camera out-of-the-box In-Reply-To: <1487697152.3972.16.camel@canonical.com> References: <1487693730.11513.35.camel@ubuntu.com> <1487697152.3972.16.camel@canonical.com> Message-ID: Okay, agreed on all points. The near-to-medium term plan is to have snaps able to request access to particular interfaces on demand. We have a good pipeline to implement this already. We just need to connect the dots. On Tue, Feb 21, 2017 at 2:12 PM, Jamie Strandboge wrote: > On Tue, 2017-02-21 at 13:23 -0300, Gustavo Niemeyer wrote: > > Actually, we do have a mechanism that enables the automatic connections > in > > those cases, and we can enable it in sensible cases, even for the camera. > > > > The question we should ask here is this: what is the snap purpose? Is it > > clear from the snap name and description that this is using a camera? > > > > If the answer yes, then I think it's fine to auto-connect. > > > > In this particular case, the snap name is called "webcam-webui". IMO, > it'd > > be fine to auto-connect it. Jamie? > > > > In general, I agree with what you described for special cases where it is > obvious what the snap is and its functionality can be deduced. Personally, > I > think that where it is obvious should be the snap name, not the > description, > because people tend to only see the snap name and the description can > change at > a later date to not meet our review criteria. > > While the bug refers to 'webcam-webui', I spoke with the 'Dev Dev' on irc > and > the snap in question is actually 'Bayam' and the description in the store > is > "Bayam, jeux, découvertes et activités pour enfants" which google translate > tells me is "Bayam, games, discoveries and activities for children". > Nothing in > that would give me the expectation that the snap would have access to the > camera. I then explained how interfaces work and why and did not grant the > snap > declaration. I then advised the conversation should be taken here in part > to ask > "What are the plans for making snap connections easier for cli, snapweb and > gnome-software installs and what is the timeline of that work?" > > > On Tue, Feb 21, 2017 at 1:15 PM, Oliver Grawert wrote: > > > > > > > > hi, > > > Am Dienstag, den 21.02.2017, 11:03 -0500 schrieb Dev Dev: > > > > > > > > Hi, > > > > > > > > Anyone can give me more information (ETA, how it will works) about > > > > the > > > > connection to camera. Right now, I need to ask my users who installed > > > > myapp via the Software Center to open a terminal and run: > > > > sudo snap connect myapp:camera > > > > > > > > It needs to be automagically connected. > > > if that was the case, what would keep me from creating "myapp-so-much- > > > more-shiny" that then quietly and constantly streams the camera pic to > > > some website without the user knowing ? (and also since i used the > > > myapp name in my snap your company might even get the blame for the > > > spying as well as the bad press around it) > > > > > > the manual connection of some risky interfaces is exactly what keeps > > > the users safe from bad stuff happening, we would not need interfaces > > > if we connected all of them automatically. > > > > > > i agree that having a more interactive way is the way to go here ... > > > i.e. if you install a gui app it should ask for the connection on first > > > access (and only on first) ... or when installing from cmdline it might > > > offer the connection at install time, but such potentially security > > > critical interfaces should really not auto-connect. > > > > > > ciao > > > oli > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > > mailman/listinfo/snapcraft > > > > > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/s > > napcraft > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.larson at canonical.com Tue Feb 21 17:25:57 2017 From: paul.larson at canonical.com (Paul Larson) Date: Tue, 21 Feb 2017 11:25:57 -0600 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: <20170220205501.GA26919@mutt.xyzz.org> References: <20170216145503.GK15361@bod> <20170220205501.GA26919@mutt.xyzz.org> Message-ID: On Mon, Feb 20, 2017 at 2:55 PM, Selene Scriven wrote: > What's happening is a host server is checking for updates to > everything in a default install. When updates are found, the > host builds a brand new set of images, flashes them to every > supported device, and runs a large test suite on each. After the > test suite is done, the device is considered dirty and not used > again until it's reflashed. In some cases, the devices are > virtual and get deleted after the tests finish. Automatic > updates (snap refresh timer) generally invalidate the test > results, and should be disabled. > > For now, I suspect we'll just do a lot of polling. Not sure if this helps, but for the things I run, when it detects there is a new candidate snap that I need to test, it does the following: 1. Install the most recent image 2. snap refresh (get everything up to the current stable) 3. snap refresh --candidate [snapname] (so we *just* get the candidate snap for the new one that we want to test) 4. force a reboot 5. disable updates (for added paranoia, because yes I really did see a stable update to a snap that triggered a reboot in the middle of a test once!) Then you can have a clean system that just contains the latest stable version plus the candidate for the thing you want to test. From jamie at canonical.com Tue Feb 21 17:53:48 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 21 Feb 2017 11:53:48 -0600 Subject: network namespaces In-Reply-To: References: Message-ID: <1487699628.3972.19.camel@canonical.com> On Tue, 2017-02-21 at 12:39 +0100, Luca Dionisi wrote: > Are network namespaces supported in snaps? > > In my RaspberryPi3 I have a snap which has been installed with --devmode. > Inside the snap I have exposed the command 'bash'. I exec that bash as > root. Then I try to create a network namespace. It fails. > > $ sudo myapp.bash > # ip netns add ns0 > open("/proc/self/ns/net"): Permission denied > # > You are hitting this bug: https://bugs.launchpad.net/apparmor/+bug/1648903 The workaround is to declare in your snap 'plugs: [ network-control ]' and to connect the interface with 'sudo snap connect myapp:network-control' even when using devmode. After that you should be able to use 'ip netns' within your snap. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From seth.arnold at canonical.com Tue Feb 21 21:47:25 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Tue, 21 Feb 2017 13:47:25 -0800 Subject: Position-independent code and Ubuntu 16.10 In-Reply-To: <24567486-8e88-9c3e-5db3-20fd4610af94@webdrake.net> References: <24567486-8e88-9c3e-5db3-20fd4610af94@webdrake.net> Message-ID: <20170221214725.GA5132@hunt> On Mon, Feb 20, 2017 at 10:12:25PM +0100, Joseph Rushton Wakeling wrote: > First, I'd thought that Ubuntu 16.04's GCC already generated > position-independent code by default, but was this in fact only introduced > with 16.10 ... ? Correct, this was changed for 16.10: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes#GCC Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From joseph.wakeling at webdrake.net Tue Feb 21 22:01:48 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 21 Feb 2017 23:01:48 +0100 Subject: Position-independent code and Ubuntu 16.10 In-Reply-To: <20170221214725.GA5132@hunt> References: <24567486-8e88-9c3e-5db3-20fd4610af94@webdrake.net> <20170221214725.GA5132@hunt> Message-ID: <5c2326ee-6d7f-e822-cd3e-50b248d8516a@webdrake.net> On 21/02/17 22:47, Seth Arnold wrote: > On Mon, Feb 20, 2017 at 10:12:25PM +0100, Joseph Rushton Wakeling wrote: >> First, I'd thought that Ubuntu 16.04's GCC already generated >> position-independent code by default, but was this in fact only introduced >> with 16.10 ... ? > > Correct, this was changed for 16.10: > https://wiki.ubuntu.com/YakketyYak/ReleaseNotes#GCC OK, thanks for the clarification. So this raises the question ... can/should snapcraft ensure this option is used when building snap packages? It's obviously not an issue for most apps, but any snap exposing a development library in any way is presumably going to risk being unusable on 16.10 or later if the package author doesn't realize this is necessary. From manik at canonical.com Tue Feb 21 22:10:19 2017 From: manik at canonical.com (Manik Taneja) Date: Tue, 21 Feb 2017 14:10:19 -0800 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170216145503.GK15361@bod> <20170220205501.GA26919@mutt.xyzz.org> Message-ID: On Tue, Feb 21, 2017 at 9:25 AM, Paul Larson wrote: > > 5. disable updates (for added paranoia, because yes I really did see a > stable update to a snap that triggered a reboot in the middle of a > test once!) > how are you disabling updates? fyi, the systemd.update-timer is no more.. /manik -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.arnold at canonical.com Tue Feb 21 23:08:15 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Tue, 21 Feb 2017 15:08:15 -0800 Subject: Position-independent code and Ubuntu 16.10 In-Reply-To: <5c2326ee-6d7f-e822-cd3e-50b248d8516a@webdrake.net> References: <24567486-8e88-9c3e-5db3-20fd4610af94@webdrake.net> <20170221214725.GA5132@hunt> <5c2326ee-6d7f-e822-cd3e-50b248d8516a@webdrake.net> Message-ID: <20170221230815.GB5132@hunt> On Tue, Feb 21, 2017 at 11:01:48PM +0100, Joseph Rushton Wakeling wrote: > OK, thanks for the clarification. So this raises the question ... > can/should snapcraft ensure this option is used when building snap packages? > > It's obviously not an issue for most apps, but any snap exposing a > development library in any way is presumably going to risk being unusable on > 16.10 or later if the package author doesn't realize this is necessary. Position independent executables have been supported for many years; the recent change was to make this the default output format, so that we can increase the amount of system services and programs that can benefit from the address space layout randomization exploit mitigation. Fixed-position executables continue to be supported and we have no plans to forbid them. Libraries are usually compiled as position independent code; this has not changed. As far as I know, only nginx and the linux kernel were affected by these changes. (Sorry kernel developers. I know git bisect is harder.) Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From joseph.wakeling at webdrake.net Tue Feb 21 23:39:50 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 22 Feb 2017 00:39:50 +0100 Subject: Position-independent code and Ubuntu 16.10 In-Reply-To: <20170221230815.GB5132@hunt> References: <24567486-8e88-9c3e-5db3-20fd4610af94@webdrake.net> <20170221214725.GA5132@hunt> <5c2326ee-6d7f-e822-cd3e-50b248d8516a@webdrake.net> <20170221230815.GB5132@hunt> Message-ID: On 22/02/17 00:08, Seth Arnold wrote: > Libraries are usually compiled as position independent code; this has not > changed. OK, fair enough. In my case I think it was the C-library parts of the D standard library that were being compiled without PIC. Seems OK to assume this may have been a project-specific thing, then (which is now fixed upstream). From robert.ancell at canonical.com Wed Feb 22 03:10:13 2017 From: robert.ancell at canonical.com (Robert Ancell) Date: Wed, 22 Feb 2017 03:10:13 +0000 Subject: snapd REST API documentation Message-ID: Hi all, I've spent some time updating the snapd REST API documentation for snapd [1]. It should be now pretty comprehensive. If you've looked at these docs in the past and found information missing, please look again. (Of course, if you're directly using this API please consider the Go library with snapd or snapd-glib [2] instead). It's a Wiki, so please edit as appropriate! If you're making a change to snapd please update the docs when you do that. Since they're not in tree anymore I think they've been a little neglected 😞. On the plus side, since they're a Wiki they're really easy to update quickly. A little documentation is better than none, things can always be fleshed out later. Happy hacking --Robert [1] https://github.com/snapcore/snapd/wiki/REST-API [2] https://launchpad.net/snapd-glib -------------- next part -------------- An HTML attachment was scrubbed... URL: From sunny.bhayani at einfochips.com Wed Feb 22 07:52:48 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Wed, 22 Feb 2017 07:52:48 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support Message-ID: Hi Ogra, Appreciate for your help. > hi, > Am Freitag, den 17.02.2017, 10:06 +0000 schrieb Sunny Bhayani: > > > > > > You are correct that in the prebuilt image (Ubuntu OS) for > > Dragonboard, the Wifi > > module is auto-loaded during boot. But in our case, this does not > > happen. > > > > So can you please let us know, that in what part (plugin) of the > > snapcraft.yaml > > do we need to mention the kernel modules that needs to be auto-loaded > > during the > > kernel boot. > > > > We tried to add the kernel module in the snapcraft.yaml as below: > > > > kernel-initrd-modules: > > - squashfs > > - wcn36xx > > this would just pull the module into the initrd which would be useless, > since we do not ship any userspace bits for WIFI support in there. > if you can modprobe it it is obviously already in the right place in > your /lib/modules dir on the booted system, so first of all remove it > from the list above. having it already loaded from the initrd on boot > might make it miss the right initialization since it wont find all the > userspace bits that it needs in the initrd. > > also make sure you have the firmware in the right place on the booted > rootfs, this is how it looks like on the official dragoboard image: > > http://paste.ubuntu.com/24012991/ > Yes, we have the /lib/modules and /lib/firmware populated as you have mentioned above. > > > > Also, we went through the kernel-initrd-modules description: > > https://snapcraft.io/docs/reference/plugins/kernel > > > > and there it is mentioned that the "kernel-initrd-modules" plugin is > > used to > > mention the modules required to mount the rootfs. > > this means filesystem or disk controller modules (squashfs, ext4 (if > you do not compile it in), mmc support and the like), since your system > boots to a rootfs already you should not need anything more than you > currently have. > > > > Yes, agreed as you have mentioned above for the "kernel-initrd-modules". > > > > It would be great if you can please help us out on this front as well > > for the > > snap list / snap install for the Ubuntu OS. > > this definitely means that snapd did not start for some reason, like i > mentioned before this could be caused by the firstboot initialization > of the board having failed or by some missing feature that snapd > expects from your kernel. > > does sudo journalctl -u snapd.service reveal anything ? > do you find anything interesting in syslog in general ? > We are seeing error related to AppArmor patches in journalctl log. The log is at: http://pastebin.com/vG9DQfTf > > > > > > Yes. We are using a USB to Ethernet module on dragonboard to use the > > Ethernet. > > > did you check if the behaviour of the WLAN device changes when booting > without the USB dongle attached ? > This we have not checked. Will update for this. > > While using the prebuilt image for Dragonboard, we are able to > > configure the > > access point for Wifi interface in the first boot screen, but then > > while doing > > ssh to the board, it is asking for password (during first boot). How > > can we > > resolve this ? > > > > did console-conf (the first boot configuration UI) actually finish the > user creation properly (did it tell you about it and give you info > about how to ssh into the board) without any errors ? > > /var/log/console-conf/subiquity-debug.log might be informative here. > The subiquity-debug.log is at: http://pastebin.com/39zsb4nE The AppArmor patches that we ported from the http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/configs/snappy?h=snappy_v3.10 are for the linux kernel 3.10. But the kernel that we are referring to is from 96boards - linux kernel 4.4. Moreover, the prebuilt image is also built for linux kernel 4.4. So do you have a kernel source for AppArmor patches which are ported on linux kernel 4.4 like the prebuilt Ubuntu Core Image for Dragonboard410c. Please provide the patchset link for the latest kernel. Awaiting your reply. Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Wed Feb 22 09:19:25 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 22 Feb 2017 10:19:25 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: Message-ID: <1487755165.11513.51.camel@ubuntu.com> hi, Am Mittwoch, den 22.02.2017, 07:52 +0000 schrieb Sunny Bhayani: >  > > >  > > > Also, we went through the kernel-initrd-modules description: > > > https://snapcraft.io/docs/reference/plugins/kernel > > >  > > > and there it is mentioned that the "kernel-initrd-modules" plugin > is > > > used to  > > > mention the modules required to mount the rootfs. > >  > > this means filesystem or disk controller modules (squashfs, ext4 > (if > > you do not compile it in), mmc support and the like), since your > system > > boots to a rootfs already you should not need anything more than > you > > currently have. > >  > > > >  > Yes, agreed as you have mentioned above for the "kernel-initrd- > modules". right, just make sure to not also have the WLAN module in there, you only want to load that one from the rootfs where it can also find its firmware and has all user space tools available. > > > >  > > > It would be great if you can please help us out on this front as > well > > > for the  > > > snap list / snap install for the Ubuntu OS. > >  > > this definitely means that snapd did not start for some reason, > like i > > mentioned before this could be caused by the firstboot > initialization > > of the board having failed or by some missing feature that snapd > > expects from your kernel. > >  > > does sudo journalctl -u snapd.service reveal anything ? > > do you find anything interesting in syslog in general ? > >  > We are seeing error related to AppArmor patches in journalctl log. > The log is at: http://pastebin.com/vG9DQfTf yes, this definitely looks like apparmor is not working, i have to pass to paolo (or the security team) for this one > > did console-conf (the first boot configuration UI) actually finish > the > > user creation properly (did it tell you about it and give you info > > about how to ssh into the board) without any errors ? > >  > > /var/log/console-conf/subiquity-debug.log might be informative > here. > >  > The subiquity-debug.log is at: http://pastebin.com/39zsb4nE > that looks fine regarding user creation, i dont see anything related to network setup though (neither wired nor wireless), which is a bit strange. > The AppArmor patches that we ported from the  > http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/c > onfigs/snappy?h=snappy_v3.10 > > are for the linux kernel 3.10. > > But the kernel that we are referring to is from 96boards - linux > kernel 4.4. this is definitely wrong, for 4.4 kernels you indeed need to use a 4.4 patch set, another thing for paolo to answer (i'm not even sure you need any patches at all on a 4.4 kernel, all bits might be in-tree already and just some config options might be enough)... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From paolo.pisati at canonical.com Wed Feb 22 10:24:52 2017 From: paolo.pisati at canonical.com (Paolo Pisati) Date: Wed, 22 Feb 2017 11:24:52 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: <1487755165.11513.51.camel@ubuntu.com> References: <1487755165.11513.51.camel@ubuntu.com> Message-ID: <20170222102452.GA16955@harukaze> On Wed, Feb 22, 2017 at 10:19:25AM +0100, Oliver Grawert wrote: > > The AppArmor patches that we ported from the  > > http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/c > > onfigs/snappy?h=snappy_v3.10 > > > > are for the linux kernel 3.10. > > > > But the kernel that we are referring to is from 96boards - linux > > kernel 4.4. > > this is definitely wrong, for 4.4 kernels you indeed need to use a 4.4 > patch set, another thing for paolo to answer (i'm not even sure you > need any patches at all on a 4.4 kernel, all bits might be in-tree > already and just some config options might be enough)... Unfortunately he is not using our Xenial kernel, so he still needs some patches for AA - here's a updated delta of patches on top of stable/linux-4.4.y: https://github.com/piso77/sample-kernels/commits/stable-4.4.y depending of the 4.4.x revision you are using, if you apply all the patches above the "Linux 4.4.50" commit, you will get all you need. -- bye, p. From luca.dionisi at gmail.com Wed Feb 22 11:33:46 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Wed, 22 Feb 2017 12:33:46 +0100 Subject: network namespaces In-Reply-To: <1487699628.3972.19.camel@canonical.com> References: <1487699628.3972.19.camel@canonical.com> Message-ID: The workaround did the job. Thanks. On Tue, Feb 21, 2017 at 6:53 PM, Jamie Strandboge wrote: > On Tue, 2017-02-21 at 12:39 +0100, Luca Dionisi wrote: >> Are network namespaces supported in snaps? >> >> In my RaspberryPi3 I have a snap which has been installed with --devmode. >> Inside the snap I have exposed the command 'bash'. I exec that bash as >> root. Then I try to create a network namespace. It fails. >> >> $ sudo myapp.bash >> # ip netns add ns0 >> open("/proc/self/ns/net"): Permission denied >> # >> > > You are hitting this bug: > https://bugs.launchpad.net/apparmor/+bug/1648903 > > The workaround is to declare in your snap 'plugs: [ network-control ]' and to > connect the interface with 'sudo snap connect myapp:network-control' even when > using devmode. After that you should be able to use 'ip netns' within your snap. > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From konrad.zapalowicz at canonical.com Wed Feb 22 12:17:37 2017 From: konrad.zapalowicz at canonical.com (=?UTF-8?Q?Konrad_Zapa=C5=82owicz?=) Date: Wed, 22 Feb 2017 13:17:37 +0100 Subject: [System Enablement] New releases Feb 2017 - week 08 In-Reply-To: References: <20170220095342.GA23028@annapurna> Message-ID: Hey everyone, We have found another problem with udisks2 snap which made it mount also not-removable media and thus created a security issue. This is fixed now. Moreover we have released tpm2 snap. The following revisions are available for testing in candidate channel tpm2 1.0-4: * Snap aliases for all TPM tools (LP: #1653699) udisks2 2.1.7-6: * Allow udisks2 to mount any filesystem that is supported by the kernel * Prevent any not removable or thumb drives from being mounted --- An overview of which revisions / versions of the particular snaps are available in which channel is available at https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# The snaps have passed our engineering QA and will now be tested by the platform and commercial QA teams before the new versions are pushed to the stable channel. Bileto requests are: - udisks2: https://bileto.ubuntu.com/#/ticket/2509 - tpm2: N/A If you have any questions feel free to ping me. regards, Konrad On Tue, Feb 21, 2017 at 8:32 AM, Konrad Zapałowicz wrote: > Hey everyone, > > We have found a problem with udisks2 snap which makes it fail to perform > auto-mount on a systems with big number of mount points. This is fixed now > and following revisions are available for testing in candidate channel: > > udisks2 - 2.1.7-5: > > * Fix automount failed on system with huge amount of mount points LP #1666179 > > --- > > An overview of which revisions / versions of the particular snaps are > available in which channel is available at > https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# > > The snaps have passed our engineering QA and will now be tested by the > platform and commercial QA teams before the new versions are pushed to > the stable channel. > > Bileto requests are: > > - udisks2 -2.1.7-5: https://bileto.ubuntu.com/#/ticket/2501 > > > If you have any questions feel free to ping me. > > regards, > Konrad > > On Mon, Feb 20, 2017 at 10:53 AM, Konrad Zapalowicz > wrote: >> Hey everyone, >> >> new releases of the following snaps were pushed into the candidate >> channel. >> >> tpm 1.2-5: >> >> * Snap aliases for all TPM tools (LP: #1653699) >> * Fix typo in tpm.restictpubek (LP: #1637251) >> >> udisks2 2.1.7-4: >> >> * Add automount capabilities via ciborium >> >> --- >> >> An overview of which revisions / versions of the particular snaps are >> available in which channel is available at >> https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# >> >> The snaps have passed our engineering QA and will now be tested by the >> platform and commercial QA teams before the new versions are pushed to >> the stable channel. >> >> Bileto requests are: >> >> - tpm: https://bileto.ubuntu.com/#/ticket/2492 >> - udisks2: https://bileto.ubuntu.com/#/ticket/2490 >> >> >> If you have any questions feel free to ping me. >> >> regards, >> Konrad From dev at tobogganstudio.com Tue Feb 21 15:44:29 2017 From: dev at tobogganstudio.com (Dev Dev) Date: Tue, 21 Feb 2017 10:44:29 -0500 Subject: snap connect myapp:camera out-of-the-box Message-ID: Hi, Anyone can give me more information (ETA, how it will works) about the connection to camera. Right now, I need to ask my users who installed myapp via the Software Center to open a terminal and run: sudo snap connect myapp:camera It needs to be automagically connected. I reported this issue here: https://bugs.launchpad.net/snapcraft/+bug/1609577 Thanks From james at jamesh.id.au Wed Feb 22 14:47:00 2017 From: james at jamesh.id.au (James Henstridge) Date: Wed, 22 Feb 2017 22:47:00 +0800 Subject: Experimental Python interpreter snap In-Reply-To: <20170221103712.71207030@subdivisions.wooz.org> References: <20170221103712.71207030@subdivisions.wooz.org> Message-ID: On 21 February 2017 at 23:37, Barry Warsaw wrote: > On Feb 21, 2017, at 09:30 PM, James Henstridge wrote: > >>So we might be able to do a single package that can both serve as a >>runtime for other snaps and as a useful Python development >>environment. > > It would be interesting to see, but my tendency is to want separate > interpreter environments for different purposes. See my previous post re: a > locked down system interpreter for /usr/bin scripts. > > The problem with one-size-fits-all (and we have this problem today with > deb-based /usr/bin/python{2,3}) is that people sudo pip install all kinds of > crazy things into their {site,dist}-packages, and that can break things, which > are difficult to debug (though we're adding some useful features to 3.7 to > help with that). That's the thing: a confined app using the interpreter from my package via the content interface is effectively going to get its own environment. It won't be searching for Python modules under /usr because that's not where the Python installation comes from. It won't search for modules installed to ~/.local/lib/pythonX.Y because it won't have permission to read that directory. So even if we get it so "sudo pip install" works, it won't actually have any impact on other snaps using the interpreter. > > So I think it makes some sense to separate these concerns: OS platform use, > confined snap application use, developer playground. Virtualenvs are the > typical "Pythonic" way of doing that, but snaps provide another opportunity > for confinement. > > (Of course "/usr/bin/python{,2,3}" is the long-established ui for that > developer playground.) Yep. So I think it probably makes most sense for the Python runtime snap to default to classic confinement so that it behaves as a user would expect for interactive/development work, with pip ready to install to ~/.local/lib/..., or to the system wide $SNAP_DATA folder if the user really wants to install things system wide. This would seem to satisfy both use cases well. James From femma.ashraf at canonical.com Wed Feb 22 15:30:27 2017 From: femma.ashraf at canonical.com (femma.ashraf at canonical.com) Date: Wed, 22 Feb 2017 15:30:27 +0000 Subject: Dashboard survey Message-ID: <001a1143f70a0ef5980549202d86@google.com> I've invited you to fill out the following form: Developer dashboard survey To fill it out, visit: https://docs.google.com/forms/d/e/1FAIpQLSdH6NdaOZ4TObOYpnVNplGBCYVnF1nd2fqEZFloP9XgTFYhNA/viewform?c=0&w=1&usp=mail_form_link Hi all, I'm doing some research into creating a developer dashboard, would you please be able to take a few moments to fill out the survey for me. It will be much appreciated. If there's any problems, please let me know. Thanks, Femma Google Forms: Create and analyze surveys. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Feb 23 00:10:28 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 23 Feb 2017 08:10:28 +0800 Subject: snap connect myapp:camera out-of-the-box In-Reply-To: References: Message-ID: I have updated the bug report. Please check my answers. Best regards, XiaoGuo On Tue, Feb 21, 2017 at 11:44 PM, Dev Dev wrote: > Hi, > > Anyone can give me more information (ETA, how it will works) about the > connection to camera. Right now, I need to ask my users who installed > myapp via the Software Center to open a terminal and run: > sudo snap connect myapp:camera > > It needs to be automagically connected. > > I reported this issue here: > https://bugs.launchpad.net/snapcraft/+bug/1609577 > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.bishop at canonical.com Thu Feb 23 06:39:49 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Thu, 23 Feb 2017 13:39:49 +0700 Subject: Experimental Python interpreter snap In-Reply-To: References: <20170221103712.71207030@subdivisions.wooz.org> Message-ID: On 22 February 2017 at 21:47, James Henstridge wrote: > Yep. So I think it probably makes most sense for the Python runtime > snap to default to classic confinement so that it behaves as a user > would expect for interactive/development work, with pip ready to > install to ~/.local/lib/..., or to the system wide $SNAP_DATA folder > if the user really wants to install things system wide. This would > seem to satisfy both use cases well. If $SNAP_USER_DATA/lib was used instead of ~/.local/lib for 'user' pip package installs, then the snap python and the system python will coexist better (as there is no risk of snap python finding a package built by system python and vice versa). I have no idea if sitecustomize.py could do this though, and suspect it might involve patching. (do classic snaps actually have $SNAP_*DATA?) -- Stuart Bishop From james.henstridge at canonical.com Thu Feb 23 07:45:10 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Thu, 23 Feb 2017 15:45:10 +0800 Subject: Experimental Python interpreter snap In-Reply-To: References: <20170221103712.71207030@subdivisions.wooz.org> Message-ID: On 23 February 2017 at 14:39, Stuart Bishop wrote: > On 22 February 2017 at 21:47, James Henstridge wrote: > >> Yep. So I think it probably makes most sense for the Python runtime >> snap to default to classic confinement so that it behaves as a user >> would expect for interactive/development work, with pip ready to >> install to ~/.local/lib/..., or to the system wide $SNAP_DATA folder >> if the user really wants to install things system wide. This would >> seem to satisfy both use cases well. > > If $SNAP_USER_DATA/lib was used instead of ~/.local/lib for 'user' pip > package installs, then the snap python and the system python will > coexist better (as there is no risk of snap python finding a package > built by system python and vice versa). I have no idea if > sitecustomize.py could do this though, and suspect it might involve > patching. > > (do classic snaps actually have $SNAP_*DATA?) So if I installed a package to $SNAP_USER_DATA for my "python36-jamesh.python3" interpreter, the files would end up somewhere under ~/snap/python36-jamesh/. If we then look at my simple hello-world example snap that uses the content interface to access the interpreter, $SNAP_USER_DATA now points to a location under ~/snap/hello-world/. So it wouldn't see the additional packages installed for "python36-jamesh.python3". In fact, the hello-world snap doesn't even have permission to read files under ~/snap/python36-jamesh, even if I put that directory on sys.path. Remember that the content interface is only sharing files: not any of the AppArmor permissions of the slot snap. James. From stuart.bishop at canonical.com Thu Feb 23 11:34:02 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Thu, 23 Feb 2017 18:34:02 +0700 Subject: Experimental Python interpreter snap In-Reply-To: References: <20170221103712.71207030@subdivisions.wooz.org> Message-ID: On 23 February 2017 at 14:45, James Henstridge wrote: > So if I installed a package to $SNAP_USER_DATA for my > "python36-jamesh.python3" interpreter, the files would end up > somewhere under ~/snap/python36-jamesh/. > > If we then look at my simple hello-world example snap that uses the > content interface to access the interpreter, $SNAP_USER_DATA now > points to a location under ~/snap/hello-world/. So it wouldn't see > the additional packages installed for "python36-jamesh.python3". In > fact, the hello-world snap doesn't even have permission to read files > under ~/snap/python36-jamesh, even if I put that directory on > sys.path. Yes, exactly. If I use the python36-jamesh.python3 interpreter from my main shell, I can pip install libraries into $SNAP_USER_DATA and use them. They will not be seen or cause conflicts if I use the /usr/bin/python3, which is what I'm suggesting is an improvement. And they will not be seen by or cause conflicts with snaps using the content interface, no matter if they are confined or classic, which is also a good thing because they will be embedding their dependencies. -- Stuart Bishop From joseph.wakeling at webdrake.net Thu Feb 23 20:04:17 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 23 Feb 2017 21:04:17 +0100 Subject: Position-independent code and Ubuntu 16.10 In-Reply-To: References: <24567486-8e88-9c3e-5db3-20fd4610af94@webdrake.net> <20170221214725.GA5132@hunt> <5c2326ee-6d7f-e822-cd3e-50b248d8516a@webdrake.net> <20170221230815.GB5132@hunt> Message-ID: <5e798f25-3dfa-9361-b1c6-cb9d106e3ae8@webdrake.net> On 22/02/17 00:39, Joseph Rushton Wakeling wrote: > OK, fair enough. In my case I think it was the C-library parts of the D > standard library that were being compiled without PIC. Seems OK to assume this > may have been a project-specific thing, then (which is now fixed upstream). Just for the record: this issue is fixed in the most recent revision of the package. Seth, thanks for your help and advice! From joseph.wakeling at webdrake.net Thu Feb 23 20:18:43 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 23 Feb 2017 21:18:43 +0100 Subject: Further ABI-related issues for ldc2 snap on 14.04 ... ? Message-ID: Hello all, I've encountered a couple of further issues with the ldc2 compiler snap when it's installed on a 14.04 system. I'm sharing here to confirm if these are indeed ABI issues which might be fixable in terms of how snapcraft constructs the package. The first [1] relates to zlib, which is included as part of the D standard library. This is built from a copy of the zlib C source and linked in to the rest of the library. However, if I try to build a program that makes use of the zlib library modules, linking fails with the following error: /usr/bin/gcc zlibtest.o -o zlibtest -L/snap/ldc2/x1/bin/../lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 /usr/bin/ld: /snap/ldc2/x1/bin/../lib/libphobos2-ldc.a(zutil.c.o): unrecognized relocation (0x2a) in section `.text' /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 This matches the error message observed in a past Ubuntu issue related to binutils: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1545653 which would suggest that there's a problematic mismatch between the binutils used to build snap packages versus the one available on 14.04. The second issue [2] relates to a plugin for the gold linker that is built for LDC to enable it to use link-time optimization. This works fine on 16.04, 16.10 and 17.04, but requesting LTO on 14.04 results in linking failing: /usr/bin/gcc hello.o -o hello -Xlinker -plugin -Xlinker /snap/ldc2/x1/lib/LLVMgold-ldc.so -Xlinker -plugin-opt=O0 -L/snap/ldc2/x1/bin/../lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 /usr/bin/ld: /snap/ldc2/x1/lib/LLVMgold-ldc.so: error loading plugin: /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0: symbol __libc_vfork, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 ... which looks to me like it is probably a mismatch between the libc used to build the plugin, versus the libc of either the host system or the core snap? I would presume that both the above would need a fix either snapcraft-side or core snap side ... ? Can anyone advise/assist? Thanks & best wishes, -- Joe [1] https://github.com/ldc-developers/ldc2.snap/issues/17 [2] https://github.com/ldc-developers/ldc2.snap/issues/18 From kyle.fazzari at canonical.com Thu Feb 23 21:58:07 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 23 Feb 2017 13:58:07 -0800 Subject: systemd-resolved and snaps Message-ID: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> Hey all. I've received a bug report on a snap where the user was running a 16.10 Server install with the snap in question, and getting DNS errors. I've distilled the problem as much as I can but I cannot for the life of me figure out what's happening, so I thought maybe the list could point me in the right direction. Prerequisites ============= I have a demo snap (a standalone snapcraft.yaml) that will demonstrate this issue[1]. Ubuntu 16.10 Server uses systemd-resolved, which means its /etc/resolv.conf contains a single nameserver: nameserver 127.0.0.53 If you have others there, comment them out for the time being. Steps to reproduce ================== 1. Build and install the `resolved-test` snap[1]. It exposes two apps, `test` (which is a python2 script uses the requests lib) and `host` which is just the `host` utility from bind9-host. 2. With 127.0.0.53 as the only nameserver, run `resolved-test.test`. Note that it fails with "Name or service not known." 3. With 127.0.0.53 as the only nameserver, run `resolved-test.host acme-staging.api.letsencrypt.org`. Note that it works perfectly fine. At this point, one might suspect that this is an issue in the requests lib. So: 4. Run the test from outside the snap: `PYTHONPATH=/snap/resolved-test/current/lib/python2.7/site-packages /snap/resolved-test/current/usr/bin/python /snap/resolved-test/current/bin/test.py`. Note that this works fine (you should see a dict printed). 5. Now add another nameserver to /etc/resolv.conf (I used `nameserver 8.8.8.8`), and run `resolved-test.test`. Note that it works fine. Some analysis ============= Note that when I run step (1) I get [2] in the syslog. When I run step (2) I get [3] in the syslog. When I run step (4) I get nothing in the syslog. I'm at a loss here. Installing with devmode doesn't change these results. `host` always seems to work fine, but `test` never works with the systemd-resolved IP address. Has anyone else encountered this? Any advice would be appreciated. [1]: http://pastebin.ubuntu.com/24055388/ [2]: http://pastebin.ubuntu.com/24055470/ [3]: http://pastebin.ubuntu.com/24055466/ -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stgraber at ubuntu.com Thu Feb 23 22:06:53 2017 From: stgraber at ubuntu.com (=?iso-8859-1?Q?St=E9phane?= Graber) Date: Thu, 23 Feb 2017 17:06:53 -0500 Subject: systemd-resolved and snaps In-Reply-To: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> References: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> Message-ID: <20170223220653.c5xcfjhyb7opecd4@dakara> On Thu, Feb 23, 2017 at 01:58:07PM -0800, Kyle Fazzari wrote: > Hey all. > > I've received a bug report on a snap where the user was running a 16.10 > Server install with the snap in question, and getting DNS errors. I've > distilled the problem as much as I can but I cannot for the life of me > figure out what's happening, so I thought maybe the list could point me > in the right direction. > > > Prerequisites > ============= > > I have a demo snap (a standalone snapcraft.yaml) that will demonstrate > this issue[1]. > > Ubuntu 16.10 Server uses systemd-resolved, which means its > /etc/resolv.conf contains a single nameserver: > > nameserver 127.0.0.53 > > If you have others there, comment them out for the time being. > > > Steps to reproduce > ================== > > 1. Build and install the `resolved-test` snap[1]. It exposes two apps, > `test` (which is a python2 script uses the requests lib) and `host` > which is just the `host` utility from bind9-host. > > 2. With 127.0.0.53 as the only nameserver, run `resolved-test.test`. > Note that it fails with "Name or service not known." > > 3. With 127.0.0.53 as the only nameserver, run `resolved-test.host > acme-staging.api.letsencrypt.org`. Note that it works perfectly fine. > > At this point, one might suspect that this is an issue in the requests > lib. So: > > 4. Run the test from outside the snap: > `PYTHONPATH=/snap/resolved-test/current/lib/python2.7/site-packages > /snap/resolved-test/current/usr/bin/python > /snap/resolved-test/current/bin/test.py`. Note that this works fine (you > should see a dict printed). > > 5. Now add another nameserver to /etc/resolv.conf (I used `nameserver > 8.8.8.8`), and run `resolved-test.test`. Note that it works fine. > > > Some analysis > ============= > > Note that when I run step (1) I get [2] in the syslog. When I run step > (2) I get [3] in the syslog. When I run step (4) I get nothing in the > syslog. > > I'm at a loss here. Installing with devmode doesn't change these > results. `host` always seems to work fine, but `test` never works with > the systemd-resolved IP address. Has anyone else encountered this? Any > advice would be appreciated. > > [1]: http://pastebin.ubuntu.com/24055388/ > [2]: http://pastebin.ubuntu.com/24055470/ > [3]: http://pastebin.ubuntu.com/24055466/ Hey there, Since acme-staging.api.letsencrypt.org is a CNAME, that may be related to: - https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647031 - https://github.com/systemd/systemd/issues/3826 What happens if you try with "host letsencrypt.org" and "https://letsencrypt.org" (that's an A+AAAA+MX instead of CNAME)? -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From steve.langasek at canonical.com Thu Feb 23 22:26:28 2017 From: steve.langasek at canonical.com (Steve Langasek) Date: Thu, 23 Feb 2017 14:26:28 -0800 Subject: systemd-resolved and snaps In-Reply-To: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> References: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> Message-ID: <20170223222628.rmu2ukrmez3sfeay@virgil.dodds.net> Hi Kyle, On Thu, Feb 23, 2017 at 01:58:07PM -0800, Kyle Fazzari wrote: > Hey all. > I've received a bug report on a snap where the user was running a 16.10 > Server install with the snap in question, and getting DNS errors. I've > distilled the problem as much as I can but I cannot for the life of me > figure out what's happening, so I thought maybe the list could point me > in the right direction. > Prerequisites > ============= > > I have a demo snap (a standalone snapcraft.yaml) that will demonstrate > this issue[1]. > > Ubuntu 16.10 Server uses systemd-resolved, which means its > /etc/resolv.conf contains a single nameserver: > > nameserver 127.0.0.53 > > If you have others there, comment them out for the time being. > > > Steps to reproduce > ================== > > 1. Build and install the `resolved-test` snap[1]. It exposes two apps, > `test` (which is a python2 script uses the requests lib) and `host` > which is just the `host` utility from bind9-host. > > 2. With 127.0.0.53 as the only nameserver, run `resolved-test.test`. > Note that it fails with "Name or service not known." acme-staging.api.letsencrypt.org is a CNAME. You are hitting bug #1647031, which we encountered when trying to roll out systemd-resolved by default for 17.04. This took a while to work through, but the fix has finally landed in zesty as of a week ago; we should now SRU the upstream change back to yakkety. (We should also SRU it back to xenial, but xenial needs a more complete backport of fixes to resolved, not just a cherry-pick of this one fix.) Dimitri, could you handle this backport to yakkety? Since unlike the Desktop, Ubuntu Server does not use dnsmasq by default (which would override resolved), this is a rather important bug there. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek at ubuntu.com vorlon at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From kyle.fazzari at canonical.com Thu Feb 23 22:39:27 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 23 Feb 2017 14:39:27 -0800 Subject: systemd-resolved and snaps In-Reply-To: <20170223222628.rmu2ukrmez3sfeay@virgil.dodds.net> References: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> <20170223222628.rmu2ukrmez3sfeay@virgil.dodds.net> Message-ID: <88e7b357-68e5-3927-c51c-b9d0bb530575@canonical.com> On 02/23/2017 02:26 PM, Steve Langasek wrote: > Hi Kyle, > > On Thu, Feb 23, 2017 at 01:58:07PM -0800, Kyle Fazzari wrote: >> Hey all. > >> I've received a bug report on a snap where the user was running a 16.10 >> Server install with the snap in question, and getting DNS errors. I've >> distilled the problem as much as I can but I cannot for the life of me >> figure out what's happening, so I thought maybe the list could point me >> in the right direction. > >> Prerequisites >> ============= >> >> I have a demo snap (a standalone snapcraft.yaml) that will demonstrate >> this issue[1]. >> >> Ubuntu 16.10 Server uses systemd-resolved, which means its >> /etc/resolv.conf contains a single nameserver: >> >> nameserver 127.0.0.53 >> >> If you have others there, comment them out for the time being. >> >> >> Steps to reproduce >> ================== >> >> 1. Build and install the `resolved-test` snap[1]. It exposes two apps, >> `test` (which is a python2 script uses the requests lib) and `host` >> which is just the `host` utility from bind9-host. >> >> 2. With 127.0.0.53 as the only nameserver, run `resolved-test.test`. >> Note that it fails with "Name or service not known." > > acme-staging.api.letsencrypt.org is a CNAME. You are hitting bug #1647031, > which we encountered when trying to roll out systemd-resolved by default for > 17.04. This took a while to work through, but the fix has finally landed in > zesty as of a week ago; we should now SRU the upstream change back to > yakkety. (We should also SRU it back to xenial, but xenial needs a more > complete backport of fixes to resolved, not just a cherry-pick of this one > fix.) > > Dimitri, could you handle this backport to yakkety? Since unlike the > Desktop, Ubuntu Server does not use dnsmasq by default (which would override > resolved), this is a rather important bug there. Stephane, Steve, thanks for the quick responses. That explanation makes sense until I consider step (4): How did that succeed? I did note that it didn't actually seem to hit systemd-resolved (due to the lack of a syslog entry), but I'm not sure why. -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From joseph.wakeling at webdrake.net Thu Feb 23 23:13:51 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 24 Feb 2017 00:13:51 +0100 Subject: Creating and running tests for a snapcraft plugin Message-ID: Hello all, I have started working on a snapcraft plugin for dub, a build/package manager for the D programming language. The plugin itself is ready (at least in a working draft), and now I'm working on the tests. Is there a simple way to run the tests for a single plugin, rather than the whole body of tests? The snapcraft HACKING.md doesn't offer any advice on this point. I'm not much of a pythonist, so apologies if this is a daft question and the answer is as simple as `python3 snapcraft/tests/test_dub.py` (but currently at least, even trying that fails with an ImportError, so I assume there's something else I have to do). Thanks & best wishes, -- Joe From steve.langasek at canonical.com Thu Feb 23 23:21:02 2017 From: steve.langasek at canonical.com (Steve Langasek) Date: Thu, 23 Feb 2017 15:21:02 -0800 Subject: systemd-resolved and snaps In-Reply-To: <88e7b357-68e5-3927-c51c-b9d0bb530575@canonical.com> References: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> <20170223222628.rmu2ukrmez3sfeay@virgil.dodds.net> <88e7b357-68e5-3927-c51c-b9d0bb530575@canonical.com> Message-ID: <20170223232102.y2dxwkst37raliv4@virgil.dodds.net> On Thu, Feb 23, 2017 at 02:39:27PM -0800, Kyle Fazzari wrote: > On 02/23/2017 02:26 PM, Steve Langasek wrote: > > acme-staging.api.letsencrypt.org is a CNAME. You are hitting bug #1647031, > > which we encountered when trying to roll out systemd-resolved by default for > > 17.04. This took a while to work through, but the fix has finally landed in > > zesty as of a week ago; we should now SRU the upstream change back to > > yakkety. (We should also SRU it back to xenial, but xenial needs a more > > complete backport of fixes to resolved, not just a cherry-pick of this one > > fix.) > > > > Dimitri, could you handle this backport to yakkety? Since unlike the > > Desktop, Ubuntu Server does not use dnsmasq by default (which would override > > resolved), this is a rather important bug there. > > Stephane, Steve, thanks for the quick responses. That explanation makes > sense until I consider step (4): How did that succeed? I did note that > it didn't actually seem to hit systemd-resolved (due to the lack of a > syslog entry), but I'm not sure why. For context, 4 was: 4. Run the test from outside the snap: `PYTHONPATH=/snap/resolved-test/current/lib/python2.7/site-packages /snap/resolved-test/current/usr/bin/python /snap/resolved-test/current/bin/test.py`. Note that this works fine (you should see a dict printed). At a guess, I would say that outside the snap you have the libnss-resolve package installed and active, such that python resolves it via the resolved native dbus interface instead of via the DNS stub resolver on port 53. These behavior differences are a reason that we should NOT use the libnss-resolve package, but instead sort out any bugs in the stub resolver and use it consistently everywhere. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek at ubuntu.com vorlon at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From gustavo.niemeyer at canonical.com Fri Feb 24 00:56:35 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Thu, 23 Feb 2017 21:56:35 -0300 Subject: Heads up: change in snapd test workers Message-ID: Hello there, We're starting to blow up the 50 minutes time quota provided by Travis during CI of master, which means PRs may now fail for no reason other than taking too long. On quick inspection, prepare.sh claims to have fixed the original problem that motivated the ubuntu-core-16-64-fixme spread system, and looking at test results using two workers on 14.04 and ubuntu-core-64 might cut about 20 minutes of testing time. I've pushed a PR and validated the theory in practice: https://github.com/snapcore/snapd/pull/2928 With this small tweak, we've indeed cut down on about 20 minutes of testing time, going back to ~30 minutes. The main cost of this change is just one more machine used per full test run, and the old machine that was specific to the one bogus test we had is now being used as a second standard worker that can parallelize all tests targeting ubuntu-core-16-64. We're keeping that one machine allocated for more time, but that pays off because first worker that used to take 50+ minutes now takes 30 as well. Seems to work, but I'm leaving on holiday, so two points to keep in mind: - The bug that seemed fixed is perhaps not fixed, and I was just lucky. If that is the case, have a look at the PR above and either revert the change or fix the remaining bits. - Instant contention increases. We're now running at 8 machines per full run (16.04-64+16.04-32+14.04+core-16, times two). On the down side, we may see more of the "no machines available" complaint. That said, the whole run takes less time, so trailing machines get deallocated faster. I expect the net effect here to be positive because Travis also has a maximum number of jobs, so even if we have machines available, that job taking 50 minutes may be holding back the follow ups. Anyway, just wanted to share these details as this was a last minute change merged with almost no discussion. If you see issues, that's where to look. Have fun! gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Fri Feb 24 10:30:19 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 24 Feb 2017 11:30:19 +0100 Subject: [System Enablement] New releases Feb 2017 In-Reply-To: References: Message-ID: On 07.02.2017 15:40, Simon Fels wrote: > Hey everyone, > > new releases of the alsa-utils, network-manager, upower and wifi-ap > snaps were pushed into the candidate channel. > > alsa-utils 1.1.2-2: > > * First official release supported by Canonical > * Aliases for all exported commands are available > * Set of automated and manual test cases guarantee quality of each release > > network-manager 1.2.2-11: > > * Wake-on-WLAN can be configured via snap confiration / nmcli > * Automatic reconfiguration of network devices when devices wakes up > * Alias support for nmcli command > * WiFi powersave is now configurable via snap configuration > * Network-Manager tests are using tests-extras repository to fetch the > image creating scripts rather than embed them. > > upower 0.99.4-2: > > * First release > * Integration with systemd to suspend the system on low battery events > > wifi-ap 13: > > * Configuration command accepts multiple key/value pairs > * AP can be disabled on installation via configuration option > > --- > > An overview of which revisions / versions of the particular snaps are > available in which channel is available at > https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit# > > The snaps have passed our engineering QA and will now be tested by the > platform and commercial QA teams before the new versions are pushed to > the stable channel. > > Bileto requests are: > > - alsa-utils: https://bileto.ubuntu.com/#/ticket/2441 > - network-manager: https://bileto.ubuntu.com/#/ticket/2442 > - upower: https://bileto.ubuntu.com/#/ticket/2445 > - wifi-ap: https://bileto.ubuntu.com/#/ticket/2444 > > If you have any questions feel free to ping me. All snaps listed above have passed testing by platform and commercial QA and have now released to the stable channel. regards, Simon From adam.collard at canonical.com Fri Feb 24 11:00:29 2017 From: adam.collard at canonical.com (Adam Collard) Date: Fri, 24 Feb 2017 11:00:29 +0000 Subject: Tracking breaking changes in core Message-ID: Hi Snapsters, We've recently hit an issue[0] that broke the canonical-livepatch snap. Work to fix it is under-way, but I'm curious how we're expected to know about these breaking changes? It seems that the key piece of information is tucked away inside a LP bug[1]. TIA, Adam [0] https://bugs.launchpad.net/canonical-livepatch-client/+bug/1667470 [1] https://bugs.launchpad.net/snappy/+bug/1619420/comments/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Feb 24 12:51:29 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 24 Feb 2017 13:51:29 +0100 Subject: Tracking breaking changes in core In-Reply-To: References: Message-ID: <1487940689.17360.8.camel@ubuntu.com> hi, Am Freitag, den 24.02.2017, 11:00 +0000 schrieb Adam Collard: > Hi Snapsters, > > We've recently hit an issue[0] that broke the canonical-livepatch > snap. Work to fix it is under-way, but I'm curious how we're expected > to know about these breaking changes? It seems that the key piece of > information is tucked away inside a LP bug[1].  > > TIA, > > Adam > > [0] https://bugs.launchpad.net/canonical-livepatch-client/+bug/166747 > 0 > [1] https://bugs.launchpad.net/snappy/+bug/1619420/comments/11 > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft this kind of exposes an issue in our way to test IMHO. the fix from [1] (needed for the core images where lsb_release has never been functional) landed in edge two weeks ago, then in candidate/beta a little later, but still ahead of the stable release of the latest core snap.  the livepatch snap on classic should be included in QAs test plan for candidate releases (alternatively you could have one machine in your team that uses the core snap from beta or candidate permanently on classic which would allow you to raise a flag before core hits stable) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From mwinter at opensourcerouting.org Fri Feb 24 13:08:53 2017 From: mwinter at opensourcerouting.org (Martin Winter) Date: Fri, 24 Feb 2017 20:08:53 +0700 Subject: Snap refresh or new install stuck at 'Run configure hook of "core" snap if present' Message-ID: <05EA4346-34FB-4329-8BD4-CE5AFAC35728@opensourcerouting.org> So not sure what’s going on. Since the latest update of my Ubuntu 16.04.2 (Server, x86_64) I can’t do a “snap refresh” anymore or reinstalling it. Basically it seems to try installing or updating (If I have earlier version) and gets stuck forever (or at least > 2hrs) at [/] Run configure hook of "core" snap if present (And spinning the animation in [ ]) Curious if anyone has seen the same. All my Ubuntu 16.04 Servers have this issue. (Approx 10 Servers which are part of my CI system) Thoughts? - Martin Winter From john.lenton at canonical.com Fri Feb 24 13:33:55 2017 From: john.lenton at canonical.com (John Lenton) Date: Fri, 24 Feb 2017 13:33:55 +0000 Subject: Snap refresh or new install stuck at 'Run configure hook of "core" snap if present' In-Reply-To: <05EA4346-34FB-4329-8BD4-CE5AFAC35728@opensourcerouting.org> References: <05EA4346-34FB-4329-8BD4-CE5AFAC35728@opensourcerouting.org> Message-ID: On 24 February 2017 at 13:08, Martin Winter wrote: > So not sure what’s going on. Neither are we! But we've spotted some of these on errors.ubuntu.com. Can you get get on IRC (#snappy on freenode)? We'd love to get our hands on systems with this happening a we haven't been able to reproduce it! Thank you, From vanessa.chang at canonical.com Fri Feb 24 15:29:54 2017 From: vanessa.chang at canonical.com (Vanessa Chang) Date: Fri, 24 Feb 2017 23:29:54 +0800 Subject: [System Enablement] New releases Feb 2017 In-Reply-To: References: Message-ID: Hi Please find the Completed test result / report for week 8 from CE QA: WW 2017 St. Louis UC16 Caracalla UC16 ww08 Network Manager 1.2.2-11 (115) Network Manager 1.2.2-11 (115) TPM2 1.0-4 (18) Wifi-AP 13 (93) udisks2 2.1.7-4 (20) udisks2 2.1.7-5 (31) alsa-utlis 1.1.2-4 (43) Ongoing Tasks: St. Louis Kernel + TPM2 (caracalla) TPM1.2 (st-louis) Thanks, Best Regards, Vanessa 2017-02-24 18:30 GMT+08:00 Simon Fels : > On 07.02.2017 15:40, Simon Fels wrote: > > Hey everyone, > > > > new releases of the alsa-utils, network-manager, upower and wifi-ap > > snaps were pushed into the candidate channel. > > > > alsa-utils 1.1.2-2: > > > > * First official release supported by Canonical > > * Aliases for all exported commands are available > > * Set of automated and manual test cases guarantee quality of each > release > > > > network-manager 1.2.2-11: > > > > * Wake-on-WLAN can be configured via snap confiration / nmcli > > * Automatic reconfiguration of network devices when devices wakes up > > * Alias support for nmcli command > > * WiFi powersave is now configurable via snap configuration > > * Network-Manager tests are using tests-extras repository to fetch the > > image creating scripts rather than embed them. > > > > upower 0.99.4-2: > > > > * First release > > * Integration with systemd to suspend the system on low battery events > > > > wifi-ap 13: > > > > * Configuration command accepts multiple key/value pairs > > * AP can be disabled on installation via configuration option > > > > --- > > > > An overview of which revisions / versions of the particular snaps are > > available in which channel is available at > > https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_ > xcAEHJpntUPGpmixU6PV8K2KU/edit# > > > > The snaps have passed our engineering QA and will now be tested by the > > platform and commercial QA teams before the new versions are pushed to > > the stable channel. > > > > Bileto requests are: > > > > - alsa-utils: https://bileto.ubuntu.com/#/ticket/2441 > > - network-manager: https://bileto.ubuntu.com/#/ticket/2442 > > - upower: https://bileto.ubuntu.com/#/ticket/2445 > > - wifi-ap: https://bileto.ubuntu.com/#/ticket/2444 > > > > If you have any questions feel free to ping me. > > All snaps listed above have passed testing by platform and commercial QA > and have now released to the stable channel. > > regards, > Simon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claudioandre.br at gmail.com Fri Feb 24 18:49:18 2017 From: claudioandre.br at gmail.com (=?UTF-8?Q?Claudio_Andr=C3=A9?=) Date: Fri, 24 Feb 2017 15:49:18 -0300 Subject: snapcraft 2.27 has been released In-Reply-To: References: Message-ID: 2017-02-17 10:49 GMT-02:00 Sergio Schvezov : > Hello snapcrafters! > > ## Setting up environment > > No more wrapper scripts just to setup on environment entry, this is now > tied into an app entry in `apps`. Here's a quick example: > > ```yaml > apps: > vim: > command: bin/vim > environment: > VIMRUNTIME: $SNAP/share/vim/vim80 > ``` > Hi, I tried to append to path (see below). It is not supported. ```yaml environment: PATH: "$SNAP/usr/lib/jvm/default-java/bin:$PATH" ``` I'm ok with it. But, in case this is not by design, I'm mailing you guys. Claudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fazzari at canonical.com Fri Feb 24 19:05:31 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Fri, 24 Feb 2017 11:05:31 -0800 Subject: snapcraft 2.27 has been released In-Reply-To: References: Message-ID: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> On 02/24/2017 10:49 AM, Claudio André wrote: > > 2017-02-17 10:49 GMT-02:00 Sergio Schvezov > >: > > Hello snapcrafters! > > ## Setting up environment > > No more wrapper scripts just to setup on environment entry, this is > now tied into an app entry in `apps`. Here's a quick example: > > ```yaml > apps: > vim: > command: bin/vim > environment: > VIMRUNTIME: $SNAP/share/vim/vim80 > ``` > > > Hi, I tried to append to path (see below). It is not supported. > > ```yaml > environment: > PATH: "$SNAP/usr/lib/jvm/default-java/bin:$PATH" > ``` > > I'm ok with it. But, in case this is not by design, I'm mailing you guys. I can verify this. To clarify, this builds and runs fine, but actually results in the PATH including the string `$PATH` instead of expanding it. Can a snapd dev comment on this? Is that intended? -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jcoates at extremenetworks.com Fri Feb 24 19:26:50 2017 From: jcoates at extremenetworks.com (Joe Coates) Date: Fri, 24 Feb 2017 19:26:50 +0000 Subject: snapping tmux Message-ID: I've been trying to add tmux to my snap to provide separate command line environments to each of several processes in the snap (the target is Ubuntu-core). It builds OK but it fails silently upon execution (by silent I mean no appArmor denials or error messages in journalctl or syslog). The tmux log indicates "fatal: tcgetattr failed: Bad file descriptor", and I believe it is trying to access the session TTY ("client 0x10e9590 IDENTIFY_ENVIRON SSH_TTY=/dev/pts/1") . This behavior is consistent on ubuntu-core, core+classic, and ubuntu server. Before delving further into tmux code I'd like to know if there is some basic restriction preventing this from working - is the console session off limits to snaps ? I noticed some early attempts at snapping tmux on github, but none of them seem to have been successful. Has anyone tried this, or can perhaps offer any advice ? Thanks, Joe Coates ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Sat Feb 25 06:06:53 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Sat, 25 Feb 2017 09:06:53 +0300 Subject: detect video player Message-ID: <3c8695a2-0382-11fa-f9b5-cdca0f914e7f@gmail.com> Please give me advice. For example, vlc come from snap package, smplayer from deb package. How correct detect video players from application-in-snap-package? -- Best regards, vasilisc From joseph.wakeling at webdrake.net Sat Feb 25 17:48:20 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 25 Feb 2017 18:48:20 +0100 Subject: Snap refresh or new install stuck at 'Run configure hook of "core" snap if present' In-Reply-To: <05EA4346-34FB-4329-8BD4-CE5AFAC35728@opensourcerouting.org> References: <05EA4346-34FB-4329-8BD4-CE5AFAC35728@opensourcerouting.org> Message-ID: On 24/02/17 14:08, Martin Winter wrote: > Curious if anyone has seen the same. All my Ubuntu 16.04 Servers have this issue. > (Approx 10 Servers which are part of my CI system) Saw the same on a Debian Sid install that I was using to test my ldc2 snap package a couple of days ago. However, it didn't persist -- a few minutes ago I was able to successfully install the core and ldc2 snaps. From shawn.wang at canonical.com Sun Feb 26 10:25:41 2017 From: shawn.wang at canonical.com (Shawn Wang) Date: Sun, 26 Feb 2017 18:25:41 +0800 Subject: snapping tmux In-Reply-To: References: Message-ID: Hi Joe, I made a classic snap. https://github.com/shawn111/tmux.snap But you are right, I'm not sure how to make it confined. Regards, Shawn On Sat, Feb 25, 2017 at 3:26 AM, Joe Coates wrote: > I’ve been trying to add tmux to my snap to provide separate command line > environments to each of several processes in the snap (the target is > Ubuntu-core). It builds OK but it fails silently upon execution (by > silent I mean no appArmor denials or error messages in journalctl or > syslog). The tmux log indicates “fatal: tcgetattr failed: Bad file > descriptor”, and I believe it is trying to access the session TTY (“client > 0x10e9590 IDENTIFY_ENVIRON SSH_TTY=/dev/pts/1”) . This behavior is > consistent on ubuntu-core, core+classic, and ubuntu server. > > Before delving further into tmux code I’d like to know if there is some > basic restriction preventing this from working – is the console session off > limits to snaps ? I noticed some early attempts at snapping tmux on > github, but none of them seem to have been successful. Has anyone tried > this, or can perhaps offer any advice ? > > Thanks, > > Joe Coates > > ------------------------------ > > DISCLAIMER: > This e-mail and any attachments to it may contain confidential and > proprietary material and is solely for the use of the intended recipient. > Any review, use, disclosure, distribution or copying of this transmittal is > prohibited except by or on behalf of the intended recipient. If you have > received this transmittal in error, please notify the sender and destroy > this e-mail and any attachments and all copies, whether electronic or > printed. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simos.lists at googlemail.com Mon Feb 27 07:14:16 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Mon, 27 Feb 2017 09:14:16 +0200 Subject: HowTo: How to make a snap package for lolcat with snapcraft on Ubuntu Message-ID: Hi All, I wrote a tutorial on how to make a snap for a CLI utility called "lolcat", https://blog.simos.info/how-to-make-a-snap-package-for-lolcat-with-snapcraft-on-ubuntu/ I am trying a different style and I aim to show how to create a snap for four different implementations of lolcat (in Python, Go, Rust, and C). The tutorial aims to gently introduce a few more concepts and reinforce at the same time the basics of snap creation. I am looking for feedback and especially if there are any concepts that I should tackle in a better way. Cheers, Simos From xiaoguo.liu at canonical.com Mon Feb 27 07:37:10 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 27 Feb 2017 15:37:10 +0800 Subject: HowTo: How to make a snap package for lolcat with snapcraft on Ubuntu In-Reply-To: References: Message-ID: Hi Simos, Thanks! Nice work! Thanks & best regards, XiaoGuo On Mon, Feb 27, 2017 at 3:14 PM, Simos Xenitellis < simos.lists at googlemail.com> wrote: > Hi All, > > I wrote a tutorial on how to make a snap for a CLI utility called "lolcat", > https://blog.simos.info/how-to-make-a-snap-package-for- > lolcat-with-snapcraft-on-ubuntu/ > > I am trying a different style and I aim to show how to create a snap > for four different implementations of lolcat (in Python, Go, Rust, and > C). > The tutorial aims to gently introduce a few more concepts and > reinforce at the same time the basics of snap creation. > > I am looking for feedback and especially if there are any concepts > that I should tackle in a better way. > > Cheers, > Simos > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Mon Feb 27 08:30:36 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Mon, 27 Feb 2017 09:30:36 +0100 Subject: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04 In-Reply-To: References: <89ea1fea-55fc-686f-874c-ad83af8fb920@ubuntu.com> <0dc231f8-26fc-d929-faef-7f28e1b8850d@ubuntu.com> <0afec719-2791-b5cd-e138-0d0a68d0b412@ubuntu.com> Message-ID: Le 17/02/2017 à 15:47, Didier Roche a écrit : > Le 15/02/2017 à 16:33, Simos Xenitellis a écrit : >> On Mon, Feb 13, 2017 at 7:13 PM, Didier Roche wrote: >>> Le 10/02/2017 à 17:30, Simos Xenitellis a écrit : >>>> I managed to complete the conversion and the tutorial is ready :-). >>>> >>>> Here it is, >>>> https://docs.google.com/document/d/1Nk-kw79lt84YJNEKS_WpnGzVSjrmCUVd1TsAx5aRoOA/ >>>> Feel free to add to tutorials.ubuntu.com or make a copy in order to edit. >>>> >>>> Overall, the experience in converting to the format required by >>>> codelabs was interesting. >>>> I still need more practice before I would be able to write a tutorial >>>> in one go in the codelab style. >>> This really looks awesome! Thanks Simos :) >>> >>> I'll add some very small tweaking, but after a first look, it's very a >>> nice first shot. Well done :) >>> I'll keep you posted with a diff so that you can see what small >>> modifications I made to be more coherent with the other ones. >>> >> Thanks, looking forward to reading the changes. > And here we go: > https://docs.google.com/document/d/1cvXAZRkmKExNIOXMUQihQrd8dNZK6f8v4wk020NymuI/edit#. > I did find your tutorial to be so good, that I changed its destination > to be the default "use python plugin" one. Due to that, I removed the > "explain what snap/snapcraft is and publish to the store" parts, as they > are already covered in other base tutorials (and we want to create a > coherent story). I added of course the pre-requisite on them and > formatted some stuff to be inline with our current one. > > Note, this is a draft, I didn't take the time to reread it yet (so > probably, a lot of typos and such, but I prefer to reread it on Monday > with a clear brain and fresh eye on this). I tried to explain the major > difference I've made (and what did divert originaly from the tutorials > guidelines) as comments on the doc. > Do not hesitate to ask (the document is opened for comments) if anything > isn't clear or if you have ideas to improve it. I hope most of my > changes and my comments will make sense. > > If you feel those changes are good, we can publish it next week, and > wait eagerly for your next tutorial! (Maybe we can work together on > deciding first the layout, main titles and separations if you want) > > Thanks again for your awesome work here! For those who followed that thread, with the modifications we discussed above (and some more exchanges with Simos on google doc comments), we do have that tutorial, focusing on how to snap a python application published here: https://tutorials.ubuntu.com/tutorial/snap-python-app Congrats again Simos, well done, and looking for more :) Cheers, Didier From Sam.Nicholson at bbc.co.uk Mon Feb 27 10:30:53 2017 From: Sam.Nicholson at bbc.co.uk (Sam Nicholson) Date: Mon, 27 Feb 2017 10:30:53 +0000 Subject: Snaps in production? Message-ID: <43E841D1CB23514783B81EFDF97705013EB47F8D@bgb01xud1004> Hi all, I've been tasked with coming up with the best way to deploy one of our research projects, developed on Ubuntu and packaged for Debian, onto our CentOS-based production infrastructure. Looking at Snaps, it seems like it could be the answer to avoid having to re-package everything as RPMs (there's about 150 assorted packages) and put us in a good position for the future, but I'm wondering if anyone else is using it server-side in production? Some quick searching doesn't pull up any case studies other than a brief mention of Nextcloud boxes, but I figured I'd ask around since it could save us a bit of work. Thanks, Sam Nicholson BBC Research & Development ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From james.jesudason at canonical.com Mon Feb 27 13:33:06 2017 From: james.jesudason at canonical.com (James Jesudason) Date: Mon, 27 Feb 2017 13:33:06 +0000 Subject: Snaps in production? In-Reply-To: <43E841D1CB23514783B81EFDF97705013EB47F8D@bgb01xud1004> References: <43E841D1CB23514783B81EFDF97705013EB47F8D@bgb01xud1004> Message-ID: On 27 February 2017 at 10:30, Sam Nicholson wrote: > Hi all, > > I've been tasked with coming up with the best way to deploy one of our research projects, developed on Ubuntu and packaged for Debian, onto our CentOS-based production infrastructure. Looking at Snaps, it seems like it could be the answer to avoid having to re-package everything as RPMs (there's about 150 assorted packages) and put us in a good position for the future, but I'm wondering if anyone else is using it server-side in production? > We've been using server-side snaps in production and plan to use this as our main deployment method going forward. The snaps are deployed using Juju and the snaps are installed and upgraded directly from the snap store. It's made the deployment infrastructure feel a lot simpler and upgrades are handled in the Juju charm using a 'snap refresh'. If you are looking for an example, take a look at the serial-vault [1] (a Go web-service). The deployment document [2] gives an idea of how we use it. The snap, charm and bundle are available on the snap store and charm store. [1] https://github.com/ubuntu-core/identity-vault [2] https://github.com/ubuntu-core/identity-vault/blob/master/docs/Deployment.md From lara.lauer at gmx.ch Mon Feb 27 13:56:46 2017 From: lara.lauer at gmx.ch (Lara Lauer) Date: Mon, 27 Feb 2017 14:56:46 +0100 Subject: Snaps in production? In-Reply-To: <43E841D1CB23514783B81EFDF97705013EB47F8D@bgb01xud1004> References: <43E841D1CB23514783B81EFDF97705013EB47F8D@bgb01xud1004> Message-ID: <438a4720-1fde-76d1-2132-a6558c6a0e10@gmx.ch> Hi Sam, On 27.02.2017 11:30, Sam Nicholson wrote: > developed on Ubuntu and packaged for Debian, onto our CentOS-based production infrastructure. To my knowledge CentOS does not support Snaps. There is a snapd package for Fedora [1]. cheers, Lara [1] https://admin.fedoraproject.org/pkgdb/package/rpms/snapd/ From jamie at canonical.com Mon Feb 27 19:10:08 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 27 Feb 2017 13:10:08 -0600 Subject: network namespaces In-Reply-To: <1487699628.3972.19.camel@canonical.com> References: <1487699628.3972.19.camel@canonical.com> Message-ID: <1488222608.3921.4.camel@canonical.com> On Tue, 2017-02-21 at 11:53 -0600, Jamie Strandboge wrote: > On Tue, 2017-02-21 at 12:39 +0100, Luca Dionisi wrote: > > > > Are network namespaces supported in snaps? > > > > In my RaspberryPi3 I have a snap which has been installed with --devmode. > > Inside the snap I have exposed the command 'bash'. I exec that bash as > > root. Then I try to create a network namespace. It fails. > > > > $ sudo myapp.bash > > # ip netns add ns0 > > open("/proc/self/ns/net"): Permission denied > > # > > > You are hitting this bug: > https://bugs.launchpad.net/apparmor/+bug/1648903 > > The workaround is to declare in your snap 'plugs: [ network-control ]' and to > connect the interface with 'sudo snap connect myapp:network-control' even when > using devmode. After that you should be able to use 'ip netns' within your > snap. > FYI, the fix for this kernel bug is in Ubuntu 17.04 development release and will be in the next kernel update for Ubuntu 16.04 LTS and Ubuntu 16.10. Ubuntu 14.04 LTS will receive the fix after 16.04 LTS is updated. I've asked for corresponding updates for the pi kernels and snaps. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From n.curalli at domotz.com Tue Feb 28 10:23:30 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 28 Feb 2017 10:23:30 +0000 Subject: workaround for connect no autoconnect interfaces without login on system Message-ID: Hi, Can anyone give me advices about the following problem? I am porting an application for network monitoring to snap format for packaging and distribution. The applicazion should use the following interfaces provided from the core/ubuntu-core snap: - network ( autoconnect) - network-bind (autoconnect) - network-control (no autoconnect) - network-observe (no autoconnect) - network-control (no autoconnect) - network-manager (no autoconnect) - network-observe (no autoconnect) - network-setup-observe (no autoconnect) - gpio (no autoconnect) The current user experience for our appliance requires that user don't login on it for make operations aboout network configuration: a solution with snap connect tool on login console don't works for us. I should replicate the user experience on snap version of our package. On this whitepaper [1] I can read the following sentence: "the gadget developer may autoconnect preinstalled snaps". Unfortunetaly i don't see a standard tool on gadget documentation for the setup of my use case. Can anyone suggest a possibile solution/workaround built with snap and core tools? Note: the use case is similar to the canonical wifi-ap snap. Thanks for each advice. Nicolino [1] http://people.canonical.com/~davidcalle/core/Whitepaper:%20Ubuntu%20Core%2016%20-%20Security.pdf From sunny.bhayani at einfochips.com Tue Feb 28 13:03:55 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Tue, 28 Feb 2017 13:03:55 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: <20170222102452.GA16955@harukaze> References: <1487755165.11513.51.camel@ubuntu.com>,<20170222102452.GA16955@harukaze> Message-ID: Hi Paolo / Oliver, Thank you for your email. > On Wed, Feb 22, 2017 at 10:19:25AM +0100, Oliver Grawert wrote: > > > The AppArmor patches that we ported from the > > > http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/c > > > onfigs/snappy?h=snappy_v3.10 > > > > > > are for the linux kernel 3.10. > > > > > > But the kernel that we are referring to is from 96boards - linux > > > kernel 4.4. > > > > this is definitely wrong, for 4.4 kernels you indeed need to use a 4.4 > > patch set, another thing for paolo to answer (i'm not even sure you > > need any patches at all on a 4.4 kernel, all bits might be in-tree > > already and just some config options might be enough)... > > Unfortunately he is not using our Xenial kernel, so he still needs some patches > for AA - here's a updated delta of patches on top of stable/linux-4.4.y: > > https://github.com/piso77/sample-kernels/commits/stable-4.4.y > We downloaded the kernel source from: https://github.com/piso77/sample-kernels.git Checked out the "stable-4.4.y" branch. The kernel version is 4.4.50 (Blurry Fish Butt). This kernel has all the latest patches that you have mentioned. So, we just ran the below commands to merge our defconfig with snappy, and distro.config: ARCH=arm64 ./scripts/kconfig/merge_config.sh arch/arm64/configs/defconfig kernel/configs/distro.config cp .config arch/arm64/configs/defconfig ARCH=arm64 ./scripts/kconfig/merge_config.sh arch/arm64/configs/defconfig kernel/configs/snappy/*.config cp .config arch/arm64/configs/defconfig Then checked in the code. Our snapcraft.yaml is at: http://pastebin.com/Na76t2ks We are able to build the kernel snap successfully. Build logs at: http://pastebin.com/fphxyh46 We are able to build the ubuntu os snap successfully by using the kernel snap from your kernel and gadget snap from the older source that we had got. But when we boot the kernel, we are getting stuck in kernel boot. It seems the kernel is not getting the initrd. The bootlogs are at: http://pastebin.com/eF2sCiyJ Can you please let us know if we are missing something ? Also, the dts files are different as compared to the 4.4.23 kernel source. So is there some work ongoing. Because the prebuilt binaries has already SMP booting enabled, while the current latest kernel version has only a primary core booting. > depending of the 4.4.x revision you are using, if you apply all the patches > above the "Linux 4.4.50" commit, you will get all you need. > Are we missing any patches that you are referring to as we have pulled the latest kernel ? One more observation: We are using the below command to build the kernel using snapcraft.yaml: sudo snapcraft --target-arch arm64 snap So, if we want to do a incremental build for the kernel, how can we achieve that ? Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Tue Feb 28 13:37:55 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 28 Feb 2017 14:37:55 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: <1487755165.11513.51.camel@ubuntu.com>,<20170222102452.GA16955@harukaze> Message-ID: <1488289075.17360.26.camel@ubuntu.com> hi, Am Dienstag, den 28.02.2017, 13:03 +0000 schrieb Sunny Bhayani: >  > But when we boot the kernel, we are getting stuck in kernel boot. It  > seems the kernel is not getting the initrd. The bootlogs are  > at: http://pastebin.com/eF2sCiyJ > looks fine to me ... reading 96boards-kernel_x1.snap/initrd.img 4821121 bytes read in 1315 ms (3.5 MiB/s) ... Unpacking initramfs... Freeing initrd memory: 4708K (ffffffc004000000 - ffffffc004499000) ... do you have a screen attached on HDMI ? the kernel command line has: ... console=ttyMSM0,115200n8 console=tty0 ... which means that after firing up the kernel with serial console the system will switch to tty0 for any further boot output. (if everything works you should get a "please press enter" message after a while on serial though) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From roberto.escandon at canonical.com Tue Feb 28 13:51:02 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Tue, 28 Feb 2017 14:51:02 +0100 Subject: snapcraft 2.27 has been released In-Reply-To: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> References: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> Message-ID: <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> Hey guys, Couldn't we have environment property pointing also to a file script as in the case of scriptlets. In the case of needing to set a bunch of things before launching app I'd prefer having it in that way. Cheers. On 24/02/17 20:05, Kyle Fazzari wrote: > > > On 02/24/2017 10:49 AM, Claudio André wrote: >> >> 2017-02-17 10:49 GMT-02:00 Sergio Schvezov >> >: >> >> Hello snapcrafters! >> >> ## Setting up environment >> >> No more wrapper scripts just to setup on environment entry, this is >> now tied into an app entry in `apps`. Here's a quick example: >> >> ```yaml >> apps: >> vim: >> command: bin/vim >> environment: >> VIMRUNTIME: $SNAP/share/vim/vim80 >> ``` >> >> >> Hi, I tried to append to path (see below). It is not supported. >> >> ```yaml >> environment: >> PATH: "$SNAP/usr/lib/jvm/default-java/bin:$PATH" >> ``` >> >> I'm ok with it. But, in case this is not by design, I'm mailing you guys. > > I can verify this. To clarify, this builds and runs fine, but actually > results in the PATH including the string `$PATH` instead of expanding it. > > Can a snapd dev comment on this? Is that intended? > > > From roberto.escandon at canonical.com Tue Feb 28 14:00:48 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Tue, 28 Feb 2017 15:00:48 +0100 Subject: snapcraft 2.27 has been released In-Reply-To: <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> References: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> Message-ID: <1f2811c3-f5d3-37fe-a83f-964474ef68dd@canonical.com> Other thing I've seen, the environment set there does not affect the stop command. Is there any way to do it? Am I doing anything wrong?. Cheers. On 28/02/17 14:51, Roberto Mier Escandón  wrote: > Hey guys, > > Couldn't we have environment property pointing also to a file script as > in the case of scriptlets. In the case of needing to set a bunch of > things before launching app I'd prefer having it in that way. > > Cheers. > > On 24/02/17 20:05, Kyle Fazzari wrote: >> >> >> On 02/24/2017 10:49 AM, Claudio André wrote: >>> >>> 2017-02-17 10:49 GMT-02:00 Sergio Schvezov >>> >: >>> >>> Hello snapcrafters! >>> >>> ## Setting up environment >>> >>> No more wrapper scripts just to setup on environment entry, this is >>> now tied into an app entry in `apps`. Here's a quick example: >>> >>> ```yaml >>> apps: >>> vim: >>> command: bin/vim >>> environment: >>> VIMRUNTIME: $SNAP/share/vim/vim80 >>> ``` >>> >>> >>> Hi, I tried to append to path (see below). It is not supported. >>> >>> ```yaml >>> environment: >>> PATH: "$SNAP/usr/lib/jvm/default-java/bin:$PATH" >>> ``` >>> >>> I'm ok with it. But, in case this is not by design, I'm mailing you guys. >> >> I can verify this. To clarify, this builds and runs fine, but actually >> results in the PATH including the string `$PATH` instead of expanding it. >> >> Can a snapd dev comment on this? Is that intended? >> >> >> From anne at bishop-accountability.org Mon Feb 27 15:22:16 2017 From: anne at bishop-accountability.org (anne at bishop-accountability.org) Date: Mon, 27 Feb 2017 15:22:16 -0000 Subject: 10765 snappy-devel Message-ID: <148820893609.14980.11151482285798066273@btopenworld.com> A non-text attachment was scrubbed... Name: 306.zip Type: application/zip Size: 8034 bytes Desc: not available URL: From james.jesudason at canonical.com Tue Feb 28 14:43:38 2017 From: james.jesudason at canonical.com (James Jesudason) Date: Tue, 28 Feb 2017 14:43:38 +0000 Subject: workaround for connect no autoconnect interfaces without login on system In-Reply-To: References: Message-ID: On 28 February 2017 at 10:23, Nicolino Curalli wrote: > Hi, > > Can anyone give me advices about the following problem? > > I am porting an application for network monitoring to snap format for > packaging and distribution. > > The applicazion should use the following interfaces provided from the > core/ubuntu-core snap: > > - network ( autoconnect) > > - network-bind (autoconnect) > > - network-control (no autoconnect) > > - network-observe (no autoconnect) > > - network-control (no autoconnect) > > - network-manager (no autoconnect) > > - network-observe (no autoconnect) > > - network-setup-observe (no autoconnect) > > - gpio (no autoconnect) > > > The current user experience for our appliance requires that user don't > login on it for make operations aboout network configuration: > > a solution with snap connect tool on login console don't works for us. > > I should replicate the user experience on snap version of our package. > > On this whitepaper [1] I can read the following sentence: "the gadget > developer may autoconnect preinstalled snaps". > > Unfortunetaly i don't see a standard tool on gadget documentation for > the setup of my use case. > > Can anyone suggest a possibile solution/workaround built with snap and > core tools? > > Note: the use case is similar to the canonical wifi-ap snap. > I'm not that this is the right solution in your scenario, but the gadget snap has a prepare-device hook where you can add you custom code to connect the snap. The hook gets called when the device initialises: https://docs.ubuntu.com/core/en/guides/build-device/gadget From simos.lists at googlemail.com Tue Feb 28 23:05:19 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Wed, 1 Mar 2017 01:05:19 +0200 Subject: HOWTO: How to snap timg (text image viewer) Message-ID: Hi All, Here is a tutorial on how to snap "timg", an image viewer for your terminal emulator (!?!), https://blog.simos.info/how-to-create-a-snap-for-timg-with-snapcraft-on-ubuntu/ It is another introductory tutorial that 1. describes an interesting utility (image view for text) 2. deals with a repository that does not have a typical Makefile, thus it requires to use parameters of the "make" plugin. 3. talks about classic and strict confinement. Decides on "strict", with plugs: [home]. 4. the snap uses two additional libraries, and we make sure that the relevant code is included in the snap. I also show how to test the snap by installing it in a fresh ubuntu:x LXD container. (because the snap might have dynamically linked libraries that happened to be already installed on my desktop). Upon further thinking, I believe that I did not have to use a fresh LXD container, because the "strict" confinement would preclude anyway the snap from using any of my desktop's existing system libraries. Isn't that indeed the case? Simos From michi.henning at canonical.com Tue Feb 28 23:13:31 2017 From: michi.henning at canonical.com (Michi Henning) Date: Wed, 1 Mar 2017 09:13:31 +1000 Subject: HOWTO: How to snap timg (text image viewer) In-Reply-To: References: Message-ID: <0973522F-225F-4D43-9583-AE73CB76349B@canonical.com> > Upon further thinking, I believe that I did not have to use a fresh > LXD container, because the "strict" confinement would preclude anyway > the snap from using any of my desktop's existing system libraries. > Isn't that indeed the case? I don’ think so. System libraries are visible even with strict confinement, as far as I know. Michi. From xiaoguo.liu at canonical.com Tue Feb 28 23:37:29 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 1 Mar 2017 07:37:29 +0800 Subject: snapcraft 2.27 has been released In-Reply-To: <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> References: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> Message-ID: Hi Roberto, In that case, you can just run your own script in the command in stead of directly launching your app. In your script, just do whatever thing there. Best regards, XiaoGuo On Tue, Feb 28, 2017 at 9:51 PM, Roberto Mier Escandón  < roberto.escandon at canonical.com> wrote: > Hey guys, > > Couldn't we have environment property pointing also to a file script as > in the case of scriptlets. In the case of needing to set a bunch of > things before launching app I'd prefer having it in that way. > > Cheers. > > On 24/02/17 20:05, Kyle Fazzari wrote: > > > > > > On 02/24/2017 10:49 AM, Claudio André wrote: > >> > >> 2017-02-17 10:49 GMT-02:00 Sergio Schvezov > >> >: > >> > >> Hello snapcrafters! > >> > >> ## Setting up environment > >> > >> No more wrapper scripts just to setup on environment entry, this is > >> now tied into an app entry in `apps`. Here's a quick example: > >> > >> ```yaml > >> apps: > >> vim: > >> command: bin/vim > >> environment: > >> VIMRUNTIME: $SNAP/share/vim/vim80 > >> ``` > >> > >> > >> Hi, I tried to append to path (see below). It is not supported. > >> > >> ```yaml > >> environment: > >> PATH: "$SNAP/usr/lib/jvm/default-java/bin:$PATH" > >> ``` > >> > >> I'm ok with it. But, in case this is not by design, I'm mailing you > guys. > > > > I can verify this. To clarify, this builds and runs fine, but actually > > results in the PATH including the string `$PATH` instead of expanding it. > > > > Can a snapd dev comment on this? Is that intended? > > > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: