Re: classic mode slow, taking up one full core with apparmor logging

2017-01-06 Thread Jamie Strandboge 
On Fri, 2017-01-06 at 10:10 -0800, Dan Kegel wrote:
> When building a c++ app on a raspberry pi 3 in classic mode,
> I noticed two things that hurt performance substantially.
> 
> 1) the obvious: if you crank config.txt's gpu_mem up above the
> default, life is bad :-)  Don't do that on build machines.
> 
> 2) the not so obvious: apparmor is keeping systemctl's journal process
> at 100% on one core logging crud like
> 
> Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3249]: AVC apparmor="ALLOWED"
> operation="open"
> profile="snap.classic.classic//null-/usr/bin/systemd-run//null-
> /usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-
> /var/snap/classic/common/classic/usr/bin/script//null-
> /var/snap/classic/common/classic/bin/bash//null-
> /var/snap/classic/common/classic/usr/bin/sudo//null-
> /var/snap/classic/common/classic/bin/bash//null-
> /var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-
> /var/snap/classic/common/classic/home/obdank/src/ob-
> repobot/yovo/buildshim//null-
> /var/snap/classic/common/classic/home/obdank/src/ob-
> repobot/yovo/cmake.d/buildshim-ubu//null-
> /var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-
> /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-
> /var/snap/classic/common/classic/usr/bin/dh//null-
> /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-
> /var/snap/classic/common/classic/usr/bin/dh_auto_build//null-
> /var/snap/classic/common/classic/usr/bin/make//null-
> /var/snap/classic/common/classic/us!
>  r/bin/mak
>  e//null-/var/snap/classic/common/classic/usr/bin/make//null-
> /var/snap/classic/common/classic/bin/dash//null-
> /var/snap/classic/common/classic/usr/bin/g++-5//null-
> /var/snap/classic/common/classic/usr/lib/gcc/arm-linux-gnueabihf/5/cc1plus"
> name="/var/snap/classic/common/classic/usr/include/c++/5/cstring"
> pid=3249 comm="cc1plus" requested_mask="r" denied_mask="r" fsuid=1000
> ouid=0
> Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3254]: AVC apparmor="ALLOWED"
> operation="mknod"
> profile="snap.classic.classic//null-/usr/bin/systemd-run//null-
> /usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-
> /var/snap/classic/common/classic/usr/bin/script//null-
> /var/snap/classic/common/classic/bin/bash//null-
> /var/snap/classic/common/classic/usr/bin/sudo//null-
> /var/snap/classic/common/classic/bin/bash//null-
> /var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-
> /var/snap/classic/common/classic/home/obdank/src/ob-
> repobot/yovo/buildshim//null-
> /var/snap/classic/common/classic/home/obdank/src/ob-
> repobot/yovo/cmake.d/buildshim-ubu//null-
> /var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-
> /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-
> /var/snap/classic/common/classic/usr/bin/dh//null-
> /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-
> /var/snap/classic/common/classic/usr/bin/dh_auto_build//null-
> /var/snap/classic/common/classic/usr/bin/make//null-
> /var/snap/classic/common/classic/us!
>  r/bin/mak
>  e//null-/var/snap/classic/common/classic/usr/bin/make//null-
> /var/snap/classic/common/classic/bin/dash//null-
> /var/snap/classic/common/classic/usr/bin/g++-5"
> name="/var/snap/classic/common/classic/tmp/ccpOmyw6.s" pid=3254
> comm="c++" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> 
> Is there an option for reducing apparmor verbosity on ALLOWED operations?
> (speaking strictly as a foreigner in the land of apparmor and snappy)
> 

What is happening is that the classic snap is currently using a chroot with
devmode. devmode causes policy violations to be allowed but logged but because
it is using a chroot instead of a pivot_root, all the file accesses don't match
the rules from the default template. To silence the logging, the policy needs to
be updated. There are several options on how to do this and it needs a little
bit of design on which implementation is best.

In the meantime, as a quick workaround you can add this to
/var/lib/snapd/apparmor/profiles/snap.classic.classic before the final '}':

  mount fstype=devpts options=(rw) devpts -> /dev/pts/,
  /bin/mountpoint ixr,
  @{PROC}/[0-9]*/mountinfo r,
  /var/lib/extrausers/{,*} r,
  capability fsetid,
  capability dac_override,
  /etc/sudoers.d/{,*} r,
  /usr/bin/systemd-run Uxr,
  /bin/systemctl Uxr,

then load the profile into the kernel with:

$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.classic.classic

Now you should be able to 'sudo classic' and not see any apparmor logging. Note
that you may have to re-add the above rules to the profile (eg, if the snap is
removed/installed/updated/etc).

