snapcraft:rb-snapcraft-channel

Last commit made on 2020-02-12
Get this branch:
git clone -b rb-snapcraft-channel https://git.launchpad.net/snapcraft

Branch merges

Branch information

Name:
rb-snapcraft-channel
Repository:
lp:snapcraft

Recent commits

b425808... by Chris Patterson on 2020-02-12

remote-build: introduce --launchpad-snapcraft-channel option

It may be useful to configure Launchpad to use a specific
snapcraft channel. This commit changes the default from "edge"
to "stable", and allows the user to configure it.

Signed-off-by: Chris Patterson <email address hidden>

0c425ae... by Sergio Schvezov on 2020-02-12

store: improve platform detection (#2931)

Also add support for Windows and Darwin.

Signed-off-by: Sergio Schvezov <email address hidden>

9b1655d... by Chris Patterson on 2020-02-12

plugin handler: process elf files only if base is specified (#2926)

ELF files are always processed when `type: app`, where `app`
is the default type.

This causes an issue when snapd is building without specifying
the type, as it gets treated as `type: app` and its files
are processed like typical app snaps. The schema currently
allows for this because it fails to set the default type `app`
in time for validation.

Since snapd does not have a base, check for the existence of the
base before attempting to process ELF files. This will prevent
the error reported in LP #1857019 and allow snapd to build without
a type specified.

Once snapd moves to `type: snapd`, we can fix the schema to
ensure that the invalid configuration that led to this error
does not pass verification.

Add basic snapd-like spread test `snapd-workaround` to ensure that
snapd is buildable and has the expected snap.yaml. Once snapd
migrates to `snapd` type, this test will be migrated.

LP #1857019
LP #1862642

Signed-off-by: Chris Patterson <email address hidden>

Co-authored-by: Sergio Schvezov <email address hidden>

4fc862f... by Sergio Schvezov on 2020-02-12

logging: use .warning instead of deprecated .warn (#2928)

Signed-off-by: Sergio Schvezov <email address hidden>

071ad06... by Sergio Schvezov on 2020-02-11

storeapi: remove exposure of series (#2921)

Series, mostly used with constants.DEFAULT_SERIES has been long deprecated and
has no use.

Remove its broad exposure across the code base. No great changes should be
observed aside from reworking how SnapNotFoundError is implemented by making
use of the new SnapcraftException.

Signed-off-by: Sergio Schvezov <email address hidden>

2023d76... by Chris Patterson on 2020-02-11

elf: ensure _GNU_VERSION_R section is of type GNUVerNeedSection (#2918)

If it the gnu_version_r section is not an instance of
GNUVerNeedSection, then we cannot use the iter_versions()
interface. Just ignore processing needed in those cases.

Since the section type will be "SHT_GNU_verneed" [1], we
don't have to check that it is != "SHT_NOBITS".

LP #1862318

[1] https://github.com/eliben/pyelftools/blob/46dea162e8154328d4e4c6ede630d8b235bf91f9/elftools/elf/elffile.py#L491

Signed-off-by: Chris Patterson <email address hidden>

cc40d5f... by Nick Zatkovich on 2020-02-10

sanity checks: fix expressions so Windows paths are considered (#2919)

7e64682... by Chris Patterson on 2020-02-10

meta: initialize Snap at once in from_dict() (#2920)

Instead of using key lists and __dict__, handle each field
and pass it into Snap at init. A little more verbose,
but very detailed and more flexible.

This actually will fix a case where `hooks` is defined as null,
though I do not believe it has been reported. Future work
should also add Hook.from_object() to handle the cases.

Future work should perform more type-checking on the inputs
to make sure all they types are sane, but I did not want to scope
that into this commit/PR.

Signed-off-by: Chris Patterson <email address hidden>

38928cd... by Chris Patterson on 2020-02-07

rust plugin: fetch correct (locked) crates during pull (#2917)

The previous PR was checking against the existence of the
Cargo.lock in builddir, which does not work at pull time.
So snapcraft it fetched the incorrect crate verisons at pull
time, but still built against the correct versions at build time.

Check for Cargo.lock in the source directory instead of the build
directory. This will work anytime after the rust project's sources
have been fetched.

Improve the spread test to hopefully capture this error by
ensuring that "time" is downloaded only once.

Signed-off-by: Chris Patterson <email address hidden>

af32601... by Chris Patterson on 2020-02-07

rust plugin: respect Cargo.lock if present in project (#2915)

Rust workspaces already support Cargo.lock, but standard builds
do not. If "Cargo.lock" is present, add the "--locked" flag
to `cargo fetch` and `cargo install` commands.

Add unit tests and spread test for verification.

LP #1862219

Signed-off-by: Chris Patterson <email address hidden>