Some more, very specific, questions...

[Martii]

1. What is @nowrep 's exact $ uname -a so we can match that on a machine (or VM) e.g. what's the root Linux distro?
2. Since there is a ppa for Ubuntu/Kubuntu... why not a nightly from @nowrep ?

Trying to get Kubuntu to handle Qt 5.6 isn't exactly fun considering even one of the most "popular" distros out there isn't on the "bleeding edge" of Qt and generates a few issues.

Rather than fight dependency hell, as the phrase goes for eons, it would be helpful to have 1 and 2 available at least for testers. e.g. "Developed on such and such and ported with such and such platforms" and of course the name for the ppa package.

Thanks in advance for your patience and answers. :)

[nowrep]

1. That won't help you. I use various Qt versions (from repo, from qt-project.org and also self-built).
2. Why not a nightly from you? :D It takes time to manage PPA .. I think I will even stop publishing new releases on my PPA.

There is a Qt 5.6 PPA for Ubuntu, I use it on CI (https://github.com/QupZilla/qupzilla/blob/master/.travis.yml)

[Martii]

1. Well the "snapshots" that was mentioned to me a few weeks back makes zero sense. I haven't done Qt work for many, many, many years and Qt and Kubuntu aren't liking each other... so yes it would help as a starting point to build a decent guide for compiling here. Most of the current BUILDING is not even accurate for the HEAD of this project from what I can tell (refs to Qt 4.x, etc)... so yes it would help quite a bit to walk your steps instead of the crappy search results I keep getting. I have no desire to investigate multiple distro's just to find out which one merges well with Qt's .run and the corresponding Linux tree. So please share.
2. Because you are the author of the program and it's your responsibility to assist... if you are lucky you might even get someone to host a nightly. :) Every time you put a QtWebKit label on anyone's issue, and close it, it's like putting a stake in this projects reliability... I'm trying to grasp the changes you are doing with QtWebEngine and get something up and running so I can actually recommend QupZilla... right now in my circles it's considered very unstable due to all the "legacy" bugs and especially with Qt 5.6 being bleeding edge for the HEAD. I am not into mystical guessing if logic is actually working and prefer to test things. :)

This is both on a personal level and OUJS Admin level here. I think what you are doing is great but if I may be so bold quite "incomplete" on support. You seem like a super nice person but you seem a bit reluctant to answer actual Q's in entirety. I'd like to add my 2 cents in every once in a while and perhaps one day make some suggestions as well but since the releases are all QtWebKit it's very apparent that it's unusable on a daily basis. Please don't take any of this wrong way as I'm a literal person and I do like to improve everyone's web experience. Right now QupZilla is unuseful in it's current release state and I'd like to change that... so cooperation would be prudent I think. :)

I'd like to help but you have to help first.

[Martii]

There is a Qt 5.6 PPA for Ubuntu

So ... my search results yield nothing for this... what do you use? e.g. somewhat incomplete and round-about answer from your yml file... it doesn't seem to resemble anything like your:

sudo add-apt-repository ppa:nowrep/qupzilla

... mentioned at QupZillas page. Every distro has their own packaging repository... Kubuntu is a machine that I just upgraded to 15.10 and I had to install your PPA in order to get 1.8.9 because the baseline repositories gave me 1.8.3 1.8.6. Luckily my primary dev station had 1.8.9 and it's actually supported directly... but nothing under contribs e.g. no nightly there.

---

CORRECTION: $ sudo apt-add-repository -y ppa:beineri/opt-qt56-trusty instead of digging for it... I don't use .yml at all so it took a few more than usual to find it. Btw the Kubuntu upgrade made lots of artifacts between the older version from last year to the latest so I figured I'd have to redo it from scratch anyhow. So thanks... indirectly with some followup. :) ;) "trusty" was mentioned for Kubuntu/Ubuntu 12.x search results but I am quite sure I wasn't running that last year... and I get to do this via VNC which is painfully slow compared to this dev station which is a completely different distro... and I won't be murking it up with libraries that may interfere with it's operation... I don't have time to reinstall this one constantly when a distro bug comes through esp. since I run KDE here. It only runs stable usually.