IIRC the snappy team is aware of this issue, but so it can be properly tracked,
I filed:
https://bugs.launchpad.net/snappy/+bug/1654642

-- 
Jamie Strandboge | http://www.canonical.com



signature.asc
Description: This is a digitally signed message part

Re: classic mode slow, taking up one full core with apparmor logging

2017-01-06 Thread Dan Kegel 
Just to illustrate, here's the output of top:

PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
  489 root  20   0   13320   3876   1940 R  99.7  0.4  17:36.31
systemd-journal
 3779 obdank20   0   75428  62776   9652 R  93.4  6.7   0:05.93
cc1plus
 3734 obdank20   0  138540 132004  12216 R  79.7 14.0   0:39.54
cc1plus
 3707 obdank20   0  202312 197908  12216 R  64.3 21.0   1:15.61
cc1plus
 3785 obdank20   0   61032  46176   9716 R  59.3  4.9   0:03.80
cc1plus

I wantsss all the cores for cc1plu, I does, I does.

On Fri, Jan 6, 2017 at 10:10 AM, Dan Kegel  wrote:
> When building a c++ app on a raspberry pi 3 in classic mode,
> I noticed two things that hurt performance substantially.
>
> 1) the obvious: if you crank config.txt's gpu_mem up above the
> default, life is bad :-)  Don't do that on build machines.
>
> 2) the not so obvious: apparmor is keeping systemctl's journal process
> at 100% on one core logging crud like
>
> Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3249]: AVC apparmor="ALLOWED"
> operation="open"
> profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/m
 
ake//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5//null-/var/snap/classic/common/classic/usr/lib/gcc/arm-linux-gnueabihf/5/cc1plus"
> name="/var/snap/classic/common/classic/usr/include/c++/5/cstring"
> pid=3249 comm="cc1plus" requested_mask="r" denied_mask="r" fsuid=1000
> ouid=0
> Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3254]: AVC apparmor="ALLOWED"
> operation="mknod"
> profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/m
 
ake//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5"
> name="/var/snap/classic/common/classic/tmp/ccpOmyw6.s" pid=3254
> comm="c++" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
>
> Is there an option for reducing apparmor verbosity on ALLOWED operations?
> (speaking strictly as a foreigner in the land of apparmor and snappy)
>
> Thanks!

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

classic mode slow, taking up one full core with apparmor logging

2017-01-06 Thread Dan Kegel 
When building a c++ app on a raspberry pi 3 in classic mode,
I noticed two things that hurt performance substantially.

1) the obvious: if you crank config.txt's gpu_mem up above the
default, life is bad :-)  Don't do that on build machines.

2) the not so obvious: apparmor is keeping systemctl's journal process
at 100% on one core logging crud like

Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3249]: AVC apparmor="ALLOWED"
operation="open"
profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/mak
 
e//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5//null-/var/snap/classic/common/classic/usr/lib/gcc/arm-linux-gnueabihf/5/cc1plus"
name="/var/snap/classic/common/classic/usr/include/c++/5/cstring"
pid=3249 comm="cc1plus" requested_mask="r" denied_mask="r" fsuid=1000
ouid=0
Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3254]: AVC apparmor="ALLOWED"
operation="mknod"
profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/mak
 
e//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5"
name="/var/snap/classic/common/classic/tmp/ccpOmyw6.s" pid=3254
comm="c++" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

Is there an option for reducing apparmor verbosity on ALLOWED operations?
(speaking strictly as a foreigner in the land of apparmor and snappy)

Thanks!

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

Re: Snaps on Unity7 and app-indicators

2017-01-06 Thread Claudio André 
 2016-12-02 13:38 GMT-02:00 Marco Trevisan < 
marco.trevi...@canonical.com>:

> Hello snapcrafters,
>
> As you might have noticed, snap packages that are including
> app-indicators won't generally show the proper icon in unity


Hi, below an error I saw while using LP build servers. Ok, I added the
missing build packages.

But, why "parts" is not aware of its dependencies?

Claudio

--
Preparing to build indicator-gtk2
Building indicator-gtk2
You need gnome-common from GNOME SVN
Downloading parts list

Downloading parts list

Downloading parts list

Downloading parts list

Downloading parts list

Downloading parts list

Downloading parts list

Downloading parts list

Downloading parts list

Command '['/bin/sh', '/tmp/tmpk6h4cu_n', 'env', 'NOCONFIGURE=1',
'./autogen.sh']' returned non-zero exit status 1
env NOCONFIGURE=1 ./autogen.sh
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)
 --
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Accessing dbus (KDE Application)

