[bringing this thread back again]
On Mon, Dec 5, 2016, at 09:09 AM, Andrea Veri wrote:
> Hey,
>
> added nevimer on the excludes list, your permissions to that
> repository have been granted.
Hey so...I know this is a crummy situation, but let's keep this
conversation open. I'm trying to underst
On Wed, Jan 18, 2017, at 05:42 PM, Colin Walters wrote:
> > Maybe `make dist` could perform a `cargo vendor`, and we could make this
> > the standard practice?
I did this:
https://github.com/ostreedev/ostree/pull/669
(Previously: https://github.com/ostreedev/ost
On Thu, Jan 5, 2017, at 10:26 PM, Hubert Figuière wrote:
> Reading this:
>
> https://czanik.blogs.balabit.com/2016/07/how-to-package-rust-applications-to-rpm-using-vendoring/
That's a very useful post.
> (It is from July and the tools have evolved).
>
> Maybe `make dist` could perform a `cargo
Hi,
Currently GContinuous' smoketest-classic test often fails with:
http://build.gnome.org/continuous/buildmaster/builds/2016/05/10/42/smoketest-classic/work-gnome-continuous-x86_64-runtime/journal.txt
```
nautilus-classic.desktop: ** (nautilus-desktop:1030): WARNING **: Desktop icons
only suppo
On Mon, Jul 20, 2015, at 10:40 PM, Owen Taylor wrote:
> And some of the things that were done to make gnome
> -continuous robust - like assembling a build root from scratch for each
> build and building each module from scratch - make it much slower and
> more resource intensive for local hacking
On Tue, May 5, 2015, at 12:51 PM, Andrea Veri wrote:
> Hey,
>
> more than half a year has passed since the GNOME Github mirror was
> setup and we are incredibly happy that it has contributed positively
> to bring more contributors to the GNOME Project.
I'm actually confused as to how the mirror h
On Wed, Feb 11, 2015, at 02:33 PM, Jim Nelson wrote:
> One of Philip's earlier suggestions was to print a console warning if
> a sync call is used. That seems like overkill to me, but it does lead
> to another possibility.
>
> Technically the issue is long synchronous calls blocking the event
> lo
On Fri, Feb 13, 2015, at 02:51 AM, Dimstar / Dominique Leuenberger wrote:
> let GSystem = imports.gi.GSystem;
> GSystem.log_structured_print('GNOME Shell started at ' +
> _startDate,
> ['MESSAGE_ID=' +
> GNOMESHELL_STARTED_MESSAGE_ID
On Fri, Feb 13, 2015, at 02:51 AM, Dimstar / Dominique Leuenberger wrote:
>
> Would the plan be for gnome-shell to also move to libgsystem2 then (Not
> that it makes a lot of use; that could likely be changed easily).
>
> let GSystem = imports.gi.GSystem;
> GSystem.log_str
I've updated this page:
https://wiki.gnome.org/Projects/LibGSystem
libgsystem has already become Linux specific (reading symlink xattrs from
/proc), and I'd like to make it even more so (some container APIs).
gnome-desktop used to depend on it, but with this bug:
https://bugzilla.gnome.org/sh
A heads up to all Vala codebases, please check your code for:
https://bugzilla.gnome.org/show_bug.cgi?id=655343
For now, I have tagged vala in Continuous.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/lis
We have a new dedicated list for the GNOME Continuous project:
https://mail.gnome.org/mailman/listinfo/gnome-continuous-list
Background on Continuous:
https://wiki.gnome.org/Projects/GnomeContinuous
I believe GNOME Continuous is still presently the fastest of its
scale[1] public automated conti
On Fri, Aug 1, 2014, at 07:18 PM, Sébastien Wilmet wrote:
> Maybe GNOME Continuous could run 'make distcheck' on (almost) every
> commit? To detect such errors earlier than the release day.
No. I think tarballs are a waste of CPU power and human time generated
solely because many popular downstr
Hi, a notice for Continuous users:
https://git.gnome.org/browse/ostree/commit/?id=f60bac45fdf9e9b1b8f663f859ffdee190f2fd0c
regressed ostree in Continuous; you will see "Unacceptable TLS
certiifcate" when doing
"ostree admin upgrade".
This is the fix:
https://git.gnome.org/browse/ostree/commit/?id
http://build.gnome.org/continuous/buildmaster/builds/2014/06/12/45/build/log-geary.txt
Anyone with vala-fu able to take a look?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hi,
On Thu, May 1, 2014 at 11:51 PM, 藍挺瑋 wrote:
Build log:
http://jhbuild.csie.org:9080/20140502/libgsystem.html#configure
There is no libattr on FreeBSD. Can we make -DGSYSTEM_CONFIG_XATTRS
optional through a configure option?
I'd prefer if gnome-shell lost the dependency on it and copied
e compatibility with OS X
Colin Walters (9):
trivial: Post-release version bump
scanner: Don't barf on anonymous unions
scanner: Use PATH_MAX, not hardcoded 1024 for realpath()
tests: Switch two more uses to LOG_COMPILER to fix parallel-tests
Release 1.39.3
Rel
On Fri, Feb 28, 2014 at 3:49 PM, Debarshi Ray
wrote:
We can implement a hidden option to override the location that is used
for local content. We can then place our test data in this location
and test against it.
Right. There is a place for potentially destructive tests, we just
need to fi
On Fri, Feb 14, 2014 at 1:32 PM, Sriram Ramkrishna
wrote:
GNOME has a owncloud service. You can use that. (well, it might
require bieng part of the foundation, but I might re-visit that
decision)
It really doesn't work for GNOME to provide free services like document
storage to the entire
On Mon, Feb 10, 2014 at 3:07 PM, Colin Walters
wrote:
On Mon, Feb 10, 2014 at 11:21 AM, Martyn Russell
wrote:
After checking with the release team some weeks back that it is
prudent make this change for this cycle, I've updated Tracker to be
API version "1.0".
Nice!
On Mon, Feb 10, 2014 at 11:21 AM, Martyn Russell
wrote:
After checking with the release team some weeks back that it is
prudent make this change for this cycle, I've updated Tracker to be
API version "1.0".
Nice!
Just a heads up, some (probably minor) fallout:
https://bugzilla.gnome.org/
On Wed, Feb 5, 2014 at 11:24 AM, Jasper St. Pierre
wrote:
2), since it means that there's no motivation to get stuff into GLib
(think of all the churn that happened with GSubprocess).
GSubprocess is a *good* example I think because it did successfully end
up in GLib. And it was quite worth
On Wed, Feb 5, 2014 at 10:21 AM, Jasper St. Pierre
wrote:
What was the issue that happened in Fedora package review? Why
doesn't it apply to our copylibs right now, or e.g. libgd?
I think no one noticed libgd...review only happens on initial
submission, there's no real rigorous ongoing proc
On Wed, Feb 5, 2014 at 8:48 AM, Richard Hughes
wrote:
Yes, that sounds awesome, but if libgsystem is going to be an "egg"
replacement I would say it's better to just copy and paste the source
files into modules; having an external library indicates some kind of
API and ABI promises, and you don
On Wed, Feb 5, 2014 at 6:52 AM, Colin Walters
wrote:
... but libgsystem helps in the meantime by avoiding code duplication
in the meantime, and I will
...work on #ifdefs such that if libgsystem is built against a new GLib,
it transparently backends to that, rather than having duplicate
On Wed, Feb 5, 2014 at 5:43 AM, Richard Hughes
wrote:
One little point
tho, how come this can't be installed into GLib proper?
First, there's the aspect where libgsystem acts as a "staging ground"
where APIs can get real-world use before landing in GLib.
Two examples of this:
GSConsole
gsy
Hi,
My libgsystem ( https://wiki.gnome.org/Projects/LibGSystem ) library is
now copied into sufficient number of modules that I'm considering
making it a real shared library.
This came up in the context of Fedora package review, but I think it
also makes sense from a technical point of view.
On Sat, Feb 1, 2014 at 10:08 AM, Matthias Clasen
wrote:
- Make the doc comments more readable by moving from clunky docbook
markup
to markdown. This will help both for reading and updating the
documentation in
the sources, and for limiting the scope of whar our
documentation-generating
Hi Daniel,
On Fri, Jan 31, 2014 at 8:44 AM, Daniel Mustieles García
wrote:
Hi all,
I've commited all the remaining patches about this issue.
You broke the glib build at least; gio/data-to-c.pl lost its executable
bits? Were you making these patches from a Windows system or something?
Not
On Thu, 2014-01-02 at 15:22 +, Michael Ikey Doherty wrote:
> * We remount "/" read-only in a bind-mount
[and put application files in a private directory]
There's a lot to be discussed about application data storage. Right now
you have all sandboxed applications sharing a single store - ea
Hi,
I'd like to talk about applying
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
to application testing.
Now, the executive summary on InstalledTests is "improved make check
framework". Its focus is on rigorous automation.
At the moment in GNOME, many shared libraries like glib
On Thu, 2014-01-02 at 15:22 +, Michael Ikey Doherty wrote:
> The idea is to wrap the dbus interface, etc, in a "portal" library.
But I'd expect that the DBus API is the underlying ultimately stable
thing, and the portal library (where it need exist at all) is just a
convenience wrapper. Righ
On Thu, 2013-11-28 at 12:12 -0500, Colin Walters wrote:
> Hi,
>
> Just a heads up that I'd like to land
> https://bugzilla.gnome.org/show_bug.cgi?id=711046
This is now done, the changes are on gjs master, and jhbuild is updated
with the change:
https://git.gnome.org/browse/j
Hi,
Just a heads up that I'd like to land
https://bugzilla.gnome.org/show_bug.cgi?id=711046
Which is Tim's work on porting gjs to mozjs24, the next stable
standalone SpiderMonkey release. He's been using this branch on Ubuntu
for some time, and I just switched gjs in Continuous to target it:
ht
Hi,
https://bugzilla.gnome.org/show_bug.cgi?id=715086
https://bugzilla.gnome.org/show_bug.cgi?id=715087
Needs global coordination, and should have been discussed here. The
jhbuild moduleset for 3.12 is still on 0.16. So is the Continuous
manifest. I'm looking at switching to master now, but: a
Hi,
Since https://bugs.freedesktop.org/show_bug.cgi?id=68559 the session bus
will now cause launched services to be connected to the systemd journal
(on systemd-based systems). Before this, output went to /dev/null.
As you might imagine, over time various components spewed (basically
debugging)
Hi Andy,
On Mon, 2013-09-23 at 12:50 -0700, Andy Tai wrote:
> what would this mean for systems not using systemd?
It wasn't hard to keep compatibility with the old way while working on
the patches. Particularly since it requires not just a dependency on
systemd, but bleeding edge systemd, with a
On Fri, 2013-09-13 at 11:55 +0400, Nikita Churaev wrote:
> There are still problems like: can't specify if a property can be NULL
> (eg. a NULL string), can't specify if an out parameter can return NULL,
> no support for reference-counted structures, can't specify length
> parameter for string argu
Hi,
Just a quick note for the users of gnome-ostree: it is now known as
"gnome-continuous" (or GNOME-Continuous in /etc/os-release). The new
home page is:
https://wiki.gnome.org/GnomeContinuous
This is just a better name, and hopefully people will stop calling it
"ostree" because that's only a p
On Wed, 2013-08-21 at 12:25 +0100, Richard Hughes wrote:
> Hi all,
>
> I've written up a specification that I would like to get feedback on.
> It's had a few iterations now, and soon I'd like to propose a GNOME
> Goal on adding the required files to at least all the apps in our core
> moduleset.
Hi,
Any opinions on:
https://bugzilla.gnome.org/show_bug.cgi?id=706155
?
(I use gerrit for some work projects and am quite happy with it in
general; the interdiff support in particular is incredibly useful)
___
desktop-devel-list mailing list
desk
A bit of a scramble, but I've got the gnome-ostree builder now tracking
geoclue master again. I had to disable geolocation support in
webkitgtk, but that's not a big deal because it doesn't really work in
VMs anyways.
But do you know if there's a patch for webkitgtk?
On Sat, 2013-08-03 at 14:15
The use of git submodules in GNOME is growing - there's libgd,
egg-list-box, and my own libgsystem, among others. Broadly speaking, I
think that's a good thing. They offer a reasonable set of tradeoffs
compared to "copylibs" like the old libegg model.
However, git submodules are easy to screw up
So, two weeks later. A quick status update on prototyping this:
First, I converted gjs to have an "installed-tests" subdirectory:
https://git.gnome.org/browse/gjs/commit/?id=54538f3da91b25ed20c9deaeda00d57fb252227c
That worked, however I got some pushback:
https://bugzilla.gnome.org/show_bug.cgi
On Mon, 2013-04-29 at 08:07 +0100, Maciej Piechotka wrote:
> If the test are going to be installed by default it might be reasonable
> to have a common option (similar to gtk doc) to disable them (if they
> are not going to be enabled by default - option to enable them) in case
> user does not nee
On Sat, 2013-04-27 at 15:40 +0200, Martin Pitt wrote:
> (II) installed tests on installed system: regular verification of
> daily image builds, self-check of installed systems and ostree
> snapshots
But note that if we're talking about black box testing which is what
most of GNOME's tests are,
On Fri, 2013-04-26 at 22:56 +0200, Florian Müllner wrote:
> On Fri, Apr 26, 2013 at 9:44 PM, Colin Walters wrote:
> > Anyways...dropping tarballs is not going to happen soon, but I'm happy
> > to consider what we need to do to lay the foundations now.
>
> More short-te
On Fri, 2013-04-26 at 20:02 +0100, Maciej Piechotka wrote:
> At least on Gentoo there is partially existing infrastructure but it is
> not considered superior to tarballs. The collision attack on git is
> possible, especially when the build is automated[1] and presumably by
> not closely watching
On Fri, 2013-04-26 at 18:49 +0200, Emilio Pozuelo Monfort wrote:
> Hi,
>
> On 04/26/2013 05:01 PM, Colin Walters wrote:
> > On Fri, 2013-04-26 at 10:32 -0400, Dan Winship wrote:
> >> I want "make distcheck" to still run all of my tests, to guarantee that
> >
On Fri, 2013-04-26 at 14:44 +0100, Patrick Welche wrote:
> On Thu, Apr 25, 2013 at 10:21:47AM -0400, Colin Walters wrote:
> > https://live.gnome.org/GnomeGoals/InstalledTests
>
> I'm not entirely sure what sort of tests your framework is designed
> to contain...
Most of
On Fri, 2013-04-26 at 10:32 -0400, Dan Winship wrote:
> On 04/26/2013 10:12 AM, Colin Walters wrote:
> > On Fri, 2013-04-26 at 08:46 -0400, Matthias Clasen wrote:
> >
> >> You are not going to get me to buy eagerly into a new installed tests
> >> scheme for glib i
On Fri, 2013-04-26 at 15:47 +0100, Simon McVittie wrote:
> I don't see any reason why this couldn't be equally true for "make
> check":
Because make check requires rebuilding the module just to run the tests.
I'm running the gjs test suite at the moment on the complete resulting
installed tree (
On Fri, 2013-04-26 at 08:46 -0400, Matthias Clasen wrote:
> You are not going to get me to buy eagerly into a new installed tests
> scheme for glib if it means that I have to give up make check.
Well, would you be OK with:
$ jhbuild make
$ gnome-desktop-testing-runner glib
?
Note though that
On Thu, 2013-04-25 at 16:41 +0100, Simon McVittie wrote:
> The currently-defined Restrictions in autopkgtest are rw-build-tree,
> breaks-testbed, needs-root and build-needed. The two build ones are not
> relevant for installed tests. GNOME could use needs-root, breaks-testbed
> (if it breaks the s
On Thu, 2013-04-25 at 16:30 +0200, Bastien Nocera wrote:
> What are the requirements in terms of what tests are allowed to do? I'm
> guessing they shouldn't touch the running environment,
That's a good question. The gnome-ostree testing infrastructure uses
qemu with a copy-on-write qcow2 disk s
See:
https://live.gnome.org/GnomeGoals/InstalledTests
I'm in the process of transitioning to that page from
https://docs.google.com/document/d/1DXgGEKTbC4ed1DFW3Mu-48TpHtq-xdfhDtwoUOWWcHg/edit
Comments appreciated; I have prototype branches of gnome-ostree,
gnome-desktop-testing, and gjs that i
On Wed, 2013-04-24 at 12:22 +0200, Florian Müllner wrote:
> First: If we are actually ready to roll out ostree images, that's
> awesome news!
Depends who the audience is...no security updates and you need to build
applications from source. But if you want to see GNOME as it is a few
minutes or l
On Tue, 2013-04-02 at 13:07 +0100, Emmanuele Bassi wrote:
> that is going to be massively difficult: we can barely test
> applications, you want to automatically test a compositor and the
> combinatorial explosion of 10+ extensions that may or may not conflict
> between themselves? I doubt you can
A quick heads up: gjs git master now depends on mozjs-17.0 (the new
Spidermonkey standalone release). jhbuild and gnome-ostree have been
updated.
For GNOME 3.8: gjs has a gnome-3-8 branch which still depends on moz185,
and if you're a distributor who wants to ship GNOME 3.8 with mozjs-17.0,
pleas
On Fri, 2013-03-22 at 07:24 -0400, Matthias Clasen wrote:
> 696169nor Nor Linugnome-shell UNCODespite
> moving mouse in
> Black Screen(Blank screen), gnome-shell doesn't switch to unlock
> screen.
This is one for which I'd say we should really consider delayin
On Mon, 2013-03-11 at 11:37 +, Simon McVittie wrote:
> DEP8 tests can work like this with sufficient support from the package's
> upstream developer (telepathy-gabble-tests 0.17.x from experimental
> works like this).
I looked this up from here:
http://packages.debian.org/experimental/telepa
On Fri, 2013-03-08 at 18:02 +, Simon McVittie wrote:
> On 08/03/13 14:45, Colin Walters wrote:
> > This gets back to something I want to figure out how to do, which is
> > standardize metadata for tests (e.g. "this test requires a public
> > Internet connection"
On Thu, 2013-03-07 at 16:48 +0100, Martin Pitt wrote:
> The thing that hurts most currently is that the machine is behind a
> proxy. This causes quite a lot of test failures (like libgdata's
> youtube test), as well as spurious build failures like [3]. We do plan
> to move this machine into the D
On Tue, 2013-02-26 at 15:29 -0500, Behdad Esfahbod wrote:
> I'm not questioning that. I think the right question would be: how
> many bugs
> got fixed in GLib because of the warnings being enabled by default
Initally? A lot, some quite bad. We were leaking internal symbols
for example.
But
On Tue, 2013-02-26 at 15:03 +0100, Dieter Verfaillie wrote:
> On 2013-02-26 14:20, Maciej Piechotka wrote:
> > I would be for not including -Werror inside configure.ac at all and
> > trust people with commit rights to enable it (either by explicit
> > option
> > or by CFLAGS variable).
>
> Agreed
Hi Behdad,
At a high level, please keep in mind that you're working with a
distributed group of people across the Internet who are actually trying
to make the world a better place (for some loosely-aligned definition of
"better").
Adding the warnings turned up a large variety of bugs in GLib, and
On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote:
> I know, it sounds like some CPU will be melting quickly
> at the rate gnome-wide commits are made... but it would be
> simply awesome, if we could automatically pull out the exact
> commit which introduced exactly which failed build re
On Wed, 2013-01-16 at 07:39 +0100, Martin Pitt wrote:
> Right now in our Juju charm it's a manual list:
>
>
> http://bazaar.launchpad.net/~jibel/charms/quantal/jhbuild/trunk/view/head:/files/jhbuild.config/gnome-core.sysdeps
>
> I'm not quite sure why; Jean-Baptiste, did jhbuild sysdeps not w
On Tue, 2013-01-15 at 11:07 +0100, Martin Pitt wrote:
> We have experimented with that a bit, by building
>
> https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
Interesting! Looks quite useful. Are you doing anything with
respect to the "jhbuild sysdeps --install" infrastructur
On Sun, 2012-12-30 at 19:43 +0100, Cosimo Cecchi wrote:
> Exactly, often a module was "red" because it needed a "git clean",
See https://bugzilla.gnome.org/show_bug.cgi?id=656081
I wrote that patch specifically for use in autobuilders. A lot of the
reliability of the gnome-ostree build system ve
On Wed, 2013-01-02 at 11:23 -0800, Travis Reitter wrote:
> I think our best bet for a usable SDK would be something that sets up a
> QEMU instance on top of OSTree
I have scripts for this
(
http://git.gnome.org/browse/gnome-ostree/tree/src/ostbuild/ostbuild-qemu-pull-deploy?id=d99b501bb0fbc5c866
On Sun, 2012-12-30 at 17:50 +0100, Andre Klapper wrote:
> http://build.gnome.org/ mentions 3.6 (past), the Fedora one seems to be
> offline, and the Debian one has not been updated since October.
There are a couple of things here - one thing I want to emphasize here
(I mentioned this too in the Bo
-based application and component authors should
be aware of. I expect overall it will be an improvement - code which previously
corrupted non-ASCII strings will no longer do so. But it's possible for
someone to have been relying on this (in hindsight) poor design choice.
Colin Walters (12):
On Mon, 2012-12-10 at 19:07 +, Debarshi Ray wrote:
> > TL;DR: It's 2012. The compiler understands UTF-8 and defaults to it.
> > Use it :)
>
> As I discovered recently, gjs does not like Unicode characters in string
> literals.
You are likely referring to:
https://bugzilla.gnome.org/show_bug.
On Mon, 2012-11-05 at 11:45 -0500, Colin Walters wrote:
> Probably the least bad thing to do is for jhbuild, just pass
> --with-python=python3 for pygobject, and --with-python=python2 for
> pygobject-py2. Then we test in jhbuild if /usr/bin/python is Python 2,
> *and* there's no
On Mon, 2012-11-05 at 17:33 +0100, Martin Pitt wrote:
> So for the fake pygobject-py2 jhbuild project we'd specify
> "--with-python=python2".
>
> Does that sound acceptable?
Makes sense, yeah. So you're suggesting this gets propagated into the
shebang lines too? If so...that does allow us to k
See also:
https://bugzilla.gnome.org/show_bug.cgi?id=658237
And the original train wreck:
https://bugzilla.gnome.org/show_bug.cgi?id=650763
If we don't have a concrete plan for how stuff like the shebang lines
work, the mess is just going to get worse. And ideally, we share
infrastructure (e.g
On Mon, 2012-11-05 at 10:28 +0100, Martin Pitt wrote:
> but if we now want to port GNOME to py3, I guess this should be
> rearranged.
>
> Should I just change the default to "python3", so that jhbuild will
> from now on build for py3 unless you explicitly configure for python2?
> That would go al
Users of gnome-common, please take a look at:
https://bugzilla.gnome.org/show_bug.cgi?id=608953
I checked everything in the current gnome-ostree 3.8 manifest builds,
but there is likely more out there. If you hit anything, please comment
on the bug and we can work out whether we should drop anyt
On Wed, 2012-10-24 at 09:36 -0400, William Jon McCann wrote:
> I agree with you that we need to have a motive to change and that
> costs should be weighed carefully. We can make the case.
Yes. You've done some of that here. As we discussed on IRC, stuff like
having GNOME tightly integrated with
On Tue, 2012-10-23 at 13:49 -0400, Adam Jackson wrote:
> In any
> case I'd like to get a better idea for which of these cases Gnome still
> cares, as that will help determine where we should be focusing on
> improving whichever window system we're running this week.
I'm not sure anyone in the
On Wed, 2012-10-24 at 10:11 +0200, Bastien Nocera wrote:
> And let's be clear, there's no maintainer for gnome-desktop.
I do look at incoming bugs and review patches, though since the module
is a bit of a grab bag, for things like randr I'll toss reviews of those
bits to Federico if he wasn't the
On Tue, 2012-10-23 at 07:26 +0200, Bastien Nocera wrote:
> I don't see how this helps. The code just lives somewhere that's still
> within view (gnome-desktop isn't some magic module where things get
> hidden),
But I'm also volunteering to help keep it compiling and at least the
systemd case tes
On Mon, 2012-10-22 at 17:38 -0400, Alexandre Rostovtsev wrote:
> 1. suspend / hibernate / poweroff / reboot
The challenge is that it's not just about an API call which ends up as
executing /usr/sbin/reboot or some other platform-specific mechanism.
It's about modeling state.
The canonical bug I
On Mon, 2012-10-22 at 14:04 +0200, Bastien Nocera wrote:
> My mistake, that's because the old (ifdef'ed) code used it. The D-Bus
> interface[1] provides the same functionality[2]. I'll take patches to
> make it use the D-Bus interface.
Right, ok rather than that, I can take over maintaining this
On Mon, 2012-10-22 at 08:07 +0200, Bastien Nocera wrote:
> Given that there are no library dependencies, it would always be
> run-time detection, as it was and as it will be. No change there.
In the current code, libsystemd-login is a hard compile-time dependency,
introduced by
http://git.gnome.
The other thing we can do (and really should do) is share more code
relating to systemd/CK and in general system abstractions.
It's really pretty silly how hard we make it to share code between
gnome-settings-daemon and gnome-shell. I'd be happy to move
more stuff into to gnome-desktop personally
On Fri, 2012-10-19 at 15:48 +0200, Bastien Nocera wrote:
> I would recommend that gnome-shell uses systemd to suspend, and I would
> recommend gnome-shell, gnome-session and gdm also drop their ConsoleKit
> session tracking code. At the end of the day, the decisions are not mine
> to make, so if t
On Sat, 2012-09-08 at 19:06 +0200, Lanoxx wrote:
>
> I tried to ask in #gtk+ why they are using the SILENT_RULES makro, but
> are not using the silent make flag, and someone tried to explain to me,
> that this also silences warnings, but as can be seen below, it does not.
> I also dont see a r
On Wed, 2012-09-05 at 15:13 -0400, Jasper St. Pierre wrote:
> On Wed, Sep 5, 2012 at 3:10 PM, Jeremy Bicha wrote:
> > On 5 September 2012 14:56, Colin Walters wrote:
> >> Hi,
> >>
> >> TL;DR: Run "git pull -r && make install" in your jhbuil
Hi,
TL;DR: Run "git pull -r && make install" in your jhbuild checkouts.
The latest "systemmodules" work has landed in jhbuild; in the default
configuration where modulesets are fetched via HTTP, the new ones will
fail to parse with the old code.
The upside though is that "jhbuild sysdeps --insta
On Wed, 2012-08-22 at 10:19 +0200, Luca Ferretti wrote:
> Hi,
>
> currently we are missing an update gnome-desktop release. Latest is
> 3.5.5 but gnome-control-center needs gnome-desktop >= 3.5.6.
>
> Could someone take care of it?
Yeah, sorry I made one but forgot to upload it =) Thanks Frédér
On Fri, 2012-08-10 at 09:38 +0200, Lanoxx wrote:
>
> On 09/08/12 23:13, Colin Walters wrote:
>
> > On Thu, 2012-08-09 at 23:04 +0200, Lanoxx wrote:
> >
> > > > Right, I splitted that up, while I was figuring out why I was getting a
> > >
On Thu, 2012-08-09 at 23:04 +0200, Lanoxx wrote:
> Right, I splitted that up, while I was figuring out why I was getting a
> link error.
Patches?? On the desktop *development* list? What's going on???
More seriously...your commit message should explain *why* you created
this patch. In this ca
Hi,
At GUADEC, it was announced that the Boston Summit 2012 is on! More
information is available here:
https://live.gnome.org/Boston2012
Please do fill in the attendance list so we can somewhat accurately
gauge required refreshment quantity, etc.
There's a lot of topics to discuss, and I hope
On Mon, 2012-08-06 at 15:05 +0800, Daniel Veillard wrote:
> So I looked at this more closely. It happens that evolution-data-server
> was using raw xmlOutputBuffer to serialize XML, and then accessing
> directly the fields inside one of the buffer of xmlOutputBuffer.
Just dropped a patch here:
Hi Daniel,
It looks like
http://git.gnome.org/browse/libxml2/commit/?id=65c7d3b2e6506283eecd19a23dcf0122fbcdac33
will require changes in evolution-data-server at least, and potentially
other GNOME modules. While jhbuild is presently stuck on a 2.8.0
tarball[1], my unofficial build system tracks
On Sat, 2012-07-28 at 16:16 +0100, David King wrote:
> On 2012-07-27 21:18, Philip Withnall wrote:
> >Furthermore, is there any reason why modules shouldn't be using
> >GNOME_COMPILE_WARNINGS? It would be great if we could standardise on
> >using it so that we can guarantee that the classes of bug
Hi Benjamin,
Thanks for responding! The reason I structured my original email as a
question/proposal because I was interested in (ideally constructive)
individual maintainer feedback.
On Sat, 2012-07-28 at 12:58 +, Benjamin Otte wrote:
> I think the general consensus is that code that trigg
On Fri, 2012-07-27 at 17:28 +0200, Frederic Peters wrote:
> Colin Walters wrote:
>
> > For compiler warning defaults, I think something similar what Dan
> > Winship has in libsoup is what we should replicate across more GNOME
> > modules:
> >
> > http
1 - 100 of 303 matches
Mail list logo
