clang; gmake
Correction on my last post. Removing "gmake" alone from many Makefiles improves many builds, by reducing gmake dependencies and options. This is since FreeBSD has its native clang. GNU and GTK tools didn't necessarily have to be removed for compile improvements to be made. Also, it would be better if ports that use hardware to have an option of only DEVD or HAL. I propose to take this into account in port-trees. It will in fact make port maintainer's jobs' easier. Thank you. ___ 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"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ chinese/joe | 3.7 | 4.0 +-+ devel/p5-Benchmark-Timer| 0.7102 | 0.7103 +-+ editors/joe | 3.7 | 4.0 +-+ misc/mc | 4.8.13 | 4.8.14 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ 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"
pkg upgrade hang on 10.1p8/amd64 with graphviz.
Hi! I have a strange situation: Proceed with this action? [y/N]: y [1/5] Installing graphviz-2.38.0_6... [1/5] Extracting graphviz-2.38.0_6: 100% load: 0.10 cmd: dot 46012 [urdlck] 1.56r 0.00u 0.00s 12% 11188k and there it hangs. Any ideas on how to fix this ? -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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: pkg upgrade hang on 10.1p8/amd64 with graphviz.
Hi! > I have a strange situation: > > Proceed with this action? [y/N]: y > [1/5] Installing graphviz-2.38.0_6... > [1/5] Extracting graphviz-2.38.0_6: 100% > load: 0.10 cmd: dot 46012 [urdlck] 1.56r 0.00u 0.00s 12% 11188k > > and there it hangs. Any ideas on how to fix this ? I found a workaround: cd /usr/local/lib/graphviz/ # fstat config6 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root dot461823 /298326 -rw-r--r-- 0 w config6 # kill -1 46182 There's something strange with graphviz. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ 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"
Want Your Opinion
The Opinion Room Visit http://theopinionroom.com/Home/Welcome/ to view this in your browser. Share Your Opinions! The Opinion Room is currently looking for individuals willing to participate in paid market research studies from the comfort of their home using any computer, tablet or mobile device. Participants will receive cash and other rewards for every market research study they successfully complete. The majority of our studies take less than 15 minutes to complete! Your responses will always remain confidential and you will never be required to make a purchase in order to participate. In fact, participation in any of our paid market research studies is absolutely voluntary! Companies want to hear from you and so do we! Your opinion will help companies make important decisions about their products and services. Registration is FREE and takes only a few minutes. Join The Opinion Room today! https://theopinionroom.com/Home/JoinUs/ You are receiving this email from The Opinion Room, Inc. because you have registered with one of our partner or affiliate websites. To ensure our emails are always delivered to your Inbox and not to your Junk / Spam folder, please add tay...@theopinionroom.com to your Safe Sender contacts list or address book. Not interested? Unsubscribe Instantly. The Opinion Room's Privacy Policy: https://theopinionroom.com/Home/PrivacyPolicy ___ 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: Problems with openssl 1.0.2 update
On 03/23/15 11:33, Gerhard Schmidt wrote: > Hi, > > we experiencing a problem after upgrading the openssl port to openssl > 1.0.2. > > /usr/bin/vi started to crash after some seconds with segfault. > /rescue/vi works just fine. Deleting the openssl 1.0.2 package > everything works just fine again. Installing the old openssl 1.0.1_18 > package it still works just fine. > > it seams that besides vi the bash also has this problem. Anybody > experiencing the same or is this something specific to my system. > > I'm running FreeBSD 10.1 updated tonight. I am seeing runtime problems with asterisk13 (which I maintain), caused by the OpenSSL update fallout. In this case, after some analysis, I concluded the problem is the libsrtp port requiring OpenSSL from ports(for a reason), causing asterisk to link to that too, which would be correct. Asterisk also uses the security/trousers port, which links to system OpenSSL. This ensues a conflict which now results in asterisk segfaulting and stopping to work. I'm investigating what can be done about this. As a local solution I can force the trousers port to link against OpenSSL from ports, but this will not fix the general problem. As a port maintaner I ony see modifying the trousers port to depend on ports OpenSSL as a solution, is this acceptable? -- Guido Falsi ___ 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"
Adding options framework variables that depend on variables coming after bsd.port.pre.mk
I'm wanting to add an options framework LIB_DEPENDS that depends on variables that normally come after bsd.port.pre.mk. In this case, I am trying to add a UTEMPTER_LIB_DEPENDS on sysutils/libutempter, but I want to check OPSYS and OSVERSION beforehand, since base FreeBSD 9.x contains utempter while any earlier FreeBSDs as well as non-FreeBSD OSes don't contain it and need the port. I cannot place the UTEMPTER_LIB_DEPENDS line after bsd.port.pre.mk because the options framework doesn't see it then, but I also cannot wrap it around an if conditional using OPSYS and OSVERSION before bsd.port.pre.mk because those variables aren't set yet. I've been told that there is a workaround, but I was not told what the workaround was. Does anyone know how this can be acomplished? ___ 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: Problems with openssl 1.0.2 update
On 03/23/15 13:40, Guido Falsi wrote: > On 03/23/15 11:33, Gerhard Schmidt wrote: >> Hi, >> >> we experiencing a problem after upgrading the openssl port to openssl >> 1.0.2. >> >> /usr/bin/vi started to crash after some seconds with segfault. >> /rescue/vi works just fine. Deleting the openssl 1.0.2 package >> everything works just fine again. Installing the old openssl 1.0.1_18 >> package it still works just fine. >> >> it seams that besides vi the bash also has this problem. Anybody >> experiencing the same or is this something specific to my system. >> >> I'm running FreeBSD 10.1 updated tonight. > > I am seeing runtime problems with asterisk13 (which I maintain), caused > by the OpenSSL update fallout. > > In this case, after some analysis, I concluded the problem is the > libsrtp port requiring OpenSSL from ports(for a reason), causing > asterisk to link to that too, which would be correct. > > Asterisk also uses the security/trousers port, which links to system > OpenSSL. This ensues a conflict which now results in asterisk > segfaulting and stopping to work. > > I'm investigating what can be done about this. As a local solution I can > force the trousers port to link against OpenSSL from ports, but this > will not fix the general problem. As a port maintaner I ony see > modifying the trousers port to depend on ports OpenSSL as a solution, is > this acceptable? > Quick followup to keep anyone interested informed(and for ML archives just in case). The only "fix" I could commit to fix the binary package was removing the SRTP option from the defaults, avoiding to pull in the libsrtp port which itself pulled in OpenSSL from ports, causing the library mix. I'm not proud of such a solution, but was unable to do anything better right away. If someone has a better solution, please send patches. So for now anyone wanting to use SRTP with asterisk will have to build his own packages. :( -- Guido Falsi ___ 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: [HEADSUP] WIP on fonts
On 3/22/2015 5:28 AM, Ben Woods wrote:
> My poudriere is acting funny now, and I'm not sure if it's related. It
> keeps deleting xorg-fonts-truetype because there is a new dependency
> (x11-fonts/dejavu), and then having to rebuild a whole suit of packages as
> a result.
>
> The interesting thing is that dejavu was a dependency the entire time. It
> will successfully peform the bulk build and update the package set. If I
> then re-run the bulk build, it does the same thing every time.
>
> My make.conf file (which hasn't changed in some time) contains:
> OPTIONS_SET=VAAPI VDPAU X265 ASS FAAC LAME
> MDNSRESPONDER RRDTOOL STATGRAB DEJAVU
>
>
It will do this if a port has a dependency listed that it does not
actually use. So the xorg-fonts-truetype is incorrectly depending on
x11-fonts/dejavu.
> The strange output from poudriere:
>
> [00:00:22] >> Sanity checking the repository
> [00:00:22] >> Checking packages for incremental rebuild needed
> [00:00:42] >> Deleting xorg-fonts-truetype-7.7_1.txz: new dependency:
> x11-fonts/dejavu
> [00:00:45] >> Deleting pango-1.36.8.txz: missing dependency:
> xorg-fonts-truetype-7.7_1
> [00:00:45] >> Deleting plexhometheater-1.2.2_7.txz: missing dependency:
> pango-1.36.8
> [00:00:45] >> Deleting policykit-gnome-0.9.2_7.txz: missing dependency:
> pango-1.36.8
> [00:00:45] >> Deleting rrdtool-1.4.8_6.txz: missing dependency:
> pango-1.36.8
>
>
> Any ideas?
> -Ben
>
> On Sunday, March 22, 2015, Baptiste Daroussin wrote:
>
>> On Fri, Mar 20, 2015 at 04:37:13PM +0100, Baptiste Daroussin wrote:
>>> Hi all,
>>>
>>> Some of you may have notice some work on the font area.
>>>
>>> The goal of this work is to prevent every single font package to act
>> differently
>>> and most of the time not correctly.
>>>
>>> The change will be done in multiple steps:
>>> 1/ Convert every ports to USES=fonts
>>> 2/ Remove @fc and @fontsdir keywords to only keep @fcfontsdir
>>> 3/ Move all fonts from ${LOCALBASE}/lib/X11/fonts to
>> ${LOCALBASE}/share/fonts in
>>> order to make the fonts following XDG as well as making them working for
>> non-x11
>>> world (wayland for example)
>>>
>>> Best regards,
>>> Bapt
>>
>>
>> Done in r381876 please report me all possible issue, I have done quite a
>> lot of
>> testing but I cannot test everything.
>>
>> Best regards,
>> Bapt
>>
>
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: [HEADSUP] WIP on fonts
On 3/23/2015 11:39 AM, Bryan Drewery wrote:
> On 3/22/2015 5:28 AM, Ben Woods wrote:
>> My poudriere is acting funny now, and I'm not sure if it's related. It
>> keeps deleting xorg-fonts-truetype because there is a new dependency
>> (x11-fonts/dejavu), and then having to rebuild a whole suit of packages as
>> a result.
>>
>> The interesting thing is that dejavu was a dependency the entire time. It
>> will successfully peform the bulk build and update the package set. If I
>> then re-run the bulk build, it does the same thing every time.
>>
>> My make.conf file (which hasn't changed in some time) contains:
>> OPTIONS_SET=VAAPI VDPAU X265 ASS FAAC LAME
>> MDNSRESPONDER RRDTOOL STATGRAB DEJAVU
>>
>>
>
> It will do this if a port has a dependency listed that it does not
> actually use. So the xorg-fonts-truetype is incorrectly depending on
> x11-fonts/dejavu.
xorg-fonts-trutype has:
+
${FONTDIR}/dejavu/DejaVuSans.ttf:${PORTSDIR}/x11-fonts/dejavu
~/svn/ports/x11-fonts/xorg-fonts-truetype # make -V FONTDIR
/usr/local/share/fonts
The dejavu port has:
~/svn/ports/x11-fonts/dejavu # grep DejaVuSans.ttf pkg-plist
%%FONTSDIR%%/DejaVuSans.ttf
~/svn/ports/x11-fonts/dejavu # make -V '${PLIST_SUB:MFONTSDIR*}'
FONTSDIR="/usr/local/share/fonts/dejavu"
So somehow the package is lacking this file, or poudriere is wrong here.
I'm double checking with some builds now.
>
>> The strange output from poudriere:
>>
>> [00:00:22] >> Sanity checking the repository
>> [00:00:22] >> Checking packages for incremental rebuild needed
>> [00:00:42] >> Deleting xorg-fonts-truetype-7.7_1.txz: new dependency:
>> x11-fonts/dejavu
>> [00:00:45] >> Deleting pango-1.36.8.txz: missing dependency:
>> xorg-fonts-truetype-7.7_1
>> [00:00:45] >> Deleting plexhometheater-1.2.2_7.txz: missing dependency:
>> pango-1.36.8
>> [00:00:45] >> Deleting policykit-gnome-0.9.2_7.txz: missing dependency:
>> pango-1.36.8
>> [00:00:45] >> Deleting rrdtool-1.4.8_6.txz: missing dependency:
>> pango-1.36.8
>>
>>
>> Any ideas?
>> -Ben
>>
>> On Sunday, March 22, 2015, Baptiste Daroussin wrote:
>>
>>> On Fri, Mar 20, 2015 at 04:37:13PM +0100, Baptiste Daroussin wrote:
Hi all,
Some of you may have notice some work on the font area.
The goal of this work is to prevent every single font package to act
>>> differently
and most of the time not correctly.
The change will be done in multiple steps:
1/ Convert every ports to USES=fonts
2/ Remove @fc and @fontsdir keywords to only keep @fcfontsdir
3/ Move all fonts from ${LOCALBASE}/lib/X11/fonts to
>>> ${LOCALBASE}/share/fonts in
order to make the fonts following XDG as well as making them working for
>>> non-x11
world (wayland for example)
Best regards,
Bapt
>>>
>>>
>>> Done in r381876 please report me all possible issue, I have done quite a
>>> lot of
>>> testing but I cannot test everything.
>>>
>>> Best regards,
>>> Bapt
>>>
>>
>>
>
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: CROSS_TOOLCHAIN=powerpc64-gcc mishandles "Substitution Failure Is Not An Error" when compiling clang and stops the build
https://llvm.org/bugs/show_bug.cgi?id=22771 from Dimitry Andric's submittal of
the problem indicates that the libc++ code is not a "Substitution Failure Is
Not An Error" context and so is wrong. (C is certainly simpler than C++ for
identifying what applies where.)
They have an improvement but Richard Smith's tiny test case shows it is not yet
correct:
> Here's a testcase that fails with Clang:
>
> #define __has_feature(x) 0
> #include
> class X { X(const X&); };
> bool b = std::is_convertible::value;
>
> (Using a public deleted copy constructor fails similarly.)
in that both the original code and the improvement fail to compile the above
but instead treat it as an error. (Dimitry Andric tested the improvement and
https://llvm.org/bugs/show_bug.cgi?id=22771 shows the error that he got.)
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-20, at 11:27 PM, Mark Millard wrote:
Basic context:
> # dmesg | head
> ...
> FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015
>root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc
> gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)
> ...
> # freebsd-version -ku; uname -apKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18
> 20:11:15 PDT 2015
> root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64
> 1100062 1100062
> make -j 8 CROSS_TOOLCHAIN=powerpc64-gcc \
> WITHOUT_CLANG_BOOTSTRAP= WITH_CLANG= WITH_CLANG_IS_CC= \
> WITH_LLDB= \
> WITH_GCC_BOOTSTRAP= WITH_GCC= WITHOUT_GNUCXX= \
> WITHOUT_BOOT= WITHOUT_LIB32= \
> buildworld buildkernel \
> KERNCONF=GENERIC64vtsc-NODEBUG \
> TARGET=powerpc TARGET_ARCH=powerpc64
For the context set by:
> # more /etc/src.conf
> CC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
> CXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
> CPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
> CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/
> X_COMPILER_TYPE=gcc
> WITH_LIBCPLUSPLUS=
> #
> # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=powerpc64-gcc use...
> # spans being-built and (failing finding those directories) live and so for
> # -DNO_CLEAN after being-built ones are in place depends on self-hodsting
> # where the two are sufficient compatibile.
> #
> # I've used .../. paths so I can tell use of these from other sources of
> paths.
> #
> # Actually only appropriate for for _includes _libraries _depend everything
> build32 :
> CXXFLAGS+=-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=gnu++11
> -L/usr/obj/usr/srcC/lib/libc++/.
> #
> # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools
> _cleanobj _obj _build-tools _cross-tools :
> CXXFLAGS+=-I/usr/include/c++/v1/. -std=gnu++11 -L/usr/lib/.
> #
> # But for self-hosting in a cross tools like manor sometimes having both can
> work.
> #
> NO_WERROR=
The problem:
(Somewhat reformatted text...)
> In file included from /usr/include/c++/v1/./algorithm:625:0,
> from
> /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringRef.h:13,
> from
> /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:17,
> from
> /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/SpecialCaseList.h:51,
> from
> /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SpecialCaseList.cpp:17:
> /usr/include/c++/v1/./type_traits:
>
> In instantiation of 'struct std::__1::__is_convertible llvm::StringMap&,
> llvm::StringMap, 0u, 0u>':
> /usr/include/c++/v1/./type_traits:943:62:
> required from
>
> 'struct std::__1::is_convertible llvm::StringMap&,
> llvm::StringMap >'
> /usr/include/c++/v1/./utility:269:77:
> required by
>
> substitution of 'template std::__1::pair<_T1,
> _T2>::pair(const std::__1::pair<_U1, _U2>&, typename
> std::__1::enable_if<(std::__1::is_convertible::value &&
> std::__1::is_convertible::value)>::type*) [with _U1 =
> llvm::StringRef; _U2 = llvm::StringMap]'
> /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:371:55:
> required from
>
> 'llvm::StringMap::MapEntryTy& llvm::StringMap AllocatorTy>::GetOrCreateValue(llvm::StringRef, InitTy) [with InitTy =
> llvm::StringMap; ValueTy =
> llvm::StringMap; AllocatorTy =
> llvm::MallocAllocator; llvm::StringMap::MapEntryTy =
> llvm::StringMapEntry >]'
> /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:375:43:
> required from
>
> 'llvm::StringMap::MapEntryTy& llvm::StringMap AllocatorTy>::GetOrCreateValue(llvm::StringRef) [with ValueTy =
> llvm::StringMap; AllocatorTy =
> llvm::MallocAllocator; llvm::StringMap::MapEntryTy =
> llvm::StringMapEntry >]'
> /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:299:32:
> required from
>
> 'ValueTy& llvm::StringMap::operator[](llvm::StringRef)
Re: Adding options framework variables that depend on variables coming after bsd.port.pre.mk
On 23 Mar, Naram Qashat wrote:
> I'm wanting to add an options framework LIB_DEPENDS that depends on
> variables that normally come after bsd.port.pre.mk.
>
> In this case, I am trying to add a UTEMPTER_LIB_DEPENDS on
> sysutils/libutempter, but I want to check OPSYS and OSVERSION beforehand,
> since base FreeBSD 9.x contains utempter while any earlier FreeBSDs as
> well as non-FreeBSD OSes don't contain it and need the port.
>
> I cannot place the UTEMPTER_LIB_DEPENDS line after bsd.port.pre.mk because
> the options framework doesn't see it then, but I also cannot wrap it
> around an if conditional using OPSYS and OSVERSION before bsd.port.pre.mk
> because those variables aren't set yet.
>
> I've been told that there is a workaround, but I was not told what the
> workaround was. Does anyone know how this can be acomplished?
Maybe something like:
UTEMPTER_LIB_DEPENDS=${FOO}
.include
.if ${OPSYS} ... && ${OSVERSION} ...
FOO=what you want to add to LIB_DEPENDS
.endif
___
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"
Time to be real
Go to hell. Go fuck yourselves. ___ 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: Adding options framework variables that depend on variables coming after bsd.port.pre.mk
> On 23 Mar, Naram Qashat wrote:
>> I'm wanting to add an options framework LIB_DEPENDS that depends on
>> variables that normally come after bsd.port.pre.mk.
>>
>> In this case, I am trying to add a UTEMPTER_LIB_DEPENDS on
>> sysutils/libutempter, but I want to check OPSYS and OSVERSION
>> beforehand,
>> since base FreeBSD 9.x contains utempter while any earlier FreeBSDs as
>> well as non-FreeBSD OSes don't contain it and need the port.
>>
>> I cannot place the UTEMPTER_LIB_DEPENDS line after bsd.port.pre.mk
>> because
>> the options framework doesn't see it then, but I also cannot wrap it
>> around an if conditional using OPSYS and OSVERSION before
>> bsd.port.pre.mk
>> because those variables aren't set yet.
>>
>> I've been told that there is a workaround, but I was not told what the
>> workaround was. Does anyone know how this can be acomplished?
>
> Maybe something like:
>
> UTEMPTER_LIB_DEPENDS=${FOO}
>
> .include
>
> .if ${OPSYS} ... && ${OSVERSION} ...
> FOO= what you want to add to LIB_DEPENDS
> .endif
That worked perfectly, thanks!
___
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: Time to be real
Thank you for your troll. For your convenience, we will do our best not to reply to you any further, to waste either your time, or valuable electrons. mcl ___ 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: Time to be real
Mark Linimon wrote: > to waste either your time, or valuable electrons. Come now, electrons are overrated. They come with every occurance of beta(-negative) decay. In fact, the intermediate negative W-boson that gives you said electron also gives you an electron antineutrino, entirely free of charge :-) AvW -- I'm not completely useless, I can be used as a bad example. pgpJHeqoe44rN.pgp Description: PGP signature
Re: Time to be real
A.J. "Fonz" van Werven wrote: > Mark Linimon wrote: > > >> to waste either your time, or valuable electrons. >> > > Come now, electrons are overrated. There's a lot of negativity over electrons here... -- Michelle Sullivan http://www.mhix.org/ ___ 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: Time to be real
On Mon, 23 Mar 2015 14:26:26 -0400 Joe Nosay wrote _ //| |___ || | /__/||| | PLEASE | |||| | | |||| | DO NOT FEED | |||| | |__|/|| | THE TROLLS ___ || | /__/||| | |__|/|| ||/ | || | ||/| |\|/\||/| /\// /\/ |_ > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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"
ports errors classification
Hello comunity! Im looking for documentation about ports instalation error codes. I meen somthing like this: *** [install] Error code 1 *** [build-depends] Error code 1 Can not find it yet. Can you shere it please? ___ 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: [HEADSUP] WIP on fonts
On 3/23/2015 11:44 AM, Bryan Drewery wrote:
> On 3/23/2015 11:39 AM, Bryan Drewery wrote:
>> On 3/22/2015 5:28 AM, Ben Woods wrote:
>>> My poudriere is acting funny now, and I'm not sure if it's related. It
>>> keeps deleting xorg-fonts-truetype because there is a new dependency
>>> (x11-fonts/dejavu), and then having to rebuild a whole suit of packages as
>>> a result.
>>>
>>> The interesting thing is that dejavu was a dependency the entire time. It
>>> will successfully peform the bulk build and update the package set. If I
>>> then re-run the bulk build, it does the same thing every time.
>>>
>>> My make.conf file (which hasn't changed in some time) contains:
>>> OPTIONS_SET=VAAPI VDPAU X265 ASS FAAC LAME
>>> MDNSRESPONDER RRDTOOL STATGRAB DEJAVU
>>>
>>>
>>
>> It will do this if a port has a dependency listed that it does not
>> actually use. So the xorg-fonts-truetype is incorrectly depending on
>> x11-fonts/dejavu.
>
>
> xorg-fonts-trutype has:
> +
> ${FONTDIR}/dejavu/DejaVuSans.ttf:${PORTSDIR}/x11-fonts/dejavu
> ~/svn/ports/x11-fonts/xorg-fonts-truetype # make -V FONTDIR
> /usr/local/share/fonts
>
>
> The dejavu port has:
>
> ~/svn/ports/x11-fonts/dejavu # grep DejaVuSans.ttf pkg-plist
> %%FONTSDIR%%/DejaVuSans.ttf
> ~/svn/ports/x11-fonts/dejavu # make -V '${PLIST_SUB:MFONTSDIR*}'
> FONTSDIR="/usr/local/share/fonts/dejavu"
>
> So somehow the package is lacking this file, or poudriere is wrong here.
>
> I'm double checking with some builds now.
>
It seems fine to me. Does it still happen for you every time?
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: Time to be real
Hi, Joe has indicated in the past that SPAM was sent from his account: https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095407.html We (postmaster@) contacted Joe and are looking into the issue. Please do not reply to the thread anymore. Florian signature.asc Description: OpenPGP digital signature
Re: ports errors classification
The code is just the value returned by the last process to run. Processes that complete successfully return 0, and if they fail, they return something else. So if you want to know what the codes mean, you have to look at the documentation - generally the man page - for the process, such as the compiler, or the 'cp ' command. That said, the number is generally 1 for any failure. On 24 March 2015 at 08:37, umka ursa wrote: > Hello comunity! > Im looking for documentation about ports instalation error codes. I meen > somthing like this: > > *** [install] Error code 1 > *** [build-depends] Error code 1 > > Can not find it yet. > Can you shere it please? > ___ > 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" > ___ 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: [HEADSUP] WIP on fonts
On Mon, Mar 23, 2015 at 05:51:51PM -0500, Bryan Drewery wrote:
> On 3/23/2015 11:44 AM, Bryan Drewery wrote:
> > On 3/23/2015 11:39 AM, Bryan Drewery wrote:
> >> On 3/22/2015 5:28 AM, Ben Woods wrote:
> >>> My poudriere is acting funny now, and I'm not sure if it's related. It
> >>> keeps deleting xorg-fonts-truetype because there is a new dependency
> >>> (x11-fonts/dejavu), and then having to rebuild a whole suit of packages as
> >>> a result.
> >>>
> >>> The interesting thing is that dejavu was a dependency the entire time. It
> >>> will successfully peform the bulk build and update the package set. If I
> >>> then re-run the bulk build, it does the same thing every time.
> >>>
> >>> My make.conf file (which hasn't changed in some time) contains:
> >>> OPTIONS_SET=VAAPI VDPAU X265 ASS FAAC LAME
> >>> MDNSRESPONDER RRDTOOL STATGRAB DEJAVU
> >>>
> >>>
> >>
> >> It will do this if a port has a dependency listed that it does not
> >> actually use. So the xorg-fonts-truetype is incorrectly depending on
> >> x11-fonts/dejavu.
> >
> >
> > xorg-fonts-trutype has:
> > +
> > ${FONTDIR}/dejavu/DejaVuSans.ttf:${PORTSDIR}/x11-fonts/dejavu
> > ~/svn/ports/x11-fonts/xorg-fonts-truetype # make -V FONTDIR
> > /usr/local/share/fonts
> >
> >
> > The dejavu port has:
> >
> > ~/svn/ports/x11-fonts/dejavu # grep DejaVuSans.ttf pkg-plist
> > %%FONTSDIR%%/DejaVuSans.ttf
> > ~/svn/ports/x11-fonts/dejavu # make -V '${PLIST_SUB:MFONTSDIR*}'
> > FONTSDIR="/usr/local/share/fonts/dejavu"
> >
> > So somehow the package is lacking this file, or poudriere is wrong here.
> >
> > I'm double checking with some builds now.
> >
>
> It seems fine to me. Does it still happen for you every time?
>
>
> --
> Regards,
> Bryan Drewery
>
This was due to me not bumping dejavu fonts, that is fixed now
Bapt
pgpJhh1vb0pdD.pgp
Description: PGP signature
Fixing a busted ports area
FreeBSD 9.3-RELEASE-p10 (GENERIC) #0: Tue Feb 24 21:01:19 UTC 2015 The ports area is broken, due to what I guess was a mangled upgrade path from FreeBSD 8.x. For example, when installing cups-client, I get: pkg-static: pkgconf-0.9.7 conflicts with pkg-config-0.25_1 (installs files into the same place). Problematic file: /usr/local/bin/pkg-config *** [fake-pkg] Error code 70 It's not clear to me how to fix this. Is the simplest way to just remove (or move) /usr/ports, install it from CD, then upgrade? I have quite a few ports installed. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ 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"
patch to bsd.ports.mk to support out-of-tree patches.
Hi, I've a need to keep soe changes outside of the ports tree, to
allow me to tailor
our installs. I could use the "EXTRA_PATCHES" setting, but I'd have to
outline the
patches every time and keep track of them one by one.
Instead, I have adde dhte following to bsd.ports.mk:
diff -u bsd.port.mk.orig bsd.port.mk
--- bsd.port.mk.orig2015-03-23 21:55:47.498891000 -0700
+++ bsd.port.mk2015-03-23 22:15:16.757385000 -0700
@@ -834,6 +834,11 @@
# The patches specified by this variable will be
# applied after the normal distribution patches but
# before those in ${PATCHDIR}.
+# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
+# Points to a directory hierarchy with the same layout
+# as the ports tree, where local patches can be found.
+# This allows a third party to keep their patches in
+# some other source control system if needed.
# PATCH_WRKSRC- Directory to apply patches in.
# Default: ${WRKSRC}
#
@@ -3523,6 +3528,37 @@
esac | ${PATCH} ${PATCH_DIST_ARGS} `patch_dist_strip $$i` ; \
done )
.endif
+.if defined(EXTRA_PATCH_TREE)
+@set -e ;\
+if [ -d ${EXTRA_PATCH_TREE} ]; then \
+if [ "`${ECHO_CMD}
${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*`" !=
"${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*" ]; then \
+${ECHO_MSG} "===> Applying local patches for
${PKGNAME}" ; \
+PATCHES_APPLIED="" ; \
+for i in
${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*; do \
+case $$i in \
+*.orig|*.rej|*~|*,v) \
+${ECHO_MSG} "===>
Ignoring patchfile $$i" ; \
+;; \
+*) \
+if [
${PATCH_DEBUG_TMP} = yes ]; then \
+ ${ECHO_MSG} "===> Applying local patch $$i" ; \
+fi; \
+if ${PATCH}
${PATCH_ARGS} < $$i ; then \
+ PATCHES_APPLIED="$$PATCHES_APPLIED $$i" ; \
+else \
+ ${ECHO_MSG} `${ECHO_CMD} "=> Patch $$i failed to apply cleanly." |
${SED} "s|${EXTRA_PATCH_TREE}/${PKGORIGIN}/||"` ; \
+if [
x"$$PATCHES_APPLIED" != x"" -a ${PATCH_SILENT} != "yes" ]; then \
+ ${ECHO_MSG} `${ECHO_CMD} "=> Patch(es) $$PATCHES_APPLIED applied
cleanly." | ${SED} "s|${EXTRA_PATCH_TREE}/${PKGORIGIN
+}/||g"` ; \
+fi; \
+${FALSE} ; \
+fi; \
+;; \
+esac; \
+done; \
+fi; \
+fi
+.endif
.if defined(EXTRA_PATCHES)
@set -e ; \
for i in ${EXTRA_PATCHES}; do \
this allows me to keep as many patches as I require in a separate
"out-of-tree"
repository, that I can change at will, allowing the actual ports tree
to be
updated as needed with no chances of file collisions etc.
Basically I keep a second parallel 'shadow' tree containing nothing
but patches, and
the ports tree remains unchanged.
Is there any interest on taking this onboard?
Julian
___
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: Fixing a busted ports area
On Tue, 24 Mar 2015 16:26:30 +1100 (EST) Dave Horsfall wrote > FreeBSD 9.3-RELEASE-p10 (GENERIC) #0: Tue Feb 24 21:01:19 UTC 2015 > > The ports area is broken, due to what I guess was a mangled upgrade path > from FreeBSD 8.x. For example, when installing cups-client, I get: > > pkg-static: pkgconf-0.9.7 conflicts with pkg-config-0.25_1 (installs files > into the same place). Problematic file: /usr/local/bin/pkg-config > *** [fake-pkg] Error code 70 > > It's not clear to me how to fix this. Is the simplest way to just remove > (or move) /usr/ports, install it from CD, then upgrade? I have quite a > few ports installed. You haven't been too specific as to your upgrade path. But sometimes it's as easy as changing to the offending ports folder, and issuing a make deinstall. Then attempting whatever upgrade procedure you following at the time of the incident. However, if this same type of error persists unreasonably. You may require more drastic measures, to overcome the issue(s). --Chris > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." http://www.horsfall.org/spam.html (and check the home page whilst > you're there) ___ > 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" ___ 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: patch to bsd.ports.mk to support out-of-tree patches.
On Tue, 24 Mar 2015 13:33:15 +0800 Julian Elischer wrote
> Hi, I've a need to keep soe changes outside of the ports tree, to
> allow me to tailor
> our installs. I could use the "EXTRA_PATCHES" setting, but I'd have to
> outline the
> patches every time and keep track of them one by one.
>
> Instead, I have adde dhte following to bsd.ports.mk:
>
>
>
> diff -u bsd.port.mk.orig bsd.port.mk
> --- bsd.port.mk.orig2015-03-23 21:55:47.498891000 -0700
> +++ bsd.port.mk2015-03-23 22:15:16.757385000 -0700
> @@ -834,6 +834,11 @@
> # The patches specified by this variable will be
> # applied after the normal distribution patches but
> # before those in ${PATCHDIR}.
> +# EXTRA_PATCH_TREE - where to find extra 'out-of-tree' patches
> +# Points to a directory hierarchy with the same layout
> +# as the ports tree, where local patches can be found.
> +# This allows a third party to keep their patches in
> +# some other source control system if needed.
> # PATCH_WRKSRC- Directory to apply patches in.
> # Default: ${WRKSRC}
> #
> @@ -3523,6 +3528,37 @@
> esac | ${PATCH} ${PATCH_DIST_ARGS} 'patch_dist_strip $$i' ; \
> done )
> .endif
> +.if defined(EXTRA_PATCH_TREE)
> +@set -e ;\
> +if [ -d ${EXTRA_PATCH_TREE} ]; then \
> +if [ "'${ECHO_CMD}
> ${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*'" !=
> "${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*" ]; then \
> +${ECHO_MSG} "===> Applying local patches for
> ${PKGNAME}" ; \
> +PATCHES_APPLIED="" ; \
> +for i in
> ${EXTRA_PATCH_TREE}/${PKGORIGIN}/patch-*; do \
> +case $$i in \
> +*.orig|*.rej|*~|*,v) \
> +${ECHO_MSG} "===>
> Ignoring patchfile $$i" ; \
> +;; \
> +*) \
> +if [
> ${PATCH_DEBUG_TMP} = yes ]; then \
> + ${ECHO_MSG} "===> Applying local patch $$i" ; \
> +fi; \
> +if ${PATCH}
> ${PATCH_ARGS} < $$i ; then \
> + PATCHES_APPLIED="$$PATCHES_APPLIED $$i" ; \
> +else \
> + ${ECHO_MSG} '${ECHO_CMD} "=> Patch $$i failed to apply cleanly." |
> ${SED} "s|${EXTRA_PATCH_TREE}/${PKGORIGIN}/||"' ; \
> +if [
> x"$$PATCHES_APPLIED" != x"" -a ${PATCH_SILENT} != "yes" ]; then \
> + ${ECHO_MSG} '${ECHO_CMD} "=> Patch(es) $$PATCHES_APPLIED applied
> cleanly." | ${SED} "s|${EXTRA_PATCH_TREE}/${PKGORIGIN
> +}/||g"' ; \
> +fi; \
> +${FALSE} ; \
> +fi; \
> +;; \
> +esac; \
> +done; \
> +fi; \
> +fi
> +.endif
> .if defined(EXTRA_PATCHES)
> @set -e ; \
> for i in ${EXTRA_PATCHES}; do \
>
>
>
>
>
> this allows me to keep as many patches as I require in a separate
> "out-of-tree"
> repository, that I can change at will, allowing the actual ports tree
> to be
> updated as needed with no chances of file collisions etc.
>
> Basically I keep a second parallel 'shadow' tree containing nothing
> but patches, and
> the ports tree remains unchanged.
>
> Is there any interest on taking this onboard?
Thank you for this, Julian!
Absolutely interested in seeing this. I've been forced
to kludge a similar approach. This would be wonderful.
Please do.
--Chris
>
>
> Julian
>
>
>
>
> ___
> 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"
___
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: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import [what N2255 suggests]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html has the
following note about std::is_convertible :
> Library implementor's note: Except for the protected/private access checks,
> and the ambiguity checks, this specification is completely implementable in
> C++03 (even without rvalue references). However it is intended that this be
> implemented with compiler help to get the access and ambiguity checks correct.
This note would seem to apply to examples like Richard Smith's tiny test case
listed in https://llvm.org/bugs/show_bug.cgi?id=22771 :
> Here's a testcase that fails with Clang:
>
> #define __has_feature(x) 0
> #include
> class X { X(const X&); };
> bool b = std::is_convertible::value;
>
> (Using a public deleted copy constructor fails similarly.)
It sounds like there are going to be limitations to any library-only solution
(i.e., to any fallback implementation of std::is_convertible).
So for a failing fallback test example to matter likely requires that the
failure not depend on accessibility checks or ambiguity checks.
Might it be that the improvement that was being tested is sufficient given the
general limitations on library-only code solutions?
Going the other way: if one wants code (such as llvm/clang source) to survive
environments that need to use a library-only fallback then that code needs to
avoid depending on accessibility or ambiguity properties for its direct or
indirect use of std::is_convertible. I do not know what criteria llvm/clang
uses for such issues.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-22, at 09:56 PM, Mark Millard wrote:
I'd sent out a note Saturday for this for powerpc64-xtoolchain-gcc and its
powerpc64-gcc port: use of CROSS_TOOLCHAIN=powerpc64-gcc used on a powerpc64.
No solution, just notes about what was going on after looking at the source
code related to the messages. If you care, see:
> CROSS_TOOLCHAIN=powerpc64-gcc mishandles "Substitution Failure Is Not An
> Error" when compiling clang and stops the build
( https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001506.html )
> sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T1>()))
> == 1
is the core place involved in your example and mine but the order of
compilation for my context means a different starting place that ended up using
the above.
lang/gcc5 did the same when I later tried it.
I doubt that host-type or TARGET or TARGET_ARCH matter. I doubt xtoolchain vs.
normal port matters. I expect that the issue spans a range of g++ versions.
Unfortunately that probably also means that the effectively "Substitution
Failure of this kind Is An Error" rule now in use will probably be around for a
while: it is likely not some local accident that has a quick fix. The best case
is if it is simple but each version/variant needs to release with the change.
===
Mark Millard
markmi at dsl-only.net
___
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: Fixing a busted ports area
On Mon, Mar 23, 2015 at 10:41 PM, Chris H wrote: > On Tue, 24 Mar 2015 16:26:30 +1100 (EST) Dave Horsfall > wrote > > > FreeBSD 9.3-RELEASE-p10 (GENERIC) #0: Tue Feb 24 21:01:19 UTC 2015 > > > > The ports area is broken, due to what I guess was a mangled upgrade path > > from FreeBSD 8.x. For example, when installing cups-client, I get: > > > > pkg-static: pkgconf-0.9.7 conflicts with pkg-config-0.25_1 (installs > files > > into the same place). Problematic file: /usr/local/bin/pkg-config > > *** [fake-pkg] Error code 70 > > > > It's not clear to me how to fix this. Is the simplest way to just remove > > (or move) /usr/ports, install it from CD, then upgrade? I have quite a > > few ports installed. > You haven't been too specific as to your upgrade path. > But sometimes it's as easy as changing to the offending > ports folder, and issuing a make deinstall. Then attempting > whatever upgrade procedure you following at the time of the > incident. > However, if this same type of error persists unreasonably. > You may require more drastic measures, to overcome the issue(s). > > --Chris > > You rally need to check out /usr/ports/UPDATING. Take a look at 20120726 If you are making this big a jump, you will likely hit a few more of these, -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.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"
