Re: Snapping with scons

2017-01-16 Thread Spencer Parkin 
Okay, maybe no one knew what I was taking about.  In any case, for the
record, I've resolved the issue by using relative paths in my SConstruct
file that would only work during snapping.  This doesn't cause an issue
with normal development, because I also include relative paths (include
paths and lib paths) that would only work in that context.  Extraneous
paths in either context is fine.

What I figured is that, like the "DESTDIR" variable provided by the scons
plugin, there would be similar environment variables setup that SConstruct
and other make-type files could use to be able to locate dependency parts
that have already been built during the snapping process.  But maybe my
solution is above reasonable?  It doesn't seem all that clean to me.

By the way, the documentation at...

http://snapcraft.io/docs/reference/plugins/scons

...is pretty bad.  If someone pointed me in the right direction, I could at
least add what I know from looking at the plugin's Python code.

Sincerely yours,
The worst snapcrafter on the list.

On Mon, Jan 16, 2017 at 12:07 AM, Spencer  wrote:

> Hi.  I have a project with 2 dependencies so I need 3 parts in my yaml
> file.  The dependencies install correctly during snapping, but when my
> program starts to compile, it can't locate the header files for the library
> dependencies.  There is no mystery here as to why that is the case.  My
> question, however, is: what do I put in my scons file so that I can locate
> the header files during snapping?  I've been looking at the snapcraft
> python code, but I can't seem to find out what, if any, additional
> environment variables there may be setup for me to use in my scons file so
> that I can locate headers and libraries.  Is there a different way to go
> about it?
>
> Thanks.
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: netplan and post-up/pre-down scripts

2017-01-16 Thread Mike Pontillo 
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]

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".)

Regards,
Mike


[1]: I would refer to the IF-MIB definitions for administrative and
operational status, which haven't changed in a long time. They can be found
in RFC 2863 sections 3.1.12 and 3.1.13[1]. There is also discussion
(amendments to a previous RFC) about when to send the "linkUp" trap. (To
summarize, only when a link is both operationally and administratively up.)
See the relevant states here:

https://tools.ietf.org/search/rfc2863#section-3.1.12

Contrast this to the default behavior of an auto/static interface: an
interface is considered UP if its operStatus AND adminStatus were "up"
within 5 minutes of boot. After that, you can throw all your assumptions
out the window; the interface will stay DOWN even if its operational status
changes from "down" to "up", and the system will hobble along in a
half-configured state, even if the link status changes.


[2]: I think that should default to to allow boot, to prevent the UX
nightmares that occur during boot when the boot process waits for
interfaces it thinks should be up. If a particular service is finicky
enough to not handle a missing interface gracefully, the admin can manually
configure the flag to /not/ allow boot.

