On Wed, 2010-12-08 at 07:23 -0500, Matthias Clasen wrote:
Doesn't build with gtk3:
evolution-data-server
gtkhtml
...
Needs e-d-s:
evolution
...
Hi,
there are 'gtk3' branches in these, where the development towards gtk3
compliance is done, though even with these branches
On Wed, 2010-12-15 at 11:06 -0500, Matthias Clasen wrote:
evolution (transient failure)
Hi,
what does this mean, please? Maybe if you can point us to the build log,
then we can look on it. Last time I tried to build gtk3 branches of
evolution packages (which is about a day ago) it didn't
On Thu, 2010-12-16 at 08:59 -0500, Matthias Clasen wrote:
What I meant with 'transient' failure is that it expected it to
succeed once the builders get around to rebuilding some dependencies
and then try evolution again.
Hi,
aha, thanks, I see it's trying to rebuild right now, so looks
On Mon, 2011-01-17 at 22:09 +0100, Andre Klapper wrote:
Evolution-Data-Server: Port to GSettings
https://bugzilla.gnome.org/show_bug.cgi?id=635379
Hi,
Matt answered in yours thread GNOME 3.0 Blocker Report for week 01
that this one will not be done on time (I understood his reply that
On Fri, 2011-08-26 at 00:05 +0200, Olav Vitters wrote:
That all said, I propose killing bug-buddy and recommending the usage
of ABRT.
Hi,
well, there are things about ABRT you might want to know. The feature of
ABRT talking to bugzilla is not that great, as it talks to downstream
On Fri, 2011-08-26 at 09:46 +0200, Olav Vitters wrote:
I guess you want to kill bug-buddy for regular users only, as you was
talking about bugzilla connection, because ABRT is unusable for
developers, as it silently ignores crashes in applications which are not
packaged, furthermore, if
On Fri, 2011-09-09 at 13:09 +0100, Javier Jardón wrote:
So if Its not already fixed in your module, we are going to proced to
fix all the GNOME modules that appear
in orange and convert it to yellow, ie
AM_MAINTAINER_MODE - AM_MAINTAINER_MODE([enable])
Hi,
you didn't give much time
On Mon, 2011-09-12 at 08:23 +0200, Milan Crha wrote:
On Fri, 2011-09-09 at 13:09 +0100, Javier Jardón wrote:
So if Its not already fixed in your module, we are going to proced to
fix all the GNOME modules that appear
in orange and convert it to yellow, ie
AM_MAINTAINER_MODE
On Wed, 2011-09-14 at 10:56 +0100, Ross Burton wrote:
On 14 September 2011 08:19, Milan Crha mc...@redhat.com wrote:
By the way, your change has a side-effect where DBus factories of
evolution-data-server (e-addressbook-factory and e-calendar-factory
processes) depend on gtk+ by default
On Wed, 2011-09-14 at 12:22 +0100, Ross Burton wrote:
On 14 September 2011 11:43, Milan Crha mc...@redhat.com wrote:
why is that? I can imagine couple useful things being tight to the
maintainer mode, also those aforementioned deprecated stuff being in use
only for maintainers
On Wed, 2011-09-14 at 12:53 +0100, Javier Jardón wrote:
...
if test x$enable_strict != xno; then
CPPFLAGS=$CPPFLAGS -DG_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED
-DGDK_DISABLE_DEPRECATED
fi
[1] https://bugzilla.gnome.org/show_bug.cgi?id=658608
Hi,
OK, that fixes one part of
On Thu, 2011-09-15 at 10:52 +0200, Dodji Seketeli wrote:
the above help string might then just suggest that I would rather define
my own --enable-maintainer-mode when I want to cover more things under
it.
If you do so, please don't call it --enable-maintainer-mode. I agree
with Ross
On Fri, 2012-12-14 at 13:42 +0100, Olav Vitters wrote:
If anyone wants to join, I'll work on Bugzilla during Dec 22 - Dec 30
together with Andrea.
Hi,
thanks a lot for that. I'm wondering, will you cover also bugs targeted
to Bugzilla 4.2, say those with patches? [1] Some looks harder,
On Fri, 2013-07-26 at 10:20 -0400, Matthias Clasen wrote:
If you've been using
gtk_widget_class_bind_child (GTK_WIDGET_CLASS (class), MyClassPrivate,
foo);
you need to change it to
gtk_widget_class_bind_child (GTK_WIDGET_CLASS (class), MyClass, foo);
The struct member foo is still
On Mon, 2014-02-24 at 18:17 -0500, Matthias Clasen wrote:
evolution-data-server
-
710683 Rebuild of libical (1.0) causes ABI break with the previous
version
Hi,
I would drop this from the list, and re-close with NotGnome resolution,
because it seems
Hello,
an Evolution team did maintain the GtkHTML in the past, because it was
its main component for a mail composer. This changed with a 3.13.3
release, when Evolution begun to use WebKit based composer. The 3.14.0
will be released together with GNOME 3.16.0, spring 2015 (Evolution
On Tue, 2014-10-14 at 21:17 -0500, Michael Catanzaro wrote:
For apps that are displaying web pages (everything not geary?)
with no such compatibility concerns, porting should be relatively
easy.
Hi,
just for your information, Evolution is on the same boat as geary, all
the previews
On Wed, 2015-02-11 at 09:52 -0800, Jasper St. Pierre wrote:
Out of curiosity, is there anything wrong with just copy/pasting a
link?
Hi,
I did that for the past few months. My comments in bugzilla sometimes
look like:
Created commit 123456 in evo master (x.y.z+) [1]
Created
Hello,
I'd like to ask: how does the auto-links for commits in the new
bugzilla work? I mean, if I write something like:
commit abcde12345
then the abcde12345 will become a link to the sources in the product
the current bug is filled for. It works similarly to bug auto-link
On Tue, 2015-02-10 at 10:20 +0100, Alexandre Franke wrote:
First of all, I'd like to point that the bug report for this feature
is still open at https://bugzilla.gnome.org/show_bug.cgi?id=559537
We started discussing the commit in another product issue there,
so maybe we can continue
On Thu, 2015-03-05 at 10:20 -0500, Matthias Clasen wrote:
evolution
-
728496 Gnome shell keeps poping modal dialog for gmail password
Hi,
this should not happen in 3.15.90, but I didn't close the bug, because
I was not able to reproduce it, thus I could not verify that
On Wed, 2015-05-06 at 09:46 +0100, Emmanuele Bassi wrote:
Indeed. Getting notifications of open pull requests to the
maintainers listed in the DOAP file would also be good, so each
maintainer can decide whether or not to integrate one or just direct.
Hi,
please do not do this by
On Sun, 2015-04-26 at 21:38 +0200, Stefan Sauer wrote:
The upcoming gtk-doc-1.22 release will switch the default makefile
flavour from legacy to no-tmpl.
Hi,
I'm trying to build evolution-data-server 3.16.2 against gtk-doc-1.22
and it fails [1]. It has its configure.ac with this line:
On Mon, 2015-05-11 at 11:19 +0200, Milan Crha wrote:
I'm trying to build evolution-data-server 3.16.2 against gtk-doc-1.22
and it fails [1]. It has its configure.ac with this line:
GTK_DOC_CHECK([1.14],[--flavour no-tmpl])
thus should not be affected by the change. Trying to build against
On Sun, 2015-07-19 at 23:17 +0800, Oliver Luo wrote:
I've been spending several days working on the migration from GConf
to GSettings/DConf in our project evolution EAS...
Hi,
I suppose you mean evolution-activesync, as it's named in the GNOME
repositories.
1. Use relocatable
On Wed, 2015-11-25 at 10:52 +, Philip Withnall wrote:
> Would such a list be useful for the release team, as a way of
> tracking who needs nagging? If so, then I hope producing it should
> not be too much of a drain on your time — if it is a drain, then you
> probably shouldn’t do it.
On Mon, 2016-06-06 at 20:32 +, Sriram Ramkrishna wrote:
> I think that is the point of the try server, right? You push it to
> the try server and make sure that it builds correctly for everyone...
Hi,
if you mean that "jhbuild" is a synonym for "everyone", then you surely
didn't open
On Mon, 2016-06-06 at 22:21 +0200, Sébastien Wilmet wrote:
> On Mon, Jun 06, 2016 at 10:10:58PM +0200, Sébastien Wilmet wrote:
> >
> > There is a solution: bump the major version of Camel or EDS each time an
> > API or ABI break is unavoidable, making the new major version
> >
On Fri, 2016-06-03 at 08:28 -0500, Michael Catanzaro wrote:
> I expect module maintainers to be understanding when reverts happen.
> It's not the end of the world; you can land your change again as soon
> as you figure out why it was broken. We can all live with a few
> revert commits in our git
On Mon, 2016-06-06 at 09:49 -0500, Michael Catanzaro wrote:
> A revert is not supposed to be "punishment" in any way... rather,
> consider it as assistance to make sure GNOME stays buildable. :)
Hi,
maybe it's not supposed to be, but it is in my eyes. I try my best to
not break builds,
On Fri, 2016-06-17 at 17:11 +0900, Tristan Van Berkom wrote:
> I dont believe you have any such functionality in jhbuild.
>
> At best, you can specify the sha1 of the commit you want to build of
> a given module, this would not let you single out one commit,
> omitting it from history in
Hello,
while playing with developer documentation I noticed that the source
tarballs (eventually `make dist` result) contain also developer
documentation in generated form. These documentation html/ files are
not small, in case of the glib it makes around 10MB. The thing is that
when I
On Thu, 2016-06-23 at 09:55 +0100, Philip Withnall wrote:
> If I remember correctly, it’s so that the tarballs can be unpacked to
> give documentation on developer.gnome.org without having to build
> anything.
Hi,
I thought it would be to have the documentation available from any
system,
On Thu, 2016-06-16 at 14:16 +0900, Tristan Van Berkom wrote:
> o The integration branch of every module is continuously
> reconstructed based on that module's master branch.
Hi,
as the 'integration' branch targets only jhbuild, then it doesn't make
sense to add it at each git
On Mon, 2016-02-29 at 15:44 +0100, Frederic Crozat wrote:
> Once you have the url of the pull request, just add ".patch" to it
> and you'll get a properly formatted patch.
Hi,
yes, that's the trick I was told to do. My point was that there is
absolutely no sign in the Web UI of github to
On Mon, 2016-02-29 at 14:52 +, Emmanuele Bassi wrote:
> $ git pull github-mirror pull/${PR_ID}/head:pr-${PR_ID}
> $ git checkout pr-${PR_ID}
>
> From then on, you can push/merge/pull/rebase as usual.
Hi,
well, it's too much overhead for:
a) someone whom does not have a github
On Fri, 2016-02-26 at 23:30 +, Alberto Ruiz wrote:
> These contributions (there's about 200 pull requests, see link below)
> would likely not have happened if we didn't have a presence in
> Github. Shutting down the mirror would simply stop that energy.
Hi,
I think it would be good to
On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
> In summary, I am not opposed to applying your proposal as is to the
> stable builds, there is no justification *ever* for breakage in stable
> branches.
>
> For master, I only think this needs to be detailed properly, perhaps it
>
On Thu, 2016-02-18 at 07:35 -0500, Matthias Clasen wrote:
> 751588 evolution Port to WebKit2
Hi,
I would change the GNOME Target to 3.22, but I'm not able to do it, the
value is not a Drop Down, but a static text for me. The thing is that
the port to WebKit2 won't happen in time
On Fri, 2016-08-19 at 10:47 -0500, Michael Catanzaro wrote:
> Please note that this kills Bijiben, we'll need to tell distros to
> remove it unless bug #728293 gets fixed very soon.
Hi,
eventually the bijiben can be patched to not link against
libedataserverui, until the proper fix (port
On Wed, 2016-10-05 at 07:54 -0500, Michael Catanzaro wrote:
> This is fine from a release team perspective, as we're already set up
> to handle CMake modules. Just make sure to update the JHbuild
> moduselets and Continuous manifest at the same time you make the
> change. There are already
On Wed, 2016-10-05 at 13:39 +0200, Bastien Nocera wrote:
> Why? Is it faster, smaller, or better in other ways?
Hi,
seems to be better than autotools, gives more freedom and easily allows
the sources to be built much faster than with autotools (it builds here
in ~1/3 of the time which
Hi,
On Wed, 2016-10-05 at 19:13 +0530, Nirbheek Chauhan wrote:
> Meson supports Ninja, MSVC 2010, MSVC 2015, and XCode. Support for
> make was omitted on purpose.
Ah, nice, I misread the list of available backends. My fault. I'm sorry
for that.
Bye,
Milan
On Wed, 2016-10-05 at 17:29 +0100, Javier Jardón wrote:
> Sure, just ping me (jjardon) or any of the release team members
>
Hi,
thanks a lot, I'll do that once the changes will be merged in the git
master.
Bye,
Milan
___
On Wed, 2016-09-21 at 11:27 -0500, Michael Catanzaro wrote:
> For some reason, Fedora doesn't seem to have a libasan-devel package,
> so there's no plain libasan.so. Really strange. I tried changing it
> to libasan.so.3 in my jhbuildrc but actually couldn't figure out how
> to do that; jhbuild is
On Mon, 2016-10-31 at 18:05 +0100, Milan Crha wrote:
> I plan to merge the evolution-data-server changes on Tuesday,
> November 8th (the next week), and as soon as possible also the
> changes in evolution, evolution-ews, evolution-mapi, evolution-rss
> and evolution-activesync, th
On Thu, 2016-10-27 at 18:10 +0100, Sam Thursfield wrote:
> On Thu, Oct 27, 2016 at 3:23 PM, 藍挺瑋 <lant...@gmail.com> wrote:
> > 於 週三，2016-10-05 於 09:33 +0200，Milan Crha 提到：
> > Can we have a common way to enable GTK-Doc installation in modules
> > using CMake? In modul
Hi all,
this is yet another announcement of prepared changes for
the Evolution-Data-Server, this time about Camel and its changes to
make more objects GObject based, for better/easier introspection of the
Camel library. I mentioned this almost four months ago [1]. This had
been initiated
On Mon, 2016-10-31 at 20:43 +, Zisu Andrei wrote:
> I had some patches for the SPECIAL-USE flags, but I haven't had time
> to deal with them over summer, should I also try to get those merged
> before the window closed?
Hi,
I suppose you mean
On Mon, 2016-10-10 at 10:49 +0200, Sebastian Geiger (Lanoxx) wrote:
> On 05/10/16 15:39, Michael Biebl wrote:
> > So while I'm not tied to autotools, I would hate to see if every
> > modules maintainer chooses his/her own build system of choice. This
> > makes it really cumbersome as
On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote:
> I plan to merge the changes the next Monday, October 10th, some time
> after the 3.22.1 release. This way there will be enough time to catch
> any issues before the 3.23.1 release.
Hi,
this is a notice that the changes
On Wed, 2016-12-14 at 10:11 -0500, Shaun McCance wrote:
> The GNOME Foundation board has a password-protected area of the wiki
> that only board members and employees have access to. That's eight
> people, nine after we finally hire an ED. Would that be a good place
> to keep a backup?
Hello,
in the light of
https://wiki.gnome.org/Initiatives/OnlineServicesAPIKeys
which is still missing the Google keys used by the evolution-data-
server (it's my fault).
I'm wondering how to avoid The Bus Factor for the keys. It doesn't
matter how many individuals would have access to
On Wed, 2017-06-28 at 10:15 +0200, Carlos Soriano wrote:
> > a) I often move bugs between products, aka user files it for product A,
> >but the issue (and actual commit) is in product B, thus it's moved,
> >by ~3 clicks
>
> How is this missing In GitLab?
Hi,
I do not use GitLab,
On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> That said, here's a potential pain point
Hi,
please, do not forget of Bugzilla integration with backtraces. It can
colorize them, it can show possible duplicates with score when the
backtrace is opened in its own window, and it can
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> The outcome of this evaluation process is that we are recommending
> that GNOME sets up its own GitLab instance, as a replacement for
> Bugzilla and cgit.
Hi,
with respect of the cgit, it lets me download sources (snapshot) as
a .zip
On Thu, 2017-05-18 at 15:12 -0500, mcatanz...@gnome.org wrote:
> I think we should remove this extension immediately.
Hi,
that sounds quite radical, does it not?
Removing everything what has bugs, instead of fixing them, what would
you ship to your users?
> It provides limited value,
On Tue, 2017-05-23 at 09:55 +0100, Javier Jardón wrote:
> I've been thinking on doing this for a while, so here you go:
>
> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
Hi,
do not count with evolution* for now, please. I'm not willing to change
their build system again,
On Fri, 2017-12-08 at 16:50 +, philip.chime...@gmail.com wrote:
> Coming from GitHub, Bugzilla was like regressing to the stone age. If
> I were to insist that my opinion take precedence in the same way that
> has happened multiple times on this thread, I'd demand that all
> activity on
On Thu, 2017-12-07 at 17:50 +, Emmanuele Bassi wrote:
> I seriously doubt you were born with innate knowledge of Bugzilla -
Hi,
it sounds like you consider an intuitive interface something obscure.
Well, it's intuitive at least for me.
> even though Bugzilla's feature set is
On Wed, 2017-12-06 at 19:31 +0100, Carlos Soriano wrote:
> To explain it better, my discussions with them are for high impact
> changes. My bandwidth is fully in there.
Hi,
that's understood and a reason why I made it "nice to have" and nothing
more.
I filled
On Thu, 2017-12-07 at 10:03 +0100, Milan Crha wrote:
> I filled https://gitlab.com/gitlab-org/gitlab-ce/issues/40903 there.
Hi again,
and also https://gitlab.com/gitlab-org/gitlab-ce/issues/40904
I do not see how to add labels to the issue, and the test instance
doesn't do anyth
On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote:
> I have good news, after few meetings and discussions with GitLab we
> reached an agreement on a way to bring the features we need and to
> fix our most important blockers in a reasonable time and in a way
> that are synced with us.
On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote:
> I have good news, after few meetings and discussions with GitLab we
> reached an agreement on a way to bring the features we need and to
> fix our most important blockers in a reasonable time and in a way
> that are synced with us.
Hello,
this is a little heads-up that evolution-data-server 3.29.3 release
will contain a D-Bus service version change, specifically
org.gnome.evolution.dataserver.Sources5
changes to
org.gnome.evolution.dataserver.Sources6
This had been done due to adding a new method to the
On Fri, 2018-06-08 at 09:42 +0100, David Woodhouse wrote:
> I don't *assert* that it was unnecessary... but I kind of *hope* it
> was unnecessary...
Hi,
you are right, it was unnecessary. I gave it a try (I really shouldn't
be that lazy) and the GDBus proxy doesn't panic when some method
Hello,
this might be a lame question, but this time I tried to read the
documentation first. I hope I didn't miss anything related to my
question. If I did, then I apologize.
When one wants to propose a change, aka create a merge request, in
GNOME GitLab instance, then it can be done only
On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote:
> Work is in progress to let maintainers upload tarballs with the
> generate API reference for developer.gnome.org
Hi,
okay, how is that supposed to work in general? As Meson builds out of
the source tree, is that "work in
On Tue, 2018-02-13 at 09:33 +, Philip Withnall wrote:
> porting the build systems of those modules to Meson is another
> legitimate way to port away from gnome-common. It would be the better
> choice in the long run for modules we are going to be maintaining for
> a while.
Hi,
I do
On Thu, 2018-02-08 at 13:57 -0600, mcatanz...@gnome.org wrote:
> Due to this delay, we will skip the 3.27.91 release altogether, so
> the next tarball deadline will be 3.27.92, on March 5. Perhaps by
> then we will be able to recommend using BuildStream for tarball
> generation.
Hi,
is it
On Tue, 2018-04-03 at 09:06 +0100, David Woodhouse wrote:
>
> On Tue, 2018-04-03 at 07:30 +0100, André Rodier via desktop-devel-
> list wrote:
> > I am setting up DNS records for email services automatic discovery
> > (RFC 6186) but it seems that evolution is ignoring them.
Hi,
which
Hi,
I'm starting a new thread here, just for an opinion on this:
On Tue, 2018-04-17 at 16:31 -0500, mcatanzaro wrote:
> The list of updated modules and changes is available here:
>
> https://download.gnome.org/core/3.29/3.29.1/NEWS
I opened above URL and there's "(*) No summarized news
On Wed, 2018-04-18 at 11:31 +0200, Kalev Lember wrote:
> Something that module maintainers can do here as a fix would be to
> cherry pick any 3.28.x NEWS entries to the master branch before
> releasing first 3.29.x release.
Hi,
except it's wrong, because then a) the NEWS file doesn't
Hi,
On Mon, 2018-03-19 at 16:49 -0500, mcatanz...@gnome.org wrote:
> Sometimes it's easy for a developer to forget what a new user sees
> when opening an app for the first time.
I agree, the first impression is important.
> Some of our apps (*cough* email clients *cough*)
I hope you
On Wed, 2018-03-21 at 11:22 +0100, Arnaud Bonatti wrote:
> Do you now understand more why I want to rename?
Hi,
yes, sure, thanks for explaining it. The reason to rename it, because
it doesn't work for DConf only, makes perfect sense. The other names do
not look good to me, but I'm not a
On Wed, 2018-03-21 at 07:56 +0100, Arnaud Bonatti wrote:
> the future name of ‘dconf-editor’ needs discussions (‘Registry’ and
> ‘Tinkerings’ are the best I came with
Hi,
may I ask why? What is the reasoning about changing the name of the
dconf-editor? You want to rename a reversi game to
On Wed, 2018-03-21 at 09:18 -0300, Germán Poo-Caamaño wrote:
> FWIW, he can type Epiphany, and filter it, right?. It is faster.
Hi,
yes, he can and I do it too, but he didn't and doesn't for some reason.
The set of things which can be done and which are actually used (and
which are
On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote:
> If you are a maintainer and you consider some issue in the migration
> process or GitLab itself a big problem for your project...
Hi,
while I begun my concerns dealing directly with Carlos I've been told I
should move it to
On Fri, 2018-03-23 at 08:17 +, philip.chime...@gmail.com wrote:
> You can test this for yourself on gitlab-test.gnome.org.
Hi,
I have only one login there, I cannot impersonate anyone, and I didn't
feel like I could try it with other issues, but I did now.
> No subscribers are
On Fri, 2018-03-23 at 11:04 +0100, Mattias Bengtsson wrote:
> > https://gitlab-test.gnome.org/mcrha/test/issues/4
>
> It's markdown formatted like most of GitLab. So just ask your users
> to wrap
> their backtraces in code blocks, like this:
>
> ```
> Your Backtrace
> ```
Hi,
I know
Hi,
On Wed, 2018-02-28 at 13:21 +0100, Carlos Soriano wrote:
> There is no subset of people in GNOME's GitLab issue tracker, you all
> can comment there, that's why it's public :)
Hmm, applying the same logic you can open a GNOME's gitlab issue for
"tips of the week" and update it,
On Fri, 2018-02-23 at 21:40 +0100, Carlos Soriano wrote:
> If you have some issue or feature request that might impact GNOME as
> a whole and you think it's important for GNOME create an issue in our
> infra project and we can discuss if we should add it as priority for
> GNOME.
Hi,
I'm
On Wed, 2018-02-28 at 15:39 +0100, Carlos Soriano wrote:
> Hope this was useful and clarified any doubt you might have, it
> certainly took some time to write.
Hi,
thanks for the explanation. It was definitely useful for me. I agree
it's not simple to evaluate the priority. The "once per
On Fri, 2018-06-29 at 16:39 +0100, Allan Day wrote:
> Those of us on the design side are interested to hear what people
> think of this, particularly if there are any apps out there that
> might have issues following the guidelines.
Hi,
this seems to be aimed to applications which use
On Mon, 2018-10-01 at 17:15 +0100, Abderrahim Kitouni wrote:
> If you find any problem, please file an issue at
> https://gitlab.gnome.org/GNOME/gnome-build-meta/issues
Hi,
is there any list of intentional changes from 3.28 runtime, please?
I'm not talking about updated libraries (like
On Wed, 2018-10-10 at 08:34 +0200, Alberto Fanjul Alonso wrote:
> On gitg we are considering to adopt GNOME Commits as project name.
Hi,
I'm used to gitk (which uses Qt, if I'm not mistaken). The gitg always
meant to me a gtk+ variant "of the same". I never looked for the real
reasoning
Hi,
On Mon, 2018-12-03 at 23:33 +, Javier Jardón wrote:
> (and gettext has been improved to implement functionality only
> intltool provided before)
right, I plan to re-evaluate and see how much they improved, though it
might be some time next year, probably.
Bye,
On Mon, 2018-12-03 at 18:15 +, Javier Jardón wrote:
> As you probably know, for some years we have been trying to move to
> upstream gettext [1]
Hi,
I know intltool has some issues, the projects I work on faced some of
them, but it also provides very useful tools and makes life easier
On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote:
> 3. I’d like to see continued movement towards disallowing direct
> pushes to git, and requiring all commits to go through MRs (and CI).
Hi,
I hope this won't go through without a good research and reasoning.
Any such requirement
On Sat, 2019-04-06 at 17:54 -0700, Javier Jardón wrote:
> - evolution-data-server
> https://gitlab.gnome.org/GNOME/evolution-data-server/issues/77
Hi,
the same applies for evolution, evolution-ews and evolution-mapi.
The above issue is closed, because there is a lack of manpower (and
On Fri, 2019-02-15 at 20:19 +, Emmanuele Bassi via desktop-devel-
list wrote:
> the switch to Meson for various libraries broke the expectations of
> library-web
Hi,
not only Meson, but also CMake (and eventually anything what doesn't
include developer documentation in the release
On Wed, 2019-01-23 at 11:54 -0600, mcatanz...@gnome.org wrote:
> Thing is, we don't have any email apps in core. It just doesn't make
> sense to have email settings in gnome-online-accounts when none of
> the core apps (the apps installed by default) actually use those
> settings. It's just going
On Mon, 2019-02-04 at 14:36 +, Alberto Ruiz wrote:
> Maybe opening an issue in GitLab that points to the original PR so
> that the maintainer can persuade the original PR author? Is this
> something maintainers would find acceptable?
Hi,
apart of duplicated space and work, that won't
Hello,
this is kind of heads-up e-mail about upcoming API changes in
evolution-data-server. I also do not like them, but they are sometimes
necessary.
The first part is about porting the calendar to use libical-glib [1],
instead of libical, in order to finally provide introspection for
On Fri, 2019-04-12 at 14:48 +0200, Bastien Nocera wrote:
> I'm guessing you looked at tarballs rather than git modules.
Hi,
yeah, sort of, I used Fedora repoquery to check for dependencies.
> "phonemgr", the module name for gnome-phone-manager is archived and
> hasn't seen a release for
On Fri, 2019-04-12 at 08:47 +0200, Milan Crha via desktop-devel-list
wrote:
> I found these hosted on GNOME:
Hi,
I've a little update on the dependencies and the porting preparation
progress. Those prepared are:
almanah
https://gitlab.gnome.org/GNOME/almanah/merge_request
On Thu, 2019-05-16 at 18:59 +0200, Milan Crha via desktop-devel-list
wrote:
> All the project references can be found here:
> https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33
>
> I'll send another email when the main parts (and those I received a
> green for
On Wed, 2019-06-05 at 23:14 +0500, Alexander via desktop-devel-list
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.
Hi,
from one of the mail application point of view
On Sat, 2019-05-25 at 23:04 +0100, Abderrahim Kitouni wrote:
> I had to disable gnome-contacts, gnome-calendar and gnome-maps
> because of the not-very-well coordinated evolution-data-server
> transition.
Hi,
if I read the dependencies correctly, then gnome-contacts and
gnome-maps depend
On Thu, 2019-04-18 at 13:52 -0500, mcatanz...@gnome.org wrote:
> Please commit all the changes to folks, gnome-calendar, and gnome-
> shell at the same time as evolution-data-server to avoid breaking
> gnome-build-meta.
Hello,
I'd like to let know that with the just released libical
1 - 100 of 121 matches
Mail list logo
