Re: Status of snapd on Arch Linux

[Gustavo Niemeyer]

Ah, please don't worry then!

Thanks for the report. We'll get this sorted out and get back to you.




On Mon, Mar 20, 2017 at 7:41 PM, Joseph Rushton Wakeling <
joseph.wakel...@webdrake.net> wrote:

> On 20/03/17 23:14, Gustavo Niemeyer wrote:
>
>> Most likely the snap was partly configured to run elsewhere, but not
>> entirely.
>>
>> We really need to have someone looking into this package, preferably just
>> restoring the standard /snap path.
>>
>> Can you rebuild the package and try that out?  Would be a nice data point.
>> If you can't or don't want to, that's okay. I'm sure the package
>> maintainer
>> will look into that.
>>
>
> Well, I'm not an Arch user typically; I just installed it into a VM
> (actually, my first ever Arch install) to check out whether snap packages
> I've created would work.
>
> I can try to take a look, but I'm not sure I'll get there before the
> maintainer does ;-)
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/snapcraft
>



-- 

gustavo @ http://niemeyer.net
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Status of snapd on Arch Linux

[Joseph Rushton Wakeling]

On 20/03/17 23:14, Gustavo Niemeyer wrote:

Most likely the snap was partly configured to run elsewhere, but not
entirely.

We really need to have someone looking into this package, preferably just
restoring the standard /snap path.

Can you rebuild the package and try that out?  Would be a nice data point.
If you can't or don't want to, that's okay. I'm sure the package maintainer
will look into that.


Well, I'm not an Arch user typically; I just installed it into a VM (actually, 
my first ever Arch install) to check out whether snap packages I've created 
would work.


I can try to take a look, but I'm not sure I'll get there before the maintainer 
does ;-)


--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Status of snapd on Arch Linux

[Joseph Rushton Wakeling]

On 20/03/17 21:39, Gustavo Niemeyer wrote:

  * installing my ldc2 snap (`snap install --classic --candidate ldc2`)

worked
fine (it shows up in `snap list` as expected) but if I try to run
/var/lib/snapd/snap/bin/ldc2 directly I get an error message:

execv failed: No such file or directory



What is it pointing to?


/var/lib/snapd/snap/bin/ldc2 is pointing to /usr/bin/snap (as are all the 
entries in /var/lib/snapd/snap/bin/).



  * attempting to run the actual underlying binary within the snap, i.e.

/var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other
binaries
there) results in a similar error message:

-bash: ./ldc2: No such file or directory



This was never supposed to be done. Exposed content is supposed to work as
done above.


I do recognize that, but in the circumstances I thought I'd try it to see if it 
shed any light on the situation.



Most of these issues seem to be related to the move out of /snap, perhaps
done too quickly.

I'd suggest returning /snap to its place, at least until those issues are
sorted out there.


Note that simply putting a /snap symlink to /var/lib/snapd/snap doesn't work 
(cf. my response to Sergio).


--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Setting environment variables from within snapcraft.yaml

[Joseph Rushton Wakeling]

Hello folks,

Is it possible to set environment variables to be used when creating a part of a 
snap?


