Re: GNOME 3.34 released
On 9/13/19 8:18 AM, Andre Klapper wrote: On Fri, 2019-09-13 at 04:56 -0500, Ty Young wrote: In terms of features, this has to be one of the biggest Gnome releases in years. Looking forward to using it when Arch Linux decides to release it in full... they keep breaking it up into segmented updates for some reason resulting in all sorts of breakage and mismatching between the old and new versions. Has anyone talked to them about that? Personally I'd say that it's up to distributions how distributions package and ship components, and up to users of distributions to discuss packaging improvements with packagers of the distribution. And then you have users reporting false bugs either because of component mismatching and/or distros not updating at all. Bit of a problem however... A background image that I used was removed in this version and there isn't any fallback logic to reset the background image. Can this maybe be fixed in the first point release so it never happens again please? Pure white desktop backgrounds aren't very pleasant to look at... Feel free to file a bug report with clear steps to reproduce and version information in https://gitlab.gnome.org - thanks! Looks like someone already did and submitted a patch. That was fast... I don't get why the image was even removed. It had existed in Gnome for years but now all of a sudden it's gone? Thanks, andre -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.34 released
On Fri, Sep 13, 2019 at 3:19 PM Andre Klapper wrote: > > On Fri, 2019-09-13 at 04:56 -0500, Ty Young wrote: > > Bit of a problem however... A background image that I used was removed > > in this version and there isn't any fallback logic to reset the > > background image. Can this maybe be fixed in the first point release so > > it never happens again please? Pure white desktop backgrounds aren't > > very pleasant to look at... > > Feel free to file a bug report with clear steps to reproduce and > version information in https://gitlab.gnome.org I filed https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/722 for the gnome-shell side. Cheers, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.34 released
On Fri, 2019-09-13 at 04:56 -0500, Ty Young wrote: > In terms of features, this has to be one of the biggest Gnome releases > in years. Looking forward to using it when Arch Linux decides to release > it in full... they keep breaking it up into segmented updates for some > reason resulting in all sorts of breakage and mismatching between the > old and new versions. Has anyone talked to them about that? Personally I'd say that it's up to distributions how distributions package and ship components, and up to users of distributions to discuss packaging improvements with packagers of the distribution. > Bit of a problem however... A background image that I used was removed > in this version and there isn't any fallback logic to reset the > background image. Can this maybe be fixed in the first point release so > it never happens again please? Pure white desktop backgrounds aren't > very pleasant to look at... Feel free to file a bug report with clear steps to reproduce and version information in https://gitlab.gnome.org - thanks! Thanks, andre -- Andre Klapper | ak...@gmx.net https://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.34 released
In terms of features, this has to be one of the biggest Gnome releases in years. Looking forward to using it when Arch Linux decides to release it in full... they keep breaking it up into segmented updates for some reason resulting in all sorts of breakage and mismatching between the old and new versions. Has anyone talked to them about that? Bit of a problem however... A background image that I used was removed in this version and there isn't any fallback logic to reset the background image. Can this maybe be fixed in the first point release so it never happens again please? Pure white desktop backgrounds aren't very pleasant to look at... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Fri, 2019-09-13 at 10:30 +0100, Emmanuele Bassi wrote: > > If a dependency is already in the GNOME SDK then there's no real need > to notify us; unless, of course, the dependency in the SDK is pinned > to a specific version, and you require a later one. > > As I said in the original email, before this detour into whether > humans can or should be automated out of their jobs, this is > definitely more important for dependencies hosted outside of > gitlab.gnome.org. So, for applications and their direct dependencies, that'd mean a mail when the development Flatpak needs a change, but not when the change is related to a dep on gitlab.gnome.org. Which I guess means that non-gitlab.gnome.org dependencies should probably be pinned to specific versions even in our nightly/devel builds. Still, that seems somewhat automatable. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Fri, 13 Sep, 2019 at 10:21, Bastien Nocera wrote: On Fri, 2019-09-13 at 10:12 +0100, Emmanuele Bassi via desktop-devel- list wrote: Not every single problem we have in building a complex project like GNOME can be solved by a script; if it were, we wouldn't need maintainers, and y'all would have been replaced by a script already. This doesn't sound one bit nice or polite. I apologise for the rudeness. I'd like to apologise in advance for the time that I'll also forget to send a mail to the release-team, or wondering why I need to tell the release-team when I bump a dependency that's going to be shipped with the new GNOME anyway, such as GTK or glib. If a dependency is already in the GNOME SDK then there's no real need to notify us; unless, of course, the dependency in the SDK is pinned to a specific version, and you require a later one. As I said in the original email, before this detour into whether humans can or should be automated out of their jobs, this is definitely more important for dependencies hosted outside of gitlab.gnome.org. Ciao, Emmanuele. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Thu, 12 Sep, 2019 at 19:08, Philip Withnall wrote: That sounds like something people are going to forget to do. Would it be possible to use computers to automate this? It's software: anything is possible. As to whether we can automate this **right now**, the answer is: no. I'm not going to block on a feature that may or may not appear in Gitlab's enterprise edition and then may or may not be backported to the community edition we have. Of course, enterprising hackers are strongly encouraged to work on that. From my perspective, I don't think is much to ask to the community of GNOME maintainers to help us on the release team (and all the people that build GNOME components) in ensuring their projects actually build instead of deploying hopes and prayers to users. Ciao, Emmanuele. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Fri, 2019-09-13 at 10:12 +0100, Emmanuele Bassi via desktop-devel- list wrote: > Not every single problem we have in building a complex project like > GNOME can be solved by a script; if it were, we wouldn't need > maintainers, and y'all would have been replaced by a script already. This doesn't sound one bit nice or polite. I'd like to apologise in advance for the time that I'll also forget to send a mail to the release-team, or wondering why I need to tell the release-team when I bump a dependency that's going to be shipped with the new GNOME anyway, such as GTK or glib. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Thu, 12 Sep 2019 at 22:40, Philip Withnall wrote: > On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote: > > On Thu, 12 Sep, 2019 at 19:08, Philip Withnall > wrote: > > That sounds like something people are going to forget to do. Would it be > possible to use computers to automate this? > > > It's software: anything is possible. > > As to whether we can automate this **right now**, the answer is: no. > > I'm not going to block on a feature that may or may not appear in Gitlab's > enterprise edition and then may or may not be backported to the community > edition we have. Of course, enterprising hackers are strongly encouraged to > work on that. > > > The link to the GitLab EE issue was illustrative, not definitive. If it > solves the problem, a cronjob which polls every module’s `/meson.build` and > `/meson_options.txt` files every 30 minutes and uses sendmail to send you > an e-mail about changes would work. > > If you're volunteering to write that script, make it work for Autotools and CMake, then feel free. Of course, a script polling your meson.build files doesn't help us in the slightest when you add a dependency on libfoobar, hosted on a random repository on GitHub, from a specific tag or branch, but only built with a set of specific options because you rely on an optional feature. Not every single problem we have in building a complex project like GNOME can be solved by a script; if it were, we wouldn't need maintainers, and y'all would have been replaced by a script already. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Thu, 12 Sep 2019 at 23:49, Michael Gratton wrote: > On Thu, 12 Sep, 2019 at 22:39, Philip Withnall > wrote: > > On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote: > >> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall > >> wrote: > >>> That sounds like something people are going to forget to do. Would > >>> it be possible to use computers to automate this? > >> > >> It's software: anything is possible. > >> > >> As to whether we can automate this **right now**, the answer is: no. > > It's a shame that build deps can't be picked up automatically from the > meson build config, where it's already specified. > > What about requiring modules include a buildstream config fragment with > a well-known name in their repos, much like how DOAP files are > required, which then gets pulled in by the release team's CI? > If maintainers want to be responsible for their own module's BuildStream recipe, by all means: submit MRs to gnome-build-meta. Adding a BuildStream recipe in your repo doesn't solve anything, though. 1. BuildStream is an implementation detail of how we build the GNOME SDK and releases 2. Applications already have their own build system, a CI configuration, and a flatpak builder manifest; adding yet another place, with a completely different syntax and semantics where your dependencies are listed is a recipe for maintainers just not doing this work 3. GNOME releases are built out of gnome-build-meta; distributing the BuildStream recipes isn't going to fix broken builds in gnome-build-meta Let's not overengineer ourselves out of sending an email. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
