CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2019/05/24 21:36:20 Modified files: news/sabnzbd : Makefile distinfo Log message: Update to sabnzbd-2.3.9. Improvements and bug fix release. Changelog can be found at https://github.com/sabnzbd/sabnzbd/releases/tag/2.3.9
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/05/24 16:43:45 Modified files: audio/audacious-plugins: Makefile Added files: audio/audacious-plugins/patches: patch-src_neon_neon_cc Log message: audacious-plugins: unbreak the build with ports-gcc Using feof() as a method name clashed with feof(3), a macro. Tested on macppc. While here, move HOMEPAGE to https. Thanks to jca@ and naddy@ for pointing out that an unrelated issue was local and didn't need patching, and bcallah@ for testing on amd64. OK jca@ naddy@
Re: [ports-gcc] Unbreak and fix audio/audacious-plugins
On Fri, 24 May 2019 21:47:36 +0200 Christian Weisgerber wrote: > Christian Weisgerber: > > > > So i've stopped sndiod in the chroot, restarted sndiod on my main > > > install, then started audacious in the chroot: the white noise > > > issue is back. > > > > The chrooted audacious doesn't see the /tmp/sndio/sock0 socket. It > > acts as if there was no sndiod running. libsndio will try talking > > directly to the audio device, but without daemon it's short on > > format conversions. I guess the device is eventually fed data in > > a format it doesn't support. I was totally oblivious about the Unix socket, i'll use a network socket indeed, it's a better and sure option. It's quite a corner case, but i'll ask ratchov@ anyway :) > PS: > When I stop sndiod on my amd64 laptop with azalia(4) and run audacious > there, it also produces white noise. > > -- > Christian "naddy" Weisgerber > na...@mips.inka.de >
Re: dpb doesn't forget invalid distfile
Marc Espie: > > E=education/anki:anki-2.0.52-source.tgz > > What do I need to delete to get rid of this persistent fetch error? > > Look in distfiles/history ? It's not in distfiles/history or distfiles/distinfo. There were entries in distfiles/build-stats/amd64 that I removed to no result. -- Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/24 15:02:07 Modified files: sysutils/random_run: Makefile distinfo Log message: bug fix
Re: dpb doesn't forget invalid distfile
Solene Rapenne: > Did you clean the distfile fetch lock in $PORTSDIR/logs/$arch/locks/? Yes. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: dpb doesn't forget invalid distfile
On Fri, May 24, 2019 at 10:28:31PM +0200, Christian Weisgerber wrote: > A while back, education/anki was updated to 2.0.52. dpb -F tried to > fetch it, but failed. Shortly afterwards, the anki port was marked > BROKEN. Ever since, dpb on this machine has kept reporting this > fetch error: > E=education/anki:anki-2.0.52-source.tgz > > It simply doesn't forget. > > There is no such error on machines where dpb did not perform a fetch > run during the brief window when anki-2.0.52 was enabled. > > Clearly, dpb remembers something, somewhere, but I can't find it. > What do I need to delete to get rid of this persistent fetch error? Strange Look in distfiles/history ?
Re: dpb doesn't forget invalid distfile
On Fri, May 24, 2019 at 10:28:31PM +0200, Christian Weisgerber wrote: > A while back, education/anki was updated to 2.0.52. dpb -F tried to > fetch it, but failed. Shortly afterwards, the anki port was marked > BROKEN. Ever since, dpb on this machine has kept reporting this > fetch error: > E=education/anki:anki-2.0.52-source.tgz > > It simply doesn't forget. > > There is no such error on machines where dpb did not perform a fetch > run during the brief window when anki-2.0.52 was enabled. > > Clearly, dpb remembers something, somewhere, but I can't find it. > What do I need to delete to get rid of this persistent fetch error? > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Did you clean the distfile fetch lock in $PORTSDIR/logs/$arch/locks/?
dpb doesn't forget invalid distfile
A while back, education/anki was updated to 2.0.52. dpb -F tried to fetch it, but failed. Shortly afterwards, the anki port was marked BROKEN. Ever since, dpb on this machine has kept reporting this fetch error: E=education/anki:anki-2.0.52-source.tgz It simply doesn't forget. There is no such error on machines where dpb did not perform a fetch run during the brief window when anki-2.0.52 was enabled. Clearly, dpb remembers something, somewhere, but I can't find it. What do I need to delete to get rid of this persistent fetch error? -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [ports-gcc] Unbreak and fix audio/audacious-plugins
Christian Weisgerber: > > So i've stopped sndiod in the chroot, restarted sndiod on my main > > install, then started audacious in the chroot: the white noise > > issue is back. > > The chrooted audacious doesn't see the /tmp/sndio/sock0 socket. It > acts as if there was no sndiod running. libsndio will try talking > directly to the audio device, but without daemon it's short on > format conversions. I guess the device is eventually fed data in > a format it doesn't support. PS: When I stop sndiod on my amd64 laptop with azalia(4) and run audacious there, it also produces white noise. -- Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2019/05/24 13:09:15 Modified files: www/chromium : Makefile distinfo www/chromium/patches: patch-chrome_app_generated_resources_grd patch-chrome_browser_download_chrome_download_manager_delegate_cc patch-chrome_browser_policy_configuration_policy_handler_list_factory_cc patch-chrome_browser_resources_plugin_metadata_plugins_linux_json patch-chrome_common_BUILD_gn patch-chrome_common_chrome_paths_internal_h patch-chrome_common_chrome_switches_cc patch-chrome_common_chrome_switches_h patch-chrome_test_BUILD_gn patch-components_policy_resources_policy_templates_json patch-content_browser_media_media_internals_cc patch-content_shell_BUILD_gn patch-media_audio_audio_thread_impl_cc patch-services_network_network_context_cc patch-services_network_network_service_cc patch-ui_views_controls_textfield_textfield_cc Log message: update to 75.0.3770.52
Re: [ports-gcc] Unbreak and fix audio/audacious-plugins
Charlene Wendling: > So i've stopped sndiod in the chroot, restarted sndiod on my main > install, then started audacious in the chroot: the white noise > issue is back. The chrooted audacious doesn't see the /tmp/sndio/sock0 socket. It acts as if there was no sndiod running. libsndio will try talking directly to the audio device, but without daemon it's short on format conversions. I guess the device is eventually fed data in a format it doesn't support. Not sure if that is supposed to happen; ask ratchov@. :-) I don't see a sndiod option to create an extra Unix domain socket, but you can make sndiod listen on a network socket with the -L option and use an environment setting like AUDIODEVICE=snd@127.0.0.1/0 inside the chroot to let the inside libsndio talk to the outside sndiod over the network. > And the problem only occurs with audacious: mpv, ffplay, mpg321 > and cmus work fine in the same conditions! I suspect audacious is different in that it defaults to a 32-bit format instead of a 16-bit one. That's why it works when you set audacious' bit depth option to 16. > INFO output.cc:175 [setup_output]: Setup output, format 0, 2 channels, 44100 > Hz. > DEBUG sndio.cc:171 [open_audio]: format=0 > INFO output.cc:199 [setup_output]: Falling back to format 12. > DEBUG sndio.cc:171 [open_audio]: format=12 > DEBUG sndio.cc:186 [open_audio]: bits=32 bytes=4 sign=1 le=0 Yeah, it first tries FMT_FLOAT (0) and then falls back to FMT_S32_NE, which is FMT_S32_BE (12) on powerpc. That's fine. > I'm sending a diff with that bit removed at least. -snip- ok -- Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2019/05/24 11:43:05 Modified files: x11/compton: Makefile x11/compton/patches: patch-src_compton_c patch-src_opengl_c Log message: fix vsync drm by using correct drm path; by mrme0w _aT_ protonmail DOT ch, thanks! While here take MAINTAINER. ok sthen@, jca@
Re: Blender - no gui menu displayed
On Fri, May 24 2019, Jeremie Courreges-Anglas wrote:
> +cc Pascal (maintainer of blender)
>
> On Mon, May 20 2019, Mihai Popescu wrote:
>> Hello,
>>
>> Maybe it is already known, but blender is not able to display gui
>> menus. IT renders just a blank no menu and items window. I will send
>> some terminal errors and dmesg. More info can be sent later.
>>
>> search for unknown operator 'WM_OT_context_set_enum',
>> 'WM_OT_context_set_enum'
>> RNA_string_set: OperatorProperties.data_path not found.
>> RNA_string_set: OperatorProperties.value not found.
>
> [...]
>
>> uiItemStringO: 'WM_OT_url_open' unknown operator
>> search for unknown menutype USERPREF_MT_splash_footer
>>
>> Blender quit
>>
>> OpenBSD 6.5-current (GENERIC.MP) #35: Sat May 18 11:40:36 MDT 2019
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> [...]
>
> Rebuilding blender with
>
> MODPY_VERSION =3.6
>
> fixes the UI issue here, I guess this could be used as a workaround.
> (Is there any rush to get rid of 3.6?)
>
> Updating the port to 2.79b didn't help.
>
> This issue may be relevant:
>
> "Blender UI failed to render using Python 3.7"
> https://developer.blender.org/T56969
This indeed fixes the UI glitches.
patch-source_blender_python_intern_bpy_rna_c below addresses this.
And since I had lightly tested an update to blender-2.79b, here's an
update diff.
Pascal, thoughts/ok?
Index: Makefile
===
RCS file: /cvs/ports/graphics/blender/Makefile,v
retrieving revision 1.91
diff -u -p -r1.91 Makefile
--- Makefile28 Apr 2019 20:51:41 - 1.91
+++ Makefile24 May 2019 17:26:46 -
@@ -4,8 +4,8 @@ ONLY_FOR_ARCHS = amd64 i386
COMMENT = 3D creation software
-DISTNAME = blender-2.79
-REVISION = 5
+DISTNAME = blender-2.79b
+PKGNAME = blender-2.79pl1
CATEGORIES = graphics
@@ -17,7 +17,7 @@ MAINTAINER = Pascal Stumpf oformat->flags & AVFMT_GLOBALHEADER) {
@@ -41,7 +41,7 @@ Index: source/blender/blenkernel/intern/
}
set_ffmpeg_properties(rd, c, "audio", );
-@@ -783,14 +781,14 @@ static AVStream *alloc_audio_stream(FFMpegContext *con
+@@ -784,14 +782,14 @@ static AVStream *alloc_audio_stream(FFMpegContext *con
st->codec->time_base.den = st->codec->sample_rate;
#ifndef FFMPEG_HAVE_ENCODE_AUDIO2
Index: patches/patch-source_blender_python_intern_bpy_rna_c
===
RCS file: patches/patch-source_blender_python_intern_bpy_rna_c
diff -N patches/patch-source_blender_python_intern_bpy_rna_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-source_blender_python_intern_bpy_rna_c24 May 2019
17:26:46 -
@@ -0,0 +1,26 @@
+$OpenBSD$
+
+Fix PyRNA class registration w/ Python 3.7
+https://developer.blender.org/rB1db47a2ccd1e68994bf8140eba6cc2a26a2bc91f
+
+Index: source/blender/python/intern/bpy_rna.c
+--- source/blender/python/intern/bpy_rna.c.orig
source/blender/python/intern/bpy_rna.c
+@@ -7389,6 +7389,7 @@ static int bpy_class_validate_recursive(PointerRNA *du
+ item = PyObject_GetAttrString(py_class, identifier);
+
+ if (item == NULL) {
++ PyErr_Clear();
+ /* Sneaky workaround to use the class name as the
bl_idname */
+
+ #define BPY_REPLACEMENT_STRING(rna_attr, py_attr)
\
+@@ -7404,6 +7405,9 @@ static int bpy_class_validate_recursive(PointerRNA *du
+ }
\
+ Py_DECREF(item);
\
+ }
\
++ else { \
++ PyErr_Clear(); \
++ } \
+ } /* intentionally allow else here */
+
+ if (false) {} /* needed for macro */
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [ports-gcc] Unbreak and fix audio/audacious-plugins
On Fri, May 24 2019, Charlene Wendling wrote:
> Hi,
>
> On Fri, 24 May 2019 13:41:32 +0200
> Christian Weisgerber wrote:
>
>> Charlene Wendling:
>>
>> > - It doesn't build with ports-gcc (macppc [0], sparc64 [1])
>> >
>> > The problem here is again a macro vs function issue. I've applied
>> > the same thing upstream still does on audacious proper [2]:
>> > undef'ing feof(3).
>>
>> That part is fine.
>>
>> > - At least on macppc, it does some white noise during playback
>> >
>> > After poking around, i've found out it was a bit depth issue when
>> > the related audio setting is on "automatic". Setting manually to
>> > 16 bit fixed the issue, but it's supposed to work...
>> > automatically.
>> >
>> > mpv does things differently [3] and i have no sound issues
>> > (excepted for CDDA) on macppc. So after comparing their work, and
>> > reading the sio_open(3) manpage, i've changed some parameters to
>> > make it work ootb.
>>
>> I object. This cannot be correct. fdata->bytes can't be wrong,
>> we're getting it from our own table, and otherwise you're nailing
>> everything to signed native endian, no matter what the actual input
>> format is. You are hiding the actual bug.
>
> You're right. In fact, it has been "fixed" again.
>
> After rebuilding audacious-plugins in my chroot where i do port
> works/tests, with your diff and without my sndio changes. It
> appears that it works. Since your diff add only debug infos,
> i was puzzled.
>
> What has changed between then and now? I have permanently disabled
> sndiod on my main install, instead starting it in my chroot.
>
> So i've stopped sndiod in the chroot, restarted sndiod on my main
> install, then started audacious in the chroot: the white noise
> issue is back.
>
> I run sndiod with no customised flags, sndiod_flags is really empty in
> /etc/rc.conf (just checked, in case i would have forgotten something).
>
> And the problem only occurs with audacious: mpv, ffplay, mpg321
> and cmus work fine in the same conditions!
>
>> Since the output format in "automatic" always appears to be 32-bit
>> signed native endian (after falling back from float), I'm surprised
>> that your change actually changes any behavior.
>>
>> > + par.bits = fdata->bits;
>> > +-par.bps = fdata->bytes;
>> > +-par.sig = fdata->sign;
>> > +-par.le = fdata->le;
>> > ++par.bps = SIO_BPS(par.bits);
>> > ++par.sig = 1;
>> > ++par.le = SIO_LE_NATIVE;
>>
>> Can you try audacious -VV with the patch below and tell us the
>> messages from [setup_output] and [open_audio]?
>>
>> --- src/sndio/sndio.cc.orig Fri May 24 03:14:01 2019
>> +++ src/sndio/sndio.cc Fri May 24 04:27:30 2019
>> @@ -168,6 +168,7 @@
>>
>> bool SndioPlugin::open_audio (int format, int rate, int channels,
>> String & error) {
>> +AUDDBG("format=%d\n", format);
>> const FormatData * fdata = nullptr;
>>
>> for (const FormatData & f : format_table)
>> @@ -181,6 +182,8 @@
>> error = String (str_printf (_("Sndio error: Unsupported
>> audio format (%d)"), format)); return false;
>> }
>> +AUDDBG("bits=%d bytes=%d sign=%d le=%d\n",
>> +fdata->bits, fdata->bytes, fdata->sign, fdata->le);
>>
>> String device = aud_get_str ("sndio", "device");
>> const char * device2 = device[0] ? (const char *) device :
>> SIO_DEVANY;
>
> In any case the output is similar:
>
> INFO output.cc:175 [setup_output]: Setup output, format 0, 2 channels, 44100
> Hz.
> DEBUG sndio.cc:171 [open_audio]: format=0
> INFO output.cc:199 [setup_output]: Falling back to format 12.
> DEBUG sndio.cc:171 [open_audio]: format=12
> DEBUG sndio.cc:186 [open_audio]: bits=32 bytes=4 sign=1 le=0
>
> I'm sending a diff with that bit removed at least.
ok jca@
> Charlène.
>
>> --
>> Christian "naddy" Weisgerber
>> na...@mips.inka.de
>>
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/audio/audacious-plugins/Makefile,v
> retrieving revision 1.78
> diff -u -p -u -p -r1.78 Makefile
> --- Makefile 20 May 2019 22:15:00 - 1.78
> +++ Makefile 24 May 2019 14:52:21 -
> @@ -4,11 +4,11 @@ COMMENT = input and output plugins for
>
> V = 3.9
> DISTNAME = audacious-plugins-$V
> -REVISION = 2
> +REVISION = 3
>
> CATEGORIES = audio multimedia
>
> -HOMEPAGE = http://audacious-media-player.org/
> +HOMEPAGE = https://audacious-media-player.org/
>
> # BSD / GPL
> PERMIT_PACKAGE_CDROM = Yes
> Index: patches/patch-src_neon_neon_cc
> ===
> RCS file: patches/patch-src_neon_neon_cc
> diff -N patches/patch-src_neon_neon_cc
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_neon_neon_cc24 May 2019 14:52:21 -
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +
> +Fix for ports gcc as feof() is a macro
> +
> +neon.cc:968:16: error: expected
Re: [NEW] misc/nnn
Openports.se is nothing to do with us and doesn't work very well. To search for ports I recommend installing the pkglocatedb package and use "pkglocate filename" - for this I would try "pkglocate bin/nnn". Sending an update diff is probably worthwhile - please CC the maintainer. -- Sent from a phone, apologies for poor formatting. On 24 May 2019 14:27:39 bijan wrote: On 5/24/19 5:46 PM, Brian Callahan wrote: On 5/24/19 9:12 AM, bijan wrote: Hi ports, I made a port of nnn file manager. it a snappy file manager for the ninjas (I guess). P.S: It's my first attempt to contribute to OpenBSD ports tree. More ports will come shortly as soon as I find the time. Thanks in advance for the critics. And hope it helps others :-) B.E Is this the same as sysutils/nnn? Yes, apparently although I'm wondering why my search didn't find any results even in openports.se. Thanks! Maybe I should post a diff updating the already existing sysutils/nnn since it's a very old version. B.E
Re: [ports-gcc] Unbreak and fix audio/audacious-plugins
Hi,
On Fri, 24 May 2019 13:41:32 +0200
Christian Weisgerber wrote:
> Charlene Wendling:
>
> > - It doesn't build with ports-gcc (macppc [0], sparc64 [1])
> >
> > The problem here is again a macro vs function issue. I've applied
> > the same thing upstream still does on audacious proper [2]:
> > undef'ing feof(3).
>
> That part is fine.
>
> > - At least on macppc, it does some white noise during playback
> >
> > After poking around, i've found out it was a bit depth issue when
> > the related audio setting is on "automatic". Setting manually to
> > 16 bit fixed the issue, but it's supposed to work...
> > automatically.
> >
> > mpv does things differently [3] and i have no sound issues
> > (excepted for CDDA) on macppc. So after comparing their work, and
> > reading the sio_open(3) manpage, i've changed some parameters to
> > make it work ootb.
>
> I object. This cannot be correct. fdata->bytes can't be wrong,
> we're getting it from our own table, and otherwise you're nailing
> everything to signed native endian, no matter what the actual input
> format is. You are hiding the actual bug.
You're right. In fact, it has been "fixed" again.
After rebuilding audacious-plugins in my chroot where i do port
works/tests, with your diff and without my sndio changes. It
appears that it works. Since your diff add only debug infos,
i was puzzled.
What has changed between then and now? I have permanently disabled
sndiod on my main install, instead starting it in my chroot.
So i've stopped sndiod in the chroot, restarted sndiod on my main
install, then started audacious in the chroot: the white noise
issue is back.
I run sndiod with no customised flags, sndiod_flags is really empty in
/etc/rc.conf (just checked, in case i would have forgotten something).
And the problem only occurs with audacious: mpv, ffplay, mpg321
and cmus work fine in the same conditions!
> Since the output format in "automatic" always appears to be 32-bit
> signed native endian (after falling back from float), I'm surprised
> that your change actually changes any behavior.
>
> > + par.bits = fdata->bits;
> > +-par.bps = fdata->bytes;
> > +-par.sig = fdata->sign;
> > +-par.le = fdata->le;
> > ++par.bps = SIO_BPS(par.bits);
> > ++par.sig = 1;
> > ++par.le = SIO_LE_NATIVE;
>
> Can you try audacious -VV with the patch below and tell us the
> messages from [setup_output] and [open_audio]?
>
> --- src/sndio/sndio.cc.orig Fri May 24 03:14:01 2019
> +++ src/sndio/sndio.ccFri May 24 04:27:30 2019
> @@ -168,6 +168,7 @@
>
> bool SndioPlugin::open_audio (int format, int rate, int channels,
> String & error) {
> +AUDDBG("format=%d\n", format);
> const FormatData * fdata = nullptr;
>
> for (const FormatData & f : format_table)
> @@ -181,6 +182,8 @@
> error = String (str_printf (_("Sndio error: Unsupported
> audio format (%d)"), format)); return false;
> }
> +AUDDBG("bits=%d bytes=%d sign=%d le=%d\n",
> + fdata->bits, fdata->bytes, fdata->sign, fdata->le);
>
> String device = aud_get_str ("sndio", "device");
> const char * device2 = device[0] ? (const char *) device :
> SIO_DEVANY;
In any case the output is similar:
INFO output.cc:175 [setup_output]: Setup output, format 0, 2 channels, 44100 Hz.
DEBUG sndio.cc:171 [open_audio]: format=0
INFO output.cc:199 [setup_output]: Falling back to format 12.
DEBUG sndio.cc:171 [open_audio]: format=12
DEBUG sndio.cc:186 [open_audio]: bits=32 bytes=4 sign=1 le=0
I'm sending a diff with that bit removed at least.
Charlène.
> --
> Christian "naddy" Weisgerber
> na...@mips.inka.de
>
Index: Makefile
===
RCS file: /cvs/ports/audio/audacious-plugins/Makefile,v
retrieving revision 1.78
diff -u -p -u -p -r1.78 Makefile
--- Makefile20 May 2019 22:15:00 - 1.78
+++ Makefile24 May 2019 14:52:21 -
@@ -4,11 +4,11 @@ COMMENT = input and output plugins for
V =3.9
DISTNAME = audacious-plugins-$V
-REVISION = 2
+REVISION = 3
CATEGORIES = audio multimedia
-HOMEPAGE = http://audacious-media-player.org/
+HOMEPAGE = https://audacious-media-player.org/
# BSD / GPL
PERMIT_PACKAGE_CDROM = Yes
Index: patches/patch-src_neon_neon_cc
===
RCS file: patches/patch-src_neon_neon_cc
diff -N patches/patch-src_neon_neon_cc
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_neon_neon_cc 24 May 2019 14:52:21 -
@@ -0,0 +1,19 @@
+$OpenBSD$
+
+Fix for ports gcc as feof() is a macro
+
+neon.cc:968:16: error: expected unqualified-id before '(' token
+bool NeonFile::feof ()
+
+Index: src/neon/neon.cc
+--- src/neon/neon.cc.orig
src/neon/neon.cc
+@@ -45,6 +45,8 @@
+ #define NEON_ICY_BUFSIZE(4096)
+ #define NEON_RETRY_COUNT 6
+
++#undef feof
Re: Blender - no gui menu displayed
+cc Pascal (maintainer of blender)
On Mon, May 20 2019, Mihai Popescu wrote:
> Hello,
>
> Maybe it is already known, but blender is not able to display gui
> menus. IT renders just a blank no menu and items window. I will send
> some terminal errors and dmesg. More info can be sent later.
>
> search for unknown operator 'WM_OT_context_set_enum', 'WM_OT_context_set_enum'
> RNA_string_set: OperatorProperties.data_path not found.
> RNA_string_set: OperatorProperties.value not found.
[...]
> uiItemStringO: 'WM_OT_url_open' unknown operator
> search for unknown menutype USERPREF_MT_splash_footer
>
> Blender quit
>
> OpenBSD 6.5-current (GENERIC.MP) #35: Sat May 18 11:40:36 MDT 2019
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
[...]
Rebuilding blender with
MODPY_VERSION =3.6
fixes the UI issue here, I guess this could be used as a workaround.
(Is there any rush to get rid of 3.6?)
Updating the port to 2.79b didn't help.
This issue may be relevant:
"Blender UI failed to render using Python 3.7"
https://developer.blender.org/T56969
Index: Makefile
===
RCS file: /cvs/ports/graphics/blender/Makefile,v
retrieving revision 1.91
diff -u -p -r1.91 Makefile
--- Makefile28 Apr 2019 20:51:41 - 1.91
+++ Makefile24 May 2019 14:47:52 -
@@ -5,7 +5,7 @@ ONLY_FOR_ARCHS = amd64 i386
COMMENT = 3D creation software
DISTNAME = blender-2.79
-REVISION = 5
+REVISION = 6
CATEGORIES = graphics
@@ -32,7 +32,7 @@ MODULES = devel/cmake \
COMPILER = base-clang ports-gcc
-MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
+MODPY_VERSION =3.6
CONFIGURE_ARGS = -DPYTHON_INCLUDE_DIR="${MODPY_INCDIR}" \
-DPYTHON_VERSION=${MODPY_VERSION} \
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/05/24 08:43:53 Modified files: games/stepmania: Makefile games/stepmania/patches: patch-src_libtomcrypt_src_headers_tomcrypt_cfg_h Log message: use endian.h instead of hardcoding a list of archs
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/24 08:11:07 Modified files: sysutils/random_run: Makefile distinfo Log message: yet another minor update with a new option
Re: new port games/dMagnetic (you helped me. Now what?)
"Waiting...". Got it! Thanks!! > Leonid Bobrov hat am 24. Mai 2019 um 15:35 geschrieben: > > > On Fri, May 24, 2019 at 03:19:48PM +0200, Thomas Dettbarn wrote: > > Hello. > > > > > > > > Attached is a slightly tweaked tarball based on that public repo. The > > > port was mostly good; I just made small adjustments to bring things > > > into > > > our standard conventions (like, not starting COMMENT with a capital > > > letter or an indefinite article). > > > > > > Your instructions in the manual pages and the binary itself were way > > > more than enough for me to get pawn to play on my machine. > > > > > > ~Brian > > > > > > > > > So, I created a new release, dMagnetic 0.13. For this, I applied the > > suggestions to the Makefile from Leonid. > > > > In addition to this, I applied Brians patch to the port at the github > > repository at > > > > https://github.com/dettus/ports_and_packages/tree/master/OpenBSD/games/dmagnetic > > > > It is now referring to version 0.13. > > > > > > > > What happens now? What would be the next step to REALLY get > > my project into the ports tree? Who decides that it has its place there? > > > > > > > > Thomas > > > > You need to wait. There are many ports to be added/upgraded, so you are > not alone. Committers are busy and each one has their own priorities > what to do in free time. I believe Solene already told you that. >
Re: new port games/dMagnetic (you helped me. Now what?)
On Fri, May 24, 2019 at 03:19:48PM +0200, Thomas Dettbarn wrote: > Hello. > > > > > Attached is a slightly tweaked tarball based on that public repo. The > > port was mostly good; I just made small adjustments to bring things into > > our standard conventions (like, not starting COMMENT with a capital > > letter or an indefinite article). > > > > Your instructions in the manual pages and the binary itself were way > > more than enough for me to get pawn to play on my machine. > > > > ~Brian > > > > > So, I created a new release, dMagnetic 0.13. For this, I applied the > suggestions to the Makefile from Leonid. > > In addition to this, I applied Brians patch to the port at the github > repository at > > https://github.com/dettus/ports_and_packages/tree/master/OpenBSD/games/dmagnetic > > It is now referring to version 0.13. > > > > What happens now? What would be the next step to REALLY get > my project into the ports tree? Who decides that it has its place there? > > > > Thomas > You need to wait. There are many ports to be added/upgraded, so you are not alone. Committers are busy and each one has their own priorities what to do in free time. I believe Solene already told you that.
Re: [NEW] misc/nnn
On 5/24/19 5:46 PM, Brian Callahan wrote: On 5/24/19 9:12 AM, bijan wrote: Hi ports, I made a port of nnn file manager. it a snappy file manager for the ninjas (I guess). P.S: It's my first attempt to contribute to OpenBSD ports tree. More ports will come shortly as soon as I find the time. Thanks in advance for the critics. And hope it helps others :-) B.E Is this the same as sysutils/nnn? Yes, apparently although I'm wondering why my search didn't find any results even in openports.se. Thanks! Maybe I should post a diff updating the already existing sysutils/nnn since it's a very old version. B.E
Re: new port games/dMagnetic (you helped me. Now what?)
Hello. > > Attached is a slightly tweaked tarball based on that public repo. The > port was mostly good; I just made small adjustments to bring things into > our standard conventions (like, not starting COMMENT with a capital > letter or an indefinite article). > > Your instructions in the manual pages and the binary itself were way > more than enough for me to get pawn to play on my machine. > > ~Brian > So, I created a new release, dMagnetic 0.13. For this, I applied the suggestions to the Makefile from Leonid. In addition to this, I applied Brians patch to the port at the github repository at https://github.com/dettus/ports_and_packages/tree/master/OpenBSD/games/dmagnetic It is now referring to version 0.13. What happens now? What would be the next step to REALLY get my project into the ports tree? Who decides that it has its place there? Thomas
Re: [NEW] misc/nnn
On 5/24/19 9:12 AM, bijan wrote: Hi ports, I made a port of nnn file manager. it a snappy file manager for the ninjas (I guess). P.S: It's my first attempt to contribute to OpenBSD ports tree. More ports will come shortly as soon as I find the time. Thanks in advance for the critics. And hope it helps others :-) B.E Is this the same as sysutils/nnn? ~Brian
Re: Seafile-v6.2.11 - NamedPipeClient - python module import error
Thanks a lot for the fix! Abhinav Tamaskar On Mon, May 20, 2019 at 11:41 PM Abhinav Tamaskar wrote: > Hi Kirill and others, > I have been trying to get seafile working on my server and have not been > able to get > `seaf-cli` to start run on my machine. Unfortunately, it seems like some > files are missing > in the latest version of the package. > > To reproduce the error: > $ pkg_add seafile-daemon > $ seaf-cli > Traceback (most recent call last): > File /usr/local/bin/seaf-cli, line 99, in > import seafile > File /usr/local/lib/python2.7/site-packages/seafile/__init__.py, line 2, > in > from rpcclient import SeafileRpcClient as RpcClient > File /usr/local/lib/python2.7/site-packages/seafile/rpcclient.py, line > 1, in > from pysearpc import searpc_func, SearpcError, NamedPipeClient > ImportError: cannot import name NamedPipeClient > > System information: > My current system is running the latest snapshot as of this moment, on an > arm64 machine > (rockpro64). There are no patches applied on top of standard package. > Kernel version: > OpenBSD 6.5-current (GENERIC.MP) #19: Thu May 16 17:05:43 MDT 2019 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > Possible cause and resolution: > I believe this is an issue with the file > `.../net/seafile/libsearpc/pkg/PLIST`, which does not > contain the names of all the required files. If the file names are added > maybe it will work. > I do not have a system capable of compiling ports, so this is a conjecture > based on an > educated guess. > > Let me know if I am being unclear at any point and I can try to clarify. > > Thanks a bunch for the port, > Abhinav >
[NEW] misc/nnn
Hi ports, I made a port of nnn file manager. it a snappy file manager for the ninjas (I guess). P.S: It's my first attempt to contribute to OpenBSD ports tree. More ports will come shortly as soon as I find the time. Thanks in advance for the critics. And hope it helps others :-) B.E nnn.tgz Description: Binary data
Re: [NEW] games/nblood
On Mon, May 13, 2019 at 01:01:03PM +0200, Solene Rapenne wrote: > Hi >=20 > I made a port of NBlood engine to play the game "Blood" if you own the > proprietary assets. >=20 > nblood is a fork of eduke32 to make blood works, so I reused most of the > games/eduke32 Makefile. nblood is also GPLv2. README is not installed (also a problem with eduke32 port) cryptic passage files and method of running via -ini parameter are not mentioned in README. does not build when enet is installed: c++ -std=3Dgnu++11 -fno-exceptions -fno-rtti -fomit-frame-pointer -fno-str= ict-aliasing -fno-threadsafe-statics -fjump-tables -fno-stack-protector -O2= -pipe -W -Wall -Wextra -Wpointer-arith -Wno-char-subscripts -Wno-missing-b= races -Wwrite-strings -Wuninitialized -Wno-attributes -Wno-strict-overflow = -funsigned-char -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3D0 -DNDEBUG -DNOAS= M -DRENDERTYPESDL=3D1 -DMIXERTYPESDL=3D1 -DSTARTUP_WINDOW -DUSE_OPENGL -DPO= LYMER -I/usr/local/include -DUSE_LIBVPX -DHAVE_VORBIS -DHAVE_FLAC -DSDL_TAR= GET=3D2 -I/usr/local/include -I/usr/local/include/SDL2 -I/usr/X11R6/include= -D_REENTRANT -I/usr/X11R6/include -DHAVE_GTK2 -I/usr/local/include/gtk-2.0= -I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/loc= al/include/gio-unix-2.0 -I/usr/X11R6/include -I/usr/local/include/cairo -I/= usr/local/include/atk-1.0 -I/usr/X11R6/include/pixman-1 -I/usr/local/includ= e/libpng16 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include -pthrea= d -I/usr/local/include/harfbuzz -I/usr/local/include/fribidi -I/usr/local/i= nclude/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/free= type2 -Isource/build/include -Isource/mact/include -Isource/audiolib/includ= e -Isource/enet/include -Isource/glad/include -Isource/libsmackerdec/includ= e -funsigned-char -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3D0 -DNDEBUG -DNOASM = -DRENDERTYPESDL=3D1 -DMIXERTYPESDL=3D1 -DSTARTUP_WINDOW -DUSE_OPENGL -DPOLY= MER -I/usr/local/include -DUSE_LIBVPX -DHAVE_VORBIS -DHAVE_FLAC -DSDL_TARGE= T=3D2 -I/usr/local/include -I/usr/local/include/SDL2 -I/usr/X11R6/include -= D_REENTRANT -I/usr/X11R6/include -DHAVE_GTK2 -I/usr/local/include/gtk-2.0 -= I/usr/local/lib/gtk-2.0/include -I/usr/local/include/pango-1.0 -I/usr/local= /include/gio-unix-2.0 -I/usr/X11R6/include -I/usr/local/include/cairo -I/us= r/local/include/atk-1.0 -I/usr/X11R6/include/pixman-1 -I/usr/local/include/= libpng16 -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include -pthread = -I/usr/local/include/harfbuzz -I/usr/local/include/fribidi -I/usr/local/inc= lude/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/X11R6/include/freety= pe2 -DHAS_SOCKLEN_T -c source/enet/src/peer.c -o obj/enet/peer.o=20 c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior i= s deprecated [-Wdeprecated] source/enet/src/peer.c:275:5: error: use of undeclared identifier 'UNREFERE= NCED_PARAMETER' UNREFERENCED_PARAMETER(queue); ^ 1 error generated. gmake: *** [GNUmakefile:1159: obj/enet/peer.o] Error 1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/24 06:13:15 Modified files: sysutils/random_run: Makefile distinfo Log message: upgrade to new version, now that we have decent std::filesystem support gcc gets special love because of the way it defines things
Re: NEW: Tacacs+ port - shrubbery.net version
This does the trick and installs perfectly on macppc, will test i386
and amd64 when I get home.
My thoughts are that because all the TACACS+ ports were obsolete after
6.2, the _tacacs user was sort of "deauthorized" in the infrastructure
userlist.
Reading the error message properly this time it confirms 100% what you
said so that even I can understand it. :-D
Thanks, this is amazing.
Regards
Ampie
On Fri, 24 May 2019 at 13:37, Gleydson Soares wrote:
>
> Try with the change below and Let us know if it works for you,
>
> Thank you
>
> sent from my mobile device
>
> On Fri, May 24, 2019, at 7:43 AM, Gleydson Soares wrote:
>
> it requires _tacacs user due to privdrop, so you need to uncomment the
> folllwing line:
> {x250} /usr/ports $ grep -rn tacacs /usr/ports/infrastructure/*
> /usr/ports/infrastructure/db/user.list:22:#511 _tacacs _tacacs
> net/tacacs+
>
> i'm with limited internet access till tomorrow morning, i will take look at
> this port and diffs tomorrow
>
>
>
> On Fri, May 24, 2019, at 7:37 AM, Ampie Niemand wrote:
> > Hi, all.
> >
> > Thanks for reviving this awesome service.
> >
> > I'm failing at the last hurdle with both macppc and amd64:
> >
> > ..
> > ..
> > ===> Building package for tacacs+-4.0.4.28v0
> > Create /usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz
> > Creating package tacacs+-4.0.4.28v0
> > Error: newgroup _tacacs: not registered in
> > /usr/ports/infrastructure/db/user.list
> > Error: newuser _tacacs: not registered in
> > /usr/ports/infrastructure/db/user.list
> > Fatal error: can't continue
> > at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1675.
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2026
> > '/usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz')
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2487
> > '_internal-package')
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2466
> > 'package')
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2039
> > '/var/db/pkg/tacacs+-4.0.4.28v0/+CONTENTS')
> > *** Error 1 in /usr/ports/mystuff/net/tacacs+
> > (/usr/ports/infrastructure/mk/bsd.port.mk:2466
> > 'install')
> >
> > .
> >
> > On Mon, 20 May 2019 at 21:56, Gleydson Soares
> > wrote:
> > >
> > > Hi Jan,
> > >
> > > thank you for your effort on this port.
> > > i've pushed it to openbsd-wip at
> > > https://github.com/jasperla/openbsd-wip/tree/master/net/tacacs%2B
> > > it addresses the joint work of you and sthen@
> > >
> > > are you still ok regarding of taking maintanership?
> > >
> > > i will give some extra tests and double review next days.
> > >
> > > Thank you,
> > > Gleydson.
> > >
> >
>
>
>
Re: [ports-gcc] Unbreak and fix audio/audacious-plugins
Charlene Wendling:
> - It doesn't build with ports-gcc (macppc [0], sparc64 [1])
>
> The problem here is again a macro vs function issue. I've applied
> the same thing upstream still does on audacious proper [2]:
> undef'ing feof(3).
That part is fine.
> - At least on macppc, it does some white noise during playback
>
> After poking around, i've found out it was a bit depth issue when
> the related audio setting is on "automatic". Setting manually to
> 16 bit fixed the issue, but it's supposed to work... automatically.
>
> mpv does things differently [3] and i have no sound issues (excepted
> for CDDA) on macppc. So after comparing their work, and reading
> the sio_open(3) manpage, i've changed some parameters to make it
> work ootb.
I object. This cannot be correct. fdata->bytes can't be wrong,
we're getting it from our own table, and otherwise you're nailing
everything to signed native endian, no matter what the actual input
format is. You are hiding the actual bug.
Since the output format in "automatic" always appears to be 32-bit
signed native endian (after falling back from float), I'm surprised
that your change actually changes any behavior.
> + par.bits = fdata->bits;
> +-par.bps = fdata->bytes;
> +-par.sig = fdata->sign;
> +-par.le = fdata->le;
> ++par.bps = SIO_BPS(par.bits);
> ++par.sig = 1;
> ++par.le = SIO_LE_NATIVE;
Can you try audacious -VV with the patch below and tell us the
messages from [setup_output] and [open_audio]?
--- src/sndio/sndio.cc.orig Fri May 24 03:14:01 2019
+++ src/sndio/sndio.cc Fri May 24 04:27:30 2019
@@ -168,6 +168,7 @@
bool SndioPlugin::open_audio (int format, int rate, int channels, String &
error)
{
+AUDDBG("format=%d\n", format);
const FormatData * fdata = nullptr;
for (const FormatData & f : format_table)
@@ -181,6 +182,8 @@
error = String (str_printf (_("Sndio error: Unsupported audio format
(%d)"), format));
return false;
}
+AUDDBG("bits=%d bytes=%d sign=%d le=%d\n",
+ fdata->bits, fdata->bytes, fdata->sign, fdata->le);
String device = aud_get_str ("sndio", "device");
const char * device2 = device[0] ? (const char *) device : SIO_DEVANY;
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: NEW: Tacacs+ port - shrubbery.net version
Try with the change below and Let us know if it works for you,
Thank you
sent from my mobile device
On Fri, May 24, 2019, at 7:43 AM, Gleydson Soares wrote:
> it requires _tacacs user due to privdrop, so you need to uncomment the
> folllwing line:
> {x250} /usr/ports $ grep -rn tacacs /usr/ports/infrastructure/*
> /usr/ports/infrastructure/db/user.list:22:#511 _tacacs _tacacs net/tacacs+
>
> i'm with limited internet access till tomorrow morning, i will take look at
> this port and diffs tomorrow
>
>
>
> On Fri, May 24, 2019, at 7:37 AM, Ampie Niemand wrote:
> > Hi, all.
> >
> > Thanks for reviving this awesome service.
> >
> > I'm failing at the last hurdle with both macppc and amd64:
> >
> > ..
> > ..
> > ===> Building package for tacacs+-4.0.4.28v0
> > Create /usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz
> > Creating package tacacs+-4.0.4.28v0
> > Error: newgroup _tacacs: not registered in
> > /usr/ports/infrastructure/db/user.list
> > Error: newuser _tacacs: not registered in
> > /usr/ports/infrastructure/db/user.list
> > Fatal error: can't continue
> > at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1675.
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2026
> > '/usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz')
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2487
> > '_internal-package')
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2466
> > 'package')
> > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2039
> > '/var/db/pkg/tacacs+-4.0.4.28v0/+CONTENTS')
> > *** Error 1 in /usr/ports/mystuff/net/tacacs+
> > (/usr/ports/infrastructure/mk/bsd.port.mk:2466
> > 'install')
> >
> > .
> >
> > On Mon, 20 May 2019 at 21:56, Gleydson Soares
> > wrote:
> > >
> > > Hi Jan,
> > >
> > > thank you for your effort on this port.
> > > i've pushed it to openbsd-wip at
> > > https://github.com/jasperla/openbsd-wip/tree/master/net/tacacs%2B
> > > it addresses the joint work of you and sthen@
> > >
> > > are you still ok regarding of taking maintanership?
> > >
> > > i will give some extra tests and double review next days.
> > >
> > > Thank you,
> > > Gleydson.
> > >
> >
>
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/05/24 05:35:32 Modified files: mail : Makefile Log message: +opendmarc
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/05/24 05:35:02 Log message: import ports/mail/opendmarc, from Renaud Allard, ok landry@ OpenDMARC is a free open source software implementation of the DMARC specification. The OpenDMARC project is a community effort to develop and maintain an open source package for providing DMARC report generation and policy enforcement services. It includes a library for handling DMARC record parsing, a database schema and tools for aggregating and processing transaction history to produce DMARC reports, and a filter that ties it all together with an MTA using the milter protocol. Status: Vendor Tag: sthen Release Tags: sthen_20190524 N ports/mail/opendmarc/Makefile N ports/mail/opendmarc/distinfo N ports/mail/opendmarc/pkg/opendmarc.rc N ports/mail/opendmarc/pkg/DESCR N ports/mail/opendmarc/pkg/PLIST No conflicts created by this import
Re: NEW: Tacacs+ port - shrubbery.net version
it requires _tacacs user due to privdrop, so you need to uncomment the
folllwing line:
{x250} /usr/ports $ grep -rn tacacs /usr/ports/infrastructure/*
/usr/ports/infrastructure/db/user.list:22:#511 _tacacs _tacacs
net/tacacs+
i'm with limited internet access till tomorrow morning, i will take look at
this port and diffs tomorrow
On Fri, May 24, 2019, at 7:37 AM, Ampie Niemand wrote:
> Hi, all.
>
> Thanks for reviving this awesome service.
>
> I'm failing at the last hurdle with both macppc and amd64:
>
> ..
> ..
> ===> Building package for tacacs+-4.0.4.28v0
> Create /usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz
> Creating package tacacs+-4.0.4.28v0
> Error: newgroup _tacacs: not registered in
> /usr/ports/infrastructure/db/user.list
> Error: newuser _tacacs: not registered in
> /usr/ports/infrastructure/db/user.list
> Fatal error: can't continue
> at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1675.
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2026
> '/usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2487
> '_internal-package')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2466
> 'package')
> *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2039
> '/var/db/pkg/tacacs+-4.0.4.28v0/+CONTENTS')
> *** Error 1 in /usr/ports/mystuff/net/tacacs+
> (/usr/ports/infrastructure/mk/bsd.port.mk:2466
> 'install')
>
> .
>
> On Mon, 20 May 2019 at 21:56, Gleydson Soares wrote:
> >
> > Hi Jan,
> >
> > thank you for your effort on this port.
> > i've pushed it to openbsd-wip at
> > https://github.com/jasperla/openbsd-wip/tree/master/net/tacacs%2B
> > it addresses the joint work of you and sthen@
> >
> > are you still ok regarding of taking maintanership?
> >
> > i will give some extra tests and double review next days.
> >
> > Thank you,
> > Gleydson.
> >
>
Re: NEW: Tacacs+ port - shrubbery.net version
Hi, all. Thanks for reviving this awesome service. I'm failing at the last hurdle with both macppc and amd64: .. .. ===> Building package for tacacs+-4.0.4.28v0 Create /usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz Creating package tacacs+-4.0.4.28v0 Error: newgroup _tacacs: not registered in /usr/ports/infrastructure/db/user.list Error: newuser _tacacs: not registered in /usr/ports/infrastructure/db/user.list Fatal error: can't continue at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1675. *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2026 '/usr/ports/packages/powerpc/all/tacacs+-4.0.4.28v0.tgz') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2487 '_internal-package') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2466 'package') *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2039 '/var/db/pkg/tacacs+-4.0.4.28v0/+CONTENTS') *** Error 1 in /usr/ports/mystuff/net/tacacs+ (/usr/ports/infrastructure/mk/bsd.port.mk:2466 'install') . On Mon, 20 May 2019 at 21:56, Gleydson Soares wrote: > > Hi Jan, > > thank you for your effort on this port. > i've pushed it to openbsd-wip at > https://github.com/jasperla/openbsd-wip/tree/master/net/tacacs%2B > it addresses the joint work of you and sthen@ > > are you still ok regarding of taking maintanership? > > i will give some extra tests and double review next days. > > Thank you, > Gleydson. >
Re: x11/compton drm path bug
On Thu, May 23 2019, Thomas Frohwein wrote: > On Thu, May 23, 2019 at 09:40:14PM +, Mr. Me0w wrote: > [...] >> Understood. I just made a patch against the current ports CVS. It is >> attached to this email. > > Thanks, one more nit - ports updates are generally sent inline at the > bottom of the email (like in this case). > >> Yes, it does fix a bug I've encountered. When using compton to handle >> vsync, the DRM option doesn't work by default because it assumes it is >> running on Linux and that the DRM device is located at /dev/dri/card0, >> but on OpenBSD it is located at /dev/drm0. Sadly, this can't be >> overriden in the compton.conf either. > > Netiquette: 72 characters per line (does protonmail mess with this?) > https://www.openbsd.org/mail.html > >> Before patch: >> >> $ compton --vsync drm >> vsync_drm_init(): Failed to open device. >> $ >> >> After patch: >> >> $ compton --vsync drm >> >> (Works.. GPU-accelerated compositing and tear-free display.) > > I can confirm this works here, too. I think this patch should go in. > Thanks for the work, Mr. Me0w! I have combined this into the same patch > file that already existed for src/compton.c. Also REVISION bump and > take MAINTAINER if no objection. Sure, ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/24 02:46:08 Modified files: devel/p5-Devel-FindRef: Makefile distinfo devel/p5-Devel-FindRef/pkg: PLIST Removed files: devel/p5-Devel-FindRef/patches: patch-FindRef_xs Log message: minor update, works better with current perl
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2019/05/24 02:41:09 Modified files: productivity/taskwarrior: Makefile Log message: fix homepage; from Micah Muer
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: es...@cvs.openbsd.org 2019/05/24 02:40:32 Modified files: devel/p5-Devel-Gladiator: Makefile distinfo Log message: minor update
Re: x11/compton drm path bug
On Thu, May 23, 2019 at 09:40:14PM +, Mr. Me0w wrote:
[...]
> Understood. I just made a patch against the current ports CVS. It is attached
> to this email.
Thanks, one more nit - ports updates are generally sent inline at the
bottom of the email (like in this case).
> Yes, it does fix a bug I've encountered. When using compton to handle vsync,
> the DRM option doesn't work by default because it assumes it is running on
> Linux and that the DRM device is located at /dev/dri/card0, but on OpenBSD it
> is located at /dev/drm0. Sadly, this can't be overriden in the compton.conf
> either.
Netiquette: 72 characters per line (does protonmail mess with this?)
https://www.openbsd.org/mail.html
> Before patch:
>
> $ compton --vsync drm
> vsync_drm_init(): Failed to open device.
> $
>
> After patch:
>
> $ compton --vsync drm
>
> (Works.. GPU-accelerated compositing and tear-free display.)
I can confirm this works here, too. I think this patch should go in.
Thanks for the work, Mr. Me0w! I have combined this into the same patch
file that already existed for src/compton.c. Also REVISION bump and
take MAINTAINER if no objection.
(By the way, I found an active fork of compton that may serve to update
this port later: https://github.com/yshui/compton)
ok?
Index: Makefile
===
RCS file: /cvs/ports/x11/compton/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- Makefile9 May 2019 21:13:26 - 1.7
+++ Makefile24 May 2019 05:31:39 -
@@ -5,11 +5,13 @@ COMMENT = lightweight compositor for X,
V =0.1_beta2
PKGNAME = compton-${V}
DISTNAME = compton-git-v0.1_beta2-2013-10-21
-REVISION = 4
+REVISION = 5
CATEGORIES = x11
HOMEPAGE = https://github.com/chjj/compton
+
+MAINTAINER = Thomas Frohwein
# MIT
PERMIT_PACKAGE_CDROM = Yes
Index: patches/patch-src_compton_c
===
RCS file: /cvs/ports/x11/compton/patches/patch-src_compton_c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-src_compton_c
--- patches/patch-src_compton_c 27 Oct 2014 11:21:49 - 1.1.1.1
+++ patches/patch-src_compton_c 24 May 2019 05:31:39 -
@@ -1,6 +1,7 @@
$OpenBSD: patch-src_compton_c,v 1.1.1.1 2014/10/27 11:21:49 sthen Exp $
src/compton.c.orig Mon Oct 21 19:47:01 2013
-+++ src/compton.c Sun Oct 26 00:56:53 2014
+Index: src/compton.c
+--- src/compton.c.orig
src/compton.c
@@ -1665,6 +1665,8 @@ win_paint_win(session_t *ps, win *w, XserverRegion reg
reg_paint, pcache_reg);
break;
@@ -10,6 +11,15 @@ $OpenBSD: patch-src_compton_c,v 1.1.1.1
}
}
+@@ -5825,7 +5827,7 @@ static bool
+ vsync_drm_init(session_t *ps) {
+ #ifdef CONFIG_VSYNC_DRM
+ // Should we always open card0?
+- if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/dri/card0", O_RDWR)) < 0) {
++ if (ps->drm_fd < 0 && (ps->drm_fd = open("/dev/drm0", O_RDWR)) < 0) {
+ printf_errf("(): Failed to open device.");
+ return false;
+ }
@@ -6165,6 +6167,8 @@ init_filters(session_t *ps) {
return false;
}
Index: patches/patch-src_opengl_c
===
RCS file: /cvs/ports/x11/compton/patches/patch-src_opengl_c,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_opengl_c
--- patches/patch-src_opengl_c 13 Feb 2019 20:36:08 - 1.1
+++ patches/patch-src_opengl_c 24 May 2019 05:31:39 -
@@ -4,9 +4,10 @@ https://github.com/yshui/compton/commit/
Avoid using 10bit FBConfigs
Fix weird color issue with Mesa 18.0
src/opengl.c.orig Mon Oct 21 16:17:01 2013
-+++ src/opengl.c Tue Feb 12 21:14:44 2019
-@@ -497,6 +497,16 @@
+Index: src/opengl.c
+--- src/opengl.c.orig
src/opengl.c
+@@ -497,6 +497,16 @@ glx_cmp_fbconfig(session_t *ps,
return -1;
if (!pfbc_b)
return 1;