I guess one could use the `prepare:` scriptlet to do something like `export 
MY_VAR=whatever` but I'd like the environment variable to be set before I even 
pull the source.  (If you're wondering why: I'm considering whether I can use 
git environment variables to work around the launchpad-buildd constraints on 
support for git:// URLs.)


I'm not seeing anything relevant in https://snapcraft.io/docs/build-snaps/parts, 
hence why I ask here.


Thanks & best wishes,

-- Joe

--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Status of snapd on Arch Linux

[Gustavo Niemeyer]

On Fri, Mar 17, 2017 at 8:32 PM, Joseph Rushton Wakeling <
joseph.wakel...@webdrake.net> wrote:

> Hello folks,
>
> Is there anyone here working on snapd on Arch?
>
> I ask because I recently tried it out on a fresh Arch install and ran into
> some issues.
>
> Installing snaps works fine in itself, and snap list is able to find the
> installed snaps.  However, these issues arose as soon as I started trying
> to use them:
>
>   * snap --version lists 'unknown' for snap, snapd and arch
>
>   * all snap-related stuff is placed in /var/lib/snapd/snap instead of
> /snap
> (fine in itself), but the PATH still contains /snap/bin rather than
> /var/lib/snapd/snap/bin.
>
>   - according to https://wiki.archlinux.org/index.php/Snapd#Installing
> ,
> installing a snap should cause it to be mounted to /snap/snapname
> but this doesn't appear to be happening
>

Looks like the package changed recently then, after the rdocumentation was
written.

Do we have details on who's done that and why?

/snap still feels so much better.

  * installing my ldc2 snap (`snap install --classic --candidate ldc2`)
> worked
> fine (it shows up in `snap list` as expected) but if I try to run
> /var/lib/snapd/snap/bin/ldc2 directly I get an error message:
>
> execv failed: No such file or directory
>

What is it pointing to?

  * attempting to run the actual underlying binary within the snap, i.e.
> /var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other
> binaries
> there) results in a similar error message:
>
> -bash: ./ldc2: No such file or directory
>

This was never supposed to be done. Exposed content is supposed to work as
done above.

Running `file ldc2` on the binary reveals what I would assume is correct
> information:
>
> ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically
> linked, interpreter /snap/core/current/lib/x86_64-linux/gnu/ld-2.23.so
> ,
> for GNU/Linux 2.6.32, BuildID[sha1]=[I'm not typing this out], not
> stripped, with debug_info
>
> ... and uname -m gives x86_64, so I don't think it can be an issue like
> trying to run a 32-bit package on a 64-bit system (or vice versa).
>
> For comparison I tried installing both hello-world and Michael
> Hudson-Doyle's go snap.  hello-world ran fine (but it is after all only a
> shell script underneath).  The go snap ran into the same issues as my ldc2
> snap.
>
> I assume these are known issues, but can anyone advise on what are the
> fundamental problems here and on whether it's expected to be addressed soon?
>

Most of these issues seem to be related to the move out of /snap, perhaps
done too quickly.

I'd suggest returning /snap to its place, at least until those issues are
sorted out there.


gustavo @ http://niemeyer.net
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Triggering CI/snap builds on changes to snapcraft parts

[Joseph Rushton Wakeling]

On 20/03/17 11:37, Evan Dandrea wrote:

Do you need better than day-level resolution? If not, I'd suggest using
Travis' cron feature to create nightly builds:
https://docs.travis-ci.com/user/cron-jobs/


Does that actually solve the problem described, though?  I ask because as Loïc 
stated it, it's one that I'm interested in too.


Suppose a security update arrives for a deb package that my snap lists as a 
build-package or a stage-package.  Ideally CI would recognize that the 
dependencies have updated since the snap was last built, build a new package, 
and auto-upload (and maybe publish) it.


Do nightly builds actually address this?  Most of the time there will be no 
changes to the dependencies, so how does one identify the times when the 
published package needs updating?



--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Status of snapd on Arch Linux

[Joseph Rushton Wakeling]

On 20/03/17 20:21, Sergio Schvezov wrote:

Does it work if you create a symlink of /var/lib/snapd/snap to /snap? One of 
the things classic confined snaps require is a fixed path to ld in core


