Re: git: f9568249d150 - main - Mark as BROKEN to unbreak INDEX

Am 12.04.21 um 10:33 schrieb Koichiro Iwao: > On Mon, Apr 12, 2021 at 10:18:20AM +0200, Antoine Brodin wrote: >> On Mon, Apr 12, 2021 at 10:05 AM Koichiro Iwao wrote: >>> >>> The branch main has been updated by meta: >>> >>> URL: >>>

Re: Python 2.7 removal outline

Am 24.03.21 um 23:11 schrieb Matthias Andree: > Am 24.03.21 um 22:50 schrieb Dan Mahoney (Ports): > >> There are packages for mailman3 but they’re incomplete and don’t > result in a working install the way the 2.x build does.  You also need > mysql, django, etc etc. > >

Re: Python 2.7 removal outline

Am 25.03.21 um 16:03 schrieb Baptiste Daroussin: > > I really think we should as a project move forward to that direction, it does > not even need to be driven by protmgr or even drive by any @freebsd.org > > I would argue here that it is even more interesting to go the gentoo way try > to >

Re: Python 2.7 removal outline

Am 24.03.21 um 22:50 schrieb Dan Mahoney (Ports): > There are packages for mailman3 but they’re incomplete and don’t result in a working install the way the 2.x build does.  You also need mysql, django, etc etc. Dan, please check if we already have bug reports on the mailman 3 issues and where

Re: Python 2.7 removal outline

Am 24.03.21 um 14:03 schrieb Rene Ladan: > Hi, > > below is an outline continuing the Python 2.7 cleanup: > > - No usage of lang/tauthon by the framework or any port, no excuses. > - lang/tauthon will be removed on 2021-06-23 as noticed in the port > itself, >   no excuses. Tauthon is not

Re: Python 2.7 removal outline

Am 24.03.21 um 22:48 schrieb Baptiste Daroussin: > On Wed, Mar 24, 2021 at 09:45:09PM +, Bob Eager wrote: >> On Wed, 24 Mar 2021 13:03:47 + >> Rene Ladan wrote: >> >>> - - mail/mailman is being replaced by clusteradm@ with mlmmj. You >>> can use `pkg lock` to stick with it after removal,

Re: nvidia-driver vs. mesa-libs

Am 20.09.20 um 21:38 schrieb Russell L. Carter: > On 2020-09-20 12:30, Rainer Hurling wrote: >> Hi Russel, >> >> There is a PR opened already: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249448 >> >> You could try the patch or wait until x11/nvidia-driver* is updated. >> >> HTH, >>

Re: Build error net/librsync (unable to find library -lpopt)

Am 16.05.20 um 17:13 schrieb Matthias Andree: > Am 16.05.20 um 16:05 schrieb Kurt Jaeger: >> Hi! >> >>> Problems building net/librsync, please advice :-) >>> >>> Looking forward to having duplicity installed! :) >> Please try to use poudriere

Re: Build error net/librsync (unable to find library -lpopt)

Am 16.05.20 um 16:05 schrieb Kurt Jaeger: > Hi! > >> Problems building net/librsync, please advice :-) >> >> Looking forward to having duplicity installed! :) > Please try to use poudriere to build it. I tested it, works fine. > Kurt, That's reaching too short. I can see that it build in

Re: FreeBSD Port: darktable-3.0.0_3 error update

Am 09.05.20 um 18:44 schrieb Matthias Andree: > Am 09.05.20 um 18:32 schrieb Adam Weinberger: >> On Sat, May 9, 2020 at 8:04 AM Matthias Andree >> wrote: >>> Am 09.05.20 um 12:33 schrieb Alex V. Petrov: >>> about graphics/darktable? >> FTR, the build

Re: FreeBSD Port: darktable-3.0.0_3 error update

Am 09.05.20 um 18:32 schrieb Adam Weinberger: > On Sat, May 9, 2020 at 8:04 AM Matthias Andree wrote: >> Am 09.05.20 um 12:33 schrieb Alex V. Petrov: >>> -- Looking for shmat >>> >>> >>> -- Looking for shmat - found >>> >>> >&

Re: FreeBSD Port: darktable-3.0.0_3 error update

Am 09.05.20 um 12:33 schrieb Alex V. Petrov: > -- Looking for shmat > > > -- Looking for shmat - found > > > -- Looking for IceConnectionNumber in ICE > > > -- Looking for IceConnectionNumber in ICE - found > > > -- building darktable-cmstest with colord support. nice. > > CMake Error at