[nowrep]

1. If you don't want to mess with Qt snapshots (or even build Qt by yourself) and your distro doesn't provide that, then you must wait for distro update or change distro. There is nothing I can do, and as there is a lot of distributions with different software and libraries, each distro may need special adjustments, so there is no one Qt snapshot fits all.
2. Yes, in current situation 99% of issues with rendering of webpages is in QtWebKit. QtWebKit is old, unmaintained and vulnerable - unfit for a modern browser. So there is nothing I can do than just add a QtWebKit label to the issue and then eventually close it.

As for building instructions, yes they are outdated. That needs to be fixed. But the thing is, that build is very easy once you have Qt libraries and few additional dependencies (which is basically just openssl). Then you run qmake && make && make install as with other software.

I agree with you that current QupZilla release with QtWebKit is not for daily use, I never claimed otherwise.

As for not answering questions, I just didn't send uname -a output, but the kernel version really won't help you. I use ArchLinux, if you want to know the distribution. And in Arch, it's really easy to install QtWebEngine QupZilla, you just install qupzilla-git from AUR.

It's really not my problem that Ubuntu is not rolling distro and leaves users with old versions of software. I don't really like that users of my application are getting slow updates and things I fix now will get to them in, let's say, year. But it's their own choice to choose the distribution. And PPAs are only a partial fix. First of all, there is problem with trust and you really shouldn't be installing packages from anywhere but your official distribution repository, and second - it will only be available for Ubuntu users, what about other distributions?

[Martii]

I'm trying to get a build machine for it... your sources yield this:

$ sudo apt-add-repository -y ppa:beineri/opt-qt56-trusty  
gpg: keyring `/tmp/tmptlefa904/secring.gpg' created
gpg: keyring `/tmp/tmptlefa904/pubring.gpg' created
gpg: requesting key *clipped* from hkp server keyserver.ubuntu.com
gpg: /tmp/tmptlefa904/trustdb.gpg: trustdb created
gpg: key *clipped*: public key "Launchpad PPA for Stephan Binner" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
$ sudo apt-get update
Hit http://us.archive.ubuntu.com wily InRelease
Get:1 http://us.archive.ubuntu.com wily-updates InRelease [65.9 kB]                                                    
Get:2 http://security.ubuntu.com wily-security InRelease [65.9 kB]                             
Ign http://ppa.launchpad.net wily InRelease                                                 
Hit http://ppa.launchpad.net wily InRelease                                                 
Hit http://us.archive.ubuntu.com wily-backports InRelease                                                 
Hit http://us.archive.ubuntu.com wily/main Sources                                                        
Ign http://ppa.launchpad.net wily Release.gpg                                                               
Hit http://us.archive.ubuntu.com wily/restricted Sources                                                                                                                               
Hit http://us.archive.ubuntu.com wily/universe Sources                                                                                                                                 
Hit http://ppa.launchpad.net wily/main amd64 Packages                                                                                                                                  
Hit http://us.archive.ubuntu.com wily/multiverse Sources                                                                                                                               
Hit http://us.archive.ubuntu.com wily/main amd64 Packages                                                                                                                              
Hit http://ppa.launchpad.net wily/main i386 Packages                                                                                                                                   
Hit http://us.archive.ubuntu.com wily/restricted amd64 Packages                                                                                                                        
Get:3 http://security.ubuntu.com wily-security/main Sources [43.2 kB]                                                                                                                  
Hit http://us.archive.ubuntu.com wily/universe amd64 Packages                                                                                                                          
Hit http://ppa.launchpad.net wily/main Translation-en                                            
Hit http://us.archive.ubuntu.com wily/multiverse amd64 Packages                          
Hit http://us.archive.ubuntu.com wily/main i386 Packages                                 
Ign http://ppa.launchpad.net wily Release                                                                      
Get:4 http://security.ubuntu.com wily-security/restricted Sources [2,854 B]                                    
Hit http://us.archive.ubuntu.com wily/restricted i386 Packages                                                     
Hit http://us.archive.ubuntu.com wily/universe i386 Packages                                                       
Get:5 http://security.ubuntu.com wily-security/universe Sources [10.8 kB]                
Hit http://us.archive.ubuntu.com wily/multiverse i386 Packages                                
Hit http://us.archive.ubuntu.com wily/main Translation-en                                                 
Hit http://us.archive.ubuntu.com wily/multiverse Translation-en                     
Get:6 http://security.ubuntu.com wily-security/multiverse Sources [2,788 B]         
Hit http://us.archive.ubuntu.com wily/restricted Translation-en                                
Get:7 http://security.ubuntu.com wily-security/main amd64 Packages [138 kB]             
Hit http://us.archive.ubuntu.com wily/universe Translation-en                                   
Get:8 http://us.archive.ubuntu.com wily-updates/main Sources [71.0 kB]                           
Get:9 http://us.archive.ubuntu.com wily-updates/restricted Sources [3,741 B]                              
Get:10 http://us.archive.ubuntu.com wily-updates/universe Sources [21.1 kB]                                              
Get:11 http://security.ubuntu.com wily-security/restricted amd64 Packages [10.9 kB]                                      
Get:12 http://us.archive.ubuntu.com wily-updates/multiverse Sources [3,199 B]                                              
Get:13 http://us.archive.ubuntu.com wily-updates/main amd64 Packages [202 kB]                                             
Get:14 http://security.ubuntu.com wily-security/universe amd64 Packages [49.8 kB]                                      
Get:15 http://us.archive.ubuntu.com wily-updates/restricted amd64 Packages [13.3 kB]                                                 
Get:16 http://us.archive.ubuntu.com wily-updates/universe amd64 Packages [88.1 kB]                                                    
Get:17 http://us.archive.ubuntu.com wily-updates/multiverse amd64 Packages [6,247 B]                                                  
Get:18 http://us.archive.ubuntu.com wily-updates/main i386 Packages [199 kB]                                                                 
Get:19 http://us.archive.ubuntu.com wily-updates/restricted i386 Packages [13.4 kB]                                                   
Err http://ppa.launchpad.net wily/main amd64 Packages                                                                      
  404  Not Found
