CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sema...@cvs.openbsd.org 2016/03/10 22:30:45 Modified files: lang/rust : Makefile lang/rust/patches: patch-configure Added files: lang/rust/patches: patch-src_compiletest_runtest_rs Log message: lang/rust: use devel/llvm for building switch from embedded version of LLVM to system version. OK juanfra@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2016/03/10 19:27:01 Modified files: textproc/calibre/patches: patch-setup_extensions_py Log message: regen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2016/03/10 19:27:26 Added files: textproc/calibre/patches: patch-src_duktape_duktape_duk_config_h Log message: attempt at fixing calibre build on sparc64
Re: [patch] productivity/slideml
David Hill wrote: > Hello - > > This moves productivity/slideml to github. It's strange that the old HOMEPAGE is still up and doesn't mention GitHub at all. Do you know if upstream has a preference about which is used? > Index: Makefile > === > RCS file: /cvs/ports/productivity/slideml/Makefile,v > retrieving revision 1.7 > diff -u -p -r1.7 Makefile > --- Makefile 25 Mar 2014 21:20:39 - 1.7 > +++ Makefile 11 Mar 2016 00:02:09 - > @@ -2,20 +2,20 @@ > > COMMENT =HTML slide generator based on SlideML > > -DISTNAME = slideml-1.1.0 > -REVISION = 0 > - > +V = 1.1.0 > +REVISION = 1 > +GH_TAGNAME = SLIDEML_${V:S/./_/g} > +GH_ACCOUNT = conformal > +GH_PROJECT = slideml > +DISTNAME = ${GH_PROJECT}-${V} > CATEGORIES = productivity > > -HOMEPAGE = http://opensource.conformal.com/wiki/Slide_ML > +HOMEPAGE = https://github.com/conformal/slideml/wiki > > MAINTAINER = Laurent Fanis> > #W3C Software Notice and License & BSD > PERMIT_PACKAGE_CDROM = Yes > - > -MASTER_SITES = > http://opensource.conformal.com/snapshots/slideml/ > -EXTRACT_SUFX = .tgz > > RUN_DEPENDS =graphics/p5-Image-Size > > Index: distinfo > === > RCS file: /cvs/ports/productivity/slideml/distinfo,v > retrieving revision 1.3 > diff -u -p -r1.3 distinfo > --- distinfo 18 Jan 2015 03:14:59 - 1.3 > +++ distinfo 11 Mar 2016 00:02:09 - > @@ -1,2 +1,2 @@ > -SHA256 (slideml-1.1.0.tgz) = RPCos9m9/bXNPhX+29p+k5yJiEBrtkm7HxGbiNN33ck= > -SIZE (slideml-1.1.0.tgz) = 28245 > +SHA256 (slideml-1.1.0.tar.gz) = mT9/V83DDpcp1dlayIwORs7gdi32Mp1MEQpfkW7zgwc= > +SIZE (slideml-1.1.0.tar.gz) = 28172 >
Re: [patch] sysutils/diskrescue
David Hill wrote: > Hello - > > This updates sysutils/diskrescue to 0.4 and moves it to github. > The change between 0.3 and 0.4 is the patch has been applied. :). Makes sense, and builds for me. ok mmcc@ > Index: Makefile > === > RCS file: /cvs/ports/sysutils/diskrescue/Makefile,v > retrieving revision 1.9 > diff -u -p -r1.9 Makefile > --- Makefile 16 Feb 2015 22:57:12 - 1.9 > +++ Makefile 11 Mar 2016 00:32:46 - > @@ -2,12 +2,14 @@ > > COMMENT =fancy dd > > -DISTNAME = diskrescue-0.3 > -REVISION = 1 > - > +V = 0.4 > +GH_TAGNAME = DISKRESCUE_${V:S/./_/g} > +GH_ACCOUNT = conformal > +GH_PROJECT = diskrescue > +DISTNAME = ${GH_PROJECT}-${V} > CATEGORIES = sysutils > > -HOMEPAGE = http://opensource.conformal.com/wiki/Disk_Rescue > +HOMEPAGE = https://github.com/conformal/diskrescue/wiki > > MAINTAINER = Laurent Fanis> > @@ -15,10 +17,6 @@ MAINTAINER = Laurent Fanis PERMIT_PACKAGE_CDROM = Yes > > WANTLIB =c > - > -MASTER_SITES = > http://opensource.conformal.com/snapshots/diskrescue/ > - > -EXTRACT_SUFX = .tgz > > NO_TEST= Yes > > Index: distinfo > === > RCS file: /cvs/ports/sysutils/diskrescue/distinfo,v > retrieving revision 1.3 > diff -u -p -r1.3 distinfo > --- distinfo 18 Jan 2015 03:15:09 - 1.3 > +++ distinfo 11 Mar 2016 00:32:46 - > @@ -1,2 +1,2 @@ > -SHA256 (diskrescue-0.3.tgz) = GHO70eRi8to/eGHl7Gbg7SvoAoIeZrucUjXd/5snfqo= > -SIZE (diskrescue-0.3.tgz) = 6825 > +SHA256 (diskrescue-0.4.tar.gz) = loVdK0MDTegiHg8eTVzDaTpjod5airDGxS/GQek/gS0= > +SIZE (diskrescue-0.4.tar.gz) = 6816 > Index: patches/patch-diskrescue_c > === > RCS file: patches/patch-diskrescue_c > diff -N patches/patch-diskrescue_c > --- patches/patch-diskrescue_c15 Jun 2013 08:19:33 - 1.1 > +++ /dev/null 1 Jan 1970 00:00:00 - > @@ -1,121 +0,0 @@ > -$OpenBSD: patch-diskrescue_c,v 1.1 2013/06/15 08:19:33 sthen Exp $ > diskrescue.c.origMon Sep 28 16:13:33 2009 > -+++ diskrescue.c Sat Jun 15 09:19:05 2013 > -@@ -44,15 +44,15 @@ static const char*cvstag = "$diskrescue: > diskrescue.c > - */ > - > - struct dr_hdr { > --daddr64_t disk_sz; > --daddr64_t block_sz; > --charoutput[PATH_MAX]; > -+daddr_t disk_sz; > -+daddr_t block_sz; > -+charoutput[PATH_MAX]; > - }; > - > - struct dr_entry { > --daddr64_t offset; > --daddr64_t size; > --chardigest[SHA1_DIGEST_LENGTH * 2 + 1]; > -+daddr_t offset; > -+daddr_t size; > -+chardigest[SHA1_DIGEST_LENGTH * 2 + 1]; > - }; > - > - /* > -@@ -80,7 +80,7 @@ FILE *resfd = stderr; > - int quiet = 0; > - int abort_on_error = 0; > - volatile sig_atomic_t running = 1; > --daddr64_t bs = DEV_BSIZE; > -+daddr_t bs = DEV_BSIZE; > - char*rawdev = NULL; > - char*outfile = NULL; > - char*infile = NULL; > -@@ -143,7 +143,7 @@ hdr_read(FILE *f, struct dr_hdr *h) > - } > - > - int > --ent_write(FILE *f, daddr64_t offset, daddr64_t sz, char *inbuf) > -+ent_write(FILE *f, daddr_t offset, daddr_t sz, char *inbuf) > - { > - u_int8_tdigest[SHA1_DIGEST_LENGTH]; > - chardigest_text[SHA1_DIGEST_LENGTH * 2 + 1]; > -@@ -208,7 +208,7 @@ ent_read(FILE *f, FILE *outf, struct dr_entry *e) > - } > - > - int > --rawsize(int fd, daddr64_t *size) > -+rawsize(int fd, daddr_t *size) > - { > - #if defined(__OpenBSD__) > - struct disklabeldl; > -@@ -223,11 +223,11 @@ rawsize(int fd, daddr64_t *size) > - #endif > - } > - > --daddr64_t > -+daddr_t > - getbs(char *val) > - { > --daddr64_t num, t; > --char*expr; > -+daddr_t num, t; > -+char*expr; > - > - num = strtoul(val, , 0); > - if (num == SIZE_T_MAX) /* Overflow. */ > -@@ -283,7 +283,7 @@ erange: errx(1, "illegal block size: > %s", strerror(E > - } > - > - int > --readoffset(daddr64_t offs, int fd, char *buf, daddr64_t bs) > -+readoffset(daddr_t offs, int fd, char *buf, daddr_t bs) > - { > - int rv; > - > -@@ -295,10 +295,10 @@ readoffset(daddr64_t offs, int fd, char *buf, daddr64_ > - } > - > - int > --recover(daddr64_t offs, int fd, char *buf, daddr64_t bs) > -+recover(daddr_t offs, int fd, char *buf, daddr_t bs) > - { > --int rv =
[patch] sysutils/diskrescue
Hello - This updates sysutils/diskrescue to 0.4 and moves it to github. The change between 0.3 and 0.4 is the patch has been applied. :). Index: Makefile === RCS file: /cvs/ports/sysutils/diskrescue/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- Makefile16 Feb 2015 22:57:12 - 1.9 +++ Makefile11 Mar 2016 00:32:46 - @@ -2,12 +2,14 @@ COMMENT = fancy dd -DISTNAME = diskrescue-0.3 -REVISION = 1 - +V =0.4 +GH_TAGNAME = DISKRESCUE_${V:S/./_/g} +GH_ACCOUNT = conformal +GH_PROJECT = diskrescue +DISTNAME = ${GH_PROJECT}-${V} CATEGORIES = sysutils -HOMEPAGE = http://opensource.conformal.com/wiki/Disk_Rescue +HOMEPAGE = https://github.com/conformal/diskrescue/wiki MAINTAINER = Laurent Fanis@@ -15,10 +17,6 @@ MAINTAINER = Laurent Fanis http://opensource.conformal.com/snapshots/diskrescue/ - -EXTRACT_SUFX = .tgz NO_TEST= Yes Index: distinfo === RCS file: /cvs/ports/sysutils/diskrescue/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo18 Jan 2015 03:15:09 - 1.3 +++ distinfo11 Mar 2016 00:32:46 - @@ -1,2 +1,2 @@ -SHA256 (diskrescue-0.3.tgz) = GHO70eRi8to/eGHl7Gbg7SvoAoIeZrucUjXd/5snfqo= -SIZE (diskrescue-0.3.tgz) = 6825 +SHA256 (diskrescue-0.4.tar.gz) = loVdK0MDTegiHg8eTVzDaTpjod5airDGxS/GQek/gS0= +SIZE (diskrescue-0.4.tar.gz) = 6816 Index: patches/patch-diskrescue_c === RCS file: patches/patch-diskrescue_c diff -N patches/patch-diskrescue_c --- patches/patch-diskrescue_c 15 Jun 2013 08:19:33 - 1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,121 +0,0 @@ -$OpenBSD: patch-diskrescue_c,v 1.1 2013/06/15 08:19:33 sthen Exp $ diskrescue.c.orig Mon Sep 28 16:13:33 2009 -+++ diskrescue.c Sat Jun 15 09:19:05 2013 -@@ -44,15 +44,15 @@ static const char *cvstag = "$diskrescue: diskrescue.c - */ - - struct dr_hdr { -- daddr64_t disk_sz; -- daddr64_t block_sz; -- charoutput[PATH_MAX]; -+ daddr_t disk_sz; -+ daddr_t block_sz; -+ charoutput[PATH_MAX]; - }; - - struct dr_entry { -- daddr64_t offset; -- daddr64_t size; -- chardigest[SHA1_DIGEST_LENGTH * 2 + 1]; -+ daddr_t offset; -+ daddr_t size; -+ chardigest[SHA1_DIGEST_LENGTH * 2 + 1]; - }; - - /* -@@ -80,7 +80,7 @@ FILE *resfd = stderr; - int quiet = 0; - int abort_on_error = 0; - volatile sig_atomic_t running = 1; --daddr64_t bs = DEV_BSIZE; -+daddr_t bs = DEV_BSIZE; - char *rawdev = NULL; - char *outfile = NULL; - char *infile = NULL; -@@ -143,7 +143,7 @@ hdr_read(FILE *f, struct dr_hdr *h) - } - - int --ent_write(FILE *f, daddr64_t offset, daddr64_t sz, char *inbuf) -+ent_write(FILE *f, daddr_t offset, daddr_t sz, char *inbuf) - { - u_int8_tdigest[SHA1_DIGEST_LENGTH]; - chardigest_text[SHA1_DIGEST_LENGTH * 2 + 1]; -@@ -208,7 +208,7 @@ ent_read(FILE *f, FILE *outf, struct dr_entry *e) - } - - int --rawsize(int fd, daddr64_t *size) -+rawsize(int fd, daddr_t *size) - { - #if defined(__OpenBSD__) - struct disklabeldl; -@@ -223,11 +223,11 @@ rawsize(int fd, daddr64_t *size) - #endif - } - --daddr64_t -+daddr_t - getbs(char *val) - { -- daddr64_t num, t; -- char*expr; -+ daddr_t num, t; -+ char*expr; - - num = strtoul(val, , 0); - if (num == SIZE_T_MAX) /* Overflow. */ -@@ -283,7 +283,7 @@ erange:errx(1, "illegal block size: %s", strerror(E - } - - int --readoffset(daddr64_t offs, int fd, char *buf, daddr64_t bs) -+readoffset(daddr_t offs, int fd, char *buf, daddr_t bs) - { - int rv; - -@@ -295,10 +295,10 @@ readoffset(daddr64_t offs, int fd, char *buf, daddr64_ - } - - int --recover(daddr64_t offs, int fd, char *buf, daddr64_t bs) -+recover(daddr_t offs, int fd, char *buf, daddr_t bs) - { -- int rv = -1, sz; -- daddr64_t blocks, b; -+ int rv = -1, sz; -+ daddr_t blocks, b; - - blocks = bs / DEV_BSIZE; - if (bs % DEV_BSIZE) -@@ -334,7 +334,7 @@ usage(void) - } - - void --print_perc(daddr64_t size, daddr64_t offs, char *s, char *cr) -+print_perc(daddr_t size, daddr_t offs, char *s, char *cr) - { - double p; - -@@
[UPDATE] plan9/drawterm (switch to new source repository)
One more time. Supercedes most recent update. The original drawterm is effectively abandoned by its author. This update switches to a new fork that is currenlty being maintained against the 9front fork of Plan 9. Latest revision from 20160310. This update: - fixes a glitch in graphics rendering, primarily noticed when viewing images in the web browser mothra(1). - defaults to new dp9ik authentication and rcpu(1) connection method, devolving to the old p9sk1 and cpu(1). - adds new cryptographic support from 9front libmp and libsec libraries. - adds support for 9front - enables audio support. Also, updates my e-mail address from stanley.lie...@gmail.com to s...@stanleylieber.com, because I am transitioning away from Google services. Tested only on 386 and amd64. Would appreciate testing on other platforms. http://openbsd.stanleylieber.com/drawterm/drawterm-port-20160310.tgz ok? sl
[patch] productivity/slideml
Hello - This moves productivity/slideml to github. Index: Makefile === RCS file: /cvs/ports/productivity/slideml/Makefile,v retrieving revision 1.7 diff -u -p -r1.7 Makefile --- Makefile25 Mar 2014 21:20:39 - 1.7 +++ Makefile11 Mar 2016 00:02:09 - @@ -2,20 +2,20 @@ COMMENT = HTML slide generator based on SlideML -DISTNAME = slideml-1.1.0 -REVISION = 0 - +V =1.1.0 +REVISION = 1 +GH_TAGNAME = SLIDEML_${V:S/./_/g} +GH_ACCOUNT = conformal +GH_PROJECT = slideml +DISTNAME = ${GH_PROJECT}-${V} CATEGORIES = productivity -HOMEPAGE = http://opensource.conformal.com/wiki/Slide_ML +HOMEPAGE = https://github.com/conformal/slideml/wiki MAINTAINER = Laurent Fanis#W3C Software Notice and License & BSD PERMIT_PACKAGE_CDROM = Yes - -MASTER_SITES = http://opensource.conformal.com/snapshots/slideml/ -EXTRACT_SUFX = .tgz RUN_DEPENDS = graphics/p5-Image-Size Index: distinfo === RCS file: /cvs/ports/productivity/slideml/distinfo,v retrieving revision 1.3 diff -u -p -r1.3 distinfo --- distinfo18 Jan 2015 03:14:59 - 1.3 +++ distinfo11 Mar 2016 00:02:09 - @@ -1,2 +1,2 @@ -SHA256 (slideml-1.1.0.tgz) = RPCos9m9/bXNPhX+29p+k5yJiEBrtkm7HxGbiNN33ck= -SIZE (slideml-1.1.0.tgz) = 28245 +SHA256 (slideml-1.1.0.tar.gz) = mT9/V83DDpcp1dlayIwORs7gdi32Mp1MEQpfkW7zgwc= +SIZE (slideml-1.1.0.tar.gz) = 28172
[patch] net/adsuck
Hello - This moves net/adsuck to github. Index: Makefile === RCS file: /cvs/ports/net/adsuck/Makefile,v retrieving revision 1.29 diff -u -p -r1.29 Makefile --- Makefile15 Jul 2015 14:59:15 - 1.29 +++ Makefile10 Mar 2016 23:55:18 - @@ -2,18 +2,19 @@ COMMENT= DNS relay for ad blocking -DISTNAME= adsuck-2.5.0 +V= 2.5.0 +REVISION= 4 +GH_TAGNAME=ADSUCK_${V:S/./_/g} +GH_ACCOUNT=conformal +GH_PROJECT=adsuck +DISTNAME= ${GH_PROJECT}-${V} CATEGORIES=net -REVISION= 3 -HOMEPAGE= http://opensource.conformal.com/wiki/Adsuck +HOMEPAGE= https://github.com/conformal/adsuck/wiki MAINTAINER=Gonzalo L. R.-EXTRACT_SUFX= .tgz # BSD PERMIT_PACKAGE_CDROM= Yes - -MASTER_SITES= http://opensource.conformal.com/snapshots/adsuck/ WANTLIB += c event_core event_extra ldns pthread Index: distinfo === RCS file: /cvs/ports/net/adsuck/distinfo,v retrieving revision 1.14 diff -u -p -r1.14 distinfo --- distinfo17 Dec 2012 11:34:44 - 1.14 +++ distinfo10 Mar 2016 23:55:18 - @@ -1,2 +1,2 @@ -SHA256 (adsuck-2.5.0.tgz) = EmAuySScbHMD+QF7yQdHKK9jxFq+wVuYPkemZNcCQmM= -SIZE (adsuck-2.5.0.tgz) = 10443584 +SHA256 (adsuck-2.5.0.tar.gz) = fWV34g0wnU+qb4hSDa+MXZUSLPXlKzUNyX3vyqx9x+Y= +SIZE (adsuck-2.5.0.tar.gz) = 10448193
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 16:05:53 Modified files: audio/gsm : Makefile audio/gsm/patches: patch-Makefile Log message: remove NO_SHARED_LIBS; ok sthen@
Re: [mail/sendmail] SMTP session reuse bugfix
On 2016/03/10 12:45, Claus Assmann wrote: > On Wed, Mar 09, 2016, Jeremie Courreges-Anglas wrote: > > > Claus, in the future would it be possible to prefix the patch file names > > with "sendmail-"? It would be a bit safer for us, as we would not have > > Do you mean the patch on the sendmail.org FTP server? That naming > scheme is used for about 10 years so it's unlikely to be changed now. > > > to check for possible collisions with other ports. > > Sorry, but I don't understand what "possible collisions with other > ports" could happen: are the patches "global"? > They would normally be fetched to /usr/ports/distfiles which is "global", it's easy enough to override with DIST_SUBDIR, it's better not to use it too much (if everything did, we'd end up with a bunch more inode use, plus the lazy person's cd /usr/ports/*/pkgname would then fail ;) but I think it would be reasonable to use in this case.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 15:51:45 Modified files: multimedia/libvpx: Makefile multimedia/x264: Makefile multimedia/xvidcore: Makefile Log message: remove simple instances of NO_SHARED_LIBS
NO_SHARED cleanup status
For any committers who want to pitch in or just wonder how their ports are affected, here's what's up: PFRAG.shared can be folded into PLIST without restrictions. Remember the REVISION bump. NO_SHARED_ARCHS isn't set any longer and PROPERTIES:Mno_shared will never match. Instances of these can be removed. However, there are usually .if branches to consider. NO_SHARED_LIBS is always set to "No". It can be removed. CONFIGURE_SHARED always expands to "--enable-shared". I expect that this is the upstream default for the vast majority of affected ports. I currently have a bulk build running that will identify all ports that actually require CONFIGURE_ARGS = --enable-shared. Once that is done, all remaining instances of CONFIGURE_SHARED can be removed. SHARED_ONLY: DO NOT REMOVE from Perl ports. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [NEW] www/pnp4nagios
On Thu, March 10, 2016 23:22, Vadim Zhukov wrote: > 2016-03-09 17:08 GMT+03:00 Kirill Bychkov: >> On Thu, March 3, 2016 16:57, Kirill Bychkov wrote: >>> Him guys! >>> This is a port of PNP4Nagios, an addon for Nafios and Oconga for analyzing >>> performance data and storing it in RRD. >>> Current port is partially based on an old one from henning@ [1] and tested >>> for more than a month with Icinga 1.x processing data from about 400 hosts. >>> It could be splitted to Nagios and Icinga 2.x flavors if there are some >>> interest in them and one can test it with. >>> >>> [1] http://marc.info/?l=openbsd-ports=140803165912579=2 >>> >>> Comments? OKs? >> Objections? :) >> >> Updated tarball with fixed typos. > > Here are some more nits: > > ... in Makefile: > >> INSTALL_OPTS="-o roog -g bin" \ Damn, as usual... :) > > One more tyop. ;) > >> SYSCONFDIR =${BASESYSCONFDIR}/pnp4nagios/ >> LOCALSTATEDIR = ${BASELOCALSTATEDIR}/pnp4nagios > > Why slash is added in one case but not in the other? Just a paste effect. Should not change anything, byt a style matters, yes. > > >> # fix broken symlink in tarball > > If this symlink gets packaged, then it should be relative one, like: > > ln -sf ../en_US/dwnld.html \ > ${WRKSRC}/share/pnp/documents/de_DE/dwnld.html At a fake stage a file is installed, not symlink. Whithout this trick fake is broken because upstream foret to symlink it while creating tarball. > > ... in patches: > > At least patch-sample-config_httpd_conf_in needs justification, why it's > needed. > > ... in pkg/README-cgi: > >> Apache2 configuration for PNP4Nagios is stored under: >> /var/conf/modules.sample/pnp4nagios.conf Yes, mi bad. This should be /var/www > > /var/conf? I suppose this should be ${LOCALSTATEDIR}/apache2/conf, or > something like that. Bit not LOCALSTATEDIR which is set to /var/pnp4nagios. > > ... in pkg/PLIST-main: > > Is it intended that not all share/example/* stuff has its @sample > counterpart under ${SYSCONFDIR}? I've aded only mandatory configs. Others are not in my setup but probably would be useful for others. > >> share/doc/pkg-readmes/${FULLPKGNAME} >> @owner _icinga >> @sample ${LOCALSTATEDIR}/ >> @sample ${LOCALSTATEDIR}/stats/ >> @sample /var/log/pnp4nagios.log > > I'm not sure the latter is supposed to work, or won't fail at some > point in the future. @sample, when applied to a file, mean "take the > file from the line above and copy it here". And you have a non-files > line above up to README one. If you want to create an empty file owned > by someone, you may either use something like: Great catch. It is a file. It's a readme (it is above in the list, before all this directories you've mentionrd). I should create a "dumb" one first and then @sample it. > > @exec-add test -e /var/log/pnp4nagios.log || install -o _nagios -g > _nagios -m 0640 /dev/null /var/log/pnp4nagios.log > @extraunexec test -s /var/log/pnp4nagios || rm -f /var/log/pnp4nagios.log > > or use /var/log/pnp4nagios/ directory instead, owned by _nagios, where > application could create/rename/remove files without problem. I'd > recommend go the 2nd way, as we usually do. Well, I'm not sure that a subdirectory is really needed for the one log file, but it is a real alternative. Or just sampling an empty file... I'll make new tarball tomorrow. > > -- > WBR, > Vadim Zhukov >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 14:58:52 Modified files: archivers/bzip2: Makefile archivers/bzip2/patches: patch-Makefile devel/libslang : Makefile devel/libslang/pkg: PLIST graphics/jbigkit: Makefile graphics/jbigkit/patches: patch-libjbig_Makefile graphics/mpeg-lib: Makefile graphics/mpeg-lib/patches: patch-Makefile_in net/libbgpdump : Makefile lang/STk : Makefile lang/STk/pkg : PLIST mail/alpine: Makefile mail/alpine/patches: patch-imap_src_osdep_unix_Makefile math/cfitsio : Makefile www/cgiparse : Makefile www/cgiparse/patches: patch-Makefile_in x11/golem : Makefile x11/golem/pkg : PLIST Removed files: devel/libslang/pkg: PFRAG.shared lang/STk/pkg : PFRAG.shared x11/golem/pkg : PFRAG.shared Log message: remove various instances of NO_SHARED_LIBS and PROPERTIES:Mno_shared, fold PFRAG.shared into PLIST
Re: devel/mico failing due to failed assertion
> On Thu, Mar 10, 2016 at 05:58:05PM +0100, Karel Gardas wrote: > > On Thu, Mar 10, 2016 at 3:13 PM, Marc Espiewrote: > > > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote: > > >> This is a sign of not so correct network configuration. MICO is really > > >> picky about it so it should be able to resolve your host name/IP > > >> address. What's failing precisely in the assert above is that it's not > > >> able to get IP for your hostname. Can you confirm that this is the > > >> case? > > > > > > Nope. This is the only port in the tree that doesn't like it when you cut > > > network access during build (which proper build machines have started > > > doing > > > for a while now). > > > > This would be strange since I commonly build MICO w/o any internet > > connection. > > This is not what I'm talking about. I'm talking about explicitly blocking > the build user from any kind of network activity thru pf. > > > Indeed, it is, but I guess this was done for a good reason in the past > > and I would rather keep it this way. What I can certainly do for > > 2.3.14 release is to add some clear error message pointing to the > > incorrect network configuration. > > It's not an incorrect network configuration, actually. It's just no > resolving > some things on localhost. > > mico is the only port that wants this. Everything else works peachy. > > I've got a very paranoid setup on my build machines. > I just have: > block out quick proto {tcp,udp} from self user pbuild0 > > oh, and the build is chroot'd to a place that only knows about localhost. > > No other port in the trees ever tries to resolve `hostname` during build. but then how does it download the egg...
Re: devel/mico failing due to failed assertion
On Thu, Mar 10, 2016 at 05:58:05PM +0100, Karel Gardas wrote: > On Thu, Mar 10, 2016 at 3:13 PM, Marc Espiewrote: > > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote: > >> This is a sign of not so correct network configuration. MICO is really > >> picky about it so it should be able to resolve your host name/IP > >> address. What's failing precisely in the assert above is that it's not > >> able to get IP for your hostname. Can you confirm that this is the > >> case? > > > > Nope. This is the only port in the tree that doesn't like it when you cut > > network access during build (which proper build machines have started doing > > for a while now). > > This would be strange since I commonly build MICO w/o any internet connection. This is not what I'm talking about. I'm talking about explicitly blocking the build user from any kind of network activity thru pf. > Indeed, it is, but I guess this was done for a good reason in the past > and I would rather keep it this way. What I can certainly do for > 2.3.14 release is to add some clear error message pointing to the > incorrect network configuration. It's not an incorrect network configuration, actually. It's just no resolving some things on localhost. mico is the only port that wants this. Everything else works peachy. I've got a very paranoid setup on my build machines. I just have: block out quick proto {tcp,udp} from self user pbuild0 oh, and the build is chroot'd to a place that only knows about localhost. No other port in the trees ever tries to resolve `hostname` during build.
Re: [mail/sendmail] SMTP session reuse bugfix
On Wed, Mar 09, 2016, Jeremie Courreges-Anglas wrote: > Claus, in the future would it be possible to prefix the patch file names > with "sendmail-"? It would be a bit safer for us, as we would not have Do you mean the patch on the sendmail.org FTP server? That naming scheme is used for about 10 years so it's unlikely to be changed now. > to check for possible collisions with other ports. Sorry, but I don't understand what "possible collisions with other ports" could happen: are the patches "global"?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 13:41:22 Modified files: graphics/ffmpeg: Makefile Log message: requires --enable-shared
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 13:26:03 Modified files: print/ghostscript/gnu: Makefile print/ghostscript/gnu/pkg: PLIST Removed files: print/ghostscript/gnu/pkg: PFRAG.shared Log message: remove NO_SHARED_ARCHS, NO_SHARED_LIBS, and fold PFRAG.shared into PLIST ok kili@
Re: [NEW] www/pnp4nagios
2016-03-09 17:08 GMT+03:00 Kirill Bychkov: > On Thu, March 3, 2016 16:57, Kirill Bychkov wrote: >> Him guys! >> This is a port of PNP4Nagios, an addon for Nafios and Oconga for analyzing >> performance data and storing it in RRD. >> Current port is partially based on an old one from henning@ [1] and tested >> for more than a month with Icinga 1.x processing data from about 400 hosts. >> It could be splitted to Nagios and Icinga 2.x flavors if there are some >> interest in them and one can test it with. >> >> [1] http://marc.info/?l=openbsd-ports=140803165912579=2 >> >> Comments? OKs? > Objections? :) > > Updated tarball with fixed typos. Here are some more nits: ... in Makefile: > INSTALL_OPTS="-o roog -g bin" \ One more tyop. ;) > SYSCONFDIR =${BASESYSCONFDIR}/pnp4nagios/ > LOCALSTATEDIR = ${BASELOCALSTATEDIR}/pnp4nagios Why slash is added in one case but not in the other? > # fix broken symlink in tarball If this symlink gets packaged, then it should be relative one, like: ln -sf ../en_US/dwnld.html \ ${WRKSRC}/share/pnp/documents/de_DE/dwnld.html ... in patches: At least patch-sample-config_httpd_conf_in needs justification, why it's needed. ... in pkg/README-cgi: > Apache2 configuration for PNP4Nagios is stored under: > /var/conf/modules.sample/pnp4nagios.conf /var/conf? I suppose this should be ${LOCALSTATEDIR}/apache2/conf, or something like that. ... in pkg/PLIST-main: Is it intended that not all share/example/* stuff has its @sample counterpart under ${SYSCONFDIR}? > share/doc/pkg-readmes/${FULLPKGNAME} > @owner _icinga > @sample ${LOCALSTATEDIR}/ > @sample ${LOCALSTATEDIR}/stats/ > @sample /var/log/pnp4nagios.log I'm not sure the latter is supposed to work, or won't fail at some point in the future. @sample, when applied to a file, mean "take the file from the line above and copy it here". And you have a non-files line above up to README one. If you want to create an empty file owned by someone, you may either use something like: @exec-add test -e /var/log/pnp4nagios.log || install -o _nagios -g _nagios -m 0640 /dev/null /var/log/pnp4nagios.log @extraunexec test -s /var/log/pnp4nagios || rm -f /var/log/pnp4nagios.log or use /var/log/pnp4nagios/ directory instead, owned by _nagios, where application could create/rename/remove files without problem. I'd recommend go the 2nd way, as we usually do. -- WBR, Vadim Zhukov
Re: patch: perl.port.mk to support Module::Build::Tiny
On 03/10/16 01:39, Stuart Henderson wrote: > On 2016/03/09 15:26, Nigel Taylor wrote: >> Attached revised perl.port.mk diff > > Looks sane, testing this (and cpan.port.mk diff) in a full build now. > >> perl.port.mk.diff_p522 - extras diffs I am using. > > Let's clear Module::Build (which already triggers warnings and breaks > with 5.22) before we look at Module::Install (which iirc does still > run with 5.22?) Looked at Module::Build, distinfo, pkg/PLIST are the same. pkg/DESCR I used only the first two lines either way is ok. Makefile is where we differ, mines a little messy I thought, what I had was this see later try. # $OpenBSD:$ COMMENT = Module build DISTNAME = Module-Build-0.4208 PKGNAME = p5-Module-Build-0.42.08 CATEGORIES =devel # Perl PERMIT_PACKAGE_CDROM = Yes MODULES = cpan TEST_DEPENDS += devel/p5-PAR-Dist>=0.17 # TODO this works but messy... do-install: cd ${WRKSRC} && \ ./Build \ --install_path lib="${TRUEPREFIX}/${P5SITE}" \ --install_path arch="${TRUEPREFIX}/${P5ARCH}" \ --install_path libdoc="${TRUEPREFIX}/man/man3p" \ --install_path bindoc="${TRUEPREFIX}/man/man1" \ --install_path bin="${TRUEPREFIX}/bin" \ --install_path script="${TRUEPREFIX}/bin" \ --destdir=${WRKINST} \ install .include Difference is Makefile.PL is used, which uses Module::Build::Compatable, converts args and runs Build.PL, results in same Build/Makefile, the convert args converts to --config rather than --install_path, so install stage is messed up. Best effort I've come up with this slightly neater one # $OpenBSD:$ COMMENT = Module build DISTNAME = Module-Build-0.4208 PKGNAME = p5-Module-Build-0.42.08 CATEGORIES =devel # Perl PERMIT_PACKAGE_CDROM = Yes MODULES = cpan TEST_DEPENDS += devel/p5-PAR-Dist>=0.17 CONFIGURE_STYLE = modbuild none .include Needs this in perl.port.mk - "none" doesn't add a build depends .if ${CONFIGURE_STYLE:L:Mmodbuild} +. if ${CONFIGURE_STYLE:L:Mtiny} +BUILD_DEPENDS += devel/p5-Module-Build-Tiny +. elif ${CONFIGURE_STYLE:L:Mnone} + # for building Module Build... +. else +BUILD_DEPENDS += devel/p5-Module-Build +. endif Currently this shouldn't be needed, as it's for when Module::Build is removed from core perl with 5.22 and want modbuild to add the dependency. Tried current perl.port.mk and the one above, both work. Will need to work out ordering, the changed perl.port.mk can go in before perl 5.22. Followed the version numbering upstream used major.minor.sub, either way is ok, but no to using epochs later, keep 4digits or 2's. $ doas -u _pbuild make ===> Enabling ccache for p5-Module-Build-0.42.08 ===> p5-Module-Build-0.42.08 depends on: ccache-* -> ccache-3.2.4 ===> Checking files for p5-Module-Build-0.42.08 `/usr/ports/distfiles/Module-Build-0.4208.tar.gz' is up to date. >> (SHA256) Module-Build-0.4208.tar.gz: OK ===> Extracting for p5-Module-Build-0.42.08 ===> Patching for p5-Module-Build-0.42.08 ===> Configuring for p5-Module-Build-0.42.08 Created MYMETA.yml and MYMETA.json Creating new 'Build' script for 'Module-Build' version '0.4208' ===> Building for p5-Module-Build-0.42.08 Building Module-Build $ doas -u _pbuild make fake ===> Faking installation for p5-Module-Build-0.42.08 install -d -m 755 /usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64 Building Module-Build Installing /usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/man/man1/config_data.1 Installing /usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/inc/latest.pm Installing /usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/inc/latest/private.pm Installing /usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/Module/Build.pm Installing /usr/ports/pobj/p5-Module-Build-0.42.08/fake-amd64/usr/local/libdata/perl5/site_perl/Module/Build/PodParser.pm $ doas -u _pbuild make test ===> p5-Module-Build-0.42.08 depends on: p5-PAR-Dist->=0.17 -> p5-PAR-Dist-0.49 ===> Regression tests for p5-Module-Build-0.42.08 /usr/bin/perl Build --makefile_env_macros 1 test t/00-compile.t . ok t/PL_files.t ... ok t/actions/installdeps.t ok ... t/unit_run_test_harness.t .. ok t/use_tap_harness.t ok t/versions.t ... ok t/write_default_maniskip.t . ok t/xs.t . ok All tests successful. Files=53, Tests=1134, 182 wallclock secs ( 0.41 usr 0.56 sys + 48.54 cusr 43.36 csys = 92.87 CPU) Result: PASS Extra in TEST_DEPENDS, PAR::Dist is optional if pardist is used in Build.PL then required, we aren't creating a distribution just building, optional if included at runtime. $ grep
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 13:15:07 Modified files: telephony/baresip/re: Makefile telephony/baresip/rem: Makefile Log message: remove NO_SHARED_LIBS
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: pas...@cvs.openbsd.org 2016/03/10 12:45:59 Modified files: security/libotr: Makefile distinfo security/libotr/pkg: PLIST Log message: SECURITY update to 4.1.1. Fixes CVE 2016-2851; to the best of our knowledge, this one is not exploitable on OpenBSD because memory returned by malloc(0) is inaccessible. Bug found by stsp@ 11 months ago.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 12:29:25 Modified files: security/nss : Makefile Log message: replace after-bsd.port.mk hack with PROPERTIES check
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 12:03:35 Modified files: x11/fleditor : Makefile Log message: requires --enable-shared remove NO_SHARED_LIBS
Re: devel/mico failing due to failed assertion
Karel Gardas wrote: > This is a sign of not so correct network configuration. MICO is really > picky about it so it should be able to resolve your host name/IP > address. What's failing precisely in the assert above is that it's not > able to get IP for your hostname. Can you confirm that this is the > case? Confirmed. I hadn't considered that my hostname could affect a package build. :-) I don't know anything about Mico, so I'll stay out of the patching process.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2016/03/10 10:45:11 Modified files: x11/qt4: qt4.port.mk x11/qt5: qt5.port.mk Added files: devel/qmake: qmake.port.mk Log message: Switch to a separate qmake.port.mk. Simplifies logic a lot. This removes support of separate qmake versions in one port: as we discovered, there are no ports actually needing this; strangers like print/poppler don't use qmake in build. This should be transparent to current ports. But expect more tweaks there: for now, qt?.port.mk forces qmake.port.mk inclusion, but that will be reworked to a more common scheme. Same idea from (at least) espie@ and me; also, espie@ agrees on the plan.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2016/03/10 10:38:52 ports/devel/qmake Update of /cvs/ports/devel/qmake In directory cvs.openbsd.org:/tmp/cvs-serv3286/devel/qmake Log Message: Directory /cvs/ports/devel/qmake added to the repository
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2016/03/10 10:37:31 Modified files: sysutils/tarsnap: Makefile distinfo Log message: Update tarsnap to 1.0.37. This version adds several new options, including --passphrase-time option for increased security of passphrase-protected key files, along with minor bug fixes and some additional warnings about common user errors.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2016/03/10 10:24:38 Modified files: x11/cool-retro-term: Makefile Log message: Use qmake instead of qmake5 in CONFIGURE_STYLE. Needed for upcoming qmake.port.mk.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2016/03/10 10:27:11 Modified files: audio/musique : Makefile Log message: Make this fit 80 columns.
Re: update devel/py-pip
On Sun, 6 Mar 2016 20:34:25 +0100, Daniel Jakotswrote: > Here's an update to latest py-pip. Ping?
Re: devel/mico failing due to failed assertion
On Thu, Mar 10, 2016 at 3:13 PM, Marc Espiewrote: > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote: >> This is a sign of not so correct network configuration. MICO is really >> picky about it so it should be able to resolve your host name/IP >> address. What's failing precisely in the assert above is that it's not >> able to get IP for your hostname. Can you confirm that this is the >> case? > > Nope. This is the only port in the tree that doesn't like it when you cut > network access during build (which proper build machines have started doing > for a while now). This would be strange since I commonly build MICO w/o any internet connection. > I've looked a bit further, and that stupid test is so deep embedded within > the mico code itself that it will be a pain to fix. Indeed, it is, but I guess this was done for a good reason in the past and I would rather keep it this way. What I can certainly do for 2.3.14 release is to add some clear error message pointing to the incorrect network configuration.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2016/03/10 09:07:27 Modified files: geo/gpsbabel : Makefile Log message: Switch to MODQMAKE, no Makefile lines count change.
Re: devel/mico failing due to failed assertion
On 2016/03/10 15:13, Marc Espie wrote: > On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote: > > This is a sign of not so correct network configuration. MICO is really > > picky about it so it should be able to resolve your host name/IP > > address. What's failing precisely in the assert above is that it's not > > able to get IP for your hostname. Can you confirm that this is the > > case? > > Nope. This is the only port in the tree that doesn't like it when you cut > network access during build (which proper build machines have started doing > for a while now). > > I've looked a bit further, and that stupid test is so deep embedded within > the mico code itself that it will be a pain to fix. > It's not even network access, it just needs the name in /etc/hosts. mico builds fine for me and I do not permit _pbuild to make network connections, but I do have an entry in /etc/hosts for the hostname (i.e. getent `hostname` works).
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2016/03/10 07:19:53 Modified files: x11/qwt: Makefile Log message: Use MODQMAKE, not MODQMAKE4. No actual changes in build process. Will be used in further transition to a separate qmake.port.mk.
Re: devel/mico failing due to failed assertion
On Thu, Mar 10, 2016 at 11:53:56AM +0100, Karel Gardas wrote: > This is a sign of not so correct network configuration. MICO is really > picky about it so it should be able to resolve your host name/IP > address. What's failing precisely in the assert above is that it's not > able to get IP for your hostname. Can you confirm that this is the > case? Nope. This is the only port in the tree that doesn't like it when you cut network access during build (which proper build machines have started doing for a while now). I've looked a bit further, and that stupid test is so deep embedded within the mico code itself that it will be a pain to fix.
Re: ports gdb thread handling... (fwd)
On Thu, 10 Mar 2016 01:08:36 +0100, Jeremie Courreges-Anglas wrote: > Philip Guentherwrites: > > > Broadening to ports@ > > > > With respect to this question in my original note: > >> Or maybe new gdb has some way to have ptid_get_pid() return the > >> per-thread value? > > > > the answer appears to be "nope, no new magic in gdb for that". > > Makes sense, I only tested with an old gdb (7.9.1) so far but will take > a look at -current soon. > > Pascal, any objection? Nope. But kettenis@ knows this code best, so I had hoped for his comment. > > > > Philip > > > > -- Forwarded message -- > > Date: Sun, 19 Apr 2015 16:18:07 -0700 > > From: Philip Guenther > > To: Pascal Stumpf > > Cc: Mark Kettenis > > Subject: ports gdb thread handling... > > > > > > Looks like the gdb in ports needs patching to try ptid_get_lwp() before > > ptid_get_pid() when fetching/setting registers. For example, diff below > > fixes this for amd64. Without this it always reports the original > > thread's registers (and thus the same backtrace), but with it I can get > > distinct backtraces like: > > > > (gdb) bt > > #0 tmain (arg=0x13b8b2200fcf) at f.c:7 > > #1 0x13bad626ba3e in _rthread_start (v=0x13bb143b9000) > > at /usr/src/lib/librthread-clean/rthread.c:145 > > #2 0x13bafd3035db in __tfork_thread () > > at /usr/src/lib/libc-clean/arch/amd64/sys/tfork_thread.S:79 > > (gdb) info thr > > Id Target Id Frame > > * 2thread 1006996tmain (arg=0x13b8b2200fcf) at f.c:7 > > 1thread 1021961_dl_sigprocmask () > > at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:121 > > (gdb) thread 1 > > [Switching to thread 1 (thread 1021961)] > > #0 _dl_sigprocmask () at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:121 > > 121 jc 1b /* error: result = -errno */ > > (gdb) bt > > #0 _dl_sigprocmask () at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:121 > > #1 0x13bba8505352 in _dl_thread_bind_lock (what=0, > > omask=0x7f7e7474) > > at /usr/src/libexec/ld.so-realclean/dlfcn.c:526 > > #2 0x13bba8506a4c in _dl_bind (object=0x13bacf01f800, > > index=) > > at /usr/src/libexec/ld.so-realclean/amd64/rtld_machine.c:393 > > #3 0x13bba85028b9 in _dl_bind_start () > > at /usr/src/libexec/ld.so-realclean/amd64/ldasm.S:167 > > #4 0x13bad626b6fe in pthread_join (thread=0x13bb143b9000, retval=0x0) > > at /usr/src/lib/librthread-clean/rthread.c:360 > > #5 0x13b8b2100f8a in main () at f.c:18 > > (gdb) > > > > > > The other arch files will need the same sort of diff. Or maybe new gdb > > has some way to have ptid_get_pid() return the per-thread value? > > > > Philip > > > > > > --- gdb/amd64bsd-nat.c Thu Feb 19 03:58:07 2015 > > +++ /tmp/amd64bsd-nat.c Sun Apr 19 16:09:45 2015 > > @@ -43,13 +43,19 @@ > >struct regcache *regcache, int regnum) > > { > >struct gdbarch *gdbarch = get_regcache_arch (regcache); > > + int pid; > > > > + /* Cater for systems like OpenBSD, that implement threads as > > + separate processes. */ > > + pid = ptid_get_lwp (inferior_ptid); > > + if (pid == 0) > > +pid = ptid_get_pid (inferior_ptid); > > + > >if (regnum == -1 || amd64_native_gregset_supplies_p (gdbarch, regnum)) > > { > >struct reg regs; > > > > - if (ptrace (PT_GETREGS, ptid_get_pid (inferior_ptid), > > - (PTRACE_TYPE_ARG3) , 0) == -1) > > + if (ptrace (PT_GETREGS, pid, (PTRACE_TYPE_ARG3) , 0) == -1) > > perror_with_name (_("Couldn't get registers")); > > > >amd64_supply_native_gregset (regcache, , -1); > > @@ -61,8 +67,7 @@ > > { > >struct fpreg fpregs; > > > > - if (ptrace (PT_GETFPREGS, ptid_get_pid (inferior_ptid), > > - (PTRACE_TYPE_ARG3) , 0) == -1) > > + if (ptrace (PT_GETFPREGS, pid, (PTRACE_TYPE_ARG3) , 0) == -1) > > perror_with_name (_("Couldn't get floating point status")); > > > >amd64_supply_fxsave (regcache, -1, ); > > @@ -77,19 +82,24 @@ > >struct regcache *regcache, int regnum) > > { > >struct gdbarch *gdbarch = get_regcache_arch (regcache); > > + int pid; > > > > + /* Cater for systems like OpenBSD, that implement threads as > > + separate processes. */ > > + pid = ptid_get_lwp (inferior_ptid); > > + if (pid == 0) > > +pid = ptid_get_pid (inferior_ptid); > > + > >if (regnum == -1 || amd64_native_gregset_supplies_p (gdbarch, regnum)) > > { > >struct reg regs; > > > > - if (ptrace (PT_GETREGS, ptid_get_pid (inferior_ptid), > > - (PTRACE_TYPE_ARG3) , 0) == -1) > > + if (ptrace (PT_GETREGS, pid, (PTRACE_TYPE_ARG3) , 0) == -1) > > perror_with_name (_("Couldn't get registers")); > > > >amd64_collect_native_gregset (regcache, ,
Re: libotr security fix
On Thu, 10 Mar 2016 10:10:07 +0100, Stefan Sperling wrote: > On Wed, Mar 09, 2016 at 05:32:47PM -0800, Michael McConville wrote: > > Is anyone working on updates for security/libotr and > > security/pidgin-otr? There were releases addressing a scary > > vulnerability this morning: > > > > https://marc.info/?l=otr-announce=145754687614832=2 > > > > If not, I probably have time to work on it tonight. > > These should be updated, but there's no reason to hurry up very very much. > > The libotr problem depends on malloc(0) returning a pointer that doesn't > segfault when it is used. On OpenBSD the program will crash at the point > where the attacker tries to overwrite the heap. > Unless there's another avenue for this exploit which doesn't use malloc(0), > but the advisory only mentions malloc(0). > See http://seclists.org/oss-sec/2016/q1/568 > > security/pidgin-otr has been already patched in our ports tree by me in > 2015 (before 5.8). I reported this bug and they left it sit for 9 months > until Hanno Boeck reported the same problem again: > https://bugs.otr.im/issues/88 > pidgin-otr crashed on OpenBSD immediately, which is why I noticed. > > Works for me with all OTR-capable messengers (Kopete untested). No API change apparently, so no bump. "make update-plist" re-added share/aclocal; is that due to some change in dependencies? Index: Makefile === RCS file: /cvs/ports/security/libotr/Makefile,v retrieving revision 1.27 diff -u -p -r1.27 Makefile --- Makefile19 Jul 2015 08:18:52 - 1.27 +++ Makefile10 Mar 2016 10:08:27 - @@ -2,7 +2,7 @@ COMMENT= portable OTR messaging library and toolkit -DISTNAME= libotr-4.1.0 +DISTNAME= libotr-4.1.1 CATEGORIES=security SHARED_LIBS += otr 4.1 # 6.0 Index: distinfo === RCS file: /cvs/ports/security/libotr/distinfo,v retrieving revision 1.9 diff -u -p -r1.9 distinfo --- distinfo3 Apr 2015 16:15:40 - 1.9 +++ distinfo10 Mar 2016 10:08:27 - @@ -1,2 +1,2 @@ -SHA256 (libotr-4.1.0.tar.gz) = T9uJGUDsidMAGQqY9pqROCSNy4yNM3Yz+5gbjQqc2TA= -SIZE (libotr-4.1.0.tar.gz) = 576771 +SHA256 (libotr-4.1.1.tar.gz) = izsYJCQlEGepUvtObHuVoh5kT7sn+9X4rysu2HykGfU= +SIZE (libotr-4.1.1.tar.gz) = 655791 Index: pkg/PLIST === RCS file: /cvs/ports/security/libotr/pkg/PLIST,v retrieving revision 1.7 diff -u -p -r1.7 PLIST --- pkg/PLIST 16 Mar 2015 18:07:54 - 1.7 +++ pkg/PLIST 10 Mar 2016 10:08:27 - @@ -33,4 +33,5 @@ lib/pkgconfig/libotr.pc @man man/man1/otr_remac.1 @man man/man1/otr_sesskeys.1 @man man/man1/otr_toolkit.1 +share/aclocal/ share/aclocal/libotr.m4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2016/03/10 06:35:23 Modified files: sysutils/logstalgia: Makefile Log message: update HOMEPAGE. OK gonzalo@ (maintainer)
Re: [update] net/transmission
On 2016-03-08 13:11, Marc Espie wrote: On Tue, Mar 08, 2016 at 04:18:16PM +, Christian Weisgerber wrote: On 2016-03-08, Josh Grossewrote: > Thank you, naddy, for your kind patience with my port update. This one in > particular has been a learning experience, and I appreciate the guidance. That port is awfully complex. I keep wavering between wanting to split off the Qt client into a separate port to simplify things, and keeping the port as is just because it makes a good example. Can you build the qt client separately in a simple enough way to not have lots of patches duplication ? If the -qt subpackage is split into its own port, it needs to build -main in order to link needed objects. If I'm right, then this doesn't seem a worthwhile separation. But, due to the large set of corrections that Vadim, Naddy, and Antoine needed to make to my port update OK for commit, it is safest to assume I'm wrong. :) I've had a look, it's not that awful, but then I'm biased, considering what "complex" was in the past...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 05:20:06 Modified files: infrastructure/bin: portcheck infrastructure/mk: arch-defines.mk bsd.port.arch.mk Log message: no more non-shared archs: NO_SHARED_ARCHS and "no_shared" in PROPERTIES are no longer set
Re: devel/mico failing due to failed assertion
On 2016 Mar 10 (Thu) at 10:53:26 + (+), Stuart Henderson wrote: :On 2016/03/10 02:05, Michael McConville wrote: :> It's been failing reliably on my machine since I started bulk building a :> couple months ago. : :If your local hostname doesn't resolve this triggers an assertion in :mico. : would setting a fake hostname fix the assert? can that be patched out? -- In Boston, it is illegal to hold frog-jumping contests in nightclubs.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2016/03/10 04:50:13 Modified files: audio/flite: Makefile databases/db : Makefile.inc lang/python: Makefile.inc lang/ruby : Makefile.inc lang/swi-prolog: Makefile math/netcdf: Makefile net/libircclient: Makefile telephony/pjsua: Makefile x11/fltk : Makefile Log message: requires --enable-shared
Re: missing lib dep for devel/iso-codes
On Thu, Mar 10, 2016 at 11:01:58AM +, Stuart Henderson wrote: > On 2016/03/10 02:37, Michael McConville wrote: > > It looks like devel/iso-codes needs libintl, although make > > lib-depends-check doesn't pick it up. See the build failure below. > > This doesn't make sense: > > > /usr/local/bin/msgfmt --verbose --check -o da.mo da.po > > 488 translated messages. > > /usr/local/bin/msgfmt --verbose --check -o vi.mo vi.po > > /usr/local/bin/msgfmt: can't load library 'libintl.so.6.0' > > Makefile:462: recipe for target 'vi.mo' failed > > The message is generated by msgfmt which is part of gettext-tools, > but gettext-tools *does* depend on devel/gettext (which contains > libintl). > > If this is something other than a local problem, it's definitely > not in iso-codes. > I've seen these sorts of things with dpb too, build tools/libs suddenly disappearing. Sometimes the build will succeed if it's run again. I'm wondering if turning off junking ("-J 0") would help? Cheers, -- Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF
Re: productivity/davical failing when fetching
On 2016/03/10 02:26, Michael McConville wrote: > Apparently none of the sources are valid anymore. IIRC, this has been > happening since I started bulk building a couple months ago. This is a bug (or missing feature) in ports infrastructure, the MASTER_SITE_BACKUP mechanism doesn't know about the filename{url}sufx handling in DISTFILES. > ===> Trying http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles// > /usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v > http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1 > Trying 145.238.209.46... > Requesting > http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1 > ftp: Error retrieving file: 404 Not Found $ curl -s http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/ | grep davical davical-1.1.3.1.tar.gz 24-Nov-2014 03:24 3031220 When using MASTER_SITE_BACKUP it needs to fetch these files from "$(filename)$(sufx)" rather than "$(url)$(sufx)".
Re: missing lib dep for devel/iso-codes
On 2016/03/10 02:37, Michael McConville wrote: > It looks like devel/iso-codes needs libintl, although make > lib-depends-check doesn't pick it up. See the build failure below. This doesn't make sense: > /usr/local/bin/msgfmt --verbose --check -o da.mo da.po > 488 translated messages. > /usr/local/bin/msgfmt --verbose --check -o vi.mo vi.po > /usr/local/bin/msgfmt: can't load library 'libintl.so.6.0' > Makefile:462: recipe for target 'vi.mo' failed The message is generated by msgfmt which is part of gettext-tools, but gettext-tools *does* depend on devel/gettext (which contains libintl). If this is something other than a local problem, it's definitely not in iso-codes.
Re: devel/mico failing due to failed assertion
On 2016/03/10 02:05, Michael McConville wrote: > It's been failing reliably on my machine since I started bulk building a > couple months ago. If your local hostname doesn't resolve this triggers an assertion in mico.
Re: devel/mico failing due to failed assertion
This is a sign of not so correct network configuration. MICO is really picky about it so it should be able to resolve your host name/IP address. What's failing precisely in the assert above is that it's not able to get IP for your hostname. Can you confirm that this is the case? On Thu, Mar 10, 2016 at 11:05 AM, Michael McConvillewrote: > It's been failing reliably on my machine since I started bulk building a > couple months ago. > > Building on localhost under devel/mico > BDEPENDS = [devel/gmake] > DIST = [devel/mico:mico-2.3.13.tar.gz] > FULLPKGNAME = mico-2.3.13p0 > (Junk lock failure for localhost at 1455583281) > Received IO > (Junk lock obtained for localhost at 1455583287) > Woken up devel/mico > Woken up devel/mico > Woken up devel/mico > Short-cut: depends already handled by devel/avr/gcc Running show-prepare-results in devel/mico at 1455583287 > ===> devel/mico > ===> mico-2.3.13p0 depends on: gmake-* -> gmake-4.1p0 > ===> Verifying specs: c m ncurses readline stdc++ crypto ssl ICE SM X11 Xt > pthread > ===> found c.84.2 m.9.0 ncurses.14.0 readline.4.0 stdc++.57.0 crypto.37.0 > ssl.38.0 ICE.10.0 SM.9.0 X11.16.1 Xt.11.0 pthread.20.1 > gmake-4.1p0 > (Junk lock released for localhost at 1455583288) > distfiles size=3269814 Running patch in devel/mico at 1455583288 > ===> devel/mico > ===> Checking files for mico-2.3.13p0 > `/mnt/big/ports/distfiles/mico-2.3.13.tar.gz' is up to date. > ===> Extracting for mico-2.3.13p0 > ===> Patching for mico-2.3.13p0 Running configure in devel/mico at 1455583290 > ===> devel/mico > ===> Configuring for mico-2.3.13p0 > Using /home/dpb-wrk/mico-2.3.13/config.site (generated) > loading site script /home/dpb-wrk/mico-2.3.13/config.site > creating cache ./config.cache > checking for extra include and lib directories... > checking host system type... x86_64-unknown-openbsd5.9 > checking target system type... x86_64-unknown-openbsd5.9 > checking build system type... x86_64-unknown-openbsd5.9 > checking for gcc... cc > checking whether the C compiler (cc -O2 -pipe ) works... yes > checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no > checking whether we are using GNU C... (cached) yes > checking whether cc accepts -g... (cached) yes > checking how to run the C preprocessor... cc -E > checking for c++... c++ > checking whether the C++ compiler (c++ -O2 -pipe ) works... yes > checking whether the C++ compiler (c++ -O2 -pipe ) is a cross-compiler... no > checking whether we are using GNU C++... yes > checking whether c++ accepts -g... (cached) yes > checking how to run the C++ preprocessor... c++ -E > checking for POSIXized ISC... no > checking OS Type... unix > checking for open in -lpthread... yes > checking for pthread.h... (cached) yes > checking for sched.h... yes > checking for semaphore.h... (cached) yes > checking for bison... yacc > checking for flex... (cached) flex > checking for yywrap in -lfl... (cached) yes > checking for ar... ar rc > checking for ranlib... ranlib > checking whether gmake sets ${MAKE}... yes > checking for tclsh... tclsh > checking for javac... no > checking for JavaCUP... no > configure: warning: you have not installed JDK 1.1 and JavaCUP. java parts > disabled. > checking for esnacc/c++/asn-incl.h... no > checking for open in -lc++asn1... no > checking for esnacc... no > checking for smp/AttributeCertificateDefinitions.h... no > checking for open in -lcmlasn... no > checking for open in -lm... (cached) yes > checking for open in -lnsl... no > checking for X... (cached) libraries /usr/X11R6/lib, headers > /usr/X11R6/include > checking for dnet_ntoa in -ldnet... no > checking for dnet_ntoa in -ldnet_stub... no > checking for gethostbyname... (cached) yes > checking for connect... (cached) yes > checking for remove... (cached) yes > checking for shmat... (cached) yes > checking for IceConnectionNumber in -lICE... (cached) yes > checking for open in -lsocket... no > checking for open in -lbsd... no > checking for open in -lelf... no > checking for open in -ldl... no > checking for open in -ldld... no > checking for open in -lld... no > checking for open in -lcrypto... yes > checking for open in -lssl... yes > checking for open in -lncurses... yes > checking for readline in -lreadline... yes > checking for ANSI C header files... (cached) yes > checking for fcntl.h... (cached) yes > checking for unistd.h... (cached) yes > checking for sys/select.h... (cached) yes > checking for strings.h... (cached) yes > checking for float.h... (cached) yes > checking for ieeefp.h... yes > checking for sys/un.h... (cached) yes > checking for netinet/in.h... (cached) yes > checking for arpa/inet.h... (cached) yes > checking for netdb.h... (cached) yes > checking for dlfcn.h... (cached) yes > checking for dl.h... no > checking for netinet/tcp.h... (cached) yes > checking for stdlib.h... (cached) yes > checking for sys/time.h... (cached) yes > checking for
missing lib dep for devel/iso-codes
It looks like devel/iso-codes needs libintl, although make lib-depends-check doesn't pick it up. See the build failure below. ===> Building for iso-codes-3.66 Making all in iso_639 gmake[1]: Entering directory '/home/dpb-wrk/iso-codes-3.66/iso-codes-3.66/iso_639' /usr/local/bin/msgfmt --verbose --check -o wa.mo wa.po 486 translated messages, 2 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o mn.mo mn.po 137 translated messages, 173 fuzzy translations, 178 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o ko.mo ko.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o id.mo id.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o ml.mo ml.po 483 translated messages, 2 fuzzy translations, 3 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o ve.mo ve.po 37 translated messages, 257 fuzzy translations, 194 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o zh_TW.mo zh_TW.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o gez.mo gez.po gez.po:9: warning: header field 'Language' still has the initial default value 121 translated messages, 49 fuzzy translations, 318 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o ms.mo ms.po ms.po:11: warning: header field 'Language' still has the initial default value 43 translated messages, 139 fuzzy translations, 306 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o ps.mo ps.po ps.po:9: warning: header field 'Language' still has the initial default value 29 translated messages, 34 fuzzy translations, 425 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o ro.mo ro.po 486 translated messages, 2 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o sk.mo sk.po 486 translated messages, 2 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o nl.mo nl.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o oc.mo oc.po oc.po:12: warning: header field 'Language' still has the initial default value 85 translated messages, 26 fuzzy translations, 377 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o pl.mo pl.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o af.mo af.po 158 translated messages, 147 fuzzy translations, 183 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o ta.mo ta.po 483 translated messages, 2 fuzzy translations, 3 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o am.mo am.po am.po:9: warning: header field 'Language' still has the initial default value 121 translated messages, 49 fuzzy translations, 318 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o pt.mo pt.po 274 translated messages, 139 fuzzy translations, 75 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o he.mo he.po 45 translated messages, 135 fuzzy translations, 308 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o gl.mo gl.po 486 translated messages, 2 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o ar.mo ar.po 60 translated messages, 133 fuzzy translations, 295 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o uk.mo uk.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o as.mo as.po 485 translated messages, 1 fuzzy translation, 2 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o mk.mo mk.po mk.po:12: warning: header field 'Language' still has the initial default value 36 translated messages, 144 fuzzy translations, 308 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o kn.mo kn.po 483 translated messages, 2 fuzzy translations, 3 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o crh.mo crh.po 431 translated messages, 37 fuzzy translations, 20 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o cs.mo cs.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o el.mo el.po 81 translated messages, 74 fuzzy translations, 333 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o it.mo it.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o is.mo is.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o xh.mo xh.po 50 translated messages, 138 fuzzy translations, 300 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o bg.mo bg.po 259 translated messages, 229 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o be.mo be.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o fr.mo fr.po 488 translated messages. /usr/local/bin/msgfmt --verbose --check -o eu.mo eu.po eu.po:13: warning: header field 'Language' still has the initial default value 270 translated messages, 39 fuzzy translations, 179 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o lt.mo lt.po 479 translated messages, 2 fuzzy translations, 7 untranslated messages. /usr/local/bin/msgfmt --verbose --check -o hr.mo
productivity/davical failing when fetching
Apparently none of the sources are valid anymore. IIRC, this has been happening since I started bulk building a couple months ago. >>> From productivity/davical ===> Trying https://gitlab.com/davical-project/davical/repository/ /usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v https://gitlab.com/davical-project/davical/repository/archive.tar.gz?ref=r1.1.3.1 Trying 104.210.2.228... Requesting https://gitlab.com/davical-project/davical/repository/archive.tar.gz?ref=r1.1.3.1 3032719 bytes received in 3.31 seconds (894.80 KB/s) size does not match ===> Trying http://ftp.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1 Trying 129.128.5.191... Requesting http://ftp.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1 ftp: Error retrieving file: 404 Not Found ===> Trying ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1 Connected to plier.ucar.edu. 220 plier.ucar.edu FTP server ready. 331 Guest login ok, send your email address as password. 230- Welcome to ftp.usa.OpenBSD.org in Boulder, Colorado, USA. 230- For other mirror sites visit http://www.openbsd.org/ftp.html 230-_ _ _ 230- / ___ \ | _ \ / | __ \ 230- / / / /___ ___ | |_) | (___ | | | | 230- / / / / __ \/ _ \/ __ \| _ < \___ \| | | | 230-/ /__/ / /_/ / __/ / / /| |_) |) | |__| | 230-\_/ .___/\___/_/ /_/ |/|_/|_/ 230- /_/ 230-|.The proactively secure Unix-like 230-. |L /| .Operating System. 230-_ . |\ _| \--+._/| . Please visit the OpenBSD web site 230- / ||\| Y J ) / |/| ./ at http://www.openbsd.org/ 230- J |)'( |` F`.'/ 230--<| F __ .-< All transfers are logged, if you don't 230- | / .-'. `. /-. L___ like this policy, disconnect now! 230- J \ <\ | | O\|.-' 230-_J \ .-\/ O | | \ |F 230- '-F -<_. \ .-' `-' L__ OpenBSD 5.8 has now been released! 230- __J _ _. >-' )._. |-' You can order a CD of OpenBSD 5.8 230- `-|.' /_. \_| F from http://www.openbsd.org/orders.html. 230-/.- ._.Trying http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles// /usr/bin/ftp -C -o /mnt/big/ports/distfiles/davical-1.1.3.1.tar.gz.part -v http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1 Trying 145.238.209.46... Requesting http://ftp.fr.openbsd.org/pub/OpenBSD/distfiles//archive.tar.gz?ref=r1.1.3.1 ftp: Error retrieving file: 404 Not Found
devel/mico failing due to failed assertion
It's been failing reliably on my machine since I started bulk building a couple months ago. >>> Building on localhost under devel/mico BDEPENDS = [devel/gmake] DIST = [devel/mico:mico-2.3.13.tar.gz] FULLPKGNAME = mico-2.3.13p0 (Junk lock failure for localhost at 1455583281) Received IO (Junk lock obtained for localhost at 1455583287) Woken up devel/mico Woken up devel/mico Woken up devel/mico Short-cut: depends already handled by devel/avr/gcc >>> Running show-prepare-results in devel/mico at 1455583287 ===> devel/mico ===> mico-2.3.13p0 depends on: gmake-* -> gmake-4.1p0 ===> Verifying specs: c m ncurses readline stdc++ crypto ssl ICE SM X11 Xt pthread ===> found c.84.2 m.9.0 ncurses.14.0 readline.4.0 stdc++.57.0 crypto.37.0 ssl.38.0 ICE.10.0 SM.9.0 X11.16.1 Xt.11.0 pthread.20.1 gmake-4.1p0 (Junk lock released for localhost at 1455583288) distfiles size=3269814 >>> Running patch in devel/mico at 1455583288 ===> devel/mico ===> Checking files for mico-2.3.13p0 `/mnt/big/ports/distfiles/mico-2.3.13.tar.gz' is up to date. ===> Extracting for mico-2.3.13p0 ===> Patching for mico-2.3.13p0 >>> Running configure in devel/mico at 1455583290 ===> devel/mico ===> Configuring for mico-2.3.13p0 Using /home/dpb-wrk/mico-2.3.13/config.site (generated) loading site script /home/dpb-wrk/mico-2.3.13/config.site creating cache ./config.cache checking for extra include and lib directories... checking host system type... x86_64-unknown-openbsd5.9 checking target system type... x86_64-unknown-openbsd5.9 checking build system type... x86_64-unknown-openbsd5.9 checking for gcc... cc checking whether the C compiler (cc -O2 -pipe ) works... yes checking whether the C compiler (cc -O2 -pipe ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether cc accepts -g... (cached) yes checking how to run the C preprocessor... cc -E checking for c++... c++ checking whether the C++ compiler (c++ -O2 -pipe ) works... yes checking whether the C++ compiler (c++ -O2 -pipe ) is a cross-compiler... no checking whether we are using GNU C++... yes checking whether c++ accepts -g... (cached) yes checking how to run the C++ preprocessor... c++ -E checking for POSIXized ISC... no checking OS Type... unix checking for open in -lpthread... yes checking for pthread.h... (cached) yes checking for sched.h... yes checking for semaphore.h... (cached) yes checking for bison... yacc checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking for ar... ar rc checking for ranlib... ranlib checking whether gmake sets ${MAKE}... yes checking for tclsh... tclsh checking for javac... no checking for JavaCUP... no configure: warning: you have not installed JDK 1.1 and JavaCUP. java parts disabled. checking for esnacc/c++/asn-incl.h... no checking for open in -lc++asn1... no checking for esnacc... no checking for smp/AttributeCertificateDefinitions.h... no checking for open in -lcmlasn... no checking for open in -lm... (cached) yes checking for open in -lnsl... no checking for X... (cached) libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... (cached) yes checking for connect... (cached) yes checking for remove... (cached) yes checking for shmat... (cached) yes checking for IceConnectionNumber in -lICE... (cached) yes checking for open in -lsocket... no checking for open in -lbsd... no checking for open in -lelf... no checking for open in -ldl... no checking for open in -ldld... no checking for open in -lld... no checking for open in -lcrypto... yes checking for open in -lssl... yes checking for open in -lncurses... yes checking for readline in -lreadline... yes checking for ANSI C header files... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/select.h... (cached) yes checking for strings.h... (cached) yes checking for float.h... (cached) yes checking for ieeefp.h... yes checking for sys/un.h... (cached) yes checking for netinet/in.h... (cached) yes checking for arpa/inet.h... (cached) yes checking for netdb.h... (cached) yes checking for dlfcn.h... (cached) yes checking for dl.h... no checking for netinet/tcp.h... (cached) yes checking for stdlib.h... (cached) yes checking for sys/time.h... (cached) yes checking for sunmath.h... no checking for sys/stat.h... (cached) yes checking for poll.h... (cached) yes checking for exception... yes checking for exception.h... no checking for terminate.h... no checking for openssl/ssl.h... (cached) yes checking for pgsql/libpq-fe.h... no checking for qapplication.h... no checking for qsocketnotifier.h... no checking for qlineedit.h... no checking for byteorder.h... no checking for iostream... yes checking for map... yes checking for string... yes checking for sstream... yes checking for Ansi C++ headers... yes checking for cxxabi.h... yes checking for
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2016/03/10 02:57:19 Modified files: net/isc-bind : Tag: OPENBSD_5_8 Makefile distinfo Log message: update to BIND 9.10.3-P4 https://kb.isc.org/article/AA-01363/81/BIND-9.10.3-P4-Release-Notes.html
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2016/03/10 02:38:08 Modified files: www/py-django/lts: Tag: OPENBSD_5_8 Makefile distinfo www/py-django/lts/pkg: Tag: OPENBSD_5_8 PLIST Log message: security fixes for https://www.djangoproject.com/weblog/2016/mar/01/security-releases/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2016/03/10 02:31:07 Modified files: www/py-django/lts: Makefile distinfo www/py-django/lts/pkg: PLIST www/py-django/stable: Makefile distinfo www/py-django/stable/pkg: PLIST Log message: security updates to latest releases, addressing https://www.djangoproject.com/weblog/2016/mar/01/security-releases/ ok rpointel@ (MAINTAINER)
UPDATE: net/py-ripe.atlas.tools to 1.2.3 (including cousteau and sagan lib update)
these need to go in together, older tools fails with newer libs. works for me[tm] OK? diff --git py-ripe.atlas.cousteau/Makefile py-ripe.atlas.cousteau/Makefile index acc68d4..80344b5 100644 --- py-ripe.atlas.cousteau/Makefile +++ py-ripe.atlas.cousteau/Makefile @@ -2,7 +2,7 @@ COMMENT = python bindings for the RIPE Atlas API -MODPY_EGG_VERSION =1.0.7 +MODPY_EGG_VERSION =1.2 DISTNAME = ripe.atlas.cousteau-${MODPY_EGG_VERSION} PKGNAME = py-${DISTNAME} diff --git py-ripe.atlas.cousteau/distinfo py-ripe.atlas.cousteau/distinfo index 8e61e15..22169dd 100644 --- py-ripe.atlas.cousteau/distinfo +++ py-ripe.atlas.cousteau/distinfo @@ -1,2 +1,2 @@ -SHA256 (ripe.atlas.cousteau-1.0.7.tar.gz) = T5mr+emFEJF0vF2uOOlY38hdxBqHK7+RZ2Oh9TqeS2s= -SIZE (ripe.atlas.cousteau-1.0.7.tar.gz) = 45757 +SHA256 (ripe.atlas.cousteau-1.2.tar.gz) = C07VFkePtqniJo3GjsqGcilh7EIJ+eVP43VkdlxWAl4= +SIZE (ripe.atlas.cousteau-1.2.tar.gz) = 47015 diff --git py-ripe.atlas.cousteau/pkg/PLIST py-ripe.atlas.cousteau/pkg/PLIST index dfdbe83..491c6a7 100644 --- py-ripe.atlas.cousteau/pkg/PLIST +++ py-ripe.atlas.cousteau/pkg/PLIST @@ -13,6 +13,10 @@ lib/python${MODPY_VERSION}/site-packages/ripe/atlas/ lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/ lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/__init__.py lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/__init__.pyc +lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_listing.py +lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_listing.pyc +lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_meta_data.py +lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/api_meta_data.pyc lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/exceptions.py lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/exceptions.pyc lib/python${MODPY_VERSION}/site-packages/ripe/atlas/cousteau/measurement.py diff --git py-ripe.atlas.sagan/Makefile py-ripe.atlas.sagan/Makefile index ad483c9..e37327f 100644 --- py-ripe.atlas.sagan/Makefile +++ py-ripe.atlas.sagan/Makefile @@ -2,7 +2,7 @@ COMMENT = parsing library for RIPE Atlas measurement results -MODPY_EGG_VERSION =1.1.8 +MODPY_EGG_VERSION =1.1.10 DISTNAME = ripe.atlas.sagan-${MODPY_EGG_VERSION} PKGNAME = py-${DISTNAME} diff --git py-ripe.atlas.sagan/distinfo py-ripe.atlas.sagan/distinfo index c9d3147..7bc6427 100644 --- py-ripe.atlas.sagan/distinfo +++ py-ripe.atlas.sagan/distinfo @@ -1,2 +1,2 @@ -SHA256 (ripe.atlas.sagan-1.1.8.tar.gz) = uzlPc4VwsLDBgleFa2HHMDddkZlsjHJvnc02f9YYs9g= -SIZE (ripe.atlas.sagan-1.1.8.tar.gz) = 100037 +SHA256 (ripe.atlas.sagan-1.1.10.tar.gz) = ODG/K8ZhiMV2Sz0LPA5Th7PWcNCog57UZKJExv/lKIs= +SIZE (ripe.atlas.sagan-1.1.10.tar.gz) = 128425 diff --git py-ripe.atlas.sagan/pkg/PLIST py-ripe.atlas.sagan/pkg/PLIST index ad74ae6..100e1f1 100644 --- py-ripe.atlas.sagan/pkg/PLIST +++ py-ripe.atlas.sagan/pkg/PLIST @@ -1,5 +1,4 @@ @comment $OpenBSD: PLIST,v 1.2 2016/01/20 09:25:03 florian Exp $ -bin/parse_abuf lib/python${MODPY_VERSION}/site-packages/ripe/ lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}-nspkg.pth lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/ @@ -7,7 +6,6 @@ lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-p lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/namespace_packages.txt -lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/pbr.json lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt lib/python${MODPY_VERSION}/site-packages/ripe.atlas.sagan-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt lib/python${MODPY_VERSION}/site-packages/ripe/atlas/ diff --git py-ripe.atlas.tools/Makefile py-ripe.atlas.tools/Makefile index be6c4cd..26e455c 100644 --- py-ripe.atlas.tools/Makefile +++ py-ripe.atlas.tools/Makefile @@ -2,7 +2,7 @@ COMMENT = official command-line client for RIPE Atlas -MODPY_EGG_VERSION =1.2.2 +MODPY_EGG_VERSION =1.2.3 DISTNAME = ripe.atlas.tools-${MODPY_EGG_VERSION} PKGNAME = py-${DISTNAME} diff --git py-ripe.atlas.tools/distinfo py-ripe.atlas.tools/distinfo index 59c6106..c624af7 100644 --- py-ripe.atlas.tools/distinfo +++ py-ripe.atlas.tools/distinfo @@ -1,2 +1,2 @@ -SHA256 (ripe.atlas.tools-1.2.2.tar.gz) = k/htEXez3E3ZrInwi3fYCPCTFQpbCvsDUbMKYoJRoqA= -SIZE
UPDATE: net/py-websocket-client to 0.35.0
tested with upcomming py-ripe.atlas.tools OK? diff --git py-websocket-client/Makefile py-websocket-client/Makefile index 9f9019e..2fed175 100644 --- py-websocket-client/Makefile +++ py-websocket-client/Makefile @@ -2,7 +2,7 @@ COMMENT = WebSocket client for Python -MODPY_EGG_VERSION =0.34.0 +MODPY_EGG_VERSION =0.35.0 REVISION = 0 DISTNAME = websocket_client-${MODPY_EGG_VERSION} PKGNAME = py-websocket-client-${MODPY_EGG_VERSION} diff --git py-websocket-client/distinfo py-websocket-client/distinfo index c46c5aa..a1b2f68 100644 --- py-websocket-client/distinfo +++ py-websocket-client/distinfo @@ -1,2 +1,2 @@ -SHA256 (websocket_client-0.34.0.tar.gz) = aCpiQcqVNJnwbKUG9pqj6ibw7SpB/nmCcyy4RJrpLd8= -SIZE (websocket_client-0.34.0.tar.gz) = 193141 +SHA256 (websocket_client-0.35.0.tar.gz) = WsPq0JG+F7aAoN2pJq7xppeits8emsD75L/7FJFMIRY= +SIZE (websocket_client-0.35.0.tar.gz) = 193509 -- I'm not entirely sure you are real.
Re: libotr security fix
On Wed, Mar 09, 2016 at 05:32:47PM -0800, Michael McConville wrote: > Is anyone working on updates for security/libotr and > security/pidgin-otr? There were releases addressing a scary > vulnerability this morning: > > https://marc.info/?l=otr-announce=145754687614832=2 > > If not, I probably have time to work on it tonight. These should be updated, but there's no reason to hurry up very very much. The libotr problem depends on malloc(0) returning a pointer that doesn't segfault when it is used. On OpenBSD the program will crash at the point where the attacker tries to overwrite the heap. Unless there's another avenue for this exploit which doesn't use malloc(0), but the advisory only mentions malloc(0). See http://seclists.org/oss-sec/2016/q1/568 security/pidgin-otr has been already patched in our ports tree by me in 2015 (before 5.8). I reported this bug and they left it sit for 9 months until Hanno Boeck reported the same problem again: https://bugs.otr.im/issues/88 pidgin-otr crashed on OpenBSD immediately, which is why I noticed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ki...@cvs.openbsd.org 2016/03/10 01:40:05 Modified files: www/goaccess : Makefile distinfo www/goaccess/patches: patch-configure_ac Log message: update to goaccess-0.9.8
dpb: Problem building ports whose RUN_DEPENDS have unmet BUILD_DEPENDS dependencies
Hi, Quite often, dpb fails to build ports because one or several BUILD_DEPENDS for some of the port's RUN_DEPENDS are not installed. Sometimes, this happens after I run "pkg_delete -a", and sometimes I think it's due to the "junking" of unneeded ports during the build (but I'm not sure). This happened just now, for example. The llvm port is definitely up to date, so py-sphinx shouldn't need to be installed, but chromium fails to build anyway: $ less /usr/ports/logs/amd64/packages/chromium-49.0.2623.75p0.log >>> Building on localhost under www/chromium BDEPENDS = [devel/yasm;archivers/xz;shells/bash;lang/python/2.7;devel/gconf2;devel/gperf;lang/gcc/4.9,-c++;devel/llvm;security/nss;sysutils/flock;x11/gtk+2;x11/gnome/libgnome-keyring;devel/ninja;devel/libexecinfo;print/cups,-libs;sysutils/pciutils;textproc/libxslt;lang/gcc/4.9,-libs;devel/bison;archivers/bzip2] DIST = [www/chromium:chromium-49.0.2623.75.tar.xz] FULLPKGNAME = chromium-49.0.2623.75p0 RDEPENDS = [x11/gtk+2;lang/gcc/4.9,-libs;textproc/libxslt;x11/gtk+3,-guic;security/nss;print/cups,-libs;devel/gconf2;graphics/libexif;devel/desktop-file-utils;devel/libexecinfo;devel/xdg-utils;fonts/noto/fonts;x11/gnome/libgnome-keyring] >>> Running clean in www/chromium at 1457594571 ===> www/chromium ===> Cleaning for chromium-49.0.2623.75p0 [...] ===> Returning to build of chromium-49.0.2623.75p0 ===> chromium-49.0.2623.75p0 depends on: g++->=4.9,<4.10 -> g++-4.9.3p3 ===> Verifying update for llvm->=3.7.1 in devel/llvm ===> Updating for llvm-3.7.1p0 ===> llvm-3.7.1p0 depends on: py-sphinx-* - not found Dependency check failed *** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:2114 '/srv/ports/pobj/llvm-3.7.1/.dep-textproc-py-sphinx') *** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:1987 '/srv/ports/update/amd64/llvm-3.7.1p0') *** Error 1 in devel/llvm (/srv/ports/infrastructure/mk/bsd.port.mk:2482 'subupdate') *** Error 1 in www/chromium (/srv/ports/infrastructure/mk/bsd.port.mk:2114 '/srv/ports/pobj/chromium-49.0.2623.75/.dep-STEM-ge-3.7.1-devel-llvm') *** Error 1 in www/chromium (/srv/ports/infrastructure/mk/bsd.port.mk:2482 'prepare') ===> Exiting www/chromium with an error *** Error 1 in /srv/ports (infrastructure/mk/bsd.port.subdir.mk:147 'show-prepare-results') (Junk lock released for localhost at 1457594593) Error: job failed 256 The ffmpeg port build failed in a similar way for exactly the same reason. Cheers, -- Andreas Kusalananda Kähäri, Bioinformatics Developer, Uppsala, Sweden OpenPGP: url=https://db.tt/2zaB1E7y; id=46082BDF