Re: How to detect a gtk desktop programmatically

[Michael Biebl via desktop-devel-list]

Am Do., 30. Apr. 2020 um 00:32 Uhr schrieb Zander Brown :
>
> That's an unfortunate truth which is why I was hoping for an alternative way 
> to detect this.
> At time of writing this, Ubuntu's the only one I've found modifying 
> XDG_CURRENT_DESKTOP and keep something indicative of Gtk inside e.g. 
> (ubuntu:GNOME).
>
>
> Nothing about "ubuntu:GNOME" is "indicative of Gtk", it's stating the fact 
> your running Ubuntu's modified GNOME session.
>
> XDG_CURRENT_DESKTOP is supposed to indicate just that: the current desktop 
> environment
>
> Not some insight into whatever technology that desktop is using - other 
> variables like XDG_SESSION_TYPE do that
>
> Really there is 3 approaches here:
>
> Convince every desktop session to export "OPENJDK_HEY_IM_GTK" and look at 
> that. - and then wait 4/5 years for that to trickle down to users
> Maintain a map of know names in OpenJDK itself
> Assume all Linux based platforms use Gtk
>
>
> When your trying to choose between Windows, GTK, Aqua, Motif & Metal the best 
> choice would seem to be 3
>
> When KDELookAndFeel becomes a thing you can worry about detecting KDE or 
> LXQt, currently this is a rather academic exercise

I have no idea how the Gtk LaF is implemented in Swing and if it needs
any Gtk system libraries.
Wonder how it would behave if you run a KDE or Qt based desktop and no
Gtk libraries are installed,
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.40.20 is released and is the last release in the 2.40.x series

[Michael Biebl]

2017-12-16 15:03 GMT+01:00 Nirbheek Chauhan <nirbheek.chau...@gmail.com>:
> On Sat, Dec 16, 2017 at 7:18 PM, Michael Biebl <mbi...@gmail.com> wrote:
>> 2017-12-16 1:28 GMT+01:00 Federico Mena Quintero <feder...@gnome.org>:
>>> People are *STRONGLY* encouraged to switch to 2.41.x as soon as
>>> possible.  Librsvg 2.41.x is ABI and API compatible with 2.40.x, so it
>>> is a drop-in replacement.  You only need a Rust toolchain to compile
>>> it.  If you or your distro can compile Firefox 57, you can probably
>>> compile librsvg 2.41 without problems.
>>
>> We'd love to switch in Debian, but
>>
>> https://buildd.debian.org/status/package.php?p=rustc=unstable
>>
>> is effectively preventing us from doing that.
>> Looks like Firefox 57 is not coming to stable Debian release either
>> anytime soon:
>> https://buildd.debian.org/status/package.php?p=firefox=sid
>>
>
> I am not sure I understand the status here. Are the failures because
> of missing arch support in llvm or because the arch teams just haven't
> gotten around to bootstrapping cargo and rust yet?

Our porters, from what I know, tried to bootstrap rust on various
architectures but run into multiple issues.
A few of them you can see at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rustc

If you need more details, I can ask them. All I know that this
situation is basically unchanged for a long time already.
Probably doesn't help that rustc considers anything non i386/amd64 as
non-first tier supported.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.40.20 is released and is the last release in the 2.40.x series

[Michael Biebl]

2017-12-16 1:28 GMT+01:00 Federico Mena Quintero :
> Hello,
>
> I have just released librsvg-2.40.20.  This is the last release that I
> will make in the 2.40.x series - the C-only version.
>
> This release is to avoid having unreleased commits in the 2.40 branch.
> It also has a security fix.
>
> People are *STRONGLY* encouraged to switch to 2.41.x as soon as
> possible.  Librsvg 2.41.x is ABI and API compatible with 2.40.x, so it
> is a drop-in replacement.  You only need a Rust toolchain to compile
> it.  If you or your distro can compile Firefox 57, you can probably
> compile librsvg 2.41 without problems.

We'd love to switch in Debian, but

https://buildd.debian.org/status/package.php?p=rustc=unstable

is effectively preventing us from doing that.
Looks like Firefox 57 is not coming to stable Debian release either
anytime soon:
https://buildd.debian.org/status/package.php?p=firefox=sid

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Michael Biebl]

Hi there

2017-09-05 19:48 GMT+02:00 Emmanuele Bassi <eba...@gmail.com>:
> On 5 September 2017 at 18:40, Michael Biebl <mbi...@gmail.com> wrote:

>> Has there been some effort to consolidate the names?
>
> We're still in the process of migrating projects. The migration was
> slowed down for the release of GNOME 3.26.
>
> I fully expect this to become a goal for the 3.28 development cycle,
> while we migrate more projects to Meson; I'll make sure to add a
> sub-page for the porting effort under
> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

Afaics there is no such page yet which documents the list of preferred
build switch names or am I simply not finding it?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Meson feedback as a user

[Michael Biebl]

2017-07-02 16:21 GMT+02:00 Sam Thursfield :
> On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet  wrote:
>> Out of curiosity, let's look at other GNOME-related modules that use
>> gtk-doc. What is the name of the option that enables gtk-doc?
>> - pango:enable_docs
>> - gtk+: enable-documentation
>> - graphene: enable-gtk-doc
>> - atk:  enable_docs
>
> We should indeed work to make these names consistent across GNOME
> modules. Having a page on the wiki where we list standard option names
> for Meson build systems would be a good start.

Has there been some effort to consolidate the names?
Looking at a few random modules I find
 with_docs, with-docs, docs, enable_docs and enable-docs
to enable the gtk-doc API documentation.
Needless to say that's quite annoying.

While at it, please consider dropping the autotoolsism and name the
option "docs", i.e. drop the with or enable prefix.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: developer.gnome.org and meson

[Michael Biebl]

I would prefer if building from git is the same as building from a
dist tarball, which means I wouldn't ship any pre-generated files in
the tarballs unless it's absolutely necessary.
I don't consider the additional dependencies for building the docs an
issue, at least for distro builds it isn't.
I guess it can be useful to not require those dependencies during a
bootstrap phase, but simply being able to disable the documentation is
sufficient for that.

2017-08-09 16:20 GMT+02:00 Emmanuele Bassi :
> In the medium-to-long term, I'd really appreciate if
> developer.gnome.org stopped trying to extract documentation from
> random locations inside tarballs, munge the cross-references, and
> published the HTML on a static website. This would avoid having to
> generate documentation at all, except when needed. After all, Linux
> distributions rebuild the documentation when building the binary
> packages anyway, so shipping documentation in release tarballs is
> pretty much for the benefit of developer.gnome.org to begin with.
>
> Ideally, with the switch to Gitlab, we'd be able to run CI targets for
> each module; that would allow us to build the API reference (and any
> other documentation we deem worthy of publishing), ensure that the
> cross-references pointed to a well-known URL prefix as part of the
> build itself, and publish them when pushing a release tag.
>
> Additionally, GitLab pages[0] would ensure that any module with
> documentation would have it published, without necessarily teaching
> developer.gnome.org how to do it.
>
> Ciao,
>  Emmanuele.
>
> [0]: https://about.gitlab.com/features/pages/
>
>
> On 9 August 2017 at 15:12, Bastien Nocera  wrote:
>> On Wed, 2017-08-09 at 08:33 -0500, mcatanz...@gnome.org wrote:
>>> Hi,
>>>
>>> developer.gnome.org is going to have some problems because for meson
>>> modules 'ninja dist' does not include generated gtk-doc files in the
>>> tarball. At least one maintainer is working around this by manually
>>> generating tarballs with gtk-doc included instead of using 'ninja
>>> dist'. I don't recommend doing that since that's equivalent to
>>> skipping
>>> distcheck. It's better to use meson's dist target.
>>> developer.gnome.org
>>> is just going to have to learn to build docs itself.
>>>
>>> Is anybody working on developer.gnome.org? Anyone interested in
>>> taking
>>> on this task? Otherwise it is going to be stuck with outdated docs.
>>
>> I filed this:
>> https://github.com/mesonbuild/meson/issues/2166
>>
>> I don't know whether that's something we'd want longer term, but it's a
>> win short-term.
>>
>> Cheers
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Michael Biebl]

017-05-18 18:22 GMT+02:00 Carlos Soriano via desktop-devel-list
:

> The only problem that arises if Nautilus becomes GPL3+ as per yesteday
> discussion in IRC at #gnome-hackers is that extensions that are GPL2-only
> cannot be used anymore.
> Keep in mind GPL2+ are fine.
>
> Said this, I took a look at extensions which are not retired from distros
> and that have seen a release in at least the last 3 years. So far they are:
> nautilus-dropbox - GPL3+
> nautilus-image-converter - GPL2+
> nautilus-pastebin - GPL2+
> nautilus-python - GPL2+
> nautilus-search-tool - GPL2+
> nautilus-sendto - GPL2+
> nautilus-terminal - GPL2+

I found the tortoise-hg plugin in the Debian archive, which seems to
be GPL2 only
https://sources.debian.net/src/tortoisehg/4.0-1/contrib/nautilus-thg.py/


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME and Debian usability testing, May 2017

[Michael Biebl]

Thought this might be interesting/useful to a wider GNOME audience:

 Weitergeleitete Nachricht 
Betreff: GNOME and Debian usability testing, May 2017
Datum: Mon, 15 May 2017 13:10:45 +0200
Von: intrigeri 
An: Jim Hall , Debian GNOME Maintainers

Kopie (CC): more-than-a-...@boum.org

Hi Jim & Debian+GNOME people,

I guess you'll be interested in this usability testing report:
https://people.debian.org/~intrigeri/blog/posts/GNOME_and_Debian_usability_testing_201705/

Let me know if there's anything you'd like me to do with these results
so they're as useful as they can be :)

Cheers,
-- 
intrigeri
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gtk-doc and meson

[Michael Biebl]

2017-03-25 19:16 GMT+01:00 Jan Alexander Steffens :
> On Sat, Mar 25, 2017 at 12:21 PM Tim-Philipp Müller  wrote:
>>
>> IIRC most issues could be worked around by copying things into the
>> build directory.
>
>
> Yes. See, for example,
> https://git.gnome.org/browse/grilo/commit1/?id=c5eac4907f9a99280064aa001485f9696f5ebe10

Having to copy the files manually is rather ugly though and it's easy
to miss when new files are added.

I would hope that gtk-doc can be improved that workarounds like that
are not necessary.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

gtk-doc and meson [Re: meson version for GNOME 3.26]

[Michael Biebl]

With Meson gaining more traction in GNOME I guess it's about time to
improve gtk-doc's support for out-of-tree builds.
At least people should be aware of issues like
https://bugzilla.gnome.org/show_bug.cgi?id=776427
when porting to Meson. Out-of-tree builds are rarely tested for
gtk-doc and there can be subtle breakages like missing images, code
samples etc.



2017-03-18 17:41 GMT+01:00 Michael Catanzaro :
> Hi,
>
> For GNOME 3.26, the maximum required version of meson will be meson
> 0.39.1 (matching what will be in Ubuntu 17.04). If you remove Autotools
> support from your module in favor of meson, you must ensure that it
> builds properly with this version of meson. (If you have added a meson
> build but retain Autotools support, then you can require whatever
> version of meson you want.)
>
> Reminder: for GNOME 3.24 the maximum required version of meson is
> 0.34.0.
>
> Ideally, we would build meson in JHBuild itself and ignore the version
> of meson installed on the system, freeing ourselves from this version
> requirement. It requires a volunteer to teach JHBuild to understand
> that  tags in the moduleset definitions mean it has to build the
> meson module. Currently JHBuild understands it to mean that it requires
> the meson package to be installed on the system, and code changes are
> required to alter this.
>
> Michael
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Librsvg 2.41.0 is released

[Michael Biebl]

Hi there!

2017-01-04 1:48 GMT+01:00 Federico Mena Quintero :
> Librsvg 2.41.0 is just released!
>
> This is the first version to have Rust code in it.  The public API
> remains unchanged.  Apologies in advance to distros who will have to
> adjust their build systems for Rust - it's like taking a one-time
> vaccine; you'll be better off in the end for it.

It has been mentioned on #debian-devel that rustc is really only
supported on i386 and amd64 (as a so-called tier1 architecture).
https://buildd.debian.org/status/package.php?p=rustc=sid looks pretty sad.

Just curious if you aware of this limited portability?

[1] https://forge.rust-lang.org/platform-support.html
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Tracker as a security risks

[Michael Biebl]

2016-12-09 7:11 GMT+01:00 Tomasz Torcz <to...@pipebreaker.pl>:
> On Fri, Dec 09, 2016 at 01:35:39AM +0100, Michael Biebl wrote:
>> 2016-12-06 0:03 GMT+01:00 Michael Catanzaro <mcatanz...@gnome.org>:
>> > On Mon, 2016-12-05 at 21:31 +0100, Carlos Garnacho wrote:
>> >> Thanks for the tip :), worth a look indeed, although I'm looking into
>> >> using seccomp directly.
>> >
>> > Strongly consider using libseccomp for this!
>>
>> Has it been considered to use the systemd sandboxing features? tracker
>> already ships systemd --user service files, so you'd basically get
>> that for free.
>
>   Correct me if I'm wrong, but aren't systemd sandboxing features only
> available to system instance?  User systemd sessions lack priviledges
> to set up separate namespaces etc.

The seccomp based ones aren't. I'm aware though, that most *do*
require root privileges to set up and I've asked upstream to more
clearly mark which features are available user services and which
aren't in the documentation.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Tracker as a security risks

[Michael Biebl]

2016-12-06 0:03 GMT+01:00 Michael Catanzaro :
> On Mon, 2016-12-05 at 21:31 +0100, Carlos Garnacho wrote:
>> Thanks for the tip :), worth a look indeed, although I'm looking into
>> using seccomp directly.
>
> Strongly consider using libseccomp for this!

Has it been considered to use the systemd sandboxing features? tracker
already ships systemd --user service files, so you'd basically get
that for free.
I know that some distros don't use systemd, but those are usually the
same ones that don't ship GNOME.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: File roller extracting with double click, bug/feature ?

[Michael Biebl]

This wasn't mentioned yet. But this feature is optional. You can
configure this in nautilus settings.
or via
gsettings set org.gnome.nautilus.preferences automatic-decompression false

2016-11-13 0:14 GMT+01:00 Bastien Nocera :
> On Sat, 2016-11-12 at 16:58 -0500, Baptiste Saleil wrote:
>> Thanks for the link to the blog post (thus the explanation to disable
>> the feature).
>>
>> So you mentioned that "Extract here" should not be available.
>
> The "Extract here" from file-roller, further down the menu, shouldn't
> be there. The "Extract here" from nautilus at the top of the menu
> should be there.
>
>> Actually it is available only if I enable the "Extract when opening"
>> option in nautilus and is not available when I uncheck it.
>> Is it not supposed to be the opposite ?
>
> No, that's about correct.
>
>> You said that it could be caused by a version mismatch, but my system
>> reports that version 3.22.1 of nautilus and 3.22.2 of file-roller are
>> installed. Should I report this as a bug ?
>
> Doesn't seem like a bug to me.
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Michael Biebl]

2016-10-05 14:54 GMT+02:00 Michael Catanzaro :

> I'm a little surprised at the use of CMake instead of meson, but that's
> your choice to make.

As much as I hate autotools and its arcane syntax, it does bring
uniformity and consistency.
Atm I'm counting waf (for some non-core modules), autotools, cmake and
some are discussing to use meson/ninja.

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/integrator.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-user-share / g-s-d will require systemd --user in 3.22

[Michael Biebl]

2016-09-05 13:56 GMT+02:00 Mart Raudsepp <l...@gentoo.org>:
> On Mon, 2016-09-05 at 12:56 +0200, Michael Biebl wrote:
>> Hi,
>>
>> I guess this deserves some wider announcement, so downstreams are
>> aware of this new dependency which was added  to gnome-settings-
>> daemon
>> after 3.21.90.
>>
>> See
>> https://bugzilla.gnome.org/show_bug.cgi?id=770758#c3
>> https://bugzilla.gnome.org/show_bug.cgi?id=766329
>
> Please explain, if possible, what are the implications for people not
> running under systemd.
> Should we avoid gnome-user-share completely on non-systemd cases? What
> are the implications to the gnome-settings-daemon side of things then?
>
>
> We support all init systems. Work is ongoing to support logind
> interface without systemd. We already have independent implementations
> of timedated, hostnamed and localed. Additional dependencies beyond
> those and logind without careful consideration and announcement not
> really welcome.
> I personally am a happy user of systemd under Gentoo though.

I'm a downstream as well (Debian), which was caught by this change.
Note this particular change was merged after the official beta release
and is only in Git atm, but it's targetted for 3.22.
Personally I'm a bit concerned that such a far reaching change was
slipped in *after* the beta release.

If you look at 770758, where I tried to make gnome-user-share
buildable on on-systemd systems, this bug was rejected, on the grounds
that g-s-d now requires systemd --user to start those services.

The implications I see so far are:
- gnome-user-share is no longer buildable on non-systemd systems
- vino is no longer buildable on non-systemd systems
- the sharing panel in g-c-c will be broken as it requires g-s-d
sharing which no relies on systemd --user.

Now, logind, timedated, hostnamed and localed are something completely
different. Those are system services, where writing a replacement at
least for the latter 3, is rather simple.

systemd --user is much more involved. Providing a replacement for that
is imho, not easily possible.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-user-share / g-s-d will require systemd --user in 3.22

[Michael Biebl]

Hi,

I guess this deserves some wider announcement, so downstreams are
aware of this new dependency which was added  to gnome-settings-daemon
after 3.21.90.

See
https://bugzilla.gnome.org/show_bug.cgi?id=770758#c3
https://bugzilla.gnome.org/show_bug.cgi?id=766329




Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.21.91

[Michael Biebl]

Hi

2016-09-02 1:16 GMT+02:00 Matthias Clasen :
> Hi,
>
> GNOME 3.21.91 is now available. This is our second beta release on the

I notice that totem 3.21.91 has a dependency on clutter-gtk 1.18.1,
but there is no release for clutter-gtk yet.
Can the maintainer of clutter-gtk please be poked to make a 1.18.1 release?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Michael Biebl]

2016-06-02 14:38 GMT+02:00 Bastien Nocera :
> And for gnome-photos you expect a collection of photos?

Jeremy raised valid concerns which I share and your response are snide remarks.

This is not constructive.

Please take the concerns of your users and downstreams more seriously.

We are here because we love GNOME, not because we want to annoy you.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Michael Biebl]

2016-06-02 11:24 GMT+02:00 Bastien Nocera :
> gnome-games package in your distribution "gnome-games-app". There's
> already prior art in that case with epiphany, the web browser vs. the
> game.

Right, I hope we don't repeat that mistake. That name conflict is
rather painful and confusing.
Let's not repeat that if we can avoid it.

Reading gnome-games, I expect a collection of games, thh. Given
Adrien's explanations, I think gnome-game-manager or gnome-video-games
would be much more suitable.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Death of gnome-common

[Michael Biebl]

Hi,

2015-06-24 9:56 GMT+02:00 Emmanuele Bassi eba...@gmail.com:
 On 23 June 2015 at 23:41, Philip Withnall phi...@tecnocode.co.uk wrote:
 What if your module uses glib-gettext, gtk-doc, or intltool?

 I do hope that, if you're using glib-gettext or intltool, you spend a
 little bit of time to port to upstream gettext instead.

Interesting. Is intltool considered deprecated nowadays? If so, where
can I read more about it?

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: TARBALLS DUE: GNOME 3.12.0

[Michael Biebl]

Awesome, thanks
Am 26.04.2014 16:38 schrieb Arx Cruz arxc...@gmail.com:

 3.12.1 tarballs uploaded with several fixes :)

 Kind regards,
 Arx Cruz


 On Wed, Apr 23, 2014 at 1:35 PM, Michael Biebl mbi...@gmail.com wrote:

 2014-03-22 14:11 GMT+01:00 Frederic Peters fpet...@gnome.org:
  Hello all,
 
  With 3.11.92 out, it's time for 3.12.0 tarballs. Let the translations
  flow into your modules then get your tarballs out.

 I don't see any 3.12.0 tarballs for zenity, the last one is
 zenity-3.8.0.tar.xz.
 Yet there are git tags for 3.10.0 and 3.12.0.

 Would be great to have tarballs for those newer releases as well.
 What's the proper procedure here: email the maintainer? bugzilla?

 Michael



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: TARBALLS DUE: GNOME 3.12.0

[Michael Biebl]

2014-03-22 14:11 GMT+01:00 Frederic Peters fpet...@gnome.org:
 Hello all,

 With 3.11.92 out, it's time for 3.12.0 tarballs. Let the translations
 flow into your modules then get your tarballs out.

I don't see any 3.12.0 tarballs for zenity, the last one is zenity-3.8.0.tar.xz.
Yet there are git tags for 3.10.0 and 3.12.0.

Would be great to have tarballs for those newer releases as well.
What's the proper procedure here: email the maintainer? bugzilla?

Michael
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GCalctool renamed to GNOME Calculator

[Michael Biebl]

2012/11/15 Jeremy Bicha jbi...@ubuntu.com

 On 13 November 2012 21:49, Robert Ancell robert.anc...@gmail.com wrote:
  I have renamed the GCalctool project to GNOME Calculator with the first
  release being 3.7.1 (we can now follow the GNOME numbering). The git
 module
  is now gnome-calculator (please now update translations/documentation
 there)
  and bugzilla will soon be moved to gnome-calculator.

 Hey, when we do renames like this, should we also add a Keywords entry
 to the .desktop so that people that try to type in gcalc… still find
 the calculator they are used to?


Sounds like a good idea.

Also, my wife has the calculator pinned to her dash so, I expect when
 she upgrades that favorite will disappear. That's something for
 distro packagers to do some gsettings/dconf magic to help migrate,
 right?


 that would be a something for session-migration [1], I guess.

Michael

[1] http://blog.didrocks.fr/post/Announcing-session-migration-now-in-ubuntu
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GCalctool renamed to GNOME Calculator

[Michael Biebl]

2012/11/15 Jasper St. Pierre jstpie...@mecheye.net

 We should keep the desktop files so that they have the same name,
 hopefully. It's always been an internal UUID of sorts (we still have
 epiphany, file-roller, baobab, etc.)


Keeping the old .desktop file name would obviously result in the least
amount of work.
But in practice there have been quite a few renamings,
like palimpsest.desktop - gnome-disks.desktop


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GCalctool renamed to GNOME Calculator

[Michael Biebl]

2012/11/15 Michael Biebl mbi...@gmail.com

 2012/11/15 Jeremy Bicha jbi...@ubuntu.com

 On 13 November 2012 21:49, Robert Ancell robert.anc...@gmail.com wrote:
  I have renamed the GCalctool project to GNOME Calculator with the
 first



 Also, my wife has the calculator pinned to her dash so, I expect when

 she upgrades that favorite will disappear. That's something for
 distro packagers to do some gsettings/dconf magic to help migrate,
 right?


  that would be a something for session-migration [1], I guess.


I guess the hard part will be, to find all the relevant places where that
old file(name) is used.
Like  org.gnome.shell favorite-apps in dconf,
~/.local/share/applications/, etc.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Finding and debugging the battery applet in GNOME 3.4 fallback mode

[Michael Biebl]

2012/5/29 Martin Langhoff martin.langh...@gmail.com:
 I am trying to characterize a bug in OLPC's development builds (based
 on F17) where the battery icon applet is out of sync with upower.

We've had similar bug reports in Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674429

Not sure if this particular issue has already been reported upstream.
In any case, it would be nice if you could keep me updated on this in
case you find out anything.

Thanks,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing Photos

[Michael Biebl]

2012/5/11 Martyn Russell mar...@lanedo.com:
 On 05/10/2012 08:24 PM, John Stowers wrote:

 Correct me if I am wrong, but I thought GNOME only depended on
 tracker-store and not the indexer?


 The two are in the same tarball release, so it would be up to packagers to
 separate them and AFAIK, that's not been the case at all (at least on Fedora
 and Ubuntu).

This is not quite true. Ubuntu is using the Debian package, and in
Debian I've split the miners into separate packages.
I.e., you can use tracker-store without having the filesystem miner installed.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]

[Michael Biebl]

Hi David,

Am 21. Januar 2012 19:33 schrieb David Zeuthen zeut...@gmail.com:
 On Sat, Jan 21, 2012 at 8:04 AM, Frederic Peters fpet...@gnome.org wrote:

 Speaking of udisks, gnome-disk-utility has now been switched to use
 udisks2;

 Note that distributors are free to continue using the old udisks1 (and
 udisks2 is parallel installable with udisks1) with gnome-disk-utility
 3.2.x series as long as they want.

Seing that KDE still uses udisks1, I'm wondering what happens if one
compiles gdu/gvfs against udisks2 and starts a KDE app within GNOME. I
assume this will fire up udisks-daemon 1 and so both udisks-daemon 1
and 2 are running at the same time. Will they step on each others toes
in this case?

What is your plan for Fedora (given that you also have a KDE spin).
Will you ship both udisks versions in the archive? udisks2 for GNOME
3.4 and udisks1 for KDE?

Do you know of any efforts of getting KDE/Solid ported to udisks2?

 @David: could you confirm this? And do you have any ETA for a udisks2
 tarball?

 There is one at http://udisks.freedesktop.org/releases/

How feature complete do you consider this 1.90.0 release? What is
missing compared to udisks1? Are any major disruptive changes still
planned before a 2.0 release?

Cheers and all the best,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism

[Michael Biebl]

Am 20. Januar 2012 17:50 schrieb Bastien Nocera had...@hadess.net:
 On Fri, 2012-01-20 at 10:29 -0500, Ryan Lortie wrote:
 snip
  and get them to package up the missing
  bits. An afternoon's work, and no need to scream bloody murder.

 As mentioned above -- Lennart has no intention of making it easy to use
 his code outside of systemd (and I don't blame him).  This is not a
 matter of some simple packaging -- more like reimplementing a D-Bus
 interface in a new code base (which could originally be copied out of
 systemd, but then would have to be maintained separately).  This is not
 an afternoon's work.

 In about 40 minutes, I created a binary RPM[1] that contains the 3
 services we care about in GNOME from the systemd Fedora package. I
 believe you do something similar.

It's unfortunately not as simple as that as far as Debian is concerned
or any other non-Linux distro. systemd is Linux-only. The
aforementioned components timedated, hostnamed and localed can't be
compiled on non-Linux systems.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feature proposal: Alternative input system based on low-cost webcam

[Michael Biebl]

2011/10/22 Richard Hughes hughsi...@gmail.com:
 On 21 October 2011 17:28, Piñeiro apinhe...@igalia.com wrote:
  * Look and feel: some people could not agree with current interface
 [2]. This shouldn't be a blocker thought.
 This feature proposal would include the proposal of wxWidgets
 as a external dependency.

 wxWidgets applications differ lots from native applications. I
 really don't think depending on wxWidgets is a good idea.

Although I'm not an active user of wxWidgets I do know that the
maintenance of wxWidgets in Debian has always been a major hassle.
E.g. there still isn't a stable upstream release of wxWidgets that
supports GTK 3. There is supposed to be one beginning next year, but
apparently that has been said since almost three years.
And the current stable branch, 2.8, still uses obsolete libraries like
libgnomeprint and apparently wxWidgets upstream likes to introduce
disruptive changes within a stable branch.

So I hope, that we won't depend on wxWidgets as toolkit.


Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Using .tar.xz only on ftp.gnome.org (was: install-module / ftp.gnome.org / master.gnome.org)

[Michael Biebl]

2011/3/19 Emilio Pozuelo Monfort po...@debian.org:
 On 19/03/11 11:19, Olav Vitters wrote:
 Note: breaking thread on purpose.

 On Wed, Mar 02, 2011 at 04:31:23PM +0100, Olav Vitters wrote:
 On Wed, Mar 02, 2011 at 03:15:34PM +, Emilio Pozuelo Monfort wrote:
 From a Debian POV, we can't upload .xz upstream tarballs yet (dpkg 
 supports it,
 but the ftp-masters don't allow it), though most likely that will change 
 soon.

 Could you ask when they'd allow that? And please mention we're
 considering switching. Don't want it to result in people compressing
 again though.

 I'm in the finishing stages to have all our scripts support .tar.xz
 (install-module, release team scripts). Once that is complete, I plan to
 send an 'intend to switch' announcement mail.

 As a pre-warning, could you please ask the ftp-masters again to support
 .xz?

 They have included this item in their agenda for the meeting. I've told them
 that GNOME plans to switch to .xz soon and that not allowing that in Debian
 would mean we'd need to repackage upstream tarballs (which is bad).

Would tar.xz be the only available format or do you plan to keep both
.gz and .xz tarballs
 (as currently there are .gz and .bz2)?

Michel


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: External dependencies, DeviceKit-power and GNOME Power Manager

[Michael Biebl]

2008/11/24 Richard Hughes [EMAIL PROTECTED]:

 Q: Why is system wide better?
 A: There's no point doing the data collection, statistics profiling and
 calculations in every session on a multiuser workstation. There's also
 the point that at GDM you run a g-p-m instance, which doesn't have
 access to the profiling data you generate in the session, and so you get
 unknown time remaining.



 Q: Yet another system daemon?!?
 A: No, all the DeviceKit daemons are system activated and low footprint,
 so if you don't need them they don't get started.


If the DeviceKit-power daemon does data collection and stuff,
shouldn't it be then running all the time (and as soon during the boot
process as possible)?

What about DeviceKit-disks and S.M.A.R.T. monitoring (which I think it does):
If the service is only started as soon as you log in and start an
application like palimpsest, isn't there a risk that we could miss
important events, i.e. shouldn't DeviceKit-disks not also be started
as soon as possible and running all the time?

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Problem with intltool 0.40.0?

[Michael Biebl]

2008/7/22 David Zeuthen [EMAIL PROTECTED]:
 On Thu, 2008-07-10 at 11:14 -0400, David Zeuthen wrote:
 On Tue, 2008-07-01 at 17:01 -0400, Colin Walters wrote:
  Options:
 
  o Rename intltool to intltool2, allow parallel install with intltool 1
  o Add backwards compatibility support
  o Don't screw with minor build system things right now, and wait a year
or so until waf is widely deployed, then switch wholesale and gain
useful improvements instead of plugging a one small leak in the
sinking shell script mess of auto*

 Can the release team please advise on this? (for example mandate that
 we're using intltool  0.40 for 2.24). FWIW, the thread starts here

 http://mail.gnome.org/archives/desktop-devel-list/2008-July/msg00011.html

 Thanks.

 It's now been 12 days since I sent this mail and I've received no reply.
 Is it possible for the release team to advise on how to proceed on
 dealing with the incident of ABI breakage? Thank you.


I had filed a bug in the Debian BTS and also upstream:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484721
http://bugzilla.gnome.org/show_bug.cgi?id=537352

intltool upstream doesn't seem to agree that this is a major annoyance.
I proposed a more smooth upgrade path in the bug report, but upstream
is apparently not interested.


Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Michael Biebl]

2008/7/22 Rob Taylor [EMAIL PROTECTED]:

Hi Rob,

 Just as a quick note, Jason's problem is completly a debian unstable
 packaging issue, as far as I can tell.

Care to eloborate, why and what the actual problem actually is
(especially regarding Debian)?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Michael Biebl]

2008/7/23 Jason D. Clinton [EMAIL PROTECTED]:
 On Tue, Jul 22, 2008 at 7:02 PM, Michael Biebl [EMAIL PROTECTED] wrote:

 2008/7/22 Rob Taylor [EMAIL PROTECTED]:

 Hi Rob,

  Just as a quick note, Jason's problem is completly a debian unstable
  packaging issue, as far as I can tell.

 Care to eloborate, why and what the actual problem actually is
 (especially regarding Debian)?

 /usr/share/PolicyKit/policy files in the 0.5.11 upstream distribution are
 not being installed by the Debian hal package.

That's quite simple. The current hal package we ship in Debian doesn't
have PolicyKit support enabled, so no PolicyKit policy files are
installed.
So there's no packaging issue afaics.
It's just a deliberate decision the Debian package maintainers took to
not enable this feature.
After the lenny release, we will reconsider this decision and likely
enable the PolicyKit support.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dep: PolicyKit

[Michael Biebl]

2008/7/23 Jason D. Clinton [EMAIL PROTECTED]:
 On Tue, Jul 22, 2008 at 7:20 PM, Michael Biebl [EMAIL PROTECTED] wrote:

  /usr/share/PolicyKit/policy files in the 0.5.11 upstream distribution
  are
  not being installed by the Debian hal package.

 That's quite simple. The current hal package we ship in Debian doesn't
 have PolicyKit support enabled, so no PolicyKit policy files are
 installed.
 So there's no packaging issue afaics.
 It's just a deliberate decision the Debian package maintainers took to
 not enable this feature.
 After the lenny release, we will reconsider this decision and likely
 enable the PolicyKit support.

 If that's your policy, then you need to patch /etc/dbus-1/system.d/hal.conf
 to NOT use PolicyKit in a package that doesn't have support for it. This
 is--AFAICT--an upstream bug in hal that this stanza is not removed when
 ./configure finds that PK is not going to be enabled. Now THAT is a bug I
 could file. But, as I've said, I already corrected for that and the problem
 appears to be deeper.

I'm honestly not sure what you are talking about, sorry.
There are no PolicyKit bits in Debians hal.conf. We use the group
based approach as we always did.

Cheers,
Michae


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Is there going to be a release of network-manager-applet for GNOME 2.18?

[Michael Biebl]

Dan Williams wrote:
 On Fri, 2007-03-02 at 22:38 +0100, Vincent Untz wrote:
 (cc'ing the NM list)

 Le vendredi 02 mars 2007, à 21:54, Jaap Haitsma a écrit :
 Something I noticed.

 The latest release of network manager (applet) is 0.6.4 which is
 already something like 9 months. AFAIK there has not been a release
 since. Is there going to be a release for 2.18?
 Hi,

 I (and possibly Andre) have pinged NetworkManager people about this.
 It's definitely important to have a release for 2.18.0. (It would have
 been great to have a release for the RC too...)
 
 Yeah; I'll get an applet 0.6.5 release done this week.

What about nm-vpn-properties? See my other email. What's your take on this?

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Is there going to be a release of network-manager-applet for GNOME 2.18?

[Michael Biebl]

Dan Williams wrote:
 On Mon, 2007-03-05 at 19:16 +0100, Michael Biebl wrote:
 Dan Williams wrote:
 On Fri, 2007-03-02 at 22:38 +0100, Vincent Untz wrote:
 (cc'ing the NM list)

 Le vendredi 02 mars 2007, à 21:54, Jaap Haitsma a écrit :
 Something I noticed.

 The latest release of network manager (applet) is 0.6.4 which is
 already something like 9 months. AFAIK there has not been a release
 since. Is there going to be a release for 2.18?
 Hi,

 I (and possibly Andre) have pinged NetworkManager people about this.
 It's definitely important to have a release for 2.18.0. (It would have
 been great to have a release for the RC too...)
 Yeah; I'll get an applet 0.6.5 release done this week.
 What about nm-vpn-properties? See my other email. What's your take on this?
 
 It has not been split out, and is still part of NetworkManager, as are
 the VPN plugins.  I guess it will be released when a 0.6.5 of NM gets
 released.

Well, this is not quite correct. The vpn plugins are in the same svn
source tree, but they are in a different tarball each (make dist).
nm-vpn-properties on the contrary is included in the network-manager
tarball.
I don't recommend to split the small nm-vpn-properties utility into a
separate svn tree and tarball but simply move it from network-manager to
network-manager-applet before 0.6.5 is released.

Thanks,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list