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



On Wed, Jan 24, 2018 at 12:22 AM, Marco Trevisan (Treviño) <mail 3v1n0 net> wrote:
Il 22/01/2018 14:34, mcatanzaro gnome org ha scritto:
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanzaro 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?:

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]