Re: [UPDATE] graphics/p5-Image-ExifTool

[patrick keshishian]

Hi,

Thanks for the update and I'm sorry I've not been able to keep updated
with this small task. Unfortunately circumstances dictate that I
remove myself as maintainer and allow someone else to take over.

cheers,
--patrick

On 6/12/18, Remi Pointel  wrote:
> Hi,
>
> attached is the diff to update exiftool to latest release.
>
> Ok?
>
> Cheers,
>
> Remi.

Re: NEW graphics/exiftool

[patrick keshishian]

Not suggesting my opinion counts on this, but when I first sent in
this port (years ago), I was told to use CPAN releases only. Then
somewhat recently (maybe a year or so ago), I was told go with latest
version even if not on CPAN (i.e. author's releases).

Maybe there should be an official guideline stating OBSD's preferred
position on this.

-pk

On 3/13/18, Stuart Henderson  wrote:
> On 2018/03/13 12:20, George Rosamond wrote:
>> Giovanni Bechis:
>> > On 03/02/18 17:02, George Rosamond wrote:
>> >> Giovanni Bechis:
>> >>> On 03/02/18 16:31, George Rosamond wrote:
>>  Attached is exiftool-10.82:
>> 
>> >>> Hi, exiftool lives in graphics/p5-Image-ExifTool,
>> >>> if you want to update it, you are welcome.
>> >>>  Thanks
>> >>>   Giovanni
>> >>
>> >> Thanks Giovanni, was confused since it's both a Perl module and a
>> >> stand-alone application.
>> >>
>> >> CC'g MAINTAINER.
>> >>
>> >> Diff updating to 10.82 attached.
>> >>
>> >> Changes:
>> >>
>> >> distinfo
>> >> version bump in Makefile
>> >> wrapped pkg/DESCR at 80 characters
>> >> a few PLIST additions
>> >>
>> >> g
>> >>
>> > There is no 10.82 version on Cpan, I would rather update to 10.80
>> > instead.
>> >  ok ?
>>
>> Yes, in cpan it's 10.80.
>>
>> FWIW, the port's Makefile is using the author's www and distfile, which
>> just bumped to 10.84 yesterday. My diff was based on the author's www.
>>
>> If it's going to stick with the cpan version, should it also use cpan
>> for the distfile?
>
> "Note: The most recent production release is Version 10.80.
> (Other versions are considered development releases, and are
> not uploaded to CPAN.)"
>
> 10.80 is the right version to use. I think MASTER_SITES is ok like it is
> (using cpan with author's site as a second option).
>
>

Re: NEW graphics/exiftool

[patrick keshishian]

Looks OK to me.
Sorry for the delay in reply.
--patrick

On 3/2/18, George Rosamond  wrote:
> Giovanni Bechis:
>> On 03/02/18 16:31, George Rosamond wrote:
>>> Attached is exiftool-10.82:
>>>
>> Hi, exiftool lives in graphics/p5-Image-ExifTool,
>> if you want to update it, you are welcome.
>>  Thanks
>>   Giovanni
>
> Thanks Giovanni, was confused since it's both a Perl module and a
> stand-alone application.
>
> CC'g MAINTAINER.
>
> Diff updating to 10.82 attached.
>
> Changes:
>
> distinfo
> version bump in Makefile
> wrapped pkg/DESCR at 80 characters
> a few PLIST additions
>
> g
>
>

[update] graphics/p5-Image-ExifTool

[patrick keshishian]

Update: 10.40 -> 10.50

Some highlights:
- Read JSON files
- Read/write MacOS system tags


Full change list:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-10.50/Changes
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.40
diff -u -p -u -p -r1.40 Makefile
--- Makefile18 Mar 2017 10:12:45 -  1.40
+++ Makefile19 May 2017 21:44:56 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-10.40
+DISTNAME=  Image-ExifTool-10.50
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.33
diff -u -p -u -p -r1.33 distinfo
--- distinfo18 Mar 2017 10:12:45 -  1.33
+++ distinfo19 May 2017 21:44:56 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-10.40.tar.gz) = 
njYZ4vnIOLN/Z6tV/VQbVHKzKNX0ZEaEQjZykmZqBdw=
-SIZE (Image-ExifTool-10.40.tar.gz) = 4220341
+SHA256 (Image-ExifTool-10.50.tar.gz) = 
M53Y93H2c/1sRI9KSzbPUP6OO/iE2pWu9s7B0YLAiFs=
+SIZE (Image-ExifTool-10.50.tar.gz) = 4247879
Index: pkg/PLIST
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 PLIST
--- pkg/PLIST   18 Mar 2017 10:12:45 -  1.28
+++ pkg/PLIST   19 May 2017 21:44:57 -
@@ -95,6 +95,7 @@ ${P5SITE}/Image/ExifTool/Import.pm
 ${P5SITE}/Image/ExifTool/InDesign.pm
 ${P5SITE}/Image/ExifTool/JPEG.pm
 ${P5SITE}/Image/ExifTool/JPEGDigest.pm
+${P5SITE}/Image/ExifTool/JSON.pm
 ${P5SITE}/Image/ExifTool/JVC.pm
 ${P5SITE}/Image/ExifTool/Jpeg2000.pm
 ${P5SITE}/Image/ExifTool/Kodak.pm
@@ -131,6 +132,7 @@ ${P5SITE}/Image/ExifTool/MPEG.pm
 ${P5SITE}/Image/ExifTool/MPF.pm
 ${P5SITE}/Image/ExifTool/MWG.pm
 ${P5SITE}/Image/ExifTool/MXF.pm
+${P5SITE}/Image/ExifTool/MacOS.pm
 ${P5SITE}/Image/ExifTool/MakerNotes.pm
 ${P5SITE}/Image/ExifTool/Matroska.pm
 ${P5SITE}/Image/ExifTool/Microsoft.pm
@@ -192,6 +194,7 @@ ${P5SITE}/Image/ExifTool/Theora.pm
 ${P5SITE}/Image/ExifTool/Torrent.pm
 ${P5SITE}/Image/ExifTool/Unknown.pm
 ${P5SITE}/Image/ExifTool/VCard.pm
+${P5SITE}/Image/ExifTool/Validate.pm
 ${P5SITE}/Image/ExifTool/Vorbis.pm
 ${P5SITE}/Image/ExifTool/WriteCanonRaw.pl
 ${P5SITE}/Image/ExifTool/WriteExif.pl
@@ -268,6 +271,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::InDesign.3p
 @man man/man3p/Image::ExifTool::JPEG.3p
 @man man/man3p/Image::ExifTool::JPEGDigest.3p
+@man man/man3p/Image::ExifTool::JSON.3p
 @man man/man3p/Image::ExifTool::JVC.3p
 @man man/man3p/Image::ExifTool::Jpeg2000.3p
 @man man/man3p/Image::ExifTool::Kodak.3p
@@ -303,6 +307,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::MPF.3p
 @man man/man3p/Image::ExifTool::MWG.3p
 @man man/man3p/Image::ExifTool::MXF.3p
+@man man/man3p/Image::ExifTool::MacOS.3p
 @man man/man3p/Image::ExifTool::MakerNotes.3p
 @man man/man3p/Image::ExifTool::Matroska.3p
 @man man/man3p/Image::ExifTool::Microsoft.3p
@@ -363,6 +368,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Torrent.3p
 @man man/man3p/Image::ExifTool::Unknown.3p
 @man man/man3p/Image::ExifTool::VCard.3p
+@man man/man3p/Image::ExifTool::Validate.3p
 @man man/man3p/Image::ExifTool::Vorbis.3p
 @man man/man3p/Image::ExifTool::WriteCanonRaw.3p
 @man man/man3p/Image::ExifTool::WriteExif.3p

[update] graphics/p5-Image-ExifTool

[patrick keshishian]

Simple update: Image-ExifTool-10.20 -> 10.40

Lightly tested on amd64.

Added support for:
 - BPG (Better Portable Graphics)
 - DJI Phantom drones image maker notes
 - FLIF (Free Lossless Image Format)
 - extracting Ogg Opus audio file meta info

Full change list:
http://search.cpan.org/src/EXIFTOOL/Image-ExifTool-10.40/Changes
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.39
diff -u -p -u -p -r1.39 Makefile
--- Makefile27 Jun 2016 09:05:05 -  1.39
+++ Makefile18 Mar 2017 04:42:35 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-10.20
+DISTNAME=  Image-ExifTool-10.40
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 distinfo
--- distinfo27 Jun 2016 09:05:05 -  1.32
+++ distinfo18 Mar 2017 04:42:35 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-10.20.tar.gz) = 
8GriAJUM0/RB8g91MhYzZZZapFqR2WEUZysOsXa3bSo=
-SIZE (Image-ExifTool-10.20.tar.gz) = 4142166
+SHA256 (Image-ExifTool-10.40.tar.gz) = 
njYZ4vnIOLN/Z6tV/VQbVHKzKNX0ZEaEQjZykmZqBdw=
+SIZE (Image-ExifTool-10.40.tar.gz) = 4220341
Index: pkg/PLIST
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 PLIST
--- pkg/PLIST   27 Jun 2016 09:05:05 -  1.27
+++ pkg/PLIST   18 Mar 2017 04:42:35 -
@@ -16,6 +16,7 @@ ${P5SITE}/Image/ExifTool/ASF.pm
 ${P5SITE}/Image/ExifTool/Apple.pm
 ${P5SITE}/Image/ExifTool/Audible.pm
 ${P5SITE}/Image/ExifTool/BMP.pm
+${P5SITE}/Image/ExifTool/BPG.pm
 ${P5SITE}/Image/ExifTool/BZZ.pm
 ${P5SITE}/Image/ExifTool/BigTIFF.pm
 ${P5SITE}/Image/ExifTool/BuildTagLookup.pm
@@ -58,6 +59,7 @@ ${P5SITE}/Image/ExifTool/Charset/Thai.pm
 ${P5SITE}/Image/ExifTool/Charset/Turkish.pm
 ${P5SITE}/Image/ExifTool/Charset/Vietnam.pm
 ${P5SITE}/Image/ExifTool/DICOM.pm
+${P5SITE}/Image/ExifTool/DJI.pm
 ${P5SITE}/Image/ExifTool/DNG.pm
 ${P5SITE}/Image/ExifTool/DPX.pm
 ${P5SITE}/Image/ExifTool/DV.pm
@@ -66,6 +68,7 @@ ${P5SITE}/Image/ExifTool/DjVu.pm
 ${P5SITE}/Image/ExifTool/EXE.pm
 ${P5SITE}/Image/ExifTool/Exif.pm
 ${P5SITE}/Image/ExifTool/FLAC.pm
+${P5SITE}/Image/ExifTool/FLIF.pm
 ${P5SITE}/Image/ExifTool/FLIR.pm
 ${P5SITE}/Image/ExifTool/Fixup.pm
 ${P5SITE}/Image/ExifTool/Flash.pm
@@ -142,6 +145,7 @@ ${P5SITE}/Image/ExifTool/OOXML.pm
 ${P5SITE}/Image/ExifTool/Ogg.pm
 ${P5SITE}/Image/ExifTool/Olympus.pm
 ${P5SITE}/Image/ExifTool/OpenEXR.pm
+${P5SITE}/Image/ExifTool/Opus.pm
 ${P5SITE}/Image/ExifTool/PDF.pm
 ${P5SITE}/Image/ExifTool/PGF.pm
 ${P5SITE}/Image/ExifTool/PICT.pm
@@ -216,6 +220,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Apple.3p
 @man man/man3p/Image::ExifTool::Audible.3p
 @man man/man3p/Image::ExifTool::BMP.3p
+@man man/man3p/Image::ExifTool::BPG.3p
 @man man/man3p/Image::ExifTool::BZZ.3p
 @man man/man3p/Image::ExifTool::BigTIFF.3p
 @man man/man3p/Image::ExifTool::BuildTagLookup.3p
@@ -227,6 +232,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Casio.3p
 @man man/man3p/Image::ExifTool::Charset.3p
 @man man/man3p/Image::ExifTool::DICOM.3p
+@man man/man3p/Image::ExifTool::DJI.3p
 @man man/man3p/Image::ExifTool::DNG.3p
 @man man/man3p/Image::ExifTool::DPX.3p
 @man man/man3p/Image::ExifTool::DV.3p
@@ -235,6 +241,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::EXE.3p
 @man man/man3p/Image::ExifTool::Exif.3p
 @man man/man3p/Image::ExifTool::FLAC.3p
+@man man/man3p/Image::ExifTool::FLIF.3p
 @man man/man3p/Image::ExifTool::FLIR.3p
 @man man/man3p/Image::ExifTool::Fixup.3p
 @man man/man3p/Image::ExifTool::Flash.3p
@@ -310,6 +317,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Ogg.3p
 @man man/man3p/Image::ExifTool::Olympus.3p
 @man man/man3p/Image::ExifTool::OpenEXR.3p
+@man man/man3p/Image::ExifTool::Opus.3p
 @man man/man3p/Image::ExifTool::PDF.3p
 @man man/man3p/Image::ExifTool::PGF.3p
 @man man/man3p/Image::ExifTool::PICT.3p

error: Can't call method "is_signed" on an undefined

[patrick keshishian]

Hi,

This is on a current system (fresh install):

# sysctl kern.version
kern.version=OpenBSD 6.0-current (GENERIC.MP) #2510: Fri Sep 30
09:49:52 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


I am trying to build some ports using dpb(1).

All dependency packages built by dpb(1) required for further builds
are installed fine by the "workflow".

# pkg_info -L yasm
Information for inst:yasm-1.3.0p1

Files:
/usr/local/bin/vsyasm
/usr/local/bin/yasm
/usr/local/bin/ytasm
...
/usr/local/man/man7/yasm_objfmts.7
/usr/local/man/man7/yasm_parsers.7
# echo $?
0


However, other packages built but not installed by the dpb(1)
(workflow) seem to cause issues with the system pkg_* tools:

# pkg_info -L xpdf
Error from file:./xpdf-3.04p1.tgz
unsigned package
Can't call method "is_signed" on an undefined value at
/usr/libdata/perl5/OpenBSD/PkgInfo.pm line 392.


Above reference to "is_signed" makes me wonder if this is a fallout
from Espie's change(s)[1]


# pkg_info -L ./xpdf-3.04p1.tgz
# echo $?
1


Even for yasm, if I point pkg_info to the tgz file, supposed source of
the installed package, acts "funny":

# pkg_info -L ./yasm-1.3.0p1.tgz
# echo $?
1


Here is how pkg_add(1) reacts:

# pkg_add - ./xpdf-3.04p1.tgz
Can't find ./xpdf-3.04p1.tgz
Can't load quirk: Can't locate OpenBSD/Quirks.pm in @INC (you may need
to install the OpenBSD::Quirks module) (@INC contains:
/usr/local/libdata/perl5/site_perl/amd64-openbsd
/usr/libdata/perl5/site_perl/amd64-openbsd
/usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl
/usr/libdata/perl5/amd64-openbsd/5.20.3
/usr/local/libdata/perl5/amd64-openbsd/5.20.3 /usr/libdata/perl5
/usr/local/libdata/perl5 .) at /usr/libdata/perl5/OpenBSD/AddDelete.pm
line 280.

--- xpdf-3.04p1 ---
Can't install xpdf-3.04p1: not found



Any hints as to what I may be doing wrong here would be appreciated.

--patrick

[1] http://marc.info/?l=openbsd-tech=147336351812365=2

strange build failure with llvm

[patrick keshishian]

Hello,

I'm just curious if this type of failures have been seen by those
doing bulk builds?

The full log file is about 4MB. I don't mind sharing, but it is
uninteresting except for these lines (let me know if you want it).

System is  Supermicro X7SPA-HF (atom) processor
Running cvs updated OPENBSD_6_0 on 2016/09/27 (dmesg sent to dmesg@)


Using dpb(1) to build some package when llvm failed like so:


[1413/2511] cd /usr/build/ports/pobj/llvm-3.8.0/build-amd64/lib/Target/Mips
&& /usr/build/ports/pobj/llvm-3.8.0/build-amd64/bin/llvm-tblgen
-gen-asm-matcher -I
/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips -I
/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target -I
/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/include
/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips/Mips.td
-o 
/usr/build/ports/pobj/llvm-3.8.0/build-amd64/lib/Target/Mips/MipsGenAsmMatcher.inc.tmp
[1414/2511] cd /usr/build/ports/pobj/llvm-3.8.0/build-amd64/lib/Target/Mips
&& /usr/local/bin/cmake -E copy_if_different
/usr/build/ports/pobj/llvm-3.8.0/build-amd64/lib/Target/Mips/MipsGenAsmMatcher.inc.tmp
/usr/build/ports/pobj/llvm-3.8.0/build-amd64/lib/Target/Mips/MipsGenAsmMatcher.inc
[...]
[1870/2511] /usr/build/ports/pobj/llvm-3.8.0/bin/c++
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Ilib/Target/Mips/AsmParser
-I/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips/AsmParser
-I/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips
-Ilib/Target/Mips -Iinclude
-I/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/include -O2 -pipe
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor
-Wno-comment -std=c++11 -ffunction-sections -fdata-sections -DNDEBUG
 -fno-exceptions -MMD -MT
lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o
-MF 
lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o.d
-o 
lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o
-c 
/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips/AsmParser/MipsAsmParser.cpp
FAILED: 
lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o
/usr/build/ports/pobj/llvm-3.8.0/bin/c++   -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Ilib/Target/Mips/AsmParser
-I/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips/AsmParser
-I/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips
-Ilib/Target/Mips -Iinclude
-I/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/include -O2 -pipe
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor
-Wno-comment -std=c++11 -ffunction-sections -fdata-sections -DNDEBUG
 -fno-exceptions -MMD -MT
lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o
-MF 
lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o.d
-o 
lib/Target/Mips/AsmParser/CMakeFiles/LLVMMipsAsmParser.dir/MipsAsmParser.cpp.o
-c 
/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips/AsmParser/MipsAsmParser.cpp
In file included from
/usr/build/ports/pobj/llvm-3.8.0/llvm-3.8.0.src/lib/Target/Mips/AsmParser/MipsAsmParser.cpp:6204:0:
lib/Target/Mips/MipsGenAsmMatcher.inc: In function 'unsigned int
validateOperandClass(llvm::MCParsedAsmOperand&,
{anonymous}::MatchClassKind)':
lib/Target/Mips/MipsGenAsmMatcher.inc:2526:47: error: 'bbeak' was not
declared in this scope
 case Mips::W4: OpKind = MCK_MSA128WEvens; bbeak;
   ^


Observations:
1. MipsGenAsmMatcher.inc seems to be a generated file.
2. obviously "bbeak" is supposed to be "break"
3. interesting b=0x62 and r=0x72 one bit-flip difference.

Cosmic rays?

Restarting the build completed successfully.

--patrick

[update] graphics/p5-Image-ExifTool

[patrick keshishian]

update: 10.10 -> 10.20

full change log:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-10.20/Changes

thanks,
--patrick
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.38
diff -u -p -u -p -r1.38 Makefile
--- Makefile26 Apr 2016 13:16:42 -  1.38
+++ Makefile25 Jun 2016 16:22:40 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-10.10
+DISTNAME=  Image-ExifTool-10.20
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 distinfo
--- distinfo26 Apr 2016 13:16:42 -  1.31
+++ distinfo25 Jun 2016 16:22:40 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-10.10.tar.gz) = 
+fzs+JVM/WsfVljh/IKAHouY+JHIimCtvWvFxxZHHgk=
-SIZE (Image-ExifTool-10.10.tar.gz) = 4056189
+SHA256 (Image-ExifTool-10.20.tar.gz) = 
8GriAJUM0/RB8g91MhYzZZZapFqR2WEUZysOsXa3bSo=
+SIZE (Image-ExifTool-10.20.tar.gz) = 4142166
Index: pkg/PLIST
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 PLIST
--- pkg/PLIST   26 Apr 2016 13:16:42 -  1.26
+++ pkg/PLIST   25 Jun 2016 16:22:40 -
@@ -86,6 +86,7 @@ ${P5SITE}/Image/ExifTool/HtmlDump.pm
 ${P5SITE}/Image/ExifTool/ICC_Profile.pm
 ${P5SITE}/Image/ExifTool/ID3.pm
 ${P5SITE}/Image/ExifTool/IPTC.pm
+${P5SITE}/Image/ExifTool/ISO.pm
 ${P5SITE}/Image/ExifTool/ITC.pm
 ${P5SITE}/Image/ExifTool/Import.pm
 ${P5SITE}/Image/ExifTool/InDesign.pm
@@ -145,6 +146,7 @@ ${P5SITE}/Image/ExifTool/PDF.pm
 ${P5SITE}/Image/ExifTool/PGF.pm
 ${P5SITE}/Image/ExifTool/PICT.pm
 ${P5SITE}/Image/ExifTool/PLIST.pm
+${P5SITE}/Image/ExifTool/PLUS.pm
 ${P5SITE}/Image/ExifTool/PNG.pm
 ${P5SITE}/Image/ExifTool/PPM.pm
 ${P5SITE}/Image/ExifTool/PSP.pm
@@ -253,6 +255,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::ICC_Profile.3p
 @man man/man3p/Image::ExifTool::ID3.3p
 @man man/man3p/Image::ExifTool::IPTC.3p
+@man man/man3p/Image::ExifTool::ISO.3p
 @man man/man3p/Image::ExifTool::ITC.3p
 @man man/man3p/Image::ExifTool::Import.3p
 @man man/man3p/Image::ExifTool::InDesign.3p
@@ -311,6 +314,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::PGF.3p
 @man man/man3p/Image::ExifTool::PICT.3p
 @man man/man3p/Image::ExifTool::PLIST.3p
+@man man/man3p/Image::ExifTool::PLUS.3p
 @man man/man3p/Image::ExifTool::PNG.3p
 @man man/man3p/Image::ExifTool::PPM.3p
 @man man/man3p/Image::ExifTool::PSP.3p

Re: fonts/terminus-font: Add `centered_tilde' flavor

[patrick keshishian]

On 4/23/16, Michael Reed  wrote:
> On 04/23/16 19:12, Christian Weisgerber wrote:
>> On 2016-04-23, Michael Reed  wrote:
>>
>>> -FLAVORS =  symquotes
>>> +FLAVORS =  symquotes centered_tilde
>>>   FLAVOR ?=
>>
>> This (implicitly) allows combining the flavors...
>>
>>>   .if ${FLAVOR:Msymquotes}
>>>   post-patch:
>>> ${PATCH} -d ${WRKSRC} < ${WRKSRC}/alt/gq2.diff
>>> +.elif ${FLAVOR:Mcentered_tilde}
>>> +post-patch:
>>> +   ${PATCH} -d ${WRKSRC} < ${WRKSRC}/alt/td1.diff
>>>   .endif
>>
>> ... but this doesn't.
>>
>
> Indeed, Patrick just pointed that out.  New patch is attached.

After sending my reply, i realized that to allow both flavors at
the same time, the post-patch needs to be a bit more sophisticated.
Not sure if make will like two targets with the same name if both
flavors are specified during make.

something like attached seems to work allowing both flavors
at the same time.

--patrick

> In the patch, I explicitly mention the compound flavor; should that be
> done?
Index: Makefile
===
RCS file: /cvs/obsd/ports/fonts/terminus-font/Makefile,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 Makefile
--- Makefile13 Nov 2015 20:18:25 -  1.10
+++ Makefile23 Apr 2016 23:33:32 -
@@ -4,6 +4,7 @@ COMMENT =   fixed width fonts especially 
 
 DISTNAME = terminus-font-4.40
 CATEGORIES =   fonts x11
+REVISION = 0
 
 HOMEPAGE = http://terminus-font.sourceforge.net/
 
@@ -24,12 +25,21 @@ FONTDIR =   ${PREFIX}/share/fonts/terminu
 
 USE_GMAKE =Yes
 
-FLAVORS =  symquotes
+FLAVORS =  symquotes centered_tilde
 FLAVOR ?=
 
 .if ${FLAVOR:Msymquotes}
+FLAVOR_PATCHES += ${WRKSRC}/alt/gq2.diff
+.endif
+.if ${FLAVOR:Mcentered_tilde}
+FLAVOR_PATCHES += ${WRKSRC}/alt/td1.diff
+.endif
+
+.if !empty(FLAVOR_PATCHES)
 post-patch:
-   ${PATCH} -d ${WRKSRC} < ${WRKSRC}/alt/gq2.diff
+   for f in ${FLAVOR_PATCHES} ; do \
+   ${PATCH} -d ${WRKSRC} < $$f ; \
+   done
 .endif
 
 do-install:
Index: pkg/DESCR
===
RCS file: /cvs/obsd/ports/fonts/terminus-font/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 DESCR
--- pkg/DESCR   19 Jul 2011 09:16:08 -  1.1.1.1
+++ pkg/DESCR   23 Apr 2016 23:33:32 -
@@ -2,4 +2,6 @@ The Terminus font is a complete set of f
 especially for the usage in terms.
 
 Flavors:
-   symquotes - Build with symmetric single quotes.
+   symquotes- Build with symmetric single quotes.
+   centered_tilde   - Build with centered ASCII tilde.
+   symquotes-centered_tilde - Build with both modifications.

Re: fonts/terminus-font: Add `centered_tilde' flavor

[patrick keshishian]

On 4/23/16, Michael Reed <m.r...@mykolab.com> wrote:
> On 04/23/16 17:01, patrick keshishian wrote:
>> On 4/23/16, Michael Reed <m.r...@mykolab.com> wrote:
>>> I prefer this variant of terminus, I wonder what others think.
>>
>> Just reading the description of this patch on $HOMEPAGE, I
>> wonder (as the page suggests) if this should be default?
>
> I initially agreed with that because a centered tilde seems to be
> more common in other fonts, and I personally like it more,
> but after some thought I don't think so.
>
> If a user does `pkg_add terminus', I'd think they would expect to
> get the vanilla, unpatched version of Terminus.  If upstream does
> indeed make that the default then so be it, but for now I think a
> separate flavor would be preferable for end-users.
>
> What do you think?

OK by me. Nice to have the flavor now at least.

>> Incidentally, if it remains a FLAVOR, is it mutually exclusive
>> with the symquotes flavor?
>
> If my understanding of flavors is correct, then yes.
>
> Anyway, are you suggesting there be a third flavor, something
> like `symquotes_centered_tilde'?

I was going to say instead of having the .elif ${FLAVOR:Mcentered_tilde}
just have a .if ${FLAVOR:Mcentered_tilde}

and as Stuart replied, evidently you can apply both patches.

Best,
--patrick