Re: Building a port with debug symbols using poudriere

Am 06.05.20 um 18:05 schrieb Greg Rivers: > I need to build bind916 with debug symbols. According to the Makefile, > defining "WITH_DEBUG" will accomplish that. Where and how would I set that > inside a basic poudriere configuration? > Either in the port, or you can set

Re: reccomendations of conference / party audio video softwar

Am 03.05.20 um 02:51 schrieb Julian H. Stacey: > To: "https://lists.freebsd.org/mailman/listinfo/freebsd-ports; > > + BCC Bernhard & Astrid > > Jitsi Meet & Server now in FreeBSD ports/ www/jitsi-meet > net-im/jitsi-videobridge (Bernhard, might make NetBSD easier too ?) > >

Mk/Uses/gnome.mk INSTALLS_ICONS broken (was: Error testing port in poudriere caused by pkg not running deinstall scripts)

Am 01.05.20 um 19:49 schrieb Guido Falsi: > hi, > > While testing an update to xfce ports I have got this error in poudriere: > > =>> Checking for extra files and directories > =>> Error: Files or directories removed: > share/icons/hicolor/icon-theme.cache > > And could not find any cause for it.

Re: mail/mailman v3?

Am 28.04.20 um 22:02 schrieb Chris: > In sentiment I am inline with your thoughts as well. > Would it be a worthy project to create a mailman(2)-lts port? > I'd be fully up for helping, and or creating it myself. > There's a port that's a shim for py2.x-->py3.x called 2to3, or something > like

Re: mail/mailman v3?

[Dan, Kurt, this is a re-send of my message written 2020-04-24 with a different sender address.] Am 24.04.20 um 15:04 schrieb Kurt Jaeger: > Hi! > >> With mail/mailman being Python 2.7 (which is end-of-life), and mailman 3 >> being Python 3 compatible: >> >> Do you know of any plans to port

Re: mail/mailman v3?

Am 28.04.20 um 16:34 schrieb Dan Langille: > On Fri, Apr 24, 2020, at 9:32 AM, Dan Langille wrote: >>> On Apr 24, 2020, at 9:04 AM, Kurt Jaeger wrote: >>> >>> Hi! >>> With mail/mailman being Python 2.7 (which is end-of-life), and mailman 3 being Python 3 compatible: Do you

Re: Oddities possibly contributing to lang/gcc9 not building (amd64->aarch64 poudriere based cross build)

