Re: Architecture-specific settings for snapcraft parts

[Joseph Rushton Wakeling]

On 03/04/17 21:18, Joseph Rushton Wakeling wrote:

Recently I tried some ARM builds of the LDC snap package, and came across some
issues where one of the custom C flags used were not supported:
https://launchpadlibrarian.net/313662608/buildlog_snap_ubuntu_xenial_armhf_ldc2_BUILDING.txt.gz

Is there any way to customize the settings for parts according to architecture?
In this case I'm looking to customize the cmake configflags.


I wonder if I might ping on the above question?  I actually have two use-cases:

  * different `configflags` for the cmake plugin depending on the architecture;

  * a different `source:` field for a plugin that downloads a prebuilt binary
used in the build process (I obviously need a different binary for i386
versus amd64 builds).

Thanks & best wishes,

-- Joe

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

Re: Snap packages as build dependencies of other snaps

[Joseph Rushton Wakeling]

On 09/04/17 05:19, Stuart Bishop wrote:

This is tracked at https://bugs.launchpad.net/bugs/1677974

I don't know the time frame. I'm primarily interested in Launchpad
building my snaps, which will also need updating once snapcraft can
somehow handle snap package build dependencies.


Thanks for the heads-up, I've added my use-case there.

Obviously time-frames are for the developers, but if support lands in snapcraft 
master before the end of the month, it might give me an opportunity to show off 
the plugin I'm working on at the D programming language conference at the 
beginning of May in Berlin: http://dconf.org/2017/index.html ;-)



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

Re: Snap packages as build dependencies of other snaps

[Joseph Rushton Wakeling]

On 09/04/17 01:24, XiaoGuo Liu wrote:

can you do it by remote parts? you can find more info by:

$ snapcraft update
$ snapcraft search

There are a number of existing parts there already. You can publish your
own.


That's a cool thing to know about.  I'd consider it, but since the package I 
want to use as a dependency is one that I control, I'm not sure that I really 
gain anything over just copying the relevant parts instructions into the other 
snap package.


The particular reason I would like to actually be able to use an existing snap 
package as a build package is really that it seems like a waste of effort to 
rebuild something that's already built (and takes some time to build).  I read 
the discussion here:

https://bugs.launchpad.net/snapcraft/+bug/1616985/comments/5

... and was wondering if that kind of flexibility was likely to arrive soon.

Note, I have a vested interest in this for a snapcraft plugin that I'd like to 
write myself, which has almost exactly the same use-case as the go plugin 
discussed in that issue. ;-)


Anyway, thanks for letting me know about remote parts.  But I think in this case 
I really would like to be able to ask for a snap package as something that can 
be used to build another snap.


Thanks & best wishes,

-- Joe


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

Snap packages as build dependencies of other snaps

[Joseph Rushton Wakeling]

Hello folks,

Is it possible to specify an existing snap package (by track and release 
channel) as a build dependency of a part of another snap package?


I'm interested specifically in the case of using an existing snap package to 
provide a compiler used to build another snap.  From what I understand from 
discussion around the go snapcraft plugin, there is some intention to allow 
this, but is it just for plugins?


Thanks & best wishes,

-- Joe

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

Re: Tracks for ldc2 snap package

[Joseph Rushton Wakeling]

On 06/04/17 14:55, Bret A. Barker wrote:

I've added these tracks for you, let me know if you have any troubles or 
questions.


All seems good!  Thank you very much :-)


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

Tracks for ldc2 snap package

[Joseph Rushton Wakeling]

Hello all,

If I understand https://snapcraft.io/docs/reference/channels right, I'm supposed 
to ask here about this -- please let me know if I'm wrong :-)


Could I please request for two tracks, named 1.1 and 1.2, to be enabled for the 
ldc2 snap package?


Thanks and best wishes,

-- Joe

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

Error with Launchpad uploading 403 Client Error: Forbidden

[Joseph Rushton Wakeling]

Hello all,

Recently I was able to successfully set up Launchpad builds for my ldc2 snap. 
However, auto-upload to the store failed with a 403 Client Error: Forbidden.


The error messages are no more informative than this, so anyone have any idea 
what's going on?


Note that I haven't specified any particular channels or tracks to release to, 
since I assumed there was a difference between uploading and releasing.


Thanks & best wishes,

-- Joe

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

Re: ANN: snapcraft 2.28 has been released

[Joseph Rushton Wakeling]

On 30/03/17 21:54, Sergio Schvezov wrote:

Prettier version of the release notes can be found on 
https://github.com/snapcore/snapcraft/releases/tag/2.28


Big thanks for this one!  More specifically ...


### classic confinement

With this release it should be now possible to use launchpad builders to build 
for other architectures than `amd64` as the detection logic for the dynamic 
linker in core has been fixed.


I can confirm that Launchpad was able to successfully complete both amd64 and 
i386 builds of the current development branch of my ldc2 snap.  Armhf and arm64 
builds are currently under way and are looking fine so far (if anything goes 
wrong I would anticipate it being an LDC issue).


Couldn't have come at a better time as far as I'm concerned.

Thanks again and best wishes,

-- Joe

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

Re: Meta-packages for snaps

[Joseph Rushton Wakeling]

On 27/03/17 04:33, Michael Hall wrote:

Because your snap is going to pull in all of your dependencies, doing
one snap per tool will likely result in more duplication and thus more
disk space than providing it all as a single package.


That's a very good point.  On the other hand, the disk space issue isn't likely 
to be so great in the grand scheme of things, whereas providing tools separately 
may allow greater freedom in updating their individual versions (these are not 
things all deriving from one repo or one release series).



If your users are likely to want more than one of these tools, I would
recommend just providing them all in one package. That way it's still
easy for them to install with a single command, and they will have
everything they might want already there.


Fair enough.  This actually dovetails quite nicely with the planned use-case, 
which is snap packages for all the core D utilities: the D core devs I'm talking 
with are probably in favour of a single snap providing all the utilities.  I 
will probably follow up on this soon :-)


Overall, though, I still think it'd be nice to have the flexibility (as a 
publisher) to choose between a single snap with multiple commands, versus a 
meta-snap that ensures multiple different independent snaps are installed.


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

Reserved project names and cooperative transfer of ownership

[Joseph Rushton Wakeling]

... yes, more questions :-)

First, how problematic is it to organize a cooperative transfer of ownership of 
a reserved name between one snap publisher and another?  I'm thinking of a case 
where a package might start as a 3rd-party project (read: yours truly) and then 
be made official later.


I know the recommended practice is to define a different name, like 
`appname-whatever`, but I'm wondering what the options and difficulties might be 
if that wasn't wanted.


Second, we discussed a while back about the possibility of reserving names for 
multiple apps provided by a single snap, so that instead of `snapname.appname` 
being the exposed command, it could just be `appname`.  Even if that's not 
technically possible right now, is it possible to reserve those names ahead of 
time in anticipation of that change ... ?


Thanks & best wishes,

-- Joe

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

Re: Defining multiple (external) snap packages in a single git repo

[Joseph Rushton Wakeling]

On 25/03/17 10:00, Mark Shuttleworth wrote:

We could host multiple snapcraft.yamls in a repo, using some sort of
snapcraft.*.yaml scheme, for example.

So:

  snapcraft

 builds all snaps

  snapcraft snap foo

 builds snapcraft.foo.yaml


Hmm, to be honest, I was thinking of a simpler setup where you'd have something 
like,


base_dir/
foo/
snap/
snapcraft.yaml
bar/
snap/
snapcraft.yaml

etc...

i.e. just there would be multiple folders containing independent snap package 
definitions.  This wouldn't require any tweaks to snapcraft, but would it be 
possible to integrate with CI in line with what's described here?

https://snapcraft.io/docs/build-snaps/ci-integration

I'm anticipating it might be easier with Travis than with Launchpad but only 
because I don't know to what extent it's straightforward to define custom build 
jobs on Launchpad.  The dlang installer project already uses Travis (but 
currently only for testing) so that might be a viable option.


Thanks & best wishes,

-- Joe

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

Re: Meta-packages for snaps

[Joseph Rushton Wakeling]

On 25/03/17 00:27, mhall119 wrote:

Usually you would include all related tools in the same snap. Is there a
need to having them separate if they all need to be installed together?