Re: fonts/terminus-font: Add `centered_tilde' flavor

[patrick keshishian]

On 4/23/16, Michael Reed  wrote:
> I prefer this variant of terminus, I wonder what others think.

Just reading the description of this patch on $HOMEPAGE, I
wonder (as the page suggests) if this should be default?

Incidentally, if it remains a FLAVOR, is it mutually exclusive
with the symquotes flavor?

--patrick

Re: [wip] Firefox 46.0beta5 & Thunderbird 45.0beta3

[patrick keshishian]

built and works nicely. two minor issues:

1. I noticed the new "button/icon" named "Hello", well, there is no
   image of it showing (see attached screen grab).

2. not really an issue, but with (I assume) gtk+3 switch, web-form
buttons seem gigantic. not too thrilled about them, but I'm sure
i'll survive.

Thanks for your hard work on this!
--patrick


On 4/4/16, Landry Breuil  wrote:
> On Wed, Mar 30, 2016 at 08:35:18AM +0200, Landry Breuil wrote:
>> On Tue, Mar 29, 2016 at 03:38:51PM +, Christian Weisgerber wrote:
>> > On 2016-03-28, Landry Breuil  wrote:
>> >
>> > > https://cgit.rhaalovely.net/mozilla-firefox/?h=beta
>> > > git clone -b beta https://rhaalovely.net/git/mozilla-firefox
>> > >
>> > > If you want to build it you probably need the attached
>> > > mozilla.port.mk
>> > > diff.
>> >
>> > Fails for me:
>> >
>> > /usr/obj/firefox-46.0beta5/firefox-46.0b5/media/ffvpx/libavutil/mem.c:36:10:
>> > fatal error: 'malloc.h' file not found
>> > #include 
>>
>> Ah, yeah, totally forgot about this. Should be handled when
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1239550 is
>> commited/completed. I'll try to figure out what patch chunk needs
>> backporting when i come back.
>
> Fixed locally with
> https://cgit.rhaalovely.net/mozilla-firefox/commit/?h=beta=0bbd84875372e45aad60a3a2d9371a0af6e00884
> built fine on amd64 with malloc.h pruned out..
>
> Landry
>
>

[update] graphics/p5-Image-ExifTool

[patrick keshishian]

no frills update: 10.00 -> 10.10
full change log:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-10.10/Changes

thanks,
--patrick
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.37
diff -u -p -u -p -r1.37 Makefile
--- Makefile20 Mar 2016 19:56:44 -  1.37
+++ Makefile8 Apr 2016 22:04:57 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-10.00
+DISTNAME=  Image-ExifTool-10.10
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 distinfo
--- distinfo11 Sep 2015 11:57:10 -  1.30
+++ distinfo8 Apr 2016 22:04:57 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-10.00.tar.gz) = 
e1czMeujkhtWM5AY6V3V5vWh5GNOT8e62R5XeNo1cfQ=
-SIZE (Image-ExifTool-10.00.tar.gz) = 4013694
+SHA256 (Image-ExifTool-10.10.tar.gz) = 
+fzs+JVM/WsfVljh/IKAHouY+JHIimCtvWvFxxZHHgk=
+SIZE (Image-ExifTool-10.10.tar.gz) = 4056189
Index: pkg/PLIST
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 PLIST
--- pkg/PLIST   11 Sep 2015 11:57:10 -  1.25
+++ pkg/PLIST   8 Apr 2016 22:04:57 -
@@ -132,6 +132,7 @@ ${P5SITE}/Image/ExifTool/Matroska.pm
 ${P5SITE}/Image/ExifTool/Microsoft.pm
 ${P5SITE}/Image/ExifTool/Minolta.pm
 ${P5SITE}/Image/ExifTool/MinoltaRaw.pm
+${P5SITE}/Image/ExifTool/Motorola.pm
 ${P5SITE}/Image/ExifTool/Nikon.pm
 ${P5SITE}/Image/ExifTool/NikonCapture.pm
 ${P5SITE}/Image/ExifTool/NikonCustom.pm
@@ -297,6 +298,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Microsoft.3p
 @man man/man3p/Image::ExifTool::Minolta.3p
 @man man/man3p/Image::ExifTool::MinoltaRaw.3p
+@man man/man3p/Image::ExifTool::Motorola.3p
 @man man/man3p/Image::ExifTool::Nikon.3p
 @man man/man3p/Image::ExifTool::NikonCapture.3p
 @man man/man3p/Image::ExifTool::NikonCustom.3p

Firefox 42.0 cookie exception preference behavior change

[patrick keshishian]

Hi,

Just updated FF from 40 to 42 and first thing I noticed, as I try
to browse a www.postgresql.org link from a google search result,
is that I'm presented with a "wants to set a cookie Allow/Disallow"
dialog. I find this odd, as was sure I had "postgresql.org" domain in
the exception list for allowing cookies.

I look in Privacy->Accept cookies from sites->Exceptions ... setting
and notice that the list has changed format.

Previously, at least up until FF 40, list was of domains, now it is of
URLs. When previously "postgresql.org" was listed, and all its sub-
domains (e.g., www.postgresql.org) were allowed cookie ops, now
list shows http://postgresql.org, which is what I think is disabling
any sub-domains the same privilege they were afforded before.

Anyone else notice this issue? or rather more importantly:
Anyone know how to revert this behavior?


Just to explain my use-case of cookies is as such. Sites I want
to allow cookie-ops, I place their domain in the exception list and
(as mentioned) their sub-domains would be allowed same ops.

This kept the exception list short and manageable.

--patrick

building ffmpeg with systrace

[patrick keshishian]

Just FYI, to build ffmpeg with "USE_SYSTRACE=Yes", I had to have the
following change to systrace.filter[1]; Evidently, due to their config
mechanism change, invoking raise(3).

--patrick


[1]
Index: systrace.filter
===
RCS file: /cvs/obsd/ports/infrastructure/db/systrace.filter,v
retrieving revision 1.50
diff -u -p -u -p -r1.50 systrace.filter
--- systrace.filter 5 Nov 2015 12:10:33 -   1.50
+++ systrace.filter 16 Nov 2015 23:56:09 -
@@ -4,6 +4,7 @@
native-__set_tcb: permit
native-__tfork: permit
native-__threxit: permit
+   native-thrkill: permit
native-__thrsigdivert: permit
native-__thrsleep: permit
native-__thrwakeup: permit

Re: graphics/jasper CVE fixes from Slackware

[patrick keshishian]

ping?

On 10/29/15, patrick keshishian <pkesh...@gmail.com> wrote:
> Slackware just notified of these:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8137
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8138
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8157
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8158
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9029
>
> Summary:
>   CVE-2014-8137: double-free
>   CVE-2014-8138: heap-based buffer overflow
>   CVE-2014-8157: off-by-one
>   CVE-2014-8158: multiple stack-based buffer overflows
>   CVE-2014-9029: multiple off-by-one
>
> Patches from Slackware are available off their ftp site:
>
>   
> ftp://ftp.slackware.com/pub/slackware/slackware64-14.1/patches/source/jasper/patches/
>
>   jasper-CVE-2014-8137.patch.gz   1 KB09/03/1518:54:00
>   jasper-CVE-2014-8138.patch.gz   1 KB09/03/1518:55:00
>   jasper-CVE-2014-8157.patch.gz   1 KB09/03/1518:55:00
>   jasper-CVE-2014-8158.patch.gz   2 KB09/03/1518:56:00
>   jasper-CVE-2014-9029.patch.gz   1 KB09/03/1518:57:00
>
>
> Attached is my attempt to merge above Slackware patches, into
> our jasper port.
>
> Someone more familiar with jasper should double check that I
> didn't screw anything up.
>
> I have a question though, 'pkg_info jasper' claims gimp as a dependent,
> however, 'ldd gimp' doesn't show jasper in the list. What am I missing?
>
> Cheers,
> --patrick
>

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 10/29/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Thu, Sep 24, 2015 at 10:58:43AM -0700, patrick keshishian wrote:
>> On 9/23/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> > On Thu, Sep 24, 2015 at 07:50:15AM +0200, Landry Breuil wrote:
>> >> On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:
>> >> > On 9/19/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> >> > > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian
>> >> > > wrote:
>> >> > >> On 9/17/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> >> > [...]
>> >> > >> Attached is new tar-ball that compile, but unfortunately "make
>> >> > >> test"
>> >> > >> mostly fails[1].
>> >> > >
>> >> > > Yes, but at least it builds :) Lots of ports have failing tests in
>> >> > > the
>> >> > > tree..
>> >> > >
>> >> > >> Most failures are due test DB not existing followed by core dump.
>> >> > >
>> >> > > Hmm, maybe have a look at databases/postgresql MODULE and the
>> >> > > ports
>> >> > > that
>> >> > > use it, the module provides helpers to run/create databases for
>> >> > > testing.
>> >> > >
>> >> > >> One hints of bad option.
>> >> > >
>> >> > > This one is strange..
>> >> > >
>> >> > >> One on Python module import.
>> >> > >
>> >> > > Needs TEST_DEPENDS on databases/py-psycopg2
>> >> >
>> >> > After adding this, the tests which were FAILing change state to
>> >> > SKIP. The error message relating to their SKIP state, indicated
>> >> > PG template0 database encoding was ASCII vs expected UTF8.
>> >> >
>> >> > Patching databases/postgresql/postgresql.port.mk[1] to accept
>> >> > an encoding to be specified in port's Makefile. Now more tests
>> >> > PASS:
>> >> >
>> >> > # TOTAL: 18
>> >> > # PASS:  6
>> >> > # SKIP:  1
>> >> > # XFAIL: 0
>> >> > # FAIL:  11
>> >> > # XPASS: 0
>> >> > # ERROR: 0
>> >> >
>> >> > Those which FAIL claim "Out of memory" (see attached
>> >> > test-suite.log).
>> >>
>> >> What if you bump ulimit -d ?
>> >
>> > Hm, after actually looking at the log, it's coming from the default
>> > value for --cache. When i tried osm2pgsql locally, with the default it
>> > was *always* complaining about this so i had to use a lower value.
>> > Maybe
>> > we should patch out in the code the default cache size so that it's
>> > more
>> > system-friendly, instead of forcing the user to specify it and it
>> > would fix the tests :)
>>
>> Glad you suggested the patch, I wasn't sure if you'd like that
>> idea. My own tests work with "-C 300", anything above fails in
>> different manners; i.e., -C 400 fails more "silently" v -C 500.
>> I am, however, messing about with small .osm files ATM.
>
> Now that postgresql.port.mk allows to run those tests with the correct
> charset, can we get an updated tarball with a patch for the default
> --cache value (and the corresponding discussion brought upstream) ? I'd
> like to import this one this weekend

I haven't had a chance to do this. I'm a bit behind of -current too.
But the project just switched to using Cmake[1], and I've not yet
looked at what I need to do for it wrt our ports tree.

Do you want to import this version or wait for a newer Cmake
one?

--patrick

[1] heads-up announcement:
https://lists.openstreetmap.org/pipermail/dev/2015-October/028786.html
and final change over:
https://lists.openstreetmap.org/pipermail/dev/2015-October/028797.html

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 10/29/15, patrick keshishian <pkesh...@gmail.com> wrote:
> On 10/29/15, Landry Breuil <lan...@rhaalovely.net> wrote:
[snip]
>> Now that postgresql.port.mk allows to run those tests with the correct
>> charset, can we get an updated tarball with a patch for the default
>> --cache value (and the corresponding discussion brought upstream) ? I'd
>> like to import this one this weekend

Per request attached is a new tar-ball that takes more tests
from FAIL to PASS. test-suite.log also attached.

$ cat test-suite.log

   osm2pgsql 0.88.1: ./test-suite.log


# TOTAL: 18
# PASS:  15
# SKIP:  1
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/test-output-pgsql-tablespace


./tests/test-output-pgsql-tablespace:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
test_regression_simple
NOTICE:  database "osm2pgsql-test-13205-1446173215" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-parse-options
==

./tests/test-parse-options:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
test_insufficient_args
terminate called after throwing an instance of 'std::runtime_error'
  what():  Usage error. For further information see:
osm2pgsql -h|--help

Abort trap (core dumped)

SKIP: tests/regression-test
===

Setting up test database
The test needs a temporary tablespace to run in, but it does not
exist. Please create the temporary tablespace. On Linux, you can do
this by running:
  sudo mkdir -p /tmp/psql-tablespace
  sudo /bin/chown postgres.postgres tmp/psql-tablespace
  psql -c "CREATE TABLESPACE tablespacetest LOCATION
'/tmp/psql-tablespace'" postgres
Cleaning up test database




> I haven't had a chance to do this. I'm a bit behind of -current too.
> But the project just switched to using Cmake[1], and I've not yet
> looked at what I need to do for it wrt our ports tree.
>
> Do you want to import this version or wait for a newer Cmake
> one?
>
> --patrick
>
> [1] heads-up announcement:
> https://lists.openstreetmap.org/pipermail/dev/2015-October/028786.html
> and final change over:
> https://lists.openstreetmap.org/pipermail/dev/2015-October/028797.html
>


geo_osm2pgsql.tar.gz
Description: GNU Zip compressed data


test-suite.log
Description: Binary data

graphics/jasper CVE fixes from Slackware

[patrick keshishian]

Slackware just notified of these:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8137
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8138
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8157
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8158
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9029

Summary:
CVE-2014-8137: double-free
CVE-2014-8138: heap-based buffer overflow
CVE-2014-8157: off-by-one
CVE-2014-8158: multiple stack-based buffer overflows
CVE-2014-9029: multiple off-by-one

Patches from Slackware are available off their ftp site:


ftp://ftp.slackware.com/pub/slackware/slackware64-14.1/patches/source/jasper/patches/

jasper-CVE-2014-8137.patch.gz   1 KB09/03/1518:54:00
jasper-CVE-2014-8138.patch.gz   1 KB09/03/1518:55:00
jasper-CVE-2014-8157.patch.gz   1 KB09/03/1518:55:00
jasper-CVE-2014-8158.patch.gz   2 KB09/03/1518:56:00
jasper-CVE-2014-9029.patch.gz   1 KB09/03/1518:57:00


Attached is my attempt to merge above Slackware patches, into
our jasper port.

Someone more familiar with jasper should double check that I
didn't screw anything up.

I have a question though, 'pkg_info jasper' claims gimp as a dependent,
however, 'ldd gimp' doesn't show jasper in the list. What am I missing?

Cheers,
--patrick
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/jasper/Makefile,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 Makefile
--- Makefile20 Apr 2013 15:25:35 -  1.17
+++ Makefile30 Oct 2015 05:37:32 -
@@ -1,9 +1,9 @@
-# $OpenBSD: Makefile,v 1.16 2013/03/21 08:45:18 ajacoutot Exp $
+# $OpenBSD: Makefile,v 1.17 2013/04/20 15:25:35 naddy Exp $
 
 COMMENT =  reference implementation of JPEG-2000
 
 DISTNAME = jasper-1.900.1
-REVISION = 2
+REVISION = 3
 SHARED_LIBS =  jasper  2.1
 
 CATEGORIES =   graphics
Index: patches/patch-src_libjasper_base_jas_icc_c
===
RCS file: 
/cvs/obsd/ports/graphics/jasper/patches/patch-src_libjasper_base_jas_icc_c,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-src_libjasper_base_jas_icc_c
--- patches/patch-src_libjasper_base_jas_icc_c  17 May 2008 09:32:16 -  
1.1
+++ patches/patch-src_libjasper_base_jas_icc_c  30 Oct 2015 05:37:32 -
@@ -1,6 +1,10 @@
 $OpenBSD$
 src/libjasper/base/jas_icc.c.orig  Fri Jan 19 22:43:05 2007
-+++ src/libjasper/base/jas_icc.c   Fri May 16 21:38:46 2008
+
+Security fix from Slackware:
+   CVE-2014-8137: double-free
+
+--- src/libjasper/base/jas_icc.c.orig  Fri Jan 19 13:43:05 2007
 src/libjasper/base/jas_icc.c   Thu Oct 29 22:03:25 2015
 @@ -373,7 +373,7 @@ int jas_iccprof_save(jas_iccprof_t *prof, jas_stream_t
jas_icctagtab_t *tagtab;
  
@@ -38,7 +42,15 @@ $OpenBSD$
goto error;
for (i = 0; i < curv->numents; ++i) {
if (jas_iccgetuint16(in, >ents[i]))
-@@ -1100,7 +1099,7 @@ static int jas_icctxtdesc_input(jas_iccattrval_t *attr
+@@ -1011,7 +1010,6 @@ static int jas_icccurv_input(jas_iccattrval_t *attrval
+   return 0;
+ 
+ error:
+-  jas_icccurv_destroy(attrval);
+   return -1;
+ }
+ 
+@@ -1100,7 +1098,7 @@ static int jas_icctxtdesc_input(jas_iccattrval_t *attr
if (jas_iccgetuint32(in, >uclangcode) ||
  jas_iccgetuint32(in, >uclen))
goto error;
@@ -47,7 +59,24 @@ $OpenBSD$
goto error;
if (jas_stream_read(in, txtdesc->ucdata, txtdesc->uclen * 2) !=
  JAS_CAST(int, txtdesc->uclen * 2))
-@@ -1292,17 +1291,17 @@ static int jas_icclut8_input(jas_iccattrval_t *attrval
+@@ -1129,7 +1127,6 @@ static int jas_icctxtdesc_input(jas_iccattrval_t *attr
+ #endif
+   return 0;
+ error:
+-  jas_icctxtdesc_destroy(attrval);
+   return -1;
+ }
+ 
+@@ -1208,8 +1205,6 @@ static int jas_icctxt_input(jas_iccattrval_t *attrval,
+   goto error;
+   return 0;
+ error:
+-  if (txt->string)
+-  jas_free(txt->string);
+   return -1;
+ }
+ 
+@@ -1292,17 +1287,17 @@ static int jas_icclut8_input(jas_iccattrval_t *attrval
  jas_iccgetuint16(in, >numouttabents))
goto error;
clutsize = jas_iccpowi(lut8->clutlen, lut8->numinchans) * 
lut8->numoutchans;
@@ -72,7 +101,15 @@ $OpenBSD$
  sizeof(jas_iccuint8_t *
goto error;
for (i = 0; i < lut8->numoutchans; ++i)
-@@ -1461,17 +1460,17 @@ static int jas_icclut16_input(jas_iccattrval_t *attrva
+@@ -1330,7 +1325,6 @@ static int jas_icclut8_input(jas_iccattrval_t *attrval
+   goto error;
+   return 0;
+ error:
+-  jas_icclut8_destroy(attrval);
+   return -1;
+ }
+ 
+@@ -1461,17 +1455,17 @@ static int jas_icclut16_input(jas_iccattrval_t *attrva
  

Re: stop firefox using ghostscript-fonts

[patrick keshishian]

On 10/26/15, Ted Unangst  wrote:
> I needed to convert an image file the other day, so I installed ImageMagick
> which somewhere along the way requires ghostscript-fonts to be installed as
> well.
>
> Now Firefox has also decided it should use these fonts to render webpages,
> much to my disappointment. The letters have a very uneven baseline on many
> sites.
>
> Besides removing the fonts/ghostscript directory (which I have done short
> term), how do I prevent Firefox from picking a new font of the day every
> time
> I install some new packages?

Does removing the ghostscript font directory in your X's font list
help?

--patrick

Re: [wip] Firefox 40.0

[patrick keshishian]

On 9/30/15, Erling Westenvik  wrote:
> On Tue, Aug 11, 2015 at 09:23:49AM +0200, Landry Breuil wrote:
>> On Thu, Jul 23, 2015 at 06:09:12AM +0200, Landry Breuil wrote:
>>
>> And fx 40.0 is almost there. Will be in cvs when ports unlock..
>
> Hi,
> Since the move from 39.0 to 40.0, and lately 41.0, Firefox has become
> unbearable slow/unrepsonsive on my Thinkpad T500. See dmesg below.

Just confirming a noticeable drop in responsiveness of FF 40.x.
Haven't tried 41 yet.

--patrick

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 9/23/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:
>> On 9/19/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
>> >> On 9/17/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> [...]
>> >> Attached is new tar-ball that compile, but unfortunately "make test"
>> >> mostly fails[1].
>> >
>> > Yes, but at least it builds :) Lots of ports have failing tests in the
>> > tree..
>> >
>> >> Most failures are due test DB not existing followed by core dump.
>> >
>> > Hmm, maybe have a look at databases/postgresql MODULE and the ports
>> > that
>> > use it, the module provides helpers to run/create databases for
>> > testing.
>> >
>> >> One hints of bad option.
>> >
>> > This one is strange..
>> >
>> >> One on Python module import.
>> >
>> > Needs TEST_DEPENDS on databases/py-psycopg2
>>
>> After adding this, the tests which were FAILing change state to
>> SKIP. The error message relating to their SKIP state, indicated
>> PG template0 database encoding was ASCII vs expected UTF8.
>>
>> Patching databases/postgresql/postgresql.port.mk[1] to accept
>> an encoding to be specified in port's Makefile. Now more tests
>> PASS:
>>
>> # TOTAL: 18
>> # PASS:  6
>> # SKIP:  1
>> # XFAIL: 0
>> # FAIL:  11
>> # XPASS: 0
>> # ERROR: 0
>>
>> Those which FAIL claim "Out of memory" (see attached test-suite.log).
>
> What if you bump ulimit -d ?
>
>> New tar-ball with suggested changes from Landry:
>> - Get rid of AUTO_ENV
>> - MODULE=gcc4 sets up proper links in ${WRKDIR}/bin for c++, cc,
>>   g++, gcc.
>> - TEST_DEPENDS = databases/py-psycopg2
>>
>> My "hack" for ensuring test-PG database uses UTF8 encoding:
>> - MODPOSTGRESQL_TEST_PGENCODING = -E UTF8
>
> I'll let vadim comment on this one but i think it should just be the
> default in postgresql.port.mk, i'm not sure we need a new knob for this.
> Few ports use this module, and they probably are all tested with UTFcrap
> anyway.

If the goal is to bring the tests results closer to all-PASS,
the test DB needs to be initdb-ed with '-E UTF8" option.

--patrick

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 9/23/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Thu, Sep 24, 2015 at 07:50:15AM +0200, Landry Breuil wrote:
>> On Tue, Sep 22, 2015 at 10:28:37PM -0700, patrick keshishian wrote:
>> > On 9/19/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> > > On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
>> > >> On 9/17/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> > [...]
>> > >> Attached is new tar-ball that compile, but unfortunately "make test"
>> > >> mostly fails[1].
>> > >
>> > > Yes, but at least it builds :) Lots of ports have failing tests in
>> > > the
>> > > tree..
>> > >
>> > >> Most failures are due test DB not existing followed by core dump.
>> > >
>> > > Hmm, maybe have a look at databases/postgresql MODULE and the ports
>> > > that
>> > > use it, the module provides helpers to run/create databases for
>> > > testing.
>> > >
>> > >> One hints of bad option.
>> > >
>> > > This one is strange..
>> > >
>> > >> One on Python module import.
>> > >
>> > > Needs TEST_DEPENDS on databases/py-psycopg2
>> >
>> > After adding this, the tests which were FAILing change state to
>> > SKIP. The error message relating to their SKIP state, indicated
>> > PG template0 database encoding was ASCII vs expected UTF8.
>> >
>> > Patching databases/postgresql/postgresql.port.mk[1] to accept
>> > an encoding to be specified in port's Makefile. Now more tests
>> > PASS:
>> >
>> > # TOTAL: 18
>> > # PASS:  6
>> > # SKIP:  1
>> > # XFAIL: 0
>> > # FAIL:  11
>> > # XPASS: 0
>> > # ERROR: 0
>> >
>> > Those which FAIL claim "Out of memory" (see attached test-suite.log).
>>
>> What if you bump ulimit -d ?
>
> Hm, after actually looking at the log, it's coming from the default
> value for --cache. When i tried osm2pgsql locally, with the default it
> was *always* complaining about this so i had to use a lower value. Maybe
> we should patch out in the code the default cache size so that it's more
> system-friendly, instead of forcing the user to specify it and it
> would fix the tests :)

Glad you suggested the patch, I wasn't sure if you'd like that
idea. My own tests work with "-C 300", anything above fails in
different manners; i.e., -C 400 fails more "silently" v -C 500.
I am, however, messing about with small .osm files ATM.

--patrick

Re: NEW: geo/osm2pgsql

[patrick keshishian]

>> Needs TEST_DEPENDS on databases/py-psycopg2
>
> After adding this, the tests which were FAILing change state to
> SKIP. The error message relating to their SKIP state, indicated
> PG template0 database encoding was ASCII vs expected UTF8.
>
> Patching databases/postgresql/postgresql.port.mk[1] to accept
> an encoding to be specified in port's Makefile. Now more tests
> PASS:
>
> # TOTAL: 18
> # PASS:  6
> # SKIP:  1
> # XFAIL: 0
> # FAIL:  11
> # XPASS: 0
> # ERROR: 0
>
> Those which FAIL claim "Out of memory" (see attached test-suite.log).
>
> I tried building with DEBUG="-g -O0", and the test results vary
> slightly:
>
> # TOTAL: 18
> # PASS:  7
> # SKIP:  2
> # XFAIL: 0
> # FAIL:  9
> # XPASS: 0
> # ERROR: 0
>
> I can play with these tests later.
>
> New tar-ball with suggested changes from Landry:
> - Get rid of AUTO_ENV
> - MODULE=gcc4 sets up proper links in ${WRKDIR}/bin for c++, cc,
>   g++, gcc.
> - TEST_DEPENDS = databases/py-psycopg2
>
> My "hack" for ensuring test-PG database uses UTF8 encoding:
> - MODPOSTGRESQL_TEST_PGENCODING = -E UTF8
>
> Thoughts, comments, etc?


I think this is a problem, and I can't quite guess how this
became:

$ ldd /usr/local/bin/osm2pgsql | grep stdc++
1c0e00869000 1c0e00d7f000 rlib 06   0
/usr/lib/libstdc++.so.57.0
1c0e48dcc000 1c0e492fa000 rlib 01   0
/usr/local/lib/libestdc++.so.17.0


The libestdc++ (from /usr/local/lib) is because the port is
built using gcc 4.9.3, but where is the base libstdc++ coming
from?

Is it from a dependency port which was built using base compiler?

--patrick

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 9/19/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Fri, Sep 18, 2015 at 11:50:19PM -0700, patrick keshishian wrote:
>> On 9/17/15, Landry Breuil <lan...@rhaalovely.net> wrote:
[...]
>> Attached is new tar-ball that compile, but unfortunately "make test"
>> mostly fails[1].
>
> Yes, but at least it builds :) Lots of ports have failing tests in the
> tree..
>
>> Most failures are due test DB not existing followed by core dump.
>
> Hmm, maybe have a look at databases/postgresql MODULE and the ports that
> use it, the module provides helpers to run/create databases for testing.
>
>> One hints of bad option.
>
> This one is strange..
>
>> One on Python module import.
>
> Needs TEST_DEPENDS on databases/py-psycopg2

After adding this, the tests which were FAILing change state to
SKIP. The error message relating to their SKIP state, indicated
PG template0 database encoding was ASCII vs expected UTF8.

Patching databases/postgresql/postgresql.port.mk[1] to accept
an encoding to be specified in port's Makefile. Now more tests
PASS:

# TOTAL: 18
# PASS:  6
# SKIP:  1
# XFAIL: 0
# FAIL:  11
# XPASS: 0
# ERROR: 0

Those which FAIL claim "Out of memory" (see attached test-suite.log).

I tried building with DEBUG="-g -O0", and the test results vary
slightly:

# TOTAL: 18
# PASS:  7
# SKIP:  2
# XFAIL: 0
# FAIL:  9
# XPASS: 0
# ERROR: 0

I can play with these tests later.

New tar-ball with suggested changes from Landry:
- Get rid of AUTO_ENV
- MODULE=gcc4 sets up proper links in ${WRKDIR}/bin for c++, cc,
  g++, gcc.
- TEST_DEPENDS = databases/py-psycopg2

My "hack" for ensuring test-PG database uses UTF8 encoding:
- MODPOSTGRESQL_TEST_PGENCODING = -E UTF8

Thoughts, comments, etc?

--patrick



[1] cvs diff -up postgresql.port.mk # also attached.
Index: postgresql.port.mk
===
RCS file: /cvs/ports/databases/postgresql/postgresql.port.mk,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 postgresql.port.mk
--- postgresql.port.mk  3 Aug 2015 07:42:30 -   1.5
+++ postgresql.port.mk  23 Sep 2015 02:49:29 -
@@ -1,4 +1,4 @@
-# $OpenBSD: postgresql.port.mk,v 1.5 2015/08/03 07:42:30 kirby Exp $
+# $OpenBSD: postgresql.port.mk,v 1.4 2015/07/19 12:42:20 zhuk Exp $
 #
 # Helps testing PostgreSQL-based software, no B/L/R-DEPS here.

@@ -19,6 +19,7 @@ MODPOSTGRESQL_TEST_TARGET = \
rm -Rf ${_MODPOSTGRESQL_TEST_PGDATA}; \
export ${ALL_TEST_ENV}; \
${LOCALBASE}/bin/initdb -D ${_MODPOSTGRESQL_TEST_PGDATA} \
+   ${MODPOSTGRESQL_TEST_PGENCODING} \
-A trust --locale=C --nosync; \
${LOCALBASE}/bin/pg_ctl start -w -D ${_MODPOSTGRESQL_TEST_PGDATA} \
-l ${WRKDIR}/pg-test.log \
Index: postgresql.port.mk
===
RCS file: /cvs/ports/databases/postgresql/postgresql.port.mk,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 postgresql.port.mk
--- postgresql.port.mk  3 Aug 2015 07:42:30 -   1.5
+++ postgresql.port.mk  23 Sep 2015 02:49:29 -
@@ -1,4 +1,4 @@
-# $OpenBSD: postgresql.port.mk,v 1.5 2015/08/03 07:42:30 kirby Exp $
+# $OpenBSD: postgresql.port.mk,v 1.4 2015/07/19 12:42:20 zhuk Exp $
 #
 # Helps testing PostgreSQL-based software, no B/L/R-DEPS here.
 
@@ -19,6 +19,7 @@ MODPOSTGRESQL_TEST_TARGET = \
rm -Rf ${_MODPOSTGRESQL_TEST_PGDATA}; \
export ${ALL_TEST_ENV}; \
${LOCALBASE}/bin/initdb -D ${_MODPOSTGRESQL_TEST_PGDATA} \
+   ${MODPOSTGRESQL_TEST_PGENCODING} \
-A trust --locale=C --nosync; \
${LOCALBASE}/bin/pg_ctl start -w -D ${_MODPOSTGRESQL_TEST_PGDATA} \
-l ${WRKDIR}/pg-test.log \


test-suite.log-without_DEBUG
Description: Binary data


test-suite.log-with_DEBUG
Description: Binary data


geo_osm2pgsql.tar.gz
Description: GNU Zip compressed data

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 9/17/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:
>> On 9/12/15, Daniel Jakots <vigdis+o...@chown.me> wrote:
>> > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
>> > <pkesh...@gmail.com> wrote:
>> >
>> >> Does the Makefile look better? I think it is headed toward a more
>> >> correct direction.
>> >
>> > Hi,
>> >
>> > I tried to build it, I had an error, but Patrick quickly sent me a new
>> > Makefile (attached), I could build it without problem then. I imported
>> > a
>> > bunch of osm data in a pgsql database to test, I had the same output
>> > that I usually have on Ubuntu so I guess it's good.
>> >
>> > Thanks for the port!
>> >
>> > Cheers,
>> > Daniel
>>
>> Thanks for your test and report Daniel.
>>
>> Attached the new tar-ball.
>
> After actually looking into it...
>
> - you have a typo in the patch adding without-lua to configure.ac... but
>   since this wasnt a build option provided by upstream, why bother with
> adding it and doing a flavor for this? i mean, lua dependency isnt
> usually big, and since it provides quite some useful features
> (scriptable tag transforming ?) why not enabling it by default ?
>
> - REVISION should be removed, no need to start at 0
>
> - devel/gmake doesnt need to got to BDEP, it's usually done with
> USE_GMAKE=Yes
>
> - make check fails here:
> tests/middle-tests.cpp:7:17: error: tuple: Fichier ou répertoire
> introuvable
> tests/middle-tests.cpp: In function 'int test_node_set(middle_t*)':
> tests/middle-tests.cpp:54: warning: comparison between signed and unsigned
> integer expressions
> tests/middle-tests.cpp: In function 'int
> test_nodes_comprehensive_set(middle_t*)':
> tests/middle-tests.cpp:79: error: 'class expected_nodelist_t' has no member
> named 'emplace_back'
>
> Tried installing libpqxx (as a potential candidate for providing tuple
> header) but that didnt help... installing g++ 4.9 didnt help either.
> Did you run the tests ?

Your comment one libpqxx threw me for a wild-goose chase.
The intended  is from c++/4.9.3/tuple.

Attached is new tar-ball that compile, but unfortunately "make test"
mostly fails[1].

Most failures are due test DB not existing followed by core dump.
One hints of bad option.
One on Python module import.

I figure the last two should be easy to fix. The ones with DB not found
failures might be a bit tougher to figure out.

I'll look further at this later, but welcome any help or hints.

Thanks,
--patrick


[1] $ cat test-suite.log

   osm2pgsql 0.88.1: ./test-suite.log


# TOTAL: 18
# PASS:  4
# SKIP:  0
# XFAIL: 0
# FAIL:  14
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: tests/test-middle-pgsql
=

./tests/test-middle-pgsql:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-28481-1442644086" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-middle-flat


./tests/test-middle-flat:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-17708-1442644107" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-tags
==

./tests/test-output-multi-tags:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-10989-1442644127" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-line
==

./tests/test-output-multi-line:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-29667-1442644148" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-line-storage
==

./tests/test-output-multi-line-storage:/usr/local/lib/libestdc++.so.17.0:
/usr/lib/libstdc++.so.57.0 : WARNING:
symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink
your program
NOTICE:  database "osm2pgsql-test-21058-1442644168" does not exist, skipping
Abort trap (core dumped)

FAIL: tests/test-output-multi-point
=

Re: NEW: geo/osm2pgsql

[patrick keshishian]

Hi,

On 9/17/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Thu, Sep 17, 2015 at 11:44:12PM +0200, Landry Breuil wrote:
>> On Sat, Sep 12, 2015 at 09:05:10AM -0700, patrick keshishian wrote:
>> > On 9/12/15, Daniel Jakots <vigdis+o...@chown.me> wrote:
>> > > On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
>> > > <pkesh...@gmail.com> wrote:
>> > >
>> > >> Does the Makefile look better? I think it is headed toward a more
>> > >> correct direction.
>> > >
>> > > Hi,
>> > >
>> > > I tried to build it, I had an error, but Patrick quickly sent me a
>> > > new
>> > > Makefile (attached), I could build it without problem then. I imported
>> > > a
>> > > bunch of osm data in a pgsql database to test, I had the same output
>> > > that I usually have on Ubuntu so I guess it's good.
>> > >
>> > > Thanks for the port!
>> > >
>> > > Cheers,
>> > > Daniel
>> >
>> > Thanks for your test and report Daniel.
>> >
>> > Attached the new tar-ball.
>>
>> After actually looking into it...
>>
>> - you have a typo in the patch adding without-lua to configure.ac... but
>>   since this wasnt a build option provided by upstream, why bother with
>> adding it and doing a flavor for this? i mean, lua dependency isnt
>> usually big, and since it provides quite some useful features
>> (scriptable tag transforming ?) why not enabling it by default ?

You are right. Making adjustments.

>> - REVISION should be removed, no need to start at 0
>>
>> - devel/gmake doesnt need to got to BDEP, it's usually done with
>> USE_GMAKE=Yes

OK.

> As for the autohell stuff, please use MODGNU_AUTOMAKE_DEPENDS &
> MODGNU_AUTOCONF_DEPENDS as everywhere else.

OK.

and currently working on the compile error you reported on
'make test' and hope to have a new tar-ball soon.

--patrick


> Landry
>
>

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 9/12/15, Daniel Jakots <vigdis+o...@chown.me> wrote:
> On Fri, 11 Sep 2015 16:45:31 -0700, patrick keshishian
> <pkesh...@gmail.com> wrote:
>
>> Does the Makefile look better? I think it is headed toward a more
>> correct direction.
>
> Hi,
>
> I tried to build it, I had an error, but Patrick quickly sent me a new
> Makefile (attached), I could build it without problem then. I imported a
> bunch of osm data in a pgsql database to test, I had the same output
> that I usually have on Ubuntu so I guess it's good.
>
> Thanks for the port!
>
> Cheers,
> Daniel

Thanks for your test and report Daniel.

Attached the new tar-ball.

--patrick


geo_osm2pgsql.tar.gz
Description: GNU Zip compressed data

Re: autoconf version to use?

[patrick keshishian]

On 9/11/15, Jérémie Courrèges-Anglas <j...@wxcvbn.org> wrote:
> patrick keshishian <pkesh...@gmail.com> writes:
>
>> Hi,
>>
>> Is there any preference/rule as to which version of autoconf
>> one should use in a new port?
>>
>> One with the largest version number or the lowest one
>> which works?
>
> I'd say use the same version as upstream if possible.

The source archive, only ships with a autogen.sh which
calls 'autoreconf -vfi'

After trying my way up from 2.13, I sent out my email.
Then I settled on using 2.69, which works/ed.

I'll need to tweak my port some more. I'll look at this
more closely. I just had to get myself out of the mud.

--patrick



>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 9/11/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Fri, Sep 11, 2015 at 12:27:40AM -0700, patrick keshishian wrote:
>> Any interest in this port? I need it for a project. Got it built on amd64
>> and been testing it with an extract dump from BBBike.org. I'll be
>> expanding my tests as the project progresses.
>>
>> Things I had to tweak:
>> - configure.ac
>>   . pickup HAVE_TERMIOS_H so passwords aren't echoed bcak.
>>   . add --without-lua option. Lua is option its README says. I
>> figure this should be a FLAVOR
>> - Fixed a few warnings about printf() format strings.
>> - Fixed one warning about unused variable as it ends up inside
>>   an #ifdef not compiled.
>>
>> After comments here I'll try and see how much of these changes
>> upstream may accept.
>>
>> Any comments? Did I miss stuff? etc.
>
> Yes, there's interest in this - i thought we already had it but it was
> osm2pgrouting which got recently imported.

I thought the same and was surprised there wasn't a port
already.

> I'm a bit surprised that
> all the deps are BDEPs, how is linking done ?

I see what you mean. Is there a "tool" within the ports
infrastructure that helps sort this stuff out?

I'll revisit the porter's guide sometime tomorrow and may
have a new tar-ball by the weekend.

> Technically im not sure you need a RDEP on postgis, since you could be
> targetting a postgis db on a remote host

That's correct.

> Anyway, i'll look into this deeper nextnext weekend.

Thanks,

--patrick

Re: NEW: geo/osm2pgsql

[patrick keshishian]

On 9/11/15, Landry Breuil <lan...@rhaalovely.net> wrote:
> On Fri, Sep 11, 2015 at 01:05:56AM -0700, patrick keshishian wrote:
>> On 9/11/15, Landry Breuil <lan...@rhaalovely.net> wrote:
>> > On Fri, Sep 11, 2015 at 12:27:40AM -0700, patrick keshishian wrote:
>> >> Any interest in this port? I need it for a project. Got it built on
>> >> amd64
>> >> and been testing it with an extract dump from BBBike.org. I'll be
>> >> expanding my tests as the project progresses.
>> >>
>> >> Things I had to tweak:
>> >> - configure.ac
>> >>   . pickup HAVE_TERMIOS_H so passwords aren't echoed bcak.
>> >>   . add --without-lua option. Lua is option its README says. I
>> >> figure this should be a FLAVOR
>> >> - Fixed a few warnings about printf() format strings.
>> >> - Fixed one warning about unused variable as it ends up inside
>> >>   an #ifdef not compiled.
>> >>
>> >> After comments here I'll try and see how much of these changes
>> >> upstream may accept.
>> >>
>> >> Any comments? Did I miss stuff? etc.
>> >
>> > Yes, there's interest in this - i thought we already had it but it was
>> > osm2pgrouting which got recently imported.
>>
>> I thought the same and was surprised there wasn't a port
>> already.
>>
>> > I'm a bit surprised that
>> > all the deps are BDEPs, how is linking done ?
>>
>> I see what you mean. Is there a "tool" within the ports
>> infrastructure that helps sort this stuff out?
>>
>> I'll revisit the porter's guide sometime tomorrow and may
>> have a new tar-ball by the weekend.
>
> make port-lib-depends-check will tell you :)

Thanks for the hints, now both portcheck and port-lib-depends-check
pass.

Does the Makefile look better? I think it is headed toward a more
correct direction.

--patrick


Pasted here for easier review (but also in attached archive).

--- 8< -
# $OpenBSD$

COMMENT =       OSM data to PostgreSQL converter

GH_TAGNAME =0.88.1
GH_PROJECT =osm2pgsql
GH_ACCOUNT =openstreetmap
REVISION =  0

DISTNAME =  osm2pgsql-${GH_TAGNAME}
CATEGORIES =geo databases

HOMEPAGE =  http://wiki.openstreetmap.org/wiki/Osm2pgsql

# Not sure
#MAINTAINER =   patrick keshishian <pkesh...@gmail.com>

# GPLv2
PERMIT_PACKAGE_CDROM =  Yes

CONFIGURE_STYLE =   autoconf
AUTOMAKE_VERSION =  1.14
AUTOCONF_VERSION =  2.69

USE_GMAKE = Yes

WANTLIB +=  boost_filesystem boost_system boost_system-mt
WANTLIB +=  boost_thread-mt bz2 c crypto geos iconv lzma
WANTLIB +=  m pq proj protobuf-c pthread ssl stdc++ xml2 z

MODULES =   converters/libiconv \
databases/postgresql\

LIB_DEPENDS =   databases/postgresql\
devel/proj  \
devel/protobuf-c\
geo/geos\
textproc/libxml \
devel/boost \

BUILD_DEPENDS = devel/gmake \
devel/libtool   \


# XXX TODO lua flavor (optional)
FLAVORS =   lua
FLAVOR ?=

.if ${FLAVOR:Mlua}
MODULES +=  lang/lua
.else
CONFIGURE_ARGS +=   --without-lua
.endif

post-patch:
cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
AUTOCONF_VERSION=${AUTOCONF_VERSION} \
AUTOMAKE_VERSION=${AUTOMAKE_VERSION}\
autoreconf -vfi

.include 
- >8 ---


geo_osm2pgsql.tar.gz
Description: GNU Zip compressed data

[patch] systrace.filter to biuld lang/ruby/2.2

[patrick keshishian]

Hi,

Attached patch to infrastructure/db/systrace.filter allows me to
build ruby/2.2 with USE_SYSTRACE=Yes.

Thanks,
--patrick
Index: systrace.filter
===
RCS file: /cvs/obsd/ports/infrastructure/db/systrace.filter,v
retrieving revision 1.46
diff -u -p -u -p -r1.46 systrace.filter
--- systrace.filter 23 Aug 2015 18:35:09 -  1.46
+++ systrace.filter 10 Sep 2015 17:47:33 -
@@ -114,6 +114,8 @@
native-getthrid: permit
native-gettimeofday: permit
native-getuid: permit
+   native-getresuid: permit
+   native-getresgid: permit
native-ioctl: permit
native-issetugid: permit
native-kbind: permit

[update] graphics/p5-Image-ExifTool

[patrick keshishian]

vCard and Audible supported added.

Full change-log:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-10.00/Changes

--patrick
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.35
diff -u -p -u -p -r1.35 Makefile
--- Makefile8 Jun 2015 09:51:30 -   1.35
+++ Makefile10 Sep 2015 22:43:06 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-9.90
+DISTNAME=  Image-ExifTool-10.00
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.29
diff -u -p -u -p -r1.29 distinfo
--- distinfo8 Jun 2015 09:51:30 -   1.29
+++ distinfo10 Sep 2015 22:43:06 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-9.90.tar.gz) = 
ZPYCdzzSBR/Tq2FEZPSzlJI4O6J0ImPN27TfJ4VbcIk=
-SIZE (Image-ExifTool-9.90.tar.gz) = 3940771
+SHA256 (Image-ExifTool-10.00.tar.gz) = 
e1czMeujkhtWM5AY6V3V5vWh5GNOT8e62R5XeNo1cfQ=
+SIZE (Image-ExifTool-10.00.tar.gz) = 4013694
Index: pkg/PLIST
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 PLIST
--- pkg/PLIST   8 Jun 2015 09:51:30 -   1.24
+++ pkg/PLIST   10 Sep 2015 22:43:06 -
@@ -14,6 +14,7 @@ ${P5SITE}/Image/ExifTool/APE.pm
 ${P5SITE}/Image/ExifTool/APP12.pm
 ${P5SITE}/Image/ExifTool/ASF.pm
 ${P5SITE}/Image/ExifTool/Apple.pm
+${P5SITE}/Image/ExifTool/Audible.pm
 ${P5SITE}/Image/ExifTool/BMP.pm
 ${P5SITE}/Image/ExifTool/BZZ.pm
 ${P5SITE}/Image/ExifTool/BigTIFF.pm
@@ -183,6 +184,7 @@ ${P5SITE}/Image/ExifTool/TagNames.pod
 ${P5SITE}/Image/ExifTool/Theora.pm
 ${P5SITE}/Image/ExifTool/Torrent.pm
 ${P5SITE}/Image/ExifTool/Unknown.pm
+${P5SITE}/Image/ExifTool/VCard.pm
 ${P5SITE}/Image/ExifTool/Vorbis.pm
 ${P5SITE}/Image/ExifTool/WriteCanonRaw.pl
 ${P5SITE}/Image/ExifTool/WriteExif.pl
@@ -209,6 +211,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::APP12.3p
 @man man/man3p/Image::ExifTool::ASF.3p
 @man man/man3p/Image::ExifTool::Apple.3p
+@man man/man3p/Image::ExifTool::Audible.3p
 @man man/man3p/Image::ExifTool::BMP.3p
 @man man/man3p/Image::ExifTool::BZZ.3p
 @man man/man3p/Image::ExifTool::BigTIFF.3p
@@ -345,6 +348,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Theora.3p
 @man man/man3p/Image::ExifTool::Torrent.3p
 @man man/man3p/Image::ExifTool::Unknown.3p
+@man man/man3p/Image::ExifTool::VCard.3p
 @man man/man3p/Image::ExifTool::Vorbis.3p
 @man man/man3p/Image::ExifTool::WriteCanonRaw.3p
 @man man/man3p/Image::ExifTool::WriteExif.3p

autoconf version to use?

[patrick keshishian]

Hi,

Is there any preference/rule as to which version of autoconf
one should use in a new port?

One with the largest version number or the lowest one
which works?

--patrick

Re: i386 build failure: audio/ardour

[patrick keshishian]

Hi,

you may already have figured this out, but just in case, i think ...

On 6/8/15, Stuart Henderson st...@openbsd.org wrote:
 Anyone know where this is coming from? Doesn't use gcc4, port hasn't
 changed recently.

 g++ -o libs/ardour/osc.os -c -Woverloaded-virtual -DGTK_NEW_TOOLTIP_API
 -DPACKAGE=\libardour2\ -DLIBSIGC_DISABLE_DEPRECATED
 -DDATA_DIR=\/usr/local/share\ -DMODULE_DIR=\/usr/local/lib\
 -DVAMP_DIR=\/usr/local/lib/ardour2/vamp\ -DCONFIG_DIR=\/etc\
 -DLOCALEDIR=\/usr/local/share/locale\ -DHAVE_JACK_CLIENT_OPEN
 -DHAVE_JACK_PORT_TYPE_GET_BUFFER_SIZE -DHAVE_JACK_ON_INFO_SHUTDOWN
 -DHAVE_JACK_RECOMPUTE_LATENCIES -DHAVE_JACK_VIDEO_SUPPORT
 -DHAVE_JACK_PORT_ENSURE_MONITOR -O3 -fomit-frame-pointer -ffast-math
 -fstrength-reduce -pipe -DARCH_X86 -Wall -DHAVE_LIBLO
 -DPROGRAM_NAME=\Ardour\ -D_REENTRANT -D_LARGEFILE_SOURCE
 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D__STDC_FORMAT_MACROS -Ilibs
 -DENABLE_NLS -Ilibs -pthread -DUSE_RUBBERBAND -fPIC -Ilibs/pbd
 -I/usr/local/include/libxml2 -I/usr/local/include -Ilibs/midi++2
 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/raptor2
 -I/usr/local/include/glibmm-2.4 -Ilibs/ardour -Ilibs/rubberband
 -I/usr/local/include/sigc++-2.0!
   -I/usr/local/lib/sigc++-2.0/include -Ilibs/surfaces/control_protocol
 -I/usr/local/lib/glib-2.0/include -Ilibs/vamp-sdk
 -I/usr/local/include/glib-2.0 libs/ardour/osc.cc
 libs/ardour/osc.cc:430: error: integer constant is too large for 'long'
 type
 libs/ardour/osc.cc:430: error: integer constant is too large for 'long'
 type
 libs/ardour/osc.cc:436: error: integer constant is too large for 'long'
 type
 libs/ardour/osc.cc:436: error: integer constant is too large for 'long'
 type


 426 // Application Hook Handlers //
 427 void
 428 OSC::session_loaded( Session s ) {
 429 lo_address listener = lo_address_new( NULL, 7770 );
  430 lo_send( listener, /session/loaded, ss,
 s.path().c_str(), s.name().c_str() );

lo_send is a macro that is defined in lo/lo_macros.h as:

#define lo_send(targ, path, types...) \
lo_send_internal(targ, __FILE__, __LINE__, path, types, \
 LO_MARKER_A, LO_MARKER_B)

and the LO_MARKERS_{A,B} as:

/* an internal value, ignored in transmission but check against LO_MARKER in the
 * argument list. Used to do primitive bounds checking */
#   define LO_MARKER_A (void *)0xdeadbeefdeadbeefL
#   define LO_MARKER_B (void *)0xf00baa23f00baa23L

It seems there is your error's source on i386.

--patrick

p.s., I don't use either port, so I haven't attempted to fix anything.
was just curious myself, so i looked.


 431 }
 432
 433 void
 434 OSC::session_exported( std::string path, std::string name ) {
 435 lo_address listener = lo_address_new( NULL, 7770 );
  436 lo_send( listener, /session/exported, ss, path.c_str(),
 name.c_str() );
 437 }

Re: i386 build failure: audio/ardour

[patrick keshishian]

On 6/8/15, Stuart Henderson st...@openbsd.org wrote:
 On 2015/06/08 10:51, patrick keshishian wrote:
 lo_send is a macro that is defined in lo/lo_macros.h as:

 #define lo_send(targ, path, types...) \
 lo_send_internal(targ, __FILE__, __LINE__, path, types, \
   LO_MARKER_A, LO_MARKER_B)

 and the LO_MARKERS_{A,B} as:

 /* an internal value, ignored in transmission but check against LO_MARKER
 in the
  * argument list. Used to do primitive bounds checking */
 #define LO_MARKER_A (void *)0xdeadbeefdeadbeefL
 #define LO_MARKER_B (void *)0xf00baa23f00baa23L

 It seems there is your error's source on i386.

 This has been building without problem for ages though, the error only
 occurred in the last build, and nothing changed in the source.

audio/liblo was updated by jasper@ on June 3rd:

revision 1.7
date: 2015/06/03 07:00:29;  author: jasper;  state: Exp;  lines: +3
-4;  commitid: yqEfAjc5XyWkweUr;
update to liblo-0.28

that's where the lo/lo_macros.h header comes from.

Here is diff of that file between version 0.26 and 0.28:


--- liblo-0.26/lo/lo_macros.h   Thu Mar  5 23:09:26 2009
+++ /usr/ports/pobj/liblo-0.28/liblo-0.28/lo/lo_macros.hSun Jan 26
06:08:24 2014
@@ -1,5 +1,5 @@
 /*
- *  Copyright (C) 2004 Steve Harris
+ *  Copyright (C) 2014 Steve Harris et al. (see AUTHORS)
  *
  *  This program is free software; you can redistribute it and/or
  *  modify it under the terms of the GNU Lesser General Public License
@@ -36,15 +36,32 @@ extern C {

 /* an internal value, ignored in transmission but check against
LO_MARKER in the
  * argument list. Used to do primitive bounds checking */
-#define LO_MARKER_A 0xdeadbeef
-#define LO_MARKER_B 0xf00baa23
+#  define LO_MARKER_A (void *)0xdeadbeefdeadbeefL
+#  define LO_MARKER_B (void *)0xf00baa23f00baa23L
+
 #define LO_ARGS_END LO_MARKER_A, LO_MARKER_B

 #define lo_message_add_varargs(msg, types, list) \
 lo_message_add_varargs_internal(msg, types, list, __FILE__, __LINE__)

-#ifdef __GNUC__
+#ifdef _MSC_VER
+#ifndef USE_ANSI_C
+#define USE_ANSI_C
+#endif
+#endif

+#if defined(USE_ANSI_C) || defined(DLL_EXPORT)
+
+/* In non-GCC compilers, there is no support for variable-argument
+ * macros, so provide internal vararg functions directly instead. */
+
+int lo_message_add(lo_message msg, const char *types, ...);
+int lo_send(lo_address targ, const char *path, const char *types, ...);
+int lo_send_timestamped(lo_address targ, lo_timetag ts, const char
*path, const char *types, ...);
+int lo_send_from(lo_address targ, lo_server from, lo_timetag ts,
const char *path, const char *types, ...);
+
+#else // !USE_ANSI_C
+
 #define lo_message_add(msg, types...) \
 lo_message_add_internal(msg, __FILE__, __LINE__, types,   \
 LO_MARKER_A, LO_MARKER_B)
@@ -61,17 +78,7 @@ extern C {
 lo_send_from_internal(targ, from, __FILE__, __LINE__, ts, path, \
 types, LO_MARKER_A, LO_MARKER_B)

-#else
-
-/* In non-GCC compilers, there is no support for variable-argument
- * macros, so provide internal vararg functions directly instead. */
-
-int lo_message_add(lo_message msg, const char *types, ...);
-int lo_send(lo_address targ, const char *path, const char *types, ...);
-int lo_send_timestamped(lo_address targ, lo_timetag ts, const char
*path, const char *types, ...);
-int lo_send_from(lo_address targ, lo_server from, lo_timetag ts,
const char *path, const char *types, ...);
-
-#endif
+#endif // USE_ANSI_C

 #ifdef __cplusplus
 }

Re: [update] graphics/p5-Image-ExifTool

[patrick keshishian]

ping? :-)

On 4/6/15, patrick keshishian pkesh...@gmail.com wrote:
 On 4/6/15, Andrew Fresh and...@afresh1.com wrote:
 On Mon, Apr 06, 2015 at 01:58:11PM -0700, patrick keshishian wrote:
 Image-ExifTool-9.76 - 9.90

 This looks ok to me, so many new cameras supported! It looks nifty, I
 may have to try it for something.

 Yes, very useful tool. Back in the day, when I used to do
 high-volume photography, it made it very simple to write
 a script for archiving/organizing images off of CF/SD cards
 onto HDD by camera make and image date, for example.

 Cheers,
 --patrick

 https://metacpan.org/changes/distribution/Image-ExifTool


 lightly tested.

 Cheers,
 --patrick

 Index: Makefile
 ===
 RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
 retrieving revision 1.34
 diff -u -p -u -p -r1.34 Makefile
 --- Makefile24 Nov 2014 09:32:45 -  1.34
 +++ Makefile6 Apr 2015 20:54:07 -
 @@ -2,7 +2,7 @@

  COMMENT=   read and write meta information in image/audio/video files

 -DISTNAME=  Image-ExifTool-9.76
 +DISTNAME=  Image-ExifTool-9.90
  CATEGORIES=graphics

  HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
 Index: distinfo
 ===
 RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
 retrieving revision 1.28
 diff -u -p -u -p -r1.28 distinfo
 --- distinfo24 Nov 2014 09:32:45 -  1.28
 +++ distinfo6 Apr 2015 20:54:07 -
 @@ -1,2 +1,2 @@
 -SHA256 (Image-ExifTool-9.76.tar.gz) =
 T7GlPNvWlZ5p7DjnvVwth9swlcj4YibTy2fcUNp8BCA=
 -SIZE (Image-ExifTool-9.76.tar.gz) = 3892850
 +SHA256 (Image-ExifTool-9.90.tar.gz) =
 ZPYCdzzSBR/Tq2FEZPSzlJI4O6J0ImPN27TfJ4VbcIk=
 +SIZE (Image-ExifTool-9.90.tar.gz) = 3940771
 Index: pkg/PLIST
 ===
 RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
 retrieving revision 1.23
 diff -u -p -u -p -r1.23 PLIST
 --- pkg/PLIST   10 Oct 2014 07:31:45 -  1.23
 +++ pkg/PLIST   6 Apr 2015 20:54:07 -
 @@ -120,6 +120,7 @@ ${P5SITE}/Image/ExifTool/MIE.pm
  ${P5SITE}/Image/ExifTool/MIEUnits.pod
  ${P5SITE}/Image/ExifTool/MIFF.pm
  ${P5SITE}/Image/ExifTool/MNG.pm
 +${P5SITE}/Image/ExifTool/MOI.pm
  ${P5SITE}/Image/ExifTool/MPC.pm
  ${P5SITE}/Image/ExifTool/MPEG.pm
  ${P5SITE}/Image/ExifTool/MPF.pm
 @@ -282,6 +283,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
  @man man/man3p/Image::ExifTool::MIEUnits.3p
  @man man/man3p/Image::ExifTool::MIFF.3p
  @man man/man3p/Image::ExifTool::MNG.3p
 +@man man/man3p/Image::ExifTool::MOI.3p
  @man man/man3p/Image::ExifTool::MPC.3p
  @man man/man3p/Image::ExifTool::MPEG.3p
  @man man/man3p/Image::ExifTool::MPF.3p


 --
 andrew - http://afresh1.com

 At the source of every error which is blamed on the computer, you
 will find at least two human errors, including the error of blaming
 it on the computer.

[patch] systrace.filter: permit chflagsat, getdtablecount and sendmsg

[patrick keshishian]

Hi ports,

Following up on file(1) thread[1] on tech@, and earlier submission
on ports[2], adding permit to chflagsat(2) for cp(1), getdtablecount(2)
and sendmsg(2) for file(1).

Thanks,
--patrick

[1] http://marc.info/?l=openbsd-techm=143345837620028w=2
[2] http://marc.info/?l=openbsd-portsm=143340587303885w=2


Index: systrace.filter
===
RCS file: /cvs/obsd/ports/infrastructure/db/systrace.filter,v
retrieving revision 1.45
diff -u -p -u -p -r1.45 systrace.filter
--- systrace.filter 11 Sep 2014 10:33:44 -  1.45
+++ systrace.filter 4 Jun 2015 22:25:08 -
@@ -22,6 +22,7 @@
native-chflags: filename match ${TMPDIR} then permit
native-chflags: filename match ${WRKDIR} then permit
native-chflags: filename match /non-existent filename: * then 
deny[enoent]
+   native-chflagsat: filename match ${WRKDIR} then permit
native-chmod: filename match /tmp then permit
native-chmod: filename match /var/tmp then permit
native-chmod: filename match ${TMPDIR} then permit
@@ -93,6 +94,7 @@
native-futimes: permit
native-futimens: permit
native-getdents: permit
+   native-getdtablecount: permit
native-getegid: permit
native-getentropy: permit
native-geteuid: permit
@@ -196,6 +198,7 @@
native-sendmsg: sockaddr match ${TMPDIR} then permit
native-sendmsg: sockaddr match ${WRKDIR} then permit
native-sendmsg: sockaddr match /non-existent filename: * then 
deny[enoent]
+   native-sendmsg: sockaddr eq unknown then permit
native-sendsyslog: permit
native-sendto: permit
native-setegid: permit

[patch] systrace.filter for chflagsat

[patrick keshishian]

Hi,

One line addition to systrace.filter to permit chflagsat() syscall.
This is now required with the recent cp(1) change. Ports like
databases/db/v4 fail to build due to a $(CP) -pr during docs
install phase with USE_SYSTRACE=Yes.

Before this can be put in, systrace(1) must know about chflagsat.
I sent a patch for that to tech@ a little ago.

Thanks,
--patrick


Index: systrace.filter
===
RCS file: /cvs/obsd/ports/infrastructure/db/systrace.filter,v
retrieving revision 1.45
diff -u -p -u -p -r1.45 systrace.filter
--- systrace.filter 11 Sep 2014 10:33:44 -  1.45
+++ systrace.filter 4 Jun 2015 07:46:13 -
@@ -22,6 +22,7 @@
native-chflags: filename match ${TMPDIR} then permit
native-chflags: filename match ${WRKDIR} then permit
native-chflags: filename match /non-existent filename: * then 
deny[enoent]
+   native-chflagsat: filename match ${WRKDIR} then permit
native-chmod: filename match /tmp then permit
native-chmod: filename match /var/tmp then permit
native-chmod: filename match ${TMPDIR} then permit

new file(1) and USE_SYSTRACE=Yes

[patrick keshishian]

Hi,

Seems, the file(1) can't be used with USE_SYSTRACE=Yes.

file: ioctl(STRIOCATTACH): Device busy

ideas?

Does it need a special option that tells it to avoid using /dev/systrace?
Or, does this mark the end of USE_SYSTRACE=Yes?

Symptom: devel/gobject-introspection build hung. Trying to find
the problem, I noticed a file process (the child) zombied and the
parent collected by init.

I think, the hang is in libtool's where it is piping output of
`eval $file_magic_cmd' to sed and output of that to egrep.

