FreeBSD ports you maintain which are out of date
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/po...@freebsd.org.html Port| Current version | New version +-+ finance/moneymanagerex | 1.2.7 | v1.5.3 +-+ math/spblas | 1_02| 1_03 +-+ 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!
Re: mounting Google Drive under FreeBSD?
On Mon, 14 Jun 2021, at 03:04, Robert Huff wrote: > > Hello: > Research suggests net/grive2 is the correct tool. > Is anyone using this, and if so what is your experience? > > > Hopefully, > > > Robert Huff > > > I've not used that but https://rclone.org/drive/ worked fine previously, I have used it also for Dropbox and it's an adequate solution. A+ Dave
Re: mounting Google Drive under FreeBSD?
Hi, I have no experience with grive2, but I have with rclone, https://www.freshports.org/net/rclone/, which should also be able to do this. I use rclone to mount webdav type shares, See https://blog.socruel.nu/freebsd/mount-webdav-with-rclone-on-freebsd.html. Cheers, Lars On 6/14/2021 5:04 AM, Robert Huff wrote: Hello: Research suggests net/grive2 is the correct tool. Is anyone using this, and if so what is your experience? Hopefully, Robert Huff
Restarting poudriere
Thanks to much support on the lists it looks like poudriere _almost_ worked on the Pi3. In earlier tries builds of llvm10 failed from lack of memory. Restraining poudriere with -J 2 and MAKE_JOBS_NUMBER=2 in /etc/make.conf, along with turning off use of tmpfs appears to have relieved the excess memory pressure. Restarting the poudriere session still fails with llvm10, reporting c++: error: no such file or directory: '/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/Hexagon/Disassembler/HexagonDisassembler.cpp' c++: error: no input files ninja: build stopped: subcommand failed. *** Error code 1 Similarly, the build of rust stopped with 10: fatal error: 'PPCTargetMachine.h' file not found #include "PPCTargetMachine.h" ^~~~ 1 error generated. ninja: build stopped: subcommand failed. thread 'main' panicked at ' command did not execute successfully, got: exit code: 1 It looks like artifacts from the previous build failures are somehow persisting into subsequent work. There are no indications of memory or swap insufficiency. Can anybody suggest a fix, short of starting over from scratch? Perhaps building the offending packages individually, or in separate jails? I've been using the same jail for all attempts so far. Thanks for reading, and everyone's help! bob prohaska
Re: Restarting poudriere
On Mon, 14 Jun 2021 09:28:39 -0700 bob prohaska wrote: > Thanks to much support on the lists it looks like poudriere _almost_ > worked on the Pi3. > > In earlier tries builds of llvm10 failed from lack of memory. > Restraining poudriere with -J 2 and MAKE_JOBS_NUMBER=2 in > /etc/make.conf, along with turning off use of tmpfs appears to have > relieved the excess memory pressure. > > Restarting the poudriere session still fails with llvm10, reporting What do you mean by "restarting"? How do you invoke poudriere exactly? -m > > c++: error: no such file or directory: > '/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/Hexagon/Disassembler/HexagonDisassembler.cpp' > c++: error: no input files ninja: build stopped: subcommand failed. > *** Error code 1 > > Similarly, the build of rust stopped with > > 10: fatal error: 'PPCTargetMachine.h' file not found > #include "PPCTargetMachine.h" > ^~~~ > 1 error generated. > ninja: build stopped: subcommand failed. > thread 'main' panicked at ' > command did not execute successfully, got: exit code: 1 > > It looks like artifacts from the previous build failures are somehow > persisting into subsequent work. There are no indications of memory > or swap insufficiency. > > Can anybody suggest a fix, short of starting over from scratch? > Perhaps building the offending packages individually, or in separate > jails? I've been using the same jail for all attempts so far. > > Thanks for reading, and everyone's help! > > bob prohaska -- Michael Gmelin
INDEX build failed for 11.x
INDEX build failed with errors: Generating INDEX-11 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- --- describe.astro --- --- describe.audio --- --- describe.benchmarks --- --- describe.biology --- --- describe.cad --- --- describe.chinese --- --- describe.comms --- --- describe.converters --- --- describe.databases --- --- describe.deskutils --- --- describe.devel --- --- describe.dns --- --- describe.editors --- --- describe.emulators --- --- describe.finance --- --- describe.french --- --- describe.ftp --- [...] --- describe.print --- --- describe.russian --- --- describe.science --- --- describe.security --- --- describe.shells --- --- describe.sysutils --- --- describe.textproc --- --- describe.ukrainian --- --- describe.vietnamese --- --- describe.www --- --- describe.x11 --- --- describe.x11-clocks --- --- describe.x11-drivers --- --- describe.x11-fm --- --- describe.x11-fonts --- --- describe.x11-servers --- --- describe.x11-themes --- --- describe.x11-toolkits --- --- describe.x11-wm --- Done. make_index: /home/indexbuild/tindex/ports/devel/rubygem-aws-sdk-resources: no entry for /home/indexbuild/tindex/ports/devel/rubygem-aws-sdk-proton Committers on the hook: arr...@freebsd.org c...@freebsd.org fern...@freebsd.org jbe...@freebsd.org j...@freebsd.org kbowl...@freebsd.org mar...@freebsd.org o...@freebsd.org sunp...@freebsd.org Most recent Git update was: biology/Makefile biology/peak-classifier/Makefile biology/peak-classifier/distinfo biology/peak-classifier/pkg-descr biology/peak-classifier/pkg-plist converters/pecl-igbinary/Makefile converters/pecl-igbinary/distinfo databases/mongodb50/Makefile databases/mongodb50/distinfo databases/pecl-memcached/Makefile databases/py-fakeredis/Makefile databases/py-fakeredis/distinfo databases/py-geoalchemy2/Makefile databases/py-geoalchemy2/distinfo databases/py-marshmallow-sqlalchemy/Makefile databases/py-marshmallow-sqlalchemy/distinfo databases/py-sqlalchemy-utils/Makefile databases/py-sqlalchemy-utils/distinfo databases/py-sqlalchemy14/Makefile databases/py-sqlalchemy14/distinfo databases/py-tiledb/Makefile databases/py-tiledb/distinfo databases/py-tiledb/files/patch-setup.py devel/Makefile devel/git-filter-repo/Makefile devel/git-filter-repo/distinfo devel/git-filter-repo/files/git-filter-repo.1.in devel/git-filter-repo/files/patch-Makefile devel/git-filter-repo/pkg-descr devel/git-filter-repo/pkg-plist devel/google-styleguide/Makefile devel/google-styleguide/distinfo devel/hs-haskell-language-server/Makefile devel/ignition-common/Makefile devel/p5-Data-Dump-Color/Makefile devel/p5-Data-Dump-Color/distinfo devel/p5-ExtUtils-CppGuess/Makefile devel/p5-ExtUtils-CppGuess/distinfo devel/p5-Git-Repository/Makefile devel/p5-Git-Repository/distinfo devel/p5-Syntax-Keyword-Try/Makefile devel/p5-Syntax-Keyword-Try/distinfo devel/p5-Term-TablePrint/Makefile devel/p5-Term-TablePrint/distinfo devel/p5-Test2-Harness/Makefile devel/p5-Test2-Harness/distinfo devel/p5-XS-Parse-Keyword/Makefile devel/p5-XS-Parse-Keyword/distinfo devel/p5-XS-Parse-Keyword/pkg-descr devel/p5-XS-Parse-Keyword/pkg-plist devel/pecl-protobuf/Makefile devel/pecl-protobuf/distinfo devel/py-astroid/Makefile devel/py-astroid/distinfo devel/py-azure-core/Makefile devel/py-azure-core/distinfo devel/py-black/Makefile devel/py-black/distinfo devel/py-cmd2/Makefile devel/py-cmd2/distinfo devel/py-constantly/Makefile devel/py-dask/Makefile devel/py-dask/distinfo devel/py-dataclasses-json/Makefile devel/py-dataclasses-json/distinfo devel/py-distributed/Makefile devel/py-distributed/distinfo devel/py-fastimport/Makefile devel/py-fastimport/distinfo devel/py-flit-core/files/setup.py devel/py-fsspec/Makefile devel/py-fsspec/distinfo devel/py-google-cloud-iam/Makefile devel/py-google-cloud-iam/distinfo devel/py-hypothesis/Makefile devel/py-hypothesis/distinfo devel/py-ipdb/Makefile devel/py-ipdb/distinfo devel/py-ipdb/pkg-descr devel/py-jupyter-server-mathjax/Makefile devel/py-jupyter-server-mathjax/distinfo devel/py-keystonemiddleware/Makefile devel/py-keystonemiddleware/distinfo devel/py-multitasking/Makefile devel/py-multitasking/distinfo devel/py-multitasking/pkg-descr devel/py-os-brick/Makefile devel/py-os-brick/distinfo devel/py-osprofiler/Makefile devel/py-osprofiler/distinfo devel/py-pint-pandas/Makefile devel/py-pint-pandas/distinfo devel/py-pint-pandas/pkg-descr devel/py-pip-licenses/Makefile devel/py-pip-licenses/distinfo devel/py-pkgconfig/Makefile devel/py-pkgconfig/distinfo devel/py-pkgconfig/pkg-descr devel/py-pooch/Makefile devel/py-pooch/distinfo devel/py-prance/Makefile devel/py-prance/distinfo devel/py-pylev/Makefile devel/py-pylev/distinfo devel/py-python-gitlab/Makefile devel/py-python-gitlab/distinfo devel/py-rtree/Makefile devel/py-typing-inspect/Makefile devel/py-typing-inspect/distinfo devel/pylint/Makefile devel/pylint/distinfo devel/pylint/files/patch-setup.cfg devel/re2/Makefile devel/re2/distinfo devel/rubygem-async-io/Mak
Re: Restarting poudriere
On Mon, Jun 14, 2021 at 06:46:52PM +0200, Michael Gmelin wrote: > > > On Mon, 14 Jun 2021 09:28:39 -0700 > > What do you mean by "restarting"? > How do you invoke poudriere exactly? > As root, poudriere bulk -J 2 -j main x11-wm/lxqt www/chromium > testbuild.log Sorry for the omission, thanks for reading! bob prohaska
Re: Restarting poudriere
bob prohaska wrote on Date: Mon, 14 Jun 2021 09:28:39 -0700 : > Thanks to much support on the lists it looks like poudriere _almost_ > worked on the Pi3. I'm presuming the RPi3B+ is being used as aarch64 instead of armv7. > In earlier tries builds of llvm10 failed from lack of memory. Restraining > poudriere with -J 2 and MAKE_JOBS_NUMBER=2 in /etc/make.conf, along with > turning off use of tmpfs appears to have relieved the excess memory pressure. > > Restarting the poudriere session still fails with llvm10, reporting > > c++: error: no such file or directory: > '/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/Hexagon/Disassembler/HexagonDisassembler.cpp' > c++: error: no input files > ninja: build stopped: subcommand failed. > *** Error code 1 > > Similarly, the build of rust stopped with > > 10: fatal error: 'PPCTargetMachine.h' file not found > #include "PPCTargetMachine.h" > ^~~~ > 1 error generated. > ninja: build stopped: subcommand failed. > thread 'main' panicked at ' > command did not execute successfully, got: exit code: 1 > > It looks like artifacts from the previous build failures are somehow > persisting into subsequent work. poudriere does not do that. Each builder (job) is started from scratch, only reusing already built packages (via reinstallation in the temporary jail). That includes its jail-local /wrkdirs/. . . content being built up from scratch (from distribution files). > There are no indications of memory > or swap insufficiency. > > Can anybody suggest a fix, short of starting over from scratch? > Perhaps building the offending packages individually, or in separate > jails? I've been using the same jail for all attempts so far. I will note that on arm (aarch64 and armv7) I use: # more /usr/local/etc/poudriere.d/options/devel_llvm10/options # This file is auto-generated by 'make config'. # Options for llvm10-10.0.1_3 _OPTIONS_READ=llvm10-10.0.1_3 _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=BE_AMDGPU OPTIONS_FILE_SET+=CLANG OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=EXTRAS OPTIONS_FILE_SET+=LIT OPTIONS_FILE_SET+=LLD OPTIONS_FILE_SET+=LLDB OPTIONS_FILE_SET+=LLD_LINK OPTIONS_FILE_SET+=OPENMP OPTIONS_FILE_UNSET+=PYCLANG OPTIONS_FILE_UNSET+=BE_FREEBSD OPTIONS_FILE_SET+=BE_NATIVE OPTIONS_FILE_UNSET+=BE_STANDARD in part in order to avoid building for targeting non-arm architectures. So: no Hexagon or powerpc* . (Less time wasted in my context.) Because of that use, I'm unsure if I would get the same as you report from using BE_FREEBSD or BE_STANDARD instead on aarch64. It is possible to have poudriere produce a (compressed) tar of the /wrkdirs/usr/ports/devel/llvm10/work/ content that can later be extracted someplace and looked at. Producing these for llvm10 tends to take significant time once it starts. The files are put at paths that look like: /usr/local/poudriere/data/wrkdirs/JAILNAME/default/* Depending on your poudriere.conf content, you might already have such a compressed tar. But I'm not sure that you would want to see what was under: . . ./llvm-10.0.1.src/lib/Target/Hexagon/. . . or if . . ./llvm-10.0.1.src/lib/Target/Hexagon/ even exists. (I'm not sure what you would do with the information beyond reporting it.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: Restarting poudriere
On 2021-Jun-14, at 12:03, Mark Millard wrote: > bob prohaska wrote on > Date: Mon, 14 Jun 2021 09:28:39 -0700 : > >> Thanks to much support on the lists it looks like poudriere _almost_ >> worked on the Pi3. > > I'm presuming the RPi3B+ is being used as aarch64 instead > of armv7. > >> In earlier tries builds of llvm10 failed from lack of memory. Restraining >> poudriere with -J 2 and MAKE_JOBS_NUMBER=2 in /etc/make.conf, along with >> turning off use of tmpfs appears to have relieved the excess memory pressure. >> >> Restarting the poudriere session still fails with llvm10, reporting >> >> c++: error: no such file or directory: >> '/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/Hexagon/Disassembler/HexagonDisassembler.cpp' >> c++: error: no input files >> ninja: build stopped: subcommand failed. >> *** Error code 1 >> >> Similarly, the build of rust stopped with >> >> 10: fatal error: 'PPCTargetMachine.h' file not found >> #include "PPCTargetMachine.h" >> ^~~~ >> 1 error generated. >> ninja: build stopped: subcommand failed. >> thread 'main' panicked at ' >> command did not execute successfully, got: exit code: 1 >> >> It looks like artifacts from the previous build failures are somehow >> persisting into subsequent work. > > poudriere does not do that. Each builder (job) is started > from scratch, only reusing already built packages (via > reinstallation in the temporary jail). That includes its > jail-local /wrkdirs/. . . content being built up from > scratch (from distribution files). > >> There are no indications of memory >> or swap insufficiency. >> >> Can anybody suggest a fix, short of starting over from scratch? >> Perhaps building the offending packages individually, or in separate >> jails? I've been using the same jail for all attempts so far. > > I will note that on arm (aarch64 and armv7) I use: > > # more /usr/local/etc/poudriere.d/options/devel_llvm10/options > # This file is auto-generated by 'make config'. > # Options for llvm10-10.0.1_3 > _OPTIONS_READ=llvm10-10.0.1_3 > _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK > OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD > OPTIONS_FILE_SET+=BE_AMDGPU > OPTIONS_FILE_SET+=CLANG > OPTIONS_FILE_SET+=DOCS > OPTIONS_FILE_SET+=EXTRAS > OPTIONS_FILE_SET+=LIT > OPTIONS_FILE_SET+=LLD > OPTIONS_FILE_SET+=LLDB > OPTIONS_FILE_SET+=LLD_LINK > OPTIONS_FILE_SET+=OPENMP > OPTIONS_FILE_UNSET+=PYCLANG > OPTIONS_FILE_UNSET+=BE_FREEBSD > OPTIONS_FILE_SET+=BE_NATIVE > OPTIONS_FILE_UNSET+=BE_STANDARD > > in part in order to avoid building for targeting non-arm > architectures. So: no Hexagon or powerpc* . (Less time > wasted in my context.) > > Because of that use, I'm unsure if I would get the same > as you report from using BE_FREEBSD or BE_STANDARD > instead on aarch64. > > It is possible to have poudriere produce a (compressed) > tar of the /wrkdirs/usr/ports/devel/llvm10/work/ content > that can later be extracted someplace and looked at. > Producing these for llvm10 tends to take significant time > once it starts. The files are put at paths that look like: > > /usr/local/poudriere/data/wrkdirs/JAILNAME/default/* > > Depending on your poudriere.conf content, you might > already have such a compressed tar. But I'm not sure > that you would want to see what was under: > > . . ./llvm-10.0.1.src/lib/Target/Hexagon/. . . > > or if . . ./llvm-10.0.1.src/lib/Target/Hexagon/ even > exists. (I'm not sure what you would do with the > information beyond reporting it.) I should also have noted that poudriere leaves logs around to look at, of the form: /usr/local/poudriere/data/logs/bulk/JAILNAME/latest-per-pkg/llvm10-10.0.1_5.log (using llvm10-10.0.1_5 as an example). With the log you can see the steps that it takes, including what OPTIONS were in use, extracting from dist files, installing packages, and so on. Toward the end should be the errors that stopped the build. The command lines that were in use are present. The log shows a list of the targets: -- Targeting AArch64 -- Targeting AMDGPU -- Targeting ARM -- Targeting BPF -- Targeting Hexagon -- Targeting Lanai -- Targeting Mips -- Targeting MSP430 -- Targeting NVPTX -- Targeting PowerPC -- Targeting RISCV -- Targeting Sparc -- Targeting SystemZ -- Targeting WebAssembly -- Targeting X86 -- Targeting XCore (The above was from an amd64 context that does build llvm10 for multiple targets.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
New port: math/polymake -- some questions and help needed
Hi ports@
I've been working on a port of polymake (polymake.org). Most of the work
is done, but there are some questions. Please advise:
- How to deal with machine/installation dependent path names?
polymake installs a helper library into
${PREFIX}/libexec/polymake/perlx/%%PERL_VERSION%%/amd64-freebsd-thread-multi/auto/Polymake/Ext/Ext.so
amd64-freebsd-thread-multi is the output of
perl -E 'use Config; print "$Config::Config{archname}\n";'
How do I correctly handle this entry in pkg-plist?
- From reading the Porters Handbook, I get the impression that setting
DESTDIR is frowned upon. However, if I don't set DESTDIR=${STAGEDIR} in
the do-install target, "make stage" dumps everything to ${PREFIX}. Any
comments on this?
- polymake installs a shared library libpolymake.so. I set USE_LDCONFIG,
but "portlint -A" complains that no libraries are installed. Why?
If I do install the port in its current form, everything looks fine:
$ pkg info polymake
...
Shared Libs provided:
libpolymake-apps-rt.so.4.4
libpolymake.so.4.4
...
$
Should I worry about this?
You can find the current state of affairs at philippost.de/polymake.tar.xz
I appreciate any hints and comments you may have. It's my first port and
I hope I didn't miss anything important. ;-)
Thanks in advance!
Philipp
Re: Restarting poudriere
> On 14. Jun 2021, at 20:30, bob prohaska wrote: > > On Mon, Jun 14, 2021 at 06:46:52PM +0200, Michael Gmelin wrote: >> On Mon, 14 Jun 2021 09:28:39 -0700 >> What do you mean by "restarting"? >> How do you invoke poudriere exactly? > As root, > poudriere bulk -J 2 -j main x11-wm/lxqt www/chromium > testbuild.log > > Sorry for the omission, thanks for reading! Doesn’t ninja handle parallel builds on its own anyway? Does it work okay if you comment out ALLOW_*_JOBS in poudriere.conf? Cheers Michael > bob prohaska
INDEX now builds successfully on 11.x
Re: New port: math/polymake -- some questions and help needed
Le lun. 14 juin 21 à 21:41:02 +0200, Philipp Ost
écrivait :
> Hi ports@
Hello,
> I've been working on a port of polymake (polymake.org). Most of the work
> is done, but there are some questions. Please advise:
Remark: this is a resurrection
$ grep polymake /usr/ports/MOVED
math/polymake||2014-06-22|Has expired: Does not build with any supported
version of Perl
> - How to deal with machine/installation dependent path names?
> polymake installs a helper library into
> ${PREFIX}/libexec/polymake/perlx/%%PERL_VERSION%%/amd64-freebsd-thread-multi/auto/Polymake/Ext/Ext.so
>
> amd64-freebsd-thread-multi is the output of
>
> perl -E 'use Config; print "$Config::Config{archname}\n";'
>
> How do I correctly handle this entry in pkg-plist?
You can define a variable to be passed in plist:
PLIST_SUB= ARCH=${ARCH}
and then %%ARCH%% will be available.
> - From reading the Porters Handbook, I get the impression that setting
> DESTDIR is frowned upon. However, if I don't set DESTDIR=${STAGEDIR} in
> the do-install target, "make stage" dumps everything to ${PREFIX}. Any
> comments on this?
I guess that you’ll have to patch the Makefile…
> - polymake installs a shared library libpolymake.so. I set USE_LDCONFIG,
> but "portlint -A" complains that no libraries are installed. Why?
>
> If I do install the port in its current form, everything looks fine:
> $ pkg info polymake
> ...
> Shared Libs provided:
> libpolymake-apps-rt.so.4.4
> libpolymake.so.4.4
> ...
> $
>
> Should I worry about this?
What is the output of `ldconfig -r | grep polymake'?
On FreeBSD, if your library is libpolymake.so.4.4, you should also
install a symlink for libpolymake.so and libpolymake.so.4.
Without that, it won’t be registered in the libraries hints file.
> You can find the current state of affairs at philippost.de/polymake.tar.xz
>
> I appreciate any hints and comments you may have. It's my first port and
> I hope I didn't miss anything important. ;-)
>
> Thanks in advance!
Thanks for this revival!
--
Th. Thomas.
signature.asc
Description: PGP signature
Re: Restarting poudriere
On Mon, Jun 14, 2021 at 09:52:22PM +0200, Michael Gmelin wrote: > > > > On 14. Jun 2021, at 20:30, bob prohaska wrote: > > > > ???On Mon, Jun 14, 2021 at 06:46:52PM +0200, Michael Gmelin wrote: > >> On Mon, 14 Jun 2021 09:28:39 -0700 > >> What do you mean by "restarting"? > >> How do you invoke poudriere exactly? > > As root, > > poudriere bulk -J 2 -j main x11-wm/lxqt www/chromium > testbuild.log > > Doesn???t ninja handle parallel builds on its own anyway? Does it work okay > if you comment out ALLOW_*_JOBS in poudriere.conf? The line ALLOW_MAKE_JOBS is already commented out in /usr/local/etc/poudriere.conf but it's active in /etc/make.conf I remain a bit confused about how poudriere and make coordinate their parallel job spawning activity. In the latest case the -J 2 on the poudriere command line put two packages under construction, but the ALLOW_MAKE_JOBS line in /etc/make.conf didn't result in parallel threads building LLVM10. Clearly I don't understand the relationship between builders, jobs, threads and (much!) more. Perhaps I've complicated matters by using testport on earlier, successful, tries. Is there a significant difference if one just wants to make packages? I merely wanted to see how the attempt would fail and hoped for more diagnostics. But it worked. So, I tried bulk and that doesn't seem to work so well. Thanks for reading! bob prohaska > > Cheers > Michael > > > > bob prohaska > >
Re: Restarting poudriere
poudriere adds DISABLE_MAKE_JOBS=poudriere to make.conf by default. ALLOW_MAKE_JOBS and ALLOW_MAKE_JOBS_PACKAGES in poudriere.conf, turn it off.
