Re: Questions about the migration from GConf to GSettings/DConf
On Sun, 2015-07-19 at 23:17 +0800, Oliver Luo wrote:
> I've been spending several days working on the migration from GConf
> to GSettings/DConf in our project evolution EAS...
Hi,
I suppose you mean evolution-activesync, as it's named in the GNOME
repositories.
> 1. Use relocatable schemas. In this case, we have one schema being
> relocatable, and multiple instance of that schema so we can store
> accounts of uncertain number. But the question is that the instances
> are separated and there seems no API to control them as a whole,
> which means we lost the structure information and make things harder
> in our project.
Briefly grepping the evolution-activesync code, the keys being read
from the GConf look like:
/apps/activesyncd/accounts//
/apps/activesyncd/accounts//
...
so you can have a relocatable schema with { key1, key2, ... } and
"attach" it under /apps/activesyncd/accounts/. That feels pretty
straightforward, and if I understand your text properly then you know
it. The thing you face is to know the list of configured accounts.
I would create a 'list' key with a list of known accounts in
/apps/activesyncd/accounts/, which will contain the of each
configured accounts, and an existing path in GSettings. I saw this
approach being used in another project, I think it was gtk+.
> I don't have the perfect solution yet, so I'm here to see if anyone
> could help me.
The evolution(-data-server) also used to store its account settings
into GConf, but then moved away from that idea and instead of migrating
account settings into GSettings it uses its own ESourceRegistry. You
can create tree of ESource-s there, each can have its own extension,
where it stores its data. Maybe it would work better than the
GSettings. See how evolution-ews stores its settings on an ESource for
an example (it uses an ESourceCollection for the parent ESource).
Alternatively, maybe, create your own API on top of a GKeyFile and
store the account information in it?
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Looking for speakers for hacknight in Gothenburg on Aug 11th
Hi all! FOSSGBG is a local free software group here in Gothenburg that has meetups every month or so to discuss various FOSS subjects. They're having an event on the 11th of August [1]. Since this overlaps with the GUADEC hackdays, the organizers of FOSSGBG thought it'd be nice to make this edition of their meetup about GNOME. They are looking for people from the GNOME community who would like to present their work at the meetup. Let me know if you'd like to volunteer. We'd like to have three 20-30 minutes talks. Subjects that would be interesting to the audience would be things like app development, Wayland and privacy. 1. http://foss-gbg.se/ - Andreas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Questions about the migration from GConf to GSettings/DConf
Hi Milan,
Thanks for your comprehensive response.
On Mon, 2015-07-20 at 09:04 +0200, Milan Crha wrote:
> Briefly grepping the evolution-activesync code, the keys being read
> from the GConf look like:
> /apps/activesyncd/accounts//
> /apps/activesyncd/accounts//
> ...
> so you can have a relocatable schema with { key1, key2, ... } and
> "attach" it under /apps/activesyncd/accounts/. That feels
> pretty
> straightforward, and if I understand your text properly then you know
> it. The thing you face is to know the list of configured accounts.
>
> I would create a 'list' key with a list of known accounts in
> /apps/activesyncd/accounts/, which will contain the of each
> configured accounts, and an existing path in GSettings. I saw this
> approach being used in another project, I think it was gtk+.
That sounds like a good solution to me; thanks.
> > . I don't have the perfect solution yet, so I'm here to see if
> > anyone could help me.
>
> The evolution(-data-server) also used to store its account settings
> into GConf, but then moved away from that idea and instead of migrating
> account settings into GSettings it uses its own ESourceRegistry. You
> can create tree of ESource-s there, each can have its own extension,
> where it stores its data. Maybe it would work better than the
> GSettings. See how evolution-ews stores its settings on an ESource for
> an example (it uses an ESourceCollection for the parent ESource).
Currently, the activesyncd dæmon is independent of Evolution. It
provides a DBus API which is used both from Evolution (for email), and
from SyncEvolution (for contacts/calendar).
So I'm a little reluctant to make it depend on ESource for
configuration.
> Alternatively, maybe, create your own API on top of a GKeyFile and
> store the account information in it?
Perhaps. I note GOA does something like this for its account storage.
But I think I like your first option better. Thanks again.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Looking for speakers for hacknight in Gothenburg on Aug 11th
On Mon, Jul 20, 2015 at 8:34 AM Andreas Nilsson wrote: > Hi all! > FOSSGBG is a local free software group here in Gothenburg that has > meetups every month or so to discuss various FOSS subjects. They're > having an event on the 11th of August [1]. > Since this overlaps with the GUADEC hackdays, the organizers of FOSSGBG > thought it'd be nice to make this edition of their meetup about GNOME. > > This is great! I want to see this happen. > They are looking for people from the GNOME community who would like to > present their work at the meetup. Let me know if you'd like to > volunteer. We'd like to have three 20-30 minutes talks. Subjects that > would be interesting to the audience would be things like app > development, Wayland and privacy. > > I would love to see this happen. I wonder if I can volunteer people. :-) I can also present on their behalf as well. But I would like someone to talk about: 1) xdg-app 2) changes in GTK+ - maybe the CSS 3) gnome-builder Are the ones that come to mind. Maybe Bastien Nocera has some hardware related type talk that he could talk about? sri > 1. http://foss-gbg.se/ > - Andreas > ___ > 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: Looking for speakers for hacknight in Gothenburg on Aug 11th
On Mon, 2015-07-20 at 19:41 +, Sriram Ramkrishna wrote: > > Are the ones that come to mind. Maybe Bastien Nocera has some > hardware related type talk that he could talk about? I'm afraid I won't be in town any more by that time. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
How do you hack on GNOME? How can we do better?
As we move to Wayland, some of the ways we used to work on the core parts of GNOME (like gnome-shell --replace) no longer work. I think this is a good time to look at how we hack on GNOME, how we can make it more standard and obvious for newcomers, and how we can make it easier. We can classify hacking on "GNOME" (taken very widely) into the following: 1) Hacking on system components that require hardware access (kernel drivers, NetworkManager) 2) Hacking on system components that don't inherently require hardware access (kernel filesystems, systemd, polkit, gdm) 3) Hacking on session level components (gnome-session, gnome-shell, gnome-settings-daemon), and the libraries they use (gnome-desktop, clutter) 4) Hacking on libraries (gtk+) 5) Hacking on applications Which ones of these do you do? How do you do it? Is 'jhbuild run' sufficient for your needs? Do you log into a jhbuild session? as yourself? as a test user? Do you replace system level components? With 'make install'? By building packages? Do you use gnome-continuous? 4 and 5 are handled pretty well by jhbuild. I think we can do better in the future for 5 using xdg-app - application checkouts could be entirely self-contained, with 'make' automatically downloading the right version of the GNOME SDK if not already present. 3 seems like a place where we can make progress - the vague idea I have is: - Move our standard install location back to /opt - Have utility scripts that set up a test user - Have hotkeys that switch directly back and forth between the main session and the test user session and respawn the test session We could theoretically address 2 by having our standard test setup to run in a VM, but a lot of aspects of the system don't test well in a VM - touchscreen input, multimonitor, networking UI, sound, etc. And running in a VM isn't possible with jhbuild, so we'd have to switch to gnome-continuous for builds, and it's not really designed for the same use case as jhbuild - the initial build and cycle times are much bigger. Addressing 1 systemically would not only require us to switch to gnome-continuous, it requires actually rebooting into the gnome-continuous tree - so in essence the user would be working in an ostree based operating system. This seems very much out of scope. Thoughts? I feel that we don't have a good story for someone coming in and wanting to hack on the core parts of GNOME right now, but perhaps there are things that I'm not aware of. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
I've hacked on things all the from 1-5. Everything has a different development process, as usual, and I don't think there's any sense in trying to unify them. Writing documentation and getting people started quicker is always great, but everybody's going to have their own little things. As for shell hacking, it's got increasingly more difficult to hack on things in a state like this, even under X11: launching a shell from a terminal loses things like search providers or some applications. There's issues with pkexec and other friends. Automounting USB keys never works when using jhbuild run. It feels strangely unclean and frustrating to work with. I just don't run a full shell as an X11 compositor through jhbuild anymore. I do what I need to, then reboot to get back to a clean state. You can run gnome-shell in a nested mode, but gnome-shell's forceful grabbing of DBus names mean that the nested gnome-shell gets notifications, screen lock goes to it, etc. I tend to only use mutter in nested mode for Wayland hacking. Having scripts or a better setup to keep my jhbuild builds mostly in-line with the system ones would be great. Full KMS-style Wayland hacking, for me, is mostly a separate machine ssh'd into my main computer, there to debug and keep a session going at all costs. I have issues, though, sometimes the keyring acts up and prompts for my ssh key on the terminal. Other times, I tend to "lose session-ness" and basically restart at that point to get things working again. What would really help is making VT switching work better. On my systems with external monitors (like the ones I hack on at work), a single VT switch takes 2-3 seconds from fbcon and back to X. I don't know if this is Xorg or fbcon or just the VT layer in general, but it is noticeable, and it is frustrating. I don't know if systemd-consoled / logind / "the VT replacement API" would help here at all. Figuring out what "session-ness" means and how to gain it when simply ssh'd in would also be great, but I have a feeling it's simply twenty different environment variables I have to port over one by one. On Mon, Jul 20, 2015 at 4:11 PM, Owen Taylor wrote: > As we move to Wayland, some of the ways we used to work on the core parts of > GNOME (like gnome-shell --replace) no longer work. I think this is a good > time to look at how we hack on GNOME, how we can make it more standard and > obvious for newcomers, and how we can make it easier. > > We can classify hacking on "GNOME" (taken very widely) into the following: > > 1) Hacking on system components that require hardware access (kernel > drivers, NetworkManager) > 2) Hacking on system components that don't inherently require hardware > access (kernel filesystems, systemd, polkit, gdm) > 3) Hacking on session level components (gnome-session, gnome-shell, > gnome-settings-daemon), and the libraries they use (gnome-desktop, clutter) > 4) Hacking on libraries (gtk+) > 5) Hacking on applications > > Which ones of these do you do? How do you do it? Is 'jhbuild run' sufficient > for your needs? Do you log into a jhbuild session? as yourself? as a test > user? Do you replace system level components? With 'make install'? By > building packages? Do you use gnome-continuous? > > 4 and 5 are handled pretty well by jhbuild. I think we can do better in the > future for 5 using xdg-app - application checkouts could be entirely > self-contained, with 'make' automatically downloading the right version of > the GNOME SDK if not already present. > > 3 seems like a place where we can make progress - the vague idea I have is: > > - Move our standard install location back to /opt > - Have utility scripts that set up a test user > - Have hotkeys that switch directly back and forth between the main session > and the test user session and respawn the test session > > We could theoretically address 2 by having our standard test setup to run in > a VM, but a lot of aspects of the system don't test well in a VM - > touchscreen input, multimonitor, networking UI, sound, etc. And running in a > VM isn't possible with jhbuild, so we'd have to switch to gnome-continuous > for builds, and it's not really designed for the same use case as jhbuild - > the initial build and cycle times are much bigger. > > Addressing 1 systemically would not only require us to switch to > gnome-continuous, it requires actually rebooting into the gnome-continuous > tree - so in essence the user would be working in an ostree based operating > system. This seems very much out of scope. > > Thoughts? I feel that we don't have a good story for someone coming in and > wanting to hack on the core parts of GNOME right now, but perhaps there are > things that I'm not aware of. > > - Owen > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper __
Re: How do you hack on GNOME? How can we do better?
On Mon, 2015-07-20 at 16:35 -0700, Jasper St. Pierre wrote: > I've hacked on things all the from 1-5. Everything has a different > development process, as usual, and I don't think there's any sense in > trying to unify them. Writing documentation and getting people > started quicker is always great, but everybody's going to have their > own little things. We obviously can't make all developers work the same way, and we don't want to. But there should be a way that we can recommend that actually *does* work :-) > As for shell hacking, it's got increasingly more difficult to hack on > things in a state like this, even under X11: launching a shell from a > terminal loses things like search providers or some applications. > There's issues with pkexec and other friends. Automounting USB keys > never works when using jhbuild run. It feels strangely unclean and > frustrating to work with. I just don't run a full shell as an X11 > compositor through jhbuild anymore. I do what I need to, then reboot > to get back to a clean state. Yeah. This type of thing is especially hard on newcomers, or simply people who don't continually work on the shell, because only through constant practice do you know *what* weirdness is due to a restarted shell. > You can run gnome-shell in a nested mode, but gnome-shell's forceful > grabbing of DBus names mean that the nested gnome-shell gets > notifications, screen lock goes to it, etc. I tend to only use mutter > in nested mode for Wayland hacking. > > Having scripts or a better setup to keep my jhbuild builds mostly > in-line with the system ones would be great. > > Full KMS-style Wayland hacking, for me, is mostly a separate machine > ssh'd into my main computer, there to debug and keep a session going > at all costs. I have issues, though, sometimes the keyring acts up > and eprompts for my ssh key on the terminal. Other times, I tend to > "lose session-ness" and basically restart at that point to get things > working again. If we could get nested working reliably, it certainly would be handy. Not everybody has access to a second computer. (Saying that as someone who is working as a nomad with a laptop for a couple of weeks.) The basic equation here is that nested == multi-seat; making nested work properly is draining the swamp of multi-seat issues. As far as I understand it, there's a strong push on the part of the systemd team to move from a session bus to a user bus; this probably means that a single user logging into multiple seats - into a nested session - is impractical. A single bus with components running from multiple versions of GNOME seems like an endless source of debugging headaches, even if we did all the work to move away from bus-global names. So nested == cross-user nested. But it probably is better to concentrate on getting VT switching to work well first, since a nested session is only an approximation of the real thing. > What would really help is making VT switching work better. On my > systems with external monitors (like the ones I hack on at work), a > single VT switch takes 2-3 seconds from fbcon and back to X. I don't > know if this is Xorg or fbcon or just the VT layer in general, but it > is noticeable, and it is frustrating. I don't know if systemd > -consoled / logind / "the VT replacement API" would help here at all. Yep. > Figuring out what "session-ness" means and how to gain it when simply > ssh'd in would also be great, but I have a feeling it's simply twenty > different environment variables I have to port over one by one. As you know, there are multiple scripts floating around for this, all pretty hacky. An official solution would be great. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Looking for speakers for hacknight in Gothenburg on Aug 11th
On Mon, 2015-07-20 at 17:34 +0200, Andreas Nilsson wrote: > They are looking for people from the GNOME community who would like > to > present their work at the meetup. Let me know if you'd like to > volunteer. We'd like to have three 20-30 minutes talks. Subjects that > > would be interesting to the audience would be things like app > development, Wayland and privacy. Regarding privacy, I could talk about HTTPS: what it does and doesn't do to keep your data private, when it can and can't be trusted, why the lock icon in your browser doesn't mean as much as you'd like it to... with a focus on Epiphany, of course. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
It'd be really nice if we could team up with the people working on container technology so that we were able to run a full GNOME session within a container. Even if it was privilleged. We could serve GNOME Continuous images as docker or lxc images with the latest stuff built in so that people can hack instead of waiting forever to build the same thing we're all building and just run it from within the container tree. Containers in general are a lot softer on hardware requirements than full fledged virtualization so we wouldn't be imposing a lot of requirements on hackers, on top of that they have the extra flexibility of us being able to step into the filesystem easily from the host so you can use your development environment instead of having to replicate it inside the VM. This would also alleviate all the dbus problems when nesting. I have tried running gnome-shell inside a docker/lxc image but had issues at several fronts what were less practical to address for me rather than switching to libvirt/kvm (this is something I needed for Fleet Commander). If we could crack those issues with a privileged container of some sort I think we could come up with a really handy workflow for ostree Relying on jhbuild from my point of view is a waste of everybody's time, we've got all these developers building the same version of the same module in the same architecture again and again and again, to reach more or less the same state, all the people who give up on writing a patch or testing master everytime a module breaks (like the latest libgit2-glib issues for example) is a precious resource we're wasting for not having the right infrastructure. Up to the point of glib or gtk+ is kinda handy but beyond that is almost impractical. 2015-07-21 1:16 GMT+01:00 Owen Taylor : > On Mon, 2015-07-20 at 16:35 -0700, Jasper St. Pierre wrote: > > I've hacked on things all the from 1-5. Everything has a different > > development process, as usual, and I don't think there's any sense in > > trying to unify them. Writing documentation and getting people > > started quicker is always great, but everybody's going to have their > > own little things. > > We obviously can't make all developers work the same way, and we don't > want to. But there should be a way that we can recommend that actually > *does* work :-) > > > As for shell hacking, it's got increasingly more difficult to hack on > > things in a state like this, even under X11: launching a shell from a > > terminal loses things like search providers or some applications. > > There's issues with pkexec and other friends. Automounting USB keys > > never works when using jhbuild run. It feels strangely unclean and > > frustrating to work with. I just don't run a full shell as an X11 > > compositor through jhbuild anymore. I do what I need to, then reboot > > to get back to a clean state. > > Yeah. This type of thing is especially hard on newcomers, or simply > people who don't continually work on the shell, because only through > constant practice do you know *what* weirdness is due to a restarted > shell. > > > You can run gnome-shell in a nested mode, but gnome-shell's forceful > > grabbing of DBus names mean that the nested gnome-shell gets > > notifications, screen lock goes to it, etc. I tend to only use mutter > > in nested mode for Wayland hacking. > > > > Having scripts or a better setup to keep my jhbuild builds mostly > > in-line with the system ones would be great. > > > > Full KMS-style Wayland hacking, for me, is mostly a separate machine > > ssh'd into my main computer, there to debug and keep a session going > > at all costs. I have issues, though, sometimes the keyring acts up > > and eprompts for my ssh key on the terminal. Other times, I tend to > > "lose session-ness" and basically restart at that point to get things > > working again. > > If we could get nested working reliably, it certainly would be handy. > Not everybody has access to a second computer. (Saying that as someone > who is working as a nomad with a laptop for a couple of weeks.) > > The basic equation here is that nested == multi-seat; making nested > work properly is draining the swamp of multi-seat issues. > > As far as I understand it, there's a strong push on the part of the > systemd team to move from a session bus to a user bus; this probably > means that a single user logging into multiple seats - into a nested > session - is impractical. A single bus with components running from > multiple versions of GNOME seems like an endless source of debugging > headaches, even if we did all the work to move away from bus-global > names. > > So nested == cross-user nested. > > But it probably is better to concentrate on getting VT switching to > work well first, since a nested session is only an approximation of the > real thing. > > > What would really help is making VT switching work better. On my > > systems with external monitors (like the ones I hack on at work), a > > single VT switch tak
Re: How do you hack on GNOME? How can we do better?
On Tue, 2015-07-21 at 02:04 +0100, Alberto Ruiz wrote: > Relying on jhbuild from my point of view is a waste of everybody's > time, we've got all these developers building the same version of the > same > module in the same architecture again and again and again, to > reach more or > less the same state, all the people who give up on > writing a patch or > testing master everytime a module breaks (like the > latest libgit2-glib > issues for example) is a precious resource we're > wasting for not having the > right infrastructure. Up to the point of > glib or gtk+ is kinda handy but > beyond that is almost impractical. The problem is that we have no way to make sure our modules are always in a buildable state. It's not impractical and it wouldn't even be particularly difficult, the result would look awfully like GNOME Continuous, building each jhbuild module in containers a few important distros; it's just a challenge nobody has had time to attempt yet. I was hoping GNOME Continuous would help with this, but the problem is that Continuous is completely separate from jhbuild so they can have different build issues; when an issue is detected in Continuous, it isn't fixed in jhbuild; and Continuous isn't a jhbuild replacement. I think our need is Continuous for jhbuild. In the meantime, all it takes to avoid the libgit2-glib situation is for someone to take a few minutes to roll back the module to an older version [1][2][3]. My bad for not doing this immediately when I noticed the problem; I wanted to give the developers some time to fix the issue, but in hindsight that was wrong; these issues must be addressed immediately since they block contributors from working on GNOME. The other issue with jhbuild right now is a circular dependency problem between, erm, g-i, vala, and... something else, I forget, which causes everything to fail for new users but work fine for existing users. This sucks. To avoid this, we need a dependency that says "build this module eventually after building me" or "build me eventually after building this other module," which we don't currently have. (I thought it was "after" but that's something else.) [1] https://git.gnome.org/browse/jhbuild/commit/?id=baa893595c98900e069 8dab2286953e0a5d723db [2] https://git.gnome.org/browse/jhbuild/commit/?id=661878b5ca0a1a97fed 1f5f61ecaa5991bf870d5 [3] https://git.gnome.org/browse/jhbuild/commit/?id=b651a03d8f1f7b7e2c3 ccd56de25ea42c2b2b9f6 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
On Mon, 2015-07-20 at 19:11 -0400, Owen Taylor wrote: > 1) Hacking on system components that require hardware access (kernel > drivers, NetworkManager) > 2) Hacking on system components that don't inherently require > hardware access (kernel filesystems, systemd, polkit, gdm) > 3) Hacking on session level components (gnome-session, gnome-shell, > gnome-settings-daemon), and the libraries they use (gnome-desktop, > clutter) > 4) Hacking on libraries (gtk+) > 5) Hacking on applications > > Which ones of these do you do? How do you do it? Is 'jhbuild run' > sufficient for your needs? I do 4 and 5 with 'jhbuild build' et. al. and 'jhbuild run'. > Do you log into a jhbuild session? as yourself? as a test user? I used to do 3 on rare occasions, but stopped doing that because I no longer remember how I ever managed to run a GNOME session under jhbuild in the past. There used to be instructions on the wiki, but they got deleted at some point because they became outdated. The problems I wanted to fix were never so urgent as to convince me to impel me to figure it out on my own. Pretty sure new contributors have no chance here. > Do you replace system level components? With 'make install'? By > building packages? Do you use gnome-continuous? I've replaced system level components with 'make install' when I found no other way to test a search provider. That displeased me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
build.gnome.org used to have auto builders for jhbuild. The problem is that jhbuild building requires maintenance. Everyone I've talked to said that after a few months of trying to have a jhbuild autobuilder, they gave up. In my opinion, the way to fix this is to make jhbuild more like Continuous. Have it read from the same manifest JSON format so that when Continuous gets fixed, so do jhbuilds. Have it work automatically in a similar way behind the scenes and "require less maintenance". And perhaps, when possible, use poor prebuilt binaries from Continuous or xdg-app. On Mon, Jul 20, 2015, 6:28 PM Michael Catanzaro wrote: > On Mon, 2015-07-20 at 19:11 -0400, Owen Taylor wrote: > > 1) Hacking on system components that require hardware access (kernel > > drivers, NetworkManager) > > 2) Hacking on system components that don't inherently require > > hardware access (kernel filesystems, systemd, polkit, gdm) > > 3) Hacking on session level components (gnome-session, gnome-shell, > > gnome-settings-daemon), and the libraries they use (gnome-desktop, > > clutter) > > 4) Hacking on libraries (gtk+) > > 5) Hacking on applications > > > > Which ones of these do you do? How do you do it? Is 'jhbuild run' > > sufficient for your needs? > > I do 4 and 5 with 'jhbuild build' et. al. and 'jhbuild run'. > > > Do you log into a jhbuild session? as yourself? as a test user? > > I used to do 3 on rare occasions, but stopped doing that because I no > longer remember how I ever managed to run a GNOME session under jhbuild > in the past. There used to be instructions on the wiki, but they got > deleted at some point because they became outdated. The problems I > wanted to fix were never so urgent as to convince me to impel me to > figure it out on my own. Pretty sure new contributors have no chance > here. > > > Do you replace system level components? With 'make install'? By > > building packages? Do you use gnome-continuous? > > I've replaced system level components with 'make install' when I found > no other way to test a search provider. That displeased me. > ___ > 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: How do you hack on GNOME? How can we do better?
Hi, On Mon, Jul 20, 2015 at 7:11 PM, Owen Taylor wrote:> > We can classify hacking on "GNOME" (taken very widely) into the following: > > 1) Hacking on system components that require hardware access (kernel > drivers, NetworkManager) > 2) Hacking on system components that don't inherently require hardware > access (kernel filesystems, systemd, polkit, gdm) > 3) Hacking on session level components (gnome-session, gnome-shell, > gnome-settings-daemon), and the libraries they use (gnome-desktop, clutter) > 4) Hacking on libraries (gtk+) > 5) Hacking on applications > > Which ones of these do you do? Mostly 2 and 3 for me (though all the above on occasion) > How do you do it? Is 'jhbuild run' sufficient for your needs? No, jhbuild doesn't work for GDM. (though I think Ryan got it to work at some point, some how, with patches) > Do you log into a jhbuild session? as yourself? as a test user? Do you > replace system level components? With 'make install'? I do the quickest, dirtiest, and sloppiest thing: alias %configure="./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --libdir=/usr/lib64" and then make install. Sometimes as a test user, but usually as myself. > 3 seems like a place where we can make progress - the vague idea I have is: > > - Move our standard install location back to /opt I actually like things going to /usr with the same flags as the distro packages so I can get things running pretty much the same way as downstream when i'm testing things. granted i realiize that makes some people cringe. > - Have utility scripts that set up a test user > - Have hotkeys that switch directly back and forth between the main session > and the test user session and respawn the test session I guess that will help for some cases, but a lot debugging (especailly for gnome-shell) really works better with a second machine. I realize that's not always feasible, but in some cases it's 100x easier. Even when doing app development. Clearly we should make the single system case work as well as possible, but i pretty much always try to have two machines with me if i'm doing development or debugging (even if it's two laptops at a coffeeshop) --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
Are there specific reasons why KVM doesn't cut it for shell developers? GPU access? 2015-07-21 2:44 GMT+01:00 Ray Strode : > Hi, > > On Mon, Jul 20, 2015 at 7:11 PM, Owen Taylor wrote:> > > We can classify hacking on "GNOME" (taken very widely) into the > following: > > > > 1) Hacking on system components that require hardware access (kernel > drivers, NetworkManager) > > 2) Hacking on system components that don't inherently require hardware > access (kernel filesystems, systemd, polkit, gdm) > > 3) Hacking on session level components (gnome-session, gnome-shell, > gnome-settings-daemon), and the libraries they use (gnome-desktop, clutter) > > 4) Hacking on libraries (gtk+) > > 5) Hacking on applications > > > > Which ones of these do you do? > Mostly 2 and 3 for me (though all the above on occasion) > > > How do you do it? Is 'jhbuild run' sufficient for your needs? > No, jhbuild doesn't work for GDM. (though I think Ryan got it to work > at some point, some how, with patches) > > > Do you log into a jhbuild session? as yourself? as a test user? Do you > replace system level components? With 'make install'? > I do the quickest, dirtiest, and sloppiest thing: > > alias %configure="./configure --prefix=/usr --sysconfdir=/etc > --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info > --libdir=/usr/lib64" > > and then make install. Sometimes as a test user, but usually as myself. > > > 3 seems like a place where we can make progress - the vague idea I have > is: > > > > - Move our standard install location back to /opt > I actually like things going to /usr with the same flags as the distro > packages so I can get things running pretty much the same way as > downstream when i'm testing things. granted i realiize that makes > some people cringe. > > > - Have utility scripts that set up a test user > > - Have hotkeys that switch directly back and forth between the main > session and the test user session and respawn the test session > I guess that will help for some cases, but a lot debugging (especailly > for gnome-shell) really works better with a second machine. I realize > that's not always feasible, but in some cases it's 100x easier. Even > when doing app development. Clearly we should make the single system > case work as well as possible, but i pretty much always try to have > two machines with me if i'm doing development or debugging (even if > it's two laptops at a coffeeshop) > > --Ray > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
On Tue, 2015-07-21 at 03:00 +0100, Alberto Ruiz wrote: > Are there specific reasons why KVM doesn't cut it for shell > developers? GPU access? As mentioned in the original mail, there are two main issues: A) Indirection from the hardware: network, sound, monitors, webcams, bluetooth, touchscreens, GPU, etc. A lot of work on the core of GNOME is hardware integration work. I don't think we can advertise running in a VM as *the* way to develop the next version of GNOME. B) We simply don't have a good hacking environment for full operating system tree development. gnome-continuous is not really set up for making local changes and is also significantly harder to understand than jhbuild. Right now, the best path for hacking gnome in a VM is running jhbuild inside the VM, with quite a bit of a speed and convenience penalty. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
Hello Michael, Another problem I didn't mention which is that sometime the checkout dir makes "make" go bonkers at some point even with jhbuild build -fac. It is quite often that I update my jhbuild setup after ages of not touching it and I have to basically "rm -rf * && git reset --hard" and configure again to get the build going again. Given how long it takes to jhbuild everything this is another extremely annoying point that we can't ensure won't hit people. You can't leave the thing building and go make a coffee, you have to work for the automation system instead of the other way around. It is really a disaster if you ask me that we enforce this on every GSoC student :/ Anyhow, why is it such a problem to resort to the latest buildable snapshot to work on a very specific modules? So say this libgit2 problem for instance: something broke in one module, I work on... say gedit. That depends on it. What are the chances of my modifications having a dependency on the stuff that was introduced while that module broke? the master/HEAD of any given module should most of the time just build fine with any latest buildable snapshot of the whole moduleset. There was a time at which I used GARNOME (a script that grabbed all the latest tarballs) and only CVS/SVN on the module I cared about because that was the most reliable way to get everything to build without issues and just focus on my module. I guess the bit I don't understand is, why do we have to think in terms of "making jhbuild more like Continuous"? What's missing from Continuous to cover all the jhbuild usecases? 2015-07-21 2:23 GMT+01:00 Michael Catanzaro : > On Tue, 2015-07-21 at 02:04 +0100, Alberto Ruiz wrote: > > Relying on jhbuild from my point of view is a waste of everybody's > > time, we've got all these developers building the same version of the > > same module in the same architecture again and again and again, to > reach > more or less the same state, all the people who give up on > writing a > patch or testing master everytime a module breaks (like the > latest > libgit2-glib issues for example) is a precious resource we're > wasting for > not having the right infrastructure. Up to the point of > glib or gtk+ is > kinda handy but beyond that is almost impractical. > > The problem is that we have no way to make sure our modules are always > in a buildable state. It's not impractical and it wouldn't even be > particularly difficult, the result would look awfully like GNOME > Continuous, building each jhbuild module in containers a few important > distros; it's just a challenge nobody has had time to attempt yet. I > was hoping GNOME Continuous would help with this, but the problem is > that Continuous is completely separate from jhbuild so they can have > different build issues; when an issue is detected in Continuous, it > isn't fixed in jhbuild; and Continuous isn't a jhbuild replacement. I > think our need is Continuous for jhbuild. > > In the meantime, all it takes to avoid the libgit2-glib situation is > for someone to take a few minutes to roll back the module to an older > version [1][2][3]. My bad for not doing this immediately when I noticed > the problem; I wanted to give the developers some time to fix the > issue, but in hindsight that was wrong; these issues must be addressed > immediately since they block contributors from working on GNOME. > > The other issue with jhbuild right now is a circular dependency problem > between, erm, g-i, vala, and... something else, I forget, which causes > everything to fail for new users but work fine for existing users. This > sucks. To avoid this, we need a dependency that says "build this module > eventually after building me" or "build me eventually after building > this other module," which we don't currently have. (I thought it was > "after" but that's something else.) > > [1] https://git.gnome.org/browse/jhbuild/commit/?id=baa893595c98900e069 > 8dab2286953e0a5d723db > [2] https://git.gnome.org/browse/jhbuild/commit/?id=661878b5ca0a1a97fed > 1f5f61ecaa5991bf870d5 > [3] https://git.gnome.org/browse/jhbuild/commit/?id=b651a03d8f1f7b7e2c3 > ccd56de25ea42c2b2b9f6 > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
On Tue, 2015-07-21 at 02:04 +0100, Alberto Ruiz wrote: > It'd be really nice if we could team up with the people working on > container technology so that we were able to run a full GNOME session > within a container. Even if it was privilleged. I'm intimidated by the amount of work there. For each system service that GNOME interacts with: systemd, logind, polkit, bluez, gdm, NetworkManager, cupsd, and so forth, you have have to choose between tunneling it through or having a version of the daemon running within the container that somehow plays nice with the host system. systemd -nspawn, which is used to test systemd goes with the "plays nice" approach Not impossible but Hard. It would be interesting if anybody has experience with getting something along these lines working. [...] > Relying on jhbuild from my point of view is a waste of everybody's > time, we've got all these developers building the same version of the > same module in the same architecture again and again and again, to > reach more or less the same state, all the people who give up on > writing a patch or testing master everytime a module breaks (like the > latest libgit2-glib issues for example) is a precious resource we're > wasting for not having the right infrastructure. Up to the point of > glib or gtk+ is kinda handy but beyond that is almost impractical. I agree that the jhbuild process is a waste but gnome-continuous as it exists currently doesn't provide an alternative. There's no provision for downloading remote build artifacts, and then building just some modules locally. And some of the things that were done to make gnome -continuous robust - like assembling a build root from scratch for each build and building each module from scratch - make it much slower and more resource intensive for local hacking than jhbuild. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
On Tue, 2015-07-21 at 03:11 +0100, Alberto Ruiz wrote: > Another problem I didn't mention which is that sometime the checkout > dir makes "make" go bonkers at some point even with jhbuild build > -fac. It is quite often that I update my jhbuild setup after ages of > not touching it and I have to basically "rm -rf * && git reset - > -hard" and configure again to get the build going again. Given how > long it takes to jhbuild everything this is another extremely > annoying point that we can't ensure won't hit people. You can't leave > the thing building and go make a coffee, you have to work for the > automation system instead of the other way around. It is really a > disaster if you ask me that we enforce this on every GSoC student :/ Perhaps the ideal solution would be to decouple the dependencies. When I'm trying to fix up some mail protocol back end in Evolution, I really *shouldn't* need to upgrade my entire system to the very latest glib/gtk+ and then upgrade a whole bunch of *applications* which for some reason don't work with the new libraries. In this thread we're talking about tooling to *help* me set up a container with that full set of upgraded stuff, but we seem to be missing the point that in an ideal world I shouldn't need it at all. (It doesn't help that we don't have symbol versioning, so the distro packaging has a lot of dependencies wrong, of course. So just running 'dnf --releasever=rawhide update gnome-foo' tends to break.) I often actually find myself testing on the *stable* branch of evolution-data-server, then committing blindly to master. Which is entirely the wrong way round. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