Get:20 http://us.archive.ubuntu.com wily-updates/universe i386 Packages [85.6 kB]                               
Get:21 http://security.ubuntu.com wily-security/multiverse amd64 Packages [6,247 B]                                       
Err http://ppa.launchpad.net wily/main i386 Packages                                                                                                     
  404  Not Found
Ign http://ppa.launchpad.net wily/main Translation-en_US                                                                                                 
Get:22 http://us.archive.ubuntu.com wily-updates/multiverse i386 Packages [6,678 B]                             
Get:23 http://security.ubuntu.com wily-security/main i386 Packages [135 kB]                                              
Get:24 http://us.archive.ubuntu.com wily-updates/main Translation-en [92.7 kB]                                           
Get:25 http://us.archive.ubuntu.com wily-updates/multiverse Translation-en [3,156 B]                                                      
Get:26 http://us.archive.ubuntu.com wily-updates/restricted Translation-en [3,024 B]                                                          
Ign http://ppa.launchpad.net wily/main Translation-en                                                                                               
Get:27 http://us.archive.ubuntu.com wily-updates/universe Translation-en [51.5 kB]                                                
Get:28 http://security.ubuntu.com wily-security/restricted i386 Packages [10.8 kB]                                 
Hit http://us.archive.ubuntu.com wily-backports/main Sources                                                  
Get:29 http://security.ubuntu.com wily-security/universe i386 Packages [49.8 kB]                  
Hit http://us.archive.ubuntu.com wily-backports/restricted Sources                                     
Hit http://us.archive.ubuntu.com wily-backports/universe Sources                            
Get:30 http://security.ubuntu.com wily-security/multiverse i386 Packages [6,443 B]          
Hit http://us.archive.ubuntu.com wily-backports/multiverse Sources                                      
Hit http://us.archive.ubuntu.com wily-backports/main amd64 Packages                               
Get:31 http://security.ubuntu.com wily-security/main Translation-en [67.9 kB]                     
Hit http://us.archive.ubuntu.com wily-backports/restricted amd64 Packages                                          
Hit http://us.archive.ubuntu.com wily-backports/universe amd64 Packages                                             
Hit http://us.archive.ubuntu.com wily-backports/multiverse amd64 Packages                                     
Hit http://us.archive.ubuntu.com wily-backports/main i386 Packages                                            
Hit http://us.archive.ubuntu.com wily-backports/restricted i386 Packages         
Hit http://us.archive.ubuntu.com wily-backports/universe i386 Packages           
Hit http://us.archive.ubuntu.com wily-backports/multiverse i386 Packages         
Hit http://us.archive.ubuntu.com wily-backports/main Translation-en
Hit http://us.archive.ubuntu.com wily-backports/multiverse Translation-en
Hit http://us.archive.ubuntu.com wily-backports/restricted Translation-en                                                                                                             
Hit http://us.archive.ubuntu.com wily-backports/universe Translation-en                                                                                                               
Get:32 http://security.ubuntu.com wily-security/multiverse Translation-en [2,806 B]                                                                                                   
Get:33 http://security.ubuntu.com wily-security/restricted Translation-en [2,666 B]                                                                                                   
Get:34 http://security.ubuntu.com wily-security/universe Translation-en [32.6 kB]                                                                                                     
Fetched 1,569 kB in 11s (131 kB/s)                                                                                                                                                    
W: Failed to fetch http://ppa.launchpad.net/beineri/opt-qt56-trusty/ubuntu/dists/wily/main/binary-amd64/Packages  404  Not Found

