Re: www/webkit-gtk2 deprecation?
On Mon, 25 Feb 2019 at 20:23, Kurt Jaeger wrote: > > Hi! > > > I notice that www/webkit-gtk2 has just been marked as FORBIDDEN and > > DEPRECATED. While I'm usually for putting down unmaintained ports, > > this particular port is a dependancy for java/eclipse. I'm sure that > > users of java/eclipse will not be happy about its loss from FreeBSD > > ports (I know I'm not). Can we leave it in the tree until a newer port > > of java/eclipse comes along? > > We have 4.6.2 in the ports. Current version upstream seems to be 2018 12 R, > I don't know how this translates to 4.x.y ? Unfortunately, the porting effort for Eclipse is quite an involved process. My feeble attempts to bring java/eclipse up to date have borne no useful results. I've pinged the maintainer, but haven't heard anything back from him. > Is the debate about openjdk11 also playing a role here ? No, this is separate from that discussion. 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"
www/webkit-gtk2 deprecation?
Hi, I notice that www/webkit-gtk2 has just been marked as FORBIDDEN and DEPRECATED. While I'm usually for putting down unmaintained ports, this particular port is a dependancy for java/eclipse. I'm sure that users of java/eclipse will not be happy about its loss from FreeBSD ports (I know I'm not). Can we leave it in the tree until a newer port of java/eclipse comes along? 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: Config inconsistency for firefox-esr on rpi2
On 24 Feb 2019, at 18:28, bob prohaska wrote: > > In playing with www/firefox-esr on an rpi2 at r343555 using > ports at 493769 make stops with > > ===> Configuring for firefox-esr-52.8.0,1 > firefox-esr-52.8.0,1: Needs gtk3 with WAYLAND support enabled. > *** Error code 1 > > despite both wayland and gtk3 being selected in the config dialog. > > I've retried several times, the error persists. This actually means that you have to rebuild the *gtk3* port with WAYLAND enabled. It could be worded a little better, maybe. :) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: freecad cannot build
## ajtiM via freebsd-ports (freebsd-ports@freebsd.org): > Subject: freecad cannot build Oh, it can, e.g.: http://beefy6.nyi.freebsd.org/data/120amd64-default/493629/logs/FreeCAD-0.17.13541_6.log and my local build logs look very similar. > All ports are built on FreeBSD-Release-12-p3 (amd64). How? Unless you build in a clean environment, both packages and builds can pick up all sorts of funny stuff from the environment, and may give funny results. >I did install > package for french/med because french/aster doesn't build on amd64. Stop right here - aster is not in the dependency path of neither med nor FreeCAD, that looks phishy. On the other hand - how about installing FreeCAD from packages? Regards, Christoph -- Spare Space ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Mon, Feb 25, 2019 at 01:58:01AM +, Dima Pasechnik wrote: > On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl > > > Given that I actually don't > > program in python, that certainly seems to be an unreasonable > > request from the python maintainers. > > If I were a Python maintainer I might have pointed out to you that > IEEE-754 speaks about sinPi(), not sinpi(), and if you added > sinPi() to libm, it would have been fine without a patch. > (although this might be breaking naming taboos :-)) > And, I would tell you to read the 3 or 4 emails I sent to the various mailing list and the PR. TS 18661-4 I should ask for my commit bit back, and commit the sinpi patch just to spite people like you who spout off without actually looking at what people give you. -- Steve ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 24, 2019 at 8:09 PM Steve Kargl wrote: > > On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote: > > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote: > > > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: > > >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl > > >> wrote: > > >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > > If I were the lang/gcc maintainer this -rpath problem would be my > > > number one priority. The current maintainer has never proposed > > > any solutions and when I submit patches he always resists. I'm > > > done wasting my time fighting him. > > > > I'm late to this discussion (not being a Fortran/Python user) but > > is there any way to remove a recalcitrant maintainer? > > >>> > > >>> Can you explain what you mean? The maintainer of the lang/gcc > > >>> ports is a long-time member of the GCC steering committee > > >>> and a long-time maintainer of all gcc FreeBSD ports. There > > >>> are very few FreeBSD users (like 3 of us) who have commit access > > >>> to the gcc tree. Seems like a dubious idea to remove one of > > >>> those 3. > > >> > > >> Given the amount of time unsuspecting and half-suspecting users wasted > > >> on making Fortran code (often in form of a Python extension) working > > >> on FreeBSD (e.g. I probably wasted weeks), time is high to do > > >> something, e.g. commit the said patches---there is an agreement that > > >> they are correct, right? > > > > > > Dima, gerald has always been very helpful in all my communications > > > with him. Have you filed a PR for the fix? dropped him an email? > > > > > > I know we (gerald and ?? can't remember) tried a static lib change > > > a few years ago. I believe it didn't work at the time due to missing > > > symbols which we have since added. > > > > This cannot be entirely correct. I don't see what missing symbols this > > would have been. I attached my patch to bug 208120 on 2017-02-09 and > > you responded it was the best idea. mmel then discovered it didn't > > entirely fix the problem on ARM where _Unwind_Backtrace has version > > GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this > > doesn't explain why this was done, but we'll have to make the same > > change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is > > part of the ABI). This isn't a blocker for the patch. > > > > I emailed the patch to gerald on 2017-02-21. He responded in the usual > > way that he prefers patches submitted upstream and because I thought the > > patch would not be accepted upstream he proposed an alternative solution > > where gcc would always add -rpath on FreeBSD so you didn't have to > > specify it on the command line. I responded this wouldn't fix the case > > where clang was used as a linker (e.g. to combine fortran and c++ code > > in one program) and that the FAQ on the gcc website said it was a bad > > idea for other reasons. I also said upstream might accept my patch if > > it was a configure option but that the gcc configure scripts are > > complicated and I didn't know where to add it exactly. Then silence. > > This is typical for all my conversations with him over the years so I > > stopped caring. > > > > I do find the above paragraph to be somewhat ironic. It seems > that python importing Fortran compiled code runs into this > problem. I have sent 3 or 4 patches to freebsd-ports@, freebsd-python, > and created a PR to fix a conflict with the symbol sinpi (which I > intend to add to libm), and I have been told to upstream my patch. The patch ought to be upstream, for your patch is quite meaningful outside of FreeBSD ports. > > Well, I checked. I would need to create an account on a python > site to send a 2-line patch. GitHub is hardly a "python site" (or rather CPython, as we talk about - yes, you need to do a PR at their GitHub repo, which is totally standard practice nowadays. https://devguide.python.org/ OK, if you need someone to do such a PR on your behalf, surely this can be arranged. > Given that I actually don't > program in python, that certainly seems to be an unreasonable > request from the python maintainers. If I were a Python maintainer I might have pointed out to you that IEEE-754 speaks about sinPi(), not sinpi(), and if you added sinPi() to libm, it would have been fine without a patch. (although this might be breaking naming taboos :-)) Dima > > BTW, I am a gfortran maintainer. gfortran is the only Fortran > compiler available for FreeBSD that actually implements most > of the Fortran standards. I've spent 15+ years making sure > gfortran works on FreeBSD and that changes to GCC don't cause > regression. This is first time I've seen your patch. AFAICT, > the file libgfortran/Makefile.am needs a patch, and then a > around of automake, autoconf, aclocal needs to be done. Just > need to figure out what
Submit of ceph12 upgrade
Hi, Looking for a port admin willing to take: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236004 Reason to sollicit, is to point to the svn move request to move from net/ceph to net/ceph12 This version has gone thru `portlint -A` and `poudriere testport` --WjW ___ 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: how to patch in port with NO_BUILD?
Sorry, first post was wrong.
Place the new file (I guess tuning-primer.sh) in the ${FILESDIR}.
And change do-install to
${CP} ${FILESDIR}/${PORTNAME}.sh
___
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: Config inconsistency for firefox-esr on rpi2
On Sun, Feb 24, 2019 at 11:12:47PM +0100, Dimitry Andric wrote: > > This actually means that you have to rebuild the *gtk3* port with > WAYLAND enabled. It could be worded a little better, maybe. :) > Indeed, it could be worded much better.8-\ There doesn't seem to be a port named gtk3, but there are quite a few with gtk3 in the name. The most likely candidates seem to be: /usr/ports/www/webkit2-gtk3 /usr/ports/www/webkit-gtk3 /usr/ports/www/vimb-gtk3 /usr/ports/devel/gwenhywfar-gtk3 /usr/ports/x11/keybinder-gtk3 /usr/ports/net/avahi-gtk3 /usr/ports/x11-toolkits/rubygem-gtk3 /usr/ports/x11-toolkits/wxgtk30 /usr/ports/x11-toolkits/gtk30 /usr/ports/x11-toolkits/wxgtk31 /usr/ports/audio/libcanberra-gtk3 My first guess would be /usr/ports/x11-toolkits/gtk30, is that right? Thanks for reading! bob prohaska > -Dimitry > ___ 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: how to patch in port with NO_BUILD?
Walter Schwarzenfeld wrote on 2019/02/24 16:02: Make a patch that includes the whole changed file and change the do-install target. In the meantime I came up with this https://bz-attachments.freebsd.org/attachment.cgi?id=202298 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235968 Miroslav Lachman ___ 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: FreeCAD 0.17 - is anyone using it?
## Torfinn Ingolfsen (tin...@gmail.com): > I looked into the build log, but it doesn't tell me anything new: > Coins is detected during configure / setup phase, and the suddenly > during compile / link it fails a step because Coin (specifically > -lCoin) can't be found The main question is why it detects Coin as "-lCoin", which can't be found by the linker without a matching "-L/usr/local/lib" (it's ok when Coin is linked as just "/usr/local/lib/libCoin.so"). There may be some hints in cmake's somewhat more verbose output in work/.build/CMakeFiles/CMakeOutput.log (and CMakeError.log). I would suspect something in your environment (LDFLAGS? picked up different linker between configure and build stages?) Anyways, I gave up on this (there are too many variables and I still cannot reproduce this in clean environments, whatever I do Coin is picked up as expected). As a possible workaround I forced "-L/usr/local/lib" into LDFLAGS - looks like the linker invocation should now work in your case. Regards, Christoph -- Spare Space ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sun, Feb 24, 2019 at 02:21:50PM +0100, Tijl Coosemans wrote: > On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote: > > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: > >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl > >> wrote: > >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: > On Fri, 22 Feb 2019, Tijl Coosemans wrote: > > If I were the lang/gcc maintainer this -rpath problem would be my > > number one priority. The current maintainer has never proposed > > any solutions and when I submit patches he always resists. I'm > > done wasting my time fighting him. > > I'm late to this discussion (not being a Fortran/Python user) but > is there any way to remove a recalcitrant maintainer? > >>> > >>> Can you explain what you mean? The maintainer of the lang/gcc > >>> ports is a long-time member of the GCC steering committee > >>> and a long-time maintainer of all gcc FreeBSD ports. There > >>> are very few FreeBSD users (like 3 of us) who have commit access > >>> to the gcc tree. Seems like a dubious idea to remove one of > >>> those 3. > >> > >> Given the amount of time unsuspecting and half-suspecting users wasted > >> on making Fortran code (often in form of a Python extension) working > >> on FreeBSD (e.g. I probably wasted weeks), time is high to do > >> something, e.g. commit the said patches---there is an agreement that > >> they are correct, right? > > > > Dima, gerald has always been very helpful in all my communications > > with him. Have you filed a PR for the fix? dropped him an email? > > > > I know we (gerald and ?? can't remember) tried a static lib change > > a few years ago. I believe it didn't work at the time due to missing > > symbols which we have since added. > > This cannot be entirely correct. I don't see what missing symbols this > would have been. I attached my patch to bug 208120 on 2017-02-09 and > you responded it was the best idea. mmel then discovered it didn't > entirely fix the problem on ARM where _Unwind_Backtrace has version > GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this > doesn't explain why this was done, but we'll have to make the same > change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is > part of the ABI). This isn't a blocker for the patch. > > I emailed the patch to gerald on 2017-02-21. He responded in the usual > way that he prefers patches submitted upstream and because I thought the > patch would not be accepted upstream he proposed an alternative solution > where gcc would always add -rpath on FreeBSD so you didn't have to > specify it on the command line. I responded this wouldn't fix the case > where clang was used as a linker (e.g. to combine fortran and c++ code > in one program) and that the FAQ on the gcc website said it was a bad > idea for other reasons. I also said upstream might accept my patch if > it was a configure option but that the gcc configure scripts are > complicated and I didn't know where to add it exactly. Then silence. > This is typical for all my conversations with him over the years so I > stopped caring. > I do find the above paragraph to be somewhat ironic. It seems that python importing Fortran compiled code runs into this problem. I have sent 3 or 4 patches to freebsd-ports@, freebsd-python, and created a PR to fix a conflict with the symbol sinpi (which I intend to add to libm), and I have been told to upstream my patch. Well, I checked. I would need to create an account on a python site to send a 2-line patch. Given that I actually don't program in python, that certainly seems to be an unreasonable request from the python maintainers. BTW, I am a gfortran maintainer. gfortran is the only Fortran compiler available for FreeBSD that actually implements most of the Fortran standards. I've spent 15+ years making sure gfortran works on FreeBSD and that changes to GCC don't cause regression. This is first time I've seen your patch. AFAICT, the file libgfortran/Makefile.am needs a patch, and then a around of automake, autoconf, aclocal needs to be done. Just need to figure out what needs to change and ensure that it does not break the rest of the computing world. -- Steve ___ 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: how to patch in port with NO_BUILD?
Make a patch that includes the whole changed file and change the do-install target. ___ 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: FreeCAD 0.17 && /lib//libgcc_s.so.1
On Sat, 23 Feb 2019 13:31:17 -0500 Diane Bruce wrote: > On Sat, Feb 23, 2019 at 10:52:03AM +, Dima Pasechnik wrote: >> On Sat, Feb 23, 2019 at 12:07 AM Steve Kargl >> wrote: >>> On Sat, Feb 23, 2019 at 09:19:01AM +1100, Dave Horsfall wrote: On Fri, 22 Feb 2019, Tijl Coosemans wrote: > If I were the lang/gcc maintainer this -rpath problem would be my > number one priority. The current maintainer has never proposed > any solutions and when I submit patches he always resists. I'm > done wasting my time fighting him. I'm late to this discussion (not being a Fortran/Python user) but is there any way to remove a recalcitrant maintainer? >>> >>> Can you explain what you mean? The maintainer of the lang/gcc >>> ports is a long-time member of the GCC steering committee >>> and a long-time maintainer of all gcc FreeBSD ports. There >>> are very few FreeBSD users (like 3 of us) who have commit access >>> to the gcc tree. Seems like a dubious idea to remove one of >>> those 3. >> >> Given the amount of time unsuspecting and half-suspecting users wasted >> on making Fortran code (often in form of a Python extension) working >> on FreeBSD (e.g. I probably wasted weeks), time is high to do >> something, e.g. commit the said patches---there is an agreement that >> they are correct, right? > > Dima, gerald has always been very helpful in all my communications > with him. Have you filed a PR for the fix? dropped him an email? > > I know we (gerald and ?? can't remember) tried a static lib change > a few years ago. I believe it didn't work at the time due to missing > symbols which we have since added. This cannot be entirely correct. I don't see what missing symbols this would have been. I attached my patch to bug 208120 on 2017-02-09 and you responded it was the best idea. mmel then discovered it didn't entirely fix the problem on ARM where _Unwind_Backtrace has version GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this doesn't explain why this was done, but we'll have to make the same change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is part of the ABI). This isn't a blocker for the patch. I emailed the patch to gerald on 2017-02-21. He responded in the usual way that he prefers patches submitted upstream and because I thought the patch would not be accepted upstream he proposed an alternative solution where gcc would always add -rpath on FreeBSD so you didn't have to specify it on the command line. I responded this wouldn't fix the case where clang was used as a linker (e.g. to combine fortran and c++ code in one program) and that the FAQ on the gcc website said it was a bad idea for other reasons. I also said upstream might accept my patch if it was a configure option but that the gcc configure scripts are complicated and I didn't know where to add it exactly. Then silence. This is typical for all my conversations with him over the years so I stopped caring. I'm not asking that he stops maintaining gcc. All I want is a little more pragmatism. User experience is more important than the patch being in the perfect shape to be submitted upstream. Be more practical instead of idealistic. The -rpath problem affects all users. Maintaining a patch in the ports tree affects just the maintainer. Make decisions based on weighing pros and cons. Ideals are just guidelines. If a situation is bad enough then committing an imperfect patch is better than doing nothing. I'm a user of gcc on FreeBSD. I'm not a gcc developer and I don't want to become one. If a maintainer wants patches to be in a perfect shape he's asking users to be developers. This doesn't work. Either the maintainer has to improve the patch himself or he has to play the role of liaison between the user and an upstream developer. If this takes too long and the situation is bad enough then he has to be willing to add the imperfect patch to the port. ___ 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"
Config inconsistency for firefox-esr on rpi2
In playing with www/firefox-esr on an rpi2 at r343555 using ports at 493769 make stops with ===> Configuring for firefox-esr-52.8.0,1 firefox-esr-52.8.0,1: Needs gtk3 with WAYLAND support enabled. *** Error code 1 despite both wayland and gtk3 being selected in the config dialog. I've retried several times, the error persists. Any suggestions? Thanks for reading, bob prohaska ___ 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"
