Re: Release team now using gnome-build-meta repository, not JHBuild

[Jens Georg]

Hi Tristan,
> 
> 
> Also, your question makes me realize I need to clarify some more
> things
> about sysdeps and how they have changed, there is a longer term plan
> which involves collaboration with the newly created freedesktop-sdk
> project (see: gitlab project[0] and mailing list[1]) for building a
> well integrated system which I will try to blog about soon.

Actually, I forgot that gexiv2 isn't a "normal" module, I even have a
ticket open regarding this. Thanks for the detailed explanations.

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Sorry I've been slow on this thread, it's an inopportune time as I'm
stuck in all day meetings all week...

On Wed, 2018-01-24 at 14:24 -0600, mcatanz...@gnome.org wrote:
> > On Wed, Jan 24, 2018 at 2:11 PM, Florian Müllner  
> wrote:
> > Really, the only thing I disagree with is that RT appears to actively 
> > discourage maintainers from updating JHbuild before everyone actually 
> > has the option to make the switch - sure, if updating GTK+ fails for 
> > me because harfbuzz gained a new dependency, I'll be able to figure 
> > out what that dependency is, what's its upstream is and whether it's 
> > available in reasonably current distros. But it'll be a lot easier 
> > and quicker for whoever made the change in the first place :-)
> 
> Maybe we should delay this until BuildStream can generate OS images. 
> Tristan, what do you think...?

Delay discouraging updates of JHBuild ?

The main motivation so far for keeping JHBuild on life support was for
Builder users who use the JHBuild integration features, giving Builder
some time to catch up, and I think we're talking about a fairly low
volume of backports for a fairly short time anyway so I'm not opposed.

I don't want us to start moving backwards either. Great progress has
been made and it's an ongoing effort, in the meantime there will be
growing pains and we should be attentive and make sure people are not
left behind.

Cheers,
-Tristan

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Wed, Jan 24, 2018 at 2:11 PM, Florian Müllner  
wrote:
Really, the only thing I disagree with is that RT appears to actively 
discourage maintainers from updating JHbuild before everyone actually 
has the option to make the switch - sure, if updating GTK+ fails for 
me because harfbuzz gained a new dependency, I'll be able to figure 
out what that dependency is, what's its upstream is and whether it's 
available in reasonably current distros. But it'll be a lot easier 
and quicker for whoever made the change in the first place :-)


Maybe we should delay this until BuildStream can generate OS images. 
Tristan, what do you think...?


(Tristan had actually suggested backporting gnome-build-meta changes to 
jhbuild for some hazy amount of time; it was mainly me who wanted to be 
rid of JHBuild ASAP. ;)


Michael

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Florian Müllner]

Oh my. I certainly did not intend to start a rant thread, sorry for that.

To clarify: I am not complaining that RT is taking away my favorite
toy. JHbuild is a great tool when it works, but it still breaks far
too often for newcomers or non-regulars. And as you rightly point out,
this is not fixable unless the build is completely isolated from the
build machine. Having to adjust my workflows is a price I'm happy to
pay if this works as advertised:

On Tue, Jan 23, 2018 at 2:18 PM, Tristan Van Berkom
 wrote:

>On BuildStream
>~~
>BuildStream is a tool which puts determinism of builds first and
>allows absolutely no room for unknown factors contaminating your
>integrated build result.

So thanks for working on that!


I'm also not complaining that RT doesn't want to be responsible for
maintaining the JHbuild moduleset anymore - even if it wouldn't be
additional work (which it is), we shouldn't delude what we consider a
GNOME release by providing two diverging versions of it.


Really, the only thing I disagree with is that RT appears to actively
discourage maintainers from updating JHbuild before everyone actually
has the option to make the switch - sure, if updating GTK+ fails for
me because harfbuzz gained a new dependency, I'll be able to figure
out what that dependency is, what's its upstream is and whether it's
available in reasonably current distros. But it'll be a lot easier and
quicker for whoever made the change in the first place :-)

I know that work is underway to fix the situation for core desktop
components, but in the meantime it would simply be nice if everyone
working on the platform was aware that some components are still stuck
on JHbuild for the time being, so updating it(*) after "breaking"
changes along with gnome-build-meta would be much appreciated.

Cheers,
Florian

(*) to be clear: I'm only concerned about the platform/dependencies
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Sébastien Wilmet]

On Wed, Jan 24, 2018 at 02:28:26AM +0200, Alberts Muktupāvels wrote:
> Sorry if that already is posted somewhere, but is there at least some kind
> of migration guide/tutorial?

See the first e-mail of this thread.

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Alberts Muktupāvels]

On Wed, Jan 24, 2018 at 12:22 AM, Marco Trevisan (Treviño) 
wrote:

> Il 22/01/2018 14:34, mcatanz...@gnome.org ha scritto:
> > On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
> >> Were you actually using JHBuild to run integrated system components
> >> (gnome-shell, gnome-session)? If so, how? I was not aware that that
> >> was even possible nowadays.
> >>
> >> When developing these components,
> >
> > Sorry, trying again
> >
> > When developing components like gnome-shell and gnome-session, I've
> > found myself working in a VM and installing directly into /usr/bin. It's
> > the only way I'm aware of that works. (You can try /usr/local, but then
> > you have to hack executable paths in several projects)
>
> As said it's not like that, I'm just running everyday this to run
> gnome-shell
>
>   jhbuild run env XDG_SESSION_TYPE=wayland \
>   XDG_RUNTIME_DIR=/tmp/jhbuild-runtime \
>   dbus-run-session gnome-shell --wayland \
>--display-server
>
> Same works when using X11 or gnome-session (just replacing the command).
> So it looks like there's nothing similar to that yet.
>
> Maybe JHBuild could be a bst client for building only?
>

Seems that everyone has their own usage...

I have multiseat setup. On my main seat I do development and testing is
done on second seat. I have configured JHBuild to make it possible to build
multiple versions. For example `jhbuild build` will build/rebuild current
development version - 3.28 and `VERSION=3.26 jhbuild build` will rebuild
3.26 modulset. On second seat I can easily login in 3.28 session and if
needed also in 3.26.

I regularly do `jhbuild build` and/or `VERSION=3.26 jhbuild build` to
update with newest changes for development and last stable version. I also
use `VERSION=3.26 jhbuild checkbranches -b gnome-3-26` to make sure that
stable version build from correct branch. And mostly I do update jhbuild
modulesets if change is simple enough that I am sure that it is correct and
wont break anything...

Mentioned at-spi2-core "problem". I am pretty sure that I have done
`jhbuild done` in November and I don't remember that build has been broken
because of at-spi2-core. Any chance that jhbuild simply has re-used
previously generated configure file?:
https://git.gnome.org/browse/jhbuild/tree/jhbuild/modtypes/autotools.py#n111

To me this looks like tool that was able to do task x is replaced with tool
that is supposed to do y... Following this thread it clear that BuildStream
will never provide same functionality. So how developers are supposed to
test fixes/changes to apps? I could easily restart re-built app in jhbuild
session or logout and login to test bigger changes. How am I supposed to
achieve  something similar with BuildStream? Will I need to build VM
images, restart VM and then test my changes?

Sorry if that already is posted somewhere, but is there at least some kind
of migration guide/tutorial?

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Treviño]

Il 22/01/2018 14:34, mcatanz...@gnome.org ha scritto:
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that
>> was even possible nowadays.
>>
>> When developing these components,
> 
> Sorry, trying again
> 
> When developing components like gnome-shell and gnome-session, I've
> found myself working in a VM and installing directly into /usr/bin. It's
> the only way I'm aware of that works. (You can try /usr/local, but then
> you have to hack executable paths in several projects)

As said it's not like that, I'm just running everyday this to run
gnome-shell

  jhbuild run env XDG_SESSION_TYPE=wayland \
  XDG_RUNTIME_DIR=/tmp/jhbuild-runtime \
  dbus-run-session gnome-shell --wayland \
   --display-server

Same works when using X11 or gnome-session (just replacing the command).
So it looks like there's nothing similar to that yet.

Maybe JHBuild could be a bst client for building only?


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

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Mon, Jan 22, 2018 at 3:12 PM, Bastien Nocera  
wrote:

Or c) nobody's needed to recompile at-spi-core2 because it hasn't
changed in significant ways in years and the distro provided versions
work just fine.

My at-spi-core checkout dates back from 2013.

I, and I suspect a majority of folks that hack on more than a few
modules, usually install the build dependencies from my distribution,
and then try to compile the application or library ("buildone") that I
want to work on. glib and gtk+ are probably the only 2 libraries that 
I

recompile at least once a week.


Hi,

It sounds like you never use 'jhbuild build', but instead manage your 
dependencies manually and use 'jhbuild buildone'. Although I wouldn't 
recommend that to newcomers, if that works for you, then great. But if 
you never use 'jhbuild build' then you're also not using the 
dependencies specified in the modulesets at all, so I don't think this 
change would even affect you, except when you want to build a new 
module that's not currently in the modulesets, which is easy to add.



Furthermore, you're the one that asked developers switching to meson
not to change the jhbuild moduleset until a tarball release with meson
existed, so you could run the releases.

Damned if you do...


Hm, maybe my request was too confusing. Yes, changing the moduleset is 
an inconvenience for us if there's no new tarball release come GNOME 
release day. But that's not a good reason to leave JHBuild broken. It's 
a reason to make a new tarball release.


The same problem actually still exists with BuildStream. The solution 
is to just pay special attention to the GNOME release cycle when you're 
switching gnome-build-meta to use the new build system. This is a 
one-time issue, so not a big deal IMO.


Michael

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Hi all,

This will be a long email, so TL;DR:

   o At this time you can keep using JHBuild for these few cases where
 testing is very difficult, you can even do so indefinitely.

   o For these few modules who dont benefit directly at development
 time from the release team's official build metadata, the effort
 should be very low.

   o We will have a way for you to test core components soon, and it
 will be superior in many ways, but will inevitably lose *some*
 of the convenience which JHBuild offered.


On Mon, 2018-01-22 at 14:31 -0600, mcatanz...@gnome.org wrote:
> > On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano  
> wrote:
> > What's the workflow for those before a proper solution is done? Or 
> > are the developers of those modules expected to maintain JHbuild on 
> > the meantime?
> 
> Thanks Carlos; this is an important question. Let me provide a bit more 
> context for our decision to stop maintaining JHBuild now, even though 
> BuildStream is not yet be usable for running some modules.
> 
[...]

   I'd like to thank Michael for chipping in here while I was enduring
a travel itenerary which takes over 20 hours all told, and recovering f
rom it's side effects.

There have been some discussion about the pain points for testing the
few, albeit very important and central components of the GNOME UX on
your own developer laptop.

First of all, to avoid blowing things out of proportion, we are talking
about the maintenance of a few configure arguments for a handful
modules here. These modules are not easily verifiable and testable on
your laptop using BuildStream, *yet*.

Yes the release team demands that you update the gnome-build-meta
repository for these for our purposes of delivering integrated builds
and releases of GNOME as a whole, and these few core modules might not
yet be benefiting from those builds as developers - but these configure
arguments don't change immensely often, and whatever work the release
team did before in terms of maintaining them (mostly this is manually
checking the status of tarball converted builds at release time), is
not benefiting your experience as a developer on these modules
anyway.

A better way to test an integrated GNOME is coming, but for the time
being:

  Please update the gnome-build-meta repository to help us ensure that
  it's building. And feel free to continue to use JHBuild modulesets
  without those modulesets being considered in the integrated releases.


With that out of the way, in the long term; yes it's also fine if you
continue to use JHBuild for your own development workflow preferences,
but I am very driven to convince you that ultimately we will have a
better way of doing things both for the release team and for all GNOME
developers, and these visions should be aligned. So, I'll try to
alleviate some of your concerns regarding the long term picture of
development.


To start, here is a general outline of how the tooling differs in their
core values, and how these tools are effectively crossed in purposes:


   On JHBuild
   ~~
   JHBuild is a tool which prioritizes developer convenience,
   attempting to build the "latest of GNOME" on top of a loosely
   defined abstract system.

   Various tricks are in place in the GNOME modulesets, for instance
   modules which we *can* build, but avoid trying if we have the chance
   to determine that a local pkg-config file is found for it.

   The result is that you can mostly test your software on your
   machine, and for the majority of high level apps, this is good
   enough for the developer to test and cover the majority of use cases
   in manual testing.


   On BuildStream
   ~~
   BuildStream is a tool which puts determinism of builds first and
   allows absolutely no room for unknown factors contaminating your
   integrated build result.

   Various safe guards are put in place to ensure that you are never
   building or testing a result that cannot be reproduced exactly on
   another laptop.

   The result is that you are never uncertain about which module
   changed from one build to the next when a bug was introduced,
   and you are never writing software against the old version of
   a changed component which happens to be lying around on your
   system, causing last minute pain at release time.

   Whether GNOME is broken or is working well, you always know that
   the integrated result of a GNOME build is exactly what you expect
   it to be.


I should also point out that from a release team perspective, our
priority has to be delivering an integrated GNOME where it's components
always work well with eachother at release time, not a hand full of
components which happened to work well in their respective maintainers
hacked distro setups.


Developers in FOSS have historically filed the integration work under
the "not my problem" category, and the result of that is a lot of back
and forth with the downstream distros which ensues 

Re: Release team now using gnome-build-meta repository, not JHBuild

[Bastien Nocera]

On Mon, 2018-01-22 at 14:31 -0600, mcatanz...@gnome.org wrote:
> 
> 
> I'll use one specific anecdote. On October 30, the Autotools build 
> files were removed from at-spi2-core. The accompanying JHBuild 
> moduleset update switching it to use meson was pushed by Philip 
> Withnall (thanks!) on December 1. So at-spi2-core was obviously not 
> buildable with JHBuild during November. at-spi2-core is, of course,
> a 
> dependency of gtk+-3 (via at-spi2-atk), which is a dependency of
> every 
> GNOME app. That means either (a) nobody tried to 'jhbuild build' any 
> app during the entire month of November, or (b) nobody bothered to 
> report that building everything was broken during this time.

Or c) nobody's needed to recompile at-spi-core2 because it hasn't
changed in significant ways in years and the distro provided versions
work just fine.

My at-spi-core checkout dates back from 2013.

I, and I suspect a majority of folks that hack on more than a few
modules, usually install the build dependencies from my distribution,
and then try to compile the application or library ("buildone") that I
want to work on. glib and gtk+ are probably the only 2 libraries that I
recompile at least once a week.

