Update port:rkward to version 0.6.3

[thomas.friedrichsmeier@…]

Hi Marko,

here's my diff. Please note that it is not tested, in particular the livecheck.url. I'll try to do some testing, later, but I hope most changes are obvious enough so that you can easily iron over my errors.

Seems I can't assign you as owner, but I hope I've put you in CC, successfully.

Again, a summary of the changes:

• We moved from SF.net to KDE.org, thus changed

homepage, maintainers (list address), master_sites, livecheck.url

• Added a patch to correct a problem starting the dbus session bus that we discovered after creating the tarball.
• Not sure, if the pre-activate section is still needed, I did not patch that out.

[mkae (Marko Käning)]

Thanks for the submission. Will deal with it later. :)

[mkae (Marko Käning)]

I don't understand what the patch is for. It seems like a NULL patch to me. :)

[mkae (Marko Käning)]

For some strange reason the download fails:

MVM7:rkward marko$ sudo port install
--->  Computing dependencies for rkward
--->  Fetching archive for rkward
--->  Attempting to fetch rkward-0.6.3_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/rkward
--->  Attempting to fetch rkward-0.6.3_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/rkward
--->  Attempting to fetch rkward-0.6.3_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/rkward
--->  Fetching distfiles for rkward
--->  Attempting to fetch rkward-0.6.3.tar.gz from http://download.kde.org/stable/rkward/0.6.3/src/rkward-0.6.3.tar.gz
--->  Attempting to fetch rkward-0.6.3.tar.gz from http://nue.de.distfiles.macports.org/macports/distfiles/rkward
...
--->  Attempting to fetch rkward-0.6.3.tar.gz from http://svn.macports.org/repository/macports/distfiles/rkward
Error: org.macports.fetch for port rkward returned: fetch failed
Please see the log file for port rkward for details:
    /opt/local/var/macports/logs/_Users_marko_WC_SVN_MacPorts_dports_kde_rkward/rkward/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port rkward failed
MVM7:rkward marko$ 

I verified that the tarball is indeed in place, but port simply won't grab it. Could redirection be the cause for that? I noticed that download.kde.org somehow redirects to some "alpha"-something (vanished too quickly)

[thomas.friedrichsmeier@…]

Replying to mk@…:

I don't understand what the patch is for. It seems like a NULL patch to me. :)

Come a little closer: "lanuchctl". See? ;-)

Very sorry about the master_sites-problem. Clearly shows the value of testing... I will try to actually test this, but not sure, I can make it today.

[mkae (Marko Käning)]

Hi Thomas,

Replying to thomas.friedrichsmeier@…:

Come a little closer: "lanuchctl". See? ;-)

Isn't indeed amazing how the human brain's perception is making it sometimes impossible to see TME difference?!

In fact I have read/compared the patch umpteen times, wondering what it was doing. I WAS comparing letter by letter, but I did - for the heck of it - not spot the swapped 'u' and 'n'! :-/

Very sorry about the master_sites-problem. Clearly shows the value of testing... I will try to actually test this, but not sure, I can make it today.

I have reworked your submission a little and committed it in r133661 (after I had messed up in r133660).

Currently the ​buildbots are stuck which is why I don't know whether removing the pre-activate stuff is okay, but it should be. I'll leave this ticket open for now, until the buildbots are up again and I know for sure that RKWard built fine on all of them. When testing it I noticed that RKWard now places only 1 app icon in the dock, which is nice! ;-)

Re the patch content I wonder why you actually call launchctl. dbus should be running anyway on MacPorts, once you installed KDE through it. OTOH this seems to be a nice way for the app itself to make sure that dbus is running, which obsoletes user intervention if you install the application including MacPorts/KDE on a new machine... Cool! I think this is something which could/should be built into KApplication, what do you think!!?

Thanks for your submission, Marko

[thomas.friedrichsmeier@…]

Replying to mk@…:

In fact I have read/compared the patch umpteen times, wondering what it was doing. I WAS comparing letter by letter, but I did - for the heck of it - not spot the swapped 'u' and 'n'! :-/

Well it would probably be easier to see the mark, where I hit myself on the forehead, when I found this typo...

I have reworked your submission a little and committed it in r133661 (after I had messed up in r133660).

Thanks!

Re the patch content I wonder why you actually call launchctl. dbus should be running anyway on MacPorts, once you installed KDE through it. OTOH this seems to be a nice way for the app itself to make sure that dbus is running, which obsoletes user intervention if you install the application including MacPorts/KDE on a new machine... Cool! I think this is something which could/should be built into KApplication, what do you think!!?

Yes, the idea is that you don't have to worry about bringing up the (per user) session bus, while the system bus should have been taken care of during installation. In our case this was really easy to add, as we already have need a wrapper to start up correctly. Yes, if this was built into KApplication - trying to start the session bus, if it could not be connected to - could clearly eliminate one potential cause of grief, when trying to run KDE apps. No idea how KDE on Windows is doing this, but their installation can be moved to a different machine entirely without worrying about dbus.

Regards

Thomas

[mkae (Marko Käning)]

Turns out building fails on the buildbots - see e.g. for ​Mavericks!

Will investigate tomorrow.

[mkae (Marko Käning)]

Replying to thomas.friedrichsmeier@…:

Yes, the idea is that you don't have to worry about bringing up the (per user) session bus, while the system bus should have been taken care of during installation. In our case this was really easy to add, as we already have need a wrapper to start up correctly. Yes, if this was built into KApplication - trying to start the session bus, if it could not be connected to - could clearly eliminate one potential cause of grief, when trying to run KDE apps. No idea how KDE on Windows is doing this, but their installation can be moved to a different machine entirely without worrying about dbus.

Yes, I think we should discuss this on KDE-MAC.

BTW, as far as I know the system bus doesn't need to be started anymore with the current dbus version.

[mkae (Marko Käning)]

We've got the same problem like last time:

Error: org.macports.activate for port rkward returned:
   Image error: /opt/local/Library/Frameworks/R.framework/Resources/library/rkward/CITATION
   already exists and does not belong to a registered port.
   Unable to activate port rkward. Use 'port -f activate rkward' to force the activation.
   DEBUG: Error code: registry::image-error

This is probably easily fixable by re-adding the pre-activate code, but I'll first try to investigate which files are on the buildbots ATM.

[mkae (Marko Käning)]

r134054 is another try of analysis of this issue - as recommended on the developer ML - using ls -ltR on the interesting folders.

[mkae (Marko Käning)]

This can be considered closed for now until the next rev bump, see also r134150.