Re: ports expiring soon due to Google Code site removal
El viernes 24 de marzo a las 16:12:00 CET, Mark Linimon escribió: As of 20170324 there are still 175 ports that are marked deprecated and broken due to the Google Code site having gone away. These are due to expire on 20170430. Please consider this a "last call" to find a current mastersite for these ports before then. Thanks. [ . ] databases/powerarchitectjjuan...@gmail.com [ .. ] Hi, for powerarchitect take a look at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218137 Best regards -- José G. Juanino ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: devel/pear update?
Am 23.03.2017 um 16:13 schrieb Andrea Venturoli: On 03/23/17 16:04, Jochen Neumeister wrote: Hi, We still have devel/pear 1.10.1 in the port tree: it is vulnerable, although "pkg audit" does not report this. 1.10.3 has been out for almost a month now. Do you have any plan to upgrade this? Are you encountering any showstopper? I hope to offer it at the weekend. Thank you very much. I'm not in that hurry, anyway. Just feel more confortable, now I know you are working (or willing to work) on it. devel/pear 1.10.3 is now available: https://svnweb.freebsd.org/changeset/ports/436958 Thanks to @miwi for help! Regards Jochen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build)
On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard wrote: > Building /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc. > so.7.full > --- libc.so.7.full --- > building shared library libc.so.7 > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): > R_AARCH64_ABS64 used with TLS symbol udb > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): > R_AARCH64_ABS64 used with TLS symbol uf > /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): > R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x146e): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_initialized > /usr/local/aarch64-freebsd/bin/ld: > cxa_thread_atexit_impl.pico(.debug_info+0x3b): > R_AARCH64_ABS64 used with TLS symbol dtors > /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): > R_AARCH64_ABS64 used with TLS symbol __thread_locale > /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > I also see this on our CI server: https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/ , this job began failing since aarch64-binutils upgraded to 2.28 on pkg.freebsd.org. Should we revert this change for now? Or the fix is being prepared? Best, Li-Wen -- Li-Wen Hsu https://lwhsu.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports expiring soon due to Google Code site removal
Hi! > Hi, for powerarchitect take a look at: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218137 Committed, thanks! -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
[I add some what-it-take-for-an-upgrade information.]
On 2017-Mar-12, at 6:53 PM, Mark Millard wrote:
> Summary: RAM+(peak swap) was about 26 GiBytes.
> Also: about 118 GiByte /usr/obj/. . ./llvm40/ area.
> (2 processors, 2 cores each, all in use;
> WITH_DEBUG= used)
>
> The peak usage times were when the 4 cores were
> each busy running ld at the same time.
>
> [So far as I know FreeBSD does not report peak swap usage
> "since boot". So I do not have a cross check on if I missed
> seeing a higher peak then I report in the details below.]
>
> What all this note spans as part of the build:
>
> # more /var/db/ports/devel_llvm40/options
> # This file is auto-generated by 'make config'.
> # Options for llvm40-4.0.0.r4
> _OPTIONS_READ=llvm40-4.0.0.r4
> _FILE_COMPLETE_OPTIONS_LIST=CLANG DOCS EXTRAS LIT LLD LLDB
> OPTIONS_FILE_SET+=CLANG
> OPTIONS_FILE_SET+=DOCS
> OPTIONS_FILE_SET+=EXTRAS
> OPTIONS_FILE_SET+=LIT
> OPTIONS_FILE_SET+=LLD
> OPTIONS_FILE_SET+=LLDB
>
> The system clang 4.0 was used to do the build. A port
> binutils was used (-B${LOCALBASE}/bin/ in CFLAGS,
> CXXFLAGS, an CPPFLAGS). The kernel was non-debug generally
> but buildworld buildkernel did not have MALLOC_PRODUCTION= .
> The llvm40 build did have MALLOC_PRODUCTION= .
>
> # uname -paKU
> FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r314687M powerpc
> powerpc64 1200023 1200023
>
> Most of what I have access to for FreeBSD does not have a
> big enough configuration to do a WITH_DEBUG= build of llvm40
> on a machine with 4 cores, all in use.
>
> One type of environment that does is an old PowerMac G5
> so-called "Quad Core" that has 16 GiBytes of RAM, 17 GiBytes
> of swap, and a 480 GiByte SSD (but extra over provisioned so
> it appears even smaller for the file system+swap).
>
> Watching with top the peak swap usage that I saw was
> 56% of the 17 GiByte --so call it 10 GiBytes or so.
>
> So something like 16 GiBytes RAM + 10 GiBytes swap
> and so something like 26 GiByte total.
>
> I used portmaster with -DK. Afterwards the /usr/obj/
> sub-area for llvm40 used totaled to a size of:
>
> # du -sg /usr/obj/portswork/usr/ports/devel/llvm40
> 118 /usr/obj/portswork/usr/ports/devel/llvm40
>
> So around 118 GiBytes of disk space.
>
> Showing the major space usage contributions:
>
> # du -sg /usr/obj/portswork/usr/ports/devel/llvm40/work/.build/*
> /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/*
> . . .
> 29/usr/obj/portswork/usr/ports/devel/llvm40/work/.build/bin
> . . .
> 29/usr/obj/portswork/usr/ports/devel/llvm40/work/.build/lib
> . . .
> 12/usr/obj/portswork/usr/ports/devel/llvm40/work/.build/tools
> . . .
> 26
> /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/bin
> . . .
> 24
> /usr/obj/portswork/usr/ports/devel/llvm40/work/stage/usr/local/llvm40/lib
> . . .
>
>
>
> Side notes that are more system specific:
>
> The timestamps on the script output file indicate that
> the build took about 8 hours 24 minutes.
>
> The powerpc64 system used was built with the system clang
> 4.0 compiler and a port-based binutils. This is despite that
> clang 4.0 produces code that has any thrown C++ exceptions
> completely non-functional for powerpc64 (program crashes
> via signals reporting problems).
I upgraded from llvm40 r4 to final. An interesting result was
its creation of a backup package for llvm40-4.0.0.r4:
about 13 cpu-core-hours running pkg create
(Remember: I've been building with WITH_DEBUG= ) Its
single-threaded status stands out via elapsed time
approximately matching.
I'll note that it was somewhat under 6 elapsed hours for
staging to have been populated (-j4 with 4 cores present
helps for this part).
(Of course these elapsed-time figures are rather system
dependent, although the ratio might be more stable.)
Also interesting was:
Installed packages to be REMOVED:
llvm40-4.0.0.r4
Number of packages to be removed: 1
The operation will free 49 GiB.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: I had to revert /usr/local/aarch64-freebsd from 2.28 for its bin/ld to work for -r315870 buildworld (adm64 -> arm64 cross build)
On 2017-Mar-26, at 5:07 AM, Li-Wen Hsu wrote: On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard wrote: > Building /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full > --- libc.so.7.full --- > building shared library libc.so.7 > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x3b): > R_AARCH64_ABS64 used with TLS symbol udb > /usr/local/aarch64-freebsd/bin/ld: getutxent.pico(.debug_info+0x58): > R_AARCH64_ABS64 used with TLS symbol uf > /usr/local/aarch64-freebsd/bin/ld: utxdb.pico(.debug_info+0x5a): > R_AARCH64_ABS64 used with TLS symbol futx_to_utx.ut > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_tls > /usr/local/aarch64-freebsd/bin/ld: jemalloc_tsd.pico(.debug_info+0x146e): > R_AARCH64_ABS64 used with TLS symbol __je_tsd_initialized > /usr/local/aarch64-freebsd/bin/ld: > cxa_thread_atexit_impl.pico(.debug_info+0x3b): R_AARCH64_ABS64 used with TLS > symbol dtors > /usr/local/aarch64-freebsd/bin/ld: xlocale.pico(.debug_info+0x403): > R_AARCH64_ABS64 used with TLS symbol __thread_locale > /usr/local/aarch64-freebsd/bin/ld: setrunelocale.pico(.debug_info+0x3c): > R_AARCH64_ABS64 used with TLS symbol _ThreadRuneLocale > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > I also see this on our CI server: > https://ci.freebsd.org/job/FreeBSD-head-aarch64-build/ , this job began > failing since aarch64-binutils upgraded to 2.28 on pkg.freebsd.org. > > Should we revert this change for now? Or the fix is being prepared? I have no clue about any effort to fix the problem. I noticed this after first doing a self-hosted amd64 update. Once I noticed the amd64 -> arm64 problem (the next thing that I tried), I also reverted for targeting armv6/v7 and for targeting powerpc64 and powerpc without testing 2.28 for them. I had to in order to complete targeting arm64 because of the slave-port status that had me revert devel/binutils itself as well. So I do not even know if TARGET_ARCH=aarch64 is the only problem area. I've no say in if something like this is reverted but I'd guess that unless the time frame for a fix is known to be rather short it would be reverted until there is an expected-fix available. === Mark Millard markmi at dsl-only.net ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
cups-filters 1.13.4 failures
Hi, I recently updated to cups-filters 1.13.4, and it appears that I now cannot print PDF files. The port is built with the default options. The logs indicate: D [27/Mar/2017:17:24:32 +1300] [Job 631] Running command line for pdftops: pdftops -level3 /var/spool/cups/tmp/0410d58dfd707 - D [27/Mar/2017:17:24:32 +1300] [Job 631] Started filter pdftops (PID 16655) D [27/Mar/2017:17:24:32 +1300] [Job 631] Unable to execute pdftops program: No such file or directory D [27/Mar/2017:17:24:32 +1300] [Job 631] Started filter pstops (PID 16656) D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16655 (pdftops) stopped with status 1! D [27/Mar/2017:17:24:32 +1300] [Job 631] The print file is empty. D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16656 (pstops) stopped with status 1! D [27/Mar/2017:17:24:32 +1300] [Job 631] Sent 0 bytes... D [27/Mar/2017:17:24:32 +1300] [Job 631] Waiting for read thread to exit... D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16653 (/usr/local/libexec/cups/filter/pdftops) stopped with status 1. I am not sure why its complaining that pdftops is not there because both the filter and the main program are there: 6:27pm# ls -l /usr/local/libexec/cups/filter/pdftops -rwxr-xr-x 1 root wheel 36672 25 Mar 15:05 /usr/local/libexec/cups/filter/pdftops 6:32pm# ls -l /usr/local/bin/pdftops -rwxr-xr-x 1 root wheel 18744 8 Jan 13:43 /usr/local/bin/pdftops* Is the filter looking for pdftops in the wrong place? 6:36pm# strings /usr/local/libexec/cups/filter/pdftops | grep bin.pdftops /usr/bin/pdftops Cheers. -- Jonathan Chen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: cups-filters 1.13.4 failures
On 27 March 2017 at 18:37, Jonathan Chen wrote: [...] > Is the filter looking for pdftops in the wrong place? > > 6:36pm# strings /usr/local/libexec/cups/filter/pdftops | grep bin.pdftops > /usr/bin/pdftops Interestingly enough, in the config.log after "make configure" [.. config.log ...] configure:19994: checking for pdftops configure:20010: found /usr/local/bin/pdftops configure:20021: result: /usr/bin/pdftops Cheers. -- Jonathan Chen ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: cups-filters 1.13.4 failures
On Mon, 2017-03-27 at 18:37 +1300, Jonathan Chen wrote: > Hi, > > I recently updated to cups-filters 1.13.4, and it appears that I now > cannot print PDF files. The port is built with the default options. > The logs indicate: > > D [27/Mar/2017:17:24:32 +1300] [Job 631] Running command line for > pdftops: pdftops -level3 /var/spool/cups/tmp/0410d58dfd707 - > D [27/Mar/2017:17:24:32 +1300] [Job 631] Started filter pdftops (PID > 16655) > D [27/Mar/2017:17:24:32 +1300] [Job 631] Unable to execute pdftops > program: No such file or directory > D [27/Mar/2017:17:24:32 +1300] [Job 631] Started filter pstops (PID > 16656) > D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16655 (pdftops) stopped > with status 1! > D [27/Mar/2017:17:24:32 +1300] [Job 631] The print file is empty. > D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16656 (pstops) stopped > with status 1! > D [27/Mar/2017:17:24:32 +1300] [Job 631] Sent 0 bytes... > D [27/Mar/2017:17:24:32 +1300] [Job 631] Waiting for read thread to > exit... > D [27/Mar/2017:17:24:32 +1300] [Job 631] PID 16653 > (/usr/local/libexec/cups/filter/pdftops) stopped with status 1. > > I am not sure why its complaining that pdftops is not there because > both the filter and the main program are there: > 6:27pm# ls -l /usr/local/libexec/cups/filter/pdftops > -rwxr-xr-x 1 root wheel 36672 25 Mar 15:05 > /usr/local/libexec/cups/filter/pdftops > 6:32pm# ls -l /usr/local/bin/pdftops > -rwxr-xr-x 1 root wheel 18744 8 Jan 13:43 /usr/local/bin/pdftops* > > Is the filter looking for pdftops in the wrong place? > > 6:36pm# strings /usr/local/libexec/cups/filter/pdftops | grep > bin.pdftops > /usr/bin/pdftops > I have the same problem and traced it to something between pdftopdf and pdftops (pdftopdf exits with no errors). Pdftopdf creates a file in /var/spool/cups/tmp but when pdftops is called the file doesn't exist. No idea why. Changing permissions didn't help. Truss didn't help. To my surprise, swearing didn't help either. > Cheers. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
