Re: Shared UI Themes

[Didier Roche]

Le 16/03/2017 à 18:28, Michał Sawicz a écrit :

W dniu 16.03.2017 o 17:34, Sebastien Bacher pisze:

One other issue is that snaps are per-system and theme are
per-user-session/desktop. You could have different users login into
different desktop environment on your laptop, how do we handle them
needing different themes?

Sounds like we'd need the ability to connect to multiple theme snaps and
then have the user's environment choose the right one?

Is it even possible to plug into multiple slots?


AFAIK it's not possible and my last email on the topic (which wasn't the 
first one) didn't get traction: "One snap to connect them all (or: the 
plugin story)".
You can as well have a look at 
https://bugs.launchpad.net/snapd/+bug/1655125 to subscribe and follow 
the status.


Cheers,
Didier

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

Re: How to bump ulimit?

[Jacek Nykis]

On 17/03/17 02:40, Michi Henning wrote:
> 
>> Would you mind pasting exact command that worked for you from inside a snap?
>>
>> In my case ulimit works just fine outside of confinement. For example:
>> jacek@laptop:~$ ulimit -n 10240
>> jacek@laptop:~$ ulimit -n
>> 10240
>>
>> But when I try the same when confined I can only go as high as 4096.
> 
> $ cat /proc/sys/fs/file-max
> 1624349
> $ ulimit -Hn
> 65536
> $ ulimit -Sn
> 1024
> $ ulimit -Sn 65536
> $ ulimit -Sn
> 65536
> 
> This works for me when running a confined shell:
> 
> $ snap run —shell mysnap.mycommand

Interesting. This worked for me too with snap run --shell.

I wonder if hard limit for my daemon is different than the one I get
when I snap run --shell? Anyway I'll dig a big deeper and file a bug if
needed, thanks for help.

-- 
Jacek



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

Re: Store - Organizations/Namespaces/Transfer packages

[Evan Dandrea]

On Thu, 16 Mar 2017 at 19:18 Tim Süberkrüb  wrote:

>
> > You are correct, this is the best way to handle this situation right
> > now. You can use the + trick (realaddress+al...@domain.com) in your
> > email address if you don't have a convenient one to use. Once you set it
> > up and assign collaborators, you can proceed with your regular account.
>


> Okay. I'd personally really love to see something like organization
> accounts (maybe comparable to how GitHub handles organizations) in the
> future because I think this is a common use case.
>

Hi Tim,

Good timing, we're exploring exactly this. :) There are a few options under
consideration, but all involve letting you treat organisation members as
collaborators on a snap.

Of course we'll announce it here. If you start with a developer account to
hold your organisation identity, you'll be able to transfer over when the
time comes.
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

[Dragonboard410c] Ubuntu OS Build Issues, and Support

[Sunny Bhayani]

Hi John,

Thanks you for your reply.

> I don't understand what's going on with your system:
> * snapd is running out of memory. snapd should be using about 20MB of
> resident memory. How much was it trying to use when it ran out? How
> much is available? What does dmesg say about this crash?
We are not able to reproduce this error again. If we get this error,
we will post details for this.

While doing "snap install", it gives error. But doing "snap login" again,
from the command prompt (shell), we are able to install the application
via "snap install". But this method also is not 100% successful. Sometimes
we get error.

Here is the dmesg logs for the error case: http://pastebin.com/rAa8Zvfb
The above log has two trial logs. In the First trial, we have prepared the
SDCard and have setup the first boot console config. In the Second trial,
we did "snap login".

We obsereved that whenever we do a "snap install", irrespective of it
being successful or fail, we get the below message repeatedly and the
board reboots automatically after 15-20 minutes:

"Broadcast message from root@localhost.localdomain (Thu 2017-03-16 12:31:13 
UTC):

reboot scheduled to update the system - temporarily cancel with 'sudo 
shutdown -c'
The system is going down for reboot at Thu 2017-03-16 12:39:13 UTC!"

This is how it looks like when board is automatically reboot:
http://pastebin.com/e2s6y3qc

After the reboot is done (which takes around 5 minutes), thie above reboot
message does not come.

It would be great, if you can provide any comments.

