Where are all of the packages for FreeBSD 13.0-RELEASE quarterly?
I have a system that I just upgraded to 13.0-RELEASE-p4 and I want to use packages to install software. I tried installing everything but many packages don't seem to be available. In particular here is a list of Python packages missing: ap24-py39-mod_wsgi py39-dateutil py39-docutils py39-matplotlib py39-ofxparse py39-openssl py39-pdfrw py39-pillow py39-pip py39-pycryptodome py39-PyGreSQL py39-reportlab py39-roman py39-sphinx py39-sphinx_rtd_theme py39-sphinxcontrib-websupport py39-weasyprint py39-xhtml2pdf I haven't moved to Python 3.10 yet but 3.9 has been out for a long time. Is 13.0 too new for a user system? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vybenetworks.com, VoIP: sip:da...@druid.net OpenPGP_signature Description: OpenPGP digital signature
Re: Where are all of the packages for FreeBSD 13.0-RELEASE quarterly?
Hi D'Arcy, The quarterly branch is on py38 as the default Python version, so if you want binary packages, install the py38- variants. If you need Python 3.9 variants of these packages, you have to build them yourself, e.g. with Poudriere and suitable configuration for your set to set up Python 3.9 as the default version. Yours, Robert Clausecker Am Tue, Sep 21, 2021 at 05:08:57AM -0400 schrieb D'Arcy Cain: > I have a system that I just upgraded to 13.0-RELEASE-p4 and I want to use > packages to install software. I tried installing everything but many > packages don't seem to be available. In particular here is a list of Python > packages missing: > > ap24-py39-mod_wsgi > py39-dateutil > py39-docutils > py39-matplotlib > py39-ofxparse > py39-openssl > py39-pdfrw > py39-pillow > py39-pip > py39-pycryptodome > py39-PyGreSQL > py39-reportlab > py39-roman > py39-sphinx > py39-sphinx_rtd_theme > py39-sphinxcontrib-websupport > py39-weasyprint > py39-xhtml2pdf > > I haven't moved to Python 3.10 yet but 3.9 has been out for a long time. Is > 13.0 too new for a user system? > > -- > D'Arcy J.M. Cain | Democracy is three wolves > http://www.druid.net/darcy/| and a sheep voting on > +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. > IM: da...@vybenetworks.com, VoIP: sip:da...@druid.net > -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments
Can a committer look at ports/258359?
Maintainer timeout. It's a tiny bug fix in Mk/Uses/go.mk that doesn't require any knowledge of the Go language.
Re: Bacula and S3
On 9/15/21 6:14 PM, Dan Langille wrote: Andrea Venturoli wrote on 9/15/21 7:49 AM: Hello. I see Bacula 11 from ports is built without such a plugin. Any reason? Is it possible to enable it? Some dependency missing? I'd just try, but perhaps you have gone this way before and can warn me I'd just be waisting my time :) I know of no reason. Please try it. :) It will not be wasted time. Thanks. So far I was able to compile and run. I've made a separate port for libs3 and added an option to bacula11-server (which will depend on the former). Unfortunately I'm still far from being able to test this properly. Are you interested in seeing this? Do you want me to send you my modifications? Open a bug report? Other? bye av.
MySQL build failure
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)Hello, I have a FreeBSD 12.2-RELEASE-p10 GENERIC amd64 box. I have been using mysql80-server as a database server for some web services that live on that box. After trying to update from version 8.0.25_1 to the latest 8.0.26 using poudriere to build the port, i always get a build failure with the following message in the log: [100%] Linking CXX executable routerfuzz_router_uricd /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/routerfuzz_router_uri.dir/link.txt --verbose=1/usr/bin/clang++ -std=c++14 -fno-omit-frame-pointer -ftls-model=initial-exec -O2 -pipe -march=native -fPIC -DNDEBUG -malign-double -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -std=c++14 -Wall -Wextra -Wformat-security -Wvla -Wundef -Wmissing-format-attribute -Woverloaded-virtual -Wcast-qual -Wno-null-conversion -Wno-unused-private-field -Wconditional-uninitialized -Wdeprecated -Wextra-semi -Wheader-hygiene -Wnon-virtual-dtor -Wundefined-reinterpret-cast -Winconsistent-missing-destructor-override -Winconsistent-missing-override -Wshadow-field -Wno-deprecated -ffunction-sections -fdata-sections -O2 -pipe -march=native -fPIC -DNDEBUG -malign-double -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -std=c++14 -Wl,-rpath,/usr/local/lib -fstack-protector-strong -fsanitize=fuzzer CMakeFiles/routerfuzz_router_uri.dir/fuzz_router_uri.cc.o CMakeFiles/routerfuzz_router_uri.dir/__/__/src/router/src/uri.cc.o CMakeFiles/routerfuzz_router_uri.dir/__/__/src/router/src/utils.cc.o -o routerfuzz_router_uri -Wl,-rpath,/wrkdirs/usr/ports/databases/mysql80-server/work/.build/library_output_directory:/usr/local/lib -pthread ../../../library_output_directory/libmysqlharness.so.1 ../../../archive_output_directory/libmysqlclient.a /usr/local/lib/libssl.so /usr/local/lib/libcrypto.so ../../../archive_output_directory/libmysys.a ../../../archive_output_directory/libstrings.a ../../../archive_output_directory/libmysys.a ../../../archive_output_directory/libstrings.a ../../../archive_output_directory/libmytime.a -pthread /usr/lib/libz.so /usr/local/lib/libzstd.so -lm -lrt -lexecinfo -L/usr/local/lib -lunwind /usr/local/lib/libssl.so /usr/local/lib/libcrypto.socd /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers && /usr/local/bin/cmake -E remove_directory /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers/corpus/routerfuzz_router_uricd /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers && /usr/local/bin/cmake -E make_directory /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers/corpus/routerfuzz_router_uricd /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers && /usr/local/bin/cmake -E remove_directory /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers/artifacts/routerfuzz_router_uricd /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers && /usr/local/bin/cmake -E make_directory /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers/artifacts/routerfuzz_router_uriPreparing corpus for routerfuzz_router_uricd /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers && ./routerfuzz_router_uri -merge=1 -verbosity=0 -merge_control_file="/wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers/routerfuzz_router_uri.control" /wrkdirs/usr/ports/databases/mysql80-server/work/mysql-8.0.26/router/tests/fuzzers/corpus/fuzz_router_uri /wrkdirs/usr/ports/databases/mysql80-server/work/.build/router/tests/fuzzers/corpus/routerfuzz_router_uri 2> /dev/null*** Signal 4make[3]: *** router/tests/fuzzers/routerfuzz_router_uri removedStop.make[3]: stopped in /wrkdirs/usr/ports/databases/mysql80-server/work/.build*** Error code 1Stop.make[2]: stopped in /wrkdirs/usr/ports/databases/mysql80-server/work/.build*** Error code 1Stop.make[1]: stopped in /wrkdirs/usr/ports/databases/mysql80-server/work/.build*** Error code 1Stop.make: stopped in /usr/ports/databases/mysql80-server=>> Cleaning up wrkdir===> Cleaning for mysql80-server-8.0.26build of databases/mysql80-server | mysql80-server-8.0.26 ended at Fri Sep 17 02:48:58 EEST 2021build time: 05:21:53!!! build failure encountered !!! Any help would be greatly appreciated Thank you for your time. - Nikos Kastanas email: n.kasta...@zerotronic.com
Makefiles with a space in the name
Hi, Found some interesting Makefiles today: $ cd /usr/ports; find . -name "Makefile " ./french/mythes/Makefile ./textproc/sk-mythes/Makefile ./textproc/it-hyphen/Makefile ./textproc/ro-mythes/Makefile ./textproc/cs-mythes/Makefile ./textproc/el-hyphen/Makefile ./textproc/sk-hyphen/Makefile ./textproc/it-mythes/Makefile ./textproc/en-mythes/Makefile ./textproc/ro-hyphen/Makefile ./textproc/lt-hyphen/Makefile ./textproc/cs-hyphen/Makefile ./textproc/nl-hyphen/Makefile ./textproc/id-hyphen/Makefile ./textproc/sv-mythes/Makefile ./textproc/hyphen/Makefile ./textproc/bg-mythes/Makefile ./textproc/es-hyphen/Makefile ./textproc/sl-mythes/Makefile ./textproc/is-hyphen/Makefile ./textproc/nl-mythes/Makefile ./textproc/bg-hyphen/Makefile ./textproc/es-mythes/Makefile ./textproc/sl-hyphen/Makefile ./russian/mythes/Makefile ./russian/hyphen/Makefile ./hungarian/hyphen/Makefile ./hungarian/mythes/Makefile ./portuguese/hyphen/Makefile ./portuguese/mythes/Makefile ./polish/hyphen/Makefile ./polish/mythes/Makefile ./ukrainian/mythes/Makefile ./ukrainian/hyphen/Makefile ./german/hyphen/Makefile They all have a space at the end of there names. Regards, Ronald.
Re: Makefiles with a space in the name
On Tue, Sep 21, 2021 at 06:07:29PM +0200, Ronald Klop wrote:
> Found some interesting Makefiles today:
>
> $ cd /usr/ports; find . -name "Makefile "
> ./french/mythes/Makefile
> {snipping for brevity}
>
> They all have a space at the end of there names.
>
> Regards,
> Ronald.
sunpoet@ mistakenly added a bunch of Makefiles with spaces at the end of
their names:
https://github.com/freebsd/freebsd-ports/commit/72664fc2b4d33ca3ae39c8e7ab6f8fa85c08bd63
https://github.com/freebsd/freebsd-ports/tree/72664fc2b4d33ca3ae39c8e7ab6f8fa85c08bd63/french/mythes
The additional files were removed (i.e. issue fixed) by bdrewery@
shortly after:
https://github.com/freebsd/freebsd-ports/commit/63b6f938109571011e834d4f1e97c248c1919102
Make sure your ports git checkout matches what's currently on the git
server.
--
| Jeremy Chadwick jdc_at_koitsu.org |
| UNIX Systems Administrator PGP 0x2A389531 |
| Making life hard for others since 1977.|
Re: Bacula and S3
Andrea Venturoli wrote on 9/21/21 10:13 AM: On 9/15/21 6:14 PM, Dan Langille wrote: Andrea Venturoli wrote on 9/15/21 7:49 AM: Hello. I see Bacula 11 from ports is built without such a plugin. Any reason? Is it possible to enable it? Some dependency missing? I'd just try, but perhaps you have gone this way before and can warn me I'd just be waisting my time :) I know of no reason. Please try it. :) It will not be wasted time. Thanks. So far I was able to compile and run. Good. Congratulations. That's good work. I've made a separate port for libs3 and added an option to bacula11-server (which will depend on the former). Unfortunately I'm still far from being able to test this properly. What is needed? Are you interested in seeing this? Do you want me to send you my modifications? Open a bug report? Other? I don't have time to add another project for testing. I am sure others will be interested in testing. Please create a PR and attach a patch. If the new feature is off by default, it will not affect existing installations. Interested parties can enable it and test it themselves Thank you. -- Dan Langille d...@langille.org
Re: armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores
On 2021-Sep-20, at 17:47, Mark Millard wrote:
> On 2021-Sep-20, at 15:10, Mark Millard wrote:
>
>> On 2021-Sep-20, at 13:58, Mark Millard wrote:
>>
>>>
>>> On 2021-Sep-20, at 12:54, Lucas Nali de Magalhães
>>> wrote:
>>>
On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain
wrote:(…)
(…)
The HoneyComb failure looks to me like like hitting the process
size limitations for armv7, something that did not happen on the
MACCHIATObin Double Shot or RPi4B (fewer cores).
It looks to me like 32-bit architectures (such as armv7) should
possibly have the multi-threaded link disabled by default
for FreeBSD unless ports are adjusted to disable multi-threaded
individually.
(…)
>>>
>>> There are a few a few problems with your analysis: 32 and 64 bit
>>> architectures sizes aren't that small and much of all OSes today
>>> evolved around extending these sizes. This doesn't means that one
>>> can not use all of it but that the analysis requires a little more "salt".
>>> So it looks like you used all of something… maybe you need to adjust
>>> some numbers somewhere.
>>>
>>> Then, processes and threads existed far before the existence of
>>> multicore desktop CPUs. Running with more threads/processes than
>>> the number of cores you have only means that some swapping *may be*
>>> necessary. If you have enough RAM, swap isn't really necessary. So I think
>>> this makes your suggestion ridiculous.
>>>
>>
>>
>> Sorry: a stray click lead to an accidental send of a reply with
>> no additional content.
>>
>>
>> The above did not indicate any specific errors for me to
>> fix, experiments to try, or even any specific alternate hypothesis
>> for the inability to allocate in the failing context that I
>> described. So I've no clue of a good way to make any progress from
>> what is written. I see no reason to withdraw the suggestion based
>> on the above. I'm well aware that there are tradeoffs and that
>> the suggestion might not be used even if I've gotten everything
>> correct about the failure's cause.
>>
>>
>> After the HoneyComb system is done with the bulk -a activity
>> targeting aarch64, I'l likely try bulk -w targeting armv7 in hopes
>> of getting a .core for the failure. That will be days away and the
>> rebuild attempt for emulators/mame will have to rebuild the
>> prerequisite ports (the armv7 packages were deleted before starting
>> the aarch64 targeting builk -a). So even more time.
>
> [I discovered that the aarch64 targeting bulk -a would not
> sucessfully build something I wanted in the bulk -a activity.
> So I stopped that build and will restart at some point after
> updating /usr/ports/ to a version that should build that port.]
>
> Well, my attempt to build llvm12 with debug info, when targeting
> armv7, did not go well. The intent was so that a backtrace
> of its linker would be useful to me.
>
> So this type of experiment proved not useful.
>
>> I'd consider other evidence gathering alternatives that might
>> better indicate specifically why the allocation fails in the
>> failing context. But the large nubmer of build steps prior to
>> the failing link and such probably limit the options.
I created a portmamster/Makefile port building context in which
the failing link also occurs, without waiting 11 hr+ for
other parts of mame to build each time after the first. I
established the context with already built prerequeisite packages
that poudriere had aleady made. So only emulators/mame was being
built.
Then I tried adding an LDFLAGS initial definition to control the
threading in that environment to be just one thread:
portmaster -CGKDg -mLDFLAGS=-Wl,--threads=1 --packages-build emulators/mame
The result was:
. . .
gmake[2]: Entering directory
'/usr/ports/emulators/mame/work/mame-mame0226/build/projects/sdl/mame/gmake-freebsd-clang'
Linking mame...
Compiling src/lib/netlist/prg/nltool.cpp...
. . .
In other words: no more failure for the link that had been failing.
(Note: I was able to see the link command and its --threads=1 in
top.)
Simply avoiding having the extra threads allowed the link
to complete --because it needed less memory to be allocated.
The rest of the build completed as well.
Such is important for native builds via poudreire on systems
with many "FreeBSD cpus" for armv7, armv6, and such. I'm
not claiming emulators/maem would be the only example, it
is just an example that I noticed.
Note: in my context I've set the default llvm to llvm12 so
that is in use.
I was interstested in what sort of problems bulk -a would have on
actual armv7 capable hardware. Otherwise emulators/mame is not
something that I use.
Side notes . . .
The GCC_LDFLAGS="${LDFLAGS}" in /usr/ports/emulators/mame/Makefile
does nothing for the llvm based build that is used as far as I could
tell. Listing such a thread control option in GCC_LDFLAGS did not
result in the link command having the option (and so it
