In some cases (mostly with insane distnames from local test builds, but
conceivably also possible with long combinations of flavours) they can
exceed the character limit. Discussed with espie@ who pointed out that
plist_db doesn't include entries for debug packages.
From Mikolaj Kucharski.
check. Newer ccache uses cmake making it impractical to break the loop by
just disabling ccache for the individual ports on the way to building ccache.
binaries for packages using DEBUG_PACKAGES. This avoids the current
situation where a backtrace is useless (function names all "??") if
a package was built with DEBUG_PACKAGES but the debug-foo package is
not installed. ok espie@ pirofti@
(a ten year old network daemon, no longer maintained in ports or upstream;
distfiles were fetched from debian who removed it from their packaging ~5
years ago). py-tagpy is one of the few consumers of boost's py2 library.
ok jca
everything so that people updating from subsequent snapshots won't
have old clang 8-compiled packages lying around.
also will work around the problem where packages don't have WANTLIB
in sync, in some cases these have an unlisted dependency on libc++
which won't have been updated as needed (found by matthieu@).
ok ajacoutot@
we rerun pkglocate
also check the pkglocate cookie vs the fake cookie, so that we rerun things
if somehow fake was rerun without cleaning things first (unlikely, but still)
- De-duplicate our .mod and .zip files.
- Move chdir to a child process.
- Break MODGO_MODULES and MODGO_MODFILES values into their own lines
for easier reading.
Updating bigger ports with lots of patches, combing the target's output
for failed hunks can be cumbersome; print failed patch files one per line
iff there are any to provide immediate feedback on what wrong and where.
"definitely wanted" landry
Style nits, OK espie
using MODGO_MODNAME.
This is needed to work around this issue:
https://github.com/golang/go/issues/27455
which makes `make clean` because of the restrictive permissions.
input and corrections from sthen@ and jca@
ok sthen@ jca@ espie@
UPDATE_COOKIES and BULK_COOKIES are not generated by dpb, but if you
build stuff manually and use dpb, they can happen, and you will see error
messages in dpb logs (trying to remove them as _pbuild), so give them
to _pbuild/tweak fix-extract-permissions accordingly.
Also fix an old feature where you can force UPDATE_COOKIES into WRKDIR
which got broken a long time ago.
Thanks to solene@ for tests
there's a bug elsewhere (autovivification of $w->{info}{BUILD_PACKAGES})
that I need to track down that results in $w->{info} being defined but
NOT a proper object.
dpb errors out at end-of-LISTING in case of a parse error in any Makefile.
solene@ ran into this a few days ago, probably some other people, and
finally I met the bug today. Ouchie. sorry about that.
tweak the path for copy-debug-info so we don't accidentally neuter
THAT strip as well.
this helps getting cmake/qmake do the right thing without needing to
alter strip behavior.
rather than 'RUN_DEPENDS=${BUILD_DEPENDS}' which is easily polluted by
compression utilities, ccache if used etc. Problem spotted by aja@ in a
port submission of mine where the skeleton was made by portgen.
While there, prefer setting 'TEST_DEPENDS=${RUN_DEPENDS}' rather than
to '${BUILD_DEPENDS}' if RDEP/BDEP are equal.
ok afresh1@
With this a port can be easily generated for Go applications that support Go
modules (there will be a go.mod file in the root of the project).
For example: https://github.com/jrick/domain/blob/master/go.mod
The mod file lists "github.com/jrick/domain" as the module name, so a portgen
command to build the above tool would be:
portgen go github.com/jrick/domain
OK afresh1@ kmos@
PyPI projects that already list multiple supported Python versions cause
portgen(1) to generate a flavoured port; of leaving FLAVOR emtpy, opt for
the highest available version.
This makes it use FLAVOR?=python3 insteaf of FLAVOR?= (empty) if any
sypport higher than Python 2 is listed.
Note that PyPI projects listing either only one sypported version or none
at all are not effected by this diff.
OK afresh1 kmos
Alexei dot Malinin at mail dot ru reported a compiler warning that,
in my opinion, probably indicates a security vulnerability, but due
to an incomplete description of the affected feature in the
documentation, it is unclear how it should be fixed. The program
appears to be sloppily written, sloppily documented, and abandoned
upstream 15 years ago.
OK ajacoutot@ for deleting it.
Although I couldn't find a definitive guide to version specs,
I did find an example showing this seems to be how RubyGems work.
From Thomas L. <tom.longshine () web ! de>
out of existence: arch-defines.mk MUST be included very early on, so that
modules can use it to decide on behavior, BUT modules are allowed to set
DEBUG_PACKAGES without worrying about it, and so bsd.port.arch.mk must be
the place that zaps!
Discovered by sthen@, because xfce4.port.mk would start churning out
DEBUG_PACKAGES on every architecture.
tested by naddy@ because I wasn't sure I didn't miss something non obvious.
They do result in a bulk package build taking about a third longer, but
the bulk build machines are significantly faster than the machines most
people are running the produced packages on, so it's a trade-off: a bit
of pain for builders vs a lot of pain for users wanting to debug things
on their normal hardware.
Simple MULTI_PACKAGES addition, no FLAVOR.
Diff from Thomas L. - thanks!
Tweaks and tests from me
"pkg_add murmur && rcctl start murmurd" just works on amd64 and sparc64
PREFIX.
Specifically:
- stop tweaking PREFIX for build-debug-info
- have build-debug-info use -B instead
- generate Makefile with full paths
- tweak the sequence in bsd.port.mk to NOT pass FAKE_SETUP around
This fixes got
it was checksummed.
(noticed on a port where EXTRACT_ONLY was a full file name and no longer
in distinfo, but still in DISTDIR)
thx naddy@ for making sure it didn't break in a bulk
Error: newgroup _inetsim: not registered in ports/infrastructure/db/user.list
Error: newuser _inetsim: not registered in ports/infrastructure/db/user.list
for now it rescans "stubbed" ports in case you did change them (or if
they were stubbed because of missing dependencies, etc)
Could become something else/more powerful eventually
add a debug command (cores) that shows explicitly each core known by
the core system, including idle cores (available) and "behind the scene"
stuff (ssh masters)
- mirrors.zerg.biz is no more (points to 127.0.0.1), drop it.
- savannah.c3sl.ufpr.br stopped their FTP service, use
ftp://ftp.cc.uoc.gr
- ftp.twaren.net replies 403 errors when fetching with ftp(1).
Move to mirror.ossplanet.net which is also in .tw and supports https
- also move mirror.csclub.uwaterloo.ca and nongnu.askapache.com to https
specifically, make sure dpb can't get confused if the same fullpkgname
points to two different locks (by stubbing/erroring out)
Clean up the code a bit so it shows up in equiv.log and as broken (so in
engine.log)
bsd.port.mk bits to test later (and document because this has lots of
caveats and should only be used under specific circumstances)
I used to have "site" always set, but it takes space for broken files,
so I removed it, and it breaks in case distfiles are incomplete.
So, just make it possible for some things to go missing, and properly test
for them later.
Noticed by jca@
- add a parameter "full" so that we don't show version mismatches twice
- remove host name from information, since the order is the same as the header
line.
- beautify by doing a line feed after banner and indent by two spaces so it
tends to fit on the line
return the full output of make as an array each time.
mainly done because SUBDIR should be passed in the environment, otherwise
some really funky things happen (ask kn@)
naddy@ approves the direction
anymore.
As a side effect, it unbreaks multimedia/mkvtoolnix on !clang archs.
Proposed by jca@, bulk tested by naddy@ on amd64 (thanks again!), and
me on macppc.
OK jca@
strip a leading "v" when it's followed by what looks like a version number,
also have it handle a few other common names seen in ports. likewise when
stripping 'v' from the default WRKDIST, also allow 'V', but only if
followed by digits (which seems a better match to what github are doing).
update the few ports which _require_ updates to match this change.
been through a bulk on i386 (plus I've diffed "make dump-vars" run in
in all ports having GH_TAGNAME before+after applying the patch), ok jca
bsd.port.mk(5) and actually make LLD_EMUL empty if the linker is not
ld.lld. Use a simpler variable-name-based lookup table rather than
string manipulation in a loop. Diff was worked out with espie a
couple of weeks ago.
drop a setuid bit AND not error out when they can't do stuff.
Fix the perms pre-emptively, so that aja@ can DEBUG_PACKAGES login_krb5
There are bugs to fix in binutils...!!!
- do the dir check late, so we don't create .debug dirs if not needed.
- add an emptyness check, so that we can warn if we produce an empty
debug package, and advise to tweak DEBUG_PACKAGES manually if there are
several subpackages involved
for use in regular builds too; if that is present in a port, use
${PARALLEL_MAKE_JOBS} jobs in the build, defaulting to hw.ncpuonline.
Adjust PARALLEL_BUILD=No, this originally seemed intended to be a hint
that a port could NOT handle a parallel build, but current usage is
"don't pass make -jXX because this port has its own way to handle things",
instead change this to a slightly more understandable PARALLEL_MAKE_FLAGS
variable. This defaults to -j${PARALLEL_MAKE_JOBS} but can be reset for
build system requirements as needed (java/libreoffice have their own
mechanism) and is added automatically to MAKE_FLAGS where a build uses
>1 concurrent job.
Based on a diff from / ok espie@ - the default value may want revising
as hw.ncpuonline jobs will be too many in some cases (e.g. machines with
many cores or low RAM), but committing at this stage to avoid further
out-of-tree bikeshedding. If you need to restrict to a lower number of
jobs, set e.g. PARALLEL_MAKE_JOBS=2 in /etc/mk.conf, and please provide
feedback.
Few people complained that stripped binaries are slightly
larger now than they used to be when debug packages are enabled.
My investigations show that this is because objcopy --strip-debug is
less efficient than plain strip(1) which is what we use for non-debug
packages.
Reintroducing strip(1) does not affect current debug packages behaviour
in my experience. The link to the debug symbols is still there and
egdb(1) still loads it automatically and displays all the debug info.
OK espie@
BUILD_DEPENDS and simplify (it's always defined, so no need for a "is defined"
check).
Although it's not used often there is now an external-facing library
that is part of gettext-tools so it's valid to have it listed as a LIB_DEPENDS
rather than a BUILD_DEPENDS.
_BUILDLIB_DEPENDS suggested by espie@ naddy@ as an improvement to my more
complex and less complete "check BUILD_DEPENDS and LIB_DEPENDS" which ignored
multi-packages.
- don't use $@D so that we can put two targets in there
- set a variable to add the debug package to the targets
This fixes behavior in the very specific case the normal package was already
built without DEBUG_PACKAGES and you're repackaging with DEBUG_PACKAGES set.
okay landry@
(how do you link with a lib in a package that you can't really depend
upon)
There are few enough static libs that the difference won't be that much
anyway.
okay pirofti@
them all we move them (and we can still fail if permissions are not okay)
Otherwise, we run the normal _internal-package-only again, with FETCH_PACKAGES
neutralized (as before)
This fixes the issue reported by semarie@ and kmos@
packages we build (normal/debug) and put the code back inside the actual
target instead of fragments.
Stop doing tests (shell exits as usual and trap is enough to remove temp
files).
The same logic will be used for debug_packages
not-so-good change to just using the PortsQ "cache":
- use _paths/_ports directly rather than the "ports" view and remove bogus
flavour-clearing regex subst
- open sqlports ReadOnly
- remove PKG_ARCH=* packages from DEBUG_PACKAGES, to help with
introspection
- ditch DEBUG_FILES entirely, the automated mechanism appears to be
good enough
- tweak show-debug-info to show the file names
so that it can figure out hardlink
create special LINK entries that just make hardlinks on the dbg info
for already generated stuff.
This solves the python problem noticed by aja@
- ignore debug files in the fake directory
- recognize and annotate shared objects and static libraries correctly
*THIS REQUIRES CURRENT PKG_* CODE TO WORK!*
if your package contains static libraries/shared objects, update-plist
WILL error out saying it can't create the new classes
- contrary to merge_depends, build_distinfo can actually work one path
at a time.
- have DISTFILES be an ordered list to give more info to roach (first
distfile)
- so put build1roach in the middle of build1info so that the ordered
list is still available.
To be leveraged once I finish roach...
this is likely to change some more (become more automated), but it
should allow us to build a few packages and tinker.
Basically it uses DEBUG_PACKAGES, DEBUG_FILES
plus DEBUG_CONFIGURE_ARGS and DEBUG_FLAGS because we don't want to allow
debug packages on small architectures before we assess the performance impact
of building these.
this will get documented properly once the dust settles...
As discussed with other people at p2k19, ok pirofti@
get closed automatically
for init core, if tasks did fail, do not continue.
in particular, this avoids calling DPB::Var->get on a failed host.
thx sthen@ for noticing this