Am 28.04.20 um 04:57 schrieb Mark Millard via freebsd-ports: > It appears that quoting vs. option handling is not > working as the build expects or some odd file > names involved: > > > libtool: compile: mv -f "-fgnu-runtime.o" ".libs/NXConstStr.o" > mv: illegal option -- g > usage: mv [-f | -i |

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

Am 19.04.20 um 00:25 schrieb D'Arcy Cain: > On 2020-04-18 17:23, Matthias Andree wrote: >> Am 18.04.20 um 18:40 schrieb D'Arcy Cain: >>> On 2020-04-18 10:18, ajtiM via freebsd-ports wrote: >>>> BTW, I do not know why some apps need llvm60 still: >>> I really

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

Am 18.04.20 um 18:40 schrieb D'Arcy Cain: > On 2020-04-18 10:18, ajtiM via freebsd-ports wrote: >> BTW, I do not know why some apps need llvm60 still: > I really wish there was only one llvm. It's one of those things that > can take days to build. A minor upgrade can trigger multiple rebuilds. >

Re: openssl problem after 11 -> 12

Am 15.04.20 um 07:55 schrieb Per olof Ljungmark: > On 2020-04-15 00:39, Matthias Andree wrote: >> >>> Finally managed to figure it out, you need to tell the perl script >>> exactly what cipher to use, so I added to 'check_ilo2_health.pl': >>> --sslopts

Re: openssl problem after 11 -> 12

> Finally managed to figure it out, you need to tell the perl script > exactly what cipher to use, so I added to 'check_ilo2_health.pl': > --sslopts 'SSL_verify_mode => SSL_VERIFY_NONE, SSL_version => > "TLSv1_1", SSL_cipher_list => "EDH-RSA-DES-CBC3-SHA"' > > Works with openssl from ports. But

Re: amdgpu panics

Am 06.04.20 um 11:19 schrieb Grzegorz Junka: > > Sorry, what discrepancy do you mean? How does FreeBSD build the > drm-fbsd12.0-kmod on the FreeBSD pkg build server if not with > poudriere? Does it have any specific configuration I don't know about, > e.g. null mounted /usr/src to the host? The

Re: amdgpu panics

Am 06.04.20 um 09:37 schrieb Grzegorz Junka: > > On 06/04/2020 08:21, Hans Petter Selasky wrote: >>> >>> They don't match, and they can't. >>> >>> Files in /boot/modules have been installed by drm-fbsd12.0-kmod and >>> files in /boot/kernel have been installed by >>> FreeBSD-kernel-venus-12.1_3

Re: amdgpu panics

Sorry for following up myself, my apologies go John and Gregorz for botching my citations of their material in my previous mail. Sorry again, Matthias ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports

Re: amdgpu panics

Thank you John for the comprehensive explanation. It took me a while to go through all the details, then again to recompile the ports and try to reinstall all packages. > > What i discovered in the meantime is that it's not an isolated problem: > > >

Re: Packages not updated?

Am 21.10.18 um 23:19 schrieb Kevin P. Neal: > On Sun, Oct 21, 2018 at 08:45:55PM +, Lorenzo Salvadore via freebsd-ports > wrote: >>> So I just saw another post on this list that mentioned the "pkg version >>> -vL=" >>> command. Now, I've got a /usr/ports tree used by poudriere and run on the

OpenVPN produces garbage on TAP on -current

alk about the port. Best regards, -- Matthias Andree ___ 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: Qpopper and openssl on FreeBSD 11.x

Am 23.03.2018 um 23:48 schrieb Doug Hardie: > >> Use SSLv23_server_method(), and use code to block out SSLv2 + SSLv3 on >> those systems that still support them - which depends on the >> OpenSSL/LibreSSL version, however: >> Older OpenSSL and LibreSSL require SSL_OP_NO_SSLv3 and SSL_OP_NO_SSLv2 >>

Re: Qpopper and openssl on FreeBSD 11.x

Am 17.02.2018 um 04:22 schrieb Doug Hardie: > I have encountered an interesting situation while trying to resolve a PR on > qpopper. I am unable to build qpopper on 11.1 (and probably 11.0) because > the openssl function SSLv3_server_method has been removed. I can see where > the SSLv2

Re: Committer needed for new port (net/nuster)

Am 21.03.2018 um 00:39 schrieb Felix Hanley: > There is a new port (net/nuster) awaiting approval at > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225721 If there are no > suggestions could someone commit it please. Committed (r465301). ___

Re: committer needed for new port sysutils/tmux23

yuri@ has committed this, thanks. ___ 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: Mailman has mismatched checksums

Am January 16, 2018 9:00:09 PM UTC schrieb Dave Horsfall : >When trying to get Mailman going (and seeing what looked like several >updates in quick succession), I completely cleaned it out, waited a bit > >for any more updates, installed the package, waited a bit for any more

Re: Procmail got updated!

Am 23.12.2017 um 08:12 schrieb Kevin Oberman: > > So, why does Eugene's question have no relevance to the procmail > case?  Could you please explain? Because I am not willing to discuss generics when we have a specific case of port at hand. The attempted generalization distracts from that, and I

Re: Procmail got updated!

Am 22.12.2017 um 07:09 schrieb Eugene Grosbein: > 22.12.2017 9:50, Matthias Andree пишет: >> Am 21.12.2017 um 10:16 schrieb Eugene Grosbein: >> >>> So, you demand we stop shipping any unmaintained software with our Ports & >>> Packages? >>> Absence of

Re: Procmail got updated!

Am 21.12.2017 um 10:16 schrieb Eugene Grosbein: > So, you demand we stop shipping any unmaintained software with our Ports & > Packages? > Absence of CVEs means nothing and almost any non-trivial software has bugs > (axiom). Eugene, these are attempts to distract from the argument, or to mount

Re: Procmail got updated!

Am 21.12.2017 um 06:07 schrieb Adam Weinberger: >> On 20 Dec, 2017, at 17:19, Matthias Andree <matthias.and...@gmx.de> >> wrote: >> >> Am 20.12.2017 um 06:40 schrieb Eugene Grosbein: >>> On 20.12.2017 01:03, Matthias Andree wrote: >>> >>

Re: Procmail got updated!

Am 20.12.2017 um 06:40 schrieb Eugene Grosbein: > On 20.12.2017 01:03, Matthias Andree wrote: > >> Dear Ted, Eugene, > [skip] > > What happened with old good "Tools, not policy" thing? > > It's simpler than that, no policy involved. The tool had a hollo

Re: Procmail got updated!

Am 19.12.2017 um 01:30 schrieb Ted Hatfield: > > > On Mon, 18 Dec 2017, Matthias Andree wrote: > >> Am 18.12.2017 um 00:17 schrieb Dave Horsfall: >>> Doing my regular update, and... >>> >>>     Upgrading procmail from 3.22_9 to 3.22_10... >>&g

Re: Procmail got updated!

Am 18.12.2017 um 00:17 schrieb Dave Horsfall: > Doing my regular update, and... > >     Upgrading procmail from 3.22_9 to 3.22_10... > > Good grief; who's the masochist who volunteered to support this > obscure insecure and hitherto-unsupported scripting language? >

Re: Bogofilter contrib scripts treated as docs

Am 06.11.2017 um 20:19 schrieb RW: > > I just noticed that the bogofilter perl and shell scripts from the contrib > directory (see below) only get installed if bogofilter is built with the > DOCS option. > > > .for i in bfproxy.pl bogofilter-milter.pl bogo.R bogofilter-qfe.sh \ >

Re: security/openvpn23 tarball size mismatch

Am 16.05.2017 um 14:00 schrieb Renato Botelho: > On 16/05/17 08:54, Renato Botelho wrote: >> Hello Mathias, >> >> I was trying to get openvpn23 installed from quarterly branch and got >> the following error: >> >> root@buildbot1:/usr/local/poudriere/ports/pfSense_v2_3/security/openvpn23 >> # make

Re: Bug in Mailman version 2.1.23

Am 25.04.2017 um 09:30 schrieb Geovani B. R.: > I found the problem, the following kernel variables can't be turned on: > > security.bsd.hardlink_check_gid (default 0). > security.bsd.hardlink_check_uid (default 0) I don't see a problem even if setting these to 1 and modifying a test list

Re: Bug in Mailman version 2.1.23

Am 25.04.2017 um 09:30 schrieb Geovani B. R.: > > I found the problem, the following kernel variables can't be turned on: > > security.bsd.hardlink_check_gid (default 0). > security.bsd.hardlink_check_uid (default 0). > Thanks for the feedback and heads-up.

Re: Bug in Mailman version 2.1.23

Am 25. April 2017 07:28:16 MESZ schrieb "Geovani B. R." : >On FreeBSD 10.3-RELEASE-p7 > >Mailman 2.1.23_1 + Postfix 3.1.4,1 > > >Mailman returns me this error when trying to manage a list after login: > > > >Bug in Mailman version 2.1.23 > >We're sorry, we hit a bug! > >Please

Re: archivers/lzo2 will not install

Am 24.03.2017 um 13:19 schrieb Matthias Andree: > > Fixed in 2.10_1, now available by SVN, and shortly via portsnap. I > believe there might be a bug in the ports infrastructure but haven't had > time to look, so I fixed it locally in the ports. I'll take back the part on infrastr

Re: archivers/lzo2 will not install

Am 24.03.2017 um 12:50 schrieb Nikos Kastanas: > Hello, > > My machine is a FreeBSD 11.0-RELEASE-p8 GENERIC amd64 box. > > I had archivers/lzo2 2.09 installed and after trying to update it to 2.10 > portmaster removed the previous version and failed to install the new one > with the following

Re: The future of portmaster

Am 19.02.2017 um 20:21 schrieb Baho Utot: > How about I will use what _I_ find necessary. BTW I am using Synth. Oh, absolutely. portmaster just doesn't do what you find necessary today. ___ freebsd-ports@freebsd.org mailing list

Re: The future of portmaster

Am 17.02.2017 um 08:37 schrieb abi: > From my point of view, jails are overkill. Chroot should be enough and > it would be nice if portmaster starts building in clean environment. Please use poudriere or some other tool instead, there are some that were designed for clean-room rebuilds, which

Re: The future of portmaster

Am 16.02.2017 um 21:48 schrieb Baho Utot: > Having built and packaged linux from scratch using the rpm package > manager, I came to find that if one is building packages to be used on > multiple machines, one needs to build each package in a chroot > environment or the package could inherit things

Re: The future of portmaster

Am 17.02.2017 um 09:25 schrieb Matthieu Volat: > Just dropping privileges to a dedicated user for building would be a > big step, but that's more a port feature (openbsd's ports do that, if > I'm not wrong). With a distfiles directory writable to the unprivileged user doing the build, and sudo as

Re: Question on upgrading ports after 9.3->10.3

Am 12.02.2017 um 04:05 schrieb Dave Horsfall: > Me again :-) I finally got around to following the notes that David > Wolfskill kindly provided (thanks!) and apart from some oddity about > "httpd" requiring a missing "libdb-4.2.so.2" (which will get rebuilt > anyway), I'm a bit wary of this:

Re: svn commit: r432323 - branches/2017Q1/print/texlive-texmf

Am 28.01.2017 um 14:28 schrieb Jan Beich: > Jan Beich writes: > >> Author: jbeich >> Date: Tue Jan 24 11:48:07 2017 >> New Revision: 432323 >> URL: https://svnweb.freebsd.org/changeset/ports/432323 >> >> Log: >> MFH: r432322 >> >> print/texlive-texmf: unbreak on aarch64

Re: 11.0-RC1 unsupported by ports?

Am 25.01.2017 um 11:39 schrieb Mathieu Arnold: > Buildworld on a raspberry isn't fun - if it works at all. >> Even if you crossbuild and just copy the binaries, the wear of >> MicroSD cards isn't something you want to test unless you really >> have to. > If you have other computers running

Re: Averia font port

Am 11.02.2017 um 20:11 schrieb alfix86: > Hi all! > This is my first email. > > I wish to create a port for Averia GWF font family [1], > it comes with 3 .zip > > - AveriaGWF.zip (has 7 .ttf) > - AveriaSansGWF.zip (has 6 .ttf) > - AveriaSerifGWF.zip (has 6.ttf) > > Should I create 3 ports or

Re: svn commit: r432796 - in head/graphics: rawtherapee rawtherapee-devel

