Re: Ports recompile for 13.0-RELEASE
On Tue, May 04, 2021 at 08:10:38AM -0600, @lbutlr wrote: > With the move to FreeBSD 13.0 is there a simple (single step) way to > reinstall all the current ports other than saving off a list of the ports and > then stepping through that list to reinstall them? It was very inefficient > when moving to 12.0 as many ports in the list, of course, were dependent on > other ports, but then got recompiled, sometimes multiple times. I know I > ended up in a make loop where came was compiled over and over again until I > aborted, listed the current ports, differ on the previous ports, and picked a > port I though would have a lot of reps to restart the compile. I then did > this several more times to get back to where I had been on 11.x > > And there's still no way to tell if a port was installed from pkg or from > ports, correct? Since I use MariaDB instead of MySQLI have to be sure I don't > try to use package for anything that will try to install MySQL instead. > > And finally, the release of 13.0 ends the 12.x versions, right? There will > not be a 12.3. > > (And yes, I've tried moving to poudrerie several times and we do not get on. > At all.) If you can get everything into a pkg repo, "pkg upgrade -f" should reinstall everything regardless of if pkg thinks it needs to. I suspect that your problem is minimum proper rebuilding rather than reinstallation. I just keep a list of packages I want (vs all build dependencies), which made my what-needs-rebuilding list much smaller (the dependency list is huge, but I didn't need to track that). I have a list of 58 packages I want installed, but have 494 packages installed for dependencies and I think the build total (some build dependencies don't get installed) is 600+. Your story is reminding me about my portmaster problems back in the day (that drove me to try poudriere, not get it, try synth, then run on synth until I ran into other issues (arm64) that remotivated me to learn poudriere). I know there is someone that has tried to fix portmaster in the meantime, but I think the basic issue is that there are, and will continue to be, issues with incompatible build dependencies that are "solved" by clean-room build systems which are probably the cause of some of those make loops. The last time I had this conversation, someone who had been beating on portmaster spoke up about the work they'd been doing to try and get the clean-room work added to it, but I don't know about the status of that. I think you're going to be aggravated until you find a ports management fix that works for you. ___ 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"
PR#252928 mtools needs iconv and mtools.conf edit for ipxe to compile
Can someone take a look at bug # 252928? I don't guarantee that it is anywhere near the right thing to do, but my general issues trying to compile net/ipxe are: net/ipxe requires mformat from emultators/mtools When mtools is built, it gets libiconv loaded because of texinfo The port Makefile didn't have it configured as a prerequisite, so when the option is used (default on), it configures itself for it and when ipxe pulls it in, the shared library is missing mtools installs mtools.conf with a line you're supposed to uncomment, but in a clean poudriere build there is no way to do that ___ 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: Can't load nvidia.ko on stable/12 after r564088 (440.100_1 -> 460.36)
On Fri, Feb 05, 2021 at 04:43:58AM -0800, David Wolfskill wrote: > dmesg reports: > > link_elf_obj: symbol nvidia_driver_name undefined > linker_load_file: /boot/modules/nvidia.ko - unsupported file type > KLD nvidia-modeset.ko: depends on nvidia - not available or version mismatch > linker_load_file: /boot/modules/nvidia-modeset.ko - unsupported file type > > for each. > > So I suspect that "link_elf_obj: symbol nvidia_driver_name undefined" > whine is likely salient. I just opened up PR#253269 for the same symptom. I suspect that it is due to me having WITH_BIND_NOW=YES set in my /etc/src.conf (my usual cause for undefined symbols that haven't bitten other people). Have you set that as well? If not, then probably a much wider audience. ___ 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: Re-enabling old ciphers in openssl
On Sun, Dec 27, 2020 at 03:49:10PM -0800, Dan Mahoney (Gushi) wrote:
> Hey there all.
>
> This is a "don't try this at home" question. This is not something I'm
> asking how to do in the general case, but I'd like to know.
>
> It seems recently (since 1.1.1, OpenSSL has deprecated a number of
> ciphers, and made them a compile-time default disable.) ...
> Ergo, I am wondering what the best way forward is to get a reasonably
> patched version of openssl that has old ciphers turned on (since it is
> still possible at compile-time, the code hasn't been outright removed),
> that I can build *some* subset of ports against.
>
> Here are the questions I can't seem to answer:
>
> 1) There's no make.conf entry to override the openssl ciphers. This needs
> to be done at the port level. (Probably reasonable, I don't think there
> should be an insecure "flavor") But in the interest of making things
> reproducible, is there a "Standard" way to keep this consistent without
> running "make config" every time, or echo'ing options into
> /var/db/ports/security-openssl/options?
If you can submit a patch, the person that maintains OpenSSL may accept it.
If not, you can always have a local-to-your-system patch that permits it.
That would give you a OpenSSL that allows it. Hopefully your window of
support isn't so big that you have to go back and start using obsolete/
dangerous versions of the software, because at some point software support
may get yanked out for those.
Either way, you start out with your own patch.
> 2) I'm unclear as to what to put in make.conf to tell ONE PORT to use the
> openssl from ports, while I want all the others to use base. I know this
> is in some cases askign for trouble, but the nagios plugins are standalone
> binaries. Is there some method in make.conf or on the port command line
> to tell ONE PORT to use a defaults+=ssl-openssl without making it the
> default for ALL PORTS?
Assuming that by default the DEFAULT_VERSIONS for ssl is base, you'd just
want to use the .if syntax for your port. Something like:
.if ${.CURDIR:M*/www/firefox}
DEFAULT_VERSIONS += ssl=openssl
.endif
That shouldn't be a syntax error, but I'm not sure it'll do what you want or
be anywhere near complete enough (I just picked it because you mentioned
firefox). Firefox has a ton of dependencies, and if one of them needs
SSL then you're going to want it running against the same version of SSL
and now you're going to be chasing a lot of nitty-gritty details that will
change over time.
Not sure if poudriere (or whatever you're using to build packages) will
complain about the potential conflicts that setup might imply.
You seemed to want a minimum amount of apps that might be linked against
the less-secure library, so there are going to be some tradeoffs there.
I haven't played with it in a while, but SSL_CTX_set_cipher_list() may
or may not be your friend if the software you're interested in lets you
configure it (so you can exclude bad ciphers where you don't want them,
and include them where you do) but then you still have to hope that
if you're using strength levels (high, medium, low, etc) that the ciphers
you want aren't getting discriminated against in multiple ways. And
who knows how that function would be called across all the packages+ports.
It sounds like you're trying to do your best with the insecure targets,
so I'm not sure if your insecure jump-hosts would be treated the same
(responsibly), then I might not feel too bad if openssl was recompiled
for everything on the box as long as it wasn't weak for incoming traffic.
Weak for outgoing traffic might be considered acceptable since the only
things it would be talking to are the known-weak remote devices.
If it was a multi-purpose host (like you were using it for other admin
purposes, like looking up documentation out on the web) then I'd lean
way more towards jailing those packages somewhere.
> 3) If I do all that, ports seems to lack a standard way to build static
> binaries, which is what I'd really like. Is there an easy way to do this,
> or is it best to work outside the ports system at that point?
Don't know the answer to that one.
___
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: portmaster new development
On Sat, Dec 26, 2020 at 07:23:59PM -0800, Thomas Mueller wrote: > ... An improved portmaster arouses my interest. Maybe modify the name so it > can be added to the ports tree and coexist with the "official" portmaster. > Desired features/options would be to keep going rather than stop when one > port fails to build, and the ability to install build dependencies, which may > be useful for building other software. > > With synth, I had a difficult time getting everything that was built to > install, some packages like bison are needed in building other software. > > How is poudriere in that regard? I never used poudriere, have been > intimidated by not wanting to use zfs or dialog4ports, or such an elaborate > setup just to update one or a few ports. I'm a dinosaur, so I was a fan of old portmaster for quite some time. I'd say it's downfall was incompatible build dependencies, since it didn't build them in a jail. As packages got more complex and port-count went up, lots of breakage (at least outside of poudriere). I tried poudriere, didn't quite get my head around it and found synth. The original synth worked for me for quite some time, but it's downfall was the dependency on gcc6-aux (I think for ADA support?) when I got off the beaten path into ARM and didn't want to cross-compile. I had a raspberry pi and I really wanted it to be able to recompile itself natively. I think there were plans for a csynth (rewritten in C, as I understood it) to fix that "issue" but by then I'd taken a second shot at figuring out poudriere and moved on. I think the new portmaster was in the works by then, but I'd reported enough build issues at that point to be wary of non-poudriere build issues. The author seemed to be hacking away at my original portmaster issues, I just didn't want to wait. My $.02? Don't worry about build dependencies, make them a target and you'll be fine. I've got devel/gmake, devel/m4 and devel/bison in mine. I'm a fan of ZFS, so that isn't a showstopper for me. Do what works for you, so long as it handles incompatible build dependencies right. Using jail(s) is one way to do that, but I'm pretty sure others have used just plain old chroot() to pull it off. Poudriere (and synth) tended to rebuild EVERYTHING that depended on some- thing that changed. That was the safe behavior, but boy did that hurt when people kept on making more and more compilers a dependency. The original portmaster didn't, but occasionally had problems when it didn't. I got in the habit of periodically recompiling everything. I've said "incompatible build dependency" a few times. I don't have a real, old example but if A depends on B and C depends on D and you want A & B but C can't co-exist with D, you've got issues. I'd run into that with programs that ran on top of X having incompatible build deps, but not an issue if built in jails where they didn't have to be on the disk at the same time as with original portmaster. ___ 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: Build errors in Python packages with compiled extensions
On Tue, Dec 22, 2020 at 05:25:41PM -0800, John Kennedy wrote: > On Tue, Dec 22, 2020 at 08:47:35PM +0100, Christian Ullrich wrote: > > Hello, > > > > I have started to notice poudriere builds of Python ports with compiled > > extensions failing: > > > > [00:00:11] /usr/bin/strip > > /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so > > [00:00:11] strip: open > > /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so > > failed: No such file or directory > > > > The reason is that setuptools puts a version tag (aka cache tag) into the > > .so's name; in this case it is actually _cffi_backend.cpython-38.so . The > > strip command, on the other hand, is in the port Makefile's post-install > > target and has the file name as above, without the version. > > > > This tag is to be available in Uses/python.mk as $PYMAGICTAG, e.g. > > "cpython-38". > > > > I'm not sure whether I'm not doing something wrong that causes the tag to > > end up in the .so file names. The last update to devel/py-setuptools was a > > while ago (to 44.0 in January 2020), and someone would probably have > > noticed since. On the other hand, this _is_ poudriere, so the build > > environments are pretty well isolated. > > > > Anyone know what is going on? > > Not just you. As soon as I upgraded python38 from 3.8.6_1 -> 3.8.7, I ran > into the same kind of problems... my local poudriere build failed 7 python > packages and skipped another 96. I don't have the exact same setup, but it > happened on both -CURRENT and releng/12.2. > > So, ports rev 558913 ~Tue Dec 22 14:58:05 2020 +. > > I opened up bug 252057. As a follow-up to myself, it looks like I did a upgrade pass ~11:08 (my TZ, PST8PDT) which was fine and then a pass ~14:42 where pkg (1.16.0) and python38 got upgraded. Now, packages that get upgraded seem to be a subset of what got built, so it's possible that something else in the same pass might be at fault. Just looking at the dates in my poudriere package stash might help someone way more python-savvy than I: 8585 -rw-r--r-- 1 nobody wheel8713736 Dec 22 14:33 pkg-1.16.0.txz 17553 -rw-r--r-- 1 nobody wheel 17841384 Dec 22 14:35 python38-3.8.7.txz 649 -rw-r--r-- 1 nobody wheel 527536 Dec 22 14:35 py38-setuptools-44.0.0.txz 265 -rw-r--r-- 1 nobody wheel 168752 Dec 22 14:35 py38-pycparser-2.20.txz 21 -rw-r--r-- 1 nobody wheel 19664 Dec 22 14:35 py38-six-1.15.0.txz 101 -rw-r--r-- 1 nobody wheel 100440 Dec 22 14:35 ninja-1.10.2,2.txz 265 -rw-r--r-- 1 nobody wheel 141576 Dec 22 14:35 py38-certifi-2020.12.5.txz 25 -rw-r--r-- 1 nobody wheel 24492 Dec 22 14:35 py38-pysocks-1.7.1.txz 69 -rw-r--r-- 1 nobody wheel 65712 Dec 22 14:36 py38-idna-2.10.txz 265 -rw-r--r-- 1 nobody wheel 161056 Dec 22 14:36 py38-pytz-2020.1,1.txz 5001 -rw-r--r-- 1 nobody wheel4988776 Dec 22 14:36 git-2.29.2.txz 113 -rw-r--r-- 1 nobody wheel 111728 Dec 22 14:36 py38-pyparsing-2.4.7.txz 1161 -rw-r--r-- 1 nobody wheel1059760 Dec 22 14:36 meson-0.56.0.txz 265 -rw-r--r-- 1 nobody wheel 155488 Dec 22 14:36 py38-chardet-3.0.4_3.txz 9 -rw-r--r-- 1 nobody wheel 6212 Dec 22 14:36 py38-imagesize-1.1.0.txz 5129 -rw-r--r-- 1 nobody wheel5224196 Dec 22 14:36 py38-Babel-2.8.0.txz 21 -rw-r--r-- 1 nobody wheel 19760 Dec 22 14:36 py38-sphinxcontrib-qthelp-1.0.3.txz 57 -rw-r--r-- 1 nobody wheel 54436 Dec 22 14:36 py38-packaging-20.8.txz 25 -rw-r--r-- 1 nobody wheel 22616 Dec 22 14:36 py38-sphinxcontrib-htmlhelp-1.0.3.txz 17 -rw-r--r-- 1 nobody wheel 15900 Dec 22 14:36 py38-sphinxcontrib-devhelp-1.0.2.txz 21 -rw-r--r-- 1 nobody wheel 17508 Dec 22 14:36 py38-sphinxcontrib-serializinghtml-1.1.4.txz 1929 -rw-r--r-- 1 nobody wheel1935412 Dec 22 14:37 py38-cython-0.29.21.txz 7561 -rw-r--r-- 1 nobody wheel7645180 Dec 22 14:37 vim-8.2.2072.txz 1289 -rw-r--r-- 1 nobody wheel1289680 Dec 22 14:37 py38-pygments-2.7.2.txz 9 -rw-r--r-- 1 nobody wheel 6088 Dec 22 14:37 py38-sphinxcontrib-jsmath-1.0.1.txz 25 -rw-r--r-- 1 nobody wheel 21364 Dec 22 14:37 py38-sphinxcontrib-applehelp-1.0.2.txz 17 -rw-r--r-- 1 nobody wheel 15764 Dec 22 14:37 py38-alabaster-0.7.6.txz 649 -rw-r--r-- 1 nobody wheel 650632 Dec 22 14:37 py38-future-0.18.2.txz 85 -rw-r--r-- 1 nobody wheel 82
Re: Build errors in Python packages with compiled extensions
On Tue, Dec 22, 2020 at 08:47:35PM +0100, Christian Ullrich wrote: > Hello, > > I have started to notice poudriere builds of Python ports with compiled > extensions failing: > > [00:00:11] /usr/bin/strip > /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so > [00:00:11] strip: open > /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so > failed: No such file or directory > > The reason is that setuptools puts a version tag (aka cache tag) into the > .so's name; in this case it is actually _cffi_backend.cpython-38.so . The > strip command, on the other hand, is in the port Makefile's post-install > target and has the file name as above, without the version. > > This tag is to be available in Uses/python.mk as $PYMAGICTAG, e.g. > "cpython-38". > > I'm not sure whether I'm not doing something wrong that causes the tag to end > up in the .so file names. The last update to devel/py-setuptools was a while > ago (to 44.0 in January 2020), and someone would probably have noticed since. > On the other hand, this _is_ poudriere, so the build environments are pretty > well isolated. > > Anyone know what is going on? Not just you. As soon as I upgraded python38 from 3.8.6_1 -> 3.8.7, I ran into the same kind of problems... my local poudriere build failed 7 python packages and skipped another 96. I don't have the exact same setup, but it happened on both -CURRENT and releng/12.2. So, ports rev 558913 ~Tue Dec 22 14:58:05 2020 +. I opened up bug 252057. ___ 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: portsnap depreciation
On Fri, Sep 18, 2020 at 08:17:35PM +, Pau Amma wrote: > On 2020-09-18 17:58, Carmel NY wrote: > > On Fri, 18 Sep 2020 13:43:48 +, Pau Amma stated: > >> See > >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html#testing-poudriere-ports-tree > >> and the next sections. > > > > According to the above page, "The most straightforward way is to have > > Poudriere create a default ports tree for itself, using either > > portsnap(8) (if running FreeBSD 12.1 or 11.4) or Subversion (if running > > FreeBSD-CURRENT)" Am I to understand that if I am running 11.4-RELEASE, > > I cannot use subversion? > > "The most straightforward", not "the only". You can definitely use > Subversion with 11.4 if you wish or need to. What you no longer can do > is use portsnap with -CURRENT. (I'll grant that "straightforward" may be > in the eye of the beholder, though.) For my stuff, I pull my stuff into /usr/ports however I want (git, long before it was fashionable in my case) and then just set up poudriere to use that. I do a similar things with /usr/src, except I want poudriere to have a static copy of that, just in case. [initial creation] poudriere jail -c -j 12-2 -v 12.2 -m src=/usr/src poudriere ports -c -m null -M /usr/ports -p master poudriere jail -l JAILNAME VERSIONARCH METHOD TIMESTAMP PATH 12-2 12.2-BETA2 1202000 amd64 src=/usr/src 2020-09-18 15:32:59 /usr/local/poudriere/jails/12-2 The "-m null" (null method) lets you manage it however you want. If I look at my mounts during the build, with ZFS, I can see them: Filesystem SizeUsed Avail Capacity Mounted on ... /usr/ports 350G4.0G346G 1% /usr/local/poudriere/data/.m/12-2-master/ref/usr/ports /usr/ports/distfiles364G 17G346G 5% /usr/local/poudriere/data/.m/12-2-master/ref/distfiles ___ 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: qt5-webengine
On Sat, Apr 04, 2020 at 07:41:54PM -0400, Robert Huff wrote: > Jonathan Chen writes: > >> Frankly speaking, if you're compiling your own ports, you >> have to use either synth or poudriere; anything else will cost you >> time hunting down broken dependencies. > > Speaking as someone who's been compiling from ports for at least > a decade, and maintains 1200+ ports on at least one box: > Yes ... but not much. I use portmaster and stuff mostly Just > Works(tm). [Thanks, guys!] Ports get updated regularly, and the last > major problem I can remember had to do with defauly version bumps in > perl and python (2->3). > I understand there are folks for whom poudriere or synth are The > Right Tool(tm). But I am one of a number of folks for whom it is like > carpet-bombing the neighborhood to get rid of one miscreant squirrel. The thing that drove me away from portmaster to synth and eventually to poudriere is incompatible dependencies. I was running into those with just X11 dependencies (~600 packages in my full port rebuild, so not sure how you got lucky over that period of time). Now, people keep on fixing portmaster and fixing dependencies, but at times I would have just been SOL for an indeterminate period of time. I also got in the habit of rebuilding and reinstalling everything about once a month because of weird (dependency) breakages that portmaster (at least at the time) couldn't figure out and recompile itself. I'm really impatient, and have a compulsion to security-patch things, so thus I was finally driven to change (after I don't know how many years). Synth and poudriere avoided it because it was a build dependency, not a run-time dependency, and their build environments kept that very clean (which portmaster couldn't do, at least at the time). It also let me have less packages loaded on the machine overall, so less surface area for attacks. Yeah, it recompiles a BUNCH of things that often don't get upgraded, but I've never felt the need to recompile everything in case something got missed. I also find that port problems that break poudriere builds get caught quickly (vs more-rare synth problems, and way faster than portmaster), so I get to reap the advantages of what FreeBSD is building with. ___ 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: INDEX build failed for 11.x
On Fri, Mar 13, 2020 at 11:25:51AM -0700, John Kennedy wrote: > There seems to be something similar going on for devel/llvm10, and probably a > lot more since they do the same kind of comparison. Seems to be fixed as of 528375 (somewhere between e9ecbe62adad..71e1eb7115a2; revision 528372-528375). ___ 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: INDEX build failed for 11.x
On Fri, Mar 13, 2020 at 06:04:38PM +, Ports Index build wrote:
> --- describe.biology ---
> make[5]: "/home/indexbuild/tindex/ports/biology/canu/Makefile" line 34:
> warning: String comparison operator should be either == or !=
> make[5]: "/home/indexbuild/tindex/ports/biology/star/Makefile" line 28:
> warning: String comparison operator should be either == or !=
> make[5]: "/home/indexbuild/tindex/ports/biology/star/Makefile" line 28:
> Malformed conditional (${CHOSEN_COMPILER_TYPE} == gcc && ${COMPILER_VERSION}
> <= 42)
There seems to be something similar going on for devel/llvm10, and probably a
lot more since they do the same kind of comparison.
...
[00:00:03] Gathering ports metadata
[00:00:03] Warning: (devel/llvm10): make: "/usr/ports/devel/llvm10/Makefile"
line 412: warning: String comparison operator should be either == or !=
[00:00:03] Warning: (devel/llvm10): make: "/usr/ports/devel/llvm10/Makefile"
line 412: Malformed conditional (${COMPILER_TYPE} == clang &&
${COMPILER_VERSION} >= 70)
[00:00:03] Warning: (devel/llvm10): make: Fatal errors encountered -- cannot
continueError: Error looking up dependencies for devel/llvm10
[00:00:04] Error: Fatal errors encountered gathering ports metadata
...
___
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: amdgpu panics
On Thu, Mar 12, 2020 at 12:22:21AM +, Grzegorz Junka wrote: > On 10/03/2020 19:46, Hans Petter Selasky wrote: > > On 2020-03-10 20:29, Grzegorz Junka wrote: > > > > > > On 09/03/2020 23:04, Hans Petter Selasky wrote: > > > > On 2020-03-10 00:03, Grzegorz Junka wrote: > > > > > I've upgraded my system to 12.1. I have recompiled all ports > > > > > with poudriere using jail 12.1. As soon as "amdgpu" kernel > > > > > module is loaded the system panics. Tried with both, > > > > > "drm-kmo" and "drm-fbsd12.0-kmod". Any ideas? > > > > > > > > Are the kernel sources in the jail matched with your system? > > > > > > Sorry, I don't understand your question. Why does it matter? The > > > jail was created by poudriere. Does the installed package use > > > sources from my system? > > > > All kernel module packages use sources from the build system! > > The base system has also been updated to 12.1 if that's what you are asking. > I am not sure if the sources are the same. Both the host and the poudriere > jail are 12.1. Do they need to be exact to the patch version? > > I understood that the drm-kmod or drm-fsbsd12.0-kmod are build as packages > by poudriere in the poudriere jail. Are you saying that they are build with > sources from the host? How is that possible? This may have absolutely nothing to do with your setup. I can only say that I've been where you are in the past, what I've done, and that it has made me happy and solved my problems. First off, packages are great. I can't quantify that, but I know that the small percentage of the time that they don't work for some reason is really annoying to me (and arguably a personal problem). (: But here is how I've channeled that into something productive, even if it isn't something that everybody can do. If everybody could do it, we wouldn't have a strong demand for packages (even ignoring some economy of scale/ease of use arguments). First off, I have a local poudriere setup, and compile all my packages from source. I have some non-default options that I prefer, occasionally some odd platforms (arm64, etc) and run closer to the bleeding edge (I tend to ride the pre- into OS releases, use the master (vs quarterly) ports, etc. So I'm pretty sure I run into all the problems that the ports/src (and other reasonable) people expect. Compiling from source dodges a huge number of those. I didn't have problems with pkg, X11 during -1.20 (except the FIXDRM/DRI issue for one graphics card, and only showed up with firefox with certain site graphics), the input problems some people have had, etc. I've been very pleased to not have those problems, although a bunch of them had nothing to do with how something was compiled vs life moving on and things changing (udev/dev/event changes, etc). Lets face it, X11 is annoying. I have a very stripped down X11 environment and I think it is at least 253 packages, even more if you have X11 for reasons (like firefox browser). Kudos to a lot of nameless people keeping that whole mess working as well as it does. That "life" choice has been REALLY painful on RPI3/arm64, but not painful at all on amd64 type systems, your mileage may vary. It has certainly given me an understanding on why some packages on FreeBSD's repo take a while to get out. I'm only building ~500 packages, and they're building all of them. Watching a readline upgrade trigger hundreds of packages to rebuild hurts, but it helps solve the mixing-source-and-package-can-hurt problems. In any case, on my poudriere system, I upgrade the kernel jail (poudriere jail -u ...) once per patch on release systems and maybe once a week (or CVE, or when they bump __FreeBSD_version) when I'm tracking stable. Basically when I think that the kernel ABI might have changed or when some security related piece of code might need to be baked into the packages. The ultimate thing might be once per kernel upgrade, but that is overkill so I try to compensate with the weekly sync, just in case. AFAIK, the ports builders keep theirs at the -release level (?), which is pretty good for most things but fails in a few cases (and here is where some of the readers are). In my case, I created the kernel source jail like this: poudriere jail -c -j 12-1 -v 12.1 -m src=/usr/src It just has whatever source when you create it or when you update it. I didn't try to create it with a null method, but maybe that would work. If you upgrade your local kernel but not your jail, then yes, you can have some kernel ABI issues that might bite you like you've seen (kernel panics). I haven't had a problem with video drivers myself, but what drove that behavior used to be virtual box. Probably daily I pull down the source tree and let poudriere decide what ports need to be rebuilt. They're always built with kernel OS that is really close to what is actually running. On top of all of THAT, I have this in my /etc/make.conf: # be extra paranoid about
Re: Starting with poudriere
On Sat, Feb 15, 2020 at 09:02:39PM -0700, @lbutlr wrote:
> On 15 Feb 2020, at 16:32, @lbutlr wrote:
> > Sorry for the rather basic questions.
>
> Thanks everyone for your comments. One more dumb question I can???t find the
> answer to.
>
> Let???s say I want to build and install a single port via poudrier. For the
> same of argument some port that has configuration options I want to change.
>
> I have the ports tree setup, have my jail setup, and I want to build it.
>
> And then I want to deploy it to the target machine once it???s built.
>
> Or I want to deploy to to the local machine.
>
> Let???s say, for fun, it???s something like ImageMafick that has a lot that
> goes with it.
>
> Am I writing a config file for this every port I want to build?
Personally, I have a single, custom make.conf that I maintain and shove into
/usr/local/etc/poudriere.d (default location I believe).
Inside the make.conf, you can bracket non-default options like this:
.if ${.CURDIR:M*/ftp/curl}
OPTIONS_FILE_UNSET += TLS_SRP
.endif
I try to leave things as default, generally, but libressl isn't the default and
things go a bit sideways from there some days.
Those options I pull from /var/db/ports after I do a "make config" (be sure to
clean out /var/db/ports when you're done). Pay attention to the packages where
you change the defaults and put the minimum number of options in (for example,
you may need to set your new value and unset the old, default value).
Before that, I was trying to sync /var/db/ports across various machines and
that was way more messy (I think that was pre-poudriere, in the synth or even
portmaster days where things wanted to have config files, even if they were
only filled with the default values).
___
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 testport" to download binary depends
On Mon, Oct 21, 2019 at 01:59:17PM +0100, Matthew Seaman wrote: > On 21/10/2019 13:31, Sergei Vyshenski wrote: > > Is it possible to instruct "poudriere testport" such > > that it downloads depends (in a form of binary packages) from the > > central repository, > > and actually tests only the port in question? > > Currently, no this is not available. Using another repo to seed the > repo you're building test packages in is something that has been talked > about, but not implemented yet. I get the feeling that it's trickier > than it at first seems. For my current one-offs, I pull down ports via git, have a local branch where my changes are (refreshing by merging from "master" in my case), and then have poudriere base ports off my branch. ___ 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: thunderbird build error
On Sun, Dec 16, 2018 at 07:54:34AM -0500, George Mitchell wrote: > On 12/15/18 1:10 PM, George Mitchell wrote: > > I recently updated my port build machine to 11.2-RELEASE. I'm in the > > process of recompiling my (previously) 10.4-based ports to 11.2, and > > perhaps I shouldn't be trying to do this incrementally. [...] > > Sure enough, deleting all ports and starting on a fresh ports tree > fixed this problem. But I'm still unable to get the Powder Keg set > up on my machine (and I'm still happy with portmaster anyway). > -- George I was a happy portmaster user for a really long time, but eventually I ran into problems. Basically, once you get enough packages built (say, X11, browser-of- choice and trimmings) and keep it up for long enough (like through some major version bumps of dependent packages) you will run into an issue two packages that are incompatible need to be installed at the same time. That tends to get caught and fixed for the general case (the FreeBSD-provided package build), but others do not (like incompatible packages that are required to build but not to be installed). I wish I'd gotten poudriere to work before I got synth to work because synth isn't as portable (say, to ARM) and I apparently like to punish myself (by not cross-compiling... yet). In any case, synth/poudriere seems to be good at rebuilding anything that might need it, ready for a quick "pkg upgrade". Sometimes it may *seem* like a bit much (like gcc7 -> gcc8, or upgrading ca_root_nss), but I've been burned by portmaster not always catching on to some more subtle changes that would break things (and that even assuming that was ever aspired to by portmaster). For example, look at the advice we were given for perl5.26 -> 5.28, but now for a bunch of packages where you don't know the dependencies because you're not a master of ports. I don't feel the need to periodically delete and reinstall all packages just to be sure. tl;dr: You can't build everything with portmaster. You should be able to with poudriere (and if not, someone will probably be working on it to figure out why not). ___ 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"