Mostly that they don't technically _need_ to all be together.  I mean, why not 
split stuff up if its components can be provided independently, allowing the 
user to pick what bits they want (or not)?


Maybe I'm hanging on too much to the deb world, but multiple independent 
packages with a meta-package to provide the recommended collection, seems like a 
good pattern in general.  But from your answer, I take it that it's not 
currently possible?


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

Defining multiple (external) snap packages in a single git repo

[Joseph Rushton Wakeling]

Hello all,

I've been discussing with some of the D language developers about how to move 
forward with snap packages for the core D tools.


The D language project has a dedicated git repo for building packages for 
various targets [1] and the obvious place to define snap packages would be 
there.  However, would this be able to work with snap-package CI such as 
build.snapcraft.io or the Launchpad build tools?  They both seem rather biased 
towards the assumption that a single git repo defines a single snap package.


An alternative would of course be for D's own CI tools to run `snapcraft 
cleanbuild` and upload the resulting packages to the store.  Any advice on how 
this could me made workable ... ?


Thanks & best wishes,

-- Joe

[1] https://github.com/dlang/installer

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

Meta-packages for snaps

[Joseph Rushton Wakeling]

Hello folks,

Is it possible -- or are there plans for -- snap 'meta-packages' whose only job 
is to make sure that multiple related snap packages get installed together?


The use-case I'm thinking of is a collective 'dlang' meta-package that would 
install a group of snaps each providing a different tool relating to the D 
programming language.


Thanks & best wishes,

-- Joe

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

Re: Status of snapd on Arch Linux

[Joseph Rushton Wakeling]

On 20/03/17 23:14, Gustavo Niemeyer wrote:

Most likely the snap was partly configured to run elsewhere, but not
entirely.

We really need to have someone looking into this package, preferably just
restoring the standard /snap path.

Can you rebuild the package and try that out?  Would be a nice data point.
If you can't or don't want to, that's okay. I'm sure the package maintainer
will look into that.


Well, I'm not an Arch user typically; I just installed it into a VM (actually, 
my first ever Arch install) to check out whether snap packages I've created 
would work.


I can try to take a look, but I'm not sure I'll get there before the maintainer 
does ;-)


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

Re: Status of snapd on Arch Linux

[Joseph Rushton Wakeling]

On 20/03/17 21:39, Gustavo Niemeyer wrote:

  * installing my ldc2 snap (`snap install --classic --candidate ldc2`)

worked
fine (it shows up in `snap list` as expected) but if I try to run
/var/lib/snapd/snap/bin/ldc2 directly I get an error message:

execv failed: No such file or directory



What is it pointing to?


/var/lib/snapd/snap/bin/ldc2 is pointing to /usr/bin/snap (as are all the 
entries in /var/lib/snapd/snap/bin/).



  * attempting to run the actual underlying binary within the snap, i.e.

/var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other
binaries
there) results in a similar error message:

-bash: ./ldc2: No such file or directory



This was never supposed to be done. Exposed content is supposed to work as
done above.


I do recognize that, but in the circumstances I thought I'd try it to see if it 
shed any light on the situation.



Most of these issues seem to be related to the move out of /snap, perhaps
done too quickly.

I'd suggest returning /snap to its place, at least until those issues are
sorted out there.


Note that simply putting a /snap symlink to /var/lib/snapd/snap doesn't work 
(cf. my response to Sergio).


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

Setting environment variables from within snapcraft.yaml

[Joseph Rushton Wakeling]

Hello folks,

Is it possible to set environment variables to be used when creating a part of a 
snap?


I guess one could use the `prepare:` scriptlet to do something like `export 
MY_VAR=whatever` but I'd like the environment variable to be set before I even 
pull the source.  (If you're wondering why: I'm considering whether I can use 
git environment variables to work around the launchpad-buildd constraints on 
support for git:// URLs.)


I'm not seeing anything relevant in https://snapcraft.io/docs/build-snaps/parts, 
hence why I ask 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: Triggering CI/snap builds on changes to snapcraft parts

[Joseph Rushton Wakeling]

On 20/03/17 11:37, Evan Dandrea wrote:

Do you need better than day-level resolution? If not, I'd suggest using
Travis' cron feature to create nightly builds:
https://docs.travis-ci.com/user/cron-jobs/


Does that actually solve the problem described, though?  I ask because as Loïc 
stated it, it's one that I'm interested in too.


Suppose a security update arrives for a deb package that my snap lists as a 
build-package or a stage-package.  Ideally CI would recognize that the 
dependencies have updated since the snap was last built, build a new package, 
and auto-upload (and maybe publish) it.


Do nightly builds actually address this?  Most of the time there will be no 
changes to the dependencies, so how does one identify the times when the 
published package needs updating?



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

Re: Status of snapd on Arch Linux

[Joseph Rushton Wakeling]

On 20/03/17 20:21, Sergio Schvezov wrote:

Does it work if you create a symlink of /var/lib/snapd/snap to /snap? One of 
the things classic confined snaps require is a fixed path to ld in core


Unfortunately not: still 'execv failed: No such file or directory' :-(

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

Re: git clone and Launchpad build system

[Joseph Rushton Wakeling]

On 18/03/17 22:11, Gregory Lutostanski wrote:

Launchpad builders have an issue with git where they do not proxy that
connection, only https. Here the issue is that that github repo has
submodules specified with the git: url schema (and its doing a recursive
checkout of the source).

The bug is https://bugs.launchpad.net/launchpad-buildd/+bug/1663920


Ah, cheers.  I'd looked through the bug list and seen that one, but not realized 
the submodules were using `git://` URLs until just before your email arrived.



As a workaround you can change the submodules to https: rather than git:
annoying indeed, that is what I had to go with personally. Dunno if anybody
else has other ideas.


Yup.  It's a bit finnicky for me to do that given that the submodules are 
defined by my upstream (I can send them a patch, but it's a PITA to ask them to 
make a patch release just to deal with this issue).


I did look into just downloading a tarball of the source, but that has some 
issues of its own -- since the CMakeLists.txt of the project I'm building 
defines some rules for comparing the version number against the output of `git 
describe`, I run into some rather nasty issues where the git history compared to 
is that of the snap package itself (!).


I'll follow up with my upstream and see what I can do, anyway.  Thanks again for 
the help and advice!


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

Re: git clone and Launchpad build system

[Joseph Rushton Wakeling]

On 18/03/17 21:28, Joseph Rushton Wakeling wrote:

On 18/03/17 14:46, Joseph Rushton Wakeling wrote:

Is there an issue with using git source for parts of snap packages when using
the Launchpad build system?  I'm having consistent build failures for this;
originally I tried switching from `git://` URLS to `https://`, but I'm still
seeing the same errors, see e.g.
https://launchpadlibrarian.net/311390659/buildlog_snap_ubuntu_xenial_amd64_ldc2_BUILDING.txt.gz:



Still failing despite updating to make sure the `source-type` is explicitly
specified as git.  The same snap package builds fine for me with a `snapcraft
cleanbuild`.


A look a bit further back in the build log reveals what I think may be the 
problem: the submodules of one of the git repositories have their URLs specified 
using `git://` URLs:


Submodule 'druntime' (git://github.com/ldc-developers/druntime.git) registered 
for path 'runtime/druntime'
Submodule 'phobos' (git://github.com/ldc-developers/phobos.git) registered for 
path 'runtime/phobos'
Submodule 'tests/d2/dmd-testsuite' 
(git://github.com/ldc-developers/dmd-testsuite.git) registered for path 
'tests/d2/dmd-testsuite'

Cloning into 'runtime/druntime'...
fatal: unable to connect to github.com:
github.com: Name or service not known

fatal: clone of 'git://github.com/ldc-developers/druntime.git' into submodule 
path 'runtime/druntime' failed


Are `git://` URLS genuinely not supported by the launchpad build system?  And if 
so, is there a chance this could be addressed?


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

git clone and Launchpad build system

[Joseph Rushton Wakeling]

Is there an issue with using git source for parts of snap packages when using 
the Launchpad build system?  I'm having consistent build failures for this; 
originally I tried switching from `git://` URLS to `https://`, but I'm still 
seeing the same errors, see e.g. 
https://launchpadlibrarian.net/311390659/buildlog_snap_ubuntu_xenial_amd64_ldc2_BUILDING.txt.gz:


Command '['git', 'clone', '--recursive', '--branch', 'v0.17.3', 
'https://github.com/ldc-developers/ldc.git', 
'/build/ldc2/parts/ldc-bootstrap/src']' returned non-zero exit status 128

Traceback (most recent call last):
  File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 202, in main
builder.pull()
  File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 139, 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-28577/chroot-autobuild', 'linux64', '/bin/sh', 
'-c', 'cd /build/ldc2 && env LANG=C.UTF-8 
https_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_SETUP_CORE=1 
http_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 
snapcraft pull']' returned non-zero exit status 1

Revoking proxy token...
RUN: /usr/share/launchpad-buildd/slavebin/scan-for-processes 
['scan-for-processes', 'SNAPBUILD-28577']
Scanning for processes to kill in build 
/home/buildd/build-SNAPBUILD-28577/chroot-autobuild...
RUN: /usr/share/launchpad-buildd/slavebin/umount-chroot ['umount-chroot', 
'SNAPBUILD-28577']

Unmounting chroot for build SNAPBUILD-28577...
RUN: /usr/share/launchpad-buildd/slavebin/remove-build ['remove-build', 
'SNAPBUILD-28577']


The corresponding part of the snapcraft.yaml:
https://github.com/ldc-developers/ldc2.snap/blob/da18a99f4c66c219b4cf9d06b4087a5fe9acce79/snap/snapcraft.yaml#L53-L55

  ldc-bootstrap:
source: https://github.com/ldc-developers/ldc.git
source-tag: v0.17.3

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

Re: build.snapcraft.io and GitHub groups

[Joseph Rushton Wakeling]

On 18/03/17 02:42, Colin Watson wrote:

As others have mentioned, this is definitely in our backlog.  It's
tricky to map the different models together in a way that doesn't end up
locking people out just because (e.g.) a previous administrator of their
GitHub organisation once created a snap for a repository and later
deleted it, but I'm sure we'll get there in the end.


That's great to hear.  I have things set up with Launchpad for now in any case 
(which was a super-friendly experience).


My builds seem to have run into git-clone issues related to my using `git://` 
urls instead of `https://`, but that should be straightforward enough to fix in 
the snap package definition ;-)



(We actually don't intentionally ask for organisation access at the
moment; I guess perhaps GitHub does that as part of admin:repo_hook?
Anyway, it's immaterial since we'll need it eventually.)


Yes, I would guess that GitHub defaults to offering hooks into everything a user 
can access with the option to exclude certain groups from the offering.



The "Create a new snap package" page in Launchpad allows you to select
an owner for the snap, which can be yourself or any team you're a member
of.  This will allow anyone in that team to modify that snap in
Launchpad (including requesting builds of it).

You still need to authorise this for upload to the snap store on behalf
of an individual user, though: the store doesn't have an equivalent of
organisations.  It's possible (though I don't know the exact details) to
add other team members as collaborators, allowing them to publish new
versions of that snap too.


Yes, this is the approach I took, although it would be great at some point if 
snap packages in the store could have actual team ownership.


Minor usability note on that: I added my 'regular' user account as a 
collaborator on the ldc2 snap, but have never uploaded using that account.  The 
snap store insisted that I add a 'unique short namespace' to my account details 
and I was worried that would be used for the published snap instead of that of 
the account that really owns the package.


Thanks & best wishes,

-- Joe

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

Re: build.snapcraft.io and GitHub groups

[Joseph Rushton Wakeling]

On 18/03/17 01:29, Mark Shuttleworth wrote:

On 17/03/17 16:49, Joseph Rushton Wakeling wrote:

... but is it possible to do this via a project registered on behalf
of a team, instead of an individual user account?


It *should* be, so if it isn't, thanks for the bug report :)


It's all working fine AFAICT, with the new ldc-developers team and a couple of 
snap package builds in the pipeline :-)



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

build.snapcraft.io and GitHub groups

[Joseph Rushton Wakeling]

Hello all,

I thought I'd give build.snapcraft.io a go for my ldc2 snap.  Signing in was 
fine, and I was asked to give permission both for accessing my account and the 
ldc-developers group which I'm part of (where the ldc2 snap is managed).


However, when being asked to choose a GitHub repo, I was presented only with 
repos from my own personal GitHub, and none belonging to ldc-developers -- so I 
couldn't add the official repo of the ldc2 snap.


This was a little bit surprising given that I was explicitly asked to OK access 
by build.snapcraft.io to the ldc-developers group, so ... any chance this could 
be addressed? :-)


Assuming it might not be soon, I assume the best option would be to use 
Launchpad as documented here:

https://snapcraft.io/docs/build-snaps/ci-integration

... but is it possible to do this via a project registered on behalf of a team, 
instead of an individual user account?


Thanks & best wishes,

-- Joe

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

Status of snapd on Arch Linux

[Joseph Rushton Wakeling]

Hello folks,

Is there anyone here working on snapd on Arch?

I ask because I recently tried it out on a fresh Arch install and ran into some 
issues.


Installing snaps works fine in itself, and snap list is able to find the 
installed snaps.  However, these issues arose as soon as I started trying to use 
them:


  * snap --version lists 'unknown' for snap, snapd and arch

  * all snap-related stuff is placed in /var/lib/snapd/snap instead of /snap
(fine in itself), but the PATH still contains /snap/bin rather than
/var/lib/snapd/snap/bin.

  - according to https://wiki.archlinux.org/index.php/Snapd#Installing,
installing a snap should cause it to be mounted to /snap/snapname
but this doesn't appear to be happening

  * installing my ldc2 snap (`snap install --classic --candidate ldc2`) worked
fine (it shows up in `snap list` as expected) but if I try to run
/var/lib/snapd/snap/bin/ldc2 directly I get an error message:

execv failed: No such file or directory

  * attempting to run the actual underlying binary within the snap, i.e.
/var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other binaries
there) results in a similar error message:

-bash: ./ldc2: No such file or directory

Running `file ldc2` on the binary reveals what I would assume is correct 
information:


ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically
linked, interpreter /snap/core/current/lib/x86_64-linux/gnu/ld-2.23.so,
for GNU/Linux 2.6.32, BuildID[sha1]=[I'm not typing this out], not
stripped, with debug_info

... and uname -m gives x86_64, so I don't think it can be an issue like trying 
to run a 32-bit package on a 64-bit system (or vice versa).


For comparison I tried installing both hello-world and Michael Hudson-Doyle's go 
snap.  hello-world ran fine (but it is after all only a shell script 
underneath).  The go snap ran into the same issues as my ldc2 snap.


I assume these are known issues, but can anyone advise on what are the 
fundamental problems here and on whether it's expected to be addressed soon?


Thanks & best wishes,

-- Joe

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

Removing an unreleased package revision

[Joseph Rushton Wakeling]

Hello folks,

Is there a mechanism for removing an unreleased package revision from the store? 
 I'd like to get rid of revision 7 of the ldc2 snap, which has some issues on 
16.10 that make it unsuitable for release (even to the Edge channel).


Thanks & best wishes,

-- Joe

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

Re: Further ABI-related issues for ldc2 snap on 14.04 ... ?

[Joseph Rushton Wakeling]

On 05/03/17 14:10, Sergio Schvezov wrote:

I think you have come to a cross roads where you will need to choose to either
always use the linker from the core snap and link to things from your snap or
provide multiple zlib targets for different versions of glibc (or any other
library you want to link with and provide it in your snap).

If you are going to have things like
/snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0 you would certainly want
to use the linker in core. If you are going to use /usr/bin/gcc you probably
shouldn't include libraries from `/snap/...`.

I am sorry that I cannot help you more without deep diving into your project.


First off, no need for apologies.  This is obviously quite an esoteric issue, 
and I shared it more with the thought that it might be interesting than with any 
expectation that anyone would be able to help.  You've already been super 
generous with your time and support!


I'm not sure I follow what you mean by "use the linker from the core snap". 
AFAICS the core snap doesn't contain ld or gcc or any toolchain ... ?


If you mean when building the contents of the snap, I'm just doing a regular 
`snapcraft cleanbuild`, no special magic to select particular gcc or binutils 
versions.



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

Re: Snap refresh or new install stuck at 'Run configure hook of "core" snap if present'

[Joseph Rushton Wakeling]

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.



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

Creating and running tests for a snapcraft plugin

[Joseph Rushton Wakeling]

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

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

Further ABI-related issues for ldc2 snap on 14.04 ... ?

[Joseph Rushton Wakeling]

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

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

Re: Position-independent code and Ubuntu 16.10

[Joseph Rushton Wakeling]

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!


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

Re: Position-independent code and Ubuntu 16.10

[Joseph Rushton Wakeling]

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



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

Re: Position-independent code and Ubuntu 16.10

[Joseph Rushton Wakeling]

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.


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

Position-independent code and Ubuntu 16.10

[Joseph Rushton Wakeling]

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

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

Re: Determining the set of snapd capabilities

[Joseph Rushton Wakeling]

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.


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

Re: Determining the set of snapd capabilities

[Joseph Rushton Wakeling]

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

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

Re: LDC compiler snap issues on 14.04 (ABI compatibility?)

[Joseph Rushton Wakeling]

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

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

Re: snapcraft 2.27 has been released

[Joseph Rushton Wakeling]

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


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

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: pro tip: use scriptlets instead of custom plugins

[Joseph Rushton Wakeling]

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


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

Re: LDC compiler snap issues on 14.04 (ABI compatibility?)

[Joseph Rushton Wakeling]

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.00] Linux version 4.4.0-62-generic (buildd@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@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: LDC compiler snap issues on 14.04 (ABI compatibility?)

[Joseph Rushton Wakeling]

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.00] Linux version 4.4.0-62-generic (buildd@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]



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