Am 04.02.2017 um 23:47 schrieb John Marino: > > Anyway ... > I don't discourage that coupling OPSYS with OSVERSION is documented. I > think the original idea is that the guideline would "ease in". maybe > we're already there because many people are following it on their own > now. Yes, but what

Re: svn commit: r432796 - in head/graphics: rawtherapee rawtherapee-devel

Am 03.02.2017 um 22:03 schrieb John Marino: > > So please, if you can, respect this guideline regardless if it's > documented, and if not, at least let others make the correction. I'd > like to take the opportunity to thank all the FreeBSD committers that > make the effort to guard OSVERSION. It

Re: svn commit: r432796 - in head/graphics: rawtherapee rawtherapee-devel

Am 29.01.2017 um 20:22 schrieb John Marino: > Author: marino > Date: Sun Jan 29 19:22:47 2017 > New Revision: 432796 > URL: https://svnweb.freebsd.org/changeset/ports/432796 > > Log: > graphics/rawtherapee(-devel): Fix OSVERSION, use with OPSYS > > The OSVERSION for FreeBSD 10.3 is

Re: Pan core dumps on start

Am 08.01.2017 um 23:19 schrieb Dave: > Does this mean 10.3 is a libc++ system and 9.3 isn't? Or does it mean I have > stuff left over from the 9.3 system that should now be removed? Dave, the former. I am not aware of the details surrounding the Pan news reader, but the former is true: FreeBSD

Re: CFT: OpenVPN 2.4 port update (upstream rc2) for FreeBSD, v2 re-adds TUNNELBLICK option

Am 16.12.2016 um 21:19 schrieb Matthias Andree: > Greetings, > > I've put up a new OpenVPN 2.4-rc2 port for FreeBSD for testing. > > Get it from <https://people.freebsd.org/~mandree/openvpn-2.4_rc2-v1.tar.xz>. > > This time, it also contains the openvpn23 a

CFT: OpenVPN 2.4 port update (upstream rc2) for FreeBSD

Greetings, I've put up a new OpenVPN 2.4-rc2 port for FreeBSD for testing. Get it from . This time, it also contains the openvpn23 and openvpn23-polarssl ports (as modified copies of what we have now) that I plan to keep for the

CFT: OpenVPN 2.4 port update for FreeBSD

