tricky bsd.port.mk diff: differentiate BUILD_PACKAGES
As landry noticed, pkglocatedb will spew out a few errors due to
SHARED_LIBS only containing libraries that exist.
I think it makes sense to restrict a few introspection targets to
actual stuff getting built, since the other subpackages may contain
interesting errors.
Any unwanted consequences ?
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1171
diff -u -p -r1.1171 bsd.port.mk
--- bsd.port.mk 28 May 2012 09:54:18 - 1.1171
+++ bsd.port.mk 28 May 2012 11:01:00 -
@@ -1667,11 +1667,11 @@ check-register:
.endif
check-register-all:
-.for _S in ${MULTI_PACKAGES}
+.for _S in ${BUILD_PACKAGES}
@cd ${.CURDIR} SUBPACKAGE=${_S} PKGPATH=${PKGPATH} ${MAKE}
check-register
.endfor
-.for _S in ${MULTI_PACKAGES}
+.for _S in ${BUILD_PACKAGES}
${_CACHE_REPO}/${_PKGFILE${_S}}:
@mkdir -p ${@D}
@@ -2035,7 +2035,7 @@ ${WRKINST}/.saved_libs: ${_FAKE_COOKIE}
@${SUDO} ${_CHECK_LIB_DEPENDS} -O $@t ${SUDO} mv $@t $@
port-lib-depends-check: ${WRKINST}/.saved_libs
- @-${_cache_fragment}; for s in ${MULTI_PACKAGES}; do \
+ @-${_cache_fragment}; for s in ${BUILD_PACKAGES}; do \
SUBPACKAGE=$$s ${MAKE} print-plist-with-depends \
lib_depends_args=all-lib-depends-args \
wantlib_args=fake-wantlib-args| \
@@ -2163,7 +2163,7 @@ _do_libs_too = NO_SHARED_LIBS=Yes
. endif
_extra_info =
-. for _s in ${MULTI_PACKAGES}
+. for _s in ${BUILD_PACKAGES}
_extra_info += PLIST${_s}='${PLIST${_s}}'
_extra_info += DEPPATHS${_s}=`${SETENV} FLAVOR=${FLAVOR:Q} SUBPACKAGE=${_s}
PKGPATH=${PKGPATH} ${MAKE} show-run-depends ${_do_libs_too}`
. endfor
@@ -2176,7 +2176,7 @@ _internal-plist _internal-update-plist:
INSTALL_PRE_COOKIE=${_INSTALL_PRE_COOKIE} \
MAKE=${MAKE} \
PORTSDIR=${PORTSDIR} \
- FLAVORS='${FLAVORS}' MULTI_PACKAGES='${MULTI_PACKAGES}' \
+ FLAVORS='${FLAVORS}' MULTI_PACKAGES='${BUILD_PACKAGES}' \
OKAY_FILES='${_FAKE_COOKIE} ${_INSTALL_PRE_COOKIE}
${WRKINST}/.saved_libs' \
SHARED_ONLY=${SHARED_ONLY} \
OWNER=`id -u` \
@@ -2606,13 +2606,13 @@ print-plist-libs-with-depends:
fi
print-plist-all:
-.for _S in ${MULTI_PACKAGES}
+.for _S in ${BUILD_PACKAGES}
@${ECHO_MSG} === ${FULLPKGNAME${_S}}
@${_PKG_CREATE} -n -q ${PKG_ARGS${_S}} ${_PACKAGE_COOKIE${_S}}
.endfor
print-plist-all-with-depends:
-.for _S in ${MULTI_PACKAGES}
+.for _S in ${BUILD_PACKAGES}
@${ECHO_MSG} === ${FULLPKGNAME${_S}}
@if a=`SUBPACKAGE=${_S} PKGPATH=${PKGPATH} ${MAKE} print-package-args`;
\
then \
オプトイン確認メール
色々な最新情報メールを配信しております。 今後、最新情報をお送りさせて頂くにあたり最終確認を行っております。 お手数をお掛け致しますが、今後最新情報メールを 希望されない方はこちらまで「希望しない」とご連絡ください。
mg - remove *init* buffer
After a recent commit (http://marc.info/?l=openbsd-techm=133787310204563w=2)
I realised the *init* buffer could be removed since we went back and updated
modes after scratch was created.
There is a side effect to this diff; theo mode now works from the command
line:
$ mg -f theo
[it had been broken for a while]
Comments/ok
-lum
Index: main.c
===
RCS file: /cvs/src/usr.bin/mg/main.c,v
retrieving revision 1.65
diff -u -p -r1.65 main.c
--- main.c 25 May 2012 05:05:48 - 1.65
+++ main.c 28 May 2012 14:09:51 -
@@ -23,7 +23,7 @@ struct mgwin *curwp; /* current windo
struct mgwin *wheadp;/* MGWIN listhead */
charpat[NPAT]; /* pattern */
-static void edinit(PF);
+static void edinit(struct buffer *);
static __dead void usage(void);
extern char*__progname;
@@ -40,11 +40,11 @@ usage()
int
main(int argc, char **argv)
{
- char*cp, *init_fcn_name = NULL;
- PF init_fcn = NULL;
- int o, i, nfiles;
- int nobackups = 0;
- struct buffer *bp;
+ char*cp, *init_fcn_name = NULL;
+ PF init_fcn = NULL;
+ int o, i, nfiles;
+ int nobackups = 0;
+ struct buffer *bp = NULL;
while ((o = getopt(argc, argv, nf:)) != -1)
switch (o) {
@@ -88,7 +88,7 @@ main(int argc, char **argv)
vtinit(); /* Virtual terminal.*/
dirinit(); /* Get current directory. */
- edinit(init_fcn); /* Buffers, windows.*/
+ edinit(bp); /* Buffers, windows.*/
ttykeymapinit();/* Symbols, bindings. */
/*
@@ -98,13 +98,6 @@ main(int argc, char **argv)
*/
update();
- /*
-* Create scratch buffer now, killing old *init* buffer.
-* This causes *scratch* to be created and made curbp.
-*/
- if ((bp = bfind(*init*, FALSE)) != NULL)
- killbuffer(bp);
-
/* user startup file. */
if ((cp = startupfile(NULL)) != NULL)
(void)load(cp);
@@ -194,26 +187,23 @@ notnum:
}
/*
- * Initialize default buffer and window.
- * Initially, buffer is named *init*. This is changed later
- * to *scratch* after the startup files are read.
+ * Initialize default buffer and window. Default buffer is called *scratch*.
*/
static void
-edinit(PF init_fcn)
+edinit(struct buffer *bp)
{
- struct buffer *bp;
struct mgwin*wp;
bheadp = NULL;
- bp = bfind(*init*, TRUE); /* Text buffer. */
+ bp = bfind(*scratch*, TRUE); /* Text buffer. */
if (bp == NULL)
panic(edinit);
wp = new_window(bp);
if (wp == NULL)
- panic(Out of memory);
+ panic(edinit: Out of memory);
- curbp = bp; /* Current ones. */
+ curbp = bp; /* Current buffer. */
wheadp = wp;
curwp = wp;
wp-w_wndp = NULL; /* Initialize window.*/
Re: pkg_add/pkg_delete: include PID in syslog messages
On Mon, Mar 19, 2012 at 12:50:12PM +0100, Marc Espie wrote:
On Wed, Mar 07, 2012 at 12:31:48AM -0500, Lawrence Teo wrote:
This simple diff makes pkg_add and pkg_delete include their PID when
logging to syslog. This is useful when trying to determine whether
several packages were added (or removed) by the same pkg_add (or
pkg_delete) process.
Here is some sample output:
Mar 3 22:15:17 obsd-amd64 pkg_add[3530]: Added nano-2.2.6
Mar 3 22:15:26 obsd-amd64 pkg_delete[21136]: Removed nano-2.2.6
Mar 3 22:16:51 obsd-amd64 pkg_add[30666]: Added redland-1.0.8p1
Mar 3 22:16:54 obsd-amd64 pkg_add[30666]: Added mozilla-dicts-en-GB-1.3
Mar 3 22:16:56 obsd-amd64 pkg_add[30666]: Added hunspell-1.2.12
Mar 3 22:23:22 obsd-amd64 pkg_add[30666]: Added libreoffice-3.4.5.2v0
Mar 3 23:33:23 obsd-amd64 pkg_add[5948]: Added kdiff3-0.9.96p1
Comments?
The more I think about it, the more I fail to see the value.
Consider that any pkg_add/pkg_delete that actually changes installed
packages *will* lock the database anyways, so by nature, all relevant
runs of pkg_add/pkg_delete will happen in sequence.
Hence, there's totally no ambiguity in the log lines. If I remove the pids
in there, I still have no trouble figuring out what happened.
When I look at those logs, I usually have to look at the time anyways,
so in the above case, figuring out that libreoffice and kdiff3 are
different runs of pkg_add is not that hard...
Thank you for your comments.
If I remove the PIDs from the above logs, part of it would look like
this:
Mar 3 22:16:51 obsd-amd64 pkg_add: Added redland-1.0.8p1
Mar 3 22:16:54 obsd-amd64 pkg_add: Added mozilla-dicts-en-GB-1.3
Mar 3 22:16:56 obsd-amd64 pkg_add: Added hunspell-1.2.12
Mar 3 22:23:22 obsd-amd64 pkg_add: Added libreoffice-3.4.5.2v0
Just relying on those timestamps alone without PIDs, it looks like
redland, mozilla-dicts, and hunspell are part of the same run, while
libreoffice is a different run.
However, with PIDs it is clear that they are part of the same run, where
it so happened that it took almost 6.5 minutes to install the
libreoffice package on this machine:
Mar 3 22:16:51 obsd-amd64 pkg_add[30666]: Added redland-1.0.8p1
Mar 3 22:16:54 obsd-amd64 pkg_add[30666]: Added mozilla-dicts-en-GB-1.3
Mar 3 22:16:56 obsd-amd64 pkg_add[30666]: Added hunspell-1.2.12
Mar 3 22:23:22 obsd-amd64 pkg_add[30666]: Added libreoffice-3.4.5.2v0
I won't say I can't be swayed, but you'll have to give me a concrete case
where the pid offers some actual advantage over no pid.
My goal is to help the bleary-eyed sysadmin figure out what in the world
s/he did after working on a project all night long. :) I think the
PIDs would help them answer questions like, Why did I install $PACKAGE
again? (where $PACKAGE could be hunspell in the above example).
Please let me know if you have any further thoughts and if you're ok
with the diff. Since a long time has passed since your post on this
thread and I only managed to reply now, I have included my diff again
below.
Thank you,
Lawrence
Index: AddDelete.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/AddDelete.pm,v
retrieving revision 1.53
diff -u -p -r1.53 AddDelete.pm
--- AddDelete.pm9 Oct 2011 16:43:50 - 1.53
+++ AddDelete.pm4 Mar 2012 04:37:04 -
@@ -185,7 +185,7 @@ sub handle_options
$state-{loglevel} //= $state-config-value(loglevel) // 1;
if ($state-{loglevel}) {
require Sys::Syslog;
- Sys::Syslog::openlog($state-{cmd}, nofatal);
+ Sys::Syslog::openlog($state-{cmd}, nofatal,pid);
}
}
Re: pkg_add/pkg_delete: include PID in syslog messages
On 2012/05/28 10:53, Lawrence Teo wrote: On Mon, Mar 19, 2012 at 12:50:12PM +0100, Marc Espie wrote: The more I think about it, the more I fail to see the value. Consider that any pkg_add/pkg_delete that actually changes installed packages *will* lock the database anyways, so by nature, all relevant runs of pkg_add/pkg_delete will happen in sequence. Hence, there's totally no ambiguity in the log lines. If I remove the pids in there, I still have no trouble figuring out what happened. When I look at those logs, I usually have to look at the time anyways, so in the above case, figuring out that libreoffice and kdiff3 are different runs of pkg_add is not that hard... Thank you for your comments. If I remove the PIDs from the above logs, part of it would look like this: Mar 3 22:16:51 obsd-amd64 pkg_add: Added redland-1.0.8p1 Mar 3 22:16:54 obsd-amd64 pkg_add: Added mozilla-dicts-en-GB-1.3 Mar 3 22:16:56 obsd-amd64 pkg_add: Added hunspell-1.2.12 Mar 3 22:23:22 obsd-amd64 pkg_add: Added libreoffice-3.4.5.2v0 Just relying on those timestamps alone without PIDs, it looks like redland, mozilla-dicts, and hunspell are part of the same run, while libreoffice is a different run. However, with PIDs it is clear that they are part of the same run, where it so happened that it took almost 6.5 minutes to install the libreoffice package on this machine: Mar 3 22:16:51 obsd-amd64 pkg_add[30666]: Added redland-1.0.8p1 Mar 3 22:16:54 obsd-amd64 pkg_add[30666]: Added mozilla-dicts-en-GB-1.3 Mar 3 22:16:56 obsd-amd64 pkg_add[30666]: Added hunspell-1.2.12 Mar 3 22:23:22 obsd-amd64 pkg_add[30666]: Added libreoffice-3.4.5.2v0 If this is necessary at all, I'd honestly prefer log entries like started update and finished update rather than logging PIDs. It's unlikely of course, but PIDs are random, so you can't rely on the PID alone to identify whether two log entries with a certain PID are from the same run. My goal is to help the bleary-eyed sysadmin figure out what in the world s/he did after working on a project all night long. :) This is certainly not restricted to pkg_add. I find sudo logs quite useful for this.
Re: pkg_add/pkg_delete: include PID in syslog messages
On Mon, May 28, 2012 at 10:53:15AM -0400, Lawrence Teo wrote: My goal is to help the bleary-eyed sysadmin figure out what in the world s/he did after working on a project all night long. :) I think the PIDs would help them answer questions like, Why did I install $PACKAGE again? (where $PACKAGE could be hunspell in the above example). Administrator forgot to turn on his brain. In the above case, hunspell is a depency of libreoffice, so it was not installed per se: it won't show up in pkg_info -m and pkg_info -R will tell him what requires it. (or hey, pkg_delete -nav will also tell him which packages won't be removed because they're needed by something).