Unfortunately not: still 'execv failed: No such file or directory' :-(

--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: udev rules

[Jamie Strandboge]

On Mon, 2017-03-20 at 14:21 +0100, Loïc Minier wrote:
> Hi!
> 
> I saw a couple of software pieces that rely on udev rules to work; I guess
> these use cases need design to be supported in snaps; I wanted to share
> some specifics below.
> 
> 1) aksusbd is a Gemalto daemon to assert presence of a license USB dongle;
> it requires USB access, and also these udev rules that call binaries on
> addition/removal of devices and create /dev symlinks:
> http://www.feflow.info/download/FEFLOW/linux/dongle-2.41/linux_dinst/hasp.rule
> s
> 
> This is a dependency of e.g. Quortus EPC (4G core network). It could be
> delivered as a part or more likely as a separate snap since Quortus can
> operate in different modes.
> 
> 2) LimeSDR is SDR hardware that comes in USB and PCI form-factor. It might
> be used from desktop apps, e.g. Gqrx is a spectrum exploration tool and
> typically a desktop app that runs as non-root. This is the set of udev
> rules that upstream recommends installing:
> https://github.com/myriadrf/LimeSuite/blob/master/udev-rules/64-limesuite.rule
> s
> 
> These two use cases (triggering commands when devices are plugged /
> unplugged and granting permissions to desktop users to a new /dev node)
> don't seem possible right now.

That's correct.

The aksusbd case seems like it could be covered by existing interface
techniques. The providing snap slots the hasp interface and that interface could
add udev rules that point to (the snappy command aliased) /snap/bin/aksusbd.
There is probably a little thought to be had there since it assumes the aksusbd
alias and that might be somewhat awkward for different slot implementations.
This would all work for gadget snaps that provide the /dev files (like with
serial-port, etc) and won't work for classic/hotplugging.

The non-root LimeSDR case is not currently handled. To me, this is clearly
another interface (eg, 'xillybus'), but we may want to change the GROUP and not
use mode 666 if someone were going to add this interface today. What is needed
to properly handle this are device acls. This is being tracked in https://bugs.l
aunchpad.net/snappy/+bug/1646144 and additional discussion in https://bugs.launc
hpad.net/snappy/+bug/1606510/comments/14 (but I don't know the priority of this
work).

>  I think the former is probably covered in
> hotplugging requirements, not sure about the latter. Perhaps I should add
> these to some existing design doc?
> 
That seems wise for both cases (though the device acls is somewhat orthogonal).
I'm not sure where the hotplugging design doc is (iirc, Gustavo may have the
details).

-- 
Jamie Strandboge | http://www.canonical.com



signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Status of snapd on Arch Linux

[Sergio Schvezov]

On Sat, 18 Mar 2017 00:32:38 +0100, Joseph Rushton Wakeling wrote:
>* installing my ldc2 snap (`snap install --classic 
> --candidate ldc2`) worked
>  fine (it shows up in `snap list` as expected) but if I try to run
>  /var/lib/snapd/snap/bin/ldc2 directly I get an error message:
>
>  execv failed: No such file or directory
>
>* attempting to run the actual underlying binary within the snap, i.e.
>  /var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other binaries
>  there) results in a similar error message:
>
>  -bash: ./ldc2: No such file or directory

Does it work if you create a symlink of /var/lib/snapd/snap to /snap? One of 
the things classic confined snaps require is a fixed path to ld in core

-- 
Sent using Dekko from my Ubuntu device

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Fotoxx snap package

[Michael Hall]

It sounds like you probably want to use the desktop-gtk3 helper part, it
will pull in all the necessary dependencies for a Gtk3 app, plus give
you a desktop-launch script that will setup any needed paths or
environment variables for your app to run.

Here's an article that explains what desktop helpers are and how to use
them:
https://insights.ubuntu.com/2016/07/06/ubuntu-app-developer-blog-announcing-new-snap-desktop-launchers/

The tl;dr is this:
1) add "after: [desktop-gtk3]" to the end of your main part
2) Change your app's command to "desktop-launch usr/bin/fotoxx"

If that doesn't fix it all for you, join us on rocket.ubuntu.com to get
realtime help in the #snapcraft channel.

Michael Hall
mhall...@ubuntu.com

