Re: Announce: LXD available as a snap

[Stéphane Graber]

On Wed, Oct 12, 2016 at 06:49:42AM +0500, Omer Akram wrote:
> Fantastic news, I have been craving for this for a while.
> 
> I need to highlight however that on a all-snap system(tried on a RPi 2) the
> lxd group cannot be added as /etc/group is ready-only. So lxd does not work
> there currently.

Yep, that's the first bug linked in my list below.

> 
> Thanks!
> 
> On Wed, Oct 12, 2016 at 4:20 AM, Stéphane Graber 
> wrote:
> 
> > Hello,
> >
> > As of a few minutes ago, LXD is now available as a snap in the stable
> > channel.
> > This has been confirmed to work on both Ubuntu 16.04 and 16.10, provided
> > that snapd and snap-confine are perfectly up to date.
> >
> > If you want to try it, pick a machine that you're NOT using LXD on and do:
> >  - apt remove --purge lxd lxd-client
> >  - groupadd --system lxd
> >  - snap install lxd
> >  - lxd init
> >  - lxd.lxc launch ubuntu:16.04 xenial
> >
> > This will remove your existing LXD to prevent any confusion between the
> > snap and packaged version, will ensure that you have a "lxd" group on
> > your system and then install LXD. Note that the daemon can take a little
> > while to startup on first installation, so you may have to retry the
> > "lxd init" step.
> >
> > And that's it, you've got LXD running with your first container!
> >
> > The default values in lxd init will get you a ZFS backed storage and a
> > working network for your containers.
> >
> > Our channel setup looks something like:
> >  - stable (manual, latest release)
> >  - candidate (semi-automatic, staging area for stable)
> >  - beta (manual, unused currently)
> >  - edge (automatic, auto-upload when git master changes)
> >
> > Note that edge can be updated up to 5-6 times a day (as it was today).
> >
> > Known limitations (sorted by priority):
> >  - "lxd" group must exist ahead of time: https://bugs.launchpad.net/
> > snappy/+bug/1606510
> >  - Updating the snap restarts all containers: https://bugs.launchpad.net/
> > snappy/+bug/1632508
> >  - Can't provide the "lxc" command: https://bugs.launchpad.net/
> > snappy/+bug/1607748
> >  - LXD always runs even when unused: https://bugs.launchpad.net/
> > snappy/+bug/1612440
> >  - No powerpc build due to lack of snapcraft support:
> > https://bugs.launchpad.net/snapcraft/+bug/1632091
> >  - Unable to build using a specific commit: https://bugs.launchpad.net/
> > snapcraft/+bug/1632126
> >  - Ability to distribute multiple upstream series:
> > https://bugs.launchpad.net/snappy/+bug/1611424
> >
> > The LXD team will be working with the Snappy team to address the above
> > limitations.
> > With those sorted, we'll be able to make the LXD snap the best way to
> > experience LXD.
> >
> >
> > If you run into issues, please file bugs!
> >  - For LXD bugs: https://github.com/lxc/lxd/issues
> >  - For packaging bugs: https://github.com/lxc/lxd-pkg-ubuntu/issues
> >  - If unsure, file against LXD.
> >
> > Enjoy!
> >
> > Stéphane
> >
> > --
> > Snapcraft mailing list
> > Snapcraft@lists.snapcraft.io
> > Modify settings or unsubscribe at: https://lists.ubuntu.com/
> > mailman/listinfo/snapcraft
> >
> >

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com


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: Announce: LXD available as a snap

[Omer Akram]

Fantastic news, I have been craving for this for a while.

I need to highlight however that on a all-snap system(tried on a RPi 2) the
lxd group cannot be added as /etc/group is ready-only. So lxd does not work
there currently.

Thanks!

On Wed, Oct 12, 2016 at 4:20 AM, Stéphane Graber 
wrote:

> Hello,
>
> As of a few minutes ago, LXD is now available as a snap in the stable
> channel.
> This has been confirmed to work on both Ubuntu 16.04 and 16.10, provided
> that snapd and snap-confine are perfectly up to date.
>
> If you want to try it, pick a machine that you're NOT using LXD on and do:
>  - apt remove --purge lxd lxd-client
>  - groupadd --system lxd
>  - snap install lxd
>  - lxd init
>  - lxd.lxc launch ubuntu:16.04 xenial
>
> This will remove your existing LXD to prevent any confusion between the
> snap and packaged version, will ensure that you have a "lxd" group on
> your system and then install LXD. Note that the daemon can take a little
> while to startup on first installation, so you may have to retry the
> "lxd init" step.
>
> And that's it, you've got LXD running with your first container!
>
> The default values in lxd init will get you a ZFS backed storage and a
> working network for your containers.
>
> Our channel setup looks something like:
>  - stable (manual, latest release)
>  - candidate (semi-automatic, staging area for stable)
>  - beta (manual, unused currently)
>  - edge (automatic, auto-upload when git master changes)
>
> Note that edge can be updated up to 5-6 times a day (as it was today).
>
> Known limitations (sorted by priority):
>  - "lxd" group must exist ahead of time: https://bugs.launchpad.net/
> snappy/+bug/1606510
>  - Updating the snap restarts all containers: https://bugs.launchpad.net/
> snappy/+bug/1632508
>  - Can't provide the "lxc" command: https://bugs.launchpad.net/
> snappy/+bug/1607748
>  - LXD always runs even when unused: https://bugs.launchpad.net/
> snappy/+bug/1612440
>  - No powerpc build due to lack of snapcraft support:
> https://bugs.launchpad.net/snapcraft/+bug/1632091
>  - Unable to build using a specific commit: https://bugs.launchpad.net/
> snapcraft/+bug/1632126
>  - Ability to distribute multiple upstream series:
> https://bugs.launchpad.net/snappy/+bug/1611424
>
> The LXD team will be working with the Snappy team to address the above
> limitations.
> With those sorted, we'll be able to make the LXD snap the best way to
> experience LXD.
>
>
> If you run into issues, please file bugs!
>  - For LXD bugs: https://github.com/lxc/lxd/issues
>  - For packaging bugs: https://github.com/lxc/lxd-pkg-ubuntu/issues
>  - If unsure, file against LXD.
>
> Enjoy!
>
> Stéphane
>
> --
> 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

Re: Announce: LXD available as a snap

[Michael Nelson]

On Wed, Oct 12, 2016 at 10:21 AM Stéphane Graber 
wrote:

> Hello,
>
>
>
> As of a few minutes ago, LXD is now available as a snap in the stable
> channel.
>
> This has been confirmed to work on both Ubuntu 16.04 and 16.10, provided
>
> that snapd and snap-confine are perfectly up to date.
>
>
>
> If you want to try it, pick a machine that you're NOT using LXD on and do:
>
>  - apt remove --purge lxd lxd-client
>
>  - groupadd --system lxd
>
>  - snap install lxd
>
>  - lxd init
>
>  - lxd.lxc launch ubuntu:16.04 xenial
>
>
>
> This will remove your existing LXD to prevent any confusion between the
>
> snap and packaged version, will ensure that you have a "lxd" group on
>
> your system and then install LXD. Note that the daemon can take a little
>
> while to startup on first installation, so you may have to retry the
>
> "lxd init" step.
>
>
>
> And that's it, you've got LXD running with your first container!
>

Excellent! I was just trying this from --beta yesterday but reverted to the
apt lxd package. I'll try again today :)

-Michael


>
>
>
> The default values in lxd init will get you a ZFS backed storage and a
>
> working network for your containers.
>
>
>
> Our channel setup looks something like:
>
>  - stable (manual, latest release)
>
>  - candidate (semi-automatic, staging area for stable)
>
>  - beta (manual, unused currently)
>
>  - edge (automatic, auto-upload when git master changes)
>
>
>
> Note that edge can be updated up to 5-6 times a day (as it was today).
>
>
>
> Known limitations (sorted by priority):
>
>  - "lxd" group must exist ahead of time:
> https://bugs.launchpad.net/snappy/+bug/1606510
>
>  - Updating the snap restarts all containers:
> https://bugs.launchpad.net/snappy/+bug/1632508
>
>  - Can't provide the "lxc" command:
> https://bugs.launchpad.net/snappy/+bug/1607748
>
>  - LXD always runs even when unused:
> https://bugs.launchpad.net/snappy/+bug/1612440
>
>  - No powerpc build due to lack of snapcraft support:
> https://bugs.launchpad.net/snapcraft/+bug/1632091
>
>  - Unable to build using a specific commit:
> https://bugs.launchpad.net/snapcraft/+bug/1632126
>
>  - Ability to distribute multiple upstream series:
> https://bugs.launchpad.net/snappy/+bug/1611424
>
>
>
> The LXD team will be working with the Snappy team to address the above
> limitations.
>
> With those sorted, we'll be able to make the LXD snap the best way to
> experience LXD.
>
>
>
>
>
> If you run into issues, please file bugs!
>
>  - For LXD bugs: https://github.com/lxc/lxd/issues
>
>  - For packaging bugs: https://github.com/lxc/lxd-pkg-ubuntu/issues
>
>  - If unsure, file against LXD.
>
>
>
> Enjoy!
>
>
>
> Stéphane
>
> --
>
> 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

