Overview
Request 458967 accepted
- Created by MargueriteSu
- In state accepted
Request History
MargueriteSu created request
leaper added leap-reviewers as a reviewer
leaper accepted review
ok
jberry_factory added as a reviewer
Being evaluated by staging project "openSUSE:Leap:42.3:Staging:adi:117"
jberry_factory accepted review
Picked openSUSE:Leap:42.3:Staging:adi:117
lnussel_factory accepted review
Removing from openSUSE:Leap:42.3:Staging:adi:117, re-evaluation needed
lnussel_factory added factory-staging as a reviewer
Requesting new staging review
lnussel accepted review
lnussel_factory added as a reviewer
Being evaluated by staging project "openSUSE:Leap:42.3:Staging:adi:117"
lnussel_factory accepted review
Picked openSUSE:Leap:42.3:Staging:adi:117
lnussel_factory accepted review
ready to accept
lnussel_factory approved review
ready to accept
lnussel_factory accepted request
Accept to openSUSE:Leap:42.3
openSUSE:Factory/libpinyin@24 -> openSUSE:Leap:42.3/libpinyin
expected origin is 'SUSE:SLE-12-SP2:GA' (changed)
the submitted sources are in or accepted for Factory
request needs review by release management
package comes from SLE. Any strong arguments to deviate from SLE here? Or are there arguments to request this upgrade also in SLE?
@lnussel libpinyin, fcitx-configtool, fcitx-libpinyin, kcm5-fcitx forms one update stack this time. so I just reply one time in this SR.
Quote the email sent from Dr. Weng Xuetian to fcitx-announcement mailing list:
Can you please share the current SLE maintainers for fcitx with me? Zhao Qiang?
SLE 12 took fcitx based on my advice back then. so I suppose it's still maintained by SUSE Desktop Team in Beijing.
Here's how we worked before: I made updates/fixes in openSUSE, they took it. If they found additional bugs, they fixed it in SLE and submitted the fix to openSUSE too. So they don't follow upstream but openSUSE if their policy is still the same.
That's why you didn't receive updates from SLE side yet because they didn't subscribe to fcitx-announcement list. They just trust me and wait for my movement. Because the core developer Dr. Weng is my friend and I'm also one of the upstream developers.
The above saying need to be confirmed by SLE maintainers because it was how things work in the old times.
So, using SLE packages here for fcitx stuff will just add some delay because anyway SUSE Desktop Team will fix both sides, no matter if the packages are theirs.
And answer for your question: Yes, this update stack needs to land in SLE too.
Marguerite
bad format...:-(
yes, @qzhao is still maintainer.
okay, let's just at @qzhao and see his comment. I'm okay with both solutions, either switch to openSUSE or update from SLE side, because the SLE maintainer is also active on OBS too. Just some work for him to catch up if the 2nd solution is picked.
I've also opened https://features.opensuse.org/322611 for SP3 get it on the radar there.
If i understand correctly, You want to update qt, that caused the update of qt-webkit, then fcitx, so ibus-pinyin should update finally.
Unfortunately, under the edition control requirement, SLE can not accept the update of libpinyin in SLE12-SP3. I will call it "SP3" in short.
1, SP3 was supposed as a maintenance update(product department make this decision), means it only accept fix patches, but no update.
2, SLE-13(maybe some time we will have it) will accept package update.
3, Yes, We can get some benefits from the better QT and fcitx, but SLE default component is gnome and ibus. And this update will cause lots of quality assurance works, cause we must confirm all the things safety. Our customers can not tolerate any little risk of broke down.
4, If it's very necessary, a fix is recommended, but please do not update.
5, Although i also like update better by private, that will reduce a lot of my working load, but product rules are there.
Just forgot 1 thing, sorry ! You can do this update in TumbleWeed, TumbleWeed is a rolling release whose strategy is different from Leap. And more and more people are using tumbleweed, include myself; :-)
Hi,
Thanks for being here with us.
A briefing of what I want to do:
I want to update those four fcitx packages in Leap 42.3 (may update the 42.1/42.2 ones through update channel too)
But @lnussel told me fcitx related stuff are SLE origin.
So either update from SLE or switch origin to Tumbleweed.
The 1st solution means you have to catch up with the commits I made and push them to SLE.
The 2nd solution means your future fixes for those packages from the SLE side has to be manually forwarded to openSUSE.
it will not automatically synced to Leap 42.3. So you can't just fix things in SLE. you have to do OBS SRs to M17N and prepare updates for those packages through OBS maintenance.
But since my previous sentences just perfectly described what you used to do. You always manually send fixes to M17N and I can always see your SRs for things affect both SLE and openSUSE. I suppose this switch won't affect your workflow much.
Of course, there's a 3rd solution, that is, leave 42.3 the same version as 42.2 (it means, no update).
But according to upstream, this is not encouraged. it means everything is on your own shoulders. Upstream said, the webkit of qt4 is dead and unmaintained, so use qt5's webengine now to do things used to be done by qt4's webkit.
So I brought you here to discuss which solution we should choose.
Answers to the things you concern:
No. I didn't intend to touch the Qt stuff.
So I don't think ibus-libpinyin will be affected. And if it is affected, it should be from the libpinyin update, not from thee fcitx stuff.
So basically, if SLE has libqt5-qtwebengine. it's doable.
And it'll prevent fcitx-libpinyin be affected by the unmaintained thus insecure qt4-webkit.
Or better: if we can build the new fcitx-libpinyin with the libpinyin 1.6.x, it'll become a fcitx only problem.
Well...it's not a question about 'better' because no actual Qt updates here...both the old packages and the new ones rely on the Qt versions that SLE has. You can consider it as a refactoring based on existing stuff.
It's not a fix. but using an alternative to avoid something insecure.
So please re-evaluate if you can update those four packages (or three if the new fcitx-libpinyin can be built with the existing libpinyin).
And if you can't do things from the SLE side, please think about if you accept a switch for those Leap packages to Tumbleweed versions (personally I see no blockage or trouble made to you with this solution, because as I see it will not affect your workflow either for the SLE or for the openSUSE)
So actually here there're two questions:
Marguerite
update doable from SLE? If your target is to update 4 fcitx packages with ibus-pinyin and libpinyin orignal version, it's ok, you can update. If you must update ibus-pinyin together, it's impossible, because product department will not allow it.
If not, okay to use Tumbleweed version? Yes.
fcitx was a bit of a smoke grenade here. Updating fcitx is no problem as SLE doesn't care. The problem is libpinyin. Version 1.7.0 changes soname, so there is a potential that it breaks stuff. So I'd rather do that. Is 1.7.0 really needed by fcitx?
soname change, comes from sle
It would appear this is holding up adi:117. Could drop sr#458968 (one that depends on this SR) from that batch, but probably not desirable given that plug may no longer work. Presumably the maintainer can indicate a direction.
please update libpinyin also. SLE maintainer agrees to the switch.
could you please submit 1.6.0 instead and see if that works better? chances for an upgrade to that one are higher
@lnussel unluckily it failed...https://build.opensuse.org/project/show/home:MargueriteSu:branches:openSUSE:Leap:42.3
after thinking about this way too long we will give it a try. Please make sure to test thoroughly when in.