Opened 10 years ago

Closed 10 years ago

#47064 closed submission (fixed)

Update port:rkward to version 0.6.3

Reported by: thomas.friedrichsmeier@… Owned by: mkae (Marko Käning)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: rkward

Description

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.

Attachments (1)

rkward_port.diff (2.3 KB) - added by thomas.friedrichsmeier@… 10 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 10 years ago by mkae (Marko Käning)

Cc: mk@… removed
Owner: changed from macports-tickets@… to mk@…
Version: 2.3.3

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

Changed 10 years ago by thomas.friedrichsmeier@…

Attachment: rkward_port.diff added

comment:2 Changed 10 years ago by mkae (Marko Käning)

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

comment:3 Changed 10 years ago by 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)

comment:4 in reply to:  2 ; Changed 10 years ago by 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.

comment:5 in reply to:  4 ; Changed 10 years ago by 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

Last edited 10 years ago by mkae (Marko Käning) (previous) (diff)

comment:6 in reply to:  5 ; Changed 10 years ago by 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

comment:7 Changed 10 years ago by mkae (Marko Käning)

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

Version 0, edited 10 years ago by mkae (Marko Käning) (next)

comment:8 in reply to:  6 Changed 10 years ago by 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.

comment:9 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by mkae (Marko Käning)

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.