Re: Error with Launchpad uploading 403 Client Error: Forbidden
On Wed, Apr 05, 2017 at 10:41:27PM +0200, Joseph Rushton Wakeling wrote: > 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? It's not 100% clear what's going on, but my guess is that either you haven't agreed to the developer terms and conditions (https://myapps.developer.ubuntu.com/dev/tos/) or haven't set a short namespace in your developer profile (https://myapps.developer.ubuntu.com/dev/account/) for the account that you used to authorise Launchpad to upload this snap to the store. Could you check those two things? If it's not either of those then we'll need to investigate further, probably by way of adding more logging and getting you to try again. In those two cases above, it's a bug that the error isn't presented clearly in the Launchpad UI; I don't think it's been filed, so it would be worth it for somebody affected by it to do so. -- Colin Watson [cjwat...@ubuntu.com] -- 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
On Fri, Mar 31, 2017 at 11:22:50AM +0100, Mark Shuttleworth wrote: > On 30/03/17 20:54, Sergio Schvezov wrote: > > ### sources > > > > Sources, thanks to an external contributor, can now make use of a new > > entry, `source-checksum` which can be added to sources that can be hashed, > > the format is the following: `source-checksum: /`. These > > are the supported algorithms: > > > > - `md5` > > - `sha1` > > - `sha224` > > - `sha256` > > Please cull those from the acceptable digests, they are the Fake News of > cryptographic reassurance ;) Seriously? MD5 and SHA-1 of course yes, but there's no particular evidence that SHA256 is problematic, and as yet it's far more popular as an advertised tarball hash than anything based on SHA-3 or BLAKE2. (I don't know about SHA224, but it's at least also in the SHA-2 family.) Current NIST policy recommends SHA256 as a minimum, and says "Currently there is no need to transition applications from SHA-2 to SHA-3", dated 2015-08-05 (http://csrc.nist.gov/groups/ST/hash/policy.html). Of course it's always important to retain hash algorithm agility and usually wise to prefer more recent standards in new applications, but it's IMO far too early to regard SHA256 as unacceptable. -- Colin Watson [cjwat...@ubuntu.com] -- 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
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
Re: Is there any way to choose the arch to build on build.snapcraft.io?
On Thu, Mar 02, 2017 at 11:16:56PM +0800, XiaoGuo Liu wrote: > I just tried to use build.snapcraft.io to build my application. The build > was successful. Great! > However, the app was meant for amd64. After I chose my repos, it built > for armhf and amd64 at the same time. The both versions were > published. How can I choose the arch to publish? This isn't configurable right now. We do expect to make this configurable at some point in the future once we work out the best place to do it. Both architectures being published shouldn't actually be a problem; snapd will pick the correct one when installing on a given architecture. However, if it's a serious problem for some reason then I can manually configure it for you for now; let me know. -- Colin Watson [cjwat...@ubuntu.com] -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Non-http git submodules with launchpad builders
On Sat, Feb 11, 2017 at 12:05:37PM -0600, Gregory Lutostanski wrote: > Is there any way I can let the git source from snapcraft not pull > recusively? Or might we be able to have launchpad builders have a git proxy > (perhaps via GIT_PROXY_COMMAND, like in > https://stackoverflow.com/questions/783811/getting-git-to-work-with-a-proxy-server/21136254#21136254 > ) I think it would be best to arrange for Launchpad builders to have a git proxy; you aren't the first to run into this. Could you file a bug against the launchpad-buildd project on Launchpad to remind us? Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- 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
On Thu, Feb 09, 2017 at 04:43:33PM -0300, Sergio Schvezov wrote: > El jueves, 9 de febrero de 2017 16h'23:34 ART, Colin Watson > <cjwat...@ubuntu.com> escribió: > >Oh, in fact, that looks just about perfect for us. With that patch I > >think LP could just export SNAPCRAFT_SETUP_CORE=1 when building snaps, > >right? > > Absolutely correct. If you enable this in staging I can give it some test > runs. This is on our dogfood instance now and I've been able to get a successful run out of it: https://dogfood.paddev.net/~cjwatson/+snap/helloworld-classic/+build/413 The ticket to deploy this is (internal link): https://portal.admin.canonical.com/99787 ... so I expect that this will be rolled out by the time you release snapcraft 2.27. 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
Re: launchpad snap recipe fails with classic confinement
On Thu, Feb 09, 2017 at 02:09:49PM -0300, Sergio Schvezov wrote: > El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche > <kyle.nitzs...@canonical.com> 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, This is https://bugs.launchpad.net/launchpad-buildd/+bug/1650946. I've been snowed under with another urgent snappy-related project, but I'm planning to attack this tomorrow. > snapcraft 2.27 adds the required support for a generic ci solution. > This will be released early next week. Oh, in fact, that looks just about perfect for us. With that patch I think LP could just export SNAPCRAFT_SETUP_CORE=1 when building snaps, right? -- Colin Watson [cjwat...@ubuntu.com] -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Creating system users and system groups
On Thu, Feb 02, 2017 at 10:49:13AM +, Mark Shuttleworth wrote: > Our general thinking is that we will maintain a standard list of those, > and approve user creation for specific snaps. Would you be willing to go > with _avahi and _lp and _lpadmin? Backward-looking names might get > grandfathered, but we'd prefer newer software to use a qualifier like _ > to disambiguate such system users from end users. You might like to use https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames as part of this; d-i and ubiquity both use that as a way of saying "you can't use that username because it'll conflict with well-known system users". It doubtless won't be complete (it doesn't currently contain avahi, for instance), but it should be a useful starting point. -- Colin Watson [cjwat...@ubuntu.com] -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
More flexible network access for Launchpad snap builds
Following widespread demand, Launchpad snap builds are now permitted to access the network (via a proxy) during the "build" phase as well as the "pull" phase. On general software engineering principles, it's still good practice to try to specify your network dependencies in a declarative way so that they can be fetched systematically and safely during the "pull" phase. However, for cases where that's prohibitively difficult, this change should make some categories of snaps easier to build. 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
