Re: poudriere(-devel) ports updating question
> Am 05.03.2019 um 15:09 schrieb tech-lists : > > Hi, > > There are several categories of ports I'd like to avoid for some > architectures. For example, I don't want x11 for mips.mips64. Or astronomy. > But let's say, for this architecture, I want to build everything else. > > I can't see a way of excluding categories with poudriere ports when > updating the ports tree - the only workaround I can see is to download > another tree, call it something and then manually edit that tree, and then > set the build off with -p port-treename. Every time I want to > make a bulk run. > > Basically I'm looking for exclude mask functionality when updating a > ports tree with poudriere ports. > > Do I need to do this manually or have I missed something? I don’t think it’s easy to do that. How would you handle dependencies? (For example, some ports require X11 libs and stuff, even though they’re in a different category.) Do you want to save time on builds by excluding pkgs that you know you’ll never need? Or what is your goal with this? In my setup, I rely on the regular packages from the official repo, but for those pkg that I need built with different options, I run a custom list. You could try to produce a filtered list of all ports, removing those that you’d never select manually, and let poudriere figure out what needs to be built. Something along the lines of: - update ports - list all ports | grep -v '^x11/' - run poudriere with resulting list Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: poudriere(-devel) ports updating question
On Wed, Mar 06, 2019 at 06:23:49PM +0100, Stefan Bethke wrote: Am 05.03.2019 um 15:09 schrieb tech-lists : Basically I'm looking for exclude mask functionality when updating a ports tree with poudriere ports. Do I need to do this manually or have I missed something? I don’t think it’s easy to do that. How would you handle dependencies? (For example, some ports require X11 libs and stuff, even though they’re in a different category.) You're right of course. My logic was wrong, and wrong premise[1] because I was stuck on thinking a bulk -a build. But I found how to do it (to remove categories) in case anyone is interested. The key is in the method used to update the tree, which is svn+https. so, from the top of the ports tree, svn update --set-depth=exclude biology would exclude the biology category permanently. svn update --set-depth=infinity biology would re-add it. svn update --set-depth=infinity would make it be like nothing was excluded in the first place. but on reflection, it breaks a little of the ports infrastructure and I don't want to do that. [1] used to use portupgrade -a but poudriere bulk -a is not equivalent!!! am just getting to grips with poudriere lol -- J. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: poudriere(-devel) ports updating question
On Mar 6, 2019, at 3:58 PM, tech-lists wrote: > On Wed, Mar 06, 2019 at 06:23:49PM +0100, Stefan Bethke wrote: >>> Am 05.03.2019 um 15:09 schrieb tech-lists : > >>> Basically I'm looking for exclude mask functionality when updating a >>> ports tree with poudriere ports. >>> >>> Do I need to do this manually or have I missed something? >> >> I don’t think it’s easy to do that. How would you handle dependencies? (For >> example, some ports require X11 libs and stuff, even though they’re in a >> different category.) > > You're right of course. My logic was wrong, and wrong premise[1] because I > was stuck on thinking a bulk -a build. But I found how to do it (to remove > categories) in case anyone is interested. The key is in the > method used to update the tree, which is svn+https. > > so, from the top of the ports tree, svn update --set-depth=exclude biology > would exclude the biology category permanently. svn update > --set-depth=infinity biology would re-add it. > svn update --set-depth=infinity would make it be like nothing was > excluded in the first place. > > but on reflection, it breaks a little of the ports infrastructure and I > don't want to do that. That's correct: omitting parts of the ports hierarchy might break a particular ports build catastrophically. If you're looking to exclude certain functionality when building ports you should investigate using ports options to achieve that. For example, I have a poudriere jail called "trurl" that is a headless system on which I don't want to use X11. I also don't want to use CUPS for that matter. So, in its "trurl-make.conf" file I include this line: OPTIONS_UNSET_FORCE= X11 CUPS That will force those options off for all ports. The result is I don't get any ports built supporting those options. I guess it's not foolproof, but it seems to work well enough for me. I hope this helps. Cheers, Paul. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
12-stable buildworld appears to be broken
Hi,
My context is poudriere creating jails on freebsd12-stable. This procedure
worked fine for some other jails I created a couple days ago (the 5th)
but now, today I get buildworld failures with creating either amd64 or
armv7 jails (the server is amd64)
To try to see the failure, I set jobs to J1 like so:
poudriere jail -x -J1 -c -j 12armv7 -a arm.armv7 -m svn+https -v
stable/12
It bails when it's making rescue with this error:
/data/poudriere/basefs/jails/12armv7/usr/src/sbin/fsck_ffs/pass1.c:454:13:
error: too many arguments to function call, expected 0, have 1
inodirty(dp);
^~
/data/poudriere/basefs/jails/12armv7/usr/src/sbin/fsck_ffs/fsck.h:453:1:
note: 'inodirty' declared here
void inodirty(void); ^
1 error generated.
*** [pass1.o] Error code 1
I know that's probably not enough, so have pasted much more output at
https://rpi3.zyxst.net/errors/poudriere-build-failure.txt
not tried make buildworld yet on the host. The OS is at r344763 and
/usr/src is at 344863
Just tried it on another 12-stable desktop, straightforward make
buildworld, same sort of error:
--- all_subdir_sbin/fsdb ---
/usr/src/sbin/fsdb/fsdb.c:1042:14: error: too many arguments to function
call, expected 0, have 1
inodirty(curinode);
^~~~
/usr/src/sbin/fsck_ffs/fsck.h:453:1: note: 'inodirty' declared
here
voidinodirty(void);
the sources are at 344869
thanks,
--
J.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12-stable buildworld appears to be broken
On Thu, 7 Mar 2019 05:13-, tech-lists wrote: > Hi, > > My context is poudriere creating jails on freebsd12-stable. This procedure > worked fine for some other jails I created a couple days ago (the 5th) but > now, today I get buildworld failures with creating either amd64 or armv7 jails > (the server is amd64) > > To try to see the failure, I set jobs to J1 like so: > > poudriere jail -x -J1 -c -j 12armv7 -a arm.armv7 -m svn+https -v > stable/12 > > It bails when it's making rescue with this error: > > /data/poudriere/basefs/jails/12armv7/usr/src/sbin/fsck_ffs/pass1.c:454:13: > error: too many arguments to function call, expected 0, have 1 >inodirty(dp); > ^~ > /data/poudriere/basefs/jails/12armv7/usr/src/sbin/fsck_ffs/fsck.h:453:1: > note: 'inodirty' declared here > void inodirty(void); ^ > 1 error generated. > *** [pass1.o] Error code 1 > > I know that's probably not enough, so have pasted much more output at > https://rpi3.zyxst.net/errors/poudriere-build-failure.txt > > not tried make buildworld yet on the host. The OS is at r344763 and > /usr/src is at 344863 > > Just tried it on another 12-stable desktop, straightforward make > buildworld, same sort of error: > > --- all_subdir_sbin/fsdb --- > /usr/src/sbin/fsdb/fsdb.c:1042:14: error: too many arguments to function > call, expected 0, have 1 >inodirty(curinode); > ^~~~ /usr/src/sbin/fsck_ffs/fsck.h:453:1: note: > 'inodirty' declared >here >voidinodirty(void); > > the sources are at 344869 It's good to see I'm not the only one experiencing this issue. It looks like r339941 was never merged to stable/12. -- Trond. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