> * snapd on a core system that doesn't list any snaps makes no sense at
> all. It needs to have at least three snaps at first boot: core,
> kernel, and gadget, otherwise you wouldn't get there.

Yes snapd on a core system does not list any snaps: http://pastebin.com/rAa8Zvfb

> How are you building the image that you are booting?

Here are the steps to building Ubuntu-Core Image: http://pastebin.com/0x52ATXi

> What's in /var/lib/snapd/state.json? (don't just pastebin that file if you 
> have
> credentials in it!) What's in /snap? What's in /var/lib/snapd/seed/?
> And in seed.yaml? What's in /var/lib/snapd/snaps? What's in
> /etc/os-release?

Here we listed various snaps directory as you asked:
http://pastebin.com/DRXDvAQQ

The state.json file is at: http://pastebin.com/0KyvECtz

It would be more helpful to us if you provide some pointers.

Thank you.
Sunny
*
 eInfochips Business Disclaimer: This e-mail message and all attachments 
transmitted with it are intended solely for the use of the addressee and may 
contain legally privileged and confidential information. If the reader of this 
message is not the intended recipient, or an employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified that 
any dissemination, distribution, copying, or other use of this message or its 
attachments is strictly prohibited. If you have received this message in error, 
please notify the sender immediately by replying to this message and please 
delete it from your computer. Any views expressed in this message are those of 
the individual sender unless otherwise stated. Company has taken enough 
precautions to prevent the spread of viruses. However the company ac
 cepts no liability for any damage caused by any virus transmitted by this 
email. 
*
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Store - Organizations/Namespaces/Transfer packages

[Tim Süberkrüb]

Hey Evan,

this is fantastic (/me is also watching 
https://github.com/canonical-ols/build.snapcraft.io/issues/132) :)


Looking forward to this!

All the best,

Tim

On 17.03.2017 10:35, Evan Dandrea wrote:
On Thu, 16 Mar 2017 at 19:18 Tim Süberkrüb > wrote:



> You are correct, this is the best way to handle this situation right
> now. You can use the + trick (realaddress+al...@domain.com
) in your
> email address if you don't have a convenient one to use. Once
you set it
> up and assign collaborators, you can proceed with your regular
account.

Okay. I'd personally really love to see something like organization
accounts (maybe comparable to how GitHub handles organizations) in the
future because I think this is a common use case.


Hi Tim,

Good timing, we're exploring exactly this. :) There are a few options 
under consideration, but all involve letting you treat organisation 
members as collaborators on a snap.


Of course we'll announce it here. If you start with a developer 
account to hold your organisation identity, you'll be able to transfer 
over when the time comes.


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

Contributing cloud parts

[Tim Süberkrüb]

Hey,

what is the process of contributing a cloud part to 
https://wiki.ubuntu.com/snapcraft/parts (is it open for community 
contributions?)?


Are there any plans for having a real parts repository instead of a wiki 
page for cloud parts? I think something like parts.snapcraft.io would be 
pretty cool :)


All the best,

Tim Süberkrüb


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

Adventures in classic Python snaps, part II

[Barry Warsaw]

A few days I asked about classic snaps and problems I was having turning
ubuntu-image into a classic snap (from devmode).  For the recently released
u-i 1.0 I thought I'd solved the problem, and had an autopkgtest to prove it.
Since then I realized the problem was *not* solved and the autopkgtest had
some dependency pollution that caused it to succeed when it should have
failed.  I've fixed that, but now I'm finding that classic Python snaps don't
work -at least not in the way I'd expect.

For reference, here's a baseline snapcraft.yaml that "works":

-snip snip-
name: ubuntu-image
summary: Create Ubuntu images
description: |
  Use this tool to create Ubuntu images.
version: 1.0+snap2
grade: stable
confinement: classic

apps:
  ubuntu-image:
command: usr/bin/ubuntu-image

environment:
  PATH: $SNAP/usr/bin:$PATH

parts:
  ubuntu-image:
plugin: python
source: .
python-packages:
  - PyYAML
  - attrs
  - voluptuous
prime:
  - usr
  - lib
  - sbin
stage-packages:
  - e2fsprogs
  - mtools
  - python3-debian
  - python3-parted
  - util-linux
  - ubuntu-image
  snapd:
plugin: go
source: https://github.com/snapcore/snapd
source-type: git
go-importpath: github.com/snapcore/snapd
prime:
  - bin/snap
-snip snip-

I was pointed to LP: #1670388 which helped me understand that I have to set
$PATH (as seen in the `environment` section) so that the 'python3'  found in
the script's shebang is the one inside the snap, not the one in the system.
That's good enough to not *also* require $PYTHONPATH afaict.

This only works for Zesty; it fails in Yakkety and Xenial, presumably because
of LP: #1665756.  The bug says this is fixed in snapd 2.23, which is available
atm only in zesty, yakkety-proposed, and xenial-proposed.

There are a few other things to note.

I don't think we need the snapd part.  Isn't it guaranteed that if someone is
running a classic snap, that /usr/bin/snap *must* be installed on their
system?  It does seem to work when I remove that part, but I want to make sure
that autopktest package pollution isn't causing a false positive.

There's one big cheat here.  I had to put ubuntu-image in stage-packages
because afaict, for classic snaps, the Python snapcraft plugin does not
arrange for the ubuntu_image Python package to live in stage, and thus it
doesn't get into prime.  I don't think there's anything you could add to a
`stage` section that would make that work.  After experimenting (the
documentation is unclear) files listed in stage are relative to the part's
installation directory:

modified   snapcraft.yaml
@@ -21,6 +21,8 @@ parts:
   - PyYAML
   - attrs
   - voluptuous
+stage:
+  - stageme
 prime:
   - usr
   - lib

Staging ubuntu-image 
[Errno 2] No such file or directory: 
'/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1/parts/ubuntu-image/install/stageme'

root@autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1#
 find parts/ubuntu-image/install -name ubuntu_image
root@autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1#
 ls parts/ubuntu-image/install/usr/lib/python3/dist-packages/
chardet _ped.cpython-35m-x86_64-linux-gnu.so
chardet-2.3.0.egg-info  pkg_resources
deb822.py   pyparted-3.10.7.egg-info
debian  python_debian-0.1.30.egg-info
debian_bundle   six-1.10.0.egg-info
parted  six.py

You can see that the ubuntu_image package doesn't end up in the part's
dist-packages, and there's nothing that can be staged.

I haven't yet tried to play with scriptlets or other workaround.  Obviously,
we don't want to snap up the ubuntu-image that's in the archive, but instead
the one in the current source directory.

This seems like a bug, but I wanted to get some feedback before I filed a bug
report.

Cheers,
-Barry


pgpkrP_fVffdC.pgp
Description: OpenPGP digital signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Adventures in classic Python snaps, part II

[Sergio Schvezov]

On Fri, 17 Mar 2017 17:25:03 -0400, Barry Warsaw wrote:
> A few days I asked about classic snaps and problems I was having turning
> ubuntu-image into a classic snap (from devmode).  For the recently released
> u-i 1.0 I thought I'd solved the problem, and had an 
> autopkgtest to prove it.
> Since then I realized the problem was *not* solved and the autopkgtest had
> some dependency pollution that caused it to succeed when it should have
> failed.  I've fixed that, but now I'm finding that classic 
> Python snaps don't
> work -at least not in the way I'd expect.
>
> For reference, here's a baseline snapcraft.yaml that "works":
>
> -snip snip-
> name: ubuntu-image
> summary: Create Ubuntu images
> description: |
>   Use this tool to create Ubuntu images.
> version: 1.0+snap2
> grade: stable
> confinement: classic
>
> apps:
>   ubuntu-image:
> command: usr/bin/ubuntu-image
>
> environment:
>   PATH: $SNAP/usr/bin:$PATH
>
> parts:
>   ubuntu-image:
> plugin: python
> source: .
> python-packages:
>   - PyYAML
>   - attrs
>   - voluptuous
> prime:
>   - usr
>   - lib
>   - sbin
> stage-packages:
>   - e2fsprogs
>   - mtools
>   - python3-debian
>   - python3-parted
>   - util-linux
>   - ubuntu-image
>   snapd:
> plugin: go
> source: https://github.com/snapcore/snapd
> source-type: git
> go-importpath: github.com/snapcore/snapd
> prime:
>   - bin/snap
> -snip snip-
>
> I was pointed to LP: #1670388 which helped me understand that I have to set
> $PATH (as seen in the `environment` section) so that the 'python3'  found in
> the script's shebang is the one inside the snap, not the one in the system.
> That's good enough to not *also* require $PYTHONPATH afaict.