On 03/18/2017 06:56 AM, Mike Cornelison wrote:
>  Apparently more complex than your tutorial. Any help on this?
> 
> Here is my .yaml file and the result when trying to execute the snap.
> 
> ---
> 
> name: fotoxx-snap
> version: '17.04'
> summary: edit photos and manage a large collection
> description: |
>  Survey a large image collection using a thumbnail browser and
> navigator.
>  etc.
> grade: devel
> confinement: devmode
> parts:
>  main:
>  source: /home2/mico/programs/fotoxx/packs/fotoxx-17.04.tar.gz
>  plugin: make
> apps:
>  fotoxx-snap:
>  command: usr/bin/fotoxx
> ---
> 
> fotoxx-17.04 
> initz. clutter and GTK ... 
> (process:4083): Gtk-WARNING **: Locale not supported by C library.
>  Using the fallback 'C' locale.
> Gtk-Message: Failed to load module "unity-gtk-module" 
> 
> (fotoxx:4083): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
> file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No
> such file or directory 
> 
> This likely means that your installation is broken.
> Try running the command
>  gdk-pixbuf-query-loaders >
> /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
> to make things work again for the time being.
> Gtk-Message: Failed to load module "canberra-gtk-module"
> Gtk-Message: Failed to load module "canberra-gtk-module" 
> 
> (fotoxx:4083): Clutter-WARNING **: Locale not supported by C library.
> Using the fallback 'C' locale. 
> 
> (fotoxx:4083): Clutter-CRITICAL **: Unable to initialize Clutter: Unable
> to initialize the Clutter backend: no available drivers found.
> fotoxx-snap $:
> 
> ---
> 
> Here are the debian package dependencies: 
> 
> Depends: libimage-exiftool-perl, libc6, libchamplain-gtk-0.12-0,
> libclutter-gtk-1.0-0
> 
> ---
> 
> Question: why not make a snap package automatically from a debian
> package?
> All the needed information is present, it seems.
> Referenced libraries can be obtained from the executable. 
> 

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Connecting snap to keyring

[Kyle Fazzari]

On 03/20/2017 08:23 AM, Jan Olszak wrote:
> Hi there!
> Is there anything like "Secret Service" interface? An interface to
> gnome-keyring or maybe any other keyring?

Not yet[1]. If you're by any chance familiar with that API, I doubt the
interface would be difficult to write.

[1]: https://bugs.launchpad.net/snapd/+bug/1653769

-- 
Kyle Fazzari (kyrofa)
Software Engineer
Canonical Ltd.
k...@canonical.com



signature.asc
Description: OpenPGP digital signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: systemd-resolved and snaps

[Kyle Fazzari]

On 02/23/2017 02:26 PM, Steve Langasek wrote:
> Hi Kyle,
> 
> On Thu, Feb 23, 2017 at 01:58:07PM -0800, Kyle Fazzari wrote:
>> Hey all.
> 
>> I've received a bug report on a snap where the user was running a 16.10
>> Server install with the snap in question, and getting DNS errors. I've
>> distilled the problem as much as I can but I cannot for the life of me
>> figure out what's happening, so I thought maybe the list could point me
>> in the right direction.
> 
>> Prerequisites
>> =
>>
>> I have a demo snap (a standalone snapcraft.yaml) that will demonstrate
>> this issue[1].
>>
>> Ubuntu 16.10 Server uses systemd-resolved, which means its
>> /etc/resolv.conf contains a single nameserver:
>>
>> nameserver 127.0.0.53
>>
>> If you have others there, comment them out for the time being.
>>
>>
>> Steps to reproduce
>> ==
>>
>> 1. Build and install the `resolved-test` snap[1]. It exposes two apps,
>> `test` (which is a python2 script uses the requests lib) and `host`
>> which is just the `host` utility from bind9-host.
>>
>> 2. With 127.0.0.53 as the only nameserver, run `resolved-test.test`.
>> Note that it fails with "Name or service not known."
> 
> acme-staging.api.letsencrypt.org is a CNAME.  You are hitting bug #1647031,
> which we encountered when trying to roll out systemd-resolved by default for
> 17.04.  This took a while to work through, but the fix has finally landed in
> zesty as of a week ago; we should now SRU the upstream change back to
> yakkety.  (We should also SRU it back to xenial, but xenial needs a more
> complete backport of fixes to resolved, not just a cherry-pick of this one
> fix.)
> 
> Dimitri, could you handle this backport to yakkety?  Since unlike the
> Desktop, Ubuntu Server does not use dnsmasq by default (which would override
> resolved), this is a rather important bug there.

