Bug 196302 - [MAINTAINER] www/qupzilla: Update to 1.8.5, Create separate Qt4 and Qt5 variants
Summary: [MAINTAINER] www/qupzilla: Update to 1.8.5, Create separate Qt4 and Qt5 variants
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Guido Falsi
Keywords: needs-qa
Depends on:
Reported: 2014-12-27 17:18 UTC by Matthew Rezny
Modified: 2015-01-18 23:42 UTC (History)
2 users (show)

See Also:

www/qupzilla update to 1.8.5 and split into -qt4 and -qt5 variants (21.95 KB, patch)
2014-12-27 17:18 UTC, Matthew Rezny
no flags Details | Diff
cleaned up patch for 1.8.5 update and port split (4.77 KB, patch)
2015-01-13 10:59 UTC, Matthew Rezny
no flags Details | Diff
Modified diff (22.95 KB, patch)
2015-01-17 12:23 UTC, Guido Falsi
madpilot: maintainer-approval? (rezny)
Details | Diff
improved patch (5.82 KB, patch)
2015-01-18 01:55 UTC, Matthew Rezny
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Rezny freebsd_committer 2014-12-27 17:18:26 UTC
Created attachment 150994 [details]
www/qupzilla update to 1.8.5 and split into -qt4 and -qt5 variants

QupZilla 1.8.5 release finally adds an option to disable use of SSLv3 entirely.

The attached patch is from svn diff after `svn mv www/qupzilla www/qupzilla-qt4` and `svn cp www/qupzilla-qt4 www/qupzilla-qt5`

Newer QtWebKit used by Qt5 variant supports WebGL and spellcheck also works. However, KWallet integration is commented out in Qt5 variant until KF5/KDE5 lands in the ports tree.
Comment 1 Matthew Rezny freebsd_committer 2015-01-13 10:59:24 UTC
Created attachment 151547 [details]
cleaned up patch for 1.8.5 update and port split

svn diff output included a removal of all the files in old port dir that should have been copied and moved, so the patch has been cleaned up. The new patch file is just the changes that would follow the svn mv and svn cp commands previously noted.
Comment 2 Guido Falsi freebsd_committer 2015-01-17 12:23:13 UTC
Created attachment 151765 [details]
Modified diff


I have tested your patch and fixed a pair of minor problems:

- Moved around some keywords to avoid portlint warnings. Please always use portlint on a port before submitting patches.

- The QT5 version of the port missed two USE_QT5: concurrent and sql-sqlite3_run (it fails to start without the last one)

- Both ports missed a file in the plist: %%DATADIR%%/themes/linux/images/goto.png

Can you test thee ports and approve this revised patch?

Comment 3 Matthew Rezny freebsd_committer 2015-01-18 01:55:02 UTC
Created attachment 151782 [details]
improved patch

Thanks for reviewing. I have updated my patch based you your feedback.

Neither concurrent nor sql-sqlite3 are mentioned in PH 6.11.2. The former appears to be new to Qt5, but the latter was present in Qt4 and should be needed just the same for both ports. I had all Qt deps present due to installing the meta-ports so hadn't noticed the dependency on concurrent, the Qt5 port ran just fine for me using the same Qt deps as the Qt4 port. The dependency on sqlite3 in both ports was likely missed because that would have already been pulled in on most systems. I added the sqlite3_run dep in both ports to be on the safe side.

The one file added to pkg-plist should have been in original patch, added now. I noticed that in addition to re-ordering bits of the Makefile to quiet portlint, you also changed the MASTER_SITES from a https:// to a http:// address. I see no reason for that change.
Comment 4 Guido Falsi freebsd_committer 2015-01-18 09:50:26 UTC
I forgot to mention the MASTER_SITE change, sorry.

portlint generates a warning with an explanation about https download URLS:

WARN: Makefile: no ftp/http mirror in MASTER_SITES for users behind a proxy.

it is suggested that at least one plaint http/ftp site is provided for download for users with restricted internet access. Since https isn't mandatory for github I changed that.

It is just a public distfile, there's no personal information involved, is there a specific reason why https should be preferred?
Comment 5 Matthew Rezny freebsd_committer 2015-01-18 12:05:31 UTC
People still use proxies that can't do HTTPS? *sigh*

The MASTER_SITES URL got changed to GitHub when upstream changed the distribution tarball to xz. I put the https URL because that's what I got from upstream on IRC.

I think everthing should be going over secured channels regardless of the purpose. Instead of asking why use HTTPS, I must ask why NOT use HTTPS? This is a public distfile, nothing secret inside. In theory using HTTPS and verifying the certificate adds a level of assurance the sources have not been tampered in transit. Are broken proxies still a real issue for more than a few odd cases? If so, then a general solution is needed that allows use of HTTPS and that is a matter outside the scope of this partcular PR.
Comment 6 Guido Falsi freebsd_committer 2015-01-18 20:18:50 UTC
(In reply to matthew from comment #5)

I was not making a statement about SSL with my question, I'm just applying an existing policy(with which I happen to agree, but this is irrelevant). The policy is to avoid, if possible, https for distfiles.

Regarding your statement about tampering with the distfile, please note that the ports tree performs a size check and then a SHA256 checksum, so the distfile is checked for integrity anyway before performing decompression..

Anyway since you insist ion it, and the port already uses SSL I'll leave it as is and commit your last patch.
Comment 7 Guido Falsi freebsd_committer 2015-01-18 20:21:51 UTC
Committed. Thanks!
Comment 8 commit-hook freebsd_committer 2015-01-18 20:22:22 UTC
A commit references this bug:

Author: madpilot
Date: Sun Jan 18 20:21:35 UTC 2015
New revision: 377345
URL: https://svnweb.freebsd.org/changeset/ports/377345

  - Create separate QT4 and QT5 ports for www/qupzilla
  - Update to 1.8.5

  PR:		196302
  Submitted by:	matthew at reztek.cz (maintainer)

Comment 9 Matthew Rezny freebsd_committer 2015-01-18 23:42:09 UTC
(In reply to Guido Falsi from comment #6)

Thank you very much for committing.

I did not mean to insist on HTTPS, just to seriously question the reason for HTTP. If it's policy, then the port should conform for now. It is possible to just list both URLs to allow fetch to do a HTTP request if HTTPS has failed, but for those who want TLS that is insecure in that it allows a forced fallback to unencrypted.

Seperately, I shall think about how to better handle this. The SHA sums are a single layer of security, TLS downloads are another.