The current behavior is also strange because if an interface becomes
operationally "down" after the five minute timeout, the system takes no
action, pretending nothing happened. (Why did we just wait 5 minutes for an
interface to be up, if we weren't going to care if it later went down?) If
a service /seriously/ depends on an interface being up, and cannot handle
changes in interface status, the admin should configure that service to
start upon receiving a link up event, and stop it upon receiving a link
down event for that interface.
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Yet more issues snapping

2017-01-16 Thread Matthew Aguirre 

I just issued a pull request on your app.
Here's the gist:

you needed to include x11 slot
I admit I am not familar w/ the python plugin, so I didn't use the 
requests package from python-packages as it failed on me the first 
time. Instead added it from the repos under stage-packages.

--
Matt

On Mon, Jan 16, 2017 at 7:07 PM, Gareth France 
 wrote:



On 16/01/17 23:58, Loïc Minier wrote:
I suggest you try running your Travis build inside a 16.04 
environment; it seems this is achieved by running the 16.04 Docker 
container.

Thank you, but how do I do that?

--
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: Yet more issues snapping

2017-01-16 Thread Gareth France 



On 16/01/17 23:58, Loïc Minier wrote:
I suggest you try running your Travis build inside a 16.04 
environment; it seems this is achieved by running the 16.04 Docker 
container.

Thank you, but how do I do that?

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

Re: Yet more issues snapping

2017-01-16 Thread Gareth France 



On 17/01/17 00:04, Matthew Aguirre wrote:
Can you not just list the library dependencies and dev packages in the 
snapcraft file instead of building everything from source?

python-gtk2

parts:
  your_app:
plugin: python
source: .
build-packages:
  - python-gtk2-dev
stage-packages:
  - python-gtk2
...
Or I assume there may be a similar package for wxPython.
--
Matt
I have no idea. I've been asking for help but it's been thin on the 
ground. I've only ever built one snap without issues, this is early days 
for me.
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Yet more issues snapping

2017-01-16 Thread Gareth France 
Having given up all hope of ever being able to do a simple thing like 
include pygtk in a snap I have rebuilt my package using wx. I can't face 
the same issue twice, surely right?



Well I've built it without explicitly mentioning wx, and specifically 
asking travis to include it. The end result is always a failure. Could 
someone please take a look at this and tell me what on earth is going on?



https://paste.ubuntu.com/23812998/



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

Re: DHCP and /etc/resolv.conf

2017-01-16 Thread Mark Shuttleworth 
On 16/01/17 16:39, Joe Coates wrote:
>
> I'm snapping an app which includes a DHCP client replacement.  
> Ultimately it wants to update/replace /etc/resolv.conf. My snap is
> connected to all the "network" interfaces available in my ubuntu-core,
> but none seem to allow write access to this file.  Shouldn't an
> interface like "network-control" allow write access to /etc/resolv.conf ? 
>

I think /etc/resolv.conf is generated from a number of sources, but yes,
it should be possible to influence it.

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

DHCP and /etc/resolv.conf

2017-01-16 Thread Joe Coates 
I'm snapping an app which includes a DHCP client replacement.   Ultimately it 
wants to update/replace /etc/resolv.conf. My snap is connected to all the 
"network" interfaces available in my ubuntu-core, but none seem to allow write 
access to this file.  Shouldn't an interface like "network-control" allow write 
access to /etc/resolv.conf ?


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

Re: snapd and semaphores

2017-01-16 Thread Mark Shuttleworth 
On 10/01/17 08:44, Olivier Tilloy wrote:
> On Tue, Jan 10, 2017 at 2:41 PM, Jamie Strandboge  wrote:
>> On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote:
>>> Here is the bug report: https://launchpad.net/bugs/1653955
>> Thanks! The fix is in master and will bi in snapd 2.21.
> Excellent, thanks Jamie for your prompt response!

Catching up on email, I have to say a TON of good stuff landed in 2.21.
Wow. Thank you everybody!

Mark

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

Re: netplan and post-up/pre-down scripts

2017-01-16 Thread Mark Shuttleworth 
On 06/01/17 13:12, Mike Pontillo wrote:
>Long story short: in order to get the behavior I wanted, I wrote a
> custom script that monitors *operational status* (aka physical link
> up/down status), and I launch it using /e/n/i's `post-up`, and bring
> it down using /e/n/i's `pre-down` scripts.
>
>Looking at the `netplan` spec[4], I don't see a way to achieve that
> functionality. I know that many people are using the script-callout
> functionality in /e/n/i to achieve what they need to achieve, so it
> seems to me that having this in `netplan` is critical to achieving
> parity with what we have in Xenial with `ifupdown`.
>
>In an ideal world, I think `netplan` would be able to model my use
> case out-of-the-box.[5] But since we can't expect to model everyone's
> use case, it seems like custom scripting functionality is a hard
> requirement, though perhaps one that could have tricky cross-platform
> implications.

Would 'got-link' and 'lost-link' be good names for this?

Mark

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

Re: [NEWS] Kdenlive devel snap

2017-01-16 Thread Mark Shuttleworth 
On 05/01/17 15:41, Tiago Herrmann wrote:
> Sorry to revive this old thread, but this very same website just
> posted a tutorial [1] on how to manage snaps.
> The maintainer of this website is a friend of mine and he told me his
> goal was to write the most complete snap utilization tutorial
> available in Portuguese.
> He has been doing a great job on spreading news about ubuntu and snap
> here in Brazil.
>
> [1] http://www.diolinux.com.br/2017/01/ubuntu-snap-utilization-manual.html
> or google translation:
> https://translate.google.com/translate?hl=pt-BR=pt=en=http%3A%2F%2Fwww.diolinux.com.br%2F2017%2F01%2Fubuntu-snap-utilization-manual.html
>

Very happy to see how many people are enjoying snaps now!

Those of you who have been thinking about making a snap, I would suggest
you start with a classic snap which should work on 14.04 and 16.04 very
easily. Then you can try to get it fully confined, starting with devmode.

Mark

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

Re: Switching to a non-native package

2017-01-16 Thread Gustavo Niemeyer 
That sounds fine, but also like a detour from the actual goal. One way or
another, the in-tree packaging that is there for Ubuntu won't be at stake
when making it work on Debian. Also note that the in-tree debian/ directory
doesn't work even for Ubuntu, strictly speaking. We already have the 14.04
bits in a separate branch.

I'd focus on making it properly test more distributions first (not just
Debian either) and later worry about whether we should get rid of debian/
or not.

