Opened 12 years ago

Last modified 4 years ago

#38099 new submission

Portfile for Krita

Reported by: patrik.andersson.se@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: cooljeanius (Eric Gallager), eirnym (Eir Nym)
Port:

Description

I have hacked a Portfile for Krita, I think it needs a review, before it get official. I succeded to install by those command listed in the Portfile.

To make krita work nice, you have to apply a theme under the settings menu.

Attachments (7)

Portfile (1.7 KB) - added by patrik.andersson.se@… 12 years ago.
Portfile.diff (4.4 KB) - added by cooljeanius (Eric Gallager) 12 years ago.
diff for the portfile author to apply to his portfile
Portfile.2 (2.5 KB) - added by patrik.andersson.se@… 12 years ago.
Revised Portfile
Portfile.3 (2.5 KB) - added by patrik.andersson.se@… 12 years ago.
draft 3
Portfile.4 (2.7 KB) - added by patrik.andersson.se@… 12 years ago.
Working Portfile
run.log (2.6 KB) - added by patrik.andersson.se@… 12 years ago.
Errors while running it
main.log (26.2 MB) - added by patrik.andersson.se@… 12 years ago.
Krita-builds log

Change History (31)

Changed 12 years ago by patrik.andersson.se@…

Attachment: Portfile added

comment:1 Changed 12 years ago by cooljeanius (Eric Gallager)

comment:2 Changed 12 years ago by patrik.andersson.se@…

So I should submit it somewhere else?

Version 0, edited 12 years ago by patrik.andersson.se@… (next)

comment:3 in reply to:  1 ; Changed 12 years ago by patrik.andersson.se@…

Replying to egall@…:

You should probably use the kde4 portgroup for this: https://svn.macports.org/repository/macports/trunk/dports/_resources/port1.0/group/kde4-1.1.tcl

So I should submit it somewhere else?

comment:4 in reply to:  3 ; Changed 12 years ago by cooljeanius (Eric Gallager)

Replying to patrik.andersson.se@…:

Replying to egall@…:

You should probably use the kde4 portgroup for this: https://svn.macports.org/repository/macports/trunk/dports/_resources/port1.0/group/kde4-1.1.tcl

So I should submit it somewhere else?

No, this is the right place, I was just suggesting you use the kde4 portgroup when writing the portfile. I'm working on a diff that uses it now...

comment:5 in reply to:  4 Changed 12 years ago by patrik.andersson.se@…

Replying to egall@…:

Replying to patrik.andersson.se@…:

Replying to egall@…:

You should probably use the kde4 portgroup for this: https://svn.macports.org/repository/macports/trunk/dports/_resources/port1.0/group/kde4-1.1.tcl

So I should submit it somewhere else?

No, this is the right place, I was just suggesting you use the kde4 portgroup when writing the portfile. I'm working on a diff that uses it now...

Great!

Changed 12 years ago by cooljeanius (Eric Gallager)

Attachment: Portfile.diff added

diff for the portfile author to apply to his portfile

comment:6 Changed 12 years ago by cooljeanius (Eric Gallager)

OK, I've attached a diff for you. I haven't been able to test it myself though, because libiodbc doesn't have a +quartz variant. It passes lint now though.

comment:7 in reply to:  6 Changed 12 years ago by patrik.andersson.se@…

Replying to egall@…:

OK, I've attached a diff for you. I haven't been able to test it myself though, because libiodbc doesn't have a +quartz variant. It passes lint now though.

Thank you for the review! I'm trying to rewrite it so it fits the port system better.

comment:8 Changed 12 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Changed 12 years ago by patrik.andersson.se@…

Attachment: Portfile.2 added

Revised Portfile

comment:9 Changed 12 years ago by patrik.andersson.se@…

I have changed the port so it will build correct in the working dir. It fails during the activation stage. I have attached a log where the option "destroot.violate_mtree yes" was not set in the Portfile.

:debug:destroot Executing portdestroot::destroot_finish
:debug:destroot checking for mtree violations
:warn:destroot violation by /include
:warn:destroot violation by /lib
:warn:destroot violation by /share
:warn:destroot krita violates the layout of the ports-filesystems!
:warn:destroot Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases!
:debug:destroot changing euid/egid - current euid: 0 - current egid: 0
:debug:destroot egid changed to: 502
:debug:destroot euid changed to: 503
:debug:install install phase started at Sun Feb 17 22:44:14 CET 2013
:notice:install --->  Installing krita @2.6.0_0
:debug:install Can't run install on this port without elevated privileges. Escalating privileges back to root.
:debug:install euid changed to: 0. egid changed to: 0.
:debug:install Executing org.macports.install (krita)
:info:install kbuildsycoca4 running...
:debug:activate activate phase started at Sun Feb 17 22:44:20 CET 2013
:debug:activate Executing org.macports.activate (krita)
:error:activate org.macports.activate for port krita returned: Registry error: krita @2.6.0_0 is not installed.
:debug:activate Error code: registry::invalid
:debug:activate Backtrace: Registry error: krita @2.6.0_0 is not installed.
    invoked from within
"throw registry::invalid "Registry error: ${name}${composite_spec} is not installed.""
    (procedure "_check_registry" line 38)
    invoked from within
"_check_registry $name $version $revision $variants"
    invoked from within
"registry::read {

        set requested [_check_registry $name $version $revision $variants]
        # set name again since the one we were passed may..."
    (procedure "portimage::activate" line 19)
    invoked from within
"registry_activate $subport $version $revision $portvariants [array get user_options]"
    (procedure "portactivate::activate_main" line 4)
    invoked from within
"$procedure $targetname"
:info:activate Warning: targets not executed for krita: org.macports.activate
:notice:activate Please see the log file for port krita for details:
    /opt/local/var/macports/logs/_Users_patrikandersson_ports_kde4_krita/krita/main.log

comment:10 in reply to:  9 Changed 12 years ago by larryv (Lawrence Velázquez)

Replying to patrik.andersson.se@…:

I have changed the port so it will build correct in the working dir. It fails during the activation stage. I have attached a log where the option "destroot.violate_mtree yes" was not set in the Portfile.

You should not be installing files outside of the MacPorts prefix without a very good reason.

comment:11 Changed 12 years ago by jmroot (Joshua Root)

You're overriding the install phase and not doing any of what the install phase needs to do. The code in your custom install phase should be run in post-activate if anywhere (though I'm not convinced it should be run automatically at all).

comment:12 in reply to:  11 Changed 12 years ago by patrik.andersson.se@…

Replying to jmr@…:

You're overriding the install phase and not doing any of what the install phase needs to do. The code in your custom install phase should be run in post-activate if anywhere (though I'm not convinced it should be run automatically at all).

I put it in the post-activate phase and it works better, but now it says that the build is broken and the log is empty. Probably it has to do with krita's installation-phase, since it then creates some folders(destroot/lib,share,include), see log above.

--->  Computing dependencies for krita
--->  Cleaning krita
--->  Deactivating krita @2.6.0_0
--->  Cleaning krita
--->  Uninstalling krita @2.6.0_0
--->  Cleaning krita
--->  Computing dependencies for krita
--->  Fetching distfiles for krita
--->  Verifying checksum(s) for krita
--->  Extracting krita
--->  Configuring krita
--->  Building krita
--->  Staging krita into destroot
Warning: krita installs files outside the common directory structure.
--->  Installing krita @2.6.0_0
--->  Activating krita @2.6.0_0
##########################################################
# Don't forget that dbus needs to be started as the local 
# user (not with sudo) before any KDE programs will launch
# To start it run the following command:                  
# launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
##########################################################
--->  Cleaning krita
--->  Updating database of binaries: 100.0%
--->  Scanning binaries for linking errors: 100.0%
--->  Found 1312 broken file(s), matching files to ports
Warning: No port py-gtk2 found in the index; can't rebuild
Error: Port krita is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Port krita still broken after rebuilding 3 time(s)
    while executing
"error "Port $portname still broken after rebuilding [expr $broken_port_counts($port
    (procedure "revupgrade_scanandrebuild" line 268)
    invoked from within
"revupgrade_scanandrebuild broken_port_counts $opts"
    (procedure "macports::revupgrade" line 5)
    invoked from within
"macports::revupgrade $opts"
    (procedure "action_revupgrade" line 2)
    invoked from within
"action_revupgrade $action $portlist $opts"
    (procedure "action_target" line 94)
    invoked from within
"$action_proc $action $portlist [array get global_options]"
    (procedure "process_cmd" line 95)
    invoked from within
"process_cmd $remaining_args"
    invoked from within
"if { [llength $remaining_args] > 0 } {

    # If there are remaining arguments, process those as a command
    set exit_status [process_cmd $remaining..."
    (file "/opt/local/bin/port" line 4785)

Changed 12 years ago by patrik.andersson.se@…

Attachment: Portfile.3 added

draft 3

comment:13 Changed 12 years ago by larryv (Lawrence Velázquez)

Why do you override build and destroot with phases that basically do the same thing that the default build and destroot do? And you’re still installing files outside of the prefix. Why?

Please install using sudo port -k install and attach a new main.log. (The -k switch prevents MacPorts from automatically cleaning.)

comment:14 Changed 12 years ago by patrik.andersson.se@…

The reason why I override the build-phase was because it did "make all" and it failed for Krita. I will try run without the modifications of destroot and post results tonight.

I was asked by the maintainer of krita if I could create a port to simplify the installation on krita, so I did an attempt. But since I'm not an active developer in the Krita-project, I only use their current build system which is a bit different from the usual ./configure & make & make install since it uses cmake instead. Their build-system do creates some folders which apparently is outside the prefix, well it could be my fault as well,

system -W ${workpath} "cmake -DCMAKE_INSTALL_PREFIX=${destroot} \
    ${worksrcpath} -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCREATIVEONLY=ON"

I thought ${destroot} would be a suitable prefix for the install prefix, then it will create some subfolder like ./lib ./share and ./include in DCMAKE_INSTALL_PREFIX. Could this be changed to a better prefix to prevent it installing outside the prefix?

comment:15 in reply to:  14 ; Changed 12 years ago by larryv (Lawrence Velázquez)

Replying to patrik.andersson.se@…:

The reason why I override the build-phase was because it did "make all" and it failed for Krita. I will try run without the modifications of destroot and post results tonight.

You can accomplish this by setting build.target to nothing. (Its default value is “all”.) But I don’t see why make should work while make all fails.

I only use their current build system which is a bit different from the usual ./configure & make & make install since it uses cmake instead.

I thought ${destroot} would be a suitable prefix for the install prefix, then it will create some subfolder like ./lib ./share and ./include in DCMAKE_INSTALL_PREFIX. Could this be changed to a better prefix to prevent it installing outside the prefix?

You should look into using the cmake PortGroup, which handles a lot of the work required for using CMake. You can use it by changing the top of your portfile to

PortSystem  1.0
PortGroup   kde4 1.1
PortGroup   cmake 1.0

Once you do this, you should be able to remove your custom configure, build, and destroot phases, as well as the “destroot.violate_mtree” bit.

comment:16 in reply to:  15 ; Changed 12 years ago by cooljeanius (Eric Gallager)

Replying to larryv@…:

Replying to patrik.andersson.se@…:

The reason why I override the build-phase was because it did "make all" and it failed for Krita. I will try run without the modifications of destroot and post results tonight.

You can accomplish this by setting build.target to nothing. (Its default value is “all”.) But I don’t see why make should work while make all fails.

I only use their current build system which is a bit different from the usual ./configure & make & make install since it uses cmake instead.

I thought ${destroot} would be a suitable prefix for the install prefix, then it will create some subfolder like ./lib ./share and ./include in DCMAKE_INSTALL_PREFIX. Could this be changed to a better prefix to prevent it installing outside the prefix?

You should look into using the cmake PortGroup, which handles a lot of the work required for using CMake. You can use it by changing the top of your portfile to

PortSystem  1.0
PortGroup   kde4 1.1
PortGroup   cmake 1.0

Once you do this, you should be able to remove your custom configure, build, and destroot phases, as well as the “destroot.violate_mtree” bit.

The kde4 portgroup actually already includes the cmake portgroup within it, so putting them both would be redundant.

comment:17 in reply to:  16 Changed 12 years ago by larryv (Lawrence Velázquez)

Replying to egall@…:

The kde4 portgroup actually already includes the cmake portgroup within it, so putting them both would be redundant.

Even better.

comment:18 Changed 12 years ago by patrik.andersson.se@…

No successful build today, the log says that it could not do make install in build-directory. I removed all overriding function and just added some configure options for DCBUILD_TYPE and DCREATIVEONLY, it seems to go better now, when it is better integrated the kde port-group. I will publish result tomorrow.

Changed 12 years ago by patrik.andersson.se@…

Attachment: Portfile.4 added

Working Portfile

Changed 12 years ago by patrik.andersson.se@…

Attachment: run.log added

Errors while running it

Changed 12 years ago by patrik.andersson.se@…

Attachment: main.log added

Krita-builds log

comment:19 Changed 12 years ago by patrik.andersson.se@…

Now "sudo port install krita" does not leaves any errors, but I'm unable to run it as user or super-user. There are some permission problems to be solved, see the run.log for more details. I can also add that Krita writes on its homepage that you shall not do this as root.

comment:20 Changed 12 years ago by patrik.andersson.se@…

Can someone test my latest portfile?

comment:21 Changed 12 years ago by cooljeanius (Eric Gallager)

There's a separate ticket for the entire Calligra suite, which includes Krita, here: #37579

comment:22 Changed 9 years ago by eirnym (Eir Nym)

Please update Krita

comment:23 Changed 9 years ago by eirnym (Eir Nym)

Cc: eirnym@… added

Cc Me!

comment:24 Changed 4 years ago by cooljeanius (Eric Gallager)

so, I've tried picking this up again, and fetching 404s on me... any updated download URL to use?

Note: See TracTickets for help on using tickets.