Start of work: 20 April 2017 End of work: 18 May 2017
New improved and clean CLI @sergiusens Snap collaboration UX @sergiusens Asset recording @elopio snapcraft whoami @sergiusens Per project containers @kalikiana Remote per project containers @kalikiana Cross compile support for go plugin @kalikiana support for ‘branches’ in Store responses (release, close, and status) @facundobatista
snapcraft whoami
Need to increase API request limits for staging LP: #1680066 @elopio snapcraft cleanbuild fails in xenial with LXD deb ‘kernel_architecture’ LP:#1689712 @kalikiana cleanbuild fails with :ARCH in build/stage-packages LP:#1664857 @kalikiana storeapi: improve the error message for the case the Store answers an upload needs manual review @facundobatista
snapcraft snap testing @elopio snapcraft UTF-8 general fixes @elopio
init: add a newline at the end of the file LP: #1660880 @roxd replace : with _ in file names PR #1262 andyli Added link to forums in the Get in touch section PR #1268 @Ads20000 sources: add support for 7-zip files PR #1168 @tim.sueberkrueb meson plugin: Add plugin for meson build system PR #1294 JulianLiu rust snaps can now use source-subdir without failing on pull PR #1296 @roxd sources: validate unknown source-type in yaml PR #1297 EduardoVega
Instructions to test a stable release update: http://elopio.net/blog/test-sru/1
These are the tests that must pass before landing this new release in the -updates pockets of xenial, yakkety and zesty:
Plugins: Run the kernel manual tests documented in manual-tests.md. Build a snap with that uses meson.
manual-tests.md
Sources: Build a snap with a 7zip source.
Store: Run the release, close and status commands in snaps with channels.
Exploratory:
Build snaps with SNAPCRAFT_BUILD_INFO=1 Check that a snap can be build with the resulting snap/prime/snapcraft.yaml. Run all the snapcraft commands in different scenarios including failure conditions. Cleanbuild snaps with local and remote containers.
snap/prime/snapcraft.yaml
Create SRU bug LP: #1692102 Create changelog branch PR #1326 Run adt for xenial:amd64 adt log Run adt for xenial:armhf adt log Run adt for xenial:arm64 adt log Run adt for yakkety:amd64 adt log Run adt for yakkety:armhf adt log Run adt for yakkety:arm64 adt log Run adt for zesty:amd64 adt log Run adt for zesty:armhf adt log Run adt for zesty:arm64 adt log Merge changelog branch Tag the release. Write specific manual tests for the SRU dput to artful dput to zesty dput to yakkety dput to xenial contact release team to accept into -proposed Run QA over packages in -proposed Create release notes contact the release team to release into -updates update the docker image send release update notice
Particularly looking forward to these two items.
Is support for snapcraft build across architectures when classically confined also in consideration for this release? This is something that’s blocking adoption of kubernetes snaps upstream. lp:1674828
snapcraft build
This is a bug problem to solve, I thought it was easier when someone asked me about it, but they didn’t mention it was a classic snap.
classic
There are other things you can do if all you need to do is use dump, where is the snapcraft.yaml?
dump
snapcraft.yaml
You can find one of the offending snapcraft.yaml files here
There is an easier fix for this, here is an extract
name: ... architectures: [DEB_ARCH] version: 'KUBE_VERSION'
and for DEB_ARCH do something similar to what you do for KUBE_VERSION here:
DEB_ARCH
KUBE_VERSION
https://github.com/kubernetes/release/pull/293/files#diff-42a71f4b3ea56a983dfd71b43c11fdf1R30 and drop the `--target-arch`.
Is this the equivalent of all_arch? We’re dumping in different architectures each time. Are you saying that we’d just set DEB_ARCH to the arch that we were dumping in?
Yes, set DEB_ARCH to the architecture you are dumping. It is not like theArchitectureentry indebian/control`, which hints on where it is supposed to build, the snapcraft one actually sets the resulting architecture of the package to what is set in that field, given the confusion that general distro packagers have is the reason we don’t promote this feature, but it is exactly what you want; that is:
DEB_ARCH to the architecture you are dumping. It is not like the
entry in
you are not really cross compiling
@elopio I’ve been looking at libpipeline demo and we may need to consider migrating it to a different branch on launchpad.
libpipeline
@sergiusens tell me more
It is using lp:~mterry …
While reviewing and polishing PRs, we worked on a few utf-8 issues.
We have this bug: snapcraft fails if desktop file included “ascii” cannot decode byte
It highlights a few issues:
Wondering if here it shouldn’t be mentioned the work for
Or these won’t be released into 2.30?
Thanks!
Bump, could the top post please be updated with the features Facundo mentioned? they’re commits 9a2b6a7da8 and 85765674a40cb.
Hey, of course, @facundobatista’s work should be there. We are just getting used to this new workflow in the forum, and tend to leave stuff only in github.
I will add them, but note that the post is a wiki, you can all touch it.
we have begun the SRUing process. The wiki entry has been updated.
All the adt tests have passed for the changelog branch, I’ve updated them with links to the log, going to merge the branch.
Moved to Snapcraft call for testing