On Mon, Jan 16, 2017 at 12:02 PM, Zygmunt Krynicki <
zygmunt.kryni...@canonical.com> wrote:

> I'd like to work on enabling Debian in the CI loop and I was thinking
> that it would be somewhat easier we switched to non-native packaging
> in the upstream tree and similarly switched to quilt in the Debian
> tree (we could have separate packaging trees for sid / stretch if that
> would help). Since my view may be simplistic I would like to ask the
> current most active Debian maintainers of snapd for opinion.
>
> Right now almost all of the CI in the tree is performed on the
> packaging that is in the tree as well. The notable exception is 14.04
> which has a separate packaging branch. This is unrealistic as the
> Debian packaging tree is widely different and even if we built a
> package from the in-tree debian directory and tested it on a real
> Debian machine the result would not be representative of what a
> subsequent upstream release would look like in Debian.
>
> I'd like to propose that we remove the debian directory from the
> upstream repository (no special casing) and work on ensuring that
> Ubuntu and subsequently Debian are tested equally well whenever we
> make a pull request.
>
> Best regards
> ZK
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>



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

Switching to a non-native package

2017-01-16 Thread Zygmunt Krynicki 
I'd like to work on enabling Debian in the CI loop and I was thinking
that it would be somewhat easier we switched to non-native packaging
in the upstream tree and similarly switched to quilt in the Debian
tree (we could have separate packaging trees for sid / stretch if that
would help). Since my view may be simplistic I would like to ask the
current most active Debian maintainers of snapd for opinion.

Right now almost all of the CI in the tree is performed on the
packaging that is in the tree as well. The notable exception is 14.04
which has a separate packaging branch. This is unrealistic as the
Debian packaging tree is widely different and even if we built a
package from the in-tree debian directory and tested it on a real
Debian machine the result would not be representative of what a
subsequent upstream release would look like in Debian.

I'd like to propose that we remove the debian directory from the
upstream repository (no special casing) and work on ensuring that
Ubuntu and subsequently Debian are tested equally well whenever we
make a pull request.

Best regards
ZK

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

Re: Spotify-Web-Player-for-Linux as a snap

2017-01-16 Thread Evan Dandrea 
Hi Matthew,

You've set your snap to use the 'platform' interface, but no such interface
exists. If you remove that line and 'unity8', then re-upload, it should
pass review.

Do you recall what you read that referenced a 'platform' interface? If
there's some outdated documentation out there, I'd like to get it fixed.

Let us know if you need any more help, and thanks for snapping Spotify!

On Sat, 14 Jan 2017 at 21:44 Thibaut Rouffineau <
thibaut.rouffin...@canonical.com> wrote:

