Re: List of packages upgraded last time `pkg upgrade` was executed
On Wed, 27 Jan 2021, Yasuhiro Kimura wrote:
From: Freddie Cash
Subject: Re: List of packages upgraded last time `pkg upgrade` was executed
Date: Tue, 26 Jan 2021 17:26:29 -0800
/var/log/messages and I think /var/log/daemon include the output of the pkg
commands. If you have the log files backed up from the last time it was
run, you could grep for pkg in those.
No idea if this info is also stored in the sqlite databases pkg uses.
Thank you for reply. But my intention is to write shell script that
gets the list of upgraded packages and does something by using
it. Because of that the list need to be gotton without any user
interaction. So unfortunately your method is not applicable to my
case.
Try something like this as a starting point for a shell script:
sqlite3 /var/db/pkg/local.sqlite \
"select datetime(time,'unixepoch'),origin,version from packages \
where datetime(time,'unixepoch')>=date('now','-7 day') \
order by time desc"
___
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: List of packages upgraded last time `pkg upgrade` was executed
On Thu, 28 Jan 2021 03:23:57 +0900 (JST) Yasuhiro Kimura wrote: > From: Michael Gmelin > Subject: Re: List of packages upgraded last time `pkg upgrade` was > executed Date: Wed, 27 Jan 2021 10:05:57 +0100 > > > This will give you a list of all packages that were > > updated/installed last: > > > > pkg query -e %t=$(pkg query %t | sort -n | tail -n1) %n-%v > > I tried this but unfortunately it doesn't seem to work as is expected. > > On the host I tried it, following packages are upgraded when I did > `pkg upgrade` last time. > > p5-URI-5.06 > p5-Module-CoreList-5.20210120 > rubygem-bundler-2.2.7_1,1 > sudo-1.9.5p2 1611721387 > > And I got following result. > > yasu@eastasia[1213]% pkg query -e %t=$(pkg query %t | sort -n | tail > -n1) %n-%v p5-Module-CoreList-5.20210120 > p5-URI-5.06 > yasu@eastasia[1213]% > > So I checked timestamp of install packages. > > yasu@eastasia[1216]% pkg query -a '%n-%v %t' | sort -k 2 -n -r | > head -10 ~ p5-URI-5.06 > 1611721389 p5-Module-CoreList-5.20210120 1611721389 > rubygem-bundler-2.2.7_1,1 1611721388 > sudo-1.9.5p2 1611721387 > p5-Config-General-2.63 1611685127 > libunwind-20201110 1611685127 > bind916-9.16.11 1611685127 > zstd-1.4.8 1611685126 > sqlite3-3.34.1,1 1611685126 > bind-tools-9.16.11 1611685125 > yasu@eastasia[1217]% > > As you can see timestamps of rubygem-bundler-2.2.7_1,1 and > sudo-1.9.5p2 are smaller than that of p5-URI-5.06 and > p5-Module-CoreList-5.20210120. So they aren't included in the list. > > > As far as I can tell, packages installed by the same pkg invocation > > run share the same installation timestamp (I didn't check the pkg > > sources, but that's what appears to be the case), > > According to the above result, it doesn't seem to be true. And I think > it's quite possible. When packages are upgraded they are upgraded not > in parallel but sequentially. So let me assume following situation. > > * Pakcage A and B are to be upgraded. > * A is upgraded first and B is next. > * Both are quite large package. > * Host is low-spec. > > In this case upgrade of each package may take a few minutes. And it > result in that there is difference of a few minites between the > timestamps of them after upgrade. I could reproduce your results easily by running `pkg install llvm10 rust gcc10`, so my bad, sorry. I could have sworn that this behaved differently in the past though. > > > If you use a script to do upgrades, you could store the timestamp as > > part of that and do something like this: > > > > touch /tmp/lastupgrade > > pkg upgrade > > # then, later: > > pkg query -e "%t>=$(stat -f %m /tmp/lastupgrade)" %n-%v > > This didn't hit upon me and I think it's really excellent way to use > file for timestamp. I'll use it in my shell script. Thank you for > letting me know. That's good to hear :) Cheers, Michael > > --- > Yasuhiro Kimura > ___ > 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" -- Michael Gmelin ___ 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: List of packages upgraded last time `pkg upgrade` was executed
From: Michael Gmelin Subject: Re: List of packages upgraded last time `pkg upgrade` was executed Date: Wed, 27 Jan 2021 10:05:57 +0100 > This will give you a list of all packages that were updated/installed > last: > > pkg query -e %t=$(pkg query %t | sort -n | tail -n1) %n-%v I tried this but unfortunately it doesn't seem to work as is expected. On the host I tried it, following packages are upgraded when I did `pkg upgrade` last time. p5-URI-5.06 p5-Module-CoreList-5.20210120 rubygem-bundler-2.2.7_1,1 sudo-1.9.5p2 1611721387 And I got following result. yasu@eastasia[1213]% pkg query -e %t=$(pkg query %t | sort -n | tail -n1) %n-%v p5-Module-CoreList-5.20210120 p5-URI-5.06 yasu@eastasia[1213]% So I checked timestamp of install packages. yasu@eastasia[1216]% pkg query -a '%n-%v %t' | sort -k 2 -n -r | head -10 ~ p5-URI-5.06 1611721389 p5-Module-CoreList-5.20210120 1611721389 rubygem-bundler-2.2.7_1,1 1611721388 sudo-1.9.5p2 1611721387 p5-Config-General-2.63 1611685127 libunwind-20201110 1611685127 bind916-9.16.11 1611685127 zstd-1.4.8 1611685126 sqlite3-3.34.1,1 1611685126 bind-tools-9.16.11 1611685125 yasu@eastasia[1217]% As you can see timestamps of rubygem-bundler-2.2.7_1,1 and sudo-1.9.5p2 are smaller than that of p5-URI-5.06 and p5-Module-CoreList-5.20210120. So they aren't included in the list. > As far as I can tell, packages installed by the same pkg invocation run > share the same installation timestamp (I didn't check the pkg sources, > but that's what appears to be the case), According to the above result, it doesn't seem to be true. And I think it's quite possible. When packages are upgraded they are upgraded not in parallel but sequentially. So let me assume following situation. * Pakcage A and B are to be upgraded. * A is upgraded first and B is next. * Both are quite large package. * Host is low-spec. In this case upgrade of each package may take a few minutes. And it result in that there is difference of a few minites between the timestamps of them after upgrade. > If you use a script to do upgrades, you could store the timestamp as > part of that and do something like this: > > touch /tmp/lastupgrade > pkg upgrade > # then, later: > pkg query -e "%t>=$(stat -f %m /tmp/lastupgrade)" %n-%v This didn't hit upon me and I think it's really excellent way to use file for timestamp. I'll use it in my shell script. Thank you for letting me know. --- Yasuhiro Kimura ___ 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 merging multiple ports trees
Greetings, i just added the overlay to my portstree, works good and great addition. I wonder how you handle moved ports with this? As example we are using a adapted Version of sysutils/sge62 with own patches but i need to remove this Line in MOVED on the Original portstree to allow building it. Is there a way to handle such exceptions or do i need to rename it? Is there any Documentation about this? Kind regards, Henrik Rosenke Am 25.01.21 um 16:28 schrieb Baptiste Daroussin: On Mon, Jan 25, 2021 at 04:25:09PM +0100, Miroslav Lachman wrote: On 25/01/2021 15:10, Baptiste Daroussin wrote: On Sun, Jan 24, 2021 at 10:23:45PM +0100, Guido Falsi via freebsd-ports wrote: On 24/01/21 20:35, Russell L. Carter wrote: Greetings, I am completely ignorant here and am looking for up to date advice on how to get poudriere to build and make available package sets from multiple ports trees. I see there is a port "portshaker" that seems to do much of what I want. [...] BTW I noticed poudriere performs shallow clones for git repos, so it should not use up a lot of disk space. Why not using directly overlays, it will simplify everything ;) I don't know if you read me reply or not - I am using poudriere with ports overlay but have a problem with it. Poudriere options does not take overlay in to account so ports options cannot be configured for overlayed ports which do not exist in the base three. Is there a way to fix it / should I file a PR for it? Kind regards Miroslav Lachman Yes I read it and for sure poudriere option not supporting overlays is a limitation, and yes a PR would help to not forget about implementing it. That said most people aren't using poudriere option and prefer to define option directly via make.conf for them overlay is fully suited, and avoid the risk or dangerous merging of trees may it be via portshaker, or git mechanism. there are room of improvements for overlays but it should work in most cases Best regards, Bapt ___ 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"
My dumper failure
# uname -rs FreeBSD 12.2-RELEASE-p1 Portmaster build of my dumper fails: [6/10] /usr/bin/cc -I/usr/local/include/mysql -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -Wall -Wno-deprecated-declarations -Wunused -Wwrite-strings -Wno-strict-aliasing -Wextra -Wshadow -O3 -g -I/usr/local/include/mysql -I/usr/local/include/mysql/mysql -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MD -MT CMakeFiles/mydumper.dir/mydumper.c.o -MF CMakeFiles/mydumper.dir/mydumper.c.o.d -o CMakeFiles/mydumper.dir/mydumper.c.o -c mydumper.c ninja: build stopped: subcommand failed. ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/databases/mydumper Ports tree updated a few hours ago. This is the only port that shows an update: # portmaster -L | grep -B1 " New ===>>> mydumper-0.9.5 ===>>> New version available: mydumper-0.10.1 This is not critical, but it is one of the ways I backup MySQL databases. -- Vi Veri Veniversum Vivus Vici ___ 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: need a mentor/reviewer for a nfs-over-tls port
Quoting Rick Macklem (from Wed, 27 Jan 2021 01:59:21 +): Hi, I am a src committer and have created a port for the userland daemons needed to implement nfs-over-tls. It is my understanding that I can commit the port once it is reviewed and approved by someone with a ports commit bit. --> So I am looking for a volunteer. It seems you are modifying the category-Makefile by hand. There is the script /usr/ports/Tools/scripts/addport which takes care about this (and other things). This script will not modify your current tree, but checkout a temporary copy of the ports Mk directory and the category Makefile, make the modification there, and then commit it for you. You can run "addport -n -a -d nfs-over-tls" in the parent directory of the nfs-over-tls directory and it will do a test run with some checks without committing anything (because of the -n option). What it prints out is: WARN: Makefile: [14]: use a tab (not space) after a variable name WARN: Consider to set DEVELOPER=yes in /etc/make.conf 0 fatal errors and 2 warnings found. I also tried (as root, so that I do not have to change the WRKDIRPREFIX and such, and with the option "-m" it does not have svn access to the repo) "addport -n -at -m -d nfs-over-tls" but it fails fetching the openssl-3.0.0-alpha8.tar.gz, so a test-build (with DEVELOPER=YES in make.conf) fails (my ports tree may need an update...). This is supposed to detect pkg-plist issues. As we do not have KTLS in every release, I suggest to add a guard to only build it on supported releases. See https://docs.freebsd.org/en/books/porters-handbook/#porting-versions and use IGNORE=... in such cases. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgp2S602xD8IM.pgp Description: Digitale PGP-Signatur
Re: List of packages upgraded last time `pkg upgrade` was executed
On Wed, 27 Jan 2021 10:35:38 +0200 Peter Pentchev wrote: > On Wed, Jan 27, 2021 at 10:57:22AM +0900, Yasuhiro Kimura wrote: > > From: Freddie Cash > > Subject: Re: List of packages upgraded last time `pkg upgrade` was > > executed Date: Tue, 26 Jan 2021 17:26:29 -0800 > > > > > /var/log/messages and I think /var/log/daemon include the output > > > of the pkg commands. If you have the log files backed up from the > > > last time it was run, you could grep for pkg in those. > > > > > > No idea if this info is also stored in the sqlite databases pkg > > > uses. > > > > Thank you for reply. But my intention is to write shell script that > > gets the list of upgraded packages and does something by using > > it. Because of that the list need to be gotton without any user > > interaction. So unfortunately your method is not applicable to my > > case. > > Well, there is the option of running a pkg query before and after > the upgrade and comparing the results... especially if you write it in > a higher-level language than the shell, it Should Not Be Too Hard(tm) > to figure out which packages have changed their version, what new > ones have appeared, which ones have been removed... > > But, yeah, it is certainly easy for me to suggest that somebody else > write something "simple" :) > This will give you a list of all packages that were updated/installed last: pkg query -e %t=$(pkg query %t | sort -n | tail -n1) %n-%v Explained: $(pkg query %t | sort -n | tail -n1) - Get timestamps of when packages were installed - Sort numerically - Take the last one (which is the latest) Feed this into `pkg query %t=x %n-%v` which returns all packages matching that latest timestamp (== when last set of packages were installed) and outputs their name and version. As far as I can tell, packages installed by the same pkg invocation run share the same installation timestamp (I didn't check the pkg sources, but that's what appears to be the case), that's why this works. This resulting list won't include the pkg package itself in case it was updated as part as the run. There might also be other multi-pass scenarios of pkg I'm not aware of though. In case you know when pkg upgrade was called last, you can simply feed it the timestamp directly, like in: pkg query -e "%t>=1609545326" %n-%v If you use a script to do upgrades, you could store the timestamp as part of that and do something like this: touch /tmp/lastupgrade pkg upgrade # then, later: pkg query -e "%t>=$(stat -f %m /tmp/lastupgrade)" %n-%v Cheers, Michael -- Michael Gmelin ___ 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 you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ science/afni| 21.0.04 | afni_21.0.06 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Reported by:portscout! ___ 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: List of packages upgraded last time `pkg upgrade` was executed
On Wed, Jan 27, 2021 at 10:57:22AM +0900, Yasuhiro Kimura wrote: > From: Freddie Cash > Subject: Re: List of packages upgraded last time `pkg upgrade` was executed > Date: Tue, 26 Jan 2021 17:26:29 -0800 > > > /var/log/messages and I think /var/log/daemon include the output of the pkg > > commands. If you have the log files backed up from the last time it was > > run, you could grep for pkg in those. > > > > No idea if this info is also stored in the sqlite databases pkg uses. > > Thank you for reply. But my intention is to write shell script that > gets the list of upgraded packages and does something by using > it. Because of that the list need to be gotton without any user > interaction. So unfortunately your method is not applicable to my > case. Well, there is the option of running a pkg query before and after the upgrade and comparing the results... especially if you write it in a higher-level language than the shell, it Should Not Be Too Hard(tm) to figure out which packages have changed their version, what new ones have appeared, which ones have been removed... But, yeah, it is certainly easy for me to suggest that somebody else write something "simple" :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
