Re: Current unassigned ports problem reports
On 11/22/2011 6:18 PM, Greg Larkin wrote: > I have tried various ways to build a query that includes "responsible IS > NULL" You almost certainly want responsible=freebsd-ports-bugs. Unassigned is a relative term. :) http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports&responsible=freebsd-ports-bugs -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Current unassigned ports problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/21/11 6:06 AM, FreeBSD bugmaster wrote: > (Note: an HTML version of this report is available at > http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) > > The following is a listing of current problems submitted by FreeBSD users. > These represent problem reports covering all versions including > experimental development code and obsolete releases. > > > S Tracker Resp. Description > > o ports/162717[PATCH] mail/mew-emacs23: update to 6.4 > o ports/162716difference in dependency lists in INDEX and > /var/db/pk Hi Bugmaster, When I visit the URL above, the list of PRs includes those already assigned, as well as the unassigned ones detailed in the email. Is there a way to display only the unassigned PRs on a web page? I have tried various ways to build a query that includes "responsible IS NULL", but I haven't had any success yet. Either GNATS doesn't support it, or I'm not RTFMing closely enough. Any advice would be appreciated! Thank you, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/cpucycle/ - Follow you, follow me -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7MV98ACgkQ0sRouByUApBh7gCdHjq9wa1cT50aYRd2phkqQZg6 LjUAnjtbdjHutfAEUaFINGCcyWXtYySC =2Oyf -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (
On Mon, 21 Nov 2011 23:19:08 +0100 Olivier Smedts wrote: > 2011/11/21 Conrad J. Sabatier : > > > > I've been using the (undocumented, at least in /etc/make.conf) > > CPUTYPE?=native with no problems for quite some time now. Let gcc > > detect the processor type and generate the appropriate code. > > Eliminates any guesswork in trying to select the correct setting for > > CPUTYPE. > > CPUTYPE=native is not recognized by /usr/share/mk/bsd.cpu.mk (that's > the real purpose of CPUTYPE, it does not only change the -march > compiler setting). > The proper way of doing what you're doing, after numerous tests and > researchs, seems to be : > > CPUTYPE?=core2 (for example, to let /usr/share/mk/bsd.cpu.mk do its > job) CFLAGS=-O2 -pipe -march=native (because you want the compiler to > detect the cpu it's running on and optimize the code for it) > NO_CPU_CFLAGS=yes (because you wanted to force the -march, you don't > want another one to be added on the command line) > COPTFLAGS=-O2 -pipe -march=native (same thing for kernel CFLAGS) > NO_CPU_COPTFLAGS=yes > > This way, bsd.cpu.mk can set useful MACHINE_CPU for your CPUTYPE, but > you let the compiler determine which processor to optimize the code > for with the -march. I add NO_CPU_CFLAGS and NO_CPU_COPTFLAGS to be > able to specify -march=native in the CFLAGS, cause it's different from > CPUTYPE. > > Now why do I force -march=core2 and don't use -march=native ? Because > our base gcc does not use the correct flags on my Core2 CPU if using > -march=native : > % /usr/bin/gcc -### -march=native md5.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "md5.c" "-march=core2" > "-mtune=generic" "-quiet" "-dumpbase" "md5.c" "-auxbase" "md5" "-o" > "/var/tmp//ccYJKvGN.s" > "/usr/bin/as" "-Qy" "-o" "/var/tmp//ccR6Lu5X.o" > "/var/tmp//ccYJKvGN.s" "/usr/bin/ld" "--eh-frame-hdr" > "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" > "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" > "/var/tmp//ccR6Lu5X.o" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" > > See the "-mtune=generic" ? Crap ! You don't want that (manpage : > Produce code optimized for the most common IA32/AMD64/EM64T > processors. If you know the CPU on which your code will run, then you > should use the corresponding -mtune option instead of -mtune=generic. > But, if you do not know exactly what CPU users of your application > will have, then you should use this option.) > > % /usr/bin/gcc -### -march=core2 md5.c > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070831 patched [FreeBSD] > "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "md5.c" "-quiet" > "-dumpbase" "md5.c" "-march=core2" "-auxbase" "md5" "-o" > "/var/tmp//ccL8Bvk4.s" > "/usr/bin/as" "-Qy" "-o" "/var/tmp//ccLrppPo.o" > "/var/tmp//ccL8Bvk4.s" "/usr/bin/ld" "--eh-frame-hdr" > "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" > "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" > "/var/tmp//ccLrppPo.o" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" > "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" > > No -mtune=generic. According to the gcc manpage for the x86 arch, > -march=core2 is sufficient to have proper values for -mtune, -mcpu... > (Generate instructions for the machine type cpu-type. The choices for > cpu-type are the same as for -mtune. Moreover, specifying > -march=cpu-type implies -mtune=cpu-type.) Strange, it seems to "just work" on my machine (note the -march and -mtune settings): $ /usr/bin/gcc -### -march=native hello.c Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070831 patched [FreeBSD] "/usr/libexec/cc1" "-quiet" "-D_LONGLONG" "hello.c" "-march=k8" "-mtune=k8" "-quiet" "-dumpbase" "hello.c" "-auxbase" "hello" "-o" "/tmp/ccAXYamu.s" "/usr/bin/as" "-Qy" "-o" "/tmp/ccIpMJgw.o" "/tmp/ccAXYamu.s" "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "-L/usr/lib" "/tmp/ccIpMJgw.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o" I've never seen any problems with this in src or ports makes, either. I do seem to recall having a look at bsd.cpu.mk a long, long time ago, and it appeared to me that it simply passed any unrecognized CPUTYPE through unchanged, which my experience does seem to bear out. -- Conrad J. Sabatier conr...@cox.net ___ freebs
Re: More nitpicks from the department of redundancy department...
On 22/11/2011 17:29, Jason Helfman wrote:
> On Tue, Nov 22, 2011 at 10:49:24AM -0500, Wesley Shields thus spake:
>> On Tue, Nov 22, 2011 at 03:44:47PM +, Matthew Seaman wrote:
>>> On 22/11/2011 13:29, Wesley Shields wrote:
>>> > On Mon, Nov 21, 2011 at 12:42:59AM -0500, Eitan Adler wrote:
>>> >> On Sun, Nov 20, 2011 at 10:18 AM, Eitan Adler
>>> wrote:
>>> >>> On Sun, Nov 20, 2011 at 4:45 AM, Matthew Seaman
>>> >>> wrote:
>>>
>>> PORT_DBDIR?= /var/db/ports is the default setting in
>>> bsd.ports.mk -- the
>>> following ports redefine it to exactly the same value:
>>> [ snip ]
>>> >>>
>>> >>> Thanks for the report - I'll handle these.
>>> >>
>>> >> Sorry for the empty promise. Something came up and I won't have the
>>> >> time to look at these :( - maybe someone else can take them up
>>> >
>>> > Hi Matthew!
>>> >
>>> > If you could please file these in a PR and CC me I will try and work
>>> > through all of these.
>>>
>>> Done: http://www.freebsd.org/cgi/query-pr.cgi?pr=162754
>>
>> Thank you! I will try and clean all this up, but as I'm sure you're
>> aware we are coming up on a holiday in the states so my time is limited
>> for the next few days. I will look at this as time permits though!
>>
>> -- WXS
>
> I did have a brief look at some of these and it was a great catch. One item
> I did find interesting is a number of these define LATEST_LINK, but it just
> matches ${PORTNAME}, so the LATEST_LINK can more than likely be dropped
> -- on
> a case-by-case basis, of course.
Yes -- in fact, all the ports where PORT_DBDIR was redefined also set
OPTIONSFILE to what would be the default value in any case. About half
the ports mentioned were essentially clones of one of the
phpX-extensions ports or borrowed heavily from them.
I did a bit of checking to see if there were any other common cases with
OPTIONSFILE but couldn't find anything obvious. Haven't searched for
people setting LATEST_LINK to what would be the default in any case.
Hmmm... just by inspection, there's a lot of ports that essentially set
LATEST_LINK to ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX} -- and that
is actually the default value already. I'll stick looking into that on
the queue.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (
On Mon, Nov 21, 2011 at 10:27 AM, Olivier Smedts wrote:
> 2011/11/21 Conrad J. Sabatier :
>> On Mon, 21 Nov 2011 07:42:43 -0600
>> eculp wrote:
>>>
>>> I have tried building both from the different ports and even more
>>> using portmaster and all stop ate similar locations in kdelabs4.
>>> Maybe there is something that I should or could build first.
>>>
>>> Thanks,
>>>
>>> ed
>>>
>>> errors follow:
>>>
>>> kdelibs stops here:
>>>
>>> Generating kurlnavigator.moc
>>> Generating moc_kdiroperatordetailview_p.cpp
>>> [ 1%] Built target kfile_automoc
>>> Scanning dependencies of target kdeinit_kconf_update_automoc
>>> Scanning dependencies of target docbookl10nhelper_automoc
>>> [ 1%] Built target kdeinit_kconf_update_automoc
>>> [ 1%] Built target docbookl10nhelper_automoc
>>> Scanning dependencies of target genshortcutents_automoc
>>> Scanning dependencies of target kio_ghelp_automoc
>>> [ 1%] Built target genshortcutents_automoc
>>> [ 1%] Built target kio_ghelp_automoc
>>> Scanning dependencies of target kio_help_automoc
>>> Scanning dependencies of target meinproc4_automoc
>>> [ 1%] Built target kio_help_automoc
>>> [ 1%] Built target meinproc4_automoc
>>> Scanning dependencies of target meinproc4_simple_automoc
>>> Scanning dependencies of target kio_file_automoc
>>> [ 1%] Built target meinproc4_simple_automoc
>
> I've got this behavior on the 2 desktop machines I use.
>
>>> kdepimlibs4 stops here:
>>>
>>> Scanning dependencies of target kimg_pcx_automoc
>>> Scanning dependencies of target kimg_pic_automoc
>>> [ 1%] Built target kimg_pcx_automoc
>>> [ 1%] Built target kimg_pic_automoc
>>> Scanning dependencies of target kimg_psd_automoc
>>> Scanning dependencies of target kimg_ras_automoc
>>> [ 1%] Built target kimg_psd_automoc
>>> [ 1%] Built target kimg_ras_automoc
>>> Scanning dependencies of target kimg_rgb_automoc
>>> Scanning dependencies of target kimg_tga_automoc
>>> [ 1%] Built target kimg_rgb_automoc
>>> [ 1%] Built target kimg_tga_automoc
>>> Scanning dependencies of target kimg_xcf_automoc
>>> Scanning dependencies of target kimg_xview_automoc
>>> [ 1%] Built target kimg_xview_automoc
>>> [ 1%] Built target kimg_xcf_automoc
>>> Scanning dependencies of target kdnssd_automoc
>>> Scanning dependencies of target krosscore_automoc
>>> Generating interpreter.moc
>>> Generating script.moc
>>> Generating action.moc
>>> Generating actioncollection.moc
>>> Generating manager.moc
>>> [ 1%] Built target krosscore_automoc
>>
>> So where are the errors? There are none in the output you posted.
>
> I think there's no error (if it's the same problem as mine).
True. There is no error anywhere.
>
> For me, the build process seems to stop/freeze randomly, most often
> after "Built target XXX". It affects only KDE ports, no other
> qt4-qmake or cmake consumer. No CPU usage. No disk usage. No excessive
> or changing memory usage... I didn't report it earlier because I don't
> know how to debug this, and it did not seem to affect other users
> (until now).
>
> Here is the "workaround" I painfully used on my 2 desktop machines :
>
> # cd /usr/ports/x11/kde4
> # make
> wait for a freeze...
> ^C
> # make
> wait for a freeze...
> ^C
> # make
I'm doing this and it is compiling. It never dawned on me to try
that. I have the "bad habit" of erasing everything re-suping and
trying again. I even blew away all my ports and started with a
totally new one. I then blew away everything built from kde4. Boy am
I dumb.
> ...
> I maybe had to restart the build one or two hundred times to have a
> fully installed KDE4.
>
> I've got this behavior since KDE 4.7.X (4.7.2 and 4.7.3), I had no
> problems building KDE 4.6.X.
>
> I even tried deleting all ports, cleaning /usr/local, tried again. No
> change. Tried compiling all ports with gcc instead of clang, no
> change. Forced make jobs UNSAFE, no change.
>
> I use FreeBSD 9.0 amd64, system built with clang (are you ?).
Yep. I don't understand why but. It is well on its way to building.
Thanks a bunch. You are a "life saver". I started admining unix7
back in the early eighties with dumb terminals but now kde has me
happily spoiled.
ed
>
> %cat /etc/make.conf
> SVN_UPDATE=yes
> SVN=/usr/local/bin/svn
> CPUTYPE?=core2
> KERNCONF=CORE
> CFLAGS=-O2 -pipe -march=core2 -fomit-frame-pointer
> NO_CPU_CFLAGS=yes
> COPTFLAGS=-O2 -pipe -march=corei7 -fomit-frame-pointer
> NO_CPU_COPTFLAGS=yes
> BOOTWAIT=0
> WITHOUT_PROFILE=yes
>
> .if !${.CURDIR:M/usr/ports/deskutils/kdepimlibs4*} &&
> !${.CURDIR:M/usr/ports/devel/icu*} &&
> !${.CURDIR:M/usr/ports/editors/kate*} &&
> !${.CURDIR:M/usr/ports/games/kdegames4*} &&
> !${.CURDIR:M/usr/ports/graphics/libwpg*} &&
> !${.CURDIR:M/usr/ports/graphics/netpbm*} &&
> !${.CURDIR:M/usr/ports/graphics/vigra*} &&
> !${.CURDIR:M/usr/ports/multimedia/kdemultimedia4*} &&
> !${.CURDIR:M/usr/ports/net/hupnp*} &&
> !${.CURDIR:M/usr/ports/net/kdenetwork4*} &&
> !${.CURDIR:M/usr/ports/textproc/libwpd*} &&
> !${.CURDIR:M/usr/ports/textpr
Re: ports/textproc/stardict3
On Fri, 18 Nov 2011 13:54:04 +0100, Matthias Apitz wrote: > Hello, > > The port (ports tree from CVS) ports/textproc/stardict3 > > ports/textproc/stardict3 > PORTVERSION=3.0.3 > MAINTAINER= m...@freebsd.org > > installs fine on 10-CURRENT, but the application just crahes or runs > into a CPU loop; if it runs into CPU loop there is a core file of 'troff', > i.e. it seems that it started for some man page reason the troff(1) and > after this it loops; Stardict has plugin for displaying man pages. > I went back for this port only to > > # cvs update -r RELEASE_8_2_0 > > which brings> > PORTVERSION=3.0.1 > PORTREVISION= 5 > and this works just fine with all my dictionaries. > > I could go back to 3.0.3 and provide more details of the crash, but I > can't debug or solve this on my own. Or should I file a bug report? backtrace would be nice to have. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: More nitpicks from the department of redundancy department...
On Tue, Nov 22, 2011 at 10:49:24AM -0500, Wesley Shields thus spake:
On Tue, Nov 22, 2011 at 03:44:47PM +, Matthew Seaman wrote:
On 22/11/2011 13:29, Wesley Shields wrote:
> On Mon, Nov 21, 2011 at 12:42:59AM -0500, Eitan Adler wrote:
>> On Sun, Nov 20, 2011 at 10:18 AM, Eitan Adler wrote:
>>> On Sun, Nov 20, 2011 at 4:45 AM, Matthew Seaman
>>> wrote:
PORT_DBDIR?= /var/db/ports is the default setting in bsd.ports.mk -- the
following ports redefine it to exactly the same value:
[ snip ]
>>>
>>> Thanks for the report - I'll handle these.
>>
>> Sorry for the empty promise. Something came up and I won't have the
>> time to look at these :( - maybe someone else can take them up
>
> Hi Matthew!
>
> If you could please file these in a PR and CC me I will try and work
> through all of these.
Done: http://www.freebsd.org/cgi/query-pr.cgi?pr=162754
Thank you! I will try and clean all this up, but as I'm sure you're
aware we are coming up on a holiday in the states so my time is limited
for the next few days. I will look at this as time permits though!
-- WXS
I did have a brief look at some of these and it was a great catch. One item
I did find interesting is a number of these define LATEST_LINK, but it just
matches ${PORTNAME}, so the LATEST_LINK can more than likely be dropped -- on
a case-by-case basis, of course.
-jgh
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: More nitpicks from the department of redundancy department...
On Tue, Nov 22, 2011 at 03:44:47PM +, Matthew Seaman wrote: > On 22/11/2011 13:29, Wesley Shields wrote: > > On Mon, Nov 21, 2011 at 12:42:59AM -0500, Eitan Adler wrote: > >> On Sun, Nov 20, 2011 at 10:18 AM, Eitan Adler wrote: > >>> On Sun, Nov 20, 2011 at 4:45 AM, Matthew Seaman > >>> wrote: > > PORT_DBDIR?= /var/db/ports is the default setting in bsd.ports.mk -- the > following ports redefine it to exactly the same value: > [ snip ] > >>> > >>> Thanks for the report - I'll handle these. > >> > >> Sorry for the empty promise. Something came up and I won't have the > >> time to look at these :( - maybe someone else can take them up > > > > Hi Matthew! > > > > If you could please file these in a PR and CC me I will try and work > > through all of these. > > Done: http://www.freebsd.org/cgi/query-pr.cgi?pr=162754 Thank you! I will try and clean all this up, but as I'm sure you're aware we are coming up on a holiday in the states so my time is limited for the next few days. I will look at this as time permits though! -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: More nitpicks from the department of redundancy department...
On 22/11/2011 13:29, Wesley Shields wrote: > On Mon, Nov 21, 2011 at 12:42:59AM -0500, Eitan Adler wrote: >> On Sun, Nov 20, 2011 at 10:18 AM, Eitan Adler wrote: >>> On Sun, Nov 20, 2011 at 4:45 AM, Matthew Seaman >>> wrote: PORT_DBDIR?= /var/db/ports is the default setting in bsd.ports.mk -- the following ports redefine it to exactly the same value: [ snip ] >>> >>> Thanks for the report - I'll handle these. >> >> Sorry for the empty promise. Something came up and I won't have the >> time to look at these :( - maybe someone else can take them up > > Hi Matthew! > > If you could please file these in a PR and CC me I will try and work > through all of these. Done: http://www.freebsd.org/cgi/query-pr.cgi?pr=162754 Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Slave ports
On Mon, 21 Nov 2011 22:33:14 -0500, Sahil Tandon wrote:
> On Mon, 2011-11-21 at 17:10:26 -0800, Doug Barton wrote:
>
> > On 11/21/2011 15:17, Matthew Seaman wrote:
> > > Lets suppose you want the gtk2 version of lazarus, and lets further
> > > suppose that the two slave ports discussed previously have been created.
> > >
> > > You would write dependency lines in the port Makefile eg. like this:
> > >
> > > BUILD_DEPENDS = lazarus:${PORTSDIR}/editors/lazarus-gtk2
> >
> > In spite of its not being documented in bsd.port.mk (hello? portmgr?
> > anyone?) there is an alternate way to describe the dependency that would
> > fix this problem:
> >
> > BUILD_DEPENDS= lazarus-gtk2>=1.23:${PORTSDIR}/editors/lazarus-gtk2
>
> FWIW, this is at least documented in the Porter's Handbook. :)
>
> http://www.freebsd.org/doc/en/books/porters-handbook/book.html#AEN2373
Sorry, I should have taken a better look at the Handbook before
asking...
In any case, thanks all for your help! I think this solves all my
problems. At least for now ;)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: More nitpicks from the department of redundancy department...
On Mon, Nov 21, 2011 at 12:42:59AM -0500, Eitan Adler wrote: > On Sun, Nov 20, 2011 at 10:18 AM, Eitan Adler wrote: > > On Sun, Nov 20, 2011 at 4:45 AM, Matthew Seaman > > wrote: > >> > >> PORT_DBDIR?= /var/db/ports is the default setting in bsd.ports.mk -- the > >> following ports redefine it to exactly the same value: > >> [ snip ] > > > > Thanks for the report - I'll handle these. > > Sorry for the empty promise. Something came up and I won't have the > time to look at these :( - maybe someone else can take them up Hi Matthew! If you could please file these in a PR and CC me I will try and work through all of these. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Can't compile kde4 and kdelibs4 with an uptodate amd64 Releng machine. (
On Monday 21 Nov 2011 16:09:45 Conrad J. Sabatier wrote: > On Mon, 21 Nov 2011 07:42:43 -0600 > > eculp wrote: > > I have tried building both from the different ports and even more > > using portmaster and all stop ate similar locations in kdelabs4. > > Maybe there is something that I should or could build first. > > > > Thanks, > > > > ed > > > > errors follow: > > > > kdelibs stops here: > > > > Generating kurlnavigator.moc > > Generating moc_kdiroperatordetailview_p.cpp > > [ 1%] Built target kfile_automoc > > Scanning dependencies of target kdeinit_kconf_update_automoc > > Scanning dependencies of target docbookl10nhelper_automoc > > [ 1%] Built target kdeinit_kconf_update_automoc > > [ 1%] Built target docbookl10nhelper_automoc > > Scanning dependencies of target genshortcutents_automoc > > Scanning dependencies of target kio_ghelp_automoc > > [ 1%] Built target genshortcutents_automoc > > [ 1%] Built target kio_ghelp_automoc > > Scanning dependencies of target kio_help_automoc > > Scanning dependencies of target meinproc4_automoc > > [ 1%] Built target kio_help_automoc > > [ 1%] Built target meinproc4_automoc > > Scanning dependencies of target meinproc4_simple_automoc > > Scanning dependencies of target kio_file_automoc > > [ 1%] Built target meinproc4_simple_automoc > > > > kdepimlibs4 stops here: > > > > Scanning dependencies of target kimg_pcx_automoc > > Scanning dependencies of target kimg_pic_automoc > > [ 1%] Built target kimg_pcx_automoc > > [ 1%] Built target kimg_pic_automoc > > Scanning dependencies of target kimg_psd_automoc > > Scanning dependencies of target kimg_ras_automoc > > [ 1%] Built target kimg_psd_automoc > > [ 1%] Built target kimg_ras_automoc > > Scanning dependencies of target kimg_rgb_automoc > > Scanning dependencies of target kimg_tga_automoc > > [ 1%] Built target kimg_rgb_automoc > > [ 1%] Built target kimg_tga_automoc > > Scanning dependencies of target kimg_xcf_automoc > > Scanning dependencies of target kimg_xview_automoc > > [ 1%] Built target kimg_xview_automoc > > [ 1%] Built target kimg_xcf_automoc > > Scanning dependencies of target kdnssd_automoc > > Scanning dependencies of target krosscore_automoc > > Generating interpreter.moc > > Generating script.moc > > Generating action.moc > > Generating actioncollection.moc > > Generating manager.moc > > [ 1%] Built target krosscore_automoc > > So where are the errors? There are none in the output you posted. Tinderbox logs of the same problem: https://chronos.org.uk/tb/errors/8-amd64-Desktop/kdelibs-4.7.3.log By selectively changing MAKE_JOBS_SAFE to MAKE_JOBS_UNSAFE in the Makefiles I can compile most of KDE-SC barring kdeplasma-addons. This is from a pristine ports tree updated yesterday with no modifications. Fails consistently on kdelibs4, but in different places each time. @eculp: Is your machine SMP? This tinderbox is a quad core MP box. -- Matt Dawson MTD15-RIPE m...@chronos.org.uk ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
