gedit crowdfunding
Hi, There is now a crowdfunding for gedit! See my blog post: https://swilmet.be/blog/2020-10-13-gedit.html The link to Liberapay: https://liberapay.com/gedit/ I plan to write blog posts more frequently about gedit, and around gedit (the work that I do in related libraries). - I've posted the news on Discourse too: https://discourse.gnome.org/t/gedit-crowdfunding/4518 GNOME is migrating from the mailing lists to Discourse, but probably not everybody thinks about going to Discourse. Thanks, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Wrong links in the gnome developer documentation
Hi, On Mon, Mar 23, 2020 at 09:59:12PM +0100, Uwe Scholz wrote: > where can I ask for correction of wrong links in the gnome developer > documentation? > > In particular, I wanted to report that various links on > https://developer.gnome.org/gtk3/stable/GtkFileChooserButton.html are > pointing to the gtk4 version of the documentation. This is wrong > and gives always a "Not Found" error. The API docs on https://developer.gnome.org/ are generated by library-web: https://gitlab.gnome.org/Infrastructure/library-web In this case (and in a lot of cases), it's the gtk-doc fixxref that is wrong. By the way, if you don't know it already, there is the Devhelp app to read the API docs locally in a more convenient way: https://wiki.gnome.org/Apps/Devhelp Good week-end, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkSourceView 4.0 released
On Mon, May 07, 2018 at 09:03:22AM +0200, Jens Georg wrote: > > GtkSourceView 4.0 has been released with GNOME 3.28 in March. It still > > depends on GTK+ 3. The port is trivial (it's mostly just getting rid of > > deprecated APIs): > > https://developer.gnome.org/gtksourceview/stable/porting-guide-3-to-4.html > > For my asurance: For very basic use (i.e. using it as a drop-in for > GtkTextView > that does Syntax highlighting) the porting effort should be just moving to > gtksourceview-4 dependency, if I understand this correctly? Yes. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GtkSourceView 4.0 released
Hi, GtkSourceView 4.0 has been released with GNOME 3.28 in March. It still depends on GTK+ 3. The port is trivial (it's mostly just getting rid of deprecated APIs): https://developer.gnome.org/gtksourceview/stable/porting-guide-3-to-4.html In gnome-build-meta I see the following modules still depending on GtkSourceView 3: - gedit - gitg - gnome-builder - gnome-calculator - sushi I will not continue to maintain GtkSourceView 3 eternaly… Cheers, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Create high-level UI widget library
On Tue, Apr 24, 2018 at 06:38:36PM +, Victor Malov wrote: > I think there is need for some high-level UI library, based on GTK, which > will provide ready-to-use widgets for Gnome Desktop and applications > willing tightly integrate into Gnome. It depends on what you need, but there are already a lot of libraries available in GNOME providing higher-level APIs than what GTK+ provides. See: https://developer.gnome.org/platform-overview/unstable/ (but it doesn't mention all GNOME libraries). > The reasons for this are the following: > 3. Instead of reinventing similar widgets all around different Gnome apps, > gives unified and reusable set. > 4. Choice for developers - create their custom widgets or use default ones. I totally agree with the above two reasons. For certain kinds of apps, I also think that there has been a lot of wheel reinventing over the years. Some new GNOME apps are created almost from scratch, while in 2005 there was already a lot of choice for those kinds of apps (I'm thinking for example about music players and image/photo viewers). For text editors and IDEs there has been also a lot of wheel reinventing, it's for that reason that I've added more features to GtkSourceView, and created new libraries like gspell and Tepl. See: https://wiki.gnome.org/Apps/Gedit/ReusableCode I'm doing the same for Devhelp, from the roadmap: https://wiki.gnome.org/Apps/Devhelp/RoadMap "Move almost all the code in the library, to have a high-level API" So you can see that in some GNOME areas there is already an effort to make more code re-usable, creating higher-level APIs, etc. I think each GNOME application should have its own shared library (like libdevhelp for the Devhelp application), to write the code in a re-usable way (the implementation is also cleaner that way), to reduce wheel reinventing over time. Having a well documented library also permits to better understand the codebase for someone new to the project, it lowers the barrier to entry. A re-usable class is also easier to test independently of the application. There are basically a lot of benefits by writing a library. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab, moving non-GNOME projects currently hosted on git.gnome.org
On Thu, Feb 15, 2018 at 11:57:07AM -0600, Michael Catanzaro wrote: > On Thu, Feb 15, 2018 at 10:23 AM, Sébastien Wilmet > wrote: > > Isn't there a better solution? What do you recommend? > > FWIW, the GNOME group already contains a *lot* of modules that are not > "Projects tracked as part of official or extra GNOME release sets and > releases" so the simple solution is to pile on and add them there. What > projects are you talking about? Stuff like gnome-latex should be fine. Yes, gnome-latex and tepl. So OK, they can be migrated to the GNOME group, good to know. Maybe the description of the group can be improved. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GitLab, moving non-GNOME projects currently hosted on git.gnome.org
Hi, I would like to move all the projects I maintain to gitlab.gnome.org. Currently those projects are hosted on git.gnome.org, but not all of them are officially part of GNOME. When looking at: https://gitlab.gnome.org/explore/groups the best group that fits is "Incubator", but I'll probably not setup CI directly. "Incubator" is also a strange name for a 9-years old stable project. I could put those projects on my personal namespace: https://gitlab.gnome.org/swilmet/ but I don't like that because in the future there can be other maintainers, I don't want to link the project with me. On git.gnome.org all the projects were located in a neutral location: https://git.gnome.org/browse/ There were no groups. It was just a flat list, the groups were defined in the *.doap files. Now on GitLab with the groups, each time that a project is moved from one group to another, the URLs change, and everybody needs to adapt the git remote in their local clone. Isn't there a better solution? What do you recommend? Thanks, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Mon, Feb 12, 2018 at 07:08:34PM -0600, mcatanz...@gnome.org wrote: > I want to remove gnome-common from our BuildStream projects, but a few > modules are still depending on it: gcr, gnome-autoar, libnotify, > adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas. The list is not complete, there is for example gedit as well, I think it was common to *not* list gnome-common as dependency in the jhbuild modulesets because libraries like gtk was already depending on it. Also, I think it's a bit a waste of effort to first port to autoconf-archive macros, and then porting to meson just a few development cycles later. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
On Fri, Jan 26, 2018 at 12:17:56PM +0100, Niels De Graef wrote: > Yes, it is already on version 10.4. > > You can check the current version on https://gitlab.gnome.org/help > (also available by clicking your avatar on the upper-right corner and > clicking "Help"). Ah great. When we are not signed in we don't see the version number. But now that I'm signed in, indeed we cannot miss the information :-) -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
Hi, Is gitlab.gnome.org already using GitLab 10.4 with the rebase + fast-forward? https://about.gitlab.com/2018/01/22/gitlab-10-4-released/#rebase-and-fast-forward-in-ce On gitlab.gnome.org I don't know where or if we can see which GitLab version is used. Thanks, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Release team now using gnome-build-meta repository, not JHBuild
On Wed, Jan 24, 2018 at 02:28:26AM +0200, Alberts Muktupāvels wrote: > Sorry if that already is posted somewhere, but is there at least some kind > of migration guide/tutorial? See the first e-mail of this thread. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Transmitter - GUI for transmission-daemon and transmission-remote
On Sat, Dec 30, 2017 at 06:46:38PM -0500, Patrick Griffis via desktop-devel-list wrote: > and you already get the free infrastructure with the GNOME gitlab now I think that gitlab.gnome.org alone is not sufficient to host a project, for example is there a way to upload tarballs? I think that new maintainers like Felipe need to ask for an account here: https://wiki.gnome.org/MaintainersCorner As long as the project meets the prerequisites: https://wiki.gnome.org/Projects/Prerequisites There are many projects hosted on gnome.org which are not officially part of GNOME. A bittorrent GTK+ client is definitely the kind of project that makes sense to host on gnome.org. But GNOME has two categories: core and apps. For example for the latest release: core - https://download.gnome.org/core/3.27/3.27.3/NEWS apps - https://download.gnome.org/apps/3.27/3.27.3/NEWS A bittorrent client could be part of apps, no? In that category there are games, an IRC client, developer tools, even a hex editor and gnome-multi-writer (some niche applications), so why not a bittorrent client? The boundary seems arbitrary. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Spell-checking, porting modules to Enchant 2
Hi, Enchant has a new maintainer (Reuben) and the project is again under development. Enchant 2 is available since several months (the last version, Enchant 1.6, was released in 2010). I've ported gspell to Enchant 2, this didn't require any code change at all. In most cases porting to Enchant 2 is straightforward. So if you maintain a module depending directly on Enchant, think about porting it to Enchant 2 (or gspell). https://abiword.github.io/enchant/ (new website) https://www.abisource.com/projects/enchant/ (old website) https://wiki.gnome.org/Projects/gspell Cheers, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Meson feedback as a user - AX_COMPILER_FLAGS
On Sun, Jul 02, 2017 at 05:29:21PM +0200, Sébastien Wilmet wrote: > The same for compiler flags, with the Autotools there is the > AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed > in each GNOME module. I've opened this issue to have the equivalent of AX_COMPILER_FLAGS in Meson: https://github.com/mesonbuild/meson/issues/2609 -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor
On Fri, Nov 24, 2017 at 03:16:09PM +0900, Tristan Van Berkom wrote: > Had not considered this use case yet, thanks ! > > I'm an emacs user but have never used any kind of symbol completion > feature myself. > > For this, one could use `bst checkout` to get a full checkout of the > build outputs which your element (module) of choice depends on, and > then periodically delete / re-checkout your sysroot checkout when it > starts to get out of date (or make parallel checkouts for separate > projects). > > However currently this is a slow operation which uses a lot of disk > space. Since it is an export of the built artifacts, we dont risk using > hardlinks for the checkout, because that leaves the user in a position > where they can accidentally corrupt their local artifact cache. > > I have been considering adding some explicit switch like `--unsafe` to > the checkout command to allow users to do this "at their own risk", but > haven't really found a use case to justify this, maybe you just > provided one ! As Christian explained, the text editor plugin also needs the list of CFLAGS, especially the -I's. With Meson the easiest is to read the compile_commands.json file created at the root of the build directory. See: https://clang.llvm.org/docs/JSONCompilationDatabase.html CMake can also create a compile_commands.json file. With the Autotools/make, the Vim plugin that I use provides a script to extract the CFLAGS while `make` is running: $ make CC='~/.vim/bin/cc_args.py gcc' this creates a .clang_complete file containing the list of CFLAGS. See: https://github.com/Rip-Rip/clang_complete/ > Philip's reply is also a possibility but I would prefer recommending > something via BuildStream, mostly because you want to use exactly the > header files that you need for your target environment, but also > because there is no guarantee that a flatpak SDK will even have headers > for the dependencies you might want to use. Yes the Flatpak SDK doesn't contain all dependencies. > For the moment, I've added this issue[0] to make sure we dont lose > sight of this, in any case it should be very easy to implement. > > [0]: https://gitlab.com/BuildStream/buildstream/issues/162 OK, it's a good news if it's easy to implement. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor
Hi, I've tried a little BuildStream, but I think I'll hit a problem if I don't use jhbuild anymore: have clang completion in my preferred text editor, it needs all the *.h files of dependent libraries. Currently those *.h files are either installed by Linux distro packages, or by jhbuild in the jhbuild install prefix, in all cases they are available on the host. With BuildStream the *.h files are inside the container, so I would need to run the text editor inside a bst shell to be able to access the *.h files and have C completion, if I understand correctly. When you need to hack on a C/C++ project with a text editor like Vim or Emacs, how are you doing it with BuildStream? Thanks, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Include GNOME Usage in the future releases
On Wed, Oct 18, 2017 at 12:11:02PM +0200, Felipe Borges wrote: > On Wed, Oct 18, 2017 at 11:57 AM, Sébastien Wilmet wrote: > > Is it really a chicken-egg dilemma? Are the crashes and bugs specific to > > some hardware or underlying software configuration? Or are the bugs > > always reproducible by the maintainer? If it's the latter, I don't see > > why it is a chicken-egg dilemma, you have everything in hand to write > > (mostly) stable software from day 1. > > Right, because everything just works on GNOME, right? You didn't answer my question, I suppose the bugs in Usage are reproducible by anyone. Some developers work too quickly and as a result there are more bugs. Personnally I prefer to work more slowly, taking the time to do things right, documenting correctly the code and the APIs, writing unit tests and so on. Another best-practice is to not proceed by trials and errors: before executing the code, you must be sure that it is correct and that it'll work. > Anyhow, Usage has been developed by one of our interns in Red Hat. > Petr is 19 years old and has been super excited about the opportunity > to work with us. I took the lead to right to mail lists and speak in > the name of the project because he feels insecure and demotivated to > do so, you know, the free software community can be pretty harsh and > rude to newcomers. Why didn't you say that in your first email? I thought it was you who wrote Usage, and since I know you're around in GNOME since quite some time, I think my comment was appropriate, at least it would make you think about the issue: yes, most of the time, if the developer tests correctly its own code, it's possible to write mostly bug-free software, when following a good methodology and taking the time to do things right, instead of always working in a hurry. I know that beginners more often proceed by trials and errors, and that's not a good practice. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Include GNOME Usage in the future releases
On Mon, Oct 16, 2017 at 05:47:29PM +0200, Felipe Borges wrote: > On Mon, Oct 16, 2017 at 5:19 PM, Adrien Plazas > wrote: > > During my quick test I encountered many crashes. The application would > > benefit from broader testing and including it as a demo version in a GNOME > > release would clearly bring, but having it part of a GNOME release means > > branding it to the end users. I would suggest to first get the app in a > > more stable test by promoting its usage inside the community before even > > discussing whether it should be part of a GNOME release or not, at least > > for the next month. > > Yes, that's a chicken-egg dilemma. Usage hasn't been tested by many users > so far and we the main motivation of this email was to promote it to a > broader audience. Is it really a chicken-egg dilemma? Are the crashes and bugs specific to some hardware or underlying software configuration? Or are the bugs always reproducible by the maintainer? If it's the latter, I don't see why it is a chicken-egg dilemma, you have everything in hand to write (mostly) stable software from day 1. -- Sébastien ___ 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 Mon, Sep 25, 2017 at 09:03:00PM +0200, Tobias Mueller wrote: > On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > > By attaching a patch to a bugtracker ticket, we loose the information of > > > the parent commit: where the commit has been initially created in the > > > git history. > > If the patch is created by git format-patch, it contains the hash of > > the parent, so git knows the original parent > I couldn't find the hash of the parent commit in my git format-patch > exported patch, e.g. https://bug778584.bugzilla-attachments.gnome.org/a > ttachment.cgi?id=345698. > Do I need to do anything special in order to export the parent also? > The man page for git-format-patch does not show anything useful for > "parent". It contains the hashes of the parent *objects*: typically it refers to the last time that the file was modified. But a patch often depends on more recent changes made in *other* files, for example when calling a function of another class that was recently implemented or changed. So there is a loss of information when creating a patch with git format-patch, at least with the default parameters. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Build and run gnome-shell in a Docker container
Hello Reto, On Sat, Sep 23, 2017 at 10:40:04PM +, Reto Kaiser wrote: > I'm new to gnome, and it took me quite some time to build and run > "gnome-shell" with "jhbuild", but I finally made it. > > For having a reproducible environment that can be thrown away and recreated > if needed, I wanted to build and run everything in a container. My approach > works roughly like this: > > [...] It will normally be possible to use BuildStream in the near future (or does it already work?) for running gnome-shell built from git. https://wiki.gnome.org/Projects/BuildStream/ BuildStream is the future! -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Iterative API design (Was: Re: Matrix as a replacement for Telepathy)
On Fri, Aug 25, 2017 at 10:21:07AM -0500, Gary Kramlich wrote: > > Release 3.0? :) > > I know, need more hours in the day :-/ I'll spend some time this > putting together a 3.0 checklist, but it's not going to be pretty.. > > > Seriously, all that nice GObjectification cleanup does make it a nicer > > proposal as a GNOME framework. > > Yeah, unfortunately it's incomplete, and if we release now, we're just > going to have a super long 4.0 cycle too. I'd rather get through 3.0 > get the GObject based API stable and complete and then get into a > normal development cycle of feature releases again. To avoid being stuck for years with non-optimal APIs, what I do in Tepl is to release a new major parallel-installable version every 6 months if needed (and up until now it *was* needed, but it's a recent library). For more details, see the section "Iterative API design and stability guarantees" at: https://developer.gnome.org/tepl/unstable/intro.html Maybe Linux distro packagers don't really like that, but I think what is more important is that in a few years the library is still relevant, with good APIs. If the GObjectification takes several cycles, no problem, the API doesn't need to be perfect all the time, it should be an iterative process, with frequent releases (e.g. every 6 months), to apply the agile methodology. For porting applications to the new versions of the library, I think it's even easier with more frequent API breaks, because if there is a huge list of API breaks all at once, it's more difficult to port an application (a huge commit is necassary just to be able to compile the code again without errors). Basically, if it hurts, do it more often (if it is necessary): https://martinfowler.com/bliki/FrequencyReducesDifficulty.html -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 11:28:34AM -0500, Michael Catanzaro wrote: > I think what's clear right now is that Telepathy has no future and should be > immediately removed from our stack. We should have done that years ago when > maintenance ceased. Maybe Telepathy and Empathy have utility/self-contained classes or functions that would be worthwhile to keep. To ease the implementation of a new protocol, or to have some re-usable building blocks for the GUI. With the library written more as a toolkit, not a framework. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating GNOME Goals?
On Thu, Aug 24, 2017 at 09:45:18AM +0200, Daniel Mustieles García wrote: > Great, one less step. > > Then, it's ok to move this goal to the Deprecated Section? We could include > the link in the goal comments RemoveMarkupInMessages should not be moved to the Deprecated section, it should simply be "retired". The Deprecated section is for the Autotools-specific goals that are not yet done. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating GNOME Goals?
On Thu, Aug 24, 2017 at 09:20:45AM +0200, Daniel Mustieles García wrote: > have doubts about AddCodeCoverage, DistCheck. - Meson instructions should be added for AddCodeCoverage. - DistCheck is specific to Autotools. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating GNOME Goals?
On Tue, Aug 22, 2017 at 06:42:07PM +, Sriram Ramkrishna wrote: > I have gone ahead and contacted the > owners of all the GNOME Goals that were more than a year old and asked > whether they can either update the goal or retire it. You contacted me for 4 different GNOME goals, but I'm definitely not the owner of those! I'm probably just the latest person who edited those wiki pages… -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating GNOME Goals?
On Tue, Aug 22, 2017 at 11:57:27AM -0500, Michael Catanzaro wrote: > On Tue, Aug 22, 2017 at 4:46 AM, Sriram Ramkrishna > wrote: > > Has anybody looked at the GNOME Goals[1] lately? Is this still > > something that is active? I only ask as I know at least some that seem > > outdated to me. > > Most of them are outdated. I volunteered to clean this up a year ago, but > never got around to it and not likely to anytime soon. Help welcome. > > Certainly, the /ModernAutotools and /NicerBuilds goals can both be retired > as they are superseded by the port to meson goal. And there was a thread about GNOME goals on this list, Feb-Apr this year. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to change default umask in gnome 3.22?
Hello Garrett, On Mon, Aug 07, 2017 at 05:13:59PM +, Garrett R. wrote: > I login to session with GDM. I then open gedit. Documents I save all > have rw-r--r--. > > I have tried setting umask to 077 at /etc/login.defs, ~/.profile, > ~/.gnomerc, ~/.xsessionrc. None of these have any effect. > > It appears systemd now manages umask in gnome 3.22. Can someone please > describe how I can change the default umask setting? I do not have an answer to your question, but from gedit the files are saved with GIO/GVfs. I don't know if GIO takes into account the umask setting. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab migration status and roadmap
On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote: > Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools, is > up to the maintainer what to do with them. OK, and when the full migration will be done for all GNOME modules, do you already know if that script will be used to migrate the bugzilla as well? And then making the bugzilla read-only? -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab migration status and roadmap
On Fri, Aug 11, 2017 at 02:37:41PM +0200, Carlos Soriano wrote: > As usual, feel free to ask any questions in this thread or personally to > Alberto Ruiz or me, we are happy to answer. Are all the bugs on bugzilla also migrated when a module moves to GitLab? How is that handled currently? -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: developer.gnome.org and meson
On Wed, Aug 09, 2017 at 09:03:36PM +0100, Emmanuele Bassi wrote: > > (and it would be painfully slow, it takes several > > hours on my machine to generate the GTK+ docs). > > Distributions typically use something slightly more beefy than a > typical PC hardware for their builds. They have also slightly more things to build. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: developer.gnome.org and meson and devhelp
On Wed, Aug 09, 2017 at 08:33:09AM -0500, mcatanz...@gnome.org wrote: > developer.gnome.org is going to have some problems because for meson modules > 'ninja dist' does not include generated gtk-doc files in the tarball. At > least one maintainer is working around this by manually generating tarballs > with gtk-doc included instead of using 'ninja dist'. I don't recommend doing > that since that's equivalent to skipping distcheck. It's better to use > meson's dist target. developer.gnome.org is just going to have to learn to > build docs itself. > > Is anybody working on developer.gnome.org? Anyone interested in taking on > this task? Otherwise it is going to be stuck with outdated docs. When implementing this, it would be nice to take also into account the following feature request for Devhelp, to download the latest versions of the API references directly in Devhelp (something that I would like to implement in the future, I don't know when): https://bugzilla.gnome.org/show_bug.cgi?id=761284 "Have the latest stable/unstable GNOME API references" I think the need for Devhelp is similar to the need for developer.gnome.org: storing somewhere on gnome.org a list of tarballs with the docs, alongside maybe an XML/JSON/whatever file listing the tarballs with some additional info. Then library-web or Devhelp can download the XML file, then download the new tarballs, andthen do its thing. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: developer.gnome.org and meson
On Wed, Aug 09, 2017 at 03:20:38PM +0100, Emmanuele Bassi wrote: > After all, Linux > distributions rebuild the documentation when building the binary > packages anyway I see that in the gspell-doc package on Fedora 26, some html pages have links to /home/seb/jhbuild/... (a problem with the gtkdoc-fixxref config). That's my home directory :-) so definitely Fedora didn't re-generate the docs (and it would be painfully slow, it takes several hours on my machine to generate the GTK+ docs). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Meson feedback as a user
On Thu, Jul 06, 2017 at 05:41:11PM +0200, Mattias Bengtsson wrote: > On Sun, 2017-07-02 at 17:39 +0200, Sébastien Wilmet wrote: > > My main point of my email was that the Meson documentation should be > > split in two or three IMHO: > > - Simple user doc, how to build a project that uses meson; > > - Doc for developers/maintainers that want to use meson as the build > > system of their project; > > - Doc for contributors to Meson itself or developers who want to > > write a macro/function (I don't exactly know how Meson works, but I > > suppose it can be extended in some way). > > This sounds like feedback perfect for their bugtracker[0] rather than > ddl honestly. > > 1: https://github.com/mesonbuild/meson/issues Done: https://github.com/mesonbuild/meson/issues/2042 I started this thread on desktop-devel-list because I think some Meson developers hang around here. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Meson feedback as a user
On Sun, Jul 02, 2017 at 04:10:45PM +0200, Iñigo Martínez wrote: > You can also use mesonconf, which will show you all the available options, > even those present in the meson_options.txt file along with their possible > values. > > To activate those options, you can use either meson or mesonconf: > > - meson -Denable_docs=true builddir > - mesonconf -Denable_docs=true builddir > > Meson site has some more information regarding build options[0]. > > I agree with you that it would be nice to use the same name for common > options, like gtk docs, just for consistency. > > Best regards, > > [0] http://mesonbuild.com/Build-options.html#build-options My main point of my email was that the Meson documentation should be split in two or three IMHO: - Simple user doc, how to build a project that uses meson; - Doc for developers/maintainers that want to use meson as the build system of their project; - Doc for contributors to Meson itself or developers who want to write a macro/function (I don't exactly know how Meson works, but I suppose it can be extended in some way). Indeed the documentation that I was looking for (and that was missing in the manpage or meson --help) is available at: http://mesonbuild.com/Build-options.html#build-options but that's the doc for developers/maintainers. (btw I've now added this to my jhbuildrc: module_mesonargs['graphene'] = '-Denable-gtk-doc=true' For Pango the build fails when enabling the docs, I didn't investigate why). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Meson feedback as a user
On Sun, Jul 02, 2017 at 03:21:51PM +0100, Sam Thursfield wrote: > On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet wrote: > > Out of curiosity, let's look at other GNOME-related modules that use > > gtk-doc. What is the name of the option that enables gtk-doc? > > - pango:enable_docs > > - gtk+: enable-documentation > > - graphene: enable-gtk-doc > > - atk: enable_docs > > We should indeed work to make these names consistent across GNOME > modules. Having a page on the wiki where we list standard option names > for Meson build systems would be a good start. To make the names consistent, the best way is to write the name in only one place, i.e. in meson itself or a meson function/macro. Not in each individual modules. Like the GTK_DOC_CHECK Autotools macro. The same for compiler flags, with the Autotools there is the AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed in each GNOME module. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Meson feedback as a user
Hi,
I don't want to learn Meson yet as a maintainer. Just as a user to build
some GNOME modules that now require Meson.
It seems that the Meson docs are now more focused for maintainers, not
users. What was great with the Autotools is that it was easy to use, as
a user: INSTALL file with all the user documentation,
./configure --help, etc.
So let's take a simple use-case: I want to build in Jhbuild the API docs
of Pango and other GNOME/GTK+ libraries.
I see that Jhbuild doesn't build the API docs of Pango by default. How
do I enable it? With the Autotools I had something like this in my
jhbuildrc:
module_autogenargs['pango'] = '--enable-gtk-doc'
$ cd ~/gnome/pango/
$ man meson
OK so I need to do:
$ meson --help
Nothing resembling --enable-gtk-doc. It seems that meson --help outputs
the same text for all projects.
Let's look at the Meson web site:
http://mesonbuild.com/Quick-guide.html doesn't help me.
http://mesonbuild.com/Tutorial.html dives directly for maintainers, not
users.
$ ls
Oh I see that there is a meson_options.txt.
$ cat meson_options.txt
option('enable_docs',
description: 'Build API reference for Pango using GTK-Doc',
type: 'boolean',
value: false)
OK that's what I was looking for, how do I enable it?
$ meson --help
-D PROJECTOPTIONS Set project options.
Probably that. Do I need to pass "-D enable_docs" or
"-D enable_docs=true" or "-D enable_docs='true'" or anything else? Do I
proceed by trials and errors until I find something that works?
Out of curiosity, let's look at other GNOME-related modules that use
gtk-doc. What is the name of the option that enables gtk-doc?
- pango:enable_docs
- gtk+: enable-documentation
- graphene: enable-gtk-doc
- atk: enable_docs
With the Autotools with the GTK_DOC_CHECK macro, it was --enable-gtk-doc
everywhere at least.
So, that's it, I think Meson is still a bit young. I'll try another day.
Or I could do the same as everybody, asking on IRC, or reading the docs
for maintainers.
--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Renaming a project
On Sun, Jun 11, 2017 at 09:22:56AM -0400, Jeremy Bicha wrote: > On Sun, Jun 11, 2017 at 7:15 AM, Sébastien Wilmet wrote: > > - What to do about the git repo? Creating a new repo with the new name > > and placing the old one in the deprecated section? > > I believe you can push the new git repo. > > Remember to update jhbuild > If your project was built by gnome-continuous (it doesn't look to me > like it is), you'd want to update that too. > > Then file a bug like this: > https://bugzilla.gnome.org/769952 Great, I'll do the same. > > - For the bugzilla product it's less important, especially if we move to > > GitLab. > > There isn't as much of a need for a bugzilla redirect and you should > be able to rename the bugzilla product yourself: > https://bugzilla.gnome.org/editproducts.cgi?action=edit&product=gtef Indeed, I'll try to rename the product there and see what happens. Thanks for the information! -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Renaming a project
Hi, I would like to rename Gtef (GTK+ text editor framework) to Tepl (Text editor product line). I don't really like the name Gtef. https://wiki.gnome.org/Projects/Gtef - The wiki page can easily be renamed, with a redirection for the old page. - What to do about the git repo? Creating a new repo with the new name and placing the old one in the deprecated section? - For the bugzilla product it's less important, especially if we move to GitLab. This page: https://wiki.gnome.org/MaintainersCorner doesn't contain guidelines for renaming a project. I can fill that gap after doing it for Gtef. -- Sébastien ___ 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 02:21:55PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote: > > By attaching a patch to a bugtracker ticket, we loose the information of > > the parent commit: where the commit has been initially created in the > > git history. > If the patch is created by git format-patch, it contains the hash of > the parent, so git knows the original parent. > > > I've already had the problem that git-bz apply fails (there was a > > conflict), while git was able to resolve automatically the conflict when > > rebasing the branch. > 'git am -3' is the same as a rebase. Thanks for correcting me. Indeed a patch created with `git format-patch` includes the hashes of the parent objects. When using git-bz it hides a little the use of git am, so I was not aware of all the possiblities of git am. It's possible to configure the am.threeWay setting in git, by default it's false. But it doesn't seem easy (or even possible) with git am to create a branch at the original place in the git history where the patches were created. The parent *commit* is not known, only the parent objects. I think it can be useful to know where the contributor has created the commits. With a pull request workflow like in GitHub and GitLab, when we fetch the branch we know the parent commit. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Sun, May 28, 2017 at 03:20:49PM +0200, Bastien Nocera wrote: > On Thu, 2017-05-25 at 12:08 +0200, Sébastien Wilmet wrote: > > For LGPL -> GPL, you need the explicit approval of all copyright > > holders. > > No, you don't. It says right in the license that you can use LGPL > sources as GPL if you so wish: > "you may convey a copy of the modified version [...] under the GNU GPL, > with none of the additional permissions of this License applicable to > that copy." > > Meaning that you can strip the additional permissions in the LGPL to > make it GPL without asking anyone. Oh, thanks for correcting me. Good to know. I confused with GPL -> LGPL. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Thu, May 25, 2017 at 06:10:56AM -0400, Carlos Soriano wrote: > I still get different opinions from different people on that. But that > makes sense to me. Probably makes sense to relicense the files too at > some point, but that would be a later decision. > Do you know any advantage of relicensing the files themselves? Well, I thought you wanted to license Nautilus as GPLv3+, that's the topic of this thread… See: https://www.gnu.org/licenses/gpl-faq.html#v3HowToUpgrade -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Thu, May 25, 2017 at 05:59:02AM -0400, Carlos Soriano wrote: > For now we won't relicense the files, since that would require > copyright holders to agree (iiuc). Instead is the project that will > become GPL3+, since the combination of GPL2+ + GPL3+ files results in > a project that is GPL3+. For the files licensed as GPLv2+, the copyright holders have already agreed with "any later version", so you can directly relicense to GPLv3+ without asking the permission to each copyright holder. For LGPL -> GPL, you need the explicit approval of all copyright holders. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
Hi, Just to mention that I've written two scripts that ease changing license headers: - gcu-multi-line-substitution - gcu-smart-c-comment-substitution available at: https://github.com/swilmet/gnome-c-utils Cheers, Sébastien ___ 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 11:45:26AM +0200, Bastien Nocera wrote: > On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote: > > > > > Most developers are more familiar with the GitHub workflow, I think > > it's > > an easier workflow than attaching a patch to a bugtracker ticket. > > Once > > the contributor has pushed a branch on the fork repo, all the rest > > can > > be done from the web interface by clicking on some buttons. > > I absolutely hate this workflow, fwiw. I prefer being able to run "git- > bz" to both create and apply patches, rather than keeping a clone with > a bunch of patches in my own org, or remembering the commands to push a > repo to my own repo from the upstream clone. > > I hope there will be a git-bz equivalent available. By attaching a patch to a bugtracker ticket, we loose the information of the parent commit: where the commit has been initially created in the git history. I've already had the problem that git-bz apply fails (there was a conflict), while git was able to resolve automatically the conflict when rebasing the branch. -- Sébastien ___ 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 11:15:51PM +0900, Tristan Van Berkom wrote: > I don't share your optimism about gitlab bug tracking, nor do I share > in the mentioned frustration with bugzilla. Me too, I like bugzilla (but not for doing code reviews). What would be the pain points if GitLab is used only for git and code reviews, and we keep bugzilla for the bug tracker? Have you considered that option? We would loose automatic links between bug tracker tickets and pull requests. When a pull request is merged, we would need to close manually the bugzilla ticket if everything is done. And when someone requests a pull, the person would need to add a comment manually on bugzilla so that other people know that the bug is being worked on. Mmh I think that's not practical if the links must be done manually. Maintaining the bugzilla instance would also require sysadmin time, and development efforts to rebase the patches to new bugzilla versions. I don't know, I'm excited about the idea to use a similar contribution workflow as in GitHub, but less excited about having a bug tracker similar to the GitHub one. (I've never used GitLab, but I'm familiar with GitHub, and after seeing some screenshots it seems that the GitLab bug tracker is similar to GitHub's). -- Sébastien ___ 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 01:42:15AM +0200, Jehan Pagès wrote: > Github/gitlab wants to force you to fork the project into a public > repository on your private account so that you can make a pull > request. This is seriously stupid IMO and very poor workflow. That's > the reason why github/gitlab is absolutely littered with useless > repositories containing absolutely no difference with the upstream > repository (except they are outdated since the person didn't touch it > for months). I'm sure trash "fork" repositories are the majority of > github/gitlab contents. Once your commit is merged upstream, you can delete your fork repo (but yes, maybe the majority of people don't do it). On GitHub at least it's easy to see if a repo is a fork, with a link to the upstream repo. Most developers are more familiar with the GitHub workflow, I think it's an easier workflow than attaching a patch to a bugtracker ticket. Once the contributor has pushed a branch on the fork repo, all the rest can be done from the web interface by clicking on some buttons. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hosting Paperwork on gnome.org
On Mon, May 01, 2017 at 02:51:42PM +0200, Jerome Flesch wrote: > Assuming this is actually a good fit for Gnome, I'm not sure where to > start either. Any indications would be welcome. Paperwork is at least a good fit for hosting it on gnome.org. Some projects are hosted on gnome.org without being part of GNOME core. I think this would be a good first step. It's a bit old, but it's still mostly relevant, and this might convince you: https://blogs.gnome.org/johannes/2010/06/04/why-gnome-org/ Once a project is hosted on gnome.org, if you ask the sysadmins it's possible to still use GitHub pull requests to handle contributions (instead of having patches on bugzilla, IMHO the only ugly thing about hosting a project on gnome.org). Once Paperwork is hosted on gnome.org, the release team could discuss whether to add it e.g. in the "Extra apps" category, or even in the "Core apps" if everyone agree that it would be nice that distros install it by default. See this recent blog post for the different categories and examples of apps in each category: https://blogs.gnome.org/mcatanzaro/2016/09/21/gnome-3-22-core-apps/ But even if Papework is just hosted on gnome.org without being officially part of GNOME, this would bring your project more visibility I think. And a nice side-effect is that it'll be easier for you to contribute to other GNOME modules if you want, because you'll already have all the necessary accounts, permissions etc. To host a new project on gnome.org, all the information should be there: https://wiki.gnome.org/MaintainersCorner - >From a technical point of view, I don't know if it's already the case, but it would be nice to have a library with the features that Paperwork provides, so if one day Simple Scan or Documents want to use some features of Papework, it would be easily possible thanks to the library. Cheers, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Build situation and BuildStream
On Thu, Apr 27, 2017 at 11:21:37PM +0900, Tristan Van Berkom wrote: > On Thu, 2017-04-27 at 14:41 +0200, Sébastien Wilmet wrote: > [...] > > With jhbuild, when we enter into a jhbuild shell we are still in the > > same directory, usually inside the git repository. With builddir == > > srcdir we have all the files that we can directly open with our > > preferred text editor. When we open a new terminal tab, we are in the > > same directory where we are able to 1) do git commands 2) building > > (with > > recursive make) 3) launching executables 4) editing files, etc. > > > > With BuildStream, will it be similar? [...] > So, this is a little bit fiddly compared to working entirely within one > build sandbox, only because you really need to exit and enter a sandbox > environment when you want to try something out, otherwise it's snappy > (and maybe a convenience command to say "build + shell" in one go could > reduce a bit of typing). > > On the bright side, you never ever trust your host environment for > anything, except for a display server and session bus in the case that > you use `bst shell` to run things. OK, thanks for your detailed explanation. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Build situation and BuildStream
Hi Tristan, For application or library developers (libraries used by applications), I'm a bit struggling to see what the workflow will look like with BuildStream. I've described two examples of my current workflow in this mail: https://mail.gnome.org/archives/desktop-devel-list/2016-August/msg00047.html "builddir != srcdir in jhbuild breaks my workflow" See also: https://mail.gnome.org/archives/desktop-devel-list/2017-February/msg00018.html "Equivalent of recursive make with meson/ninja?" With BuildStream you're talking about launching a VM. It's quite a big change compared to how applications are launched with jhbuild. So, can you describe a little more how the workflow would look like for application developers using the terminal (not an IDE)? With jhbuild, when we enter into a jhbuild shell we are still in the same directory, usually inside the git repository. With builddir == srcdir we have all the files that we can directly open with our preferred text editor. When we open a new terminal tab, we are in the same directory where we are able to 1) do git commands 2) building (with recursive make) 3) launching executables 4) editing files, etc. With BuildStream, will it be similar? -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME goal candidates
On Wed, Mar 01, 2017 at 10:31:24AM +, Philip Withnall wrote: > On Tue, 2017-02-28 at 17:12 -0600, Michael Catanzaro wrote: > > GtkBuilder validation looks like more gook to add to our Automake > > files, when we really want less gook there. Even if it's only a small > > amount of code, I'd rather it be implemented as an autoconf archive > > macro and re-proposed. I'm not sure if it's really necessary anymore > > anyway, since GTK+ almost always warns about XML problems at runtime, > > right? > > Who cares how much ‘gook’ we have in the build system? What we care > about is how useful it is. The value of adding validation for files at > build time is that it catches errors *at build time*, not at runtime if > a certain code path is taken. For GtkBuilder files, the usefulness of > this depends entirely on the project — if the project uses a single > massive .ui file, any errors in that are going to be caught when the > program is started. But if a project uses a separate .ui file for each > dialogue, you have to test every dialogue in the program at runtime > before you know all the .ui files are valid. > > This is a textbook example of the tradeoff between build time and > runtime testing. > > The example rules given on the goal page are not the tidiest. There is > a simpler way to do this: > > https://git.gnome.org/browse/hitori/tree/Makefile.am#n95 (four lines) > https://git.gnome.org/browse/hitori/tree/configure.ac#n51 (two lines) > > I don’t think that needs to be shipped out to an autoconf-archive macro > — including such a macro in a project would be two lines at the least, > so it would save a total of four lines. This one is better off being > cargo-culted. So the general consensus was to approve this GNOME goal: https://wiki.gnome.org/Initiatives/GnomeGoals/ValidateGtkBuilderFiles provided that someone updates the instructions and the list of modules. For the instructions, hitori currently does this: (with more future-proof links): https://git.gnome.org/browse/hitori/tree/Makefile.am?h=3.22.2#n95 https://git.gnome.org/browse/hitori/tree/configure.ac?h=3.22.2#n51 There is now also the gtk-builder-tool utility program (or gtk4-builder-tool for GTK+ 4), which can also validate GtkBuilder files. With gtk-builder-tool I wonder if xmllint is still necessary. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Develop of gnomeradio
Hi George, You were apparently not subscribed to the mailing list, your email has appeared on the mailing list only today. On Thu, Feb 16, 2017 at 02:31:22PM +0200, George Pojar wrote: > I took gnomeradio from archive in GNOME git [ > https://git.gnome.org//browse/archive/gnomeradio ] and redesign, > actualize and modernize the original gnomeradio application that > according to its developer, is not under active development anymore > since 2008. > > Here is a new package gnome-radio to listen to FM radio in GNOME [ > https://launchpad.net/gnome-radio ] > > In Debian gnomeradio package has been removed from development > repository due to the lack of a maintainer. > The source package gnomeradio is at 1.8-2 in Ubuntu, whose development > was provided by me through some patches, but now I have decided to > rewrite almost entirely this application. > > I am interested to further develop this application in GNOME. Good news! Indeed it would be better to keep the development of gnome-radio on the gnome.org infrastructure. All the information is here: https://wiki.gnome.org/MaintainersCorner You need to ask for a git account at least: https://wiki.gnome.org/AccountsTeam/NewAccounts Thanks for your work! -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk-doc goes python
On Thu, Mar 30, 2017 at 09:51:27PM +0200, Stefan Sauer wrote: > as a heads up - Jussi Pakkanen and I are rewriting gtkdoc to python. The > shell scripts are already gone (so running gtkdoc won't need a shell > anymore). At the same time we're modernizing it a bit and adding more > and proper tests. This is all very much work in progress though. If we > break something, please ping us in irc (#gtkdoc) or file a bug. Also > help is very welcome. Very good news! I've tested with GtkSourceView and a few other projects, and everything seems to still work fine. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.25/3.26 Schedule available
On Wed, Apr 05, 2017 at 12:18:44PM +0200, Andre Klapper wrote: > On Wed, 2017-04-05 at 11:13 +0200, Sébastien Wilmet wrote: > > Is it intentional that the development cycle lasts 25 weeks instead > > of 26? > > > > 365.25 / 7 = 52.18 weeks/year in average. So 26 or 27 weeks per > > development cycle. > > > > But maybe you want to release one week sooner to better fit a certain > > distro schedule? > > Yes it is intentional. Seeing release plans of some distributions this > hopefully allows an additional week of integration / testing :) OK makes sense, especially for Ubuntu, I think they now ship again the latest versions thanks to GTK+ 3 being stable (and apps still depending on GTK+ 3). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.25/3.26 Schedule available
Hi, On Wed, Mar 29, 2017 at 05:05:14PM +0200, Andre Klapper wrote: > the release schedule for GNOME 3.25/3.26 is out: > > https://wiki.gnome.org/ThreePointTwentyfive Is it intentional that the development cycle lasts 25 weeks instead of 26? 365.25 / 7 = 52.18 weeks/year in average. So 26 or 27 weeks per development cycle. But maybe you want to release one week sooner to better fit a certain distro schedule? -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Do not use -Werror by default in your modules without joining #testable
On Sun, Apr 02, 2017 at 06:22:07PM +0100, Emmanuele Bassi wrote: > On 2 April 2017 at 18:16, Michael Catanzaro wrote: > > On Sun, 2017-04-02 at 15:59 +0100, Emmanuele Bassi wrote: > >> Adding: > >> > >> disable_Werror = False > >> > >> to your jhbuildrc should do the trick. > > > > Ah, but nobody wants to do that for all modules locally... I only want > > it for Epiphany. > > Adding this: > > ``` > module_autogenargs['epiphany'] = '--disable-Werror' > ``` > > should work, assuming Epiphany uses the m4 macros that add `--disable-Werror`. So, --disable-Werror for all modules, except epiphany. Maybe this works: module_autogenargs['epiphany'] = '--enable-Werror' but if the command line contains both --disable-Werror (because of Jhbuild defaults) and --enable-Werror, I don't know how it'll behave. Or this: module_makeargs['epiphany'] = 'CFLAGS="-Werror"' ? -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Do not use -Werror by default in your modules without joining #testable
On Sun, Apr 02, 2017 at 07:21:38PM +0200, Sébastien Wilmet wrote: > 1) This warning: comparison between signed and unsigned integer. After a bit more thoughts, I see one flaw in my reasoning, because GCC triggers the above warning depending on the architecture it is building for. When the ARM CI server was set up for GNOME, someone filed a bug about this warning, but on x86_64 the warning was not present. I consider that a bug in GCC, it should show warnings depending on the C standard, not depending on a specific architecture. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Do not use -Werror by default in your modules without joining #testable
On Sun, Apr 02, 2017 at 09:53:41AM -0500, Michael Catanzaro wrote: > Simplest solution would be for Continuous to just pass --disable-Werror > to configure. OTOH I'm willing to change the Epiphany behavior if you > don't agree, but it's baked into use of AX_IS_RELEASE([git-directory]) > and AX_COMPILER_FLAGS, which to my understanding is the recommended set > of macros to use for GNOME modules. So we need to adjust that if we > want to change this. The behavior you want would require using > AX_IS_RELEASE([always]), which doesn't seem great to me. I think that's > the only way to get the behavior you want without totally dropping use > of AX_COMPILER_FLAGS, which we probably don't want to do. (Am I > mistaken?) AX_IS_RELEASE([always]) might have unintended effects for other macros than AX_COMPILER_FLAGS. To disable -Werror by default it's better to set the IS-RELEASE parameter of AX_COMPILER_FLAGS to "yes": AX_COMPILER_FLAGS([WARN_CFLAGS], [WARN_LDFLAGS], [yes]) I think that's what I'll do in the modules I maintain, because I don't use -Werror, and there can be deprecation warnings that pop up at any time. -Werror is anyway disabled by default in Jhbuild, so I don't see why it should be enabled by default for other people not using Jhbuild and want to build the module from git. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Do not use -Werror by default in your modules without joining #testable
On Sun, Apr 02, 2017 at 04:52:49PM +0100, Emmanuele Bassi wrote: > You seem to misunderstand what a continuous delivery/continuous > integration pipeline is for. I think I understand what a CI server is for, I simply disagree with you. Let's compare two scenarios: 1) This warning: comparison between signed and unsigned integer. 2) A real build error due to a change in an underlying library. For the sake of argument, 1) can be replaced by any warning that becomes an error if -Werror is enabled. I.e. not a "real" build failure, by default it's just a warning. In most cases, if 1) appears, the problem is located in the code of the module itself, it's not caused by a dependency. So the developer directly sees it when building the module in jhbuild, even if the deps are not up-to-date. For 2), it's better that it is detected by a CI server so that we know the problem as soon as possible. A lot of GNOME modules have compilation warnings, and I don't consider them critically important. In fact, -Werror is disabled in tarballs (what we actually ship to distros). Of course it's better to fix them, and in the modules that I maintain they are all fixed except deprecation warnings. I won't push a commit on the master branch if it adds a warning, because I directly see the warning when building the code locally. On the other hand it's nice that the CI server detects 2) because it's not practical to rebuild the dependencies in jhbuild all the time. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Do not use -Werror by default in your modules without joining #testable
On Sun, Apr 02, 2017 at 03:59:39PM +0100, Emmanuele Bassi wrote: > The point of my email was, though, that people should be keeping an > eye on their modules on the CD pipeline. It's easier to keep an eye on our local compilation output, and rebuild from time to time the dependencies in jhbuild. GNOME Continuous is useful to detect as early as possible real build breakages (a FTBFS *with* --disable-Werror). Or determining the culprit commit when a unit test starts to fail (and possibly cross-modules, e.g. a commit in gtk that makes an app unit test to fail). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hosting Gtef on gnome.org
On Fri, Mar 10, 2017 at 08:42:23AM -0600, Michael Catanzaro wrote: > Seems like a perfect candidate for git.gnome.org. Be sure to update > JHBuild and Continuous. > > https://openclipart.org/image/800px/svg_to_png/195669/Traffic-light.png Thanks! The git repo is now created, I'll go through the next steps this week-end. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hosting Gtef on gnome.org
Hi, I would like to host Gtef on gnome.org. Gtef is a library that eases the development of GtkSourceView-based text editors and IDEs. It is the acronym for "GTK+ Text Editor Framework". It also serves as an incubator for some GtkSourceView features. Gtef is currently hosted on my GitHub repository: https://github.com/swilmet/gtef Gtef is used by LaTeXila, which is already hosted on gnome.org. It satisfies all requirements from this page: https://wiki.gnome.org/Projects/Prerequisites So if I have the green light, I'll create the git repository, ask for a bugzilla account etc. Thanks, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Improving the way we build nightly apps
On Tue, Feb 28, 2017 at 05:18:55PM -0600, Michael Catanzaro wrote: > On Tue, 2017-02-28 at 11:44 -0500, Matthias Clasen wrote: > > So far, we have this gnome-nightly-apps repository which contains > > copies of the flatpak manifests for a bunch of gnome apps. That is > > redundant and suboptimal. Recently, flatpak has gained the ability to > > find manifests in git repositories that you point it to, and we > > should use this to move the json files to each applications git tree. > > Quite possibly there is already a copy of it there anyway. > > > > If you want to help out with making this happen, the details are > > described here: > > > > https://wiki.gnome.org/Initiatives/GnomeGoals/FlatpakManifests > > This is clearly superior to how we build the flatpaks now. > > On the other hand, these manifests should hopefully be obsoleted soon > by BuildStream. I don't know how soon it'll be. The Flatpak manifest goal is a small goal (the files are even already written, it's just moving them and doing small edits). If it's useful during 6 months or one year, that's already worthwhile. It's easy to remove the Flatpak manifests once (and if) BuildStream becomes the preferred way. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME goal candidates
On Thu, Mar 02, 2017 at 08:58:26AM -0600, Michael Catanzaro wrote: > On Thu, 2017-03-02 at 12:36 +0100, Sébastien Wilmet wrote: > > I can take ownership of: > > https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage > > > > I will update the description. > > OK. Go ahead and move it to the approved list goals list once you've > updated the list of modules, since it's been discussed at length now on > the list. We obviously don't have a super formal process for this, at > least not that I'm aware of. Done! One less goal in the candidates category. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.23.91
On Thu, Mar 02, 2017 at 07:37:12AM -0500, Matthias Clasen wrote: > The release notes that describe the changes between 3.21.90 and 3.21.91 > are available. Go read them to learn what's new in this release: > > core - https://download.gnome.org/core/3.21/3.23.91/NEWS > apps - https://download.gnome.org/apps/3.21/3.23.91/NEWS > > The GNOME 3.21.91 release itself is available here: > > core sources - https://download.gnome.org/core/3.21/3.23.91 > apps sources - https://download.gnome.org/apps/3.23/3.21.91 s/21/23/: core - https://download.gnome.org/core/3.23/3.23.91/NEWS apps - https://download.gnome.org/apps/3.23/3.23.91/NEWS core sources - https://download.gnome.org/core/3.23/3.23.91 apps sources - https://download.gnome.org/apps/3.23/3.23.91 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME goal candidates
On Wed, Mar 01, 2017 at 03:12:17PM -0600, Michael Catanzaro wrote: > On Wed, 2017-03-01 at 14:22 -0500, Carlos Soriano via desktop-devel- > list wrote: > > I think installed test etc it's not going to happen or be maintained > > if we don't enable coverage with it too. I think that's the actual > > trick that will keep us up with the initiative. > > > > So I would go with both since the start, and together. > > OK then. Does anybody want to take ownership of this? It'd require > updating the goal pages to match the new best practices, maybe merging > them together, and updating the list of affected modules. I can take ownership of: https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage I will update the description. For the list of modules, I can merge the current list with the list from: https://wiki.gnome.org/Initiatives/GnomeGoals/Template I'll not actively see if more modules can be marked as done, nor file bugs for every module, that's a task for each individual module maintainer. I'm not sure it is a good idea to merge the two goals (installed tests + code coverage). When filing a bug in bugzilla, it should cover only one task. The installed tests make sense only if it'll actually be used, for example by GNOME Continuous. I don't know if all modules listed in the Template page are built by GNOME Continuous. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME goal candidates
On Wed, Mar 01, 2017 at 08:31:24AM -0600, Michael Catanzaro wrote: > OK, you all have changed my mind. I guess installed tests should be a > goal. > > Do we want to do this for coverage as well...? https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage The page needs to be updated for AX_CODE_COVERAGE. But I would keep it, at least to have a list of best-practices as Emmanuele said. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME goal candidates
On Wed, Mar 01, 2017 at 07:26:19AM -0600, Michael Catanzaro wrote: > This is the other thing. The goals should be achievable, something we > can look at in a year or two and say "all apps meet the goal" and close > it, not a longstanding epic that stays open forever. The installed > tests and coverage goals do not really qualify. Even though more tests > are definitely desirable, I don't think it's reasonable to use the > GNOME Goals project for this, even if it would be nice to see as many > projects as possible adopting it. > > Maybe I am being too negative here. It does seem odd to say that doing > something desirable should not be a goal. But a longstanding pie-in- > the-sky project is very different from existing goals. Switching to > g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks that > all apps should be able to accomplish easily. Adding a comprehensive > testsuite, not so much. And adding just one or two installed tests, > while a good starting point, is not very useful on its own. Replacing a menubar + toolbar to a GtkHeaderBar can be a major undertaking for large applications (for example for IDEs, Evolution, etc). It's not always a "quick task", especially if the application needs to move away from GtkUIManager/GtkAction. The GNOME goals about unit tests don't require to write a comprehensive test suite. If there is just one small unit test, it's already valuable, because the module will have the infrastructure to write unit tests, so chances are that more unit tests will be written in the future. And with code coverage support, it gives more motivation to write more unit tests. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hello && About Maintainership of Gtranslator
On Wed, Feb 15, 2017 at 11:27:25PM +0300, Muhammet Kara wrote: > I have been using gtranslator for years, and I love it. Lack of updates on > gtranslator has been bugging me for quite some time, and I have decided to > take action after seeing it on the Unmaintained list.[0] > > I would like to help fix its bugs (when/if I can), and at least keep it > alive/usable. And I would be happy to co-maintain it with a more > experienced maintainer/developer. > > I first wrote a message about this to the gtranslator-list, and also CC'ed > the last maintainer about seven weeks ago. About two weeks ago (if I am not > mistaken) on irc (#gtranslator), he told that he had been busy, and he > would write a proper response soon. On Alexandre Franke's suggestion, we > have been waiting for the reponse to get some insight about Seán's plans > for the master branch since the old UI was wiped in master, and it is not > in a usable state. I am still waiting for that. So the usable state is on the gtranslator-2-91 branch? It is probably a better idea to restart from that point, and always keep gtranslator in a usable state. > In the meantime, I committed a few patches to the current master and the > gtranslator-2-91 branches (thanks to Alexandre Franke for the reviews on > bugzilla). And I have also submitted a few more patches to bugzilla.[1][2] > (Reviews are most appreciated. :)) > > I have been a local GNOME advocate, and a translator so far. And I would > love to continue my GNOME journey also as a developer. > > Any help and directions are appreciated. If you don't have a computer science background, it'll be more difficult for you to work alone on gtranslator. Although it is entirely possible to learn programming oneself, I think the state of gtranslator will first get worse, then once you've gained more experience it'll improve. For GLib/GTK+, I've started writing this guide: https://people.gnome.org/~swilmet/glib-gtk-book/ You can also ask to previous gtranslator maintainers what they think (e.g. Ignacio Casal Quinteiro, nacho on IRC). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Slowness problem with GTK-Doc
On Mon, Feb 13, 2017 at 12:48:56PM +0100, Milan Crha wrote: > On Sat, 2017-02-11 at 18:35 +0100, Sébastien Wilmet wrote: > > For big projects like GTK+, building the docs takes several hours on > > my machine, and there are anyway too many warnings, with huge > > 'unused' files… > > just out of interest, do you run gtk-doc with address sanitizer > (libasan) preloaded? I just faced myself, when running gtk-doc with > ASAN preloaded, that it takes ages to finish, but without it the same > project finished within minutes (evolution-data-server speaking, size > of its gtk-doc is comparable to gtk+, I believe). Thanks for the hint, but I don't have libasan installed. So it must be something else. I thought everybody had the same slowness problem with gtk-doc. I have an Intel core i5, so there is a problem if it takes several hours to build the GTK+ docs. I can try with evolution-data-server. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Equivalent of recursive make with meson/ninja?
On Sat, Feb 11, 2017 at 03:58:54PM +, Tim-Philipp Müller wrote: > Dunno, for me the fact that gtk-doc is so slow is extremely annoying in > my normal dev workflow, especially when it rebuilds the docs just > because I or someone else touched a source file somewhere (i.e. pretty > much constantly when you git pull from a module that's actively worked > on by many people). For almost all modules I maintain, gtk-doc is > slower by a factor N than the rest of the entire build, so that really > kills productivity. Many devs I know build everything with --disable- > gtk-doc by default for that reason. > > As such I found it quite refreshing that meson does not build the docs > by default :) > > I'm sure it would be fairly easy to add a kwarg or switch somewhere to > make it build the docs by default though if that's really wanted. For small to medium-sized projects, I still enable gtk-doc by default. I've just tested with GtkSourceView, re-building the docs takes 25s. (btw it's a regression, one year or two years ago gtk-doc didn't have that performance problem, it's reported on bugzilla). 25s is too much for doing it all the time, that's one reason why I like recursive make, to re-build only the source code for example. I prefer to always enable the docs, to fix warnings as soon as they arrive, and have an empty 'unused' file (yes, for all the projects that I maintain, there are zero warnings when building the docs). For big projects like GTK+, building the docs takes several hours on my machine, and there are anyway too many warnings, with huge 'unused' files… -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Equivalent of recursive make with meson/ninja?
On Sat, Feb 11, 2017 at 07:03:01PM +0530, Nirbheek Chauhan wrote: > On 11-Feb-2017 18:32, "Sébastien Wilmet" wrote: > > It'll also relink all the tests and rebuild the docs (GTK-Doc is very > > slow). > > Fwiw, it won't rebuild the docs since that is done at install time, not at > compile time. That is a strange thing to do, building something at install time. I often do: $ cd docs/ $ make clean $ make to see if there are any warnings. If it's mixed up with install output, it's far less convenient. And thanks to builddir == srcdir, I often do: $ cd docs/reference/ $ vi -o to move the symbols from the 'unused' file to the section file. is in scrdir while is in builddir. The names of those files are different for each project (although it's probably possible to use globs). But these are just examples, `touch file.c && make` was another example. I probably do other similar things (more rarely, without even being aware of it) thanks to recursive make and builddir == srcdir. Basically each time I want to open a built file, I'm usually already in the good directory. > It also won't relink all the tests if you specify a target > (an executable, library, etc) to build. You can also rebuild a specific > file by specifying the corresponding .o file, and I'm sure that can be made > more convenient with a wrapper tool. > > I think your use-case can even be improved by writing such a tool that will > rebuild only a specific file. This would actually be faster than make even > because it wouldn't relink anything in that directory unless you want it > to. > > Would you like to take a shot at it? It's really simpler than it might > seem. Just a matter of reading the compiler db (json file) and calling > ninja with the right argument. :) > > IMO this is one of the major advantages of Meson. It actually provides an > API that you can use to support and even improve your custom workflows. Mmh, yes, maybe. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Equivalent of recursive make with meson/ninja?
On Sat, Feb 11, 2017 at 11:54:40AM +, Tim-Philipp Müller wrote: > With meson/ninja, everything will end up in one single build.ninja file > (the equivalent to a Makefile). > > You'd just do > > touch foo.c > ninja In two different terminal tabs though. > and it will only recompile/relink the bits that have changed, and > nothing else. It will be very very fast in most cases. It'll also relink all the tests and rebuild the docs (GTK-Doc is very slow). > You can also do: > > touch foo.c > ninja -C ../build > > if you prefer to be in the source dir. Too long to type. > If you haven't got a full build yet and only want to build a single > target without building more than absolutely needed you can also just > do > > ninja -C ../build src/libfoobar.so.1.2.3 > > or somesuch (tab completion for targets should just work if you have > the right bits installed), but I'd expect that the normal use case is > that you do a full build and then just rebuild when things change. Yes I always do a full build first. autogen.sh/configure takes a lot of time compared to meson, but once the full build is done, I just run make commands which is fast enough. > You'll also notice that 'ninja' is near-instantaneous if there are no > changes, compared to recursive make which can take tens of seconds to > do nothing in that case. (Just as a data point, why the recursive ninja > thing is not really needed.) What I don't like to do is to scroll up the build output to see the warnings I'm interested in. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Equivalent of recursive make with meson/ninja?
Hi, With the Autotools, recursive make is very convenient to re-build only the stuff present in a sub-directory. And with builddir == srcdir, it's convenient to do things like: $ cd src/ $ make $ touch file-that-i-modified.c $ make To see the warnings only for the file that I modified. (see also this thread for more details on my workflow: https://mail.gnome.org/archives/desktop-devel-list/2016-August/msg00047.html "builddir != srcdir in jhbuild breaks my workflow") I've tried this command in a project using meson: ``` $ meson . Error during basic setup: Source and build directories must not be the same. Create a pristine build directory. ``` So meson doesn't support builddir == srcdir. This is a no-go for me. And I suppose meson/ninja doesn't support recursive ninja either (and anyway recursive ninja with builddir != srcdir would not be convenient). It's a pity, because meson on the paper looks nice, with faster build and multiplatform support (including Visual Studio, currently with the Autotools some GNOME projects have a separate build/win32/ directory to support Visual Studio). So, that's it, I think I'll continue to use the Autotools in my projects for the foreseeable future. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documentation for build system setup
On Thu, Feb 09, 2017 at 04:14:13PM +0100, Sebastian Geiger (Lanoxx) wrote: > I have just updated the wiki, please let me know if something I changed > is not right: > > https://wiki.gnome.org/Projects/GnomeCommon/Migration This is probably bikeshedding, but it's easier to remove lines than adding lines, after copying the template. -- Sébastien > On 09/02/17 15:03, Emmanuele Bassi wrote: > > On 9 February 2017 at 13:57, Sebastian Geiger (Lanoxx) > > wrote: > >> What confuses me is that this paragraph starts with the phrase "it does > >> not need any modifications made". > >> > >>> It does not need any modifications made, unless you need to run > >>> another tool before configure, or do not use one of glib-gettextize, > >>> gtkdocize or intltoolize. (Note that you should not use both > >>> glib-gettextize and intltoolize in the same module, and it is better > >>> to use neither; see the FAQ entry below for details.) > >> It might be more helpful to provide a autogen.sh listing that omits both > >> glib-gettextize and intltoolize and then add a paragraph explaining to > >> add these for project that use either of these tools. If I understand > >> right both a deprecated anyway and should not be needed for > >> state-of-the-art projects. > >> > >> Maybe write something like this: > >> > >> If you are still using the deprecated glib-gettextize, then add the > >> following line immediately before > >> autoreconf: > >> > >> glib-gettextize --force --copy || exit 1 > >> > >> If you are still using the almost obsolete intltoolize, then add the > >> following line immediately before > >> autoreconf: > >> > >> intltoolize --force --copy --automake || exit 1 > > Those look like good changes, indeed. Feel free to update the wiki. > > > > Ciao, > > Emmanuele. > > > >> On 09/02/17 11:45, Philip Withnall wrote: > >>> Can we please standardise on the autogen.sh given in > >>> https://wiki.gnome.org/Projects/GnomeCommon/Migration#autogen.sh ? > >>> > >>> It does everything we need, and meets all the standards (like build- > >>> api). If you’ve got improvements to make, please make them on that > >>> page. > >>> > >>> Sebastian: the paragraph immediately above the example does say that > >>> you should remove one or both of the intltoolize/glib-gettextize calls > >>> as appropriate. > >> > >> ___ > >> 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.23.3 released
On Thu, Dec 15, 2016 at 03:34:40PM -0600, Michael Catanzaro wrote: > On Thu, 2016-12-15 at 21:08 +0100, Sébastien Wilmet wrote: > > - gspell (1.2.1 => 1.3.1) (*) > > (*) No summarized news available > > > > There is a bug in the code that extracts the news, because I've > > updated > > the NEWS file as always: > > https://git.gnome.org/browse/gspell/commit/?h=1.3.1 > > > > So, there is basic support of spell-checking for GtkEntry. Something > > that was missing from GNOME during the whole lifetime of GTK+ 3 :-) > > Yeah, the script isn't smart enough to handle branchings so it misses > news updates quite often. In this case 1.2.1 was the last release, and > the script didn't find 1.2.1 in your NEWS file because that release was > made on a sidebranch, so it gave up. No doubt this could be improved, > but in the meantime if you want to be sure your NEWS will show up you > have to copy the NEWS entries from the sidebranch to master as a > workaround. Arguably that results in more-readable NEWS anyway, but > it's harder for maintainers and I don't bother to do so personally. OK, thanks for the explanation. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.23.3 released
On Tue, Dec 13, 2016 at 12:27:08PM -0600, Michael Catanzaro wrote: > The lists of updated modules and changes are available here: > core - https://download.gnome.org/core/3.23/3.23.3/NEWS > apps - https://download.gnome.org/apps/3.23/3.23.3/NEWS - gspell (1.2.1 => 1.3.1) (*) (*) No summarized news available There is a bug in the code that extracts the news, because I've updated the NEWS file as always: https://git.gnome.org/browse/gspell/commit/?h=1.3.1 So, there is basic support of spell-checking for GtkEntry. Something that was missing from GNOME during the whole lifetime of GTK+ 3 :-) -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Script to format the functions in a C header?
On Sun, Nov 20, 2016 at 11:44:41AM +0100, Lasse Schuirmann wrote: > Shouldn't this be like totally easy with GNU Indent or so? You'll have > to give it the right CLI args. (We have a wrapper for that in coala if > you're interested in doing loads of other stuff but indent is usually > already there.) No, GNU Indent doesn't fully support the GNOME coding style: https://developer.gnome.org/programming-guidelines/unstable/c-coding-style.html.en And I don't use Emacs. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Script to format the functions in a C header?
On Tue, Nov 22, 2016 at 07:03:02PM +0100, Daiki Ueno wrote: > For what it's worth, I wrote such elisp some time ago: > http://elpa.gnu.org/packages/gnome-c-style.html Cool, added to: https://wiki.gnome.org/Newcomers/Tools-C-language > If anyone is trying to implement the feature somewhere, I would suggest > to provide two separate scripts or commands to do the job: (1) guess the > alignment rule somehow, e.g. from the existing C code, and (2) do the > actual formatting. That would be helpful to avoid unnecessary > formatting changes when creating a patch for existing projects. Why two separate scripts? A single script can have two passes. I think I'll write a new script like I did for lineup-parameters, so that it can be integrated in Vim or Emacs or other text editors (it just reads stdin and write to stdout, or optionally takes file arguments). For the script, the first pass - to determine the columns where to do the alignment - could have two modes: "re-align everything" and "minimal perturbation". For the minimal perturbation, it would look which columns are used the most, and fix the functions that are not aligned to those columns. Also, in the GNOME convention there is something that I don't like and that I would prefer not to do: aligning all the parameter names on the same column (the third column). I prefer aligning the parameter names for each function separately, IMHO it's more readable. Because otherwise, for some functions, there can be a big empty space between parameter types and their names, which doesn't help readability (caused by a long type in another function). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Script to format the functions in a C header?
On Mon, Nov 21, 2016 at 03:49:09PM +, Ikey Doherty wrote: > You could use clang-format and an appropriately configured > .clang-format file to enforce coding convention within a source > tree. > > I'd recommend checking: https://clangformat.com/ as a simple way > to build your .clang-format > > I tend to keep an "update_format.sh" script in my repos to ensure > everything stays sane during development: > > #!/bin/bash > clang-format -i $(find . -name '*.[ch]') > > # Check we have no typos. > which misspell 2>/dev/null >/dev/null > if [[ $? -eq 0 ]]; then > misspell -error $(find . -name '*.[ch]') > fi > > > Note that misspell is a golang package, and makes sure I have > no embarrassing typos in my code :) "diffrent" happens so often.. Ok, thanks, I can look at clang-format if it supports the GNOME/GTK+ convention for formatting function prototypes in a header. Otherwise I can write a new script, and re-use some code from lineup-parameters: https://github.com/swilmet/gnome-c-utils (it's based on regexes, so it's clearly not ideal, but it does its job). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Script to format the functions in a C header?
Hi, Is there a script to format the function prototypes in a C header, with the GNOME conventions? I.e. aligning the function names on the same column, aligning the parameters, etc. Thanks, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GtkSourceView changes in jhbuild
Hi, GtkSourceView 3.24 has branched, master is now open for GtkSourceView 4 development, which breaks backward-compatibility with GtkSourceView 3. The jhbuild modulesets have been modified exactly as for GTK+: 1. Rename the gtksourceview module to gtksourceview-3 2. For gtksourceview-3, set the branch to gnome-3-24 3. Add back a gtksourceview module for the master branch The biggest change with GtkSourceView 4 will be to rename the namespace of the code from GtkSource to Gsv. So if you build modules in jhbuild that depend on GtkSourceView, please update your jhbuild. gnome-continuous has been also updated. Good week-end, Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Ok to release GtkSourceView 3.24 in a few weeks?
On Tue, Oct 25, 2016 at 11:13:04AM +0200, Sébastien Wilmet wrote: > On Mon, Oct 24, 2016 at 03:20:08PM -0500, Michael Catanzaro wrote: > > So it sounds like it can just wait until March, right? You could do > > GtkSourceView 3.24 and 3.90 at the same time in March? > > It is actually more complicated than that. All the information is at: > https://wiki.gnome.org/Projects/GtkSourceView/TransitionToGtkSourceView4 After more thoughts, I think GtkSourceView 3.24 can be released in March, the gnome-3-24 branch will just be created a bit earlier than in other modules. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Ok to release GtkSourceView 3.24 in a few weeks?
On Mon, Oct 24, 2016 at 03:20:08PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-24 at 22:00 +0200, Sébastien Wilmet wrote: > > It is primarily new APIs replacing old ones. In one case, the new API > > is > > more powerful than the previous one, so it can be seen as a new > > feature. > > So if it is released as 3.22.2, it would break: the API freeze, the > > feature freeze, and the string freeze. > > > > The GNOME versioning scheme has clear semantics, which makes life > > easier > > for downstreams. By releasing GtkSourceView 3.24, we directly know > > what > > it can entail. > > So it sounds like it can just wait until March, right? You could do > GtkSourceView 3.24 and 3.90 at the same time in March? It is actually more complicated than that. All the information is at: https://wiki.gnome.org/Projects/GtkSourceView/TransitionToGtkSourceView4 We are not yet decided on how to handle the namespace change. It'll be painful for applications, so the idea is to make it less painful (with more incremental steps). I wanted to have 3.24 out of the way, so we can say "it's done" and continue with the next steps. With 3.24 released early, applications can already be ported to it (and do a stable release). As much as I like the 6 months release schedule, I think for a period of transition like here it is less appropriate. "Release early, release often", they said. 6 months can be considered too long nowadays. For example, with Flatpak, Allan proposed a more rapid cadence for applications, in this blog post: https://blogs.gnome.org/aday/2015/11/12/the-next-big-thing/ So I think the GNOME project will anyway need to deal with modules wanting to release new minor stable versions more often. For stable versions of distros (that want only bug fixes and translation updates for their packages), GtkSourceView 3.24 should be shipped alongside GNOME 3.24. For rolling release distros, GtkSourceView can be updated to 3.24 as soon as it is released. The same for GtkSourceView 3.50 if we decide to do such a stable version. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Ok to release GtkSourceView 3.24 in a few weeks?
On Mon, Oct 24, 2016 at 11:50:01AM -0700, Christian Hergert wrote: > On 10/24/2016 11:28 AM, Michael Catanzaro wrote: > > It might be less confusing to call it GtkSourceView 3.22.2, and just > > accept that it will have rather bigger changes than are typical for a > > stable release. > > I think this is a good idea as well. Especially if it's primarily > deprecation warnings. It is primarily new APIs replacing old ones. In one case, the new API is more powerful than the previous one, so it can be seen as a new feature. So if it is released as 3.22.2, it would break: the API freeze, the feature freeze, and the string freeze. The GNOME versioning scheme has clear semantics, which makes life easier for downstreams. By releasing GtkSourceView 3.24, we directly know what it can entail. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Ok to release GtkSourceView 3.24 in a few weeks?
On Mon, Oct 24, 2016 at 01:28:49PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-24 at 20:22 +0200, Sébastien Wilmet wrote: > > And, the master branch is now ready for GtkSourceView 3.24. The > > question > > is: when to release it? Do we do a period of freeze? There are a few > > changes for translations. > > I think you can do as you please, so long as you give sufficient time > (say, two weeks) for translators to do their thing. You could release > it alongside GNOME 3.22, for example. > > It might be less confusing to call it GtkSourceView 3.22.2, and just > accept that it will have rather bigger changes than are typical for a > stable release. Mmh, not sure I like that approach. It would require to change the "Since: 3.24" to "Since: 3.22" and removing the versioning macros for 3.24. At least two apps are already depending on GtkSourceView >= 3.23.1 (released yesterday). (on the master branch of those two apps, there is no releases so it is also fixable). For downstreams, I think it's important that they can trust us to not sneak in unexpected things in new stable micro versions. New stable micro versions should contain only bug fixes, sometimes performance fixes and translation updates. So it is normally always safe, for downstreams, to update to the latest micro versions of GNOME without looking in details what changed for each module. If from time to time we sneak in unexpected things, downstreams will no longer trust us. For example in Debian stable, they already prefer keeping a GNOME module at 3.14.0 instead of updating to 3.14.2, even though 3.14.2 has important bug fixes (but they have a strict policy to update packages during their freeze). As an upstream developer, I don't like when distros keep the .0 micro version. So, in summary, I would prefer calling GtkSourceView 3.24 "GtkSourceView 3.24". -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Ok to release GtkSourceView 3.24 in a few weeks?
Hi, The plan for GtkSourceView is to follow GTK+. So GtkSourceView 3.90 released at the same time as GTK+ 3.90, if everything goes well. But last cycle (before the freeze) we didn't know that GTK+ 3.22 would be the last GTK+ 3 version. And there was some more things that I wanted to do in GtkSourceView (adding other APIs and deprecating old ones). So a GtkSourceView 3.24 is needed, so that porting applications will be easier with the deprecation warnings [1]. And, the master branch is now ready for GtkSourceView 3.24. The question is: when to release it? Do we do a period of freeze? There are a few changes for translations. I think the best is to do a few weeks of freeze and then release 3.24. Another solution is to wait March. What do you think? -- Sébastien [1] BTW, off-topic but worth mentioning, I added "version 2" functions (e.g. to add a parameter), for example foo2() has been added, foo() has been deprecated and in GtkSourceView 3.90 foo2() will just be renamed to foo(). Adding foo2() is backward-compatible, so porting an application to GtkSourceView 4 will be trivial (wrt those API breaks, at least). Usually adding numbers at the end of function names is a bad practice, but here it just means "version 2" (like some Linux syscalls). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switching from Autotools to CMake for core evolution products
On Mon, Oct 10, 2016 at 12:45:50PM -0500, Michael Catanzaro wrote: > On Mon, 2016-10-10 at 12:57 -0400, Owen Taylor wrote: > > Can you propose what the necessary change would be to: > > > > https://people.gnome.org/~walters/build-api/build-api.md > > Well that document is Autotools-specific. The build API is basically a subset of the GNU Coding Standards: https://www.gnu.org/prep/standards/html_node/index.html (see chapter 7 The Release Process) For downstreams, as Michael Biebl already said, it's much easier if all modules can be built the same way. GNU has written a standard, but new build systems don't follow it… The GNU Coding Standards (GCS) has several decades of experience, the standards are well established, and we can trust the GNU hackers for having well conceived them. Those that don't follow them are devoted to reinvent the wheel: they will be faced sooner or later by the same problems already solved by the GCS and the Autotools. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Looking for a GNOME Calculator maintainer
On Mon, Sep 05, 2016 at 04:43:02PM +0100, Alberto Ruiz wrote: > I'm looking for someone to inherit GNOME Calculator. > > I've been trying to cope with maintenance tasks but there are more bugs > that I can handle atm and I thought I should prolly look for another > maintainer or at least a helping hand. > > I'd say the biggest point of pain right now is at the math level, it > suffers from a number of bugs that make calculations inaccurate in a > collection of cases. > > If you're interested in maintaining the module or offering a helping hand > please get in touch. Added GNOME Calculator to: https://wiki.gnome.org/Apps/Unmaintained And added a note at the top of: https://wiki.gnome.org/Apps/Calculator -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: builddir != srcdir in jhbuild breaks my workflow
On Fri, Sep 09, 2016 at 11:43:51AM -0400, Owen Taylor wrote: > On Tue, 2016-08-30 at 19:23 +0200, Sébastien Wilmet wrote: > > > > 1) Once a project is fully built, to re-build something I always do > > something along those lines: > > > > To compile only what I need: > > > > $ jhbuild shell > > [jhbuild] $ cd src/ > > [jhbuild] $ make > > > > To re-build only a certain *.c file, to see if there are any > > warnings: > > [jhbuild] $ touch file.c > > [jhbuild] $ make > > Just was looking back at this thread, and wondered - what if we > (by unspecified means) made it that under 'jhbuild shell', > 'make' was a shell alias/function that ran make in the right > place in the src dir? It is not just for the 'make' command, sometimes I want to open a generated file alongside a file from srcdir, for example for GTK-Doc (opening the 'unused' file alongside the section file, to add the new symbols). -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: builddir != srcdir in jhbuild breaks my workflow
On Tue, Aug 30, 2016 at 09:25:20PM +, philip.chime...@gmail.com wrote: > I've been thinking about the exact same thing recently; how about a > 'jhbuild jump' command that will take you from a location under srcdir to > the corresponding location under builddir and vice versa? And perhaps have > some environment variables defined as well. I would prefer to be lazy and still use builddir == srcdir, and let the computer tell me automatically if `make distcheck` fails, or at least if the build fails with builddir != srcdir. This can be resolved in GNOME Continuous by sending a mail to the maintainers listed in the doap file, for the module that fails. Or a local script run by cron could run `make distcheck` on some modules (`make -j1 distcheck`, even, to not slow down too much the computer, or use cgroups). But the local script probably needs a different jhbuild prefix to not mess up what the developer is currently doing. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: builddir != srcdir in jhbuild breaks my workflow
On Tue, Aug 30, 2016 at 07:05:49PM +0100, Emmanuele Bassi wrote: > > To compile only what I need: > > > > $ jhbuild shell > > [jhbuild] $ cd src/ > > [jhbuild] $ make > > > > To re-build only a certain *.c file, to see if there are any warnings: > > [jhbuild] $ touch file.c > > [jhbuild] $ make > > If you use: > > jhbuild make > > instead of entering inside a shell, jhbuild would pick up the changes > and build in the build directory. No, jhbuild make: - is longer to type (I need to type jhbuild shell only once); - compiles the whole module, and installs it (I prefer to run make install separately, only when needed). Btw I've filed a bug (with patches) for updating the buildroot docs: https://bugzilla.gnome.org/show_bug.cgi?id=770691 -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: builddir != srcdir in jhbuild breaks my workflow
On Tue, Aug 30, 2016 at 07:05:49PM +0100, Emmanuele Bassi wrote:
> On 30 August 2016 at 18:23, Sébastien Wilmet wrote:
> > I've put the following in my jhbuildrc:
> >
> > checkoutroot = os.path.expanduser('~/gnome')
> > buildroot = os.path.expanduser('~/gnome')
> >
> > (to have again builddir == scrdir)
>
> That's not really how it's done.
>
> Just set:
>
> buildroot = None
>
> and jhbuild will use the srcdir by default.
It's indeed better. By looking at jhbuild/defaults.jhbuildrc, there is
no way to know that.
The manual talks about the None value, but still saying that it's the
default value:
https://developer.gnome.org/jhbuild/unstable/config-reference.html.en
--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
builddir != srcdir in jhbuild breaks my workflow
Hi,
With the new jhbuild default configuration, it builds the module with
scrdir != builddir. I wanted to explain why I don't like it, and why
I've put the following in my jhbuildrc:
checkoutroot = os.path.expanduser('~/gnome')
buildroot = os.path.expanduser('~/gnome')
(to have again builddir == scrdir)
Here is my workflow (but I'm sure other developers do the same):
1) Once a project is fully built, to re-build something I always do
something along those lines:
To compile only what I need:
$ jhbuild shell
[jhbuild] $ cd src/
[jhbuild] $ make
To re-build only a certain *.c file, to see if there are any warnings:
[jhbuild] $ touch file.c
[jhbuild] $ make
Etc etc.
You see that that workflow relies heavily on builddir == srcdir.
2) For updating the GTK-Doc section file:
$ jhbuild shell
[jhbuild] $ cd docs/reference/
[jhbuild] $ make clean
[jhbuild] $ make
If the unused file contains symbols that I need to add to the section
file, I open a new terminal tab and do:
$ vi -o
Note that when I open a new terminal, I'm already at the right place,
with both the section file and unused file in the same directory.
So, builddir != srcdir breaks my workflow. There are probably other
examples, the above two are the most common to me.
For some projects that I develop externally to GNOME, I run from time to
time `make distcheck` (more often than creating tarballs), e.g. after
merging a big branch, or when I touch in a non-trivial fashion the build
system. But ideally a machine would check everything, and send me a mail
when something breaks. That way, I can work conveniently and let the
computer do the extra work.
In GNOME, GNOME Continuous needs to be (continuously) babysitted, it
doesn't send automatic mails to the right people. That's the root of the
problem. Enabling builddir != srcdir by default in jhbuild is just a
workaround. With git clean -Xdf, there is really no need to build in a
separate directory.
Finding builddir != srcdir issues early is nice, but for me it hinders
my workflow too much.
--
Sébastien
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SVG rendering - Librsvg and Lasem
On Tue, Jun 21, 2016 at 03:41:48PM +0200, Emmanuel Pacaud wrote: > This is a message I intended to write for some times, but the Toronto > hackfest notes gives me incentives to actually send it. > > In these notes, there is a paragraph saying Benjamin seems not too happy > with librsvg. > So I would appreciate any feedback regarding lasem design and > implementation, or any comment about the possibility of using lasem as a > replacement of librsvg. Did you receive any feedback? Because there is no replies to this thread, but it looks to me an important subject if the GTK+ project is looking at using an SVG rasterizer library. CCed Benjamin. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [ Revised Proposal ] Continuous Builds in GNOME
On Sat, Jun 18, 2016 at 08:15:19AM +0100, Emmanuele Bassi wrote: > So, I want to stop this thread on my side because not only is making > me not want to contribute anything ever again, but it also is > absolutely pointless busy work that relies on two people architecture > astronauting without the minimal intention of building anything or > even consensus. Citing myself from several mails ago: "With master/master-stable, it's a more relaxed atmosphere." https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg2.html There is a proposal that is simple to understand: when tagging a module in GContinuous, this would mirror what jhbuild builds by default. With a branch. That's it. Then there are more complicated proposals where everything is fully automated, delivering a stable desktop continuously to end users. I didn't talk about it, but it would enable to do canary releasing and A/B testing. And there is a gray scale between those two proposals. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Tue, Jun 07, 2016 at 07:34:42AM +0200, Milan Crha wrote: > > > There is a solution: bump the major version of Camel or EDS each time an > > > API or ABI break is unavoidable, making the new major version > > > parallel-installable with the previous ones. And that, every 6 months if > > > needed (or one year if the development cycle is longer for the > > > Evolution-related projects). > > there is no need to give me pointers to things and practices which are > already used in the project. It can be useful for some other projects, > for some maintainers following this thread, thought. > > I mean, that's exactly what we do (unless accidentally overlooked). If > the API/ABI changes, a soname version is bumped for that respective > part, at least once between releases (I just did a soname version bump > of Camel for 3.21.3 in one commit, then I did another change in the > Camel API in another commit, but I didn't bump the soname version, > because that all will be available for the early adopters in one single > release, 3.21.3). What I meant is that for the Camel library, incompatible versions should be parallel-installable, like GTK+ 2 and GTK+ 3. That way, some modules could still depend on the previous major version of Camel, and you can port the modules that you want to the new major version of Camel, one at a time if you want. From a quick glance at the evolution-data-server repo, this isn't done. The difference would be that all modules still build and work fine. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Tue, Jun 07, 2016 at 05:24:21PM +0900, Tristan Van Berkom wrote: > One approach might be a setup where we have an RC branch opened for > integration of changes from master at the beginning of each cycle - > this could be a sort of "soft master" that builds but might not be > bleeding edge in every way, it could benefit new comers as they could > still submit patches against the RC branch and it should at least > successfully build all projects from scratch. Also it could benefit the > release team inasmuch as we could have constant awareness of exactly > how much of the bleeding edge currently integrates at a given time. > > I strongly disagree with holding project maintainers responsible for > creating feature branches and burdening them with the duty of updating > other modules not under their control, especially for reasons already > outlined in [0], however perhaps a uniform 'integration' CI branch > could be automated to a certain extent, as gnome-continuous currently > blacklists not-building modules, it could instead be made to guess what > changes break a build and recreate the integration branch without the > said failing patch, performing tries with merges from master until > something builds and integration can again include the new changes. > > This of course, requires real thought and engineering, but I wanted to > at least offer some technical input, some starting point that could be > explored - this wont be solved without real engineering, trial and > error. It's similar to the "master/master-stable-next/master-stable" branches concept that I thought about in this previous sub-thread. See those two mails: https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg2.html https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg8.html It doesn't look like rocket science to me, and it would get us closer to continuous delivery. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Mon, Jun 06, 2016 at 10:10:58PM +0200, Sébastien Wilmet wrote: > There is a solution: bump the major version of Camel or EDS each time an > API or ABI break is unavoidable, making the new major version > parallel-installable with the previous ones. And that, every 6 months if > needed (or one year if the development cycle is longer for the > Evolution-related projects). Mmh maybe it's not possible for EDS, since it's a daemon (or contains a daemon) and thus only one instance can run on a system. I don't know much about how EDS, Camel etc are designed. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Mon, Jun 06, 2016 at 07:05:49PM +0200, Milan Crha wrote: > There is a bug to make more structures in Camel GObject based [2], to > be able to introspect it in a much easier way and so on. That change > will not be only a simple API change, it'll break core Camel things, > everything what uses it. If you open the [2], then I listed affected > projects at the end of the comment #5. It counts 18 projects. Maybe > there are more. I do not think I'd be able to coordinate the change in > a side branch for all of them, I (we) will surely provide patches in > the bugzilla around the time of the change landing, then it'll be up to > the respective maintainers to pick or reject them. What will the > Continuous do during this "broken period" is something I do not know. I > only know that the change will be for good. Introspection support for > the Mail part is good, I believe. Trying to revert such change in the > eds would hurt very much, no doubt. There is a solution: bump the major version of Camel or EDS each time an API or ABI break is unavoidable, making the new major version parallel-installable with the previous ones. And that, every 6 months if needed (or one year if the development cycle is longer for the Evolution-related projects). Distros might not like that, but packagers should be encouraged to drop old major versions if it is no longer used by any package. (As a more practical matter, instead of hardcoding the API/major version a bit everywhere in the build system, see how it is done at: https://developer.gnome.org/programming-guidelines/stable/parallel-installability.html.en with @LIBRARY_API_VERSION@ in the Makefile.am etc. That way the API version can be bumped easily). One of the initial goals of developing a shared library is to reduce memory consumption. But with systems like Flatpak, that goal is fading away: there will be a new GNOME runtime version every 6 months. And with today's computers, is it more important to save, say, 100MB of memory, or to fluidize the development and ease big refactorings? -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Games source name
On Fri, Jun 03, 2016 at 10:50:04AM -0500, Michael Catanzaro wrote: > I talked with Adrien and he doesn't want to change the name... so GNOME > Games it will continue to be. So there's probably not much point to > continued discussion here. > > I realize this is inconvenient for Debian and other distros that might > need to pick a different source package name, but the original upstream > gnome-games module was removed in GNOME 3.8, so it's been three years > from an upstream perspective and we're fine with reusing the name at > this point. Then the gnome-games project can recommend to distros to use another name for the package, so that it has more chances that it'll be the same name on all distros. -- Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