Greetings, I've put up an OpenVPN 2.4-rc1 port for FreeBSD up for testing. Get it from https://people.freebsd.org/~mandree/openvpn-2.4.r1-v1.tar.xz Or review the diff at https://reviews.freebsd.org/D8813 Cheers, Matthias signature.asc Description: OpenPGP digital signature

Re: No port should need root for make fetch

Am 13.12.2016 um 23:28 schrieb Julian H. Stacey: > I'm just building a stockpile of local distfiles for use later on a mass > build. > I'm quite happy to build as root. > > [...] > Please stop guessing & assuming wrongly, > try as normal user what I reported in 3rd line of my first post >

Re: No port should need root for make fetch

Am 13.12.2016 um 22:35 schrieb Julian H. Stacey: > >> How is that a problem of "some" ports? All ports require root for "make >> fetch" > No they dont. Given that, then "none do". I'll do what what you omitted in your blind rage, I've dug the important detail up for you, which was the first

Re: No port should need root for make fetch

Am 13.12.2016 um 21:32 schrieb Julian H. Stacey: > Hi ports@ > IMO No port should need root for > cd /usr/ports; make -i fetch > The first one that broke for me was databases/mysql-q4m > (OK might be others before, but I have DUDS = >arabic biology chinese hebrew hungarian japanese

Re: Jive prejudices

Am 23.10.2016 um 18:49 schrieb Louis Epstein: > > On Sun, 23 Oct 2016, Alphons van Werven wrote: > >> Louis Epstein wrote: >> >>> In any event,portmaster -a -i updates now abort because misc/jive is >>> detected on my system. >>> >>> This goes beyond "We will no longer provide this application" to

Re: Portmaster still be dissin' jive,bros

Am 24.10.2016 um 21:42 schrieb Louis Epstein: > The technical issue persists that I can not update via portmaster because > I installed misc/jive out of sheer curiosity over its unprecedented MOVED > message. workarounds wirth trying - but untested (alternative): 1. pkg delete -fy jive 2. run

Re: Alternatives to rsync

Am 17.10.2016 um 00:46 schrieb Greg 'groggy' Lehey: > On Friday, 14 October 2016 at 8:01:51 +0300, reko.turja--- via freebsd-ports > wrote: >> Greg, I've actually put some thought in making a local port of >> rsync2. I've done some research on it and it seems to be fairly >> usable and security

Re: Alternatives to rsync

Am 13.10.2016 um 07:20 schrieb Peter Beckman: > 2. Why is GPL3 out of the question? Is the user going to resell the > device >as a service? If the user is simply "using" the software, no > disclosure >of other software is necessary. Only if your user is attempting to > "make >money"

Re: Google Code as an upstream is gone

Am 01.10.2016 um 10:03 schrieb Grzegorz Junka: > The fact that some source is hosted at a provider that doesn't close > their services, like Google does (aka GitHub), doesn't make it > "maintained". Is that your definition of "maintained", that the "the > code could be updated if needed"? If yes,

Re: ca_root_nss compile failure

Am 01.10.2016 um 03:43 schrieb Carlos J. Puga Medina: > Hi Matthias, > >> Am 28.09.2016 um 10:36 schrieb Carlos J. Puga Medina: > Sorry, I >> wasn't clear enough in my first reply: I set ssl=3Dopenssl as >> default version in make.conf to pick openssl from ports instead >> from base because

Re: ca_root_nss compile failure

Am 28.09.2016 um 10:36 schrieb Carlos J. Puga Medina: > Sorry, I wasn't clear enough in my first reply: I set ssl=openssl as > default version in make.conf to pick openssl from ports instead from > base because the openssl port was previously updated and fixed. > Later I updated my system with all

Re: ca_root_nss compile failure

Am 28.09.2016 um 01:51 schrieb George Mitchell: > Before I file a PR, does this failure look familiar to anyone? > > portmaster -BDg security/ca_root_nss > ===> Building for ca_root_nss-3.26 > ## Untrusted certificates omitted from this bundle: 20 > openssl x509 failed with exit code 139 at >

Re: Problems with out libgcc_s.so in base

Am 18.08.2016 um 14:48 schrieb Dimitry Andric: > For example, on one of my systems, I now have these: > > /usr/local/lib/gcc47/libgcc_s.so.1 > /usr/local/lib/gcc48/libgcc_s.so.1 > /usr/local/lib/gcc49/libgcc_s.so.1 > /usr/local/lib/gcc5/libgcc_s.so.1 > /usr/local/lib/gcc6/libgcc_s.so.1 >

Re: security/openvpn build failure on 12-CURRENT/amd64

Hi Ngie, Quite possibly an incompatibility between the port or the upstream software build/self-test rigging with the rather new FreeBSD 12-CURRENT. Since I do not have the latter, I am soliciting patches (through Bugzilla). I am staring at

Re: security/openvpn build failure on 12-CURRENT/amd64

Hi Shawn, The compilation attempt was done on an invalid configuration and has zero relevance whatsoever. As the log says: !!! Jail is newer than host. (Jail: 121, Host: 1100116) !!! !!! This is not supported. !!! !!! Host kernel must be same or newer than jail. !!! !!! Expect build

Re: blanket portmgr approval vs. non-fixing changes

Am 28.06.2016 um 11:17 schrieb Baptiste Daroussin: > What you are asking is part of the blanket in particular when changing things > in > individual ports, we expect committers to have a look at pending PR (yes I > know > I have been guilty of individual port change without sometime checking

Re: blanket portmgr approval vs. non-fixing changes

Am 27.06.2016 um 18:07 schrieb Cy Schubert: > Mathias, Cy, Mind the double t please. > I'm surprised at your position. I recall a commit you made to one of my > ports a few years ago, to which I objected. Your position now is a complete > reversal of your arguments then. Quite possible.

Re: blanket portmgr approval vs. non-fixing changes

Am 27.06.2016 um 12:02 schrieb Guido Falsi: >> 2. What I was meaning to state was that (and I'll not pick at the >> kind soul who has modernized the port) we should only apply the >> blanket approval if ports have fallen into disrepair. > > I'd say that it's a matter of urgency for the change.

blanket portmgr approval vs. non-fixing changes (was: svn commit: r417590 - in head/databases/db6: . files and 417595 (revert))

[Sorry for this re-send, I feel we need to re-send thisto ports@ so the discussion goes to a public and archived list.] Am 27.06.2016 um 10:16 schrieb Mathieu Arnold: > > > +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo > wrote: > | 2016-06-27 16:02 GMT+08:00 Mathieu

Re: bug 204175 ready to commit

Am 26.05.2016 um 17:08 schrieb Hiroo Ono (小野寛生): > Hello, > > bug 204175 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204175 > has a patch to workaround the build error on i386 > and no objection from the maintainer. Please commit it. > > Thank you in advance. Committed as new revision:

Re: Why clang++37 behaves differently on 9.3 and 10.3?

Am 12.05.2016 um 19:59 schrieb Dimitry Andric: > On 12 May 2016, at 13:33, Yuri wrote: >> >> clang++37 compiles this simple program fine on 10.3, but fails on 9.3. >> >> Why does it behave differently on different OS versions? >> >> It looks like it ignores -std=c++11 on 9.3. > > You cannot

Re: Failure compiling java/openjdk8

Am 23.04.2016 um 12:02 schrieb Willem Offermans: > Dear FreeBSD friends, > > In my attempt to juvenile an old FreeBSD beast, I encountered another > hurdle: a failure compiling java/openjdk8 > > > gmake[4]: Leaving directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make' > gmake[4]: Entering

Re: pkg: fail to install packages from local file repository targeted via file:///

Am 04.02.2016 um 11:29 schrieb O. Hartmann: > On Tue, 02 Feb 2016 18:34:01 +0100 > Patrick Hess wrote: > >> O. Hartmann wrote: >>> file:///pool/poudriere/data/packages/head-amd64-head-default/meta.txz: No >>> such file or directory repository myrepo has no meta file, using

Re: gnomehier

Am 26.12.2014 um 20:22 schrieb Jos Chrispijn: With portmanager I got this line: === The misc/gnomehier port has been deleted: Not needed anymore But I still have it active. How can I remove it when the port itself is nog existing anymore as gnomehier deinstall won't work anymore as

How to handle port merges on upgrade for pkg/portmaster/portupgrade/port... (was: Dealing with a port being merged into another)

Am 23.10.2014 um 12:01 schrieb Raphael Kubo da Costa: Hi everyone, One of the changes we (kde@) have made in the upcoming Qt 5.3.2 update is merging devel/qt5-qmldevtools into lang/qt5-qml. I'd now like to know what needs to be done to make it easy to everyone to upgrade their ports. By

Re: Reducing the size of the ports tree (brainstorm v2)

Am 03.11.2014 um 21:24 schrieb Tijl Coosemans: Other tools won't change anything. It's the file system that would have to change which is not going to happen. When the ports tree was created disks were much smaller and file systems were better (still not good) at storing small files. Today

Re: Reducing the size of the ports tree (brainstorm v2)

Am 31.10.2014 um 19:56 schrieb Baptiste Daroussin: Hi all, tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for free, we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files

Re: Reducing the size of the ports tree (brainstorm v2)

Am 02.11.2014 um 19:50 schrieb Tijl Coosemans: The reason I looked into this is because many subversion operations are slow on the ports tree. For me it's about saving time there and not so much about saving disk space. Which is exactly my point of using inferior tools for the job.

Re: www/dansguardian revival?

Am 21.10.2014 um 01:08 schrieb Nick Rogers: Hello, I recently learned that the www/dansguardian port was deprecated due to its dependency on the old www/squid port (squid 2.7). Is there any way this port can be revived? I've been using it for years with great success against newer versions

Re: Port does not display pkg-message while installing from remote repository

Am 29.09.2014 um 09:18 schrieb Alexander Moisseev: Hi, sysutils/backuppc displays pkg-message if installing from locally stored package file, but it does not display pkg-message while installing from remote repository. # pkg install /var/cache/pkg/backuppc-3.3.0_7.txz shows pkg-message

Re: lack of framework and pkg documentation (was: svn commit: r369281 - in head/dns: dnsmasq dnsmasq-devel)

Am 25.09.2014 um 20:33 schrieb Bryan Drewery: On 9/25/2014 1:27 PM, Matthias Andree wrote: Author: mandree Date: Thu Sep 25 18:27:56 2014 New Revision: 369281 URL: http://svnweb.freebsd.org/changeset/ports/369281 QAT: https://qat.redports.org/buildarchive/r369281/ Log: Update to new

Re: lack of framework and pkg documentation

Am 26.09.2014 um 09:37 schrieb Mathieu Arnold: | The other issue I'm having with that is that the technical side of | Keywords/* - it's not documented or visible how these are actually used, | grep -ri keywords Mk comes up mostly empty, there's only the definition | - and it's a leftover from

Re: lack of framework and pkg documentation

Am 26.09.2014 um 10:51 schrieb Mathieu Arnold: +--On 26 septembre 2014 09:03:01 +0200 Matthias Andree matthias.and...@gmx.de wrote: | Now if you would read my post before brushing it off, that would be | greatly appreciated. Well, I read all of it, the problem is that you are looking

Re: Need help compiling use of std::vector

Am 24.09.2014 um 17:04 schrieb Shane Ambler: I am trying to compile the new version of a port I maintain and have trouble related to std::vector. The code producing the error can be boiled down to the following test case, which compiles as 64bit but fails as 32bit. #include stdlib.h

Re: dbtool compile error

Am 19.09.2014 um 19:10 schrieb Yves Guérin: Dear, Before filing a PR I go thte following error: uname -a: FreeBSD beastie 9.3-RELEASE-p1 FreeBSD 9.3-RELEASE-p1 #0: Tue Sep 16 14:35:04 EDT 2014 root@beastie:/usr/obj/usr/src/sys/PATRIOTEBSD43 i386 Intel(R) Pentium(R) 4 CPU 2.66GHz

Re: pkgng: How to prevent autoremoval during pkg delete ?

Am 15.09.2014 um 01:07 schrieb Marco Steinbach: Hi. Is there a way to tell pkg delete to just remove the package(s) listed on the command line, instead of automatically removing depending packages ? Try: pkg delete -f somepackage ___

Re: svn commit: r368031 - head/mail/thunderbird

Am 12.09.2014 um 17:48 schrieb Baptiste Daroussin: Great so it is now broken for anyone using gcc from ports on system without libstdc++.so.6... Sorry for that. The actual issue is that if you have any port without proper dependencies earlier in the from-source upgrade list than thunderbird

Re: RedPorts down?

Am 10.09.2014 um 18:44 schrieb Michael Gmelin: it seems to ignore the portrevision in the Makefile (it shows an older revision in the build view and log output suggests it's building the old version as well). So I'm not entirely sure which version it actually built. The one thing I figured

  1   2   3   4   5   6   >