Re: Let's kill gnome-common!

[Bastien Nocera]

On Tue, 2018-02-13 at 10:08 +0100, Carlos Soriano wrote:
> Hi Michael,
> 
> Could you give some context and explanation on this? I could take the
> gnome-autoar, but need to know why this is wanted and the alternative
> to gnome-common.

When the wiki comes back:
https://wiki.gnome.org/Projects/GnomeCommon/Migration

Discussion dates back from May 2015.

Or better port to meson.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.27.90 tarball deadline extended

[Bastien Nocera]

On Thu, 2018-02-08 at 13:57 -0600, mcatanz...@gnome.org wrote:
> Hi developers,
> 
> We're getting closer, but we're not yet at a point where we can 
> recommend that you try generating release tarballs with BuildStream and 
> expect it to work. So I have to reluctantly recommend that you use 
> JHBuild to generate your 3.27.90 release tarballs,

FWIW, I don't see any reason why individual maintainers are being asked
to use this particular tool to create tarballs.

It was clear from the earlier mails that the release-team would be
using BuildStream, it really wasn't explicit that the developers and
maintainers of individual modules were also being asked that.

>  if your module has 
> dependencies that can't be satisfied by your host system. Even though 
> the release team is no longer maintaining JHBuild, you can make 
> whatever changes to the modulesets you need, and I believe that it is 
> still the easiest way to generate your release tarballs at this time.

gnome-control-center requires a newer version of gnome-desktop, which
has usually been released by the release-team on the day of the tarball
deadline.

gnome-settings-daemon requires a new version of gnome-session which
hasn't been released yet.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Release team now using gnome-build-meta repository, not JHBuild

[Bastien Nocera]

On Mon, 2018-01-22 at 14:31 -0600, mcatanz...@gnome.org wrote:
> 
> 
> I'll use one specific anecdote. On October 30, the Autotools build 
> files were removed from at-spi2-core. The accompanying JHBuild 
> moduleset update switching it to use meson was pushed by Philip 
> Withnall (thanks!) on December 1. So at-spi2-core was obviously not 
> buildable with JHBuild during November. at-spi2-core is, of course,
> a 
> dependency of gtk+-3 (via at-spi2-atk), which is a dependency of
> every 
> GNOME app. That means either (a) nobody tried to 'jhbuild build' any 
> app during the entire month of November, or (b) nobody bothered to 
> report that building everything was broken during this time.

Or c) nobody's needed to recompile at-spi-core2 because it hasn't
changed in significant ways in years and the distro provided versions
work just fine.

My at-spi-core checkout dates back from 2013.

I, and I suspect a majority of folks that hack on more than a few
modules, usually install the build dependencies from my distribution,
and then try to compile the application or library ("buildone") that I
want to work on. glib and gtk+ are probably the only 2 libraries that I
recompile at least once a week.

Furthermore, you're the one that asked developers switching to meson
not to change the jhbuild moduleset until a tarball release with meson
existed, so you could run the releases.

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Bastien Nocera]

On Mon, 2018-01-22 at 07:34 -0600, mcatanz...@gnome.org wrote:
> 
> On Mon, Jan 22, 2018 at 7:25 AM, mcatanz...@gnome.org wrote:
> > Were you actually using JHBuild to run integrated system
> > components 
> > (gnome-shell, gnome-session)? If so, how? I was not aware that
> > that 
> > was even possible nowadays.
> > 
> > When developing these components,
> 
> Sorry, trying again
> 
> When developing components like gnome-shell and gnome-session, I've 
> found myself working in a VM and installing directly into /usr/bin. 
> It's the only way I'm aware of that works. (You can try /usr/local,
> but 
> then you have to hack executable paths in several projects)
> 
> Since it was already not possible to run these components with
> JHBuild, 

It was. You'd build close to the whole desktop, and end up with a
jhbuild session file you'd link in to a system directory (once). From
then on, you'd have a "jhbuild session" available as an option in gdm.

> this does not seem like a regression to me. Tristan mentioned the 
> future goal is to create a VM image, but one step at a time.
> 
> If you are aware of some way that you can successfully run gnome-
> shell 
> or gnome-session or gdm or similar components using JHBuild, I would 
> love to know! gnome-shell used to be possible using 'jhbuild build 
> gnome-shell' and 'jhbuild run gnome-shell -r', but the last time
> that 
> worked for me was many years ago.

"When you still used X11". That worked when the shell wasn't also the
display server.

>  Even trying different combinations of 
> undocumented args like --nested and --wayland, I've yet to see it
> work 
> in recent times.

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

Re: About lib version and git

[Bastien Nocera]

Hey Daniel,

On Wed, 2018-01-17 at 11:49 +0100, Daniel Garcia Moreno wrote:
> On Tue, Jan 16, 2018 at 9:35 PM, Philip Withnall  .uk> wrote:
> > On Tue, 2018-01-16 at 12:17 -0600, Federico Mena Quintero wrote:
> > > It doesn't really matter when you do it.  There are some
> > important
> > > things:
> > >
> > > * Make sure the new header files are parallel-installable with
> > the
> > > old
> > > ones.
> > >
> > > * Make sure the soname in the library changes.  Grep for
> > LT_VERSION
> > > here: https://wiki.gnome.org/MaintainersCorner/Releasing -
> > although
> > > I'm
> > > not sure how this works in Meson.
> > >
> > > Just to avoid apps that use the old API to inadvertently try to
> > > compile/link with the new one.
> > 
> > There is a documentation page covering this in its entirety:
> > 
> > https://developer.gnome.org/programming-guidelines/unstable/paralle
> > l-in
> > stallability.html.en
> > 
> > Pay attention to all of it; if there’s only one part of your
> > library
> > which is not parallel installable, the whole thing is effectively
> > not
> > parallel installable.
> 
> I've changed the version number and the build names so now for the
> next version all goes with a different name, so I think that this
> will allow different versions of libgepub running in the same system.
> 
> https://gitlab.gnome.org/GNOME/libgepub/commit/d721c7ebba040b935d3c8e
> 0456ccf5a4a674e531
> 
> These are all files that will install libgepub:
> 
> local
> local/lib
> local/lib/libgepub-0.6.so
> local/lib/girepository-1.0
> local/lib/girepository-1.0/Gepub-0.6.typelib
> local/lib/libgepub-0.6.so.0.0.0
> local/lib/libgepub-0.6.so.0
> local/lib/pkgconfig
> local/lib/pkgconfig/libgepub-0.6.pc
> local/share
> local/share/gir-1.0
> local/share/gir-1.0/Gepub-0.6.gir
> local/include
> local/include/libgepub-0.6
> local/include/libgepub-0.6/gepub-widget.h
> local/include/libgepub-0.6/gepub-archive.h
> local/include/libgepub-0.6/gepub-text-chunk.h
> local/include/libgepub-0.6/gepub-doc.h
> local/include/libgepub-0.6/gepub.h
> 
> With this change, anyone that uses libgepub should specify the
> version in his code and link with -lgepub-0.6 for example.
> 
> Is this the recommended way to do that?

That looks correct, but I'm wondering which branches one is supposed to
use now. There's a libgepub-0.5 and a libgepub-0.6 branch, as well as a
master branch.

Usually, you'd use branches for continuing stable releases, and master
for ongoing development. Is libgepub-0.6 your tests before merging into
master?

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

Need a little help with libgweather yak shaving

[Bastien Nocera]

Hello all,

If you're feeling a little generous in this holiday season, do I have
the project for you!

I've spent the past week and a bit triaging libgweather's bugzilla,
adding automated tests, and hooking up continuous integration so it's
easier than ever to contribute to libgweather.

But we still have a fair number of bugs opened against libgweather
which I'd like us to close before migrating to GitLab for issue
tracking.

I've rewritten the libgweather contribution wiki page to include what
we're looking for:
https://wiki.gnome.org/Projects/LibGWeather/ImprovingLocations

This is the list of bugs we'd like to fix before the migration:
https://bugzilla.gnome.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=locations_id=271984=libgweather

A few of them are easier than others, and bug 556843 is a huge task
which you can contribute to for your country.

Feel free to comment in the bugs with references, and ask here about
more generic concerns.

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

Re: Bugzilla migration tool user accounts

[Bastien Nocera]

On Thu, 2017-11-30 at 05:43 +, philip.chime...@gmail.com wrote:
> On Tue, Nov 28, 2017 at 6:48 AM Nicolas Dufresne <nicolas@ndufresne.c
> a> wrote:
> > Le mardi 28 novembre 2017 à 14:56 +0100, Bastien Nocera a écrit :
> > > Hey,
> > >
> > > On Tue, 2017-11-28 at 04:21 +, philip.chime...@gmail.com
> > wrote:
> > > > Hi list,
> > > >
> > > > This is about the migration tool for Bugzilla bug reports to
> > GitLab
> > > > issues. See, for background, issues [1] and [2]. Currently, the
> > > > migration tool posts all the migrated issues and their
> > associated
> > > > comments as one single user; either the maintainer who runs the
> > > > script, or a special 'bugzilla-migration' user.
> > >
> > > At the very least, I'd expect people who were on CC: for the
> > Bugzilla
> > > bugs to also be CC:ed on the GitLab issues.
> > >
> > > I'm currently on the CC: list for more than 2000 bugs in
> > Bugzilla. That
> > > doesn't cover modules for which I'm a co-maintainer and would
> > have
> > > received automated -ma...@gnome.bugs emails. I would hate to have
> > to
> > > resubscribe to every one of those by hand.
> > >
> > > I already found the 20-odd bugs I was CC:ed on in gnome-calendar
> > a pain
> > > to resubscribe to, so you can imagine with 2k bugs.
> > >
> > > Also, my GNOME.org gitlab registered e-mail address isn't the
> > same as
> > > my bugzilla mail address. It's another problem you might run into
> > with
> > > the migration script.
> > 
> > To be checked in the script, but you have to make sure your
> > bugzilla
> > email is listed in gitlab (it supports multiple email). After
> > migration
> > there will be no issue removing old emails. You can also change
> > your
> > email in bugzilla too if you want, that works these days.
> 
> Indeed, I'm not planning to support an outside mapping of emails
> other than what is in GitLab — good catch that GitLab accounts can
> have more than one email address. I'll need to check that the script
> will behave properly in that case.
> 
> Bastien, do you also mean to imply that the wish to be subscribed to
> >2000 issues means that receiving >2000 mails won't be a problem?

That's fine if I only receive a single mail for each issue. It's either
that, or having to resub to each issue, or lose track of issues I'm
interested in, neither of which are particularly appealing.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla migration tool user accounts

[Bastien Nocera]

On Tue, 2017-11-28 at 09:48 -0500, Nicolas Dufresne wrote:
> Le mardi 28 novembre 2017 à 14:56 +0100, Bastien Nocera a écrit :
> > Hey,
> > 
> > On Tue, 2017-11-28 at 04:21 +, philip.chime...@gmail.com wrote:
> > > Hi list,
> > > 
> > > This is about the migration tool for Bugzilla bug reports to
> > > GitLab
> > > issues. See, for background, issues [1] and [2]. Currently, the
> > > migration tool posts all the migrated issues and their associated
> > > comments as one single user; either the maintainer who runs the
> > > script, or a special 'bugzilla-migration' user.
> > 
> > At the very least, I'd expect people who were on CC: for the
> > Bugzilla
> > bugs to also be CC:ed on the GitLab issues.
> > 
> > I'm currently on the CC: list for more than 2000 bugs in Bugzilla.
> > That
> > doesn't cover modules for which I'm a co-maintainer and would have
> > received automated -ma...@gnome.bugs emails. I would hate to have
> > to
> > resubscribe to every one of those by hand.
> > 
> > I already found the 20-odd bugs I was CC:ed on in gnome-calendar a
> > pain
> > to resubscribe to, so you can imagine with 2k bugs.
> > 
> > Also, my GNOME.org gitlab registered e-mail address isn't the same
> > as
> > my bugzilla mail address. It's another problem you might run into
> > with
> > the migration script.
> 
> To be checked in the script, but you have to make sure your bugzilla
> email is listed in gitlab (it supports multiple email).

Cool.

>  After migration
> there will be no issue removing old emails. You can also change your
> email in bugzilla too if you want, that works these days.

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

Re: Bugzilla migration tool user accounts

[Bastien Nocera]

Hey,

On Tue, 2017-11-28 at 04:21 +, philip.chime...@gmail.com wrote:
> Hi list,
> 
> This is about the migration tool for Bugzilla bug reports to GitLab
> issues. See, for background, issues [1] and [2]. Currently, the
> migration tool posts all the migrated issues and their associated
> comments as one single user; either the maintainer who runs the
> script, or a special 'bugzilla-migration' user.

At the very least, I'd expect people who were on CC: for the Bugzilla
bugs to also be CC:ed on the GitLab issues.

I'm currently on the CC: list for more than 2000 bugs in Bugzilla. That
doesn't cover modules for which I'm a co-maintainer and would have
received automated -ma...@gnome.bugs emails. I would hate to have to
resubscribe to every one of those by hand.

I already found the 20-odd bugs I was CC:ed on in gnome-calendar a pain
to resubscribe to, so you can imagine with 2k bugs.

Also, my GNOME.org gitlab registered e-mail address isn't the same as
my bugzilla mail address. It's another problem you might run into with
the migration script.

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

Re: GNOME 3.27.2 RELEASED

[Bastien Nocera]

On Wed, 2017-11-15 at 20:15 +0900, Tristan Van Berkom wrote:
> Hi all,
> 
> GNOME 3.27.2, the second unstable release in the 3.28 development
> cycle, is now available.
> 
> The porting of more modules to meson continues (which is great!), but
> It's still causing some problems for some modules. See the build
> failures below, along with a short list of other build errors.

> Build Failures
> --
> Instead of including a skip list of failing modules, I will just note
> here which modules were unable to build and for what reason, it looks
> like the majority of failures are due to lack of fresh tarballs:
> 
>   o gnome-chess: Changed to use meson, need new release tarball
> with meson
>   o gnome-documents: Changed to use meson, need a new release tarball
> with meson

It wasn't. Autotools support is still there, but the jhbuild moduleset
was changed to use meson as the default. Reverting this for the release
would have been enough in this case.

>   o gnome-boxes: Changed to use meson, new release tarball exists
> but lacks the meson.build
>   o gnome-terminal:  Depends on vte 0.51.1, only 0.50.2 is available
> (need new vte tarball)
> 
>   o gnome-system-monitor: Build failure
> 
> looks like source schema xml is missing from EXTRA_DIST:
> 
> No rule to make target 'org.gnome.gnome-system-
> monitor.gschema.xml', needed by 'org.gnome.gnome-system-
> monitor.gschema.valid'.  Stop.
> 
>   o fwupd: Stack trace encountered in po/make-images (this seems to
> be
>a bug in the runtime / sysdeps, I will investigate
> further)
> 
>   o gnome-software: Now depends on fwupd, which did not build

Do you have a list of bugs for those build failures?

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

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera]

On Tue, 2017-11-07 at 09:11 -0600, PWR PWR wrote:
> Great discussion! I would encourage making things as customization
> and personalized as possible, as a principle of open source software.

Close enough:
http://www.islinuxaboutchoice.com/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera]