--patrick

Re: [wip] Firefox 35.0rc3

[patrick keshishian]

On 1/12/15, patrick keshishian pkesh...@gmail.com wrote:
 On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
 On Mon, Jan 12, 2015 at 02:00:02PM -0800, patrick keshishian wrote:
 On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
  On Mon, Jan 12, 2015 at 12:48:25PM -0800, patrick keshishian wrote:
  On 1/12/15, patrick keshishian pkesh...@gmail.com wrote:
   On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
   On Mon, Jan 12, 2015 at 12:29:00PM -0800, patrick keshishian
   wrote:
   On 1/10/15, Landry Breuil lan...@rhaalovely.net wrote:
Hi,
   
here's the wip update to ffx 35.0rc3, ETA next wednesday. Been
using
35.0betas on amd64 for the past 6 weeks without issues, also
tested
on
i386 and powerpc.
   
http://cgit.rhaalovely.net/mozilla-firefox/?h=release
  
   very possible this is my fault but ... the build fails for me on:
  
   kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06
   MST
   2015
  
   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
  
   with:
   ...
   INPUT(../../gfx/skia/SkLayer.o)
   INPUT(../../gfx/skia/SkMatrix22.o)
   INPUT(../../gfx/skia/SkMatrix44.o)
   INPUT(../../gfx/skia/SkMeshUtils.o)
   INPUT(../../gfx/skia/SkNWayCanvas.o)
   INPUT(../../gfx/skia/SkNinePatch.o)
   INPUT(../../gfx/skia/SkNullCanvas.o)
   INPUT(../../gfx/skia/SkOSFile.o)
   INPUT(../../gfx/skia/SkParseColor.o)
   INPUT(../../gfx/skia/SkParsePath.o)
   INPUT(../../gfx/skia/SkPathUtils.o)
   INPUT(../../gfx/skia/SkPictureUtils.o)
   INPUT(../../gfx/skia/SkProxyCanvas.o)
   INPUT(../../gfx/skia/SkRTConf.o)
   INPUT(../../gfx/skia/SkTextureCompressor.o)
   INPUT(../../gfx/skia/SkTextureCompressor_ASTC.o)
   INPUT(../../gfx/skia/SkTextureCompressor_LATC.o)
   INPUT(../../gfx/skia/SkTextureCompressor_R11EAC.o)
   INPUT(../../gfx/skia/SkThreadUtils_pthread.o)
   INPUT(StaticXULComponentsEnd/StaticXULComponentsEnd.o)
  
   /usr/bin/ld: Warning: gc-sections option ignored
   ../../gfx/skia/opts_check_x86.o(.data.rel.ro.local._ZL22platform_32_procs_SSE4+0x10):
   In function `SkBoxBlurGetPlatformProcs(void (**)(unsigned int
   const*,
   int, unsigned int*, int, int, int, int, int), void (**)(unsigned
   int
   const*, int, unsigned int*, int, int, int, int, int), void
   (**)(unsigned int const*, int, unsigned int*, int, int, int, int,
   int), void (**)(unsigned int const*, int, unsigned int*, int,
   int,
   int, int, int))':
   /usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/gfx/skia/trunk/src/opts/opts_check_x86.cpp:212:
   undefined reference to `S32A_Opaque_BlitRow32_SSE4_asm'
   /usr/bin/ld: libxul.so.53.0: hidden symbol
   `S32A_Opaque_BlitRow32_SSE4_asm' isn't defined
  
   What does 'grep HAVE_TOOLCHAIN
   /usr/build/ports/pobj/firefox-35.0rc3/build-amd64/config.status'
   says ?
  
   (''' HAVE_TOOLCHAIN_SUPPORT_MSSSE3 ''', r''' 1 '''),
   (''' HAVE_TOOLCHAIN_SUPPORT_MSSE4_1 ''', r''' 1 '''),
 
  full dmesg in case it is of more help:
  OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST 2015
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
  real mem = 1861025792 (1774MB)
  avail mem = 1807708160 (1723MB)
  mpath0 at root
  scsibus0 at mpath0: 256 targets
  mainbus0 at root
  bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1010 (17 entries)
  bios0: vendor Phoenix Technologies LTD version v1.3307 date
  05/31/2010
  bios0: Gateway LT31
  acpi0 at bios0: rev 2
  acpi0: sleep states S0 S3 S4 S5
  acpi0: tables DSDT FACP APIC MCFG HPET BOOT SLIC
  acpi0: wakeup devices PB5_(S5) OHC1(S3) OHC2(S3) EHCI(S3) HDAU(S3)
  acpitimer0 at acpi0: 3579545 Hz, 32 bits
  acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
  cpu0 at mainbus0: apid 0 (boot processor)
  cpu0: AMD Athlon(tm) Processor L110, 1197.20 MHz
  cpu0:
  FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,SVM,EAPICSP,AMCR8,3DNOWP
 
  Interesting, your cpu doesnt have SSSE3 nor SSE4.1, while binutils/the
  configure script detects so.. that might explain why it built here and
  not on your machine. That doesnt explain why configure things they're
  here though...

 I don't understand all this configure scaffolding jazz, but if I'm
 looking at the right bits, the configure script is only testing
 to see if the the compile command succeeds:

 configure:7455: checking if toolchain supports -mssse3 option
 configure:7467: cc -c -O2 -pipe -std=gnu99 -fgnu89-inline
 -fno-strict-aliasing -mssse3 -Qunused-arguments  conftest.c 15

 Now, i can't quite figure out where cc is aliased to clang,

 It comes from $WRKDIR/bin/, check the symlinks there..

 but /usr/bin/cc fails with unrecognized option -Qunused-arguments
 and -mssse3, but clang runs w/o complain:

 $ cat moo.c
 asm (pmaddubsw %xmm2,%xmm3);
 int main() {

 ; return 0; }
 $ clang -c -O2 -pipe -std=gnu99 -fgnu89-inline -fno

Re: [wip] Firefox 35.0rc3

[patrick keshishian]

On 1/13/15, Landry Breuil lan...@rhaalovely.net wrote:
[snip]
 so fixed this way in my git repo:

 http://cgit.rhaalovely.net/mozilla-firefox/commit/?h=releaseid=41cef5a7e563083c40cb52f8c764f10ef32bfe8b

 Thx for the testing!

You are the one doing the real hard work.
Much appreciated!
--patrick

Re: [wip] Firefox 35.0rc3

[patrick keshishian]

On 1/12/15, patrick keshishian pkesh...@gmail.com wrote:
 On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
 On Mon, Jan 12, 2015 at 12:29:00PM -0800, patrick keshishian wrote:
 On 1/10/15, Landry Breuil lan...@rhaalovely.net wrote:
  Hi,
 
  here's the wip update to ffx 35.0rc3, ETA next wednesday. Been using
  35.0betas on amd64 for the past 6 weeks without issues, also tested on
  i386 and powerpc.
 
  http://cgit.rhaalovely.net/mozilla-firefox/?h=release

 very possible this is my fault but ... the build fails for me on:

 kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST
 2015
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

 with:
 ...
 INPUT(../../gfx/skia/SkLayer.o)
 INPUT(../../gfx/skia/SkMatrix22.o)
 INPUT(../../gfx/skia/SkMatrix44.o)
 INPUT(../../gfx/skia/SkMeshUtils.o)
 INPUT(../../gfx/skia/SkNWayCanvas.o)
 INPUT(../../gfx/skia/SkNinePatch.o)
 INPUT(../../gfx/skia/SkNullCanvas.o)
 INPUT(../../gfx/skia/SkOSFile.o)
 INPUT(../../gfx/skia/SkParseColor.o)
 INPUT(../../gfx/skia/SkParsePath.o)
 INPUT(../../gfx/skia/SkPathUtils.o)
 INPUT(../../gfx/skia/SkPictureUtils.o)
 INPUT(../../gfx/skia/SkProxyCanvas.o)
 INPUT(../../gfx/skia/SkRTConf.o)
 INPUT(../../gfx/skia/SkTextureCompressor.o)
 INPUT(../../gfx/skia/SkTextureCompressor_ASTC.o)
 INPUT(../../gfx/skia/SkTextureCompressor_LATC.o)
 INPUT(../../gfx/skia/SkTextureCompressor_R11EAC.o)
 INPUT(../../gfx/skia/SkThreadUtils_pthread.o)
 INPUT(StaticXULComponentsEnd/StaticXULComponentsEnd.o)

 /usr/bin/ld: Warning: gc-sections option ignored
 ../../gfx/skia/opts_check_x86.o(.data.rel.ro.local._ZL22platform_32_procs_SSE4+0x10):
 In function `SkBoxBlurGetPlatformProcs(void (**)(unsigned int const*,
 int, unsigned int*, int, int, int, int, int), void (**)(unsigned int
 const*, int, unsigned int*, int, int, int, int, int), void
 (**)(unsigned int const*, int, unsigned int*, int, int, int, int,
 int), void (**)(unsigned int const*, int, unsigned int*, int, int,
 int, int, int))':
 /usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/gfx/skia/trunk/src/opts/opts_check_x86.cpp:212:
 undefined reference to `S32A_Opaque_BlitRow32_SSE4_asm'
 /usr/bin/ld: libxul.so.53.0: hidden symbol
 `S32A_Opaque_BlitRow32_SSE4_asm' isn't defined

 What does 'grep HAVE_TOOLCHAIN
 /usr/build/ports/pobj/firefox-35.0rc3/build-amd64/config.status'
 says ?

 (''' HAVE_TOOLCHAIN_SUPPORT_MSSSE3 ''', r''' 1 '''),
 (''' HAVE_TOOLCHAIN_SUPPORT_MSSE4_1 ''', r''' 1 '''),