Re: LDC compiler snap issues on 14.04 (ABI compatibility?)

[Joseph Rushton Wakeling]

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.00] Linux version 4.4.0-62-generic (buildd@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


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

Re: LDC compiler snap issues on 14.04 (ABI compatibility?)

[Joseph Rushton Wakeling]

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.


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

Re: snapd available in Trusty Tahr

[Joseph Rushton Wakeling]

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!

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

Re: launchpad snap recipe fails with classic confinement

[Joseph Rushton Wakeling]

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 :-)


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

Re: license.txt and snap/ directory

[Joseph Rushton Wakeling]

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 :-)


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

Re: license.txt and snap/ directory

[Joseph Rushton Wakeling]

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?



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

Re: license.txt and snap/ directory

[Joseph Rushton Wakeling]

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

Re: license.txt and snap/ directory

[Joseph Rushton Wakeling]

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.


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

license.txt and snap/ directory

[Joseph Rushton Wakeling]

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?


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

Re: snapcraft 2.26 has been released

[Joseph Rushton Wakeling]

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.



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

Re: snapcraft 2.26 has been released

[Joseph Rushton Wakeling]

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?


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

Re: Using docker for clean builds of classic snaps

[Joseph Rushton Wakeling]

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
snap2.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

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

Re: Using docker for clean builds of classic snaps

[Joseph Rushton Wakeling]

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

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

Re: snapcraft 2.26 has been released

[Joseph Rushton Wakeling]

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

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

Re: Using docker for clean builds of classic snaps

[Joseph Rushton Wakeling]

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']




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

Re: snapd available in Trusty Tahr

[Joseph Rushton Wakeling]

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?

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

Using docker for clean builds of classic snaps

[Joseph Rushton Wakeling]

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

LDC snap published in edge channel

[Joseph Rushton Wakeling]

On 26/01/17 22:04, Joseph Rushton Wakeling wrote:

Just to follow up on this: the LDC devs have agreed to allow me to move forward
with this in the name of the project.  The new git repo is available at:
https://github.com/ldc-developers/ldc2.snap


The snap packaged passed manual review today, so earlier this evening I 
published it to the edge channel (accessing the developer site from an Ubuntu 
phone, appropriately enough:-).


It should be possible to install with:

sudo snap install --edge --classic ldc2

Would be really grateful if anyone would be prepared to try it out and confirm 
that it works for them (especially people using snapd on non-Ubuntu distros). 
If you need inspiration for some D code to write, you could play with some of 
the examples available at https://dlang.org/ :-)


Thanks very much to everyone who gave so much generous advice and support to 
help me get this package ready.


Best wishes,

-- Joe

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

Re: Classic confinement success for LDC D compiler

[Joseph Rushton Wakeling]

On 26/01/17 23:31, Bret A. Barker wrote:

We just added a feature to notify us on new name requests and it caught me 
before EOD.


Well, thank you VERY much.  Your advice and support has been great.


You should be good to go now, but please reach out here or in the #snapcraft 
channel if you need any further assistance with releasing the snap.


Yes, all looks good.  Everything is uploaded and just awaiting manual review.


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

Re: Classic confinement success for LDC D compiler

[Joseph Rushton Wakeling]

On 26/01/17 23:04, Joseph Rushton Wakeling wrote:

The `ldc2` name is apparently reserved (I requested it); if I temporarily choose
a different name, will I wind up with the issue of all my programs being called
something like my-temporary-snap-name.ldc2 etc.?


... no need: permission was granted VERY quickly.  I don't know if anyone acted 
to reserve the name anticipating my submission, but if so, thank you :-)


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

Re: Classic confinement success for LDC D compiler

[Joseph Rushton Wakeling]

On 20/01/17 13:58, Mark Shuttleworth wrote:

Congrats! What's the best way to get the D community aware of this?
Sounds like it would be a nice way for them to keep up to date.


Just to follow up on this: the LDC devs have agreed to allow me to move forward 
with this in the name of the project.  The new git repo is available at:

https://github.com/ldc-developers/ldc2.snap

Question about setting up a developer account to start publishing: is it 
possible to create a 'group' account with multiple members to act in the name of 
the LDC project?  Or should I just create a single developer account and add the 
email addresses of others who are interested in having account access?


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

Version numbers for snap packages

[Joseph Rushton Wakeling]

Hello all,

Quick question about version numbering (as in, the `version:` field of 
`snapcraft.yaml`).  The logical choice here is to use the version of the app 
being packaged, but what's the recommended way to handle changes to the snap 
package alone that don't change the version of the underlying app?


Is a scheme like x.y.z-n advisable (where n is the revision number of the snap 
itself for this version of the app), or are there alternative suggestions?


More generally, what are recommended practices for setting the `version:` field 
of snap packages?


Thanks & best wishes,

-- Joe

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

Snap install apparmor error: 'profile has merged rule with conflicting x modifiers'

[Joseph Rushton Wakeling]

Hello folks,

With my LDC snap seemingly sorted, I'm now turning attention to my snap for the 
DUB build system:

https://github.com/WebDrake/dub.snap/pull/1/files

I've been able to get this to build as a classic snap with minimal tweaks (just 
switching `strict` => `classic` confinement and adding


stage-packages:
- libconfig9
- libphobos2-ldc68

... to the `ldc` part.

All builds fine, but when I try to install with

sudo snap install --classic --dangerous dub_1.1.1_amd64.snap

I get an error message:

---
error: cannot perform the following tasks:
- Setup snap "dub" (unset) security profiles (cannot setup apparmor for snap 
"dub": cannot load apparmor profile "snap.dub.dub": cannot load apparmor 
profile: exit status 1

apparmor_parser output:
profile has merged rule with conflicting x modifiers
ERROR processing regexs for profile snap.dub.dub, failed to load
)
- Setup snap "dub" (unset) security profiles (cannot load apparmor profile 
"snap.dub.dub": cannot load apparmor profile: exit status 1

apparmor_parser output:
profile has merged rule with conflicting x modifiers
ERROR processing regexs for profile snap.dub.dub, failed to load
)
---

Can anyone suggest what could be wrong here?  The package builds and installs 
fine with `strict` confinement.


Thanks & best wishes,

-- Joe

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

Re: Classic confinement success for LDC D compiler

[Joseph Rushton Wakeling]

On 20/01/17 13:58, Mark Shuttleworth wrote:

Congrats! What's the best way to get the D community aware of this?
Sounds like it would be a nice way for them to keep up to date.


Thanks Mark :-)

I'm going to be in touch with the LDC devs directly in the next days (they know 
me, and they have known that I'm working on this for some time).  I'm going to 
ask them to take a glance over things as they stand and to see whether we can 
make this an official package of the LDC project from the start.