W: Failed to fetch http://ppa.launchpad.net/beineri/opt-qt56-trusty/ubuntu/dists/wily/main/binary-i386/Packages  404  Not Found

E: Some index files failed to download. They have been ignored, or old ones used instead.
$ sudo apt-get install -qq qt56tools qt56script qt56webengine qt56webchannel qt56declarative qt56x11extras
E: Unable to locate package qt56tools
E: Unable to locate package qt56script
E: Unable to locate package qt56webengine
E: Unable to locate package qt56webchannel
E: Unable to locate package qt56declarative
E: Unable to locate package qt56x11extras
$

... granted I need to redo Kubuntu from scratch as I detected artifacts... but this isn't looking good... this is why it would be helpful to know your uname so I can start there instead of what "might be"... you said ArchLinux so I'll go dig that up from a download and learn it too. :)

It's really not my problem that Ubuntu is not rolling distro and leaves users with old versions of software.

I don't blame you for saying that at all... but they might consider it unstable... I consider it bleeding-edge to be at Qt 5.6... so do many distro maintainers. I freed up an older machine to twiddle with just for this project... so I hope that it can build it then I can cross build across the distro's and perhaps do a nightly (at the very least improve your BUILD guide to cover the HEAD here)... which leads to your question you just asked. I deal with some distros, including my own, but not Kubuntu/Ubuntu... having the BUILD guide more complete would be the best/easiest route but I've been staring at the current docs off and on since QupZilla came into my focus... going "Huh?". :) ;)

you just install qupzilla-git from AUR

Since I'm not Ubuntu/Kubuntu all the time and definitely not ArchLinux I have no idea what "AUR" is... yes I'll web search for it but not hopeful on results until I get ArchLinux installed. :(

I think your design concepts are really good; you have a clear path on coding style; calm demeanor esp. with me... thank you; killer potential for a browser with a few glitches here and there... but just awful BUILD docs. ;) :)

First of all, there is problem with trust and you really shouldn't be installing packages from anywhere but your official distribution repository

FYI... Debian has jesse and that's in a network of trust but it's not mainstream too... it's how node actually works in that distro... but that's just a side-bar to show that PPA's are sometimes a necessity. My distro has a contrib repo, backports, etc.... but I rarely use them because I prefer stable and supported... but if there's an established network of trust it's usually added... apparently your project is "mainstream" with them. :)

[nowrep]

I don't recommend to install ArchLinux just to try new QupZilla. Your error log indicates that you are using wily but that PPA is for trusty. So I think you should be able to either to force install for trusty with (I think) apt-get install -t trusty ... or install manually package by package.