full dmesg in case it is of more help:
OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1861025792 (1774MB)
avail mem = 1807708160 (1723MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1010 (17 entries)
bios0: vendor Phoenix Technologies LTD version v1.3307 date 05/31/2010
bios0: Gateway LT31
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET BOOT SLIC
acpi0: wakeup devices PB5_(S5) OHC1(S3) OHC2(S3) EHCI(S3) HDAU(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Athlon(tm) Processor L110, 1197.20 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,SVM,EAPICSP,AMCR8,3DNOWP
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-8
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB3_)
acpiprt2 at acpi0: bus -1 (PB4_)
acpiprt3 at acpi0: bus 3 (PB5_)
acpiprt4 at acpi0: bus 4 (PB6_)
acpiprt5 at acpi0: bus -1 (PB7_)
acpiprt6 at acpi0: bus 9 (P2P_)
acpiprt7 at acpi0: bus 1 (AGP_)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2
acpitz0 at acpi0: critical temperature is 100 degC
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model UM09A41 serial 22962 type LION oem SONY
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: PWRB
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCD_
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 ATI RS690 Host rev 0x00
ppb0 at pci0 dev 1 function 0 ATI RS690 PCIE rev 0x00
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 5 function 0 ATI Radeon X1250 IGP rev 0x00
drm0 at radeondrm0
radeondrm0: msi
ppb1 at pci0 dev 5 function 0 ATI RS690 PCIE rev 0x00: msi
pci2 at ppb1 bus 3
re0 at pci2 dev 0 function 0 Realtek 8101E rev 0x02

Re: [wip] Firefox 35.0rc3

[patrick keshishian]

On 1/10/15, Landry Breuil lan...@rhaalovely.net wrote:
 Hi,

 here's the wip update to ffx 35.0rc3, ETA next wednesday. Been using
 35.0betas on amd64 for the past 6 weeks without issues, also tested on
 i386 and powerpc.

 http://cgit.rhaalovely.net/mozilla-firefox/?h=release

very possible this is my fault but ... the build fails for me on:

kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

with:
...
INPUT(../../gfx/skia/SkLayer.o)
INPUT(../../gfx/skia/SkMatrix22.o)
INPUT(../../gfx/skia/SkMatrix44.o)
INPUT(../../gfx/skia/SkMeshUtils.o)
INPUT(../../gfx/skia/SkNWayCanvas.o)
INPUT(../../gfx/skia/SkNinePatch.o)
INPUT(../../gfx/skia/SkNullCanvas.o)
INPUT(../../gfx/skia/SkOSFile.o)
INPUT(../../gfx/skia/SkParseColor.o)
INPUT(../../gfx/skia/SkParsePath.o)
INPUT(../../gfx/skia/SkPathUtils.o)
INPUT(../../gfx/skia/SkPictureUtils.o)
INPUT(../../gfx/skia/SkProxyCanvas.o)
INPUT(../../gfx/skia/SkRTConf.o)
INPUT(../../gfx/skia/SkTextureCompressor.o)
INPUT(../../gfx/skia/SkTextureCompressor_ASTC.o)
INPUT(../../gfx/skia/SkTextureCompressor_LATC.o)
INPUT(../../gfx/skia/SkTextureCompressor_R11EAC.o)
INPUT(../../gfx/skia/SkThreadUtils_pthread.o)
INPUT(StaticXULComponentsEnd/StaticXULComponentsEnd.o)

/usr/bin/ld: Warning: gc-sections option ignored
../../gfx/skia/opts_check_x86.o(.data.rel.ro.local._ZL22platform_32_procs_SSE4+0x10):
In function `SkBoxBlurGetPlatformProcs(void (**)(unsigned int const*,
int, unsigned int*, int, int, int, int, int), void (**)(unsigned int
const*, int, unsigned int*, int, int, int, int, int), void
(**)(unsigned int const*, int, unsigned int*, int, int, int, int,
int), void (**)(unsigned int const*, int, unsigned int*, int, int,
int, int, int))':
/usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/gfx/skia/trunk/src/opts/opts_check_x86.cpp:212:
undefined reference to `S32A_Opaque_BlitRow32_SSE4_asm'
/usr/bin/ld: libxul.so.53.0: hidden symbol
`S32A_Opaque_BlitRow32_SSE4_asm' isn't defined
clang-3.5: error: linker command failed with exit code 1 (use -v to
see invocation)
/usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/config/rules.mk:829:
recipe for target 'libxul.so.53.0' failed
gmake[3]: *** [libxul.so.53.0] Error 1
gmake[3]: Leaving directory
'/usr/build/ports/pobj/firefox-35.0rc3/build-amd64/toolkit/library'
/usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/config/recurse.mk:74:
recipe for target 'toolkit/library/target' failed
gmake[2]: *** [toolkit/library/target] Error 2
gmake[2]: Leaving directory '/usr/build/ports/pobj/firefox-35.0rc3/build-amd64'
/usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/config/recurse.mk:36:
recipe for target 'compile' failed
gmake[1]: *** [compile] Error 2
gmake[1]: Leaving directory '/usr/build/ports/pobj/firefox-35.0rc3/build-amd64'
/usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/config/rules.mk:551:
recipe for target 'all' failed
gmake: *** [all] Error 2
*** Error 2 in . (/usr/build/ports/infrastructure/mk/bsd.port.mk:2748
'/usr/build/ports/pobj/firefox-35.0rc3/build-amd64/.build_done')
*** Error 1 in . (/usr/build/ports/infrastructure/mk/bsd.port.mk:1940
'/usr/build/ports/packages/amd64/all/firefox-35.0rc3.tgz')
*** Error 1 in . (/usr/build/ports/infrastructure/mk/bsd.port.mk:2493
'_internal-package')
*** Error 1 in . (/usr/build/ports/infrastructure/mk/bsd.port.mk:2473 'package')
*** Error 1 in . (/usr/build/ports/infrastructure/mk/bsd.port.mk:1957
'/var/db/pkg/firefox-35.0rc3/+CONTENTS')
*** Error 1 in /usr/ports/www/mozilla-firefox
(/usr/build/ports/infrastructure/mk/bsd.port.mk:2473 'install')


--patrick



 git clone -b release http://git.rhaalovely.net/git/mozilla-firefox

 http://rhaalovely.net/stuff/amd64/firefox-35.0rc3.tgz
 http://rhaalovely.net/stuff/i386/firefox-35.0rc3.tgz

 Landry

Re: [wip] Firefox 35.0rc3

[patrick keshishian]

On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
 On Mon, Jan 12, 2015 at 12:29:00PM -0800, patrick keshishian wrote:
 On 1/10/15, Landry Breuil lan...@rhaalovely.net wrote:
  Hi,
 
  here's the wip update to ffx 35.0rc3, ETA next wednesday. Been using
  35.0betas on amd64 for the past 6 weeks without issues, also tested on
  i386 and powerpc.
 
  http://cgit.rhaalovely.net/mozilla-firefox/?h=release

 very possible this is my fault but ... the build fails for me on:

 kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST
 2015
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

 with:
 ...
 INPUT(../../gfx/skia/SkLayer.o)
 INPUT(../../gfx/skia/SkMatrix22.o)
 INPUT(../../gfx/skia/SkMatrix44.o)
 INPUT(../../gfx/skia/SkMeshUtils.o)
 INPUT(../../gfx/skia/SkNWayCanvas.o)
 INPUT(../../gfx/skia/SkNinePatch.o)
 INPUT(../../gfx/skia/SkNullCanvas.o)
 INPUT(../../gfx/skia/SkOSFile.o)
 INPUT(../../gfx/skia/SkParseColor.o)
 INPUT(../../gfx/skia/SkParsePath.o)
 INPUT(../../gfx/skia/SkPathUtils.o)
 INPUT(../../gfx/skia/SkPictureUtils.o)
 INPUT(../../gfx/skia/SkProxyCanvas.o)
 INPUT(../../gfx/skia/SkRTConf.o)
 INPUT(../../gfx/skia/SkTextureCompressor.o)
 INPUT(../../gfx/skia/SkTextureCompressor_ASTC.o)
 INPUT(../../gfx/skia/SkTextureCompressor_LATC.o)
 INPUT(../../gfx/skia/SkTextureCompressor_R11EAC.o)
 INPUT(../../gfx/skia/SkThreadUtils_pthread.o)
 INPUT(StaticXULComponentsEnd/StaticXULComponentsEnd.o)

 /usr/bin/ld: Warning: gc-sections option ignored
 ../../gfx/skia/opts_check_x86.o(.data.rel.ro.local._ZL22platform_32_procs_SSE4+0x10):
 In function `SkBoxBlurGetPlatformProcs(void (**)(unsigned int const*,
 int, unsigned int*, int, int, int, int, int), void (**)(unsigned int
 const*, int, unsigned int*, int, int, int, int, int), void
 (**)(unsigned int const*, int, unsigned int*, int, int, int, int,
 int), void (**)(unsigned int const*, int, unsigned int*, int, int,
 int, int, int))':
 /usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/gfx/skia/trunk/src/opts/opts_check_x86.cpp:212:
 undefined reference to `S32A_Opaque_BlitRow32_SSE4_asm'
 /usr/bin/ld: libxul.so.53.0: hidden symbol
 `S32A_Opaque_BlitRow32_SSE4_asm' isn't defined

 What does 'grep HAVE_TOOLCHAIN
 /usr/build/ports/pobj/firefox-35.0rc3/build-amd64/config.status'
 says ?

(''' HAVE_TOOLCHAIN_SUPPORT_MSSSE3 ''', r''' 1 '''),
(''' HAVE_TOOLCHAIN_SUPPORT_MSSE4_1 ''', r''' 1 '''),

 Landry

Re: [wip] Firefox 35.0rc3

[patrick keshishian]

On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
 On Mon, Jan 12, 2015 at 12:48:25PM -0800, patrick keshishian wrote:
 On 1/12/15, patrick keshishian pkesh...@gmail.com wrote:
  On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
  On Mon, Jan 12, 2015 at 12:29:00PM -0800, patrick keshishian wrote:
  On 1/10/15, Landry Breuil lan...@rhaalovely.net wrote:
   Hi,
  
   here's the wip update to ffx 35.0rc3, ETA next wednesday. Been
   using
   35.0betas on amd64 for the past 6 weeks without issues, also tested
   on
   i386 and powerpc.
  
   http://cgit.rhaalovely.net/mozilla-firefox/?h=release
 
  very possible this is my fault but ... the build fails for me on:
 
  kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST
  2015
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
 
  with:
  ...
  INPUT(../../gfx/skia/SkLayer.o)
  INPUT(../../gfx/skia/SkMatrix22.o)
  INPUT(../../gfx/skia/SkMatrix44.o)
  INPUT(../../gfx/skia/SkMeshUtils.o)
  INPUT(../../gfx/skia/SkNWayCanvas.o)
  INPUT(../../gfx/skia/SkNinePatch.o)
  INPUT(../../gfx/skia/SkNullCanvas.o)
  INPUT(../../gfx/skia/SkOSFile.o)
  INPUT(../../gfx/skia/SkParseColor.o)
  INPUT(../../gfx/skia/SkParsePath.o)
  INPUT(../../gfx/skia/SkPathUtils.o)
  INPUT(../../gfx/skia/SkPictureUtils.o)
  INPUT(../../gfx/skia/SkProxyCanvas.o)
  INPUT(../../gfx/skia/SkRTConf.o)
  INPUT(../../gfx/skia/SkTextureCompressor.o)
  INPUT(../../gfx/skia/SkTextureCompressor_ASTC.o)
  INPUT(../../gfx/skia/SkTextureCompressor_LATC.o)
  INPUT(../../gfx/skia/SkTextureCompressor_R11EAC.o)
  INPUT(../../gfx/skia/SkThreadUtils_pthread.o)
  INPUT(StaticXULComponentsEnd/StaticXULComponentsEnd.o)
 
  /usr/bin/ld: Warning: gc-sections option ignored
  ../../gfx/skia/opts_check_x86.o(.data.rel.ro.local._ZL22platform_32_procs_SSE4+0x10):
  In function `SkBoxBlurGetPlatformProcs(void (**)(unsigned int const*,
  int, unsigned int*, int, int, int, int, int), void (**)(unsigned int
  const*, int, unsigned int*, int, int, int, int, int), void
  (**)(unsigned int const*, int, unsigned int*, int, int, int, int,
  int), void (**)(unsigned int const*, int, unsigned int*, int, int,
  int, int, int))':
  /usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/gfx/skia/trunk/src/opts/opts_check_x86.cpp:212:
  undefined reference to `S32A_Opaque_BlitRow32_SSE4_asm'
  /usr/bin/ld: libxul.so.53.0: hidden symbol
  `S32A_Opaque_BlitRow32_SSE4_asm' isn't defined
 
  What does 'grep HAVE_TOOLCHAIN
  /usr/build/ports/pobj/firefox-35.0rc3/build-amd64/config.status'
  says ?
 
  (''' HAVE_TOOLCHAIN_SUPPORT_MSSSE3 ''', r''' 1 '''),
  (''' HAVE_TOOLCHAIN_SUPPORT_MSSE4_1 ''', r''' 1 '''),

 full dmesg in case it is of more help:
 OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST 2015
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
 real mem = 1861025792 (1774MB)
 avail mem = 1807708160 (1723MB)
 mpath0 at root
 scsibus0 at mpath0: 256 targets
 mainbus0 at root
 bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1010 (17 entries)
 bios0: vendor Phoenix Technologies LTD version v1.3307 date 05/31/2010
 bios0: Gateway LT31
 acpi0 at bios0: rev 2
 acpi0: sleep states S0 S3 S4 S5
 acpi0: tables DSDT FACP APIC MCFG HPET BOOT SLIC
 acpi0: wakeup devices PB5_(S5) OHC1(S3) OHC2(S3) EHCI(S3) HDAU(S3)
 acpitimer0 at acpi0: 3579545 Hz, 32 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
 cpu0: AMD Athlon(tm) Processor L110, 1197.20 MHz
 cpu0:
 FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,SVM,EAPICSP,AMCR8,3DNOWP

 Interesting, your cpu doesnt have SSSE3 nor SSE4.1, while binutils/the
 configure script detects so.. that might explain why it built here and
 not on your machine. That doesnt explain why configure things they're
 here though...

I don't understand all this configure scaffolding jazz, but if I'm
looking at the right bits, the configure script is only testing
to see if the the compile command succeeds:

configure:7455: checking if toolchain supports -mssse3 option
configure:7467: cc -c -O2 -pipe -std=gnu99 -fgnu89-inline
-fno-strict-aliasing -mssse3 -Qunused-arguments  conftest.c 15

Now, i can't quite figure out where cc is aliased to clang,
but /usr/bin/cc fails with unrecognized option -Qunused-arguments
and -mssse3, but clang runs w/o complain:

$ cat moo.c
asm (pmaddubsw %xmm2,%xmm3);
int main() {

; return 0; }
$ clang -c -O2 -pipe -std=gnu99 -fgnu89-inline -fno-strict-aliasing
-mssse3 -Qunused-arguments  moo.c  echo Woo!
Woo!

The C file is a snippet from configure, w/o the #line or confdefs.h
(which I don't know how to regenerate).

thoughts?
--patrick



 Landry

Re: [wip] Firefox 35.0rc3

[patrick keshishian]

On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
 On Mon, Jan 12, 2015 at 02:00:02PM -0800, patrick keshishian wrote:
 On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
  On Mon, Jan 12, 2015 at 12:48:25PM -0800, patrick keshishian wrote:
  On 1/12/15, patrick keshishian pkesh...@gmail.com wrote:
   On 1/12/15, Landry Breuil lan...@rhaalovely.net wrote:
   On Mon, Jan 12, 2015 at 12:29:00PM -0800, patrick keshishian wrote:
   On 1/10/15, Landry Breuil lan...@rhaalovely.net wrote:
Hi,
   
here's the wip update to ffx 35.0rc3, ETA next wednesday. Been
using
35.0betas on amd64 for the past 6 weeks without issues, also
tested
on
i386 and powerpc.
   
http://cgit.rhaalovely.net/mozilla-firefox/?h=release
  
   very possible this is my fault but ... the build fails for me on:
  
   kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06
   MST
   2015
  
   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
  
   with:
   ...
   INPUT(../../gfx/skia/SkLayer.o)
   INPUT(../../gfx/skia/SkMatrix22.o)
   INPUT(../../gfx/skia/SkMatrix44.o)
   INPUT(../../gfx/skia/SkMeshUtils.o)
   INPUT(../../gfx/skia/SkNWayCanvas.o)
   INPUT(../../gfx/skia/SkNinePatch.o)
   INPUT(../../gfx/skia/SkNullCanvas.o)
   INPUT(../../gfx/skia/SkOSFile.o)
   INPUT(../../gfx/skia/SkParseColor.o)
   INPUT(../../gfx/skia/SkParsePath.o)
   INPUT(../../gfx/skia/SkPathUtils.o)
   INPUT(../../gfx/skia/SkPictureUtils.o)
   INPUT(../../gfx/skia/SkProxyCanvas.o)
   INPUT(../../gfx/skia/SkRTConf.o)
   INPUT(../../gfx/skia/SkTextureCompressor.o)
   INPUT(../../gfx/skia/SkTextureCompressor_ASTC.o)
   INPUT(../../gfx/skia/SkTextureCompressor_LATC.o)
   INPUT(../../gfx/skia/SkTextureCompressor_R11EAC.o)
   INPUT(../../gfx/skia/SkThreadUtils_pthread.o)
   INPUT(StaticXULComponentsEnd/StaticXULComponentsEnd.o)
  
   /usr/bin/ld: Warning: gc-sections option ignored
   ../../gfx/skia/opts_check_x86.o(.data.rel.ro.local._ZL22platform_32_procs_SSE4+0x10):
   In function `SkBoxBlurGetPlatformProcs(void (**)(unsigned int
   const*,
   int, unsigned int*, int, int, int, int, int), void (**)(unsigned
   int
   const*, int, unsigned int*, int, int, int, int, int), void
   (**)(unsigned int const*, int, unsigned int*, int, int, int, int,
   int), void (**)(unsigned int const*, int, unsigned int*, int, int,
   int, int, int))':
   /usr/build/ports/pobj/firefox-35.0rc3/mozilla-release/gfx/skia/trunk/src/opts/opts_check_x86.cpp:212:
   undefined reference to `S32A_Opaque_BlitRow32_SSE4_asm'
   /usr/bin/ld: libxul.so.53.0: hidden symbol
   `S32A_Opaque_BlitRow32_SSE4_asm' isn't defined
  
   What does 'grep HAVE_TOOLCHAIN
   /usr/build/ports/pobj/firefox-35.0rc3/build-amd64/config.status'
   says ?
  
   (''' HAVE_TOOLCHAIN_SUPPORT_MSSSE3 ''', r''' 1 '''),
   (''' HAVE_TOOLCHAIN_SUPPORT_MSSE4_1 ''', r''' 1 '''),
 
  full dmesg in case it is of more help:
  OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST 2015
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
  real mem = 1861025792 (1774MB)
  avail mem = 1807708160 (1723MB)
  mpath0 at root
  scsibus0 at mpath0: 256 targets
  mainbus0 at root
  bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1010 (17 entries)
  bios0: vendor Phoenix Technologies LTD version v1.3307 date
  05/31/2010
  bios0: Gateway LT31
  acpi0 at bios0: rev 2
  acpi0: sleep states S0 S3 S4 S5
  acpi0: tables DSDT FACP APIC MCFG HPET BOOT SLIC
  acpi0: wakeup devices PB5_(S5) OHC1(S3) OHC2(S3) EHCI(S3) HDAU(S3)
  acpitimer0 at acpi0: 3579545 Hz, 32 bits
  acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
  cpu0 at mainbus0: apid 0 (boot processor)
  cpu0: AMD Athlon(tm) Processor L110, 1197.20 MHz
  cpu0:
  FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,SVM,EAPICSP,AMCR8,3DNOWP
 
  Interesting, your cpu doesnt have SSSE3 nor SSE4.1, while binutils/the
  configure script detects so.. that might explain why it built here and
  not on your machine. That doesnt explain why configure things they're
  here though...

 I don't understand all this configure scaffolding jazz, but if I'm
 looking at the right bits, the configure script is only testing
 to see if the the compile command succeeds:

 configure:7455: checking if toolchain supports -mssse3 option
 configure:7467: cc -c -O2 -pipe -std=gnu99 -fgnu89-inline
 -fno-strict-aliasing -mssse3 -Qunused-arguments  conftest.c 15

 Now, i can't quite figure out where cc is aliased to clang,

 It comes from $WRKDIR/bin/, check the symlinks there..

 but /usr/bin/cc fails with unrecognized option -Qunused-arguments
 and -mssse3, but clang runs w/o complain:

 $ cat moo.c
 asm (pmaddubsw %xmm2,%xmm3);
 int main() {

 ; return 0; }
 $ clang -c -O2 -pipe -std=gnu99 -fgnu89-inline -fno-strict-aliasing
 -mssse3 -Qunused-arguments  moo.c  echo Woo!
 Woo

[update] graphics/p5-Image-ExifTool

[patrick keshishian]

basic update ... 9.70 (prod) - 9.76 (prod)

Full ChangeLog:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-9.76/Changes

thanks,
--patrick
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.33
diff -u -p -u -p -r1.33 Makefile
--- Makefile10 Oct 2014 07:31:45 -  1.33
+++ Makefile24 Nov 2014 05:12:16 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-9.70
+DISTNAME=  Image-ExifTool-9.76
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 distinfo
--- distinfo10 Oct 2014 07:31:45 -  1.27
+++ distinfo24 Nov 2014 05:12:16 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-9.70.tar.gz) = 
pZ1ItYbDg2PB/BbYuVTF+efNz2Bqt6mkZSqC4p/snhw=
-SIZE (Image-ExifTool-9.70.tar.gz) = 3861823
+SHA256 (Image-ExifTool-9.76.tar.gz) = 
T7GlPNvWlZ5p7DjnvVwth9swlcj4YibTy2fcUNp8BCA=
+SIZE (Image-ExifTool-9.76.tar.gz) = 3892850

Re: emacs and emacs21 handling

[patrick keshishian]