Hey guys, this still seems to be an issue for Yakkety. Any idea of the
timeframe we're looking at for this SRU?

-- 
Kyle Fazzari (kyrofa)
Software Engineer
Canonical Ltd.
k...@canonical.com



signature.asc
Description: OpenPGP digital signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Connecting snap to keyring

[Jan Olszak]

Hi there!
Is there anything like "Secret Service" interface? An interface to
gnome-keyring or maybe any other keyring?


Thanks,
Jan
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Snap tracks for Kubernetes

[Daniel Manrique]

On Mon, Mar 20, 2017 at 10:45 AM, George Kraft
 wrote:
> Hey folks,
>
> We're working on a collection of snaps for Kubernetes that we'd like to
> have tracks added to:
> - kubectl
> - kube-apiserver
> - kube-controller-manager
> - kube-scheduler
> - kubelet
> - kube-proxy
> - cdk-addons
>
> All of these need tracks for 1.5, 1.6, and 1.7. Can someone create these
> for us?

Hello George,

I've created all 21 tracks (3 each for your 7 snaps). They should be
usable now. Do let me know if anything looks odd.

I can also add a "version pattern" as a mild preventive measure
against releasing a snap under the wrong track. This is a regex which
will be matched against your upload's "version" value and if it
doesn't match, releasing to that track will not be allowed. This helps
humans avoid mistakenly releasing a snap in an undesired
track/channel. Let me know if you find this useful and I can set it up
for you.

Cheers,
- Daniel

>
> Thanks!
> George
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/snapcraft

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Snap tracks for Kubernetes

[George Kraft]

Hey folks,

We're working on a collection of snaps for Kubernetes that we'd like to
have tracks added to:
- kubectl
- kube-apiserver
- kube-controller-manager
- kube-scheduler
- kubelet
- kube-proxy
- cdk-addons

All of these need tracks for 1.5, 1.6, and 1.7. Can someone create these
for us?

Thanks!
George
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

udev rules

[Loïc Minier]

Hi!

I saw a couple of software pieces that rely on udev rules to work; I guess
these use cases need design to be supported in snaps; I wanted to share
some specifics below.

1) aksusbd is a Gemalto daemon to assert presence of a license USB dongle;
it requires USB access, and also these udev rules that call binaries on
addition/removal of devices and create /dev symlinks:
http://www.feflow.info/download/FEFLOW/linux/dongle-2.41/linux_dinst/hasp.rules

This is a dependency of e.g. Quortus EPC (4G core network). It could be
delivered as a part or more likely as a separate snap since Quortus can
operate in different modes.

2) LimeSDR is SDR hardware that comes in USB and PCI form-factor. It might
be used from desktop apps, e.g. Gqrx is a spectrum exploration tool and
typically a desktop app that runs as non-root. This is the set of udev
rules that upstream recommends installing:
https://github.com/myriadrf/LimeSuite/blob/master/udev-rules/64-limesuite.rules

These two use cases (triggering commands when devices are plugged /
unplugged and granting permissions to desktop users to a new /dev node)
don't seem possible right now. I think the former is probably covered in
hotplugging requirements, not sure about the latter. Perhaps I should add
these to some existing design doc?

Thanks,
- Loïc Minier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Fotoxx snap package

[Mike Cornelison]

 Apparently more complex than your tutorial. Any help on this?

Here is my .yaml file and the result when trying to execute the snap.

---

name: fotoxx-snap
version: '17.04'
summary: edit photos and manage a large collection
description: |
 Survey a large image collection using a thumbnail browser and
navigator.
 etc.