Re: Announce: LXD available as a snap

[Manik Taneja]

Thank you Stephane and the LXD team. This is fantastic news for machine
container
aficionados. Its time to start testing this out :)

/Manik

On Tue, Oct 11, 2016 at 4:20 PM, Stéphane Graber 
wrote:

> Hello,
>
> As of a few minutes ago, LXD is now available as a snap in the stable
> channel.
> This has been confirmed to work on both Ubuntu 16.04 and 16.10, provided
> that snapd and snap-confine are perfectly up to date.
>
> If you want to try it, pick a machine that you're NOT using LXD on and do:
>  - apt remove --purge lxd lxd-client
>  - groupadd --system lxd
>  - snap install lxd
>  - lxd init
>  - lxd.lxc launch ubuntu:16.04 xenial
>
> This will remove your existing LXD to prevent any confusion between the
> snap and packaged version, will ensure that you have a "lxd" group on
> your system and then install LXD. Note that the daemon can take a little
> while to startup on first installation, so you may have to retry the
> "lxd init" step.
>
> And that's it, you've got LXD running with your first container!
>
> The default values in lxd init will get you a ZFS backed storage and a
> working network for your containers.
>
> Our channel setup looks something like:
>  - stable (manual, latest release)
>  - candidate (semi-automatic, staging area for stable)
>  - beta (manual, unused currently)
>  - edge (automatic, auto-upload when git master changes)
>
> Note that edge can be updated up to 5-6 times a day (as it was today).
>
> Known limitations (sorted by priority):
>  - "lxd" group must exist ahead of time: https://bugs.launchpad.net/
> snappy/+bug/1606510
>  - Updating the snap restarts all containers: https://bugs.launchpad.net/
> snappy/+bug/1632508
>  - Can't provide the "lxc" command: https://bugs.launchpad.net/
> snappy/+bug/1607748
>  - LXD always runs even when unused: https://bugs.launchpad.net/
> snappy/+bug/1612440
>  - No powerpc build due to lack of snapcraft support:
> https://bugs.launchpad.net/snapcraft/+bug/1632091
>  - Unable to build using a specific commit: https://bugs.launchpad.net/
> snapcraft/+bug/1632126
>  - Ability to distribute multiple upstream series:
> https://bugs.launchpad.net/snappy/+bug/1611424
>
> The LXD team will be working with the Snappy team to address the above
> limitations.
> With those sorted, we'll be able to make the LXD snap the best way to
> experience LXD.
>
>
> If you run into issues, please file bugs!
>  - For LXD bugs: https://github.com/lxc/lxd/issues
>  - For packaging bugs: https://github.com/lxc/lxd-pkg-ubuntu/issues
>  - If unsure, file against LXD.
>
> Enjoy!
>
> Stéphane
>
> --
> 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

Announce: LXD available as a snap

[Stéphane Graber]

Hello,

As of a few minutes ago, LXD is now available as a snap in the stable channel.
This has been confirmed to work on both Ubuntu 16.04 and 16.10, provided
that snapd and snap-confine are perfectly up to date.

If you want to try it, pick a machine that you're NOT using LXD on and do:
 - apt remove --purge lxd lxd-client
 - groupadd --system lxd
 - snap install lxd
 - lxd init
 - lxd.lxc launch ubuntu:16.04 xenial

