Re: pkgsrc build server
At Fri, 10 Jul 2020 14:24:20 +0300, Denys Nykula wrote: Subject: Re: pkgsrc build server > > "Greg A. Woods" 4 July 2020, 23:58:24: > > > # use pkgtools/autoswc to cache some autoconf results > > # > > .sinclude "/usr/pkg/share/autoswc/autoswc.mk" > > Hello, after your letter I went to look what autoswc is. Its Makefile > hardcodes CACHEDIR and MKCONF to root paths, /var/db/autoswc and > /etc/mk.conf. What is the reason they're set this way and not to > VARBASE/db/autoswc and LOCALBASE/etc? Would it be possible to > pull in paths from mk.conf and cache autoconf results as an > unprivileged pkgsrc user? I'm sure it would be possible, but I'm guessing this is an indication of how well, or how poorly, that unprivileged pkgsrc use is supported at the moment. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpzIh9AXupZh.pgp Description: OpenPGP Digital Signature
Re: pkgsrc build server
"Greg A. Woods" 4 July 2020, 23:58:24: > # use pkgtools/autoswc to cache some autoconf results > # > .sinclude "/usr/pkg/share/autoswc/autoswc.mk" Hello, after your letter I went to look what autoswc is. Its Makefile hardcodes CACHEDIR and MKCONF to root paths, /var/db/autoswc and /etc/mk.conf. What is the reason they're set this way and not to VARBASE/db/autoswc and LOCALBASE/etc? Would it be possible to pull in paths from mk.conf and cache autoconf results as an unprivileged pkgsrc user?
Re: pkgsrc build server
On 04/07/2020 21:57, Greg A. Woods wrote: At Sat, 4 Jul 2020 21:01:26 +0300, Dima Veselov wrote: Subject: Re: pkgsrc build server What I want is to run "make install" on fast real production server with lot of resources once and then have all of those packages built in NFS DISTDIR so any VM can just install them. Yes, you can do that, provided the fast server runs the same OS that will run on the target VM. I share my /build FS from the build server(s) and install binary packages built there on production systems. With libkver its possible to set up chroots for other versions as long as the binaries will run on the current kernel. libkver allows you to lie about kernel version and arch (as long as the arch is compatible with the kernel). On 9.0-STABLE amd64 I build binary packages for 9.0 amd64, 8.2 amd64 and also for 8.2 i386 and 9.x i386. I do this with home grown scripts based around libkver + chroot. libkver is in pkgsrc. I do this for exactly the reasons the original poster flagged. I don't want my pkgsrc builds taking down a server and I want my target systems to only have runtime dependencies install rather than all the build ones as well. pkg_comp1 supports most of this but I found its internal package building logic a little bit inflexible for my needs which is what led to the homegrown scripts. A pbulk based chroot using libkver may be better if working from in pkgsrc components. Mike
Re: pkgsrc build server
rhia...@falu.nl (Rhialto) writes: >> You can also use the pbulk system to build in a chroot. To >Pkg_comp is I think a bit easier to set up than pbulk I think. Also you >can "go into" the chroot interactively and poke around by hand, if >packages don't build (which will happen of course). That's unrelated. You can enter the chroot, whether you run pkg_comp or pbulk in it. I use sandboxctl to create the chroot environment and that's pretty easy to use. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: pkgsrc build server
On Sat 04 Jul 2020 at 19:53:45 -, Michael van Elst wrote: > Building in a chroot is the most useful way, and it avoids > conflicts with the (productive) host installation. > > You can look at the pkg_comp package that does exactly that. That is what I do. There are pkg_comp1 and pkg_comp (which is a 2.x version). I started when pkg_comp1 was the only version that existed and never saw a reason to switch to version 2. > You can also use the pbulk system to build in a chroot. To Pkg_comp is I think a bit easier to set up than pbulk I think. Also you can "go into" the chroot interactively and poke around by hand, if packages don't build (which will happen of course). -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: pkgsrc build server
mayur...@acm.org (Mayuresh) writes: >On Sat, Jul 04, 2020 at 09:49:32PM -0400, Greg Troxel wrote: >> >> I would say: don't ever use make update. >> > Why does something exist that isn't to be used `ever'? >> You seeme to have conflated "I would say" and "everyone woudl say". >It's worthwhile to explain why even you'd say and my question is merely a >hint to provoke an insightful answer. The update process is pretty brittle. Updates may fail, due to broken packages, unresolved dependencies or due to local errors. Since updates work by recursively deleting, building and re-adding things, you'll end with a system were possibly many packages have been deleted and that cannot be added simply again. >> I think the notion that replace is risky and update is not is confused. >Depends on how you define the risk. >replace can lead to packages that are alive (installed) but inconsistent >with each other [would exist but won't possibly run] >update can lead to packages getting wiped out *if* there are build errors. Yes. But the damage from update is usually much larger and not easily recoverable unless you have the old pkgsrc tree (and distfiles) available somewhere. >To me there is no value in having a package installed but not functioning >- giving me a just a false feel of safety of its existence. >Also, if I am doing a compilation on non-prod build server wipe out is no >risk IMO. >I'd use replace when I know exactly what I am doing and not as a default. I neither do source updates or replaces. I build in a separate chroot and add/update from the generated binary packages. Everything else proved to be a waste of time. I ended too often in a situation where I had to re-build everything (and fix a few packages in between). It's still the same effort (in terms of computer ressources), but it's now mostly automated. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: pkgsrc build server
Mayuresh writes: > On Sat, Jul 04, 2020 at 09:49:32PM -0400, Greg Troxel wrote: >> >> I would say: don't ever use make update. >> > Why does something exist that isn't to be used `ever'? >> You seeme to have conflated "I would say" and "everyone woudl say". > > It's worthwhile to explain why even you'd say and my question is merely a > hint to provoke an insightful answer. My usage is often on computers that I expect to work. Having a large number of missing packages is bad, and I have found that there is no easy way to continue a failed make update and get back to things. >> I think the notion that replace is risky and update is not is confused. > > Depends on how you define the risk. indeed. > replace can lead to packages that are alive (installed) but inconsistent > with each other [would exist but won't possibly run] true, but it's remarkably rare. I basically on do pkg_rr, which when it completes resolves the inconsistencies. > update can lead to packages getting wiped out *if* there are build errors. > > To me there is no value in having a package installed but not functioning > - giving me a just a false feel of safety of its existence. So obviously you should run pbulk in a chroot. > Also, if I am doing a compilation on non-prod build server wipe out is no > risk IMO. which is sort of like pbulk.
Re: pkgsrc build server
On Sat, Jul 04, 2020 at 09:49:32PM -0400, Greg Troxel wrote: > >> I would say: don't ever use make update. > > Why does something exist that isn't to be used `ever'? > You seeme to have conflated "I would say" and "everyone woudl say". It's worthwhile to explain why even you'd say and my question is merely a hint to provoke an insightful answer. > I think the notion that replace is risky and update is not is confused. Depends on how you define the risk. replace can lead to packages that are alive (installed) but inconsistent with each other [would exist but won't possibly run] update can lead to packages getting wiped out *if* there are build errors. To me there is no value in having a package installed but not functioning - giving me a just a false feel of safety of its existence. Also, if I am doing a compilation on non-prod build server wipe out is no risk IMO. I'd use replace when I know exactly what I am doing and not as a default.
Re: pkgsrc build server
Mayuresh writes: > On Sat, Jul 04, 2020 at 02:15:13PM -0400, Greg Troxel wrote: >> I would say: don't ever use make update. > Why does something exist that isn't to be used `ever'? You seeme to have conflated "I would say" and "everyone woudl say". >> Use pkg_rolling-replace if you need to. > Isn't replace a risky target in event of changes that require recursively > building what depends on the package replaced? I guess it still carries a > warning. I think the notion that replace is risky and update is not is confused. It is perhaps true that *if* update finishes succcessfully your system will be consistent. But I have seen update fail to complete. With make replace/pkg_rr, you get to fix and keep trying. The 'safe' thing is to run pbulk and build everything you need, and only when you are sure you have it all, do a pkgin fug.
Re: pkgsrc build server
On Sat, Jul 04, 2020 at 02:15:13PM -0400, Greg Troxel wrote: > I would say: don't ever use make update. Why does something exist that isn't to be used `ever'? > Use pkg_rolling-replace if you need to. Isn't replace a risky target in event of changes that require recursively building what depends on the package replaced? I guess it still carries a warning.
Re: pkgsrc build server
At Sat, 4 Jul 2020 21:01:26 +0300, Dima Veselov wrote: Subject: Re: pkgsrc build server > > What I want is to run "make install" on fast real production server > with lot of resources once and then have all of those packages built in > NFS DISTDIR so any VM can just install them. Yes, you can do that, provided the fast server runs the same OS that will run on the target VM. I share my /build FS from the build server(s) and install binary packages built there on production systems. You may have to arrange for pkgsrc to build binary packages for you, and I think that's relatively easy now with something like this in your /etc/mk.conf (i.e. on the build server), though I must warn I may have missed somthing that I've more permanently hacked on in my pkgsrc tree (there are some other nice things shown here too). # This section is just for pkgsrc # .if defined(BSD_PKG_MK) # carefully share host settings for packages with BSD-Style makefiles # PKGMAKECONF = /etc/mk.conf INSTALL_UNSTRIPPED =YES DEFAULT_DEPENDS_TARGET =package DEFAULT_UPDATE_TARGET ?=package DEPENDS_TARGET =update UPDATE_TARGET = package-install # uncomment this if you sometimes manually build packages and might miss # some dependency that was built without "make update" or "make package" # and thus which still needs a "make package" run to build the binary # package. # #CLEANDEPENDS= no # use pkgtools/autoswc to cache some autoconf results # .sinclude "/usr/pkg/share/autoswc/autoswc.mk" .endif # BSD_PKG_MK As others have warned though, be careful about mixing packages from different pkgsrc trees. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpkECIGDsJhb.pgp Description: OpenPGP Digital Signature
Re: pkgsrc build server
kab...@lich.phys.spbu.ru (Dima Veselov) writes: >Is there an opportunity to build a package with dependencies >on production server without installing all dependencies? >Maybe we can deploy NetBSD dist into a directory and build >pkgsrc in chroot environment or there is more smooth >way to do that? Building in a chroot is the most useful way, and it avoids conflicts with the (productive) host installation. You can look at the pkg_comp package that does exactly that. You can also use the pbulk system to build in a chroot. To some degree (and with some hacks) it can also be used to build for a system with a different OS release than the host, e.g. to build packages for netbsd-8 when the build host already runs netbsd-9. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: pkgsrc build server
On Sat, 4 Jul 2020 at 17:07, Dima Veselov wrote: > > Greetings, > Is there an opportunity to build a package with dependencies > on production server without installing all dependencies? [This should belong to pkgsrc-users@] I'd have thought it's not possible, however: ===> ../../mk/depends/bsd.depends.mk # SKIP_DEPENDS # Whether to run the ``depends'' phase. This is probably only # useful for pkgsrc developers. # # Default value: no I'm not sure what the practicality of this option is, to be honest. -- Ottavio Caruso
Re: pkgsrc build server
04.07.2020 19:34, Greg Troxel wrote: Is there an opportunity to build a package with dependencies on production server without installing all dependencies? Maybe we can deploy NetBSD dist into a directory and build pkgsrc in chroot environment or there is more smooth way to do that? I don't understand what you want. Sorry my fault I wasn't clear. I run a network with bunch of NetBSD servers. I have DISTDIR, RELEASEDIR, PKGSRCDIR on NFS share. When we update systems one real production server (let's say mail server) builds distribution sets which would be rolled out on all NetBSD systems. But any of that systems have to build its own packages by itself - let's say web VMs need lighttpd. I would like to use production server to build packages with deps to put all them in DESTDIR and roll it later to those who need it. But in this example mail server have its own structure and history like it has postfix compiled from pkgsrc-2019Q1 and its okay. If I build lighttpd on mail server it 1) will interfere in underlying packages and may demand to remove postfix what is pointless for mail server, 2) will make a mess of dependencies which will make me do lot of work later. If you want to avoid intalling things, you can run pbulk, but this will use more space, but with better isolation. That seems to be an answer if pbulk is capable of building not the whole pkgsrc tree. I will try it. Thank you! -- Dima Veselov Physics R Establishment of Saint-Petersburg University
Re: pkgsrc build server
Dima Veselov writes: > Good example I had started to concern was building SOGo (not built in > pkgsrc releases) which also depend on LLVM/cLang 10 in pkgsrc-current, > but only 9 is available in 2020Q1. I tried to build it on VM and this was > quite a mistake - it took several days and about 5 Gb to complete. > > Anyway binary installation of underlying packages takes lot of time > of me and hit the versions difference between -current and last > release. Maybe I should try nightly pkgsrc builds? mixing pkgsrc head and stable branches is asking for trouble. You're welcome to do it, but "when I do this things don't work" reports will be (should be) rejected as an out-of-order bug report. > My pkgsrc tree and DISTDIR are separated on NFS shares available > for all used servers. > > What I want is to run "make install" on fast real production server > with lot of resources once and then have all of those packages built in > NFS DISTDIR so any VM can just install them. Then I think you want a pbulk chroot. >> - Use make update. This reduces space requirements drastically by cleaning >>each work area on each package's installation. > > Thats a good point, thanks. I would say: don't ever use make update. Use pkg_rolling-replace if you need to. But really set up pbulk. > In mentioned SOGo build I had to delete distfiles between dependencies when > they were failing because of space. :-) that means you don't really have enough space to do what you want to do. Use gluster/NFS or get more. > Sorry if my original question wasn't certain enough. There is no need to > shrink building space. I can give unlimited space and lot of resources to > build process, but I have it only on production servers and I don't want > to mess them with packages they do not need. Then pbulk in a chroot.
Re: pkgsrc build server
On Sat, Jul 04, 2020 at 09:01:26PM +0300, Dima Veselov wrote: > Sorry if my original question wasn't certain enough. There is no need to > shrink building space. I can give unlimited space and lot of resources to > build process, but I have it only on production servers and I don't want > to mess them with packages they do not need. Then the problem is unclear to me. I assume you want a build environment that is separate from prod and in the build env you have a space crunch. To summarize my last mail in short: 1. work area: use update to minimize space usage 2. distfiles: keep deleting 3. packages: store away 4. pkg on build server (not on prod server): I don't know a systematic answer. I can just say keep deleting large packages at higher levels. Please ignore all this if you don't have a space crunch. -- Mayuresh
Re: pkgsrc build server
04.07.2020 19:51, Mayuresh пишет: On Sat, Jul 04, 2020 at 07:07:02PM +0300, Dima Veselov wrote: Is there an opportunity to build a package with dependencies on production server without installing all dependencies? Maybe we can deploy NetBSD dist into a directory and build pkgsrc in chroot environment or there is more smooth way to do that? If that suits you, and if available for your platform, you can use binary installation - at least for lower level packages. Only thing to watch is for all the dependencies your and binary distribution's configuration options are same. Good example I had started to concern was building SOGo (not built in pkgsrc releases) which also depend on LLVM/cLang 10 in pkgsrc-current, but only 9 is available in 2020Q1. I tried to build it on VM and this was quite a mistake - it took several days and about 5 Gb to complete. Anyway binary installation of underlying packages takes lot of time of me and hit the versions difference between -current and last release. Maybe I should try nightly pkgsrc builds? My pkgsrc tree and DISTDIR are separated on NFS shares available for all used servers. What I want is to run "make install" on fast real production server with lot of resources once and then have all of those packages built in NFS DISTDIR so any VM can just install them. - Check out from CVS or if you are using git, use --depth 1 to keep source size less. I am using CVS and keep pkgsrc tree on NFS apart from build directory. - Use make update. This reduces space requirements drastically by cleaning each work area on each package's installation. Thats a good point, thanks. - Delete distfiles. In mentioned SOGo build I had to delete distfiles between dependencies when they were failing because of space. :-) - If possible, store packages away on some other server if you are using the build server only for build and consumers of the packages are different machines. You can possibly use NFS mount for that. This is also done. - The only concern I don't have a good answer to (others can suggest) is trimming the pkg space. Here the server is exclusively a build server and packages aren't used here. When required for build, it should be possible for the system to install from packages (unless version/ configuration has changed). Not aware if there is a way to manage that. Sorry if my original question wasn't certain enough. There is no need to shrink building space. I can give unlimited space and lot of resources to build process, but I have it only on production servers and I don't want to mess them with packages they do not need. It's a bit complex as you'd not want all packages to be deleted by default. But even assuming you supply that list manually, can pkgsrc install them on demand and uninstall afterwards automatically? That is possible, but I am very afraid of a mess leaved afterwards and also build server can have its own needs interfering with what it compile. -- Dima Veselov Physics R Establishment of Saint-Petersburg University
Re: pkgsrc build server
On Sat, Jul 04, 2020 at 07:07:02PM +0300, Dima Veselov wrote: > Is there an opportunity to build a package with dependencies > on production server without installing all dependencies? > Maybe we can deploy NetBSD dist into a directory and build > pkgsrc in chroot environment or there is more smooth > way to do that? If that suits you, and if available for your platform, you can use binary installation - at least for lower level packages. Only thing to watch is for all the dependencies your and binary distribution's configuration options are same. Other things I can suggest are: - Check out from CVS or if you are using git, use --depth 1 to keep source size less. - Use make update. This reduces space requirements drastically by cleaning each work area on each package's installation. - Delete distfiles. - If possible, store packages away on some other server if you are using the build server only for build and consumers of the packages are different machines. You can possibly use NFS mount for that. - The only concern I don't have a good answer to (others can suggest) is trimming the pkg space. Here the server is exclusively a build server and packages aren't used here. When required for build, it should be possible for the system to install from packages (unless version/ configuration has changed). Not aware if there is a way to manage that. It's a bit complex as you'd not want all packages to be deleted by default. But even assuming you supply that list manually, can pkgsrc install them on demand and uninstall afterwards automatically? -- Mayuresh
Re: pkgsrc build server
Dima Veselov writes: > Sometimes we need to compile a package with lot of > dependencies, let's say to use it on NetBSD VM. On one hand VM > is limited in memory, CPU and especially disk space, on other > hand we aren't rich enough to have separate server for pkgsrc > builds. a plausible sceenario > Is there an opportunity to build a package with dependencies > on production server without installing all dependencies? > Maybe we can deploy NetBSD dist into a directory and build > pkgsrc in chroot environment or there is more smooth > way to do that? I don't understand what you want. If you are short on disk space, but want a package installed, then you can build it, and dependencies will get built and installed. You need the dependencies installed to run anyway. If you want to avoid intalling things, you can run pbulk, but this will use more space, but with better isolation. If your concern is space from build-time dependencies not needed at runtime, then you can uninstall them afterwards.
pkgsrc build server
Greetings, Sometimes we need to compile a package with lot of dependencies, let's say to use it on NetBSD VM. On one hand VM is limited in memory, CPU and especially disk space, on other hand we aren't rich enough to have separate server for pkgsrc builds. Is there an opportunity to build a package with dependencies on production server without installing all dependencies? Maybe we can deploy NetBSD dist into a directory and build pkgsrc in chroot environment or there is more smooth way to do that? -- Dima Veselov Physics R Establishment of Saint-Petersburg University