grade: devel
confinement: devmode
parts:
 main:
 source: /home2/mico/programs/fotoxx/packs/fotoxx-17.04.tar.gz
 plugin: make
apps:
 fotoxx-snap:
 command: usr/bin/fotoxx
---

fotoxx-17.04 
initz. clutter and GTK ... 
(process:4083): Gtk-WARNING **: Locale not supported by C library.
 Using the fallback 'C' locale.
Gtk-Message: Failed to load module "unity-gtk-module" 

(fotoxx:4083): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No
such file or directory 

This likely means that your installation is broken.
Try running the command
 gdk-pixbuf-query-loaders >
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
Gtk-Message: Failed to load module "canberra-gtk-module"
Gtk-Message: Failed to load module "canberra-gtk-module" 

(fotoxx:4083): Clutter-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale. 

(fotoxx:4083): Clutter-CRITICAL **: Unable to initialize Clutter: Unable
to initialize the Clutter backend: no available drivers found.
fotoxx-snap $:

---

Here are the debian package dependencies: 

Depends: libimage-exiftool-perl, libc6, libchamplain-gtk-0.12-0,
libclutter-gtk-1.0-0

---

Question: why not make a snap package automatically from a debian
package?
All the needed information is present, it seems.
Referenced libraries can be obtained from the executable. 
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Private Placement

[Mr. Ernest Pinto]

Good day,

Welcome to our Private Placement Portfolio.

I am a Staff of a Venture Capital Firm specializing in Growth Capital 
Investments/Loans.We seek to invest in Projects with Public and Private sectors 
in a broad range of areas including Real estate, Agriculture, Energy, Oil and 
Gas, emerging markets and high-technology. Within the technology sector, the 
firm focuses on communications, software, digital content and services.

We have the capacity to invest a considerable amount of funds in any viable 
project(s) that your company requires funding for on an investment 
capacity/Loan Application. Upon the review of your company's Project Business 
Plan we shall determine on the project(s) possible funding. This will be form 
of a silent and Private Placement Investments.

Endeavor to respond promptly if the investment proposal meets your company's 
approval.

Kind Regards,
Ernest Pinto


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Netplan replug function is incompatible with ath9k_htc module

[Oliver Grawert]

hi,
On Di, 2017-03-14 at 11:29 +0100, Loïc Minier wrote:
> 
> (So you want to test an updated netplan binary.)
> 
> How can we repack a core snap with different code per netplan?

add netplan to a PPA you own ...

branch https://github.com/snapcore/core

edit the Makefile and add an entry for your PPA to teh EXTRA_PPAS
variable at "ENV" line ...

run "sudo snapcraft" in the top level of your cloned dir...

ciao
oli

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Best Practice for building modules and including them in Kernel Snap

[Oliver Grawert]

hi,
On Mi, 2017-03-15 at 12:29 -0700, Luke Williams wrote:
> Hello,
> 
> What are the best practices for building and including kernel modules
> with
> kernel snaps?
> 
> Prior to snapcraft 2.25, when building kernel snaps, the modules
> would be
> located in parts/kernel/install/lib/modules// so that if
> I
> needed to add custom modules, I could put them in this path and then
> run
> depmod -a -b parts/kernel/install/  and it would update
> the
> modules dependancies and symbols and then I could run snapcraft snap
> and
> package everything up.
> 
> Now that the modules and firmware directories fall under
> parts/kernel/install the depmod -b doesn't work anymore.
> 
> What I have done to make this work is I create a symlink to install
> as lib
> and then I can run the depmod command, then I remove the lib symlink
> and
> then run snapcraft snap and everything is good.
> 
> This seems kind of kludgy and not the right way to do this. Is there
> a
> recommended way that this should be handled?
> 
> 
i suspect the symlink is the best workaround today unless you want to
patch depmod :)

ciao
oli

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: How to convert the initrd.img during buiding the kernel snap.

[Oliver Grawert]