We have a custom sitecustomize.py that takes care of the magic now. You don't 
need to set PATH though, alternatively in command you can do

```
command: /usr/bin/env $SNAP/usr/bin/python3 $SNAP/usr/bin/ubuntu-image
```

Next week I am going to be giving the python plugin some love.

> This only works for Zesty; it fails in Yakkety and Xenial, 
> presumably because
> of LP: #1665756.  The bug says this is fixed in snapd 2.23, 
> which is available
> atm only in zesty, yakkety-proposed, and xenial-proposed.

Yes, this is the case.

> There are a few other things to note.
>
> I don't think we need the snapd part.  Isn't it guaranteed that 
> if someone is
> running a classic snap, that /usr/bin/snap *must* be installed on their
> system?  It does seem to work when I remove that part, but I 
> want to make sure
> that autopktest package pollution isn't causing a false positive.

It can be in a different path though.

> There's one big cheat here.  I had to put ubuntu-image in stage-packages
> because afaict, for classic snaps, the Python snapcraft plugin does not
> arrange for the ubuntu_image Python package to live in stage, and thus it
> doesn't get into prime.  I don't think there's anything you could add to a
> `stage` section that would make that work.  After experimenting (the
> documentation is unclear) files listed in stage are relative to the part's
> installation directory:

I don't understand this fully, but I am way past EOD so I will look with fresh 
eyes on monday, but is this exclusive to classic confinement?

> modified   snapcraft.yaml
> @@ -21,6 +21,8 @@ parts:
>- PyYAML
>- attrs
>- voluptuous
> +stage:
> +  - stageme
>  prime:
>- usr
>- lib
>
> Staging ubuntu-image 
> [Errno 2] No such file or directory: 
> '/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1/parts/ubuntu-image/install/stageme'
>
> root@autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1#
>  
> find parts/ubuntu-image/install -name ubuntu_image
> root@autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1#
>  
> ls parts/ubuntu-image/install/usr/lib/python3/dist-packages/
> chardet _ped.cpython-35m-x86_64-linux-gnu.so
> chardet-2.3.0.egg-info  pkg_resources
> deb822.py   pyparted-3.10.7.egg-info
> debian  python_debian-0.1.30.egg-info
> debian_bundle   six-1.10.0.egg-info
> parted  six.py
>
> You can see that the ubuntu_image package doesn't end up in the part's
> dist-packages, and there's nothing that can be staged.

It should end up in $SNAP/lib/site-packages if not using stage-packages.


> I haven't yet tried to play with scriptlets or other workaround.  Obviously,
> we don't want to snap up the ubuntu-image that's in the archive, but instead
> the one in the current source directory.
>
> This seems like a bug, but I wanted to get some feedback before 
> I filed a bug
> report.


-- 
Sent using Dekko from my Ubuntu device

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

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

Re: build.snapcraft.io and GitHub groups

[Mark Shuttleworth]

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

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

[Manik Taneja]

On Fri, Mar 17, 2017 at 4:49 PM, Joseph Rushton Wakeling <
joseph.wakel...@webdrake.net> wrote:

> 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?
>
Yes, OpenHAB project is doing exactly that-
https://code.launchpad.net/~openhab/openhab-snap/+git/master

Cheers,
Manik
-- 
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

[Loïc Minier]

Hi!

Support for Github orgs in build.snapcraft.io is still WIP:
https://github.com/canonical-ols/build.snapcraft.io/issues/132

Cheers,
- Loïc Minier

On Sat, Mar 18, 2017 at 12:49 AM, Joseph Rushton Wakeling <
joseph.wakel...@webdrake.net> wrote:

> 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/mailm
> an/listinfo/snapcraft
>



-- 
- Loïc
-- 
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

[Colin Watson]

On Sat, Mar 18, 2017 at 12:49:15AM +0100, Joseph Rushton Wakeling wrote:
> 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? :-)

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.

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

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

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.

Cheers,

-- 
Colin Watson   [cjwat...@ubuntu.com]

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