On Tue, 2017-11-07 at 11:05 +, Allan Day wrote:
> Bastien Nocera <had...@hadess.net> wrote:
> ...
> > I don't think that applications such as Calendar, Contacts, or
> > finding
> > and reminding apps should be removed from the requirements for a
> > well-
> > rounded, default desktop. How they're installed is a technical
> > question
> > that's not relevant to the fact that they're needed.
> 
> That's certainly true. I'm mostly coming it this from a direction of
> a) trying to figure out what the user experience will look like on a
> flatpak-based system and b) having done some digging, feeling
> somewhat dissatisfied with the current use of
> . Particular issues that I see:
> 
> 1.  is only respected by Software or other
> "app centers", so you get different behaviour with the command line,
> which lets you install and remove apps that Software doesn't. This
> adds complexity, makes testing difficult, and introduces bugs. It
> also creates ambiguity; I don't think anyone is really sure what the
> experience is supposed to be.

I think that's actually a benefit. rpm/dpkg don't know about Flatpak,
and vice-versa. But Software knows both, and I should be able to remove
the distro provided version of the software if I've installed the same
"mandatory" app using Flatpak (they should have the same ID, otherwise
it's a bug).

Installing Flatpaks and removing RPMs is how some of us are slowly
edging towards Flatpak, dog-fooding Flatpak itself, the infrastructure
around it such as portals, and the software itself if we use nightlies.

> 2. In Software,  is used to hide apps that
> belong to other desktops. In part I think this is motivated by the
> desire not to end up with identical apps (because stock apps tend to
> use the icon theme and often have identical names). However, it has
> the side-effect that applications that could easily be installed
> can't be. This is because it equates something being essential to an
> environment as meaning that it shouldn't be available outside of it,
> which I don't think is always the case - we might well say that
> Photos is essential to GNOME 3, but that doesn't necessarily mean
> that it shouldn't be installable on a non-GNOME system.

That seems like a problem in the appstream format which needs to be
fixed, and possibly have better replacements. Incidentally, do you
rename Photos to GNOME Photos when the current desktop isn't GNOME?

> 3. I guess I just find it strange that this mechanism is so
> decentralised. Can anyone use ? Who makes the
> decisions about what's included and what isn't? How is that monitored
> and managed?

If the lack of centralisation is a problem, we can move that "you can't
uninstall this" list to gnome-desktop for the GNOME desktop. It would
make it easier for the release team to maintain, and curate.

> Relying an the ostree/flatpak split to determine which apps are
> removable has some advantages in relation to this - it would remove a
> layer of configuration, you'd get a consistent experience and GUI
> tools would be transparent in how they operate, it would be the OS
> builder who decides what forms part of the product, and projects
> could decide what to make available as standalone apps simply by
> making them available as flatpaks or not.
> 
> Maybe there are issues with this approach - and I certainly take the
> point about updates - but maybe it's also illustrative of what we
> ought to be aiming for.

I don't think that the underlying technology should be used as the
safeguard for whether or not something can be uninstalled.

As a case in point, most core applications on iOS, the mail client for
example, are shipped and updated with the OS (the "ostree" in your
example above), but can be "removed" (hidden actually). The mail client
is core, can't be removed physically, but can be removed from view.

So the OS technology is always going to allow us to remove/hide. How to
add back is probably relevant.

I think the short answer to this thread is that we need use something
other than mandatory_for_desktop.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera]

On Mon, 2017-11-06 at 07:50 -0500, Matthias Clasen wrote:
> On Mon, Nov 6, 2017 at 7:16 AM, Allan Day <a...@gnome.org> wrote:
> > Bastien Nocera <had...@hadess.net> wrote:
> > ...
> > > > > I don't see the relation between sandboxable and unremovable.
> > > > >
> > > >
> > > > On an image-based OS, wouldn't it be the case that anything
> > > that's
> > > > not a flatpak would be part of the image, and therefore
> > > unremovable?
> > > > I've been looking at this issue recently from a slightly
> > > different
> > > > perspective and wondered whether "part of the base OS" might be
> > > a
> > > > simpler and more natural replacement for
> > > .
> > > 
> > > Seems to me that the whole problem is that gnome-software keeps
> > > the
> > > "package" uninstallable even if the same application is installed
> > > via
> > > Flatpak.
> > > 
> > > Fix that, and you don't need to make any changes to the appdata
> > > files.
> > 
> > I'm thinking about a "pure" system that doesn't have any packages -
> > it's just an ostree-based image with flatpaks installed on it. My
> > understanding is that, in this situation, some apps would be
> > shipped as part of the image, and that these apps wouldn't be
> > removable.
> > 
> > 
> 
> That is really a side-effect of how the OS is deployed. If that is
> all this is about, we can remove all the 'mandatory' markings -
> things in the base image will not be removable anyway.
> I would be in favor of that. Lets treat our users as grown-ups who
> can make their own decisions.

I read that as "Let users shoot themselves in the foot". There are no
expectations that gnome-shell is tested with Calendar, Clocks or
Weather uninstalled.

I'm really not in favour of returning to the bag of bits distribution
model.

I also don't see why how the OS is deployed is relevant. ostree based
images are still not the way that the majority of GNOME installations
are made and given that the apps shipped that way are uninstallable,
the "mandatory for desktop" setting is irrelevant and ignored.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera]

On Mon, 2017-11-06 at 12:16 +, Allan Day wrote:
> Bastien Nocera <had...@hadess.net> wrote:
> ...
> > > > I don't see the relation between sandboxable and unremovable.
> > > >
> > >
> > > On an image-based OS, wouldn't it be the case that anything
> > that's
> > > not a flatpak would be part of the image, and therefore
> > unremovable?
> > > I've been looking at this issue recently from a slightly
> > different
> > > perspective and wondered whether "part of the base OS" might be a
> > > simpler and more natural replacement for .
> > 
> > Seems to me that the whole problem is that gnome-software keeps the
> > "package" uninstallable even if the same application is installed
> > via
> > Flatpak.
> > 
> > Fix that, and you don't need to make any changes to the appdata
> > files.
> 
> I'm thinking about a "pure" system that doesn't have any packages -
> it's just an ostree-based image with flatpaks installed on it. My
> understanding is that, in this situation, some apps would be shipped
> as part of the image, and that these apps wouldn't be removable.

I don't think that we should have applications in the base OS that can
be safely run in Flatpaks, and independently updated.

Say, Settings requires particular versions of the OS, and cannot be run
with arbitrary versions of BlueZ, PulseAudio, gnome-settings-daemon or
gnome-shell.

But, given a baseline in capabilities, a Flatpak of Photos, or
Documents should be able to be upgraded separately in a Flatpak.

That doesn't however mean that those applications should be removable,
or that they shouldn't be shipped as part of the "OS". To me, the OS is
the barebones desktop environment and all the applications necessary to
make it somewhat useful. It has a browser, a way to add applications,
and contains the applications that integrate well for the base
experience.

I don't think that applications such as Calendar, Contacts, or finding
and reminding apps should be removed from the requirements for a well-
rounded, default desktop. How they're installed is a technical question
that's not relevant to the fact that they're needed.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera]

On Mon, 2017-11-06 at 11:23 +0100, Carlos Soriano wrote:
> 
> On Sat, Nov 4, 2017 at 11:03 PM, Jeremy Bicha 
> wrote:
> > On Sat, Nov 4, 2017 at 4:45 PM,   wrote:
> > > On Sat, Nov 4, 2017 at 2:41 PM, Florian Müllner  > org> wrote:
> > >> Why is that in the list? I would expect most users to use the
> > various
> > >> PrintScrn shortcuts for taking screenshots, which don't depend
> > on
> > >> gnome-screenshot (anymore).
> > >
> > >
> > > Maybe we should drop it from core, then?
> > 
> > Well, based on Michael's original definition here, is it an
> > essential
> > app without a popular drop-in replacement that seems to be unable
> > to
> > be properly confined as a Flatpak?
> > 
> > Can it be confined by Flatpak?
> > 
> > I think that it is an essential app. Users expect to be able to
> > take
> > screenshots and we should not expect users to use keyboard
> > shortcuts
> > instead of regular apps. Personally, I don't recall hearing anyone
> > complain about gnome-screenshot being pre-installed and
> > unremovable.
> > 
> > The list seems to be missing several core system utilities:
> > - Archive Manager
> 
> I'm not sure this one should be nowadays, we have the common use case
> covered in Nautilus already (except dammed rar5 in some corner cases,
> but I believe rar is not so used anymore).

It's still used plenty, depending on the use of it, which is why I
worked to have CBR files work out of the box in evince.

Determining usage should also consider its past usage. It's unlikely
that users will re-compress all their files using a different
compression algorithm if their original choice becomes unpopular.

> > - Disks
> > - Disk Usage Analyzer
> > - Logs
> > - System Monitor
> > 
> > Thanks,
> > Jeremy Bicha
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera]

On Fri, 2017-11-03 at 19:03 -0500, mcatanz...@gnome.org wrote:
> Hi,
> 
> Currently about half of the GNOME core apps are unremovable in GNOME 
> Software. It's the set of apps that are not new additions to core
> over 
> the past two years, but at this point that's entirely arbitrary. So
> we 
> need to find a better criterion for determining what should and
> should 
> not be unremovable.
> 
> In the interests of allowing users to replace core apps with their 
> preferred alternatives, I'd like to propose that only the most 
> essential applications -- stuff that cannot plausibly be packaged as
> a 
> properly-sandboxed flatpak -- should remain unremovable. 

I can only say that I have problems understanding what the problem is,
and how this is a reasonable solution.

A number of applications currently set as mandatory are needed to have
a reasonable experience as designed. This is what we test, and what we
would want users to experience. Breakage caused by a particular
application being removed when it's "mandatory" should go as far down
the list of bugs to fix as it could probably go.

> Specifically, 
> I propose that GNOME
> be 
> removed from the appstream metainfo for all of our apps

Which doesn't require the user to have a replacement installed. Which
causes different, possibly broken, experiences to what is designed.

>  except the 
> following four:
> 
>  * gnome-screenshot
>  * gnome-software
>  * nautilus
>  * yelp

I see no reason why those can't be sandboxed. They can be sandboxed
just about as well as most of the other apps can be, eg. with tons of
holes poked in the sandbox. Calendar needs access to the calendar data
shared with Evolution and gnome-shell, all the finding & reminding
applications need access to the per-user Tracker database, Videos needs
unhindered access to gvfs and raw disc devices, etc.

> This matches one of Javier's proposed moduleset changes [1].
> 
> Thoughts?

See my answer to Allan later in the thread, I don't think this is the
right solution.

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

Re: Proposal for reducing the number of unremovable apps in GNOME Software

[Bastien Nocera]

On Mon, 2017-11-06 at 10:51 +, Allan Day wrote:
> Matthias Clasen  wrote:
> ...
> > I don't see the relation between sandboxable and unremovable.
> > 
> 
> On an image-based OS, wouldn't it be the case that anything that's
> not a flatpak would be part of the image, and therefore unremovable?
> I've been looking at this issue recently from a slightly different
> perspective and wondered whether "part of the base OS" might be a
> simpler and more natural replacement for .

Seems to me that the whole problem is that gnome-software keeps the
"package" uninstallable even if the same application is installed via
Flatpak.

Fix that, and you don't need to make any changes to the appdata files.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Include GNOME Usage in the future releases

[Bastien Nocera]

On Mon, 2017-10-16 at 16:27 +0200, Felipe Borges wrote:
> Hi everyone,
> 
> We have been discussing for quite some time the inclusion of GNOME
> Usage in the GNOME release, initially as a "demo".
> 
> The project has been evolving quite fast and it is expected to have
> an
> Outreachy student working on it as well.
> 
> This way, I would like to know whether there are any objections
> regarding the $subject.
> 
> Ideally we would ship it as a demo in GNOME 3.28, but it would be a
> good test to include it in the 3.27.x series too.

Filed a number of bugs.

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

Bug in gitlab git repo redirection (was Re: Cannot access nautilus-sendto repository with HTTPS)

[Bastien Nocera]

Hey,

On Sat, 2017-10-14 at 20:28 +0800, 藍挺瑋 wrote:
> Hello,
> 
> It seems that all nautilus-* repositories on git.gnome.org became 
> inaccessible after nautilus was moved to GitLab. It is still possible
> to 
> access these repositories with GIT or SSH protocol, but I hope we
> can 
> keep HTTPS protocol working.
> 
> $ jhbuild buildone nautilus-sendto
> *** Checking out nautilus-sendto *** [1/1]
> git remote set-url origin https://git.gnome.org/browse/nautilus-sendt
> o
> git remote update origin
> Fetching origin
> fatal: unable to update url base from redirection:
>asked for: 
> https://git.gnome.org/browse/nautilus-sendto/info/refs?service=git-up
> load-pack
> redirect: https://gitlab.gnome.org/users/sign_in
> error: Could not fetch origin

This is a bug in the redirection for GitLab. nautilus-sendto still
lives in git.gnome.org, not on gitlab yet. Overeager widlcard?

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

Re: GitHub mirror creates contribution problems

[Bastien Nocera]

On Tue, 2017-09-05 at 13:12 +0200, Bastien Nocera wrote:
> Hey,
> 
> As expected the GitHub mirror might be costing us some contributions
> rather than attracting more:
> - none of the projects repositories mention that the mirrors are
> mirrors
> - the READMEs don't mention that they're mirrors either, or point to
> the upstream code, Bugzilla or code contributions
> - none of the project pages on the Wiki mention that the GitHub repos
> are mirrors
> - the PR getting closed means that the contribution won't even be
> looked at, after the person's figured out how to try and contribute
> to
> the repository
> 
> From a discussion with a colleague who tried to upstream a fix:
> > I could not find instructions how to submit a patch, but the Github
> > repository had pull requests enabled, so I submitted a fix there:
> > 
> > Then [the automatic closure] happened:
> > [...]
> > 
> > At this point, I moved on to more productive things.
> 
> We really need a way to disable PRs, or disable the mirror.
> 
> At the *very least*, and that would need to happen yesterday, we need
> a
> PR template mentioning that PRs will be closed, and the repository
> descriptions mentioning that the repositories are mirrors.

I'm now getting comments on commits which are really bug reports, like
this one:
https://github.com/GNOME/gdk-pixbuf/commit/c2a40a92fe3df4111ed9da51fe3368c079b86926#commitcomment-24951987

Do we have any control over what's allowed on our mirrors, or do we
need to accept this as yet another source of bug reports, like forums,
blog post comments and Twitter/Facebook/Google+ questions?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Mobile, or "GNOME on Purism's Librem 5"

[Bastien Nocera]

On Tue, 2017-09-05 at 18:14 +0200, Matthias Klumpp wrote:
> 2017-09-05 17:46 GMT+02:00 Bastien Nocera <had...@hadess.net>:
> > 
> > - try integrating with (currently out-of-tree) OOM killer helpers
> > to go
> > away from application lifetime management by the users
> > - implementing USB "gadget" to share the device's network access,
> > or
> > music library (requires specific hardware with the gadget
> > capability)
> > 
> > 

> Alright, that is great to hear! I am not a UI developer myself,

Those last two don't require writing any UI, at least to start with :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Mobile, or "GNOME on Purism's Librem 5"

[Bastien Nocera]

On Sun, 2017-09-03 at 16:29 +0200, Matthias Klumpp wrote:
> [ Please keep the CC list for replies ]
> 

> So, is having a mobile UX something in scope for GNOME as a project
> and the GNOME Shell?
> Did anyone try to use GNOME on a smaller, phone-sized display
> already?
> Is there interest in the community in actually making a "GNOME
> Mobile"
> a reality (of course, Purism would help with that)?
> 
> I am looking forward to your replies!

Disregarding the fact that asking for the direction GNOME would need to
go as a project to accommodate your use case when you've already said
you could achieve it in 18 months seems a bit, well, like putting the
cart before the horse. Anyway...

There are plenty of things to be done on "the desktop" that would be
useful for convertible laptops (like your own Librem 11), tablets (same
one, but without the keyboard) and small form factor tablets, like
cheap 7" Windows tablets you can now find for under $100.

In no particular order:
- working on a tip-top On-Screen Keyboard
- working on more touch-enabled widgets (GtkImageView, "swipe" enabled
listbox rows, slide-under toolbars that need scroll down to show up
again, etc.)
- have a go at gnome-shell's "maximising sovereign windows" problem
(it's named exactly like that in bugzilla ;)
- experimenting with UIs with smaller screens (build yourself a ghetto
phone with the right size screen, and try out whether we need new
widgets, adaptive apps or just CSS changes)
- try integrating with (currently out-of-tree) OOM killer helpers to go
away from application lifetime management by the users
- implementing USB "gadget" to share the device's network access, or
music library (requires specific hardware with the gadget capability)

Tons to do! Let me know if you want to start experimenting with any of
those, I'll gladly point you the right direction, and to the right
people.

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

Re: GitHub mirror creates contribution problems

[Bastien Nocera]

On Tue, 2017-09-05 at 13:33 +, Alberto Fanjul Alonso wrote:
> I remember to suggest a PR and the close response easily drive to
> correct place.

If it happens *after* the PR has been filed, it doesn't help one bit.
The person might be new to GitHub and go through a number of steps to
submit their PR, and they'd have to do it again to submit it through
bugzilla.

> I know bugzilla and git.gnome.org by that time but guess that getting
> such response and don't look at it as it seems automatic is the real
> problem.

That's not the problem.

> Anyway a README.md is available in our projects and is the default
> for github (and people used to github). Maybe a simple automatic
> rebase on master po f a README.md (and if you want a mirror-master
> branch as tip on github) can solve this

That would require making changes to every single mirrored module, so
that's not viable.

> On mar, 5 de septiembre de 2017 13:13 Bastien Nocera
> <had...@hadess.net> wrote:
> > Hey,
> > 
> > As expected the GitHub mirror might be costing us some
> > contributions
> > rather than attracting more:
> > - none of the projects repositories mention that the mirrors are
> > mirrors
> > - the READMEs don't mention that they're mirrors either, or point
> > to
> > the upstream code, Bugzilla or code contributions
> > - none of the project pages on the Wiki mention that the GitHub
> > repos
> > are mirrors
> > - the PR getting closed means that the contribution won't even be
> > looked at, after the person's figured out how to try and contribute
> > to
> > the repository
> > 
> > From a discussion with a colleague who tried to upstream a fix:
> > > I could not find instructions how to submit a patch, but the
> > Github
> > > repository had pull requests enabled, so I submitted a fix there:
> > >
> > > Then [the automatic closure] happened:
> > > [...]
> > >
> > > At this point, I moved on to more productive things.
> > 
> > We really need a way to disable PRs, or disable the mirror.
> > 
> > At the *very least*, and that would need to happen yesterday, we
> > need a
> > PR template mentioning that PRs will be closed, and the repository
> > descriptions mentioning that the repositories are mirrors.
> > 
> > Cheers
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GitHub mirror creates contribution problems

[Bastien Nocera]

Hey,

As expected the GitHub mirror might be costing us some contributions
rather than attracting more:
- none of the projects repositories mention that the mirrors are
mirrors
- the READMEs don't mention that they're mirrors either, or point to
the upstream code, Bugzilla or code contributions
- none of the project pages on the Wiki mention that the GitHub repos
are mirrors
- the PR getting closed means that the contribution won't even be
looked at, after the person's figured out how to try and contribute to
the repository

>From a discussion with a colleague who tried to upstream a fix:
> I could not find instructions how to submit a patch, but the Github
> repository had pull requests enabled, so I submitted a fix there:
> 
> Then [the automatic closure] happened:
> [...]
> 
> At this point, I moved on to more productive things.

We really need a way to disable PRs, or disable the mirror.

At the *very least*, and that would need to happen yesterday, we need a
PR template mentioning that PRs will be closed, and the repository
descriptions mentioning that the repositories are mirrors.

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

Re: Nautilus has officially moved to GitLab

[Bastien Nocera]

On Mon, 2017-09-04 at 15:41 +0100, Alberto Ruiz wrote:
> Should not be a big deal, basically all URLs are still working
> (ssh://u...@git.gnome.org etc...)

They don't, as per my mail.

>  and Carlos is not going to stop
> looking at bugzilla bugs for now. This just means that people can
> start submitting changes through gitlab.gnome.org

Even if you think that nothing is going to go wrong, why put ourselves
in that position? We could have moved any number of applications that
don't follow the GNOME release schedule, to test things, if that was
the intent.

Moving a core application and having to fix things up _while we're
starting the hard code freeze_ really isn't great timing.

That could have been a great "start to the 3.28 development cycle" blog
post, instead it looks like a scramble.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Nautilus has officially moved to GitLab

[Bastien Nocera]

On Mon, 2017-09-04 at 16:30 +0200, Carlos Soriano wrote:
> Hey Bastien,
> 
> I don't feel is neither wise or unwise. Do you have some specific
> concern?
> The only one we had was translations, and that seems to work.

I think that this sort of failure, while we're working on stabilising
the software, is unacceptable:
jhbuild buildone nautilus
*** Checking out nautilus *** [1/1]
git remote set-url origin ssh://had...@git.gnome.org/git/nautilus
git remote update origin
Fetching origin
git repository does not exist.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch origin
*** Error during phase checkout of nautilus: ## Error running
git remote update origin *** [1/1]

It will make it easier to respect the hard code freeze though! ;)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Nautilus has officially moved to GitLab

[Bastien Nocera]

On Mon, 2017-09-04 at 15:47 +0200, Carlos Soriano wrote:
> I guess you can expect this from the previous email, Nautilus has
> moved and is now officially living in our instance of GitLab.
> 
> Many thanks to Alberto Ruiz and Andrea Veri for resolving the issues
> we were blocking on.

Just before the .0 release, is that wise?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Updating GNOME Goals?

[Bastien Nocera]

On Fri, 2017-09-01 at 12:20 +0100, Allan Day wrote:
> I have a list of about 12 apps that don't have search providers and
> probably should. I'd love for us to make some progress on that -
> would it make a good goal?

Let's fix the search providers infrastructure first. They're unusable
on slow machines, and slow down faster machines.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.25.91 released

[Bastien Nocera]

On Wed, 2017-08-23 at 11:38 +0200, Bastien Nocera wrote:
> On Wed, 2017-08-23 at 11:13 +0200, Bastien Nocera wrote:
> > Hey,
> > 
> > On Tue, 2017-08-22 at 01:04 -0500, mcatanz...@gnome.org wrote:
> > > Hi,
> > > 
> > > GNOME 3.25.91, a late development preview of the upcoming GNOME
> > > 3.26 
> > > release, is now available. Please help us test it. If you want
> > > to 
> > > compile GNOME 3.25.91 by yourself, you can use the jhbuild
> > > modulesets 
> > > available here:
> > > 
> > > https://download.gnome.org/teams/releng/3.25.91/
> > 
> > The person releasing the GNOME releases usually also spins a new
> > version of gnome-desktop so that the About section of the Settings
> > has
> > correct information.
> > 
> > Can you please make sure this gets added to the checklist for
> > releases?
> 
> I've released gnome-desktop 3.25.91 with a lovely version number bump
> and thumbnailer fixes. Enjoy :)

I apparently release 3.25.91.1, because I completely blanked out the
sub version which is separated from the other components of the version
numbers. *sigh*
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.25.91 released

[Bastien Nocera]

On Wed, 2017-08-23 at 11:13 +0200, Bastien Nocera wrote:
> Hey,
> 
> On Tue, 2017-08-22 at 01:04 -0500, mcatanz...@gnome.org wrote:
> > Hi,
> > 
> > GNOME 3.25.91, a late development preview of the upcoming GNOME
> > 3.26 
> > release, is now available. Please help us test it. If you want to 
> > compile GNOME 3.25.91 by yourself, you can use the jhbuild
> > modulesets 
> > available here:
> > 
> > https://download.gnome.org/teams/releng/3.25.91/
> 
> The person releasing the GNOME releases usually also spins a new
> version of gnome-desktop so that the About section of the Settings
> has
> correct information.
> 
> Can you please make sure this gets added to the checklist for
> releases?

I've released gnome-desktop 3.25.91 with a lovely version number bump
and thumbnailer fixes. Enjoy :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Initiatives

[Bastien Nocera]

On Tue, 2017-08-22 at 22:23 +0100, Philip Withnall wrote:
> On Tue, 2017-08-22 at 18:50 +, Sriram Ramkrishna wrote:
> > Looks like GNOME Initiatives could use with some updating as well. 
> > There are some that are current and some that might need to be
> > revisited.  For instance:
> > 
> > Document Centric GNOME
> > Memory Reduction
> 
> Memory reduction would be a good one to revisit and update. I was
> looking at that in frustration today as my machine hit swap and an
> Intel driver bug took down my desktop session as a result. It looks
> like we’ve gone sufficiently long without focusing on reducing memory
> usage that there should be some good low-hanging fruit there.
> 
> (For example, it seems like half the shell search providers persist
> in
> memory long (indefinitely?) after a shell search is done, at about
> 50MB
> RSS each.)

There's low-hanging fruit in the shell search providers, certainly. But
I don't think they should be running at all:
https://bugzilla.gnome.org/show_bug.cgi?id=785380

Switching to a systemd-based session should also allow us to transform
some long-running background processes into timer units, freeing some
space.

Finally, getting rid of the gdm shell session will also free up RAM:
https://bugzilla.gnome.org/show_bug.cgi?id=785950
(the duplicate bug has a nonsensical summary)

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

Re: GitLab migration status and roadmap

[Bastien Nocera]

On Mon, 2017-08-14 at 11:02 +0200, Jens Georg wrote:
> > 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 manually added and
> > they
> > have to request us to join. We had have many projects and
> > maintainers
> > asking us to move, but as said to you individually we are holding
> > the
> > gates until we fix our remaining blockers.
> 
> I'm currently massively underwhelmed by the overall performance and
> snappiness of the web interface, even for a small project with not
> that
> much commit history.

To be fair, Bugzilla used to be instant and now takes around 10 seconds
to show a page from Europe. So it might be something more general than
Gitlab.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's pause meson migration in preparation for the 3.26 release

[Bastien Nocera]

On Sun, 2017-08-13 at 20:42 +0200, Petr Kovar wrote:
> On Fri, 11 Aug 2017 11:21:05 -0500
> Michael Catanzaro  wrote:
> 
> > On Fri, Aug 11, 2017 at 10:59 AM, Jeremy Bicha  
> > wrote:
> > > If you want to do these things, please branch for 3.26 and make
> > > your 
> > > changes to git master for 3.27/3.28.
> > > 
> > > Please do continue to fix bugs in the meson build for your
> > > modules.
> > 
> > Thanks Jeremy! This is a good rule to follow.
> > 
> > I do encourage projects to remove their Autotools build systems as
> > soon 
> > as reasonable, since having to support two build systems is
> > causing 
> > many problems. But it's probably not reasonable to do so at this
> > point 
> > until after you've first branched for gnome-3-26.
> 
> Related to this, when migrating your module, please do keep in mind
> that
> Damned Lies support for Meson modules is still incomplete, see
> https://bugzilla.gnome.org/show_bug.cgi?id=783099.
> 
> As Piotr reported elsewhere [1], totem-pl-parser, nautilus-sendto,
> and
> gnome-bluetooth have broken/incomplete i18n support as a result.

The pot file in those haven't changed since autotools, so the i18n
support should be as it was, unless damned-lies can't use the cached
version of the pot files.

> Your help with fixing #783099 would be much appreciated.
> 
> Thanks,
> pk
> 
> [1] https://mail.gnome.org/archives/gnome-i18n/2017-August/msg00015.h
> tml
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.25.90 will probably be delayed

[Bastien Nocera]

On Sat, 2017-08-12 at 17:47 -0500, mcatanz...@gnome.org wrote:
> On Sat, Aug 12, 2017 at 4:52 PM, Bastien Nocera <had...@hadess.net> 
> wrote:
> > What usually happened in the past was that the older version was
> > used
> > when such a problem happened, which would hopefully have
> > streamlined
> > the process somewhat ("I used this old version because that new
> > one...).
> 
> Yes.
> 
> The problem this time is that I don't know what components are even
> to 
> blame for these issues.  E.g. in the PackageKit bug it's not clear
> if 
> the underlying issue is in PackageKit, or gobject-introspection, or 
> glib itself. Since we don't know where the bug is, I don't know
> which 
> package I can hold back.

Right, that's a fair assessment. Might be useful to check afterwards
why the problem wasn't hit on C-I, or jhbuild before you ran into it.

> > Quite a bit of time was also spent on e-mailing maintainers (myself
> > included) that didn't make releases after porting to projects to
> > Meson
> > but changing jhbuild modulesets. I really think that somebody needs
> > to
> > spend the time finding and implementing a solution for this
> > problem.
> 
> We're migrating away from jhbuild and this is a one-time issue, so I 
> don't think it's worth spending time on. The solution is to make a
> new 
> release sometime before the release is due if you switch to meson at 
> the same time that you delete the Autotools build.
> 
> It's annoying to do for 15 modules, which is why I sent out mails,
> but 
> it's also easy to work around by just changing the build type in the 
> release moduleset.

If that's not something that you spent a lot of time on and didn't
block the release on, then don't mind me.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.25.90 will probably be delayed

[Bastien Nocera]

On Sat, 2017-08-12 at 15:40 -0500, mcatanz...@gnome.org wrote:
> Hi developers,
> 
> I'm still struggling to get buildable release modulesets for
> 3.25.90. 
> As you know, tarballs for that release were due Monday and the
> release 
> was due Wednesday, but it's Saturday now and I haven't delivered it 
> yet. Normally I spend about one day working on a release and it's not
> a 
> big deal, but this time around there have been such a huge number of 
> failures that it's taken all week. I can't understate how much worse 
> this release has been than any I've ever worked on before.

What usually happened in the past was that the older version was used
when such a problem happened, which would hopefully have streamlined
the process somewhat ("I used this old version because that new
one...).

Quite a bit of time was also spent on e-mailing maintainers (myself
included) that didn't make releases after porting to projects to Meson
but changing jhbuild modulesets. I really think that somebody needs to
spend the time finding and implementing a solution for this problem.

Cheers
___
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

[Bastien Nocera]

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

Re: Relicensing Nautilus to GPLv3+

[Bastien Nocera]

On Tue, 2017-07-18 at 07:56 +0200, Alexandre Franke wrote:
> On Mon, Jul 17, 2017 at 10:23 PM, Carlos Soriano via
> desktop-devel-list  wrote:
> > This is done now in
> > https://git.gnome.org/browse/nautilus/commit/?id=365ec7f7ac1cec51dc
> > 0248dd05b17cb78252a788
> 
> I don’t think that’s sufficient though. Putting a LICENSE file in the
> project directory just addresses the “You should have received a
> copy”
> provision, but doesn’t effectively place the code under that license.
> You could even have several license files if parts of your project
> are
> under different licenses.
> 
> That license file you put in your repository also states that you
> should attach a notice to the program. It can take several form but
> the recommended one is in the header of your source. In fact, there
> is
> already such a notice and it claims that the software is GPLv2+
> (https://git.gnome.org/browse/nautilus/tree/src/nautilus-main.c?id=36
> 5ec7f7ac1cec51dc0248dd05b17cb78252a788).

That's fine. The license of the compound work just has to be compatible
with the individual files' licenses, it doesn't need to be the exact
same one.

For example, you can have a project mixing GPLv2+, GPLv3+ and BSD
licensed files, and choose to have the compound work be GPLv3+. That
also tells contributors that any new files in the project should be
compatible with that overall license.

> This brings us to another point: do you intend to use GPLv3 or
> GPLv3+?
> The notice should be explicit about it (again, as suggested by the
> license you copied to your project).
> 
> Cheers,
> 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Bastien Nocera]

On Thu, 2017-05-25 at 12:08 +0200, Sébastien Wilmet wrote:
> On Thu, May 25, 2017 at 05:59:02AM -0400, Carlos Soriano wrote:
> > For now we won't relicense the files, since that would require
> > copyright holders to agree (iiuc). Instead is the project that will
> > become GPL3+, since the combination of GPL2+ + GPL3+ files results
> > in
> > a project that is GPL3+.
> 
> For the files licensed as GPLv2+, the copyright holders have already
> agreed with "any later version", so you can directly relicense to
> GPLv3+
> without asking the permission to each copyright holder.
> 
> For LGPL -> GPL, you need the explicit approval of all copyright
> holders.

No, you don't. It says right in the license that you can use LGPL
sources as GPL if you so wish:
"you may convey a copy of the modified version [...] under the GNU GPL,
with none of the additional permissions of this License applicable to
that copy."

Meaning that you can strip the additional permissions in the LGPL to
make it GPL without asking anyone.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

On Mon, 2017-05-22 at 11:50 +0100, Philip Withnall wrote:
> I would also be supportive of a solution using Phabricator+cgit. Phab
> for task management and patch review, since its task management is
> more
> powerful than gitlab’s, and its patch review workflow doesn’t have
> the
> problems of gitlab’s branch-and-merge approach (its inter-diff
> reviews
> are great). cgit for viewing the repositories, as normal.

I was given examples of inter-diff views in a deployed gitlab instance
(framagit), and it seems to work pretty well.

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

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

On Tue, 2017-05-23 at 11:21 +0200, Felipe Borges wrote:
> 

> +1: I am supportive of the initiative.
> 
> After catching up with the discussion, my personal pros and cons are:
> 
> Pros:
> 
> - code browsing is better than cgit

Seeing the history of a single file is unfortunately much harder than
in cgit.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Porting applications to meson

[Bastien Nocera]

On Mon, 2017-05-22 at 21:29 +0200, Iñigo Martínez wrote:
> Hi,
> 
> I have been using meson for some months now at work, and I've taken
> advantage of what I learned to port some applications' build systems
> to it (gnome-todo[0], bijiben[1] and gnome-calendar[2]). While I'm
> waiting for those patches to be reviewed, I could also help on
> porting
> other applications' build systems too, although there is some work in
> progress[3][4] and I would rather not start working on any random
> application duplicating someone else's work.
> 
> Is there any application that no one is working on and that it would
> be interesting to port it to meson?
> 
> Please, do not hesitate to contact me. I can try my best :)

If you're interested, a non-trivial application would be totem. It has
optional Python and Vala deps, an external API to port to the newer
gtk-doc, etc.

Porting any libraries in its dependency chain would also be helpful.

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

Re: Possible broken parser for slideshow background xml

[Bastien Nocera]

On Sat, 2017-05-20 at 22:36 -0700, Luya Tshimbalanga wrote:
> Hello,
> 
> 

> Somehow, the starting image from the transition display a blank
> instead
> as demonstrated by the screencast below:
> https://luya.fedorapeople.org/videos/Screencast%20from%2020-05-17%201
> 0:32:45%20PM.webm

I didn't watch the video. If it happens in gnome-shell, this background
code was reimplemented in gnome-shell itself, so the bug would be
there.

There's the reference/original implementation in gnome-desktop, used by
old versions of GNOME, and various third-parties.

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

Re: Relicensing Nautilus to GPLv3+

[Bastien Nocera]

On Thu, 2017-05-18 at 15:47 -0400, Carlos Soriano wrote:
> Maybe I didn't explain well. Emilio points out there could one one of
> those extensions that say GPL2+ to link to a GPL2-only library. But
> that would make the extension itself GPL2 anyway, and it's License
> file would have to reflect that initially.

Again, it wouldn't. The combined work would be GPLv2-only, but each one
of the items keeps its own license. The licenses are compatible.

You don't have to have an piece of code depending on the exact same
version of the license if those licenses are compatible. GPLv2-only is
compatible with GPLv2+, as the license mentions for that dependency
says:
"either version 2 of the License, or (at your option) any later
version."

The selection is "made" automatically when you run those 2 items in the
same memory address space (eg. when you "link" them).

> It's just a hipotetical case, I checked the extensions dependencies
> in a quick look and look fine (>= GPL+2).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Bastien Nocera]

On Thu, 2017-05-18 at 13:50 -0400, Carlos Soriano via desktop-devel-
list wrote:
> Wouldn't that make the actual extension GPL2-but-not-GPL3 comaptible
> since the start, and therefore cannot be GPL2+ project and therefore
> its License file would need to reflect that?

No. nautilus' license says "GPLv2 or later". The extension's license
says "GPLv2 only".

When you combine both licenses into the final product/memory address
space (the "linking" mentioned in the GPL license) you end up with a
"combined work" license of GPLv2.

So it was compatible, but wouldn't be any more.

As mentioned on IRC, I think that the original intent of using the LGPL
for the libnautilus-extensions library was to allow non-GPL-compatible
extensions to link into nautilus, at will. It's not like you could link
to the extensions library without also eventually linking to nautilus
itself...

If that were the case, and that might require some digging to talk to
the original authors, then you might be able to mention this in the
extensions document that was recently (and erroneously) removed.

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

gnome-settings-daemon/gnome-control-center under new ownership

[Bastien Nocera]

Hey,

At GUADEC 2010, Matthias asked Richard Hughes and I to help with gnome-
control-center's port to GTK+ 3.x and update all the panels to the new
control-center shell that Jon McCann had been polishing.

Skip forward 7 years later, and I'm mostly doing patch reviews for
features and redesigns done by others, along with being the person that
rejects adding new options.

I'm writing this mail because I want to be able to focus on writing
code again, implementing new features desktop-wide such as integrating
OOM handling into the desktop, porting our session handling to systemd,
dealing with kernel bugs and, finally, spending some time on my old
friend Videos.

Rui will be taking over handling of day-to-day operations for gnome-
control-center and gnome-settings-daemon. I'll still be around to
handle bugs in my own area of expertise (such as the Bluetooth panel or
the fingerprint integration).

If you have long-standing bugs still opened because the maintainer got
jaded, or because your patches didn't get reviewed, please connect with
Rui to get a fresh look.

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

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

Hey,

On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri,
> Emmanuele Bassi and myself.]
> 
> Please bear in mind that this is just a recommendation! We are not
> claiming to have complete knowledge and we would like to hear
> questions and comments. At the same time, we do ask that members of
> the community approach this proposal with an open mind: please read
> the wiki pages and try to resist making assumptions about GitLab
> without familiarising yourself with it.

I've now read through the documentation, and annotated my early
thoughts on the migration.

- Keep bugzilla URLs working, along with history
  This is very important for code history purposes, and has been
mentioned as an explicit goal at:
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/#Migration_Possibilities

- Keep cgit URLs working
  Again, important for code history purposes. We often link to those in
bug reports and commit messages. This could probably be achieved
through redirections rather than keeping the cgit instance alive

- Keep git URLs working
  While not a problem for developers (you'd change your gitconfig and
update jhbuild, and done, mostly), it has the potential to break a lot
of flatpaks, possibly also upstream packaging. I know something similar
was done in the Fedora package repos when they migrated, so maybe it's
possible?

- Component bug assignment: g-c-c/g-s-d or gnome-documents/gnome-books
  This is probably the most important one for bug handling. Otherwise
managing bugs for g-c-c and g-s-d, the different components of which
require a lot of domain-specific knowledge, would be terribly unwieldy.

- Equivalent to NEEDINFO?
  This status was pretty important in terms of bug triaging, as the
reporter was allowed to remove that flag when they were done providing
the information, removing the burden from the bug triager to monitor
the bug. Is there an equivalent?

- Cross-module issue searching?
  Again, quite useful in terms of bug triaging, allowing to find a
"root cause" bug, possibly assigned to a different component than the
top level application. For example, a crash in Videos could be in about
7 different modules, being able to search the whole instance would be
useful.

- Mail for own replies (a-la bugzilla)
  - This is also a useful tool for bug triaging, as all the comments
end up in my Bugzilla folder, and I can search through them. I'm
guessing/hoping it's possible.

- Handling of private bugs?
  Bugzilla has the ability to create private bugs, for security and
community feedback management purposes. Does GitLab allow that?

- Bugzilla yearly reports
  Is there some statistics tool builtin to GitLab?

- Bugzilla points
  Will they be migrated? :)

Overall, the migration is a good idea, especially the ability to report
bugs and contribute without a GNOME specific account. I hope the
information about how different teams and bugzilla triagers use
Bugzilla, in particular, was of interest.

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

Re: Relicensing Nautilus to GPLv3+

[Bastien Nocera]

On Wed, 2017-05-17 at 11:13 -0400, Carlos Soriano wrote:
> There are few by error.
> The important cases are lineup-parameters used for uncrustify, and
> the threatics part from gnome-builder.
> However, we already spent time on implementing our own thing in the
> past with git-archive-all (GPLv3+) when meson couldn't handle it, so
> I would like to prevent this from happening again and avoid us the
> work with asking few upstreams to relicense based on our needs, and
> rather switch to GPL3+ where most of the tools are.

I don't understand what git-archive-all has to do with this. Is the
problem that some of the tools you ship are GPLv3? That doesn't mean
the rest of the module has to be...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Bastien Nocera]

On Wed, 2017-05-17 at 09:45 -0500, Michael Catanzaro wrote:
> On Wed, May 17, 2017 at 9:20 AM, Bastien Nocera <had...@hadess.net> 
> wrote:
> > If nautilus is GPLv3+, that means we can't link it against GPLv2-
> > only
> > or LGPLv2-only libraries in the extensions. I'm also not opening
> > the
> > can of worms that is non-GPL-compatible dependencies of extensions
> > (such as proprietary, or patent-encumbered GStreamer plugins),
> > because
> > that's an existing problem.
> > 
> > What's the end goal for relicensing? What problems do the current
> > license cause that require a relicense?
> > 
> > Cheers
> 
> Sounds like the license is already GPLv3+, since it uses GPLv3+
> source 
> files, and the existing GPLv2+ notices are incorrect or misleading.

Were those licenses applied in error, or imported from projects that
were GPLv3 themselves?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Relicensing Nautilus to GPLv3+

[Bastien Nocera]

On Wed, 2017-05-17 at 17:01 +0300, Ernestas Kulik wrote:
> (Attempt no. 2, since Geary hates me)
> 
> Hi,
> 
> As the current licensing situation in Nautilus is quite complicated,
> I
> and Carlos are planning a move to relicense the entire codebase to
> GPLv3+.
> 
> The codebase has files under several licenses: LGPLv2+, GPLv2+ and
> GPLv3+, the latter implicitly making the project be licensed under
> its
> terms, so our options are quite limited here.
> 
> The situation wrt extensions is also not entirely clear, as the
> extension library is LGPLv2+ with Nautilus being GPLv2+, which in
> turn
> disallows loading non-free extensions. Given the fact that it is not
> meant to be a generic mechanism for loading extensions, I feel like
> relicensing it without much consideration is reasonable.

If nautilus is GPLv3+, that means we can't link it against GPLv2-only
or LGPLv2-only libraries in the extensions. I'm also not opening the
can of worms that is non-GPL-compatible dependencies of extensions
(such as proprietary, or patent-encumbered GStreamer plugins), because
that's an existing problem.

What's the end goal for relicensing? What problems do the current
license cause that require a relicense?

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

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote:
> On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote:
> > >  Original Message 
> > > Subject: Re: Proposal to deploy GitLab on gnome.org
> > > Local Time: May 17, 2017 2:10 PM
> > > UTC Time: May 17, 2017 12:10 PM
> > > From: had...@hadess.net
> > > To: Carlos Soriano <csori...@protonmail.com>
> > > desktop-devel-list@gnome.org <desktop-devel-list@gnome.org>
> > > 
> > > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-
> > > devel-
> > > list wrote:
> > > > Hey Bastien,
> > > > 
> > > > Not sure if you read the wiki and the workflow we outlined in
> > > 
> > > there,
> > > > since we mention how this works. You will realize that's not
> > > > necessary for you, neither a git-bz alternative since you will
> > > 
> > > use
> > > > just git:
> > > > - git-bz apply equals to git checkout remoteBranch
> > > 
> > > No, it doesn't. git-bz apply on a master or version branch will
> > > allow
> > > me to amend commits. It does everything but push. The above
> > > doesn't
> > > allow me to apply the same set of patches to a development and a
> > > stable
> > > branch for example.
> > 
> > Doesn't git rebase do precisely this?
> 
> I don't quite understand the workflow for users to create merge
> requests with patches added, compared to my experiences with GitHub
> for
> example, so bear with me.
> 
> If I'm a registered developer for the GNOME org, or that particular
> module, I'd create my merge requests as wip branches in the main
> repo?Or as branches in a separate repo that I have the control of?
> 
> What about developers that don't have GNOME commit access? Do they
> fork, play in their corners and then create a merge request? Does
> that
> merge request automatically create a branch in the upstream repo? How
> do we stop merge request spam, or the unbounded growth of the repo
> with
> all the wip branches, if that's the case?

The workflow page is hidden inside the conclusion on the original page
that was posted:
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabWorkflows

So it's unbounded growth as the merge request branches are created in
the upstream repo.


> Do you have a link to the tool and its documentation? There's nothing
> in the Wiki linking to it, it just says "a tool exists".

The tool is also linked from that page:
https://github.com/NARKOZ/gitlab/

FWIW, we should get to a point where I don't need to open my browser to
manage a merge request. I do this quite often directly from my bug mail
to the terminal, copying the bug URL and appending it to git-bz. I
don't think that anything else should be required, and most of it
should be automated.

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

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote:
> >  Original Message 
> > Subject: Re: Proposal to deploy GitLab on gnome.org
> > Local Time: May 17, 2017 2:10 PM
> > UTC Time: May 17, 2017 12:10 PM
> > From: had...@hadess.net
> > To: Carlos Soriano 
> > desktop-devel-list@gnome.org 
> > 
> > On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-
> > devel-
> > list wrote:
> > > Hey Bastien,
> > > 
> > > Not sure if you read the wiki and the workflow we outlined in
> > there,
> > > since we mention how this works. You will realize that's not
> > > necessary for you, neither a git-bz alternative since you will
> > use
> > > just git:
> > > - git-bz apply equals to git checkout remoteBranch
> > 
> > No, it doesn't. git-bz apply on a master or version branch will
> > allow
> > me to amend commits. It does everything but push. The above doesn't
> > allow me to apply the same set of patches to a development and a
> > stable
> > branch for example.
> 
> Doesn't git rebase do precisely this?

I don't quite understand the workflow for users to create merge
requests with patches added, compared to my experiences with GitHub for
example, so bear with me.

If I'm a registered developer for the GNOME org, or that particular
module, I'd create my merge requests as wip branches in the main
repo?Or as branches in a separate repo that I have the control of?

What about developers that don't have GNOME commit access? Do they
fork, play in their corners and then create a merge request? Does that
merge request automatically create a branch in the upstream repo? How
do we stop merge request spam, or the unbounded growth of the repo with
all the wip branches, if that's the case?

> > > - git-bz attach equals to git push origin HEAD:fix2340issue, then
> > > click create merge request.
> > 
> > Does this rewrite the commit message to include the PR or bug
> > number?
> 
> No, as written in the wiki you write "Closes: $number" and it will
> handle things automatically.
> Of course some addition could be done to do the rewrite.

Right, so that's not automated, and you can't know what to put in the
commit messages until you've create the merge request. Kind of a
chicken and egg problem.

> > Do we end up with separate merge requests and bug numbers,
> > segregating
> > users and developers? And yes, clicking a button is a problem when
> 
> Yes. They are different concepts in this tool, which I though it was
> an improvement. The bug is more about the discussion of what is
> wanted/motivation/reasoning/design/etc., the merge request is about
> pure code.
> Not sure I would frame it as segregating users and developers though.

As Jehan mentions, it is. Users filing bugs look at open issues, most
of the time, but don't look at merge requests at all.

> > "git-bz file" took care of all the clicky stuff on the command-
> > line.
> 
> Right, that can be improved.
> 
> > > And since you will have access to all projects...not need for
> > your
> > > own repo.
> > > 
> > > Do you mean you don't like the extra step that is clicking once
> > per
> > > issue the "create merge request" button?
> > 
> > I don't like the fact that the bug report and the merge request are
> > separate.
> > 
> > > If that's the case, why is the command line tool we mention in
> > the
> > > wiki not good for you? (you will need some alias for adapting it
> > to
> > > your needs, or maybe we can modify to make the "create merge
> > request"
> > > more comprehensible?)
> > 
> > The only mention of a command-line tool says:
> > "There is a CLI tool which allows a wide range of actions to be
> > done
> > from the command line, although it isn't particularly user
> > friendly."
> > which is a bit low on details to allow me to comment on it.
> 
> It's rather vague, I agree. But you can explore it yourself, the
> readme of the project is quite explanation. But I'm afraid is not up
> to the expectations you have as it is right now. Would be good to
> improve this of course.

Do you have a link to the tool and its documentation? There's nothing
in the Wiki linking to it, it just says "a tool exists".
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-devel-
list wrote:
> Hey Bastien,
> 
> Not sure if you read the wiki and the workflow we outlined in there,
> since we mention how this works. You will realize that's not
> necessary for you, neither a git-bz alternative since you will use
> just git:
> - git-bz apply equals to git checkout remoteBranch

No, it doesn't. git-bz apply on a master or version branch will allow
me to amend commits. It does everything but push. The above doesn't
allow me to apply the same set of patches to a development and a stable
branch for example.

> - git-bz attach equals to git push origin HEAD:fix2340issue, then
> click create merge request.

Does this rewrite the commit message to include the PR or bug number?
Do we end up with separate merge requests and bug numbers, segregating
users and developers? And yes, clicking a button is a problem when
"git-bz file" took care of all the clicky stuff on the command-line.

> And since you will have access to all projects...not need for your
> own repo.
> 
> Do you mean you don't like the extra step that is clicking once per
> issue the "create merge request" button?

I don't like the fact that the bug report and the merge request are
separate.

> If that's the case, why is the command line tool we mention in the
> wiki not good for you? (you will need some alias for adapting it to
> your needs, or maybe we can modify to make the "create merge request"
> more comprehensible?)

The only mention of a command-line tool says:
"There is a CLI tool which allows a wide range of actions to be done
from the command line, although it isn't particularly user friendly."
which is a bit low on details to allow me to comment on it.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal to deploy GitLab on gnome.org

[Bastien Nocera]

On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
> 

> Most developers are more familiar with the GitHub workflow, I think
> it's
> an easier workflow than attaching a patch to a bugtracker ticket.
> Once
> the contributor has pushed a branch on the fork repo, all the rest
> can
> be done from the web interface by clicking on some buttons.

I absolutely hate this workflow, fwiw. I prefer being able to run "git-
bz" to both create and apply patches, rather than keeping a clone with
a bunch of patches in my own org, or remembering the commands to push a
repo to my own repo from the upstream clone.

I hope there will be a git-bz equivalent available.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [gnome-terminal/vte] What about to add an action to "Select All and Copy"?

[Bastien Nocera]

On Sat, 2017-05-13 at 13:29 +, Debarshi Ray wrote:
> Hey,
> 
> On Tue, May 09, 2017 at 01:08:24PM +0800, xiaofeng wrote:
> > When I use the "Select All" action, the next step is always being
> > "Copy",
> > what about your next step? If that's the most case, what about to
> > add an
> > action to bind "Select All" and "Copy"?
> 
> I am quite used to doing ctrl+a ctrl+c to "select all" and "copy to
> clipboard" in other applications. Maybe we need an accelerator for
> "select all"? I don't know. I don't have the final say in this
> matter. :)

There used to be an accelerator:
https://bugzilla.gnome.org/show_bug.cgi?id=86119

Not sure where it disappeared, but I don't remember ever being able to
use it from the keyboard.

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

Re: Paperwork : a personal document manager (scanned and PDFs)

[Bastien Nocera]

On Tue, 2017-05-02 at 15:56 +, jfle...@gmail.com wrote:
> 

> It makes sense.
> Since simple-scan is written in vala/C and Paperwork in Python 3, I
> guess any common ground would have to be written in C/GObject. It's
> going to take time ... Not sure if I will ever enough free time to do
> everything I would like to :-)

I'm guessing that you would at least need some C code to interact with
SANE, so making simple-scan's base functionality available through
gobject introspection would make it available to you in Python, and in
other languages with introspection support, so there's always that.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Paperwork : a personal document manager (scanned and PDFs)

[Bastien Nocera]

Hey,

On Tue, 2017-05-02 at 12:54 +, jfle...@gmail.com wrote:
> First of all, I want to thank you all for your comments and
> feedbacks. I wasn't really expecting such a nice welcome :-)
> 
> Regarding the HIG, you can actually also thank Mathieu Jourdan ( http
> s://github.com/mjourdan ). He has been providing me with awesome
> mockups.
> 
> 
> Regarding the goals, I think we can agree it would be best to keep
> Gnome documents, simple-scan and Paperwork separated, at least for
> now:
> 
> - Simple-scan: For me, the way I see it, it's more of a general scan
> application. It can do wonder, but my understanding is that it's not
> intended as a document manager. For instance, I used it to scan this
> drawing : https://cloud.githubusercontent.com/assets/135331/22778343/
> e449f9c2-eeb6-11e6-9edc-ece6f372d147.png . Scanning it with Gnome
> Documents or Paperwork wouldn't have make sense.
> - Gnome Documents: Correct me if I'm wrong, but it seems mostly
> focused at electronics documents (.odt, .pdf, etc).
> - Paperwork: As stated previously, it has a very clear focus on paper
> documents. PDFs are mostly a side-effect so people don't have to
> switch between document managers all the time. It's also intended to
> let the users do as little as possible .. and some people just don't
> want that (I got a bunch of tickets over time regarding putting
> titles on documents ...). So, while its goal may overlap Gnome
> Documents, I don't think one size fits all here.

If I could give you a piece of advice, it would be to try and share the
maximum amount of code with simple-scan and what would become the
GNOME-ified version of it. That is, start by hacking on simple-scan for
all the "simpler" stuff, making sure to split off the bits you want to
reuse, like the scanning, calibrating, and cropping UI, the OCR
support, and the system-wide configuration, if that happens.

In the longer term, that would mean that you would get more people
working on this portion of the code, so more eyeballs, maintenance, and
features "for free" for your application. I could also see this part as
very interesting to integrate into other GNOME-ish applications, such
as the GIMP, or Inkscape, in the longer term.

OCRFeeder is also another project that you could be interested in
looking at, it's an OCR application for GNOME, though it's not in the
"highly maintained" category.

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

Re: For projects switching to Meson *only*

[Bastien Nocera]

On Sat, 2017-04-29 at 12:06 -0500, mcatanz...@gnome.org wrote:
> On Sat, Apr 29, 2017 at 7:45 AM, Bastien Nocera <had...@hadess.net> 
> wrote:
> > Are you saying you reverted jhbuild module changes, without
> > notifying
> > the committer, because there's a problem with the grilo/grilo-
> > plugins
> > handling,
> 
> I did notify the committer (Javier).
> 
> >  but you didn't file a bug against those modules?
> 
> Due to the large number of build failures we have to deal with when 
> releasing, I normally only file bugs on release day if I can't get
> the 
> modules to build at all.

I filed:
https://bugzilla.gnome.org/show_bug.cgi?id=782055
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Bastien Nocera]

On Fri, 2017-04-28 at 10:19 -0500, mcatanz...@gnome.org wrote:
> On Fri, Apr 28, 2017 at 4:40 AM, Bastien Nocera <had...@hadess.net> 
> wrote:
> > On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote:
> > >  On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer
> > >  <peter.hutte...@who-t.net> wrote:
> > >  > I will, but I'll keep the two parallel for at least a release
> > > or
> > >  > two.
> > >  > If you
> > >  > need me to add anything specific to keep continuous happy for
> > > the
> > >  > time
> > >  > being, let me know.
> > >  >
> > >  > Cheers,
> > >  >Peter
> > > 
> > >  Here's a request for maintainers who are supporting both meson
> > > and
> > >  Autotools: please consider adding the meson build files to your
> > >  release
> > >  tarballs (add them to EXTRA_DIST) if you want people to actually
> > > use
> > >  the meson build system. You don't have to, but it'd be nice.
> > > 
> > >  For people helping maintain the jhbuild modulesets, please do
> > > not
> > >  switch modules to use meson until the meson build files have
> > >  appeared
> > >  in a release tarball, or you're confident they will appear in
> > > the
> > >  next
> > >  tarball. (Unless Autotools support has already been dropped, in
> > >  which
> > >  case maintainers, please follow the GNOME release cycle in
> > > making
> > >  your
> > >  next release!) This will reduce the amount of manual hacking
> > >  required
> > >  to produce release modulesets that actually build. I've
> > > temporarily
> > >  switched GStreamer and Grilo back to using Autotools for this 
> > > reason.
> > 
> > What was the problem with Grilo's meson support?
> > 
> > We have a bug opened for a regression with the 0.4.0 version, but
> > the
> > meson build works as expected in jhbuild.
> > 
> > Cheers
> 
> Problem with grilo is there are no meson build files in the latest 
> release tarballs, and the modulesets need to work when converted to 
> tarballs for our release process.

Are you saying you reverted jhbuild module changes, without notifying
the committer, because there's a problem with the grilo/grilo-plugins
handling, but you didn't file a bug against those modules?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: For projects switching to Meson *only*

[Bastien Nocera]

On Fri, 2017-04-28 at 00:37 -0500, mcatanz...@gnome.org wrote:
> On Thu, Apr 27, 2017 at 7:00 PM, Peter Hutterer 
>  wrote:
> > I will, but I'll keep the two parallel for at least a release or
> > two. 
> > If you
> > need me to add anything specific to keep continuous happy for the
> > time
> > being, let me know.
> > 
> > Cheers,
> >    Peter
> 
> Here's a request for maintainers who are supporting both meson and 
> Autotools: please consider adding the meson build files to your
> release 
> tarballs (add them to EXTRA_DIST) if you want people to actually use 
> the meson build system. You don't have to, but it'd be nice.
> 
> For people helping maintain the jhbuild modulesets, please do not 
> switch modules to use meson until the meson build files have
> appeared 
> in a release tarball, or you're confident they will appear in the
> next 
> tarball. (Unless Autotools support has already been dropped, in
> which 
> case maintainers, please follow the GNOME release cycle in making
> your 
> next release!) This will reduce the amount of manual hacking
> required 
> to produce release modulesets that actually build. I've temporarily 
> switched GStreamer and Grilo back to using Autotools for this reason.

What was the problem with Grilo's meson support?

We have a bug opened for a regression with the 0.4.0 version, but the
meson build works as expected in jhbuild.

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

Multimedia keys API regression in gnome-settings-daemon 3.24

[Bastien Nocera]

Hey,

After splitting up gnome-settings-daemon in small independent daemons
for the GNOME 3.24 release, making it more robust and easier to debug,
a regression was discovered in gnome-settings-daemon's multimedia keys
plugin, which handles, well, multimedia keys and offers up an API for
applications.

For around 6 years, the API implemented by the multimedia keys plugin
did not match the API documentation for it. A work-around was put in
place for GNOME 3.24, and a fix for both development and older versions
is available to make the implemented API match the documented one.

Forward compatibility for GNOME 3.22:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-22=12c92274bc118836d9c6dcb5262b82536ef2fe58

Work-around for GNOME 3.24:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-24=42f75ed4cdc86498d6e02e511a1314b8916bd4aa

Fix for GNOME 3.26:
https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=33d47e655606ac88ed7d529c1132e5be6299633b

The downside of this is that applications will need to be modified to
use the D-Bus name as documented since 2011, rather than the cargo-
culted D-Bus name that was used.

The patches are small enough but they will be numerous.

Examples for totem:
https://bugzilla.gnome.org/show_bug.cgi?id=781589
and rhythmbox:
https://bugzilla.gnome.org/show_bug.cgi?id=781664

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

Re: GNOME Logo Licensing

[Bastien Nocera]

On Mon, 2017-03-13 at 12:43 +, Simon McVittie wrote:
> On Sun, 12 Mar 2017 at 00:52:25 +, Alberto Ruiz wrote:
> > There has been many instances of us protecting our brand by asking
> > people to
> > stop using our logo for commercial purposes, CC-BY-SA/LGPLv3 does
> > grant
> > precisely the right to use it commercially.
> 
> There are two things a third party needs to do to use the GNOME name
> and logo legally:
> 
> * Not infringe trademarks: they need to be either using them in a
>   way that is not protected by trademark law (for instance writing a
>   Wikipedia page about GNOME, or describing MATE/Cinnamon/etc. as
>   being based on GNOME), or using it in a way for which GNOME
>   specifically gives permission.
> 
> * Not infringe copyright: for the logo specifically, they need to be
>   allowed to copy it without infringing the copyright held by whoever
>   designed/made the logo. The GNOME *name* is far too short to be
>   protected by copyright, so this doesn't apply; so GNOME needs
>   (and has) a trademark policy covering at least the name, regardless
>   of what is done about the logo.
> 
> Briefly, copyright is about an author's right to control copying of
> their work (and potentially make money by selling permission to
> copy it). Trademarks are about a vendor's right to not have their
> reputation damaged by applying their name, logo, or other things
> that are recognised by consumers to an inferior product.
> 
> Open source software is unusual because the inferior product is
> often a modified version of the "real" product, rather than a
> reimplementation (for instance Mozilla has had a lot of trouble with
> third parties offering modified versions of Firefox that bundle
> or contain malware, but I'm not aware of anyone publishing things
> that were not based on Firefox at all and calling *those* Firefox);
> but trademarks, not copyright, are the right weapon against that.
> 
> I think what you need here is a trademark license that forbids what
> you want to forbid, in particular using the GNOME name or the GNOME
> logo to identify things that are not GNOME.
>  already
> provides this.
> 
> (Ab)using copyright licenses to do the job of trademarks typically
> leads to using copyright licenses that certainly don't meet the
> Open Source Definition (or similar definitions like the FSF's
> Free Software Definition and Debian's Debian Free Software
> Guidelines), and in many cases forbid perfectly reasonable forms
> of distribution altogether. This is how we got into the silly
> Firefox/Iceweasel situation, which has only recently been resolved
> (Mozilla's logos are now covered by a permissive copyright license
> but a much more restrictive trademark license).

That was what I would have said, if Simon didn't put it so eloquently.
So +1 for a permissive license for the artwork itself, we can control
its usage through the GNOME trademark.

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

Re: Improving the way we build nightly apps

[Bastien Nocera]

On Tue, 2017-02-28 at 11:44 -0500, Matthias Clasen wrote:
> So far, we have this gnome-nightly-apps repository which contains
> copies of the flatpak manifests for a bunch of gnome apps. That is
> redundant and suboptimal. Recently, flatpak has gained the ability to
> find manifests in git repositories that you point it to, and we
> should use this to move the json files to each applications git tree.
> Quite possibly there is already a copy of it there anyway.
> 
> If you want to help out with making this happen, the details are
> described here:
> 
> https://wiki.gnome.org/Initiatives/GnomeGoals/FlatpakManifests

My flatpak is too old to test. As totem has additional patches, and a
separate json file for lua, which one of these is correct:

JSON=org.gnome.Totem.json
GITURL=git://git.gnome.org/totem/flatpak

or

JSON=flatpak/org.gnome.Totem.json
GITURL=git://git.gnome.org/totem

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

Re: Sick day today

[Bastien Nocera]

On Wed, 2017-01-25 at 05:55 -0500, Carlos Soriano Sanchez wrote:
> Got down again

At least it's a sick note, not a rant like Behdad sent to the wrong
list ;)
___
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

[Bastien Nocera]

On Fri, 2017-01-06 at 01:23 +, Emmanuele Bassi wrote:
> I'd be very careful in framing this issue in absolute terms like
> you've been doing. For instance, I think you need to be explicit in
> saying you're speaking with your Fedora packager hat on.

Does it matter when, when pushed to master and released, it was broken
for every developer?

>  Personally, I have no problem in having people rely on pip, cpanm,
> npm, or cargo to get their software in order to build ours - just
> like I have no issues when people need autoconf-archive for a fancy
> m4 macro. I would not ask programmers that wish to add to our
> platform to bend over backwards and use tools that are not part of
> the common workflow of their community and platform in order to
> satisfy the requirements imposed by third parties like Linux
> distributions.
> 
> "It downloads third party software" is not a convincing rationale
> when we are pushing for things like Flatpak, or when we use things
> like SCSS to generate our CSS.

False equivalence?

And the current librsvg, downloading helper libraries from the
Internet, wouldn't even compile under Flatpak.

> Additionally, the fact that something that is commonly used by
> millions of developers around the world is "unacceptable" to Linux
> distributions is what I was referring to as "routing around".
> Personally, I couldn't care less about the damage inflicted upon me
> by Linux distributors, so to me there is no problem to be solved at
> all - just a reality that should have long since been accepted, like
> bundling.

librsvg isn't some little library we put in the application bundle.
It's at the same level as gtk+ in the core desktop dependencies.

Saying that it's all a problem with the distribution workflow is a lack
of understanding about what this workflow tried to avoid and fix.
Downloading random shit from the internet as part of the build isn't
secure, isn't reproduceable, is difficult to debug and integrate.

I don't think it's too much to ask that librsvg is compilable offline.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: meson ground rules!

[Bastien Nocera]

On Tue, 2016-11-22 at 11:07 -0600, Michael Catanzaro wrote:
> Hi,
> 
> Some GNOME modules have started to experiment with switching to the
> meson build system instead of Autotools. Personally, I want to
> encourage this; even though as a project we haven't come to any
> consensus on whether we want to do a wholesale migration to meson, I
> think it's starting to look likely as its advantages over Autotools
> and
> CMake are pretty clear to me. But we still need to make sure it's
> easy
> for contributors to build GNOME. So a couple ground rules for this
> from
> release team:
> 
>  * Projects using meson are encouraged (although not required) to
> continue maintaining the Autotools build in parallel for GNOME 3.24
> as
> meson continues to mature. We will consider recommending the removal
> of
> Autotools builds in the GNOME 3.26 timeframe.
> 
>  * Projects that choose to remove the Autotools build system must not
> require meson newer than 0.34.0. We'll set a higher permissible
> version
> requirement for GNOME 3.26 next spring.
> 
>  * Make sure your module builds in JHBuild. Important: do not switch
> JHBuild to use the meson module type until you have released a
> tarball
> that includes the meson build system.
> 
>  * For GNOME 3.24, make sure your module builds in Continuous. You'll
> have to add a patch that adds a fake configure script and a fake
> Makefile. I do not believe this requirement is desirable going
> forward
> -- if we do a large scale switch to meson, then Continuous is just
> going to have to learn to grok our new build system -- but let's not
> break it now.

* Ditto for Flatpak nightly applications

> Thanks for helping make sure our release process goes smoothly,
> 
> Michael
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
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 ?

[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

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

[Bastien Nocera]

On Sat, 2016-11-12 at 16:07 -0500, Baptiste Saleil wrote:
> Again, I was never prentious enough to say that someone is stupid. I
> only talked about a feature that I, personally, find "stupid", I
> never talked about an actual person and I never would.

It's still not constructive.

> To go back to the original question, would you be so kind as to send
> me links to the design pages and blog posts you mentioned earlier ?

I already did link to one which you can use as a starting point.
___
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 ?

[Bastien Nocera]

On Sat, 2016-11-12 at 13:12 -0500, Baptiste Saleil wrote:
In passing, I'm not a native english speaker.Maybe you took
personally the "you" in my last sentence, it was a general "you"
meaning the users and not the developers. Maybe I should have said
"If one wants..."

Whether calling GNOME designers and developers stupid, or even Apple's
designers and developers stupid is not the level of discourse we
expect.

Neither of the people that answered your original mail are native
English speakers. We're not interested in non-constructive criticism
and calling things "stupid" doesn't elevate the level.

Fow what it's worth, apologising would likely have been easier and not
dragged this conversation any further. Alas...
___
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 ?

[Bastien Nocera]

Hello Baptiste,

On Sat, 2016-11-12 at 12:00 -0500, Baptiste Saleil wrote:
> Hi all.
> 
> File roller extract my archives in current directory by double click
> since 3.22
> Is this a bug or a feature ?
> 
> If it's a feature, is there a bug report or discussion I can track to
> understand why devs choose to make this change ?

It's not file-roller but nautilus, and the feature has been mentioned
in various blog posts, including this recap for GNOME 3.22:
https://csorianognome.wordpress.com/2016/08/31/nautilus-3-22-news-changes/

> IMHO, this is one of the most stupid features which is again probably
> copied from the full-of-stupid-features MacOS.

What exactly do you expect this sort of comment to achieve?

> I mean, if you really want to extract an archive in the current
> directory, there is the "Extract here" context menu entry, and it's
> literaly the same amount of clicks.

Looks like you have mismatched versions of file-roller and nautilus
though, because those 2 aren't supposed to appear at the same time.

Please make sure you've read the various blog posts and design wiki
pages before commenting further, especially using that kind of
language.

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

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Bastien Nocera]

On Thu, 2016-10-13 at 10:18 -0500, Michael Catanzaro wrote:
> On Thu, 2016-10-13 at 11:53 +0100, Sam Thursfield wrote:
> > Would a GNOME-goal to ensure that every project follows the Build
> > API
> > help
> > here?
> 
> 
> What do the meson developers think about the Build API?
> 
> I think I would not support such a goal. I do not want to add a
> boilerplate fake configure script to my project, nor a fake Makefile
> to
> a project that doesn't use make at all. I want to have fewer build
> system files to worry about, not more.

This "build API" is also what Flatpak expects. It's also baked in a
number of package build systems.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-settings-daemon now split up

[Bastien Nocera]

Hey,

gnome-settings-daemon 3.23.2 is now released. The major change is that
instead of launching a single big daemon, gnome-session will now launch
a number of smaller daemons.

Eventually, those daemons will be started as needed (through timers, or
D-Bus autostart) via systemd --user, as announced last cycle. For now,
the changes should be safe to deploy on Linux and non-Linux platforms.

Note that gnome-settings-daemon 3.23.2 requires gnome-session 3.23.2
and is incompatible with older releases. The GNOME Classic session file
has not been updated yet:
https://bugzilla.gnome.org/show_bug.cgi?id=772736

Cheers
___
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

[Bastien Nocera]

On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote:
>   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.

The email doesn't explain the most important part though. Why? Is it
faster, smaller, or better in other ways? Were other alternatives
considered (Meson,seems to be the preferred non-autotools build system
for GNOME projects)?

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

Re: GNOME 3.22.0 newstable tarballs due (and more) (responsible: mclasen)

[Bastien Nocera]

Great stuff, thanks!

> On 21 Sep 2016, at 21:21, Michael Catanzaro  wrote:
> 
>> On Tue, 2016-09-20 at 21:11 -0500, Michael Catanzaro wrote:
>> Matthias rebuilt the version set at least once today in order to pick
>> up stragglers. Not sure why your releases didn't get in; seems like
>> today's other releases didn't either. I'll let him answer.
> 
> Checking today, it did get in, yay! Looks like Matthias did another
> rebuild last night.
> 
> Michael
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.22.0 newstable tarballs due (and more) (responsible: mclasen)

[Bastien Nocera]

On Tue, 2016-09-20 at 19:06 -0500, Michael Catanzaro wrote:
> On Fri, 2016-09-16 at 00:00 +, Release Team wrote:
> > Hello all,
> > 
> > We would like to inform you about the following:
> > * GNOME 3.22.0 newstable tarballs due
> > * Hard Code Freeze ends
> 
> 
> Hi,
> 
> The following modules missed the Monday deadline and will be included
> in GNOME 3.22.0 with an unstable version number:
> 
> core: adwaita-icon-theme, at-spi2-atk, at-spi2-core, cheese, evince,
> gjs, glibmm, gnome-backgrounds, gnome-boxes, gnome-characters, gnome-
> control-center, gnome-logs, gnome-online-accounts, gnome-settings-
> daemon, gobject-introspection, gsettings-desktop-schemas, gtkmm,
> libsigc++, orca, sushi, vino, yelp
> 
> apps: bijiben, dconf-editor, gnome-chess, gnome-devel-docs, gnome-
> mahjongg, gnome-nibbles, gnome-sound-recorder, gnome-sudoku, gnome-
> taquin, gnome-tetravox, gnome-tweak-tool, iagno, quadrapassel, tali,
> vinagre
> 
> It's too many modules. Please maintainers, let's make 3.22.0 releases
> of these modules in time for 3.22.1 and let's do better for GNOME
> 3.24.
> If you need help releasing your module on time, please ask release
> team
> (or any GNOME maintainer). We don't mind helping with a few modules
> that would otherwise be late, but we can't handle this many.
> 
> The release deadline is always Monday. Tuesday is too late. If you
> can't do Monday, please do it over the weekend or on Friday instead.

I couldn't and I said so. To a release team member. We've always
figured out how to include stuff released on the Tuesday, why can't we
this time? Or maybe you need to change the schedule if Monday is bad
for so many people.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome "opt-in" functionality.

[Bastien Nocera]

On Fri, 2016-09-16 at 10:23 +0200, Daniel Mustieles García wrote:
> In Debian, 'apt-get remove --purge tracker' fixes the problem ;)

It fixes nothing. You just work around whatever problem is either
really happening on the system, or is one of those grand-mother tales,
carried around in forums.

Don't do that. Get bugs filed.

> 2016-09-15 23:22 GMT+02:00 Alvaro Kuolas :
> > Hello gnome developers and gnome team!
> > 
> > I am a gnome user since the year 2000 (Version 1.2 days).
> > 
> > I really like the Gnome Shell 3, it's UI and UX.
> > 
> > The only downside I found it is the software that I do not use,
> > but, cannot be "opt-out" and be left out of the installation.
> > 
> > Specifically, I do not use and do not want Tracker and Evolution.
> > 
> > Even more, they are very difficult to eliminate and disable. They
> > are using memory and resources that are wasted (even more on a
> > portable system).
> > 
> > They should be applications, that can be left out of the desktop,
> > and not "core" part of it.
> > 
> > It is possible to separate these parts or they are deeply embedded
> > in the system?
> > 
> > Best regards!
> > 
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
___
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

[Bastien Nocera]

On Mon, 2016-09-05 at 14:19 +0200, Michael Biebl wrote:

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

It was announced, and I requested comments about this, on May 12th 2016
in the "upcoming "systemd --user" dependency in gnome-settings-daemon"
thread on desktop-devel-list.

Other projects, GUADEC, holidays and sickness got in the way of me
merging this code before, but has it had already been discussed and
elicited few comments.


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

The horse has bolted on this one. gnome-settings-daemon's Sharing
plugin required a better way to keep track of the daemons it launched,
and using systemd --user as a baby-sitter process means that we don't
lose track of already launched daemons when gnome-settings-daemon
crashes, and reap them properly even when said g-s-d is abruptly closed
without cleanups.

Note that there are also plans to switch gnome-settings-daemon to be
mini-D-Bus services, which are likely going to be started through
"systemd --user", in the next development cycle.

Given that the Sharing plugin's functionality already required
NetworkManager, that NetworkManager is only available on Linux, and
that systemd is the de-facto init system for Linux OSes, this means we
only dropped support for non-systemd init systems. I'm fine with the
loss of support for non-systemd init systems, if it means more reliable
functionality (which has impacts on privacy and security).

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

Re: Maybe deprecating libgweather

[Bastien Nocera]

On Tue, 2016-08-30 at 17:33 +, Leslie S Satenstein wrote:
> I found that the Openweather extension maintained by  Jens Lody
> suited me better than the Gnome version. So much so that its the one
> I recommend to other Gnome users

What "GNOME version" are you talking about?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: upcoming "systemd --user" dependency in gnome-settings-daemon

[Bastien Nocera]

On Tue, 2016-08-30 at 13:05 +0200, Jens Georg wrote:
> > 
> > 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. later fixes) was included in some 
> previous release - do you also need the other two commits you pushed 
> today, then I can make another rygel beta release tonight with those
> two 
> included.

I don't think those are needed to test the changes on a "stock" GNOME
desktop, so the 2 additional patches can wait until you make a full
stable release.

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

Re: upcoming "systemd --user" dependency in gnome-settings-daemon

[Bastien Nocera]

On Thu, 2016-05-12 at 18:06 +0200, Bastien Nocera wrote:
> Hey,
> 
> "systemd --user" has been enabled in Fedora 24 beta, which will ship
> with GNOME 3.20. For GNOME 3.22, I'd like to make some changes in
> gnome-settings-daemon, first in the sharing plugin, then in gnome-
> settings-daemon itself.

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.

Cheers

PS: https://bugzilla.gnome.org/show_bug.cgi?id=766329 and dependencies
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Maybe deprecating libgweather

[Bastien Nocera]

On Tue, 2016-08-30 at 10:19 +0100, Allan Day wrote:
> Giovanni Campagna  wrote:
> ...
> > Any comments / opinions?
> > 
> 
> The dropdown list of search results that libgweather provides isn't
> great, so  +1 from me.

I've wanted libgweather to move to using geocode-glib for a while, so
this would be useful. But we'll still need an offline database for
those applications that don't need or can't use the network (gnome-
clocks, gnome-initial-setup and gnome-control-center I think)

This could be provided by geocode-glib though, meaning we could stop
relying on a weather library to provide locations. And we'll still need
a "drop-down" for those.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Flatpak build system, descriptions and questions

[Bastien Nocera]

On Fri, 2016-08-26 at 11:48 -0400, Shaun McCance wrote:
> On Fri, 2016-08-26 at 10:17 -0500, Michael Catanzaro wrote:
> > On Fri, 2016-08-26 at 10:29 -0400, Shaun McCance wrote:
> > > 
> > > Don't all maintainers already use signed tags for releases?
> > No. I used to do this, but stopped a couple years ago because it
> > was
> > pointless. Nobody should trust my key, so why use it?
> 
> IIRC, git.gnome.org won't let you push an unsigned tag.

Not sure whether we're talking about the same thing, but I never signed
any tags, or releases for GNOME.

>  I've been
> tagging releases since the days of CVS, because tags are useful. I
> thought everybody did.
> 
> That still leaves the question: If the release team tags with a key
> we
> can all trust, how does the release team trust that the commit they
> tagged is the one the maintainer intended?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Flatpak build system, descriptions and questions

[Bastien Nocera]

On Fri, 2016-08-26 at 09:43 +0200, Alexander Larsson wrote:
> On tor, 2016-08-25 at 17:29 +0100, Richard Hughes wrote:
> > On 25 August 2016 at 16:29, Alexander Larsson 
> > wrote:
> > > 
> > > However, it would
> > > make more sense for each individual application developers to
> > > maintain
> > > the manifest in the applications git repo.
> > I think this is a very good idea indeed; I was confused about the
> > "centralization" aspect of the builder files. Isn't this just some
> > globbing, if we all agree to put the manifest in the same place in
> > the
> > git tree?
> 
> Well, it was initially put in a separate git repo as we were just a
> few
> people trying to build a lot of apps, and that was the easiest way to
> get started. However, now that things are a bit more stable moving it
> to each individual repo makes sense.
> 
> There are some complexities though. There are two things we want to
> build, the "latest unstable" and the "last stable release". The
> obvious
> solution is to store a json file with a predictable name in master
> for
> the unstable release, and in the latest stable branch for the stable
> one.
> 
> However, how do we find which git repos have such json files, and how
> do we know what is the current latest stable branch? Also, its
> somewhat
> weird to clone the entire git repo just to get a json file that then
> itself may refer to the git repo.
> 
> Another issue is that we'd like the to have some control of what gets
> built, at least for the stable builds. Right now we just pull the
> gnome-apps-nightly repo and assumes it is correct (i.e nobody
> commited
> an attack to git or MITMed our connection to git.gnome.org), but from
> there everything is verified by sha256 on all the various tarballs
> that
> are downloaded. Getting even this level of verification is trickier
> when things are spread all across git.gnome.org. Ideally we should
> have
> some kind of gpg signatures for the stable commits so that we can
> verify everything from that, but we don't really have that kind of
> setup for gnome git.
> 
> Anyway, the best we can do now is i think having a git repo, say
> gnome-
> apps-nightly, that has two files in it, listing for each row:
> * A git repo
> * A branch name
> * The filename of the json manifest in the repo
> One of the files would be for unstable/nightly builds, and the other
> for stable builds.

You can replace all 3 of those items with a URL pointing to the file in
an https cgit.

2 problems with requiring GPG signatures for stable releases though:
- gnupg's "UI" sucks utterly
- we really should have had people signing each other's keys at GUADEC
when face to face
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver: Up for grabs?

[Bastien Nocera]

On Wed, 2016-07-27 at 16:55 +0300, Alberts Muktupāvels wrote:
> For long time I already want/plan to merge gnome-screensaver into
> gnome-flashback. It will give more freedom to make needed changes
> without affecting any other users and/or sessions that still use
> gnome-screensaver. So I guess I can say that we are not interested in
> GNOME Screensaver as standalone module.

It is already closed for entering new bugs. It should probably have
been moved to the attic as well, but that wasn't done at the time.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver: Up for grabs?

[Bastien Nocera]

On Thu, 2016-07-21 at 14:12 +0100, Emmanuele Bassi wrote:
> Hi;
> 
> On 21 July 2016 at 13:42, Ikey Doherty 
> wrote:
> > So Jeremy Bicha kindly contacted me the other day to express
> > concern
> > with Budgie/GNOME Screensaver. I had been toying with the notion of
> > forking GNOME Screensaver due to its deadness, and making it work
> > better for Budgie/Modern GNOME integration.
> > 
> > Jeremy correctly pointed out it might be worth maintaining the
> > project instead, which I'm up for.
> 
> AFAIR, gnome-screensaver is part of the "Flashback" session:
> 
> https://wiki.gnome.org/Projects/GnomeFlashback
> 
> given that it uses Metacity.

I don't know how well that works, or whether they've replaced gnome-
screensaver and gnome-settings-daemon yet. I refused to add hacks to
gnome-settings-daemon to make it work under GNOME Flashback as there
were just too many things that wouldn't work properly with it.

I think a fork/rename would be the best option to avoid confusion in
the bug tracker. Given the number of time I have to reassign bugs about
the desktop file manager window to nautilus from gnome-desktop, it
would probably be best if bugs weren't stuck there.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver: Up for grabs?

[Bastien Nocera]

On Thu, 2016-07-21 at 14:20 +0100, Ikey Doherty wrote:
> 
> On 21/07/16 14:03, Bastien Nocera wrote:
> > On Thu, 2016-07-21 at 13:42 +0100, Ikey Doherty wrote:
> > > Hi all,
> > > 
> > > So Jeremy Bicha kindly contacted me the other day to express
> > > concern
> > > with Budgie/GNOME Screensaver. I had been toying with the notion
> > > of
> > > forking GNOME Screensaver due to its deadness, and making it work
> > > better for Budgie/Modern GNOME integration.
> > > 
> > > Jeremy correctly pointed out it might be worth maintaining the
> > > project instead, which I'm up for.
> > 
> > You should really rename it. The gnome-screensaver product in
> > Bugzilla
> > is closed, so that screensaver related bugs don't end up there even
> > though we (GNOME) don't use it anymore.
> > 
> > gnome-flashback-screensaver, if gnome-flashback folks want to use
> > it,
> > would be fine. Otherwise, a completely different name would be
> > better.
> 
> Interesting. So up or down a fork is the only way to go here? If so
> perhaps the burden on GNOME would be less if this was done
> externally,
> given the project is entirely closed within GNOME now.

Not so much a fork as a name change. You can keep all the git history,
which will probably prove useful in the longer term. It would probably
be fine to keep it in the GNOME git as well.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver: Up for grabs?

[Bastien Nocera]

On Thu, 2016-07-21 at 13:42 +0100, Ikey Doherty wrote:
> Hi all,
> 
> So Jeremy Bicha kindly contacted me the other day to express concern
> with Budgie/GNOME Screensaver. I had been toying with the notion of
> forking GNOME Screensaver due to its deadness, and making it work
> better for Budgie/Modern GNOME integration.
> 
> Jeremy correctly pointed out it might be worth maintaining the
> project instead, which I'm up for.

You should really rename it. The gnome-screensaver product in Bugzilla
is closed, so that screensaver related bugs don't end up there even
though we (GNOME) don't use it anymore.

gnome-flashback-screensaver, if gnome-flashback folks want to use it,
would be fine. Otherwise, a completely different name would be better.

You can then rename pages like:
https://wiki.gnome.org/Projects/GnomeScreensaver
in the Wiki.

See also:
https://bugzilla.gnome.org/show_bug.cgi?id=735123

And you can see an example canned closure message, which we used after
triaging the bugs that might still affect GNOME:
https://bugzilla.gnome.org/show_bug.cgi?id=648567

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

Re: Multi DPI user interface

[Bastien Nocera]

On Tue, 2016-07-19 at 23:23 +0800, Jonas Ådahl wrote:
> 

> Well, 3 options with the other one being to have "A" and "B" content
> be
> placed in individual files, i.e. Screenshot - 2016-07-19 - 12:34 -
> LVDS1.png and Screenshot - 2016-07-19 - 12:34 - HDMI1.png, each one
> with
> their correct resolution

As Christian mentioned, the 4th option is to pass on that data on "raw"
(along with metadata such as the scaling factor), and let the "front-
ends" deal with it.

For gnome-settings-daemon's screenshot functionality, we'd probably
stitch the screenshots together either as per option #1 or #2 but more
involved screenshotting tools could offer different options.

In short, don't bake the end-user application design choices into the
API for this.

On that note, relying on the cursor position is as bad an idea as it
ever was with touchscreens, or for when we implement the "presentation"
screen mode (which is inaccessible for anything but display).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Multi DPI user interface

[Bastien Nocera]

On Tue, 2016-07-19 at 23:03 +0800, Jonas Ådahl wrote:
> Hi,
> 
> Over at mutter we've been working towards supporting proper multi DPI
> setups when running GNOME using Wayland. Proper multi DPI means to
> support having multiple monitors where two or more monitors have
> significantly different DPI but applications showing correctly on
> both
> monitors at all times.
> 
> Apart from making mutter, gnome-shell and gtk+ draw things correctly,
> supporting proper multi DPI has some implications on things touching
> more than just Wayland backends here and there; more specifically
> screen
> shooting and screen casting.
> 
> Until soon, gnome-shell have always drawn the content of all the
> monitors into one large framebuffer. This framebuffer was then used
> as a
> source for screen casting and screen shots; monitors with different
> scales were still simply regions of this framebuffers where windows
> were
> enlarged. Soon mutter/gnome-shell will be able to draw each monitor
> onto
> separate framebuffers; in the future, these framebuffers may have
> different scales, i.e. there will be no way to create an exact
> representation of what is currently displayed, making it less obvious
> how to create a screenshot or screencast frame.
> 
> To illustrate, if we have two monitors, one (A) with the resolution
> 800x600 and the other (B) with 1600x1200, where the second one
> physically small enough to make it HiDPI with output scale 2, today
> we
> get the following configuration:
> 
> +--+-+
> |  | |
> |A | |
> |  | |
> +--+ B   |
>    | |
> |  | |
>    | |
> -  -  -  - +-+
> 
> A large framebuffer with two regions representing the two monitors.
> Windows would be rendered twice as large when positioned on B than on
> A.
> When dragging a window from A to B it'd "flip" the size and suddenly
> become large when mostly within B.
> 
> A proper representation of this setup should be:
> 
> +--+--+
> |  |  |
> |A |B |
> |  |  |
> +--+--+
> 
> Two regions of a coordinate space, but with B having much higher
> pixel
> density. A window would be drawn larger on B's framebuffer, but at
> the
> same time, the correct size on A's framebuffer, would it be displayed
> there.
> 
> With this comes the question; how do we provide a user interface for
> screen shooting and screen casting? As I see it there are two
> options:
> 
> 1) Scale up every monitor to the largest scale and draw onto a large
> framebuffer.
> 
> 2) Represent each monitor separately, generating one file for each
> 
> Both have bad and good sides. For example, 1) doesn't need to change
> the
> user interface, while 2) more correctly represent what is displayed.
> For
> screencasts, 2) would mean we need two video encoding streams; but
> also
> make it easier to do reasonable post production.
> 
> Any opinions on in what way we should deal with this? What user
> interface do we want?

In terms of user interface, I'm fairly certain we want screen "B" to
behave as if it was an 800x600 screen, as that's what it's acting as.

For screenshots and screencasts, you have 2 options, either you double
up everything so that "x2" is normal scale, and you have a slightly
fuzzy screen A, or you "lose data" by shrinking everything as well. I
would go for "more data". In any case, as in the original screen case,
you'd need the screens to line up.

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

Re: nautilus-sendto 3.8.4

[Bastien Nocera]

On Mon, 2016-06-13 at 12:49 +0200, Bastien Nocera wrote:
> On Sun, 2016-06-12 at 23:31 +, Michael Catanzaro wrote:
> > About nautilus-sendto
> > =
> > 
> > Easily send files via mail
> > 
> > News
> > 
> > 
> > - Fix build with GCC 6
> > - Updated translations
> 
> While I appreciate the bug fixes, note that this module still has
> both
> a maintainer and a bugzilla where you can file bugs and attach
> patches.

This was supposed to be a private mail.

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

Re: nautilus-sendto 3.8.4

[Bastien Nocera]

On Sun, 2016-06-12 at 23:31 +, Michael Catanzaro wrote:
> About nautilus-sendto
> =
> 
> Easily send files via mail
> 
> News
> 
> 
> - Fix build with GCC 6
> - Updated translations

While I appreciate the bug fixes, note that this module still has both
a maintainer and a bugzilla where you can file bugs and attach patches.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Bastien Nocera]

On Fri, 2016-06-03 at 13:11 +0200, Bastien Nocera wrote:
> On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
> > [ Picking this up again ]
> > 
> > I've been spending the last couple of days fixing modules on
> > git.gnome.org (you may have noticed a commit or two from me on your
> > modules fixing builddir != srcdir issues); submitting bugs/patches
> > to
> > modules that are hosted elsewhere; and disabling non-srcdir builds
> > directly in the jhbuild modulesets. I'm fairly confident that all
> > remaining issues are now limited to modules that are in gnome-apps
> > or
> > gnome-world, but I haven't tested things like all the C++ language
> > bindings modules.
> > 
> > If you maintain a module listed in jhbuild, *please* update your
> > jhbuild local repository and try build your module with the new
> > buildroot setting enabled. If your module fails to build, fixing it
> > would also be appreciated — as it would spare you and everybody
> > else
> > time and effort; alternatively, you can poke me on IRC, and I'll
> > either fix it for you, or help you out in fixing it.
> > 
> > As a last resource, we can mark modules that do not support non-
> > srcdir
> > builds in the various modulesets, but I'd rather avoid it as it
> > defeats the purpose.
> 
> Looks like this is uncovering more bugs.
> $ jhbuild buildone -afn gnome-documents
> *** Configuring gnome-documents *** [1/1]
> /home/hadess/Projects/jhbuild/gnome-documents/autogen.sh --prefix
> /home/hadess/Projects/gnome-install --disable-Werror  --enable-
> getting-
> started 
> /usr/bin/gnome-autogen.sh
> fatal: Not a git repository (or any parent up to mount point /home)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
> 
> 
> The autogen.sh tries to run:
> git submodule update --init --recursive
> 
> Which might, or might not be a good idea. In any case, that won't
> work
> if cwd isn't the git repo.
> 
> What's the proper fix for this then?

The "srcdir != builddir" implemented in jhbuild isn't the same one as
the one implemented in Continuous[1].

Which is a bit of a shame when the jhbuild implementation was done to
avoid continuous breaking. And that might also have explained a number
of the breakages you've found.

[1]: Continuous runs autogen.sh from srcdir, jhbuild from builddir.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Bastien Nocera]

On Fri, 2016-06-03 at 15:53 +0200, Sébastien Wilmet wrote:
> On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote:
> > Yet this is what you're doing. If you want an application to be
> > renamed, you'd better make sure that you can actually come up with
> > a
> > good name, and argue why it is an insurmountable problem to call
> > the
> > package "gnome-games-app" or similar in your distribution.
> 
> gnome-games-center ? Like gnome-control-center.
> 
> Anyway, the plugins of gnome-games will maybe be tricky to package.
> Isn't a Flatpak sufficient? The purpose of Flatpak is to avoid all
> the
> duplicated work of packaging in all the distros. I have always seen
> that
> as a big waste of time. For new apps, does it really make sense to
> package them in the traditional manner?

Again, that's not relevant to the discussion about why the "gnome-
games" tarball name is a problem for distributions.

The flatpak name is "org.gnome.Games". I doubt it conflicts with
anything.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Bastien Nocera]

On Thu, 2016-06-02 at 20:43 +0200, Sébastien Wilmet wrote:
> On Thu, Jun 02, 2016 at 03:10:59PM +0200, Bastien Nocera wrote:
> > If you want an application to be
> > renamed, you'd better make sure that you can actually come up with
> > a
> > good name, and argue why it is an insurmountable problem to call
> > the
> > package "gnome-games-app" or similar in your distribution.
> > 
> > gnome-games has been called gnome-games for 2 years. It uses the
> > gnome-
> > games list for communication, it uses the gnome-games bugzilla, it
> > uses
> > the gnome-games git repo.
> 
> gnome-games is not hosted on gnome.org since a long time, the project
> has moved from GitHub to gnome.org recently. I already talked to
> Adrien
> about the naming problem well before it was hosted on gnome.org.
> 
> Is the gnome-games mailing list also for the other games in GNOME? If
> not, the name is misleading. The same for the bugzilla product. Users
> will start filing bugs on gnome-games because, hey, that's what they
> installed on their system.
> 
> Personally, when I develop a new software, I make sure the name that
> I
> choose isn't yet used or at least not widely used in the same domain.
> To
> have good results in a search engine, and find it easily in a package
> manager. That's just common sense but I'm sure you can find it
> written
> somewhere in a list of good practices when writing free software. For
> example:
> http://producingoss.com/en/getting-started.html#choosing-a-name
> 
> which is a recommended reading from the GNOME programming guidelines:
> https://developer.gnome.org/programming-guidelines/stable/additional-
> materials.html.en
> 
> So in the first link you can read:
> 
>   “Is not the same as some other project's name, and does not
> infringe on any trademarks. This is just good manners, as well as
> good
> legal sense. You don't want to create identity confusion. It's hard
> enough to keep track of everything that's available on the Net
> already,
> without different things having the same name.”
> 
> (side note, it's a bit ironic to see gnome.org as an example a bit
> below
> on the same page)

This is a discussion about why the use of the gnome-games name might or
might not be legitimate. That isn't an answer to the questions I asked
however.

> Btw Michael Catanzaro is a member of the release team. In GNOME
> module
> maintainers have a lot of freedom, but maybe it is a good idea to
> know
> the opinion of the release team, since it's the team responsible for
> what GNOME ships. gnome-games (the new one) is not part of GNOME core
> though.

Would be great if you, or somebody else, could answer my questions.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Enabling builddir != srcdir by default in jhbuild

[Bastien Nocera]

On Thu, 2016-06-02 at 23:50 +0100, Emmanuele Bassi wrote:
> [ Picking this up again ]
> 
> I've been spending the last couple of days fixing modules on
> git.gnome.org (you may have noticed a commit or two from me on your
> modules fixing builddir != srcdir issues); submitting bugs/patches to
> modules that are hosted elsewhere; and disabling non-srcdir builds
> directly in the jhbuild modulesets. I'm fairly confident that all
> remaining issues are now limited to modules that are in gnome-apps or
> gnome-world, but I haven't tested things like all the C++ language
> bindings modules.
> 
> If you maintain a module listed in jhbuild, *please* update your
> jhbuild local repository and try build your module with the new
> buildroot setting enabled. If your module fails to build, fixing it
> would also be appreciated — as it would spare you and everybody else
> time and effort; alternatively, you can poke me on IRC, and I'll
> either fix it for you, or help you out in fixing it.
> 
> As a last resource, we can mark modules that do not support non-
> srcdir
> builds in the various modulesets, but I'd rather avoid it as it
> defeats the purpose.

Looks like this is uncovering more bugs.
$ jhbuild buildone -afn gnome-documents
*** Configuring gnome-documents *** [1/1]
/home/hadess/Projects/jhbuild/gnome-documents/autogen.sh --prefix
/home/hadess/Projects/gnome-install --disable-Werror  --enable-getting-
started 
/usr/bin/gnome-autogen.sh
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).


The autogen.sh tries to run:
git submodule update --init --recursive

Which might, or might not be a good idea. In any case, that won't work
if cwd isn't the git repo.

What's the proper fix for this then?

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

Re: GNOME Games source name

[Bastien Nocera]

On Thu, 2016-06-02 at 15:03 +0200, Michael Biebl wrote:
> 2016-06-02 14:38 GMT+02:00 Bastien Nocera <had...@hadess.net>:
> > 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.

It's not constructive because you're not explaining to this list why
you think gnome-games should be a collection of games, and gnome-photos 
can't be a collection of photos.

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

Yet this is what you're doing. If you want an application to be
renamed, you'd better make sure that you can actually come up with a
good name, and argue why it is an insurmountable problem to call the
package "gnome-games-app" or similar in your distribution.

gnome-games has been called gnome-games for 2 years. It uses the gnome-
games list for communication, it uses the gnome-games bugzilla, it uses
the gnome-games git repo.

If you want the name to be changed, you'd better start arguing why. So
far, it's just a packaging problem, as you already have the discovery
problem with other core gnome applications ("apt-get install gnome-
videos gnome-web" ?)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Bastien Nocera]

On Thu, 2016-06-02 at 13:03 +0200, Michael Biebl wrote:
> 2016-06-02 11:24 GMT+02:00 Bastien Nocera <had...@hadess.net>:
> > 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.

And for gnome-photos you expect a collection of photos?

>  Given
> Adrien's explanations, I think gnome-game-manager or gnome-video-
> games
> would be much more suitable.

The application is part of the "Finding and Reminding" collection of
applications for GNOME. It would appear as "Games" in GNOME. Once you
namespace it, it's gnome-games.

Call the package what you want, it doesn't matter, users should be able
to install this application through Software.

Or, even better, distributors would ship it in Games, and point towards
the Games section of Software when you have no games installed.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Games source name

[Bastien Nocera]

On Wed, 2016-06-01 at 21:56 -0400, Jeremy Bicha wrote:
> On Wed, Jun 1, 2016 at 7:47 AM, Adrien Plazas  et> wrote:
> > AFAIK the application is already distributed in Arch since 3.18 and
> > as a
> > Flatpak with the gnome-games name.
> 
> No, it's not in Arch yet really. [1]
> 
> It's funny you bring up Flatpak though, because I think that proves
> you *can* change a project name even after it's been packaged in
> distros.
> 
> > This seems like a distribution problem and one which is specific to
> > Debian
> > and its derivatives, so after more reflection changing the
> > project's name is
> > probably not the solution, especially as nothing prevents Debian to
> > use a
> > different package name like the one suggested by Michael.
> 
> Of course, Ubuntu and Linux Mint are major Debian derivatives. But
> it's not only Debian derivatives as openSUSE did the same thing! [2]
> 
> Not to put words in Michael's mouth, but my reading was that he was
> suggesting a name for your valued project, not for the distro
> metapackage.
> 
> Even if Debian and openSUSE changed the name  of the metapackage
> today, that name would not be available for reuse in those projects
> for *years*. In Debian's case, the old name must be kept with a
> temporary dependency on the new name for at least one stable release.
> 
> While you mentioned confusion to users as a concern, think about the
> confusion when several distros have to maintain a different source
> package name, meaning the package is named differently in their
> repositories and bug trackers than the primary project. I believe
> it's
> early enough that most of the pain is easily avoidable, even though
> it's less convenient now than it would have been a few months ago.

I don't think it should have to change names. You can name the "new"
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.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: upcoming "systemd --user" dependency in gnome-settings-daemon

[Bastien Nocera]

On Fri, 2016-05-13 at 13:01 +0300, Christian Hergert wrote:
> On 05/12/2016 07:06 PM, Bastien Nocera wrote:
> > So, I intend to use systemd to launch each gnome-settings-daemon
> > plugin
> > as a separate service, which would be tracked, and relaunched
> > through
> > "systemd --user":
> 
> We do a fair bit of subprocess launching/tracking in Builder with
> private DBus for IPC, and I would love to be able to re-use the
> spawning/tracking code.
> 
> I filed a bug[1] a while back wrt reliably killing processes. But I'd
> really like to see this go just a bit further in terms of something
> like
> a "GContainer" API. Going that route might simplify the process for
> supporting non-Linux too.

For our use, it'll be fire-and-forget. We don't do private IPC, and
"spawning" will be done by systemd itself.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

upcoming "systemd --user" dependency in gnome-settings-daemon

[Bastien Nocera]

Hey,

"systemd --user" has been enabled in Fedora 24 beta, which will ship
with GNOME 3.20. For GNOME 3.22, I'd like to make some changes in
gnome-settings-daemon, first in the sharing plugin, then in gnome-
settings-daemon itself.

Now
===

When I implemented the per-network sharing for UPnP/DLNA, VNC and
WebDAV services:
http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html
it was always the plan to switch to a better way of tracking the
services that gnome-settings-daemon would start.

When gnome-settings-daemon crashes, it loses track of the services it
started, and cannot stop them when it should, when switching networks.
It is a potential privacy problem.

The bug for gnome-settings-daemon is here:
https://bugzilla.gnome.org/show_bug.cgi?id=766329

The necessary changes in rygel, vino and gnome-user-share are in the
blocking bugs.

Then


The second part of the plan for using "systemd --user" is probably a
bigger problem for non-systemd operating systems [1].

gnome-settings-daemon, to avoid inter-dependency between plugins,
ordering problems, and making it easier to disable and debug some parts
separately, is using D-Bus internally, and to offer those features
externally.

For example, both the media-keys plugin and the orientation plugin use
the xrandr plugin's D-Bus interface to rotate the screen, the former
for the laptop multimedia key, the latter for the accelerometer in
tablets.

Because the gnome-settings-daemon code interacts with so many different
services to implement policy and hardware enablement[2], it's not
uncommon for one particular plugin to cause gnome-settings-daemon to
crash.

This has consequences, such as, on X11, losing the default theme, font
and hi-dpi setting, even though something other than the XSettings
plugin crashes. Or network-facing services not being tracked any more.
Or the desktop-wide keyboard shortcuts not working any more.

So, I intend to use systemd to launch each gnome-settings-daemon plugin
as a separate service, which would be tracked, and relaunched through
"systemd --user":
- the "org.gnome.settings-daemon.plugins.* active" boolean would be
replaced by a call to "systemctl disable foo.service"
- inconsiderate uses of sync calls, crashes and memory leaks will be
easier to debug, and will stop affecting other parts of the system
- start-up will be heavily parallellised
- the wacom plugin won't eat memory on the user's system unless a Wacom
tablet is plugged in, or the orientation plugin without an
accelerometer
- the housekeeping plugin can be run at a regular interval, as
configured
- plugins that are only useful on X11 can be disabled on Wayland

I plan to work on this for the GNOME 3.22 release, though postponement
is a possibility, depending on the hurdles we encounter.

I expect that only gnome-settings-daemon and gnome-session would need
changes to implement this feature.

Comments?

I'd be especially interested in hearing from non-Linux developers about
what their plans would be.

Cheers

[1]: I have no interest, personally, supporting the fringe, non-
systemd, Linux distributions. Not using systemd is much more work for
me, and I'm not even talking about when the features just can't be
implemented on a paper-and-glue-quality init system.

[2]: It will interact with your keyboard, screen, accelerometer, sound
cards, buttons on USB speakers and Bluetooth headsets, Wacom tablets,
network, VNC, location, colour sensors, batteries, wireless
killswitches, and smartcards.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Photos plans for 3.22

[Bastien Nocera]

On Thu, 2016-03-31 at 07:50 +, Debarshi Ray wrote:
> Hello everybody,
> 
> GNOME 3.20 was a busy cycle for Photos, with a lot of activity
> from new contributors, and we want to carry that momentum into
> 3.22. While we have a roadmap [1] to list the priority bugs
> and features for the near future, I want to draw your attention
> to two big things that we want to achieve for GNOME 3.22.
> 
> * Uploads & sharing: Uploading and sharing to online accounts -
>   Google, Facebook and Flickr [2]. (proposed for GSoC & Outreachy)
> 
>   I think it is time to integrate sharing more tightly into the
>   content applications, and this is a step in that direction.
>   Realistically speaking, we will target only one of the
>   aforementioned providers and I am currently thinking of Google.
>   Once the basic framework in place we can add more.
> 
> * Import from device: Importing images from cameras, SD cards and
>   USB sticks [3].
> 
>   This is another thing that has, so far, been missing from the
>   content applications, and I think it is a crucial feature when
>   dealing with images.

FWIW, I consider "importing" through browsing with the file browser to
be more important than importing from devices. Eg. opening image files
in Photos through the filemanager should work, and allow importing.

(Both gnome-photos and gnome-music can't be selected as the defaults in
the Details settings panel, which is pretty weird...)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list