Re: 3.25.90 will probably be delayed
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
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
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: developer.gnome.org and meson
On Fri, Aug 11, 2017 at 4:10 PM, Stefan Sauer wrote: > On 08/09/2017 10:11 PM, Nirbheek Chauhan wrote: > > Somewhat relatedly, the only reason why it takes so long to build docs > > is because we haven't been improving gtk-doc. There is little > > technical reason why building our documentation has to be *so* slow. > > For instance, there's Hotdoc which as a proof-of-concept does the same > > work, but much faster. So perhaps our time is better spent figuring > > out why gtk-doc eats CPU (single-threaded!) and fixing that. > It is not a secret why gtk-doc is slow. It is slow because libxslt and > the xsl-stylesheets are slow. In particular libxslt is single threaded. Thanks for the clarification, Stefan :) > In the gtk-doc-1.26 I just release, everything was ported to python. Yes, I was following the port to Python. It was great! Another step towards getting rid of Perl from our toolchain. I have a vested interest in this because it makes bootstrapping builds on, for example, Windows much easier. > Next step is to remove file generating code from the xslt pipeline. Then > we can replace xslt by e.g. a markdown toolchain. I appreciate what was > done in hotdoc, but I'd like to provide a step by step migration path > for existing modules. I never understood why what has been done could > not have been made inside gtk-doc as well. > I appreciate anyone helping (like jussi helping a lot with porting from > perl to python). > I completely agree, my mention of Hotdoc wasn't an endorsement of it, but rather to say that there is room for improvement in the time it takes to build our docs. A gradual migration to a markdown-based toolchain would do wonders. Do you have any bugs about the work that's needed so people can dive in if they can? 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
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
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: Let's pause meson migration in preparation for the 3.26 release
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. Your help with fixing #783099 would be much appreciated. Thanks, pk [1] https://mail.gnome.org/archives/gnome-i18n/2017-August/msg00015.html ___ 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
Yeah I guess, when the full migration is done, if the maintainer wants to migrate the bugs, we will use that tool. On Sat, Aug 12, 2017 at 4:48 PM, Sébastien Wilmet wrote: > On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote: > > Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools, > is > > up to the maintainer what to do with them. > > OK, and when the full migration will be done for all GNOME modules, do > you already know if that script will be used to migrate the bugzilla as > well? And then making the bugzilla read-only? > > -- > Sébastien > ___ > 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: GitLab migration status and roadmap
Hi. On Fr, 2017-08-11 at 14:37 +0200, Carlos Soriano wrote: > Also I hope in the time frame of 3-4 months the pilot program is successful For completeness sake: Are we still considering to *not* move to Gitlab if that pilot is not successful? How do we measure "success"? Cheers, Tobi ___ 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
On Sun, Aug 13, 2017 at 2:11 PM, Tobias Mueller wrote: > Hi. > > On Fr, 2017-08-11 at 14:37 +0200, Carlos Soriano wrote: > > Also I hope in the time frame of 3-4 months the pilot program is > successful > For completeness sake: > Are we still considering to *not* move to Gitlab if that pilot is not > successful? > I would say we won't switch if we discover some big and non fixable core issue. But we need the pilot program to make sure of that, that's the whole point. I'm confident GitLab team will help us if that situation happens though. > > How do we measure "success"? > We will measure success as we have been doing until now, identifying issues that impact most of the developers in a daily basis and putting it on the balance with the benefits. It's vague, but I don't think we need something more specific... the pilot program is about getting this feedback from maintainers, and working with the GitLab team to figure out the details we will be finding. > > Cheers, > Tobi > Is that a good enough answer? Or do you want something more specific? Best, Carlos Soriano ___ 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
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
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
