On Mon, 2022-09-19 at 08:21 +0200, Milan Crha via desktop-devel-list
wrote:
> Maybe.
Hi,
just to close this thread with a conclusion: there had been multiple
opinions (I received some also as private responses), and because I do
not have any strong reason for the change and the m
On Thu, 2022-09-29 at 16:48 +0100, Neil McGovern wrote:
> For those which should close, they've had very low activity (in some
> cases, zero...).
Hi,
I think you can safely close also the evolution-hackers list. It used
to be used to announce or ask development/developer related
questions/
On Fri, 2022-09-16 at 08:41 -0500, Michael Catanzaro wrote:
> I'm glad you're phasing it out, but doing something
> different from the rest of GNOME is inherently confusing.
Hi,
I think any change is always confusing at the start. My idea behind
x.y.0.90 is that the tweak number being so
Hello,
I'm thinking of changing version scheme for the evolution-data-server,
evolution, evolution-ews and evolution-mapi. It still uses the "old"
GNOME version scheme, meaning odd minor version (aka 3.45.x) being a
development series, even minor version (aka 3.46.x) being a stable
series.
On Wed, 2022-06-22 at 21:36 +0200, Marcus Lundblad wrote:
> Maps still depends on libsoup 2 (we get this dependency via
> libchamplain, and it is unlikly to get ported…)
Hi,
Evolution also (optionally) depended on libchamplain and I disabled it
due to this libsoup2 dependency. I know it's
Hello,
just a quick heads-up, the evolution-data-server development version is
libsoup3 now; it will be the 3.45.1 release. The port depends on
libsoup3 change [1], which improves libsoup3 use in multi-threaded
applications.
Most people are probably aware, all apps using the evolution-data
On Thu, 2021-11-04 at 09:06 -0500, Michael Catanzaro wrote:
> The list of updated modules and changes is available here:
>
> https://download.gnome.org/core/40/40.5/NEWS
Hi,
the NEWS file says the gnome-autoar had been downgraded, while there
had been a new release almost a week ago. Is t
On Fri, 2021-02-05 at 11:01 +0100, Kristi Progri wrote:
> I will check the poll for the final results by Sunday (7th)
Hi,
only checking, do you really mean to give people only ~two days to fill
it, or even to notice your mail here? It feels like a short notice,
from my point of view.
On Mon, 2020-09-28 at 10:26 +0200, Sam Thursfield via desktop-devel-
list wrote:
> It sounds like a good idea to automatically subscribe users to this
> tag on discourse.gnome.org.
Hi,
this kind of behavior can be seen as a spam attempt, especially when
it's done silently, behind people's
On Fri, 2020-09-25 at 14:33 -0500, Michael Catanzaro wrote:
> and make contributing to GNOME more attractive to newcomers.
Hi,
do you think the newcomers do not know how the mail works? Or it's used
as an excuse to replace something working for years with something new,
with new bugs, its
Hi,
On Thu, 2020-05-28 at 19:46 +0100, Zander Brown wrote:
> I think it's clear it was supposed to be humorous
Right, right, I didn't mean to offend anyone. If I did, I apologize for
that.
I guess Fridays are also not the best days for maintenance, unless
admins are ready to deal with i
On Thu, 2020-05-28 at 17:13 +0200, Bartłomiej Piotrowski wrote:
> We're sorry for this inconvenience and at your disposal in case of
> your questions.
Hi,
this is the second time you plan something bigger, some server
maintenance, at the days when the releases are supposed to happen.
Is t
On Thu, 2020-03-26 at 08:37 -0500, Michael Catanzaro wrote:
> Tarballs are always due on Saturday. We don't have Monday deadlines
> anymore.
Hi,
yes, I know. That's the reason why I moved to Friday releases.
> there should still be plenty of time to do so afterwards on Friday
> or Saturd
On Thu, 2020-03-26 at 09:14 +0100, Bartłomiej Piotrowski wrote:
> gitlab.gnome.org will be down during migration to the new data center
> starting today at 23 CET. Unfortunately due to the amount of data it is
> not feasible to migrate without downtime. As transferring the data will
> take about 6
On Thu, 2020-03-19 at 10:00 -0500, Michael Catanzaro wrote:
> It's a lost battle. The flathub infrastructure is clearly broken and
> has been for a very long time. It's reasonable to refuse to debug
> flatpak problems until this is fixed.
Hi,
yeah, that's okay. I worked around that by bu
Hello,
I'm trying to debug a crash in libsecret when using 3.36 runtime on
Fedora 32 Beta in Flatpak, with an application from flathub.org (that
application being org.gnome.Evolution). My idea was to download the
.Debug parts, to see where exactly it crashes. It was no problem for
Evolution
On Wed, 2019-10-02 at 11:58 +0200, Frederic Peters wrote:
> gnome-doc-list@ would be the right place, especially as there are
> plans to redo help.gnome.org. (ditto for developer.gnome.org).
Hi,
done, thanks.
https://mail.gnome.org/archives/gnome-doc-list/2019-October/msg0.html
> fwiw
Hi here,
I'm not sure whether this is the right list for this, thus I'm sorry if
it's not. Feel free to redirect me to the right place.
I'd like to ask: how do I manually update content of
https://help.gnome.org/users/$PROJECT , please?
As (I guess) the [1] is no near to be fixed/impleme
On Wed, 2019-09-11 at 14:09 +0200, Andre Klapper wrote:
> * Stable maintenance releases over a longer period
Hi,
does it make sense to have 3.34.5 at the time of 3.36.1? I guess not
for majority of the projects. Even if it would be a soft requirement,
it happens that the stable branch does
On Wed, 2019-08-14 at 13:04 -0500, mcatanz...@gnome.org wrote:
> 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.
Hi,
my personal preference is on Monday, thinki
On Thu, 2019-08-01 at 10:13 -0300, Isaque Galdino via desktop-devel-
list wrote:
> Notes is failing due to EDS. Once EDS changes to gettext, Notes
> should be fine.
Hi,
from what the Goal page references:
https://gitlab.gnome.org/GNOME/evolution-data-server/issues/77
Long story short: Thi
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 (bein
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 o
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
> gree
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 3.0.5
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_re
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 6
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 it.
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
knowl
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 tarb
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 w
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 Wed, 2019-01-23 at 15:21 -0500, Jeremy Bicha wrote:
> I'm just not sure that Evolution is designed to handle adding a
> replacement account when the GOA provider is ripped away when users
> upgrade.
Hi,
users can configure accounts directly in Evolution, and to get close to
GOA, or mayb
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
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,
Mila
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 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 th
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 be
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 head
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 i
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 interfa
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 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 descr
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 a
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 vers
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 it's
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 auto-ad
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 public,
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 obvious
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 d
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
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 get
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 t
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, instea
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 wo
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 progress"
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 not
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 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 basically
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 Bugzill
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 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 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 https://gitlab.com/gitlab-org
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-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, t
On Tue, 2017-06-27 at 10:54 +0200, Carlos Soriano wrote:
> We’ve been collecting the feedback on this wiki page:
> https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/CommunityInput
Hi,
can I add some things I'm missing there? It seems that it's better if
you manage the Wiki page
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, that
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, sin
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 an
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 Sat, 2017-02-11 at 18:35 +0100, Sébastien Wilmet wrote:
> For big projects like GTK+, building the docs takes several hours on
> my machine, and there are anyway too many warnings, with huge
> 'unused' files…
Hi,
just out of interest, do you run gtk-doc with address sanitizer
(libasan)
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?
Hi,
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 the
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 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
https://bugzilla.gnome.org/show_bug.cgi?id=
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 by
On Thu, 2016-10-27 at 18:10 +0100, Sam Thursfield wrote:
> On Thu, Oct 27, 2016 at 3:23 PM, 藍挺瑋 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 modules using Autotools, we
On Mon, 2016-10-10 at 11:51 -0400, Owen Taylor wrote:
> Javier has tagged evolution and evolution-data-server to pre-cmake
> versions in gnome-continuous.
Hi,
I know, I coordinate the change with Javier online. He already gave me
two links as examples, I gave him a stub which can be used i
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 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 downstream/int
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
___
desktop-d
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 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 examples
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 uses
Hello,
this is a heads up that the evolution-data-server, evolution,
evolution-ews and evolution-mapi products will switch from Autotools to
CMake for the 3.23.1 release. Each of them has created a wip/cmake
branch, which builds and even runs. I tried to keep things as close as
they were wi
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 p
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 o
Hello all,
this is just a little heads-up that the evolution-data-server's
libedataserverui sub-library and the evolution itself will depend on
WebKit2 since the upcoming 3.21.90 release, unless anything really bad
would rise till the release Monday.
Big kudos to Tomas Popela, whom led thi
On Thu, 2016-06-23 at 11:30 -0400, Alexandre Rostovtsev wrote:
> Gentoo uses the html/ contents if they are available, because (1)
> regenerating docs using gtk-doc is often very slow, and (2) it brings
> in more build-time dependencies that annoy some of our users.
Hi,
thanks for the info
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, f
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 conf
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 integrati
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 module,
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
> > parallel-installable
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, I'm
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 hi
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 acco
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 d
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
1 - 100 of 129 matches
Mail list logo
