Re: snapcraft 2.27 has been released

[Joseph Rushton Wakeling]

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

--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Fwd: petname snap bug

[Dustin Kirkland]

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.

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Fwd: petname snap bug

[Jamie Strandboge]

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



signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: petname snap bug

[Charles Butler]

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@Xenial:/media/psf/work/builds⟫ sudo snap install petname
> [sudo] password for charles:
> petname 2.6 from 'kirkland' installed
> charles@Xenial:/media/psf/work/builds⟫ petname --help
> /snap/petname/9/bin/petname: 49: exec: man: not found
> 127 charles@Xenial:/media/psf/work/builds⟫ man
> What manual page do you want?
> 1 charles@Xenial:/media/psf/work/builds⟫ petname -h
> /snap/petname/9/bin/petname: 49: exec: man: not found
> 127 charles@Xenial:/media/psf/work/builds⟫ petname
> guided-chicken
> charles@Xenial:/media/psf/work/builds⟫ petname
> united-collie
> charles@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.
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

sosreport and snaps

[Louis Bouchard]

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

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: After last "snap refresh" problem with contents of /writable/system-data/etc/iproute2.

[Luca Dionisi]

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@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@lists.snapcraft.io
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: After last "snap refresh" problem with contents of /writable/system-data/etc/iproute2.

[Oliver Grawert]

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@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

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04

[Didier Roche]

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

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Access denied on dbus for MM with plug connected

[Jamie Strandboge]

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



signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: New stable "core" and "ubuntu-core" snaps released

[Paul Larson]

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\=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.

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: New stable "core" and "ubuntu-core" snaps released

[Oliver Grawert]

hi,
Am Freitag, den 17.02.2017, 13:21 + 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

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: New stable "core" and "ubuntu-core" snaps released

[Jamie Bennett]

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 + 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@dragonboard:~$ snap get core refresh.schedule
> error: snap "core" has no "refresh.schedule" configuration option
> ogra@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@lists.snapcraft.io
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

snapcraft 2.27 has been released

[Sergio Schvezov]

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.
ArchTrackSeriesChannelVersionRevision
amd64   0.2  16stable -  -
   candidate  - 

Re: [Dragonboard410c] Ubuntu OS Build Issues, and Support

[Oliver Grawert]

hi,
Am Freitag, den 17.02.2017, 10:06 + 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

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Github badges?

[Evan Dandrea]

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.
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: pro tip: use scriptlets instead of custom plugins

[Oliver Grawert]

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

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

[Dragonboard410c] Ubuntu OS Build Issues, and Support

[Sunny Bhayani]

Hi Ogra,

Thank you for your reply.

> hi,
> Am Donnerstag, den 16.02.2017, 10:16 + 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. 
*
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft