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: [GitLab] Projects moved and 'tips of the week'

[Carlos Soriano]

Done , cheers.

Carlos Soriano
GNOME Board of Directors

On 22 January 2018 at 18:08, 藍挺瑋  wrote:

> Tobias Mueller 於 西元2018年01月23日 00:46 寫道:
> > Hi.
> >
> > On Tue, 2018-01-23 at 00:09 +0800, 藍挺瑋 wrote:
> >> Is it possible to get a private bug migrated to GitLab? I have a bug
> >> report which was marked as private by a libgtop developer, but there
> >> is
> >> no confidential information in the bug and I don't know why it became
> >> private.
> >>
> >> https://bugzilla.gnome.org/show_bug.cgi?id=744890
> >>
> > I've unchecked the private box.
> >
>
> Thanks. So the remaining issue is that whether it is possible to do the
> migration for only one bug.
>
>
___
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: [GitLab] Projects moved and 'tips of the week'

[藍挺瑋]

Tobias Mueller 於 西元2018年01月23日 00:46 寫道:
> Hi.
> 
> On Tue, 2018-01-23 at 00:09 +0800, 藍挺瑋 wrote:
>> Is it possible to get a private bug migrated to GitLab? I have a bug
>> report which was marked as private by a libgtop developer, but there
>> is
>> no confidential information in the bug and I don't know why it became
>> private.
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=744890
>>
> I've unchecked the private box.
> 

Thanks. So the remaining issue is that whether it is possible to do the
migration for only one bug.

___
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: [GitLab] Projects moved and 'tips of the week'

[Tobias Mueller]

Hi.

On Tue, 2018-01-23 at 00:09 +0800, 藍挺瑋 wrote:
> Is it possible to get a private bug migrated to GitLab? I have a bug
> report which was marked as private by a libgtop developer, but there
> is
> no confidential information in the bug and I don't know why it became
> private.
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=744890
> 
I've unchecked the private box.

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

Re: [GitLab] Projects moved and 'tips of the week'

[藍挺瑋]

Carlos Soriano 於 西元2018年01月11日 19:17 寫道:
> All bugs migrated now, including gnome-builder
> , libdazzle
>  and gnome-boxes
> 

Is it possible to get a private bug migrated to GitLab? I have a bug
report which was marked as private by a libgtop developer, but there is
no confidential information in the bug and I don't know why it became
private.

https://bugzilla.gnome.org/show_bug.cgi?id=744890

> 
> One mistake we did is that the creators of the bugs are not subscribed
> (if you were in the CC list, like if you put a comment, you are
> subscribed though), sorry!
> 
> Enjoy!
> 

___
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