Bug 1049053

1.6.1 is already out: http://blog.qupzilla.com/2014/01/qupzilla-161-released.html

1.6.3: http://blog.qupzilla.com/2014/02/qupzilla-163-released.html

Is this package unmaintained or what is going on here?

No, people tend to have real live and jobs.

So, turns out the latest version does not build. I spent some time on fixing the qmake for the kwallet plugin, and now there is an issue with the locales. 3 of them are generated but not packages. This looks like a bug in rpm's find_lang.sh to me.

You can find my latest work in git at 
http://pkgs.fedoraproject.org/cgit/qupzilla.git

I think I got the locale-handling fixed (worked-around is more like it), but at least it builds now, 
rawhide:  http://koji.fedoraproject.org/koji/taskinfo?taskID=6550161

christoph,
I can help merge and do builds for prior releases too if you'd like. (or leave it to you, whichever you prefer).

Thanks a lot, Rex.

Štefan, kamikazow, is there anything that justifies/requires an update for F19 and F20? Is there any major bug that gets fixed or something else?

It's a new minor version with many bugfixes. What would justify that F20 does not receive it?
With the new specfile 1.6.3 builds just fine under F20. F19 is compiling while I'm writing this: https://build.opensuse.org/package/show/home:KAMiKAZOW:Fedora/qupzilla

(In reply to Markus S. from comment #7)
> It's a new minor version with many bugfixes. What would justify that F20
> does not receive it?

1. If it does not fix anything important.
2. http://fedoraproject.org/wiki/Updates_Policy

Created attachment 867448 [details]
QupZilla 1.6 for F19 and F20

While I think that in this case the KDE SIG's update policy applies anyway (i.e. one bigger update per Fedora cycle), IMO the following fixes are important enough to justify the update even if it doesn't apply:

* Security: workaround for servers not understanding TLSv1 handshake
* Privacy: Disabled AdBlock rules can now be enabled

The CHANGELOG entry "fixed: issues detected by scan.coverity.com" does not specify how grave those issues were.

In case you don't find these fixes important enough, feel free to point other asking users to my Fedora repo (see attachment).

As a sidenote: Considering that Fedora 21 aims at Wayland, it's likely a sane approach to build the Rawhide version of QupZilla with Qt 5.x instead of Qt 4 (QupZilla was ported to Qt5 over a year ago). The F20 version should obviously stay at Qt4.

@Christoph: This is a leaf application, so, frankly, I'd push the update all the way down to F19, and I'm not alone with that in the KDE SIG. But of course, it's your call, you're the primary maintainer.

@Markus: No, we don't build applications against Qt 5 yet when they can build just fine against Qt 4. Our KDE environment is still Qt-4-based, so Qt 4 apps will necessarily look more integrated. In this particular case, KWallet integration is also affected (can't link KDE 4 KWallet libraries and Qt 5 in the same application, because the KDE 4 KWallet libs are linked to Qt 4). The only app in this situation that we're considering building against Qt 5 ASAP is Qt Creator, because its new features only work with Qt 5. Anything else should just be built against Qt 4 for now (and libraries need to be built for both).

@Kevin:
Plasma 2.0 will be released in June, Fedora 21 in August. According to a blogpost by Dan the plan is to ship the KF5/Qt5-based KDE stack in F21 next to the 4.x stack.
I didn't see a mailing list post or similar informing of any change of plans…

The KF5/Qt5 stack, sure, but that's just the libraries, the Plasma 2 workspace is not part of that. That it will release as soon as June is news to me, we can consider it for F21 then, but it will be tight. We had a longer slack period for KDE 4.0 in F9, and we still only barely made it to release with it. A part of the slack period was eaten up by upstream schedule slippage, the rest by the fact that 4.0.0 honestly wasn't shippable, only 4.0.3 with some fixes backported from 4.0.4 and some workarounds patched in by us really was (and that still had some clearly noticeable bugs).

Now of course, everyone is saying that Plasma 2.0 is different from KDE 4.0, but please consider that:
* The main problem with KDE 4.0 was the workspace, not the applications. So the fact that Plasma 2.0 only includes the workspace (and the libraries, because it means switching from a Qt4/kdelibs4-based Plasma to a Qt5/KF5-based one, even if we ship both sets of libraries either way) does not help.
* Plasma is probably the part of the core KDE software (as in, what was included in the coordinated KDE Software Compilation releases) that is changing the most in the KF5 world. Not only are all the remaining C++/QWidgets plasmoids being ported to QML, but it is also a switch from QML 1 to QML 2, which is very similar as a language, but has a very different implementation. In addition, the libplasma library also got a big API rework.
* According to Dan Vratil (who did the KF5 and Plasma 2 builds in COPR), Plasma 2 is currently not fully usable. I think the state is similar as KDE 4.0 was early in the F9 cycle. Importing it now would likely mean totally breaking Rawhide for KDE Plasma users, as we did when we imported the 4.0 prereleases in pre-F9 Rawhide. But nowadays, breaking Rawhide that way is no longer tolerated.
* The packages also need to go through Fedora package review. We don't even have KF5 through review yet, let alone Plasma 2.
* If F21 really releases in August, the feature freeze will be around June. So importing a major release of the Plasma workspaces in June is scary, especially considering that it could slip upstream (like KDE 4.0 did).

