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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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:
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
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
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
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
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
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
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
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
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
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.
___
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
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
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
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
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,
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
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
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.
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:
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
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
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
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.
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
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:
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
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
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
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
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
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
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,
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
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
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 - 100 of 147 matches
Mail list logo