That being said, the easiest to test it (if your distro doesn't offer Qt 5.6) is I guess to use Ubuntu Trusty (current LTS release) as that's the OS that is used on CI.

[ghost]

@nowrep What about, if i release live image with preinstalled QupZilla master? Is that will be useful?

[nowrep]

@cranes-bill I think live image is just too much for one app. What would be great is to get QupZilla build & run as a bundle (eg. xdg-app).

[ghost]

I never used similar tool, so i should learn how to work with it first.

[Martii]

heh... UA is:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QupZilla/1.9.99 Chrome/45.0.2454.101 Safari/537.36

... for the QtWebEngine 5.6.0 and QupZilla 1.9.99 ... bit confusing there.

[The-Compiler]

Welcome to the world of user-agent strings :wink:

At least here, that's the same I get with Chromium, plus the QupZilla/1.9.99 part.

[Martii]

@The-Compiler Well I know that QupZilla is built from Chromium pieces from the back-end... at least I think... so I am used to that but I wasn't expecting AppleWebKit for the QtWebEngine build. :)... also a lower WebKit version too.

[jamesqf]

@Martii: If having a browser you can use is what you want (rather than participating in development), why not simply stick with release versions? I use 1.8.9 release on OpenSuSE 13.1 as my daily browser. While it's not without problems, overall it works better than any other browser I've tried - which is why I use it.

[Martii]

@jamesqf

While it's not without problems

That's the primary issue here. I realize that QupZilla is running on bleeding-edge software (Qt 5.6 for example) and not every distro does this... hence the term stable distros vs unstable distros.

It's a nice browser for what it does. I'm here in official capacity for OUJS as well as personal. Only things I don't like about 1.8.9 seriously is when it crashes on a web site and what appears to be a lack of font smoothing (or default font perhaps... haven't gotten that far yet). v2.0.0 is released although Linux builds look like they are going to need to be done by hand now as mentioned here if I'm reading this correctly... which may present the issue of getting multiple Qt 5's on a single machine (My distro is currently at 5.5.1)... usually I don't do that because I've never had the need. Each distro can be different in its tree which can lead to dependency hell. As time progresses I may be able to assist in improving the FAQ here and other docs too.

[Martii]

@nowrep Is there some reason why "Bookman URW" is the default font for "Font Families" with ArchLinux build? Everything I've read about Qt says the DejaVu familly should be set for Linux. Tried new profiles too and always sets "Bookman URW"... even for Fixed. Easy enough to change but kind of odd.

[nowrep]

@Marti Fonts are used in according to system defaults. I assume you set it as your default font in system settings?

[Martii]

@nowrep No I didn't change them in KDE/Plasma settings at all (and I'd never pick Bookman URW for anything unless it was a letter to someone in an office type prog)... I'm rebuilding ArchLinux as a VM (had an issue with grub there too) but looks like Debian has an issue right now with the kernel... so it looks like it's affecting GH too as well as OUJS right now (keeps stopping and no stderr... but working on that before sleep heh... might be GH solely too or nota heh)... so that's on hold for the moment. Like I said it's no biggie just thought I'd ask. :)

[ghost]

I think that's a qt issue. To me, any new QupZilla installation starts with different fonts....

[Martii]

Hmmm in the VM it did "Clean" for all the fonts (no sign of DejaVu font families either) vs. the physical machine which did "Bookman URW"... this is really strange.

Ref:

• https://www.archlinux.org/packages/extra/any/ttf-dejavu/

[Martii]

Keep in mind that I do know how to use git well... every time there is a Code update I have to blow away the local clone and redownload it from GH via https ... then qmake, make in order to get a viable sudo make install e.g. the last, previously downloaded, commit hash is all that is ever compiled ... but git show shows the checkout to be at the current GH hash... this is getting a little lengthy on compilation time esp. with make since it has to do the whole project all over instead of just the objects that have changed.

:question: Any ideas on what's going on with that?

I'll eventually fork this project and do it my usual way with my ssh keys but haven't gotten that far with the exchange mechanism between the host (my distro) and the guest (ArchLinux).

[r-a-v-a-s]

Just throwing out ideas... as I don't fully understand what your problem is.

I noticed strange behavior regarding the profiles and building. As a test, you could try to delete the profile folder (or file) before you build, or temporarily move it if deleting isn't acceptable.

If you can download and use clang, it takes less than two minutes to do a full build on a 3.1ghz quad core using the -j3 make arg.

Maybe try clean or distclean... http://superuser.com/questions/637844/difference-between-make-clean-and-make-distclean

[Martii]

$ make clean has already been tried... same results... however forgot about $ make distclean... will try that next round. Thanks. :)

Also $ sudo make uninstall is typically done when "upgrading" to make sure file artifacts are removed from different $ sudo make installs... and the uninstall has lots of errors in it... but that's probably a Qt issue in bleeding-edge ArchLinux right now.

[Martii]

$ make distclean didn't work... one last thing to try is to redo $ qmake-qt5 first then the normal make. Maybe it will save a little bit of compile time... dunno yet.

---

Note distclean did help with not having to erase the repo and reget it though... just have to compile 100% still instead of just what's changed.

[Martii]

Nope that (qmake-qt5) didn't work either... Help → About QupZilla still says commit ref of 06087a943e and my current:

$ git rev-parse --short HEAD
ff3c45c

... did actually compile something and was shorter this time.

[r-a-v-a-s]

I just pulled and did a full rebuild, and there is no sign of a commit id in 'About QupZilla'.

Application version 2.0.0
QtWebEngine version 5.6.0
© 2010-2016 David Rosca
https://www.qupzilla.com
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QupZilla/2.0.0 Chrome/45.0.2454.101 Safari/537.36

Also note the application version is 2.0.0 not 2.0.99.

The use of Qz::VERSION seems convoluted. Why not just use QUPZILLA_VERSION?

OpenSUSE Tumbleweed

[r-a-v-a-s]

I just remembered I also had qupzilla installed... removed it with zypper and then tried to run / build from Creator:

error while loading shared libraries: libQupZilla.so.2: cannot open shared object file: No such file or directory

[nowrep]

You need to either make install or build with NO_SYSTEM_DATAPATH (constult BUILDING.md).

[Martii]

There's some build issues for sure (good or bad who knows for sure)... OS X doesn't show the commit hash at all. I closed this because most of my questions were answered. It would still be nice not to have to do make distclean but from how Qt is designed (centric on making the Makefile) it probably isn't possible.

[Martii]

@r-a-v-a-s

Also note the application version is 2.0.0 not 2.0.99.

With a slight modification of 2.0.1 I took this as GH dev here is "working on 2.0.99". This is similar to how mongoose does their GH structure. e.g. GH dev here is qupzilla@next with semver/npm/node syntax but Qt probably requires a specific version and may or may not follow semver semantics.

[r-a-v-a-s]

Thanks :-]

For easy testing I just removed unix:contains(DEFINES, "NO_SYSTEM_DATAPATH"): from main.pro.

It built and ran from Creator. :sunglasses:

Application version 2.0.99 (960f3a7996)

What do you think about "including" a custom.pri file, which is ignored by git. Then developers could define NO_SYSTEM_DATAPATH and run from Creator without modifying tracked files... or is there another way? export NO_SYSTEM_DATAPATH="true" from a terminal didn't seem to help.

[nowrep]

In QtCreator: Project -> Build Steps -> Additional qmake arguments -> put DEFINES+=NO_SYSTEM_DATAPATH there

[r-a-v-a-s]

Back to the reason I wanted to test... Martii's comment about the older commit id.

I've found with another project that when working in Creator:

1. make a small change to the .pro file that calls git for the information, and save
2. make a small change to the file that uses the information (about window), and save
3. build

It only rebuilds what was changed and the commit id is correct.

The .pro file uses: LC_VERSION=$$system([ "$(which git)x" != "x" -a -d ../../.git ] && echo "$(git describe --tags)" || echo "$${LC_VERSION}")

I still don't understand the [ "$(which git)x" != "x" -a -d ../../.git ]

[r-a-v-a-s]

@nowrep Thanks!

[r-a-v-a-s]

It seems to be the same for Qz. Modifying aboutdialog.cpp and defines.pri, and then build/run from Creator will only rebuild what is needed, and the commit id becomes current.