FreeBSD ports you maintain which are out of date

2024-04-23 Thread portscout 
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/chrom...@freebsd.org.html


Port| Current version | New version
+-+
www/chromium| 124.0.6367.60   | 125.0.6422.4
+-+
www/ungoogled-chromium  | 124.0.6367.60   | 
124.0.6367.61
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!

[Bug 278560] www/chromium 124.0.6367.60 on 13.2-RELEASE-p10 compile failure

2024-04-23 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278560

Bug ID: 278560
   Summary: www/chromium 124.0.6367.60 on 13.2-RELEASE-p10 compile
failure
   Product: Ports & Packages
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: Individual Port(s)
  Assignee: chrom...@freebsd.org
  Reporter: geo...@m5p.com
 Flags: maintainer-feedback?(chrom...@freebsd.org)
  Assignee: chrom...@freebsd.org

./../third_party/ffmpeg/libavutil/thread.h:228:19: error: call to undeclared
function 'pthread_setname_np'; ISO C99 and later do not support implicit
function declarations [-Wimplicit-function-declaration]
  228 | ret = AVERROR(pthread_setname_np(pthread_self(), name));
  |   ^
m../../third_party/ffmpeg/libavutil/thread.h:228:19: note: did you mean
'pthread_set_name_np'?
/usr/include/pthread_np.h:67:6: note: 'pthread_set_name_np' declared here
   67 | void pthread_set_name_np(pthread_t, const char *);
  |  ^
1 error generated.


In short, the problem seems to be that HAVE_PTHREAD_SETNAME_NP was set during
the configuration phase of things instead HAVE_PTHREAD_SET_NAME_NP.  In order
to be able to compile, I changed lines 225 and following of
third_party/ffmpeg/libavutil/thread.h to:

static inline int ff_thread_setname(const char *name)
{
int ret = 0;

pthread_set_name_np(pthread_self(), name);

return ret;
}


Clearly not the right fix!  But I'm testing right now (i.e. for at least the
next couple of hours) to see if it lets me finish the compile.  Perhaps an
expert on the configuration phase can point me in the right direction.

-- 
You are receiving this mail because:
You are the assignee for the bug.

maintainer-feedback requested: [Bug 278560] www/chromium 124.0.6367.60 on 13.2-RELEASE-p10 compile failure

2024-04-23 Thread bugzilla-noreply 
Bugzilla Automation  has asked freebsd-chromium (Nobody)
 for maintainer-feedback:
Bug 278560: www/chromium 124.0.6367.60 on 13.2-RELEASE-p10 compile failure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278560



--- Description ---
./../third_party/ffmpeg/libavutil/thread.h:228:19: error: call to undeclared
function 'pthread_setname_np'; ISO C99 and later do not support implicit
function declarations [-Wimplicit-function-declaration]
  228 | ret = AVERROR(pthread_setname_np(pthread_self(), name));
  |   ^
m../../third_party/ffmpeg/libavutil/thread.h:228:19: note: did you mean
'pthread_set_name_np'?
/usr/include/pthread_np.h:67:6: note: 'pthread_set_name_np' declared here
   67 | void pthread_set_name_np(pthread_t, const char *);
  |  ^
1 error generated.


In short, the problem seems to be that HAVE_PTHREAD_SETNAME_NP was set during
the configuration phase of things instead HAVE_PTHREAD_SET_NAME_NP.  In order
to be able to compile, I changed lines 225 and following of
third_party/ffmpeg/libavutil/thread.h to:

static inline int ff_thread_setname(const char *name)
{
int ret = 0;

pthread_set_name_np(pthread_self(), name);

return ret;
}


Clearly not the right fix!  But I'm testing right now (i.e. for at least the
next couple of hours) to see if it lets me finish the compile.  Perhaps an
expert on the configuration phase can point me in the right direction.