This will remove your existing LXD to prevent any confusion between the
snap and packaged version, will ensure that you have a "lxd" group on
your system and then install LXD. Note that the daemon can take a little
while to startup on first installation, so you may have to retry the
"lxd init" step.

And that's it, you've got LXD running with your first container!

The default values in lxd init will get you a ZFS backed storage and a
working network for your containers.

Our channel setup looks something like:
 - stable (manual, latest release)
 - candidate (semi-automatic, staging area for stable)
 - beta (manual, unused currently)
 - edge (automatic, auto-upload when git master changes)

Note that edge can be updated up to 5-6 times a day (as it was today).

Known limitations (sorted by priority):
 - "lxd" group must exist ahead of time: 
https://bugs.launchpad.net/snappy/+bug/1606510
 - Updating the snap restarts all containers: 
https://bugs.launchpad.net/snappy/+bug/1632508
 - Can't provide the "lxc" command: 
https://bugs.launchpad.net/snappy/+bug/1607748
 - LXD always runs even when unused: 
https://bugs.launchpad.net/snappy/+bug/1612440
 - No powerpc build due to lack of snapcraft support: 
https://bugs.launchpad.net/snapcraft/+bug/1632091
 - Unable to build using a specific commit: 
https://bugs.launchpad.net/snapcraft/+bug/1632126
 - Ability to distribute multiple upstream series: 
https://bugs.launchpad.net/snappy/+bug/1611424

The LXD team will be working with the Snappy team to address the above 
limitations.
With those sorted, we'll be able to make the LXD snap the best way to 
experience LXD.


If you run into issues, please file bugs!
 - For LXD bugs: https://github.com/lxc/lxd/issues
 - For packaging bugs: https://github.com/lxc/lxd-pkg-ubuntu/issues
 - If unsure, file against LXD.

Enjoy!

Stéphane


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 sources

[Chris]

On Tue, 2016-10-11 at 14:30 +, Wes Mason wrote:
> On Tue, 11 Oct 2016 at 15:24 Chris  wrote:
> > On Tue, 2016-10-11 at 09:56 +0200, Didier Roche wrote:
> > 
> > > Le 10/10/2016 à 23:45, Chris a écrit :
> > 
> > > >
> > 
> > > > Other than those shown here - https://uappexplorer.com/apps?typ
> > e=sn
> > 
> > > > appy
> > 
> > > > =title are there other places to get Snaps from?
> > 
> > > >
> > 
> > > Actually, there is now!
> > 
> > >
> > 
> > > If you use the beta3 images, they come with snapweb baked in
> > 
> > > (listening
> > 
> > > on port 4200). You can connect to it, click on "store" and you
> > will
> > 
> > > see
> > 
> > > the available snaps for your architecture!
> > 
> > >
> > 
> > > You should be able to install it as well on your desktop system.
> > 
> > >
> > 
> > > Didier
> > 
> > >
> > 
> > Hmm, everything was going really well until I ran the command
> > 
> > 
> > 
> > chris@localhost:~/GO_PROJECTS/src/github.com/snapcore$ git clone gi
> > t@gi
> > 
> > thub.com:snapcore/snapweb.git
> > 
> > Cloning into 'snapweb'...
> > 
> > Permission denied (publickey).
> > 
> > fatal: Could not read from remote repository.
> > 
> > 
> > 
> > Please make sure you have the correct access rights
> > 
> > and the repository exists.
> > 
> > 
> > 
> > Not sure what I should be do now.
> > 
> > 
> > 
> > Chris
> > 
> > 
> > 
> Try: sudo snap install snapweb
> 
> What Didier meant is beta3  of Ubuntu Core ships with snapweb baked
> in, but your desktop you can install it as a snap (but of course!) :-
> )
> 
> btw - the git error you got is because git was trying to use your SSH
> keys to authenticate to github over the git protocol, but you may not
> have a github account of keys setup etc., you can try the HTTPS
> endpoint instead: git clone https://github.com/snapcore/snapweb.git -
> but as you just wanted to install snapweb to play around with, I
> wouldn't bother, just try out the snap.

Odd because I did setup a github account and added my gpg key. I should
have asked earlier before I went through adding other software such as
Go and others. The link http://localhost:4200/store works fine for me.
I'll stick with that for now.

Thanks
Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
10:55:13 up 17:05, 1 user, load average: 0.14, 0.36, 0.29
Ubuntu 16.04.1 LTS, kernel 4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 
UTC 2016


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

Re: Snap sources

[Jamie Bennett]

Try the https interface which would be:

git clone https://github.com/snapcore/snapweb.git

Regards,
Jamie.

On Tue, Oct 11, 2016 at 3:23 PM, Chris  wrote:
> On Tue, 2016-10-11 at 09:56 +0200, Didier Roche wrote:
>> Le 10/10/2016 à 23:45, Chris a écrit :
>> >
>> > Other than those shown here - https://uappexplorer.com/apps?type=sn
>> > appy
>> > =title are there other places to get Snaps from?
>> >
>> Actually, there is now!
>>
>> If you use the beta3 images, they come with snapweb baked in
>> (listening
>> on port 4200). You can connect to it, click on "store" and you will
>> see
>> the available snaps for your architecture!
>>
>> You should be able to install it as well on your desktop system.
>>
>> Didier
>>
> Hmm, everything was going really well until I ran the command
>
> chris@localhost:~/GO_PROJECTS/src/github.com/snapcore$ git clone git@gi
> thub.com:snapcore/snapweb.git
> Cloning into 'snapweb'...
> Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> Not sure what I should be do now.
>
> Chris
>
> --
> Chris
> KeyID 0xE372A7DA98E6705C
> 31.11972; -97.90167 (Elev. 1092 ft)
> 09:19:10 up 15:29, 1 user, load average: 0.38, 0.32, 0.36
> Ubuntu 16.04.1 LTS, kernel 4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 
> UTC 2016
>
>
> --
> 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

Re: Snap sources

[Chris]

On Tue, 2016-10-11 at 09:56 +0200, Didier Roche wrote:
> Le 10/10/2016 à 23:45, Chris a écrit :
> > 
> > Other than those shown here - https://uappexplorer.com/apps?type=sn
> > appy
> > =title are there other places to get Snaps from?
> > 
> Actually, there is now!
> 
> If you use the beta3 images, they come with snapweb baked in
> (listening
> on port 4200). You can connect to it, click on "store" and you will
> see
> the available snaps for your architecture!
> 
> You should be able to install it as well on your desktop system.
> 
> Didier
> 
Hmm, everything was going really well until I ran the command

chris@localhost:~/GO_PROJECTS/src/github.com/snapcore$ git clone git@gi
thub.com:snapcore/snapweb.git
Cloning into 'snapweb'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Not sure what I should be do now.

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
09:19:10 up 15:29, 1 user, load average: 0.38, 0.32, 0.36
Ubuntu 16.04.1 LTS, kernel 4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 
UTC 2016


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

How to control order of daemon starts in a snap

[Till Kamppeter]

Hi,

I am making a snap containing both cupsd and cups-browsed, cupsd has to 
be started first, then cups-browsed, and on shutdown cups-browsed has to 
stop before cupsd. cups-browsed needs a running cupsd all the time.


How do I define the correct startup/shutdown sequence?

Till

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

CUPS out of a snap: Filters and backends do not have access to system resources

[Till Kamppeter]

Hi,

I have snapped cups (listening on port 10631 to not interfere with the 
system's CUPS) and cups-filters into one single snap. The CUPS web 
interface (http://localhost:10631/) works, one can set up print queues, 
kill jobs, ...


Printing jobs also works, at least when there is no need to access 
certain resources. For example I can print a PDF file on USB-connected 
HP inkjet (CUPS running the job through separate filter executables for 
turning PDF into PCL).


What does not work is:

- Printing plain text files as the texttopdf CUPS filter is not able to 
access the systems TTF fonts.


- Printing to a printer in the local network via JetDirect port 9100 as 
th "socket" CUPS backend is not able to access the printer through its 
IP address.


cupsd has the following definition in snapcraft.yaml:

   cupsd:
 command: ./run-cupsd
 daemon: simple
 plugs: [network, network-bind]

Are the permissions which cupsd gets in the sandbox also applied to 
programs which CUPS is calling, as the mentioned filters and backends?


Any help is appreciated.

Till


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

Re: Different values of environment variables during build time and run time, eg. JAVA_HOME and PATH

[Sergio Schvezov]

El martes, 11 de octubre de 2016 07h'37:33 ART, Jian LUO 
 escribió:

On Oct 11, 2016 12:23, "Sergio Schvezov" 
wrote:


El martes, 11 de octubre de 2016 06h'38:49 ART, Jian LUO <

jian.luo...@gmail.com> escribió:


Hi,

Thanks for the explanation. That's exactly what comes first in my mind.
I've tried to customize the ant / jdk plugin by overriding the env

method.

The doc string of BasePlugin.env reads "return a list with the execution
environment for building". However the result env applies both to build
time and to the generated wrapper nonetheless. How can i 
override runtime

only env in the plugin?



Look at how we do it in the go plugin. That will give you anice idea.


Thanks. I'll give it a try.



With regards to a way to do it more generically we want to eventually

introduce a build-environment keyword for parts and have that carry some
weight in the chaining of parts with the `after` keyword. As an
illustration you would be able to do something like this:


parts:
   my-app:
   plugin:maven
   source: 
   after: [ibm-java]
   environment:
   - CLASSPATH:
   build-environment:
   - $ibm-java
   ibm-java:
   plugin: dump
   source: 
   build-environment:
   - JAVA_HOME: 
   - PATH:
   environment:
   - PATH:

And for apps:

apps:
   my-app:
   command: 
   environment:
   - $ibm-java
   -

Something like that. This in the design phase though. But this way you

can provide a Java to build as a part and a subsequent one to use as the
runtime.

Great! Will it be back ported to 16.04 when finished?


Indeed it will


--
Enviado con Dekko desde mi dispositivo Ubuntu

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

Re: Different values of environment variables during build time and run time, eg. JAVA_HOME and PATH

[Jian LUO]

On Oct 11, 2016 12:23, "Sergio Schvezov" 
wrote:
>
> El martes, 11 de octubre de 2016 06h'38:49 ART, Jian LUO <
jian.luo...@gmail.com> escribió:
>>
>> Hi,
>>
>> Thanks for the explanation. That's exactly what comes first in my mind.
>> I've tried to customize the ant / jdk plugin by overriding the env
method.
>> The doc string of BasePlugin.env reads "return a list with the execution
>> environment for building". However the result env applies both to build
>> time and to the generated wrapper nonetheless. How can i override runtime
>> only env in the plugin?
>
>
> Look at how we do it in the go plugin. That will give you anice idea.

Thanks. I'll give it a try.

>
> With regards to a way to do it more generically we want to eventually
introduce a build-environment keyword for parts and have that carry some
weight in the chaining of parts with the `after` keyword. As an
illustration you would be able to do something like this:
>
> parts:
>my-app:
>plugin:maven
>source: 
>after: [ibm-java]
>environment:
>- CLASSPATH:
>build-environment:
>- $ibm-java
>ibm-java:
>plugin: dump
>source: 
>build-environment:
>- JAVA_HOME: 
>- PATH:
>environment:
>- PATH:
>
> And for apps:
>
> apps:
>my-app:
>command: 
>environment:
>- $ibm-java
>-
>
> Something like that. This in the design phase though. But this way you
can provide a Java to build as a part and a subsequent one to use as the
runtime.

Great! Will it be back ported to 16.04 when finished?

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

Re: Different values of environment variables during build time and run time, eg. JAVA_HOME and PATH

[Sergio Schvezov]

El martes, 11 de octubre de 2016 06h'38:49 ART, Jian LUO 
 escribió:

Hi,

Thanks for the explanation. That's exactly what comes first in my mind.
I've tried to customize the ant / jdk plugin by overriding the env method.
The doc string of BasePlugin.env reads "return a list with the execution
environment for building". However the result env applies both to build
time and to the generated wrapper nonetheless. How can i override runtime
only env in the plugin?


Look at how we do it in the go plugin. That will give you anice idea.

With regards to a way to do it more generically we want to eventually 
introduce a build-environment keyword for parts and have that carry some 
weight in the chaining of parts with the `after` keyword. As an 
illustration you would be able to do something like this:


parts:
   my-app:
   plugin:maven
   source: 
   after: [ibm-java]
   environment:
   - CLASSPATH:
   build-environment:
   - $ibm-java
   ibm-java:
   plugin: dump
   source: 
   build-environment:
   - JAVA_HOME: 
   - PATH:
   environment:
   - PATH:

And for apps:

apps:
   my-app:
   command: 
   environment:
   - $ibm-java
   -

Something like that. This in the design phase though. But this way you can 
provide a Java to build as a part and a subsequent one to use as the 
runtime.
   



--
Enviado con Dekko desde mi dispositivo Ubuntu

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

Re: Different values of environment variables during build time and run time, eg. JAVA_HOME and PATH

[Jian LUO]

Hi,

Thanks for the explanation. That's exactly what comes first in my mind.
I've tried to customize the ant / jdk plugin by overriding the env method.
The doc string of BasePlugin.env reads "return a list with the execution
environment for building". However the result env applies both to build
time and to the generated wrapper nonetheless. How can i override runtime
only env in the plugin?

Jian

On Oct 11, 2016 09:53, "Didier Roche"  wrote:

Le 10/10/2016 à 23:49, Jian LUO a écrit :

Hi,

I don't think it counts as cross compiling since Java (at least in my case)
is cross platform. Just wanted to compile Java with one JDK and run with
another.


Hey,

I'm adding Sergio to the conversation, but I think the easiest path is to
create a custom plugin, inheriting from the base java one, which is
outputting a wrapper scripts with different JAVA env variables.
That way, you keep the current building behavior (build with java on the
machine), but output a script which will point to an armhf java path for
instance and download the correct version and packages version for all
those.
Cross-compilation-like may be needed as Manik suggested as you will need to
pull some packages which are architectures specific.

On how to create a custom plugin, here is some documentation:
http://snapcraft.io/docs/build-snaps/plugins and the playpen has some
example: https://github.com/ubuntu/snappy-playpen/blob/master/
idea/parts/plugins/x-antIntellij.py
I'll let Sergio adding more info as needed :)

Cheers,
Didier



Jian

On Oct 10, 2016 20:05, "Manik Taneja"  wrote:

>
>
> On Mon, Oct 10, 2016 at 6:33 AM, Jian LUO  wrote:
>
>> Hi List,
>>
>> Is there any formal way in snapcraft  to set environment variables
>> separately for build time and run time? The use case I'm facing is building
>> a Java snap on amd64 host for armhf target.
>>
> Snapcraft does not support cross-compilation. Consider building natively
> on armhf, or using this as reference-
>
> https://github.com/snapcore/snapd/blob/master/docs/cross-build.md
>
> and let us know if you see any issues.
>
> /Manik
>




--
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

Re: Different values of environment variables during build time and run time, eg. JAVA_HOME and PATH

[Didier Roche]

Le 10/10/2016 à 23:49, Jian LUO a écrit :
>
> Hi,
>
> I don't think it counts as cross compiling since Java (at least in my
> case) is cross platform. Just wanted to compile Java with one JDK and
> run with another.
>

Hey,

I'm adding Sergio to the conversation, but I think the easiest path is
to create a custom plugin, inheriting from the base java one, which is
outputting a wrapper scripts with different JAVA env variables.
That way, you keep the current building behavior (build with java on the
machine), but output a script which will point to an armhf java path for
instance and download the correct version and packages version for all
those.
Cross-compilation-like may be needed as Manik suggested as you will need
to pull some packages which are architectures specific.

On how to create a custom plugin, here is some documentation:
http://snapcraft.io/docs/build-snaps/plugins and the playpen has some
example:
https://github.com/ubuntu/snappy-playpen/blob/master/idea/parts/plugins/x-antIntellij.py
I'll let Sergio adding more info as needed :)

Cheers,
Didier


> Jian
>
>
> On Oct 10, 2016 20:05, "Manik Taneja"  > wrote:
>
>
>
> On Mon, Oct 10, 2016 at 6:33 AM, Jian LUO  > wrote:
>
> Hi List,
>
> Is there any formal way in snapcraft  to set environment
> variables separately for build time and run time? The use case
> I'm facing is building a Java snap on amd64 host for armhf target.
>
> Snapcraft does not support cross-compilation. Consider building
> natively on armhf, or using this as reference-
>
> https://github.com/snapcore/snapd/blob/master/docs/cross-build.md
> 
>
> and let us know if you see any issues.
>
> /Manik
>
>
>

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