Re: socat does not provide TUN/TAP support
I decided to do a watchdog script, vxlan works fine. One endpoint is an old 5$ raspberry 0, its CPU is much happier with vxlan than with wg. Thanks again Il giorno gio 16 nov 2023 alle 10:41 Stuart Henderson ha scritto: > Ah, so it's an existing upstream feature that just isn't working on > OpenBSD yet. That wasn't clear from the earlier mails. > > That could be something which is reasonable to patch in ports. > Though for your use case, I think you'll be happier with performance > of something in-kernel. If vxlan doesn't work for you then wg may well > be your best bet, as long as you don't have a specific reason to > avoid encryption. > > > On 2023/11/13 16:29, Luca Di Gregorio wrote: > > Socat upstream tells me that they don't have resource/time > > to add tun/tap support on OpenBSD. > > > > No matter anyway. > > Thanks again > > > > > > Il giorno lun 13 nov 2023 alle ore 10:19 Luca Di Gregorio < > luc...@gmail.com> > > ha scritto: > > > > > I will do it. > > > Anyway, a few months ago I noticed a similar issue on vlc. > > > Prior 7.4, OpenBSD port didn't have the telnet interface available. > > > Some gentlemen here in ports@openbsd.org added it and now it's > available > > > in 7.4. > > > That is why I submitted the question related to socat and TUN. > > > Thanks > > > > > > Il giorno dom 12 nov 2023 alle ore 11:54 Theo de Raadt < > > > dera...@openbsd.org> ha scritto: > > > > > >> you would need to talk to socat upstream, because in general the ports > > >> team do not add features > > >> > > >> Luca Di Gregorio wrote: > > >> > > >> > I would like to set a point to point interface encapsulating > packets via > > >> > UDP. > > >> > > > >> > It would be like a point to point wireguard but: > > >> > - without authentication (I can set permissions in PF on source ip) > > >> > - without encryption (content is already encrypted by source > > >> application) > > >> > > > >> > I can't use GIF or GRE interfaces because I'm behind NAT with only > > >> TCP/UDP > > >> > capabilities. > > >> > > > >> > With linux it's possible with fou-gue interfaces, but I see that in > > >> OpenBSD > > >> > fou is not implemented. > > >> > > > >> > So, I installed socat with pkg_add and tried to do like this: > > >> > http://www.dest-unreach.org/socat/doc/socat-tun.html > > >> > > > >> > Anyway, I see this: > > >> > # socat UDP:1.2.3.4:11443 TUN:192.168.255.2/24,up > > >> > 2023/11/11 14:11:27 socat[4504] E unknown device/address "TUN" > > >> > > > >> > Do you think it's possible to add TUN/TAP support in socat? > > >> > > > >
Re: socat does not provide TUN/TAP support
Socat upstream tells me that they don't have resource/time to add tun/tap support on OpenBSD. No matter anyway. Thanks again Il giorno lun 13 nov 2023 alle ore 10:19 Luca Di Gregorio ha scritto: > I will do it. > Anyway, a few months ago I noticed a similar issue on vlc. > Prior 7.4, OpenBSD port didn't have the telnet interface available. > Some gentlemen here in ports@openbsd.org added it and now it's available > in 7.4. > That is why I submitted the question related to socat and TUN. > Thanks > > Il giorno dom 12 nov 2023 alle ore 11:54 Theo de Raadt < > dera...@openbsd.org> ha scritto: > >> you would need to talk to socat upstream, because in general the ports >> team do not add features >> >> Luca Di Gregorio wrote: >> >> > I would like to set a point to point interface encapsulating packets via >> > UDP. >> > >> > It would be like a point to point wireguard but: >> > - without authentication (I can set permissions in PF on source ip) >> > - without encryption (content is already encrypted by source >> application) >> > >> > I can't use GIF or GRE interfaces because I'm behind NAT with only >> TCP/UDP >> > capabilities. >> > >> > With linux it's possible with fou-gue interfaces, but I see that in >> OpenBSD >> > fou is not implemented. >> > >> > So, I installed socat with pkg_add and tried to do like this: >> > http://www.dest-unreach.org/socat/doc/socat-tun.html >> > >> > Anyway, I see this: >> > # socat UDP:1.2.3.4:11443 TUN:192.168.255.2/24,up >> > 2023/11/11 14:11:27 socat[4504] E unknown device/address "TUN" >> > >> > Do you think it's possible to add TUN/TAP support in socat? >> >
Re: socat does not provide TUN/TAP support
Hi, with vlanx(4): In both endpoints I can set p-t-p mode with a destination UDP port, but I can't set what is the source UDP port to bind to. With static IP address I tested and it works fine: # ifconfig vxlan0 tunnel :4789 vnetid 1 Anyway, if the REMOTE_IP is not static, I should destroy and recreate the vlanx0 interface whenever the REMOTE_IP changes. It would not be difficult with a watchdog script in cron. But I think that, for my purposes, a wireguard configured in client/server mode is better, even with an unnecessary overhead due to encryption. I haven't tested with private LOCAL_IP or REMOTE_IP natted to public IPs. Thanks anyway, regards Il giorno lun 13 nov 2023 alle ore 07:49 Stuart Henderson < s...@spacehopper.org> ha scritto: > On 2023/11/11 14:17, Luca Di Gregorio wrote: > > I would like to set a point to point interface encapsulating packets via > > UDP. > > > > It would be like a point to point wireguard but: > > - without authentication (I can set permissions in PF on source ip) > > - without encryption (content is already encrypted by source > application) > > How about vxlan(4)? > >
Re: socat does not provide TUN/TAP support
Test: OpenBSD UDP Server: # ifconfig tun0 create # ifconfig tun0 inet 192.168.74.1/24 # socat -d -d UDP-LISTEN:11443,reuseaddr GOPEN:/dev/tun0 2023/11/13 10:30:58 socat[31554] N listening on UDP LEN=16 AF=2 0.0.0.0:11443 2023/11/13 10:33:27 socat[31554] N accepting UDP connection from LEN=16 AF=2 192.168.255.2:59152 2023/11/13 10:33:27 socat[31554] N opening character device "/dev/tun0" for reading and writing Linux UDP Client: $ socat UDP:1.2.3.4:11443 TUN:192.168.74.2/24,up OpenBSD UDP Server, this line appears: 2023/11/13 10:33:27 socat[31554] N starting data transfer loop with FDs [5,5] and [6,6] Linux UDP Client, start a ping but no replies received $ ping 192.168.74.1 OpenBSD UDP Server, tcpdump -ni tun0 shows: 11:02:15.130291 11:02:16.130410 11:02:17.130223 11:02:18.130072 11:02:19.131211 11:02:20.130417 11:02:21.130218 So, maybe socat doesn't know how to decode raw data received on tun0. Thanks anyway Il giorno dom 12 nov 2023 alle ore 14:03 Sebastien Marie < sema...@kapouay.eu.org> ha scritto: > Luca Di Gregorio writes: > > > So, I installed socat with pkg_add and tried to do like this: > > http://www.dest-unreach.org/socat/doc/socat-tun.html > > > > Anyway, I see this: > > # socat UDP:1.2.3.4:11443 TUN:192.168.255.2/24,up > > 2023/11/11 14:11:27 socat[4504] E unknown device/address "TUN" > > > > Have you try to manually configure tun(4) interface and simply use > /dev/tun0 ? > > To keep your example: > # ifconfig tun0 create > # ifconfig tun0 inet 192.168.255.2/24 > # socat UDP:1.2.3.4:11443 GOPEN:/dev/tun0 > > Regards. > -- > Sebastien Marie >
Re: socat does not provide TUN/TAP support
I was thinking about using a more "point-to-point-oriented" method than vxlan. Anyway, I'll do some tests with it and let you know. Thanks Il giorno lun 13 nov 2023 alle ore 07:49 Stuart Henderson < s...@spacehopper.org> ha scritto: > On 2023/11/11 14:17, Luca Di Gregorio wrote: > > I would like to set a point to point interface encapsulating packets via > > UDP. > > > > It would be like a point to point wireguard but: > > - without authentication (I can set permissions in PF on source ip) > > - without encryption (content is already encrypted by source > application) > > How about vxlan(4)? > >
Re: socat does not provide TUN/TAP support
I will do it. Anyway, a few months ago I noticed a similar issue on vlc. Prior 7.4, OpenBSD port didn't have the telnet interface available. Some gentlemen here in ports@openbsd.org added it and now it's available in 7.4. That is why I submitted the question related to socat and TUN. Thanks Il giorno dom 12 nov 2023 alle ore 11:54 Theo de Raadt ha scritto: > you would need to talk to socat upstream, because in general the ports > team do not add features > > Luca Di Gregorio wrote: > > > I would like to set a point to point interface encapsulating packets via > > UDP. > > > > It would be like a point to point wireguard but: > > - without authentication (I can set permissions in PF on source ip) > > - without encryption (content is already encrypted by source > application) > > > > I can't use GIF or GRE interfaces because I'm behind NAT with only > TCP/UDP > > capabilities. > > > > With linux it's possible with fou-gue interfaces, but I see that in > OpenBSD > > fou is not implemented. > > > > So, I installed socat with pkg_add and tried to do like this: > > http://www.dest-unreach.org/socat/doc/socat-tun.html > > > > Anyway, I see this: > > # socat UDP:1.2.3.4:11443 TUN:192.168.255.2/24,up > > 2023/11/11 14:11:27 socat[4504] E unknown device/address "TUN" > > > > Do you think it's possible to add TUN/TAP support in socat? >
socat does not provide TUN/TAP support
I would like to set a point to point interface encapsulating packets via UDP. It would be like a point to point wireguard but: - without authentication (I can set permissions in PF on source ip) - without encryption (content is already encrypted by source application) I can't use GIF or GRE interfaces because I'm behind NAT with only TCP/UDP capabilities. With linux it's possible with fou-gue interfaces, but I see that in OpenBSD fou is not implemented. So, I installed socat with pkg_add and tried to do like this: http://www.dest-unreach.org/socat/doc/socat-tun.html Anyway, I see this: # socat UDP:1.2.3.4:11443 TUN:192.168.255.2/24,up 2023/11/11 14:11:27 socat[4504] E unknown device/address "TUN" Do you think it's possible to add TUN/TAP support in socat?
Re: vlc no telnet interface
I've just updated to 7.4 and now I see that vlc has the telnet interface.
It works like a charm.
Thanks again and regards
Il giorno ven 26 mag 2023 alle ore 14:09 Luca Di Gregorio
ha scritto:
> Ok, clear, thanks a lot for the effort and for the clarification.
>
> Il giorno ven 26 mag 2023 alle ore 10:58 Stuart Henderson <
> s...@spacehopper.org> ha scritto:
>
>> You are running 7.3. That has been added for -current only (the first
>> release it will make it into is 7.4).
>>
>> --
>> Sent from a phone, apologies for poor formatting.
>>
>>
>> On 26 May 2023 07:42:18 Luca Di Gregorio wrote:
>>
>> Hello, I've just done a 'pkg_add -Uu -v':
>>>
>>> Update candidates: vlc-3.0.18 -> vlc-3.0.18
>>>
>>> and tried to run 'vlc -vvv -I telnet', but I see again:
>>>
>>> main interface debug: looking for interface module matching "telnet": 13
>>> candidates
>>> main interface debug: no interface modules matched
>>> main interface error: no suitable interface module
>>>
>>> Am I doing something wrong?
>>>
>>> With a 'vlc --version' I see:
>>> VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
>>> VLC version 3.0.18 Vetinari (3.0.13-8-g41878ff4f2)
>>> Compiled by _pbuild on amd64-3.ports.openbsd.org (Mar 25 2023 12:30:05)
>>>
>>> Regards
>>> Luca
>>>
>>> Il giorno ven 12 mag 2023 alle ore 23:48 Brad Smith
>>> ha
>>> scritto:
>>>
>>> On 2023-05-10 4:29 a.m., Stuart Henderson wrote:
>>>>
>>>>> On 2023/04/30 11:53, Antoine Jacoutot wrote:
>>>>>
>>>>>> + if test "${enable_lua}" != "no"
>>>>>>> + then
>>>>>>> +- PKG_CHECK_MODULES(LUA, lua5.2,
>>>>>>> ++ PKG_CHECK_MODULES(LUA, lua51,
>>>>>>>
>>>>>> Can we use SUBST_CMD to prevent hardcoding?
>>>>>>
>>>>> I don't see anything wrong with hardcoding here? I think MODLUA_VERSION
>>>>> should reflect what the port wants, it's not like SHARED_LIBS.
>>>>>
>>>>> On 2023/05/09 02:29, Brad Smith wrote:
>>>>>
>>>>>> On 2023-05-01 5:36 a.m., Stuart Henderson wrote:
>>>>>>
>>>>>>> Any particular reason to use 5.1 instead of 5.2? (They're all EoL
>>>>>>>
>>>>>> except
>>>>
>>>>> 5.4, but 5.1 is much longer since EoL).
>>>>>>>
>>>>>> Just that is what the default is, MODLUA_DEFAULT_VERSION.
>>>>>>
>>>>> I don't think this is meant to be prescriptive any more than
>>>>> say AUTOCONF_VERSION, just that it's what most things used when the
>>>>> module was added. We haven't run into problems with ports pulling
>>>>> in multiple lua versions via lib deps.
>>>>>
>>>>> (I have a diff to add lua5.X pkg-config files to the lua ports to
>>>>> test sometime but the i386 builders are unhappy atm, also the include
>>>>> directories are non-standard too and also need patches in various
>>>>> ports,
>>>>> so it would be good to clean up that whole lot at once).
>>>>>
>>>>> How about this diff for vlc? Compared to your previous:
>>>>>
>>>>> - uses the lua version which upstream prefers
>>>>> - brings back UPDATE_PLIST_ARGS from my earlier one to avoid the
>>>>> a52/a${MODLUA_VERSION} that is subst'ed in PLIST-main with 5.2
>>>>>
>>>> I saw this part and did not understand what it was for.
>>>>
>>>>> - uses the minimum necessary configure.ac patch to handle lua52.pc.
>>>>>
>>>>
>>>> Sure.
>>>>
>>>>
>>>>
>>
Re: [NEW] net/megacmd
Compiling megacmd.tar.gz with -stable ports: cd /usr cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -rOPENBSD_7_3 -P ports works with no errors on OpenBSD XXX 7.3 GENERIC#1072 amd64 Thanks again, regards Il giorno gio 15 giu 2023 alle ore 19:00 Omar Polo ha scritto: > On 2023/06/15 18:34:25 +0200, Luca Di Gregorio wrote: > > Hi, I would need a clarification: > > > > The correct way to compile the > > current megacmd.tar.gz is > > dowloading the -stable, not -current. > > > > Am I right? > > No, it is not right. Port development happens in -CURRENT, -stable > only sees backports of security fixes. > > Said that, you should also keep in mind that the -stable port tree is > for OpenBSD-stable, and the -current port tree is for OpenBSD-current. > > You can't mix-and-match. > > So, fetch the port tree for your branch and use that. In this case, > the port in question should compile both on -stable and -current, but > please keep in mind that it's not always the case. > > If you're on current, other than a -current ports tree you also need > to have up-to-date packages (doas pkg_add -u). > > All of this is carefully documented in the FAQS: > > https://www.openbsd.org/faq/ports/ports.html#PortsIntro > > along with the exact commands you need to fetch the port tree, setup > things, build, etc. > > > Buona fortuna :) >
Re: [NEW] net/megacmd
Hi, I would need a clarification:
The correct way to compile the
current megacmd.tar.gz is
dowloading the -stable, not -current.
Am I right?
Il giorno gio 15 giu 2023 alle 18:17 Robert Bagdan ha
scritto:
> Thanks to your reviews, I will install -current OpenBSD to a vm in the
> next few days, and fix this port with your modifications and
> proposals.
> I will come back soon.
>
> Stuart Henderson ezt írta (időpont: 2023. jún.
> 15., Cs, 9:24):
> >
> > On 2023/06/14 13:13, Omar Polo wrote:
> >
> > > the patches seemed fine for me. I'd wish we could avoid patching for
> > > ereadline.
> >
> > that's normal for our renamed ports version of readline.
> >
> > > The only odd one is patches/patch-sdk_include_mega_http_h which
> > > defines AI_V4MAPPED...
> >
> > sdk/include/mega/http.h
> > 44-
> > 45-#if defined(__FreeBSD__) || defined(__OpenBSD__)
> > 46-#include
> > 47:#define AI_V4MAPPED 0x0800
> > 48-#endif
> > 49-
> > 50-namespace mega {
> >
> > yes, don't set it to some random value
> >
> > sdk/src/http.cpp
> > 270-hints.ai_family = AF_UNSPEC;
> > 271-
> > 272-#ifndef __MINGW32__
> > 273:hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG;
> > 274-#endif
> > 275-
> > 276-if (!getaddrinfo("ns.mega.co.nz", NULL, , ))
> >
> > since it's only used in this one place, best bet is to remoce the http.h
> > patch and remove AI_V4MAPPED from http.cpp.
> >
> > (if it was used more often, I'd define it, but to 0).
> >
> >
> > > - the bundled sdk installs also the headers, a static library and a
> > >pkgconfig file:
> > >
> > > 1. we usually prefer dynamic linking
> > > 2. would it make sense (maybe in the future) to split the sdk off
> > > this port? There are other projects we may want that need
> > > this sdk too? Maybe there's already something in ports that
> > > optionally looks for this and could statically link to
> > > libmega?
> >
> > I think I would have used a separate port for the sdk, but think this
> > way is ok too (especially if nothing else uses the sdk).
> >
> > > - i'd probably install the bash completions in
> > >/usr/local/share/bash-completion and avoid to @sample, but I don't
> > >use bash and don't really know the difference (if there is) to
> > >install in /etc/bash_completion.d.
> >
> > yes, please use /usr/local/share/bash-completion like other ports do.
> >
> > "MEGAcmd provides non UI access to MEGA services"
> >
> > I see this is just copied from the readme, but "non UI" doesn't make
> > much sense. Something like "MEGAcmd provides scriptable command-line
> > tools and an interactive shell to access services from mega.nz"?
> >
>
>
> --
> kikadf
>
>
Re: [NEW] net/megacmd
You're right, it's useful, I forgot to do that, sorry.
To install the ports tree, I followed the first link that appeared
when I googled 'openbsd ports'
https://www.openbsd.org/faq/ports/ports.html
I downloaded with the command:
ftp https://cdn.openbsd.org/pub/OpenBSD/$(uname
-r)/{ports.tar.gz,SHA256.sig}
And then I unzipped the megacmd.tar.gz, in the /net directory,
provided by kikadf...@gmail.com
Il giorno mer 14 giu 2023 alle ore 20:58 Omar Polo ha
scritto:
> On 2023/06/14 19:35:08 +0200, Luca Di Gregorio wrote:
> > Hello, I've successfully installed megacmd.
> >
> > Anyway, I had the last version of curl installed on my system,
> > before compiling megacmd.
> >
> > I had to delete curl (pkg_delete curl, pkg_delete -a) to compile megacmd.
> > I saw some errors related to curl.so.
>
> it's useful to report the errors when you get them, along with a
> description of what you did to trigger them.
>
> In this case -but it's pure speculation- I guess you used the 7.3 port
> tree on -CURRENT, or viceversa, which ain't gonna work.
>
> Refer to this page for how to fetch the port tree, under the heading
> "Getting the ports and xenocara Trees" (xenocara is not needed for
> port hacking.)
>
> https://www.openbsd.org/anoncvs.html
>
> > I cleaned up everything after the installation
> > (make clean, pkg_delete -a, make clean=dist, make clean=flavors, make
> > package BULK=Yes).
> >
> > After that, I added again curl (pkg_add curl) and both curl and mega-*
> work.
> >
> > Thanks a lot, regards
> >
> >
> > Il giorno lun 12 giu 2023 alle ore 17:57 Robert Bagdan <
> kikadf...@gmail.com>
> > ha scritto:
> >
> > > Hi! To build megacmd: get the 7.3 branch of the ports tree, extract
> > > magacmd.tar.gz attachment to the net subdirectory in your ports tree,
> > > and run "make FETCH_PACKAGES= install" from net/megacmd subdirectory.
> > > I don't know megatools, so I can't help with that.
> > >
>
>
>
Re: [NEW] net/megacmd
Hello, I've successfully installed megacmd. Anyway, I had the last version of curl installed on my system, before compiling megacmd. I had to delete curl (pkg_delete curl, pkg_delete -a) to compile megacmd. I saw some errors related to curl.so. I cleaned up everything after the installation (make clean, pkg_delete -a, make clean=dist, make clean=flavors, make package BULK=Yes). After that, I added again curl (pkg_add curl) and both curl and mega-* work. Thanks a lot, regards Il giorno lun 12 giu 2023 alle ore 17:57 Robert Bagdan ha scritto: > Hi! To build megacmd: get the 7.3 branch of the ports tree, extract > magacmd.tar.gz attachment to the net subdirectory in your ports tree, > and run "make FETCH_PACKAGES= install" from net/megacmd subdirectory. > I don't know megatools, so I can't help with that. >
Re: [NEW] net/megacmd
Hi, I would like to use megacmd, but I don't understand how to download/compile it on OpenBSD 7.3. I tried installing megatools with 'pkg_add megatools', but megals -u XXX -p YYY gives me this error: 'ERROR: Can't login to mega.nz: API call 'us' failed: Server returned error EEXPIRED' Il giorno lun 15 mag 2023 alle ore 11:37 Robert Bagdan ha scritto: > I've attached the updated version of net/megacmd, which provides non > UI access to > MEGA services. It intends to offer all the functionality with your > MEGA account via commands. It features synchronization,backup of local > folders into your MEGA account. > > I use on amd64 7.3, works fine for me. > > -- > kikadf >
Re: vlc no telnet interface
Ok, clear, thanks a lot for the effort and for the clarification.
Il giorno ven 26 mag 2023 alle ore 10:58 Stuart Henderson <
s...@spacehopper.org> ha scritto:
> You are running 7.3. That has been added for -current only (the first
> release it will make it into is 7.4).
>
> --
> Sent from a phone, apologies for poor formatting.
>
>
> On 26 May 2023 07:42:18 Luca Di Gregorio wrote:
>
> Hello, I've just done a 'pkg_add -Uu -v':
>>
>> Update candidates: vlc-3.0.18 -> vlc-3.0.18
>>
>> and tried to run 'vlc -vvv -I telnet', but I see again:
>>
>> main interface debug: looking for interface module matching "telnet": 13
>> candidates
>> main interface debug: no interface modules matched
>> main interface error: no suitable interface module
>>
>> Am I doing something wrong?
>>
>> With a 'vlc --version' I see:
>> VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
>> VLC version 3.0.18 Vetinari (3.0.13-8-g41878ff4f2)
>> Compiled by _pbuild on amd64-3.ports.openbsd.org (Mar 25 2023 12:30:05)
>>
>> Regards
>> Luca
>>
>> Il giorno ven 12 mag 2023 alle ore 23:48 Brad Smith
>> ha
>> scritto:
>>
>> On 2023-05-10 4:29 a.m., Stuart Henderson wrote:
>>>
>>>> On 2023/04/30 11:53, Antoine Jacoutot wrote:
>>>>
>>>>> + if test "${enable_lua}" != "no"
>>>>>> + then
>>>>>> +- PKG_CHECK_MODULES(LUA, lua5.2,
>>>>>> ++ PKG_CHECK_MODULES(LUA, lua51,
>>>>>>
>>>>> Can we use SUBST_CMD to prevent hardcoding?
>>>>>
>>>> I don't see anything wrong with hardcoding here? I think MODLUA_VERSION
>>>> should reflect what the port wants, it's not like SHARED_LIBS.
>>>>
>>>> On 2023/05/09 02:29, Brad Smith wrote:
>>>>
>>>>> On 2023-05-01 5:36 a.m., Stuart Henderson wrote:
>>>>>
>>>>>> Any particular reason to use 5.1 instead of 5.2? (They're all EoL
>>>>>>
>>>>> except
>>>
>>>> 5.4, but 5.1 is much longer since EoL).
>>>>>>
>>>>> Just that is what the default is, MODLUA_DEFAULT_VERSION.
>>>>>
>>>> I don't think this is meant to be prescriptive any more than
>>>> say AUTOCONF_VERSION, just that it's what most things used when the
>>>> module was added. We haven't run into problems with ports pulling
>>>> in multiple lua versions via lib deps.
>>>>
>>>> (I have a diff to add lua5.X pkg-config files to the lua ports to
>>>> test sometime but the i386 builders are unhappy atm, also the include
>>>> directories are non-standard too and also need patches in various ports,
>>>> so it would be good to clean up that whole lot at once).
>>>>
>>>> How about this diff for vlc? Compared to your previous:
>>>>
>>>> - uses the lua version which upstream prefers
>>>> - brings back UPDATE_PLIST_ARGS from my earlier one to avoid the
>>>> a52/a${MODLUA_VERSION} that is subst'ed in PLIST-main with 5.2
>>>>
>>> I saw this part and did not understand what it was for.
>>>
>>>> - uses the minimum necessary configure.ac patch to handle lua52.pc.
>>>>
>>>
>>> Sure.
>>>
>>>
>>>
>
Re: vlc no telnet interface
Hello, I've just done a 'pkg_add -Uu -v':
Update candidates: vlc-3.0.18 -> vlc-3.0.18
and tried to run 'vlc -vvv -I telnet', but I see again:
main interface debug: looking for interface module matching "telnet": 13
candidates
main interface debug: no interface modules matched
main interface error: no suitable interface module
Am I doing something wrong?
With a 'vlc --version' I see:
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
VLC version 3.0.18 Vetinari (3.0.13-8-g41878ff4f2)
Compiled by _pbuild on amd64-3.ports.openbsd.org (Mar 25 2023 12:30:05)
Regards
Luca
Il giorno ven 12 mag 2023 alle ore 23:48 Brad Smith ha
scritto:
> On 2023-05-10 4:29 a.m., Stuart Henderson wrote:
> > On 2023/04/30 11:53, Antoine Jacoutot wrote:
> >>> + if test "${enable_lua}" != "no"
> >>> + then
> >>> +- PKG_CHECK_MODULES(LUA, lua5.2,
> >>> ++ PKG_CHECK_MODULES(LUA, lua51,
> >> Can we use SUBST_CMD to prevent hardcoding?
> > I don't see anything wrong with hardcoding here? I think MODLUA_VERSION
> > should reflect what the port wants, it's not like SHARED_LIBS.
> >
> > On 2023/05/09 02:29, Brad Smith wrote:
> >> On 2023-05-01 5:36 a.m., Stuart Henderson wrote:
> >>> Any particular reason to use 5.1 instead of 5.2? (They're all EoL
> except
> >>> 5.4, but 5.1 is much longer since EoL).
> >> Just that is what the default is, MODLUA_DEFAULT_VERSION.
> > I don't think this is meant to be prescriptive any more than
> > say AUTOCONF_VERSION, just that it's what most things used when the
> > module was added. We haven't run into problems with ports pulling
> > in multiple lua versions via lib deps.
> >
> > (I have a diff to add lua5.X pkg-config files to the lua ports to
> > test sometime but the i386 builders are unhappy atm, also the include
> > directories are non-standard too and also need patches in various ports,
> > so it would be good to clean up that whole lot at once).
> >
> > How about this diff for vlc? Compared to your previous:
> >
> > - uses the lua version which upstream prefers
> > - brings back UPDATE_PLIST_ARGS from my earlier one to avoid the
> > a52/a${MODLUA_VERSION} that is subst'ed in PLIST-main with 5.2
> I saw this part and did not understand what it was for.
> > - uses the minimum necessary configure.ac patch to handle lua52.pc.
>
> Sure.
>
>
Re: vlc no telnet interface
It would be great for my project.
With oldrc I can only add/enqueue items to the playlist,
but I cannot remove a specific item.
There is the command 'clear', but it removes all the items of the playlist.
Thanks a lot
Il giorno gio 27 apr 2023 alle ore 06:58 Brad Smith ha
scritto:
> On 2023-04-26 11:15 a.m., Stuart Henderson wrote:
> > On 2023/04/25 09:55, Luca Di Gregorio wrote:
> >> Hi, I see that vlc doesn't have the telnet interface:
> >>
> >> # vlc -vvv -I telnet
> >> VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
> >> ...
> >> main interface debug: looking for interface module matching "telnet": 13
> >> candidates
> >> main interface debug: no interface modules matched
> >> ...
> >>
> >> Do you think that it's possible to have a new executable of vlc
> >> with the telnet interface available?
> > It can be done like this. I have no idea whether the maintainer
> > (cc'd) would like to do that or not though, it will add a bit of
> > extra work at port update time if the PLISTs need updating.
>
> I don't mind adding it to the main package.
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/x11/vlc/Makefile,v
> > retrieving revision 1.262
> > diff -u -p -r1.262 Makefile
> > --- Makefile 24 Apr 2023 11:42:50 - 1.262
> > +++ Makefile 26 Apr 2023 15:12:15 -
> > @@ -1,11 +1,13 @@
> > COMMENT-main= VideoLAN client; multimedia player
> > COMMENT-jack= JACK audio output module for VLC
> > +COMMENT-lua= Lua support for VLC, including telnet module
> >
> > V= 3.0.18
> > DISTNAME= vlc-${V}
> > PKGNAME-main= ${DISTNAME}
> > PKGNAME-jack= vlc-jack-${V}
> > -REVISION-main= 1
> > +PKGNAME-lua= vlc-lua-${V}
> > +REVISION-main= 2
> > CATEGORIES= x11
> > MASTER_SITES=
> https://download.videolan.org/pub/videolan/vlc/${V}/
> > EXTRACT_SUFX= .tar.xz
> > @@ -49,6 +51,8 @@ WANTLIB-main+= v4l2
> >
> > WANTLIB-jack= db execinfo jack vlccore ${WANTLIB-common}
> >
> > +WANTLIB-lua= ${MODLUA_WANTLIB}
> > +
> > AUTOCONF_VERSION= 2.69
> > AUTOMAKE_VERSION= 1.16
> > AUTORECONF= ./bootstrap
> > @@ -101,6 +105,8 @@ LIB_DEPENDS-main= ${MODQT5_LIB_DEPENDS}
> > x11/gtk+3
> > LIB_DEPENDS-jack= ${BUILD_PKGPATH} \
> > audio/jack
> > +RUN_DEPENDS-lua= ${BUILD_PKGPATH}
> > +LIB_DEPENDS-lua= ${MODLUA_LIB_DEPENDS}
> > BUILD_DEPENDS= ${MODGNU_AUTOCONF_DEPENDS} \
> > ${MODGNU_AUTOMAKE_DEPENDS} \
> > archivers/gtar \
> > @@ -145,7 +151,6 @@ CONFIGURE_ARGS+=--disable-a52 \
> > --disable-libva \
> > --disable-linsys \
> > --disable-live555 \
> > - --disable-lua \
> > --disable-mad \
> > --disable-mfx \
> > --disable-microdns \
> > @@ -190,19 +195,27 @@ CONFIGURE_ENV+= BUILDCC="${CC}" \
> > PKG_CONFIG_PATH="${LOCALBASE}/lib/qt5/pkgconfig" \
> > RCC="${LOCALBASE}/bin/rcc-qt5"
> >
> > -PSEUDO_FLAVORS= no_jack
> > +PSEUDO_FLAVORS= no_jack no_lua
> > FLAVOR?=
> >
> > -MULTI_PACKAGES= -main
> > -
> > -.if !${FLAVOR:Mno_jack}
> > -MULTI_PACKAGES+=-jack
> > -.endif
> > +MULTI_PACKAGES= -main -jack -lua
> >
> > .include
> >
> > .if !${BUILD_PACKAGES:M-jack}
> > CONFIGURE_ARGS+=--disable-jack
> > +.endif
> > +
> > +.if !${BUILD_PACKAGES:M-lua}
> > +CONFIGURE_ARGS+= --disable-lua
> > +.else
> > +CONFIGURE_ENV+= LUAC="luac${MODLUA_DEP_VERSION}"
> > +MODULES+=lang/lua
> > +MODLUA_VERSION= 5.2
> > +MODLUA_SA= Yes
> > +MODLUA_RUNDEP= No
> > +CONFIGURE_ARGS+= --enable-lua
> > +UPDATE_PLIST_ARGS+= -i MODLUA_DEP_VERSION
> > .endif
> >
> > .if ${MACHINE_ARCH} == "amd64"
> > Index: patches/patch-configure_ac
> > ===
> > RCS file: /cvs/ports/x11/vlc/patches/patch-configure_ac,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 patch-configure_ac
> > --- patches/patch-configure_ac25 Nov 2022 11:52:17 -
> 1.43
> > +++ patches/patch-configure_ac26 Apr 2023 15:12:15 -
> > @@ -11,11 +11,10 @@ Index: configur
Re: vlc no telnet interface
I would really appreciate it a lot.
Currently I'm setting vlc via the oldrc interface, which has a smaller
set of options than the telnet interface.
And I don't want to use Linux, PF is by far smarter than iptables.
I'm sorry but I can't help in compiling, I have poor knowledge on C.
Regards, thanks for your time
Il giorno mer 26 apr 2023 alle ore 17:15 Stuart Henderson <
s...@spacehopper.org> ha scritto:
> On 2023/04/25 09:55, Luca Di Gregorio wrote:
> > Hi, I see that vlc doesn't have the telnet interface:
> >
> > # vlc -vvv -I telnet
> > VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
> > ...
> > main interface debug: looking for interface module matching "telnet": 13
> >candidates
> > main interface debug: no interface modules matched
> > ...
> >
> > Do you think that it's possible to have a new executable of vlc
> > with the telnet interface available?
>
> It can be done like this. I have no idea whether the maintainer
> (cc'd) would like to do that or not though, it will add a bit of
> extra work at port update time if the PLISTs need updating.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/vlc/Makefile,v
> retrieving revision 1.262
> diff -u -p -r1.262 Makefile
> --- Makefile24 Apr 2023 11:42:50 - 1.262
> +++ Makefile26 Apr 2023 15:12:15 -
> @@ -1,11 +1,13 @@
> COMMENT-main= VideoLAN client; multimedia player
> COMMENT-jack= JACK audio output module for VLC
> +COMMENT-lua= Lua support for VLC, including telnet module
>
> V= 3.0.18
> DISTNAME= vlc-${V}
> PKGNAME-main= ${DISTNAME}
> PKGNAME-jack= vlc-jack-${V}
> -REVISION-main= 1
> +PKGNAME-lua= vlc-lua-${V}
> +REVISION-main= 2
> CATEGORIES=x11
> MASTER_SITES= https://download.videolan.org/pub/videolan/vlc/${V}/
> EXTRACT_SUFX= .tar.xz
> @@ -49,6 +51,8 @@ WANTLIB-main+=v4l2
>
> WANTLIB-jack= db execinfo jack vlccore ${WANTLIB-common}
>
> +WANTLIB-lua= ${MODLUA_WANTLIB}
> +
> AUTOCONF_VERSION= 2.69
> AUTOMAKE_VERSION= 1.16
> AUTORECONF=./bootstrap
> @@ -101,6 +105,8 @@ LIB_DEPENDS-main= ${MODQT5_LIB_DEPENDS}
> x11/gtk+3
> LIB_DEPENDS-jack= ${BUILD_PKGPATH} \
> audio/jack
> +RUN_DEPENDS-lua= ${BUILD_PKGPATH}
> +LIB_DEPENDS-lua= ${MODLUA_LIB_DEPENDS}
> BUILD_DEPENDS= ${MODGNU_AUTOCONF_DEPENDS} \
> ${MODGNU_AUTOMAKE_DEPENDS} \
> archivers/gtar \
> @@ -145,7 +151,6 @@ CONFIGURE_ARGS+=--disable-a52 \
> --disable-libva \
> --disable-linsys \
> --disable-live555 \
> - --disable-lua \
> --disable-mad \
> --disable-mfx \
> --disable-microdns \
> @@ -190,19 +195,27 @@ CONFIGURE_ENV+= BUILDCC="${CC}" \
> PKG_CONFIG_PATH="${LOCALBASE}/lib/qt5/pkgconfig" \
> RCC="${LOCALBASE}/bin/rcc-qt5"
>
> -PSEUDO_FLAVORS=no_jack
> +PSEUDO_FLAVORS=no_jack no_lua
> FLAVOR?=
>
> -MULTI_PACKAGES=-main
> -
> -.if !${FLAVOR:Mno_jack}
> -MULTI_PACKAGES+=-jack
> -.endif
> +MULTI_PACKAGES=-main -jack -lua
>
> .include
>
> .if !${BUILD_PACKAGES:M-jack}
> CONFIGURE_ARGS+=--disable-jack
> +.endif
> +
> +.if !${BUILD_PACKAGES:M-lua}
> +CONFIGURE_ARGS+= --disable-lua
> +.else
> +CONFIGURE_ENV+=LUAC="luac${MODLUA_DEP_VERSION}"
> +MODULES+= lang/lua
> +MODLUA_VERSION=5.2
> +MODLUA_SA= Yes
> +MODLUA_RUNDEP= No
> +CONFIGURE_ARGS+= --enable-lua
> +UPDATE_PLIST_ARGS+= -i MODLUA_DEP_VERSION
> .endif
>
> .if ${MACHINE_ARCH} == "amd64"
> Index: patches/patch-configure_ac
> ===
> RCS file: /cvs/ports/x11/vlc/patches/patch-configure_ac,v
> retrieving revision 1.43
> diff -u -p -r1.43 patch-configure_ac
> --- patches/patch-configure_ac 25 Nov 2022 11:52:17 - 1.43
> +++ patches/patch-configure_ac 26 Apr 2023 15:12:15 -
> @@ -11,11 +11,10 @@ Index: configure.ac
> ;;
> netbsd*)
> SYS=netbsd
> -@@ -1122,22 +1121,6 @@ AC_ARG_ENABLE(optimizations,
> -
> +@@ -1123,22 +1122,6 @@ AC_ARG_ENABLE(optimizations,
> dnl Check for various optimization flags
> AS_IF([test "${enable_optimizations}" != "no"], [
> --
> +
> - dnl -O3 only in production builds
> - AS_IF([test "${enable_debug}" = "no"], [
> -VLC_SAVE_FLAGS
> @@ -31,6 +30,16 @@ Index: configure.ac
> -])
vlc no telnet interface
Hi, I see that vlc doesn't have the telnet interface: # vlc -vvv -I telnet VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2) ... main interface debug: looking for interface module matching "telnet": 13 candidates main interface debug: no interface modules matched ... Do you think that it's possible to have a new executable of vlc with the telnet interface available?
websocketd make install problem
OpenBSD 6.5 Platform: Hyper V Windows 10 Enterprise Windows 10 version: Version 10.0.17134 Build 17134 VM Version: 8.3 RAM: 1024Mb cd /usr/ports/net/websocketd make install After a while, the system is blocked. Impossible to login via SSH. Impossible to login via console with root. Output of 'make install': ===> Checking files for websocketd-0.2.12p1 `/usr/ports/distfiles/websocketd-0.2.12.tar.gz' is up to date. >> (SHA256) websocketd-0.2.12.tar.gz: OK ===> websocketd-0.2.12p1 depends on: go-net-* - not found ===> Verifying install for go-net-* in net/go-net ===> Checking files for go-net-20190226 `/usr/ports/distfiles/go-net-20190226-fe579d43.tar.gz' is up to date. >> (SHA256) go-net-20190226-fe579d43.tar.gz: OK ===> go-net-20190226 depends on: go-sys-* - not found ===> Verifying install for go-sys-* in devel/go-sys ===> Checking files for go-sys-20190226 `/usr/ports/distfiles/go-sys-20190226-cc5685c2.tar.gz' is up to date. >> (SHA256) go-sys-20190226-cc5685c2.tar.gz: OK ===> go-sys-20190226 depends on: go-=1.12.1 - not found ===> Verifying install for go-=1.12.1 in lang/go ===> Building for go-1.12.1 Building Go cmd/dist using /usr/local/go/bootstrap. Building Go toolchain1 using /usr/local/go/bootstrap. Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1. Building Go toolchain2 using go_bootstrap and Go toolchain1.
