Hi,
rygel needs valac 0.11.6 since it fixes a codegen bug which leads to a
crash in one of our plugins.
Note that this release deprecates the string.to_foo() methods thus will
break all projects building with --fatal-warnings.
___
desktop-devel-list
On Thu, 2011-02-17 at 00:02 +0200, Zeeshan Ali (Khattak) wrote:
On Wed, Feb 16, 2011 at 12:23 PM, Jens Georg m...@jensge.org wrote:
Hi,
rygel needs valac 0.11.6 since it fixes a codegen bug which leads to a
crash in one of our plugins.
IIRC, micro version could be bumped without
On Tue, 2011-03-29 at 19:53 +0200, Maciej Piechotka wrote:
It should be Available or Unavailable why you're unavailable could be a
secondary status.. but in general it should be those two statuses.
sri
Possibly also Invisible - implicit state when screen is locked.
Why would that be
On Thu, 2011-04-07 at 08:54 +0200, Olav Vitters wrote:
On Thu, Apr 07, 2011 at 07:39:30AM +0200, Maciej Piechotka wrote:
May I ask big the problem is? Splitting into subpages/hiding makes it
more difficult to find (I usually search using C-f as it is much faster
then determining in which it
Can we make synchronisation not suck?
Achieving good and non-breaking sync is really hard and sometimes next
to impossible, given that the formats used in PIM sync (vCard, I'm
looking at you) are really weird and broadly interpreted differently by
different devices out there (Like e.g. the
On Tue, 2011-04-19 at 13:21 +0200, daniel g. siegel wrote:
and right here i think we shouldn't base on bad formats (vcard) and
sucking protocols (syncml). using json is a much better option.
Well as soon as you talk about sync, someone says device. And devices
come with vCard.
see for example
Hi,
What I would like to propose is something in the lines of less open DLNA
sharing. This is a feature on top of Rygel.
It would be similar to the Play to feature of Windows 7, where you can
right-click on a file and send it to UPnP-capable media renderer.
(Thinking of a nautilus send-to plugin
On Mi, 2011-05-25 at 11:30 +0100, Bastien Nocera wrote:
Hi, sorry, was busy lately, took a bit to get back on this.
On Wed, 2011-05-25 at 07:55 +0200, Jens Georg wrote:
Hi,
What I would like to propose is something in the lines of less open DLNA
sharing. This is a feature on top
On So, 2011-11-06 at 17:06 +0100, Frederic Peters wrote:
Hello all,
It's about time to decide on the major features we'll track for 3.4.
Actually the release team already met yesterday and did a quick round
up of the proposed features, here's a summary (title/url) of them as
well a a quick
Hi,
Since the last gupnp-* unstable releases, gupnp-vala is more or less
obsolete since all of them generate the vala bindings themselves now
from gobject-introspection.
Looking at the modulesets, Rygel is the only project that depends on
gupnp-vala and I've already removed that dependency.
Is
On So, 2012-12-02 at 10:48 +, David King wrote:
I have used EasyTAG for many years to edits tags and rename files in my
music collection, and I was sad to see that the project had languished
somewhat on SourceForge. However, after some discussions with the
maintainer, Kip Warner, I
Is everyone ok with dropping gupnp-vala completely from 3.8 (and later)
-apps or did I overlook something?
And it's gone.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Fr, 2013-03-08 at 14:12 +0800, Ma Xiaojun wrote:
As title.
GUPnP is from time to time when I need symbol browsing. Rygel would, but
the autoconf-foo does too many things anjuta's auto* parser does not
support (rightfully, as it's kindof complex).
On Mi, 2013-08-21 at 00:15 +0200, Andrea Veri wrote:
Hi,
I noticed that many repositories are not using the name tag
correctly into the respective .doap files. The name tag should
possibly match the repository name (i.e gnome-shell.git --
gnome-shell, gnome-user-docs.git --
On Di, 2013-08-27 at 13:46 +0200, fr33domlo...@mailoo.org wrote:
And this is different from tracker in what regard?
Hello Gnome contributors,
Few months ago I came up with an idea, relevant to developers of any
application software. I mentioned it somewhere here on the lists, got
Hi,
https://wiki.gnome.org/GnomeGoals/HeaderBars
gedit ist marked to do but green so either the colour is wrong or the
to do :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
I'm a little concerned that we seem to be growing a qt dependency
here
That's the same optional! Qt dependency that tracker has grown since
the Harmattan days.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
I am unfamiliar with the innards of Grilo so, I can't say if it competes
or duplicates efforts there.
Not really. I'd say Grilo could use it for populating the media art
cache using its last.fm or tmbd plugins to make those available to other
consumers or use it in it's local metadata
There’s a bit of discussion going on at the DX hackfest about personal
branches of other people’s modules.
People here agree that it would be pretty good if we standardised on:
wip/$nick/$branch_name
as the name for your branches on someone else’s module. These could be
pushed to
gnome-photos depends on dleyna-renderer, which in jhbuild is
provided by pkgconfig(dleyna-renderer-service-1.0), but this .pc file
is deleted in the Fedora spec file since it's apparently only for use
of the dleyna daemon (which raises the question why it exists at all).
Yeah, that *.pc file
Hi,
having dug through the variants of (L)GPL license texts lately, I
noticed that we apparenly have put Rygel and GUPnP under a weird mixure
of LGPL v2 versions. The text and version comes from the "old" Library
GPL 2, but as a license name we use "Lesser GPL" in the headers but
Library GPL
Does anyone know whether I can just do a "soft" relicensing to
"proper"
LGPLv2.1+ by myself (the license says version 2 or later) to clean
this
up or whether I need to involve all contributing parties (oh dear)?
Yes, go right ahead: this is why the "or later" clause exists. If the
"or later"
> * automated builds of our software are possible without hacks
> * distchecking projects does not fail at the very last minute before
> release but during development
> * we bring the development environment and the continuous deployment
> environment closer
>
> What do maintainers think?
On So, 2016-02-28 at 15:43 +0100, Jens Georg wrote:
> > * automated builds of our software are possible without hacks
> > * distchecking projects does not fail at the very last minute
> > before
> > release but during development
> > * we bring the development
Hi,
>
> I've created a wiki page to list the unmaintained applications:
> https://wiki.gnome.org/Apps/Unmaintained
>
I would like to take over shotwell as I already spent some time in its
code (albeit not contributing) and kind of rely on it. I suppose
Jim/Adam do not have any objections?
As of recently GNOME Maps can no longer fetch tiles to display. This
is because MapQuest,
which we use as a tile provider, changed its usage policy[1].
And we are no longer able to use the service without paying. We have
as of know no clear alternative.
We _could_ switch to OpenStreetMap own
This landed in gnome-settings-daemon, vino, rygel and gnome-user-share.
I'll make release for that first and last modules. Hopefully the other
2 will see releases for the beta release this week, otherwise
distributions will have to patch that in for now.
Your initial patch to Rygel (incl.
* Generated by gdbus-codegen %s. DO NOT EDIT.
*
* The license of this code is the same as for the source it was
derived
from.
I'm looking for a clarification on the term "source" here. Is it the
XML D-Bus interface description?
I am not a significant copyright holder on gdbus-codegen, but I
Hi,
C and H files generated by gdbus-codegen carry the following header:
* Generated by gdbus-codegen %s. DO NOT EDIT.
*
* The license of this code is the same as for the source it was derived
from.
I'm looking for a clarification on the term "source" here. Is it the
XML D-Bus interface
Best solution is to just change the text in the generated file to be
more clear that the license for the generated source is the same as
that of the source code files fed into gdbus-codegen, rather than the
source code of gdbus-codegen itself. Do you want to submit a patch for
this? I'm sure it
Hello all,
As you may know we continue working and pushing for our transition
from Bugzilla and cgit to GitLab.
Similarly to what we said in the previous mail thread, we are still in
the pilot program phase, that means projects that go into our real
deployment at gitlab.gnome.org [1] are still
> > Ah yes, this is slower than before, this was not the case with our
> > instances few weeks ago.
> >
> > I need to check with Andrea.
>
> I tried to load the commit log for json-glib (from North America)
> and
> it took 28 seconds. With our cgit the page loads in maybe half a
> second.
From the migration plan in the wiki:
"Our contention is that copying/moving every existing GNOME issue
to
a new issue tracker is impractical and, in many situations,
undesirable."
May you expand in which many situations is undesirable?
I have tickets in Shotwell that have
Yes, feel free to use https://gitlab-test.gnome.org/ as you wish. Also
feel free to ask if you need some tweak or test at admin level.
You might be interested also to check GitLab itself [0] to see how
aprox 30.000 are managed in a single product and the tests I did in
our test instance [1],
>
> It's more about the readability of the old issues. Those already
> have been migrated two times (trac -> redmine -> bugzilla) and are
> really
> hard to understand and I'm wondering how bad (nor not) it will get.
> I'll check later when I have proper internet access again
Uh. That turned
In particular, I created a new group named External [2] where we can
host projects that are closely related to GNOME and would like to use
our infrastructure but are not official GNOME. This is an early
attempt to opening ourselves more to a wider world.
So far there is only one project, that
Hi,
GtkSourceView 4.0 has been released with GNOME 3.28 in March. It still
depends on GTK+ 3. The port is trivial (it's mostly just getting rid of
deprecated APIs):
https://developer.gnome.org/gtksourceview/stable/porting-guide-3-to-4.html
For my asurance: For very basic use (i.e. using it
On Sat, 2018-01-20 at 11:06 -0600, mcatanz...@gnome.org wrote:
> Hi all,
>
> This bears repeating: the release team will no longer maintain
> JHBuild
> or the JHBuild modulesets. When adding or removing a dependency from
> your module, please now update gnome-build-meta instead.
So, following
Hi Tristan,
>
>
> Also, your question makes me realize I need to clarify some more
> things
> about sysdeps and how they have changed, there is a longer term plan
> which involves collaboration with the newly created freedesktop-sdk
> project (see: gitlab project[0] and mailing list[1]) for
>
>
>
> Alessandro Bono
> mailto:ab...@gnome.org; />
> abono
>
>
But that still doesn't make it a valid tag according to the spec or do
we just ignore that?
___
desktop-devel-list mailing list
com/phako/dleyna-core/
> https://github.com/phako/dleyna-connector-dbus/
> https://github.com/phako/dleyna-renderer/
> https://github.com/phako/dleyna-server/
>
> On Mon, 2020-06-22 at 13:02 +, Debarshi Ray wrote:
> > On Sun, Dec 16, 2018 at 07:31:03PM +0100, Jens Georg
Hello,
I am going to give up gexiv2 maintainership, for multiple reasons.
One of them is that I have too many projects, the other one is I don't
want to work with Exiv2 upstream anymore.
I will do a final 0.14 release for GNOME 41 and than I'll stop caring.
Sorry about that, but I have to let
42 matches
Mail list logo