Once something is in the devel or edge channels of the snap store, and it seems 
to be working OK, I'm going to make a more public announcement to the D 
community (and I'll try to also blog about the experience).


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

Classic confinement success for LDC D compiler

[Joseph Rushton Wakeling]

On 13/01/17 21:46, Joseph Rushton Wakeling wrote:

Hearing about classic confinement was rather exciting given that it seems
tailor-made for the use-cases of my current WiP snaps for the ldc2 D compiler
and the dub D build system:
https://github.com/WebDrake/ldc2.snap/pull/1
https://github.com/WebDrake/dub.snap/pull/1


Just to follow up on this: after everyone's help in this thread, I was able to 
adjust the design of my package for the D compiler `ldc2`:

https://github.com/WebDrake/ldc2.snap/pull/2

As far as I can tell, this fixes all the major issues with the original snap 
package.


The `dub` package manager snap will follow some time soon now I've got the hang 
of things ;-)


Thanks very much to everyone who offered advice and support.

Best wishes,

-- Joe

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

Re: Classic confinement and core_dynamic_linker

[Joseph Rushton Wakeling]

On 18/01/17 13:12, Sergio Schvezov wrote:

After a quick but thorough conversation with Gustavo we agreed that this is the 
wrong path to take as it might not be deterministic or people might get 
surprised about things included that shouldn't have been.

There needs to be a clear line between `build-packages` and `stage-packages`. 
With that in mind snapcraft (even for `strict` snaps) will still crawl all the 
libraries and error on missing ones with a list of those that are missing. This 
should be something one can disable and set to ignore as some of the missing 
libraries might be provided by a content interface slot from another snap.


Well, I'm glad that my question may have led to a more rigorous and consistent 
definition of desired snapcraft behaviour, even if it means a slightly longer 
snapcraft.yaml ... :-)


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

Re: Classic confinement and core_dynamic_linker

[Joseph Rushton Wakeling]

On 18/01/17 02:21, Sergio Schvezov wrote:

The logic is still run, but the resulting binary in classic uses rpath and no 
dynamic loading so there is no resolution to a on-system library we can pick 
up. I guess we can do some magic, but it feels it might be either fragile or 
make the build process a lot slower. We will need to look into it, but not 
short term.


OK -- thanks for the explanation.  Completely understand the preference to 
require explicit staging of packages over potentially fragile automation.


Anyway, I had a go at tweaking my snap package as defined here:
https://github.com/WebDrake/ldc2.snap/pull/1/files
https://github.com/WebDrake/ldc2.snap/blob/a437ec17d50bdd767febebf5b617d7d3a716716b/snapcraft.yaml

... to use `classic` confinement and staging packages necessary for linking. 
I've posted the resulting `snapcraft.yaml` below.  The major diff apart from the 
`confinement` setting is the addition of these lines to the `ldc` part of the file:


stage-packages:
- libconfig++-dev
- libphobos2-ldc-dev

When I run `snapcraft build`, however, everything builds and links fine, but 
_nothing_ gets staged (the `stage/` and `prime/` directories both remain empty). 
 I've tried the same thing while removing the `gcc`, `gcc-wrapper`, `libc6` and 
`libc6-dev` parts, with the same result.


Any thoughts on what could be the problem here?


--- snapcraft.yaml --

name: ldc2
version: "1.1.0-beta6"
summary: D compiler with LLVM backend
description: |
LDC is a portable compiler for the D programming Language, with
modern optimization and code generation capabilities.  It uses
the official DMD compiler frontend to support the latest version
of D2, and uses the LLVM Core libraries for code generation.
confinement: classic
grade: devel

apps:
  ldc2:
command: ldc2
plugs: [home]
  ldmd2:
command: ldmd2
plugs: [home]
  ldc-profdata:
command: ldc-profdata
plugs: [home]

parts:
  ldc:
source: git://github.com/ldc-developers/ldc.git
source-tag: v1.1.0-beta6
plugin: cmake
stage:
- -etc/ldc2.conf
build-packages:
- build-essential
- ldc
- llvm-dev
- libconfig++-dev
- libedit-dev
- zlib1g-dev
stage-packages:
- libconfig++-dev
- libphobos2-ldc-dev
  ldc-config:
plugin: dump
source: ldc-config
organize:
  ldc2.conf: etc/ldc2.conf

  gcc:
plugin: nil
stage-packages: [gcc]
organize:
  usr/bin/gcc: usr/bin/gcc.real
  gcc-wrapper:
plugin: dump
source: gcc-wrapper
organize:
  gcc.wrapper: usr/bin/gcc
  libc6:
plugin: nil
stage-packages: [libc6]
  libc6-dev:
plugin: nil
stage-packages: [libc6-dev]

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

Re: Classic confinement and core_dynamic_linker

[Joseph Rushton Wakeling]

On 17/01/17 22:22, Sergio Schvezov wrote:

For classic confined snaps to link, they either need to be part of core or 
staged into your snap. On system libraries are ignored completely to ensure you 
have a working snap in the end.


