Kevin Funk | 22 Jun 10:49 2016
Picon
Gravatar

Emerge: WIP Unix support (unix3 branch)

Heya,

a few people might have noticed a few odd-looking commits in Emerge recently. 
In fact, Hannah has been working on adding Unix support to Emerge! [1]

That means, you can run Emerge on either Linux or OS X now, too!

This is all very much work in progress so far, but we already got Kate to 
build & run under OS X, using Emerge, it worked out pretty well for us. I've 
mentioned the Linux & OS X ports on [1], since then a few people approached me 
for more information.

Here it is.

# Try it out

In order to try it out:

$ mkdir kderoot
$ cd kderoot
$ git clone git://anongit.kde.org/emerge
$ cd emerge
$ git checkout unix3

$ mkdir ../etc
$ cp kdesettings ../etc/kdesettings.ini
$ vi ../etc/kdesettings.ini

Add the following to the [Portage] section:

(Continue reading)

Kevin Funk | 18 Jun 14:44 2016
Picon
Gravatar

Blog post: KDE on Windows status update

Heya,

I've just blogged a status update of the KDE on Windows initiative.

Please read: 
  http://kfunk.org/2016/06/18/kde-on-windows-update/

Cheers!
Kevin

--

-- 
Kevin Funk | kfunk@... | http://kfunk.org
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Kevin Funk | 16 Jun 16:08 2016
Picon
Gravatar

Heads up: Emerge: Upgrade to Qt 5.6

Heya,

we've dropped support for everything below Qt 5.6 recently (as part of cleanup 
efforts) in Emerge.

So you if you have something like this in kdesettings.ini:

[PortageVersions]
Qt5 = 5.5

... please either let it point to 5.6 (git branch) or 5.6.1 (tarballs).

Thanks,
Kevin

--

-- 
Kevin Funk | kfunk@... | http://kfunk.org
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Picon

[Bug 364143] New: kde-windows installer not ran as admin by default

https://bugs.kde.org/show_bug.cgi?id=364143

            Bug ID: 364143
           Summary: kde-windows installer not ran as admin by default
           Product: kde-windows
           Version: unspecified
          Platform: MS Windows
                OS: MS Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: installer
          Assignee: kde-windows <at> kde.org
          Reporter: logixoul <at> gmail.com

KDE version: 4.10.2

By default the installer is not ran with Administrator privileges, so it fails
when it gets to putting files in C:\Program Files.
This applies both when initially running the installer after downloading it,
and when running the already-installed copy of the installer.

Reproducible: Always

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
(Continue reading)

Picon

[frameworks-kdoctools] [Bug 362849] meinproc5.exe searches the wrong path for kdoctools

https://bugs.kde.org/show_bug.cgi?id=362849

Lays Rodrigues <laysrodriguessilva <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laysrodriguessilva <at> gmail.co
                   |                            |m

--- Comment #7 from Lays Rodrigues <laysrodriguessilva <at> gmail.com> ---
(In reply to Jasem Mutlaq from comment #6)
> This bug can be considered "fixed" if it is mentioned in kdesettings.ini NOT
> to use stock Qt. To suggest it is experiment means it could work which is
> not the case.

I had emerge frameworks and everything build fine, witth some issues, but I
could solve them. There's any information that you could give?
I need it to use the Qt in emerge repository, because using qt from qt.io,
didn't work...

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Dāvis Mosāns | 2 Jun 04:45 2016
Picon
Gravatar

Review Request 128079: Double quote paths so they can contain whitespace

This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128079/

Review request for kdewin.
By Dāvis Mosāns.
Repository: emerge

Description

Currently if DownloadDir contains spaces it won't work so need to double quote paths so they can contain whitespace

Testing

Tested with DownloadDir which contains spaces and now it works correctly

Diffs

  • bin/utils.py (b2a26bcf34e03e438916f050f73618d5322ac437)

View Diff

_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Jonathan Schultz | 2 Jun 04:00 2016

Pre-built KF5 archives and okular

Hi Thomas and friends,

First of all, thank you so much Thomas for providing those archives. 
Without them I'd probably still be struggling to build any KDE apps on 
Windows. Now I can build okular using mingw/x86 which is a great start.

That said, I have a few comments and further questions. Your assistance 
with any of them would be most appreciated.

1. The README says that the builds require at least Windows 8.1 
Everything I describe below I have tried using both Windows 8.1 and 
Windows 7, and have seen no difference at all between the two.

2. Of the archives, only the first one (KF5_emerge.7z) allows me to 
build okular, and succeeds with no extra intervention. This tells me 
that there is no big problem preventing okular from building. However, 
with the other archives I find that I'm getting some linking errors. 
Using KF5_emerge_MinGW4.9.2.7z the build fails on libcurl with the 
following output:

> K:/k/lib/libcrypto.a(bss_sock.o):bss_sock.c:(.text+0x90): undefined reference to `_imp__shutdown <at> 8'
> K:/k/lib/libcrypto.a(bss_sock.o):bss_sock.c:(.text+0x1c0): undefined reference to `_imp__shutdown <at> 8'

And using the MSVC archive KF5_emerge_MsVS2013.7z it fails building 
libspectre with the following:

> [ 75%] Linking C shared library spectre.dll
>    Creating library spectre.lib and object spectre.exp
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_new_instance referenced in
function _spectre_gs_create_instance
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_delete_instance referenced in
function _spectre_gs_cleanup
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_set_stdio referenced in
function _spectre_gs_create_instance
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_set_display_callback
referenced in function _spectre_gs_set_display_callback
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_init_with_args referenced in
function _spectre_gs_run
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_run_string_begin referenced in
function _spectre_gs_process
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_run_string_continue
referenced in function _spectre_gs_process
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_run_string_end referenced in
function _spectre_gs_process
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_run_string_with_length
referenced in function _spectre_gs_send_string
> spectre-gs.c.obj : error LNK2019: unresolved external symbol _gsapi_exit referenced in function _spectre_gs_cleanup
> spectre.dll : fatal error LNK1120: 10 unresolved externals

3. Finally I have also tried to replicate your build process (partly to 
prove to myself that I can do it, but also so that I can build a 64 bit 
version) and it fails with:

> In file included from K:\k\download\git\qtbase\src\plugins\platforms\windows\qwindowsfontdatabase_ft.h:37:0,
>                  from K:\k\download\git\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp:45:
>
..\..\..\..\include\QtPlatformSupport\5.5.1/QtPlatformSupport/private/qbasicfontdatabase_p.h:1:124:
fatal error:
../../../../../../../../../../download/git/qtbase/src/platformsupport/fontdatabases/basic/qbasicfontdatabase_p.h:
No such file or directory

What I notice here is that the file 
.../QtPlatformSupport/private/qbasicfontdatabase_p.h is in different 
locations in the different builds. In your three archives there is a 
copy under k/include while when I try to build it is only under 
k/build/libs/qtbase/work/mingw-w64-RelWithDebInfo-5.5/include There are 
some other differences too, which I can describe if that would help, but 
I'm hoping that in the meantime someone can tell me what might be going 
wrong.

Many thanks,

Jonathan
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Picon

[frameworks-kdoctools] [Bug 362849] meinproc5.exe searches the wrong path for kdoctools

https://bugs.kde.org/show_bug.cgi?id=362849

--- Comment #6 from Jasem Mutlaq <mutlaqja <at> ikarustech.com> ---
This bug can be considered "fixed" if it is mentioned in kdesettings.ini NOT to
use stock Qt. To suggest it is experiment means it could work which is not the
case.

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Jasem Mutlaq | 28 May 19:50 2016

KF5 fails to load Windows executables located in the application bin directory

Hello,

I already filed a bug with the same name here:


So is the way to resolve this issue by patching findExectable Qt function so that it also searches in the current application directory under Windows?

--
Best Regards,
Jasem Mutlaq

_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Picon

[Bug 363613] New: emerge --package does not remove hard links to build path from executables

https://bugs.kde.org/show_bug.cgi?id=363613

            Bug ID: 363613
           Summary: emerge --package does not remove hard links to build
                    path from executables
           Product: kde-windows
           Version: unspecified
          Platform: MS Windows
                OS: MS Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: installer
          Assignee: kde-windows <at> kde.org
          Reporter: mutlaqja <at> ikarustech.com

My KDEROOT is D:\k and under it I ran emerge --package kstars, It created an
installer which I then installed on a fresh Win10 VM. The application runs but
when I tried using "Get Hot New Stuff" AKA KNewStuff, it "failed to load
providers". Since this feature requires that kdeinit5.exe is invoked which then
executes dbus-daemon.exe and klauncher.exe for this to work, it only started
dbus-daemon.exe

But it seems all executable files already point to the build location in the
primary machine (i.e. D:\k). When I launched klauncher.exe manually, I got this
message inside the fresh VM:

"path of the process "dbus-daemon" seems to be outside of the installPath:
"C:/Program Files/KStars Desktop Planetarium/bin" "D:/k"
QDBusConnection: session D-Bus connection created before QCoreApplication.
Application may misbehave.

Furthermore, I started dbus-monitor.exe and got this:

signal time=1464388944.096486 sender=org.freedesktop.DBus -> destination=:1.5
serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=NameAcquired
   string ":1.5"
signal time=1464388944.111972 sender=org.freedesktop.DBus -> destination=:1.5
serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=NameLost
   string ":1.5"
method call time=1464388955.643587 sender=:1.0 ->
destination=org.freedesktop.DBus serial=22 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameHasOwner
   string "org.kde.klauncher5"
method return time=1464388955.658837 sender=org.freedesktop.DBus ->
destination=:1.0 serial=11 reply_serial=22
   boolean true
method call time=1464388955.658837 sender=:1.0 ->
destination=org.kde.klauncher5 serial=23 path=/KLauncher;
interface=org.kde.KSlaveLauncher; member=requestSlave
   string "http"
   string "edu.kde.org"
   string "tcp://127.0.0.1:50230"
method return time=1464388955.688128 sender=:1.2 -> destination=:1.0 serial=9
reply_serial=23
   int32 0
   string "Error loading 'D:/k/bin/kioslave'.

So it is clear that the emerge --package does not create an independent package
from the build location at this point which is leading to these errors.

Reproducible: Always

Steps to Reproduce:
1. Use emerge --package to create a package
2. Install on a fresh VM
3. Use any feature that requires klauncher, dbus, or kinit like KNewStuff

Actual Results:  
KNewStuff fails "failed to load providers"

Expected Results:  
KNewStuff works along with dbus calls..etc

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows
Picon

[Bug 363467] New: Portage fails to construct runtime dependencies for packages under kde/applications

https://bugs.kde.org/show_bug.cgi?id=363467

            Bug ID: 363467
           Summary: Portage fails to construct runtime dependencies for
                    packages under kde/applications
           Product: kde-windows
           Version: unspecified
          Platform: MS Windows
                OS: MS Windows
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: buildsystem
          Assignee: kde-windows <at> kde.org
          Reporter: mutlaqja <at> ikarustech.com

While trying to use 'emerge --package kstars', the emerge process never finds
the required runtime dependencies for KStars and install them as needed to the
archive directory.

After a bit of investigation, the problem turns out to be getDependencies(
category, package, runtimeOnly = False ): function in portage.py.

For applications that fall under portage/kde/applications/*, the function
returns the subpackage as "applications" but that fails when it tries to call 
_getSubinfo("kde", "applications) as it cannot find the applications.py file
since it doesn't exist.

Attached is a small patch that fixes this problem. However, a bigger issue is
that tree layout itself. There are many applications (kdevelop, ktorrent, k3b)
that fall under portage's "extragear" while others fall under
"kde/applications". What's the reason for this? It seems inconsistent.

Reproducible: Always

Steps to Reproduce:
1. emerge --package kstars
2. 
3.

Actual Results:  
no runtime dependencies installed

Expected Results:  
runtime dependencies installed

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Kde-windows mailing list
Kde-windows <at> kde.org
https://mail.kde.org/mailman/listinfo/kde-windows

Gmane