tricky bsd.port.mk diff: differentiate BUILD_PACKAGES

2012-05-28 Thread Marc Espie
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 \



オプトイン確認メール

2012-05-28 Thread オプトインメール確認
色々な最新情報メールを配信しております。
今後、最新情報をお送りさせて頂くにあたり最終確認を行っております。
お手数をお掛け致しますが、今後最新情報メールを
希望されない方はこちらまで「希望しない」とご連絡ください。



mg - remove *init* buffer

2012-05-28 Thread Mark Lumsden
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

2012-05-28 Thread Lawrence Teo
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

2012-05-28 Thread Stuart Henderson
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

2012-05-28 Thread Marc Espie
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).