Is that a work in progress constraint, or is it the intended long term 
behaviour?  (I'll try it out shortly in any case.)


I ask because currently, if a package is explicitly stated as a build 
dependency, then with `strict` confinement it's automatically included in the 
final snap where necessary.  What makes `classic` confinement unable to 
automatically handle the inclusion of build dependencies in the same way?


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

Re: Classic confinement and core_dynamic_linker

[Joseph Rushton Wakeling]

On 13/01/17 23:18, Kyle Fazzari wrote:

Since you're using cleanbuild, you would actually need the core snap
installed in the lxc container being used, which I don't think is
currently possible in lxc (though maybe it is nowadays, I know work was
being done in that area).

Have you tried _not_ doing this in cleanbuild, on a system with the core
snap installed?


Ah, thanks.  I did consider that but thought it would be a bit odd for a new 
feature to come without a cleanbuild of it being possible.


Anyway, doing a regular `snapcraft build` means the `core_dynamic_linker` error 
vanishes, but this time I get linker errors when building LDC:


   error while loading shared libraries: libconfig.so.9: cannot open shared
   object file: No such file or directory

`libconfig++-dev` and `libconfig-dev` are both installed along with their 
dependencies (libconfig++-dev is specified as a build dependency), and I _don't_ 
get this linker error when confinement is set to `strict`.


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

Classic confinement and core_dynamic_linker

[Joseph Rushton Wakeling]

Hello all,

Hearing about classic confinement was rather exciting given that it seems 
tailor-made for the use-cases of my current WiP snaps for the ldc2 D compiler 
and the dub D build system:

https://github.com/WebDrake/ldc2.snap/pull/1
https://github.com/WebDrake/dub.snap/pull/1

However, I'm running into difficulties every time I try to do a `snapcraft 
cleanbuild`: part-way through the build process I invariably get an error:


classic confinement requires the core_dynamic_linker to be set

I've discovered and tried the proposed workaround here:
https://bugs.launchpad.net/snapcraft/+bug/1650946/comments/11

... but it seems to make no difference.  Can anyone advise what else needs to be 
done to build a package with `classic` confinement?


My system is Ubuntu 16.04 with snapcraft 2.24 and snapd 2.20.1 (both installed 
from the normal Ubuntu apt repos).


Thanks & best wishes,

-- Joe

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

Re: Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

On 14/11/16 10:27, Didier Roche wrote:

I guess for now, the compiler part (and access to system libraries)
should be part of an interface. I'm CCing Jamie to see if he has any
thoughts on that.


Yes, that makes sense -- probably two different interfaces ... ?  I know that 
access to system libraries is a known issue in terms of defining an interface 
(this was discussed earlier when I was attempting to snap-package LDC, the 
LLVM-based D compiler).


I'm happy to have a go at defining an interface that would allow access to a D 
compiler, if someone can offer basic guidance as to what would be involved. 
(Ideally, such an interface would offer access both to snap-packaged D compilers 
and any D compilers installed on the host system.)


Thanks & best wishes,

-- Joe


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

Re: Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

On 03/11/16 12:08, Jamie Bennett wrote:



Regards,
Jamie.


... I guess an email got lost there? :-)  Thanks in any case for taking the time 
to look at my questions.



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

Re: Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

On 01/11/16 22:43, Sergio Schvezov wrote:

If this is x86_64, everything is aligned with the world, syscall 92 is chown. A
useful tool here can help you out, and luckily there is one, run `snap install
snappy-debug` and it will do some nice things to figure out what is going on wth
these apparmor and seccomp blockers.


Cheers, I'll try that out.  Will probably be a little while before I follow up 
-- I'm going to be away from computer for the next couple of weeks.



If this is the problem and you can patch the software then removing the chown
could work, I am CCing Jamie for other ideas that could come up.


In principle might be possible.

Thanks very much for the help & advice :-)


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

Re: Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

On 27/10/16 22:13, Joseph Rushton Wakeling wrote:

On 27/10/16 08:37, Didier Roche wrote:

I would look at /var/log/syslogs. Apparmor and seccomp denials are
listed there. Note that if you didn't already, you should really start
developping your snap in devmode. That way, it will get confinment out
of the equasion to get your relocatable code and dependencies working.
Then, we can turn on confinement and figure out those issues to be able
to publish in the stable channel.


Yea, I probably should have started with devmode.  Thanks for the advice about
syslogs; I'll check it out and see what I can find.


OK, so it looks like apparmor was indeed responsible.  The loglines in question:

Oct 30 17:50:50 computername kernel: [ 9532.992875] audit: type=1400 
audit(1477846250.853:43): apparmor="DENIED" operation="link" 
profile="snap.dub.dub" 
name="/home/username/code/D/dgraph/build/dgraph_graphtest" pid=22464 comm="dub" 
requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 
target="/home/username/code/D/dgraph/.dub/build/application-debug-linux.posix-x86_64-ldc_0-B7AFC7F4AA486AA98C5445F91F5653DB/dgraph_graphtest"
Oct 30 17:50:50 computername kernel: [ 9533.035303] audit: type=1326 
audit(1477846250.897:44): auid=4294967295 uid=1000 gid=1000 ses=4294967295 
pid=22464 comm="dub" exe="/snap/dub/x1/bin/dub" sig=31 arch=c03e syscall=92 
compat=0 ip=0x7f9b72d13717 code=0x0


I'm not experienced with apparmor, so could someone explain exactly what this 
means?  (I get the general idea, but the specifics would be useful to understand 
precisely.)


In particular, is there an obvious reason why this might be showing up with the 
dub snap, when the earlier ldc2 snap didn't have this problem?  I would guess 
because the ldc2 instance used by the snap-packaged dub is internal to the snap 
and does not benefit from the home-directory interface that dub itself gets?


Setting the containment to devmode removes the problem, but it would be nice to 
be able to have strict confinement earlier rather than later.


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

Re: Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

On 27/10/16 10:27, Didier Roche wrote:

Just a note: after a quick double checking , the snapcraft go plugin
relies on ubuntu packages (I think it should rather download latest
stable go and use GOROOT to use it). This isn't the case for other
plugins like nodejs which was the one I had in mind and I still think
you should prefer that road.


In principle that should be possible, as there are precompiled downloads of dub 
available here: https://code.dlang.org/download  Using these could have some 
advantages, including allowing the user of the plugin to specify the exact 
version of dub they want to build with.


Since there are different Linux downloads for x86, x86-64 and ARM, is there any 
way for the snapcract plugin to detect what the host system is and download 
accordingly ... ?


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

Re: Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

On 27/10/16 08:37, Didier Roche wrote:

It would be great to have D support! Thanks for working on that :)


Great to hear :-)

Just to be clear, it's already in principle possible to package D applications 
as snaps; DUB support isn't needed, but is very helpful, because a lot of D 
projects do use it.



I'm going to try to answer to some of your questions, but I'm sure
Sergio (CCed) would be able to give deeper insights on some parts as
being the snapcraft upstream.


Thanks very much.  I'll respond to some of your suggestions below ...


I would really advise going the build.sh route. Doing a custom snapcraft
plugin as you started is definitively the right path.


Yes, agreed.  I was curious about the `build.sh` option not because I think it's 
a good idea, but because I was thinking: "What if it was the only build option 
for this project?"  I'd like to know how to handle that situation if I ever 
encounter it in another project.



From your questions and the statement that there is no explicit install
steps, I think you mean that D programs just build in tree (snapcraft
tries to encourage builds out of trees) and then, the install step for
people is to copy the resulting binaries and assets manually?


Yes, exactly.  It's not _entirely_ as bad as it sounds because each project's 
`dub.json` config file can define a `targetPath` variable where built programs 
will be placed.  The plugin can use that if available.



If so, I can see 2 paths here:
- either you expect people to explicitely list assets and binaries that
should be installed (this could again be a custom option of your plugin)


This is pretty much the direction I've taken for now.


- either you try to be starter, as you told, and detect extra files
being created in the parts//build. There is no built-in
features in snapcraft for this as far as I know, but, it would be quite
easy to build it as part of your plugin: list at the start of the build
phase files in parts//build and redo the same thing after the
build. Then, in the install phase, use that list (that you store on
disk) to copy newly created content in parts//install. Then,
snapcraft will pick it up from there. Note that I think you still need a
manual options for your users to list eventual assets (or they can use
the dump plugin in another part).


Nice thought.  I'll try to look into that.

There is a 3rd option which could be for the plugin to read the `dub.json` 
config file of the project being built, and parse that to discover the targets 
that will be built, but honestly that feels like duplication of effort, and it 
would probably be better to encourage the DUB developers to provide an `install` 
option.



If you prefer to copy everything and have your users filtering from the
stage area to the prime area, you can use the "snap:" stenza (don't use
filesets for now if you don't plan to repeat the file list name).


Yup, this is the option I use now.


I would advise in a first step to consider the D compiler used by DUB to
build other things to be part of your snap. You want to control the
version in it and consider it as part of your dependencies you need in
your snap. We can discuss later about an interface, but I would really
go that way as a first step.


Yup, bundling the compiler into the snap is the way I have gone as a first step.

However, the real issue is that DUB is supposed to provide the user with the 
option to choose the D compiler to use.  It's tolerable as a first step to just 
give one option bundled, but ideally the user would be able to invoke DUB and 
specify to it any compiler they like -- whether a snap-packaged one, or one 
installed on the host system.


I was assuming that allowing the user to (optionally) specify a compiler of 
choice via an interface would be easier to achieve, but I don't know if that's true.



There is no way right now on definining new interfaces apart from
building them in snapd, and so, use your own local version. (That's the
reason why I advise you to not bother with this right now, let's take an
easier path first, figure the rest, and then, we can rediscuss)


Well, I already took the easier path, so that's why I raised the discussion of 
alternatives ... :-)



I would look at /var/log/syslogs. Apparmor and seccomp denials are
listed there. Note that if you didn't already, you should really start
developping your snap in devmode. That way, it will get confinment out
of the equasion to get your relocatable code and dependencies working.
Then, we can turn on confinement and figure out those issues to be able
to publish in the stable channel.


Yea, I probably should have started with devmode.  Thanks for the advice about 
syslogs; I'll check it out and see what I can find.



Don't make your snap calling other snap endpoints. It's better from your
own snap code to ensure that your local ldc2 is in your snap $PATH, and
call ldc2 directly (it will then use the parent process confinment
profile, of course). I think 

Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

Hello folks,

Following my attempt to create a snap for LDC (LLVM-based compiler for the D 
programming language), I thought I'd have a go at another D-related project and 
snap DUB.  This is a package/build manager that's popular in the D community, 
and so having it available as a snap could be very useful.


First caveats: this is a command-line developer tool, so some of the same 
limitations are going to apply as were identified with the LDC snap (access to 
system tools, linking against host-system development libraries, etc.).  I also 
had to take some temporary shortcuts to ensure that the packaged DUB had a D 
compiler available.


The draft package is available here:
https://github.com/WebDrake/dub.snap/pull/1/files

A few things on what went into it, and corresponding requests for feedback.

First: DUB can be built two ways; either by calling a shell script, `build.sh`, 
or by DUB itself via an existing install.  I couldn't identify an obvious way to 
handle the former, so (given that DUB is packaged in Ubuntu 16.04) I opted to 
create a `dub.py` snapcraft plugin.


I'm not a Pythonist myself, so any feedback on that code would be welcome.  But 
I have a couple of other questions:


  * Is there any way for the plugin to ask for a `dub` instance to be available?
Currently I'm just specifying `dub` as a build dependency in addition to the
plugin.

  * Assuming I'd wanted to go the `build.sh` route, is there any way I could
have achieved that with existing plugins?

DUB doesn't have an `install` option, only a `build` one, which creates some 
problems in terms of determining what files go into the snap.  I compromised on 
a short term workaround where the plugin copies everything in the `build/` dir 
of the part being built, and the user is expected to manually specify what bits 
of that should actually wind up in the final snap.  If there is a target path 
where the built files are placed, the plugin can handle that, too.


Two questions there, too:

  * Is there any way to filter that stuff out already at the staging area
or earlier?  I tried using `filesets:` but didn't have much luck.

  * Is there any way to detect what extra files have been created after the
build completes and just use those?

Since DUB needs a D compiler to be able to build anything, I first tried to just 
use the existing Ubuntu `ldc` package, and then reverted to copying the entirety 
of my LDC snap setup because it proved simpler to get working.  That's very much 
a temporary measure, I hope, but again, questions here:


  * Is there any way for me to give the DUB snap access to the ldc2 and/or
ldmd2 installed in my LDC snap package, other than explicitly defining a
`d-compiler` interface and submitting it to `snapd`?

  * Is there any way of defining/using/testing an interface short of building
my own local snapd?

The last issue is a bit weird: DUB installed by the current snap package can 
build D projects, but exits with an error: "Bad System Call".  It's been 
difficult to track down what was going on here (`strace dub build` for example 
was not very edifying, presumably because of the containerization) so any advice 
on how to identify what's wrong?


At a guess, it's related to the step where the built binaries are made 
executable, because they get created, but are _not_ executable at the end of the 
process.  This is a bit of a surprise, because the standalone LDC snap doesn't 
have this issue (things get made executable just fine).


I did try making ldc2 and ldmd2 apps of the DUB snap too, but that seemed to 
make no difference.  OTOH that might be related to how the snap-packaged DUB 
would invoke the D compiler (because presumably you'd need to call `dub.ldc2` in 
order to ensure that you get the `home` plug working properly, while DUB 
probably calls `ldc2` directly).  Anyway, any thoughts on what could be going on 
here?


Thanks in advance for any advice or thoughts, and best wishes,

-- Joe

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

Re: Access to other commands

[Joseph Rushton Wakeling]

On 15/09/16 14:12, Mark Shuttleworth wrote:

On 15/09/16 05:00, Zygmunt Krynicki wrote:

As discussed a few times this is technically challenging to do.

All of “classic” is visible from /var/lib/snapd/hostfs/ but there is no 
guarantee that you can run them in any way. They may require the classic 
dynamic linker, the classic runtime libraries and the classic filesystem layout 
that are all lost when snap-confine sets up the execution environment. If 
there’s desire to run executables from the outside we could look for solutions 
but this is not as simple as “just use devmode”


I think this is a topic for the next snapfest community event, in
October/November. Call it "snapping CLI utilities".


Is this going to be an online or face-to-face event?  This  seems like something 
I ought to not miss ... :-)



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

Re: Working LDC snap [was: Re: Snapping LDC (LLVM-based D compiler)]

[Joseph Rushton Wakeling]

On 05/09/16 00:25, Joseph Rushton Wakeling wrote:

One problem fixed (the inclusion of `build-essential` as a build dependency
ensures the snap will build in a `cleanbuild` environment), but one remains: it
looks like the `ldc-config` part (which manually replaces the incorrectly
auto-generated ldc2.conf with a correct alternative, using the `dump` plugin)
can sometimes fail.

There doesn't seem to be any reason for it, just with some builds I end up with
a wrong (auto-generated) ldc2.conf in the snap package, and some I end up with
the correct one copied from the ldc-config directory.

Any ideas what's up?  I'm guessing bug either with the dump plugin or with the
handling of the `snap` section of the `ldc` part ... ?


Looks like it because of only filtering out the ldc part's etc/ldc2.conf file at 
the `snap` step.  This allowed a race condition where if ldc was staged after 
ldc-config, its etc/ldc2.conf would overwrite the desired one, and the `snap` 
filter was powerless to distinguish this.


Replacing the `snap` exclusion filter with a `stage` exclusion filter solved 
things:

parts:
  ldc:
source: git://github.com/ldc-developers/ldc.git
source-tag: v1.0.0
plugin: cmake
stage:
- -etc/ldc2.conf
build-packages:
- build-essential
- ldc
- llvm-dev
- libconfig++-dev
- libcurl4-gnutls-dev
- libedit-dev
- zlib1g-dev
  ldc-config:
plugin: dump
source: ldc-config
organize:
  ldc2.conf: etc/ldc2.conf



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

Re: DEPRECATED: 'license' defined in snapcraft.yaml

[Joseph Rushton Wakeling]

On 05/09/16 13:03, Jamie Bennett wrote:

License files can be copied across if they are present in the setup/
directory. Reproduced from docs/meta.md

"
## Fixed assets

Some metadata is provided in the form of conventions, such as license files,
icons and desktop files among others. For these fixed files to make it into
your final snap they need to be in a `setup` directory at the same level of
your `snapcraft.yaml`.
"


Thanks!  I've fixed my snap accordingly.


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

(Not entirely) working LDC snap

[Joseph Rushton Wakeling]

On 04/09/16 13:55, Joseph Rushton Wakeling wrote:

On 27/08/16 22:45, Joseph Rushton Wakeling wrote:

I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the
D programming language.


A "final first draft" of the working snap is available here:
https://github.com/WebDrake/ldc2.snap/pull/1


So, you'd think I'd have tested this before, given that I'm trying to snap a 
compiler, but ... :-P


Turns out the snap-packaged LDC will fail if it's trying to compile a project 
that needs other libraries to be linked in.  This isn't surprising, of course -- 
system libraries won't be on the library paths of the snap -- but it does put in 
place a BIG constraint on what can be built and what not.


Any thoughts on how this might be addressed?

Thanks & best wishes,

-- Joe

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

Re: Working LDC snap [was: Re: Snapping LDC (LLVM-based D compiler)]

[Joseph Rushton Wakeling]

On 04/09/16 13:55, Joseph Rushton Wakeling wrote:

On 27/08/16 22:45, Joseph Rushton Wakeling wrote:

I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the
D programming language.


A "final first draft" of the working snap is available here:
https://github.com/WebDrake/ldc2.snap/pull/1


One problem fixed (the inclusion of `build-essential` as a build dependency 
ensures the snap will build in a `cleanbuild` environment), but one remains: it 
looks like the `ldc-config` part (which manually replaces the incorrectly 
auto-generated ldc2.conf with a correct alternative, using the `dump` plugin) 
can sometimes fail.


There doesn't seem to be any reason for it, just with some builds I end up with 
a wrong (auto-generated) ldc2.conf in the snap package, and some I end up with 
the correct one copied from the ldc-config directory.


Any ideas what's up?  I'm guessing bug either with the dump plugin or with the 
handling of the `snap` section of the `ldc` part ... ?


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

Working LDC snap [was: Re: Snapping LDC (LLVM-based D compiler)]

[Joseph Rushton Wakeling]

On 27/08/16 22:45, Joseph Rushton Wakeling wrote:

I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the
D programming language.


A "final first draft" of the working snap is available here:
https://github.com/WebDrake/ldc2.snap/pull/1

Obviously everyone here has already been very generous with their advice and 
feedback, but I thought it would be good to offer an opportunity for final 
comments before finishing this up.  Thoughts as ever gratefully received :-)


Thanks again to everyone & best wishes,

-- Joe


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

Re: Snapping LDC (LLVM-based D compiler)

[Joseph Rushton Wakeling]

On 27.08.2016 22:45, Joseph Rushton Wakeling wrote:

I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the
D programming language.  I recognize that snapping a compiler might be jumping
ahead of the current intended use-case(s), but it's fun to see what could be
possible -- and besides, D's compilers are updated fairly often, so it would be
great to be able to package them easily in a truly cross-distro form.


OK, a certain amount of wailing and gnashing of teeth later (and following some 
great help here and from the LDC devs -- big thanks to all!), I have a 
provisional first working setup (as in, at least, "Works For Me").


First, here's my snapcraft.yaml:
https://gist.github.com/WebDrake/6ad7e5fe48abc999460cb67a31972afe

So, put this in a working directory, and run `snapcraft stage`.

Now edit stage/etc/ldc2.conf and replace it with this:
https://gist.github.com/WebDrake/65cb3aaa355ea325af98d58f8ca52e3f

... and run `snapcraft prime`.

Now create a file `prime/bin/gcc.wrapper` with the following contents:
https://gist.github.com/WebDrake/0081628d70b61e271006c9b8fa3454ef

(This is basically the command-gcc.wrapper that would be generated if I were 
exposing the gcc command outside the snap, but minus the path-related stuff that 
I presume is the objectionable part of using that wrapper.)


Now run `snapcraft snap` to finish things up, install, and ... voilà, a working 
LDC snap.


So, with something provisionally working, questions:

  * anything obvious that I could do better in the general setup?

  * is there any way to automate some of the stages of the above,
e.g. the editing of stage/etc/ldc2.conf or the generation of
prime/bin/gcc.wrapper ... ?

For the second point, obviously I could create a makefile or other script to run 
things, but I wondered if there was any support in snapcraft itself for running 
simple post-stage or post-prime hooks ... ?


Thanks again and best wishes,

-- Joe

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

Re: Snapping LDC (LLVM-based D compiler)

[Joseph Rushton Wakeling]

On 01.09.2016 23:18, Sergio Schvezov wrote:



El 01/09/16 a las 18:06, Joseph Rushton Wakeling escribió:

On 31.08.2016 21:35, Joseph Rushton Wakeling wrote:

First things first, run `snapcraft stage`.  Then edit the auto-generated
stage/etc/ldc2.conf and replace it with this:
https://gist.github.com/WebDrake/229645efeca14fa54b0b1c82bcbb6477

... which as you can see includes a compiler flag: `-gcc=ldc2.gcc`.  This should
ensure that ldc2.gcc is called when LDC wants to call GCC.


OK, I think I have tied down why this is failing.

Under the hood, LDC does a lookup of the full path to the executable whose
name is passed via the -gcc flag, using llvm::sys::findProgramByName to do
so.  If it doesn't get a result, it first tries to look up CC, and if that
fails, it reverts to looking up the path for gcc.

This would suggest that, running within the snap, LDC is not able to find the
path to ldc2.gcc.

I've also tried passing it -gcc=%%ldcbinarypath%%/../command-gcc.wrapper and
also -gcc=/snap/ldc2/x1/command-gcc.wrapper and in both cases it still fails.


Actually, turns out I was completely wrong in the comments above: putting

-gcc=%%ldcbinarypath%%/../command-gcc.wrapper

... _does_ work; it was failing because I'd manually included an extra -gcc= 
flag in the snapcraft.yaml for the ldc2 and ldmd2 commands.  With that fixed, 
all is good.


But that brings us to ...


Please don't use the wrapper :-)


Well, I didn't _want_ to; it was something I tried as an experiment to see what 
would happen, and it's the first setup that has worked.


BTW what is problematic about using that wrapper in this way?  Just to make sure 
I understand.



Any reason why you don't just set it to gcc? If gcc is inside the snap, it
should be in the PATH. To experiment simply run:


Yea, the problem is not gcc being in the path, but the --sysroot of gcc being 
correct.  With the default gcc being called, the LDC build process falls over 
something like this (LDC's verbose output of its gcc call):


/snap/ldc2/x1/usr/bin/gcc hello.o -o hello -L/snap/ldc2/x1/bin/../lib 
-lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64
/snap/ldc2/x1/usr/bin/ld: cannot find 
/usr/lib/x86_64-linux-gnu/libpthread_nonshared.a

collect2: error: ld returned 1 exit status
Error: /snap/ldc2/x1/usr/bin/gcc failed with status: 1

So, gcc needs to be wrapped with something that adds the --sysroot=$SNAP option.

I'll try now to create such a minimal wrapper.

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

Re: Snapping LDC (LLVM-based D compiler)

[Joseph Rushton Wakeling]

On 31.08.2016 21:35, Joseph Rushton Wakeling wrote:

First things first, run `snapcraft stage`.  Then edit the auto-generated
stage/etc/ldc2.conf and replace it with this:
https://gist.github.com/WebDrake/229645efeca14fa54b0b1c82bcbb6477

... which as you can see includes a compiler flag: `-gcc=ldc2.gcc`.  This should
ensure that ldc2.gcc is called when LDC wants to call GCC.


OK, I think I have tied down why this is failing.

Under the hood, LDC does a lookup of the full path to the executable whose name 
is passed via the -gcc flag, using llvm::sys::findProgramByName to do so.  If it 
doesn't get a result, it first tries to look up CC, and if that fails, it 
reverts to looking up the path for gcc.


This would suggest that, running within the snap, LDC is not able to find the 
path to ldc2.gcc.


I've also tried passing it -gcc=%%ldcbinarypath%%/../command-gcc.wrapper and 
also -gcc=/snap/ldc2/x1/command-gcc.wrapper and in both cases it still fails. 
The weird thing is that the latter works when it's passed manually:


ldc2.ldmd2 -gcc=/snap/ldc2/x1/command-gcc.wrapper hello.d

... but not when it's included in the etc/ldc2.conf file.

This would suggest that something about the snap container is preventing LDC 
from resolving the path correctly.  Can anyone more experienced with snappy 
containment advise what could be going on 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: Snapping LDC (LLVM-based D compiler)

[Joseph Rushton Wakeling]

On 29.08.2016 03:38, Andrew Wilkins wrote:

I've been looking into doing this too, for llgo (Go compiler frontend for LLVM).


Nice! :-)


You need libc6-dev also. After including that, I was then met with another
issue: libc.so is a linker script, and that uses absolute paths to point at the
real libraries. I haven't solved that yet. If it's possible to override files in
a staged package, you could just provide a replacement linker script.


Yea, including libc6-dev gets me to the point where attempting to build a 
program fails with:


cannot find /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a

... which I presume is down to the linker script expecting the absolute paths 
you describe.


I already edit some stuff after the stage -- my current process is to type 
`snapcraft stage`, and after that completes, editing files in the `stage/` 
directory, followed by `snapcraft snap` to finish it up.


So, in principle it should be possible to edit the stuff in 
stage/usr/lib/x86_64-linux-gnu to change the paths.  (I guess it'll need to be 
more than just libc.so though; I'd guess libm.so and libpthread.so will also 
need to be tweaked.)


It's a bit late at night for me to start work on it now and I probably won't 
have time tomorrow, but I'll give it a go some time this week.  If you get to it 
before me and it works for you, let me know!


Thanks & best wishes,

-- Joe

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

Re: Snapping LDC (LLVM-based D compiler)

[Joseph Rushton Wakeling]

On 28.08.2016 18:28, Mark Shuttleworth wrote:

Try $SNAP for the location of the snap root, and there are a few others
like $SNAP_DATA and $SNAP_COMMON and $SNAP_USER_DATA and
$SNAP_USER_COMMON which are writable directories (the COMMON ones are
unversioned the others get snapshotted on update). The snap also get its
own /tmp directory.


I found a different solution courtesy of LDC itself: it supports a wildcard 
%%ldcbinarypath%% that can be inserted into paths in the ldc2.conf file.


It's easy to handle this manually -- just `snapcraft stage`, a quick 
search'n'replace in stage/etc/ldc2.conf, and then `snapcraft snap` to finish 
things up -- but is there any way to insert some sort of end-of-stage hook to do 
this automatically?  Being able to trigger a simple `sed` call would be enough, 
I'd have thought.


I can always provide a Makefile that carries out the stages, but it'd be nice if 
it was possible to just specify this from within snapcraft.yaml.



Yes you can arrange for the snap to see stuff from the rest of the
world, but the more of that you have, the more you burden the user to
get all those bits in place. I would explore the bundling option and see
how that pans out. It doesn't look like it's particularly large. And
we're adding delta updates so even if it is quite large it will only
affect update sizes when it changes.


OK, makes sense.  According to the LDC devs:

You need a GCC-compatible linker driver, which links in the C
standard libraries. (The latter is the reason why (g)cc is used
instead of ld.) You might need to pull in the full GCC package
if there is no other way to depend on a C toolchain.

... which is a bit 'ouch', but seems like a viable enough starting point.

Just to make sure I don't head off in completely the wrong direction, is there a 
straightforward (or at least, advisable) way to include gcc and the C standard 
libraries in a snap, perhaps deriving from existing Ubuntu packages?  I imagine 
this doesn't have a ready solution yet, but just to make sure...


Thanks again & best wishes,

-- Joe

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