from:"mcatanzaro"


Hi devs,

There are too many broken modules right now! Here is the list of 
modules that Javier had to skip when releasing 3.25.4:


'pango', 'at-spi2-atk', 'vte', 'gdm', 'clutter-gtk', 'graphene', 
'nautilus', 'glade', 'libgxps', 'libgepub', 'gnome-font-viewer', 
'fwupd', 'gnome-terminal', 'totem', 'simple-scan', 'usbredir', 
'spice-gtk', 'gst-plugins-base', 'gst-plugins-bad', 'gnome-dictionary', 
'nautilus-sendto', 'gnome-builder', 'gnome-chess', 'gnome-sudoku'


That's wy too many broken modules. We normally have just one or two 
broken modules per release. Please, if your module is in the list 
above, make sure your module builds in JHBuild using your latest 
*tarball* release. In particular, if JHBuild is configured to build 
your module using meson, and you still have an Autotools build, you 
*must* ensure every meson.build is distributed, otherwise the build 
cannot work.


I'll be contacting individual maintainers regarding build breakage next 
week. It'd be easier if everything is fixed by Monday next week. :) I'm 
hoping to release 3.25.90 on time next week, but will delay as long as 
required if modules are not building.


Thanks,

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

Re: Too many broken modules

On Mon, Jul 31, 2017 at 12:36 PM, Arun Raghavan  
wrote:

Is there some place we can look at logs of the current build? I don't
have a jhbuild-y setup here, but I'd be happy to look at the gst-*
failures.


Nope, got to ask Javier if he remembers why it failed. Sorry. We know 
we need way better release infrastructure. Alternatively you could 
download the 3.25.4 modulesets from the release announcement and try 
building that.


In the past, I had to change GStreamer to build from Autotools instead 
of meson because the tarballs did not contain meson.build. That's the 
first thing I would check.


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

Re: Building GNOME in restrictive network environments

On Mon, Jul 31, 2017 at 2:15 PM, Bastian Ilso 
 wrote:
We also experienced this issue at the newcomers workshop as many 
flatpak manifests also download dependencies using the git:// 
protocol. It'd be great to have these fixed or maybe have a fallback 
behavior (having several URLs to try in the manifests?).


I'd also ask the GUADEC 2018 hosts to keep in mind the importance of 
having a good network connection for the unconference days. I'm told 
the MMU network is blocking email and IRC in addition to git. It's also 
blocking my Private Internet Access VPN. Shame we can't use our free 
PIA subscriptions (thanks PIA!) to avoid these problems.


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

2017-08-13 Thread mcatanzaro

On Sun, Aug 13, 2017 at 10:33 AM, Richard Hughes  
wrote:

I can do this tomorrow, today I have family things to sort today.
Thanks to everybody offering PRs for the colord issues, I've merged
all of them and I think we're in good shape now.


Yeah that's fine, enjoy your Sunday!

Unfortunately I did just file [1] for you to look at tomorrow. It's not 
clear to me if that will require changes in meson or not. I'm going to 
try holding back to colord 1.3.5 for this release. I bet that will work.


Michael

[1] https://github.com/hughsie/colord/issues/57

___
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

2017-08-11 Thread mcatanzaro


On Thu, Aug 10, 2017 at 6:25 PM, mcatanz...@gnome.org wrote:
Unfortunately I don't see anything wrong with the generated enums 
files. It turned out those are actually distributed in the PackageKit 
tarball, which was briefly a subject of suspicion since there are no 
problems when building from git, but I don't see anything wrong with 
them.


Since this seems to be a major problem we do need to figure it out 
now instead of proceeding with the release and expecting distros to 
build a broken result. But I am stumped. Help welcome from anyone 
interested in this problem.


Michael


