Adriaan de Groot | 1 Jan 2008 21:47
Picon
Favicon

Re: [ports-sparc64 <at> FreeBSD.org: OpenEXR-1.6.0 failed on sparc64 6]

On Sunday 30 December 2007 18:11, Tilman Linneweh wrote:
> * Mark Linimon [ Dec 26, 2007 (18:28 )]:
> > OpenEXR is coredumping on sparc64-6 and sparc64-7.  This means that
> > kde can't
> > be built for those architectures, including for the releases.  Does
> > anyone
> > have some time to investigate this?  I am willing to assist in
> > testing patches.
>
> I am a bit behind and currently don't have a SPARC, but maybe we can
> get KDE building by just disabling the OpenEXR self-tests?

As FBSD SPARC64 doesn't work on the U45, I'm no help here.
ml-vic | 2 Jan 2008 22:24
Picon

cups doesn't work as a generic user

Context: 
KDE 3.5.8, FreeBSD 7.0-BETA4, laptop centrino duo

I have cups up and running dealing with one real network laser only and a PDF 
printer.

I can print as root from every application while as an ordinary user I can 
print   using cups from any non-kde application like openoffice swriter, 
firefox,etc. Instead no printer is browseable from any kde application. Even 
in kde control center the printer doesn't show up with a 15 code error whilst 
as administrator, root, I can browse  them all.

Please help

Ciao
Vittorio
Bruce M Simpson | 3 Jan 2008 20:17
Favicon
Gravatar

Bringing back kdoc as a port

Hi,

I'm wearing my XORP hat here. We use kdoc to generate the XORP API 
documentation, and have done so for many years.

The most recent version is here:
    http://sirtaj.net/projects/kdoc

* Are there any objections to my rolling a port for it?
* Or reviving the dead port textproc/kdoc?

NOTE: kdoc and kdoctools are NOT the same thing.

cheers
BMS
Andy Fawcett | 3 Jan 2008 21:12
Picon
Favicon

Re: Bringing back kdoc as a port

On Thursday 03 January 2008 21:17:46 Bruce M Simpson wrote:
> Hi,
>
> I'm wearing my XORP hat here. We use kdoc to generate the XORP API
> documentation, and have done so for many years.
>
> The most recent version is here:
>     http://sirtaj.net/projects/kdoc
>
> * Are there any objections to my rolling a port for it?
> * Or reviving the dead port textproc/kdoc?

I don't see any problem with that if you are going to maintain it yourself.

According to that manpage (which is very very old) it requires perl 5.6, but 
doesn't mention any dependencies on KDE at all. I'm not at all familiar with 
kdoc, but providing you can get it to work with the perl 5.8 and the KDE in 
ports, I think you are good to go.

Andy
(with his little bit of the kde <at>  hat on)

--

-- 
Andy Fawcett                                     | andy <at> athame.co.uk
                                                 | tap <at> kde.org
"In an open world without walls and fences,      | tap <at> lspace.org
  we wouldn't need Windows and Gates."  -- anon  | tap <at> fruitsalad.org
arved | 4 Jan 2008 16:56
Picon
Favicon

Re: ports/118860: misc/kdeutils3 and security/kgpg conflict

Synopsis: misc/kdeutils3 and security/kgpg conflict

State-Changed-From-To: open->closed
State-Changed-By: arved
State-Changed-When: Fri Jan 4 15:56:21 UTC 2008
State-Changed-Why: 
committed, thanks

http://www.freebsd.org/cgi/query-pr.cgi?pr=118860
dfilter service | 4 Jan 2008 17:00
Picon
Favicon

Re: ports/118860: commit references a PR

The following reply was made to PR ports/118860; it has been noted by GNATS.

From: dfilter <at> FreeBSD.ORG (dfilter service)
To: bug-followup <at> FreeBSD.org
Cc:  
Subject: Re: ports/118860: commit references a PR
Date: Fri,  4 Jan 2008 15:56:22 +0000 (UTC)

 arved       2008-01-04 15:56:14 UTC

   FreeBSD ports repository

   Modified files:
     security/kgpg        Makefile 
   Log:
   Adjust conflicts

   PR:             118860
   Submitted by:   Anatoly Borodin <anatoly.borodin <at> gmail.com>

   Revision  Changes    Path
   1.22      +1 -1      ports/security/kgpg/Makefile
 _______________________________________________
 cvs-all <at> freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe <at> freebsd.org"
Mikhail Teterin | 4 Jan 2008 20:54

KDE4/Qt4 porting efforts?

Hello!

How is the subject coming along? It seems, some new things like "strigi" are 
required for kdelibs-4 -- but I don't see a port of that in the tree yet... 
Would you like it added?

Given that Qt4 claims to have Qt3-compatibility, maybe, it is a good idea to 
switch KDE3 to Qt4 for the time being, so as to avoid upgrading both pieces 
at once?

Anything else?.. Yours,

 -mi
Adriaan de Groot | 4 Jan 2008 21:41
Picon
Favicon

Re: KDE4/Qt4 porting efforts?

On Friday 04 January 2008 20:54, Mikhail Teterin wrote:
> Given that Qt4 claims to have Qt3-compatibility, maybe, it is a good idea
> to switch KDE3 to Qt4 for the time being, so as to avoid upgrading both
> pieces at once?

Claims and "has a complete source-compatible infrastructure" are two very 
different things, unfortunately. Among other things, many container classes 
have changed fundamentally, lots of widgets have vanished. It's a "fairly 
simple to port" compatibility, not a drop-in replacement.
Adriaan de Groot | 4 Jan 2008 21:42
Picon
Favicon

Re: KDE4/Qt4 porting efforts?

On Friday 04 January 2008 20:54, Mikhail Teterin wrote:
> How is the subject coming along? It seems, some new things like "strigi"
> are required for kdelibs-4 -- but I don't see a port of that in the tree
> yet... Would you like it added?

All the things in kdesupport should have ports created. Since they depend only 
on Qt4 (and possibly other things) this should be fairly straightforward. 
Bear in mind that their build systems are CMake-based. I'm not sure there's 
any infrastructure for CMake-based ports yet.

[ade]
Shane Bell | 5 Jan 2008 09:42
Picon

Re: KDE4/Qt4 porting efforts?

On Sat, 05 Jan 2008 09:42 am Adriaan de Groot wrote:
> On Friday 04 January 2008 20:54, Mikhail Teterin wrote:
> > How is the subject coming along? It seems, some new things like "strigi"
> > are required for kdelibs-4 -- but I don't see a port of that in the tree
> > yet... Would you like it added?
>
> All the things in kdesupport should have ports created. Since they depend
> only on Qt4 (and possibly other things) this should be fairly
> straightforward. Bear in mind that their build systems are CMake-based. I'm
> not sure there's any infrastructure for CMake-based ports yet.
>

I've got a port for strigi here that's about 90% complete, but I've been 
waiting for a couple things, namely:

- The next release of strigi, because it will make OPTIONS handling in the 
port a lot more neater/easier.

- Updated Qt4 in ports. bombs on qt from ports(iirc something to do with moc), 
works fine with svn qt-copy though.

I also made a simple bsd.cmake.mk a few months back. Never tested it out 
though, so ill have look it and make it available when I'm done.

shane.

Gmane