On 10/26/14, Jérémie Courrèges-Anglas j...@wxcvbn.org wrote:

 So the idea was to deconflict those two ports, to be able to use both
 during bulk builds.  Several ports are waiting for this as they depend
 on newer emacs releases.

 I had sent patches to rename the conflicting files in emacs21, but it
 turns out that it won't happen.  *shrug*

 So my plan is to kill any use of emacs21 at build time. To achieve
 this, there are several ways:

 - remove the port
 - stop byte-compiling files at build time
 - switch the port to using emacs24 at build time

 I'd kill those:

   net/zenirc,-main|editors/emacs21|||editors/emacs21|B
   net/zenirc,-main|editors/emacs21|||editors/emacs21|R
   net/zenirc,-el|editors/emacs21|||editors/emacs21|R
   net/zenirc,-el|editors/emacs21|||editors/emacs21|B

 print/auctex|emacs-=21,22:editors/emacs21|emacs-=21,22||editors/emacs21|B

 print/auctex|emacs-=21,22:editors/emacs21|emacs-=21,22||editors/emacs21|R
   mail/mew|editors/emacs21|||editors/emacs21|R
   mail/mew|editors/emacs21|||editors/emacs21|B

 zenirc has seen no update since 2000, auctex and mew are lagging behind
 upstream.

 I'd switch those to using emacs 24 :

   devel/automake/1.9|editors/emacs21|||editors/emacs21|T
   devel/automake/1.10|editors/emacs21|||editors/emacs21|T
   devel/automake/1.11|editors/emacs21|||editors/emacs21|T
   devel/automake/1.12|editors/emacs21|||editors/emacs21|T
   devel/automake/1.13|editors/emacs21|||editors/emacs21|T
   devel/automake/1.14|editors/emacs21|||editors/emacs21|T

 There is no automated run of regress tests right now but IIRC people
 were interested.  IMO it would make more sense to test whether those
 packages correctly support *current* emacs versions.

 I'm unsure about those:

   inputmethods/anthy,-main|editors/emacs21|||editors/emacs21|B
   inputmethods/anthy,-emacs|editors/emacs21|||editors/emacs21|B
   math/gnuplot|editors/emacs21|||editors/emacs21|B
   math/gnuplot,no_x11|editors/emacs21|||editors/emacs21|B

Fwiw, whenever I build gnuplot from ports, I remove the emacs
dependency and the .el and .elc files.

I'm not sure what they are for, and I've not missed them.

--patrick


 We could either just install the .el files, without byte-compiling, or
 move them to using emacs24 at build time.  The latter is a bit of
 a problem since emacs=24 may use byte-compiled instructions that
 emacs21 doesn't grok.  But do we care?  I have only heard about one
 emacs21 user on OpenBSD, and he doesn't use those ports...

 This has waited for a long time now, if you folks have comments please
 chime in before thursday.

 Thanks,
 --
 jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: Time to kill systrace? (was: Re: go ports.)

[patrick keshishian]

On 10/21/14, Stuart Henderson st...@openbsd.org wrote:
 On 2014/10/21 13:32, Amit Kulkarni wrote:
 On Tue, Oct 21, 2014 at 12:18 PM, patrick keshishian pkesh...@gmail.com
 wrote:

  On 10/21/14, Stuart Henderson st...@openbsd.org wrote:
   On 2014/10/21 10:58, Amit Kulkarni wrote:
   On Tue, Oct 21, 2014 at 10:28 AM, Stuart Henderson
   st...@openbsd.org
I'm fetching distfiles as my normal uid, then doing builds as
pbuild.
pf.conf:
   
