Re: gnu screen does not work in classic?

[Nick Moffitt]

Dan Kegel:
> I tried to use 'screen' as usual to start a long-running job
> inside classic, but it failed because /proc/self/fd/0 was
> owned by root:

As a workaround, you can use /usr/bin/script from the bsdutils package
to give you a fresh pty that screen won't get upset about.  Something
like this should do the trick:

script -c 'screen -RAD' /dev/null

-- 
Nick Moffitt

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

lxc not working in classic on pi?

[Dan Kegel]

I have a script from a classic ubuntu environment
that wants to be able to create lxc containers
on the fly.  I tried running it on ubuntu core on the pi3,
in the classic environment, but it failed:

(classic)user@localhost:~$ sudo apt install lxc
...
(classic)user@localhost:~$ sudo lxc-create -n foo -t download
lxc-create: utils.c: get_template_path: 1394 No such file or directory
- bad template: download
(classic)user@localhost:~$ sudo apt install lxc-templates
(classic)user@localhost:~$ sudo lxc-create -n foo -t download
lxc-create: lxccontainer.c: create_run_template: 1290 container
creation template for foo failed

I guess I can live without isolating my jobs in lxc
when running on pi for now, but this seems like a fidelity problem in
the classic environment.

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

snapd and semaphores

[Olivier Tilloy]

Hi everyone, and happy new year!

I’m snapping an app that makes use of semaphores¹ and seeing an
apparmor denial. The glibc implementation of sem_open calls
SHM_GET_NAME(EINVAL,SEM_FAILED,SEM_SHM_PREFIX) where SEM_SHM_PREFIX is
"sem.", so it tries to create /dev/shm/sem.{name}, which fails because
snapd only allows /dev/shm/snap.@{SNAP_NAME}.**.
At a quick glance, there’s no mechanism (e.g. env var) to customize
the prefix ("sem.").
Is this an issue others have run into? Is there a recommended solution?

Thanks in advance!

 Olivier


¹ http://man7.org/linux/man-pages/man7/sem_overview.7.html

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

Re: Shared content example - ubuntu-app-platform

[Timo Jyrinki]

2016-12-08 2:56 GMT+02:00 knitzsche :
> How do consumers (snap devs) know the lib/API versions contained? On touch
> we had the concept of a "framework", whose version implied a set of API
> commitments. Since this puts QT together with other (Ubuntu )  libs,
> what's the reasonable expectation?

Right now the versioning we have is the "content:" field, currently at
ubuntu-app-platform1. This was recommended to me in October.

The idea would be to increment that so that apps using
ubuntu-app-platform1 continue to fetch an older platform snap from the
store providing that version, while people can update their apps to
the newer version at their pace. This is the theory, I'm not sure
about the implementation status for things like 1) fetching older
version with matching "content:" value in case the newest snap in
store has incremented value, 2) co-installing different versions with
different "content:" value. We may need to change snap itself or
introduce a new method for the versioning if this is not the final
way.

-Timo

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