Re: Gracefully killing and restarting a port build....
On 2020-07-08 14:53, bob prohaska wrote: > > AIUI, screen runs until the session terminates and then stops... I'm a tmux user now, but I never experienced this behavior when I used screen. Screen was my go-to workaround for a flaky Internet connection to the host I was trying to manage. Tmux certainly does not exhibit this behavior. You may have to detach a session before you can reattach to it, but that's it. > think screen would have quit as well. Just why ssh connections keep breaking > is a mystery of long standing... Have you set a ServerAliveInterval in your ssh config file? http://man.openbsd.org/ssh_config#ServerAliveInterval HTH, Jose ___ 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: Gracefully killing and restarting a port build....
On Wed., Jul. 8, 2020, 2:53 p.m. bob prohaska, wrote: > On Wed, Jul 08, 2020 at 09:34:53AM -0600, Janky Jay, III wrote: > > In the future, if you can, try using "screen" or "tmux" to run these > > large builds in so you don't take the risk of losing the > > terminal/console. Or, maybe I'm completely off-base as to how it was > > lost to begin with. > > > > AIUI, screen runs until the session terminates and then stops. In my case > the controlling terminal was lost when the ssh connection broke. Thus, I > think screen would have quit as well. Nope. Screen (or tmux which is nicer to use, imo) takes over as the controlling terminal. When the ssh connection terminates, screen continues running (along with all the processes started in that screen session). You reconnect via ssh, and connect to the running screen session and carry on like nothing happened. Cheers, Freddie Typos due to smartphone keyboard. ___ 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: Gracefully killing and restarting a port build....
On Wed, Jul 08, 2020 at 09:34:53AM -0600, Janky Jay, III wrote: > In the future, if you can, try using "screen" or "tmux" to run these > large builds in so you don't take the risk of losing the > terminal/console. Or, maybe I'm completely off-base as to how it was > lost to begin with. > AIUI, screen runs until the session terminates and then stops. In my case the controlling terminal was lost when the ssh connection broke. Thus, I think screen would have quit as well. Just why ssh connections keep breaking is a mystery of long standing. I've been blaming it on feeble wifi between my workstation (a Pi3B+) and WAP (D-Link DI524) but have no persuasive evidence. Not usually a big deal. The build was started using something like make [options] > make.log & so it kept beavering away after ssh gave up and still existed when I looked for it with ps -a. There were still other ssh connections open and running at the same time. Is there some way to re-attach a running background job to a new controlling terminal? Thanks for writing! bob prohaska > On 7/8/20 9:30 AM, bob prohaska wrote: > > On Wed, Jul 08, 2020 at 10:44:03AM +0200, Ronald Klop wrote: > >> > >> Kill the leaf nodes of the process tree. So kill the c++ processes. Or > >> type ctrl-c if you have control of the terminal. > > In this case I'd lost control of the controlling terminal and didn't > > know how to recover it. After kill -9 of the initial make process > > I left the system standing overnight, to see if killing the original make > > process would eventually propagate down to the leaf nodes. It didn't. > > > > Then I used killall c++, and again, it killed the named processes, but > > other things, > > notably pkg, kept running. After waiting a few minutes they were killall-ed. > > A notation from ninja eventually showed up in the logfile saying > > "interrupted > > by user", so maybe ninja was the place to start shutting things down. > > > >> If you are running the compile in a jail (like poudriere) you might use > >> "killall -j c++" or something similar. > > No room for a jail on a Pi, alas > >> Pkill can be usable also. > > Thank you, I didn't know about it. > >> BTW: How graceful a restart works is outside of the scope of the ports > >> framework and depends a lot on the structure of the chromium build process > >> itself. > >> > > Understood. This is the first time I've ever needed to kill a port build. > > Usually they die prematurely of natural causes! > > > > Thanks for your help > > > > bob prohaska > > > > ___ > > 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" > > ___ > 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" ___ 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: Gracefully killing and restarting a port build....
On Wed, 8 Jul 2020 08:30:13 -0700 bob prohaska f...@www.zefox.net said On Wed, Jul 08, 2020 at 10:44:03AM +0200, Ronald Klop wrote: > > > Kill the leaf nodes of the process tree. So kill the c++ processes. Or type > ctrl-c if you have control of the terminal. In this case I'd lost control of the controlling terminal and didn't know how to recover it. After kill -9 of the initial make process I left the system standing overnight, to see if killing the original make process would eventually propagate down to the leaf nodes. It didn't. Then I used killall c++, and again, it killed the named processes, but other things, notably pkg, kept running. After waiting a few minutes they were killall-ed. A notation from ninja eventually showed up in the logfile saying "interrupted by user", so maybe ninja was the place to start shutting things down. > If you are running the compile in a jail (like poudriere) you might use > "killall -j c++" or something similar. No room for a jail on a Pi, alas > Pkill can be usable also. Thank you, I didn't know about it. > BTW: How graceful a restart works is outside of the scope of the ports > framework and depends a lot on the structure of the chromium build process > itself. > Understood. This is the first time I've ever needed to kill a port build. Usually they die prematurely of natural causes! FWIW should you need to attempt such a strategy again. You'll want to add sh (/bin/sh) to the list of potential "victims" in your kill list. :-) --Chris Thanks for your help bob prohaska ___ 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" ___ 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: Gracefully killing and restarting a port build....
On Tue, 7 Jul 2020 20:47:03 -0700 bob prohaska f...@www.zefox.net said While compiling www/chromium on a Pi3B it has become clear that the default -j4 isn't going to work (yes, I know, ya told me). On the plus side, it hasn't crashed, despite several days of continuous swapping with 1-2GB of swap in use. Kudos to the VM folks. Now I'd like to (gracefully) stop the make and restart it with more sane -j values. -2 seems like a reasonable start. A simple kill aimed at the original make doesn't seem to do anything. Even kill -9 appears to have no effect on the c++ threads, which are still running minutes afterwards. Now it seems rather like I'm stuck: The original is gone, but c++ is still grinding away as if nothing has changed.. Is there a better way to accomplish a clean(ish) stop and restart of a multi-threaded make process? Thanks for reading, apologies if it's a dumb question, Not at all. :-) I usually leverage multiple terminals, and simply dedicate one to the/a build session. So simply issuing a ^C to that terminal sends an INTR to the parent, and children. I've experienced no problems restarting the process (build) after doing so. HTH! :-) --Chris bob prohaska ___ 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" ___ 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: Gracefully killing and restarting a port build....
In the future, if you can, try using "screen" or "tmux" to run these large builds in so you don't take the risk of losing the terminal/console. Or, maybe I'm completely off-base as to how it was lost to begin with. On 7/8/20 9:30 AM, bob prohaska wrote: > On Wed, Jul 08, 2020 at 10:44:03AM +0200, Ronald Klop wrote: >> >> Kill the leaf nodes of the process tree. So kill the c++ processes. Or type >> ctrl-c if you have control of the terminal. > In this case I'd lost control of the controlling terminal and didn't > know how to recover it. After kill -9 of the initial make process > I left the system standing overnight, to see if killing the original make > process would eventually propagate down to the leaf nodes. It didn't. > > Then I used killall c++, and again, it killed the named processes, but other > things, > notably pkg, kept running. After waiting a few minutes they were killall-ed. > A notation from ninja eventually showed up in the logfile saying "interrupted > by user", so maybe ninja was the place to start shutting things down. > >> If you are running the compile in a jail (like poudriere) you might use >> "killall -j c++" or something similar. > No room for a jail on a Pi, alas >> Pkill can be usable also. > Thank you, I didn't know about it. >> BTW: How graceful a restart works is outside of the scope of the ports >> framework and depends a lot on the structure of the chromium build process >> itself. >> > Understood. This is the first time I've ever needed to kill a port build. > Usually they die prematurely of natural causes! > > Thanks for your help > > bob prohaska > > ___ > 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" ___ 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: Gracefully killing and restarting a port build....
On Wed, Jul 08, 2020 at 10:44:03AM +0200, Ronald Klop wrote: > > > Kill the leaf nodes of the process tree. So kill the c++ processes. Or type > ctrl-c if you have control of the terminal. In this case I'd lost control of the controlling terminal and didn't know how to recover it. After kill -9 of the initial make process I left the system standing overnight, to see if killing the original make process would eventually propagate down to the leaf nodes. It didn't. Then I used killall c++, and again, it killed the named processes, but other things, notably pkg, kept running. After waiting a few minutes they were killall-ed. A notation from ninja eventually showed up in the logfile saying "interrupted by user", so maybe ninja was the place to start shutting things down. > If you are running the compile in a jail (like poudriere) you might use > "killall -j c++" or something similar. No room for a jail on a Pi, alas > Pkill can be usable also. Thank you, I didn't know about it. > BTW: How graceful a restart works is outside of the scope of the ports > framework and depends a lot on the structure of the chromium build process > itself. > Understood. This is the first time I've ever needed to kill a port build. Usually they die prematurely of natural causes! Thanks for your help bob prohaska ___ 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: net/qt5-network
On Wed, 8 Jul 2020 15:44:21 +0200, Christoph Moench-Tegeder stated: >## Carmel NY (carmel...@outlook.com): > >> The entire build log, what there is of it, is available here: >> https://seibercom.net/logs/qt5-network_build.log > >And there's your problem: >: /usr/local/etc/poudriere.d/make.conf >: >: LICENSES_ACCEPTED+= PDFlib > >: DEFAULT_VERSIONS=samba=4.11 >: DEFAULT_VERSIONS+=ssl=openssl >: DEFAULT_VERSIONS=mysql=8.0 >: DEFAULT_VERSIONS=python=3.7 >: DEFAULT_VERSIONS=python3=3.7 > >You are setting DEFAULT_VERSIONS multiple times, always writing over >the previous assignment (except for that one line for "ssl=openssl", >but that's overwritten with the next line again). >Either use > DEFAULT_VERSIONS=samba=4.11 ssl=openssl mysql=8.0 [...] >or > DEFAULT_VERSIONS+=samba=4.11 > DEFAULT_VERSIONS+=ssl=openssl > DEFAULT_VERSIONS+=mysql=8.0 > [...] > >If you use the multiline version, use "+=" consistenly - it's way too >easy to copy the first line and accidently use "=" (assignment, not >addition). >See make(1), section "VARIABLE ASSIGNMENTS" for details on that syntax. > >BTW, the same goes for WITH_DEBUG_PORTS. >Didn't you notice that you got wrong mysql and samba versions? >Also, you can use "make -V DEFAULT_VERSIONS" in any port directory >to check your settings (as far as they're in /etc/make.conf). > >Regards, >Christoph Thanks, that was the problem. Interestingly enough, it had never bitten me in the 'ass' before this, and that is for a period of over a year. -- Carmel ___ 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: net/qt5-network
## Carmel NY (carmel...@outlook.com): > The entire build log, what there is of it, is available here: > https://seibercom.net/logs/qt5-network_build.log And there's your problem: : /usr/local/etc/poudriere.d/make.conf : : LICENSES_ACCEPTED+= PDFlib : DEFAULT_VERSIONS=samba=4.11 : DEFAULT_VERSIONS+=ssl=openssl : DEFAULT_VERSIONS=mysql=8.0 : DEFAULT_VERSIONS=python=3.7 : DEFAULT_VERSIONS=python3=3.7 You are setting DEFAULT_VERSIONS multiple times, always writing over the previous assignment (except for that one line for "ssl=openssl", but that's overwritten with the next line again). Either use DEFAULT_VERSIONS=samba=4.11 ssl=openssl mysql=8.0 [...] or DEFAULT_VERSIONS+=samba=4.11 DEFAULT_VERSIONS+=ssl=openssl DEFAULT_VERSIONS+=mysql=8.0 [...] If you use the multiline version, use "+=" consistenly - it's way too easy to copy the first line and accidently use "=" (assignment, not addition). See make(1), section "VARIABLE ASSIGNMENTS" for details on that syntax. BTW, the same goes for WITH_DEBUG_PORTS. Didn't you notice that you got wrong mysql and samba versions? Also, you can use "make -V DEFAULT_VERSIONS" in any port directory to check your settings (as far as they're in /etc/make.conf). Regards, Christoph -- Spare Space ___ 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: net/qt5-network
On Wed, 8 Jul 2020 16:30:52 +0400, Gleb Popov stated: >On Wed, Jul 8, 2020 at 4:28 PM Carmel NY wrote: > >> >On Wed, 8 Jul 2020 at 13:10, Carmel NY >> >wrote: >> >> >> >> FreeBSD 11.4-RELEASE >> >> >> >> With a freshly updated ports tree, when I attempt to run >> >> poudriere to update the installed ports, I am greeted with this >> >> warning: >> >> >> >> [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is >> >> marked as broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD >> >> 12.x/13.x or add DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to >> >> /etc/make.conf >> >> >> >> Subsequently, 339 ports are skipped, and now I cannot get 'X' to >> >> start. I have "DEFAULT_VERSIONS+=ssl=openssl" in both the >> >> '/etc/make.conf' file and the 'poudriere.d/make.conf' file. >> >> >> >> $ openssl version >> >> OpenSSL 1.1.1g 21 Apr 2020 >> >> >> >> I cannot install version 12 or 13 of FreeBSD because of an >> >> squashed bug, >> >> "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666; >> >> >> >> I have I correct this problem? >> >> >> >> Thanks >> >> On Wed, 8 Jul 2020 13:20:39 +0200, Tobias C. Berner stated: >> >Moin moin >> > >> >As you see the Ignore-message, I would say that your make.conf is >> >not used by poudriere. >> >> I think that is obvious. What I am trying to determine is how to >> correct the situation. > >man poudriere, section "CUSTOMISATION", subsection "Create optional >make.conf" That was part of my original poudriere configuration when I first installed FreeBSD 11.0 awhile ago. That is not the problem. The entire build log, what there is of it, is available here: https://seibercom.net/logs/qt5-network_build.log -- Carmel ___ 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: net/qt5-network
On Wed, Jul 8, 2020 at 4:28 PM Carmel NY wrote: > >On Wed, 8 Jul 2020 at 13:10, Carmel NY wrote: > >> > >> FreeBSD 11.4-RELEASE > >> > >> With a freshly updated ports tree, when I attempt to run poudriere to > >> update the installed ports, I am greeted with this warning: > >> > >> [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked > >> as broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x > >> or add DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf > >> > >> Subsequently, 339 ports are skipped, and now I cannot get 'X' to > >> start. I have "DEFAULT_VERSIONS+=ssl=openssl" in both the > >> '/etc/make.conf' file and the 'poudriere.d/make.conf' file. > >> > >> $ openssl version > >> OpenSSL 1.1.1g 21 Apr 2020 > >> > >> I cannot install version 12 or 13 of FreeBSD because of an squashed > >> bug, "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666; > >> > >> I have I correct this problem? > >> > >> Thanks > > On Wed, 8 Jul 2020 13:20:39 +0200, Tobias C. Berner stated: > >Moin moin > > > >As you see the Ignore-message, I would say that your make.conf is not > >used by poudriere. > > I think that is obvious. What I am trying to determine is how to > correct the situation. > man poudriere, section "CUSTOMISATION", subsection "Create optional make.conf" ___ 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: net/qt5-network
>On Wed, 8 Jul 2020 at 13:10, Carmel NY wrote: >> >> FreeBSD 11.4-RELEASE >> >> With a freshly updated ports tree, when I attempt to run poudriere to >> update the installed ports, I am greeted with this warning: >> >> [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked >> as broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x >> or add DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf >> >> Subsequently, 339 ports are skipped, and now I cannot get 'X' to >> start. I have "DEFAULT_VERSIONS+=ssl=openssl" in both the >> '/etc/make.conf' file and the 'poudriere.d/make.conf' file. >> >> $ openssl version >> OpenSSL 1.1.1g 21 Apr 2020 >> >> I cannot install version 12 or 13 of FreeBSD because of an squashed >> bug, "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666; >> >> I have I correct this problem? >> >> Thanks On Wed, 8 Jul 2020 13:20:39 +0200, Tobias C. Berner stated: >Moin moin > >As you see the Ignore-message, I would say that your make.conf is not >used by poudriere. I think that is obvious. What I am trying to determine is how to correct the situation. -- Jerry ___ 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: net/qt5-network
Moin moin As you see the Ignore-message, I would say that your make.conf is not used by poudriere. mfg Tobias On Wed, 8 Jul 2020 at 13:10, Carmel NY wrote: > > FreeBSD 11.4-RELEASE > > With a freshly updated ports tree, when I attempt to run poudriere to > update the installed ports, I am greeted with this warning: > > [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked as > broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x or add > DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf > > Subsequently, 339 ports are skipped, and now I cannot get 'X' to start. > I have "DEFAULT_VERSIONS+=ssl=openssl" in both the '/etc/make.conf' > file and the 'poudriere.d/make.conf' file. > > $ openssl version > OpenSSL 1.1.1g 21 Apr 2020 > > I cannot install version 12 or 13 of FreeBSD because of an squashed > bug, "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666; > > I have I correct this problem? > > Thanks > > -- > Carmel ___ 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"
net/qt5-network
FreeBSD 11.4-RELEASE With a freshly updated ports tree, when I attempt to run poudriere to update the installed ports, I am greeted with this warning: [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked as broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x or add DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf Subsequently, 339 ports are skipped, and now I cannot get 'X' to start. I have "DEFAULT_VERSIONS+=ssl=openssl" in both the '/etc/make.conf' file and the 'poudriere.d/make.conf' file. $ openssl version OpenSSL 1.1.1g 21 Apr 2020 I cannot install version 12 or 13 of FreeBSD because of an squashed bug, "https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666; I have I correct this problem? Thanks -- Carmel pgpMTIUEK9hyF.pgp Description: OpenPGP digital signature
Re: State changes via pkg's scripts
On 8/07/2020 5:23 pm, Baptiste Daroussin wrote: > On Wed, Jul 08, 2020 at 04:32:34PM +1000, Dewayne Geraghty wrote: >> Is there a more convenient method to examine a package's scripts than >> unpacking the manifest file and >> # cat +MANIFEST | jq -rM '.scripts' >> ? As I'd like to know what changes will, or have been applied. > > pkg info --raw-format json -R yourpkg | jq -rM '.scripts' > > So far noone added a better interface yet, it should not be difficult to add > > Best regards, > Bapt > Unfortunate. Thank-you, that is helpful. Kind regards, Dewayne. ___ 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: Gracefully killing and restarting a port build....
Van: bob prohaska Datum: woensdag, 8 juli 2020 05:47 Aan: freebsd-ports@freebsd.org Onderwerp: Gracefully killing and restarting a port build While compiling www/chromium on a Pi3B it has become clear that the default -j4 isn't going to work (yes, I know, ya told me). On the plus side, it hasn't crashed, despite several days of continuous swapping with 1-2GB of swap in use. Kudos to the VM folks. Now I'd like to (gracefully) stop the make and restart it with more sane -j values. -2 seems like a reasonable start. A simple kill aimed at the original make doesn't seem to do anything. Even kill -9 appears to have no effect on the c++ threads, which are still running minutes afterwards. Now it seems rather like I'm stuck: The original is gone, but c++ is still grinding away as if nothing has changed.. Is there a better way to accomplish a clean(ish) stop and restart of a multi-threaded make process? Thanks for reading, apologies if it's a dumb question, bob prohaska ___ 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" Kill the leaf nodes of the process tree. So kill the c++ processes. Or type ctrl-c if you have control of the terminal. If you are running the compile in a jail (like poudriere) you might use "killall -j c++" or something similar. Pkill can be usable also. BTW: How graceful a restart works is outside of the scope of the ports framework and depends a lot on the structure of the chromium build process itself. Regards, Ronald. ___ 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: State changes via pkg's scripts
On Wed, Jul 08, 2020 at 04:32:34PM +1000, Dewayne Geraghty wrote: > Is there a more convenient method to examine a package's scripts than > unpacking the manifest file and > # cat +MANIFEST | jq -rM '.scripts' > ? As I'd like to know what changes will, or have been applied. pkg info --raw-format json -R yourpkg | jq -rM '.scripts' So far noone added a better interface yet, it should not be difficult to add Best regards, Bapt signature.asc Description: PGP signature
Re: State changes via pkg's scripts
On 8/07/2020 4:52 pm, Dave Horsfall wrote: > On Wed, 8 Jul 2020, Dewayne Geraghty wrote: > >> # cat +MANIFEST | jq -rM '.scripts' > > Sorry, but this always pushes one of my buttons. When using "cat file | > proc" > what's wrong with "proc < file"? > > -- Dave Almost answered the question. :) I was being explicit (and mentally lazy) though saving an extra three characters is better. ;) ___ 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: State changes via pkg's scripts
On Wed, 8 Jul 2020, Dewayne Geraghty wrote: # cat +MANIFEST | jq -rM '.scripts' Sorry, but this always pushes one of my buttons. When using "cat file | proc" what's wrong with "proc < file"? -- Dave ___ 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"
State changes via pkg's scripts
Is there a more convenient method to examine a package's scripts than unpacking the manifest file and # cat +MANIFEST | jq -rM '.scripts' ? As I'd like to know what changes will, or have been applied. For example to review the dependencies of a file # pkg info -d -F /packages/K8/All/samba410-4.10.15.txz provides an indication of what is going to be installed. I'd searched the man pages of pkg-info and pkg-query. Cheers, Dewayne. ___ 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"