Obvious workaround is obvious: distros can just build PackageKit with 
--disable-vala. (Heads-up distros: you'll probably need to do this!)


Bug report: https://github.com/hughsie/PackageKit/issues/212

Moving on.

Michael

___
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

2017-08-12 Thread mcatanzaro


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.


I was hoping to finish up today, but it's just not going to happen. 
Normally all releases have an app or two that fails to build and we 
just mark them as skipped in the jhbuildrc that we release and roll 
with it. But right now, we have tricky outstanding build failures in 
low-level components [1][2] that I don't understand and which I have 
spent *far* too much time on already. This is a judgment call, but I 
think we're just not in a state to make our .90 beta release right now, 
since if we can't build it ourselves, distros probably won't be able to 
either. Please help fix these tricky issues and then we can see where 
we're at and decide how to adjust our schedule when they're fixed. I've 
uploaded tentative jhbuild modulesets [3] for smoketesting, so you can 
build with the exact same tarball versions and build flags that we 
release. You can use a command like this:


$ jhbuild -f sample-tarball.jhbuildrc -m gnome-apps-3.25.90.modules 
build


The good news is that a huge number of other build failures have 
already been fixed. In 80% of these cases the problem was already fixed 
in git and just needed a new tarball release. It's becoming too much 
effort to track down maintainers when releases are needed. When you 
make incompatible changes to your module or commit build fixes, it's 
important to follow the GNOME release cycle as otherwise it creates a 
big problem on release day when we can't build our tarballs against 
each other.


Michael

[1] https://github.com/hughsie/colord/issues/54
[2] https://github.com/hughsie/PackageKit/issues/212
[3] I've uploaded tentative jhbuild modulesets [3] for smoketesting, so 
you can build with the exact same tarball versions and build flags that 
we release.


___
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

2017-08-13 Thread mcatanzaro


Whew, it's done! I wound up doing a minimal number of workarounds:

* Held colord at a previous version
* Built PackageKit without Vala support
* Built totem without plugin support

This is a normal amount of workarounds. There's always a few hacks we 
need to do to get everything building. So in the end I'm pleased with 
the level of quality.


Better late than never,

Michael

___
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

2017-08-13 Thread mcatanzaro


Thanks a bunch.

Ernestas!

Now if I can get a new colord tarball, I think this might work. I can 
disable vala support in PackageKit because vala ships its own 
PackageKit vapi, but that wasn't an option for colord


Michael

___
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

2017-08-12 Thread mcatanzaro


On Sat, Aug 12, 2017 at 3:40 PM, mcatanz...@gnome.org wrote:
[3] I've uploaded tentative jhbuild modulesets [3] for smoketesting, 
so you can build with the exact same tarball versions and build flags 
that we release.


Sigh, Geary

Here they are:

https://download.gnome.org/teams/releng/3.25.90/

___
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

2017-08-12 Thread mcatanzaro

On Sat, Aug 12, 2017 at 4:52 PM, Bastien Nocera  
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.



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.


Michael

___
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

2017-04-28 Thread mcatanzaro

On Fri, Apr 28, 2017 at 4:40 AM, Bastien Nocera  
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
  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.

By the way, I'm told the latest GStreamer tarballs are unproblematic, 
so I switched it back to Meson. Turns out I just forgot to remove our 
GStreamer version limit that we had used for 3.24. We don't have any 
way to automatically handle unstable versions of dependencies that 
aren't using the GNOME release cycle but which we still want to build 
from git usually. :(

Michael

___
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

2017-04-27 Thread mcatanzaro

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.


Thanks,

Michael

___
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

2017-04-29 Thread mcatanzaro

On Sat, Apr 29, 2017 at 7:45 AM, Bastien Nocera  
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.


Michael

___
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

2017-08-08 Thread mcatanzaro


On Tue, Aug 8, 2017 at 4:37 PM, mcatanz...@gnome.org wrote:

Hi,

Unfortunately 3.25.90 is going to be delayed indefinitely until all 
the tarballs build for me. It hasn't been going well so far. As I 
mentioned last week, there are a much higher number of failures than 
usual due to the meson switch. I'll be reaching out to individual 
maintainers as needed.


OK, I'm done sending emails. If you don't have a mail from me, then 
your module is probably fine.


Michael

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

Re: Building GNOME in restrictive network environments


On Mon, Jul 31, 2017 at 1:29 PM, mcatanz...@gnome.org wrote:
I'm testing this now and will push as soon as I'm sure I haven't 
broken anything.


Done.

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

2017-08-09 Thread mcatanzaro

On Tue, Aug 8, 2017 at 10:45 PM, mcatanz...@gnome.org wrote:
OK, I'm done sending emails. If you don't have a mail from me, then
your module is probably fine.

Michael

Another update. Thanks to lots of help from lots of people, I'm down to
just three known build failures. (There might be more hidden behind
modules I failed to build last night, but probably not many.) Two are
easy and just need new tarballs. There is only one real problem right
now: simple-scan. Here is the build error:

../../../../releases/gnome-apps-3.25.90/simple-scan-3.25.90/src/app-window.vala:1441.95-1441.100:
error: The name `code' does not exist in the context of `Pk.Error'
result_text = _("Failed to install drivers
(error code %d).").printf (e.code);

Compilation failed: 1 error(s), 0 warning(s)
ninja: build stopped: subcommand failed.

The problem seems to be that in GNOME we have two different, competing
packagekit-glib2.vapi files: one installed by PackageKit and one
installed by vala. The one installed by vala has Error.code, but the
one installed by PackageKit seems to take precedence, and it does not
have Error.code. The two sets of bindings are really
significantly/worryingly different. I'm really not sure what to make of
this.

Since this might indicate a major issue somewhere in either the
gobject-introspection or vala stacks, I don't think we should proceed
until simple-scan is buildable.

Michael

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

developer.gnome.org and meson

2017-08-09 Thread mcatanzaro


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.


Michael

___
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

2017-08-23 Thread mcatanzaro

On Wed, Aug 23, 2017 at 3:45 AM, Andika Triwidada  
wrote:

*.modules are named 3.25.90? wrong files? wrong names?


Oops! I will fix this.

Michael

___
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

2017-08-23 Thread mcatanzaro

On Wed, Aug 23, 2017 at 4:13 AM, Bastien Nocera  
wrote:

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?


Whoops, my bad. This is already on the checklist, but our checklist 
currently contains a lot of obsolete steps and it's out of order, so I 
don't follow it directly and just forgot this time. I was indeed 
supposed to do this. Too late now.


Michael

___
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

Another issue we haven't discussed yet is commit permissions. Right 
now, everyone can commit anything to every repository, but with GitLab 
we'll probably eventually want something more fine-grained where 
*active* maintainers have more control over who is allowed to commit. 
Currently we still need the ability to commit build fixes when a 
project is broken in JHBuild (or Continuous), so that means everyone 
(or at least release team) still needs commit access to everything for 
the time being. But I bet if we replace JHBuild with BuildStream and 
integrate it with GitLab CI, then build failures will become much 
easier to track than they are right now, and this won't be necessary 
anymore.


Michael

___
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

On Tue, May 16, 2017 at 11:12 AM, Germán Poo-Caamaño  
wrote:

From the migration plan in the wiki:

"Our contention is that copying/moving every existing GNOME issue 
to

a new issue tracker is impractical and, in many situations,
undesirable."

May you expand in which many situations is undesirable?

I can foresee unmaintained projects, but I clearly am missing more
cases.

For (semi-)maintained projects bugzilla is a database of "wisdom",
which is practical to find duplicated reports, for example, repetitive
bugs, and more importantly, the rationale behind WONTFIX issues 
because

of design decisions.

Does the plan consider a tool like bugzilla2gitlab, but removing the
part that copy the accounts?


We need a much better migration plan than that. If we don't have a 
script to migrate Bugzilla issues, comments, and attachments to our new 
GitLab instance, then we should not be considering using GitLab's issue 
tracker at all. I would rather continue to use Bugzilla forever than 
switch to GitLab without a proper migration of existing issues. We 
could still switch from cgit to GitLab and use it for merge requests, 
but turn off the issue tracker for now and reevaluate in the future 
when we have a better migration story in place. (Of course, we do not 
need to migrate anything except for actively-maintained projects 
currently hosted on git.gnome.org.)


We might even decide to never migrate the issue tracker. I would be 
surprised (and, of course, pleased) if the GitLab issue tracker ever 
becomes anywhere near as good as Bugzilla (or Phabricator's issue 
tracker, Maniphest). That said, some of the comments in this thread 
have made me more comfortable with switching, especially Emmanuele's 
comment that it's now possible to move issues from one project to 
another.


Michael

___
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


On Tue, May 16, 2017 at 12:03 PM, Ray Strode  wrote:

Hi,

On Tue, May 16, 2017 at 12:20 PM  wrote:

Another issue we haven't discussed yet is commit permissions. Right
now, everyone can commit anything to every repository, but with 
GitLab

we'll probably eventually want something more fine-grained where
*active* maintainers have more control over who is allowed to commit.
uhh, why? I think the lack of fine grained ACLs is an extremely 
useful feature of our current setup.  Are you concerned we might grow 
abusers at some point?


--Ray


Some maintainers want this, and I think that will be fine in the 
future. I don't really care much either way, because I've never seen 
any intentional abuse, and if someone commits something wrong to one of 
my projects I can simply revert it... which is very rare. But GitLab 
makes it easy to lock down permissions, and I hope we don't do that 
right away, when our build system is still very fragile and waiting for 
maintainers to approve build fixes is undesirable.


Michael

___
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


On Tue, May 16, 2017 at 12:23 PM, mcatanz...@gnome.org wrote:
Some maintainers want this, and I think that will be fine in the 
future. I don't really care much either way, because I've never seen 
any intentional abuse, and if someone commits something wrong to one 
of my projects I can simply revert it... which is very rare. But 
GitLab makes it easy to lock down permissions, and I hope we don't do 
that right away, when our build system is still very fragile and 
waiting for maintainers to approve build fixes is undesirable.


And we do need some tier of permissions, since we want everyone to be 
able to use the issue tracker, but we surely do not want everyone to be 
able to close and reopen issues, or to commit to our projects.


Michael

___
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

2017-05-19 Thread mcatanzaro


On Thu, May 18, 2017 at 11:36 AM, Andre Klapper  wrote:
The Traceparser is another (basically) unmaintained custom extension 
we

have in our Bugzilla, with some confusing bugs (e.g. bug 744491).


I think we should remove this extension immediately. It provides 
limited value, since you almost always want to skip through the pretty 
little trace to see the full backtrace anyway. And this confusing bug 
is very serious.


It will be a shame to lose the feature that notifies you if your 
backtrace is similar to a backtrace in another bug, but we can live 
without and it's not worth the cost of bug 744491.


Michael

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

GNOME 3.25.91 released

2017-08-22 Thread mcatanzaro


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 lists of updated modules and changes are available here:

core - https://download.gnome.org/core/3.25/3.25.91/NEWS
apps - https://download.gnome.org/apps/3.25/3.25.91/NEWS

The source packages are available here:

core - https://download.gnome.org/core/3.25/3.25.91/sources/
apps - https://download.gnome.org/apps/3.25/3.25.91/sources/

WARNING! WARNING! WARNING!
--

This release is a snapshot of early development code. Although it is 
buildable and usable, it is primarily intended for testing and hacking 
purposes. GNOME uses odd minor version numbers to indicate development 
status.


For more information about 3.25, the full schedule, the official module 
lists and the proposed module lists, please see:


https://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:

https://wiki.gnome.org/Schedule

On behalf of the release team,

Michael Catanzaro



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

paste.gnome.org

2017-12-04 Thread mcatanzaro


Hi,

paste.gnome.org is great, except for:

"You must select a language other than 'text' for this paste."

where is the source code? Can we get rid of this?

Michael

___
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

2017-11-04 Thread mcatanzaro



On Sat, Nov 4, 2017 at 2:41 PM, Florian Müllner  
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?

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

Proposal for reducing the number of unremovable apps in GNOME Software

2017-11-03 Thread mcatanzaro


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. Specifically, 
I propose that GNOME be 
removed from the appstream metainfo for all of our apps except the 
following four:


* gnome-screenshot
* gnome-software
* nautilus
* yelp

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

Thoughts?

Michael

[1] 
https://git.gnome.org/browse/jhbuild/commit/?h=jjardon/reorganization=276a5c4472d5e7f593caa382dc975de5ec4195d6


___
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

2017-11-07 Thread mcatanzaro


On Tue, Nov 7, 2017 at 5:05 AM, Allan Day  wrote:
3. I guess I just find it strange that this mechanism is so 
decentralised. Can anyone use ?


Yes.

Who makes the decisions about what's included and what isn't? How is 
that monitored and managed?


Application developers make the decision themselves by specifiying it 
in the application's metainfo.xml/appdata.xml. It's certainly 
suboptimal.


There used to be a list of "core" desktop files maintained by GNOME 
Software, so this was not a problem. But this metadata wound up being 
pushed into appstream a couple years ago.


Michael

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

Re: GitLab update: Moving to the next step

2017-12-08 Thread mcatanzaro

On Fri, Dec 8, 2017 at 3:40 AM, Emilio Pozuelo Monfort 
 wrote:
Can't you write a simple greasemonkey script to add canned replies to 
gitlab, until they are implemented upstream?


No, because our web browser does not support Greasemonkey yet. (Should 
be possible to do using WebKitUserContentManager, if anyone has an itch 
to scratch.)


But thanks for your suggestion, because it reminded be that our custom 
CSS feature (which is under the hood implemented in the same way that 
user scripts would have to be) is broken under flatpak... it works by 
launching gedit to edit a text file, and that's hard to do under 
flatpak. I will fix that


Michael

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

Re: GitLab update: Moving to the next step

2017-12-11 Thread mcatanzaro

On Sun, Dec 10, 2017 at 10:04 AM, Michael Catanzaro 
 wrote:
I was providing my opinions on which issues should be blockers for 
GNOME. I'm not issuing demands here... Carlos is running this show.


I updated a tracker bug today:

https://bugzilla.gnome.org/show_bug.cgi?id=776514

How will that be migrated?

Without issue dependencies, keeping track of related tasks is going to 
be a lot harder


Michael

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

Re: GitLab update: Moving to the next step

2017-12-11 Thread mcatanzaro

On Thu, Dec 7, 2017 at 2:04 PM, Michael Catanzaro 
 wrote:
Looking over #8, I think duplicate issues, canned replies, and 
dependencies between issues should all be considered blockers to 
issue tracker migration.


Carlos has pointed out that there is rudimentary (not very good) 
support for duplicates:


https://wiki.gnome.org/GitLab#Issues

I think it suffices for now... you just have to remember the magic 
words /duplicate #number. Lack of duplicates was my biggest concern. I 
trust this will be improved in the future.


Canned replies are WIP upstream. I can live without for a short while, 
as I trust they will be implemented sooner rather than later.


Emmanuele and Carlos both proposed various workarounds to lack of issue 
dependencies. One option is to use labels to track a group of related 
issues. The other option is to manually maintain a task list issue, 
which is a bit of manual effort, but not really a big deal.


No further objections from me.

Michael

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

GNOME 3.26.2 released

2017-10-31 Thread mcatanzaro


Hi,

I'm pleased to announce the release of GNOME 3.26.2, the final planned 
release for the GNOME 3.26 series. It includes many bugfixes, 
documentation improvements, and translation updates. All distributions 
shipping GNOME 3.26 are strongly encouraged to upgrade.


Packages should arrive in your distribution of choice soon, but if you 
want to compile GNOME 3.26.2 by yourself, you can use the JHBuild 
modulesets available here:


 https://download.gnome.org/teams/releng/3.26.2/

The lists of updated modules and changes are available here:
 core   -  https://download.gnome.org/core/3.26/3.26.2/NEWS
 apps   -  https://download.gnome.org/apps/3.26/3.26.2/NEWS

The source packages are available here:
 core   -  https://download.gnome.org/core/3.26/3.26.2/sources/
 apps   -  https://download.gnome.org/apps/3.26/3.26.2/sources/

Our next major release, GNOME 3.28, is expected in March.

Enjoy,

Michael

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

Re: New module in GNOME: gnome-internet-radio-locator

2018-05-21 Thread mcatanzaro

On Mon, May 21, 2018 at 1:16 PM, Ole Aamot  
wrote:

What else do I have to do to mark the module
gnome-internet-radio-locator for release in
GNOME 3.29.2 unstable?


Hi Ole,

For GNOME 3.28, we severely downsized what we release to just a few 
core GNOME apps and dependencies. The motivation behind this change was 
to reduce the amount of software that the release team was responsible 
for (it was just too much). Anyway, that more or less corresponds to 
[1] and dependencies. Everything else was moved off to the world 
element [2].


It's possible that we could revisit this change! But as things stand, 
I'd invite you to add gnome-internet-radio-locator to the world element 
instead. This doesn't require any approval, since world doesn't get 
officially released by release team. Just add an element file under 
elements/world, add it to the list in world.bst, and verify that it 
builds successfully. Feel free to either push directly or open a merge 
request, as you prefer.


Hope that's OK,

Michael

[1] 
https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/core/meta-gnome-core-utilities.bst
[2] 
https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/world.bst


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

Re: GNOME 3.29.3 unstable tarballs due (responsible: mcatanzaro)

2018-06-14 Thread mcatanzaro




On Thu, Jun 14, 2018 at 8:02 PM, Federico Mena Quintero 
 wrote:

This:

http://ftp.gnome.org/pub/GNOME/teams/releng/3.29.2/versions

has librsvg 2.40.20, which is the unmaintained series.  How can I
change it to 2.43.0 for the development release?  I'd really like to
get some testing there.


We discussed this earlier today on IRC. We need to resolve these two 
issues:


https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/100
https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/24

Once we have Rust working, then updating librsvg should be 
straightforward.


Michael

___
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

2018-01-20 Thread mcatanzaro

On Sat, Jan 20, 2018 at 3:47 AM, Tristan Van Berkom 
 wrote:

JHBuild
---
For what regards the upcomming 3.28 release and further, patches 
should

go to the gnome-build-meta project instead of the JHBuild modulesets -
otherwise these patches would not be considered in the releases we are
building.

As agreed upon in this previous thread[1], changes in gnome-build-meta
can be backported to the JHBuild modulesets while they remain on "life
support".


Hi all,

This bears repeating: the release team will no longer maintain JHBuild 
or the JHBuild modulesets. When adding or removing a dependency from 
your module, please now update gnome-build-meta instead.


JHBuild has served us very well for a long time, but BuildStream should 
be much more reliable. Thanks very much to Tristan and Codethink for 
making this transition possible!


(Of course, you can still use jhbuild and commit to the jhbuild 
modulesets if you want to. Just please don't expect the release team to 
review your patches anymore.)


Thanks and happy hacking,

Michael

___
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

2018-01-24 Thread mcatanzaro

On Wed, Jan 24, 2018 at 2:11 PM, Florian Müllner  
wrote:
Really, the only thing I disagree with is that RT appears to actively 
discourage maintainers from updating JHbuild before everyone actually 
has the option to make the switch - sure, if updating GTK+ fails for 
me because harfbuzz gained a new dependency, I'll be able to figure 
out what that dependency is, what's its upstream is and whether it's 
available in reasonably current distros. But it'll be a lot easier 
and quicker for whoever made the change in the first place :-)


Maybe we should delay this until BuildStream can generate OS images. 
Tristan, what do you think...?


(Tristan had actually suggested backporting gnome-build-meta changes to 
jhbuild for some hazy amount of time; it was mainly me who wanted to be 
rid of JHBuild ASAP. ;)


Michael

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

Re: GNOME 3.27.90 beta tarballs due (and more) (responsible: mcatanzaro)

2018-02-01 Thread mcatanzaro

On Thu, Feb 1, 2018 at 6:00 PM, Release Team  
wrote:
Tarballs are due on 2018-02-05 before 23:59 UTC for the GNOME 3.27.90 
beta release


Hi maintainers,

If you're reading this, now is a good time to do your releases! No need 
to wait until the last minute on Monday.


As usual, please be especially sensitive of the need for a new release 
if:


* You've switched your module to the meson build system; or
* You've added new API to your module, which another module already 
depends on


Thanks for helping this release go smoothly,

Michael

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

3.27.90 tarball deadline extended

2018-02-05 Thread mcatanzaro


Hi developers,

TL;DR: the 3.27.90 tarball deadline is extended until next Monday

The release team is still learning how to get by in a BuildStream 
world. It turns out that nobody who is currently available knows how to 
generate release tarballs using BuildStream. Many developers, notably 
Tristan, are traveling from FOSDEM and unavailable at the moment. I've 
been discussing with Javier, and we're both kind of lost as to what to 
do. If you've already released a tarball, you must have done so either 
using host dependencies, which doesn't work for modules that depend on 
new stuff, or with JHBuild. We think it's important to actually be able 
to release all modules without using JHBuild, and we'll need a couple 
days to figure this out, and you all surely deserve at least one 
weekend after that before tarballs are due, so let's extend the 3.27.90 
tarball deadline until at least next Monday. Expect more development 
schedule change announcements as we figure out what we're doing.


Thanks for your patience throughout this big transition,

Michael

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

Freezes begin today

2018-02-05 Thread mcatanzaro


Hi all,

Despite the release schedule change, we're now quite close to the final 
3.28.0 release, so to ensure quality we should begin all the freezes as 
previously-scheduled. That means UI freeze, feature freeze, API/ABI 
freeze for libraries, and the string change announcement period all 
begin tonight.


Thanks for helping to make GNOME 3.28 stable and reliable,

Michael

___
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

2018-02-08 Thread mcatanzaro



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


The final tarball deadline for 3.27.90 will be Monday, February 12. Our 
release deliverable will still be a BuildStream project: that has not 
changed.


Due to this delay, we will skip the 3.27.91 release altogether, so the 
next tarball deadline will be 3.27.92, on March 5. Perhaps by then we 
will be able to recommend using BuildStream for tarball generation.


Thanks very much for your patience during this transition period.

Michael

___
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

2018-02-05 Thread mcatanzaro


On Mon, Feb 5, 2018 at 11:59 AM, mcatanz...@gnome.org wrote:
The release team is still learning how to get by in a BuildStream 
world. It turns out that nobody who is currently available knows how 
to generate release tarballs using BuildStream.


Hi developers,

An update on this. With some help from Mathieu and Jürg, we've figured 
out how to generate tarballs. You need to use a combination of `bst 
workspace open` and `bst shell --build`. Then once you enter the bst 
shell, you can generate a tarball normally (mkdir build; cd build; 
meson ..; ninja; ninja dist) and it will be generated in the workspace. 
This is actually pretty simple; I had gotten confused earlier today 
because I had forgotten the --build flag to `bst shell`.


Unfortunately, I discovered a bug that's a blocker for Epiphany [1], so 
it might not work for you in practice. We'll evaluate later this week 
whether we'll need to recommend switching back to JHBuild to generate 
tarballs for the time being, or whether we can get this working 
reliably.


Thanks for your patience,

Michael

[1] https://gitlab.com/BuildStream/buildstream/issues/232

___
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

2018-02-09 Thread mcatanzaro

On Fri, Feb 9, 2018 at 9:14 AM, Emmanuele Bassi  
wrote:
Whatever maintainers use to build release tarballs is fine — as 
long as you ensure that you're always keeping the build of the whole 
GNOME set of modules running.


Yes, this!

Milan, feel free to do the .91 release whenever you want. Or you could 
do it now and call it .90.5, or whatever you want to call it.


The delay seemed appropriate because, having advised maintainers to 
switch from JHBuild to BuildStream, but not having any way to generate 
release tarballs with BuildStream, was not a friendly situation for 
maintainers. I had provided guidance that was not possible to follow. I 
know you're used to releasing without using JHBuild, but that can be 
difficult, and anyone who relies on JHBuild to make releases and 
followed our advice to stop doing so would have been stuck. Hence, some 
extra time to figure out what we were doing was needed.


Michael

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

Let's kill gnome-common!

2018-02-12 Thread mcatanzaro


Hi,

I want to remove gnome-common from our BuildStream projects, but a few 
modules are still depending on it: gcr, gnome-autoar, libnotify, 
adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas.


If you help fix these sad modules, you'll earn the right to say that 
you helped fix these sad modules.


Thanks,

Michael

___
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

2018-02-09 Thread mcatanzaro

On Fri, Feb 9, 2018 at 8:36 AM, Bastien Nocera  
wrote:
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.


To be clear, we're not asking for that. You can use whatever tool you 
want.


JHBuild was previously the easiest way to generate a release tarball 
for GNOME. Now we intend for BuildStream to fulfill that role. So, 
going forward, it will be our recommendation to use it. But you 
certainly don't have to. It's just a tool, after all.


Michael

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

Re: Let's kill gnome-common!

2018-02-13 Thread mcatanzaro




On Tue, Feb 13, 2018 at 3:43 AM, Sébastien Wilmet  
wrote:
The list is not complete, there is for example gedit as well, I think 
it

was common to *not* list gnome-common as dependency in the jhbuild
modulesets because libraries like gtk was already depending on it.


Hm, indeed, gedit does not use gnome-autogen but it does use 
GNOME_COMPILE_WARNINGS. It must be getting pulled into the build 
environment by one of its dependencies.



Also, I think it's a bit a waste of effort to first port to
autoconf-archive macros, and then porting to meson just a few
development cycles later.


Getting rid of gnome-common takes about 10 minutes at worst, but 
porting to meson is a much larger effort!


Michael

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

GNOME 3.27.90 released

2018-02-14 Thread mcatanzaro


Hi developers,

Better late than never: GNOME 3.27.90 is here, exactly one week later 
than originally scheduled.


With this release, the release team is no longer going to be building 
or releasing non-core applications. We have renamed the apps moduleset 
to world to reflect this. App developers are encouraged to test their 
applications against new versions of GNOME to make sure they are still 
building and working well.


If you want to compile GNOME 3.27.90, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of the dependencies on your 
host system:


https://download.gnome.org/teams/releng/3.27.90/gnome-3.27.90.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.27/3.27.90/NEWS

The source packages are available here:

https://download.gnome.org/core/3.27/3.27.90/sources/

Some commentary. As is typical for our development releases, I ran into 
some build issues. As usual, maintainers received either an email or a 
ping on IRC if I found an issue with your module. Unfortunately, I had 
to temporarily drop a couple modules. The gtkmm module (which is based 
on GTK+ 4, not gtkmm-3) seems to be keeping up with changes in GTK+ 4 
in git, but not making releases. Either it will need to either start 
releasing following GTK+ 4, or we'll need to drop it until GTK+ 4 
development slows down. Additionally, gnome-documents and gedit have 
been temporarily removed due to build issues.


We also have a problem with some prominent modules not getting 
releases. Notably, GNOME 3.27.90 includes GNOME Shell 3.27.1 and mutter 
3.27.1, which are the latest-available versions. This is sad. Let's do 
better next cycle, please.


As a reminder, there will be no 3.27.91 release next week due to the 
delay of 3.27.90. You'll get an automated reminder later this week; 
just ignore it.


Thanks for your hard work on GNOME 3.28. It's going to be great!

WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.27, the full schedule, the official module
lists and the proposed module lists, please see our 3.27 wiki page:

https://www.gnome.org/start/unstable

Michael

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

Re: Using BuildStream as a module maintainer

2018-02-16 Thread mcatanzaro

On Fri, Feb 16, 2018 at 4:15 PM, Shaun McCance  wrote:
> $ bst build --track-all --track-save core/yelp.bst
> # For some reason I have to do this too? Not sure.
> $ bst build core/yelp.bst

It's a bug (very recently fixed):
https://gitlab.com/BuildStream/buildstream/issues/236

> $ bst shell --build core/yelp.bst bash
>
> That drops me in a shell in a yelp clone. I can do the autogen.sh,
> make, make distcheck dance. (I'll catch on to meson soon, promise.)
> But
> I don't know what to do next. I can't seem to scp. The only editor I
> have for writing NEWS entries and commit messages is vi. I don't have
> my ssh keys, pgp keys, git configs, etc. I'm kind of thinking this
> sandbox isn't the place for me to be doing things.

This confused me too. The missing step is, on the host:

$ bst workspace open core/yelp.bst ~/src/yelp

where the last parameter is the path to wherever you want your git
checkout to be. Then the bst shell command will take you to that
directory, inside the sandbox. You can do make distcheck there, the
generated tarball will appear, and then you can scp it from the host.

> And what about doing general development work? I can't really do much
> inside BuildStream's shell. And even running yelp leaves it pretty
> crippled, because it doesn't have access to /usr/share or D-Bus.
>
> I need some sort of build environment to keep up with dependencies,
> but
> I feel like I'm not fully grokking how people do stuff these days.
> Could somebody shed more light on how they do things?

I don't have a good answer, other than to use JHBuild. That's not a
very great answer, since you know I sent a mail a couple weeks ago
announcing that release team wouldn't be maintaining JHBuild anymore.
(Emmanuele has since taken up that role, in addition to maintaining the
Continuous manifest.) Perhaps that was premature, because many or
perhaps even most GNOME applications are barely functional inside the
bst shell. I've reported an issue for this:

https://gitlab.com/BuildStream/buildstream/issues/223

Problem is, if we keep using both JHBuild and BuildStream, then we have
four different sets of build definitions to maintain, rather than
three, and we're worse off than before. So we'll need to discuss what
we want to do about this.

Michael

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

Re: GNOME 3.27.90 released

2018-02-15 Thread mcatanzaro

On Thu, Feb 15, 2018 at 4:37 AM, Sam Thursfield  
wrote:
Does it makes sense to create a tagged commit in gnome-build-meta.git 
for each release, instead of publishing the release metadata only as 
a tarball?


I guess that could be quite useful, if people want to  see what the 
changes are. I just hadn't considered it, because it's something we've 
never done before.


It would maybe be a bit confusing, because the commits would not be on 
any branch, but I think that's fine.


Michael

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

GNOME 3.29.3 released

2018-06-20 Thread mcatanzaro


Hi developers,

GNOME 3.29.3 is now available.

This release is primarily notable in that all modules are buildable in 
this release, which is historically very rare for our development 
releases. This is an accomplishment! I hope we can keep this up going 
forward.


If you want to compile GNOME 3.29.3, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of your host system:


https://download.gnome.org/teams/releng/3.29.3/gnome-3.29.3.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.29/3.29.3/NEWS

The source packages are available here:

https://download.gnome.org/core/3.29/3.29.3/sources/

WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.29, the full schedule, the official module
lists and the proposed module lists, please see our 3.29 wiki page:

https://www.gnome.org/start/unstable

Michael

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

GNOME 3.29.91 released

2018-08-15 Thread mcatanzaro


Hi,

GNOME 3.29.91 is now available!

If you want to compile GNOME 3.29.91, you can use the official
BuildStream project snapshot:

https://download.gnome.org/teams/releng/3.29.91/gnome-3.29.91.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.29/3.29.91/NEWS

The source packages are available here:

https://download.gnome.org/core/3.29/3.29.91/sources/

A couple informal notes. First, this was too hard. Too many build 
failures. I wound up downgrading several modules, I just removed 
gnome-boxes rather than fight to get it to build. If you know there is 
some build failure affecting your module and fixed in git, then please, 
we really need a tarball release according to schedule to avoid making 
the release process difficult for us. Second, this release marks the 
beginning of the software string freeze. String changes from this point 
out require string freeze break approval.


WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.29, the full schedule, the official module
lists and the proposed module lists, please see our 3.29 wiki page:

https://www.gnome.org/start/unstable

Happy hacking,

Michael Catanzaro
GNOME Release Team

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

Re: GNOME 3.29.91 released

2018-08-16 Thread mcatanzaro




On Wed, Aug 15, 2018 at 5:42 PM, mcatanz...@gnome.org wrote:

Hi,

GNOME 3.29.91 is now available!


Hi developers,

I made a mistake in our release validation process, and accidentally 
included incompatible versions of glib (2.57.1) and 
gobject-introspection (1.57.2) in GNOME 3.29.91. gobject-introspection 
1.57.2 requires glib 2.57.2, but this version of glib is incompatible 
with GNOME 3.29.91. I properly downgraded glib when I noticed this, but 
failed to downgrade gobject-introspection as well. The result is that 
GNOME 3.29.91 is not buildable.


Actions:

* I'm currently working on an updated release with 
gobject-introspection downgraded to 1.56.1, to be published when 
available.
* I've updated our release procedure to require the strict build plan 
in BuildStream, to avoid this happening in the future.


Lastly, I'll remind maintainers that it would be really helpful to 
release according to our release schedule when there are build fixes 
present in your tree, so that we wouldn't have to fight so many build 
failures and downgrade so many modules. I'm still waiting on releases 
from gtk-doc, gnome-online-accounts, gnome-boxes, and gnome-software, 
all of which were broken and required workarounds to be included in 
GNOME 3.29.91.


Michael

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

Re: GNOME 3.29.91 released

2018-08-17 Thread mcatanzaro


On Thu, Aug 16, 2018 at 12:11 PM, mcatanz...@gnome.org wrote:

Hi developers,

I made a mistake in our release validation process, and accidentally 
included incompatible versions of glib (2.57.1) and 
gobject-introspection (1.57.2) in GNOME 3.29.91. 
gobject-introspection 1.57.2 requires glib 2.57.2, but this version 
of glib is incompatible with GNOME 3.29.91. I properly downgraded 
glib when I noticed this, but failed to downgrade 
gobject-introspection as well. The result is that GNOME 3.29.91 is 
not buildable.


Hi developers,

Here is a corrected release, GNOME 3.29.91.1. The only difference is 
that gobject-introspection has been downgraded:


https://download.gnome.org/teams/releng/3.29.91.1/gnome-3.29.91.1.tar.xz

https://download.gnome.org/core/3.29/3.29.91.1/NEWS

https://download.gnome.org/core/3.29/3.29.91.1/sources/

Please, make sure the latest releases of your modules build against 
glib 2.57.2, so that we can update glib and gobject-introspection for 
3.29.92.


Thanks,

Michael

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

libdw

2018-07-14 Thread mcatanzaro


Hi all,

Has anybody recently added libdw as a dependency of anything in GNOME?

I'm trying to figure out what has gone wrong in 
https://gitlab.gnome.org/GNOME/gnome-sdk-images/issues/13.


Thanks,

Michael

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

Re: No app menu changes for GNOME 3.30, please!

2018-07-24 Thread mcatanzaro


On Tue, Jul 24, 2018 at 8:53 AM, Allan Day  wrote:

I'd expected there to be some discussion about the timeline and a
decision by the Release Team.

As it is, we're less than a week away from UI freeze and most apps
haven't changed their app menus. For consistency's sake, it would be
better to hold off until next release.


I agree with Allan: please don't remove your app menus until after you 
have branched for 3.30. Removing app menus is a huge deal, and we don't 
want 3.30 to be an unfinished transition.


From the lack of objections to Allan's original proposal, it's clear 
that we have consensus on removing the app menus, so I suggest we 
should feel free to delete our app menus in master after branching for 
3.30.


Michael

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

Re: [GitLab] Gravatar vs libravatar

2018-09-04 Thread mcatanzaro

On Tue, Sep 4, 2018 at 10:24 AM, Nicolas Dufresne 
 wrote:

So it's a gain in privacy if you want to host your own. I'm surely not
the only one that isn't going that extreme in keeping control over
couple of my pictures flying around and won't go that far.


The gain in privacy comes from disabling gravitar integration, not 
hosting your own avatar service.



That being said, for people my me, where to I upload yet another
picture ? Any free hosted services ?


Just use libravatar.org. The website design is not the greatest, but if 
you look above the orange Contribute! button there is a "Create a free 
account" link... click that, confirm your email, upload your avatar, 
done. It's just the free software replacement for Gravatar, really that 
simple. I assume you trust libravatar.org not to sell our IP addresses, 
avatar lookup history, email contact graphs, etc. to advertising 
companies.


Or just manually upload your avatar to gitlab.gnome.org. The only 
reason I bothered with libravatar.org was that it was required to set 
an avatar on Fedora infrastructure. I don't really care whether we 
enable libravatar or not, just that we disable Gravatar.


Michael

___
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



On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano  
wrote:
What's the workflow for those before a proper solution is done? Or 
are the developers of those modules expected to maintain JHbuild on 
the meantime?


Thanks Carlos; this is an important question. Let me provide a bit more 
context for our decision to stop maintaining JHBuild now, even though 
BuildStream is not yet be usable for running some modules.


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.


So I assumed that demand to continue maintaining the JHBuild modulesets 
was really, really, *really* low.


This is just one particularly-egregious case... maintaining JHBuild is 
a constant fight against this sort of breakage; it seems to almost 
always be broken, and it's just not sustainable. (Big thanks to Alberts 
Muktupāvels, Javier Jardón, Ting-Wei Lan, and everyone else who's 
helped to maintain JHBuild during the past few years.) Now that release 
team is no longer using JHBuild, we simply don't want to deal with it 
anymore.


But I'm only speaking for the release team here, not the entire 
community. This conversation has made clear that, due to BuildStream's 
current limitations, there is still desire to continue using JHBuild 
that we failed to anticipate. Even I'll admit that, when it does work, 
JHBuild is actually easier and more convenient to use for development. 
So I would say: please do feel free to maintain the modulesets to the 
degree that you require for your own development. We have no plans to 
delete them. Ensuring that the modules you're personally interested in 
are building fine should be much easier for you than it was for us to 
try to ensure that everything always builds.


But with BuildStream, we now know for sure that our software always at 
least builds, because there is CI to enforce it, and a well-defined 
base system which is unaffected by host dependencies. That's step one. 
We've never had that before. I'm hopeful that the GNOME community can 
continue to improve the situation from here, to help make BuildStream 
more powerful and easier to use. No doubt Tristan will be here tomorrow 
with a comment on his plans for this. :)


I know that answer doesn't actually solve the problem, but hopefully 
that explains our thinking.


Michael

P.S. Unimportant: the dependency of gtk+-3 on at-spi2-atk is actually 
illegal, since gtk+-3 is in core-deps, and at-spi2-atk is in core, and 
core-deps is not supposed to depend on core. I just now noticed this. 
We of course have no tools to detect it. ;)


___
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

2018-01-21 Thread mcatanzaro


Hi,

On Sun, Jan 21, 2018 at 3:16 AM, Jens Georg  wrote:
So, following up on that and also on the libgepub thread: Which 
places do I have to modify if I were to switch the ABI and API 
version of gexiv2 (to either keep depending entities on the old 
stable branch or to the new branch or provide both etc) ? Only 
gnome-build-meta as mandatory, jhbuild as goodwill? What about 
continous?


Please do continue to update Continuous as needed for the time being. 
The future plan is to generate the Continuous manifest from 
gnome-build-meta, so that we don't have all this metadata specified in 
three different places, but replacing the manifest in gnome-sdk-images 
is more important to do first. (gnome-sdk-images is more 
lightly-maintained, and yet it's our only set of build definitions that 
directly affects our users.) Unfortunately, that's not likely to be 
ready for 3.28, so we'll need to be patient in the meantime. Hopefully 
later this year, we'll be able to announce that the Continuous manifest 
is gone. Again, thank Tristan and Codethink for this. ;)


I personally wouldn't touch JHBuild anymore unless you want to continue 
using JHBuild yourself and benefit from the changes you make, but it's 
up to you. JHBuild's developer workflow is still IMO better than what 
is currently provided by BuildStream, and we're used to using it for 
many years, so it's understandable if some community members desire to 
keep it working. (But release team considers it too fragile, and we 
really want to reduce the number of build definitions that we have to 
maintain.)


Michael

___
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

2018-01-21 Thread mcatanzaro



On Sun, Jan 21, 2018 at 6:02 AM, Tristan Van Berkom 
 wrote:

gexiv2 is listed as a system dependency, which strikes me as a bit odd
seeing as it's a requirement for some GNOME modules and it's hosted in
GNOME - I'm new to the release team and will have to figure out the
reasoning behind this.


We used to prefer to move modules from core-deps into sysdeps when 
possible, to reduce the number of modules that can cause build failures 
in JHBuild. That's not really going to be an issue anymore. I think 
moving gexiv2 to core-deps would be uncontroversial, if there's desire 
to do so, especially since it's hosted on GNOME infrastructure.



For now, the actual sysdeps we use to populate a base runtime to build
against are controlled by this list[2], and is basically generated 
from

packages in debian testing - until the freedesktop-sdk project evolves
and we start generating bootable VMs with a combination of that, and
GNOME build metadata, I should move that repo over to GNOME's gitlab
and re-enable the automation of generating the images it creates (I've
been doing this manually in order to avoid unnecessary rebuilds).


Tristan mentions that gexiv2 is a system dependency... that means it 
was never built in JHBuild before now, so it's not going to be built in 
BuildStream either (unless we add it to the core-deps project).


Under JHBuild, our rule was that GNOME modules can depend on a system 
dependency only if it's present in the latest stable releases of both 
Fedora and Ubuntu. Now, under BuildStream, it's much easier to add a 
new version of a system dependency. Once the new gexiv2 package enters 
Debian testing, you can simply create a merge request to add it to 
multistrap.conf.in, the file Tristan pointed to in his last mail, and 
then GNOME modules can begin to depend on it.


Alternatively, you could create a merge request or issue report to add 
it to the core-deps project.


Michael

___
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




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


Michael

___
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




On Mon, Jan 22, 2018 at 6:33 AM, Florian Müllner  
wrote:

Is this information outdated? At least I see all those components in
the gnome-build-meta repo, so I dare to hope ...


You can build them, and there is CI to ensure the build does not fail.

But I imagine it would be hard to run them.


If not, are we now expected to monitor all our dependencies'
dependencies (and so on) and effectively take over maintenance of the
jhbuild moduleset until someone figures out how to support our
components?


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,

___
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