So I think Plasma 2 for F21 is very tight, and I'm the only one who still defends the decision to ship 4.0 in F9, so if *I* am saying that it's tight, the rest of the SIG will probably say that it's impossible. Sorry.

Oh, and I forgot: If what you are actually proposing is to ship BOTH Plasma 1 (kde-workspace 4) and Plasma 2 alongside, then sorry, but that is not possible. Only the libraries can be installed in parallel. For the workspaces, it's either or, as long as we're talking about installations to /usr (as required for official Fedora packages). The Plasma 2 preview packages in COPR are built to reside in a separate prefix, which is not an acceptable solution for Fedora packages. (By the way, this actually doesn't work right now without also installing the libraries to a separate prefix, so currently Plasma 2 from COPR doesn't start up at all. Reportedly, a fix was recently committed upstream, so that should soon be fixed. But it's still a solution that is only acceptable for unofficial preview packages.)

1.8.3: http://blog.qupzilla.com/2014/10/qupzilla-183-released.html

v1.8.6 … https://github.com/QupZilla/qupzilla/releases/tag/v1.8.6

*** Bug 1164392 has been marked as a duplicate of this bug. ***

Hi Helio,
I saw your commit request at bodhi. So I try to assign this bug to you. Are you investigating here?

Latest version 1.8.6 also builds properly with Qt5. I've tested the behavior, and it is slightly better than the Qt4 one: less crashes in stress situations, better integration with webkit. See the latest files:

Spec URL: https://mariobl.fedorapeople.org/Review/SPECS/qupzilla.spec
SRPM URL: https://mariobl.fedorapeople.org/Review/SRPMS/qupzilla-1.8.6-2.fc21.src.rpm

It is somewhat odd that the package has quite a few co-maintainers, but in fact nothing happened last months. However, I've also applied for becoming yet another co-maintainer, maybe it helps to get the package really updated one day ;)

Keep in mind, we also preach "features, first", not only "freedom, friends", but at least in this special case actually we are far behind other distributions which want to be bleeding edge ... Moreover, the upcoming LxQT spin needs a default browser. Qupzilla would be the best candidate, in any case the latest stable version, which is more stable than ever before, and the Qt5 GUI perfectly matches the needs of the current LxQT v0.9.0.

Updated to 1.8.6 with Qt5 on Fedora 21, 22 and Rawhide ( a.k.a. 23 )
Pending decision to update on F20 using Qt4

Mario, the main reason nothing happened was the qt4 vs. qt5 problem, in particular KDE 4 KWallet integration.

Helio, what did you do about this? IIRC we agreed you discuss this with Rex and the KDE SOG, but I haven't heard anything from you or anybody else.

helio asked my opinion on doing an update on irc yesterday, and I agreed doing an update would be a good thing in general.  We did not specifically discuss the topics of qt4/qt5 or kwallet (that I recall).

(In reply to Christoph Wickert from comment #21)
> Mario, the main reason nothing happened was the qt4 vs. qt5 problem, in
> particular KDE 4 KWallet integration.
> 
As I already wrote, v1.8.6 compiled with Qt5 is the most stable Qupzilla I've ever seen. Actually I test it from its ancients on, but I was never satisfied regarding stability and features. Although I use it under KDE, I don't use any KDE "bindings". Let's publish the Fedora package as a pure Qt browser without any KDE dependencies. The KDE folks don't need a third KDE browser behind Rekonq and Konqueror, but LxQT needs a pure Qt one. Otter-browser doesn't seem to be stable enough for the default role, so only Qupzilla remains. And by the way, its Firefox-like approach could be very attractively for people who are willing to get rid of Firefox. But we shouldn't force them to install any KDE libs or anything similar.

There was an impossibility to have both qt5 and Qt4 binaries simultaneously without a hideous hack, and this was not desired, so i modified minimal on the original package, push Qt5 ( more stable ) for all distros f21 and higher and Qt4 version for f20 and less.
I already received complaints to not have a Qt5 release on f20 as well, but i decided be more conservative unless some high powers ask me to do it.

About kwallet, new version handles itself the information, and i liked the new native process, including the fact that this is better for lxqt in general not depends on whole framework. 
Since i'm using plasma 5 as my default environment, i can check over the new kwallet to assure is not too much ugly intruder to use as standalone.

I tested the new build alredy on f21 (my personal work machine ), and f22. not have rawhide here, but yet, is rawhide.