llvm37 python3 problem
Hello @ports i recently created an issue because everybody wants to use LLVM/Clang 3.7 on FreeBSD with Python3(.4) as a default could not build it due to some python2 scripts not converted. Here is the issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203618 Can someone look at this issue and maybe fix it ? I know that clang 3.7 will be included in FreeBSD 11, maybe the issue was already solved in head. Thanks ! -- Best regards, Loïc BLOT, UNIX systems, security and network engineer http://www.unix-experience.fr ___ 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: Working of "pkg audit "
On Wed, Oct 07, 2015 at 04:02:25PM -1000, p...@pair.com wrote: > (Sent to -questions@ on Oct 3 but hadn't got any reply, so sending > to @ports now. Also, situation below is before www/firefox was > updated to 41.0.) > > I want to know if running "pkg audit" makes any sense for a port > installed that has not been updated officially yet. Also, is it > possible to supplement the vuxml catalog for such ports installed? > > Firefox 39 or 40 had been installed from ports. I got tired of > seeing package being vulnerable on every ports tree update process > that rebuilds "security/vuxml". As the "www/firefox" port has not > been updated yet, so I fetched source of firefox 41.0.1; updated > distinfo; installed (after rebuilding databases/sqlite3 with DBSTAT > option & moving out "files/patch-bug702179" out of "files"). > > Now I see vulnerability warnings going back to 2004, which are > just useless & rather amusing. At least the installed firefox is not > vulnerable any more (yet). > > Apparently per pkg-version > > # pkg version -t 41.0.1 41.0,1 > < The PORTEPOCH here (the ,1) will always make the second version newer than the first. If you do any local updates then keep the PORTEPOCH and it would work as intended. If you do a local update, don't forget the most import step... the patch to Bugzilla of course. ___ 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"
Working of "pkg audit "
(Sent to -questions@ on Oct 3 but hadn't got any reply, so sending to @ports now. Also, situation below is before www/firefox was updated to 41.0.) I want to know if running "pkg audit" makes any sense for a port installed that has not been updated officially yet. Also, is it possible to supplement the vuxml catalog for such ports installed? Firefox 39 or 40 had been installed from ports. I got tired of seeing package being vulnerable on every ports tree update process that rebuilds "security/vuxml". As the "www/firefox" port has not been updated yet, so I fetched source of firefox 41.0.1; updated distinfo; installed (after rebuilding databases/sqlite3 with DBSTAT option & moving out "files/patch-bug702179" out of "files"). Now I see vulnerability warnings going back to 2004, which are just useless & rather amusing. At least the installed firefox is not vulnerable any more (yet). Apparently per pkg-version # pkg version -t 41.0.1 41.0,1 < ... & ... https://vuxml.freebsd.org/freebsd/2d56c7f4-b354-428f-8f48-38150c607a05.html ... 41.0.1 is still vulnerable. But according to ... https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ ... there are no outstanding vulnerabilities. Now I am confused. -- ___ 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: Firefox 41.1 fails build on Current AMD64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/06/2015 21:19, Manfred Antar wrote: > >> On Oct 6, 2015, at 5:33 PM, Walter Schwarzenfeld >> wrote: >> >> Found this: https://bugzilla.mozilla.org/show_bug.cgi?id=1181382 >> > Yes ... The fix was committed. Thanks! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWFVf8AAoJEHyflib82/FGP2cH/3LfhhclicM5dbNPnnOoH8MO KUet1CoiqL7c5vmD0eoyat38k5Kx95G81auzgwg7mRElfjzt5lH5C8C1qOiGITru qJAfdDX2VVjQwGT3nUs2aNgdbjoIRQQw5/2lv9Fz1ZIFn4Mhg05Yv4ICAFJs8Med 9jEGeQrBfsYBVjor/L6Ux7u4S49QvAX+CjWg+if5wjfLGhOi3QMGWto+KnxQ8OKU G8WsYjQ6OhUQXqHlKQod5O0henfpxKGWrccmcP8J/xV3OkfktDwlsuv/zi25QIH1 98rdoNOxugVFvN0h49Q+ZZbpWqS81haIPWyuaR09pzO1fjr4Ia9oCJoxCDOu84E= =8vV5 -END PGP SIGNATURE- ___ 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: Firefox + SeaMonkey (gecko browsers) instant crash on some web pages
I have got the same problem. Opening mapy.cz in FF, creates a core dump . Any idea what is the cause and the solution? The same site works fine in FF under Linux Mint and Windows 7. I am using FF 40.0.3 on FREEBSD 10.1-RELEASE. ___ 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: change ports default work directory prefix
Dirk Engling writes: > Today in EuroBSDCon's jail working group we discussed changing the > default for WRKDIRPREFIX to /usr/obj/ports. This has the advantage of > being able to share the ports tree between host system and jails. > Another plus is that cleaning all work directories is much faster than a > recursive make clean. I set WRKDIRPREFIX in all cases (including the "real" system) for these reasons. I don't use /usr/obj/ports, but /usr/obj is the best place that exists in hier(7). > With the current default, exposing the ports tree to jails potentially > leaks information about installed programs, configured options or host > specific generated secrets (thinking of LocalSettings.php). I don't understand why any of these would be concerns. If there are work directories littering the tree, that could leak some information, and the distfiles set could leak some information, but not much and not reliably. > On the down side, developers can't by default just copy the port, hack > away and be sure to only modify files in their respective home directories. When I do that, I'm running under my own UID, so I don't have permission to write into /usr/obj. If I forget to set WRKDIRPREFIX, I'll get a quick reminder. I don't think it's a problem. > bapt@ asked me to discuss this here, also looking for potential other > pitfalls I have not thought about. People with unusual partitioning schemes might see some surprising effects, but I think it's unlikely to break anything even in those cases, and they may well set WRKDIRPREFIX already. There are no significant downsides, and although I think the benefits will turn out to mostly go to types of people who already set WRKDIRPREFIX today, they are real. In short: can't hurt, will help a bit, go ahead. Be well. ___ 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: they all die (was: Re: ZoneMinder /zmu dies on FreeBSD 10.2)
Hi! > I do not mean replace Zoneminder as such; I just try to use ffserver > temporarily until that port gets running. > So I am still interested and wish help to fix that. Yes, I got that, I'm only very busy with $daywork. I'll get back to the topic as soon as I find the time. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: they all die (was: Re: ZoneMinder /zmu dies on FreeBSD 10.2)
Hi Kurt, Probably I was not quite correct wriring. I do not mean replace Zoneminder as such; I just try to use ffserver temporarily until that port gets running. So I am still interested and wish help to fix that. Please tell if you need access to that computer for tests; as for now I cannot help with anything else as my programmer skills are not good enough to debug those thread-concerned errors. You wrote on 2015-10-05, 21:41:38: > Hi! >> Just thought of other binaries from Zoneminder, i.e. >> >> zma >> zmc >> zmf >> zms >> zms >> zmstreamer >> >> They all get signal 11 when I try to run them. > Do you have core dumps and backtraces ? Can you put them up somewhere ? >> Looks like there is one general error and probably a simple one. > Hmm, I'm almost done getting the port to build, but it will take a bit > more time. >> .. And looks like I have to use some alternative for those functions, >> getting short of time. :( > Uh, porting-while-short-on-time is difficult 8-} -- Best regards, Violet mailto:vio...@sm.msk.ru ___ 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: change ports default work directory prefix
Hi! > Today in EuroBSDCon's jail working group we discussed changing the > default for WRKDIRPREFIX to /usr/obj/ports. This has the advantage of > being able to share the ports tree between host system and jails. > Another plus is that cleaning all work directories is much faster than a > recursive make clean. portsclean -C runs really fast and does not use a recursive make clean. It's part of ports-mgmt/portupgrade-devel. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: change ports default work directory prefix
Today in EuroBSDCon's jail working group we discussed changing the default for WRKDIRPREFIX to /usr/obj/ports. This has the advantage of being able to share the ports tree between host system and jails. Another plus is that cleaning all work directories is much faster than a recursive make clean. Speeding up make clean would be nice. Otherwise i've just use a simple find, because its much faster than the recursive make clean. With the current default, exposing the ports tree to jails potentially leaks information about installed programs, configured options or host specific generated secrets (thinking of LocalSettings.php). The options are stored under /var/db/ports; therefore this should be saved. But i believe i did not understand the change you propose. What is the idea behind this? Do you want the portstree to be sharable with the jails? In this case the distfiles must be considered. Sometime it is very nice to share them between the jails. Sometimes i do not want this. Also the options should be discussed. Do i want them exposed to the tree? In my history there were cases i want this and sometimes not. Next thought: why should i share the portstree to my jail? Obviously to save time/space if every jail use the same tree. If this is the case. Enabling the portstree exposing optionally to a jail would be very fine. Therefore i support changing WRKDIRPREFIX. But we need to take care of the distfiles and the options. distfiles should move out of the portstree - otherwise the tree must be writable to the jails and this can case different sideeffects; for example when building the same port at the same time in different jails. On the down side, developers can't by default just copy the port, hack away and be sure to only modify files in their respective home directories. Why? When i'm in a jail and build a port, whould the WRKDIRPREFIX not apply within the jail? Therefore it should be save to build a port (even with different options) in host or jail. Or did i miss something? bapt@ asked me to discuss this here, also looking for potential other pitfalls I have not thought about. Is there a documentation about the thoughts and pitfalls you already found? This would be very helpful for a discussion. Otherwise its more like a guessing. ;) Greetings, Torsten ___ 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"