2017-01-06 Thread Daniel Llewellyn 
On Fri, 6 Jan 2017 at 17:47 Jamie Strandboge  wrote:

> Yes, to claim the well-known dbus name for your snap you need a snap
> declaration
> that allows it. I've granted this to your snap just now and it passes
> automated
> review. This snap declaration applies to future uploads as well. (Note that
> while revisions 6 and 7 have passed review, you still need to release
> them).
>

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

Re: Accessing dbus (KDE Application)

2017-01-06 Thread Jamie Strandboge 
On Fri, 2017-01-06 at 16:10 +, Daniel Llewellyn wrote:
> On Thu, 15 Dec 2016 at 18:33 Jamie Strandboge  wrote:
> 
> > 
> > FYI, the upcoming snapd 2.20 will support the 'dbus' interface. With this
> > you
> > can update your snap to include something like:
> > 
> > slots:
> >   dbus-corebird:
> > interface: dbus
> > bus: session
> > name: org.baedert.corebird
> > 
> I've added that stanza to my snapcraft.yml and rebuilt using strict
> confinement on the new 2.20 snapd. That works perfectly,

Glad to hear the interface is working for you! :)

> but on uploading
> my package to the store (corebird-diddledan.diddledan) I received an
> automated testing fail email reporting that:
> 
> not allowed by 'deny-connection/slot-attributes' in base declaration
> declaration-snap-v2_slots_deny-connection (dbus-corebird, dbus)
> 

Yes, to claim the well-known dbus name for your snap you need a snap declaration
that allows it. I've granted this to your snap just now and it passes automated
review. This snap declaration applies to future uploads as well. (Note that
while revisions 6 and 7 have passed review, you still need to release them).

-- 
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: App Developer

2017-01-06 Thread Michael Hall 
Hi Muhammed,

You can subscribe to the mailing list here:
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Michael Hall
mhall...@gmail.com

On 01/05/2017 09:53 PM, Muhammed Arshid KV wrote:
> Please add me
> 
> 
> 

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

Locally extending trusted certificates

2017-01-06 Thread Loïc Minier 
Hi,

This question came up in the context of Docker registries with self-signed
certificates:
http://askubuntu.com/questions/868268/add-self-signed-
certificate-in-ubuntu-core-16-04
this could be addressed in ways specific to the Docker snap, but I believe
this touches a larger question: support for extending the list of
system-trusted certificates.

Our Ubuntu Core images ship with a set of trusted certificates. These are
inherited from the .deb world where there is a mechanism to locally extend
the list of trusted certificates (update-ca-certificates). This mechanism
doesn't work with core images due to read-only directories (and perhaps
other issues as well).

Here are some possible options to address this:
1) fix the update-ca-certificates system to also work on core images; this
might just be a matter of making some directories bind-mounts to the
writable space

2) implement some kind of snapd keystore feature/configs/APIs (much like
system keystores on mobile OSes); this is likely significant work, but
opens interesting perspectives in providing new management APIs and a more
secure implementation. For instance, one could design this to store secrets
in hw-specific secure stores, or offer mechanisms to roll out new
certificates/keys via assertions, or to disable some specific CAs

3) keep the list of system certificates as static and not locally
configurable; this will likely result in some snaps developing alternate
keystores

I'm sure there are other options and I'd to hear how people think this
should best be addressed in the snap/snapd world.

Cheers,
- Loïc Minier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Accessing dbus (KDE Application)

2017-01-06 Thread Daniel Llewellyn 
On Thu, 15 Dec 2016 at 18:33 Jamie Strandboge  wrote:

> FYI, the upcoming snapd 2.20 will support the 'dbus' interface. With this
> you
> can update your snap to include something like:
>
> slots:
>   dbus-corebird:
> interface: dbus
> bus: session
> name: org.baedert.corebird
>

I've added that stanza to my snapcraft.yml and rebuilt using strict
confinement on the new 2.20 snapd. That works perfectly, but on uploading
my package to the store (corebird-diddledan.diddledan) I received an
automated testing fail email reporting that:

not allowed by 'deny-connection/slot-attributes' in base declaration
declaration-snap-v2_slots_deny-connection (dbus-corebird, dbus)

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

Re: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3

2017-01-06 Thread Oliver Grawert 
hi,
Am Freitag, den 06.01.2017, 08:09 -0600 schrieb Jamie Strandboge:
>  
> > if i install with --devmode from either channel, the daemon starts
> > and
> > the commands work fine though ... so seems we are close ;)
> > 
> This seems like a bug in the pulseaudio interface which allows
> 'setgroups' but
> not 'setgroups32'. Can you add setgroups32 to
> /var/lib/snap/seccomp/profiles/snap.pulseaudio... then restart the
> daemon and
> see if that works for you? Can you file a bug if you haven't already?
> 
adding setgroups32 led to the next missing syscall ("send") ... adding
support for send as well makes the daemon start fine then ... i filed
http://pad.lv/1654585 and assigned it to you ... 

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