> Hi Matthew
>
> Once again, great job on the snap!
>
> Meet the snapcraft list! (feel free to join too : here
> 
>  )
>
> Copying in your messages below to see if someone can help!
>
> Cheers
>
> T
>
> -- Forwarded message --
> From: *Matthew James* 
> Date: Sat, Jan 14, 2017 at 5:31 PM
> Subject: Re: Spotify-Web-Player-for-Linux as a snap
> To: Thibaut Rouffineau 
>
>
> Just to update that the snap is now under 'manual review' after it failed
> automatic testing due to platform lint tags, perhaps because I built with
> electron-builder.
>
> On 14 Jan 2017 5:05 p.m., "Matthew James"  wrote:
>
> Hi Thibaut,
>
> I have been able to make 32 and 64bit snaps in the next version of Spotify
> Web Player for Linux, version 1.0.30. I made a snap package on the Ubuntu
> Store and uploaded the 64bit snap but I cannot upload the 32bit snap unless
> I upload a new update. How would I be able to offer both? At the moment I
> can also host it on GitHub with the AppImages too.
>
>
> Regards,
>
> Matthew
>
> --
> 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: Apparmor error when using classic mode

2017-01-16 Thread Zygmunt Krynicki 
Hey

This bug is fixed in the recently released snapd 2.21. Mark's suggestion is
correct. You should not (until 2.21) combine interfaces and classic
confinement. Since you may be interested what happens when you do. In 2.21
you can install a snap that is using classic confinement with --jailmode
which will enable all those plugs/slots and treat it as any other snap.

I hope this helps you out

Best regards
ZK

On Mon, Jan 16, 2017 at 10:02 AM, Mark Shuttleworth  wrote:

> On 15/01/17 08:58, Luke Williams wrote:
>
> Hello,
>
> I have the following error when I try to install my snap in classic mode:
>
> root@ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap --classic
> --force-dangerous
> error: cannot perform the following tasks:
>
> - Setup snap "flexswitch" (unset) security profiles (cannot setup apparmor
> for snap "flexswitch": cannot load apparmor profile "snap.flex
> switch.flexswitch": cannot load apparmor profile: exit status 1
>
> apparmor_parser output:
>
> profile has merged rule with conflicting x modifiers
>
> ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to
> load
> )
>
> - Setup snap "flexswitch" (unset) security profiles (cannot load apparmor
> profile "snap.flexswitch.flexswitch": cannot load apparmor prof
> ile: exit status 1
>
> apparmor_parser output:
>
> profile has merged rule with conflicting x modifiers
>
> ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to
> load
> )
>
>
> I cannot find any information on why it is failing to install. Any thing I
> should look at to see what is keeping this from working or any more
> information you need to assist in troubleshooting?
>
> I am trying to install this snap on 16.04 Server.
>
>
> I have a feeling this is when one tries to combine "confinement: classic"
> with plugs on commands.
>
> Mark
>
> --
> 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: Apparmor error when using classic mode

2017-01-16 Thread Mark Shuttleworth 
On 15/01/17 08:58, Luke Williams wrote:
> Hello,
>
> I have the following error when I try to install my snap in classic mode:
>
> root@ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap
> --classic --force-dangerous  
>  
> error: cannot perform the following tasks:
>   
> - Setup snap "flexswitch" (unset) security profiles (cannot setup
> apparmor for snap "flexswitch": cannot load apparmor profile "snap.flex
> switch.flexswitch": cannot load apparmor profile: exit status 1  
>
> apparmor_parser output:  
>
> profile has merged rule with conflicting x modifiers  
>   
> ERROR processing regexs for profile snap.flexswitch.flexswitch, failed
> to load   
> )
>
> - Setup snap "flexswitch" (unset) security profiles (cannot load
> apparmor profile "snap.flexswitch.flexswitch": cannot load apparmor prof
> ile: exit status 1
>   
> apparmor_parser output:  
>
> profile has merged rule with conflicting x modifiers  
>   
> ERROR processing regexs for profile snap.flexswitch.flexswitch, failed
> to load   
> )
>   
>
> I cannot find any information on why it is failing to install. Any
> thing I should look at to see what is keeping this from working or any
> more information you need to assist in troubleshooting?
>
> I am trying to install this snap on 16.04 Server.

I have a feeling this is when one tries to combine "confinement:
classic" with plugs on commands.

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