Re: Improving the way we build nightly apps

[Matthias Clasen]

On Sat, Mar 4, 2017 at 9:37 PM, Bastien Nocera  wrote:

> ifests 
>
> My flatpak is too old to test. As totem has additional patches, and a
> separate json file for lua, which one of these is correct:
>
>
> JSON=flatpak/org.gnome.Totem.json
> GITURL=git://git.gnome.org/totem
>
>
This one looks right, and works in my testing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Bastien Nocera]

On Tue, 2017-02-28 at 11:44 -0500, Matthias Clasen wrote:
> So far, we have this gnome-nightly-apps repository which contains
> copies of the flatpak manifests for a bunch of gnome apps. That is
> redundant and suboptimal. Recently, flatpak has gained the ability to
> find manifests in git repositories that you point it to, and we
> should use this to move the json files to each applications git tree.
> Quite possibly there is already a copy of it there anyway.
> 
> If you want to help out with making this happen, the details are
> described here:
> 
> https://wiki.gnome.org/Initiatives/GnomeGoals/FlatpakManifests

My flatpak is too old to test. As totem has additional patches, and a
separate json file for lua, which one of these is correct:

JSON=org.gnome.Totem.json
GITURL=git://git.gnome.org/totem/flatpak

or

JSON=flatpak/org.gnome.Totem.json
GITURL=git://git.gnome.org/totem

Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Jeremy Bicha]

On Fri, Mar 3, 2017 at 8:10 AM, Adrian Perez de Castro
 wrote:
> I do not use JHBuild, as I rarely need it — and when it may be needed, it
> feels clumsy. For 99% of my needs a ~130-line shell script [1] which sets
> the environment in a way similar to how JHBuild does is enough. I do not
> mind having to manually building a coupld of dependency modules now and
> then, as for me most of the time the distribution (Arch Linux) has recent
> enough packages.

You can use 'jhbuild buildone' if you don't want to build all the dependencies.

Jeremy
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Adrian Perez de Castro]

On Wed, 01 Mar 2017 18:13:53 +, Sriram Ramkrishna  
wrote:
> On Wed, Mar 1, 2017 at 5:16 AM Michael Catanzaro 
> wrote:
> 
> > On Tue, 2017-02-28 at 15:50 -0800, Christian Hergert wrote:
> > > You make it sound like there is already unanimous support for this
> > > (considering I've seen no discussion on the topic, I find that hard
> > > to
> > > take at face value)?
> >
> >
> > release team is dealing with right now. Currently, we only maintain the
> > JHBuild modulesets, and that's not great because it's not what users
> > actually use.
>
> Users aren't using Jhbuild?  What are they using?  I'm asking because in
> our newcomer documentation we are asking them to use JHBuild.  So I'm
> trying to understand why there is a dichotomy.

I do not use JHBuild, as I rarely need it — and when it may be needed, it
feels clumsy. For 99% of my needs a ~130-line shell script [1] which sets
the environment in a way similar to how JHBuild does is enough. I do not
mind having to manually building a coupld of dependency modules now and
then, as for me most of the time the distribution (Arch Linux) has recent
enough packages.

Cheers,

---
[1] https://gist.github.com/aperezdc/6ad5937a28c04bf23750024c47438b47


pgpoS92SEnv9G.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Matthias Clasen]

On Thu, 2017-03-02 at 12:46 -0600, Michael Catanzaro wrote:
> On Thu, 2017-03-02 at 19:11 +0100, Sébastien Wilmet wrote:
> > I don't know how soon it'll be. The Flatpak manifest goal is a
> > small
> > goal (the files are even already written, it's just moving them and
> > doing small edits). If it's useful during 6 months or one year,
> > that's
> > already worthwhile. It's easy to remove the Flatpak manifests once
> > (and
> > if) BuildStream becomes the preferred way.
> 
> Yes, I think this argument is a winner. Matthias, feel free to go
> ahead
> and move it to the approved goals page. I doubt anybody will object.

Done.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Michael Catanzaro]

On Thu, 2017-03-02 at 19:11 +0100, Sébastien Wilmet wrote:
> I don't know how soon it'll be. The Flatpak manifest goal is a small
> goal (the files are even already written, it's just moving them and
> doing small edits). If it's useful during 6 months or one year,
> that's
> already worthwhile. It's easy to remove the Flatpak manifests once
> (and
> if) BuildStream becomes the preferred way.

Yes, I think this argument is a winner. Matthias, feel free to go ahead
and move it to the approved goals page. I doubt anybody will object.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Sébastien Wilmet]

On Tue, Feb 28, 2017 at 05:18:55PM -0600, Michael Catanzaro wrote:
> On Tue, 2017-02-28 at 11:44 -0500, Matthias Clasen wrote:
> > So far, we have this gnome-nightly-apps repository which contains
> > copies of the flatpak manifests for a bunch of gnome apps. That is
> > redundant and suboptimal. Recently, flatpak has gained the ability to
> > find manifests in git repositories that you point it to, and we
> > should use this to move the json files to each applications git tree.
> > Quite possibly there is already a copy of it there anyway.
> > 
> > If you want to help out with making this happen, the details are
> > described here:
> > 
> > https://wiki.gnome.org/Initiatives/GnomeGoals/FlatpakManifests
> 
> This is clearly superior to how we build the flatpaks now.
> 
> On the other hand, these manifests should hopefully be obsoleted soon
> by BuildStream.

I don't know how soon it'll be. The Flatpak manifest goal is a small
goal (the files are even already written, it's just moving them and
doing small edits). If it's useful during 6 months or one year, that's
already worthwhile. It's easy to remove the Flatpak manifests once (and
if) BuildStream becomes the preferred way.

--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Tristan Van Berkom]

On Wed, 2017-03-01 at 18:13 +, Sriram Ramkrishna wrote:
> 
> 
> On Wed, Mar 1, 2017 at 5:16 AM Michael Catanzaro  g> wrote:
> > On Tue, 2017-02-28 at 15:50 -0800, Christian Hergert wrote:
> > > You make it sound like there is already unanimous support for
> > this 
> > > (considering I've seen no discussion on the topic, I find that
> > hard
> > > to 
> > > take at face value)?
> > 
> > 
> > release team is dealing with right now. Currently, we only maintain
> > the
> > JHBuild modulesets, and that's not great because it's not what
> > users
> > actually use.
> > 
> 
> Users aren't using Jhbuild?  What are they using?  I'm asking because
> in our newcomer documentation we are asking them to use JHBuild.  So
> I'm trying to understand why there is a dichotomy.

I think what Michael is saying (correct me if I'm wrong) is that
developers (newcomers or otherwise) are using JHBuild. Users in general
use what distro packagers put together, which was not assembled with
JHBuild. Users are also going to be using Flatpaks as it becomes
available in the next/current wave of distro.

The JHBuild modulesets, besides being handy to actually build stuff, is
also the GNOME release team's method of blessing what vector of
specific package versions that are appropriate to assemble as a whole,
and I would not be surprised that distros use this metadata at least as
a guideline to build and distribute GNOME.

Cheers,
    -Tristan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Sriram Ramkrishna]

On Wed, Mar 1, 2017 at 5:16 AM Michael Catanzaro 
wrote:

> On Tue, 2017-02-28 at 15:50 -0800, Christian Hergert wrote:
> > You make it sound like there is already unanimous support for this
> > (considering I've seen no discussion on the topic, I find that hard
> > to
> > take at face value)?
>
>
> release team is dealing with right now. Currently, we only maintain the
> JHBuild modulesets, and that's not great because it's not what users
> actually use.
>
>
Users aren't using Jhbuild?  What are they using?  I'm asking because in
our newcomer documentation we are asking them to use JHBuild.  So I'm
trying to understand why there is a dichotomy.

sri
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Michael Catanzaro]

On Tue, 2017-02-28 at 15:50 -0800, Christian Hergert wrote:
> You make it sound like there is already unanimous support for this 
> (considering I've seen no discussion on the topic, I find that hard
> to 
> take at face value)?

Well indeed, nothing's decided yet. We're still in early stages here;
that public discussion needs to take place, for starters, and we need
working code that actually builds Flatpaks via BuildStream. But I'm
very, very interested in any technology that can replace JHBuild and
also the Continuous manifest and flatpak-builder JSON all at the same
time (presuming it provides a pleasant development environment
equivalent or superior to JHBuild's). Having our build definitions
fragmented in three different places is the most serious problem
release team is dealing with right now. Currently, we only maintain the
JHBuild modulesets, and that's not great because it's not what users
actually use.

I'm also not really opposed to moving the flatpak-builder JSON into
application repositories. That will help solve a big problem, which is
that it's not very well-maintained right now, because release team does
not have the resources to maintain a second set of build metadata and
flatpak-builder metadata is obviously not suitable for replacing
JHBuild. Really, I checked the stable Epiphany flatpak recently, it's
version 3.22.0 (which is vulnerable to a major security issue) and
can't display youtube.com at all for some reason. I seriously hope
nobody is using that. In contrast, application maintainers should
surely be able to maintain their own build definition for their one
module.

I guess I was just... thinking out loud about the situation. But now
seems like a good time to point out that there is serious interest in
relpacing flatpak-builder (not generally, but for building the official
GNOME Flatpaks).

Of course, we also need to make sure that BuildStream meets the needs
of other GNOME consumers, like Builder.

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Christian Hergert]

On 02/28/2017 03:18 PM, Michael Catanzaro wrote:

On the other hand, these manifests should hopefully be obsoleted soon
by BuildStream. The goal of that effort is to remove the separate
Continuous manifest, JHBuild moduleset, and flatpak nightlies repos. So
 if we implement this now, we'd be going from centralized to
decentralized and then back to centralized in the future. So I don't
know if it makes sense to do this for all modules now. But it's a small
amount of work and certainly doesn't hurt anything.


You make it sound like there is already unanimous support for this 
(considering I've seen no discussion on the topic, I find that hard to 
take at face value)?


Having configurations that are generated from meta-configurations makes 
IDE tooling a giant PITA. The .json files are our primary configuration 
format for Builder going forward.


The further we abstract from that, the more difficult we make our 
newcomer story. If they aren't in the projects git repository, this ends 
up being as bad as jhbuild today where we have to synchronize 
configuration changes between separate modules.


I really don't want to see a development workflow where after checking 
out a GNOME module we have to look up in an external system how to build 
the thing, just to have to push changes back to said system when the 
developer changes a project setting.


If we do end up with something (other than the flatpak json files) that 
end up in each projects module, then it is paramount that we have enough 
information to tie together how to configure the project, how to execute 
flatpak-builder, what build system to use, what runtime and sdk to wire 
up, and of course, without having a pre-processed .in file.


I don't see any reason the aforementioned project can't do that, but I 
expect some bike-shedding about where configurations live. I hope this 
serves as a major counter-point to the ultimately centralized choice.


I have some more thoughts, but this email is already too long. So I'll stop.

-- Christian

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Michael Catanzaro]

On Tue, 2017-02-28 at 11:44 -0500, Matthias Clasen wrote:
> So far, we have this gnome-nightly-apps repository which contains
> copies of the flatpak manifests for a bunch of gnome apps. That is
> redundant and suboptimal. Recently, flatpak has gained the ability to
> find manifests in git repositories that you point it to, and we
> should use this to move the json files to each applications git tree.
> Quite possibly there is already a copy of it there anyway.
> 
> If you want to help out with making this happen, the details are
> described here:
> 
> https://wiki.gnome.org/Initiatives/GnomeGoals/FlatpakManifests

This is clearly superior to how we build the flatpaks now.

On the other hand, these manifests should hopefully be obsoleted soon
by BuildStream. The goal of that effort is to remove the separate
Continuous manifest, JHBuild moduleset, and flatpak nightlies repos. So
 if we implement this now, we'd be going from centralized to
decentralized and then back to centralized in the future. So I don't
know if it makes sense to do this for all modules now. But it's a small
amount of work and certainly doesn't hurt anything.

You should add it to the list of proposed goals:

https://wiki.gnome.org/Initiatives/GnomeGoals/

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Improving the way we build nightly apps

[Adrien Plazas via desktop-devel-list]

Hi Matthias,

That sounds great! I'm eager to do this for Games.

To be sure, gnome-2-22 in the wiki page is a typo and you meant 
gnome-3-22, right?


Cheers,
Adrien Plazas


Le mar. 28 févr. 2017 à 17:44, Matthias Clasen 
 a écrit :
So far, we have this gnome-nightly-apps repository which contains 
copies of the flatpak manifests for a bunch of gnome apps. That is 
redundant and suboptimal. Recently, flatpak has gained the ability to 
find manifests in git repositories that you point it to, and we 
should use this to move the json files to each applications git tree. 
Quite possibly there is already a copy of it there anyway.


If you want to help out with making this happen, the details are 
described here:


https://wiki.gnome.org/Initiatives/GnomeGoals/FlatpakManifests
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list