Re: classic 32 bit application
On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote: > I'm trying to package a 32 bit software development environment: Pharo > Smalltalk (http://pharo.org). > > I've got it working OK as a devmode package, but as soon as I switch it > to classic confinement it fails to run. I was under the impression the usual progression is from devmode to strict. Are you certain classic is the correct direction for your snap? Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: your mail
On Tue, Mar 28, 2017 at 11:20:41AM -0600, Leo Arias wrote: > Here are the sources for the snap and CI scripts, in case you want to > verify them or build it yourself: > https://github.com/elopio/blockchain-snaps/blob/master/bitcoin/snap/snapcraft.yaml Hi Leo, it looks like you've documented this fairly well but I'm not familiar enough with the details of snap packaging to know how it actually works in practice. This might serve as a good example for the snap community: - At what point do you download the blockchain? - Where does the blockchain get stored? - How are interrupted downloads handled? - How are package upgrades handled? Is a copy of the blockchain made? - How are package downgrades handled? Is a copy of the blockchain made? - Have you run into problems moving BDB forward or backwards when upgrading or downgrading? Is BDB used in the storage of the blockchain or is it used for 'simpler' snap storage? It feels like bitcoin's 100-ish gigabyte blob makes an interesting constraint that many simpler tools may not need to address. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: clarification about review process
On Fri, Mar 24, 2017 at 05:09:28AM +, Nicolino Curalli wrote: > I want to build a CI pipeline for test my snap for the fundamental > requirements to pass the review process before uploading it on store. > Where could i find something to help me to build this pipeline? Hi Nicolino, Is this what you are looking for? https://code.launchpad.net/~store-reviewers/click-reviewers-tools/trunk Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: detect video player
On Thu, Mar 02, 2017 at 08:02:53AM +0300, Vasilisc wrote: > For example, > vlc come from snap package (location /snap/vlc/current/...), > smplayer - from deb package (location /usr/bin/smplayer). > > How to find available a video players in host system? Can you trust the PATH to be useful and just blindly call execlp() with the names of the players you support, each in turn, until you succeed or fail? Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Position-independent code and Ubuntu 16.10
On Tue, Feb 21, 2017 at 11:01:48PM +0100, Joseph Rushton Wakeling wrote: > OK, thanks for the clarification. So this raises the question ... > can/should snapcraft ensure this option is used when building snap packages? > > It's obviously not an issue for most apps, but any snap exposing a > development library in any way is presumably going to risk being unusable on > 16.10 or later if the package author doesn't realize this is necessary. Position independent executables have been supported for many years; the recent change was to make this the default output format, so that we can increase the amount of system services and programs that can benefit from the address space layout randomization exploit mitigation. Fixed-position executables continue to be supported and we have no plans to forbid them. Libraries are usually compiled as position independent code; this has not changed. As far as I know, only nginx and the linux kernel were affected by these changes. (Sorry kernel developers. I know git bisect is harder.) Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Position-independent code and Ubuntu 16.10
On Mon, Feb 20, 2017 at 10:12:25PM +0100, Joseph Rushton Wakeling wrote: > First, I'd thought that Ubuntu 16.04's GCC already generated > position-independent code by default, but was this in fact only introduced > with 16.10 ... ? Correct, this was changed for 16.10: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes#GCC Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: LDC compiler snap issues on 14.04 (ABI compatibility?)
On Fri, Feb 10, 2017 at 09:41:52PM +0100, Joseph Rushton Wakeling wrote: > Attempting to compile this program resulted in a segfault in GCC (which LDC > invokes in order to link programs). [...] > Anyway, does anyone have any thoughts? Hi Joe, can you grab the dmesg output that might include DENIED lines as well as the kernel's segfault report? This may give enough information for someone to suggest the next step. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Error to call "docker" command in a snap
On Tue, Feb 07, 2017 at 09:56:04PM -0600, Peng Liu wrote: > Yes, thanks for your reminder. I found a kernel panic! The logs are below: Thanks Peng; could you please file a bug with "ubuntu-bug linux"? (At least I think that should work.) If that doesn't work, please include at least uname -a output. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Error to call "docker" command in a snap
On Tue, Feb 07, 2017 at 09:43:38PM -0600, Peng Liu wrote: > I built a snap which needs to call "docker" command instead of using > bindings like docker-py to get logs from a container. Unfortunately, the > command reported an error with messages "support process for mount > namespace capture exited abnormally". Are there any hints in dmesg or more detailed log files that might provide a direction to start looking? Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Where to save stuff (in snap-agnostic way)
On Sat, Feb 04, 2017 at 10:33:20AM +0800, XiaoGuo Liu wrote: > liuxg@liuxg:~/snappy/desktop/ss$ hello.env | grep XDG_RUNTIME > XDG_RUNTIME_DIR=/run/user/1000/snap.hello > $ sudo snap run --shell hello.env > # env | grep XDG_RUNTIME_DIR > XDG_RUNTIME_DIR=/run/user/0/snap.hello Your first command was run as a standard user, probably the first user installed on the system, since it is user 1000. Your second command was run as root via the sudo tool, thus you get a different directory. Every user's data should be stored in a place where it won't collide with other users, and root is no different in this case. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: snapd available in Trusty Tahr
On Thu, Feb 02, 2017 at 12:51:59AM +0100, Joseph Rushton Wakeling wrote: > snapd: Depends: systemd (>= 204-5ubuntu20.20) but it is not going to be > installed Not just any systemd will do, make sure you get one with 'deputy' mentioned somewhere in the changelogs: https://bugs.launchpad.net/ubuntu/trusty/+source/systemd/+bug/1656280 Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Building snap from binaries
On Fri, Dec 23, 2016 at 03:32:19PM +, Luther Goh Lu Feng wrote: > If I am building a snap, and for some reason, I wish to not snap it from > source, but from a compiled binary, is it allowed? Thanks. Luther, it is allowed; snaps are just squashfs filesystems with some metadata in expected filenames. I've been unable to keep track of a spec for it, sorry, but if you snap up a simple tool and inspect the resulting squashfs image you'll probably learn all you need to know faster than I could find a reference. :) Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: A kernel panic issue of docker snap
On Wed, Dec 21, 2016 at 09:52:11PM -0600, Peng Liu wrote: > I found a kernel panic issue when I was using pipework to config the > network of a docker container on an x86 board with all-snap image. The > issue is related to the auditing module of Linux kernel. So it should be an > issue of pc-kernel-snap. Please file the bug against source package 'linux'. This looks vaguely related to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1508737 and: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1586997 (Your reproducer looks very different, taking a trip through AppArmor first, but it looks to me like it's the kernel trying to audit unix domain sockets that falls over, regardless of the path taken to get there.) But it's hard for me to confirm/deny this wild suspicion at this point. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Snapcraft's state tracking improvements
On Tue, Dec 13, 2016 at 01:57:20PM -0800, Kyle Fazzari wrote: > *Option 2*: Automatically take care of everything. If you modify a part > with dependencies, snapcraft will rebuild those dependencies as it sees > fit without your needing to say so. Similarly, if you clean a part with This options feels most likely to lead to reliably reproducable results. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Announcing Snaplint
On Thu, Dec 08, 2016 at 10:12:58PM -0700, Spencer Parkin wrote: > proprietary. So many times I find something I think is great and I want to > use it but...oh...crap...it's GPL; can't use it. In other words, GPL is a > pain for in-house development, and it's an infectious license that spreads You should talk with your team's lawyers again; it's normally understood that the GPL's provisions on promising to provide source code for three years only applies to people to whom you distribute binaries. If you never distribute anything then you're under no obligation to provide anyone with a promise of source code for three years. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: sha3-384 mismatch
On Fri, Dec 02, 2016 at 05:50:06PM +0100, Didier Roche wrote: > However, as you can see in https://bugs.launchpad.net/bugs/1643893, I > can still reproduce pretty easily here this kind of error (nework > dropping and snapd disconnecting). While curl or wget can cope with the > download as expected. The last time I saw a Go program failing to download something from another host, and dying in the same spot repeatably, it was because the Go library authors didn't have EAGAIN (or was it EINTR?) errno handled correctly everywhere in the libraries. This was diagnosed by using 'strace' on the failing command and noticing that a read() or recv() or recvmsg() or somoething similar wasn't retried on EAGAIN. I don't know how the Go programmer in question found the corresponding Go code to manipulate but I'd start by looking for read() or recv() or recvmsg() system calls without EAGAIN error handling within two lines or something. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: snap and ssh
On Wed, Nov 23, 2016 at 02:29:12PM +0100, Didier Roche wrote: > It seems then that ssh is using hardcoded paths like /home/$USER/.ssh > for looking by default to id_rsa file and not using $HOME. Multiple ways > to get that fixed: > * reading the openssh-client code and fix it to use $HOME (and so, it > will use your snap $HOME) openssh is using the standard getpwnam() interface to retrieve home directory information: http://sources.debian.net/src/openssh/1:7.3p1-3/misc.c/#L579 openssh uses getpwnam(), getpwent(), getpwuid(), extensively. [1] Undoing this would take a lot of time. I can imagine a few ways to customize the home directory results for openssh: - Write libraries to LD_PRELOAD to intercept this family of functions and modify the results of lookups - Modify an /etc/passwd that's bind-mounted over the host's version so the standard library routines function normally - Write an NSS library that knows snappy - Ship a different ssh client that's easier to configure (really, untangling the standard unix password database from openssh looks like an extremely expensive task.) Each of these have pros and cons for different use cases. (For example, the LD_PRELOAD and NSS library choices may not even function in a statically-compiled executable, so they may have limited applicability.) Thanks 1: $ grep -rE '(getpwnam|getpwuid|getpwent|pw->)' | wc -l 350 signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Cliqz Snap
On Mon, Nov 14, 2016 at 08:13:33AM -0600, Chris wrote: > Hallo Cpollock, > > deine Anfrage hat den CLIQZ Support erreicht. Unser Ziel ist es, dir so > schnell wie möglich zu antworten. Das wird nicht allzu lange dauern, > versprochen. > > In der Zwischenzeit kannst du mal in unsere FAQs schauen: https://cliqz > .com/support > > Und kennst du schon unseren Blog? Schau mal hier: https://cliqz.com/abo > utus/blog > > Danke für deine Geduld. Wir melden uns bald wieder bei dir! > > Der CLIQZ Support Here's my shot; perhaps not idiomatic but should convey the idea well: Hello Cpollack, Your question has reached CLIQZ Support. Our goal is to answer you as quickly as possible. That will not take long, promise. In the meantime, you can look in our FAQs: https://cliqz..com/support And do you already know our blog? Look here: https://cliqz.com/aboutus/blog Thanks for your patience. We'll contact you soon! signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Problem removing a snap
On Wed, Nov 02, 2016 at 05:34:10PM -0500, Chris wrote: > chris@localhost:~$ sudo mount --bind /snap/ubuntu-core/current > /snap/viking-gps/1 > [sudo] password for chris: > mount: mount point /snap/viking-gps/1 does not exist Either a file or directory needs to exist in the filesystem for a mount to succeed; so try creating this directory and re-try? sudo mkdir -p /snap/viking-gps/1 sudo mount --bind /snap/ubuntu-core/current /snap/viking-gps/1 sudo snap remove viking-gps Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Guidance on deprecating debs for snaps
On Wed, Aug 17, 2016 at 09:28:32PM +, Marco Ceppi wrote: > Has anyone deprecated debian packages yet in favor of snaps? My end goal is > people who've installed the debian package from the xenial archive will get > an updated debian package which no longer is the software but instead > either guides them to installing the snap or installs it for them. This sounds like a surprising and inconsiderate thing to do to our users. There's probably still time to get your transitional package into yakkety before feature freeze (or file for a feature freeze exception) but once it was shipped in an LTS we've agreed to support it for five years. (Where "support" is of course variable -- for main, we support it. For universe, the community supports it and someone will sponsor updates.) Be sure to consider how 16.04 LTS -> 18.04 LTS upgrades will work. We also support LTS to LTS upgrades. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
