Re: RKWard is in kdereview
Hi, and sorry for the too late reply. El miércoles, 10 de octubre de 2018 11:53:59 -03 Thomas Friedrichsmeier escribió: [snip] > > It depends on WebKit which is not supported, could this be ported to > > WebEngine? > > We're in a somewhat uncomfortable situation, here, as we're currently > stuck with the MinGW-API on Windows, which means no QtWebEngine for us > (see also https://marc.info/?l=kde-core-devel&m=145716183226732&w=2). I > do have several ideas to work around this, the simplest being to use > #ifdefs to use QtWebEngine on non-Windows platforms. I had started along > that track, but quickly abandoned my efforts after finding out that > Debian did not have QtWebEngine, either, then. > > I guess I'll have to pick this up again. Beware the qtwebengine is only available in a handful of archs: <https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src> So yes, it's an uncomfortable situation. -- Los errores ortográficos y de redacción fueron insertados con la única intención de testear sus conocimientos de la lengua castellana. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Installing qml caches
El martes, 3 de julio de 2018 05:21:56 -03 Volker Krause escribió: [snip] > Qt 5.11 actually has something like this, but only covering QML files > compiled in via qrc, see qtquick_compiler_add_resources() (I needed a very > recent 5.11 branch build though for this to work, post 5.11.1). > > I have no performance measurements yet, but at least the package size goes > up contrary to what one might expect, as the compiled binary is 2-3x larger > than the (non-minified) QML source code. That space would be needed by the > qmlc files anyway in the end though, so overall disk space cost goes down a > bit once deployed. > > With the QML sources no longer included you end up with a non-starting > application after updating Qt though. > > So, interesting for APKs etc where you fully control Qt, but probably not > for distros. I was actually thinking in packages shipping qml source files as usual, make package register them with some tool and recompile them with any qt update. Now I don't know if that happens automatically, ie, qml files become compiled at runtime in a cache. If that's the case then only the first run for each user would just take time. But again, the benefit really needs to be interesting to deploy something like this. -- 16: De quien es Internet * De DIOS dado que todas las cosas del mundo le pertenecen Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Installing qml caches
El martes, 5 de junio de 2018 17:38:04 -03 Sune Vuorela escribió: > On 2018-06-04, Alexander Volkov wrote: > > This can be made optional, as it is done in Qt. > > So distros will have a choice whether to install qmlc files or not. > > Debian installs them. > > I think Debian only installs the qmlc files for Qt packages (where the > versioning already is tightly coupled to Qt stuff) Exactly. But if it the gain is *really important* we might come up with a solution maybe, like triggering rebuilds in the user's machine. But the gain needs to be really significant. -- La ciencia sin la religión es renga, la religión sin la ciencia es ciega. Albert Einstein Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Policy regarding QtWebKit and QtScript
On Wednesday 30 December 2015 00:19:39 Allan Sandfeld Jensen wrote: [snip] > > - Same applies to most of the bundled stuff. A lot of the FreeBSD patches > > > > for Chromium itself are, indeed, unbundlings. But those need to be re-done > > for webengine, because who knows how the versions differ. > > We have already done third-party library unbundling in Qt 5.6. Allan: are sqlite3 and leveldatabase still embedded? -- firmaware: soft cuya licencia pagas enviando un autografo StucKman en #grulic, irc.freenode.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Policy regarding QtWebKit and QtScript
On Friday 25 December 2015 13:43:22 Nicolás Alvarez wrote: [snip] > The linking step needs 4GB of RAM At least on the qtwebkit case that's the amount of RAM without generating debugging symbols (or maybe using stabs). I also know that Allan has worked toward deembedding stuff from QtWebEngine. Sadly my available time and build power has proven to not be enough to properly test this fact :( -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Policy regarding QtWebKit and QtScript
On Tuesday 22 December 2015 20:03:22 Thomas Lübking wrote: > On Dienstag, 22. Dezember 2015 19:44:21 CEST, Aleix Pol wrote: > > compiling for some time, but that's not a reason to rely on it on our > > side. > > Sure, getting rid of it is mandatory. > What worries me is that this *break* happens in a *minor* Qt release. Should > generally not happen. Period. > > It should still be released and everytime you try to build against it > (include it) and didn't "#define > I_KNOW_WEBKIT_IS_BITROT_AND_AM_PORTING_TO_QT_WEBENGINE_ALREADY" you get a > compiler error. > > The idea that users may have remainders of QtWebKit 5.5 on their disk (or > not and thus unresolvable linkage) and install Qt 5.6 and still have (not > recompiled) client code that is now gonna crash scares me a bit - it > doesn't really improve reputation. Distros will virtually *have* to provide > downstream webkit solutions to cover 3rd party installs and we'll get > "somthing broke" reports on this all over the place. What we distro packagers are going to do is to recompile QtWebkit for as long ans possible/necessary. IIRC Thiago said that it didn't use private stuff, so recompiling should be more than enough (in case it is really needed). -- Contrary to popular belief, Unix is user friendly. It just happens to be very selective about who it decides to make friends with. Unknown - http://www.linfo.org/q_unix.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Policy regarding QtWebKit and QtScript
On Tuesday 22 December 2015 19:50:43 Allan Sandfeld Jensen wrote: > On Tuesday 22 December 2015, Thomas Lübking wrote: > > On Dienstag, 22. Dezember 2015 19:05:23 CEST, Ivan Čukić wrote: > > > So, using Kross would mean implementing the kjs backend for it that we > > > had in 4.x times? > > > > Isn't the designated successor for QtScript QJSEngine (I even assumed > > there > > should be some porting tools?) > > > > About QtWebkit - what exactly does "disappear" mean in this context? > > Will it be impossible to link QtWebKit 5.5 to Qt 5.6 ? > > For if it would, that would be one giant ABI break and the answer would be > > to fork Qt... :-P > > No, probably not, it uses private Qt modules, so it cases the version > mismatch assert. But currently it looks like there will be a source-only > qtwebkit 5.6, but not as part of the official release. And should be compilable for some time, indeed. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Something has gone horribly wrong.. Linux builds carnage.
On Thursday 14 May 2015 08:40:09 Scarlett Clark wrote: > I woke up this morning to a sea of red. Almost all of the linux builds are > failing. It looks like QT5 was triggered by an scm change, but hard to tell > as it was also started and aborted by kaning. > The error: > 15:16:38 /srv/jenkins/install/ubuntu/x86_64/g++/kf5- > qt5/qt5/inst/include/QtCore/qglobal.h:1051:4: error: #error "You must > build your code with position independent code if Qt was built with - > reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)." > 15:16:38 # error "You must build your code with position independent code > if Qt was built with -reduce-relocations. "\ > 15:16:38 ^ Scarlett: are you using an upstream clone of Qt5 to build or a distro one? -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
On Tuesday 21 April 2015 09:44:41 Lisandro Damián Nicanor Pérez Meyer wrote: > On Tuesday 21 April 2015 09:39:35 Milian Wolff wrote: > [snip] > > > > Yes we have, but on the main devel mailing list, > > > developm...@qt-project.org > > > It has been troughly discussed, the thread is actually very long. > > > > When did this take place and what is the threads subject? I seem to have > > missed it, and also can't find it in my recent mails. Sorry for that. > > Fair enough. One of them starts in [0], but there was another thread in > which even Lars participated. So far I haven't been able to find it, I'll > keep trying. > > > [0] > <http://lists.qt-project.org/pipermail/development/2014-November/019333.htm > l> Found the other one! The real thread begins in [1] when it was suggested to deprecate QtWebkit with 5.5 (which doesn't means dropping). It contains some interesting assertions, like Qt Creator people asking for an lightweight alternative [2]. Then things get more interesting from the distro-side in [3]. [1] <http://lists.qt-project.org/pipermail/development/2015-February/019893.html> [2] <http://lists.qt-project.org/pipermail/development/2015-February/019922.html> [3] <http://lists.qt-project.org/pipermail/development/2015-February/019958.html> -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
On Tuesday 21 April 2015 09:39:35 Milian Wolff wrote: [snip] > > Yes we have, but on the main devel mailing list, > > developm...@qt-project.org > > It has been troughly discussed, the thread is actually very long. > > When did this take place and what is the threads subject? I seem to have > missed it, and also can't find it in my recent mails. Sorry for that. Fair enough. One of them starts in [0], but there was another thread in which even Lars participated. So far I haven't been able to find it, I'll keep trying. [0] <http://lists.qt-project.org/pipermail/development/2014-November/019333.html> -- firmaware: soft cuya licencia pagas enviando un autografo StucKman en #grulic, irc.freenode.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
Sorry Milian, i've sent it to your personal address by mistake. Resending to the list. On Monday 20 April 2015 23:02:35 you wrote: [snip] > Have you notified the Qt WebEngine developers about this? I have not seen > any email in that regard to the official upstream mailing list at > qtwebengine@qt- project.org . Yes we have, but on the main devel mailing list, developm...@qt-project.org It has been troughly discussed, the thread is actually very long. > Previously, many of the 3rd party stuff was just hardcoded and shipped > internally because it was easier to get stuff done. At least in Qt (not mentioning the web engines) they have been added to easier the development in platforms that do not have a coherent way to handle system libs (like Windows). They are also quite open to add code to detect and use the system lib when required, and I'm really thankful for that :) Sadly that's not the case with the webengine, read: the part the Qt guys don't code. > Now with things settling > a bit, afaik one could start working on the build system to use a system- > provided version of "the 3rd party stuff". Some stuff will probably always > be shipped internally, but at least this could help things a bit. In all > cases, its sadly sometimes simply not possible to make different FOSS code > work together without custom patches for a certain project. Yes, this is > against the ideal utopia we all dream of, but with limited man power there > will always be problems like this. Actually when it comes to the web engine it's not true. When I suggested to use an external ffmpeg and libv8 (javascript engine) the answer was directly no, simply because they are too entangled to be possible. And ffmpeg tends to be quite a source of CVEs... > Regarding debug symbols, it certainly works with ld as others have > mentioned. And it is definitely easier to build than QtWebKit. > > Anyhow, I won't judge distros when they won't package software that is > against their principals. But I hope you guys also understand that for some > developers a good solution for some people is better than a half baked > broken solution for some more people. I'm not a KDE PIM maintainer, but > with my KDevelop hat on (that uses a web view to display documentation > pages, currently QtWebKit), I could understand a projects decision to just > make a certain feature optional. Certainly less maintenance effort than > supporting different implementations. Right. And now I know at least you know the implicants of making QtWebEngine a hard (or not) dependency. -- Hiroshima '45, Chernobyl '86, Windows '95. Grafitti en Niceto Vega 5940, Buenos Aires. De una foto de Mario Gallo. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
On Monday 20 April 2015 20:17:13 Albert Astals Cid wrote: [snip] > IMHO the duty of a distro is providing software to their users to use, if > the rules of the distro make providing software hard/impossible they need > to be updated or these distros need to understand they will lose users to > more flexible distros. Let me begin that I acknowledge you have a fair point there. But using the same reasoning users can also switch to using other apps. I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in the same position as us) is also a large userbase for KDE to loose. But *it's not really* about which distro or app is going to loose more user base, it's about keeping the current one. I don't want Debian nor KDE to loose users, in the same way I do not want to ship something that's unmaintainable. So if any of us with with an upstream hat is going to code something, please consider that having a hard dependency on QtWebEngine might mean his/her code might not get available to everyone as it used to be, that's all. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Distros and QtWebEngine
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to the problem that QtWebEngine poses for us distros (in this case, at least Debian and Fedora). I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a hard (very hard) piece of software to package. It embeds quite a lot of 3rd party stuff which we distros don't accept (in different grades depending on the distro) as we require to build using the system versions. Fedora's Rex Dieter tells me that's actually why chromium is not available for them. Moreover we can't build debugging symbols on most archs due to the enormous amount of RAM+swap it involves in the linking process (more than 8GB last time I checked). This is at least the same as QtWebKit, but seems to be getting worse. Yes, we do understand that QtWebEngine is technically superior to any other thing out there but making that code an acceptable package is another thing. So basically what I'm trying to say is: don't expect us down streamers to easily package QtWebEngine soon, if we ever get to it. I'm really sorry if this comes as "bad news", but the reality is currently this :( -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: openSUSE packagers' take on the 3 month release cycle
Hi, one of Debian's Qt/KDE packagers here. Àlex Fiestas wrote: > On Monday 08 July 2013 20:35:22 Luca Beltrame wrote: >> (apologies for breaking your threading, but I'm not subscribed to k-c-d; >> in fact, please CC me with replies, thanks!) >> >> Currently, the people working on openSUSE packages are against the >> proposal. A detailed explanation follows. >> >> First and foremost, the KDE packaging in openSUSE is almost completely >> community driven. This means that most of the work is done by volounteers >> which handle what they can in their (limited) time. Faster releases may >> mean worse packaging and increased maintenance (and I think this is also >> an issue w/most non rolling distros). > Well, KDE is also ran by volunteers doing what they can in their limited > time. If we can achieve 3 month releases, meaning developing features, > promo, i18n, etc I'm sure you can package it as well. > > My question to you (all distro people) is, what can we do to help? and > what is more interesting, what can you do, distro people, to help > yourselves? > > I see at least a duplicated effort across all distros which is > "adding/figuring out" new dependencies. Can't we coordinate on that so > everybody life is easier? First of all, thanks for this nice thread, it's awesome to see it well discussed :) WRT licenses: whatever we can do to improve the situation here will surely help us **a lot**, no matter what the schedule is. The same can be applied to dependencies, of course. > Also, what can we do, upstream to make this happen? so far what I read in > this thread is "This doesn't work perfectly for us, -1", what I'd love to > read is a "This as it is won't work for us, but if we do X and Y and Z, > maybe we can do it". There are some factors that you can't simply manage, distro side. For example, every new major upstream release requires a transition in our side, to allow build-dependencies be correctly rebuilt. And that requires distro coordination (in our case, with the release team). We are currently waiting for an ACK to push KDE 4.10 to unstable. For more than a month. Of course, this is not somthing the you folks can help (at least as far as I understand it), but shortening the release cycle will surely not help us.
Re: startkde modifies PATH to add qt4 bin dir to the front
On Tuesday 18 June 2013 19:19:24 Albert Astals Cid wrote: [snip] > > There's also a check that the dbus session is available, but surely we'll > > error out soon enough if this isn't the case? > > Sure we could do all that, but given the black magic that is involved in > startkde (or so I've been told), i'd prefer to go for a simpler solution > like the attached patch. > > If anyone is running without qdbus on the path can you give this a try? I have just tested it with my Debian setup (I'm currently running it) and everything seems OK, PATH is as it should be, nothing broke. But so far I haven't tested with XDG_CONFIG_DIR setted as I don't know exactly what to do (I may need an extra setup maybe?). -- Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer a la comunidad SL como una sarta de fanáticos que viven dentro de un tupperware. Pablo Di Noto - GrULiC Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
