[Bug 210027] devel/qt4-script: ARM Architecture not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027 Tobias C. Berner changed: What|Removed |Added Status|New |In Progress CC||tcber...@freebsd.org --- Comment #4 from Tobias C. Berner --- I do not really have a clue of arm. But from [1] it seems that the __ARM_ARCH_6ZK__ is a misspelling of the __ARM_ARCH_6KZ__ which you are adding. So, assuming this patch actually helps the build for you, I see no harm in adding it. [1] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01679.html -- You are receiving this mail because: You are the assignee for the bug.
[Bug 210027] devel/qt4-script: ARM Architecture not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027 Tobias C. Berner changed: What|Removed |Added URL||https://reviews.freebsd.org ||/D8322 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 210027] devel/qt4-script: ARM Architecture not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027 --- Comment #5 from mikael.uran...@gmail.com --- Yes it's a mispelling, a lot of qt ports are affected too, should I open a single PR for all of them or one per port? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 210027] devel/qt4-script: ARM Architecture not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027 --- Comment #6 from Tobias C. Berner --- I think it would be the cleanest if we try to do it in one go in D8322. Do you have a list of the affected ports? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 210027] devel/qt4-script: ARM Architecture not supported
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210027 --- Comment #7 from mikael.uran...@gmail.com --- I don't have a list but I can make one. I'm looking the build failures of the last run: http://beefy8.nyi.freebsd.org/build.html?mastername=head-armv6-default&build=p423739_s307008 The core dump of devel/libdbusmenu-qt, net-im/licq-qt-gui... is a fallout of the mispelling. I don't know how the qt* ports work, patches in qt4-corelib/files are applied to all the qt4 ports? qt5 is affected too. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 213704] x11/kde: Request to update to KDE Plasma 5.8 LTS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213704 Kubilay Kocak changed: What|Removed |Added Status|New |Open Assignee|freebsd-ports-bugs@FreeBSD. |tcber...@freebsd.org |org | Summary|[maintainer-update] |x11/kde: Request to update |kde-plasma 5.8 LTS |to KDE Plasma 5.8 LTS CC||k...@freebsd.org, ||ko...@freebsd.org --- Comment #1 from Kubilay Kocak --- @Reporter Requesting port/pkg versions updates as bugzilla issues without patches are normally closed without further action. Requests to update ports *may* instead be sent to the freebsd-ports mailing list. In this case, given last commit [1] to x11/kde4 mentioning area51 (KDE development repository) and Plasma 5 among other things, assign to tcberner to resolve with comment pointing user to further information/instructions if available and/or appropriate. [1] http://svnweb.freebsd.org/changeset/ports/420774 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 213704] x11/kde: Request to update to KDE Plasma 5.8 LTS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213704 gr...@kde.org changed: What|Removed |Added CC||gr...@kde.org --- Comment #2 from gr...@kde.org --- Could be assigned to kde@ as well. The area51 repository is where KDE ports are prepared for inclusion into FreeBSD ports proper. You can find some minimal documentation at https://freebsd.kde.org/area51.php . There are ports of Plasma 5.8 LTS; and packages; but not from the official ports and packages repositories, because it's slow going getting all the ports in, KDE 4 shuffled around, Qt updated, etc. Current work-items are: - Qt 5.8.2 update - minor KDE & Qt updates / small fixes - takeover of extra-cmake-modules - KDE Frameworks 5 Beyond getting the frameworks in, things are a little more open. Plasma 5 alone could be added without clashing with any other ports -- it is all new software. Dealing with applications is another thing, though, and requires a great deal of shuffling and writing of MOVING-entries. -- You are receiving this mail because: You are on the CC list for the bug.
Re: First try at a digikam-kf5 port
So I've updated the digikam-kf5 port skeleton for release 5.2.0 and added a kipiplugins-kf5 port that's also been updated to 5.2.0. Had fixed the gphoto2 issues with 5.1.0 release and had cameras/phones detected and transfered files. 5.2.0 works great as long as you haven't compiled the graphics/opencv2 port with qt4 gui. On Sat, Sep 3, 2016 at 1:28 PM, Thomas Legg wrote: > So I've updated the port skeleton. I think it now covers all of the kf5 > and qt5 USES properly. I've also brought in the DOCS and NLS options. I've > also added the multimedia option that will do thumbnailing and playback via > qt5-multimedia. This has been tested locally with the qt5.6.1-multimedia > and is pretty dang slick. The digikam DEPENDENCIES file lists this option > as needing more testing as some earlier versions of qt5-multimedia had bugs > with gstreamer 1.0. I've yanked the gphoto2 pending some patching and > testing, but hopefully camera integration will return sooner rather than > later. > > This version I feel confident enough about that I'd say it's worth a > commit pending approval of the freebsd-kde maintainers. > > Thomas Legg > > On Thu, Sep 1, 2016 at 4:41 PM, Tobias C. Berner > wrote: > >> Hi there >> >> I'd rather have -docs and -l10n as options than separate ports [as it is >> the same distfile] -- if at all (I don't really see a good reason not to >> install either docs or translations -- we should ship the complete thing by >> default). >> >> And then, the Makefile.common rather belongs to the kipiplugin metaport >> than to digikam itself. >> >> Yes, I think appending a -kf5 to the ports would be the right nameing >> scheme here. >> But again as with digkim,digikam-docs,digikam-l10n, I'm not sure if it >> is actually worth it to split the kipiplugins into sub-ports. >> So I would suggest to simply add a single kipiplugins-kf5 port -- you may >> choose to do it differently of course :). >> >> >> mfg Tobias >> >> On 1 September 2016 at 02:35, Thomas Legg wrote: >> >>> Thanks for the feedback and link. I've updated the Created by line and >>> will probably push it to github when I have some time this weekend. I'm >>> also going back and looking at the makefiles for the existing kf5 ports as >>> to kde:5, kde, and qt5 options >>> >>> I think the Makefile.common will end up staying as in many ways it seems >>> to make handling the digikam-xxx-doc, digikam-xxx-l10n, the multitude of >>> kipi-pluginxx ports a bit easier. Speaking of the kipi-plugin-xxx ports, >>> none of these have a kde4 added to their name. Should I create new ports >>> with a kf5 name (kipi-plugin-imgur-kf5)? I think I probably should as it >>> looks like most of these kde4 kipi-plugins have disappeared. >>> >>> Thomas Legg >>> >>> On Tue, Aug 30, 2016 at 1:48 PM, Tobias C. Berner >>> wrote: >>> Hi there Thanks a lot :) 1) You can modify that "Created by line" to mention you :) 2) You could probably improve that Makefile a bit, by using FOO_CMAKE_BOOL [1]. 3) I'm personally also not a fan of the Makefile.common used in digikam-kde4, and now in this one too, it makes it more confusing to me [also it contains kde4 bits]. If you wan't I can import it into plasma5/PORTS :) mfg Tobias [1] https://www.freebsd.org/doc/en/books/porters-handbook/makefi le-options.html#options-cmake_bool On 29 August 2016 at 06:46, Thomas Legg wrote: > Would love some feedback, especially on the USES, KDE, and QT5 > sections of Makefiles. > https://github.com/thomaslegg/digikam-kf5 > > This builds digikam 5.1.0 built around a mutt version of the area51 > kf5 branch. Mutt as I've rolled the kdepim back to 16.04 as 16.08 kdepim > calendaring requires qt5-webengine, which seems like it's going to require > a lot of work to port. > > If using digikam-kde4, I recommend moving the .db files out of your > photo repo directories and letting digikam-kde5 build new ones. I haven't > tested all of the digikam features so far, but it launches, indexes, > builds > thumbnails, displays photos, adds tags. More testing required and if > anyone > else gets this to build, I'd love feedback on your use. > > Thomas Legg > >>> >> >
