Let's update our doaps!

Hi, Please take a moment to look through your .doap files and remove any old/inactive maintainers, or switch them from tags to tags. There seem to be many projects just adding new maintainers but never removing old ones, as if in fear of perhaps offending the former maintainers. But it

Re: Changes: GNOME 3.35/3.36 release schedule

On Thu, Sep 12, 2019 at 8:22 AM, Bastien Nocera wrote: This is very important for the maintainers of libraries that live in the GNOME runtime. Do we have a full list of those? What happens if there are security issues that crop up in the meanwhile? Security issues that crop up in the

Re: Changes: GNOME 3.35/3.36 release schedule

On Thu, Sep 12, 2019 at 2:45 AM, Milan Crha via desktop-devel-list wrote: As a real life example, I skipped 3.32.5 this year, because there was no code change in the stable branch with which the users could benefit. The late stables are for bug fixes, from my point of view. I wondered about

Re: GNOME 3.33.92 (GNOME 3.34rc2) RELEASED

On Fri, Sep 6, 2019 at 6:56 PM, Javier Jardón wrote: the final release is scheduled next Wednesday! Oops, it will really be Thursday, September 12. The release was originally scheduled for Wednesday because I'm bad at picking good dates. You might still have stale calendar events scheduled

Re: Epiphany memory corruption problem

On Tue, Sep 3, 2019 at 6:45 AM, Bastien Nocera wrote: Maybe release 3.32.x as a 3.34 instead if that's the problem? We absolutely could, but have no way to know where the memory corruption was actually introduced. It could be an Epiphany regression (not unlikely). But it could also be a

Re: Epiphany memory corruption problem

On Sat, Aug 17, 2019 at 4:41 PM, mcatanz...@gnome.org wrote: The bug report shows valgrind crashes on startup. I've tried to get a working asan build of Tech Preview, but haven't been successful. If anyone is willing to help with asan, that would be great. Unfortunately we never solved this

Hard code freeze is here ❄

Hi developers, As of 45 minutes ago, we are now in hard code freeze for GNOME 3.34.0! No further code changes may be made without permission from release team. The goal of this freeze is to improve the quality of GNOME 3.34. If you think a code change will improve quality, has low risk of

Re: Epiphany memory corruption problem

Eh, perhaps bad timing, but I was just running valgrind over geary after a geary crash, and noticed: https://bugs.webkit.org/show_bug.cgi?id=199295 which I had totally forgotten about. I don't know whether that's our problem or not, but probably no sense in worrying about mystery memory

Epiphany memory corruption problem

Hi, Epiphany 3.34 is going to be a pretty crashy release, because we've developed a memory corruption problem that seems almost impossible to debug: https://gitlab.gnome.org/GNOME/epiphany/issues/876 The bug report shows valgrind crashes on startup. I've tried to get a working asan build

Re: Proposal: earlier tarball deadlines

On Fri, Aug 16, 2019 at 10:39 pm, Alexandre Franke wrote: Indeed. Moreover, in my experience, many maintainers consciously leave that time for translators and check the status of their module on Damned lies to see if there’s any team currently working on it and whether they need to wait just a

Re: Proposal: earlier tarball deadlines

On Fri, Aug 16, 2019 at 7:31 pm, Alexandre Franke wrote: Weekends are usually the time when most translations get done. If you remove this opportunity, I guess we should consider freezing earlier too so that translators basically get the same amount of time to do their job. I'm a bit confused

Proposal: earlier tarball deadlines

Hi, I'd like to propose moving tarball deadlines for the 3.36 cycle one business day earlier, from Mondays to Fridays, while leaving the overall release deadline on Wednesday. That way, we can have the weekend for trying to build the release. This will allow release team more time to resolve

Re: Games in need of maintainers

On Tue, Aug 6, 2019 at 10:20 AM, mcatanz...@gnome.org wrote: So that leaves just Quadrapassel and Tali in need of help: We have a volunteer for Quadrapassel too, so every game is now assigned. Thanks all! Although gnome-klotski, gnome-robots, and gnome-tetravex are assigned, these are

Re: Games in need of maintainers

On Tue, Aug 6, 2019 at 1:17 PM, Mart Raudsepp wrote: I can try my hand on Tali, if needed, as long as it remains written in C. I don't feel strongly about it at all, just to help, so basically if no-one else steps up.. Was going to offer for both, but then found that the other one is vala.

Re: Games in need of maintainers

On Tue, Aug 6, 2019 at 5:07 AM, Arnaud Bonatti wrote: Yes, I’ve by two times tried to avoid some work for translators in original ways, and some of them have been not happy with that. We’ve already discussed about that, and I’ve understood in the process that nothing is really doable here

Re: Games in need of maintainers

On Tue, Aug 6, 2019 at 4:59 AM, Alberto Ruiz wrote: I can take care of mahjongg, although not before next week as I am on vacation and won't have access to a computer. Thanks Alberto! ___ desktop-devel-list mailing list

GNOME 3.33.90 released

Hi developers and testers, GNOME 3.33.90 is now available, slightly ahead of schedule for a change! This is the first beta release for GNOME 3.34. To ensure the quality of the final release, we have entered feature freeze, UI freeze, and API freeze, so now is a good time for distributors

Freezes in effect

Hi developers! It's that time of the year again: a new stable release, 3.34, fast approaching. That means it's time to lock down our feature set and go into bugfixing mode. As usual, the following freezes are now in effect: * API/ABI freeze * Feature freeze * UI freeze * String change

Games in need of maintainers

Hi, I'm trying to find new maintainers for the following games: four-in-a-row, gnome-klotski, gnome-robots, gnome-mahjongg, gnome-tetravex, quadrapassel, tali The first three in the list used to be lightly maintained by me, but I don't want to keep releasing them. I'll continue to care for

Re: Some nigthly flatpaks are failing to build

On Fri, Aug 2, 2019 at 5:51 PM, Michael Gratton wrote: Is there any way to get notification for build failures here? I frequently don't end up seeing the build failures. Email sent to people listed in the project's DOAP maybe? Unfortunately there's currently no way to be notified of build

Re: GNOME 3.33.4 RELEASED

On Wed, Jul 24, 2019 at 5:19 AM, Javier Jardón wrote: Little reminder: "The Freeze" is only a week and a half away (5th of August), so please be sure to finish on time all those awesome features you have been working on this cycle Hi all, To help the next release go smoother, I'd encourage

Re: GNOME 3.33.4 unstable tarballs due (responsible: jjardon)

Hi, This release will be delayed, probably until next week. We're still working out problems with dependencies. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Heads-up: possible breakage in the master flatpak runtime

On Fri, Jun 28, 2019 at 9:36 AM, mcatanz...@gnome.org wrote: Bug is https://mail.gnome.org/archives/desktop-devel-list/2019-June/msg00018.html Sorry: https://gitlab.gnome.org/GNOME/gnome-software/issues/723 ___ desktop-devel-list mailing list

Re: Heads-up: possible breakage in the master flatpak runtime

Hi again, We've discovered that updating with GNOME Software will break your flatpak apps. You must update with the flatpak CLI to fix this, not with GNOME Software. Everything should be in good shape after you do a one-time update using the CLI. Bug is

Re: Heads-up: possible breakage in the master flatpak runtime

On Wed, Jun 26, 2019 at 9:04 AM, mcatanz...@gnome.org wrote: Now Abderrahim has fixed the problems with the last attempt and we are trying to upgrade to 19.08 again. Also Tristan. Thanks Tristan! ___ desktop-devel-list mailing list

Re: Heads-up: possible breakage in the master flatpak runtime

On Fri, Jun 21, 2019 at 3:16 AM, a.kitouni--- via desktop-devel-list wrote: Nightly apps may be broken (as in refuse to start) for up to 24h until they're rebuilt against the new ABI, so if you depend on a nigtly app don't update today. Hi, I wound up reverting back to the 18.08 runtime due

Re: Heads-up: possible breakage in the master flatpak runtime

Hi, It looks like the runtime is going to be broken for a couple days due to https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/181. You can downgrade to the last good version with: $ flatpak update --commit=4935b45d02b85cf5ab09a7ec28f851fcc850f28f0e9b9911808f002c49aee6eb

Re: System-wide dark mode

On Wed, Jun 5, 2019 at 1:14 PM, Alexander wrote: Since WebKit supports Apple's dark mode now, I wonder if mail clients (and also Devhelp/Builder) will be able to provide styles for dark mode with that. Well we really don't, not yet. That's what I've been trying to say Once we do,

Re: System-wide dark mode

On Wed, Jun 5, 2019 at 1:44 AM, Tristan Van Berkom wrote: Are you saying that WebKitGTK interprets the system theme and CSS to render the HTML content ? Yes, as does Firefox. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: System-wide dark mode

On Mon, Jun 3, 2019 at 5:40 AM, Allan Day wrote: If the size of the theme is the issue, do we know what size is acceptable? For WebKit to be able to handle this, the required performance improvement would be measured in orders of magnitude. I don't know about Firefox. Without changes in

Re: System-wide dark mode

On Thu, May 30, 2019 at 4:15 AM, Allan Day wrote: How does this relate to the dark mode in WebKit? I was hoping that Web would follow the system-wide dark mode preference, and expose it to websites... The ideal, desired behavior is to enable dark mode on any websites that opt-in to dark

Re: System-wide dark mode

On Wed, May 29, 2019 at 8:35 AM, Allan Day wrote: Therefore, before we get too far into planning and implementing this feature: does anyone know of any serious obstacles they'd face, if we were to support a dark mode? WebKit is having trouble with this now:

Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

On Sat, May 4, 2019 at 4:22 AM, Bastien Nocera wrote: The person you quoted is a troll. In fact, I'm not sure there's any comments on that issue that aren't trolls (apart from the OP and the repository owner). Ah OK then, fooled me because he took a such strong plausibly-sincere stance

Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

On Fri, May 3, 2019 at 5:57 PM, Bastien Nocera wrote: Seriously Michael, you’re embarrassing yourself. I don't feel very embarrassed. Your suggested alternative name, "main," is clearly considered to be offensive by at least one of the very same people who don't like "master," and who

Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

On Fri, May 3, 2019 at 5:09 AM, Bastien Nocera wrote: - And to what? A few possible names were mentioned/used. "mainline" was thought to have strong connections to drug use, "release" (use in the contributor covenant) seems to restrictive (we also do releases from other branches). I like

Re: Proposal: Replace all references to master/slave in GNOME modules

On Wed, May 1, 2019 at 6:08 AM, Michael Gratton wrote: This has already been covered in the original proposal under objection (1) "It doesn't matter". As has already been discussed, what actually doesn't matter is what you or I think, it is the people who have been affected by the language we

Re: Proposal: Replace all references to master/slave in GNOME modules

On Wed, May 1, 2019 at 12:22 AM, Tristan Van Berkom wrote: We should also not show favoritism of one set of cultural values over another, I feel that censorship to this degree is a very western concept which we should not lend any credit to. Ask has already pointed out that the possible

Re: Proposal: Replace all references to master/slave in GNOME modules

I'm a little surprised that nobody has yet mentioned the elephant in the room. The definition of "git" is not very inclusive: From https://www.merriam-webster.com/dictionary/git: British : a foolish or worthless person Or from https://www.thefreedictionary.com/git: n. Chiefly British

Re: GNOME 3.33.1 RELEASED

On Fri, Apr 26, 2019 at 2:43 AM, Samuel Thibault wrote: I guess I am missing something in the process of releasing a version? Or is accerciser perhaps just not part of a desktop package set? Only GNOME core elements are included in the release. accerciser is in world, not core. Michael

Re: Proposal: Replace all references to master/slave in GNOME modules

Hard to believe this is a serious discussion that we're actually having. On Thu, Apr 25, 2019 at 7:02 AM, jtojnar--- via desktop-devel-list wrote: On Thu, 25 Apr, 2019 at 11:21 AM, Daniel Playfair Cal via desktop-devel-list wrote: "master/slave" -> "leader/follower" Please note that

Re: Proposal: Replace all references to master/slave in GNOME modules

This should go without saying, but master branches are not a reference to slavery, rather to canonicity. The master branch is the canonical branch, the primary copy. The relevant dictionary definition here (Merriam-Webster) is "an original from which copies can be made." As was pointed out

Re: Gnome 3.32 Bugs

On Sun, Apr 7, 2019 at 6:38 PM, Ty Young via desktop-devel-list wrote: If any of these aren't known and reported yet I can report them. I'm using Arch/Fedora 30 Beta Silverblue. I'd recommend reporting separate bugs for all of these. ___

Re: Upcoming evolution-data-server API changes (libical-glib + more)

On Thu, Apr 18, 2019 at 12:29 PM, Milan Crha via desktop-devel-list wrote: One thing, with the prepared merge requests [which will need changes in the version reference (they reference libecal-2.0 as 3.33.1, while it'll be a different version)], should I contact respective maintainers anyhow

GNOME 3.32.1 released!

Hi, GNOME 3.32.1 is now available. This is a stable release containing four weeks' worth of bugfixes since the 3.32.0 release. Since it only contains bugfixes, all distributions shipping 3.32.0 should upgrade. If you want to compile GNOME 3.32.1, you can use the official BuildStream project

Re: 3.32 applications still missing icon changes

On Sat, Mar 30, 2019 at 11:32 AM, Leslie S Satenstein wrote: Monday April 4th??? Is your desktop calendar set to February? Good catch. I meant Monday, April 8 and Tuesday, April 9. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

3.32 applications still missing icon changes

Hi, I'd like to proposal a global freeze exception to encourage all applications to feel free to belatedly update to Jakub's new app icons, to improve consistency. This freeze exception would expire Monday, April 4 when 3.32.1 tarballs are due. Two core apps are still missing Jakub's new

Re: I believe we should reconsider our sys-tray removal

On Mon, Mar 25, 2019 at 12:33 PM, Florian =?iso-8859-1?q?M=FCllner?= wrote: I'm not. The StatusNotifier spec is seriously flawed, and I don't want to support it unless at least the issues that were raised ten years ago are addressed (the spec was put up for "review" on xdg-list, but then any

Re: I believe we should reconsider our sys-tray removal

On Sat, Mar 23, 2019 at 1:06 PM, Britt Yazel wrote: I believe that there is an elegant solution to handling sys-tray icons without sacrificing our core goals, one idea being to incorporate it into the Dash. I wonder if there's been any serious design consideration of this proposal? The dash

Re: Extension review

On Mon, Mar 25, 2019 at 6:16 AM, Neil McGovern wrote: Just to confirm though, is this for working on the extension review infrastructure, or actually doing reviews? That may change the answer :) Actually doing reviews, I think. Dunno, I'll pass him on to you.

Extension review

Hi devs, I found a volunteer who's interested in helping out with shell extension review. Who should he talk to? Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Update your libhandy submodules (and packages)

Yeah, a new libhandy release ASAP would be appreciated. Affected applications: epiphany gnome-bluetooth gnome-contacts gnome-control-center gnome-games I think libhandy has reached the point that it's time to start thinking about making it a system dependency so we don't have to enter panic

Re: API stability for Meson configuration options

On Sun, Feb 17, 2019 at 8:55 AM, Sam Thursfield via desktop-devel-list wrote: Do we have a policy for if/when we can do breaking changes to Meson configuration API? If this was a change to the C API, we'd delay it until the next major release (in this case Tracker 3.0). If gnome-build-meta

Re: Clarifications regarding GNOME Online Accounts

On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield wrote: 1. require every user of the software to contact Google and obtain their own client ID, which they provide at runtime to any desktop software that needs to interact with Google APIs at Ha ha. 2. require distributors and people who build

Re: Clarifications regarding GNOME Online Accounts

On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list wrote: A solution would be for distribution package maintainers to use the binary tarball as a base instead of sources - this way the build can be done with secrets (ie. using GitLab CI and environment variable secrets) and

Re: Clarifications regarding GNOME Online Accounts

On Sat, Feb 16, 2019 at 12:57 PM, mcatanz...@gnome.org wrote: It's not clear to me how g-o-a can continue to exist, then. Also, Epiphany's Safe Browsing support. (How do Firefox and Chromium make this work?) Turns out it's a new restriction that took effect on January 16, 2019. So probably

Re: Clarifications regarding GNOME Online Accounts

On Sat, Feb 16, 2019 at 11:58 AM, Michael Terry wrote: “Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API

GNOME 3.31.90 released

Hi developers and testers, GNOME 3.31.90 is now available. This is the first beta release for GNOME 3.32. To ensure the quality of the final release, we have entered feature freeze, UI freeze, and API freeze, so now is a good time for distributors planning to ship GNOME 3.32 to start testing

Re: GitLab mirror considered harmful

FWIW I only use our GitHub mirrors when our GitLab is running slow. But that happens often enough On Mon, Feb 4, 2019 at 10:58 AM, philip.chime...@gmail.com wrote: Could we take it all the way and just push the PR branch to "$github_user_name/$branch_name" in the main repository on GitLab,

Re: GitLab mirror considered harmful

On Sun, Feb 3, 2019 at 8:59 PM, Christopher Davis via desktop-devel-list wrote: If we keep the mirrors around, then we should at the very least ensure that pull requests aren't able to be opened at all on the repos. GitHub doesn't allow disabling pull requests, that's why we have the

Freezes incoming!

Hi all, This is just a reminder that API/ABI freeze, feature freeze, and UI freeze begin this Monday, February 4. [1] The purpose of the freezes is to improve the quality of the upcoming GNOME 3.32 release. If you feel that breaking the freeze would allow you to improve the quality of the

Re: GNOME Online Accounts 3.34 won't have documents support

This is a tangent of a tangent, but: On Mon, Jan 28, 2019 at 9:29 AM, Jeremy Bicha wrote: Thank you for your reply. Ubuntu includes GNOME To Do by default in 18.04 LTS and still does. I guess we need to discuss whether it should be removed by default, but we try to limit the adding and

Re: GNOME Online Accounts 3.34 won't have documents support

On Sun, Jan 27, 2019 at 6:32 PM, Nathan Graule via desktop-devel-list wrote: Given what I've read about the Google policy (and I don't know how much of that was added with the Jan. 15 revision), but it seems like the very concept of GOA as a centralized account repository goes against Google

Re: GNOME Online Accounts 3.34 won't have documents support

On Sun, Jan 27, 2019 at 7:29 PM, Michael Terry wrote: You say deja-dup has nothing to worry about. But I very much have to solve the problem of many of my users losing access to their backups (through my app at least) in three weeks. Will not inspire confidence. Again, my fault I guess for

Re: GNOME Online Accounts 3.34 won't have documents support

On Sun, Jan 27, 2019 at 4:27 AM, Debarshi Ray wrote: It so happens that we have half a dozen notifications from Facebook and Google about our uses of their APIs at varying degrees of seriousness. They are still on my todo list. Thankfully, Philip Withnall and Michael Catanzaro are on top of

Re: GNOME Online Accounts 3.34 won't have documents support

On Thu, Jan 24, 2019 at 4:00 AM, Allan Day wrote: I'd personally like us to keep the path open for you and provide some guarantees about Geary being able to use Online Accounts in the future. I wonder if this should be part of a wider conversation about Geary becoming GNOME Mail? :) Seems

Re: GNOME Online Accounts 3.34 won't have documents support

On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera wrote: It is what is happening in GNOME Online Accounts in general. Pocket is disabled in Fedora 29, and there's a good chance that the mail configuration bits will be disabled in Fedora 30. I don't know whether those changes will also be done

Re: GNOME Online Accounts 3.34 won't have documents support

On Mon, Jan 21, 2019 at 9:14 AM, Christopher Davis via desktop-devel-list wrote: Hi Rishi, Cloud documents is an important part of where I want to move forward with the application, so Online Accounts integration would still be critical. A file previewer is definitely a priority, and an

Re: Documents and core apps

On Thu, Jan 17, 2019 at 11:06 AM, Bastien Nocera wrote: Nobody added the ability for gnome-documents to open files... Yeah, I think it never really had much chance without that. Music and Photos need to learn to open files, too. I'll probably split off Books at some point in the future.

Documents and core apps

On Thu, Jan 17, 2019 at 9:25 AM, Bastien Nocera wrote: I think the release team is wrong in the first place. Lack of maintainership and bugs don't equate to removal. Otherwise there would be plenty more applications to remove there... These were secondary reasons. The main reason is that we

Re: GitLab postmortem

On the whole, I'm really pleased with GitLab. Especially really pleased with the ability to start discussions during reviews and mark comments as resolved. It's a bit of a shame we can't batch comments like on GitHub, but marking discussions as resolved is amazing and makes up for it. The

Re: new GNOME Weather maintainers

First problems I see: There has not yet been a GitLab migration, so bugs and unreviewed patches are still on Bugzilla. First responsibility of new maintainers is to review unreviewed patches. But there's no way to list them. To get to the patch list, or just to view all the open bugs,

Re: getting commit rights for / maintaining Dia ?

Hi Tomas, You should have gotten an email about this from Zander. He will help manage this! Thanks, Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: extensions.gnome.org password resets

On Sat, Dec 1, 2018 at 11:43 AM, Yuri Konotopov wrote: Hi, Michael There is such feature exists. Look to screenshot attached. Well I'll be. It's not even hidden, either. It's right there where you'd expect it to be. Cool. I wonder why we get so many requests about this... or why they

extensions.gnome.org password resets

Hi, Most of the non-spam mail received GNOME security group is asking for help with extensions.gnome.org. Mostly people ask for password resets. We ignore all these mails. Is anyone maintaining extensions.gnome.org? It's really not OK to keep this website running without a password reset

GNOME 3.31.2 released

Hi, GNOME 3.31.2 is now available. This is the second unstable development release leading to 3.32 stable series. Apologies that it's slightly late: there were some technical snafus. If you want to compile GNOME 3.31.2, you can use the official BuildStream project snapshot. Thanks to

Re: Removing gstreamer git master from gnome-build-meta

On Wed, Nov 7, 2018 at 3:00 AM, Abderrahim Kitouni wrote: Hi all, We would like to remove gstreamer master from gnome-build-meta. What this means is that the nightly flatpak runtimes will have the latest gstreamer stable version (1.14.4 as of this writing, but 1.16 should be released soon). I

Re: GNOME 3.31.1 released

Thanks for your first release, Abderrahim! It's great to have you helping with releases. On Thu, Oct 11, 2018 at 1:58 PM, Abderrahim Kitouni wrote: There haven't been many updates to the GNOME modules in this release, I blame this partly on the fact that we had a problem with the script

GNOME 3.30.1 released!

Hi, GNOME 3.30.1 is now available. This is a stable release containing three weeks' worth of good bugfixes since the 3.30.0 release. Since it only contains bugfixes, all distributions shipping 3.30.0 should upgrade. If you want to compile GNOME 3.30.1, you can use the official BuildStream

Re: Retiring app menus - planning for 3.32.0

On Fri, Sep 21, 2018 at 2:47 PM, Bastien Nocera wrote: Those are not keyboard shortcuts, they're mnemonics, used for navigating menus using the keyboard, not launching keyboard shortcuts without opening the menu. Feel free to start a new discussion about those, but they're really not the

Re: Retiring app menus - planning for 3.32.0

On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera wrote: It's faster to access for users, has terser explanations (no need to create sentences to describe actions) and it's usually better updated as it lives in the code, as opposed to being separate in the docs. It's also larger, well-designed,

Re: [GitLab] Gravatar vs libravatar

On Tue, Sep 4, 2018 at 10:24 AM, Nicolas Dufresne wrote: So it's a gain in privacy if you want to host your own. I'm surely not the only one that isn't going that extreme in keeping control over couple of my pictures flying around and won't go that far. The gain in privacy comes from

Re: GNOME 3.29.91 released

On Thu, Aug 16, 2018 at 12:11 PM, mcatanz...@gnome.org wrote: Hi developers, I made a mistake in our release validation process, and accidentally included incompatible versions of glib (2.57.1) and gobject-introspection (1.57.2) in GNOME 3.29.91. gobject-introspection 1.57.2 requires glib

Re: GNOME 3.29.91 released

On Wed, Aug 15, 2018 at 5:42 PM, mcatanz...@gnome.org wrote: Hi, GNOME 3.29.91 is now available! Hi developers, I made a mistake in our release validation process, and accidentally included incompatible versions of glib (2.57.1) and gobject-introspection (1.57.2) in GNOME 3.29.91.

GNOME 3.29.91 released

Hi, GNOME 3.29.91 is now available! If you want to compile GNOME 3.29.91, you can use the official BuildStream project snapshot: https://download.gnome.org/teams/releng/3.29.91/gnome-3.29.91.tar.xz The list of updated modules and changes is available here:

Re: No app menu changes for GNOME 3.30, please!

On Tue, Jul 24, 2018 at 8:53 AM, Allan Day wrote: I'd expected there to be some discussion about the timeline and a decision by the Release Team. As it is, we're less than a week away from UI freeze and most apps haven't changed their app menus. For consistency's sake, it would be better to

libdw

Hi all, Has anybody recently added libdw as a dependency of anything in GNOME? I'm trying to figure out what has gone wrong in https://gitlab.gnome.org/GNOME/gnome-sdk-images/issues/13. Thanks, Michael ___ desktop-devel-list mailing list

GNOME 3.29.3 released

Hi developers, GNOME 3.29.3 is now available. This release is primarily notable in that all modules are buildable in this release, which is historically very rare for our development releases. This is an accomplishment! I hope we can keep this up going forward. If you want to compile GNOME

Re: GNOME 3.29.3 unstable tarballs due (responsible: mcatanzaro)

On Thu, Jun 14, 2018 at 8:02 PM, Federico Mena Quintero wrote: This: http://ftp.gnome.org/pub/GNOME/teams/releng/3.29.2/versions has librsvg 2.40.20, which is the unmaintained series. How can I change it to 2.43.0 for the development release? I'd really like to get some testing there.

Re: New module in GNOME: gnome-internet-radio-locator

On Mon, May 21, 2018 at 1:16 PM, Ole Aamot wrote: What else do I have to do to mark the module gnome-internet-radio-locator for release in GNOME 3.29.2 unstable? Hi Ole, For GNOME 3.28, we severely downsized what we release to just a few core GNOME apps and

GNOME 3.29.1 released

Hi developers, GNOME 3.29.1 is now available. If you want to compile GNOME 3.29.1, you can use the official BuildStream project snapshot. Thanks to BuildStream's build sandbox, it should build reliably for you regardless of the dependencies on your host system:

GNOME 3.28.1 tarballs due

Hi developers, It looks like our automated reminder mails are not working properly currently. (Does anybody know how to help fix this?) 3.28.1 tarballs are due Monday. You all know the drill. Thanks a bunch, Michael ___ desktop-devel-list mailing

Check your default window size!

Hi, Sometimes it's easy for a developer to forget what a new user sees when opening an app for the first time. Some of our apps (*cough* email clients *cough*) have default window sizes that are waaay too small. Check yours out! Increase the default window size if needed. Michael

Re: Making a phone call with GNOME

Note the DTMF is really, really unreliable... not sure if that's a bug in Empathy or in Telepathy, but I'd assume the later. I reported this as https://bugzilla.gnome.org/show_bug.cgi?id=770709. ___ desktop-devel-list mailing list

Re: Using BuildStream as a module maintainer

On Fri, Feb 16, 2018 at 4:15 PM, Shaun McCance wrote: > $ bst build --track-all --track-save core/yelp.bst > # For some reason I have to do this too? Not sure. > $ bst build core/yelp.bst It's a bug (very recently fixed): https://gitlab.com/BuildStream/buildstream/issues/236

Re: GNOME 3.27.90 released

On Thu, Feb 15, 2018 at 4:37 AM, Sam Thursfield wrote: Does it makes sense to create a tagged commit in gnome-build-meta.git for each release, instead of publishing the release metadata only as a tarball? I guess that could be quite useful, if people want to see what the

GNOME 3.27.90 released

Hi developers, Better late than never: GNOME 3.27.90 is here, exactly one week later than originally scheduled. With this release, the release team is no longer going to be building or releasing non-core applications. We have renamed the apps moduleset to world to reflect this. App

Re: Let's kill gnome-common!

On Tue, Feb 13, 2018 at 3:43 AM, Sébastien Wilmet wrote: 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. Hm,

Let's kill gnome-common!

Hi, 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. If you help fix these sad modules, you'll earn the right to say that you helped fix

Re: 3.27.90 tarball deadline extended

On Fri, Feb 9, 2018 at 8:36 AM, Bastien Nocera wrote: It was clear from the earlier mails that the release-team would be using BuildStream, it really wasn't explicit that the developers and maintainers of individual modules were also being asked that. To be clear, we're

Re: 3.27.90 tarball deadline extended

On Fri, Feb 9, 2018 at 9:14 AM, Emmanuele Bassi wrote: Whatever maintainers use to build release tarballs is fine — as long as you ensure that you're always keeping the build of the whole GNOME set of modules running. Yes, this! Milan, feel free to do the .91 release

  1   2   >