Description of problem: Final f32-backgrounds version isn't in stable repo Current images are shipping f32-backgrounds-base-32.0.0-3.fc32.noarch. Latest final version at bodhi needs simple push to stable f32-backgrounds-32.1.1-1.fc32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ed3d94b26
Proposed as a Freeze Exception for 32-final by Fedora user raveit65 using the blocker tracking app because: Fedora 32 should ship final f32-backgrounds version.
+1 FE in case the current RC doesn't pass muster
reluctantly +1 FE. reluctantly because animated backgrounds are a *giant* pain for openQA. We have a test that literally checks for the correct desktop background; if it's animated that means I have to fiddle around to generate screenshots covering the whole range of animation. Also, some KDE UI elements are translucent, which means they can look different if the background color is different, so that breaks stuff too. I really wish we just didn't do animated backgrounds. Does anyone love this feature?
sigh, in fact, we really ought to jump through some hoops here. This should be treated as a blocker, per Final criterion "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops." But I would strongly suggest we invoke the "late blocker" policy here, because this really didn't show up in time. It wasn't submitted to Bodhi until 2020-04-12 (three days after the already-delayed Final freeze, only four days before go/no-go) and it wasn't proposed as an FE or blocker issue until today. So I'm gonna simultaneously propose this as a Final blocker, vote +1 on it, but *also* vote that we invoke https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases and waive it. (It would also be nonsensical to accept this specific flavor of bug as a blocker for F33 Beta, so I'll say in this case we don't do that either, we just don't accept it as a blocker at all).
Honestly, i am missing the background-extra package.
(In reply to Adam Williamson from comment #3) > I really wish we just didn't do animated backgrounds. Does anyone love this > feature? I do, animated backgrounds are fun! Also +1 to applying late blocker policy. We shouldn't delay release or set off an emergency scramble for wallpaper animation.
(In reply to Wolfgang Ulbrich from comment #5) > Honestly, i am missing the background-extra package. Anyone know what's supposed to pull it in?
+1 FE and +1 blocker, same as adamw Luya, could you please submit a blocker/FE ticket yourself next time so that it can be tracked properly (and pulled into composes)? If this had been filed yesterday things would have been much smoother. Right now it's a difficult decision because on one hand we'd want to pull this in to have the latest backgrounds, but then on the other hand we also want to ship on time. I think I'd lean towards respinning for this, but I think we need to be ready that the new backgrounds package breaks something (as it switches to animated backgrounds etc and we have so many spins, each with their own background handling code). I wouldn't vote against if everybody else feels like we should invoke https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases
Respinning at this point is going to mean a slip. I'm not asking the QA team to hero test a new RC in less than 24 hours just so we get animated backgrounds.
AFAIK, the animated backgrounds will not work in anything other than GNOME. All other desktops can only use one image per resolution, or even only one image overall. Also, what is going to drag in f32-backgrounds-animated? I see that the per-desktop background packages supplement (!?) f32-backgrounds-animated, but do not require or recommend it. (And I think that it would be wrong for the -kde one to drag in the animated version anyway, because it would just be bloat if the animation is not actually implemented for Plasma.) I also think that the artwork designers must be taught to respect freeze deadlines. It is just not acceptable that artworks gets rushes in late for every single release. That also goes for the initial version, which must be delivered before branch time, not when we are rushing to get the Beta out.
+1 blocker, +1 invoking late blocker exception
"Also, what is going to drag in f32-backgrounds-animated?" This is a good question, and I wonder it too. The Supplements seem strange on their face; perhaps they were meant to be Recommends, but if KDE doesn't support animated backgrounds, maybe KDE shouldn't have one at all...
mcatanzaro: re the -extras package - some spins include it in their kickstarts or comps groups (MATE, Cinnamon, and Design Suite), but it's mainly there just for people to install manually if they want.
I'm going to vote -1 blocker on the grounds that I doubt this would pass muster as a "Last blocker at the Go/No Go Meeting". I'm +1 FE if we end up slipping and respinning for something else. The backgrounds that are there today are close to what was desired for the release and cannot be confused for the previous release's background. I'm also going to propose a change to the criteria for Fedora 33.
(In reply to Michael Catanzaro from comment #7) > (In reply to Wolfgang Ulbrich from comment #5) > > Honestly, i am missing the background-extra package. > > Anyone know what's supposed to pull it in? This is only related for Mate-Compiz spin, background-extra package are in comps group of Mate. Well, Mate isn't a blocker desktop. But keep in mind that the background-color will change from green to blue when using xml background, with final background package. So, some users will have a surprise after first update of a fresh installation.
I confused -extras with -animated. I was mainly curious as to how the animated background is supposed to get installed. I think Kevin is correct, the Supplements are all wrong, since they can't be accomplishing anything where they are now. Either the Supplements should be moved (if the goal is to drag in the -animated package) or changed to Recommends (probably simpler way to do the same... but again, not for KDE, or only for desktops that actually support animation) or removed (if the goal is for them to require manual installation, which would be weird). Our previous Fedora releases have not featured animated backgrounds in quite a long time. Is it intended to be provided as an optional subpackage that has to be manually installed? If so, what's the point in putting in all the effort to develop an animation that users will never see? I looked at F31 and I see an animated background was created for it, and was very surprised because it's not there by default.
(In reply to Michael Catanzaro from comment #16) > I confused -extras with -animated. I was mainly curious as to how the > animated background is supposed to get installed. Maintainer here. -extras are reserved for supplemental wallpapers (https://apps.fedoraproject.org/nuancier/) and -animated is the equivalent of -timed for Gnome version of Adwaita. > the Supplements are all wrong, since they can't be accomplishing anything > where they are now. Either the Supplements should be moved (if the goal is > to drag in the -animated package) or changed to Recommends (probably simpler > way to do the same... but again, not for KDE, or only for desktops that > actually support animation) or removed (if the goal is for them to require > manual installation, which would be weird). I thought Supplements fit their roles on complementing the main package per definition of packaging guideline. The documentation was unclear about both Supplements and Recommends. Improvements are welcome. > > Our previous Fedora releases have not featured animated backgrounds in quite > a long time. Fedora 31 was the latest release featuring animated background as option. > Is it intended to be provided as an optional subpackage that > has to be manually installed? If so, what's the point in putting in all the > effort to develop an animation that users will never see? I looked at F31 > and I see an animated background was created for it, and was very surprised > because it's not there by default. -animated was currently optional for legacy reason: file size in PNG. Until F31, whole -animated were easily over 120 MB due to extras folder for resolution format from standard to widescreen. For F32, following GNOME approach, trimming drastically improve the size. The plan is to set -animated as default with proper dependency. The approach will be closer to GNOME. Other DE maintainers are welcome to improve the packaging process on https://github.com/fedoradesign/backgrounds
"I thought Supplements fit their roles on complementing the main package per definition of packaging guideline. The documentation was unclear about both Supplements and Recommends. Improvements are welcome." "Recommends" is a 'soft' version of Requires. A requires B means, when A is installed, B must also be installed. A recommends B means, when A is installed, B will also be pulled in by default, but an admin can remove B and this is allowed, it's not a dependency error. "Supplements" is the *inverse* of "Recommends". "B supplements A" has more or less the same effect as "A recommends B". So, for instance, your 'f32-backgrounds-gnome Supplements: f32-backgrounds-animated' is essentially the same as 'f32-backgrounds-animated Recommends: f32-backgrounds-gnome'. What it means is this: "When f32-backgrounds-animated is installed, f32-backgrounds-gnome should also be installed, but this is a 'soft' dependency and it's not an error if f32-backgrounds-gnome is then removed." Right now, the way the package is set up, if you manually install 'f32-backgrounds-animated', it will also pull in 'f32-backgrounds-kde', 'f32-backgrounds-gnome' and 'f32-backgrounds-mate'. Installing 'f32-backgrounds-kde' or 'f32-backgrounds-gnome' or 'f32-backgrounds-mate' will not pull in 'f32-backgrounds-animated'.
(In reply to Luya Tshimbalanga from comment #17) > I thought Supplements fit their roles on complementing the main package per > definition of packaging guideline. The documentation was unclear about both > Supplements and Recommends. Improvements are welcome. OK, Supplements is a reverse weak dependency. i.e. it is the opposite of Recommends. There is documentation at the bottom of https://rpm.org/user_doc/dependencies.html. For example: %package gnome Summary: Fedora %{relnum} default wallpaper for GNOME and Cinnamon Requires: %{name}-base = %{version}-%{release} Supplements: %{name}-animated = %{version}-%{release} This means "if f32-wallpapers-animated is installed, then also install f32-wallpapers-gnome." Whereas Recommends would be "if f32-wallpapers-gnome is installed, then also install f32-wallpapers-animated." So I would change this particular Supplements to Recommends, and drop the other Supplements. (And thanks Adam for noticing that the Supplements are causing every desktop's subpackage to be installed if the animated version is installed. I missed that.) > -animated was currently optional for legacy reason: file size in PNG. Until > F31, whole -animated were easily over 120 MB due to extras folder for > resolution format from standard to widescreen. For F32, following GNOME > approach, trimming drastically improve the size. The plan is to set > -animated as default with proper dependency. The approach will be closer to > GNOME. Other DE maintainers are welcome to improve the packaging process on > https://github.com/fedoradesign/backgrounds Is the goal for the animated background to become default in F32 (after the first system update, since it is clearly too late for GA)? Or do you just want it installed by default, but not selected by default? FWIW, I like animated backgrounds. They're a bit more interesting than a static image, but, when done well, not distractingly so. So I would support making the animated version the default. Anyway: $ gsettings get org.gnome.desktop.background picture-uri 'file:///usr/share/backgrounds/f32/default/f32.xml' This is the default background. So if that file is not animated, our default will not be animated.
(In reply to Adam Williamson from comment #18) (In reply to Michael Catanzaro from comment #19) Thank you for the explanations. I applied the changed on the spec file and set up the build right away. I will wait for pushing update once 32.1.1 reach stable. > Is the goal for the animated background to become default in F32 (after the > first system update, since it is clearly too late for GA)? Or do you just > want it installed by default, but not selected by default? FWIW, I like > animated backgrounds. They're a bit more interesting than a static image, > but, when done well, not distractingly so. So I would support making the > animated version the default. Anyway: Preferable for F33 for default animated background. > > $ gsettings get org.gnome.desktop.background picture-uri > 'file:///usr/share/backgrounds/f32/default/f32.xml' > > This is the default background. So if that file is not animated, our default > will not be animated. f32.xml will need changes for the next Fedora release.
So to be clear, for F32 the animated background is intended to be optional, not installed by default, and require the sysadmin to manually install some packages and possibly adjust config settings to enable it?
IMHO (as NOT one of those who get or have to vote): * This is clearly not a blocker. * Freeze overrides should not be accepted from maintainers who do not understand the basics of RPM (such as the difference between Supplements and Recommends). The risk of those late changes breaking something is just too high. * Post-release updates should not be allowed to change the default background in any noticeable way. So this: > But keep in mind that the background-color will change from green to blue when using xml background, with final background package. is a no-go, and this change will have to be reverted before the update goes through to the stable post-release updates. Enabling the animated backgrounds by default is also not acceptable.
(PS: Sorry if the above sounds harsh to you, but I am really fed up of the systematic late changes to f*-backgrounds during Beta Freeze and sometimes (like now) also during Final Freeze.)
There's no need to be so harsh or point fingers at anyone. I think we all agree we want the process better, but I do not think this is the right place to discuss that.
I do think the question of whether it's OK for the default background to change substantially with a post-release update is an important thing to discuss. At present, if nothing changes, that's what will happen - we'll release F32 with the same background we've had since Beta, which is a very light blue or almost turquoise color, then 32.1.1 will arrive as a 0-day update and change it to a similar image with a much more blue color. That is, the background will change from this: https://github.com/fedoradesign/backgrounds/blob/v32.0.0/default/f32.png to this: https://github.com/fedoradesign/backgrounds/blob/master/default/f32-02-day.png I don't know if I have a certain opinion on whether we should do that or not, but it certainly seems like a valid thing to consider. If we don't want that change to happen we'll have to unpush the 32.1.1 update and do another new f32-backgrounds, which can still have the non-default animated theme, but would need to restore the image from 32.0.0 as the default static image.
(In reply to Adam Williamson from comment #21) > So to be clear, for F32 the animated background is intended to be optional, > not installed by default, and require the sysadmin to manually install some > packages and possibly adjust config settings to enable it? From what I understood, yes as I found out it was not installed on Workstation as default. I would not mind animated background as deafult. (In reply to Adam Williamson from comment #25) . That > is, the background will change from this: > > https://github.com/fedoradesign/backgrounds/blob/v32.0.0/default/f32.png > > to this: > > https://github.com/fedoradesign/backgrounds/blob/master/default/f32-02-day. > png > Yes, f32.png will be the generated copy of f32-02-day in the package (absolute symlink is broken when building rpm: https://fedoraproject.org/wiki/PackagingDrafts/Symlinks). For that reason, 32.1.1 should be pushed for that release. I already build 32.1.2 with some minor fixes which can wait for the post-release.
Luya: right now, the voting in this bug is fairly clear that we do not want to block on it. That is, if no other blockers are found in RC 1.3, we intend to ship RC 1.3 as-is, with the old background. I'm not going to make that an official declaration yet because we may as well leave it open and decide for sure in the go/no-go meeting, but that is the direction of the voting so far. If we do wind up releasing RC 1.3, the question is whether we think it's acceptable to then change the default background significantly with a post-release update or not.
FWIW I would tend to agree with Kevin on this. Background changes should happen before beta freeze.
The current criteria are specifically written to allow the backgrounds to be done/finalized between Beta and Final. I'm fine with any time *up to Final freeze*...but this late is just too late.
(In reply to Adam Williamson from comment #25) > I do think the question of whether it's OK for the default background to > change substantially with a post-release update is an important thing to > discuss. At present, if nothing changes, that's what will happen - we'll > release F32 with the same background we've had since Beta, which is a very > light blue or almost turquoise color, then 32.1.1 will arrive as a 0-day > update and change it to a similar image with a much more blue color. That > is, the background will change from this: > > https://github.com/fedoradesign/backgrounds/blob/v32.0.0/default/f32.png > > to this: > > https://github.com/fedoradesign/backgrounds/blob/master/default/f32-02-day. > png > > I don't know if I have a certain opinion on whether we should do that or > not, but it certainly seems like a valid thing to consider. If we don't want > that change to happen we'll have to unpush the 32.1.1 update and do another > new f32-backgrounds, which can still have the non-default animated theme, > but would need to restore the image from 32.0.0 as the default static image. Well, i know that my vote doesn't count. But for me fedora color is blue and not green or mint or turquoise color. I never saw another color than blue as background since i use fedora (f9). So, not updating the background with a sero-update is really bad for my taste. .... but maybe i have only a bad taste :)
(In reply to Adam Williamson from comment #27) > If we do wind up releasing RC 1.3, the question is whether we think it's > acceptable to then change the default background significantly with a > post-release update or not. Fair enough. (In reply to Michael Catanzaro from comment #28) > FWIW I would tend to agree with Kevin on this. Background changes should > happen before beta freeze. To be fair, it was my fault as maintainer. Designer team already completed the task two weeks ago but I saw the email too late.
Frankly, I'm in favor of allowing the background to change in a post-release update and noting it in the Common Bugs (and possibly the release announcement) that "due to a bug, the default background image displays in the wrong color, which will be fixed with a release-day update". If we give people a heads-up that the change is coming, I think we'll be okay. Is it ideal from a polish standpoint? No. Is it good enough? I think so.
+1 FE as I think we shouldn't block on animated backgrounds as its not causing any issue with critical functioning of the system. We can add it to known issues in the release notes.
In today's Go/No-Go meeting, we agreed to accept this as a blocker per the Final release criterion "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops." https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-16/f32-final-go_no_go-meeting.2020-04-16-16.59.log.html#l-122
Is this the fixed update https://bodhi.fedoraproject.org/updates/FEDORA-2020-568d90367b? I would be helpful when you guys mention that somewhere for a blocker bug. Than people can test it.....
Opps, my fault, there is no fixed build for f32 at bodhi :/
Side note: I'm wondering which wallpapers the -extras package will contain, since the voting period for f32 supplemental wallpapers isn't even over yet? https://apps.fedoraproject.org/nuancier/elections/
Can you do a new build with the supplements and recommends fixed please? As it stands, we've given a freeze exception to a update with broken Supplements.
Not really. The freeze exception applies to the *bug*, not the update. We still apply reasonable discretion in deciding what to actually pull through the freeze to fix FE/blocker bugs, i.e., we will not pull a broken update just because it's associated with an FE bug.
This Bug is a marked as Blocker bug and double as a freeze exception. So you really don't want to make a new RC release with a fixed update to fix this blocker bug? Honestly, there was/is enough time to do this since this bug was marked as blocker bug after last Go/No-Go meeting from 2020-04-16. Seems you're only searching for reasons not do this instead of doing much as possible to make a good release. @Luya Tshimbalanga Can you please do a new release?
A new RC can only be composed if there is a working package to include in it. The current proposed update, with backwards dependencies, is not suitable.
There are enough provenpackagers around here. Can someone of you do a proper update with fixed Recommends, please?
Note that Luya has already done a successful build in koji, so we only need a provenpackager to prepare the bodhi update.
There's no real need to rush this as we have another blocker to deal with which is more complex. The design team is also looking at maybe tweaking the backgrounds over the weekend; https://pagure.io/design/issue/669 , so we might need to update the package again anyway.
(In reply to Wolfgang Ulbrich from comment #40) > @Luya Tshimbalanga > Can you please do a new release? I just saw the notice. The Recommends fixes are already done. @Michael Catanzaro With the NO-Go status, I will include the default animate background in f32.xml if there is no objection.
animated backgrounds are kind of a big pain in the ass for openQA, but since everyone seems to like them I guess go ahead :( it will likely cause tests to fail in the next RC compose and I will have to patch them. I think we should wait and see if mizmo comes up with any tweaks to the backgrounds before pushing anything here. see the design team ticket.
well, in a sense, I guess it's kinda dangerous to change to an animated background *now*, since we haven't actually tested that feature through the whole cycle.
(In reply to Fabio Valentini from comment #37) > Side note: I'm wondering which wallpapers the -extras package will contain, > since the voting period for f32 supplemental wallpapers isn't even over yet? > > https://apps.fedoraproject.org/nuancier/elections/ For now, a plain dark blue wallpaper as requested by spins maintainers.
(In reply to Adam Williamson from comment #47) > well, in a sense, I guess it's kinda dangerous to change to an animated > background *now*, since we haven't actually tested that feature through the > whole cycle. I understand. Taking advantage of blocker, I will make a scratch build for a quick test.
It's quite unlikely that animated background would cause problems for Workstation (beyond OpenQA). This feature is well-tested and hasn't really changed in the past decade.
Spending time setting animated background, I realize that "/usr/share/backgrounds/f32/default/" will automatically look for animated xml regardless the name $ gsettings get org.gnome.desktop.background picture-uri 'file:///usr/share/backgrounds/f32/default/f32-animated.xml' The test was done with only f32-animated.xml. Thanks Michael for the tip. The benefit is the simplification on Makefile remove legacy codes. Here is the scratch build before I can push the change upstream: https://koji.fedoraproject.org/koji/taskinfo?taskID=43538070
(In reply to Luya Tshimbalanga from comment #51) > Spending time setting animated background, I realize that > "/usr/share/backgrounds/f32/default/" will automatically look for animated > xml regardless the name I don't understand this. > $ gsettings get org.gnome.desktop.background picture-uri > 'file:///usr/share/backgrounds/f32/default/f32-animated.xml' That's not the default value of the setting. Use 'gsettings reset org.gnome.desktop.background picture-uri' to reset to the default value. That's set here: https://src.fedoraproject.org/rpms/desktop-backgrounds/blob/30fa9a57463f84691e8fad698efb39c35f7d9b43/f/desktop-backgrounds.spec#_132 If you want to change the filename of the default background, you'd need to edit that package. > Here is the scratch build before I can push the change upstream: > https://koji.fedoraproject.org/koji/taskinfo?taskID=43538070 Mo was still planning to do a new version of the background this weekend.
(In reply to Michael Catanzaro from comment #52) > (In reply to Luya Tshimbalanga from comment #51) > > Spending time setting animated background, I realize that > > "/usr/share/backgrounds/f32/default/" will automatically look for animated > > xml regardless the name > > I don't understand this. > > > $ gsettings get org.gnome.desktop.background picture-uri > > 'file:///usr/share/backgrounds/f32/default/f32-animated.xml' > It was a test on my desktop until I realized I manually set it. > That's not the default value of the setting. Use 'gsettings reset > org.gnome.desktop.background picture-uri' to reset to the default value. > That's set here: > > https://src.fedoraproject.org/rpms/desktop-backgrounds/blob/ > 30fa9a57463f84691e8fad698efb39c35f7d9b43/f/desktop-backgrounds.spec#_132 > If you want to change the filename of the default background, you'd need to > edit that package. No need. Wearing upstream hat, f32.xml is a symlink of f32-animated.xml so the default value remains the same.
(In reply to Luya Tshimbalanga from comment #53) > > No need. Wearing upstream hat, f32.xml is a symlink of f32-animated.xml so > the default value remains the same. 1. That means we don't have a f32.xml without animation any more, is this really what we want? 2. This is really a last minute change during release freeze, and i don't see that this was the main point in discussion here. Why not shipping different /usr/share/backgrounds/f32/default/f32.xml and /usr/share/backgrounds/f32/default/f32-animated.xml? In result desktop maintainer and user can decide what they want to choose. Well, i can live with (2) for Mate-Compiz spin, but i am more in worry about (1).
The koji build works on my computer, but yeah, why not having a non-animated version, too?
(In reply to Wolfgang Ulbrich from comment #54) > (In reply to Luya Tshimbalanga from comment #53) > > > > No need. Wearing upstream hat, f32.xml is a symlink of f32-animated.xml so > > the default value remains the same. > > 1. That means we don't have a f32.xml without animation any more, is this > really what we want? > 2. This is really a last minute change during release freeze, and i don't > see that this was the main point in discussion here. > Why not shipping different /usr/share/backgrounds/f32/default/f32.xml and > /usr/share/backgrounds/f32/default/f32-animated.xml? > In result desktop maintainer and user can decide what they want to choose. > > Well, i can live with (2) for Mate-Compiz spin, but i am more in worry about > (1). (In reply to Lukas Ruzicka from comment #55) > The koji build works on my computer, but yeah, why not having a non-animated > version, too? IT is not final yet. The koji build is a test. Could you select the non-animated version on backgrounds setup?
@Wolfgang Ulbrich How making a f32-static.xml, a non-animated version, which can symlink on default.xml for MATE?
(In reply to Luya Tshimbalanga from comment #57) > @Wolfgang Ulbrich > How making a f32-static.xml, a non-animated version, which can symlink on > default.xml for MATE? +1 Perfect, and congrats, this is really what i want :) Please do.
Luya, in this case i need a rebuild of mate-desktop package to change our gsettings key to load the image. There wasn't time to change to new Mate default dir because of release freeze. Currently it matches to /usr/share/backgrounds/f32/default/f32.xml So i need a freeze exeption from re-leng to to update the package. And a very quick notification from you when final f32-background package is at bodhi. I hope re-leng team like that plan. Adam and others. What do you think?
I would prefer we don't make any messy changes to this late. If we can enable the animated background by default in a clearly safe way that doesn't involve changing other packages, let's do that. If we can't, let's leave it disabled. I heard from Mo that after looking at the backgrounds and feedback again she decided not to make any changes, so the images we have are the images we should ship. We just need a final version of the update that has the Supplements/Recommends thing fixed, and doesn't make any other problematic changes.
And i think cinnamon and probably others use also /usr/share/backgrounds/f32/default/f32.xml for their settings.
FEDORA-2020-8ed3d94b26 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ed3d94b26
I tested the update. - f32- extra packages are there. - Recommands are fixed - and the final f32 background is included. LGTM. BtW: the animated.xml background looks better than f32.xml. Because it doesn't have a weird `zoom` which makes it more sharp. Switch from f32.xml to animated.xml and compare the size of the crystal, than you will see what i mean ;)
Uf, it does seem like /usr/share/gnome-background-properties/f32.xml has "zoom" set for each image, but /usr/share/gnome-background-properties/f32-animated.xml has "stretched"...maybe that's the difference...
(In reply to Adam Williamson from comment #64) > Uf, it does seem like /usr/share/gnome-background-properties/f32.xml has > "zoom" set for each image, but > /usr/share/gnome-background-properties/f32-animated.xml has > "stretched"...maybe that's the difference... Now it is clear what happened. Setting to scale which properly centre the image and scale to screen for both static and animated backgrounds will do the trick. f32.xml is now a symlink for f32-animated.xml and the old f32.xml is renamed f32-static.xml which symlink is /usr/share/backgrounds/mate/default.xml. So Wolfgang, you do not need to change the default. As noticed, recommends is fixed. Here is another scratch build based on the feedback: https://koji.fedoraproject.org/koji/taskinfo?taskID=43588849 If anything goes well, I will push the changes to the next update.
(In reply to Luya Tshimbalanga from comment #65) > (In reply to Adam Williamson from comment #64) > > Uf, it does seem like /usr/share/gnome-background-properties/f32.xml has > > "zoom" set for each image, but > > /usr/share/gnome-background-properties/f32-animated.xml has > > "stretched"...maybe that's the difference... > > Now it is clear what happened. Setting to scale which properly centre the > image and scale to screen for both static and animated backgrounds will do > the trick. > f32.xml is now a symlink for f32-animated.xml and the old f32.xml is renamed > f32-static.xml which symlink is /usr/share/backgrounds/mate/default.xml. So > Wolfgang, you do not need to change the default. Luya, thanks, if i understand Adam correctly than 32.1.2-1.fc32.1 from https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ed3d94b26 will be used for RC4 and luckily for f32. For f32 release it's Ok for me to use old f32.xml. When your new version will be taken for another RC release than i will use /usr/share/backgrounds/f32/default/f32.xml directory too. I don't like to ask for another freeze exception only for changing to /usr/share/backgrounds/mate/default.xml I can do that after f32 release. Any way, it's good to have a static version of the default xml background.
I tested new f32-backgrounds-32.1.3-1.fc32 version. - It is is possible to uninstall f32-backgrounds-animated-32.1.3-1.fc32.noarch.rpm without the other f32-background packages!!! This breaks the symlink too f32.xml. This shouldn't happen when animated background is default. - new f32.xml (animated) use `zoom`, f32-animated.xml uses `stretched`. Personal i would prefer `stretched` - f32-02-day.png use `scaled`, all other PNGs (f32-01-dawn.png, f32-03-dusk.png, f32-04-twilight.png) for the animated background us `zoom` - f32-static.xml use `zoom`, same as f32.xml which is good. - my personal favourite for f32-static.xml would be using the color from f32-01-dawn.png ;) i think we need more time to test this without any pressure from f32 release.
Hmm, and the new symlink for Mate is broken. [rave@f32 ~]$ ls -l /usr/share/backgrounds/mate/default.xml lrwxrwxrwx 1 root root 28 21. Apr 08:34 /usr/share/backgrounds/mate/default.xml -> ../../default/f32-static.xml
The symlink for Mate should be [rave@f32 ~]$ ls -l /usr/share/backgrounds/mate/default.xml lrwxrwxrwx 1 root root 29 21. Apr 13:26 /usr/share/backgrounds/mate/default.xml -> ../f32/default/f32-static.xml
> - It is is possible to uninstall f32-backgrounds-animated-32.1.3-1.fc32.noarch.rpm without the other f32-background packages!!! > This breaks the symlink too f32.xml. This shouldn't happen when animated background is default. Well, f32-backgrounds-kde should NOT drag in f32-backgrounds-animated because animated backgrounds are not supported under Plasma (and I guess the same goes for Mate).
The dependencies of f32-backgrounds-kde look OK to me (Requires: f32-backgrounds-base), which is static (not animated). For GNOME and MATE, there is a Recommends: f32-backgrounds-animated. I guess the question is whether that should be a Requires (and also why -mate has that Recommends when the default is supposedly the static version).
(In reply to Kevin Kofler from comment #71) > The dependencies of f32-backgrounds-kde look OK to me (Requires: > f32-backgrounds-base), which is static (not animated). > > For GNOME and MATE, there is a Recommends: f32-backgrounds-animated. I guess > the question is whether that should be a Requires (and also why -mate has > that Recommends when the default is supposedly the static version). The Recommends for -mate is Ok for the moment to be sure that animated-backgrounds are installed, because of the current default Mate settings. [rave@mother ~]$ gsettings get org.mate.background picture-filename '/usr/share/backgrounds/f32/default/f32.xml' I don't wanna change that before f32 release. But yes, you're are right in general and for f33 release. Btw. I tested Fedora-MATE_Compiz-Live-x86_64-32-1.4.iso which comes with the correct f32.xml background.
Workstation WG discussed this in today's meeting (as part of https://pagure.io/fedora-workstation/issue/140) and requests that the animated backgrounds be dropped from default F32 Workstation install.
We can try animated backgrounds again for F33 if we have an increased image size limit (likely). But for F32, reverting the last-minute change is required.
Sorry, this was my fault, as explained on the ticket I got tripped up by power-of-2 bytes vs. power-of-10 bytes... Luya, we seem to have had a git crash trying to change this at the same time. My change seems to have gone to F32 branch, yours to master. Can we please use mine? Yours includes an unnecessary 'code optimization' change from upstream which has not been properly tested, and does not actually remove the Recommends, which is what we need. My change took the known-to-be-more-or-less-working 32.1.2-1 and just dropped the Recommends.
Will the backgrounds work as is without the Recommends or are changes to the symlinks in -gnome and -mate (to make the static ones the default again) needed too?
We never shipped the symlink changes to an F32 official build. The animated backgrounds were never made default there, only *included on the images* as a non-default choice (which caused the size problem). All the other changes Luya talked about are in 32.1.3+.
(In reply to Adam Williamson from comment #75) > Sorry, this was my fault, as explained on the ticket I got tripped up by > power-of-2 bytes vs. power-of-10 bytes... > > Luya, we seem to have had a git crash trying to change this at the same > time. My change seems to have gone to F32 branch, yours to master. > > Can we please use mine? Yours includes an unnecessary 'code optimization' > change from upstream which has not been properly tested, and does not > actually remove the Recommends, which is what we need. My change took the > known-to-be-more-or-less-working 32.1.2-1 and just dropped the Recommends. I noticed that and adjust it on the main branch. The fix has in which includes your latest commit. Would you complete the change as I have to leave now as the build in on the way? Thanks
Of course I will check after work.
openQA looks like it confirms the 32.1.2-2 build I did should be good: -rw-r--r--. 1 geekotest geekotest 2020130816 Apr 21 02:22 00581960-Fedora-Workstation-Live-x86_64-FEDORA-2020-8ed3d94b26.iso -rw-r--r--. 1 geekotest geekotest 1964244992 Apr 21 17:03 00582864-Fedora-Workstation-Live-x86_64-FEDORA-2020-8ed3d94b26.iso the first is the live image it built with the 32.1.2-1.2 build which had the Recommends, the second is the live image it built with the 32.1.2-2 build which does not have the Recommends. And the correct backgrounds show up in the KDE and GNOME tests.
FEDORA-2020-8ed3d94b26 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8ed3d94b26` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ed3d94b26 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hmm, i tested f32-backgrounds-32.1.2-2.fc32 again. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8ed3d94b26 https://koji.fedoraproject.org/koji/buildinfo?buildID=1496538 Now the background has a pink point in the middle. Adam or any other, please recheck the update before making a rc5. See attachment
Created attachment 1680669 [details] background with pink color point!
That's how it's supposed to look. The pink light has been in every "final" build so far.
(In reply to Adam Williamson from comment #84) > That's how it's supposed to look. The pink light has been in every "final" > build so far. Which `every final build` you mean? Every final build from every fedora release? The light blue background combined with this ping spot is not very nice. With a dark blue background color it might be OK. You can't combine every color tone..... Well, every taste is different, but this isn't mine.
I mean every build since f32-backgrounds-32.1.1-1.fc32 , where the final versions of the images themselves first appeared.
(In reply to Adam Williamson from comment #86) > I mean every build since f32-backgrounds-32.1.1-1.fc32 , where the final > versions of the images themselves first appeared. Ok, does this fact make the background better? I am sorry that i didn't saw this before in this last-minute f32-background-chaos. I hope that we make it better for the next release and start with a first f33-background release before f33 branching.........Hello design team :)
"Ok, does this fact make the background better?" like you said, every taste is different. You can read more about the design choices behind the background images at https://pagure.io/design/issue/669 .
If you ask me, the whole background looks like a scanned, low-quality printing. The dithering looks like a high-dpi scan of a low-dpi printing. The pink spot looks as if the printer had a problem with its cyan cartridge, printing magenta instead of blue. And even without the "broken printer" association that those "artistic effects" invoke in me, they both just look "wrong".
I like the idea of the image in general and i respect the idea from the artist, because I am a artist for myself. And i don't want to review it like other people in fedora-devel list shit storm. But the dithering on the surface of the image make it hard to view with clear modern HIDPI monitor resolutions. And the pink spot on light blue background conflicts with basic color art rules, IHMO. But Ok if you think that is best what fedora can present, go ahead. I will stop boring you and at least it is is only LINUX. The world has other important problems now.
(In reply to Wolfgang Ulbrich from comment #90) > I like the idea of the image in general and i respect the idea from the > artist, because I am a artist for myself. > And i don't want to review it like other people in fedora-devel list shit > storm. > But the dithering on the surface of the image make it hard to view with > clear modern HIDPI monitor resolutions. > And the pink spot on light blue background conflicts with basic color art > rules, IHMO. The fix for the zoom is on 32.1.3. When Fedora 32 is released, the update will come shortly. You can test with Rawhide version on https://bodhi.fedoraproject.org/updates/FEDORA-2020-179e9d1517 It is a learned lesson for all of us as contributors. I will take responsibility for the last time change. Let use that experience to improve Fedora 33.
Here are gnome-software builds to use the final F32 artwork (for the distro upgrade banner) when upgrading to F32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9fadf854a4 (F31) https://bodhi.fedoraproject.org/updates/FEDORA-2020-06b6a23d9c (F30)
FEDORA-2020-8ed3d94b26 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.