Description: KPorts is Qt-based frontend to the FreeBSD-Ports. Support for the OpenBSD-Ports and PkgSrc is planned for a future release. It is designed to make managing your applications easier and more pleasent.
For more information, take a look at the homepage.
If you would like to help with translations, artwork or coding PLEASE let me know.Last changelog:
[0.8.2]
FEATURES: * Experimental support for updating the ports-tree
BUGFIXES: * Bogus-Ports appearing in the tree (r96) * Ports added twice (r96) * Vulnerability Database now works correctly, it is updated on each start * Bug fixed where Installed packages where not read on start * fixed support for changing the icon-theme * little freeze on startup fixed, startup is now much faster * search results are now clickable again (don't know if this actually was broken in 0.8.1 or only inbetween)
TRANSLATIONS: * Portuguese Translation added (thanks to Marcio!)
MISC: * h2 is now co-maintainer * KPorts now shares the FTPINDEX with bsdadminscripts and uses uma to update it * KPorts attains a lock from uma on startup, so as not to conflict with other tools
KNOWN ISSUES: * higher memory usage after updating and re-reading the ports tree * a patched version of portsnap is packed, because nobody is looking into: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/136325
When I try to upgrade port without portupgrade presence in system, I have a "information windows" storm - KPorts generated window with messge "portupgrade not found, use Konsole button to see unfiltered output" in endless loop.
i am really sorry for that.
alltogether development has been going rather slow in the last months with no release since last summer.
i am working on it, but i havent decided yet, if the next release will be a qt4 release (which would delay it further) or if a release version earlier....
the next version will definitey have this problem fixed, though...
Great tool indeed!
I have these suggestions which marked as questions ;)
1. How about making it work with DBSD tools as well?
2. Could you please make it uses portsnap which is faster than cvsup-without-gui?
what do you mean by "making it work with dbsdtools?
you can install both at the same time on dbsd/freebsd...
or did you mean "integrate" it into dbsd? i wanted to do that, but desktopbsd has its own packagemanager gui and doesnt want mine...
portsnap support will probably be in the next version :)
thanks for your interest!
Yes, I meant integrate it with the DBSD tools.
If they don't agree I can understand that, but I'm sure you can integrate Kports with the PCBSD guys, they will welcome you, and they like your port, check this thread about it.
http://forums.pcbsd.org/viewtopic.php?t=6574&highlight=kports
I'll be waiting for portsnap addition and I hope it will happen very soon ;)
i know most pcbsd users like kports, but the the pcbsd crew thinks ports and everything else that isnt pbi is evil ;)
no seriously, i talked with them, they do not want to support alternatives to pbi.
I have just finished compile and install 0.6.1 on 6.1-RELEASE. But, ports tree contains 0.6.0 version, marked as "BROKEN". Will you send a PR to update FreeBSD port up to 0.6.1?
i already sent the patch more than a week ago, they semm ti be a little slow right now...
you could change the makefile yourself, or just use package if you want kports to be registered as a clean port ;)
note that 0.6.1 has NOTHING new compared to 0.6.0, except the bug being fixed that is preventing build of 0.6.0 in the ports system.
a new version, with new features and a cleaner interface is being worked on!
stay tuned :D
how about putting it in FreeBSD's ports system ?? It's be real useful to be able to install it from ports and use the tool or portupgrade to update it as new versions come out :-D
Nice tool. I have searched a very long time a tool to do this (KBarry and KPackage are SUXX!). But could you please add 'make package' action to produce package from installed port (like pkg_create -b port_name)?
thanks for the feedback!
i put it on my TODO-list, alltogether i will start implementing developer features, like advanced pkg_creation and maybe even ports-dir creation for homemade software, after most user-features are there and at least pkgsrc is supported, but the feature you requested doesnt seem to complicated, so i'll think about adding it sooner! :d
greetings
i think that - due to the differences in package management systems - one graphical frontend is not recomendable.
on the other hand i would recommend that kpackage get kparts functionality and load the kports kpart if bsd is selected and load the kuroo kpart(i dont know if it has kpart support but just f.ex.) if gentoo is selected et cetera. this way kpackage will be able to support all special features of a packaging system and have individually supported parts.
i will request this as feature on bugs.kde.org
should this not be accepted i might look into working on kpackage once kports is final
KPorts distribution missed some files? I have just tried to compile KPorts on FreeBSD 5.3-RELEASE, but failed with:
gmake all-recursive
gmake[1]: Entering directory `/usr/home/shelton/program/kports'
Making all in doc
gmake[2]: Entering directory `/usr/home/shelton/program/kports/doc'
gmake[3]: Entering directory `/usr/home/shelton/program/kports/doc'
gmake[3]: Nothing to be done for `all-am'.
gmake[3]: Leaving directory `/usr/home/shelton/program/kports/doc'
gmake[2]: Leaving directory `/usr/home/shelton/program/kports/doc'
Making all in src
gmake[2]: Entering directory `/usr/home/shelton/program/kports/src'
if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/kde3/include -I/usr/X11R6/qt33/include -I
/usr/X11R6/include -I/usr/local/include -DQT_THREAD_SUPPORT -I/usr/local/include -D_THRE
AD_SAFE -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strin
gs -DNDEBUG -DNO_DEBUG -O2 -fno-exceptions -fno-check-new -fno-common -MT main.o -MD -MP -
MF ".deps/main.Tpo" -c -o main.o main.cpp; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi
In file included from kports.h:31,
from main.cpp:22:
kportsview.h:23:28: kportsviewbase.h: No such file or directory
In file included from kportsview.h:45,
from kports.h:31,
from main.cpp:22:
bsdport.h: In member function `CBSDPort& CBSDPort::operator=(const CBSDPort&)':
bsdport.h:91: warning: no return statement in function returning non-void
bsdport.h: In member function `CBSDPortGroup& CBSDPortGroup::operator=(const CBSDPortGroup
&)':
bsdport.h:214: warning: no return statement in function returning non-void
In file included from kportsview.h:46,
from kports.h:31,
from main.cpp:22:
pref.h:44:27: prefpage1base.h: No such file or directory
pref.h:45:27: prefpage2base.h: No such file or directory
In file included from kportsview.h:46,
from kports.h:31,
from main.cpp:22:
pref.h: At global scope:
pref.h:68: error: expected class-name before '{' token
pref.h:81: error: expected class-name before '{' token
In file included from kportsview.h:47,
from kports.h:31,
from main.cpp:22:
wizards.h:27:34: installbinwizardbase.h: No such file or directory
wizards.h:28:33: uninstallwizardbase.h: No such file or directory
In file included from kportsview.h:47,
from kports.h:31,
from main.cpp:22:
wizards.h:41: error: expected class-name before '{' token
wizards.h:41: warning: `class KPortsInstallBinWizard' has virtual functions but non-virtua
l destructor
wizards.h:73: error: expected class-name before '{' token
wizards.h:99:7: warning: no newline at end of file
In file included from kports.h:31,
from main.cpp:22:
kportsview.h:125: error: expected class-name before '{' token
kportsview.h:125: warning: `class KPortsView' has virtual functions but non-virtual destru
ctor
gmake[2]: *** [main.o] Error 1
gmake[2]: Leaving directory `/usr/home/shelton/program/kports/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/shelton/program/kports'
gmake: *** [all] Error 2
did you do:
WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -f Makefile.cvs
before gmaking? the problem usually occurs if you forget that, or use autoconf and automake manually...
I noticed that KPort does not detect some important make variables correctly. E.g., on my FreeBSD-5.4 the dependencies of x11-toolkits/qt33 say "XFree86-libraries" instead of "xorg-libraries", which is the default (also what I am using) on FreeBSD-5.x.
Also, KPort does not know the changes of port names caused by different options. E.g., x11-toolkits/qt33 is qt-3.3.4 by default, but its name can change to qt-copy-3.3.4 if you choose the option "KDE patches" by doing a make config. Another similar example is editors/vim, which could be vim-6.... or vim-gtk2-6...., depending on user's options.
I guess these limitations are caused by not parsing some Makefile includes, including files in /usr/ports/Mk/, stored user options in /var/db/ports/, and also settings in /etc/make.conf
But nevertheless, KPorts is a good start to give users nice GUI to the ports system. Keep up your good work!
hm this rather strange... i never access the index file directly only through "/usr/ports/make search" and pkgtools; i thought that these already follow the rules and settings you specified...
and again on my system, qt33 shows xorg as dependancy not xfree86 ;) ...
i will however find out for sure and try fixing it before the next release.
The configure script included is an old one with known bugs to FreeBSD. It cannot detect correct PTHREAD_LIBS value if it should be -pthread. You will get something like:
checking for pthread_create in -l-pthread... no
checking for pthread_create in -lpthread... yes
while running it on FreeBSD-5.4. But the correct flag should be -pthread not -lpthread. This problem was introduced sometime around KDE-3.3 and was fixed later.
So I suggest that you use a more up-to-date configure script (or admin directory), or apply patch from FreeBSD ports: /usr/ports/x11/kde3/files/extrapatch-old_configure
This seems to be trivial but actually not. It may cause strange threading-related crashes.
hm i looked into the patch but as far as i read it is supposed to be -lpthread and configure does tell me on my computer:
checking for pthread_create in -lpthread... yes
i will however upgrade my kde(currently 3.4.0) and kdevelop as soon as freebsd has binaries of 3.4.1 on their servers (my pc is too slow for src ;) ), maybe that will solve the problem...
if you know something else i should do let me know (patching configure is not really an option since configure is recreated by autoconf and automake...)
gretings
Ratings & Comments
28 Comments
When I try to upgrade port without portupgrade presence in system, I have a "information windows" storm - KPorts generated window with messge "portupgrade not found, use Konsole button to see unfiltered output" in endless loop.
i am really sorry for that. alltogether development has been going rather slow in the last months with no release since last summer. i am working on it, but i havent decided yet, if the next release will be a qt4 release (which would delay it further) or if a release version earlier.... the next version will definitey have this problem fixed, though...
Great tool indeed! I have these suggestions which marked as questions ;) 1. How about making it work with DBSD tools as well? 2. Could you please make it uses portsnap which is faster than cvsup-without-gui?
what do you mean by "making it work with dbsdtools? you can install both at the same time on dbsd/freebsd... or did you mean "integrate" it into dbsd? i wanted to do that, but desktopbsd has its own packagemanager gui and doesnt want mine... portsnap support will probably be in the next version :) thanks for your interest!
Yes, I meant integrate it with the DBSD tools. If they don't agree I can understand that, but I'm sure you can integrate Kports with the PCBSD guys, they will welcome you, and they like your port, check this thread about it. http://forums.pcbsd.org/viewtopic.php?t=6574&highlight=kports I'll be waiting for portsnap addition and I hope it will happen very soon ;)
i know most pcbsd users like kports, but the the pcbsd crew thinks ports and everything else that isnt pbi is evil ;) no seriously, i talked with them, they do not want to support alternatives to pbi.
I have just finished compile and install 0.6.1 on 6.1-RELEASE. But, ports tree contains 0.6.0 version, marked as "BROKEN". Will you send a PR to update FreeBSD port up to 0.6.1?
i already sent the patch more than a week ago, they semm ti be a little slow right now... you could change the makefile yourself, or just use package if you want kports to be registered as a clean port ;) note that 0.6.1 has NOTHING new compared to 0.6.0, except the bug being fixed that is preventing build of 0.6.0 in the ports system. a new version, with new features and a cleaner interface is being worked on! stay tuned :D
how about putting it in FreeBSD's ports system ?? It's be real useful to be able to install it from ports and use the tool or portupgrade to update it as new versions come out :-D
i have a working port already, but decided to wait for the release of kports 0.5.0 before commiting it to freebsd.
it should soon appear as sysutils/kports
Nice tool. I have searched a very long time a tool to do this (KBarry and KPackage are SUXX!). But could you please add 'make package' action to produce package from installed port (like pkg_create -b port_name)?
thanks for the feedback! i put it on my TODO-list, alltogether i will start implementing developer features, like advanced pkg_creation and maybe even ports-dir creation for homemade software, after most user-features are there and at least pkgsrc is supported, but the feature you requested doesnt seem to complicated, so i'll think about adding it sooner! :d greetings
i have implemented the requested feature, it will be part of the next release (0.5.0) that i will hopefully get finished in the next 2 weeks!
Why nobody want to fix Kpackage on BSD? Kports is in the Utility menu it is for nobody look at Kpackage in System menu? http://bugs.kde.org/show_bug.cgi?id=107278
Why nobody want to fix Kpackage on BSD? Kports is in the Utility menu it is for nobody look at Kpackage in System menu? http://bugs.kde.org/show_bug.cgi?id=107278
i think that - due to the differences in package management systems - one graphical frontend is not recomendable. on the other hand i would recommend that kpackage get kparts functionality and load the kports kpart if bsd is selected and load the kuroo kpart(i dont know if it has kpart support but just f.ex.) if gentoo is selected et cetera. this way kpackage will be able to support all special features of a packaging system and have individually supported parts. i will request this as feature on bugs.kde.org should this not be accepted i might look into working on kpackage once kports is final
you can vote for this wish @ http://bugs.kde.org/show_bug.cgi?id=107652 would be happy if you did :D
KPorts distribution missed some files? I have just tried to compile KPorts on FreeBSD 5.3-RELEASE, but failed with: gmake all-recursive gmake[1]: Entering directory `/usr/home/shelton/program/kports' Making all in doc gmake[2]: Entering directory `/usr/home/shelton/program/kports/doc' gmake[3]: Entering directory `/usr/home/shelton/program/kports/doc' gmake[3]: Nothing to be done for `all-am'. gmake[3]: Leaving directory `/usr/home/shelton/program/kports/doc' gmake[2]: Leaving directory `/usr/home/shelton/program/kports/doc' Making all in src gmake[2]: Entering directory `/usr/home/shelton/program/kports/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/kde3/include -I/usr/X11R6/qt33/include -I /usr/X11R6/include -I/usr/local/include -DQT_THREAD_SUPPORT -I/usr/local/include -D_THRE AD_SAFE -Wnon-virtual-dtor -Wno-long-long -Wundef -Wall -W -Wpointer-arith -Wwrite-strin gs -DNDEBUG -DNO_DEBUG -O2 -fno-exceptions -fno-check-new -fno-common -MT main.o -MD -MP - MF ".deps/main.Tpo" -c -o main.o main.cpp; \ then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi In file included from kports.h:31, from main.cpp:22: kportsview.h:23:28: kportsviewbase.h: No such file or directory In file included from kportsview.h:45, from kports.h:31, from main.cpp:22: bsdport.h: In member function `CBSDPort& CBSDPort::operator=(const CBSDPort&)': bsdport.h:91: warning: no return statement in function returning non-void bsdport.h: In member function `CBSDPortGroup& CBSDPortGroup::operator=(const CBSDPortGroup &)': bsdport.h:214: warning: no return statement in function returning non-void In file included from kportsview.h:46, from kports.h:31, from main.cpp:22: pref.h:44:27: prefpage1base.h: No such file or directory pref.h:45:27: prefpage2base.h: No such file or directory In file included from kportsview.h:46, from kports.h:31, from main.cpp:22: pref.h: At global scope: pref.h:68: error: expected class-name before '{' token pref.h:81: error: expected class-name before '{' token In file included from kportsview.h:47, from kports.h:31, from main.cpp:22: wizards.h:27:34: installbinwizardbase.h: No such file or directory wizards.h:28:33: uninstallwizardbase.h: No such file or directory In file included from kportsview.h:47, from kports.h:31, from main.cpp:22: wizards.h:41: error: expected class-name before '{' token wizards.h:41: warning: `class KPortsInstallBinWizard' has virtual functions but non-virtua l destructor wizards.h:73: error: expected class-name before '{' token wizards.h:99:7: warning: no newline at end of file In file included from kports.h:31, from main.cpp:22: kportsview.h:125: error: expected class-name before '{' token kportsview.h:125: warning: `class KPortsView' has virtual functions but non-virtual destru ctor gmake[2]: *** [main.o] Error 1 gmake[2]: Leaving directory `/usr/home/shelton/program/kports/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/shelton/program/kports' gmake: *** [all] Error 2
did you do: WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -f Makefile.cvs before gmaking? the problem usually occurs if you forget that, or use autoconf and automake manually...
I noticed that KPort does not detect some important make variables correctly. E.g., on my FreeBSD-5.4 the dependencies of x11-toolkits/qt33 say "XFree86-libraries" instead of "xorg-libraries", which is the default (also what I am using) on FreeBSD-5.x. Also, KPort does not know the changes of port names caused by different options. E.g., x11-toolkits/qt33 is qt-3.3.4 by default, but its name can change to qt-copy-3.3.4 if you choose the option "KDE patches" by doing a make config. Another similar example is editors/vim, which could be vim-6.... or vim-gtk2-6...., depending on user's options. I guess these limitations are caused by not parsing some Makefile includes, including files in /usr/ports/Mk/, stored user options in /var/db/ports/, and also settings in /etc/make.conf But nevertheless, KPorts is a good start to give users nice GUI to the ports system. Keep up your good work!
hm this rather strange... i never access the index file directly only through "/usr/ports/make search" and pkgtools; i thought that these already follow the rules and settings you specified... and again on my system, qt33 shows xorg as dependancy not xfree86 ;) ... i will however find out for sure and try fixing it before the next release.
The configure script included is an old one with known bugs to FreeBSD. It cannot detect correct PTHREAD_LIBS value if it should be -pthread. You will get something like: checking for pthread_create in -l-pthread... no checking for pthread_create in -lpthread... yes while running it on FreeBSD-5.4. But the correct flag should be -pthread not -lpthread. This problem was introduced sometime around KDE-3.3 and was fixed later. So I suggest that you use a more up-to-date configure script (or admin directory), or apply patch from FreeBSD ports: /usr/ports/x11/kde3/files/extrapatch-old_configure This seems to be trivial but actually not. It may cause strange threading-related crashes.
i will look into it asap... it does however work fine for me on freebsd 5.4-prerelease and kde3.4
hm i looked into the patch but as far as i read it is supposed to be -lpthread and configure does tell me on my computer: checking for pthread_create in -lpthread... yes i will however upgrade my kde(currently 3.4.0) and kdevelop as soon as freebsd has binaries of 3.4.1 on their servers (my pc is too slow for src ;) ), maybe that will solve the problem... if you know something else i should do let me know (patching configure is not really an option since configure is recreated by autoconf and automake...) gretings