* Eitan Adler (eitanadlerl...@gmail.com) wrote:
I'd suggest
-+.if defined(WITHOUT_DEBUG)
++.if !defined(WITH_DEBUG)
DEBUG knob is assumed to defauly to false, this WITH_DEBUG is checked
everywhere. See `grep -R _DEBUG /usr/ports/Mk`
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510
HOUT_FOO if FOO is on by default. Same for
> > other checks.
>
> Is this documented in the Porters Handbook anywhere?
Doesn't look like this. Maybe it should be.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2
the aMule install trying to do here?
>
> Ok, that was only one question. :-)
Seems like gettext and all gettext consumers use the same set of
autotools macros, but gettext itself should be processed differently
by them. Thus the `if'. Since "amule" = "gettext" evalua
will remove resulting empty file)
But I assume what you need is -r option for diff - it compares 2
directories recursively, processing all changes as well as new and
removed files correctly.
% diff -ruN /usr/ports/net-p2p/amule amule
where amule is your modified port.
--
Dmitry Marakasov .
lf.
This patch looks good at a first glance, I've scheduled it to be build
in a tinderbox.
Btw, I'll second porttools advice, it really does much work for you,
such as patch creation and partially filling send-pr form.
Also look at portlint - it inspects a port and porints you at some
c
d at 0.
Removing amule2/files/patch-amuleDlg.cpp (empty after patching).
ensure that you're testing it on really original amule2 port (I guess
that you're not, considering (offset 1 line) messages in the first
chunk).
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD
ecessary.
> WARN: Makefile: how about using MANLANG for designating manual
> language, such as "fr"?
Those are likely false positives, as portlint doesn't seem see
Makefile.man.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
* Torfinn Ingolfsen (tin...@gmail.com) wrote:
It builds OK, but plist (and Makefile.man I guess) is incorrect.
http://people.freebsd.org/~amdmi3/aMule-nooptimize-2.2.3.log
don't mind -nooptimize, I'm just testing it with different options.
--
Dmitry Marakasov . 55B5 0596 FF1E
* Chess Griffin (ch...@chessgriffin.com) wrote:
> It looks like my new pkg-plist was not included in the commit. It is in
> my PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=130062
My bad, fixed.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amd
* Olivier SMEDTS (oliv...@gid0.org) wrote:
> and of course you must have "bin/program_name" in pkg-plist.
If it's just a single file, the preferred way is to add
PLIST_FILES=bin/program_name
to the Makefile and not use pkg-plist at all.
--
Dmitry Marakasov . 55B5 0
it not? Why? There's no reason to introduce pkg-plist for just
a single file.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-ports@freeb
* Florent Thoumie (f...@xbsd.org) wrote:
> > You are lucky guys you have not lived in USSR. otherwise you'd surely like
> > alternative ways :)
>
> In soviet russia, alternative ways like you.
>
> I wish people remembered KISS more than TIMTOWTDI.
PLIST_* seems S
stree
is too slow, so it's better to create an index like that:
find -L /usr/ports -name Makefile -maxdepth 3 -mindepth 3 -exec grep -H '' {}
\; > MAKEFILES.INDEX
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.a
I think there's
no need in such strict dependency, as clamav 0.94.2 is in the tree
for 3 months already.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
_
=0.94.2:${PORTSDIR}/security/clamav
That's just what I said that's no need to use.
RUN_DEPENDS+= ${LOCALBASE}/bin/clamscan:${PORTSDIR}/security/clamav
and/or
BUILD_DEPENDS+= ${LOCALBASE}/bin/clamscan:${PORTSDIR}/security/clamav
-or-
LIB_DEPENDS+= clamav:${PORTSDIR}/security/clamav
is
those before the
deadline and freeze. Actually, the only port left is OOo which I
currently have some trouble making to fail on my dev box (as opposed
to tinderbox).
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp
t:
(cd xxx; make)
and that fails with -j (make: illegal option -- -). So is there
some magic with recursive make calls and -j?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
_
that reason
(althrough there's no equivalent for GNU make).
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
ave been my boost 1.37 compatibility fix. I've reverted it for now.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing li
* Pav Lucistnik (p...@freebsd.org) wrote:
Btw, this change broke build failures. If vendor's make fails,
.build_done.xxx._usr_local is still created in work and $? = 0 as if it
have succeeded.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdm
$?
0
r...@hades:test# ls work
.build_done.test._usr_local
.configure_done.test._usr_local
.extract_done.test._usr_local
.patch_done.test._usr_local
Makefile
---
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.am
nd the ${ECHO_CMD} ${BUILD_FAIL_MESSAGE}, BTW?
> Because they are present in do-configure target too - should they be
> removed there too?
I just didn't like them :) Are they really needed around single command?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F
patch to boost,
pav@ is going to start it on Sunday evening. The update itself is
planned for 6th, as we're still awaiting approvals or timeouts for
2 PRs. For now all we need is to wait for exp-run results and fix
extra bugs, if there are any.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5
thon
.elif defined(USE_BOOST)
LIB_DEPENDS+= boost_thread:${PORTSDIR}/devel/boost
.endif
boost-check-python:
.if !exists(${LOCALBASE}/include/boost/python.hpp)
@${ECHO_MSG} "This port requires boost built with python support."
@${ECHO_MSG} "Please uninstall boost
above and make boost-python only
install python stuff, it will be easier to change logic in a single
place.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
plains what really happens when
using -lpthread, and what happens in the above mentioned error case
(cc'ing hackers@).
So should -pthread be forced in ldflags
1) Only in ports that explicitely use threads
2) In all ports that link with -lthr implicitely, including through
other ports?
--
Dmi
because not many people need
them, bjam, well, because it's a build tool, and everything else
may be left in a single port.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@
with boost-python separation, it's somewhat transparent
from the point of library names (i.e. if I want ${libname} I should use
boost-${libname} if it exists, else just boost-other or how-do-we-name-
it).
The statistics on what ports use which boost libs, and build times for
separate boost libs
1.38 with some ports,
> not with all that depend on boost and then file a PR, specifying which
We'll need an exp-run for it anyway, so I guess it's OK.
If you have a patch ready, I suggest to file a PR and mail pav@ to do
exp-run for it. If there are no major failures, we can push
e
> > tree, else we won't be bored during the freeze fixing it.
>
> As I understand this, it's OK to file a PR for just updating to 1.38,
> but port re-organization is delayed until 7.2 is released. Is this
> correct?
Better ask pav (cc'd). I myself see no r
5.8.9" | awk -F/ '{print $5}'
then this:
for f in `find /usr/local/bin /usr/local/lib /usr/local/libexec /usr/local/sbin
-type f`; do ldd $f 2>/dev/null | grep -q libperl && pkg_which $f; done
and portupgraded only named ports. No problems so far.
--
Dm
There were some pretty serious vulnerabilities found in freetype:
http://secunia.com/advisories/34723/
I think we need to fix these before the tag.
There's the patch:
https://bugzilla.redhat.com/show_bug.cgi?id=491384
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD
4.1.tbz
Boost was updatex to 1.37 couple of weeks ago. Maybe you need to update
your ports?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebs
* Alexander Churanov (alexanderchura...@gmail.com) wrote:
> I'm looking into that.
I unfortunately was not able to reproduce the problem. It hangs for a
second on startup without GUI drawn yet, yes, but then it works
normally.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D
r s-n 0.10 and consider awesome
broken for now. Meanwhile, awesome users are recommended to not
upgrade from/downgrade to xcb-util 0.3.3.
This is really our fault as there should've been more testing and
coordination with this update.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510
is widespread progress must continue. Awesome needs to be
> patched, updated or marked BROKEN temporarily.
Sure, I've just did exactly that - marked awesome BROKEN in presence of
newer xcb-util. The note above was for awesome users who, regardless of
ports progression and updates, will need
him/her about the potential break?
Probably. Productive communication and collaboration haven't harmed
anyone yet.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
_
27;t use @dirrm libdata/pkgconfig
- pkg-config's plist is incorrect
Then the last needs to be corrected and maybe Porter's handbook should
be updated, as there are ports that don't USE_GNOME=pkgconfig and do
@dirrm. Or correct me if I'm wrong
orts/Mk to discover exact
behavior of the ports system in specific case and/or search for examples
in other ports. To ease the process, I've indexed all Makefiles in a
single file, with this:
find /usr/ports -name Makefile -mindepth 3 -maxdepth 3 -exec grep -H ''
{} \; >MAKEFIL
* Rong-En Fan ([EMAIL PROTECTED]) wrote:
> After pav@'s commit to bsd.port.mk, now you can test WITH/WITHOUT
> freely with OPTIONS. Also, when the set of OPTIONS is changed, users
> will be prompted to the dialog again (thank you pav!).
So good, thanks a lot pav!
--
Best reg
even more. For example, kdelibs3-nocups support is
rather ugly as it is).
I would like to hear if there are more people who's for such a change,
and general opinion of kde@ guys. Thanks.
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
lso we can be sure
problem report doesn't get lost.
Here's an example PR if you get confused with some fields:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88506
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
__
available from http://www.amdmi3.ru/gnash/
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
gnash-0.8.0.tar.gz
Description: Binary data
gnash.gdb.log.gz
Description: Binary data
___
freebsd-ports@freebsd.o
nd is more or
less playable (multiplayer also, as far as I remember)
I'm not sure it's worth effort to repocopy ogre3d port and then dealing
with resolving file collisions (but I guess ogre3d and ogre3d12 may just
be marked in CONFLICTS of each other). Any comments?
--
Best regards,
t possible to use things like USE_QT_VER or USE_SDL
conditionally depending on what OPTIONS are set.
So, is it possible to use this feature, or are there still any issues
not allowing use of options.mk in ports?
--
Best regards,
Dmitry Marakasov mailto:[EMAIL
27;ll have to not use OPTIONS in this case, am I right?
> Note that hardcoding /usr/ports to your port breaks the port for users
> with nonstandard PORTSDIR.
Well, ../../Mk/bsd.port.options.mk should go then?
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
at will eliminate possibility of using your port standalone, outside
> ports tree.
Including ${PORTSDIR}/Mk/bsd.foo.mk after bsd.port.pre.mk is
the only solution then (assuming that corresponding WANT_FOO is
missing). Ok, many thanks for help.
--
Best regards,
Dmitry Marakasov mailto:
n notice any problems, as
any port install/update will also install the fix.
3) Note in CHANGES for lucky ones who encounter `Could not find
bsd.port.options.mk' error, with trivial fix.
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
-n100 cat | sed -n -e
'/^\.if.*WITH_/,/^\.endif/ p'
.if's are far more flexible. And for my eyes, if's look cleaner.
> eyes. The reason I'm not rallying for cosmetics like that is that
> I fail to see make(1) as a future-proof base for ports.
That is unfortunate
t)
> - Change the hyperlink to point to a copy of the GPL on the Internet
> - something else.
I think it's better to not bother and install GPL file.
Not like it's some kind of terrible never-NEVER-do-it thing.
--
Best regards,
Dmitry Marakasov
need some help,
but it'll be easy and quick.
Thank you for your patience, and enjoy free Flash player.
It supports YouTube, yes :)
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org ma
up-to-date with port
> > ..
> > automake-wrapper-20070404 = up-to-date with port
Also different ports, so no problem here either.
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
Hi!
I have a problem porting a piece of software that use
getline(char**, int*, FILE*). This function is only present in
glibc so I wonder what do I do in this case? Maybe there is some
port which provides required functionality (like for example
argp-standalone)?
--
Best regards,
Dmitry
functionality (like for example argp-standalone)?
> Just a guess, but maybe devel/libgetline?
Unfortunately, no. libgetline is command line library (like readline),
it has nothing to do with what getline() of glibc does :(
--
Best regards,
Dmitry Marakasov
ould be to make simple port out of
it, with single .h file with static functions, which can be included in
any place where it is needed. Is it OK to place GPL sources into the
ports tree? (it would be silly to make distfile for single 3kb .h file)
--
Best regards
sion cause any bugs?
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
something broke after autoconf dependenices
switch in many ports.
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscr
different way: check .a instead of .so.*, and
fail if .a is missing, and .so is present (i.e. needed static lib is not
available at all), don't add library ports to package depends
- Add -static to CFLAGS/CXXFLAGS
Any comments? I will try to experiment with this for now.
--
Best regards,
D
t an option that may be
usedul, but don't guarantee anything. Like, for example, WITH_DEBUG.
But, yes, it would be nice to indicate that the port should be rebuild
if any of libs it use are updated, I need to think about it.
--
Best regards,
Dmitry M
Hi!
I'm porting silvertree game (from creators of wesnoth), and I have
some issues with it's DATADIR.
The problem is that port is named silvertree, but it installs data under
${PREFIX}/share/silvertree-rpg. What do I do with DATADIR in this case?
1. Rename the port:
Not a best solution, as I'll
* Tijl Coosemans ([EMAIL PROTECTED]) wrote:
> Actually I'd like to see this clarified as well, because none of the
> port maintainers I've ever spoken to knows this. Is DATADIR supposed
> to be user changeable or not? Does it need to be passed to configure
> or not?
Seems like it's not user-changea
Hi!
net/tightvnc seem to be the first port to actually use
bsd.port.options.mk, but AFAIK tha latter is broken for now:
# cd /usr/ports/net/tightvnc && make
"Makefile", line 41: Could not find bsd.port.options.mk
make: fatal errors encountered -- cannot continue
options.mk should only work on fo
onal:2083:9: note: candidate template ignored:
substitution failure [with _Args = <>]: implicit instantiation of undefined
template 'std::__1::__bind_return,
std::__1::tuple<>, false>'
operator()(_Args&& ...__args)
^
/usr/include/c++/v1/functio
e enough to just rebuild lib/libc++ and install
> it.
Sorry, I haven't tested the branch myself, only seen exp-run results.
Would be nice to have another exp-run.
Btw, is it possible to merge the patch into stable/10 as well?
It will make it possible to use clang35 there.
--
Dmit
nd change needs
@dir /var/run/unbound
instead, which will remove empty directory for cleaner deinstallation.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
_
lcome!
[1] http://beta.repology.org/
[2] https://github.com/AMDmi3/repology
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://amdmi3.ru
___
freebsd-ports@freebs
* Carlos J. Puga Medina (c...@freebsd.org) wrote:
> https://twitter.com/FreshPorts/status/780932556883623936
>
> Keep up the good work :)
Thanks :)
Unfortunately, this project draws time from processing your reviews,
but I hope to get to them until the weekend.
--
Dmitry Marakasov
-5.7.1 Qt unit testing module
> qt5-x11extras-5.7.1Qt platform-specific features for X11-based
> systems
> qtchooser-39 Qt tool wrapper
>
>
> Is there anything I'm missing?
See https://bug
Hi!
I'm now exploring new DESTDIR-related stuff, and I find it far from
being useable. More of that, DESTDIR-related changes seem dangerous
to me.
As far as I understand, for port to support DESTDIR, it's files
should be installed into ${DESTDIR}/${PREFIX}/foo (aka ${TARGETDIR}/foo),
but all path
* G??bor K??vesd??n ([EMAIL PROTECTED]) wrote:
> >Now, if we want to fix these, we'll need to change variables in
> >REINPLACE_CMD lines: LOCALBASE to LOCALBASE_REL, X11BASE to X11BASE_REL
> >and DATADIR... hmm, we have no DATADIR_REL, so all is left is
> >${PREFIX}/share/${PORTNAME}. That's unforg
* G??bor K??vesd??n ([EMAIL PROTECTED]) wrote:
> >I agree with every your word.
> I was to implement it in this way, but as I said this would require us
> to change all of the *_DEPENDS lines. Erwin told me that this can't be
> happen, so I was pushed to go the another way. Erwin is in portmgr, a
* Kris Kennaway ([EMAIL PROTECTED]) wrote:
> > The hard part is to get ports writers to think the right way about
> > DESTDIR after ignoring it for so many years. And once you decide to
> > go about fixing it, there's no way around that problem.
>
> My preferred solution involves a couple of shel
* Doug Barton ([EMAIL PROTECTED]) wrote:
> > if we can work this out a bit better, my progress so far
> > would become pointless...
> Not at all! If I had a dollar for every Good Idea(TM) that I had which ended
> up leading me down a completely different road, I'd be retired now. These
> are not ea
* Roman Bogorodskiy ([EMAIL PROTECTED]) wrote:
> 2. Port tree is unstable
>
> IMO, port tree is not very stable. I mean: we're all human and more or
> less often make mistakes and inaccurate commits. So you cannot be sure
> that if you cvsup/portsnap your tree, it will not break something
> (e.g.
* Dominique Goncalves ([EMAIL PROTECTED]) wrote:
> According to Security Advisories SA-06:19 about OpenSSL, we need to
> rebuild ports which are statically linked to libcrypto(3).
>
> Is there a magic command to rebuild these ports ?
No magic command, but this seems pretty reliable for me:
for p
* Stanislav Sedov ([EMAIL PROTECTED]) wrote:
> We are going to update all sdl ports to latest version.
> This will require modifications to sdl-dependent ports,
> and we are currently doing full build in tinderbox
> to ensure that all goes right.
I.e. that will be include/SDL12, sdl12-config, etc.?
* Stanislav Sedov ([EMAIL PROTECTED]) wrote:
> > I.e. that will be include/SDL12, sdl12-config, etc.?
> > Are there other changes besides version?
> No, it will resemble original distribution (include/SDL, sdl-config).
> In any case you should not rely on this and always use bsd.sdl.mk
> supplied v
* Stanislav Sedov ([EMAIL PROTECTED]) wrote:
Seems like SDL ports were updated before freeze after all :)
Right now, I've ran into a problem when upgrading SDL_net, so meybe
there's bug that should be fixed.
The problem is that linking SDL_net failed with complain from libtool
that it can't find
* Marcus von Appen ([EMAIL PROTECTED]) wrote:
> Personally I would break games/diameter and keep it as broken until a
> compatible version of it will be released (or remove it in a year or so
> if nothing happens).
I agree. To fork guichan for only one port is not a solution. I
would be grateful if
* Marcus von Appen ([EMAIL PROTECTED]) wrote:
> > > Personally I would break games/diameter and keep it as broken until a
> > > compatible version of it will be released (or remove it in a year or so
> > > if nothing happens).
> > I agree. To fork guichan for only one port is not a solution. I
> >
* Marcus von Appen ([EMAIL PROTECTED]) wrote:
> > I've just mailed diameter's author, and I hope we'll come with some
> > solution shortly, most likely patch for current version of diameter.
> > I'll keep you informed.
> Okay, great.
All done, I've got patches for diameter to support guichan 0.5.0.
re of it's current status.
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
eady without
problems. So more likely the cause is new category in ports
(ports-mgmt) or new virtual category gnustep.
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.o
yone experience this problem? Qt3 designer does work without
any problems...
--
Best regards,
Dmitry Marakasov mailto:[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
make[1]: *** [hotspot-build] Error 2
> gmake[1]: Leaving directory
> `/usr/ports.work/usr/ports/java/openjdk7/work/openjdk'
> gmake: *** [build_product_image] Error 2
> *** [do-build] Error code 1
>
> Stop in /usr/ports/java/openjdk7.
> *** [build] Error code 1
Sam
* Don Lewis (truck...@freebsd.org) wrote:
> Is anyone else seeing this?
Yes. The same problem breaks at least math/drgeo and can be confirmed
in poudriere.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruh
in options
added)?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listin
ILER_SUPPORTED_ARGUMENTS:M-fwhole-program}
@${REINPLACE_CMD} -e 's|-fwhole-program||' ${WRKSRC}/CMakeLists.txt
.endif
.if ${COMPILER_SUPPORTED_ARGUMENTS:M-malign-double}
CXXFLAGS+= -malign-double
.endif
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F
-
To fix that, first we need to fix macros containing these lines, next
wait for new versions to be released, next wait for everybody to use
these versions. That's years for maintained software while there's also
unmaintained, and for that we need a way to deal with this in ports.
So dealing wit
201 - 289 of 289 matches
Mail list logo
