Loading...
Request History
manfred-h created request
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
staging-bot added openSUSE:Factory:Staging:adi:1 as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:1"
staging-bot accepted review
Picked "openSUSE:Factory:Staging:adi:1"
licensedigger accepted review
ok
dimstar accepted review
dimstar_suse accepted review
Staging Project openSUSE:Factory:Staging:adi:1 got accepted.
dimstar_suse approved review
Staging Project openSUSE:Factory:Staging:adi:1 got accepted.
dimstar_suse accepted request
Staging Project openSUSE:Factory:Staging:adi:1 got accepted.
not sure if this is doing what's expected:
seife@server:~> cat /etc/os-release NAME="openSUSE Leap" VERSION="15.4" ID="opensuse-leap" ID_LIKE="suse opensuse" VERSION_ID="15.4" PRETTY_NAME="openSUSE Leap 15.4" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:15.4" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap" LOGO="distributor-logo-Leap" seife@server:~> rpm --eval %{is_opensuse} %{is_opensuse}Now this is really strange! I have a test rpm at
https://build.opensuse.org/package/show/home:manfred-h:mozilla/debug-build
which I wrote years ago to be able to find out actual values of some macros. The following code:
cat << EOF is_opensuse = "%{is_opensuse}" EOF
clearly shows
is_opensuse = "1" for Leap 15.4
https://build.opensuse.org/package/live_build_log/home:manfred-h:mozilla/debug-build/openSUSE_Leap_15.4/x86_64
Isn't it supposed to be like that? I mean, we use a similar test in lots of other packages to distinguish between Leap, Tumbleweed and SLE.
To me it does what is expected. I check here: See Recommended section for both:
https://build.opensuse.org/package/binary/X11:xfce/patterns-xfce/15.4/x86_64/patterns-xfce-xfce-20230212-lp154.45.1.x86_64.rpm
vs
https://build.opensuse.org/package/binary/X11:xfce/patterns-xfce/openSUSE_Tumbleweed/x86_64/patterns-xfce-xfce-20230212-45.1.x86_64.rpm
If it works as intended, that's of course fine with me ;-) I was just double-checking after the previous tries with version mismatches.
No worries :). It indeed took a few trials to get it right
It might be set in OBS prjconf only and not rpm-config-SUSE.
Results in an openQA test issue that needs to be addressed: https://progress.opensuse.org/issues/124364
(gpk-update-viewer has been removed from a default xfce install with this SR; so openQA should not use it anymore)
I'm not sure why exactly you opted to go that route - were there recent issues reported? pk zypp backend has had special code for TW for a couple years by now to transparently switch to dup internal. So in most cases there should be little to no issues (of course we still recommend to only use zypper)
There was no issue reported, but it seemed misleading to keep a default for Tumbleweed that we do not recommend. We could of course keep it around to keep openQA happy but how reliable is it for a Tumbleweed update?
well, let's say i've been brave enough to use offline updates quite a bit lately and it never failed me :) and that's all PK based (as said, PK/zypp does an auto-fallback to dup mode on TW - in most cases this should catch the weirdness and do the right thing)
of course we can also adjust openQA to use zypper in the xfce case - just needs to be done
offline update does not work with Xfce... we would need to patch xfce4-session and I am not sure how exactly to make it work. But in theory I would much prefer that way of updating over the updating live via PK.
We could retract the update until I write a openQA test first to use zypper, I would just need some time to do it
the QA fix would be in line https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/63c68aa424c1c6636018675198af17bedd9069a5/lib/main_common.pm#L3105
i.e. just take xfce out of the list of guiupdate applicable - then openQA falls back to zypper
Thanks! :D
Just to buy some time I have restored gnome-packagekit so that openQA does not fail the test. Will find a better solution later, perhaps by implementing offline updates. https://build.opensuse.org/request/show/1065455