block quick log proto {tcp udp} user pbuild
   
   
   This can be disabled by user and bypassed,
  
   If you're aware of a way in which an unprivileged user can change PF
   rules, it's probably best if you let me (or security@) know in
   private
   mail.
 
  I read that comment as: the system admin, may not
  (forgets to?) enable such a rule. Also, the pf rule route
  seems a bit clunky and disjointed from the ports process.
 


 Somebody might disable the default PF rules and overwrite with their own,
 and forget about it. If it isn't caught by anybody else port might get
 committed. In that case, it will be caught in a bulk build by someone.
 Generally, people don't touch systrace enable/disable, but they usually
 fiddle with PF rules. But yes, this is immaterial. Patrick got the drift
 of
 this, sorry for not explaining clearly in the initial email.

 Exact opposite on most machines I use for ports work I hardly ever
 touch PF rules there, but before we had build-as-nonroot I was often
 doing 'make USE_SYSTRACE=Yes' when working on a new port or testing
 a submission.

 systrace is not without problems, it can make some syscalls fail which
 people don't expect or check for, so can have an impact on how the build
 works (another issue is that it's very noticably slower).

   you can't bypass systrace during ports build. Also, it would be
   possible to place files in FAKE /etc i.e in places other than
  /usr/local?
  
   I'm confused. It's ok if the port build puts things in directories
   writable by the user doing port builds, because that user only has
   filesystem permissions to write to a limited number of places
   (mostly the build dir).
 
  Consider a wip port, which may write files in $HOME, or
  worse yet, delete files or directories from $HOME.
 
  I always felt more at ease, knowing systrace would slap
  the hand that attempted that, whether maliciously or
  erroneously.

 Yes that is a problem if you do builds as your normal userid.

I don't mean to split hairs on this. You guys know better.
But, are you suggesting a $PORTUSER that the ports's
infrastructure will automatically sudo to for all make
commands? This I like!

Otherwise, as an example, I maintain a notes.txt for
ports I work on, contents of which includes a fair amount
of output from `make SHOW=this-and-that'. It would be a
bit of PITA to maintain that file as my everyday user.

OK, said my piece, thanks for considering it.

--patrick



  --patrick
 

 +1

 I am asking if user can create /etc/sysctl.conf in a port, that port
 overwrites the real /etc/sysctl.conf because a port has superuser
 privileges during install. If systrace is not there to catch it, would it
 get installed?

 It does not, not any more - this whole mail thread probably makes
 little sense if you missed that change.
 http://undeadly.org/cgi?action=articlesid=20141003132339


Or as Patrick says in another email: what about add/delete
 in $HOME? Systrace protects us here. Is there any way to solve this
 problem
 and the arbitrary net download problem during port building?

 Using a separate UID for builds protects against this too.

Re: eating cockroaches is the future, start doing it now!

[patrick keshishian]

On 10/3/14, Antoine Jacoutot ajacou...@openbsd.org wrote:
 Hi.

 So, to all of you slackers out there who are wondering how you could
 contribute to the project, have a look at:
 http://portroach.openbsd.org/

 This will let you know the ports that could use an update in our tree. The
 point is not to *blindly* update everything of course, but at least it will
 give you a chance to look at candidates (full disclosure: there are many!).
 The the openbsd ports mailing-list MAINTAINER references all orphan ports,
 so it's likely there's some nice work to do in there -- some of which may be
 very trivial.

 Oh also, a nice side effect is that you can start pointing fingers at
 maintainers that are slacking too much :-)

 Do note that portroach[1] is still a fast moving target: you can harass
 jasper@ about the bugs you find...

 If you are maintaining a port and would like portroach to automatically send
 you a mail when one of your port becomes out-of-date, drop me a mail and
 I'll register you.

Yes, please add me to this list.

Also, is there a reverse version of this process for when an
update sent to ports@ seems to have fallen through the cracks?

e.g., http://marc.info/?l=openbsd-portsm=141058337421511w=2

Thanks,
--patrick


 This will allow you to update it before anyone has a chance to mock you for
 being out-of-date!

 [1]
 portroach is a friendly fork of FreeBSD's portscout

 --
 Antoine

Re: postgresql rc.d script

[patrick keshishian]

On 9/22/14, frantisek holop min...@obiit.org wrote:

 i installed postgresql and starting to use it for
 first time.  here is what i think could be improved.

Hmm...

 1.
 i think the postgres package readme could mention,
 that while there is no default database location
 the rc.d script has /var/postgresql/data hardcoded
 in it.


 2.
 without actually initializing a database i tried:

Why did you do this?
The README is clear about creating the database:

  If you are installing PostgreSQL for the first time, you have to create
  a default database first.



 $ sudo /etc/rc.d/postgresql start
 postgresql(ok)# ???
 $ sudo /etc/rc.d/postgresql check
 postgresql(failed)

 a bit of set -x reveals:
 $ sudo su -l -c daemon -s /bin/sh _postgresql -c \
   /usr/local/bin/pg_ctl -D /var/postgresql/data \
   start -l /var/postgresql/logfile
 server starting
 $ echo $?
 0
 # tail -1 /var/postgresql/logfile
 postgres cannot access the server configuration file
 /var/postgresql/data/postgresql.conf: No such file or directory

 what happens is, that pg_ctl's return code cannot
 be trusted because it starts the server in background
 and does not wait for confirmation. to really make
 sure the server was started, -w must be used:

 $ sudo su -l -c daemon -s /bin/sh _postgresql -c \
   /usr/local/bin/pg_ctl -w -D /var/postgresql/data \
   start -l /var/postgresql/logfile
 waiting for server to start stopped waiting
 pg_ctl: could not start server
 Examine the log output.
 $ echo $?
 1

 i dont know how long it takes to start up a huge
 postgres installation with -w, and maybe it is good
 to have it start in the background at startup time,
 but it can mask startup errors like this...


 3.
 my last issue is check: i think it is a bit of overkill
 that i have to be root to check if postgres is running.
 this is because daemon_user is defined. so not even
 '_postgresql' is allowed to check, although it
 is allowed to run the actual 'pg_ctl check' command.

 i think it would make sense to get rid of rc_usercheck=NO,
 all of rc_check() and override pexp= to the actual
 daemon signature instead of pg_ctl..  this way any user
 can run the check.

The database could be in a shutdown mode, and
the change you propose could give a false-positive.

Maybe there are reasons why folks who have maintained
this port, and have used it in production, for much longer
than first time, have things this way.

--patrick



 please find attached my patch that tries to remedy
 the issues mentioned above.

 -f
 --
 the best way out of a difficulty is through it.

Re: postgresql rc.d script

[patrick keshishian]

On 9/22/14, frantisek holop min...@obiit.org wrote:
[snip]
 well, can 'pg_ctl status' tell it is in shutdown mode?

evidently I've mistaken.

--patrick

[patch] x11/blackbox [was: X11 Focus Issue (2014-SEP-09 snapshot)]

[patrick keshishian]

Hi,

Digging more after I couldn't reproduce the issue with
stock fvwm, I believe the problem is blackbox's code
calling XSetInputFocus() with a stale time. With attached
patch I am unable to reproduce the issue.

Would appreciate if this could be put in.

Certainly a change in X made this bug show up. If any
X11 guru knows what change, I'm very curious to find out.

Cheers,
--patrick



On 9/14/14, patrick keshishian pkesh...@gmail.com wrote:
 Visual aid demonstraiting the issue described here:

   http://youtu.be/gl49UBVOUog

 --patrick

 On 9/14/14, patrick keshishian pkesh...@gmail.com wrote:
 Hi,

 Moving to 2014-SEP-09 snapshot (amd64)[1] I started to notice
 something strange with my wm (blackbox) and window focus
 events. I have it set to sloppy focus, where focus follows the
 mouse, but doesn't leave the last visited window, until the mouse
 enters a new window.

 Every so often moving the mouse from one window to another,
 the latter does not get focus.

 I tried to capture the condition with xev. Here the first sequence
 of EnterNotify - KeymapNotify - FocusIn - LeaveNotify -
 FocusOut shows an expected behavior where mouse moved
 from xterm to xev window, xev window:

 1. EnterNotify (mouse moved from xterm - xev window)
 2. FocusIn (xev window got focus)
 3. bunch of MotionNotify events as mouse moved around
 4. LeaveNotify (mouse left xev window)
 5. FocusOut (mouse entered xterm window)

 EnterNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82741873, (13,137), root:(960,467),
 mode NotifyNormal, detail NotifyAncestor, same_screen YES,
 focus NO, state 0

 KeymapNotify event, serial 35, synthetic NO, window 0x0,
 keys:  4294967224 0   0   0   0   0   0   0   0   0   0   0   0   0
 0
  0
0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82741877, (13,137), root:(960,467),
 state 0x0, is_hint 0, same_screen YES

 FocusIn event, serial 35, synthetic NO, window 0x1c1,
 mode NotifyNormal, detail NotifyNonlinear

 KeymapNotify event, serial 35, synthetic NO, window 0x0,
 keys:  4294967224 0   0   0   0   0   0   0   0   0   0   0   0   0
 0
  0
0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82741889, (47,139), root:(994,469),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82741903, (72,139), root:(1019,469),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82741913, (82,139), root:(1029,469),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82741926, (84,139), root:(1031,469),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82741937, (84,139), root:(1031,469),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82742392, (79,139), root:(1026,469),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82742404, (67,138), root:(1014,468),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82742416, (41,134), root:(988,464),
 state 0x0, is_hint 0, same_screen YES

 MotionNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82742428, (10,133), root:(957,463),
 state 0x0, is_hint 0, same_screen YES

 LeaveNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82742433, (-22,131), root:(925,461),
 mode NotifyNormal, detail NotifyAncestor, same_screen YES,
 focus YES, state 0

 FocusOut event, serial 35, synthetic NO, window 0x1c1,
 mode NotifyNormal, detail NotifyNonlinear


 This next sequence shows the problem:

 1. EnterNotify (mouse moved from xterm - xev window)
 2. FocusIn (xev window got focus - briefly?)
 3. FocusOut (mouse still in xev window, but window w/o focus)
 XXX What happened here?
 4. bunch of MotionNotify events as mouse moved around
 5. LeaveNotify (mouse left xev window)

 Notice no FocusOut event at the end of the sequence. Why
 did the FocusOut event happen early? What causes this?


 EnterNotify event, serial 35, synthetic NO, window 0x1c1,
 root 0x2b8, subw 0x0, time 82742834, (23,139), root:(970,469),
 mode NotifyNormal, detail NotifyAncestor, same_screen YES,
 focus NO, state 0

 KeymapNotify event, serial 35, synthetic NO, window 0x0

Re: UPDATE: FFmpeg 20140912

[patrick keshishian]

On 9/12/14, Brad Smith b...@comstyle.com wrote:
 Here is an update to a newer FFmpeg snapshot from 20140912. Mainly
 to fix bugs with HEVC and VP9 decoding (among the other bug fixes
 coming in).

Not sure if you care. Seems OK on amd64, playing some mp4s
and converting some m4a to mp3s.

--patrick

$ sysctl kern.version
kern.version=OpenBSD 5.6-current (GENERIC.MP) #368: Tue Sep  9 00:28:20 MDT 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


 OK?


 Index: graphics/ffmpeg/Makefile
 ===
 RCS file: /home/cvs/ports/graphics/ffmpeg/Makefile,v
 retrieving revision 1.106
 diff -u -p -u -p -r1.106 Makefile
 --- graphics/ffmpeg/Makefile  4 Sep 2014 05:49:49 -   1.106
 +++ graphics/ffmpeg/Makefile  12 Sep 2014 15:13:21 -
 @@ -2,22 +2,21 @@

  COMMENT= audio/video converter and streamer

 -V=   20140810
 +V=   20140912
  DISTNAME=ffmpeg-git-${V}
  PKGNAME= ffmpeg-${V}
 -REVISION=0
  CATEGORIES=  graphics multimedia
  MASTER_SITES=http://comstyle.com/source/
  EXTRACT_SUFX=.tar.xz

 -SHARED_LIBS= avcodec 21.0 \
 +SHARED_LIBS= avcodec 21.1 \
   avdevice9.0 \
   avfilter7.0 \
 - avformat19.0 \
 + avformat19.1 \
   avresample  1.0 \
 - avutil  12.0 \
 + avutil  12.1 \
   postproc16.0 \
 - swresample  1.0 \
 + swresample  1.1 \
   swscale 6.0

  HOMEPAGE=http://ffmpeg.org/
 @@ -33,6 +32,11 @@ WANTLIB=   SDL X11 Xext Xfixes Xv bz2 c cr
   theoraenc vorbis vorbisenc vpx=5 x264=8 x265 xvidcore \
   z

 +MODULES= lang/clang
 +
 +MODCLANG_ARCHS=  amd64 i386
 +MODCLANG_LANGS=  c
 +
  BUILD_DEPENDS=   textproc/texi2html
  .if ${MACHINE_ARCH} == amd64 || ${MACHINE_ARCH} == i386
  BUILD_DEPENDS+=  devel/yasm
 @@ -90,6 +94,7 @@ CONFIGURE_ARGS+= ${CONFIGURE_SHARED} \
   --disable-iconv \
   --disable-indev=jack \
   --disable-indev=oss \
 + --disable-lzma \
   --disable-mips32r2 \
   --disable-mipsdspr1 \
   --disable-mipsdspr2 \
 Index: graphics/ffmpeg/distinfo
 ===
 RCS file: /home/cvs/ports/graphics/ffmpeg/distinfo,v
 retrieving revision 1.31
 diff -u -p -u -p -r1.31 distinfo
 --- graphics/ffmpeg/distinfo  14 Aug 2014 08:20:27 -  1.31
 +++ graphics/ffmpeg/distinfo  12 Sep 2014 15:14:09 -
 @@ -1,2 +1,2 @@
 -SHA256 (ffmpeg-git-20140810.tar.xz) =
 1yR5E7oR6twORJ9rbd7iWMFZAfKegkIGZxdf19V2rXU=
 -SIZE (ffmpeg-git-20140810.tar.xz) = 6168568
 +SHA256 (ffmpeg-git-20140912.tar.xz) =
 TGf/UNFP2SY+D+s1kMslPSEowOd+St9PiH0qaoe6lZI=
 +SIZE (ffmpeg-git-20140912.tar.xz) = 6038712
 Index: graphics/ffmpeg/patches/patch-configure
 ===
 RCS file: /home/cvs/ports/graphics/ffmpeg/patches/patch-configure,v
 retrieving revision 1.40
 diff -u -p -u -p -r1.40 patch-configure
 --- graphics/ffmpeg/patches/patch-configure   14 Aug 2014 08:20:27 -  
 1.40
 +++ graphics/ffmpeg/patches/patch-configure   4 Sep 2014 06:03:50 -
 @@ -1,7 +1,7 @@
  $OpenBSD: patch-configure,v 1.40 2014/08/14 08:20:27 brad Exp $
  configure.orig   Sun Aug 10 21:09:03 2014
 -+++ configureSun Aug 10 21:15:16 2014
 -@@ -1630,7 +1630,6 @@ HEADERS_LIST=
 +--- configure.orig   Thu Sep  4 01:50:15 2014
  configureThu Sep  4 02:03:44 2014
 +@@ -1633,7 +1633,6 @@ HEADERS_LIST=
   mach_mach_time_h
   machine_ioctl_bt848_h
   machine_ioctl_meteor_h
 @@ -9,7 +9,7 @@ $OpenBSD: patch-configure,v 1.40 2014/08
   openjpeg_1_5_openjpeg_h
   OpenGL_gl3_h
   poll_h
 -@@ -3970,7 +3969,7 @@ case $target_os in
 +@@ -3981,7 +3980,7 @@ case $target_os in
   openbsd|bitrig)
   disable symver
   SHFLAGS='-shared'
 @@ -18,7 +18,7 @@ $OpenBSD: patch-configure,v 1.40 2014/08
   SLIB_INSTALL_LINKS=
   oss_indev_extralibs=-lossaudio
   oss_outdev_extralibs=-lossaudio
 -@@ -4301,7 +4300,7 @@ die_license_disabled version3 libvo_amrwbenc
 +@@ -4312,7 +4311,7 @@ die_license_disabled version3 libvo_amrwbenc

   enabled version3  { enabled gpl  enable gplv3 || enable lgplv3; }

 @@ -27,15 +27,15 @@ $OpenBSD: patch-configure,v 1.40 2014/08

   enable_weak_pic() {
   disabled pic  return
 -@@ -5026,7 +5025,6 @@ check_disable_warning -Wno-pointer-sign
 +@@ -5042,7 +5041,6 @@ check_disable_warning -Wno-pointer-sign
   check_ldflags -Wl,--warn-common
   check_ldflags
 -Wl,-rpath-link=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample
 - enabled rpath  add_ldflags -Wl,-rpath,$libdir
 + enabled rpath  add_ldexeflags 

[update] graphics/p5-Image-ExifTool

[patrick keshishian]

simple update.

Full Changelog:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-9.70/Changes
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 Makefile
--- Makefile13 Jul 2014 06:52:42 -  1.32
+++ Makefile13 Sep 2014 04:31:47 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-9.60
+DISTNAME=  Image-ExifTool-9.70
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 distinfo
--- distinfo13 Jul 2014 06:52:42 -  1.26
+++ distinfo13 Sep 2014 04:31:47 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-9.60.tar.gz) = 
rYl23DOL8EYurE9qOGM8TfpjFpadFXscisU8VNL9+ac=
-SIZE (Image-ExifTool-9.60.tar.gz) = 3821772
+SHA256 (Image-ExifTool-9.70.tar.gz) = 
pZ1ItYbDg2PB/BbYuVTF+efNz2Bqt6mkZSqC4p/snhw=
+SIZE (Image-ExifTool-9.70.tar.gz) = 3861823
Index: pkg/PLIST
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.22
diff -u -p -u -p -r1.22 PLIST
--- pkg/PLIST   13 Jul 2014 06:52:42 -  1.22
+++ pkg/PLIST   13 Sep 2014 04:31:47 -
@@ -114,6 +114,7 @@ ${P5SITE}/Image/ExifTool/Lang/tr.pm
 ${P5SITE}/Image/ExifTool/Lang/zh_cn.pm
 ${P5SITE}/Image/ExifTool/Lang/zh_tw.pm
 ${P5SITE}/Image/ExifTool/Leaf.pm
+${P5SITE}/Image/ExifTool/Lytro.pm
 ${P5SITE}/Image/ExifTool/M2TS.pm
 ${P5SITE}/Image/ExifTool/MIE.pm
 ${P5SITE}/Image/ExifTool/MIEUnits.pod
@@ -144,6 +145,7 @@ ${P5SITE}/Image/ExifTool/PLIST.pm
 ${P5SITE}/Image/ExifTool/PNG.pm
 ${P5SITE}/Image/ExifTool/PPM.pm
 ${P5SITE}/Image/ExifTool/PSP.pm
+${P5SITE}/Image/ExifTool/Palm.pm
 ${P5SITE}/Image/ExifTool/Panasonic.pm
 ${P5SITE}/Image/ExifTool/PanasonicRaw.pm
 ${P5SITE}/Image/ExifTool/Pentax.pm
@@ -274,6 +276,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Lang::zh_cn.3p
 @man man/man3p/Image::ExifTool::Lang::zh_tw.3p
 @man man/man3p/Image::ExifTool::Leaf.3p
+@man man/man3p/Image::ExifTool::Lytro.3p
 @man man/man3p/Image::ExifTool::M2TS.3p
 @man man/man3p/Image::ExifTool::MIE.3p
 @man man/man3p/Image::ExifTool::MIEUnits.3p
@@ -304,6 +307,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::PNG.3p
 @man man/man3p/Image::ExifTool::PPM.3p
 @man man/man3p/Image::ExifTool::PSP.3p
+@man man/man3p/Image::ExifTool::Palm.3p
 @man man/man3p/Image::ExifTool::Panasonic.3p
 @man man/man3p/Image::ExifTool::PanasonicRaw.3p
 @man man/man3p/Image::ExifTool::Pentax.3p

add native-dup3 to systrace.filter?

[patrick keshishian]

building gstreamer1-1.2.4 barffed w/o this.

--patrick

$ sysctl kern.version
kern.version=OpenBSD 5.6-current (GENERIC) #345: Tue Sep  9 00:22:24 MDT 2014
t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Index: db/systrace.filter
===
RCS file: /cvs/obsd/ports/infrastructure/db/systrace.filter,v
retrieving revision 1.44
diff -u -p -u -p -r1.44 systrace.filter
--- db/systrace.filter  3 Sep 2014 10:21:39 -   1.44
+++ db/systrace.filter  11 Sep 2014 08:55:18 -
@@ -46,6 +46,7 @@
native-connect: sockaddr match ${TMPDIR} then permit
native-connect: sockaddr match ${WRKDIR} then permit
native-connect: sockaddr match /non-existent filename: * then 
deny[enoent]
+   native-dup3: permit
native-dup2: permit
native-dup: permit
native-execve: true then permit

Re: add native-dup3 to systrace.filter?

[patrick keshishian]

On 9/11/14, David Coppa dco...@gmail.com wrote:
 On Thu, Sep 11, 2014 at 11:42 AM, patrick keshishian pkesh...@gmail.com
 wrote:
 building gstreamer1-1.2.4 barffed w/o this.

 --patrick

 $ sysctl kern.version
 kern.version=OpenBSD 5.6-current (GENERIC) #345: Tue Sep  9 00:22:24 MDT
 2014
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

 Sure.

 Bikeshedding: shouldn't these be sorted alphabetically?

I wasn't sure if there was a reason dup2 was ahead of dup,
so I followed the lead. Looking pipe and pipe2, those are
listed in expected order.

--patrick

Re: add native-dup3 to systrace.filter?

[patrick keshishian]

oops... missed diff as you suggsted.

On 9/11/14, patrick keshishian pkesh...@gmail.com wrote:
 On 9/11/14, David Coppa dco...@gmail.com wrote:
 On Thu, Sep 11, 2014 at 11:42 AM, patrick keshishian pkesh...@gmail.com
 wrote:
 building gstreamer1-1.2.4 barffed w/o this.

 --patrick

 $ sysctl kern.version
 kern.version=OpenBSD 5.6-current (GENERIC) #345: Tue Sep  9 00:22:24 MDT
 2014
 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

 Sure.

 Bikeshedding: shouldn't these be sorted alphabetically?

 I wasn't sure if there was a reason dup2 was ahead of dup,
 so I followed the lead. Looking pipe and pipe2, those are
 listed in expected order.

 --patrick

Index: systrace.filter
===
RCS file: /cvs/obsd/ports/infrastructure/db/systrace.filter,v
retrieving revision 1.44
diff -u -p -u -p -r1.44 systrace.filter
--- systrace.filter 3 Sep 2014 10:21:39 -   1.44
+++ systrace.filter 11 Sep 2014 10:06:35 -
@@ -46,8 +46,9 @@
native-connect: sockaddr match ${TMPDIR} then permit
native-connect: sockaddr match ${WRKDIR} then permit
native-connect: sockaddr match /non-existent filename: * then 
deny[enoent]
-   native-dup2: permit
native-dup: permit
+   native-dup2: permit
+   native-dup3: permit
native-execve: true then permit
native-exit: permit
native-fchdir: permit

Re: Is this a bug?

[patrick keshishian]

On 7/21/14, Stefan Wollny stefan.wol...@web.de wrote:
 Hi Stuart,
 This is the README to the squid-stable port. Should the First line really
 look like this :
 quoteRunning ${Fullpackagename} on OpenBSD \quote
 I would have expected the sentence to read like so:Running squid-stable
 on OpenBSD 
 See what I mean?

Those variables are filled out by the port's build
process as it is built into a package.

i.e.,
(cd /usr/ports/www/squid/stable/  make show=FULLPKGNAME)
squid-3.3.12

HTH,
--patrick

Re: NEW (kinda): www/lynx (hooray!)

[patrick keshishian]

On 7/16/14, Brian Callahan bcal...@devio.us wrote:
 Hi ports --

 First, let me start by saying that some of you know that I'm in the
 middle of moving. So apologies if it takes longer than normal for me to
 reply.

 Here is a port of lynx, everyone's favorite web browser that was just
 removed from base.

thanks for doing this!

--patrick


 Run-down:
 This is a port of lynx-current. At the time I made this port, lynx was
 still in base and I wasn't sure if it would go or not. I thought it
 would be silly to have the ports lynx be the same as the base lynx if it
 were to stay. This can easily be changed to the stable branch of lynx if
 desired. Doesn't matter to me either way. Either way, I'd like to track
 upstream. I know we had local patches, but I don't think it's worth the
 cost of maintaining them. Unless there's something really important,
 then let me know.

 I switched on options that would let users install lynx without any
 external deps. Since that is what base had. Again, not committal on
 this. But if I missed something from the old in-base lynx, let me know.

 Do we really want all the docs and help? I turned them on but they can
 be flipped off by removing the post-install routine.

 And finally, because I am in the middle of a move, the *only* arch I
 have access to right now is amd64 (this laptop). I'm relying on others
 to test on the other archs.

 I am able to reach webspace and gopherspace with this. That's all I've
 had the opportunity to test.

 OK?

 ~Brian

x11/xsel crash [patch included] (was: _XData32() crash ...)

[patrick keshishian]

Hi,

This is a follow up of my post[1] originally on misc@
on x11/xsel crash.

Matthew Dempsky committed his fix for data argument to
XChangeProperty() interface.

Running with the updated port, I still ran into a crash (same
crash based on backtrace).

[short version]
Attached diff fixes an issue where NUM_TARGETS in main()
is incremented one too many times.

The diff also plugs a memory leak in handle_targets()
where a copy of supported_targets is created to be
passed to change_property() - XChangeProperty()
but is not free()-ed.

The malloc()/memcpy() may be entirely unnecessary.


[longer version]
NUM_TARGETS is what is passed in as nelements to
XChangeProperty() and data is supported_targets, which
is declared to have MAX_NUM_TARGETS (#define-d to 8)
elements.

Disclaimer: this is outside my expertise.
Comment on supported_targets mentions all Atoms
it has slots for. It does not specify the NULL atom,
which NUM_TARGETS is incremented for (the one too
many). This leaves NUM_TARGETS equaling 9 at the
end of initialization.

Side note: the code uses an extra variable s as an
incrementer as supported_targets is initialized, and
it increments NUM_TARGETS along side. This is curious.

I also added an assert(NUM_TARGETS = MAX_NUM_TARGETS)
in main() to catch mismatches should they happen in
future code changes.

I've been running this patch on amd64 for about a
week and no issues so far.

Note #1, make update-patches somehow changes
patch-configure, even though it isn't changed. *shrug*

Note #2, I contacted upstream author, both when Matthew
posted his patch and a week ago when I found this mistake.
I have not heard a peep from him.

Thoughts?
--patrick

[1] http://marc.info/?l=openbsd-miscm=140299560300878w=2
Index: Makefile
===
RCS file: /cvs/obsd/ports/x11/xsel/Makefile,v
retrieving revision 1.8
diff -u -p -u -p -r1.8 Makefile
--- Makefile18 Jun 2014 20:49:15 -  1.8
+++ Makefile30 Jun 2014 09:30:32 -
@@ -3,7 +3,7 @@
 COMMENT=   command-line program for managing X selection contents
 
 DISTNAME=  xsel-1.2.0
-REVISION=  0
+REVISION=  1
 CATEGORIES=x11
 HOMEPAGE=  http://www.vergenet.net/~conrad/software/xsel/
 
Index: patches/patch-configure
===
RCS file: /cvs/obsd/ports/x11/xsel/patches/patch-configure,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-configure
--- patches/patch-configure 5 Sep 2009 08:55:51 -   1.1
+++ patches/patch-configure 30 Jun 2014 09:30:32 -
@@ -2,10 +2,9 @@ $OpenBSD$
 
 -Wdeclaration-after-statement is gcc 4-only.
 
 configure.orig Wed Jul 29 23:21:22 2009
-+++ configure  Wed Jul 29 23:21:44 2009
-@@ -5879,9 +5879,9 @@ fi
- 
+--- configure.orig Mon Mar 24 08:27:33 2008
 configure  Mon Jun 30 00:10:19 2014
+@@ -5880,7 +5880,7 @@ fi
  
  # Error out on compile warnings
  if test x$ac_cv_c_compiler_gnu = xyes ; then
@@ -14,4 +13,3 @@ $OpenBSD$
  fi
  
  # Checks for header files.
- { echo $as_me:$LINENO: checking for grep that handles long lines and -e 5
Index: patches/patch-xsel_c
===
RCS file: /cvs/obsd/ports/x11/xsel/patches/patch-xsel_c,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 patch-xsel_c
--- patches/patch-xsel_c18 Jun 2014 20:49:15 -  1.1
+++ patches/patch-xsel_c30 Jun 2014 09:30:32 -
@@ -1,24 +1,52 @@
 $OpenBSD$
 
-Format 32 properties use long, not int, even on LP64 platforms.
+- Format 32 properties use long, not int, even on LP64 platforms.
+- ensure NUM_TARGETS does not exceed MAX_NUM_TARGETS.
+- plug a memory leak in handle_targets()
 
 xsel.c.origWed Jun 18 12:42:56 2014
-+++ xsel.c Wed Jun 18 12:43:16 2014
-@@ -630,7 +630,7 @@ wait_selection (Atom selection, Atom request_target)
- } else if (target == incr_atom) {
-   /* Handle INCR transfers */
-   retval = wait_incr_selection (selection, event.xselection,
--*(int *)value);
-+*(long *)value);
-   keep_waiting = False;
- } else if (target != utf8_atom  target != XA_STRING 
-target != compound_text_atom 
-@@ -1165,7 +1165,7 @@ change_property (Display * display, Window requestor, 
-  Atom selection, Time time, MultTrack * mparent)
+--- xsel.c.origMon Jun 30 00:10:19 2014
 xsel.c Mon Jun 30 00:20:50 2014
+@@ -15,6 +15,7 @@
+ #include config.h
+ #endif
+ 
++#include assert.h
+ #include stdio.h
+ #include stdlib.h
+ #include stdarg.h
+@@ -1300,14 +1301,16 @@ handle_targets (Display * display, Window requestor, A
+ Atom selection, Time time, MultTrack * mparent)
  {
-   XSelectionEvent ev;
--  int nr_bytes;
-+  long nr_bytes;
-   IncrTrack * it;
+   Atom * targets_cpy;
++  HandleResult r;
+ 
+   targets_cpy = malloc 

Re: update textproc/xpdf

[patrick keshishian]

On 5/30/14, Matthias Kilian k...@outback.escape.de wrote:
 Update to xpdf-3.04.

 See http://www.foolabs.com/xpdf/CHANGES for a full list of changes.

 Tested with a couple of (broken and evil) pdf documents on amd64.

 The fix from miod@ (dates back to 2009) shouldn't be necessary any
 longer, but to be safe I prefer to keep some asserts around for a
 while.

Are there test-cases which can be shared?

 I added pdftopng(1) but not pdftohtml(1), because poppler-utils
 already contains a program with this name. No idea which one is
 more useful.

 Tests, comments and oks are welcome.

Only tested a few minutes on amd64, but it does open the
postgresql-9.3-US.pdf much(!) quicker than previous version.

Thanks for the quick update to the port.

--patrick


 Ciao,
   Kili

 Index: Makefile
 ===
 RCS file: /cvs/ports/textproc/xpdf/Makefile,v
 retrieving revision 1.83
 diff -u -p -r1.83 Makefile
 --- Makefile  11 Mar 2013 11:42:47 -  1.83
 +++ Makefile  30 May 2014 14:06:49 -
 @@ -2,12 +2,10 @@

  COMMENT= PDF viewer for X11

 -DISTNAME=xpdf-3.03
 -REVISION=0
 +DISTNAME=xpdf-3.04
  CATEGORIES=  textproc x11

  MASTER_SITES=ftp://ftp.foolabs.com/pub/xpdf/ \
 - ftp://gd.tuwien.ac.at/publishing/xpdf/ \
   http://mirror.ctan.org/support/xpdf/

  HOMEPAGE=http://www.foolabs.com/xpdf/
 @@ -15,7 +13,7 @@ HOMEPAGE=   http://www.foolabs.com/xpdf/
  # GPLv2 only or GPLv3 only or both (at our choice)
  PERMIT_PACKAGE_CDROM=Yes

 -LIB_DEPENDS+=x11/openmotif
 +LIB_DEPENDS+=graphics/png x11/openmotif
  USE_GMAKE=   Yes
  CONFIGURE_STYLE=gnu
  CONFIGURE_ARGS=  --enable-multithreaded \
 @@ -29,7 +27,7 @@ MAKE_ENV+=MOTIFLIB='-L${LOCALBASE}/lib -
  RUN_DEPENDS= print/ghostscript/gnu-fonts

  WANTLIB= ICE SM X11 Xext Xpm Xt freetype Xm \
 - c m pthread stdc++ z
 + c m png pthread stdc++ z

  NO_TEST= Yes

 @@ -42,5 +40,9 @@ post-install:
   rm ${PREFIX}/man/man1/$i.1
   rm ${PREFIX}/bin/$i
  .endfor
 +# forgotten in Makefile.in (there's also a pdfthtml, but it conflicts
 +# with poppler-utils):
 + ${INSTALL_PROGRAM} ${WRKBUILD}/xpdf/pdftopng ${PREFIX}/bin
 + ${INSTALL_MAN} ${WRKSRC}/doc/pdftopng.1 ${PREFIX}/man/man1

  .include bsd.port.mk
 Index: distinfo
 ===
 RCS file: /cvs/ports/textproc/xpdf/distinfo,v
 retrieving revision 1.17
 diff -u -p -r1.17 distinfo
 --- distinfo  1 Oct 2011 19:46:35 -   1.17
 +++ distinfo  30 May 2014 13:14:12 -
 @@ -1,5 +1,2 @@
 -MD5 (xpdf-3.03.tar.gz) = r3X3cr7g5a5KgR/50D6sWg==
 -RMD160 (xpdf-3.03.tar.gz) = 7xM2wYkCb7Ds0Wnis3taWqIuBL4=
 -SHA1 (xpdf-3.03.tar.gz) = SZQj6KeV4O/XbKeYI5600NUv4kg=
 -SHA256 (xpdf-3.03.tar.gz) = As9j2PYybtpkQJbND5aeFYhwKthyIsHpOIqTwnD7zso=
 -SIZE (xpdf-3.03.tar.gz) = 795537
 +SHA256 (xpdf-3.04.tar.gz) = ETkMdHM6vLJiqspNtocQ8T///UK/4qCGGl38kSspd+U=
 +SIZE (xpdf-3.04.tar.gz) = 825519
 Index: patches/patch-doc_sample-xpdfrc
 ===
 RCS file: /cvs/ports/textproc/xpdf/patches/patch-doc_sample-xpdfrc,v
 retrieving revision 1.4
 diff -u -p -r1.4 patch-doc_sample-xpdfrc
 --- patches/patch-doc_sample-xpdfrc   1 Oct 2011 19:46:35 -   1.4
 +++ patches/patch-doc_sample-xpdfrc   30 May 2014 13:14:12 -
 @@ -1,6 +1,6 @@
  $OpenBSD: patch-doc_sample-xpdfrc,v 1.4 2011/10/01 19:46:35 kili Exp $
  doc/sample-xpdfrc.orig   Mon Aug 15 23:08:53 2011
 -+++ doc/sample-xpdfrcThu Aug 18 21:10:22 2011
 +--- doc/sample-xpdfrc.orig   Wed May 28 20:50:50 2014
  doc/sample-xpdfrcFri May 30 14:26:13 2014
  @@ -56,7 +56,7 @@

   # Set the default PostScript file or command.
 @@ -10,7 +10,7 @@ $OpenBSD: patch-doc_sample-xpdfrc,v 1.4

   # Set the default PostScript paper size -- this can be letter, legal,
   # A4, or A3.  You can also specify a paper size as width and height
 -@@ -88,5 +88,5 @@
 +@@ -87,5 +87,5 @@
   # Set the command used to run a web browser when a URL hyperlink is
   # clicked.

 Index: patches/patch-splash_Makefile_in
 ===
 RCS file: /cvs/ports/textproc/xpdf/patches/patch-splash_Makefile_in,v
 retrieving revision 1.1
 diff -u -p -r1.1 patch-splash_Makefile_in
 --- patches/patch-splash_Makefile_in  25 Jan 2004 06:02:40 -  1.1
 +++ patches/patch-splash_Makefile_in  30 May 2014 13:14:12 -
 @@ -1,12 +1,12 @@
  $OpenBSD: patch-splash_Makefile_in,v 1.1 2004/01/25 06:02:40 brad Exp $
  splash/Makefile.in.orig  2004-01-24 23:49:23.0 -0500
 -+++ splash/Makefile.in   2004-01-24 23:49:34.0 -0500
 +--- splash/Makefile.in.orig  Wed May 28 20:50:50 2014
  splash/Makefile.in   Fri May 30 14:29:41 2014
  @@ -16,7 +16,7 @@ GOOLIBDIR = ../goo
   FOFISRCDIR = $(srcdir)/../fofi
   FOFILIBDIR = ../fofi

 --CXXFLAGS = @CXXFLAGS@ 

Re: firefox download issue

[patrick keshishian]

On 5/21/14, Fabian Raetz fabian.ra...@gmail.com wrote:
 Hi folks,

 i'm seeing a weird behavour in Firefox 30 beta (it was there already in
 29 though).

 When downloading something, nothing happens.  I opened the
 Show all Downloads Library and saw that there is an entry
 for the downloaded file but either it is marked as Failed or as
 Canceled. After clicking the Retry button, the Download starts as
 expected.

For a (long) while I have seen similar issue. I say similar
because, even though the Downloads window indicates
Failed, the download is inprogress and it completes
properly.

Depending on the server, the download may have slow
initiation time, so it may seem nothing is happening.

Just my observations.
--patrick


 I've recorded a small video which demostrates the issue.
 http://mischi.selfhost.bz/Firefox30beta-SafeMode-Download-issue.webm


 My first suggestion was, that some AddOns like Vimperator messed
 somthing up.  But after installing the Beta i reseted all and started
 in Safe Mode.

 Does anyone else seeing this?


 Regards,
 Fabian

Re: xpdf slow opening postgresql-9.3-US.pdf

[patrick keshishian]

On 5/18/14, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
 previously on this list Stuart Henderson contributed:

 Slow with xpdf for me too. mupdf opens them quickly though.

 There were some arguments on the debian list about removing xpdf as it
 was no longer developed upstream and they had long standing bugs open
 against it. Not sure if that is relevant at all.

The author, Derek Noonburg, got back to me on this.
Two noteworthy points he shared are that the files open
much faster with his development code (due to object
stream cache added) and that he plans to release 3.04
end of this month.

--patrick

xpdf slow opening postgresql-9.3-US.pdf

[patrick keshishian]

Hi,

I noticed with PostgreSQL 9.2.x releases that their
documentation file in PDF (US) format took a
considerable time longer to open using xpdf compared
with the 9.1, and earlier PDF files I had.

With Pg 9.3.x I see the same, so I started to wonder
and noticed that the currently available 9.1 PDF on
their site[1] advertises a much smaller file than what
I have on my local drive: 6.0 MB vs 8.7M respectively.
I grabbed the smaller 9.1 document, and it too takes
a long time to open:

Opening the (smaller) 6M postgresql-9.1-US.pdf (version 9.1.13)
takes 49.54s.[2]

Opening the (larger) 8.7M postgresql-9.1-US.pdf (version 9.1.3)
takes 1.95s.[2]

On a MacBook Pro all documents open so quickly it is
difficult to time them. I am not sure if this is due to some
sinister caching OS X uses or simply a better document
parsing in Preview (and of course, a faster CPU).

Does anyone (with PDF knowledge) know if this is due
to some compression being used in generating these
documents? Obvious guess due to size shrink.

Last update to xpdf was in August 2011, so I'm not
sure if author would be interested in this report, I
will forward a copy of this message to them anyway.

--patrick

[1] http://www.postgresql.org/docs/manuals/
[2] cpu0: AMD E-350 Processor, 1597.54 MHz

Re: new: reop-1.0.0

[patrick keshishian]

On 5/10/14, Ted Unangst t...@tedunangst.com wrote:
 On Fri, May 09, 2014 at 22:20, patrick keshishian wrote:
 Ted, what is the purpose of the first if-statement
 in readident()?

 static char *
 readident(char *buf, char *ident)
 {
  if (IDENTLEN != 64)
  errx(1, wrong IDENTLEN);

 If somebody changes IDENTLEN, it will break the sscanf on the next line.

would it be better as a compile time error?


--- reop.c.orig Sat May 10 12:21:30 2014
+++ reop.c  Sat May 10 12:27:16 2014
@@ -59,7 +59,10 @@
 #define EKCALG eS/* ephemeral-curve25519-Salsa20 */
 #define SYMALG SP/* Salsa20-Poly1305 */
 #define KDFALG BK/* bcrypt kdf */
-#define IDENTLEN 64
+#define IDENTLEN 64/* Do NOT change. See readident() */
+#if IDENTLEN != 64
+#error wrong IDENTLEN
+#endif
 #define FPLEN 8

 /* metadata */
@@ -434,8 +437,6 @@ gethomefile(const char *filename)
 static char *
 readident(char *buf, char *ident)
 {
-   if (IDENTLEN != 64)
-   errx(1, wrong IDENTLEN);
if (sscanf(buf, ident:%63s, ident) != 1)
errx(1, no ident found: %s, buf);
if (!(buf = strchr(buf + 1, '\n')))

Re: new: reop-1.0.0

[patrick keshishian]

On 5/9/14, Ted Unangst t...@tedunangst.com wrote:
 On Fri, May 09, 2014 at 18:09, Ted Unangst wrote:
 On Fri, May 09, 2014 at 19:49, Stuart Henderson wrote:

 Works on amd64, but macppc fails tests:

 ===  Regression tests for reop-1.0.0
 reop: decryption failed

 I'll one up that. It segfaults on sparc64. :(

 This will fix it, at the cost of making startup slow as balls. The one
 second test.sh now takes over 15 seconds to run.

 The libsodium documentation says this isn't required. Obviously, it's
 a crypto library, therefore it lies.

 diff -r b7b0f515429c reop.c
 --- a/reop.cSat Apr 19 11:32:25 2014 -0400
 +++ b/reop.cFri May 09 18:17:07 2014 -0400
 @@ -1054,6 +1054,7 @@
 VERIFY
 } verb = NONE;

 +   sodium_init();

 rounds = 42;

Ted, what is the purpose of the first if-statement
in readident()?

static char *
readident(char *buf, char *ident)
{
if (IDENTLEN != 64)
errx(1, wrong IDENTLEN);
...

given on line 62:

#define IDENTLEN 64


$ cc -E /tmp/reop.c | grep -A3 ^readident
/tmp/reop.c:36:20: error: sodium.h: No such file or directory
readident(char *buf, char *ident)
{
 if (64 != 64)
  errx(1, wrong IDENTLEN);


just curious.
--patrick

Re: postgresql syslog

[patrick keshishian]

On 3/26/14, Jan Stary h...@stare.cz wrote:
 I am trying to setup syslog logging
 for a postgresql 9.3.2 server on current/amd64.
 All goes well except, the postgresql server seems
 to not notice whan the log rotates via newsyslog.

 /var/postgresql/logfile  600  100   *@T00  Z

 When this happens, no fourther messages are logged;
 as if the server hasn't noticed that the logfile
 got rotated under its feet. Sending HUP only makes
 the server reread configuration, not reopen logfiles.

 Is someone using syslog for postgresql,
 and rotating without this problem?

Can't be sure with limited info you provided (where is
your postgresql.conf file?), but, it doesn't sound like
you are using syslogd for postgresql logging. you are
only using newsyslog to rotate the log file.

--patrick

update: graphics/p5-Image-ExifTool

[patrick keshishian]

Update since last CPAN release.

Changes:
http://cpansearch.perl.org/src/EXIFTOOL/Image-ExifTool-9.53/Changes

--patrick
Index: Makefile
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/Makefile,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 Makefile
--- Makefile4 Jul 2013 10:34:16 -   1.30
+++ Makefile23 Mar 2014 05:51:38 -
@@ -2,7 +2,7 @@
 
 COMMENT=   read and write meta information in image/audio/video files
 
-DISTNAME=  Image-ExifTool-9.27
+DISTNAME=  Image-ExifTool-9.53
 CATEGORIES=graphics
 
 HOMEPAGE=  http://owl.phy.queensu.ca/~phil/exiftool/
Index: distinfo
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/distinfo,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 distinfo
--- distinfo4 Jul 2013 10:34:16 -   1.24
+++ distinfo23 Mar 2014 05:51:38 -
@@ -1,2 +1,2 @@
-SHA256 (Image-ExifTool-9.27.tar.gz) = 
zITYHjk4th6w5EwWv7moJbGyUvZHwjnBhZc5o068Z7g=
-SIZE (Image-ExifTool-9.27.tar.gz) = 3618455
+SHA256 (Image-ExifTool-9.53.tar.gz) = 
NRObiF4PdZ+u0Ekaxp6xt2Sh4V+trTJxZIusB0oGAZw=
+SIZE (Image-ExifTool-9.53.tar.gz) = 3747390
Index: pkg/PLIST
===
RCS file: /cvs/obsd/ports/graphics/p5-Image-ExifTool/pkg/PLIST,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 PLIST
--- pkg/PLIST   4 Jul 2013 10:34:17 -   1.20
+++ pkg/PLIST   23 Mar 2014 05:51:38 -
@@ -13,6 +13,7 @@ ${P5SITE}/Image/ExifTool/AIFF.pm
 ${P5SITE}/Image/ExifTool/APE.pm
 ${P5SITE}/Image/ExifTool/APP12.pm
 ${P5SITE}/Image/ExifTool/ASF.pm
+${P5SITE}/Image/ExifTool/Apple.pm
 ${P5SITE}/Image/ExifTool/BMP.pm
 ${P5SITE}/Image/ExifTool/BZZ.pm
 ${P5SITE}/Image/ExifTool/BigTIFF.pm
@@ -57,6 +58,7 @@ ${P5SITE}/Image/ExifTool/Charset/Turkish
 ${P5SITE}/Image/ExifTool/Charset/Vietnam.pm
 ${P5SITE}/Image/ExifTool/DICOM.pm
 ${P5SITE}/Image/ExifTool/DNG.pm
+${P5SITE}/Image/ExifTool/DPX.pm
 ${P5SITE}/Image/ExifTool/DV.pm
 ${P5SITE}/Image/ExifTool/DarwinCore.pm
 ${P5SITE}/Image/ExifTool/DjVu.pm
@@ -163,6 +165,7 @@ ${P5SITE}/Image/ExifTool/Reconyx.pm
 ${P5SITE}/Image/ExifTool/Ricoh.pm
 ${P5SITE}/Image/ExifTool/Samsung.pm
 ${P5SITE}/Image/ExifTool/Sanyo.pm
+${P5SITE}/Image/ExifTool/Scalado.pm
 ${P5SITE}/Image/ExifTool/Shift.pl
 ${P5SITE}/Image/ExifTool/Shortcuts.pm
 ${P5SITE}/Image/ExifTool/Sigma.pm
@@ -174,6 +177,7 @@ ${P5SITE}/Image/ExifTool/TagInfoXML.pm
 ${P5SITE}/Image/ExifTool/TagLookup.pm
 ${P5SITE}/Image/ExifTool/TagNames.pod
 ${P5SITE}/Image/ExifTool/Theora.pm
+${P5SITE}/Image/ExifTool/Torrent.pm
 ${P5SITE}/Image/ExifTool/Unknown.pm
 ${P5SITE}/Image/ExifTool/Vorbis.pm
 ${P5SITE}/Image/ExifTool/WriteCanonRaw.pl
@@ -183,6 +187,7 @@ ${P5SITE}/Image/ExifTool/WritePDF.pl
 ${P5SITE}/Image/ExifTool/WritePNG.pl
 ${P5SITE}/Image/ExifTool/WritePhotoshop.pl
 ${P5SITE}/Image/ExifTool/WritePostScript.pl
+${P5SITE}/Image/ExifTool/WriteQuickTime.pl
 ${P5SITE}/Image/ExifTool/WriteXMP.pl
 ${P5SITE}/Image/ExifTool/Writer.pl
 ${P5SITE}/Image/ExifTool/XMP.pm
@@ -199,6 +204,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::APE.3p
 @man man/man3p/Image::ExifTool::APP12.3p
 @man man/man3p/Image::ExifTool::ASF.3p
+@man man/man3p/Image::ExifTool::Apple.3p
 @man man/man3p/Image::ExifTool::BMP.3p
 @man man/man3p/Image::ExifTool::BZZ.3p
 @man man/man3p/Image::ExifTool::BigTIFF.3p
@@ -212,6 +218,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Charset.3p
 @man man/man3p/Image::ExifTool::DICOM.3p
 @man man/man3p/Image::ExifTool::DNG.3p
+@man man/man3p/Image::ExifTool::DPX.3p
 @man man/man3p/Image::ExifTool::DV.3p
 @man man/man3p/Image::ExifTool::DarwinCore.3p
 @man man/man3p/Image::ExifTool::DjVu.3p
@@ -316,6 +323,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::Ricoh.3p
 @man man/man3p/Image::ExifTool::Samsung.3p
 @man man/man3p/Image::ExifTool::Sanyo.3p
+@man man/man3p/Image::ExifTool::Scalado.3p
 @man man/man3p/Image::ExifTool::Shift.3p
 @man man/man3p/Image::ExifTool::Shortcuts.3p
 @man man/man3p/Image::ExifTool::Sigma.3p
@@ -327,6 +335,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::TagLookup.3p
 @man man/man3p/Image::ExifTool::TagNames.3p
 @man man/man3p/Image::ExifTool::Theora.3p
+@man man/man3p/Image::ExifTool::Torrent.3p
 @man man/man3p/Image::ExifTool::Unknown.3p
 @man man/man3p/Image::ExifTool::Vorbis.3p
 @man man/man3p/Image::ExifTool::WriteCanonRaw.3p
@@ -336,6 +345,7 @@ ${P5SITE}/Image/ExifTool/iWork.pm
 @man man/man3p/Image::ExifTool::WritePNG.3p
 @man man/man3p/Image::ExifTool::WritePhotoshop.3p
 @man man/man3p/Image::ExifTool::WritePostScript.3p
+@man man/man3p/Image::ExifTool::WriteQuickTime.3p
 @man man/man3p/Image::ExifTool::WriteXMP.3p
 @man man/man3p/Image::ExifTool::Writer.3p
 @man man/man3p/Image::ExifTool::XMP.3p

Re: Array bounds warnings

[patrick keshishian]

On 2/7/14, Ted Unangst t...@tedunangst.com wrote:
 On Sat, Feb 08, 2014 at 01:32, Christian Weisgerber wrote:
 Back in January, there was this commit to gcc:

 Enable Wbounded by default.  Passing bound bigger than the buffer
 size almost always has security implications.

 Very interesting set of errors. Just based on a quick read through the
 log file:

 ./audio/rioutil.log:rio.c:650: warning: array size (16) smaller than
 bound
 length (17)

 There's some like this that look like obvious off by ones.

 ./audio/pms.log:src/libmpdclient.c:396: warning: array size (1001)
 smaller
 than bound length (5)

 There's some like this where you wonder how the two lengths could
 possibly be related.

 ./audio/festival/core.log:EST_Chunk.cc:336: warning: array size (1)
 smaller than bound length (20)

 There's a lot of size 1 warnings, which I'd guess are uses of the
 struct hack and probably lower priority.

you don't like those?

 ./audio/soundtracker.log:gui.c:1609: warning: non-positive bounds length
 (-1) detected

 WTF?

my guess: pointer into some buffer, and doing a look-back
for last character in said buffer.

char *p = somebuf;
for (...) {
if (*p == 'r'  p[-1] == '\\')
printf(or something like that...\n);
}

meh,
--patrick

 ./audio/audacious-plugins.log:Gb_Apu.cxx:126: warning: array size (16)
 smaller than bound length (32)
 ./audio/milkytracker.log:ExporterXM.cpp:70: warning: array size (256)
 smaller than bound length (1024)

 And there's quite a few that are off by a multiple of two or four.

Re: PostgreSQL: Critical update !

[patrick keshishian]

err...

 Index: pkg/PLIST-plpython
 ===
 RCS file: /cvs/ports/databases/postgresql/pkg/PLIST-plpython,v
 retrieving revision 1.1
 diff -u -p -u -p -r1.1 PLIST-plpython
 --- pkg/PLIST-plpython15 Oct 2013 02:18:19 -  1.1
 +++ pkg/PLIST-plpython29 Dec 2013 20:50:40 -
 @@ -1,5 +1,6 @@
  @comment $OpenBSD: PLIST-plpython,v 1.1 2013/10/15 02:18:19 jeremy Exp $
  lib/postgresql/plpython2.so
 +share/doc/pkg-readmes/${FULLPKGNAME\-plpython}

should be ${FULLPKGNAME}. packaging fails on my -current
(snapshot from 2013-DEC-28) otherwise.

  share/postgresql/extension/plpython2u--1.0.sql
  share/postgresql/extension/plpython2u--unpackaged--1.0.sql
  share/postgresql/extension/plpython2u.control
 Index: pkg/PLIST-server


On 12/29/13, Pierre-Emmanuel André p...@raveland.org wrote:
 Hi,

 The PostgreSQL group has released a critical update to all
 supported versions of PostgreSQL databases.
 This update fixes three serious data-loss bugs affecting
 replication and database maintenance.

 Annoucement: http://www.postgresql.org/about/news/1492/
 More informations here:
 https://wiki.postgresql.org/wiki/Nov2013ReplicationIssue

 I made a diff for:
 + -current (PostgreSQL 9.3.2, tested on @amd64)
 + 5.4 -stable (PostgreSQL 9.2.6, tested on @amd64)
 + 5.3 -stable (PostgreSQL 9.2.6, NOT tested but it should work. If anyone
 has a 5.3 system it would
 be nice to give it a try)

 Comments/OK ?

 Regards,


 --
 Pierre-Emmanuel André pea at raveland.org
 GPG key: 0x487CE475

Re: [new] fonts/hermit-ttf

[patrick keshishian]

On 9/16/13, Aaron def...@gmail.com wrote:
 On Mon, Sep 16, 2013 at 9:33 AM, Aaron def...@gmail.com wrote:
 On Mon, Sep 16, 2013 at 9:23 AM, Aaron def...@gmail.com wrote:
 On Mon, Sep 16, 2013 at 9:03 AM, Stuart Henderson st...@openbsd.org
 wrote:
 On 2013/09/16 08:22, Aaron wrote:
 Hola!

 New font: Hermit is a monospace font designed to be clear, pragmatic
 and very readable. Its creation has been focused on programming. Every
 glyph was carefully planned and calculated, according to defined
 principles and rules. For this reason, Hermit is coherent and regular.

 OK?

 I'd probably install this as hermit.ttf rather than hermit-1.01.ttf,
 what do you think?


 Sounds good, I also added # OFL 1.1 per bcallah@.


 New version with ttf file renamed to hermit.ttf - also added OFL version.

 OK?


 Heeen

Curious about this font. After looking at author's page and
examples he has up there, I am starting to wonder why this
fonts looks soft on my system. Any ideas?

--patrick

Re: x11/blackbox: time_t fix (too late i see .. but please read)

[patrick keshishian]

On 8/18/13, patrick keshishian sids...@boxsoft.com wrote:
 Swaping accounts for sending diff in-line and not have
 gmail fuck it up.

 On Sat, Aug 17, 2013 at 20:03:32 -0600, Theo de Raadt wrote:
So basically, this takes a long long value, and casts it to a long.
  
   Yes, but that's not the entire story.
  
   the function declaration is: long nextTimeout(int resolution)
  
   So it would truncate anyway. But look at it closer. It
   takes the value of timeval.tv_sec (your time_t / long long)
   and mod's it with resolution (an int value). The only thing
   it then does is multiply it by 1000L.
  
   The only reason this function broke is C++'s std::max()
   defined as a template function, requiring both args be of
   the same typename. Since the original code uses 1000L
   literal for the first arg, the compiler was having issues with
   the long long as the second arg., but ...
  
   What is long long % int? another int value? Yes, I realize
   it would be a long long according to the compiler, but,
   I fail to see where/how 0x % 0xFF would
   ever be greater than 0xfe.
  
   As is, the best you can expect from that function is a long
   second argument for std::max(). Unless I'm completely missing
   something here (and I'll certainly budget for that possibility).
 
  You're completely missing the point.
 
  We provide an opportunity to the entire community to fix things
  in the best way possible.
 
  And you squander it.
 
  The solution is to take all the subsystems and arguments to time_t,
  throughout the entire program, and then do the best from there.
 
  Instead, you chose to prematurely downcast.

 Now, before you say this is impossible or ridiculous, let me say this.

 We did what I suggest to the entire base tree, before the kernel
 changes were commited.  If we can do this to the entire base tree
 system -- something much much larger than the average package, then
 people working in the ports tree can at least try to not squander
 the opportunity.

 Please  thanks.


 unsquandering ... (hopefully)

 The reason for the extra REVISION bump is for ajacoutot@'s
 patch-src_Toolbar_cc addition (it missed the bump?).

 Minimally tested.

well?

Also, would like to (again) bring attention to this patch:

http://marc.info/?l=openbsd-portsm=137339931231574w=2

--patrick


 Index: Makefile
 ===
 RCS file: /cvs/obsd/ports/x11/blackbox/Makefile,v
 retrieving revision 1.51
 diff -u -p -u -p -r1.51 Makefile
 --- Makefile  21 Mar 2013 08:48:55 -  1.51
 +++ Makefile  18 Aug 2013 07:14:22 -
 @@ -1,9 +1,9 @@
 -# $OpenBSD: Makefile,v 1.50 2013/03/11 11:46:08 espie Exp $
 +# $OpenBSD: Makefile,v 1.51 2013/03/21 08:48:55 ajacoutot Exp $

  COMMENT= small  pretty window manager for 8 and more bits displays

  DISTNAME=blackbox-0.70.1
 -REVISION=2
 +REVISION=4
  CATEGORIES=  x11

  HOMEPAGE=http://blackboxwm.sourceforge.net/
 Index: patches/patch-lib_Resource_cc
 ===
 RCS file: patches/patch-lib_Resource_cc
 diff -N patches/patch-lib_Resource_cc
 --- /dev/null 1 Jan 1970 00:00:00 -
 +++ patches/patch-lib_Resource_cc 18 Aug 2013 07:14:22 -
 @@ -0,0 +1,20 @@
 +$OpenBSD$
 +
 +64bit time_t fix.
 +
 +--- lib/Resource.cc.orig Wed Apr  6 14:16:50 2005
  lib/Resource.cc  Sat Aug 17 22:26:11 2013
 +@@ -207,6 +207,13 @@ void bt::Resource::write(const char* resource,
 unsigne
 + }
 +
 +
 ++void bt::Resource::write(const char* resource, unsigned long long value)
 {
 ++  char tmp[64];
 ++  sprintf(tmp, %llu, value);
 ++  write(resource, tmp);
 ++}
 ++
 ++
 + void bt::Resource::write(const char* resource, bool value)
 + { write(resource, boolAsString(value)); }
 +
 Index: patches/patch-lib_Resource_hh
 ===
 RCS file: patches/patch-lib_Resource_hh
 diff -N patches/patch-lib_Resource_hh
 --- /dev/null 1 Jan 1970 00:00:00 -
 +++ patches/patch-lib_Resource_hh 18 Aug 2013 07:14:22 -
 @@ -0,0 +1,14 @@
 +$OpenBSD$
 +
 +64bit time_t fix.
 +
 +--- lib/Resource.hh.orig Mon Jan  3 01:42:52 2005
  lib/Resource.hh  Sat Aug 17 22:25:59 2013
 +@@ -78,6 +78,7 @@ namespace bt {
 + void write(const char* resource, unsigned int value);
 + void write(const char* resource, long value);
 + void write(const char* resource, unsigned long value);
 ++void write(const char* resource, unsigned long long value);
 + void write(const char* resource, bool value);
 + void write(const char* resource, double value);
 +
 Index: patches/patch-lib_Timer_cc
 ===
 RCS file: patches/patch-lib_Timer_cc
 diff -N patches/patch-lib_Timer_cc
 --- /dev/null 1 Jan 1970 00:00:00 -
 +++ patches/patch-lib_Timer_cc18 Aug 2013 07:14:22 -
 @@ -0,0 +1,25

Re: x11/blackbox: time_t fix (too late i see .. but please read)

[patrick keshishian]

Attaching a new diff which includes both sets of patches
mentioned in this thread. As a bonus, includes two new
patch files to silence warnings about deprecated conversion
from string constant to 'char*'.

--patrick


blackbox.diff
Description: Binary data

Re: Java Development Kit and Icedtea

[patrick keshishian]

On 8/21/13, Stuart Henderson st...@openbsd.org wrote:
 On 2013/08/21 22:15, Pascal Stumpf wrote:
 On Wed, 21 Aug 2013 13:47:03 -0500, eagir...@cox.net wrote:
  Having installed the 64 bit time snapshots (amd64), I have reinstalled
  packages. Except that the jdks used to have packages, and don't. Will
  they be coming back? Can't build a new icedtea plugin without them

 Yes, they will be back as soon as they have been re-bootstrapped for
 64bit time_t.

 It's likely to be more than just a bootstrap problem - at least there are
 no bad system call messages with T32 but the internal self-tests in the
 build fail (and if you patch away the tests, other things fail later)...

 Anyone who has ideas about how to fix it, feel free to send a mail ;)

rm comes to mind ...

Re: x11/blackbox: time_t fix (too late i see .. but please read)

[patrick keshishian]

Swaping accounts for sending diff in-line and not have
gmail fuck it up.

On Sat, Aug 17, 2013 at 20:03:32 -0600, Theo de Raadt wrote:
So basically, this takes a long long value, and casts it to a long.
   
   Yes, but that's not the entire story.
   
   the function declaration is: long nextTimeout(int resolution)
   
   So it would truncate anyway. But look at it closer. It
   takes the value of timeval.tv_sec (your time_t / long long)
   and mod's it with resolution (an int value). The only thing
   it then does is multiply it by 1000L.
   
   The only reason this function broke is C++'s std::max()
   defined as a template function, requiring both args be of
   the same typename. Since the original code uses 1000L
   literal for the first arg, the compiler was having issues with
   the long long as the second arg., but ...
   
   What is long long % int? another int value? Yes, I realize
   it would be a long long according to the compiler, but,
   I fail to see where/how 0x % 0xFF would
   ever be greater than 0xfe.
   
   As is, the best you can expect from that function is a long
   second argument for std::max(). Unless I'm completely missing
   something here (and I'll certainly budget for that possibility).
  
  You're completely missing the point.
  
  We provide an opportunity to the entire community to fix things
  in the best way possible.
  
  And you squander it.
  
  The solution is to take all the subsystems and arguments to time_t,
  throughout the entire program, and then do the best from there.
  
  Instead, you chose to prematurely downcast.
 
 Now, before you say this is impossible or ridiculous, let me say this.
 
 We did what I suggest to the entire base tree, before the kernel
 changes were commited.  If we can do this to the entire base tree
 system -- something much much larger than the average package, then
 people working in the ports tree can at least try to not squander
 the opportunity.
 
 Please  thanks.


unsquandering ... (hopefully)

The reason for the extra REVISION bump is for ajacoutot@'s
patch-src_Toolbar_cc addition (it missed the bump?).

Minimally tested.


Index: Makefile
===
RCS file: /cvs/obsd/ports/x11/blackbox/Makefile,v
retrieving revision 1.51
diff -u -p -u -p -r1.51 Makefile
--- Makefile21 Mar 2013 08:48:55 -  1.51
+++ Makefile18 Aug 2013 07:14:22 -
@@ -1,9 +1,9 @@
-# $OpenBSD: Makefile,v 1.50 2013/03/11 11:46:08 espie Exp $
+# $OpenBSD: Makefile,v 1.51 2013/03/21 08:48:55 ajacoutot Exp $
 
 COMMENT=   small  pretty window manager for 8 and more bits displays
 
 DISTNAME=  blackbox-0.70.1
-REVISION=  2
+REVISION=  4
 CATEGORIES=x11
 
 HOMEPAGE=  http://blackboxwm.sourceforge.net/
Index: patches/patch-lib_Resource_cc
===
RCS file: patches/patch-lib_Resource_cc
diff -N patches/patch-lib_Resource_cc
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_Resource_cc   18 Aug 2013 07:14:22 -
@@ -0,0 +1,20 @@
+$OpenBSD$
+
+64bit time_t fix.
+
+--- lib/Resource.cc.orig   Wed Apr  6 14:16:50 2005
 lib/Resource.ccSat Aug 17 22:26:11 2013
+@@ -207,6 +207,13 @@ void bt::Resource::write(const char* resource, unsigne
+ }
+ 
+ 
++void bt::Resource::write(const char* resource, unsigned long long value) {
++  char tmp[64];
++  sprintf(tmp, %llu, value);
++  write(resource, tmp);
++}
++
++
+ void bt::Resource::write(const char* resource, bool value)
+ { write(resource, boolAsString(value)); }
+ 
Index: patches/patch-lib_Resource_hh
===
RCS file: patches/patch-lib_Resource_hh
diff -N patches/patch-lib_Resource_hh
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_Resource_hh   18 Aug 2013 07:14:22 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+64bit time_t fix.
+
+--- lib/Resource.hh.orig   Mon Jan  3 01:42:52 2005
 lib/Resource.hhSat Aug 17 22:25:59 2013
+@@ -78,6 +78,7 @@ namespace bt {
+ void write(const char* resource, unsigned int value);
+ void write(const char* resource, long value);
+ void write(const char* resource, unsigned long value);
++void write(const char* resource, unsigned long long value);
+ void write(const char* resource, bool value);
+ void write(const char* resource, double value);
+ 
Index: patches/patch-lib_Timer_cc
===
RCS file: patches/patch-lib_Timer_cc
diff -N patches/patch-lib_Timer_cc
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-lib_Timer_cc  18 Aug 2013 07:14:22 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+64bit time_t fix.
+
+--- lib/Timer.cc.orig  Fri Mar 18 01:07:09 2005
 lib/Timer.cc   Sat Aug 17 22:43:13 2013
+@@ -28,8 +28,7 @@
+ 
+ 
+ bt::timeval::timeval(const ::timeval t)
+-  : tv_sec(t.tv_sec), 

Re: x11/blackbox: time_t fix (too late i see .. but please read)

[patrick keshishian]

On 8/18/13, Christian Weisgerber na...@mips.inka.de wrote:
 patrick keshishian sids...@boxsoft.com wrote:

 unsquandering ... (hopefully)

 I think most of this is pointless and misleading.  The timeout value
 that is passed around is NOT a time_t.  It's a time offset in the
 range 0 .. 3600*1000 milliseconds.  Putting it into a time_t is an
 abuse of that type.

I agree. The purpose of nextTimeout(), seems to be, to returning
an interval in milliseconds. That is then passed to Timer::setTimeout().

--patrick


 +--- lib/Timer.hh.orig   Fri Mar 18 01:07:09 2005
  lib/Timer.hhSat Aug 17 22:43:03 2013
 +@@ -37,16 +37,12 @@ struct timeval;
 + namespace bt {
 +
 +   // use a wrapper class to avoid the header as well
 +-  struct timeval {
 +-long tv_sec;
 +-long tv_usec;
 ++  struct timeval : public ::timeval {

 Now THIS is a good catch.

 --
 Christian naddy Weisgerber  na...@mips.inka.de

Re: x11/blackbox: time_t fix (too late i see .. but please read)

[patrick keshishian]

On 8/18/13, Matthew Dempsky matt...@dempsky.org wrote:
 On Sun, Aug 18, 2013 at 2:43 AM, patrick keshishian sids...@boxsoft.com
 wrote:
 + bt::timeval::timeval(const ::timeval t)
 +-  : tv_sec(t.tv_sec), tv_usec(t.tv_usec)
 +-{ }
 ++{ tv_sec = t.tv_sec; tv_usec = t.tv_usec; }

 What's the point of these changes?

The bt::timeval struct's definition changed. tv_sec and tv_usec are
no longer direct members, and can not be initialized as before.

--patrick

x11/blackbox: time_t fix (too late i see .. but please read)

[patrick keshishian]

Hi,

I see naddy@ already commited a fix for this from NetBSD. Thank
you!

My patch fwiw was to cast second arg to std::max() to long.

$OpenBSD$
--- src/Toolbar.cc.orig Sat Aug 17 16:58:14 2013
+++ src/Toolbar.cc  Sat Aug 17 17:08:12 2013
@@ -44,7 +44,7 @@ long nextTimeout(int resolution)
 {
   timeval now;
   gettimeofday(now, 0);
-  return (std::max(1000l, resolution - (now.tv_sec % resolution)) * 1000l))
+  return (std::max(1000l, (long)resolution - (now.tv_sec %
resolution)) * 1000l))
- (now.tv_usec / 1000l;
 }

anyway, while on topic of x11/blackbox, i posted a patch on July 9th
to fix title bar issue with UTF8 sequence. See details in my original
post:

http://marc.info/?l=openbsd-portsm=137339931231574w=2

Can I ask someone to review/commit this patch as well?

Cheers,
--patrick

Re: x11/blackbox: time_t fix (too late i see .. but please read)

[patrick keshishian]

On 8/17/13, Theo de Raadt dera...@cvs.openbsd.org wrote:
 I see naddy@ already commited a fix for this from NetBSD. Thank
 you!

 My patch fwiw was to cast second arg to std::max() to long.

 $OpenBSD$
 --- src/Toolbar.cc.orig  Sat Aug 17 16:58:14 2013
 +++ src/Toolbar.cc   Sat Aug 17 17:08:12 2013
 @@ -44,7 +44,7 @@ long nextTimeout(int resolution)
  {
timeval now;
gettimeofday(now, 0);
 -  return (std::max(1000l, resolution - (now.tv_sec % resolution)) *
 1000l))
 +  return (std::max(1000l, (long)resolution - (now.tv_sec %
 resolution)) * 1000l))
 - (now.tv_usec / 1000l;
  }

 So basically, this takes a long long value, and casts it to a long.

Yes, but that's not the entire story.

the function declaration is: long nextTimeout(int resolution)

So it would truncate anyway. But look at it closer. It
takes the value of timeval.tv_sec (your time_t / long long)
and mod's it with resolution (an int value). The only thing
it then does is multiply it by 1000L.

The only reason this function broke is C++'s std::max()
defined as a template function, requiring both args be of
the same typename. Since the original code uses 1000L
literal for the first arg, the compiler was having issues with
the long long as the second arg., but ...

What is long long % int? another int value? Yes, I realize
it would be a long long according to the compiler, but,
I fail to see where/how 0x % 0xFF would
ever be greater than 0xfe.

As is, the best you can expect from that function is a long
second argument for std::max(). Unless I'm completely missing
something here (and I'll certainly budget for that possibility).

--patrick


 So, on a 32 bit machine, that throws away the high bits.

 Meaning it will make it compile today, but it will break in 2038.

 So, let me summarize.  the transition to 'long long' exposes a real
 problem.  The addition of this (long) cast now hides the problem; so
 that sometime further into the future someone is going to have a
 harder time fixing it right.

 That is wrong.

Re: ports build failures [mostly 64-bit time_t]

[patrick keshishian]

On Friday, August 16, 2013, David Coppa wrote:

 On Thu, 15 Aug 2013, Christian Weisgerber wrote:

  My list (amd64, plain GENERIC.MP) looks a lot like sthen's:

 ...

  x11/blackbox

 IMHO this is a candidate for the Attic.


boo! i use it :(


 Latest release is dated Nov 3rd, 2005.
 There're valid and more up-to-date alternatives in our tree, like
 fluxbox or openbox.


both are shit alts. openbox is xml-ifed nightmare wrt its config files
(last time i looked, admitedly ages ago). fluxbox is better, but its
behavior is quite different than blackbox.

-pk


Ciao,
 David

Re: ports build failures [mostly 64-bit time_t]

[patrick keshishian]

On Friday, August 16, 2013, David Coppa wrote:

 On Fri, Aug 16, 2013 at 3:46 PM, patrick keshishian 
 pkesh...@gmail.comjavascript:;
 wrote:
 
 
  On Friday, August 16, 2013, David Coppa wrote:
 
  On Thu, 15 Aug 2013, Christian Weisgerber wrote:
 
   My list (amd64, plain GENERIC.MP) looks a lot like sthen's:
 
  ...
 
   x11/blackbox
 
  IMHO this is a candidate for the Attic.
 
 
  boo! i use it :(

 Then fix it ;)


give me a chance to get a new snapshot and look at it. i'm not as fast as
you guys.

-pk

Re: ports build failures [mostly 64-bit time_t]

[patrick keshishian]

On 8/16/13, patrick keshishian pkesh...@gmail.com wrote:
 On Friday, August 16, 2013, David Coppa wrote:

 On Fri, Aug 16, 2013 at 3:46 PM, patrick keshishian
 pkesh...@gmail.comjavascript:;
 wrote:
 
 
  On Friday, August 16, 2013, David Coppa wrote:
 
  On Thu, 15 Aug 2013, Christian Weisgerber wrote:
 
   My list (amd64, plain GENERIC.MP) looks a lot like sthen's:
 
  ...
 
   x11/blackbox
 
  IMHO this is a candidate for the Attic.
 
 
  boo! i use it :(

 Then fix it ;)


 give me a chance to get a new snapshot and look at it. i'm not as fast as
 you guys.

Obviously I'm very confused.

I just installed the amd64 snapshot that is out there. I have
obviously done something extremely wrong here. I grabbed
the install54.iso, but now I realize that that file has a time
stamp of Jul 30, and:

$ sysctl kern.version
kern.version=OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 15:24:05 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

although, the installed files, e.g., /bsd, /bsd.rd, /boot, etc.
have time stamp of Aug 16.

time_t has sizeof 4.

Which snapshot am I supposed to install?

--patrick

firefox-22: missing print-to-file option?

[patrick keshishian]

Hi,

I don't have a printer configured, and I hardly ever have a need
to print. However, the few times I do end up printing things,
especially web content, I use ff's print-to-file option (pdf/ps
output).

Tonight, I had a need to take a hardcopy of an email (gmail) to a
meeting, and noticed that the option to print to file is now missing
in ff-22, which I built from ports after my last snapshot[1] install.

Anyone know if this is/was broken in ff-22 or if the issue is entirely
on my end? If the former, is there a remedy in works for future ff
release and/or port?

Thanks,
--patrick

[1] $ sysctl kern.version
kern.version=OpenBSD 5.3-current (GENERIC.MP) #18: Sat Jul  6 16:54:29 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Re: firefox-22: missing print-to-file option?

[patrick keshishian]

On 8/15/13, James Turner ja...@calminferno.net wrote:
 On Thu, Aug 15, 2013 at 07:11:22AM -0700, patrick keshishian wrote:
 Hi,

 I don't have a printer configured, and I hardly ever have a need
 to print. However, the few times I do end up printing things,
 especially web content, I use ff's print-to-file option (pdf/ps
 output).

 Tonight, I had a need to take a hardcopy of an email (gmail) to a
 meeting, and noticed that the option to print to file is now missing
 in ff-22, which I built from ports after my last snapshot[1] install.

 Anyone know if this is/was broken in ff-22 or if the issue is entirely
 on my end? If the former, is there a remedy in works for future ff
 release and/or port?

 Thanks,
 --patrick

 [1] $ sysctl kern.version
 kern.version=OpenBSD 5.3-current (GENERIC.MP) #18: Sat Jul  6 16:54:29 MDT
 2013
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


 You can add something like the following in your .gtkrc-2.0.

 gtk-print-backends = file,lpr

 Of course you can leave of lpr if you only want file. This should affect
 all gtk2 apps not just firefox.


Thanks for the quick reply James. I don't have a .gtkrc-2.0 file, but
I crated one with the line you specified (copy-and-pasted) and
restarted ff-22. But did not observe any change.

Hmm...
--patrick

Re: firefox-22: missing print-to-file option?

[patrick keshishian]

On 8/15/13, Scott McEachern sc...@blackstaff.ca wrote:
 On 08/15/13 10:11, patrick keshishian wrote:
 Hi,

 I don't have a printer configured, and I hardly ever have a need
 to print. However, the few times I do end up printing things,
 especially web content, I use ff's print-to-file option (pdf/ps
 output).

 Tonight, I had a need to take a hardcopy of an email (gmail) to a
 meeting, and noticed that the option to print to file is now missing
 in ff-22, which I built from ports after my last snapshot[1] install.

 Anyone know if this is/was broken in ff-22 or if the issue is entirely
 on my end? If the former, is there a remedy in works for future ff
 release and/or port?

 Thanks,
 --patrick

 [1] $ sysctl kern.version
 kern.version=OpenBSD 5.3-current (GENERIC.MP) #18: Sat Jul  6 16:54:29 MDT
 2013
  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


 Odd, because I'm using ffx 22 as well, also built from ports, on

 $ sysctl kern.version
 kern.version=OpenBSD 5.4-beta (GENERIC.MP) #26: Thu Jul 11 15:38:31 MDT
 2013
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

 and I can print to file just fine.  Just tested now by viewing a page in
 PDF form (epdfview) without a problem.

Thanks Scott. I wonder what I fudged up. Thanks for the confirmation.

--patrick



 --
 Scott McEachern

 https://www.blackstaff.ca

 Those who would give up essential liberty to purchase a little temporary
 safety deserve neither liberty nor safety. -- Benjamin Franklin

Re: firefox-22: missing print-to-file option?

[patrick keshishian]

I have spent some time searching on-line without success.
I have seen suggestions of resetting print.print_printer and
print.printer setting in about:config and restarting ff. I have
tried these without success.

I'm curious, for those who have success selecting print to
file from ff-22 (e.g., Scott McEachern if kind enough) can
you tell me what your about:config says for following
setting items?

print.print_printer
print.printer_list

Anyone else have any ideas I can/should try? Short of trying
a new snapshot (I think I'll wait after the storm to clear before
attempting a snapshot upgrade).

Incidentally, I am not running any modern desktop environment,
if that is potentially the problem of gtk2 not configuring the/any
printer settings, or whatever modern desktop utility ff is
depending on to select printers.

Previously, with ff-18, this worked just fine.

Thanks for reading/replying.
--patrick


On 8/15/13, patrick keshishian pkesh...@gmail.com wrote:
 On 8/15/13, Scott McEachern sc...@blackstaff.ca wrote:
 On 08/15/13 10:11, patrick keshishian wrote:
 Hi,

 I don't have a printer configured, and I hardly ever have a need
 to print. However, the few times I do end up printing things,
 especially web content, I use ff's print-to-file option (pdf/ps
 output).

 Tonight, I had a need to take a hardcopy of an email (gmail) to a
 meeting, and noticed that the option to print to file is now missing
 in ff-22, which I built from ports after my last snapshot[1] install.

 Anyone know if this is/was broken in ff-22 or if the issue is entirely
 on my end? If the former, is there a remedy in works for future ff
 release and/or port?

 Thanks,
 --patrick

 [1] $ sysctl kern.version
 kern.version=OpenBSD 5.3-current (GENERIC.MP) #18: Sat Jul  6 16:54:29
 MDT
 2013

 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP


 Odd, because I'm using ffx 22 as well, also built from ports, on

 $ sysctl kern.version
 kern.version=OpenBSD 5.4-beta (GENERIC.MP) #26: Thu Jul 11 15:38:31 MDT
 2013
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

 and I can print to file just fine.  Just tested now by viewing a page in
 PDF form (epdfview) without a problem.

 Thanks Scott. I wonder what I fudged up. Thanks for the confirmation.

 --patrick



 --
 Scott McEachern

 https://www.blackstaff.ca

 Those who would give up essential liberty to purchase a little temporary
 safety deserve neither liberty nor safety. -- Benjamin Franklin

Re: firefox-22: missing print-to-file option?

[patrick keshishian]

On 8/15/13, Scott McEachern sc...@blackstaff.ca wrote:
 On 08/15/13 23:04, patrick keshishian wrote:
 I have spent some time searching on-line without success.
 I have seen suggestions of resetting print.print_printer and
 print.printer setting in about:config and restarting ff. I have
 tried these without success.

 I'm curious, for those who have success selecting print to
 file from ff-22 (e.g., Scott McEachern if kind enough) can
 you tell me what your about:config says for following
 setting items?

  print.print_printer
  print.printer_list

 Anyone else have any ideas I can/should try? Short of trying
 a new snapshot (I think I'll wait after the storm to clear before
 attempting a snapshot upgrade).

 Incidentally, I am not running any modern desktop environment,
 if that is potentially the problem of gtk2 not configuring the/any
 printer settings, or whatever modern desktop utility ff is
 depending on to select printers.

 Previously, with ff-18, this worked just fine.



 print_printer (not print.print_printer) is user set, string, and
 Print to File
 print.printer_list is default and string.  No value is set.

Thanks Scott!

I know this is an old post (couldn't find anything newer), but
is mentioned print.print_printer (and it was in my about:config):

http://kb.mozillazine.org/Problems_printing_web_pages



 FWIW, ffx 22 was compiled using dpb on a bog-standard install with no
 special compile options.  I have a ton of addons (noscript, adblockplus,
 ghostery, etc.) but none of them involve printing.  I do not have a
 physical printer attached.

mine compiled with 'make install'

 I'm not running any fancy desktop either, just spectrwm, but a lot of
 crap is still installed because I used this box to build the packages
 (that I use) from the July 11th snapshot.

good to know.

 $ pkg_info|grep gtk
 atk-2.8.0   accessibility toolkit used by gtk+
 gdk-pixbuf-2.28.2p1 graphic library for gtk+2
 gtk+2-2.24.20p1 multi-platform graphical toolkit
 gtk+3-3.8.2p3   multi-platform graphical toolkit
 gtk-update-icon-cache-2.24.20 gtk+ icon theme caching utility
 py-gtk2-2.24.0p1GTK+2 Python bindings

Identical in my case as well:

$ pkg_info | grep -e gtk -e cairo
atk-2.8.0   accessibility toolkit used by gtk+
cairo-1.12.14p0 vector graphics library
gdk-pixbuf-2.28.2p1 graphic library for gtk+2
gtk+2-2.24.20p1 multi-platform graphical toolkit
gtk+3-3.8.2p3   multi-platform graphical toolkit
gtk-update-icon-cache-2.24.20 gtk+ icon theme caching utility
py-cairo-1.10.0p1   cairo bindings for Python
py-gtk2-2.24.0p1GTK+2 Python bindings


 Also, a new snapshot appeared today, presumably with the 64-bit time
 stuff.  There's a t32 directory under the amd64 snaps which I've never
 seen before, and presumably that's a snap from before the time switch.
 I'm downloading the new snap (64-bit) now and will give it a whirl, but
 it won't be finished for at least 8h.

Unless anyone else chimes in, I'll see when I have some down-
time to do an upgrade. Most likely following weekend.

Thanks for your time Scott!
--patrick


 --
 Scott McEachern

 https://www.blackstaff.ca

 Those who would give up essential liberty to purchase a little temporary
 safety deserve neither liberty nor safety. -- Benjamin Franklin

Re: Firefox and the ports tree LOCKED

[patrick keshishian]

On Mon, Jul 22, 2013 at 8:00 AM, Kenneth R Westerback
kwesterb...@rogers.com wrote:
 On Mon, Jul 22, 2013 at 10:01:25AM +0300, Lars Engblom wrote:
 Then I was right regarding how well known the bugs are. ??As you wrote, 
 there are even known workarounds.

 There are steps to diagnose YOUR problem and things to try that work for OTHER
 PEOPLE. Who knows what your problems are until you tell us. Even if it is
 the identical problem, your problem report could have that single new bit
 of information that reveals all.


 That I did not want to make double bug reports for something already 
 reported should be understandable.??


 Nope.

 Also, somebody new to openbsd will not search the mail archives for 
 workarounds. They expect things to work out of box. Should not the 
 workarounds be enabled by default then???

 Anybody new to OpenBSD will either not report bugs in which case we don't
 know about them or their problems, or be told in the gentle OpenBSD way to
 RTFML.

Since you bring it up... /or/ when a problem gets reported, even with
great detail, it goes ignored.

it's a crapshoot.

at least be honest about the reality of things.

--patrick



  Ken


 I would not consider myself to be whiny in this case as I long time ago 
 noticed the reports and been patiently been waiting without whining hoping 
 the problem would get a solution. Also it is not for own benefit i am 
 complaining. I'm managing well (and I do not even run stable at home).??

  Original message 
 From: Landry Breuil lan...@rhaalovely.net
 Date: 22/07/2013  08:49  (GMT+02:00)
 To: ports@openbsd.org
 Subject: Re: Firefox and the ports tree LOCKED

 On Mon, Jul 22, 2013 at 07:56:31AM +0300, Lars Engblom wrote:
  I have several times seen reports about FF crashing. It might have
  been here or then on #openbsd (I am not sure where). I thought this
  is something everybody knows. I made a misjudgement because I did
  not want to send a bug-report for something I thought everybody knew
  already.
 
  What I sent to the list today was not a bug report either, I was
  more raising the concern that the maintainer might need more time to
  get it stable even though the tree is in lock and no big changes
  should be allowed.
 
  This problem might be related to drivers also. My laptop at home is
  using i915, which has seen quite a bit of development during the
  latest cycle. I am using amd64 snapshots. The pictures often get
  horizontal stripes. HTML5 videos often crashes it completely, so
  also a bit more intensive java scripts.
 
  I can manage with Chromium, as it is not crashing. The problem is
  not that big deal for me (although it is annoying). I am more
  concerned about the reputation my favorite OS gets if FF gets
  released in this shape.
 
  I am not a good C programmer (my code can be dangerous) and I am
  unable of debugging C, but I am willing to do by instruction what
  anyone wants me to do in order to help in this case.

 You just need to use common sense.

 - try with a fresh empty profile
 - try to reset your regular profile (see about:support)
 - collect backtraces of crashes, open bugs upstream  cc me
 - gfx issues with pictures are known and have been discussed here, try
 ?? the various workarounds devised in the archives. (about:config
 gfx.xrender.enabled, layers.acceleration.enabled,
 MOZ_DISABLE_IMAGE_OPTIMIZE=1 in the env... see
 http://marc.info/?l=openbsd-portsm=136560946723949w=2)

 Of course, i'm using firefox all the time on all my computers, and i
 dont see such OMGSOUNSTABLE behaviour. It crashes with OOM sometimes with
 heavy javascript, gobbles all cpu when viewing huge images, but besides
 that it's totally usable.

  I have been following snapshots the whole time and this problems in FF
  has been since the spring.

 Yeah, great timing to come whining... nothing will happen for 5.4.

 Landry

[patch] x11/blackbox

[patrick keshishian]

Hi,

This patch fixes an annoyance, which started some time ago, when
firefox started using UTF-8 sequence \302\240\303\227\302\240 in
between image dimensions (e.g., 800 x 600) for its X window title,
when opening an image. The sequence is non-breaking-space, the times
sign followed by another non-breaking-space.

The patch modifies an existing patch to lib/Unicode.cc. I don't know
why we opted not to use nl_langinfo(3) (I'm sure there is a good
reason, which I'm missing the history behind).

The fix to the issue being addressed is in two place.

First, there is a bit of code in bt::convert(...), which attempts to
skip over un-convertible sequences, however, in the #ifdef
HAVE_GNU_LIBICONV / #else / #endif, it missed being added skip-over
in the else-block. The patch adds this hack in there. Also see
footnote on HAVE_GNU_LIBICONV at the end.

Second, i think appending //TRANSLIT to the tocode in calling
iconv_open(3) is a better way to handle cases the original hack was
attempting to address. The patch does this as well for conversion to
codeset, used in bt::toLocale(). But note, that I'm adding it to the
#if defined(HAV_NL_LANGINFO) bit, which original patch-lib_Unicode_cc
added a  ! defined(__OpenBSD__).

Long story short, this makes the X window titles, which happen to use
UTF-8, look much better; at least for me here they do.

Comments?

--patrick


HAVE_GNU LIBICONV:

Is converters/libiconv not same as GNU_LIBICONV referenced in the
#ifdef? I think configure looks at the prototype of the function
iconv(3) in determining this. I noticed that iconv.h has a slightly
different prototype defined than the man page, not matching what
configure expects(?).

/usr/local/iconv.h:
extern size_t iconv (iconv_t cd,  char* * inbuf, size_t *inbytesleft,
char* * outbuf, size_t *outbytesleft);

vs man 3 iconv:
   size_t iconv (iconv_t cd,
 const char* * inbuf, size_t * inbytesleft,
 char* * outbuf, size_t * outbytesleft);

The const for the 2nd param.


blackbox.diff
Description: Binary data

[update] p5-Image-ExifTool

[patrick keshishian]

simple update.

cheers,
--patrick


p5-Image-ExifTool.diff
Description: Binary data

Gimp avahi-{client,common} not found

[patrick keshishian]

Need this tiny change for gimp port to build using 2013-JUN-27
snapshot. ports tree updated a day ago from spacehopper.

Without it, make package phase would error out on port-wantlib-args target.

--patrick


Index: Makefile
===
RCS file: /cvs/ports/graphics/gimp/stable/Makefile,v
retrieving revision 1.92
diff -u -p -u -p -r1.92 Makefile
--- Makefile20 Jun 2013 06:54:36 -  1.92
+++ Makefile4 Jul 2013 04:17:20 -
@@ -45,7 +45,8 @@ LIB_DEPENDS=  x11/gtk+2 \
print/poppler \
graphics/gegl=0.2 \
graphics/openjpeg \
-   net/curl
+   net/curl \
+   net/avahi

 # GPLv2
 PERMIT_PACKAGE_CDROM=  Yes

Re: Awaiting lock for firefox libtool, gtk+2, cups, glib2, avahi, gtk+

[patrick keshishian]

Hi all,

I installed 2013-JUN-27 snapshot and started building a bunch of
ports. I ran into this problem again on a few ports. See a snippet at
the end of this message.

I *think* I have an idea of what may be going on to cause this issue,
but I'm not 100% certain. espie@ may have a better idea on this.

I think this issue happened on all ports where my 'make install'
halted on an error, and was restarted. For example, if I started the
'make install' on a biggish port (e.g., something that took hour+ to
build), where I walked away from the terminal, and eventually the
build process required me to enter a password for sudo, and sudo timed
out.

I think the initial lock file remains in the $PORTSDIR/pobj/locks
directory, and when the build is restarted,
$PORTSDIR/infrastructure/bin/dolock gets stuck Awaiting lock 

I have not verified this, but it seems for the three ports I noticed
this, it was the case.

Hope this is helpful in someway,
--patrick

Here is a snippet from build output as an example:

[window 1]
===  Building package for gnome-icon-theme-symbolic-3.8.3
Create 
/usr/build/ports/packages/amd64/no-arch/gnome-icon-theme-symbolic-3.8.3.tgz
Link to /usr/build/ports/packages/amd64/all/gnome-icon-theme-symbolic-3.8.3.tgz
Link to /usr/build/ports/packages/amd64/ftp/gnome-icon-theme-symbolic-3.8.3.tgz
Link to 
/usr/build/ports/packages/amd64/cdrom/gnome-icon-theme-symbolic-3.8.3.tgz
===  Cleaning for hicolor-icon-theme-0.12p2
===  Cleaning for bzip2-1.0.6p0
===  Cleaning for docbook-dsssl-1.72p0
===  Cleaning for metaauto-1.0p1
===  Cleaning for autoconf-2.13p2
===  Cleaning for libelf-0.8.13p1
===  Cleaning for jpeg-9p0
===  Cleaning for gperf-3.0.4
===  Cleaning for libiconv-1.14p0
===  Cleaning for gettext-0.18.2p2
===  Cleaning for gmake-3.82p2
===  Cleaning for help2man-1.41.1
===  Cleaning for autoconf-2.69p0
===  Cleaning for tiff-4.0.3p2
===  Cleaning for xz-5.0.4p0
===  Cleaning for libarchive-3.0.4p0
===  Cleaning for libgpg-error-1.11
===  Cleaning for libgcrypt-1.5.2
===  Cleaning for libidn-1.27
===  Cleaning for curl-7.26.0p2
===  Cleaning for p5-XML-Parser-2.41p0
===  Cleaning for intltool-0.50.2
===  Cleaning for groff-1.22.2p0
===  Cleaning for p5-XML-NamespaceSupport-1.11p0
===  Cleaning for p5-XML-SAX-0.96p1
===  Cleaning for p5-XML-Simple-2.18p0
===  Cleaning for icon-naming-utils-0.8.90p0
===  Cleaning for icontool-0.1.0
===  Cleaning for gdbm-1.10
===  Cleaning for tcl-8.5.14
===  Cleaning for tk-8.5.14
===  Cleaning for unzip-6.0p1
===  Cleaning for iso8879-1986p0
===  Cleaning for jasper-1.900.1p2
===  Cleaning for pcre-8.33
===  Cleaning for re2c-0.13.5
===  Cleaning for icu4c-51.2
===  Cleaning for libsigsegv-2.10
===  Cleaning for m4-1.4.16
===  Cleaning for bison-2.3p0
===  Cleaning for db-4.6.21v0
===  Cleaning for lzo2-2.06p0
===  Cleaning for png-1.6.2p0
===  Cleaning for libffi-3.0.9p3
===  Cleaning for python-2.7.5
===  Cleaning for libxml-2.9.0p0
===  Cleaning for docbook-4.5p1
===  Cleaning for libxml-2.9.0p0
===  Cleaning for py-libxml-2.9.0p0
===  Cleaning for libxslt-1.1.28p0
===  Cleaning for docbook-xsl-1.68.1p5
===  Cleaning for glib2-2.36.3
===  Cleaning for cairo-1.12.14p0
===  Cleaning for gobject-introspection-1.36.0
===  Cleaning for atk-2.8.0
===  Cleaning for vala-0.20.1
===  Cleaning for shared-mime-info-1.1
===  Cleaning for gdk-pixbuf-2.28.2p1
===  Cleaning for libcroco-0.6.8p0
===  Cleaning for ninja-1.3.4
===  Cleaning for cmake-2.8.11.1p0
===  Cleaning for graphite2-1.2.1
===  Cleaning for harfbuzz-0.9.18
===  Cleaning for pango-1.34.1p1
===  Cleaning for librsvg-2.36.4p3
Awaiting lock /usr/build/ports/pobj/locks/gtk+-2.24.19.lock

[window 2]
$ ls -ltr /usr/ports/pobj/locks/
total 8
-rw-r--r--  1 me  wsrc  11 Jul  2 08:27 gtk+-2.24.19.lock
-rw-r--r--  1 me  wsrc  31 Jul  2 11:19 gnome-icon-theme-symbolic-3.8.3.lock

[window 2]
$ rm /usr/ports/pobj/locks/gtk+-2.24.19.lock
$ ls -ltr /usr/ports/pobj/locks/
total 8
-rw-r--r--  1 me  wsrc  31 Jul  2 11:19 gnome-icon-theme-symbolic-3.8.3.lock
-rw-r--r--  1 root wsrc  11 Jul  2 11:26 gtk+-2.24.19.lock




On Tue, May 28, 2013 at 1:16 PM, patrick keshishian pkesh...@gmail.com wrote:
 On Tue, May 28, 2013 at 10:02 AM,  sh...@lavabit.com wrote:
 $ ps -auxw
 USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
 root 1  0.0  0.0   564   424 ??  Is 9:45AM0:01.00 /sbin/init
 root 25430  0.0  0.0   820   480 ??  Is 9:45AM0:00.31
 dhclient: iwn0 [priv] (dhclient)
 _dhcp21496  0.0  0.0   888   380 ??  Is 9:45AM0:00.39
 dhclient: iwn0 (dhclient)
 root 10029  0.0  0.0   616   856 ??  Is 9:45AM0:00.04 syslogd:
 [priv] (syslogd)
 _syslogd 18461  0.0  0.0   632   844 ??  S  9:45AM0:00.01
 /usr/sbin/syslogd -a /var/www/dev/log -a /var/empty/dev/log
 root 14204  0.0  0.0   884  1412 ??  Is 9:45AM0:00.09
 /usr/sbin/sshd
 _sndio   18215  0.0  0.0   584   496 ??  Is9:45AM0:00.03
 /usr/bin/sndiod
 root 28593  0.0

Re: Update: net/curl 7.30.0

[patrick keshishian]

On Tue, Jun 4, 2013 at 1:54 PM, Christian Weisgerber na...@mips.inka.de wrote:
 Can people please run the regression tests on a variety of machines
 and report back to me the results?

 Index: Makefile
 ===
 RCS file: /cvs/ports/net/curl/Makefile,v
 retrieving revision 1.89
 diff -u -p -r1.89 Makefile
 --- Makefile7 May 2013 06:53:26 -   1.89
 +++ Makefile4 Jun 2013 20:53:18 -
 @@ -2,9 +2,8 @@

  COMMENT=   get files from FTP, Gopher, HTTP or HTTPS servers

 -DISTNAME=  curl-7.26.0
 -REVISION=  2
 -SHARED_LIBS=   curl 23.0 # .6.0
 +DISTNAME=  curl-7.30.0
 +SHARED_LIBS=   curl 24.0 # 7.0
  CATEGORIES=net
  MASTER_SITES=  http://curl.haxx.se/download/ \
 ftp://ftp.sunet.se/pub/www/utilities/curl/
 @@ -20,6 +19,7 @@ MODULES=  devel/gettext
  LIB_DEPENDS=   devel/libidn
  WANTLIB=   c crypto idn ssl z

 +SEPARATE_BUILD=Yes
  CONFIGURE_STYLE=gnu
  CONFIGURE_ARGS=${CONFIGURE_SHARED} \
 --with-ca-bundle=/etc/ssl/cert.pem \
 @@ -32,11 +32,6 @@ CONFIGURE_ENV+=curl_cv_func_select_args=
  CONFIGURE_ENV+=curl_cv_func_recv_args=int,void *,size_t,int,ssize_t
  CONFIGURE_ENV+=curl_cv_func_recvfrom_args=int,void *,size_t,int,struct 
 sockaddr *,socklen_t *,ssize_t
  CONFIGURE_ENV+=curl_cv_func_send_args=int,const void *,size_t,int,ssize_t
 -
 -post-install:
 -   ${INSTALL_DATA_DIR} ${PREFIX}/share/emacs/site-lisp
 -   cd ${WRKSRC}; ${INSTALL_DATA} curl-style.el \
 -   ${PREFIX}/share/emacs/site-lisp

  # Note:
  # use ulimit -p 256 for test
 Index: distinfo
 ===
 RCS file: /cvs/ports/net/curl/distinfo,v
 retrieving revision 1.44
 diff -u -p -r1.44 distinfo
 --- distinfo11 Jul 2012 22:15:00 -  1.44
 +++ distinfo4 Jun 2013 20:53:18 -
 @@ -1,2 +1,2 @@
 -SHA256 (curl-7.26.0.tar.gz) = eczOntuK7hfSCtTXXh+Dp4n4wuceaPRo4b+Kv4kzGT8=
 -SIZE (curl-7.26.0.tar.gz) = 3073624
 +SHA256 (curl-7.30.0.tar.gz) = NhZpw8S5uqU0Pn6DvOaV5gaD0Ll7QC5mS7rtQsFelag=
 +SIZE (curl-7.30.0.tar.gz) = 3329809
 Index: patches/patch-lib_cookie_c
 ===
 RCS file: patches/patch-lib_cookie_c
 diff -N patches/patch-lib_cookie_c
 --- patches/patch-lib_cookie_c  7 May 2013 06:53:26 -   1.1
 +++ /dev/null   1 Jan 1970 00:00:00 -
 @@ -1,42 +0,0 @@
 -$OpenBSD: patch-lib_cookie_c,v 1.1 2013/05/07 06:53:26 jasper Exp $
 -
 -Security fix for CVE-2013-1944 curl: Cookie domain suffix match vulnerability
 -Patch from http://curl.haxx.se/curl-tailmatch.patch
 -
  lib/cookie.c.orig  Thu Mar  8 20:35:24 2012
 -+++ lib/cookie.c   Mon May  6 16:17:34 2013
 -@@ -118,15 +118,29 @@ static void freecookie(struct Cookie *co)
 -   free(co);
 - }
 -
 --static bool tailmatch(const char *little, const char *bigone)
 -+static bool tailmatch(const char *cooke_domain, const char *hostname)
 - {
 --  size_t littlelen = strlen(little);
 --  size_t biglen = strlen(bigone);
 -+  size_t cookie_domain_len = strlen(cooke_domain);
 -+  size_t hostname_len = strlen(hostname);
 -
 --  if(littlelen  biglen)
 -+  if(hostname_len  cookie_domain_len)
 - return FALSE;
 -
 --  return Curl_raw_equal(little, bigone+biglen-littlelen) ? TRUE : FALSE;
 -+  if(!Curl_raw_equal(cooke_domain, hostname+hostname_len-cookie_domain_len))
 -+return FALSE;
 -+
 -+  /* A lead char of cookie_domain is not '.'.
 -+ RFC6265 4.1.2.3. The Domain Attribute says:
 -+   For example, if the value of the Domain attribute is
 -+   example.com, the user agent will include the cookie in the Cookie
 -+   header when making HTTP requests to example.com, www.example.com, and
 -+   www.corp.example.com.
 -+   */
 -+  if(hostname_len == cookie_domain_len)
 -+return TRUE;
 -+  if('.' == *(hostname + hostname_len - cookie_domain_len - 1))

I'm not proof-reading this, but couldn't help noticing this ugliness.
Why not index into the host string? i.e.,
hostname[hostname_len-cookie_domain_len-1]?

-pk


 -+return TRUE;
 -+  return FALSE;
 - }
 -
 - /*
 Index: patches/patch-lib_smtp_c
 ===
 RCS file: patches/patch-lib_smtp_c
 diff -N patches/patch-lib_smtp_c
 --- patches/patch-lib_smtp_c8 Feb 2013 16:27:12 -   1.2
 +++ /dev/null   1 Jan 1970 00:00:00 -
 @@ -1,48 +0,0 @@
 -$OpenBSD: patch-lib_smtp_c,v 1.2 2013/02/08 16:27:12 jasper Exp $
 -
 -Security fix for CVE-2013-0249, smtp_state_authdigest_resp()
 -buffer overflow vulnerability.
 -
 -Advisory:
 -http://curl.haxx.se/docs/adv_20130206.html
 -
 -Backported from:
 -http://curl.haxx.se/curl-sasl.patch
 -
  lib/smtp.c.origTue May 22 23:36:17 2012
 -+++ lib/smtp.c Fri Feb  8 13:28:22 2013
 -@@ -964,7 +964,7 @@ static CURLcode smtp_state_authdigest_resp(struct conn
 - snprintf(HA1_hex[2 * i], 

Re: Awaiting lock for firefox libtool, gtk+2, cups, glib2, avahi, gtk+

[patrick keshishian]

On Tue, May 28, 2013 at 10:02 AM,  sh...@lavabit.com wrote:
 $ ps -auxw
 USER   PID %CPU %MEM   VSZ   RSS TT  STAT  STARTED   TIME COMMAND
 root 1  0.0  0.0   564   424 ??  Is 9:45AM0:01.00 /sbin/init
 root 25430  0.0  0.0   820   480 ??  Is 9:45AM0:00.31
 dhclient: iwn0 [priv] (dhclient)
 _dhcp21496  0.0  0.0   888   380 ??  Is 9:45AM0:00.39
 dhclient: iwn0 (dhclient)
 root 10029  0.0  0.0   616   856 ??  Is 9:45AM0:00.04 syslogd:
 [priv] (syslogd)
 _syslogd 18461  0.0  0.0   632   844 ??  S  9:45AM0:00.01
 /usr/sbin/syslogd -a /var/www/dev/log -a /var/empty/dev/log
 root 14204  0.0  0.0   884  1412 ??  Is 9:45AM0:00.09
 /usr/sbin/sshd
 _sndio   18215  0.0  0.0   584   496 ??  Is9:45AM0:00.03
 /usr/bin/sndiod
 root 28593  0.0  0.0   328   776 ??  Ss 9:45AM0:00.02
 /usr/sbin/apmd -C
 root 31406  0.0  0.0   724   980 ??  Ss 9:45AM0:00.00
 /usr/sbin/cron
 root  3593  0.0  0.1  3484  3180 ??  Is 9:49AM0:00.72 sshd:
 shaul [priv] (sshd)
 shaul15335  0.0  0.1  3452  2432 ??  S  9:49AM0:00.02 sshd:
 shaul@ttyp0 (sshd)
 shaul27663  0.0  0.0   736   560 p0  Ss 9:49AM0:00.03 -ksh (ksh)
 shaul28217  0.0  0.0   344   256 p0  R+/3   9:50AM0:00.00 ps -auxw
 root 27732  0.0  0.0   432   888 C0  Is+9:45AM0:00.01
 /usr/libexec/getty std.9600 ttyC0
 root 29620  0.0  0.0   300   900 C1  Is+9:45AM0:00.01
 /usr/libexec/getty std.9600 ttyC1
 root 28938  0.0  0.0   540   896 C2  Is+9:45AM0:00.01
 /usr/libexec/getty std.9600 ttyC2
 root  8766  0.0  0.0   308   900 C3  Is+9:45AM0:00.01
 /usr/libexec/getty std.9600 ttyC3
 root 28219  0.0  0.0   292   896 C5  Is+9:45AM0:00.00
 /usr/libexec/getty std.9600 ttyC5
 $ ls /usr/obj/ports/locks
 $ sudo sh -c cd /usr/ports/www/mozilla-firefox  make configure
 ===  Verifying update for libIDL-* in devel/libIDL
 ===  Checking files for libIDL-0.8.14p1
 Fetch
 http://ftp.acc.umu.se/pub/GNOME/sources/libIDL/0.8/libIDL-0.8.14.tar.bz2
 libIDL-0.8.14.tar.bz2 100%
 ||
   417 KB00:03
 (SHA256) libIDL-0.8.14.tar.bz2: OK
 ===  Verifying update for gettext-=0.10.38 in devel/gettext
 === Returning to build of libIDL-0.8.14p1
 === libIDL-0.8.14p1 depends on: gettext-=0.10.38 - gettext-0.18.2p1
 ===  Verifying update for intltool-=0.41.1p0 in textproc/intltool
 === Returning to build of libIDL-0.8.14p1
 === libIDL-0.8.14p1 depends on: intltool-=0.41.1p0 - intltool-0.50.2
 ===  Verifying update for gmake-* in devel/gmake
 === Returning to build of libIDL-0.8.14p1
 === libIDL-0.8.14p1 depends on: gmake-* - gmake-3.82p2
 ===  Verifying update for bzip2-* in archivers/bzip2
 === Returning to build of libIDL-0.8.14p1
 === libIDL-0.8.14p1 depends on: bzip2-* - bzip2-1.0.6
 ===  Verifying update for glib2-* in devel/glib2
 ===  Checking files for glib2-2.34.3
 `/usr/distfiles/glib-2.34.3.tar.xz' is up to date.
 `/usr/distfiles/glib-gio-kqueue-2.34.2-v2.patch' is up to date.
 (SHA256) glib-2.34.3.tar.xz: OK
 (SHA256) glib-gio-kqueue-2.34.2-v2.patch: OK
 ===  Verifying update for docbook-=4.5p1 in textproc/docbook
 === Returning to build of glib2-2.34.3
 === glib2-2.34.3 depends on: docbook-=4.5p1 - docbook-4.5p1
 ===  Verifying update for libxslt-* in textproc/libxslt
 === Returning to build of glib2-2.34.3
 === glib2-2.34.3 depends on: libxslt-* - libxslt-1.1.27
 ===  Verifying update for dbus-* in x11/dbus
 === Returning to build of glib2-2.34.3
 === glib2-2.34.3 depends on: dbus-* - dbus-1.6.8p5v0
 ===  Verifying update for metaauto-* in devel/metaauto
 === Returning to build of glib2-2.34.3
 === glib2-2.34.3 depends on: metaauto-* - metaauto-1.0
 ===  Verifying update for autoconf-2.68 in devel/autoconf/2.68
 === Returning to build of glib2-2.34.3
 === glib2-2.34.3 depends on: autoconf-2.68 - autoconf-2.68
 ===  Verifying update for automake-=1.11,1.12 in devel/automake/1.11
 === Returning to build of glib2-2.34.3
 === glib2-2.34.3 depends on: automake-=1.11,1.12 - automake-1.11.6
 ===  Verifying update for libtool-* in devel/libtool
 ===  Cleaning for help2man-1.29p0
 ===  Cleaning for metaauto-1.0
 ===  Cleaning for autoconf-2.67
 Awaiting lock /usr/obj/ports/locks/libtool-2.4.2.lock


I reported similar issue to espie@ sometime in Feb '13 while building
xpdf. This wasn't port specific as I noticed it with a few different
ports. I have not attempted a ports build of my own since.

This was the first time I noticed this issue while building my own
ports. The only difference, besides the OBSD version (all snapshots
btw), this particular time I was running an MP kernel whilst building
ports.

Possibly relevant points:
- MP kernel (as mentioned).
- ports directory is on a different mount point than /usr/ports.
  /usr/ports is a soft-link to the actual ports directory.
- ports 

Re: UPDATE: gnuplot

[patrick keshishian]

On Wed, May 22, 2013 at 1:42 AM, Stuart Henderson st...@openbsd.org wrote:
 On 2013/05/22 09:39, Stuart Henderson wrote:
 On 2013/05/22 10:07, Jasper Lievisse Adriaanse wrote:
  Hi,
 
  Here's an update for gnuplot to the latest release, all regress tests works
  fine and my own plots still looks good. Please test this on your data and
  report any regressions; OK?

 This fails in make fake for me, even if emacs is installed (tried
 both 21 and 24)..

 bleh, I was building with parallel, this is just a dependency issue in
 gnuplot's Makefile.

 However as-is it does need a BUILD_DEPENDS on emacs21 (can't be 24
 for bulk builds).

where is this seeping in?

-pk


 install -c -o root -g bin -m 444 gnuplot.gih 
 /usr/obj/ports/gnuplot-4.6.3/fake-amd64/usr/local/share/gnuplot/4.6/gnuplot.gih
 make: don't know how to make gnuplot-eldoc.el (prerequisite of: install-info)
 Stop in docs

   # see Copyright in source
  +# http://gnuplot.cvs.sourceforge.net/gnuplot/gnuplot/Copyright

 I do love how gnuplot is not GNU :)

Re: make it possible to have /usr/ports as symlink

[patrick keshishian]

On Wed, May 15, 2013 at 10:24 PM, Antoine Jacoutot
ajacou...@bsdfrog.org wrote:
 On Wed, May 15, 2013 at 01:21:52PM -0700, patrick keshishian wrote:
 Hi,

 On Wed, May 15, 2013 at 1:08 PM, Antoine Jacoutot ajacou...@bsdfrog.org 
 wrote:
  Hi.
 
  Some time ago espie@ added a check to make sure that /usr/ports was not a 
  symlink because this could break a couple (or 3?) ports.
  I hate that restriction.
  Last time I talked to him he said that chromium needed to be fixed because 
  it was one of the outstanding ports that would not build with a symlinked 
  /usr/ports.
 
  Well I just reverted the diff and chromium built fine with /usr/ports - 
  /home/cvs/openbsd/ports today.
  So I am proposing to revert the diff and if any other port breaks because 
  of this, I volunteer to fix it/them; I just find the restriction stupid.

 :-)

 I had this diff locally, and got yelled at by espie@. He suggested
 setting PORTSDIR to point to the actual directory /usr/ports is
 symlinked to.

 I'm not against your proposal, but curious if there is any reason
 setting PORTSDIR does not work?

 Setting PORTSDIR works, but is not the point of this diff.

I'm not trying to argue with you or the diff. As I said, I have those
lines removed in my local copy of that file as well.

I don't know the history, or the why of those some (or a couple) ports
which break if /usr/ports (or more correctly $PORTSDIR) is a symlink.
However, my question was (and remains): Why not simply set PORTSDIR to
the actual directory /usr/ports points to and not hassle with fixing
or risk any ports that might break?

--patrick

Re: make it possible to have /usr/ports as symlink

[patrick keshishian]

Hi,

On Wed, May 15, 2013 at 1:08 PM, Antoine Jacoutot ajacou...@bsdfrog.org wrote:
 Hi.

 Some time ago espie@ added a check to make sure that /usr/ports was not a 
 symlink because this could break a couple (or 3?) ports.
 I hate that restriction.
 Last time I talked to him he said that chromium needed to be fixed because it 
 was one of the outstanding ports that would not build with a symlinked 
 /usr/ports.

 Well I just reverted the diff and chromium built fine with /usr/ports - 
 /home/cvs/openbsd/ports today.
 So I am proposing to revert the diff and if any other port breaks because of 
 this, I volunteer to fix it/them; I just find the restriction stupid.

:-)

I had this diff locally, and got yelled at by espie@. He suggested
setting PORTSDIR to point to the actual directory /usr/ports is
symlinked to.

I'm not against your proposal, but curious if there is any reason
setting PORTSDIR does not work?

--patrick


 Sometimes it is good to adapt the infrastructure for broken stuffs, but here 
 it makes no sense especially if we are talking about a couple of ports.

 comments/ok?


 Index: bsd.port.mk
 ===
 RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
 retrieving revision 1.1224
 diff -u -r1.1224 bsd.port.mk
 --- bsd.port.mk 14 May 2013 13:38:59 -  1.1224
 +++ bsd.port.mk 15 May 2013 20:03:33 -
 @@ -2401,11 +2401,6 @@

  ${_WRKDIR_COOKIE}:
 @rm -rf ${WRKDIR}
 -   @if test -h ${PORTSDIR}; then \
 -   echo 12 Fatal: ${PORTSDIR} is a symlink.; \
 -   echo 12 Please point PORTSDIR to the real directory (in 
 /etc/mk.conf); \
 -   exit 1; \
 -   fi
  .if ${PORTS_BUILD_XENOCARA_TOO:L} != yes
 @appdefaults=${LOCALBASE}/lib/X11/app-defaults; \
 if ! test -d $$appdefaults -a -h $$appdefaults; then \

 --
 Antoine

Re: font weight changing

[patrick keshishian]

On Sat, Mar 30, 2013 at 6:46 PM, Ted Unangst t...@tedunangst.com wrote:
 On Sat, Mar 30, 2013 at 20:21, joshua stein wrote:
 On Sat, 30 Mar 2013 at 16:39:34 +, Kevin Chadwick wrote:
 If you can reproduce it, I wonder if it only happens with downloaded
 fonts. gfx.downloadable_fonts.enabled may test that?

 I see it (and can reproduce most easily) on websites that don't even change 
 the default font or size. just htmlwall of text/html.

just for FYI i see it in gmail using ff18. It doesn't happen often,
but seems to sometimes when composing (like right now) but as soon as
the compose window (HTML TEXTAREA) loses focus the text rendering
corrects itself; making it difficult to take a screen-shot.

I recall another text rendering issue a while ago, which was worse
than what I am seeing, but I believe it was fixed/related to what is
this post:

http://marc.info/?l=openbsd-portsm=134443710831579w=2

--patrick


 The fonts I have installed:
 ghostscript-fonts-8.11p2 35 standard PostScript fonts with Adobe name aliases
 terminus-font-4.38  fixed width fonts especially for long hacking sessions
 ubuntu-fonts-0.80p0 unicode sans-serif/monospace TrueType fonts from Ubuntu

 I don't think firefox uses any of them over the default installed fonts 
 however.

 Since Ted reported it happening in Chrome as well, I figured it
 might be a Freetype issue.  I tried reverting Freetype to 2.4.8
 (-D2012-01-01 in CVS) but it made no difference in Firefox 19.0.2.
 I installed Chrome and can't seem to reproduce the issue with either
 Freetype, but I didn't use it for very long.

 On reflection, what I was seeing in chrome was something else. I use chrome 
 less frequently, and remembered seeing some very similar artifacts, but going 
 back to check, chrome just draws certain characters (!, *, ) extra heavy. 
 It's always consistent about it, so I don't think it's a bug. When I wrote my 
 email about firefox, I mentally merged the issues.