hi,
On Do, 2017-03-16 at 21:22 +0800, Madper Xie wrote:
> Hi all,
> 
> My u-boot do not support the format of the initrd.img. So I need to
> manually convert it via mkimage every time.
> 
> I tried to use scriptlet to convert the initrd.img file but failed.
> 
> ```
> install: |
>   mkimage -n 'RamdiskImage' -A arm -O linux -T ramdisk -C gzip -d
> initrd.img ramfs.img
>   rm initrd.img
> ```
> 
> I got:
> mkimage: Can't open initrd.img: No such file or directory
> rm: cannot remove 'initrd.img': No such file or directory
> 
> It seems the scriptlet executed before downloading the initrd.img.
> Do we have any way to run a command after downloading the initrd.img?
> 

please fix your u-boot instead, one of the required uboot config
options we have is:

#define CONFIG_SUPPORT_RAW_INITRD

in your include/configs/.h file ...

the others are:

#define CONFIG_ENV_IS_IN_FAT
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
and 
#define CONFIG_ENV_SIZESZ_128K

to make the rollback function work.

ciao
oli

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: [Dragonboard410c] Ubuntu OS Build Issues, and Support

[Oliver Grawert]

hi,
Am Montag, den 20.03.2017, 06:04 + schrieb Sunny Bhayani:
> Hi Oliver,
> 
> Thank you for your reply.
> 
> > hi,
> > the image has not properly being initialized ... else you would
> only
> > get the reboot notifications after the first upgrade of the core
> snap
> > (i.e. your root filesystem)...
> > 
> > normally a "snap list" should list the gadget (dragonboard), core
> and
> > the kernel snap (ubuntu-snapdragon-kernel) you described in your
> model
> > assertion, even before you installed anything.
> > 
> We are not getting the above three snaps listed even though we get
> through 
> the initial conf setup. So can you point to a possible error ?

yes, the broken assertion file will prevent the verification of the
snaps in the firstboot setup.
this happens during first boot way before you can interact with the
system. it will then (amongst other things) add these snaps to the
state.json file (which is why john asked for the content i guess).

> 
> We are populating the "authority-id" and "brand-id" fields in the
> json file 
> from the above link that you have mentioned i.e.
> https://myapps.developer.ubuntu.com/dev/account/
> 
> The "authority-id" field and "brand-id" is populated as "Account-Id"
> found 
> in the above link which is a 32-letter (Alpha-numeric).
> 
> Please do let us know if we are missing anything.

with that it should work if the account the assertion gets signed with
is identical to the one in the store 

> 
> Also, as you mentioned that without proper authority id and brand id
> in the 
> assertion file, initial setup (before console-conf) will not happen.
> But we are 
> able to do the initial setup (profile setup) and then we get the
> shell prompt.
> 
> So can the initial setup be done if assertion model is not correct ?

yes, this is probably a usability bug a failed firstboot configuration
should at least spill a readable error or show it failed in the
console-conf UI.

> 
> If possible, this is to request you that if you can build the xenial
> sources (branch "snapdragon")
> once and check if you are facing these errors like we are ?
> 
> We had only changed the snapcraft.yaml to get the dtb and firmware
> built.

i'm a bit short on time this week but i'll see what i can do :)

ciao
oli

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Contributing cloud parts

[Didier Roche]

Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit :

Hey,


Hey Tim,


what is the process of contributing a cloud part to 
https://wiki.ubuntu.com/snapcraft/parts (is it open for community 
contributions?)?


Are there any plans for having a real parts repository instead of a 
wiki page for cloud parts? I think something like parts.snapcraft.io 
would be pretty cool :)




There isn't any process as of now AFAIK. It is open for community 
contributions, so feel free to edit the wiki page adding your awesome 
cloud part :)
snapcraft update && snapcraft search should list your part within the 
next hour (the importer runs hourly AFAIK).


I agree some way to see/check metrics on parts popularity, getting 
user's feedback and such would be pretty cool!

Cheers,
Didier

--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft