Re: 3.25.90 will probably be delayed

[Nirbheek Chauhan]

On Mon, Aug 14, 2017 at 3:48 AM,   wrote:
> 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,
>

Thanks Michael (and everyone else!) for doing the hard work of
whipping everything into shape :)

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

[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

[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

[Richard Hughes]

On 13 August 2017 at 15:35,   wrote:
> Now if I can get a new colord tarball, I think this might work.

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.

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

[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

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

[Ernestas Kulik]

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

I’ve created a pull request for the colord issue. That, along with the
commit you referenced, fixes the build for 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

[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: 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: 3.25.90 will probably be delayed

[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

[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

[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

[Robert Ancell]

Can you attach your two versions of the .vapi? On Ubuntu 17.10 they are
almost identical and would compile against either one.

On Thu, 10 Aug 2017 at 10:06  wrote:

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

[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

Re: 3.25.90 will probably be delayed

[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