Re: minor fix for devel/check
21 нояб. 2014 г. 3:42 пользователь "Kaspars Bankovskis" <
kasp...@bankovskis.net> написал:
>
> Hi,
>
> Currently, when linking your source against libcheck, you get an
> annoying warning about unsafe usage of tempnam(3). The following
> patch fixes that, by commenting out a block of code which, according
> to comments above it, is supposed to solve issues with Windows, and
> shouldn't be relevant in OpenBSD case.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/check/Makefile,v
> retrieving revision 1.12
> diff -u -p -u -r1.12 Makefile
> --- Makefile29 Sep 2014 19:58:04 - 1.12
> +++ Makefile21 Nov 2014 00:26:44 -
> @@ -3,6 +3,7 @@
> COMMENT = unit test framework for C programs
>
> DISTNAME = check-0.9.14
> +REVISION = 0
> SHARED_LIBS += check3.0 # unknown
>
> CATEGORIES = devel
> Index: patches/patch-src_check_msg_c
> ===
> RCS file: patches/patch-src_check_msg_c
> diff -N patches/patch-src_check_msg_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_check_msg_c 20 Nov 2014 23:50:20 -
> @@ -0,0 +1,30 @@
> +--- src/check_msg.c.orig Fri Nov 21 01:47:21 2014
> src/check_msg.cFri Nov 21 01:50:16 2014
> +@@ -232,10 +232,12 @@
> + /* and finally, the "b" from "w+b" is ignored on OS X, not sure
about WIN32 */
> +
> + file = tmpfile();
> ++/*
> + if(file == NULL)
> + {
> + char *tmp = getenv("TEMP");
> + char *tmp_file = tempnam(tmp, "check_");
> ++*/
> +
> + /*
> + * Note, tempnam is not enough to get a unique name. Between
> +@@ -247,12 +249,14 @@
> + * we append the pid to the file. The pid should be unique on
the
> + * system.
> + */
> ++/*
> + char *uniq_tmp_file = ck_strdup_printf("%s.%d", tmp_file,
getpid());
> +
> + file = fopen(uniq_tmp_file, "w+b");
> + *name = uniq_tmp_file;
> + free(tmp_file);
> + }
> ++*/
> + return file;
> + }
> +
Could you, please, use something that upstream will accept instead? Like
"#ifdef _WIN32".
--
Vadim Zhukov
Re: alternatives to procmail: security
> So which of the suggested alternatives (fdm, sieved, ???) have > undergone a security audit or at least can claim that no problems > were found when using some of those "fuzzing" tools? Well the real answer here is that procmail hasn't undergone a security audit and has a claim that it just failed under "fuzzing" tools. > Before switching from procmail to something else it would be > nice to know if that alternative is (more) secure. Well, the options are (1) stick with procmail (2) start auditing (3) try to prompt other people to audit. Oh, I get it. Anyways, fmd is written by nicm@ who has a incredibly good track record. My audit of the first draft of tmux was depressing, there was so little for me to poke a finger at. Modern mail is terribly complicated, the attack surface on something like this is huge. Having it privsep from the start of development certainly raises the bar.
Re: NEW: x11/mpv [0.6.2]
Anthony J. Bentley said: > There's at least one more obvious issue: when I pause music or > video, I can't unpause... Apparently the workaround in audio_resume() function was causing this bug. (Not sure why, as the function exited just fine.) Attached revision of the port fixes that by replacing the whole function body with "return;". I don't see the effect that was being faught according to the comment in removed code. P.S.: While we are patching sndio backend, we should probably remove the warning about blocking because of sndio bug – these messages litter the output, which is particularily irritating if plaback was paused several times or seeking was done. -- Dmitrij D. Czarkoff mpv.tar.gz Description: application/tar-gz
Re: alternatives to procmail: security
So which of the suggested alternatives (fdm, sieved, ???) have undergone a security audit or at least can claim that no problems were found when using some of those "fuzzing" tools? Before switching from procmail to something else it would be nice to know if that alternative is (more) secure.
minor fix for devel/check
Hi,
Currently, when linking your source against libcheck, you get an
annoying warning about unsafe usage of tempnam(3). The following
patch fixes that, by commenting out a block of code which, according
to comments above it, is supposed to solve issues with Windows, and
shouldn't be relevant in OpenBSD case.
Index: Makefile
===
RCS file: /cvs/ports/devel/check/Makefile,v
retrieving revision 1.12
diff -u -p -u -r1.12 Makefile
--- Makefile29 Sep 2014 19:58:04 - 1.12
+++ Makefile21 Nov 2014 00:26:44 -
@@ -3,6 +3,7 @@
COMMENT = unit test framework for C programs
DISTNAME = check-0.9.14
+REVISION = 0
SHARED_LIBS += check3.0 # unknown
CATEGORIES = devel
Index: patches/patch-src_check_msg_c
===
RCS file: patches/patch-src_check_msg_c
diff -N patches/patch-src_check_msg_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_check_msg_c 20 Nov 2014 23:50:20 -
@@ -0,0 +1,30 @@
+--- src/check_msg.c.orig Fri Nov 21 01:47:21 2014
src/check_msg.cFri Nov 21 01:50:16 2014
+@@ -232,10 +232,12 @@
+ /* and finally, the "b" from "w+b" is ignored on OS X, not sure about
WIN32 */
+
+ file = tmpfile();
++/*
+ if(file == NULL)
+ {
+ char *tmp = getenv("TEMP");
+ char *tmp_file = tempnam(tmp, "check_");
++*/
+
+ /*
+ * Note, tempnam is not enough to get a unique name. Between
+@@ -247,12 +249,14 @@
+ * we append the pid to the file. The pid should be unique on the
+ * system.
+ */
++/*
+ char *uniq_tmp_file = ck_strdup_printf("%s.%d", tmp_file, getpid());
+
+ file = fopen(uniq_tmp_file, "w+b");
+ *name = uniq_tmp_file;
+ free(tmp_file);
+ }
++*/
+ return file;
+ }
+
Re: file permissions in a port
On 11/20/14 17:47, Stuart Henderson wrote: On 2014/11/20 17:21, Fred wrote: On 11/20/14 17:14, Marc Espie wrote: On Thu, Nov 20, 2014 at 09:39:03AM -0500, Jiri B wrote: On Thu, Nov 20, 2014 at 02:17:34PM +, Fred wrote: Hi ports@ Can someone point me at the documentation for changing the file permissions in a package? I'm working on porting radiotray[1] and have wip port [2] but I noticed when testing it on i386 that the ~/.local/share/radiotray/config.xml is installed with 444 permisions rather than 644 which is needed for the package to run. Cheers Fred [1] http://radiotray.sourceforge.net/ [2] https://github.com/fcbsd/openbsd-wip/tree/master/audio/radiotray man pkg_create and see '@chmod'. You mean @mode (though he will probably find it with that). More precisely: packing-list are signed, the tar meta-info is not, so anything even slightly unusual *must* be explicitly written in the plist. Thanks - I'm reading through pkg_create now. ~/.local/share/radiotray/config.xml isn't included in the package anyway though, presumably it gets copied from /usr/local/share/... at runtime (copying permissions there perhaps)? - if so, wouldn't it be more sane for permissions to be set by the program doing the copying? This turned out to be the answer - I'm trying to see if I can get my changes pushed upstream to remove the patches. Thanks for all the cluebats. Cheers Fred
Re: NEW: archivers/innoextract
Donovan Watteau writes: > Here's a new version, with an explicit requirement on boost's latest > revision, as suggested by Landry. > > As for Doxygen: I don't see the point of requiring doxygen and > graphviz just for documenting API internals; it's just a tool, not > a library. I agree. Works fine with a few installers from $DAYJOB and the port looks clean. ok? -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: NEW: archivers/innoextract
On 2014/11/20 21:28, Donovan Watteau wrote: > Here's a new version, with an explicit requirement on boost's latest > revision, as suggested by Landry. > > As for Doxygen: I don't see the point of requiring doxygen and > graphviz just for documenting API internals; it's just a tool, not > a library. I agree - you have disabled doxygen in cmake so there's no problem with it picking up an installed copy at configure time, API docs aren't useful for this port, so I think this is fine. Seems useful and the port looks good. Any OKs to import it? (or if someone else would like to, it's OK sthen@). I don't like upstream's hardcoded escape sequences for colour support and overwriting text for the progress bar (it ought to use terminal capabilities to work out what sequences to send) but at least it provides a way to disable them on the command line.
Re: NEW: archivers/innoextract
Here's a new version, with an explicit requirement on boost's latest revision, as suggested by Landry. As for Doxygen: I don't see the point of requiring doxygen and graphviz just for documenting API internals; it's just a tool, not a library. innoextract.tgz Description: Binary data
Re: file permissions in a port
Stuart Henderson said: > ~/.local/share/radiotray/config.xml isn't included in the package > anyway though, presumably it gets copied from /usr/local/share/... I suspect that Fred sets LOCALBASE=~/.local for testing purposes. -- Dmitrij D. Czarkoff
Re: file permissions in a port
On 2014/11/20 17:21, Fred wrote: > On 11/20/14 17:14, Marc Espie wrote: > >On Thu, Nov 20, 2014 at 09:39:03AM -0500, Jiri B wrote: > >>On Thu, Nov 20, 2014 at 02:17:34PM +, Fred wrote: > >>>Hi ports@ > >>> > >>>Can someone point me at the documentation for changing the file > >>>permissions in a package? > >>> > >>>I'm working on porting radiotray[1] and have wip port [2] but I > >>>noticed when testing it on i386 that the > >>>~/.local/share/radiotray/config.xml is installed with 444 permisions > >>>rather than 644 which is needed for the package to run. > >>> > >>>Cheers > >>> > >>>Fred > >>> > >>>[1] > >>>http://radiotray.sourceforge.net/ > >>> > >>>[2] > >>>https://github.com/fcbsd/openbsd-wip/tree/master/audio/radiotray > >> > >>man pkg_create and see '@chmod'. > > > >You mean @mode > > > >(though he will probably find it with that). > > > >More precisely: packing-list are signed, the tar meta-info is not, so > >anything even slightly unusual *must* be explicitly written in the plist. > > > > Thanks - I'm reading through pkg_create now. > ~/.local/share/radiotray/config.xml isn't included in the package anyway though, presumably it gets copied from /usr/local/share/... at runtime (copying permissions there perhaps)? - if so, wouldn't it be more sane for permissions to be set by the program doing the copying?
Re: file permissions in a port
On 11/20/14 17:14, Marc Espie wrote: On Thu, Nov 20, 2014 at 09:39:03AM -0500, Jiri B wrote: On Thu, Nov 20, 2014 at 02:17:34PM +, Fred wrote: Hi ports@ Can someone point me at the documentation for changing the file permissions in a package? I'm working on porting radiotray[1] and have wip port [2] but I noticed when testing it on i386 that the ~/.local/share/radiotray/config.xml is installed with 444 permisions rather than 644 which is needed for the package to run. Cheers Fred [1] http://radiotray.sourceforge.net/ [2] https://github.com/fcbsd/openbsd-wip/tree/master/audio/radiotray man pkg_create and see '@chmod'. You mean @mode (though he will probably find it with that). More precisely: packing-list are signed, the tar meta-info is not, so anything even slightly unusual *must* be explicitly written in the plist. Thanks - I'm reading through pkg_create now.
Re: file permissions in a port
On Thu, Nov 20, 2014 at 09:39:03AM -0500, Jiri B wrote: > On Thu, Nov 20, 2014 at 02:17:34PM +, Fred wrote: > > Hi ports@ > > > > Can someone point me at the documentation for changing the file > > permissions in a package? > > > > I'm working on porting radiotray[1] and have wip port [2] but I > > noticed when testing it on i386 that the > > ~/.local/share/radiotray/config.xml is installed with 444 permisions > > rather than 644 which is needed for the package to run. > > > > Cheers > > > > Fred > > > > [1] > > http://radiotray.sourceforge.net/ > > > > [2] > > https://github.com/fcbsd/openbsd-wip/tree/master/audio/radiotray > > man pkg_create and see '@chmod'. You mean @mode (though he will probably find it with that). More precisely: packing-list are signed, the tar meta-info is not, so anything even slightly unusual *must* be explicitly written in the plist.
Re: NEW: devel/afl
On 2014/11/21 01:11, Jonathan Gray wrote: > On Thu, Nov 20, 2014 at 01:40:13PM +, Stuart Henderson wrote: > > On 2014/11/21 00:14, Jonathan Gray wrote: > > > On Thu, Nov 20, 2014 at 11:44:08PM +1100, Jonathan Gray wrote: > > > > On Wed, Nov 19, 2014 at 02:08:32PM +1100, Jonathan Gray wrote: > > > > > Here is a quick port of lcamtuf/Michal Zalewski's instrumented fuzzer > > > > > 'American fuzzy lop'. Only tested on amd64 where it requires the > > > > > binutils > > > > > change I just committed to allow sahf/lahf instructions. > > > > > > > > > > http://lcamtuf.coredump.cx/afl/ for more details > > > > > > > > Updated port attached for version 0.60b that includes > > > > various changes made by Michal Zalewski upstream for OpenBSD. > > > > In particular afl can now handle instrumenting OpenBSD binaries > > > > without having to disable pie. > > > > > > > > Also adds a change to the Makefile to raise the fd ulimit to > > > > ensure the regress test passes from Daniel Dickman. > > > > > > And here is another version of the port as sthen@ points > > > out the distfile was rerolled. Apparently for a workaround > > > for lahf / sahf on older releases of OpenBSD/amd64 before > > > http://marc.info/?l=openbsd-cvs&m=141636589924400 > > > > One minor thing, I think this means that afl requires VT to be available > > on the CPU (and possibly enabled in BIOS)? If that's correct, then a short > > comment in DESCR is probably appropriate. > > I think you might be getting confused on what the instructions do. > They are for loading and setting the cpu flags (carry, zero etc) > via the low byte in a register. I'm aware of that, I looked it up. And many of the pages which described them said that Intel added them as part of VT-x...
Re: NEW: devel/afl
a few thoughts. I'm not in love with changing CFLAGS if hostname is raccoon. i would make a choice to either include no-format or not. I would not run the regress tests as part of the main build but would disconnect it. this is how most ports work as far as I know. while my ulimit patch will let the regress tests work, I think a note might be desirable in pkg-readme. otherwise someone with a low ulimit -n will have to hunt for the same problem when they try to run. ok daniel@ if these changes are made. > On Nov 20, 2014, at 8:14 AM, Jonathan Gray wrote: > >> On Thu, Nov 20, 2014 at 11:44:08PM +1100, Jonathan Gray wrote: >>> On Wed, Nov 19, 2014 at 02:08:32PM +1100, Jonathan Gray wrote: >>> Here is a quick port of lcamtuf/Michal Zalewski's instrumented fuzzer >>> 'American fuzzy lop'. Only tested on amd64 where it requires the binutils >>> change I just committed to allow sahf/lahf instructions. >>> >>> http://lcamtuf.coredump.cx/afl/ for more details >> >> Updated port attached for version 0.60b that includes >> various changes made by Michal Zalewski upstream for OpenBSD. >> In particular afl can now handle instrumenting OpenBSD binaries >> without having to disable pie. >> >> Also adds a change to the Makefile to raise the fd ulimit to >> ensure the regress test passes from Daniel Dickman. > > And here is another version of the port as sthen@ points > out the distfile was rerolled. Apparently for a workaround > for lahf / sahf on older releases of OpenBSD/amd64 before > http://marc.info/?l=openbsd-cvs&m=141636589924400 >
Re: file permissions in a port
On Thu, Nov 20, 2014 at 02:17:34PM +, Fred wrote: > Hi ports@ > > Can someone point me at the documentation for changing the file > permissions in a package? > > I'm working on porting radiotray[1] and have wip port [2] but I > noticed when testing it on i386 that the > ~/.local/share/radiotray/config.xml is installed with 444 permisions > rather than 644 which is needed for the package to run. > > Cheers > > Fred > > [1] > http://radiotray.sourceforge.net/ > > [2] > https://github.com/fcbsd/openbsd-wip/tree/master/audio/radiotray man pkg_create and see '@chmod'. j.
file permissions in a port
Hi ports@ Can someone point me at the documentation for changing the file permissions in a package? I'm working on porting radiotray[1] and have wip port [2] but I noticed when testing it on i386 that the ~/.local/share/radiotray/config.xml is installed with 444 permisions rather than 644 which is needed for the package to run. Cheers Fred [1] http://radiotray.sourceforge.net/ [2] https://github.com/fcbsd/openbsd-wip/tree/master/audio/radiotray
Re: NEW: devel/afl
On Thu, Nov 20, 2014 at 01:40:13PM +, Stuart Henderson wrote: > On 2014/11/21 00:14, Jonathan Gray wrote: > > On Thu, Nov 20, 2014 at 11:44:08PM +1100, Jonathan Gray wrote: > > > On Wed, Nov 19, 2014 at 02:08:32PM +1100, Jonathan Gray wrote: > > > > Here is a quick port of lcamtuf/Michal Zalewski's instrumented fuzzer > > > > 'American fuzzy lop'. Only tested on amd64 where it requires the > > > > binutils > > > > change I just committed to allow sahf/lahf instructions. > > > > > > > > http://lcamtuf.coredump.cx/afl/ for more details > > > > > > Updated port attached for version 0.60b that includes > > > various changes made by Michal Zalewski upstream for OpenBSD. > > > In particular afl can now handle instrumenting OpenBSD binaries > > > without having to disable pie. > > > > > > Also adds a change to the Makefile to raise the fd ulimit to > > > ensure the regress test passes from Daniel Dickman. > > > > And here is another version of the port as sthen@ points > > out the distfile was rerolled. Apparently for a workaround > > for lahf / sahf on older releases of OpenBSD/amd64 before > > http://marc.info/?l=openbsd-cvs&m=141636589924400 > > One minor thing, I think this means that afl requires VT to be available > on the CPU (and possibly enabled in BIOS)? If that's correct, then a short > comment in DESCR is probably appropriate. I think you might be getting confused on what the instructions do. They are for loading and setting the cpu flags (carry, zero etc) via the low byte in a register.
Re: NEW: devel/afl
On 2014/11/21 00:14, Jonathan Gray wrote: > On Thu, Nov 20, 2014 at 11:44:08PM +1100, Jonathan Gray wrote: > > On Wed, Nov 19, 2014 at 02:08:32PM +1100, Jonathan Gray wrote: > > > Here is a quick port of lcamtuf/Michal Zalewski's instrumented fuzzer > > > 'American fuzzy lop'. Only tested on amd64 where it requires the binutils > > > change I just committed to allow sahf/lahf instructions. > > > > > > http://lcamtuf.coredump.cx/afl/ for more details > > > > Updated port attached for version 0.60b that includes > > various changes made by Michal Zalewski upstream for OpenBSD. > > In particular afl can now handle instrumenting OpenBSD binaries > > without having to disable pie. > > > > Also adds a change to the Makefile to raise the fd ulimit to > > ensure the regress test passes from Daniel Dickman. > > And here is another version of the port as sthen@ points > out the distfile was rerolled. Apparently for a workaround > for lahf / sahf on older releases of OpenBSD/amd64 before > http://marc.info/?l=openbsd-cvs&m=141636589924400 One minor thing, I think this means that afl requires VT to be available on the CPU (and possibly enabled in BIOS)? If that's correct, then a short comment in DESCR is probably appropriate. I don't see any other issues, so otherwise OK.
Re: NEW: devel/afl
On Thu, Nov 20, 2014 at 11:44:08PM +1100, Jonathan Gray wrote: > On Wed, Nov 19, 2014 at 02:08:32PM +1100, Jonathan Gray wrote: > > Here is a quick port of lcamtuf/Michal Zalewski's instrumented fuzzer > > 'American fuzzy lop'. Only tested on amd64 where it requires the binutils > > change I just committed to allow sahf/lahf instructions. > > > > http://lcamtuf.coredump.cx/afl/ for more details > > Updated port attached for version 0.60b that includes > various changes made by Michal Zalewski upstream for OpenBSD. > In particular afl can now handle instrumenting OpenBSD binaries > without having to disable pie. > > Also adds a change to the Makefile to raise the fd ulimit to > ensure the regress test passes from Daniel Dickman. And here is another version of the port as sthen@ points out the distfile was rerolled. Apparently for a workaround for lahf / sahf on older releases of OpenBSD/amd64 before http://marc.info/?l=openbsd-cvs&m=141636589924400 afl.tgz Description: application/tar-gz
Re: NEW: devel/afl
On Wed, Nov 19, 2014 at 02:08:32PM +1100, Jonathan Gray wrote: > Here is a quick port of lcamtuf/Michal Zalewski's instrumented fuzzer > 'American fuzzy lop'. Only tested on amd64 where it requires the binutils > change I just committed to allow sahf/lahf instructions. > > http://lcamtuf.coredump.cx/afl/ for more details Updated port attached for version 0.60b that includes various changes made by Michal Zalewski upstream for OpenBSD. In particular afl can now handle instrumenting OpenBSD binaries without having to disable pie. Also adds a change to the Makefile to raise the fd ulimit to ensure the regress test passes from Daniel Dickman. afl.tgz Description: application/tar-gz
scantailor, has it anybody in his own ports tree?
hi, does anybody have scantailor in his own ports tree? so i do not waste time to solve some cmake issue with finding png16 library? :D j.
Re: NEW: x11/mpv [0.6.2]
Hi Alexandre, Alexandre Ratchov writes: > sorry, don't have the time to test & debug this right now, but a > quick look at the ao_sndio.c suggest that blocking mode is used, > while the device is opened in non-blocking mode: > > p->hdl = sio_open(p->dev, SIO_PLAY, 1); > ^^ > > could you replace 1 by 0, and see if it makes things better? Thanks, playback is totally smooth now. There's at least one more obvious issue: when I pause music or video, I can't unpause... -- Anthony J. Bentley
Re: UPDATE: mail/offlineimap
On 2014/11/20 10:23, Jérémie Courrèges-Anglas wrote:
> "Dmitrij D. Czarkoff" writes:
>
> > Edd Barrett said:
> >> +GH_TAGNAME = v${MODPY_EGG_VERSION}
> >> +GH_COMMIT = 7770b5ff73737d1269eb1ba7554b8d3486c7f5ec
> >
> > Does it make sense to include both? Tags are supposed to identify
> > commit reliably...
>
> I don't think that tags are reliable. You can delete and move them
> around.
That is correct, but GH_COMMIT doesn't actually do anything in this case.
After overwriting some of the GH_COMMIT line from this:
$ make checksum
===> Checking files for offlineimap-6.5.6
>> Fetch file:///dist/files//xicjkclf73737d1269eb1ba7554b8d3486c7f5ec.tar.gz
ftp: Can't open file
///dist/files//xicjkclf73737d1269eb1ba7554b8d3486c7f5ec.tar.gz: No such file or
directory
>> Fetch
>> https://github.com/OfflineIMAP/offlineimap/archive/v6.5.6/xicjkclf73737d1269eb1ba7554b8d3486c7f5ec.tar.gz
>> (SHA256) offlineimap-6.5.6.tar.gz: OK
Re: UPDATE: mail/offlineimap
"Dmitrij D. Czarkoff" writes:
> Edd Barrett said:
>> +GH_TAGNAME =v${MODPY_EGG_VERSION}
>> +GH_COMMIT = 7770b5ff73737d1269eb1ba7554b8d3486c7f5ec
>
> Does it make sense to include both? Tags are supposed to identify
> commit reliably...
I don't think that tags are reliable. You can delete and move them
around.
--
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: UPDATE: mail/offlineimap
Edd Barrett said:
> +GH_TAGNAME = v${MODPY_EGG_VERSION}
> +GH_COMMIT = 7770b5ff73737d1269eb1ba7554b8d3486c7f5ec
Does it make sense to include both? Tags are supposed to identify
commit reliably...
--
Dmitrij D. Czarkoff
Re: NEW: x11/mpv [0.6.2]
Alexandre Ratchov said: > sorry, don't have the time to test & debug this right now, but a > quick look at the ao_sndio.c suggest that blocking mode is used, > while the device is opened in non-blocking mode: > > p->hdl = sio_open(p->dev, SIO_PLAY, 1); > ^^ > > could you replace 1 by 0, and see if it makes things better? Thank you! Sure, audio playback is just fine now. I am ashamed that I didn't spot this myself. Expectedly, this does not fix issues with video playback, which seemingly remains as bad as it was with SDL backend. Updated port attached. -- Dmitrij D. Czarkoff mpv.tar.gz Description: application/tar-gz
Re: UPDATE: mail/offlineimap
On Thu, Nov 20, 2014 at 09:42:23AM +0100, Peter Hessler wrote:
> I ended up creating basically the same patch, this is OK from me.
>
> I like sthen's comment to move the GH_COMMIT next to the
> MODPY_EGG_VERSION, as well.
>
> (also adding the MAINTAINER to the email list)
>
>
Looks good to me. ok pea but please remove me as maintainer.
Regards,
> On 2014 Oct 30 (Thu) at 22:08:13 + (+), Edd Barrett wrote:
> :Hey,
> :
> :Update to offlineimap. I have been running this for a while now. No
> :issues. First time I have used GH_*, so please check carefully.
> :
> :OK?
> :
> :Index: Makefile
> :===
> :RCS file: /home/edd/cvsync/ports/mail/offlineimap/Makefile,v
> :retrieving revision 1.26
> :diff -u -p -r1.26 Makefile
> :--- Makefile 11 Mar 2013 11:23:52 - 1.26
> :+++ Makefile 30 Oct 2014 21:58:30 -
> :@@ -2,7 +2,7 @@
> :
> : COMMENT=powerful IMAP/Maildir synchronization and reader support
> :
> :-MODPY_EGG_VERSION= 6.5.4
> :+MODPY_EGG_VERSION= 6.5.6
> : DISTNAME= offlineimap-${MODPY_EGG_VERSION}
> : CATEGORIES= mail
> :
> :@@ -13,15 +13,17 @@ MAINTAINER= Pierre-Emmanuel Andre : # GPLv2+
> : PERMIT_PACKAGE_CDROM= Yes
> :
> :-MASTER_SITES=
> https://github.com/spaetz/offlineimap/tarball/v${MODPY_EGG_VERSION}/
> :+GH_ACCOUNT =OfflineIMAP
> :+GH_PROJECT =offlineimap
> :+GH_TAGNAME =v${MODPY_EGG_VERSION}
> :+GH_COMMIT = 7770b5ff73737d1269eb1ba7554b8d3486c7f5ec
> :+DISTNAME = offlineimap-${MODPY_EGG_VERSION}
> :
> : NO_TEST=Yes
> :
> : MODULES=lang/python
> :
> : BUILD_DEPENDS= textproc/py-docutils
> :-
> :-WRKDIST=${WRKDIR}/spaetz-offlineimap-c9e9690
> :
> : EXAMPLESDIR=${PREFIX}/share/examples/offlineimap
> :
> :Index: distinfo
> :===
> :RCS file: /home/edd/cvsync/ports/mail/offlineimap/distinfo,v
> :retrieving revision 1.16
> :diff -u -p -r1.16 distinfo
> :--- distinfo 15 Aug 2012 13:09:58 - 1.16
> :+++ distinfo 22 Oct 2014 20:51:55 -
> :@@ -1,2 +1,2 @@
> :-SHA256 (offlineimap-6.5.4.tar.gz) =
> gxqXtRVPOYtl4cBkJ2aLeM+DPZn6w2zIJ4rSzww5Ogw=
> :-SIZE (offlineimap-6.5.4.tar.gz) = 167023
> :+SHA256 (offlineimap-6.5.6.tar.gz) =
> wjIZzbuuf+EjRuzpTEJ3N/1Ag3IKEk//b5WibFb3KMM=
> :+SIZE (offlineimap-6.5.6.tar.gz) = 187803
> :Index: patches/patch-docs_MANUAL_rst
> :===
> :RCS file:
> /home/edd/cvsync/ports/mail/offlineimap/patches/patch-docs_MANUAL_rst,v
> :retrieving revision 1.3
> :diff -u -p -r1.3 patch-docs_MANUAL_rst
> :--- patches/patch-docs_MANUAL_rst15 Aug 2012 13:09:59 - 1.3
> :+++ patches/patch-docs_MANUAL_rst22 Oct 2014 20:51:55 -
> :@@ -1,7 +1,7 @@
> : $OpenBSD: patch-docs_MANUAL_rst,v 1.3 2012/08/15 13:09:59 gonzalo Exp $
> : docs/MANUAL.rst.origSat Jun 2 08:41:46 2012
> :-+++ docs/MANUAL.rst Mon Aug 6 17:32:45 2012
> :-@@ -322,7 +322,7 @@ a running offlineimap "daemon".
> :+--- docs/MANUAL.rst.origFri May 23 18:50:46 2014
> : docs/MANUAL.rst Wed Oct 22 21:43:18 2014
> :+@@ -335,7 +335,7 @@ core.
> : Folder filtering and nametrans
> : ==
> :
> :Index: patches/patch-offlineimap___init___py
> :===
> :RCS file: patches/patch-offlineimap___init___py
> :diff -N patches/patch-offlineimap___init___py
> :--- /dev/null1 Jan 1970 00:00:00 -
> :+++ patches/patch-offlineimap___init___py22 Oct 2014 20:51:55 -
> :@@ -0,0 +1,15 @@
> :+$OpenBSD$
> :+
> :+They forgot to bump the version.
> :+
> :+--- offlineimap/__init__.py.origWed Oct 22 21:46:26 2014
> : offlineimap/__init__.py Wed Oct 22 21:46:36 2014
> :+@@ -1,7 +1,7 @@
> :+ __all__ = ['OfflineImap']
> :+
> :+ __productname__ = 'OfflineIMAP'
> :+-__version__ = "6.5.5"
> :++__version__ = "6.5.6"
> :+ __copyright__ = "Copyright 2002-2013 John Goerzen & contributors"
> :+ __author__ = "John Goerzen"
> :+ __author_email__= "j...@complete.org"
> :Index: patches/patch-offlineimap_conf
> :===
> :RCS file:
> /home/edd/cvsync/ports/mail/offlineimap/patches/patch-offlineimap_conf,v
> :retrieving revision 1.2
> :diff -u -p -r1.2 patch-offlineimap_conf
> :--- patches/patch-offlineimap_conf 15 Aug 2012 13:09:59 - 1.2
> :+++ patches/patch-offlineimap_conf 22 Oct 2014 20:51:55 -
> :@@ -1,7 +1,7 @@
> : $OpenBSD: patch-offlineimap_conf,v 1.2 2012/08/15 13:09:59 gonzalo Exp $
> : offlineimap.conf.orig Sat Jun 2 08:41:46 2012
> :-+++ offlineimap.confMon Aug 6 17:32:45 2012
> :-@@ -312,7 +312,7 @@ ssl = yes
> :+--- offlineimap.conf.orig Fri May 23 18:50:46 2014
> : offlineimap.confWed Oct 22 21:43:18 2014
> :+@@ -385,7 +385,7 @@ ssl = yes
> : # specified, the CA Cert(s) need to verify the Serve
Re: UPDATE: mail/offlineimap
I ended up creating basically the same patch, this is OK from me.
I like sthen's comment to move the GH_COMMIT next to the
MODPY_EGG_VERSION, as well.
(also adding the MAINTAINER to the email list)
On 2014 Oct 30 (Thu) at 22:08:13 + (+), Edd Barrett wrote:
:Hey,
:
:Update to offlineimap. I have been running this for a while now. No
:issues. First time I have used GH_*, so please check carefully.
:
:OK?
:
:Index: Makefile
:===
:RCS file: /home/edd/cvsync/ports/mail/offlineimap/Makefile,v
:retrieving revision 1.26
:diff -u -p -r1.26 Makefile
:--- Makefile 11 Mar 2013 11:23:52 - 1.26
:+++ Makefile 30 Oct 2014 21:58:30 -
:@@ -2,7 +2,7 @@
:
: COMMENT= powerful IMAP/Maildir synchronization and reader support
:
:-MODPY_EGG_VERSION= 6.5.4
:+MODPY_EGG_VERSION= 6.5.6
: DISTNAME= offlineimap-${MODPY_EGG_VERSION}
: CATEGORIES= mail
:
:@@ -13,15 +13,17 @@ MAINTAINER=Pierre-Emmanuel Andre https://github.com/spaetz/offlineimap/tarball/v${MODPY_EGG_VERSION}/
:+GH_ACCOUNT = OfflineIMAP
:+GH_PROJECT = offlineimap
:+GH_TAGNAME = v${MODPY_EGG_VERSION}
:+GH_COMMIT = 7770b5ff73737d1269eb1ba7554b8d3486c7f5ec
:+DISTNAME =offlineimap-${MODPY_EGG_VERSION}
:
: NO_TEST= Yes
:
: MODULES= lang/python
:
: BUILD_DEPENDS=textproc/py-docutils
:-
:-WRKDIST= ${WRKDIR}/spaetz-offlineimap-c9e9690
:
: EXAMPLESDIR= ${PREFIX}/share/examples/offlineimap
:
:Index: distinfo
:===
:RCS file: /home/edd/cvsync/ports/mail/offlineimap/distinfo,v
:retrieving revision 1.16
:diff -u -p -r1.16 distinfo
:--- distinfo 15 Aug 2012 13:09:58 - 1.16
:+++ distinfo 22 Oct 2014 20:51:55 -
:@@ -1,2 +1,2 @@
:-SHA256 (offlineimap-6.5.4.tar.gz) =
gxqXtRVPOYtl4cBkJ2aLeM+DPZn6w2zIJ4rSzww5Ogw=
:-SIZE (offlineimap-6.5.4.tar.gz) = 167023
:+SHA256 (offlineimap-6.5.6.tar.gz) =
wjIZzbuuf+EjRuzpTEJ3N/1Ag3IKEk//b5WibFb3KMM=
:+SIZE (offlineimap-6.5.6.tar.gz) = 187803
:Index: patches/patch-docs_MANUAL_rst
:===
:RCS file:
/home/edd/cvsync/ports/mail/offlineimap/patches/patch-docs_MANUAL_rst,v
:retrieving revision 1.3
:diff -u -p -r1.3 patch-docs_MANUAL_rst
:--- patches/patch-docs_MANUAL_rst 15 Aug 2012 13:09:59 - 1.3
:+++ patches/patch-docs_MANUAL_rst 22 Oct 2014 20:51:55 -
:@@ -1,7 +1,7 @@
: $OpenBSD: patch-docs_MANUAL_rst,v 1.3 2012/08/15 13:09:59 gonzalo Exp $
: docs/MANUAL.rst.orig Sat Jun 2 08:41:46 2012
:-+++ docs/MANUAL.rst Mon Aug 6 17:32:45 2012
:-@@ -322,7 +322,7 @@ a running offlineimap "daemon".
:+--- docs/MANUAL.rst.orig Fri May 23 18:50:46 2014
: docs/MANUAL.rst Wed Oct 22 21:43:18 2014
:+@@ -335,7 +335,7 @@ core.
: Folder filtering and nametrans
: ==
:
:Index: patches/patch-offlineimap___init___py
:===
:RCS file: patches/patch-offlineimap___init___py
:diff -N patches/patch-offlineimap___init___py
:--- /dev/null 1 Jan 1970 00:00:00 -
:+++ patches/patch-offlineimap___init___py 22 Oct 2014 20:51:55 -
:@@ -0,0 +1,15 @@
:+$OpenBSD$
:+
:+They forgot to bump the version.
:+
:+--- offlineimap/__init__.py.orig Wed Oct 22 21:46:26 2014
: offlineimap/__init__.py Wed Oct 22 21:46:36 2014
:+@@ -1,7 +1,7 @@
:+ __all__ = ['OfflineImap']
:+
:+ __productname__ = 'OfflineIMAP'
:+-__version__ = "6.5.5"
:++__version__ = "6.5.6"
:+ __copyright__ = "Copyright 2002-2013 John Goerzen & contributors"
:+ __author__ = "John Goerzen"
:+ __author_email__= "j...@complete.org"
:Index: patches/patch-offlineimap_conf
:===
:RCS file:
/home/edd/cvsync/ports/mail/offlineimap/patches/patch-offlineimap_conf,v
:retrieving revision 1.2
:diff -u -p -r1.2 patch-offlineimap_conf
:--- patches/patch-offlineimap_conf 15 Aug 2012 13:09:59 - 1.2
:+++ patches/patch-offlineimap_conf 22 Oct 2014 20:51:55 -
:@@ -1,7 +1,7 @@
: $OpenBSD: patch-offlineimap_conf,v 1.2 2012/08/15 13:09:59 gonzalo Exp $
: offlineimap.conf.orig Sat Jun 2 08:41:46 2012
:-+++ offlineimap.conf Mon Aug 6 17:32:45 2012
:-@@ -312,7 +312,7 @@ ssl = yes
:+--- offlineimap.conf.orig Fri May 23 18:50:46 2014
: offlineimap.conf Wed Oct 22 21:43:18 2014
:+@@ -385,7 +385,7 @@ ssl = yes
: # specified, the CA Cert(s) need to verify the Server cert AND
: # match the hostname (* wildcard allowed on the left hand side)
: # The certificate should be in PEM format.
:Index: pkg/PLIST
:===
:RCS file: /home/edd/cvsync/ports/mail/offlineimap/pkg/PLIST,v
:retrieving revision 1.11
:diff -u -p -r1.11 PLIST
:--- pkg/PLIST 13 May 2012 11:56:35 - 1.11
:+++ pkg/PLIST 22 Oct 2014 20:51:55 -
:@@ -8,6 +8,8 @@ lib/pytho
Re: NEW: x11/mpv [0.6.2]
On Thu, Nov 20, 2014 at 08:45:45AM +0100, Dmitrij D. Czarkoff wrote: > Anthony J. Bentley said: > > Not sure if this is related, but sound is very choppy for me, and: > > > > AV: 00:05:23 / 01:40:58 (5%) A-V: 0.020 > > [ao/sndio] Blocking until remaining audio is played... (sndio design bug). > > > > was added in this commit: > > https://github.com/mpv-player/mpv/commit/387d5f55e639425bfb6ee1efec4e21202e5642ad > > > >"ao_sndio: print a warning when draining audio > > > >"libsndio has absolutely no mechanism to discard already written audio > > (other than SIGKILLing the sound server). sio_stop() will always block > > until all audio is played. This is a legitimate design bug. > > > >"In theory, we could just not stop it at all, so if the player is e.g. > > paused, the remaining audio would be played. When resuming, we would > > have to do something to ensure get_delay() returns the right value. But > > I couldn't get it to work in all cases." > > > > I was previously using a crappy hand-rolled port of... 0.4.something? > > which wasn't nearly as slow. > > I rebuilt mpv with sdl audio backend, and I still have the same issue: > playback periodically pauses for a fraction of second. With sdl backend > audio also pauses, while with sndio backend it "cracks". The frequency > of pauses seeming depends on video resolution: 1280x720 videos pause > every several seconds, 480x360 video only a couple of times per minute, > while 360x270 plays smoothly. Switching of video backend changes > nothing (with notable exception of "opengl-hq" backend with fails to > start). > > Still, with sdl backend audio files play smoothly, while sndio backend > makes everything inaudible. sorry, don't have the time to test & debug this right now, but a quick look at the ao_sndio.c suggest that blocking mode is used, while the device is opened in non-blocking mode: p->hdl = sio_open(p->dev, SIO_PLAY, 1); ^^ could you replace 1 by 0, and see if it makes things better?
Re: NEW: x11/mpv [0.6.2]
On Wed, Nov 19, 2014 at 08:45:50PM -0700, Anthony J. Bentley wrote: > "Dmitrij D. Czarkoff" writes: > > FWIW on my ThinkPad E325 the performance of mpv is really bad. (MPlayer > > does no good here either, although ffplay copes with everything just > > fine.) I also noticed that it has problems with unmuting if master > > output was muted before mpv started. To really unmute I had to mute > > sound in mpv by pressing "m" and then unmute it by pressing Mute button > > on my keyboard; no other combination worked out. > > Not sure if this is related, but sound is very choppy for me, and: > > AV: 00:05:23 / 01:40:58 (5%) A-V: 0.020 > [ao/sndio] Blocking until remaining audio is played... (sndio design bug). > > was added in this commit: > https://github.com/mpv-player/mpv/commit/387d5f55e639425bfb6ee1efec4e21202e5642ad > >"ao_sndio: print a warning when draining audio > >"libsndio has absolutely no mechanism to discard already written audio > (other than SIGKILLing the sound server). sio_stop() will always block > until all audio is played. This is a legitimate design bug. > >"In theory, we could just not stop it at all, so if the player is e.g. > paused, the remaining audio would be played. When resuming, we would > have to do something to ensure get_delay() returns the right value. But > I couldn't get it to work in all cases." > The above discussed "bug" is that when one hits the pause button, audio doesn't stop immediately, but blocks during ~0.2 seconds while finishing playing the already submitted audio samples. Mpv developpers complain about sndio not providing a function to discard submitted audio samples. The problem is about stopping and doesn't affect sound during playback. The "choppy sound" during playback is caused by something else. It used to work so it's fixable :) [...] Out of curiousity, what's the CPU why playing videos with the choppy sound? -- Alexandre
Re: NEW: x11/mpv [0.6.2]
On Thu, Nov 20, 2014 at 02:43:05AM +0100, Dmitrij D. Czarkoff wrote: > Henrik Friedrichsen said: > > I understand. I have attached another version that fetches all the files > > in the fetch phase. > > > > Could you give it another try? > > I made some changes to the port. (See attached tarball for details.) > > FWIW on my ThinkPad E325 the performance of mpv is really bad. (MPlayer > does no good here either, although ffplay copes with everything just > fine.) This used to work well last year; I just compiled the sources from github and it worked out of the box. I'll look at this as soon as I get some free time. > I also noticed that it has problems with unmuting if master > output was muted before mpv started. To really unmute I had to mute > sound in mpv by pressing "m" and then unmute it by pressing Mute button > on my keyboard; no other combination worked out. > This is a known keyboard driver bug, the fix (not commited) discussed here: http://comments.gmane.org/gmane.os.openbsd.tech/36229 -- Alex