App Developer

2017-01-06 Thread Muhammed Arshid KV 
Please add me
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3

2017-01-06 Thread Jamie Strandboge 
On Fri, 2017-01-06 at 13:18 +0100, Oliver Grawert wrote:
> hi,
> Am Donnerstag, den 05.01.2017, 14:31 +0100 schrieb Oliver Grawert:
> > 
> > hi,
> > Am Mittwoch, den 04.01.2017, 19:11 +0100 schrieb Oliver Grawert:
> > > 
> > > 
> > > 
> > > ogra@pi3:~$ grep audio= /boot/uboot/config.txt 
> > > dtparam=audio=on
> > > 
> > FYI both gadgets for pi2 and pi3 have just been updated in the edge
> > channel with this fix, would be good if they could be tested with the
> > pulse snap now :)
> > 
> so i tried to do some testing now that we have alsa enabled images ... 
> 
> installing 8.0-3-12 from beta/candidate without --devmode makes the
> daemon fail on startup with a seccomp error trying to call setgroups32
> and indeed you cant use any of the shipped commands like parec or
> paplay ... 
> if i install with --devmode from either channel, the daemon starts and
> the commands work fine though ... so seems we are close ;)
> 
This seems like a bug in the pulseaudio interface which allows 'setgroups' but
not 'setgroups32'. Can you add setgroups32 to
/var/lib/snap/seccomp/profiles/snap.pulseaudio... then restart the daemon and
see if that works for you? Can you file a bug if you haven't already?

-- 
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: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3

2017-01-06 Thread Oliver Grawert 
hi,
Am Donnerstag, den 05.01.2017, 14:31 +0100 schrieb Oliver Grawert:
> hi,
> Am Mittwoch, den 04.01.2017, 19:11 +0100 schrieb Oliver Grawert:
> > 
> > 
> > ogra@pi3:~$ grep audio= /boot/uboot/config.txt 
> > dtparam=audio=on
> > 
> FYI both gadgets for pi2 and pi3 have just been updated in the edge
> channel with this fix, would be good if they could be tested with the
> pulse snap now :)
> 
so i tried to do some testing now that we have alsa enabled images ... 

installing 8.0-3-12 from beta/candidate without --devmode makes the
daemon fail on startup with a seccomp error trying to call setgroups32
and indeed you cant use any of the shipped commands like parec or
paplay ... 
if i install with --devmode from either channel, the daemon starts and
the commands work fine though ... so seems we are close ;)

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: snapd 2.20 release available in {xenial,yakkety}-updates

2017-01-06 Thread Michael Vogt 
Hi Dan,

On Thu, Jan 05, 2017 at 02:22:11PM -0800, Dan Kegel wrote:
> Can you say a few words about classic confinement?  I didn't see doc...

Thanks for this reminder, I should have included the link that David
provided to http://snapcraft.io/docs/reference/confinement

In a nutshell classic make it very easy to provide snaps for
traditional (classic) distributions like Ubuntu 16.04. It is currently
not quite as polished as we would like it to be (we are actively
working on fixing that!) but I think its a really nice feature.

> (Like the fact that you're supporting 14.04.  Some large customers
> are stuck on that version still, could be handy.)

We have good news here - we fixed the build problem and snapd 2.20 is
now available in 14.04 in the "trusty-proposed" channel. I would
suggest to use it in a server environment only currently until we had
a chance to fix the xserver bug [3] (below).

Cheers,
 Michael

> On Thu, Jan 5, 2017 at 2:13 PM, Michael Vogt  
> wrote:
> > Hi,
> >
> >
> > the new snapd version 2.20 is now available for everyone on Ubuntu
> > 16.04 and 16.10 via xenial-updates and yakkety-updates. It contains
> > some nice improvements and fixes, see [1] for the details.
> >
> > The other distros will be updated shortly. The snapd 14.04 version is
> > not quite ready yet, we are working on a seccomp filtering bug [2] on
> > amd64 and also on a xserver related problem [3]. We hope to resolve
> > those soon.
> >
> > Please let us know if you notice any issue.
> >
> >
> > Happy snapping,
> >  Michael (on behalf of the snappy team)
> >
> >
> > [1] https://lists.ubuntu.com/archives/snapcraft/2016-December/002095.html
> > [2] https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1653487
> > [3] https://bugs.launchpad.net/snappy/+bug/1650389
> >
> > --
> > 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 mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft