Too many broken modules

Hi devs, There are too many broken modules right now! Here is the list of modules that Javier had to skip when releasing 3.25.4: 'pango', 'at-spi2-atk', 'vte', 'gdm', 'clutter-gtk', 'graphene', 'nautilus', 'glade', 'libgxps', 'libgepub', 'gnome-font-viewer', 'fwupd', 'gnome-terminal',

Re: Too many broken modules

On Mon, Jul 31, 2017 at 12:36 PM, Arun Raghavan wrote: Is there some place we can look at logs of the current build? I don't have a jhbuild-y setup here, but I'd be happy to look at the gst-* failures. Nope, got to ask Javier if he remembers why it failed. Sorry. We know

Re: Building GNOME in restrictive network environments

On Mon, Jul 31, 2017 at 2:15 PM, Bastian Ilso wrote: We also experienced this issue at the newcomers workshop as many flatpak manifests also download dependencies using the git:// protocol. It'd be great to have these fixed or maybe have a fallback behavior (having

Re: 3.25.90 will probably be delayed

On Sun, Aug 13, 2017 at 10:33 AM, Richard Hughes wrote: I can do this tomorrow, today I have family things to sort today. Thanks to everybody offering PRs for the colord issues, I've merged all of them and I think we're in good shape now. Yeah that's fine, enjoy your

Re: 3.25.90 will probably be delayed

On Thu, Aug 10, 2017 at 6:25 PM, mcatanz...@gnome.org wrote: Unfortunately I don't see anything wrong with the generated enums files. It turned out those are actually distributed in the PackageKit tarball, which was briefly a subject of suspicion since there are no problems when building from

Re: 3.25.90 will probably be delayed

Hi developers, I'm still struggling to get buildable release modulesets for 3.25.90. As you know, tarballs for that release were due Monday and the release was due Wednesday, but it's Saturday now and I haven't delivered it yet. Normally I spend about one day working on a release and it's not

Re: 3.25.90 will probably be delayed

Whew, it's done! I wound up doing a minimal number of workarounds: * Held colord at a previous version * Built PackageKit without Vala support * Built totem without plugin support This is a normal amount of workarounds. There's always a few hacks we need to do to get everything building. So in

Re: 3.25.90 will probably be delayed

Thanks a bunch. Ernestas! Now if I can get a new colord tarball, I think this might work. I can disable vala support in PackageKit because vala ships its own PackageKit vapi, but that wasn't an option for colord Michael ___ desktop-devel-list

Re: 3.25.90 will probably be delayed

On Sat, Aug 12, 2017 at 3:40 PM, mcatanz...@gnome.org wrote: [3] I've uploaded tentative jhbuild modulesets [3] for smoketesting, so you can build with the exact same tarball versions and build flags that we release. Sigh, Geary Here they are:

Re: 3.25.90 will probably be delayed

On Sat, Aug 12, 2017 at 4:52 PM, Bastien Nocera wrote: What usually happened in the past was that the older version was used when such a problem happened, which would hopefully have streamlined the process somewhat ("I used this old version because that new one...). Yes.

Re: For projects switching to Meson *only*

On Fri, Apr 28, 2017 at 4:40 AM, Bastien Nocera wrote: On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote: On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer wrote: > I will, but I'll keep the two parallel for at least a release or >

Re: For projects switching to Meson *only*

On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer wrote: I will, but I'll keep the two parallel for at least a release or two. If you need me to add anything specific to keep continuous happy for the time being, let me know. Cheers, Peter Here's a request for

Re: For projects switching to Meson *only*

On Sat, Apr 29, 2017 at 7:45 AM, Bastien Nocera wrote: Are you saying you reverted jhbuild module changes, without notifying the committer, because there's a problem with the grilo/grilo-plugins handling, I did notify the committer (Javier). but you didn't file a bug

Re: 3.25.90 will probably be delayed

On Tue, Aug 8, 2017 at 4:37 PM, mcatanz...@gnome.org wrote: Hi, Unfortunately 3.25.90 is going to be delayed indefinitely until all the tarballs build for me. It hasn't been going well so far. As I mentioned last week, there are a much higher number of failures than usual due to the meson

Re: Building GNOME in restrictive network environments

On Mon, Jul 31, 2017 at 1:29 PM, mcatanz...@gnome.org wrote: I'm testing this now and will push as soon as I'm sure I haven't broken anything. Done. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: 3.25.90 will probably be delayed

On Tue, Aug 8, 2017 at 10:45 PM, mcatanz...@gnome.org wrote: OK, I'm done sending emails. If you don't have a mail from me, then your module is probably fine. Michael Another update. Thanks to lots of help from lots of people, I'm down to just three known build failures. (There might be

developer.gnome.org and meson

Hi, 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

Re: GNOME 3.25.91 released

On Wed, Aug 23, 2017 at 3:45 AM, Andika Triwidada wrote: *.modules are named 3.25.90? wrong files? wrong names? Oops! I will fix this. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: GNOME 3.25.91 released

On Wed, Aug 23, 2017 at 4:13 AM, Bastien Nocera wrote: The person releasing the GNOME releases usually also spins a new version of gnome-desktop so that the About section of the Settings has correct information. Can you please make sure this gets added to the checklist for

Re: Proposal to deploy GitLab on gnome.org

Another issue we haven't discussed yet is commit permissions. Right now, everyone can commit anything to every repository, but with GitLab we'll probably eventually want something more fine-grained where *active* maintainers have more control over who is allowed to commit. Currently we still

Re: Proposal to deploy GitLab on gnome.org

On Tue, May 16, 2017 at 11:12 AM, Germán Poo-Caamaño wrote: From the migration plan in the wiki: "Our contention is that copying/moving every existing GNOME issue to a new issue tracker is impractical and, in many situations, undesirable." May you expand in which

Re: Proposal to deploy GitLab on gnome.org

On Tue, May 16, 2017 at 12:03 PM, Ray Strode wrote: Hi, On Tue, May 16, 2017 at 12:20 PM wrote: Another issue we haven't discussed yet is commit permissions. Right now, everyone can commit anything to every repository, but with GitLab we'll

Re: Proposal to deploy GitLab on gnome.org

On Tue, May 16, 2017 at 12:23 PM, mcatanz...@gnome.org wrote: Some maintainers want this, and I think that will be fine in the future. I don't really care much either way, because I've never seen any intentional abuse, and if someone commits something wrong to one of my projects I can simply

Re: Proposal to deploy GitLab on gnome.org

On Thu, May 18, 2017 at 11:36 AM, Andre Klapper wrote: The Traceparser is another (basically) unmaintained custom extension we have in our Bugzilla, with some confusing bugs (e.g. bug 744491). I think we should remove this extension immediately. It provides limited value,

GNOME 3.25.91 released

Hi, GNOME 3.25.91, a late development preview of the upcoming GNOME 3.26 release, is now available. Please help us test it. If you want to compile GNOME 3.25.91 by yourself, you can use the jhbuild modulesets available here: https://download.gnome.org/teams/releng/3.25.91/ The lists of

paste.gnome.org

Hi, paste.gnome.org is great, except for: "You must select a language other than 'text' for this paste." where is the source code? Can we get rid of this? Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org

Re: Proposal for reducing the number of unremovable apps in GNOME Software

On Sat, Nov 4, 2017 at 2:41 PM, Florian Müllner wrote: Why is that in the list? I would expect most users to use the various PrintScrn shortcuts for taking screenshots, which don't depend on gnome-screenshot (anymore). Maybe we should drop it from core, then?

Proposal for reducing the number of unremovable apps in GNOME Software

Hi, Currently about half of the GNOME core apps are unremovable in GNOME Software. It's the set of apps that are not new additions to core over the past two years, but at this point that's entirely arbitrary. So we need to find a better criterion for determining what should and should not be

Re: Proposal for reducing the number of unremovable apps in GNOME Software

On Tue, Nov 7, 2017 at 5:05 AM, Allan Day wrote: 3. I guess I just find it strange that this mechanism is so decentralised. Can anyone use ? Yes. Who makes the decisions about what's included and what isn't? How is that monitored and managed? Application developers make

Re: GitLab update: Moving to the next step

On Fri, Dec 8, 2017 at 3:40 AM, Emilio Pozuelo Monfort wrote: Can't you write a simple greasemonkey script to add canned replies to gitlab, until they are implemented upstream? No, because our web browser does not support Greasemonkey yet. (Should be possible to do using

Re: GitLab update: Moving to the next step

On Sun, Dec 10, 2017 at 10:04 AM, Michael Catanzaro wrote: I was providing my opinions on which issues should be blockers for GNOME. I'm not issuing demands here... Carlos is running this show. I updated a tracker bug today:

Re: GitLab update: Moving to the next step

On Thu, Dec 7, 2017 at 2:04 PM, Michael Catanzaro wrote: Looking over #8, I think duplicate issues, canned replies, and dependencies between issues should all be considered blockers to issue tracker migration. Carlos has pointed out that there is rudimentary (not very

GNOME 3.26.2 released

Hi, I'm pleased to announce the release of GNOME 3.26.2, the final planned release for the GNOME 3.26 series. It includes many bugfixes, documentation improvements, and translation updates. All distributions shipping GNOME 3.26 are strongly encouraged to upgrade. Packages should arrive in

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

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: Release team now using gnome-build-meta repository, not JHBuild

On Sat, Jan 20, 2018 at 3:47 AM, Tristan Van Berkom wrote: JHBuild --- For what regards the upcomming 3.28 release and further, patches should go to the gnome-build-meta project instead of the JHBuild modulesets - otherwise these patches would not be

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

On Wed, Jan 24, 2018 at 2:11 PM, Florian Müllner wrote: Really, the only thing I disagree with is that RT appears to actively discourage maintainers from updating JHbuild before everyone actually has the option to make the switch - sure, if updating GTK+ fails for me

Re: GNOME 3.27.90 beta tarballs due (and more) (responsible: mcatanzaro)

On Thu, Feb 1, 2018 at 6:00 PM, Release Team wrote: Tarballs are due on 2018-02-05 before 23:59 UTC for the GNOME 3.27.90 beta release Hi maintainers, If you're reading this, now is a good time to do your releases! No need to wait until the last minute on Monday.

3.27.90 tarball deadline extended

Hi developers, TL;DR: the 3.27.90 tarball deadline is extended until next Monday The release team is still learning how to get by in a BuildStream world. It turns out that nobody who is currently available knows how to generate release tarballs using BuildStream. Many developers, notably

Freezes begin today

Hi all, Despite the release schedule change, we're now quite close to the final 3.28.0 release, so to ensure quality we should begin all the freezes as previously-scheduled. That means UI freeze, feature freeze, API/ABI freeze for libraries, and the string change announcement period all

Re: 3.27.90 tarball deadline extended

Hi developers, We're getting closer, but we're not yet at a point where we can recommend that you try generating release tarballs with BuildStream and expect it to work. So I have to reluctantly recommend that you use JHBuild to generate your 3.27.90 release tarballs, if your module has

Re: 3.27.90 tarball deadline extended

On Mon, Feb 5, 2018 at 11:59 AM, mcatanz...@gnome.org wrote: The release team is still learning how to get by in a BuildStream world. It turns out that nobody who is currently available knows how to generate release tarballs using BuildStream. Hi developers, An update on this. With some help

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

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: 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,

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: 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.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

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: 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.

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

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

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

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: Release team now using gnome-build-meta repository, not JHBuild

On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano wrote: What's the workflow for those before a proper solution is done? Or are the developers of those modules expected to maintain JHbuild on the meantime? Thanks Carlos; this is an important question. Let me provide a

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

Hi, On Sun, Jan 21, 2018 at 3:16 AM, Jens Georg wrote: So, following up on that and also on the libgepub thread: Which places do I have to modify if I were to switch the ABI and API version of gexiv2 (to either keep depending entities on the old stable branch or to the new

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

On Sun, Jan 21, 2018 at 6:02 AM, Tristan Van Berkom wrote: gexiv2 is listed as a system dependency, which strikes me as a bit odd seeing as it's a requirement for some GNOME modules and it's hosted in GNOME - I'm new to the release team and will have to

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

On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote: Were you actually using JHBuild to run integrated system components (gnome-shell, gnome-session)? If so, how? I was not aware that that was even possible nowadays. When developing these components, Sorry, trying again When

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

On Mon, Jan 22, 2018 at 6:33 AM, Florian Müllner wrote: Is this information outdated? At least I see all those components in the gnome-build-meta repo, so I dare to hope ... You can build them, and there is CI to ensure the build does not fail. But I imagine it would

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

On Mon, Jan 22, 2018 at 9:13 AM, Florian Müllner wrote: Very much, I actually use a jhbuild GNOME session as my everyday system. I don't have a good answer. :/ Michael ___ desktop-devel-list mailing list

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

On Mon, Jan 22, 2018 at 3:12 PM, Bastien Nocera wrote: Or c) nobody's needed to recompile at-spi-core2 because it hasn't changed in significant ways in years and the distro provided versions work just fine. My at-spi-core checkout dates back from 2013. I, and I suspect a

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

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

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:

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: 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

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: 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: 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

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

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

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: 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.

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: 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: 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: 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

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

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

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 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: 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

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: 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.

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: 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

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: 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 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 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

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: 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

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: 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

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

  1   2   >