Furthermore, you're the one that asked developers switching to meson
not to change the jhbuild moduleset until a tarball release with meson
existed, so you could run the releases.

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Carlos Soriano]

>But I'm only speaking for the release team here, not the entire community
- I know that answer doesn't actually solve the problem, but hopefully that
explains our thinking.

Definitely, I imagined this is just a side effect of the release team not
using JHbuild anymore, which I understand. Just wanted to have clear that
part.

So I guess is up to us the developers to keep maintaining JHBuild as best
as we can while finding other solutions.

Cheers

On 22 January 2018 at 21:31,  wrote:

>
> On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano 
> wrote:
>
>> What's the workflow for those before a proper solution is done? Or are
>> the developers of those modules expected to maintain JHbuild on the
>> meantime?
>>
>
> Thanks Carlos; this is an important question. Let me provide a bit more
> context for our decision to stop maintaining JHBuild now, even though
> BuildStream is not yet be usable for running some modules.
>
> I'll use one specific anecdote. On October 30, the Autotools build files
> were removed from at-spi2-core. The accompanying JHBuild moduleset update
> switching it to use meson was pushed by Philip Withnall (thanks!) on
> December 1. So at-spi2-core was obviously not buildable with JHBuild during
> November. at-spi2-core is, of course, a dependency of gtk+-3 (via
> at-spi2-atk), which is a dependency of every GNOME app. That means either
> (a) nobody tried to 'jhbuild build' any app during the entire month of
> November, or (b) nobody bothered to report that building everything was
> broken during this time.
>
> So I assumed that demand to continue maintaining the JHBuild modulesets
> was really, really, *really* low.
>
> This is just one particularly-egregious case... maintaining JHBuild is a
> constant fight against this sort of breakage; it seems to almost always be
> broken, and it's just not sustainable. (Big thanks to Alberts Muktupāvels,
> Javier Jardón, Ting-Wei Lan, and everyone else who's helped to maintain
> JHBuild during the past few years.) Now that release team is no longer
> using JHBuild, we simply don't want to deal with it anymore.
>
> But I'm only speaking for the release team here, not the entire community.
> This conversation has made clear that, due to BuildStream's current
> limitations, there is still desire to continue using JHBuild that we failed
> to anticipate. Even I'll admit that, when it does work, JHBuild is actually
> easier and more convenient to use for development. So I would say: please
> do feel free to maintain the modulesets to the degree that you require for
> your own development. We have no plans to delete them. Ensuring that the
> modules you're personally interested in are building fine should be much
> easier for you than it was for us to try to ensure that everything always
> builds.
>
> But with BuildStream, we now know for sure that our software always at
> least builds, because there is CI to enforce it, and a well-defined base
> system which is unaffected by host dependencies. That's step one. We've
> never had that before. I'm hopeful that the GNOME community can continue to
> improve the situation from here, to help make BuildStream more powerful and
> easier to use. No doubt Tristan will be here tomorrow with a comment on his
> plans for this. :)
>
> I know that answer doesn't actually solve the problem, but hopefully that
> explains our thinking.
>
> Michael
>
> P.S. Unimportant: the dependency of gtk+-3 on at-spi2-atk is actually
> illegal, since gtk+-3 is in core-deps, and at-spi2-atk is in core, and
> core-deps is not supposed to depend on core. I just now noticed this. We of
> course have no tools to detect it. ;)
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano  
wrote:
What's the workflow for those before a proper solution is done? Or 
are the developers of those modules expected to maintain JHbuild on 
the meantime?


Thanks Carlos; this is an important question. Let me provide a bit more 
context for our decision to stop maintaining JHBuild now, even though 
BuildStream is not yet be usable for running some modules.


I'll use one specific anecdote. On October 30, the Autotools build 
files were removed from at-spi2-core. The accompanying JHBuild 
moduleset update switching it to use meson was pushed by Philip 
Withnall (thanks!) on December 1. So at-spi2-core was obviously not 
buildable with JHBuild during November. at-spi2-core is, of course, a 
dependency of gtk+-3 (via at-spi2-atk), which is a dependency of every 
GNOME app. That means either (a) nobody tried to 'jhbuild build' any 
app during the entire month of November, or (b) nobody bothered to 
report that building everything was broken during this time.


So I assumed that demand to continue maintaining the JHBuild modulesets 
was really, really, *really* low.


This is just one particularly-egregious case... maintaining JHBuild is 
a constant fight against this sort of breakage; it seems to almost 
always be broken, and it's just not sustainable. (Big thanks to Alberts 
Muktupāvels, Javier Jardón, Ting-Wei Lan, and everyone else who's 
helped to maintain JHBuild during the past few years.) Now that release 
team is no longer using JHBuild, we simply don't want to deal with it 
anymore.


But I'm only speaking for the release team here, not the entire 
community. This conversation has made clear that, due to BuildStream's 
current limitations, there is still desire to continue using JHBuild 
that we failed to anticipate. Even I'll admit that, when it does work, 
JHBuild is actually easier and more convenient to use for development. 
So I would say: please do feel free to maintain the modulesets to the 
degree that you require for your own development. We have no plans to 
delete them. Ensuring that the modules you're personally interested in 
are building fine should be much easier for you than it was for us to 
try to ensure that everything always builds.


But with BuildStream, we now know for sure that our software always at 
least builds, because there is CI to enforce it, and a well-defined 
base system which is unaffected by host dependencies. That's step one. 
We've never had that before. I'm hopeful that the GNOME community can 
continue to improve the situation from here, to help make BuildStream 
more powerful and easier to use. No doubt Tristan will be here tomorrow 
with a comment on his plans for this. :)


I know that answer doesn't actually solve the problem, but hopefully 
that explains our thinking.


Michael

P.S. Unimportant: the dependency of gtk+-3 on at-spi2-atk is actually 
illegal, since gtk+-3 is in core-deps, and at-spi2-atk is in core, and 
core-deps is not supposed to depend on core. I just now noticed this. 
We of course have no tools to detect it. ;)


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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Carlos Soriano]

Adding on top of Florian, some apps like gnome-boxes and Nautilus are not
yet ready for Flatpak, or Flatpak is not ready for them yet. While I agree
we should pursue that as a end goal, pulling out maintenance of JHbuild as
tool for people to contribute to our modules before a viable alternative is
worked out it's kinda unexpected.

What's the workflow for those before a proper solution is done? Or are the
developers of those modules expected to maintain JHbuild on the meantime?


Carlos Soriano
GNOME Board of Directors

On 22 January 2018 at 19:17, Sam Thursfield  wrote:

> On Sat, Jan 20, 2018 at 9:47 AM, Tristan Van Berkom
>  wrote:
> > Instructions for using the gnome-build-meta BuildStream project can be
> > found at:
> >
> > https://wiki.gnome.org/Newcomers/BuildSystemComponent
>
> We found a bug in BuildStream which is triggered by those
> instructions. It's reported at
> https://gitlab.com/BuildStream/buildstream/issues/202
>
> For anyone who hits this error, please try out the fix proposed in
> https://gitlab.com/BuildStream/buildstream/merge_requests/250
>
> Thanks!
> Sam
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Sam Thursfield]

On Sat, Jan 20, 2018 at 9:47 AM, Tristan Van Berkom
 wrote:
> Instructions for using the gnome-build-meta BuildStream project can be
> found at:
>
> https://wiki.gnome.org/Newcomers/BuildSystemComponent

We found a bug in BuildStream which is triggered by those
instructions. It's reported at
https://gitlab.com/BuildStream/buildstream/issues/202

For anyone who hits this error, please try out the fix proposed in
https://gitlab.com/BuildStream/buildstream/merge_requests/250

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Mon, Jan 22, 2018 at 9:13 AM, Florian Müllner  
wrote:
Very much, I actually use a jhbuild GNOME session as my everyday 
system.


I don't have a good answer. :/

Michael

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[藍挺瑋]

mcatanz...@gnome.org 於 西元2018年01月22日 21:34 寫道:
> 
> 
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that
>> was even possible nowadays.
>>
>> When developing these components,
> 
> Sorry, trying again
> 
> When developing components like gnome-shell and gnome-session, I've
> found myself working in a VM and installing directly into /usr/bin. It's
> the only way I'm aware of that works. (You can try /usr/local, but then
> you have to hack executable paths in several projects)
> 
> Since it was already not possible to run these components with JHBuild,
> this does not seem like a regression to me. Tristan mentioned the future
> goal is to create a VM image, but one step at a time.

It is not possible to run GDM, but it is possible to run gnome-shell,
gnome-session, gnome-keyring in JHBuild without the help from a display
manager. JHBuild gnome-session is the primary desktop environment on my
FreeBSD desktop machine because packages provided by FreeBSD tend to be
out of date. Features requiring GDM or polkit don't work in JHBuild, but
I don't really care them because they are not essential for basic
functionality of desktop.

> 
> If you are aware of some way that you can successfully run gnome-shell
> or gnome-session or gdm or similar components using JHBuild, I would
> love to know! gnome-shell used to be possible using 'jhbuild build
> gnome-shell' and 'jhbuild run gnome-shell -r', but the last time that
> worked for me was many years ago. Even trying different combinations of
> undocumented args like --nested and --wayland, I've yet to see it work
> in recent times.

Here are my steps to run GNOME session on X11 on FreeBSD.

1. Login from a text console. I usually use VT 2 to avoid seeing
messages from the kernel and daemons. It is also possible to login from
ssh, but it seems the a local session works better with ConsoleKit.

2. Run 'screen' so we can see messages sent to stdout and stderr without
switching VT. We can re-attach the screen session from gnome-terminal.

3. Run 'screen Xorg'. It will be started on VT 9 on FreeBSD.

4. Run 'screen jhbuild run env DISPLAY=:0 gnome-session'. It will prompt
for gnome-keyring password because we don't use a display manager.

It is also possible to run JHBuild GNOME session on a remote server with
TigerVNC. 'jhbuild run gnome-session' usually works for me.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Florian Müllner]

On Mon, Jan 22, 2018 at 2:34 PM,   wrote:
>
>
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
>>
>> Were you actually using JHBuild to run integrated system components
>> (gnome-shell, gnome-session)? If so, how? I was not aware that that was even
>> possible nowadays.

Very much, I actually use a jhbuild GNOME session as my everyday
system. On a recently current system, a separate gnome-jhbuild.desktop
file in /usr/share/{x,wayland-}sessions with "Exec=jhbuild run
gnome-session" is enough to get a working session. If you want DBus
activated services from your jhbuild prefix to work as expected, the
invocation gets a bit trickier, but it's still possible.


> gnome-shell used to be possible using 'jhbuild build gnome-shell' and
> 'jhbuild run gnome-shell -r', but the last time that worked for me was many
> years ago.

Right, as noted by Bastien, you cannot swap out the display server, so
replacing the running shell only works when it is not acting as one
(i.e. not in the wayland session).


> Even trying different combinations of undocumented args like
> --nested and --wayland, I've yet to see it work in recent times.

That one should still work:
jhbuild run gnome-shell --replace --nested --wayland

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Bastien Nocera]

On Mon, 2018-01-22 at 07:34 -0600, mcatanz...@gnome.org wrote:
> 
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
> > Were you actually using JHBuild to run integrated system
> > components 
> > (gnome-shell, gnome-session)? If so, how? I was not aware that
> > that 
> > was even possible nowadays.
> > 
> > When developing these components,
> 
> Sorry, trying again
> 
> When developing components like gnome-shell and gnome-session, I've 
> found myself working in a VM and installing directly into /usr/bin. 
> It's the only way I'm aware of that works. (You can try /usr/local,
> but 
> then you have to hack executable paths in several projects)
> 
> Since it was already not possible to run these components with
> JHBuild, 

It was. You'd build close to the whole desktop, and end up with a
jhbuild session file you'd link in to a system directory (once). From
then on, you'd have a "jhbuild session" available as an option in gdm.

> this does not seem like a regression to me. Tristan mentioned the 
> future goal is to create a VM image, but one step at a time.
> 
> If you are aware of some way that you can successfully run gnome-
> shell 
> or gnome-session or gdm or similar components using JHBuild, I would 
> love to know! gnome-shell used to be possible using 'jhbuild build 
> gnome-shell' and 'jhbuild run gnome-shell -r', but the last time
> that 
> worked for me was many years ago.

"When you still used X11". That worked when the shell wasn't also the
display server.

>  Even trying different combinations of 
> undocumented args like --nested and --wayland, I've yet to see it
> work 
> in recent times.

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
Were you actually using JHBuild to run integrated system components 
(gnome-shell, gnome-session)? If so, how? I was not aware that that 
was even possible nowadays.


When developing these components,


Sorry, trying again

When developing components like gnome-shell and gnome-session, I've 
found myself working in a VM and installing directly into /usr/bin. 
It's the only way I'm aware of that works. (You can try /usr/local, but 
then you have to hack executable paths in several projects)


Since it was already not possible to run these components with JHBuild, 
this does not seem like a regression to me. Tristan mentioned the 
future goal is to create a VM image, but one step at a time.


If you are aware of some way that you can successfully run gnome-shell 
or gnome-session or gdm or similar components using JHBuild, I would 
love to know! gnome-shell used to be possible using 'jhbuild build 
gnome-shell' and 'jhbuild run gnome-shell -r', but the last time that 
worked for me was many years ago. Even trying different combinations of 
undocumented args like --nested and --wayland, I've yet to see it work 
in recent times.


Michael

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Mon, Jan 22, 2018 at 6:33 AM, Florian Müllner  
wrote:

Is this information outdated? At least I see all those components in
the gnome-build-meta repo, so I dare to hope ...


You can build them, and there is CI to ensure the build does not fail.

But I imagine it would be hard to run them.


If not, are we now expected to monitor all our dependencies'
dependencies (and so on) and effectively take over maintenance of the
jhbuild moduleset until someone figures out how to support our
components?


Were you actually using JHBuild to run integrated system components 
(gnome-shell, gnome-session)? If so, how? I was not aware that that was 
even possible nowadays.


When developing these components,

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Florian Müllner]

On Sat, Jan 20, 2018 at 6:06 PM,   wrote:
> When adding or removing a dependency from your
> module, please now update gnome-build-meta instead.

The BuildSteam page still mentions this:
> In case you are trying to develop integrated components such as GNOME Shell,
> GDM, gnome-session or gnome-keyring, these are more difficult and not yet 
> supported.

Is this information outdated? At least I see all those components in
the gnome-build-meta repo, so I dare to hope ...
If not, are we now expected to monitor all our dependencies'
dependencies (and so on) and effectively take over maintenance of the
jhbuild moduleset until someone figures out how to support our
components?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Sun, Jan 21, 2018 at 6:02 AM, Tristan Van Berkom 
 wrote:

gexiv2 is listed as a system dependency, which strikes me as a bit odd
seeing as it's a requirement for some GNOME modules and it's hosted in
GNOME - I'm new to the release team and will have to figure out the
reasoning behind this.


We used to prefer to move modules from core-deps into sysdeps when 
possible, to reduce the number of modules that can cause build failures 
in JHBuild. That's not really going to be an issue anymore. I think 
moving gexiv2 to core-deps would be uncontroversial, if there's desire 
to do so, especially since it's hosted on GNOME infrastructure.



For now, the actual sysdeps we use to populate a base runtime to build
against are controlled by this list[2], and is basically generated 
from

packages in debian testing - until the freedesktop-sdk project evolves
and we start generating bootable VMs with a combination of that, and
GNOME build metadata, I should move that repo over to GNOME's gitlab
and re-enable the automation of generating the images it creates (I've
been doing this manually in order to avoid unnecessary rebuilds).


Tristan mentions that gexiv2 is a system dependency... that means it 
was never built in JHBuild before now, so it's not going to be built in 
BuildStream either (unless we add it to the core-deps project).


Under JHBuild, our rule was that GNOME modules can depend on a system 
dependency only if it's present in the latest stable releases of both 
Fedora and Ubuntu. Now, under BuildStream, it's much easier to add a 
new version of a system dependency. Once the new gexiv2 package enters 
Debian testing, you can simply create a merge request to add it to 
multistrap.conf.in, the file Tristan pointed to in his last mail, and 
then GNOME modules can begin to depend on it.


Alternatively, you could create a merge request or issue report to add 
it to the core-deps project.


Michael

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

Hi,

On Sun, Jan 21, 2018 at 3:16 AM, Jens Georg  wrote:
So, following up on that and also on the libgepub thread: Which 
places do I have to modify if I were to switch the ABI and API 
version of gexiv2 (to either keep depending entities on the old 
stable branch or to the new branch or provide both etc) ? Only 
gnome-build-meta as mandatory, jhbuild as goodwill? What about 
continous?


Please do continue to update Continuous as needed for the time being. 
The future plan is to generate the Continuous manifest from 
gnome-build-meta, so that we don't have all this metadata specified in 
three different places, but replacing the manifest in gnome-sdk-images 
is more important to do first. (gnome-sdk-images is more 
lightly-maintained, and yet it's our only set of build definitions that 
directly affects our users.) Unfortunately, that's not likely to be 
ready for 3.28, so we'll need to be patient in the meantime. Hopefully 
later this year, we'll be able to announce that the Continuous manifest 
is gone. Again, thank Tristan and Codethink for this. ;)


I personally wouldn't touch JHBuild anymore unless you want to continue 
using JHBuild yourself and benefit from the changes you make, but it's 
up to you. JHBuild's developer workflow is still IMO better than what 
is currently provided by BuildStream, and we're used to using it for 
many years, so it's understandable if some community members desire to 
keep it working. (But release team considers it too fragile, and we 
really want to reduce the number of build definitions that we have to 
maintain.)


Michael

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Hi Jens,

Hurried reply whilst getting ready to go to airport...

On Sun, 2018-01-21 at 10:16 +0100, Jens Georg wrote:
> > On Sat, 2018-01-20 at 11:06 -0600, mcatanz...@gnome.org wrote:
> 
> > Hi all,
> > 
> > This bears repeating: the release team will no longer maintain
> > JHBuild 
> > or the JHBuild modulesets. When adding or removing a dependency from 
> > your module, please now update gnome-build-meta instead.
> 
> So, following up on that and also on the libgepub thread: Which places
> do I have to modify if I were to switch the ABI and API version of
> gexiv2

gexiv2 is listed as a system dependency, which strikes me as a bit odd
seeing as it's a requirement for some GNOME modules and it's hosted in
GNOME - I'm new to the release team and will have to figure out the
reasoning behind this.

Also, your question makes me realize I need to clarify some more things
about sysdeps and how they have changed, there is a longer term plan
which involves collaboration with the newly created freedesktop-sdk
project (see: gitlab project[0] and mailing list[1]) for building a
well integrated system which I will try to blog about soon.

For now, the actual sysdeps we use to populate a base runtime to build
against are controlled by this list[2], and is basically generated from
packages in debian testing - until the freedesktop-sdk project evolves
and we start generating bootable VMs with a combination of that, and
GNOME build metadata, I should move that repo over to GNOME's gitlab
and re-enable the automation of generating the images it creates (I've
been doing this manually in order to avoid unnecessary rebuilds).

Cheers,
-Tristan


[0]: https://gitlab.com/freedesktop-sdk
[1]: https://lists.freedesktop.org/mailman/listinfo/freedesktop-sdk
[2]: 
https://gitlab.com/BuildStream/debootstrap-ostree/blob/master/data/multistrap.conf.in

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Jens Georg]

On Sat, 2018-01-20 at 11:06 -0600, mcatanz...@gnome.org wrote:

> Hi all,
> 
> This bears repeating: the release team will no longer maintain
> JHBuild 
> or the JHBuild modulesets. When adding or removing a dependency from 
> your module, please now update gnome-build-meta instead.

So, following up on that and also on the libgepub thread: Which places
do I have to modify if I were to switch the ABI and API version of
gexiv2 (to either keep depending entities on the old stable branch or
to the new branch or provide both etc) ? Only gnome-build-meta as
mandatory, jhbuild as goodwill? What about continous?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro]

On Sat, Jan 20, 2018 at 3:47 AM, Tristan Van Berkom 
 wrote:

JHBuild
---
For what regards the upcomming 3.28 release and further, patches 
should

go to the gnome-build-meta project instead of the JHBuild modulesets -
otherwise these patches would not be considered in the releases we are
building.

As agreed upon in this previous thread[1], changes in gnome-build-meta
can be backported to the JHBuild modulesets while they remain on "life
support".


Hi all,

This bears repeating: the release team will no longer maintain JHBuild 
or the JHBuild modulesets. When adding or removing a dependency from 
your module, please now update gnome-build-meta instead.


JHBuild has served us very well for a long time, but BuildStream should 
be much more reliable. Thanks very much to Tristan and Codethink for 
making this transition possible!


(Of course, you can still use jhbuild and commit to the jhbuild 
modulesets if you want to. Just please don't expect the release team to 
review your patches anymore.)


Thanks and happy hacking,

Michael

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

Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Hi,

The time has come, the Release Team is now maintaining the GNOME
releases in BuildStream format, which is now available at:

https://gitlab.gnome.org/GNOME/gnome-build-meta

This repo is intended to contain the build metadata required for
building the GNOME core modules only, while many applications have been
migrated to Flatpak.

In the near future, Jürg Billeter will be landing his work[0] on
finally allowing BuildStream projects to depend on eachother, this will
allow people to create projects which depend on `gnome-build-meta`,
which will be a suitable approach for building things which are not a
part of the "core" category in GNOME.

Instructions for using the gnome-build-meta BuildStream project can be
found at:

https://wiki.gnome.org/Newcomers/BuildSystemComponent


JHBuild
---
For what regards the upcomming 3.28 release and further, patches should
go to the gnome-build-meta project instead of the JHBuild modulesets -
otherwise these patches would not be considered in the releases we are
building.

As agreed upon in this previous thread[1], changes in gnome-build-meta
can be backported to the JHBuild modulesets while they remain on "life
support".


Issues
--
Whenever you encounter a problem or hinderance in your workflow, please
let us know at either of the below trackers, depending on the nature of
your issue:

GNOME Build Metadata problems:
~~
https://gitlab.gnome.org/GNOME/gnome-build-meta/issues

BuildStream problems:
~
https://gitlab.com/BuildStream/buildstream/issues


At this time, I am aware of a few problems and inconveniences and we
are working hard on improving things as the project evolves and we
learn about new issues.

The hot topics I am aware of so far include:

  o Inconvenience when pulling changes from the gnome-build-meta
repository.

As is described in the newcomers wiki page[2], BuildStream rewrites
the project when fetching the latest commits on any given branch,
making it inconvenient when you want to pull new changes in the
metadata itsef (e.g. fixes to configure flags or dependencies,
additions of modules etc.).

A solution for this is under way[3].

  o Testing of modules which need integration with your host.

Some applications want to access resources which are highly
host specific, or require access to the internet to really
try out (e.g. epiphany). This doesnt always work out of the
box in an isolated `bst shell` environment with a base runtime
that may bear no resemblance to your actual host.

For the internet, it should be enough to setup a resolv.conf,
we should be able to bake this in pretty easily, other things
like access to pulse audio prove more difficult to address
without reimplementing Flatpak and portals.

The ultimate solution for this will be generating VM images
of what is really the "latest GNOME" (or more accurately,
the "exact version" of GNOME you wanted to build).

At the same time, I am considering allowing a project to create
"shell profiles" which can make `bst shell` more useful for more
resource intensive applications (perhaps by giving some control
as to what the shell can inherit from the host in terms of
environment variables and such like).

  o Integration with Builder

Christian has raised a list of features and points[4] to ensure
a great UX (or DX) which we will be considering and allocating
resources to address.


Cheers,
-Tristan


[0]: https://gitlab.com/BuildStream/buildstream/merge_requests/160
[1]: 
https://mail.gnome.org/archives/desktop-devel-list/2017-November/msg00036.html
[2]: 
https://wiki.gnome.org/Newcomers/BuildSystemComponent#Fetching_the_latest_build_metadata
[3]: https://mail.gnome.org/archives/buildstream-list/2018-January/msg5.html
[4]: 
https://mail.gnome.org/archives/buildstream-list/2017-November/msg00046.html

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