Re: Windows runner for CI now generally available!
On Tue, Nov 19, 2019 at 10:49 AM Carlos Soriano via desktop-devel-list wrote: > > Hi everyone, > > Good news! Thanks to OpenAtMicrosoft and our staff we have set up a Windows > runner for the GNOME/ group. Right now it's a single runner with the > "windows" tag attached, feel free to use it as you see fit. Is there any documentation for the runner? Like which executor is used, what is installed on it and where, can it handle parallel builds etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gtk-Doc Manual in DevHelp
On Sat, Aug 11, 2018 at 12:28 PM, Lanoxx wrote: > Hi All, > > It would be nice if I could get some response about my question from the > community. I spend several days of work on this and I would like to know if > there is a change that my patch gets merged into Gtk-Doc. I am restating my > question in case it was not clear from my original mail what I was asking: It's probably best if you create a new gtk-doc merge request with this change as in the end the gtk-doc maintainers have to decide. > Does anybody have objections on merging my patch which installs the GTK-Doc > Manual as HTML so it can be read via DevHelp? I haven't looked at the patch, but having the manual in devhelp seems good to me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python 2 support in GNOME build tools
Thanks everyone for chiming in! I think we have all distros/OSes covered now and can make an informed decision based on that. I've opened a proposal MR for glib to drop Python 2 support https://gitlab.gnome.org/GNOME/glib/merge_requests/196 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python 2 support in GNOME build tools
On Sun, Jul 15, 2018 at 3:25 PM, Nicolas Dufresne wrote: > Stable distribution shouldn't block software from going forward with > Python 3. Simply because stable OS won't update to whatever we release > next, unless it's bug/security fixes. I agree in general, but as I noted at the end of my mail, RHEL 7 does get non-bugfix/security updates nowadays. And from what I see many of the people working on those updates also work on GNOME and we should try figuring out what they need before potentially making their lives harder. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python 2 support in GNOME build tools
> Slow-releasing/stable/"enterprise" distributions like RHEL, Debian, > Ubuntu LTS and SLED are the usual sticking point for dependency versions. > > My understanding is that the main blocker for using Python 3 is > that RHEL/CentOS 7 doesn't have it built-in, only as part of a secondary > "software collection"? Yeah, that's also what I heard when the topic came up on IRC, but similarly vague re RHEL.. :) > For what it's worth, requiring Python 3 would be no problem from Debian's > perspective, as long as it isn't assumed to be /usr/bin/python: for > compatibility with historical scripts, if /usr/bin/python exists then > it is always Python 2, while Python 3 is available at /usr/bin/python3 > if installed. Using Python 3 for all programs that can work in either > version is recommended, and in particular we've used Python 3 for the GLib > and GObject-Introspection build tools since Debian 9 'stretch' (2017). > > We don't normally backport the latest GNOME versions to stable releases > anyway; but if we do, the latest stable release (Debian 9 'stretch') > has Python 3.5 as its supported Python 3 version, and the one before that > (Debian 8 'jessie', 2015) had 3.4. > > Ubuntu is in about the same situation as Debian, with new LTS releases > every 2 years, although a year out of phase with Debian (the most recent > LTS releases were in 2018 and 2016 and have contemporary Python 3 versions). That's good to know, thanks! I'll try to summarize the remaining cases: Windows: I'm confident that on Windows Python 3 is enough in all cases. MSYS2 switched some months ago and all looks good. gvsbuild also uses Python 3. macOS: There still isn't any system Python 3 in sight, and could be that it never will happen. Homebrew works. SLED/SLES: They use old versions [0] [1], so unlikely that they will try to backport things now imo. I couldn't find a working package index for SLED, I assume it is similar to SLES. [0] https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=12&service_pack=&architecture=x86_64&package_name=libglib-2_0-0 [1] https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=11&service_pack=&architecture=i386&package_name=glib2 RHEL7: RHEL got a GNOME 3.26 update for 7.5 and there is a 3.28 update in the works for 7.6 [3]. Full support for 7.X ends with "~Q4 of 2019" [4] and based on the previous update intervals [5] this should mean RHEL 7.7 is the last feature release. GNOME 3.32 comes out some months before that, so it theoretically could make it into the last release. This means we can drop Python 2 definitely after GNOME 3.32, or earlier if someone from RH can rule out that 3.32 will make it into RHEL 7 (anyone?). [3] https://bugzilla.redhat.com/show_bug.cgi?id=1567375 [4] https://access.redhat.com/support/policy/updates/errata [5] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Version_history_and_timeline ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Python 2 support in GNOME build tools
Hey everyone, we currently do support Python 2 and 3 for things like gobject-introspection and glib scripts etc. and while I don't see any problem with continuing that support I'd like to know why we still need to support Python 2 there. i.e. What needs to happen so that Python 3 support is enough for everyone? Also, if anyone knows an environment where the latest releases are used with Python 2, please share them. thanks! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab CI runners for non-Linux systems
On Wed, May 23, 2018 at 9:20 PM, wrote: > Le vendredi 18 mai 2018 à 10:52 +0100, Philip Withnall a écrit : >> Hi all, >> >> Can anybody else provide and maintain CI runners for other platforms? >> I’d particularly like to see: >> • *BSD (probably OpenBSD and NetBSD) >> • macOS (ideally several versions, since we support from OS X 10.7 >> upwards[2]) >> • Android (probably a cross-build) >> • More Windows configurations (currently we have MSYS2 on Windows >> Server 2012; ideally we’d have a MinGW-w64 runner too) > > One big item missing in this list is MSVC. Since we already have a > Windows VM that does MSYS2 CI, is it possible to setup msvc on that one > too, or does it require a VisualStudio licence, or something? For the license, gvsbuild [0] builds on appveyor which uses the community edition, so I think you can get by without a license. For the MSYS2 CI, the server is a bit low on disk space (10-15GB of 40GB left) as I went for the cheaper one, and I don't want to push it to the limit really. But if someone knows how to build glib+deps with msvc and wants to collaborate feel free to contact me. [0] https://github.com/wingtk/gvsbuild ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab CI runners for non-Linux systems
On Mon, May 21, 2018 at 5:54 PM, Alan Coopersmith wrote: > On 05/18/18 02:52 AM, Philip Withnall wrote: >> Can anybody else provide and maintain CI runners for other platforms? > > Are there instructions somewhere on what's needed to do this? 1) Install the gitlab runner on a server: https://docs.gitlab.com/runner/#install-gitlab-runner 2) Fork glib on gitlab and register your runner in the forked repo settings 3) Adjust the .gitlab-ci.yml file to add a job using your runner. See Xavier's recent patch for macos for what's roughly needed there: https://bugzilla.gnome.org/show_bug.cgi?id=796343 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès wrote: > The only thing I am annoyed at is this forking workflow. Both as a > contributor, and as a code committer/reviewer. Having to fetch a new > remote for every single-commit contribution out there is terrible. In case you didn't know, just like with github you can fetch the PRs from the main remote if you adjust the git config accordingly: https://docs.gitlab.com/ce/user/project/merge_requests/#checkout-merge-requests-locally $ git fetch $ git branch -a # look for PR branch $ git checkout origin/merge-requests/42 $ git checkout master ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 7:03 PM, Ray Strode wrote: > Hi, > > On Tue, May 16, 2017 at 12:20 PM wrote: >> >> Another issue we haven't discussed yet is commit permissions. Right >> now, everyone can commit anything to every repository, but with GitLab >> we'll probably eventually want something more fine-grained where >> *active* maintainers have more control over who is allowed to commit. > > uhh, why? I think the lack of fine grained ACLs is an extremely useful > feature of our current setup. Are you concerned we might grow abusers at > some point? It's quite hard to get commit access atm because you have to be trusted initially. If a maintainer can give commit access to one repo he/she watches anyway there is less trust needed in the beginning. Or if a new contributor wants to take over an abandoned project. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
pygobject: Plan to depend on a new pycairo fork
Hey, I'm trying to establish a pycairo fork as a new upstream and I'm planing to depend on it in upcoming versions of pygobject: https://pycairo.readthedocs.io https://github.com/pygobject/pycairo https://github.com/pygobject/pycairo/releases For the cairo mailing list thread see: https://lists.cairographics.org/archives/cairo/2017-April/027919.html >From a distributions POV the main changes are that it uses distutils as build system, can build Python 2 and Python 3 versions from the same source, and is licensed under MPLv1.1+LGPLv2.1. The new versions are API/ABI compatible to the 1.10.0 releases of both py2cairo and py3cairo. This includes the patched version of py3cairo currently in Debian/Ubuntu. One issue with Debian is that it still uses py2cairo 1.8.8 and py2cairo broke ABI between 1.8.8 and 1.8.10 and all other distributions have moved on to 1.10.0 by now. There are 8 packages directly affected by the ABI break: https://codesearch.debian.net/search?q=Pycairo_IMPORT I assume a transition is required here. Depending on a newer version would require pycairo to be added to jhbuild, as it is currently a sysdep. Since the new versions is distutils based, this is straight forward. Distributions building the Python 2 version with xpyb support (Fedora for example) can pass "--enable-xpyb" to "setup.py build" to enable it. MSYS2 has switched to the new version: https://github.com/Alexpux/MINGW-packages/pull/2390 Emmanuele Bassi has switched gnome-continuous: https://git.gnome.org/browse/gnome-continuous/commit/?id=80ce62a6 I'd appreciate any feedback and I encourage everyone to switch to this new version and report any problems on the github bug tracker. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GJS documentation browser: follow up and hosting
On Tue, Jun 28, 2016 at 8:40 AM, wrote: > Good point. Do you know if those pages are static or if there is a webapp > behind them? vala is php [0], pygobject [1] is static [0] https://github.com/flobrosch/valadoc-org [1] https://github.com/lazka/pgi-docs ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Power switch to actually turn off my computer
On Thu, Apr 10, 2014 at 11:51 AM, Charles T. Smith wrote: > I've spent an hour or so looking around /usr/lib/python/site-packages/gtweak > and haven't found what it does yet... it occurs to me that one shouldn't > have to reverse engineer a tool in order to learn how to configure something > ... > > Can anybody point me to the configuration files which are relevant? "org.gnome.settings-daemon.plugins.power button-power" in dconf ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python Docs (was Re: Coordination for developer documentations)
On Mon, Mar 10, 2014 at 4:27 AM, Simon Feltman wrote: > On Sat, Mar 8, 2014 at 9:15 AM, Christoph Reiter > wrote: >> On Sat, Mar 8, 2014 at 4:04 AM, Simon Feltman wrote: >>> * GI function argument interpretation for Python docs would be as >>> close as possible to pygobject by having the argument translation code >>> living in pygobject itself. Preferably we could expose pygobjects >>> internal argument caches which already have all the translation logic >>> applied and re-use this for the docstrings. This has the benefit of >>> lowering maintenance cost by ensuring the documentation for function >>> arguments is in lockstep with how pygobject actually works. >>> >>> * Overrides and Python specific API extensions would automatically be >>> included in the docs. >> >> (This is mainly the reason why I think Python introspection + Sphinx is >> better in the long run than something like g-ir-doctool.. for the Python >> bindings at least) >> >> This should be possible with the current Sphinx based approach but still >> needs some work (it only shows the correct override signature atm). I need >> to handle the following cases somehow: >> >> * In case the functionality of the overidden function differs from the >> original one it should be possible to replace the gir documentation >> all together. > > In terms of overrides having additional side effects beyond the > intended GI API, I really hope we can deprecate those scenarios or > additional arguments that invoke new/alternate behavior (like > Gtk.MessageBox's "buttons" argument). It doesn't seem like there are > very many of these cases and I'm not sure if the deprecations would help > ease documentation or makes it more complex though. But I wouldn't > mind leaving doc strings for deprecated functionality out granted > usage of the function called as specified by a GI generated doc string > works in a backwards compatible way (similarly I think we should > ignore arguments/doc overrides for deprecated GObject initializers). I was mostly thinking of functions returning "(ok, result)" which gets translated to "result or None". For other stuff, please keep in mind that documentation can also be used for understanding old code, so I wouldn't just ignore and hide them. I'd prefer deprecation warnings in the docstring with instructions how to do it right in those cases. >> * In case the override just adds some additional arguments or default >> values it should be possible to include the gir docs in the override >> docstring (something like "%INCLUDE%" which gets replaced) > > That sounds like a good idea. A bit of bike-shedding, but I think a > more explicit name would be nice. Something like > "%gi_doc_string_body%" or variations on that which may or may not > include argument documentation? Sure. >> * In case the override uses "*args, *kwargs" because of backwards >> compatibility or because argument processing is delegated to some helper >> function it should be possible to define a Python signature which replaces >> the real one as seen by Sphinx. > > Do you mean the doc generator could figure this out or that we make > sure to manually add doc strings in these cases? No, that needs be done manually somehow. Sphinx already supports such function signature overrides in docstrings (for C extensions I guess), but that clashes with the signature pgi exposes for type information, so I need to find another way. >> Once I have this working with pgi, I will try to move the override changes >> needed to PyGObject. > > Sounds great. I would like to go through the existing override doc > strings at some point and update them for better compatibility with > Sphinx/reST. Would this be helpful or would it be in conflict with > what you are thinking? (at least the Python only extensions like > Property and Signal should be well formatted). Sure, that would be helpful. >>> * Better developer workflow. By using Python doc strings, we >>> automatically integrate with all of the awesome Python developer tools >>> and things like doc tips in IDE's should just work. >> >> Is there any IDE/editor which supports some sort of auto completion for >> PyGObject right now (using the gi.repository import hook)? > > I was a bit overzealous with that statement. "should just work" is at > least true in ipython standalone or integrated with eclipse/pydev > (which is good enough for me at the moment). Eclipse nor Anjuta work > for editor auto-completion with import hooks. At a cursory glance, > Eclipse seems want to
Re: Python Docs (was Re: Coordination for developer documentations)
On Sun, Mar 9, 2014 at 11:35 PM, Stefan Sauer wrote: > devhelp is basically the index.sgml (ignore the sgml extension, it is > not) + prerendered html. devhelp does not do anything with the link in > the html doc, except trying to follow them when one is clicked. OK, thanks for the clarification ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python Docs (was Re: Coordination for developer documentations)
On Sat, Mar 8, 2014 at 4:04 AM, Simon Feltman wrote: > That would be helpful. I think it would be nice to integrate your work > (or abstracted parts of it) with pygobject itself. > > An idea that has been cooking in the back of my mind (and to a very > small degree has been realized with pygobject's function signature > docs) is to have pygobject handle documentation by filling out Python > doc strings lazily when accessed. This would of course require > developers to have either gir files installed or preferably devhelp > could ship sgml (or mallard?) files which are accessible to tools > outside of devhelp (or devhelp provides some sort of API if it doesn't > already). Sounds good to me. > I think the benefits to an approach like this could be fairly significant: > > * GI function argument interpretation for Python docs would be as > close as possible to pygobject by having the argument translation code > living in pygobject itself. Preferably we could expose pygobjects > internal argument caches which already have all the translation logic > applied and re-use this for the docstrings. This has the benefit of > lowering maintenance cost by ensuring the documentation for function > arguments is in lockstep with how pygobject actually works. > > * Overrides and Python specific API extensions would automatically be > included in the docs. (This is mainly the reason why I think Python introspection + Sphinx is better in the long run than something like g-ir-doctool.. for the Python bindings at least) This should be possible with the current Sphinx based approach but still needs some work (it only shows the correct override signature atm). I need to handle the following cases somehow: * In case the functionality of the overidden function differs from the original one it should be possible to replace the gir documentation all together. * In case the override just adds some additional arguments or default values it should be possible to include the gir docs in the override docstring (something like "%INCLUDE%" which gets replaced) * In case the override uses "*args, *kwargs" because of backwards compatibility or because argument processing is delegated to some helper function it should be possible to define a Python signature which replaces the real one as seen by Sphinx. Once I have this working with pgi, I will try to move the override changes needed to PyGObject. > * Better developer workflow. By using Python doc strings, we > automatically integrate with all of the awesome Python developer tools > and things like doc tips in IDE's should just work. Is there any IDE/editor which supports some sort of auto completion for PyGObject right now (using the gi.repository import hook)? > * Tools like Sphinx [1] could be used to generate html docs by > pointing it at the "gi" Python package. In a similar vein, I realize > Christoph's pgidocgen uses gir files translated to reStructuredText > which is then run through Sphinx (please correct me if I'm wrong > here). In a limited form "pointing it at gi" should work then. It doesn't handle import hooks afaik, so you would still have to generate rst files with all autodoc references in them. Maybe provide it as a helper in PyGObject similar to sphinx-apidoc. This is basically what pgi-docgen does + adding docstrings. In addition I've tried to hide the existence of overrides while still exposing the user facing interfaces. > * By using Sphinx, we also get direct references back to the Python > docs [2] for native Python constructs (as is realized with Christoph's > docs, although I'm not sure if it is Sphinx or pgidocgen doing that). This is possible through the Sphinx intersphinx extension [0]. Sphinx creates a "object.inv" [1] file which can be used by other sphinx based projects to resolve references. This is, as you've said, used to link to the official python documentation + the pycairo docs (see Gtk.Widget.draw() [2] for example). It's also used in Sebastian's GTK+3 tutorial to link to the API reference itself. > * We could integrate Sebastian's Python GTK+ tutorials which are > written in reST by moving them into pygobject. Since GNOME projects > are mirrored on github, I think they could still be pushed to > readthedocs if we want that. > > * Testing of example code. Another possibility is to have Python > specific versions of the developer doc examples living under a > sub-folder of pygobject (preferably in Python's "doctest" format > [3]). These could be pulled into the docs given the examples have some > type of unique tag in the xml source. They could then be run as part > of the pygobject test suite to ensure they are working Python. > > * Sphinx also seems to supports devhelp output (among other formats) > which is interesting in that we might be able to achieve a similar > look and feel with the rest of the GNOME developer docs. I've tried the devhelp export and it seemed to work quite well for the all in one API docs. But I'm not sure how
Re: Coordination for developer documentations
On Thu, Mar 6, 2014 at 11:37 AM, Ekaterina Gerasimova wrote: > On 6 March 2014 10:07, Christoph Reiter wrote: >> Since it wasn't mentioned so far; outside of gnome.org, on the Python >> side of things, there exists the GTK+ 3 tutorial [0] maintained by >> Sebastian Pölsterl (accepts pull requests, but isn't actively working >> on it [1]) and the gi api reference [2], which I actively maintain. > > I have been using these recently and am very keen to see them on > developer.gnome.org. There is a developer experience hackfest[3] > coming up at the end of April which would be a perfect time to make > that happen, is there any chance that you could make it? Sorry, can't make it, but I'm willing to help in that regard. I can write up a project status/roadmap if that helps. >> There doesn't seem to be a dedicated IRC channel, so I'm idling in >> #docs-devel now > > At the moment, we use #docs for everything. OK, thanks. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Coordination for developer documentations
(responding to the wrong mail since I just subscribed and don't bother modifying mail headers..) Since it wasn't mentioned so far; outside of gnome.org, on the Python side of things, there exists the GTK+ 3 tutorial [0] maintained by Sebastian Pölsterl (accepts pull requests, but isn't actively working on it [1]) and the gi api reference [2], which I actively maintain. There doesn't seem to be a dedicated IRC channel, so I'm idling in #docs-devel now [0] http://python-gtk-3-tutorial.readthedocs.org [1] http://github.com/sebp/PyGObject-Tutorial/issues/35 [2] http://lazka.github.io/pgi-docs/api/Gtk_3.0/classes/Container.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
