Re: dpb: packages not built, in 'H' state (no NFS, local build)
On 04/22/18 10:45, Andreas Kusalananda Kähäri wrote: > On Sun, Apr 22, 2018 at 10:01:28AM +0100, Nigel Taylor wrote: >> On 04/22/18 09:35, Andreas Kusalananda Kähäri wrote: >>> Hi, >>> >>> I'm using dpb in combination with proot to build a subset of packages on >>> my local machine. I quite often have an issue with packages not getting >>> built and instead being listed as in the 'H' state. According to the >>> dpb(1) manual, this is due to "package still not found due to nfs on >>> this run", but I'm not mounting anything on NFS. >>> >>> Examples of packages that ended up in this state in my most recent >>> build: >>> >>> lang/python/2.7 >>> devel/git >>> devel/shellcheck >>> >>> Python 2.7 (and 3.6) often end up in 'H'. >>> >>> What are the other reasons this may happen? >>> >>> Regards, >>> >> I seen this when I've updated the ports tree while dpb is running, the >> last in the list devel/shellcheck, has only recently been updated, so >> revision has changed from p0 to p1, you might have built p1 revision, >> but dpb is still looking for p0 revision as it doesn't rescan the ports >> tree once building started, so dpb has information that devel/shellcheck >> has been built, but can't see the matching package. >> >> This is the one I know off. >> > > Thanks. This does however not apply to my setup. I make sure the > usr/ports directory in the chroot directory is up to date before > starting dpb, and I don't touch it while it's running. Also, re-running > the build will quickly cycle through all packages and dependencies and > immediately put the same packages in the 'H' state. > > FWIW, I run dpb with > > dpb -B "$chroot_dir" -s -uU -R -M 2G \ > -P "$HOME/packages.txt" > > and I build the proot with the following configuration: > > actions=unpopulate > chroot=/extra/proot > preserve=/usr/ports > > After building the proot, I rsync over the ports directory from outside > the chroot (while doing this, I make sure that the two copies of > usr/ports are identical). > > The ports that end up in the 'H' state builds just fine in or outside > the chroot when I do "make package". > > > > I use a machine dedicated for building, I don't use -u -U -R -M -B -P options. -R is known to have issues. I used to use -R now I get around this, by using sqlports from previous build and the log from my cvs update to find packages that need rebuilding including dependencies and shared libs in WANTLIB and remove them before dpb is run. -M need all the memory to build some ports, until I add more RAM. Think there are also issues, or used to be. Need to set USE_MFS, WRKOBJDIR_MFS if comparing make to dpb. -u, -U - don't have any packages installed that haven't been built by current dpb run like -R known issues, or restarted run. -B I don't use proot, as using dedicated build machine. -P will read from files on command line by default not needed. My encounter with 'H' are on a different set up, you need someone using dpb in the same manner as you to comment.
Re: dpb: packages not built, in 'H' state (no NFS, local build)
On Sun, Apr 22, 2018 at 10:01:28AM +0100, Nigel Taylor wrote: > On 04/22/18 09:35, Andreas Kusalananda Kähäri wrote: > > Hi, > > > > I'm using dpb in combination with proot to build a subset of packages on > > my local machine. I quite often have an issue with packages not getting > > built and instead being listed as in the 'H' state. According to the > > dpb(1) manual, this is due to "package still not found due to nfs on > > this run", but I'm not mounting anything on NFS. > > > > Examples of packages that ended up in this state in my most recent > > build: > > > > lang/python/2.7 > > devel/git > > devel/shellcheck > > > > Python 2.7 (and 3.6) often end up in 'H'. > > > > What are the other reasons this may happen? > > > > Regards, > > > I seen this when I've updated the ports tree while dpb is running, the > last in the list devel/shellcheck, has only recently been updated, so > revision has changed from p0 to p1, you might have built p1 revision, > but dpb is still looking for p0 revision as it doesn't rescan the ports > tree once building started, so dpb has information that devel/shellcheck > has been built, but can't see the matching package. > > This is the one I know off. > Thanks. This does however not apply to my setup. I make sure the usr/ports directory in the chroot directory is up to date before starting dpb, and I don't touch it while it's running. Also, re-running the build will quickly cycle through all packages and dependencies and immediately put the same packages in the 'H' state. FWIW, I run dpb with dpb -B "$chroot_dir" -s -uU -R -M 2G \ -P "$HOME/packages.txt" and I build the proot with the following configuration: actions=unpopulate chroot=/extra/proot preserve=/usr/ports After building the proot, I rsync over the ports directory from outside the chroot (while doing this, I make sure that the two copies of usr/ports are identical). The ports that end up in the 'H' state builds just fine in or outside the chroot when I do "make package". -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
Re: dpb: packages not built, in 'H' state (no NFS, local build)
On 04/22/18 09:35, Andreas Kusalananda Kähäri wrote: > Hi, > > I'm using dpb in combination with proot to build a subset of packages on > my local machine. I quite often have an issue with packages not getting > built and instead being listed as in the 'H' state. According to the > dpb(1) manual, this is due to "package still not found due to nfs on > this run", but I'm not mounting anything on NFS. > > Examples of packages that ended up in this state in my most recent > build: > > lang/python/2.7 > devel/git > devel/shellcheck > > Python 2.7 (and 3.6) often end up in 'H'. > > What are the other reasons this may happen? > > Regards, > I seen this when I've updated the ports tree while dpb is running, the last in the list devel/shellcheck, has only recently been updated, so revision has changed from p0 to p1, you might have built p1 revision, but dpb is still looking for p0 revision as it doesn't rescan the ports tree once building started, so dpb has information that devel/shellcheck has been built, but can't see the matching package. This is the one I know off.
dpb: packages not built, in 'H' state (no NFS, local build)
Hi, I'm using dpb in combination with proot to build a subset of packages on my local machine. I quite often have an issue with packages not getting built and instead being listed as in the 'H' state. According to the dpb(1) manual, this is due to "package still not found due to nfs on this run", but I'm not mounting anything on NFS. Examples of packages that ended up in this state in my most recent build: lang/python/2.7 devel/git devel/shellcheck Python 2.7 (and 3.6) often end up in 'H'. What are the other reasons this may happen? Regards, -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
