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
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:
Run the kernel manual tests documented in manual-tests.md.
Build a snap with that uses meson.
Build a snap with a 7zip source.
Run the release, close and status commands in snaps with channels.
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.
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
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.
There are other things you can do if all you need to do is use dump, where is the snapcraft.yaml?
You can find one of the offending snapcraft.yaml files here
There is an easier fix for this, here is an extract
and for DEB_ARCH do something similar to what you do for KUBE_VERSION here:
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
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.
@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?
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