FreeBSD:13:aarch64 packages are outdated
I checked packages for www/authelia, www/adguardhome, science/siesta and they are 2+ weeks outdated for thus architecture. Yuri ___ 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"
[TIP] Outdated ports can be looked up by maintainer through Repology
There is a way to find outdated ports for specific maintainers by running a query like this: https://repology.org/projects/?search==po...@freebsd.org=freebsd=on (replace the e-mail with maintainer's e-mail) It compares FreeBSD port versions to other distros and shows, with some false positives, if the same package is more updated in other distros. This is in addition to the Portscout query https://portscout.freebsd.org/po...@freebsd.org.html that returns results based on its attempts to discover new versions by version guessing. Yuri ___ 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: MAIL ADMINISTRATIVE SERVICE CENTER
Dave Horsfall wrote: > On Tue, 16 Feb 2021, Yuri Pankov wrote: > >>> As this came from freebsd.org, were they trying to shout something or >>> do they have a compromised server? >> >> It's obvious it did NOT come from freebsd.org once you check the headers: > > Really? Here are my headers: Really. > Return-Path: > Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) > by aneurin.horsfall.org (8.15.2/8.15.2) with ESMTP id 11FFDtmL039444 > for ; Tue, 16 Feb 2021 02:14:09 +1100 (EST) > (envelope-from owner-freebsd-po...@freebsd.org) > Received: from mx1.freebsd.org (mx1.freebsd.org > [IPv6:2610:1c1:1:606c::19:1]) > (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) > key-exchange X25519 server-signature RSA-PSS (4096 bits) > client-signature RSA-PSS (4096 bits)) > (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) > by mx2.freebsd.org (Postfix) with ESMTPS id EE5DF95ED7; > Mon, 15 Feb 2021 15:13:53 + (UTC) > (envelope-from owner-freebsd-po...@freebsd.org) > Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org > [IPv6:2610:1c1:1:606c::50:13]) > by mx1.freebsd.org (Postfix) with ESMTP id 4DfSL95Fdgz4gt0; > Mon, 15 Feb 2021 15:13:53 + (UTC) > (envelope-from owner-freebsd-po...@freebsd.org) > > Sure looks like freebsd.org to me, hence my comment about a compromised > server... Are you really surprised list mail comes from freebsd.org servers because that's what your excerpt shows? Real question is where the list software received it from, and my excerpt had that, coming from somewhere unknown with forged From header. ___ 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: MAIL ADMINISTRATIVE SERVICE CENTER
Dave Horsfall wrote: > On Tue, 15 Feb 2021, administra...@freebsd.org wrote: > > (Nothing) > > As this came from freebsd.org, were they trying to shout something or do > they have a compromised server? It's obvious it did NOT come from freebsd.org once you check the headers: Received: from bambo.com (unassigned.162-216-243-43.pivo.com [162.216.243.43]) by mx1.freebsd.org (Postfix) with ESMTP id 4DfSL624h4f for ; Mon, 15 Feb 2021 15:13:49 + (UTC) (envelope-from ne...@gusikowski.ml) Received: from gusikowski.ml (unknown [64.44.131.48]) by bambo.com (Postfix) with ESMTPA id D75CA20F0CD0 for ; Mon, 15 Feb 2021 14:48:17 + (UTC) From: administra...@freebsd.org And "From:" is so easy to forge that it means absolutely nothing. ___ 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: Portlint complains about %%FOO%% in PLIST_FILES
Rainer Hurling wrote:
Yesterday I committed net/hblock [r556099] after changing the patch to
PLIST_FILES (instead of pkg-plist with only two files) against the
suggestion of the submitter.The line in question is:
PLIST_FILES=bin/${PORTNAME} %%MANPAGES%%man/man1/hblock.1.gz
I made this change because it allows the port to build and install
correctly in all combinations of OPTIONS.
With the use of %%MANPAGES%%% in PLIST_FILES one can selectively enable
and disable the building of manpages.
The maintainer of net/hblock informs me about a problem with using
%%MANPAGES%% in PLIST_FILES. I don't know why I did not notice the
message from 'portlint -AC' before:
FATAL: PLIST_FILES: files cannot contain %%FOO%% variables. Use make
variables and logic instead
Is it possibly correct to use %%MANPAGES%% in PLIST_FILES and only
portlint can't handle it?
Is there an alternative to switching back to pkg-plist file?
Thanks in advance for clarification and maybe a suggestion for correct
usage.
See 5.13.3.11 in
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html,
i.e. use MANPAGES_PLIST_FILES=.
See x11/swaybg/Makefile for example.
___
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: Sudden trouble with net/rdesktop
Greg Veldman wrote:
On Fri, Nov 13, 2020 at 03:52:54PM +0300, Yuri Pankov wrote:
OK, I was able to reproduce this; actually, it hit that assertion for
all Windows 10 20H2 installs I have, all are updated to latest patches,
so I can't tell when this started to happen. Adding a debug print
before that assert() shows the following:
$ DISPLAY=mercury:0.0
/usr/ports/net/rdesktop/work/rdesktop-1.9.0/rdesktop orion
len=128 size=128
Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file
utils.c, line 501.
So we need the len of 128 we need size of digest buf to be > 256, the
following patch worked for me:
polaris:ypankov:/usr/ports/net/rdesktop$ cat files/patch-utils.c
--- utils.c.orig2020-11-13 12:40:51 UTC
+++ utils.c
@@ -584,7 +584,7 @@ _utils_cert_get_info(gnutls_x509_crt_t cert, char *out
{
char buf[128];
size_t buf_size;
- char digest[128];
+ char digest[512];
gnutls_x509_dn_t dn;
time_t expire_ts, activated_ts;
This seems like a reasonable change, but I'll make one minor
note. Later on in _utils_cert_get_info() the contents of
digest are written to sha1 and sha256, which are both size
256. In the initial implementation both buf and digest are
of the same size, which would seem to indicate that buf was
not expected to be completely full (in fact less than half
full based on the assertion in _utils_data_to_hex()). However
if defined to 512 chars and ever somehow filled beyond 256
(in fact a bit less than that, since a static string is
prepended to the call to snprintf()), the writes to sha1 and
sha256 would be incomplete, which I haven't completely read
through but would very likely lead to Bad Things(tm) later on.
All this to say, perhaps a more conservative approach would be
to increase digest to 256 chars instead of 512. I don't currently
have a Windows 10 20H2 machine to test on, but would you mind
trying with 256 instead of 512 and see if that also fixes the
issue? If so, let me know and I'll submit a PR to get this
patch added.
size is 128 now, so with digest of 256 we fail the ((len * 2) < size)
assertion, 257 works though (or changing the assertion to be <=).
Actually, this does not look like a real fix. I have looked more into
it and something is still very wrong -- _utils_cert_get_info() calls
gnutls_x509_crt_get_fingerprint() and does NOT check the return value
while it is -72 (GNUTLS_E_ASN1_VALUE_NOT_VALID), while the only
*documented* return values are 0 (got fingerprint successfully) and -51
(GNUTLS_E_SHORT_MEMORY_BUFFER, not enough buffer space). I don't know
if it was the same previously as I don't have a system to test against.
If yes, then this patch could be used in ports at least until upstream
fixes the problem properly; if no, then we would need a proper fix first.
Also note that sha1 and sha256 fingerprints reported are the *same*,
which doesn't look right with this approach.
___
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: Sudden trouble with net/rdesktop
Andrea Venturoli wrote:
On 11/12/20 5:18 PM, Yuri Pankov wrote:
Could it be something that changed on remote side, e.g. any recent
updates?
Sure.
Most targets are Windows 10 machines, so they possibly updated to a
newer version, but I don't know.
One is Windows 2012, though, so I don't think that changed that much.
OK, I was able to reproduce this; actually, it hit that assertion for
all Windows 10 20H2 installs I have, all are updated to latest patches,
so I can't tell when this started to happen. Adding a debug print
before that assert() shows the following:
$ DISPLAY=mercury:0.0
/usr/ports/net/rdesktop/work/rdesktop-1.9.0/rdesktop orion
len=128 size=128
Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file
utils.c, line 501.
So we need the len of 128 we need size of digest buf to be > 256, the
following patch worked for me:
polaris:ypankov:/usr/ports/net/rdesktop$ cat files/patch-utils.c
--- utils.c.orig2020-11-13 12:40:51 UTC
+++ utils.c
@@ -584,7 +584,7 @@ _utils_cert_get_info(gnutls_x509_crt_t cert, char *out
{
char buf[128];
size_t buf_size;
- char digest[128];
+ char digest[512];
gnutls_x509_dn_t dn;
time_t expire_ts, activated_ts;
Also attached so you could simply drop it to files/ directory (if the
list will pass it through). Though I must admit I have no idea what
changed exactly on Windows side caused the digest size to grow that much.
As a workaround, try increasing the buf size to e.g. 512 in
utils.c:_utils_cert_get_info().
Sorry, looks like I'm reading that backwards, and increasing the buf
size will actually make it worse.
BTW, did you previously have rdesktop compiled without DEBUG option,
so that assert() simply didn't fire, and now it's ON?
Actually I built it in poudriere *without* DEBUG option.
I might as well enable it and investigate, then.
Sorry, that was another shot in the dark, without actually trying
something, and wrong one at it.
--- utils.c.orig2020-11-13 12:40:51 UTC
+++ utils.c
@@ -584,7 +584,7 @@ _utils_cert_get_info(gnutls_x509_crt_t cert, char *out
{
char buf[128];
size_t buf_size;
- char digest[128];
+ char digest[512];
gnutls_x509_dn_t dn;
time_t expire_ts, activated_ts;
___
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: Sudden trouble with net/rdesktop
Andrea Venturoli wrote: Hello. After many year of happy usage, since yesterday rdesktop dumps core (12.2/amd64). % rdesktop xx Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file utils.c, line 499. Abort (core dumped) This is systematic with 4 servers out of 5; the 5th still works perfectly, but I have no idea in which way it might differ from the others. I don't think this has anything to do with the upgrade to 1.9.0, since I was able to use 1.9.0 for a while. Anyone else seeing this? Where do I go and look? I see a similar report on github: https://github.com/rdesktop/rdesktop/issues/380 Could it be something that changed on remote side, e.g. any recent updates? As a workaround, try increasing the buf size to e.g. 512 in utils.c:_utils_cert_get_info(). ___ 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: Sudden trouble with net/rdesktop
Yuri Pankov wrote: Andrea Venturoli wrote: Hello. After many year of happy usage, since yesterday rdesktop dumps core (12.2/amd64). % rdesktop xx Assertion failed: ((len * 2) < size), function _utils_data_to_hex, file utils.c, line 499. Abort (core dumped) This is systematic with 4 servers out of 5; the 5th still works perfectly, but I have no idea in which way it might differ from the others. I don't think this has anything to do with the upgrade to 1.9.0, since I was able to use 1.9.0 for a while. Anyone else seeing this? Where do I go and look? I see a similar report on github: https://github.com/rdesktop/rdesktop/issues/380 Could it be something that changed on remote side, e.g. any recent updates? As a workaround, try increasing the buf size to e.g. 512 in utils.c:_utils_cert_get_info(). Sorry, looks like I'm reading that backwards, and increasing the buf size will actually make it worse. BTW, did you previously have rdesktop compiled without DEBUG option, so that assert() simply didn't fire, and now it's ON? ___ 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: STOP rust!
Rozhuk Ivan wrote: On Tue, 10 Nov 2020 20:01:55 +0300 Yuri Pankov wrote: Actually, it started quite some time ago, and it was 2.41 that introduced the rust dependency: https://mail.gnome.org/archives/desktop-devel-list/2017-January/msg1.html This does not explain why I should waste my time and money to compile ugly rust. You should ask librsvg developers then as I said in the first reply. P.S. please reply to the list, not to me directly, I'm not interested in unicast discussion and adding the list address back every time. ___ 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: STOP rust!
Rozhuk Ivan wrote: Hi all! With latest ports tree librsvg2-rust-2.50.0 is required to some ports. It want replace librsvg2-2.40.21. I do not want build ugly rust during hours to build small lib in less than minute. You might want to send your complaints to librsvg authors, or fork the before-the-rust version and maintain it; ports list really seems to be a wrong target for this discussion. Same with polkit & spidermonkey. https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35 I remove polkit where it is possible. ___ 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: iperf checksums?
@lbutlr wrote: When trying to install iperf: ===>>> Waiting on fetch & checksum for benchmarks/iperf <<<=== fetch: https://freefr.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz: size mismatch: expected 370518, actual 373268 => Attempting to fetch https://jaist.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz fetch: https://jaist.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz: size mismatch: expected 370518, actual 373268 => Attempting to fetch https://nchc.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz fetch: https://nchc.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz: size mismatch: expected 370518, actual 373268 => Attempting to fetch https://netcologne.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz fetch: https://netcologne.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz: size mismatch: expected 370518, actual 373268 => Attempting to fetch https://netix.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz fetch: https://netix.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz: size mismatch: expected 370518, actual 373268 => Attempting to fetch https://superb-dca2.dl.sourceforge.net/project/iperf2/iperf-2.0.14a.tar.gz Over and over with identical numbers on slightly differ source forge servers. Looking at the commit log, it's not the first time distfile is being silently rerolled: commit 0fa0c820d6f179cf280a663437687f6fe1d4ab87 Author: Sunpoet Po-Chuan Hsieh Date: Sun Oct 4 14:12:56 2020 + Update distinfo: upstream rerolled the tarball - Bump PORTREVISION for package change Diff: https://people.FreeBSD.org/~sunpoet/iperf-2.0.14a.diff Looks like they did it again. ___ 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: Aggressive ports removal
On 2020-08-30 12:39, Gary Aitken wrote: Should I file a bug report? Yes, please create a bug report for the port "sysutils/bsdstats". I believe that its current maintainer also runs the BSDstats website. Yuri ___ 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: Aggressive ports removal
On 2020-08-30 11:20, Warner Losh wrote: I don't know how easy this would be to implement, but it would be very useful to know which ports are actually being built and installed. How difficult This is already implemented in the BSDstats project (sysutils/bsdstats). It does such accounting for hosts that have BSDstats installed. It shows stats on it's webpage https://bsdstats.org/ However, not many people are willing to install sysutils/bsdstats, or know about it, so it only counts based on a tiny fraction of hosts running FreeBSD. Best, Yuri ___ 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: poudriere segmentation fault on 13-CURRENT
Grzegorz Junka wrote: On 20/05/2020 19:33, Yuri Pankov wrote: Grzegorz Junka wrote: When configuring ports with this option: poudriere options -j 13 -p gui -z v8 lang/v8 for every port the configuration ends with "Segmentation fault". For example, with that command the first port that shows up is "python27-2.7.18". After the ncurses dialog is shown I click OK which supposed to save the option. But instead, I see "Segmentation fault" and nothing is written to /usr/local/etc/poudriere.d/13-gui-v8-options/lang_python27/ This only happens when I use kernel 13-CURRENT and "Segmentation fault" would happen regardless if used -j 13 or -j 12 or -j 12.1 (STABLE and 12.1 jails respectively). Otherwise compiling with poudriere on kernel 13 works fine, it's just the options that don't work. I have to boot kernel 12, configure options, then boot kernel 13 to compile. What might be the issue? Which program is misbehaving, is it dialog4ports? Do you have the core and can provide the backtrace? That's what I would like to find out. No core is dumped in the local folder. Not sure where it would be dumped instead? If at all? The segmentation fault happens after the options have been selected. I think it's at the moment when they should have been written to disk. You can check dmesg for that information, e.g.: pid 41216 (sleep), jid 0, uid 1001: exited on signal 11 pid 43373 (bad), jid 0, uid 1001: exited on signal 11 (core dumped) Note that the former doesn't say the "core dumped" as I just sent SIGSEGV to it using `pkill`, the latter is small test case dereferencing null pointer, and has its core written to the working directory. Also, is it reproducible without using poudriere? Is it running 12.x binaries with 13-CURRENT kernel? If yes, what are the revisions for both? ___ 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: More xorg mischief on Rpi3B, failed to open /dev/io
bob prohaska wrote: Enabling amdgpu in llvm80 solved the problem of compiling xorg on a Pi3b, but now that it's built and installed it still fails to run. Probably stupid question, but as you didn't mention it, is the actual drm module loaded? Also you don't need the 'configure' step, how about a simple 'startx' from normal user? ___ 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: poudriere segmentation fault on 13-CURRENT
Grzegorz Junka wrote: When configuring ports with this option: poudriere options -j 13 -p gui -z v8 lang/v8 for every port the configuration ends with "Segmentation fault". For example, with that command the first port that shows up is "python27-2.7.18". After the ncurses dialog is shown I click OK which supposed to save the option. But instead, I see "Segmentation fault" and nothing is written to /usr/local/etc/poudriere.d/13-gui-v8-options/lang_python27/ This only happens when I use kernel 13-CURRENT and "Segmentation fault" would happen regardless if used -j 13 or -j 12 or -j 12.1 (STABLE and 12.1 jails respectively). Otherwise compiling with poudriere on kernel 13 works fine, it's just the options that don't work. I have to boot kernel 12, configure options, then boot kernel 13 to compile. What might be the issue? Which program is misbehaving, is it dialog4ports? Do you have the core and can provide the backtrace? ___ 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: New feature suggestion: print-gh-tuple: Print GH_TUPLE corresponding to submodules of a GitHub repository ${GH_ACCOUNT}/${GH_PROJECT}
On 2020-04-17 00:37, Mateusz Piotrowski wrote: Great idea! I've done something similar for x11/ly. It's great to possibly have something more general and available through out the whole ports tree. Thanks! This particular project (ly) is a bad example because it uses some GitHub extension, git itself doesn't find submodules there: 'git submodule status' fails on it, and 'git clone --recurse-submodules' doesn't clone submodules. Yuri ___ 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"
New feature suggestion: print-gh-tuple: Print GH_TUPLE corresponding to submodules of a GitHub repository ${GH_ACCOUNT}/${GH_PROJECT}
Hi, I am suggesting a new feature: make print-gh-tuple https://reviews.freebsd.org/D24231 It works when USE_GITHUB=yes is set. When a GitHub repository has git submodules, that themselves can also have embedded submodules, it can traverse all of them and output the value of GH_TUPLE that would include all of them. This is quite tedious and difficult to do manually. It checks out the GitHub repository with submodules, traverses the list using a combination of shell and awk scripting, and prints GH_TUPLE that can be pasted into a ports's Makefile. Yuri ___ 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: Linux-foldingathome
@lbutlr wrote: On 07 Apr 2020, at 06:36, Yuri Pankov wrote: @lbutlr wrote: # service fahclient start Starting fahclient. 13:33:52:WARNING:Exception: Failed to open '/proc/bus/pci/devices': Failed to open '/proc/bus/pci/devices': No such file or directory: No such file or directory 13:33:52:ERROR:Exception: Could not read link /proc/self/exe It is looking for /compat/linux/proc -- if it isn't mounted and you aren't on recentish -current 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64 Isn’t recent enough, I guess? Correct, I mean the following commit in HEAD (so 13.0-CURRENT only, at the moment): https://svnweb.freebsd.org/base?view=revision=354458 where all required mounts are done by rc script, you should follow the pkg-message for linux_base-c7 port. Thank you, that solved the issue and the client is running now. ___ 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: Linux-foldingathome
@lbutlr wrote: Has anyone had any experience with installing the port biology/linux-foldingathome? After installing it and editing the configuration file I try to start it and get the following: # service fahclient start Starting fahclient. 13:33:52:WARNING:Exception: Failed to open '/proc/bus/pci/devices': Failed to open '/proc/bus/pci/devices': No such file or directory: No such file or directory 13:33:52:ERROR:Exception: Could not read link /proc/self/exe /usr/local/etc/rc.d/fahclient: WARNING: failed to start fahclient /proc/ is empty. There were no errors when installing the port. # kldstat Id Refs AddressSize Name 1 57 0x8020 2448d90 kernel 21 0x82649000 3a99a8 zfs.ko 32 0x829f3000 a5b8 opensolaris.ko 41 0x82f11000 4260 ng_ubt.ko 56 0x82f16000 9e30 netgraph.ko 62 0x82f2 91b8 ng_hci.ko 73 0x82f2a000 9c0 ng_bluetooth.ko 81 0x82f2b000 cad0 ng_l2cap.ko 91 0x82f380001ba00 ng_btsocket.ko 101 0x82f54000 21c0 ng_socket.ko 111 0x82f57000 acf mac_ntpd.ko 121 0x82f58000 18a0 uhid.ko 131 0x82f5a000 1aa0 wmt.ko 141 0x82f5c000 2928 ums.ko 151 0x82f5f00035b20 linux64.ko 163 0x82f95000 3178 linux_common.ko 171 0x82f99000 494c linprocfs.ko 181 0x82f9e000 1eae linsysfs.ko It is looking for /compat/linux/proc -- if it isn't mounted and you aren't on recentish -current where all required mounts are done by rc script, you should follow the pkg-message for linux_base-c7 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"
The "3.2.2 Maintainer responsibilities" section should ask maintainers to be a bit more proactive and fix known problems, keep ports in a working order
I suggest that this new paragraph is added to the rules for maintainers: 4. Fix known problems, keep ports in a working order Please attempt to resolve known problems in the ports that you maintain. When others report a problem or you yourself find a problem in the port, please make a reasonable effort to fix the problem and submit your changes that would resolve the issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245226 Yuri ___ 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"
Please approve or comment on D23994: graphics/gmic-qt: Flavorize the port to support all 3 variants: "gimp", "krita", standalone
https://reviews.freebsd.org/D23994 Thanks, Yuri ___ 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: Deluge port for FreeBSD
On 2020-03-02 13:33, Chris Ross wrote: Yuri, will you be able to un-BROKEN net-p2p/py-libtorrent-rasterbar sometime soon? From reading and my own testing, version 1.2.4 does not have the "doesn't install any files" problem that earlier releases did on FreeBSD. Fixing that port will also allow deluge to be updated. net-p2p/py-libtorrent-rasterbar isn't currently labeled BROKEN. Please update your ports tree. Yuri ___ 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: reccomendations of conference / party audio video software ?
On 2020-03-22 03:50, Hans Petter Selasky wrote: On 2020-03-21 19:53, Matthias Apitz wrote: El día sábado, marzo 21, 2020 a las 07:49:23p. m. +0100, Hans Petter Selasky escribió: On 2020-03-21 17:06, Julian H. Stacey wrote: Hi ports@ Any reccomendations of conference / social group party chat server software ? Hi, I made a liveshow recently using the following ports: virtual_oss, webcamd, baresip, zynaddsubfx, midipp and obs-studio . Worked great and I have some patches to improve support under FreeBSD. Might be an idea for coming BSD conferences ! Is this somewhere recorded to get an idea? Thanks Currently I have two videos at my facebook page (You need to add me as a friend): https://www.facebook.com/hanspetter.selasky The second one is better than the first one :-) Found some bugs with JACK input and had to configure use of ALSA manually in the port. From a user's standpoint it would be best if this configuration was represented as a meta-port that would install all required dependencies and a sample configuration, and would provide instructions on how to configure/use it in pkg-message. Is it possible to create such a meta-port? Yuri ___ 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"
Broken ports subversion directory: sqlite[S19]: UNIQUE constraint failed: NODES.wc_id, NODES.parent_relpath, NODES.local_relpath, NODES.op_depth
Now the 'svn update' command in /usr/ports always prints this error for me: $ svn update Updating '.': svn: E200035: sqlite[S19]: UNIQUE constraint failed: NODES.wc_id, NODES.parent_relpath, NODES.local_relpath, NODES.op_depth svn: E200042: Additional errors: svn: E200035: sqlite[S19]: UNIQUE constraint failed: NODES.wc_id, NODES.parent_relpath, NODES.local_relpath, NODES.op_depth Anybody knows how to fix this? Or, perhaps, the only way is to refetch it? Thank you, Yuri ___ 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: whereis lynx
Amit Yaron wrote: For those who like the GUI-less browser. There is a port directory from which to install lynx, but it is not listed in the output of whereis lynx Instead, the output is: lynx: /usr/local/bin/lynx /usr/local/man/man1/lynx.1.gz /usr/ports/japanese/lynx If you install it from the Japanese port, the sources will be compiled without SSL, which means that you cannot open an 'https' URL. The browser can also be installed from '/usr/ports/www/lynx'. You could use -a option though: $ whereis -a lynx lynx: /usr/ports/japanese/lynx /usr/ports/www/lynx ___ 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"
Should 'Reported by' reflect who/which system reported the port to be out-of-date?
I got a feedback that such use of 'Reported by' might be incorrect. Opinions? Yuri ___ 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: good gui bit-torrent client?
On 29 Feb 2020, at 22:39, Miroslav Lachman <000.f...@quip.cz> wrote: > > Robert Huff wrote on 2020/02/29 00:49: >> I used to use azureus/vuze, but it hasn't been maintained is >> quite a while. >> So I changed to deluge ... which now has a dependency >> semi-permanently BROKEN. >> What can people recommend as a replacement? > > I used uTurrent in Windows times. When I switched to FreeBSD on my desktop I > used Vuze / Azureus. But it was resource hungry and at some point in time no > longer works for me. > Then I tried qBittorrent and I am very happy with it. Simple, stable, good > looking with my KDE. > > net-p2p/qbittorrent is my choice Same here, using it on FreeBSD/macOS/Windows and not seeing any issues (even without KDE on FreeBSD). ___ 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"
Notifying maintainers when their port is labeled BROKEN would make a difference
Currently maintainers aren't notified when their ports are labeled broken. Adding broken ports to "Issues that need your attention" e-mails would make a difference. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243271 Who can make this change? Yuri ___ 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"
Duplicated origin for libxml2-2.9.10: textproc/py-libxml2 AND textproc/libxml2
After some recent commit some ports now fail in poudriere: [00:00:09] Warning: (textproc/py-libxml2): Error: Duplicated origin for libxml2-2.9.10: textproc/py-libxml2 AND textproc/libxml2. Rerun with -v to see which ports are depending on these. [00:00:09] Error: Fatal errors encountered gathering ports metadata For example cad/ktechlab fails. Yuri ___ 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: GL_xx tags fail when GL_SITE=https://git.zrythm.org
On 2019-10-31 00:57, Tobias Kortkamp wrote: GL_* is for GitLab instances andhttps://git.zrythm.org does not appear to be one anymore. It worked as a GitLab in the previous versions, but now it doesn't any more? Did it morph somehow? Yuri ___ 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"
GL_xx tags fail when GL_SITE=https://git.zrythm.org
In the port audio/zrythm when DISTVERSION=0.7.021 and GL_COMMIT=869fc2493d252506c7bf4f76d2e6ec25c0b5d1da 'make makesum' fails to fetch the tarball. What is wrong? Thanks, Yuri ___ 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: packaging a port that uses npm during build.
On 2019-10-30 13:16, Willem Jan Withagen wrote: But my project includes about a npm 62 toplevel packages. :-( and many more getting installed as extra dependancies. So that is not really an option. 'npm install -l' does the basic local installation, it has a ton of options that allow it to install extra/optional dependencies. So I am pretty sure that this approach can be used with most npm-based projects, except when they attempt to build some native libs and fail for some obscure reasons. Yuri ___ 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: packaging a port that uses npm during build.
On 2019-10-28 04:17, Willem Jan Withagen wrote: I think I read once somewhere that there is also a "flag" that indicates that the port wants network access during the build. Is that feasible? No, this isn't/shouldn't be possible. Please look at how misc/netron is done. It pre-packages NPM modules into a separate distfile. CAVEAT: Please keep in mind that NodeJS downloads JS files from a multitude of GitHub locations, which makes this technology fundamentally insecure because any malicious or otherwise harmful change in any of the hundreds of projects would be automatically propagated into the FreeBSD package and further to the users. For this reason NodeJS software is less secure and for example RPM and Debian packages often (or always) just don't include such software into their distributions. misc/netron only has a few js files installed so it is okay. You can also do the same with more complex projects, with the above caveat. Best, Yuri ___ 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"
Please commit the patch in Bug 235275 - Multiply bundled GH_TUPLE repositories result in broken links - it holds up one new port
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235275 Thanks, Yuri ___ 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: 12.0-RELEASE-p7 doesn't contain std::filesystem that has been added to 12.0-STABLE some time later
On 2019-07-10 07:19, Jan Beich wrote:
C++ example:
#if __cplusplus >= 201703L && __has_include()
#include
#else
#include
namespace std {
namespace filesystem = experimental::filesystem;
}
#endif
Makefile example:
.if exists(/usr/lib/libc++fs.a)
LIBS+= -lc++fs
.elif exists(/usr/lib/libc++experimental.a)
# XXX Remove after FreeBSD 12.0 EOL
LIBS+= -lc++experimental
.else
# XXX Remove after FreeBSD 11.2 EOL
USE_GCC= yes
LIBS+= -lstdc++fs
.endif
This helps with locating the header/library, but it fails to compile in
poudriere on 12.0-RELEASE-p7:
x.cpp:213:15: error: no member named 'is_symlink' in
'std::experimental::filesystem::v1::directory_entry'
if (entry.is_symlink())
~ ^
It looks like 12.0-RELEASE-p7 is technically broken, because it doesn't
include is_symlink().
Yuri
___
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: 12.0-RELEASE-p7 doesn't contain std::filesystem that has been added to 12.0-STABLE some time later
On 2019-07-09 13:19, Mathieu Arnold wrote: On Tue, Jul 09, 2019 at 12:51:52PM -0700, Yuri wrote: On 2019-07-08 23:54, Mathieu Arnold wrote: On Mon, Jul 08, 2019 at 03:48:25PM -0700, Yuri wrote: Maybe the patch level should be updated, because any port using std::filesystem fails in the current poudriere 12.0-RELEASE-p7 VM. 12.0-RELEASE-p* is a different branch than 12.0-STABLE. releng/12.0 vs stable/12. Only security fixes and critical fixes get applied to the releng branches. When releng/12.0 was branched, OSVERSION of the branch was 1200086, and it has not changed on that branch. Just after releng/12.0 was branched, the stable/12 branch OSVERSION was bumped to 1200500, to show it is ahead. Details are available here (some OSVERSION bumps may be missing): https://www.freebsd.org/doc/en/books/porters-handbook/versions-12.html Thanks for this information. This means that ports using std::filesystem can never be built in poudriere on 12 because std::filesystem is not a security feature and it will not be included in the patches. I'm not sure I follow what you are talking about. It can be built on stable/12, which is 12.0-STABLE, and on 12.1 when it gets released in November. Ok, thanks. Yuri ___ 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: 12.0-RELEASE-p7 doesn't contain std::filesystem that has been added to 12.0-STABLE some time later
On 2019-07-08 23:54, Mathieu Arnold wrote: On Mon, Jul 08, 2019 at 03:48:25PM -0700, Yuri wrote: Maybe the patch level should be updated, because any port using std::filesystem fails in the current poudriere 12.0-RELEASE-p7 VM. 12.0-RELEASE-p* is a different branch than 12.0-STABLE. releng/12.0 vs stable/12. Only security fixes and critical fixes get applied to the releng branches. When releng/12.0 was branched, OSVERSION of the branch was 1200086, and it has not changed on that branch. Just after releng/12.0 was branched, the stable/12 branch OSVERSION was bumped to 1200500, to show it is ahead. Details are available here (some OSVERSION bumps may be missing): https://www.freebsd.org/doc/en/books/porters-handbook/versions-12.html Thanks for this information. This means that ports using std::filesystem can never be built in poudriere on 12 because std::filesystem is not a security feature and it will not be included in the patches. Yuri ___ 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"
12.0-RELEASE-p7 doesn't contain std::filesystem that has been added to 12.0-STABLE some time later
Maybe the patch level should be updated, because any port using std::filesystem fails in the current poudriere 12.0-RELEASE-p7 VM. Yuri ___ 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"
TIL: there are alternative ports trees with ports that don't exist in FreeBSD's tree
Some people submit ports to this fork: https://github.com/myfreeweb/freebsd-ports-dank Some ports that exist there aren't in the main tree, for example "x11 <https://github.com/myfreeweb/freebsd-ports-dank/tree/lite/x11>/tilix". If one person submits a new port into this "dank" mirror, and another person would just commit the port for the same software to the main ports tree, the work of the first contributor would be wasted, because his port would just stay in this fork. Yuri ___ 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"
Bugzilla keeps failing: Error 503 Backend fetch failed
This happened all day yesterday and today. I couldn't open it to create a bug report for bugzilla itself, so sending a message here. Yuri Error 503 Backend fetch failed Backend status: Backend fetch failed Transaction ID: 1168565 ___ 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"
Is there a way to build only the port from source, and install dependencies from packages with the make command?
Sometimes instructions to build some port from source are needed. "cd
/usr/ports/{caregory}/{port-name} && make" rebuilds everything from
source, including dependencies.
Is there an easy way to make it install missing dependencies with pkg,
without listing them? I couldn't find such feature.
This can be useful:
1. When some software's README describes how to install it on FreeBSD
from source.
2. When developers need to compile from source only a specific port
without waiting for dependencies to build.
Yuri
___
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"
https://www.freshports.org/ is down
It resolves to the IP, and pings work, but it can't be contacted on 443 or 80. Yuri ___ 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: Best way to generate a patch file
Dan Mahoney (Gushi) wrote: > All, > > I'm requesting takeover of a couple of FreeBSD ports (cvs and dma, > although dma is now in base, I imagine the port will be used to track > upstream changes before they make it into base). > > What has been requested thusfar is a diff to update maintainer. Seems > simple enough, right, effectively a one-line patch/diff? > > So, how do I go about it? I could certainly cd to /usr/ports/mail/dma, > copy Makefile to Makefile.orig, and run a manual diff Makefile.orig > Makefile > /tmp/patch, while in that directory. That would apply only > for the single file, obviously. > > Or I could clone the entire port, and make a unified diff. Yes, more > complicated and perhaps unnecessary for a one-line-in-one-file patch, > but maybe some tooling expects that (I couldn't find a good rule of > thumb here). > > Finally, in googling around, I found a makefile target that's called > "make makepatch" -- which isn't documented in 'man ports', and which I > *think* is not used for tracking patches that will live the lifetime of > a port, but there's no section in the porters handbook that covers this. > > That is to say, the entire "patching" section in the porter's handbook > covers "lifecycle" (./files) patches, and not "bugreport" patches: > > https://www.freebsd.org/doc/en/books/porters-handbook/slow-patch.html Check https://www.freebsd.org/doc/en/books/porters-handbook/port-upgrading.html#svn-diff. Also, I think it's general rule of thumb that you should set yourself as maintainer along with submitting actual changes to the port (upgrading, fixing, etc.). signature.asc Description: OpenPGP digital signature
anyone tried/ported nvidia-driver 410.66 yet?
Hi, Just wondering if anyone has ported nvidia-driver 410.66 yet, and could provide a patch for testing (myself being lazy and not that ports proficient)? signature.asc Description: OpenPGP digital signature
Re: Inkscape compiles but crashes on startup
Stefan Esser wrote: > Am 04.11.18 um 22:21 schrieb bob prohaska: >> On Sun, Nov 04, 2018 at 10:47:22AM +0100, T??l Coosemans wrote: >>> On Sat, 3 Nov 2018 22:31:34 -0700 bob prohaska wrote: On Sat, Nov 03, 2018 at 07:18:52AM +0100, Walter Schwarzenfeld wrote: > Wait, fix of the primal cause of it is committed right now. > > https://svnweb.freebsd.org/ports?view=revision=483878 Alas, no luck. Updating the ports tree and recompiling inkscape got rid of the locale error, but inkscape still crashes with an otherwise similar error stream from Gtk. >>> >>> You have to rebuild devel/glib20. >> >> That did the trick, thank you! > > If some dependent port only runs after glib20 has been recompiled, > shouldn't that be reason to bump the port revision of glib20, even > though the port didn't change in any other way? It was bumped actually: r483878 | jbeich | 2018-11-03 09:10:28 +0300 (Sat, 03 Nov 2018) | 8 lines devel/glib20: revert to old g_convert() behavior PR: 232073 Reported by:many (via inkscape) Suggested by: tijl Tested by: glib/tests/convert MFH:2018Q4 Index: Makefile === --- Makefile(revision 483877) +++ Makefile(revision 483878) @@ -3,7 +3,7 @@ PORTNAME= glib PORTVERSION= 2.56.1 -PORTREVISION= 2 +PORTREVISION= 3 ... signature.asc Description: OpenPGP digital signature
Re: FreeBSD Port: firefox-63.0.1,1 multiple errors build
Yuri Pankov wrote: > Montgomery-Smith, Stephen wrote: >> On 10/31/18 1:12 PM, Alex V. Petrov wrote: >> [lots of build errors snipped] >> >> I found that when I downgraded rust-cbindgen to 0.6.6_1 that this fixed >> the build problems. So I suspect it is version 0.6.7 of rust-cbindgen >> that is causing the build errors. > > Fails for me even with 0.6.6_1. And it built with rust-cbindgen-0.6.7, so I'm now wondering if it's not about the version, and has something to do with the fact that 0.6.6_1 was installed using pkg, and update to 0.6.7 was done using ports. ___ 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: FreeBSD Port: firefox-63.0.1,1 multiple errors build
Montgomery-Smith, Stephen wrote: > On 10/31/18 1:12 PM, Alex V. Petrov wrote: > [lots of build errors snipped] > > I found that when I downgraded rust-cbindgen to 0.6.6_1 that this fixed > the build problems. So I suspect it is version 0.6.7 of rust-cbindgen > that is causing the build errors. Fails for me even with 0.6.6_1. ___ 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: [freebsd 11.2] net-snmpd incomplete mac addresses
Yuri Pankov wrote: Patrick Lamaiziere wrote: Hello, freebsd 11.2/amd64 release net-snmp-5.7.3_18 net-snmpd returns incomplete MAC addresses in IF-MIB::ifPhysAddress, the first octet is always "0". $ snmpwalk -v 2c -c "xxx" localhost 1.3.6.1.2.1.2.2.1.6 IF-MIB::ifPhysAddress.1 = STRING: 0:36:9f:93:7d:f8 IF-MIB::ifPhysAddress.2 = STRING: 0:36:9f:93:7d:fa IF-MIB::ifPhysAddress.3 = STRING: 0:f4:bb:ef:c8:e4 ... $ ifconfig | grep ether ether a0:36:9f:93:7d:f8 ether a0:36:9f:93:7d:fa ether ec:f4:bb:ef:c8:e4 tcpdump confirms that the problem is in net-snmpd (and not the client). Also when using the MIB IP-MIB::ipNetToMediaPhysAddress the MAC addresses are correct. $ snmpwalk -v2c -c '***r***' localhost IP-MIB::ipNetToMediaPhysAddress | grep a0:36:9f:93:7d:f8 IP-MIB::ipNetToMediaPhysAddress.13.10.10.1.118 = STRING: a0:36:9f:93:7d:f8 I've checked net-snmpd 5.7.3 under linux and the mac addresses are correct. (So it's specific to FreeBSD.) Any clue ? It looks like net-snmp being stupid, try the attached patch (put to files/). For the note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231996 https://sourceforge.net/p/net-snmp/code/merge-requests/20/ ___ 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: [freebsd 11.2] net-snmpd incomplete mac addresses
Patrick Lamaiziere wrote:
Hello,
freebsd 11.2/amd64 release
net-snmp-5.7.3_18
net-snmpd returns incomplete MAC addresses in IF-MIB::ifPhysAddress,
the first octet is always "0".
$ snmpwalk -v 2c -c "xxx" localhost 1.3.6.1.2.1.2.2.1.6
IF-MIB::ifPhysAddress.1 = STRING: 0:36:9f:93:7d:f8
IF-MIB::ifPhysAddress.2 = STRING: 0:36:9f:93:7d:fa
IF-MIB::ifPhysAddress.3 = STRING: 0:f4:bb:ef:c8:e4
...
$ ifconfig | grep ether
ether a0:36:9f:93:7d:f8
ether a0:36:9f:93:7d:fa
ether ec:f4:bb:ef:c8:e4
tcpdump confirms that the problem is in net-snmpd (and not the client).
Also when using the MIB IP-MIB::ipNetToMediaPhysAddress the MAC
addresses are correct.
$ snmpwalk -v2c -c '***r***' localhost IP-MIB::ipNetToMediaPhysAddress | grep
a0:36:9f:93:7d:f8
IP-MIB::ipNetToMediaPhysAddress.13.10.10.1.118 = STRING: a0:36:9f:93:7d:f8
I've checked net-snmpd 5.7.3 under linux and the mac addresses are
correct. (So it's specific to FreeBSD.)
Any clue ?
It looks like net-snmp being stupid, try the attached patch (put to files/).
--- agent/mibgroup/if-mib/data_access/interface_sysctl.c.orig 2018-10-05
13:11:25 UTC
+++ agent/mibgroup/if-mib/data_access/interface_sysctl.c
@@ -397,7 +397,8 @@ netsnmp_arch_interface_container_load(netsnmp_containe
}
}
adl = (struct sockaddr_dl *) a;
-if_name = (char *) adl->sdl_data;
+if_name = malloc(adl->sdl_nlen + 1);
+memcpy(if_name, adl->sdl_data, adl->sdl_nlen);
if_name[adl->sdl_nlen] = '\0';
}
if (!(ifp->ifm_addrs & RTA_IFP) || if_name == NULL) {
@@ -411,6 +412,7 @@ netsnmp_arch_interface_container_load(netsnmp_containe
netsnmp_access_interface_container_free(container,
NETSNMP_ACCESS_INTERFACE_FREE_NOFLAGS);
free(if_list);
+free(if_name);
return -3;
}
@@ -429,6 +431,7 @@ netsnmp_arch_interface_container_load(netsnmp_containe
entry->paddr_len = 6;
memset(entry->paddr, 0, 6);
}
+ free(if_name);
entry->mtu = ifp->ifm_data.ifi_mtu;
entry->type = ifp->ifm_data.ifi_type;
___
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: Port collection (incorrectly) marked as not supporting 11.1
Aryeh Friedman wrote: On: FreeBSD lilith 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321664: Fri Jul 28 23:35:18 EDT 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC amd64 Attempting to run make on any port produces: /!\ ERROR: /!\ Ports Collection support for your FreeBSD version has ended, and no ports are guaranteed to build on this system. Please upgrade to a supported release. No support will be provided if you silence this message by defining How is this possibly correct when 11.1 is still listed as a production release!?!?!?!? https://lists.freebsd.org/pipermail/freebsd-announce/2018-September/001842.html ___ 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: gcc5
Lorenzo Salvadore via freebsd-ports wrote: Todays update and I am using portmaster: ===>>> Starting build for ports that need updating <<<=== ===>>> Launching child to install lang/gcc5 ===>>> All >> lang/gcc5 (1/2) ===>>> Currently installed version: gcc5-5.5.0_4 ===>>> Port directory: /usr/ports/lang/gcc5 ===>>> Starting check for build dependencies ===>>> Gathering dependency list for lang/gcc5 from ports ===>>> Dependency check complete for lang/gcc5 ===>>> All >> gcc5-5.5.0_4 (1/2) ===> Cleaning for gcc5-5.5.0_5 Making GCC 5.5.0 for x86_64-portbld-freebsd11.2 [c,c++,objc,fortran] ===> NOTICE: This port is deprecated; you may wish to reconsider installing it: Unsupported by upstream. Use GCC 7 or newer instead.. ===> License GPLv3 GPLv3RLE accepted by the user ===> gcc5-5.5.0_5 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by gcc5-5.5.0_5 for building ===> Extracting for gcc5-5.5.0_5 => SHA256 Checksum OK for gcc-5.5.0.tar.xz. but there are many ports which depend on gcc5: Installed packages to be REMOVED: gcc5-5.5.0_4 libx264-0.155.2917 gstreamer-plugins-x264-0.10.19_8,3 gstreamer1-plugins-x264-1.12.3_2 mencoder-1.3.0.20180920 ffmpeg-4.0.2_4,1 libstreamanalyzer-0.7.8_12 aqualung-1.0_9 chromaprint-1.4.3_2 mlt-6.10.0_1 iridium-browser-2018.5.67_4 youtube_dl-2018.09.10 synfig-1.2.1_9 blender-2.79b_6 gimp-gmic-plugin-1.6.9_16 gegl-0.2.0_25 mpv-0.29.0_6,1 gegl3-0.3.34_2 gstreamer1-plugins-chromaprint-1.12.3 synfigstudio-1.2.1_5 py27-gimp-2.8.22_1 gimp-app-2.8.22_1,1 gnome-mpv-0.15 gimp-2.8.22,2 gimp-resynthesizer-2.0.3 gimp-lqr-plugin-0.7.2 gimpfx-foundry-2.6_2,1 gimp-wavelet-decompose-plugin-0.1.2_3 gimp-wavelet-sharpen-plugin-0.1.2_3 gimp-wavelet-denoise-plugin-0.3.1_3 gimp-lensfun-plugin-0.2.4.d_7 gimp-gutenprint-5.2.14 gimp-beautify-plugin-2012.08.12.00_7 gimp-refocus-plugin-0.9.0_7 Number of packages to be removed: 34 The operation will free 863 MiB. Proceed with deinstalling packages? [y/N]: I think you should do the following: pkg remove -f gcc5 This should remove gcc5 only and ignore dependencies. Once you install gcc7 you will probably have your broken dependencies solved with gcc7 or you will have to reinstall them. As a side note, I do not think that all the ports listed depends on gcc5: for example I do not think that ffmepg depends on any gcc version. This would mean that you have only a few ports depending on gcc5 (maybe only one) and that ffmpeg is installed automatically as a dependency of those ports: since the ports that depend on gcc5 are removed, their dependencies are not needed any more and are also removed. It's likely the libx264 port (guessing on it coming first after gcc in the list), which has the GCC option. Try reinstalling only that one unselecting the GCC option, and you (most likely) should be able to remove the gcc package altogether. ___ 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: Gnutls depends on unbound. Why?
@lbutlr wrote:
When trying to update gnutls it wants to install unbound.
I do not want unbound since my server is already running bind.
make config shows nothing at all that implies unbound is required, and the only
option that is even close to being related is IDN support which certainly
doesn’t require unbound, but disabling this option doesn’t change anything.
It's actually the DANE option, which brings in unbound.
# portmaster --show-work gnutls
===>>> Currently installed version: gnutls-3.5.18
===>>> Port directory: /usr/ports/security/gnutls
===>>> Starting check for all dependencies
===>>> Gathering dependency list for security/gnutls from ports
===>>> Installed converters/libiconv
===>>> Installed devel/gettext-runtime
===>>> Installed devel/gettext-tools
===>>> Installed devel/gmake
===>>> Installed devel/libunistring
===>>> Installed devel/pkgconf
===>>> NOT INSTALLEDdns/unbound
===>>> Installed math/gmp
===>>> Installed ports-mgmt/pkg
===>>> Installed print/indexinfo
===>>> Installed print/texinfo
===>>> Installed security/ca_root_nss
===>>> Installed security/libtasn1
===>>> Installed security/nettle
===>>> Installed security/p11-kit
===>>> Installed security/trousers
Also, when actually running postmaster gnutls it says it will install unbound
AND ldns, and also upgrade p11-kit, none of which are mentioned in —show-work.
I thought show work would show ALL the dependancies down the tree (Unbound
depends on ldns), don’t know where p11-kit shows up.
Trying to dig further,
# pkg info -Rx gnutls
Shows only the following dependancies (In deps { … }:
trousers
p11-kit
nettle
libtasn1
ca_root_nss
indexinfo
gmp
libidn2
libunistring
gettext-runtime
Which is a different list than —show-work lists.
So I am quite 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: Bacula 9.2.1 fails on 10.4:
Dan Langille wrote: Why would Bacula 9.2.1 compile on 11.2 but fail on 10.4? The error is: bsock.c:439:20: error: use of undeclared identifier 'ENODATA' The complete build logs are at the following URLs. Can you see the cause. 11.2: https://services.unixathome.org/poudriere/data/112amd64-default/2018-08-27_21h15m53s/logs/bacula9-client-9.2.1.log 10.4: https://services.unixathome.org/poudriere/data/104amd64-default/2018-08-27_21h43m31s/logs/errors/bacula9-client-9.2.1.log It doesn't make any sense to me. Thanks. I'd say it's libc++ missing its errno.h having ENODATA defined if the following is true: - both builds are using clang++ - both builds are using libc++ That header defining ENODATA exists in 11.2 and doesn't exist in 10.4 (contrib/libc++/include/errno.h). ___ 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: Porting python applications and meeting dependency requirements
On 8/12/18 2:52 PM, Carsten Larsen wrote: I am not so familiar with porting python applications. There seems to be some caveats, dependencies being one of them. Question is: Would it be difficult to make a port of The Onion Box? Source is on Github: https://github.com/ralphwetzel/theonionbox I added the port for theonionbox: https://www.freshports.org/security/theonionbox/ Regards, Yuri ___ 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"
Stage-qa doesn't complain about unstripped elfs in many cases
For example, on the misc/orange3 port: > $ make stage-qa > > Running Q/A tests (stage-qa) > [yuri@yv /usr/ports/misc/orange3]$ file ./work-py36/stage/usr/local/lib/python3.6/site-packages/Orange/widgets/utils/_grid_density.so > ./work-py36/stage/usr/local/lib/python3.6/site-packages/Orange/widgets/utils/_grid_density.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, not stripped This is because the stage-qa check only looks at .debug sections, and file(1) looks at more sections. My proposed partial fix was rejected: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230371 on the grounds that it goes against some other commit. So stage-qa doesn't check what it is supposed to check, and this is somehow ok. Should this stage-qa check be changed to just run file(1) and check if the output contains "not stripped" in it? What would be the downside of this? I also don't understand what is the downside of the rejected patch in bug#230371 that expands the list of sections. Yuri ___ 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"
Do you support creation of "chemistry" and "physics" virtual categories?
I assembled the lists of 50 ports for the chemistry virtual category, and 25 ports for the physics virtual category: https://reviews.freebsd.org/D13481#350005 Virtual categories are generally needed to assist users to find software that they need. The existing real and virtual categories are here: https://www.freebsd.org/ports/categories-grouped.html Some virtual categories there are very small, ex. "enlightenment" with 23 ports and "parallel" with 38 ports. Chemistry and physics are major sciences, and they deserve to have virtual categories. Do you support creation of "chemistry" and "physics" virtual categories? Thanks, Yuri ___ 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: SVN down or slow
On 7/29/18 10:43 AM, blubee blubeeme wrote: Has anyone else noticed that svn is getting this type of error trying to run svn: svn: E65: Error running context: No route to host This is likely due to network problems, not the subversion server itself. Yuri ___ 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: google-earth installs but fails to run
On 7/23/18 9:05 AM, tech-lists wrote: Is this a google earth problem or a linux-c6 one ? This is a well known problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221448 Yuri ___ 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: mupdf
On 07/14/18 13:45, Ajtim wrote: Update of mupdf to version 1.13.0,1 doesn't work on my FreeBSD 11.2-RELEASE (amd64): Fixed in rev.474665. Thanks for reporting! Yuri ___ 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: Is there an index of all central poudriere builds?
On 07/12/18 20:22, Adam Weinberger wrote: Every 11.x gets the same packages. They're built on the lowest supported version (11.1 here), but 11.2 and 11.1 pkg users get the same packages. Quarterly is NOT outdated. It is specifically and intentionally not latest-and-greatest. Whatever new pkg you're talking about, the whole point is that it is tested for ~3 mo in head before it arrives in quarterly. If you don't like it, you switch to head. That's what it's there for. Looking from a perspective of a simple user who keeps with the latest release, 11.2 users now don't get recent package updates. The advice "just switch to CURRENT" doesn't work because you shouldn't advise users to switch to the unreleased, unstable version, and they shouldn't even be bothered with such things. The advise to change to 11.1 also doesn't work for users, because why did we release 11.2 then? It isn't obvious what to tell to a user in this case. Then it is also illogical that while 11.1 was the latest release, the packages were same as in ports, and once 11.2 became the latest release, packages became delayed. Why does this change with the release number? I think that the right solution is to use the same packages for 11.2 that are used for 11.1. Yuri ___ 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: Is there an index of all central poudriere builds?
On 07/12/18 19:12, Jan Beich wrote: pkg(8) defaults to /quarterly set on -RELEASE since FreeBSD 10.2. https://svnweb.freebsd.org/changeset/base/333474 cinelerra-gg is missing on 2018Q3, so the package is only built for /latest until 2018Q4 branches sometime after 2018-10-01. http://beefy3.nyi.freebsd.org/data/latest-per-pkg/cinelerra-gg/ # 111amd64-quarterly http://beefy9.nyi.freebsd.org/data/latest-per-pkg/cinelerra-gg/ # 111amd64-default So 11.2 is the latest release, but is doesn't get any latest package updates? Quarterly is mostly for security patches, otherwise it is outdated. What should people do who install the latest FreeBSD release (11.2) and want some recently added packages? Yuri ___ 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: Is there an index of all central poudriere builds?
On 07/12/18 18:19, Kyle Evans wrote: Packages are built on the earliest supported release of a branch, so 11.1. They'll switch to 11.2 when 11.1 goes EOL. One user on 11.2 amd64 is trying to install the package cinelerra-gg, and pkg can't find it. I have 11.1 amd64, and this package installs fine. Where it is supposed to come on 11.2 and why is it not found? Yuri ___ 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: Is there an index of all central poudriere builds?
On 07/12/18 16:26, Jan Beich wrote: Do you meanhttps://pkg-status.freebsd.org/ or something else? I don't find 112amd64 among Package Builds there. Which server do packages come from when people install 11.2 amd64? Yuri ___ 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"
Is there an index of all central poudriere builds?
For example, this server http://package21.nyi.freebsd.org/ builds for 110amd64 and 111amd64. Some other builds can be found if to change 21 to 20 or 22, but I couldn't find 112amd64, for example. Is there an index of build servers by version/architecture? Yuri ___ 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: What the port license should be when software is "free for non-commercial use" with "click-to-accept" or clickwrap license?
On 07/02/18 16:11, Eugene Grosbein wrote: It does. See mail/dcc-dccd for example. But it doesn't ask to "agree" during 'pkg install dcc-dccd'. Yuri ___ 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"
What the port license should be when software is "free for non-commercial use" with "click-to-accept" or clickwrap license?
One software package has the custom license text that users need to click-to-accept in order to install it. Does 'pkg' support such license? Can it show the user the license text and ask the user to click "Agree" before installing the package? If not, I think this is a good feature to have. Yuri ___ 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"
Build logs are on IPv6-only hosts: it makes it difficult to sent such logs to other people
Build log URLs are IPv6-only, which makes them inaccessible for people without IPv6. One way to access IPv6-only sites is through the Tor network. But what happens when such log needs to be sent to other parties, and they also don't have IPv6? Now I need to explain to them how to install Tor, and how to set up the SOCKS5 proxy. This bug has been rejected: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228442 but IMO it should be fixed, and IPv4 addresses should be available. The advise "Please complain to your ISP" doesn't work in practice in such situation. example: http://beefy11.nyi.freebsd.org/data/head-i386-default/p472945_s335462/logs/pcl-pointclouds-1.8.1_5.log Yuri ___ 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"
net-p2p/qbittorrent needs to be unblocked by portmgr
Committing transaction... svn: E165001: Commit failed (details follow): svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output: Do not commit a port with FLAVORS without first getting approval from portmgr. Yuri ___ 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"
Is there any RSS feed or mailing list that informs users when new package version is available via pkg.freebsd.org?
One user asked me this question via e-mail, and I don't know the answer myself. Thanks! Yuri ___ 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: Visual Studio Code on FreeBSD / port request
On 06/04/18 06:51, Miroslav Lachman wrote:
Does somebody successfully run Visual Studio Code on FreeBSD?
https://github.com/Microsoft/vscode
I know my friends are running it on Ubuntu but I didn't found any
references how to run it on FreeBSD desktop.
This function, for example, would fail for freebsd:
https://github.com/Microsoft/vscode/blob/master/src/paths.js#L11 It is
likely to be one among many others.
No, npm-based projects can't be ported to FreeBSD. They download a lot
of things under the hood, that can't be fingerprinted.
Last time I tried, node projects are hit or miss: they depend on a lot
of other projects that can be automatically updated any time. It might
work one day, and not work the next day. It's also very insecure to run
an unvetted code direct off of github. Somebody might add a rimraf('*')
call as a matter of a mistake or a joke, and all your files will be
eliminated, and you will never know who did it. npm/node is certainly a
very volatile and insecure technology.
Yuri
___
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"
What is the right way to change the clang compiler version for one port?
When I need to use clang60, I add these lines:
LLVM_VER= 60
BUILD_DEPENDS+= clang${LLVM_VER}:devel/llvm${LLVM_VER}
CPP= clang-cpp${LLVM_VER}
CC= clang${LLVM_VER}
CXX= clang++${LLVM_VER}
This works, but it also prints this warning in poudriere:
[00:00:02] Gathering ports metadata
[00:00:02] Warning: (graphics/myport): clang60: not found
[00:00:02] Warning: (graphics/myport): make:
"/usr/ports/Mk/Uses/compiler.mk" line 75: warning: "clang60 --version"
returned non-zero status
[00:00:02] Warning: (graphics/myport): make:
"/usr/ports/Mk/Uses/compiler.mk" line 130: warning: "clang++60 -###
/dev/null 2>&1" returned non-zero status
[00:00:07] Calculating ports order and dependencies
Should this message be ignored (it's only a warning), or otherwise how
to fix it?
Thanks,
Yuri
___
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: Hydraulic simulation software
On 05/04/18 19:03, blubee blubeeme wrote: Are there any hydraulic simulation software in the FreeBSD ecosystem? Please provide examples of projects that you have in mind. Yuri ___ 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"
Python-2.7.14 breaks on 12-CURRENT
I've just re-created the 12-CURRENT amd64 poudriere jail, and python breaks with the latest ports tree: cc -c -fPIC -fno-strict-aliasing -O2 -pipe -fstack-protector -fno-strict-aliasing -DNDEBUG -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/include -fPIC -DPy_BUILD_CORE -o Modules/_math.o Modules/_math.c /wrkdirs/usr/ports/lang/python27/work/Python-2.7.14/Modules/_heapqmodule.c:600:21: warning: illegal character encoding in string literal [-Winvalid-source-encoding] [explanation by Franois Pinard]\n\ ^~~~ Include/Python.h:171:60: note: expanded from macro 'PyDoc_STRVAR' #define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str) ^ Include/Python.h:173:24: note: expanded from macro 'PyDoc_STR' #define PyDoc_STR(str) str ^ 1 warning generated. Yuri ___ 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"
https://bugs.freebsd.org fails with 502 Bad Gateway
___ 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: Not much reason to have */R-cran-* ports
On 03/20/18 11:20, Eugene Grosbein wrote: It is a bit funny you are bothered on 250 R-cran-* ports when we have 1908 p5-* ports, 964 py-* ports, 600 rubygem-* ports and 280 hs-* ports in the single ports/devel category. Are you planning to ban and remove p5 ports too? Most of them should be from CPAN. We had BSDPAN for some time even... You are missing the key differences: 1. Python and perl ports represent individually run software with their own executables, when R doesn't. R packages are only useful in the context of R, as building blocks of larger R programs only runnable in R environment. R packages are much more dependent on environment. 2. With python, there is a hope of having all major software pieces in ports. With R there is no such hope. There are thousands of individual small R packages, while we only have 250 in ports with no hope or reason to add another few thousands. Now, if I want to use some R package should I look it up in ports and try to port if it is missing? Of course not, I will just install it from R. It's much easier this way, Yuri ___ 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"
Not much reason to have */R-cran-* ports
There are more than 250 R-cran-* ports. They are R packages. The thing is that R has its own, very capable package manager which can find packages, download them, check hash, build, find upgrades. Every R-cran-* port can be easily installed through R itself, so there is really no need for these ports. These ports need to be maintained, updated, looked into when they break. This duplicates functionality that is already nicely supported by R itself, and only unnecessarily clogs the ports system. One only needs to click twice in RStudio to update all outdated R packages, it's so easy. FreeBSD should consider banning and removing them, in the same way as Go libraries are banned. Yuri ___ 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: sysutils/ipfs-go downloads pre-built binaries while sources are available
On 03/12/18 14:06, Kurt Jaeger wrote: Yes, but the boundary can not be drawn at the 'source' border. My fear is that we do not really understand where the border lies. In general this is true. However, in case of Go or C++ the boundary is clear. -) Yuri ___ 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: sysutils/ipfs-go downloads pre-built binaries while sources are available
On 03/12/18 13:42, Adam Weinberger wrote: While source is preferred over binary, we don’t delete ports just because they have binary blobs. Binary downloads have an entirely different trust model. You have to trust the producer of the binary, vs. with source code it is much more obvious what does it do. Neglect or misunderstanding of this difference leads to rampant spread of malware on Windows and cell phones. Yuri ___ 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"
sysutils/ipfs-go downloads pre-built binaries while sources are available
There should be no reason to download prebuilt executables for open source software. Binaries present security risk. It violates chapter 5.4 of PHB which mentions that MASTER_SITES/DISTNAME refers to "source archive", and for sysutils/ipfs-go it isn't a source archive. This port should be either deleted or reworked. Yuri ___ 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"
Why some python ports fail with build_fs_violation like this: usr/local/lib/python3.6/site-packages/dbus/__pycache__ ?
Examples: http://package21.nyi.freebsd.org/data/111amd64-default-qat/463452/logs/errors/py36-notify2-0.3.1.log http://package21.nyi.freebsd.org/data/111amd64-default-qat/463452/logs/errors/Carla-1.9.8.log Yuri ___ 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: poudriere: "Permission denied" in the extract phase?
On 02/26/18 17:11, Marcin Cieslak wrote: So I don't know what has changed and why but the temporary fix is to use "if" to check if the desired files are not already there, and then proceeding with "post-fetch" only if the files are not found. Some time back I was working on nodejs support: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204577 So far, I couldn't make it stable because after a week or two files fetched from the npm server change without an apparent reason. I will return to it to see if the situation improved. Yuri ___ 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: Go ports fail with fs violation: Error: Filesystem touched during build:,extra: root/.cache
On 02/28/18 13:15, Antoine Brodin wrote: Both examples do not use MAKE_ENV. Maybe all of them should be changed to use MAKE_ENV, and if it will also include XDG_DATA_HOME, the problem wil be gone? Yuri ___ 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: Go ports fail with fs violation: Error: Filesystem touched during build:,extra: root/.cache
On 02/28/18 13:07, Antoine Brodin wrote: No, HOME is already enough to fix the violation. The problem is that those ports/go.mk do fancy things and do not respect BUILD_ENV. Both examples don't use go.mk and still fail. Yuri ___ 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: Go ports fail with fs violation: Error: Filesystem touched during build:,extra: root/.cache
On 02/28/18 00:35, Antoine Brodin wrote:
Ports that use CONFIGURE_ENV / MAKE_ENV have this violation issue with
HOME=${WRKDIR}.
Maybe this should be added to GO_ENV and go ports should respect more
this environment.
PGo also tries "XDG_CACHE_HOME" when "GOCACHE" isn't defined.
Mk/ does define "XDG_DATA_HOME" in MAKE_ENV.
Maybe the right solution is to just add "XDG_CACHE_HOME" there?
Yuri
___
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"
Go ports fail with fs violation: Error: Filesystem touched during build:,extra: root/.cache
For example: http://package21.nyi.freebsd.org/data/111amd64-default-qat/462883/logs/errors/gogs-0.11.34_2.log http://package21.nyi.freebsd.org/data/111amd64-default-qat/462883/logs/errors/cryptoballot-g20170928.log Yuri ___ 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: poudriere: "Permission denied" in the extract phase?
On 02/25/18 05:37, Marcin Cieslak wrote: Yes, this is my private port that I am using to produce FreeBSD binaries for node-sass. Getting binary npm modules into our ports tree is another conversation. The problem here is that a whole thing worked for me before for months so I am aware of all those limitations for particular build phases (it took me long to figure out that). npm is an extremely volatile technology. Some package might work now, and then break in a week due to a dependency package update. It continuously automatically updates files that are downloaded as dependencies. NodeJS is largely incompatible with the FreeBSD ports system because of this volatility. NodeJS is also a very insecure technology. It brings files directly from github without any vetting. So if somebody will update some github package with malware, it is extremely likely that next day this malware will end up on your production servers. There is nobody in between, you have to always trust hundreds of parties. Yuri ___ 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"
If a submitted port is in "enlightenment" category, who should maintain it?
Can it/should it be assigned to enlightenm...@freebsd.org? Does enlightenm...@freebsd.org need to be asked if they want to maintain it? Or the submitter should maintain it? Yuri ___ 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: Why no `operator delete(void*, unsigned int)' on 10 i386?
On 02/18/18 22:46, Fernando Apesteguía wrote: Those are sized operators from c++14. Have you tried to compile with: -std=gnu++11? Thank you, but it didn't help in my case. Yuri ___ 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"
Why no `operator delete(void*, unsigned int)' on 10 i386?
I have one port failing on 10 i386 like this: > undefined reference to `operator delete(void*, unsigned int)' 11 amd64, 12 i386, 12 amd64 work fine. What might be a problem? Thanks, Yuri ___ 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"
Should mail/offlineimap be renamed into mail/py-offlineimap, because it is a python port?
If the port is a python port, but it doesn't have the "py-" prefix, should it be renamed now, or should it be left as it is? Thanks, Yuri ___ 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: First time porter seeks guidance on 'make package' (as user)
On 01/09/18 00:26, Mathieu Arnold wrote: What an insanely long and complicated method. As your own user: And, of course, the method is "insanely long and complicated" only because it actually explains how to set up "sudo" with ports such that there is no need to type password all the time. Cheers! Yuri ___ 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: SPDY-related ports should be deprecated, because the SPDY protocol is deprecated
On 01/11/18 08:24, Peter Beckman wrote: Might make sense to mark them as being deprecated and schedule for removal at some future date (6-12 months out?) to give people time to sunset support. Yes, this makes sense. Thanks! Yuri ___ 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"
SPDY-related ports should be deprecated, because the SPDY protocol is deprecated
The relevant ports are: net/p5-Net-SPDY www/mod_spdy www/spdylay Additionally, the SPDY option and dependency should be deleted in www/trafficserver. https://en.wikipedia.org/wiki/SPDY Thanks, Yuri ___ 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: First time porter seeks guidance on 'make package' (as user)
On 01/08/18 12:46, James E Keenan wrote:
Can someone offer guidance as to how to proceed?
As a root:
1. Check out the ports tree: svn checkout
https://svn.FreeBSD.org/ports/head /usr/ports (if you don't have it
checked out yet)
2. Change the ports tree to your user: chown -R {username}:users /usr/ports
3. Install sudo: pkg install sudo
4. Add yourself to sudoers: /usr/local/etc/sudoers (alternatively, add
yourself to the 'wheel' group and enable '%wheel ALL=(ALL) ALL' in the
sudoers file)
5. Add these 2 lines to sudoers:
Defaults env_reset,timestamp_timeout=240
Defaults !tty_tickets
6. In /etc/make.conf: add the line 'SU_CMD= /usr/local/bin/sudo -E sh -c'
As your own user:
7. Go into any port directory: cd /usr/ports/{category}/{portdir}
8. commands like 'make makesum', 'make install', 'make package', 'make
clean' will only require your password once in 4 hours
You can download tarballs, build, install, uninstall, build packages,
all without typing in your password more often than once in 240 minutes.
Using this method, you never need to do anything as a root again within
the ports tree.
How to work with poudriere - is another story. :-)
Hope this helps,
Yuri
___
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"
If the port is designed to have a Motif version, a GTK version, and a NOGUI version, can these be made into flavors, instead of options?
The port can be built to have the exact same UI but alternatively based on Motif, GTK, or no GUI at all. In each case, the plist is exactly the same. Can these be made into flavors: FLAVORS=nogui motif gtk ? My opinion: this is a good idea. The package is originally designed to have 2 UI incarnations, and flavors beautifully match this polymorphism. Is there any reason that flavors shouldn't be used in this case? Thanks, Yuri ___ 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: Ruby version question
On 01/06/18 14:17, Kevin Oberman wrote: You seem to assume that Ubuntu and FreeBSD both have the same version of Ruby installed. The current version in FreeBSD is 2.4.3. 2.3 is still available as lang/ruby23, but should only be used when some code won't work with 2.4. The Ubuntu system is still running 2.3. Have you checked for available upgrades? No, I don't assume that FreeBSD and Ubuntu have the same version. I assume that this command should return the version in the same format. Currently, it doesn't. Yuri ___ 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"
Ruby version question
In order to get a Ruby version, I run this command:
> $ ruby -r rbconfig -e 'C = RbConfig::CONFIG' -e 'puts C["ruby_version"]'
> 2.4
However, on Ubuntu 17.10 the same command returns 2.3.0 (with the minor
version of zero).
My question is which one is correct, or "more correct"? Should it rather
be 2.4.0? Or both are correct?
I recommended one upstream maintainer to get the current ruby version
using this command, and then to use 'pkg-config ruby-${THIS_VERSION}
--libs', but he says that Ubuntu prints it in a different format.
2.4 matches .pc file on FreeBSD, and doesn't on Ubuntu.
Is this a bug on Ubuntu? On FreeBSD?
Yuri
___
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: Any way to make pkg use 'sudo' instead of 'su' to install as root?
On 12/31/17 10:37, Kurt Jaeger wrote: In Mk/bsd.commands.mk I found SU_CMD, so maybe redefining SU_CMD works ? Thank you! Yuri ___ 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"
