Re: [update] textproc/lowdown to 0.6.4
On Sun, 19 Apr 2020 19:18:57 -0500 Lucas Raab wrote: > On Sun, Apr 12, 2020 at 09:41:24AM -0500, Lucas Raab wrote: > > On Sat, Apr 4, 2020, at 10:18, Lucas Raab wrote: > > > Hello, > > > > > > Here is a lowdown update to 0.6.4. > > > > > > Bryan, everything seem ok? > > > > > > Thanks, > > > Lucas > > > > > > Index: Makefile > > > === > > > RCS file: /cvs/ports/textproc/lowdown/Makefile,v > > > retrieving revision 1.19 > > > diff -u -p -r1.19 Makefile > > > --- Makefile 22 Feb 2020 11:29:17 - 1.19 > > > +++ Makefile 4 Apr 2020 15:17:26 - > > > @@ -1,7 +1,7 @@ > > > # $OpenBSD: Makefile,v 1.19 2020/02/22 11:29:17 sthen Exp $ > > > > > > COMMENT =simple markdown translator > > > -DISTNAME = lowdown-0.5.4 > > > +DISTNAME = lowdown-0.6.4 > > > CATEGORIES = textproc > > > > > > HOMEPAGE = https://kristaps.bsd.lv/lowdown/ > > > Index: distinfo > > > === > > > RCS file: /cvs/ports/textproc/lowdown/distinfo,v > > > retrieving revision 1.16 > > > diff -u -p -r1.16 distinfo > > > --- distinfo 22 Feb 2020 11:29:17 - 1.16 > > > +++ distinfo 4 Apr 2020 15:17:26 - > > > @@ -1,2 +1,2 @@ > > > -SHA256 (lowdown-0.5.4.tar.gz) = > > > VbTDlqP9IOljqb94kau0EgArpfVX5+iVmp0aFiAyVQo= > > > -SIZE (lowdown-0.5.4.tar.gz) = 119029 > > > +SHA256 (lowdown-0.6.4.tar.gz) = > > > EPftZ5/jJMAAs7I0955bEolbpCISgH0kKv3Eja0Tjno= > > > +SIZE (lowdown-0.6.4.tar.gz) = 154971 > > > > > > > > > > Ping > > > > Bryan, any thoughts? > > No response from maintainer. Thoughts? > > I'm not deadset on this making 6.7. Low risk, but that plays both ways. > > Lucas > For what its's worth, I used your patch to test 0.6.4. on amd64 and macppc. Compiles and runs without issue. I noticed no regressions. Thank you for sending the update. Micah
Re: github mirror
On Mon, Apr 20, 2020 at 12:05:28AM +0100, Stuart Henderson wrote: > On 2020/04/20 00:53, Jeremie Courreges-Anglas wrote: > > > > I think we should use the format described by f.holop, ie > > distfiles (.cvsignore) -> /distfiles/ (.gitignore) > > otherwise this could create confusion in case of a name collision in > > a subdirectory. > > > > But yeah, makes sense, ok jca@ > > So to be specific, the diff below. I'll wait a bit for any NAKs before > I commit it. just to point that this syntax isn't compatible with got. got [...] gives no special significance to the location of path component separators, “/”, in a pattern. so as it, it means it doesn't match anything. but it doesn't mean it shouldn't be committed. (the pattern in .cvsignore are also used by got, and match them) thanks. > Index: .gitignore > === > RCS file: .gitignore > diff -N .gitignore > --- /dev/null 1 Jan 1970 00:00:00 - > +++ .gitignore19 Apr 2020 23:04:52 - > @@ -0,0 +1,13 @@ > +/bulk/ > +/distfiles/ > +/locks/ > +/logs/ > +/lost+found/ > +/mystuff/ > +/openbsd-wip/ > +/packages/ > +/plist/ > +/pobj/ > +/sqlports/ > +/sqlports-journal/ > +/update/ > -- Sebastien Marie
Re: [update] textproc/lowdown to 0.6.4
On Sun, Apr 12, 2020 at 09:41:24AM -0500, Lucas Raab wrote: > On Sat, Apr 4, 2020, at 10:18, Lucas Raab wrote: > > Hello, > > > > Here is a lowdown update to 0.6.4. > > > > Bryan, everything seem ok? > > > > Thanks, > > Lucas > > > > Index: Makefile > > === > > RCS file: /cvs/ports/textproc/lowdown/Makefile,v > > retrieving revision 1.19 > > diff -u -p -r1.19 Makefile > > --- Makefile22 Feb 2020 11:29:17 - 1.19 > > +++ Makefile4 Apr 2020 15:17:26 - > > @@ -1,7 +1,7 @@ > > # $OpenBSD: Makefile,v 1.19 2020/02/22 11:29:17 sthen Exp $ > > > > COMMENT = simple markdown translator > > -DISTNAME = lowdown-0.5.4 > > +DISTNAME = lowdown-0.6.4 > > CATEGORIES = textproc > > > > HOMEPAGE = https://kristaps.bsd.lv/lowdown/ > > Index: distinfo > > === > > RCS file: /cvs/ports/textproc/lowdown/distinfo,v > > retrieving revision 1.16 > > diff -u -p -r1.16 distinfo > > --- distinfo22 Feb 2020 11:29:17 - 1.16 > > +++ distinfo4 Apr 2020 15:17:26 - > > @@ -1,2 +1,2 @@ > > -SHA256 (lowdown-0.5.4.tar.gz) = > > VbTDlqP9IOljqb94kau0EgArpfVX5+iVmp0aFiAyVQo= > > -SIZE (lowdown-0.5.4.tar.gz) = 119029 > > +SHA256 (lowdown-0.6.4.tar.gz) = > > EPftZ5/jJMAAs7I0955bEolbpCISgH0kKv3Eja0Tjno= > > +SIZE (lowdown-0.6.4.tar.gz) = 154971 > > > > > > Ping > > Bryan, any thoughts? No response from maintainer. Thoughts? I'm not deadset on this making 6.7. Low risk, but that plays both ways. Lucas
new misc/py-opcua
Hi, I would like to browse OPC UA servers with a python GUI. For that I need py-opcua, py-opcua-widgets, py-opcua-client. As py-opcua-widgets does not compile with python2, I think we should only have python3 ports. ok? Description: Pure Python OPC UA / IEC 62541 Client and Server Python 2, 3 and pypy. OPC UA binary protocol implementation is quasi complete and has been tested against many different OPC UA stacks. API offers both a low level interface to send and receive all UA defined structures and high level classes allowing to write a server or a client in a few lines. It is easy to mix high level objects and low level UA calls in one application. Description: Common widgets for opcua-modeler og opcua-client-gui. Description: Simple OPC-UA GUI client. Written using freeopcua python api and pyqt. Most needed functionnalities are implemented including subscribing for data changes and events, write variable values listing attributes and references, and call methods. bluhm py-opcua.tgz Description: application/tar-gz py-opcua-widgets.tgz Description: application/tar-gz py-opcua-client.tgz Description: application/tar-gz
Re: make extract woes (rust)
On 2020/04/20 01:10, f.holop wrote: > hello, > > not my day. > i am trying to put together my first rust port but failing miserably. > > i use ripgrep all the time. so i look at the port. i try to build it. > it errors out right away: > > ~/src/ports/textproc/ripgrep$ make extract > ===> Checking files for ripgrep-11.0.2p0 > `/home/g/src/ports/distfiles/ripgrep-11.0.2.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/libc-0.2.63.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/aho-corasick-0.7.4.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/atty-0.2.13.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/base64-0.10.1.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/bitflags-1.1.0.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/bstr-0.2.6.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/bytecount-0.5.1.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/byteorder-1.3.2.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/c2-chacha-0.2.2.tar.gz' is up to date. > `/home/g/src/ports/distfiles/cargo/cc-1.0.38.tar.gz' is up to date. > >> Fetch https://crates.io/api/v1/crates/cfg-if/0.1.9/download > ftp: File is already fully retrieved. > >> Fetch > >> https://ftp.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz > ftp: File is already fully retrieved. > >> Fetch > >> https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz > ftp: Error retrieving > https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz: > 404 Not Found > >> Fetch > >> https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz > ftp: File is already fully retrieved. > *** Error 1 in . (/home/g/src/ports/infrastructure/mk/bsd.port.mk:3136 > '/home/g/src/ports/distfiles/cargo/cfg-if-0.1.9.tar.gz': @lock=cfg-if...) > *** Error 2 in . (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2447 > '_internal-fetch': @cd /home/g/src/ports/textproc/ripgrep && PKGPATH=...) > *** Error 2 in . (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2652 > '/home/g/src/ports/pobj/ripgrep-11.0.2/.extract_done': @cd/home/g/sr...) > *** Error 2 in /home/g/src/ports/textproc/ripgrep > (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2573 'extract': > @lock=ripgrep-11.0.2p0; ...) > what does it mean "File is already fully retrieved." ? > why is that a bad thing? It's trying to continue fetching (ftp -C) but the range request is rejected because it's trying to fetch starting at the end of the file. You'll see the same if you try to fetch it twice manually with ftp -C. I guess it didn't get renamed from cfg-if-0.1.9.tar.gz.dist to cfg-if-0.1.9.tar.gz maybe due to some permissions problem. ls -l distfiles/cargo/cfg-if-0.1.9.tar.gz* - anything look different than other files? > > some other questions: > > where did this list of MODCARGO_CRATES come from? > it's not the dep list in the toml file, so it's not > like RUN_DEPENDS in python... is it _all_ the crates > from the lock file? am i supposed to fill in the licenses > for all of them manually? Remove the old MODCARGO_CRATES entries, run "make modcargo-gen-crates" and include the newly generated list in the port Makefile. Then "make modcargo-gen-crates-licenses" and replace the list in the Makefile with the new output which includes license information. If it now uses a new version of rust-libc newer than 0.2.63 that's ok, if not then put MODCARGO_CRATES_UPDATE and MODCARGO_CRATES += libc 0.2.63 back.
make extract woes (rust)
hello, not my day. i am trying to put together my first rust port but failing miserably. i use ripgrep all the time. so i look at the port. i try to build it. it errors out right away: ~/src/ports/textproc/ripgrep$ make extract ===> Checking files for ripgrep-11.0.2p0 `/home/g/src/ports/distfiles/ripgrep-11.0.2.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/libc-0.2.63.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/aho-corasick-0.7.4.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/atty-0.2.13.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/base64-0.10.1.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/bitflags-1.1.0.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/bstr-0.2.6.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/bytecount-0.5.1.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/byteorder-1.3.2.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/c2-chacha-0.2.2.tar.gz' is up to date. `/home/g/src/ports/distfiles/cargo/cc-1.0.38.tar.gz' is up to date. >> Fetch https://crates.io/api/v1/crates/cfg-if/0.1.9/download ftp: File is already fully retrieved. >> Fetch https://ftp.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz ftp: File is already fully retrieved. >> Fetch >> https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz ftp: Error retrieving https://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz: 404 Not Found >> Fetch >> https://ftp.fr.openbsd.org/pub/OpenBSD/distfiles/cargo/cfg-if-0.1.9.tar.gz ftp: File is already fully retrieved. *** Error 1 in . (/home/g/src/ports/infrastructure/mk/bsd.port.mk:3136 '/home/g/src/ports/distfiles/cargo/cfg-if-0.1.9.tar.gz': @lock=cfg-if...) *** Error 2 in . (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2447 '_internal-fetch': @cd /home/g/src/ports/textproc/ripgrep && PKGPATH=...) *** Error 2 in . (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2652 '/home/g/src/ports/pobj/ripgrep-11.0.2/.extract_done': @cd/home/g/sr...) *** Error 2 in /home/g/src/ports/textproc/ripgrep (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2573 'extract': @lock=ripgrep-11.0.2p0; ...) what does it mean "File is already fully retrieved." ? why is that a bad thing? some other questions: where did this list of MODCARGO_CRATES come from? it's not the dep list in the toml file, so it's not like RUN_DEPENDS in python... is it _all_ the crates from the lock file? am i supposed to fill in the licenses for all of them manually? -f -- foied vinom pipafo, cra carefo.
Re: github mirror
On 2020/04/20 00:53, Jeremie Courreges-Anglas wrote: > On Sun, Apr 19 2020, Stuart Henderson wrote: > > On 2020/04/19 21:15, f.holop wrote: > >> hello, > >> > >> i realize the github mirror comes as is, but i was wondering, > >> if it would be possible to add a teeny tiny .gitignore with > >> > >> /distfiles/ > >> /packages/ > >> /plist/ > >> /pobj/ > >> > >> (and possibly some others i have forgotten) > > > > It just needs a copy of .cvsignore committing to CVS and it should > > carry across. Makes sense to me, any OKs/objections? > > I think we should use the format described by f.holop, ie > distfiles (.cvsignore) -> /distfiles/ (.gitignore) > otherwise this could create confusion in case of a name collision in > a subdirectory. > > But yeah, makes sense, ok jca@ So to be specific, the diff below. I'll wait a bit for any NAKs before I commit it. Index: .gitignore === RCS file: .gitignore diff -N .gitignore --- /dev/null 1 Jan 1970 00:00:00 - +++ .gitignore 19 Apr 2020 23:04:52 - @@ -0,0 +1,13 @@ +/bulk/ +/distfiles/ +/locks/ +/logs/ +/lost+found/ +/mystuff/ +/openbsd-wip/ +/packages/ +/plist/ +/pobj/ +/sqlports/ +/sqlports-journal/ +/update/
Re: github mirror
On Sun, Apr 19 2020, Stuart Henderson wrote: > On 2020/04/19 21:15, f.holop wrote: >> hello, >> >> i realize the github mirror comes as is, but i was wondering, >> if it would be possible to add a teeny tiny .gitignore with >> >> /distfiles/ >> /packages/ >> /plist/ >> /pobj/ >> >> (and possibly some others i have forgotten) > > It just needs a copy of .cvsignore committing to CVS and it should > carry across. Makes sense to me, any OKs/objections? I think we should use the format described by f.holop, ie distfiles (.cvsignore) -> /distfiles/ (.gitignore) otherwise this could create confusion in case of a name collision in a subdirectory. But yeah, makes sense, 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: k...@cvs.openbsd.org2020/04/19 16:31:30 Modified files: devel/ruby-shims: Makefile devel/ruby-shims/pkg: PLIST devel/go-tools : Makefile devel/go-tools/pkg: PLIST Log message: Register conflict on bundle executable Both install /usr/local/bin/bundle.
Re: FreeRDP 2.0.0 released April 9, 2020
On 2020/04/19 12:25, Steve Williams wrote:
> Thanks very much for all the information. I'll have to spin up my old
> desktop & upgrade it if I'm going to get serious about troubleshooting
> this. My current box is an APU :).
>
> Using DEBUG=-g, I complied a debugging library (OpenBSD 6.6) and was able to
> get a meaningful stack trace. I then applied your patch and recompiled and
> was getting a meaningful stack trace in the new code.
>
> What is the "fastest" way to iterate troubleshooting in the "packages"
> world.
>
> Is it possible to make modifications to the code directly in the
> /usr/ports/pobj/freerdp-2.0.0rc1 tree and somehow magically re-compile
> starting there, rather than having to create a patch, make clean, etc?
Yes, make rebuild / make fake / make repackage (with DEBUG=-g set for
rebuild/fake; as well as being passed to cc it also controls stripping
in "fake").
Ports also has support for ccache which can save rebuild time while
working on things. Not so much needed for this case, but if you need to
clean and do a whole rebuild (changing configure options, etc) it can
be quite helpful. See USE_CCACHE in bsd.port.mk(5).
> Sorry for the newby questions..
No need to apologise, these are questions which are not really
discoverable in docs. DEBUG is mentioned in mk.conf(5) but it's not
at all obvious that it will apply to ports too.
> Once I understand the build environment, I'll be fine working through
> this...
>
> And for reference, the code is blowing up on line 234
> void _aligned_free(void* memblock)
> {
> WINPR_ALIGNED_MEM* pMem;
>
> if (!memblock)
> return;
>
> pMem = WINPR_ALIGNED_MEM_STRUCT_FROM_PTR(memblock);
>
> if (pMem->sig != WINPR_ALIGNED_MEM_SIGNATURE)
> ^^
> Core Dump -
> {
> WLog_ERR(TAG, "_aligned_free: memory block was not allocated
> by _aligned_malloc!");
> return;
> }
>
> free(pMem->base_addr);
> }
>
>
> #0 _aligned_free (memblock=0xdfdfdfdfdfdfdfdf) at
> /usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/winpr/libwinpr/crt/alignment.c:234
> ^
> Wow, that memblock looks pretty suspicious!!
Consult malloc(3) on the subject of 0xdf.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/04/19 15:44:29 Modified files: x11/dstat : Makefile distinfo Removed files: x11/dstat/patches: patch-Makefile patch-dstat_1 patch-dstat_c Log message: update to 0.7 release which switches volume reading to sndio so patches are no longer needed
Re: wip: mail/notmuch
This is now OK sthen@ to import. As there has been a fair bit of
interest in this over time, I think it might be worth considering this
for commit before 6.7 if another committer agrees, but I would not like
to add the dependency to neomutt until after release (because then
notmuch build failures for any arches would knock out building neomutt
on those arches).
On 2020/04/19 23:14, Olivier Taïbi wrote:
> Oops, just realised that the addition of MODPY_VERSION as Stuart
> Henderson suggested means that sphinx-build-3 is installed as a
> dependency, instead of sphinx-build previously. The attached port
> reflects this (sphinx-build -> sphinx-build-3 in two files).
>
> On Thu, Apr 16, 2020 at 08:47:50PM +0200, Olivier Taïbi wrote:
> > On Fri, Apr 10, 2020 at 09:47:35PM +0100, Stuart Henderson wrote:
> > > for a standalone port, use "MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}",
> > > the FLAVOR setup is for python modules (py-* ports).
> >
> > Thanks, I did that.
> >
> > > The update of the main copy in src/lib/libz has been done at least twice
> > > (though I don't think it happened for the other copies in sys/lib/libz and
> > > src/gnu/usr.bin/cvs - amusingly the fourth copy, in perl, is already at
> > > 1.2.11) - but not made it into the tree. The thing I remember putting
> > > some people off was the "new" z_off64_t (10 years old today in the
> > > public api).
> > >
> > > But updating it is the only option that fixes the various pain / patching
> > > / workarounds / using bundled copies in various things in ports that
> > > has been a problem at least going back to 2012.
> >
> > Would incremental changes converging towards API compatibility with
> > newer zlib stand a better chance of being committed?
> >
> > In any case, I patched notmuch-dump.c (mostly) to replace zlib by stdio
> > and added crude error checking. Thanks to the notmuch tests I believe I
> > came across a bug in src/lib/libz/gzio.c, see
> > https://marc.info/?l=openbsd-bugs=158697346006702
> > With this patch to base, almost all tests now pass, except:
> > - in T350-crypto, the first decryption test fails with "Failed to
> > decrypt part: Decryption failed: No secret key". Oddly, the next ones
> > succeed, and if I permute them, then only the first one fails. I was
> > not able to reproduce this bug (even running the test on another
> > machine made it disappear, go figure...), and I would guess that it
> > comes from gmime30 (which is responsible for looking for said secret
> > key) rather than notmuch. Probably related to an environment variable
> > or something else particular to the chroot in which I build.
> > - In T455-emacs-charsets, two tests related to the Yen character fail,
> > but I think they shouldn't: the output is the "Yen sign" U+00A5, i.e.
> > 0xC2 0xA5, when the test expected the "Fullwidth Yen sign" U+FFE5,
> > i.e. 0xEF 0xBF 0xA5. What we get seems to be more correct.
> > - in T610-message-property, the "prefix" test fails, but this seems to
> > be because the test is incorrect (it expects a certain order that is
> > not guaranteed by the implementation: there is a key-multiple values
> > map in which the keys are sorted, but not the values). The test
> > itself should be fixed.
> > I also ran the tests in T530-upgrade, which require a file to be
> > downloaded separately (I did not see a way to achieve this automatically
> > using bsd.port.mk, so I just downloaded the file on the side and ran the
> > test manually), and the tests pass (after a small patch in
> > notmuch-new.c). It probably does not matter much anyway because these
> > tests concern upgrading from an old database.
> >
> > So I am now happy with the result of the tests.
> >
> > I did not touch the python bindings part of the port. In fact I did not
> > even look at it, but the test pass so hopefully they're ok. Grepping
> > for dump does not yield any match, so I guess that the removal of the
> > --gzip option makes no difference for them.
> >
> > Note that there are also ruby bindings, which are currently not built by
> > the port, and that are presumably required for the vim plugin. I do not
> > intend to look at them in the near future.
> >
> > I hope that this port can now be commited. I have been using notmuch on
> > OpenBSD for more than a year without issues now, but I have not tagged
> > anything (too lazy) and only used searching, and so I have never had any
> > use for the dump/restore feature. I hope that Enric, Andrea and others
> > can test tagging more extensively now.
> >
> > Next, there is a trivial patch for neomutt (notmuch is a configure
> > option), which I also have been happily using. Would that be better as
> > a flavor or is notmuch small enough to be a dependency of neomutt?
> >
> > PS: The three zlib-related bugs in notmuch mentioned in a previous email
> > are now fixed upstream, so they should vanish in the next version.
>
>
Re: UPDATE: math/octave
On 2020/04/19 22:04, Stuart Henderson wrote: > On 2020/04/18 14:38, Steven Mestdagh wrote: > > update octave, and reinstate wantlib that was somehow removed earlier. > > tested lightly on amd64, test suite shows no regression compared to > > version 5.1.0 in tree. > > > > please test/comment/ok. > > Not an Octave user and I can't really comment on whether the update is > important/safe to have before release or not (ports-wise it looks good > though).. but one way or the other the WANTLIB definitely needs fixing. > oh, it picks up fltk if present at configure time, it either needs wantlib+lib_depends additions, or --without-fltk octave-5.2.0(math/octave): Missing: Xau.10 (/usr/local/lib/octave/5.2.0/oct/x86_64-unknown-openbsd6.7/__init_fltk__.oct) (system lib) Missing: Xcursor.5 (/usr/local/lib/octave/5.2.0/oct/x86_64-unknown-openbsd6.7/__init_fltk__.oct) (system lib) Missing: Xdmcp.11 (/usr/local/lib/octave/5.2.0/oct/x86_64-unknown-openbsd6.7/__init_fltk__.oct) (system lib) Missing: Xft.12 (/usr/local/lib/octave/5.2.0/oct/x86_64-unknown-openbsd6.7/__init_fltk__.oct) (system lib) Missing: Xinerama.6 (/usr/local/lib/octave/5.2.0/oct/x86_64-unknown-openbsd6.7/__init_fltk__.oct) (system lib) Missing lib: fltk.8 (/usr/local/lib/octave/5.2.0/oct/x86_64-unknown-openbsd6.7/__init_fltk__.oct) (NOT REACHABLE) Missing lib: fltk_gl.8 (/usr/local/lib/octave/5.2.0/oct/x86_64-unknown-openbsd6.7/__init_fltk__.oct) (NOT REACHABLE) WANTLIB += Xau Xcursor Xdmcp Xft Xinerama *** Error 1 in target 'port-lib-depends-check' (ignored)
Re: wip: mail/notmuch
Oops, just realised that the addition of MODPY_VERSION as Stuart
Henderson suggested means that sphinx-build-3 is installed as a
dependency, instead of sphinx-build previously. The attached port
reflects this (sphinx-build -> sphinx-build-3 in two files).
On Thu, Apr 16, 2020 at 08:47:50PM +0200, Olivier Taïbi wrote:
> On Fri, Apr 10, 2020 at 09:47:35PM +0100, Stuart Henderson wrote:
> > for a standalone port, use "MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}",
> > the FLAVOR setup is for python modules (py-* ports).
>
> Thanks, I did that.
>
> > The update of the main copy in src/lib/libz has been done at least twice
> > (though I don't think it happened for the other copies in sys/lib/libz and
> > src/gnu/usr.bin/cvs - amusingly the fourth copy, in perl, is already at
> > 1.2.11) - but not made it into the tree. The thing I remember putting
> > some people off was the "new" z_off64_t (10 years old today in the
> > public api).
> >
> > But updating it is the only option that fixes the various pain / patching
> > / workarounds / using bundled copies in various things in ports that
> > has been a problem at least going back to 2012.
>
> Would incremental changes converging towards API compatibility with
> newer zlib stand a better chance of being committed?
>
> In any case, I patched notmuch-dump.c (mostly) to replace zlib by stdio
> and added crude error checking. Thanks to the notmuch tests I believe I
> came across a bug in src/lib/libz/gzio.c, see
> https://marc.info/?l=openbsd-bugs=158697346006702
> With this patch to base, almost all tests now pass, except:
> - in T350-crypto, the first decryption test fails with "Failed to
> decrypt part: Decryption failed: No secret key". Oddly, the next ones
> succeed, and if I permute them, then only the first one fails. I was
> not able to reproduce this bug (even running the test on another
> machine made it disappear, go figure...), and I would guess that it
> comes from gmime30 (which is responsible for looking for said secret
> key) rather than notmuch. Probably related to an environment variable
> or something else particular to the chroot in which I build.
> - In T455-emacs-charsets, two tests related to the Yen character fail,
> but I think they shouldn't: the output is the "Yen sign" U+00A5, i.e.
> 0xC2 0xA5, when the test expected the "Fullwidth Yen sign" U+FFE5,
> i.e. 0xEF 0xBF 0xA5. What we get seems to be more correct.
> - in T610-message-property, the "prefix" test fails, but this seems to
> be because the test is incorrect (it expects a certain order that is
> not guaranteed by the implementation: there is a key-multiple values
> map in which the keys are sorted, but not the values). The test
> itself should be fixed.
> I also ran the tests in T530-upgrade, which require a file to be
> downloaded separately (I did not see a way to achieve this automatically
> using bsd.port.mk, so I just downloaded the file on the side and ran the
> test manually), and the tests pass (after a small patch in
> notmuch-new.c). It probably does not matter much anyway because these
> tests concern upgrading from an old database.
>
> So I am now happy with the result of the tests.
>
> I did not touch the python bindings part of the port. In fact I did not
> even look at it, but the test pass so hopefully they're ok. Grepping
> for dump does not yield any match, so I guess that the removal of the
> --gzip option makes no difference for them.
>
> Note that there are also ruby bindings, which are currently not built by
> the port, and that are presumably required for the vim plugin. I do not
> intend to look at them in the near future.
>
> I hope that this port can now be commited. I have been using notmuch on
> OpenBSD for more than a year without issues now, but I have not tagged
> anything (too lazy) and only used searching, and so I have never had any
> use for the dump/restore feature. I hope that Enric, Andrea and others
> can test tagging more extensively now.
>
> Next, there is a trivial patch for neomutt (notmuch is a configure
> option), which I also have been happily using. Would that be better as
> a flavor or is notmuch small enough to be a dependency of neomutt?
>
> PS: The three zlib-related bugs in notmuch mentioned in a previous email
> are now fixed upstream, so they should vanish in the next version.
notmuch.tgz
Description: Binary data
Re: github mirror
On 2020/04/19 21:15, f.holop wrote: > hello, > > i realize the github mirror comes as is, but i was wondering, > if it would be possible to add a teeny tiny .gitignore with > > /distfiles/ > /packages/ > /plist/ > /pobj/ > > (and possibly some others i have forgotten) It just needs a copy of .cvsignore committing to CVS and it should carry across. Makes sense to me, any OKs/objections?
Re: make update-patches woes (go lang)
On 2020/04/19 19:54, f.holop wrote: > hello, > > i don't have experience with go ports and i cannot seem to have > `make update-patches` work on this go project: It is not ideal at present. The directory layout isn't put into place until "make build" starts running. Last diff I saw to fix this broke some of the go ports.
Re: UPDATE: math/octave
On 2020/04/18 14:38, Steven Mestdagh wrote: > update octave, and reinstate wantlib that was somehow removed earlier. > tested lightly on amd64, test suite shows no regression compared to > version 5.1.0 in tree. > > please test/comment/ok. Not an Octave user and I can't really comment on whether the update is important/safe to have before release or not (ports-wise it looks good though).. but one way or the other the WANTLIB definitely needs fixing.
Re: make update-patches woes (go lang)
"f.holop" writes: > hello, > > i don't have experience with go ports and i cannot seem to have > `make update-patches` work on this go project: > > ~/ports/sysutils/fzf$ make update-patches > WRKDIST=/home/g/src/ports/pobj/fzf-0.21.1/fzf-0.21.1 does not exist > *** Error 1 in /home/g/src/ports/sysutils/fzf > (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2559 > 'update-patches': @toedit=`WRKDIST=/home...) > > ~/src/ports/sysutils/fzf$ make show=WRKSRC > /home/g/src/ports/pobj/fzf-0.21.1/go/src/github.com/junegunn/fzf This is what I do for net/dnscrypt-proxy. $ make clean patch Go to /usr/ports/pobj/dnscrypt-proxy-2.0.42/dnscrypt-proxy-2.0.42 and make edits. $ make update-patches $ make clean configure $ make show=WRKSRC /usr/ports/pobj/dnscrypt-proxy-2.0.42/go/src/github.com/jedisct1/dnscrypt-proxy Refer to the lang/go section in port-modules(5) for a full explanation. > > ~/src/ports/sysutils/fzf$ make > ===> fzf-0.21.1 depends on: go-=1.13.9 -> go-1.13.9 > ===> Verifying specs: c pthread > ===> found c.96.0 pthread.26.1 > ===> Checking files for fzf-0.21.1 > `/home/g/src/ports/distfiles/fzf-0.21.1.tar.gz' is up to date. >>> (SHA256) fzf-0.21.1.tar.gz: OK > ===> Extracting for fzf-0.21.1 > ===> Patching for fzf-0.21.1 > ===> Compiler link: clang -> /usr/bin/clang > ===> Compiler link: clang++ -> /usr/bin/clang++ > ===> Compiler link: cc -> /usr/bin/cc > ===> Compiler link: c++ -> /usr/bin/c++ > ===> Generating configure for fzf-0.21.1 > ===> Configuring for fzf-0.21.1 > ===> Building for fzf-0.21.1 > /usr/bin/env -i GOCACHE="/home/g/src/ports/pobj/fzf-0.21.1/go-cache" > GOPATH="/home/g/src/ports/pobj/fzf-0.21.1/go:/usr/local/go-pkg" > GO111MODULE=off GO386=387 > GOPROXY=invalid://ports.should.not.fetch.at.buildtime/ > PORTSDIR="/home/g/src/ports" LIBTOOL="/usr/bin/libtool" > PATH='/home/g/src/ports/pobj/fzf-0.21.1/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin' > PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6' > CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR='' > HOME='/fzf-0.21.1_writes_to_HOME' PICFLAG="-fpic" BINGRP=bin > BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755 INSTALL_COPY=-c > INSTALL_STRIP= MANGRP=bin MANOWN=root MANMODE=644 > BSD_INSTALL_PROGRAM="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c > -m 755" > BSD_INSTALL_SCRIPT="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c > -m 755" > BSD_INSTALL_DATA="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c -m > 644" BSD_INSTALL_MAN="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c > -m 644" > BSD_INSTALL_PROGRAM_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install > -d -m 755" > BSD_INSTALL_SCRIPT_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install > -d -m 755" > BSD_INSTALL_DATA_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -d > -m 755" > BSD_INSTALL_MAN_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -d > -m 755" go install -v -p 1 github.com/junegunn/fzf > github.com/junegunn/fzf/vendor/golang.org/x/sys/unix > github.com/junegunn/fzf/vendor/github.com/mattn/go-isatty > github.com/junegunn/fzf/vendor/github.com/mattn/go-runewidth > github.com/junegunn/fzf/src/util > github.com/junegunn/fzf/src/algo > github.com/junegunn/fzf/vendor/golang.org/x/crypto/ssh/terminal > github.com/junegunn/fzf/src/tui > github.com/junegunn/fzf/vendor/github.com/mattn/go-shellwords > github.com/junegunn/fzf/vendor/golang.org/x/sync/errgroup > github.com/junegunn/fzf/vendor/github.com/saracen/walker > github.com/junegunn/fzf/src > github.com/junegunn/fzf/src/protector > github.com/junegunn/fzf > > -f
Re: github mirror
On Sun, Apr 19, 2020 at 09:32:21PM +0200, Rafael Sadowski wrote: > Use your own *global* gitignore. For more details see core.excludesFile: > https://git-scm.com/docs/gitignore Rather than the global gitignore, you can use the local repo-specific $GIT_DIR/info/exclude
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/04/19 13:57:23 Modified files: sysutils : Makefile Log message: +packer-vmm
Re: github mirror
Rafael Sadowski - Sun, 19 April 2020 at 21:32:21 > Use your own *global* gitignore. For more details see core.excludesFile: > https://git-scm.com/docs/gitignore thanks for tip. from all the local options though i wouldn't choose this one, as it could lead to hard to track down hair pulling problems in some other projects.. -f -- if there's one thing i can't stand, it's intolerance.
make update-patches woes (go lang)
hello, i don't have experience with go ports and i cannot seem to have `make update-patches` work on this go project: ~/ports/sysutils/fzf$ make update-patches WRKDIST=/home/g/src/ports/pobj/fzf-0.21.1/fzf-0.21.1 does not exist *** Error 1 in /home/g/src/ports/sysutils/fzf (/home/g/src/ports/infrastructure/mk/bsd.port.mk:2559 'update-patches': @toedit=`WRKDIST=/home...) ~/src/ports/sysutils/fzf$ make show=WRKSRC /home/g/src/ports/pobj/fzf-0.21.1/go/src/github.com/junegunn/fzf ~/src/ports/sysutils/fzf$ make ===> fzf-0.21.1 depends on: go-=1.13.9 -> go-1.13.9 ===> Verifying specs: c pthread ===> found c.96.0 pthread.26.1 ===> Checking files for fzf-0.21.1 `/home/g/src/ports/distfiles/fzf-0.21.1.tar.gz' is up to date. >> (SHA256) fzf-0.21.1.tar.gz: OK ===> Extracting for fzf-0.21.1 ===> Patching for fzf-0.21.1 ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ ===> Generating configure for fzf-0.21.1 ===> Configuring for fzf-0.21.1 ===> Building for fzf-0.21.1 /usr/bin/env -i GOCACHE="/home/g/src/ports/pobj/fzf-0.21.1/go-cache" GOPATH="/home/g/src/ports/pobj/fzf-0.21.1/go:/usr/local/go-pkg" GO111MODULE=off GO386=387 GOPROXY=invalid://ports.should.not.fetch.at.buildtime/ PORTSDIR="/home/g/src/ports" LIBTOOL="/usr/bin/libtool" PATH='/home/g/src/ports/pobj/fzf-0.21.1/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11R6/bin' PREFIX='/usr/local' LOCALBASE='/usr/local' X11BASE='/usr/X11R6' CFLAGS='-O2 -pipe' TRUEPREFIX='/usr/local' DESTDIR='' HOME='/fzf-0.21.1_writes_to_HOME' PICFLAG="-fpic" BINGRP=bin BINOWN=root BINMODE=755 NONBINMODE=644 DIRMODE=755 INSTALL_COPY=-c INSTALL_STRIP= MANGRP=bin MANOWN=root MANMODE=644 BSD_INSTALL_PROGRAM="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c -m 755" BSD_INSTALL_SCRIPT="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c -m 755" BSD_INSTALL_DATA="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c -m 644" BSD_INSTALL_MAN="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -c -m 644" BSD_INSTALL_PROGRAM_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -d -m 755" BSD_INSTALL_SCRIPT_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -d -m 755" BSD_INSTALL_DATA_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -d -m 755" BSD_INSTALL_MAN_DIR="/home/g/src/ports/pobj/fzf-0.21.1/bin/install -d -m 755" go install -v -p 1 github.com/junegunn/fzf github.com/junegunn/fzf/vendor/golang.org/x/sys/unix github.com/junegunn/fzf/vendor/github.com/mattn/go-isatty github.com/junegunn/fzf/vendor/github.com/mattn/go-runewidth github.com/junegunn/fzf/src/util github.com/junegunn/fzf/src/algo github.com/junegunn/fzf/vendor/golang.org/x/crypto/ssh/terminal github.com/junegunn/fzf/src/tui github.com/junegunn/fzf/vendor/github.com/mattn/go-shellwords github.com/junegunn/fzf/vendor/golang.org/x/sync/errgroup github.com/junegunn/fzf/vendor/github.com/saracen/walker github.com/junegunn/fzf/src github.com/junegunn/fzf/src/protector github.com/junegunn/fzf -f -- reach out /usr/bin/touch faith
Re: github mirror
On Sun Apr 19, 2020 at 09:15:33PM +0200, f.holop wrote: > hello, > > i realize the github mirror comes as is, but i was wondering, > if it would be possible to add a teeny tiny .gitignore with > > /distfiles/ > /packages/ > /plist/ > /pobj/ > > (and possibly some others i have forgotten) > Use your own *global* gitignore. For more details see core.excludesFile: https://git-scm.com/docs/gitignore
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2020/04/19 13:28:57 Log message: Import packer-vmm, HashiCorp Packer plugin for OpenBSD vmm(4). ok sthen@ Status: Vendor Tag: pvk Release Tags: pvk_20200419 N ports/sysutils/packer-vmm/distinfo N ports/sysutils/packer-vmm/Makefile N ports/sysutils/packer-vmm/pkg/DESCR N ports/sysutils/packer-vmm/pkg/PLIST N ports/sysutils/packer-vmm/pkg/README No conflicts created by this import
github mirror
hello, i realize the github mirror comes as is, but i was wondering, if it would be possible to add a teeny tiny .gitignore with /distfiles/ /packages/ /plist/ /pobj/ (and possibly some others i have forgotten) -f -- second star to the right and straight on till morning.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/04/19 13:11:28 Added files: www/chromium/patches: patch-components_services_print_compositor_BUILD_gn Log message: add another missing internal dependency for a mojom rule
Re: UPDATE sysutils/fzf
I know i am a bit late to the party but here are my 2 cents:
1. without overriding FZF_DEFAULT_COMMAND, this port does not work from a
shell that has no `set -o pipefail`:
$ fzf
[Command failed: set -o pipefail; command find -L . -mindepth 1 \( -path ..
>
i think that this is a bug and opened an issue:
https://github.com/junegunn/fzf/issues/1993
While trivial, it's annoying, and of course it might not make it into
upstream for whatever reason. For the time being I am proposing the
following local patch for constants.go:
--- constants.go.orig Sun Apr 19 20:40:59 2020
+++ constants.goSun Apr 19 20:41:36 2020
@@ -59,7 +59,7 @@
func init() {
if !util.IsWindows() {
- defaultCommand = `set -o pipefail; command find -L . -mindepth
1 \( -path '*/\.*' -o -fstype 'sysfs' -o -fstype 'devfs' -o -fstype 'devtmpfs'
-o -fstype'proc' \) -prune -o -type f -print -o -type l -print 2> /dev/null |
cut -b3-`
+ defaultCommand = `sh -c "command find -L . -mindepth 1 -path
'*/\.*' -prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-"`
} else if os.Getenv("TERM") == "cygwin" {
defaultCommand = `sh -c "command find -L . -mindepth 1 -path
'*/\.*' -prune -o -type f -print -o -type l -print 2> /dev/null | cut -b3-"`
}
2. i am a daily user of fzf, also from vim and nvim, integrated with
numerous plugins, but i dont appreciate the package (any package)
installing plugins into my vim runpath whether i asked for it or not.
(also it does not work by default with nvim). The documented and
recommended approach is to add the folder holding the `.vim` file as
another plugin (if used with `vim-plug` from the same author as fzf):
" e.g. on macOS:
Plug '/usr/local/opt/fzf' " <- `fzf.vim` from `brew install fzf`
Plug 'junegunn/fzf.vim' " <- the vim fzf plugin itself
So I think the more generic approach would be to install the `.vim`
file under `/usr/local/share/fzf/...` and use the vim/nvim settings to
discover and load it:
" openbsd:
Plug '/usr/local/share/fzf' " <- where the package should install
Plug 'junegunn/fzf.vim'
diff --git a/sysutils/fzf/Makefile b/sysutils/fzf/Makefile
index 1a807ae1c..94a704a1e 100644
--- a/sysutils/fzf/Makefile
+++ b/sysutils/fzf/Makefile
@@ -4,6 +4,8 @@ COMMENT = command-line fuzzy finder
DISTNAME = fzf-0.21.1
+REVISION = 0
+
CATEGORIES = sysutils
HOMEPAGE = https://github.com/junegunn/fzf
@@ -33,7 +35,7 @@ ALL_TARGET = github.com/junegunn/fzf
ZSH_SITE = ${PREFIX}/share/zsh/site-functions
FISH_SITE =${PREFIX}/share/fish/functions
BASH_SITE =${PREFIX}/share/fzf/bash
-VIMFILES = ${PREFIX}/share/vim/vimfiles
+VIMFILES = ${PREFIX}/share/fzf
VIM_PLUGIN = ${VIMFILES}/plugin
VIM_DOC = ${VIMFILES}/doc
SUBST_VARS += BASH_SITE FISH_SITE VIMFILES
--- PLIST.orig Sun Apr 19 18:16:45 2020
+++ PLIST Sun Apr 19 21:00:23 2020
@@ -11,12 +11,10 @@
share/fzf/bash/
share/fzf/bash/completion.bash
share/fzf/bash/key-bindings.bash
-share/vim/
-share/vim/vimfiles/
-share/vim/vimfiles/doc/
-share/vim/vimfiles/doc/fzf.txt
-share/vim/vimfiles/plugin/
-share/vim/vimfiles/plugin/fzf.vim
+share/fzf/doc/
+share/fzf/doc/fzf.txt
+share/fzf/plugin/
+share/fzf/plugin/fzf.vim
share/zsh/
share/zsh/site-functions/
share/zsh/site-functions/_fzf_completion
-f
--
a man serves best, when he serves himself.
Re: FreeRDP 2.0.0 released April 9, 2020
On 19/04/2020 10:08 a.m., Stuart Henderson wrote:
On 2020/04/19 09:17, Steve Williams wrote:
I am missing something on building the Debug packages. I modified the
Makefile per your other email thread but there must be more magic as I don't
see any of the output pertaining to "Extracting debug info..."
As others mentioned, -current has some infrastructure to produce detached
symbols (and add links to the object so gdb can find them). That isn't
available in earlier releases but the standard old method of setting
DEBUG=-g in the environment is available:
make clean
make DEBUG=-g repackage (add e.g. MAKE_JOBS=4 to build on multiple cpus)
make reinstall
It is a bit disappointing that the newer version of freerdp needs
significant work to have it functional in OpenBSD. I had a look at the
Apple code for the timers... the whole timers file. Not very pleasant with
all the #ifdef's all over the place. I am sure greater minds than mine have
looked at what it would take to have it working in OpenBSD.
cheloha@ mentioned that he has done some work on posix timers for OpenBSD,
I'm not sure what state that is currently in, but it's probably more pleasant
and more useful to gone down that road than add special OpenBSD support to
freerdp..
I guess that leaves debugging the existing code. I started by comparing the
2.0rc1 /winpr/libwinpr/crt/alignment.c with the version in 2.0 and there
have been quite a few changes. It seems most of them are for clarity of
code, but hidden in the changes must be some alignment challenges. Lots of
math going on... and a few confusing comments.
For example:
/* alignment must be a power of 2 */
if (alignment % 2 == 1)
return NULL;
That's not a "power" of two, that's a "multiple" of 2. What did they really
mean?? I assume they meant multiple... but that's not what the code is
doing.
There are only 2 commits in that file between rc1 and 2.0; one is code
formatting, the other is this:
https://github.com/FreeRDP/FreeRDP/issues/2039 /
https://github.com/FreeRDP/FreeRDP/pull/4961
Perhaps it will fix the problem you're seeing. Please try building with the
attached file saved in /usr/ports/x11/freerdp/patches.
Hi,
Thanks very much for all the information. I'll have to spin up my old
desktop & upgrade it if I'm going to get serious about troubleshooting
this. My current box is an APU :).
Using DEBUG=-g, I complied a debugging library (OpenBSD 6.6) and was
able to get a meaningful stack trace. I then applied your patch and
recompiled and was getting a meaningful stack trace in the new code.
What is the "fastest" way to iterate troubleshooting in the "packages"
world.
Is it possible to make modifications to the code directly in the
/usr/ports/pobj/freerdp-2.0.0rc1 tree and somehow magically re-compile
starting there, rather than having to create a patch, make clean, etc?
Sorry for the newby questions..
Once I understand the build environment, I'll be fine working through
this...
And for reference, the code is blowing up on line 234
void _aligned_free(void* memblock)
{
WINPR_ALIGNED_MEM* pMem;
if (!memblock)
return;
pMem = WINPR_ALIGNED_MEM_STRUCT_FROM_PTR(memblock);
if (pMem->sig != WINPR_ALIGNED_MEM_SIGNATURE)
^^
Core Dump -
{
WLog_ERR(TAG, "_aligned_free: memory block was not
allocated by _aligned_malloc!");
return;
}
free(pMem->base_addr);
}
#0 _aligned_free (memblock=0xdfdfdfdfdfdfdfdf) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/winpr/libwinpr/crt/alignment.c:234
^
Wow, that memblock looks pretty suspicious!!
#1 0x047714e6a215 in Bitmap_Free (context=Variable "context" is not
available.
) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/graphics.c:64
#2 0x047714e2a79d in gdi_bitmap_update (context=0x477c4c397f0,
bitmapUpdate=Variable "bitmapUpdate" is not available.
) at color.h:762
#3 0x047714e864c4 in fastpath_recv_update (fastpath=Variable
"fastpath" is not available.
) at stream.h:57
#4 0x047714e84a93 in fastpath_recv_updates (fastpath=Variable
"fastpath" is not available.
) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/fastpath.c:538
#5 0x047714e80468 in rdp_recv_pdu (rdp=0x477663bf400,
s=0x476fb847000) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/rdp.c:1294
#6 0x047714e7fa44 in rdp_recv_callback (transport=Variable
"transport" is not available.
) at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/rdp.c:1448
#7 0x047714e88e63 in transport_check_fds (transport=0x4772b5e4a00)
at
/usr/ports/pobj/freerdp-2.0.0rc1/freerdp-2.0.0-rc1/libfreerdp/core/transport.c:1035
#8 0x047714e80c71 in rdp_check_fds (rdp=0x477663bf400) at
Slowing down for 6.7 release
With the release approaching, ports work should slow down. If you want to update a port, ask yourself: Do we need this now? Is it important? What does it fix? Assume you'll break something: How much effort will be required to fix it? There's a new gettext point release. Nothing important in NEWS. Guess what, I will not update devel/gettext before the release! Let's focus on the important stuff. Things I don't want you to hesitate about: * fixes required for ratchov@'s audio work; * architecture fixes, in particular powerpc; * fixes for other problems. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: FreeRDP 2.0.0 released April 9, 2020
On 2020/04/19 09:17, Steve Williams wrote:
> I am missing something on building the Debug packages. I modified the
> Makefile per your other email thread but there must be more magic as I don't
> see any of the output pertaining to "Extracting debug info..."
As others mentioned, -current has some infrastructure to produce detached
symbols (and add links to the object so gdb can find them). That isn't
available in earlier releases but the standard old method of setting
DEBUG=-g in the environment is available:
make clean
make DEBUG=-g repackage (add e.g. MAKE_JOBS=4 to build on multiple cpus)
make reinstall
> It is a bit disappointing that the newer version of freerdp needs
> significant work to have it functional in OpenBSD. I had a look at the
> Apple code for the timers... the whole timers file. Not very pleasant with
> all the #ifdef's all over the place. I am sure greater minds than mine have
> looked at what it would take to have it working in OpenBSD.
cheloha@ mentioned that he has done some work on posix timers for OpenBSD,
I'm not sure what state that is currently in, but it's probably more pleasant
and more useful to gone down that road than add special OpenBSD support to
freerdp..
> I guess that leaves debugging the existing code. I started by comparing the
> 2.0rc1 /winpr/libwinpr/crt/alignment.c with the version in 2.0 and there
> have been quite a few changes. It seems most of them are for clarity of
> code, but hidden in the changes must be some alignment challenges. Lots of
> math going on... and a few confusing comments.
>
> For example:
> /* alignment must be a power of 2 */
> if (alignment % 2 == 1)
> return NULL;
>
> That's not a "power" of two, that's a "multiple" of 2. What did they really
> mean?? I assume they meant multiple... but that's not what the code is
> doing.
There are only 2 commits in that file between rc1 and 2.0; one is code
formatting, the other is this:
https://github.com/FreeRDP/FreeRDP/issues/2039 /
https://github.com/FreeRDP/FreeRDP/pull/4961
Perhaps it will fix the problem you're seeing. Please try building with the
attached file saved in /usr/ports/x11/freerdp/patches.
$OpenBSD$
>From 71036fe0b2e3b599ba67340fb0e66daee29a4975 Mon Sep 17 00:00:00 2001
From: Armin Novak
Date: Wed, 24 Oct 2018 10:59:54 +0200
Subject: [PATCH] Fixed #2039: Check for overflow in calculations.
Index: winpr/libwinpr/crt/alignment.c
--- winpr/libwinpr/crt/alignment.c.orig
+++ winpr/libwinpr/crt/alignment.c
@@ -27,6 +27,9 @@
#ifndef _WIN32
+#include
+#include
+
#define WINPR_ALIGNED_MEM_SIGNATURE0x0BA0BAB
#define WINPR_ALIGNED_MEM_STRUCT_FROM_PTR(_memptr) \
@@ -70,6 +73,8 @@ void* _aligned_recalloc(void* memblock, size_t num, si
void* _aligned_offset_malloc(size_t size, size_t alignment, size_t offset)
{
+ size_t header, alignsize;
+ uintptr_t basesize;
void* base;
void* memblock;
WINPR_ALIGNED_MEM* pMem;
@@ -86,13 +91,31 @@ void* _aligned_offset_malloc(size_t size, size_t align
if (alignment < sizeof(void*))
alignment = sizeof(void*);
+ if (alignment > SIZE_MAX - sizeof(WINPR_ALIGNED_MEM))
+ return NULL;
+
+ header = sizeof(WINPR_ALIGNED_MEM) + alignment;
+
+ if (size > SIZE_MAX - header)
+ return NULL;
+
+ alignsize = size + header;
/* malloc size + alignment to make sure we can align afterwards */
- base = malloc(size + alignment + sizeof(WINPR_ALIGNED_MEM));
+ base = malloc(alignsize);
if (!base)
return NULL;
- memblock = (void*)size_t)(((BYTE*) base) + alignment + offset +
sizeof(WINPR_ALIGNED_MEM)) & ~(alignment - 1)) - offset));
+ basesize = (uintptr_t)base;
+
+ if ((offset > UINTPTR_MAX) || (header > UINTPTR_MAX - offset) ||
+ (basesize > UINTPTR_MAX - header - offset))
+ {
+ free(base);
+ return NULL;
+ }
+
+ memblock = (void*)(((basesize + header + offset) & ~(alignment - 1)) -
offset);
pMem = WINPR_ALIGNED_MEM_STRUCT_FROM_PTR(memblock);
pMem->sig = WINPR_ALIGNED_MEM_SIGNATURE;
pMem->base_addr = base;
@@ -111,6 +134,7 @@ void* _aligned_offset_realloc(void* memblock, size_t s
return _aligned_offset_malloc(size, alignment, offset);
pMem = WINPR_ALIGNED_MEM_STRUCT_FROM_PTR(memblock);
+
if (pMem->sig != WINPR_ALIGNED_MEM_SIGNATURE)
{
WLog_ERR(TAG, "_aligned_offset_realloc: memory block was not
allocated by _aligned_malloc!");
@@ -124,18 +148,19 @@ void* _aligned_offset_realloc(void* memblock, size_t s
}
newMemblock = _aligned_offset_malloc(size, alignment, offset);
+
if (!newMemblock)
return NULL;
pNewMem = WINPR_ALIGNED_MEM_STRUCT_FROM_PTR(newMemblock);
-
copySize = (pNewMem->size < pMem->size) ? pNewMem->size : pMem->size;
Re: CVS: cvs.openbsd.org: ports
On 2020/04/19 09:38, Stuart Henderson wrote: > CVSROOT: /cvs > Module name: ports > Changes by: st...@cvs.openbsd.org 2020/04/19 09:38:58 > > Modified files: > net/isc-bind : Makefile > > Log message: > isc-bind: remove obsolote CONFIGURE_ARGS (noop; they were ignored anyway). > From Claus Assmann. > ok jca
Re: net/isc-bind: configure: WARNING: unrecognized options?
On 2020/04/19 11:06, Claus Assmann wrote: > I'm probably doing something wrong, but just in case: > these warnings where displayed when I ran > make > in ports/net/isc-bind/ > > configure: WARNING: unrecognized options: --enable-filter-, > --enable-threads, --with-randomdev, --disable-silent-rules, --disable-gtk-doc > > Maybe those options are used to build other versions of ISC bind? > Below is a trivial patch to remove those options in the list which > are in Makefile: Thanks, committed. The options were removed upstream; > - --enable-filter- \ this is now built by default as a plugin filter > - --enable-threads \ not sure when this was removed, possibly with the move to libuv, though it was on by default prior to removal anyway > - --with-randomdev=/dev/random \ RAND_bytes is used instead now
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/19 09:38:58 Modified files: net/isc-bind : Makefile Log message: isc-bind: remove obsolote CONFIGURE_ARGS (noop; they were ignored anyway). >From Claus Assmann.
NEW: sysutils/packer-vmm
Dear all, Please find sysutils/packer-vmm, a vmm(4) builder plugiun for HashiCorp Packer attached. Upstream maintainer, Philipp Buehler is OK for me taking maintainership. OK to import? -- With best regards, Pavel Korovin packer-vmm.tar.gz Description: Binary data
[UPDATE] games/ezquake 3.2
Hi,
Attached is a diff to update ezquake to v3.2 which was released today
the 19th of April 2020.
I had to change the Makefile to use the github tag since no release
tarball was available.
Builds and runs on my machine (amd64) and I played both single
player and connected to a multiplayer server (using games/mvdsv).
Thanks,
Tom
Index: Makefile
===
RCS file: /cvs/ports/games/ezquake/Makefile,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 Makefile
--- Makefile12 Jul 2019 20:46:17 - 1.7
+++ Makefile19 Apr 2020 14:57:19 -
@@ -1,11 +1,15 @@
# $OpenBSD: Makefile,v 1.7 2019/07/12 20:46:17 sthen Exp $
-V =3.1
+N =ezquake
+V =3.2
COMMENT = modern QuakeWorld client
-DISTNAME = ezquake-source-${V}
-PKGNAME = ezquake-${V}
+
+PKGNAME = ${N}-${V}
+GH_ACCOUNT = ezQuake
+GH_PROJECT = ${N}-source
+GH_TAGNAME = ${V}
+
CATEGORIES = games
-REVISION = 3
HOMEPAGE = https://ezquake.github.io/
MAINTAINER = Tom Murphy
@@ -16,8 +20,6 @@ PERMIT_PACKAGE = Yes
WANTLIB += GL SDL2 c curl expat jansson jpeg m pcre png pthread
WANTLIB += speex speexdsp z
-MASTER_SITES =
https://github.com/ezQuake/ezquake-source/releases/download/${V}/
-
LIB_DEPENDS = audio/speex \
graphics/jpeg \
graphics/png \
@@ -28,7 +30,6 @@ LIB_DEPENDS = audio/speex \
USE_GMAKE =Yes
MAKE_ENV = V=1
-WRKDIST = ${WRKDIR}
NO_TEST = Yes
Index: distinfo
===
RCS file: /cvs/ports/games/ezquake/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo15 Sep 2018 18:54:54 - 1.3
+++ distinfo19 Apr 2020 14:57:19 -
@@ -1,2 +1,2 @@
-SHA256 (ezquake-source-3.1.tar.gz) =
NGW6FyAXOzBOoppVfO6KFl9tUe7GgNoMqsnST4iqko4=
-SIZE (ezquake-source-3.1.tar.gz) = 3613947
+SHA256 (ezquake-source-3.2.tar.gz) =
gBFR1UBwYQbL0m2nJmql4zCEK4zMvFrNS8jVpz2zUV0=
+SIZE (ezquake-source-3.2.tar.gz) = 5758861
Index: patches/patch-Makefile
===
RCS file: /cvs/ports/games/ezquake/patches/patch-Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 patch-Makefile
--- patches/patch-Makefile 15 Aug 2018 22:15:02 - 1.1.1.1
+++ patches/patch-Makefile 19 Apr 2020 14:57:19 -
@@ -5,7 +5,7 @@ Skip the architecture dance.
Index: Makefile
--- Makefile.orig
+++ Makefile
-@@ -388,7 +388,7 @@ endif
+@@ -379,7 +379,7 @@ endif
ifdef CONFIG_WINDOWS
TARG_c := ezquake.exe
else
Re: FreeRDP 2.0.0 released April 9, 2020
On Sun, Apr 19 2020, Steve Williams wrote:
> On 19/04/2020 12:20 a.m., Landry Breuil wrote:
>> On Sun, Apr 19, 2020 at 07:59:04AM +0200, Landry Breuil wrote:
>>> On Sat, Apr 18, 2020 at 11:29:11PM -0600, Steve Williams wrote:
Hi,
OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020
I am working on trying to get Apache Guacamole working (I've got it
compiling) to provide RDP and SSH access to my home network. I have the
ssh
access working, but Guacamole (guacd) is dumping a core in freerdp
(freerdp-2.0.0rc1p4). Based on the stack trace, I am assuming an issue
with the more strict malloc that OpenBSD uses. I checked and see that a
final release of FreeRDP (2.0.0) was made available April 9, 2020.
Is anyone working on porting the new version of FreeRDP? I could not see a
"MAINTAINER" in the Makefile.
>>> Newer versions of freerdp needs some methods not available on OpenBSD,
>>> check
>>> http://openbsd-archive.7691.n7.nabble.com/x11-freerdp-update-to-2-0-0-rc4-td360502.html#a360567
>>> and https://marc.info/?t=15248249265=1=2 and
>>> https://github.com/FreeRDP/FreeRDP/issues/4592.
>> there's a comment about it in the port Makefile:
>>
>>
>> # XXX This version has known security issues.
>>
>> # XXX Can't be updated without either timer_create() and friends or
>> # an alternative timer implementation (as was done for OSX)
>>
>>
I've been using OpenBSD since version 2.7 and am a C programmer of 30+
years.
>>> glad if you can help on this then ! build a debug package for the port
>>> to have proper symbols for the backtrace..
>> more details on this after i've actually looked - its a cmake port which
>> doesnt always cope well yet with our DEBUG_PACKAGES framework, you can try
>> with
>> DEBUG_PACKAGES=${BUILD_PACKAGES} which will give you this:
>>
>> Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new
>> Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/PLIST
>> Renaming /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new
>> to Makefile
>>> Extracting debug info from
>>> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-hash
>>> Extracting debug info from
>>> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-makecert
>>> Extracting debug info from
>>> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/xfreerdp
>>> Extracting debug info from
>>> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp-client2.so.0.0
>>> Extracting debug info from
>>> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp2.so.0.0
>>> Extracting debug info from
>>> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr-tools2.so.0.0
>>> Extracting debug info from
>>> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr2.so.0.0
>> Create /usr/ports/packages/amd64/all/freerdp-2.0.0rc1p4.tgz
>> Creating package freerdp-2.0.0rc1p4
>> Creating package debug-freerdp-2.0.0rc1p4
>> Link to /usr/ports/packages/amd64/ftp/freerdp-2.0.0rc1p4.tgz
>> Link to /usr/ports/packages/amd64/ftp/debug-freerdp-2.0.0rc1p4.tgz
>>
>> and then install the debug-freerdp package & check if gdb find syms.
>>
>> Tried it here and it doesnt seem to help (blame cmake that forcefully strips
>> syms when CMAKE_BUILD_TYPE=Release...):
>>
>> nikki:~/ $egdb /usr/local/bin/xfreerdp
>> Reading symbols from /usr/local/bin/xfreerdp...(no debugging symbols
>> found)...done.
>>
>> Another option worth a try, you can locally add
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo to CONFIGURE_ARGS to build a local package
>> with debug symbols enabled via cmake. Might work.
>>
>> Landry
>
>
> Hi,
>
> Thanks for the fast replies :)
>
> TL;DR
>
> I am missing something on building the Debug packages. I modified the
> Makefile per your other email thread but there must be more magic as
> I don't see any of the output pertaining to "Extracting debug info..."
DEBUG_PACKAGES is supported on -current which will become the 6.7
release. Setting this variable does nothing on 6.6.
> Details:
>
> It is a bit disappointing that the newer version of freerdp needs
> significant work to have it functional in OpenBSD. I had a look at the
> Apple code for the timers... the whole timers file. Not very pleasant
> with all the #ifdef's all over the place. I am sure greater minds than
> mine have looked at what it would take to have it working in OpenBSD.
>
> I guess that leaves debugging the existing code. I started by comparing
> the 2.0rc1 /winpr/libwinpr/crt/alignment.c with the version in 2.0 and
> there have been quite a few changes. It seems most of them are for
> clarity of code, but hidden in the changes must be some alignment
> challenges. Lots of math going on... and a few confusing comments.
>
> For example:
> /* alignment must be a power of 2 */
> if (alignment % 2 == 1)
> return NULL;
>
> That's not a "power" of two, that's a "multiple"
Re: FreeRDP 2.0.0 released April 9, 2020
On Sun, Apr 19, 2020 at 09:17:15AM -0600, Steve Williams wrote:
>
>
> On 19/04/2020 12:20 a.m., Landry Breuil wrote:
> > On Sun, Apr 19, 2020 at 07:59:04AM +0200, Landry Breuil wrote:
> > > On Sat, Apr 18, 2020 at 11:29:11PM -0600, Steve Williams wrote:
> > > > Hi,
> > > >
> > > > OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020
> > > >
> > > > I am working on trying to get Apache Guacamole working (I've got it
> > > > compiling) to provide RDP and SSH access to my home network. I have
> > > > the ssh
> > > > access working, but Guacamole (guacd) is dumping a core in freerdp
> > > > (freerdp-2.0.0rc1p4). Based on the stack trace, I am assuming an issue
> > > > with the more strict malloc that OpenBSD uses. I checked and see that a
> > > > final release of FreeRDP (2.0.0) was made available April 9, 2020.
> > > >
> > > > Is anyone working on porting the new version of FreeRDP? I could not
> > > > see a
> > > > "MAINTAINER" in the Makefile.
> > > Newer versions of freerdp needs some methods not available on OpenBSD,
> > > check
> > > http://openbsd-archive.7691.n7.nabble.com/x11-freerdp-update-to-2-0-0-rc4-td360502.html#a360567
> > > and https://marc.info/?t=15248249265=1=2 and
> > > https://github.com/FreeRDP/FreeRDP/issues/4592.
> > there's a comment about it in the port Makefile:
> >
> >
> > # XXX This version has known security issues.
> >
> > # XXX Can't be updated without either timer_create() and friends or
> > # an alternative timer implementation (as was done for OSX)
> >
> >
> > > > I've been using OpenBSD since version 2.7 and am a C programmer of 30+
> > > > years.
> > > glad if you can help on this then ! build a debug package for the port
> > > to have proper symbols for the backtrace..
> > more details on this after i've actually looked - its a cmake port which
> > doesnt always cope well yet with our DEBUG_PACKAGES framework, you can try
> > with
> > DEBUG_PACKAGES=${BUILD_PACKAGES} which will give you this:
> >
> > Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new
> > Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/PLIST
> > Renaming /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new
> > to Makefile
> > > Extracting debug info from
> > > /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-hash
> > > Extracting debug info from
> > > /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-makecert
> > > Extracting debug info from
> > > /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/xfreerdp
> > > Extracting debug info from
> > > /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp-client2.so.0.0
> > > Extracting debug info from
> > > /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp2.so.0.0
> > > Extracting debug info from
> > > /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr-tools2.so.0.0
> > > Extracting debug info from
> > > /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr2.so.0.0
> > Create /usr/ports/packages/amd64/all/freerdp-2.0.0rc1p4.tgz
> > Creating package freerdp-2.0.0rc1p4
> > Creating package debug-freerdp-2.0.0rc1p4
> > Link to /usr/ports/packages/amd64/ftp/freerdp-2.0.0rc1p4.tgz
> > Link to /usr/ports/packages/amd64/ftp/debug-freerdp-2.0.0rc1p4.tgz
> >
> > and then install the debug-freerdp package & check if gdb find syms.
> >
> > Tried it here and it doesnt seem to help (blame cmake that forcefully
> > strips syms when CMAKE_BUILD_TYPE=Release...):
> >
> > nikki:~/ $egdb /usr/local/bin/xfreerdp
> > Reading symbols from /usr/local/bin/xfreerdp...(no debugging symbols
> > found)...done.
> >
> > Another option worth a try, you can locally add
> > -DCMAKE_BUILD_TYPE=RelWithDebInfo to CONFIGURE_ARGS to build a local package
> > with debug symbols enabled via cmake. Might work.
> >
> > Landry
>
>
> Hi,
>
> Thanks for the fast replies :)
>
> TL;DR
>
> I am missing something on building the Debug packages. I modified the
> Makefile per your other email thread but there must be more magic as I don't
> see any of the output pertaining to "Extracting debug info..."
That is only in -current, where development happens :)
> What magic do I need to build freerdp-2.0.0rc1 with debugging symbols?
Using -current ..
> Also, in your response, it shows you using "egdb". Is this something
> different than gdb? I couldn't find it anywhere...
that's gdb from ports which is more recent (and useful) than the one in base.
Landry
Re: FreeRDP 2.0.0 released April 9, 2020
On 19/04/2020 12:20 a.m., Landry Breuil wrote:
On Sun, Apr 19, 2020 at 07:59:04AM +0200, Landry Breuil wrote:
On Sat, Apr 18, 2020 at 11:29:11PM -0600, Steve Williams wrote:
Hi,
OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020
I am working on trying to get Apache Guacamole working (I've got it
compiling) to provide RDP and SSH access to my home network. I have the ssh
access working, but Guacamole (guacd) is dumping a core in freerdp
(freerdp-2.0.0rc1p4). Based on the stack trace, I am assuming an issue
with the more strict malloc that OpenBSD uses. I checked and see that a
final release of FreeRDP (2.0.0) was made available April 9, 2020.
Is anyone working on porting the new version of FreeRDP? I could not see a
"MAINTAINER" in the Makefile.
Newer versions of freerdp needs some methods not available on OpenBSD,
check
http://openbsd-archive.7691.n7.nabble.com/x11-freerdp-update-to-2-0-0-rc4-td360502.html#a360567
and https://marc.info/?t=15248249265=1=2 and
https://github.com/FreeRDP/FreeRDP/issues/4592.
there's a comment about it in the port Makefile:
# XXX This version has known security issues.
# XXX Can't be updated without either timer_create() and friends or
# an alternative timer implementation (as was done for OSX)
I've been using OpenBSD since version 2.7 and am a C programmer of 30+
years.
glad if you can help on this then ! build a debug package for the port
to have proper symbols for the backtrace..
more details on this after i've actually looked - its a cmake port which
doesnt always cope well yet with our DEBUG_PACKAGES framework, you can try with
DEBUG_PACKAGES=${BUILD_PACKAGES} which will give you this:
Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new
Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/PLIST
Renaming /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new to
Makefile
Extracting debug info from
/usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-hash
Extracting debug info from
/usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-makecert
Extracting debug info from
/usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/xfreerdp
Extracting debug info from
/usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp-client2.so.0.0
Extracting debug info from
/usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp2.so.0.0
Extracting debug info from
/usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr-tools2.so.0.0
Extracting debug info from
/usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr2.so.0.0
Create /usr/ports/packages/amd64/all/freerdp-2.0.0rc1p4.tgz
Creating package freerdp-2.0.0rc1p4
Creating package debug-freerdp-2.0.0rc1p4
Link to /usr/ports/packages/amd64/ftp/freerdp-2.0.0rc1p4.tgz
Link to /usr/ports/packages/amd64/ftp/debug-freerdp-2.0.0rc1p4.tgz
and then install the debug-freerdp package & check if gdb find syms.
Tried it here and it doesnt seem to help (blame cmake that forcefully strips
syms when CMAKE_BUILD_TYPE=Release...):
nikki:~/ $egdb /usr/local/bin/xfreerdp
Reading symbols from /usr/local/bin/xfreerdp...(no debugging symbols
found)...done.
Another option worth a try, you can locally add
-DCMAKE_BUILD_TYPE=RelWithDebInfo to CONFIGURE_ARGS to build a local package
with debug symbols enabled via cmake. Might work.
Landry
Hi,
Thanks for the fast replies :)
TL;DR
I am missing something on building the Debug packages. I modified the
Makefile per your other email thread but there must be more magic as I
don't see any of the output pertaining to "Extracting debug info..."
Details:
It is a bit disappointing that the newer version of freerdp needs
significant work to have it functional in OpenBSD. I had a look at the
Apple code for the timers... the whole timers file. Not very pleasant
with all the #ifdef's all over the place. I am sure greater minds than
mine have looked at what it would take to have it working in OpenBSD.
I guess that leaves debugging the existing code. I started by comparing
the 2.0rc1 /winpr/libwinpr/crt/alignment.c with the version in 2.0 and
there have been quite a few changes. It seems most of them are for
clarity of code, but hidden in the changes must be some alignment
challenges. Lots of math going on... and a few confusing comments.
For example:
/* alignment must be a power of 2 */
if (alignment % 2 == 1)
return NULL;
That's not a "power" of two, that's a "multiple" of 2. What did they
really mean?? I assume they meant multiple... but that's not what the
code is doing.
Regardless...
What magic do I need to build freerdp-2.0.0rc1 with debugging symbols?
Also, in your response, it shows you using "egdb". Is this something
different than gdb? I couldn't find it anywhere...
Thanks,
Steve W.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/04/19 09:12:23 Modified files: textproc/pdftk : Makefile distinfo Log message: update to pdftk-3.0.10
[macppc] emulators/qemu: fix build, runtime is BROKEN
Hi, qemu build failed in the current macppc bulk with: > tcg-target.inc.c:2290:3: error: "Unhandled abi" > # error "Unhandled abi" It appears that the impacted code uses the _CALL_SYSV define that clang does not provide. The below diff fixes that. The runtime is broken, it segfaults when starting every qemu-system-* command. I'm attaching a backtrace built with -02 because qemu works with -O0. Charlène. Index: patches/patch-tcg_ppc_tcg-target_inc_c === RCS file: patches/patch-tcg_ppc_tcg-target_inc_c diff -N patches/patch-tcg_ppc_tcg-target_inc_c --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-tcg_ppc_tcg-target_inc_c 19 Apr 2020 14:57:22 - @@ -0,0 +1,19 @@ +$OpenBSD$ + +Workaround the lack of _CALL_SYSV with clang on powerpc + +Index: tcg/ppc/tcg-target.inc.c +--- tcg/ppc/tcg-target.inc.c.orig tcg/ppc/tcg-target.inc.c +@@ -25,6 +25,11 @@ + #include "elf.h" + #include "tcg-pool.inc.c" + ++/* clang on OpenBSD does not define _CALL_* */ ++#if defined __clang__ && defined __OpenBSD__ ++#define _CALL_SYSV 1 ++#endif ++ + #if defined _CALL_DARWIN || defined __APPLE__ + #define TCG_TARGET_CALL_DARWIN + #endif gdb.qemu.txt Description: Binary data
Re: opensmtpd-extras -main & python 2.7
works for me, but I'm only using the -main package and only the passwd
table from that.
Thanks,
Florian
On Sat, Apr 18, 2020 at 10:21:29PM +0200, Giovanni Bechis wrote:
> On Sat, Apr 18, 2020 at 01:38:20AM +0200, Klemens Nanni wrote:
> > On Sat, Apr 18, 2020 at 01:34:47AM +0200, Joerg Jung wrote:
> > > thanks, but please hold-off for a second, as giovanni is already going
> > > to commit a diff to upgrade to latest release 6.7.0 better he merges
> > > the line then into his diff instead of the revision bumps, I believe ...
> > Go ahead with whatever seems fit; I don't use this port, just wanted to
> > help out florian.
> >
> diff to 6.7.1 with kn@ fix.
> ok ?
> Cheers
> Giovanni
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/mail/opensmtpd-extras/Makefile,v
> retrieving revision 1.32
> diff -u -p -r1.32 Makefile
> --- Makefile 26 Dec 2019 11:19:28 - 1.32
> +++ Makefile 18 Apr 2020 20:19:21 -
> @@ -6,14 +6,13 @@ COMMENT-pgsql= postgresql based smtpd t
> COMMENT-python= extras with python bindings for smtpd
> COMMENT-redis= redis based smtpd table support
>
> -V= 6.6.0
> +V= 6.7.1
> DISTNAME=opensmtpd-extras-${V}
> PKGNAME-main=${DISTNAME}
> PKGNAME-mysql= opensmtpd-extras-mysql-${V}
> PKGNAME-pgsql= opensmtpd-extras-pgsql-${V}
> PKGNAME-python= opensmtpd-extras-python-${V}
> PKGNAME-redis= opensmtpd-extras-redis-${V}
> -REVISION=2
> EPOCH= 0
>
> CATEGORIES= mail
> @@ -36,9 +35,8 @@ WANTLIB-redis= c crypto event ssl hired
>
> MASTER_SITES=${HOMEPAGE}archives/
>
> -WRKSRC= ${WRKDIR}/OpenSMTPD-extras-${V}
> -
> MODULES= lang/python
> +MODPY_RUNDEP=no
>
> LIB_DEPENDS-main=databases/sqlite3
> LIB_DEPENDS-mysql= databases/mariadb,-main
> Index: distinfo
> ===
> RCS file: /cvs/ports/mail/opensmtpd-extras/distinfo,v
> retrieving revision 1.17
> diff -u -p -r1.17 distinfo
> --- distinfo 22 Dec 2019 12:19:20 - 1.17
> +++ distinfo 18 Apr 2020 20:19:21 -
> @@ -1,2 +1,2 @@
> -SHA256 (opensmtpd-extras-6.6.0.tar.gz) =
> EmsCNgLouyIr8kVDoFbuClSDQ9yG0YRmn/nYLfyh+98=
> -SIZE (opensmtpd-extras-6.6.0.tar.gz) = 124234
> +SHA256 (opensmtpd-extras-6.7.1.tar.gz) =
> +EOFVZqLs2ay/iXYsfeMEI8HzBWZI1AXFWnXvcLpNaw=
> +SIZE (opensmtpd-extras-6.7.1.tar.gz) = 548792
--
I'm not entirely sure you are real.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2020/04/19 08:37:41 Modified files: sysutils/raspberrypi-firmware: Makefile distinfo sysutils/raspberrypi-firmware/pkg: PLIST Log message: update to 1.20200212
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/04/19 06:44:22 Modified files: mail/kopano: Makefile.inc mail/kopano/core: distinfo mail/kopano/core/patches: patch-Makefile_am patch-common_include_kopano_platform_linux_h Log message: update to 10.0.4
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/04/19 06:43:43 Modified files: sysutils/htop : Makefile Added files: sysutils/htop/patches: patch-htop_c Log message: fix a crash while using the -s option; the -s option requires an argument to be passed so add a leading : to getopt_long()
Re: update: gnupg2 -> 2.2.20
Bumping in case this was missed.
Was hoping this could be added for the 6.7 release.
aisha
On 4/10/20 7:23 AM, Aisha Tammy wrote:
> readding the diff, because my thunderbird was wrapping messages by default.
>
> thanks again.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/security/gnupg2/Makefile,v
> retrieving revision 1.66
> diff -u -p -r1.66 Makefile
> --- Makefile 12 Jul 2019 21:15:35 - 1.66
> +++ Makefile 10 Apr 2020 11:22:22 -
> @@ -2,7 +2,7 @@
>
> COMMENT =GNU privacy guard - a free PGP replacement
>
> -DISTNAME = gnupg-2.2.12
> +DISTNAME = gnupg-2.2.20
> CATEGORIES = security
> REVISION = 0
>
> @@ -55,6 +55,7 @@ CONFIGURE_STYLE = gnu
> CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include" \
> LDFLAGS="-L${LOCALBASE}/lib"
> CONFIGURE_ARGS +=docdir=${LOCALBASE}/share/doc/gnupg2 \
> + --with-mailprog="/usr/sbin/sendmail" \
> --enable-gpgtar \
> --enable-wks-tools \
> --enable-gpg-is-gpg2
> Index: distinfo
> ===
> RCS file: /cvs/ports/security/gnupg2/distinfo,v
> retrieving revision 1.31
> diff -u -p -r1.31 distinfo
> --- distinfo 22 Dec 2018 17:49:21 - 1.31
> +++ distinfo 10 Apr 2020 11:22:22 -
> @@ -1,2 +1,2 @@
> -SHA256 (gnupg-2.2.12.tar.bz2) = 2wMPi0yYZA6RMA021Rbx9Pj+CVFKlOqfx0Ee4aNAgss=
> -SIZE (gnupg-2.2.12.tar.bz2) = 6682303
> +SHA256 (gnupg-2.2.20.tar.bz2) = BKfJ1It0w5kWjugnDlSFiN2+UiGMM3cD1/Bjc9MmyjA=
> +SIZE (gnupg-2.2.20.tar.bz2) = 6786913
> Index: patches/patch-doc_Makefile_in
> ===
> RCS file: /cvs/ports/security/gnupg2/patches/patch-doc_Makefile_in,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-doc_Makefile_in
> --- patches/patch-doc_Makefile_in 20 Aug 2017 11:52:38 - 1.2
> +++ patches/patch-doc_Makefile_in 10 Apr 2020 11:22:22 -
> @@ -2,7 +2,7 @@ $OpenBSD: patch-doc_Makefile_in,v 1.2 20
> Index: doc/Makefile.in
> --- doc/Makefile.in.orig
> +++ doc/Makefile.in
> -@@ -462,14 +462,6 @@ libcommontls = ../common/libcommontls.a
> +@@ -474,14 +474,6 @@ libcommontls = ../common/libcommontls.a
> libcommontlsnpth = ../common/libcommontlsnpth.a
> examples = examples/README examples/scd-event examples/trustlist.txt
> \
> examples/vsnfd.prf examples/debug.prf\
> Index: patches/patch-tools_send-mail_c
> ===
> RCS file: patches/patch-tools_send-mail_c
> diff -N patches/patch-tools_send-mail_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-tools_send-mail_c 10 Apr 2020 11:22:22 -
> @@ -0,0 +1,16 @@
> +$OpenBSD: patch-doc_Makefile_in,v 1.2 2020/04/09 13:40:29 aisha Exp $
> +
> +use the sendmail option from the command line
> +
> +Index: tools/send-mail.c
> +--- tools/send-mail.c.orig
> tools/send-mail.c
> +@@ -33,7 +33,7 @@ static gpg_error_t
> + run_sendmail (estream_t data)
> + {
> + gpg_error_t err;
> +- const char pgmname[] = "/usr/lib/sendmail";
> ++ const char pgmname[] = "/usr/sbin/sendmail";
> + const char *argv[3];
> +
> + argv[0] = "-oi";
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/04/19 05:14:13 Modified files: net/gnugk : Makefile Log message: --disable-mqtt to prevent picking up net/mosquitto reported by jca@
Re: update: games/openttd
On Sun, 19 Apr 2020, Solène Rapenne wrote: > Hello, > > Thank you for your update although I updated it one hour ago :-) Did not see your commit, sorry. -- Paco Esteban. 0x5818130B8A6DBC03
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2020/04/19 03:59:45 Modified files: devel/got : Makefile distinfo Log message: update to got 0.34 - make use of new convenience API functions of kcgi 0.12 in gotweb - make 'got update' skip conflicted files (prevents loss of local changes) - show a summary of conflicts and related problems after updating/merging files - add 'got log' -x option to stop logging when a specific commit was traversed - add 'got log' -R option to reverse commit display order - clarify wording in got.1 related to local changes/commits/branches - show bad object ID in "object not found" error messages where possible
Re: update: games/openttd
Le 2020-04-19 11:30, Paco Esteban a écrit : Hi ports@, This is a simple update to games/openttd. They released a bugfix release recently. Here is the changelog: https://cdn.openttd.org/openttd-releases/1.10.1/changelog.txt CCing maintainer. Builds and works ok for me on amd64. I haven't played much, so it would be nice if more regular users of this game could take a look. Index: Makefile === RCS file: /home/cvs/ports/games/openttd/Makefile,v retrieving revision 1.67 diff -u -p -r1.67 Makefile --- Makefile7 Apr 2020 15:13:34 - 1.67 +++ Makefile18 Apr 2020 08:08:34 - @@ -2,7 +2,7 @@ COMMENT= open source clone of the game Transport Tycoon Deluxe -V =1.10.0 +V =1.10.1 DISTNAME = openttd-$V-source PKGNAME = openttd-$V Index: distinfo === RCS file: /home/cvs/ports/games/openttd/distinfo,v retrieving revision 1.34 diff -u -p -r1.34 distinfo --- distinfo7 Apr 2020 15:13:34 - 1.34 +++ distinfo18 Apr 2020 08:08:43 - @@ -1,2 +1,2 @@ -SHA256 (openttd/openttd-1.10.0-source.tar.xz) = G6IarJod6Ysj+A/ulStLnF4tPMSsGH9SA3MIJrPw4lM= -SIZE (openttd/openttd-1.10.0-source.tar.xz) = 6801228 +SHA256 (openttd/openttd-1.10.1-source.tar.xz) = DSKjxQ96Mh9PIRWU9Jh6wWw4Ho4+QPEWhI5j6R5/u5s= +SIZE (openttd/openttd-1.10.1-source.tar.xz) = 6741548 Hello, Thank you for your update although I updated it one hour ago :-)
update: games/openttd
Hi ports@, This is a simple update to games/openttd. They released a bugfix release recently. Here is the changelog: https://cdn.openttd.org/openttd-releases/1.10.1/changelog.txt CCing maintainer. Builds and works ok for me on amd64. I haven't played much, so it would be nice if more regular users of this game could take a look. Index: Makefile === RCS file: /home/cvs/ports/games/openttd/Makefile,v retrieving revision 1.67 diff -u -p -r1.67 Makefile --- Makefile7 Apr 2020 15:13:34 - 1.67 +++ Makefile18 Apr 2020 08:08:34 - @@ -2,7 +2,7 @@ COMMENT= open source clone of the game Transport Tycoon Deluxe -V =1.10.0 +V =1.10.1 DISTNAME = openttd-$V-source PKGNAME = openttd-$V Index: distinfo === RCS file: /home/cvs/ports/games/openttd/distinfo,v retrieving revision 1.34 diff -u -p -r1.34 distinfo --- distinfo7 Apr 2020 15:13:34 - 1.34 +++ distinfo18 Apr 2020 08:08:43 - @@ -1,2 +1,2 @@ -SHA256 (openttd/openttd-1.10.0-source.tar.xz) = G6IarJod6Ysj+A/ulStLnF4tPMSsGH9SA3MIJrPw4lM= -SIZE (openttd/openttd-1.10.0-source.tar.xz) = 6801228 +SHA256 (openttd/openttd-1.10.1-source.tar.xz) = DSKjxQ96Mh9PIRWU9Jh6wWw4Ho4+QPEWhI5j6R5/u5s= +SIZE (openttd/openttd-1.10.1-source.tar.xz) = 6741548 -- Paco Esteban. 0x5818130B8A6DBC03
net/isc-bind: configure: WARNING: unrecognized options?
I'm probably doing something wrong, but just in case: these warnings where displayed when I ran make in ports/net/isc-bind/ configure: WARNING: unrecognized options: --enable-filter-, --enable-threads, --with-randomdev, --disable-silent-rules, --disable-gtk-doc Maybe those options are used to build other versions of ISC bind? Below is a trivial patch to remove those options in the list which are in Makefile: Index: Makefile === RCS file: /home/cvs/ports/net/isc-bind/Makefile,v retrieving revision 1.115 diff -u -r1.115 Makefile --- Makefile15 Apr 2020 18:41:07 - 1.115 +++ Makefile19 Apr 2020 09:00:08 - @@ -52,10 +52,7 @@ CONFIGURE_STYLE= autoconf AUTOCONF_VERSION= 2.69 CONFIGURE_ARGS=--enable-full-report \ - --enable-filter- \ - --enable-threads \ --with-libtool \ - --with-randomdev=/dev/random \ --with-libidn2 \ --without-lmdb \ --without-readline \ -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sol...@cvs.openbsd.org 2020/04/19 02:24:33 Modified files: games/openttd : Makefile distinfo Log message: Update to openttd-1.10.1 this is little bugfix release ok maintainer bentley@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/04/19 02:13:59 Modified files: productivity/davical: Makefile distinfo productivity/davical/pkg: PLIST Log message: Update to davical 1.1.9.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/04/19 02:13:19 Modified files: www/awl: Makefile distinfo Log message: update to php-awl 0.61
Re: cmake and DEBUG_PACKAGES
Nice overview Landry, thanks!
I took a look at it too. I think the problem for us is how cmake
ninja/make builds.
We can read for ninja and Unix makefiles install step:
"Runs the install step in the subdirectory followed by a CMAKE_STRIP
command, if any. The CMAKE_STRIP variable will contain the platform’s
strip utility, which removes symbols information from generated
binaries."
https://cmake.org/cmake/help/v3.17/generator/Unix%20Makefiles.html?highlight=cmake_strip
https://cmake.org/cmake/help/v3.17/generator/Ninja.html?highlight=cmake_strip
For me, that means, if we run "make fake" we trigger install witch
trigger the strip job.
I already started[1] to avoid using ninja/make for all generated targets
(build, install, test and so one) because cmake(1) can do it for use:
https://cmake.org/cmake/help/v3.17/manual/cmake.1.html
It looks to me like it doesn't strip automatically because there's a
knob for it: --strip
https://cmake.org/cmake/help/v3.17/manual/cmake.1.html#install-a-project
[1]:
https://github.com/sizeofvoid/wip-ports/commit/b8da77ca08387c70e0a3efaa1ba5b3c7ad44236
More comments below:
On Sun Apr 19, 2020 at 09:07:10AM +0200, Landry Breuil wrote:
> Hi,
>
> i've had a look at why cmake insists on striping libs/binaries (even if
> it seems upstream states it isnt the case by default.. no 100% sure
> about this statment), rendering our DEBUG_PACKAGES framework useless for
> (some?) cmake ports. CMAKE_BUILD_TYPE=RelWithDebInfo doesnt really work
> as it produces different binaries, and it would be great to have a
> 'generic' solution that would work for all cmake ports.
>
> after looking at the cmake code there are two things/knobs:
> CMAKE_INSTALL_DO_STRIP seem to control which sub makefile is called, but
> upstream wants to hide it from the API:
> https://gitlab.kitware.com/cmake/cmake/commit/d5b722bbbd684477e8b8a979ba62a2f1b45a720c
>
> CMAKE_STRIP is the path to the strip utility, looked for in
> https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/CMakeFindBinUtils.cmake#L113
>
> the 'interesting' generator bits are here:
> https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmGlobalGenerator.cxx#L2663
> https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmInstallTargetGenerator.cxx#L785
>
> those could be patched out,i'd say 'remove the line force-adding
> -DCMAKE_INSTALL_DO_STRIP=1' but then that would affect all cmake-using
> ports, where we'd have to change more bits to actually do the striping
> somewhere else ? but first, id prefer something less invasive, using
> only user-knobs via DEBUG_CONFIGURE_ARGS.
>
> tried:
> * -DCMAKE_INSTALL_DO_STRIP=0 -> no dice, not meant as a user-visible knob:
> Manually-specified variables were not used by the project:
> CMAKE_INSTALL_DO_STRIP
There is no documentation for CMAKE_INSTALL_DO_STRIP.
>
> * -UCMAKE_STRIP to avoid cmake looking for CMAKE_STRIP -> still finds it.
I see no documentation to stop it.
>
> * -DCMAKE_STRIP=/usr/bin/true seems to be taken into account:
> /usr/obj/ports/freerdp-2.0.0rc1/build-amd64/CMakeCache.txt:CMAKE_STRIP:FILEPATH=/usr/bin/true
>
> and the resulting package seems to provide debug syms:
> [08:53] nikki:~/ $egdb /usr/local/bin/xfreerdp
> Reading symbols from /usr/local/bin/xfreerdp...Reading symbols from
> /usr/local/bin/.debug/xfreerdp.dbg...done.
>
> so it seems this:
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/freerdp/Makefile,v
> retrieving revision 1.39
> diff -u -r1.39 Makefile
> --- Makefile4 Nov 2019 10:30:20 - 1.39
> +++ Makefile19 Apr 2020 06:55:41 -
> @@ -8,6 +8,8 @@
> PKGNAME = freerdp-2.0.0rc1
> REVISION = 4
> CATEGORIES = x11 net
> +DEBUG_PACKAGES=${BUILD_PACKAGES}
> +DEBUG_CONFIGURE_ARGS+= -DCMAKE_STRIP=/usr/bin/true
>
> actually works for freerdp (but apparently, after retesting twice and
> being puzzled, without overriding CMAKE_STRIP i have a working
> debug-freerdp package). Can others check with various cmake ports that
> were reluctant to work with only DEBUG_PACKAGES set ? Should
> DEBUG_CONFIGURE_ARGS be set by default in cmake.port.mk - leaving the
> DEBUG_PACKAGES knob to be the only line added to ports Makefiles as is
> the case with autohell-based ports ?
I think C-DCMAKE_STRIP=/usr/bin/true is promising for our current
cmake-ports-env.
>
> Landry
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/04/19 01:26:24 Modified files: textproc/meld : Makefile distinfo textproc/meld/pkg: PLIST Log message: Update to meld-3.21.0.
cmake and DEBUG_PACKAGES
Hi,
i've had a look at why cmake insists on striping libs/binaries (even if
it seems upstream states it isnt the case by default.. no 100% sure
about this statment), rendering our DEBUG_PACKAGES framework useless for
(some?) cmake ports. CMAKE_BUILD_TYPE=RelWithDebInfo doesnt really work
as it produces different binaries, and it would be great to have a
'generic' solution that would work for all cmake ports.
after looking at the cmake code there are two things/knobs:
CMAKE_INSTALL_DO_STRIP seem to control which sub makefile is called, but
upstream wants to hide it from the API:
https://gitlab.kitware.com/cmake/cmake/commit/d5b722bbbd684477e8b8a979ba62a2f1b45a720c
CMAKE_STRIP is the path to the strip utility, looked for in
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/CMakeFindBinUtils.cmake#L113
the 'interesting' generator bits are here:
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmGlobalGenerator.cxx#L2663
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmInstallTargetGenerator.cxx#L785
those could be patched out,i'd say 'remove the line force-adding
-DCMAKE_INSTALL_DO_STRIP=1' but then that would affect all cmake-using
ports, where we'd have to change more bits to actually do the striping
somewhere else ? but first, id prefer something less invasive, using
only user-knobs via DEBUG_CONFIGURE_ARGS.
tried:
* -DCMAKE_INSTALL_DO_STRIP=0 -> no dice, not meant as a user-visible knob:
Manually-specified variables were not used by the project:
CMAKE_INSTALL_DO_STRIP
* -UCMAKE_STRIP to avoid cmake looking for CMAKE_STRIP -> still finds it.
* -DCMAKE_STRIP=/usr/bin/true seems to be taken into account:
/usr/obj/ports/freerdp-2.0.0rc1/build-amd64/CMakeCache.txt:CMAKE_STRIP:FILEPATH=/usr/bin/true
and the resulting package seems to provide debug syms:
[08:53] nikki:~/ $egdb /usr/local/bin/xfreerdp
Reading symbols from /usr/local/bin/xfreerdp...Reading symbols from
/usr/local/bin/.debug/xfreerdp.dbg...done.
so it seems this:
Index: Makefile
===
RCS file: /cvs/ports/x11/freerdp/Makefile,v
retrieving revision 1.39
diff -u -r1.39 Makefile
--- Makefile4 Nov 2019 10:30:20 - 1.39
+++ Makefile19 Apr 2020 06:55:41 -
@@ -8,6 +8,8 @@
PKGNAME = freerdp-2.0.0rc1
REVISION = 4
CATEGORIES = x11 net
+DEBUG_PACKAGES=${BUILD_PACKAGES}
+DEBUG_CONFIGURE_ARGS+= -DCMAKE_STRIP=/usr/bin/true
actually works for freerdp (but apparently, after retesting twice and
being puzzled, without overriding CMAKE_STRIP i have a working
debug-freerdp package). Can others check with various cmake ports that
were reluctant to work with only DEBUG_PACKAGES set ? Should
DEBUG_CONFIGURE_ARGS be set by default in cmake.port.mk - leaving the
DEBUG_PACKAGES knob to be the only line added to ports Makefiles as is
the case with autohell-based ports ?
Landry
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Thu Apr 16 05:22:11 MDT 2020 finished at Sun Apr 19 00:25:35 MDT 2020 lasted 2D19h03m done with kern.version=OpenBSD 6.7-beta (GENERIC.MP) #562: Thu Apr 16 01:22:58 MDT 2020 built packages:10892 Apr 16:3677 Apr 17:1344 Apr 18:4463 Apr 19:1407 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2020-04-16/summary.log build failures: 9 http://build-failures.rhaalovely.net/aarch64/2020-04-16/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/graphics/vulkan-loader.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/net/filezilla.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/net/gnugk.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2020-04-16/x11/e17/elementary.log recurrent failures failures/editors/xwpe.log failures/graphics/vulkan-loader.log failures/lang/pfe.log failures/net/filezilla.log failures/sysutils/nomad.log failures/sysutils/telegraf.log failures/sysutils/terragrunt.log failures/x11/e17/elementary.log new failures +++ ls-failures Sun Apr 19 00:25:45 2020 +failures/net/gnugk.log resolved failures --- ../old/aarch64/last//ls-failuresTue Apr 14 00:33:52 2020 -failures/cad/kicad-share/packages3D.log -failures/devel/sqlc.log -failures/games/burgerspace.log -failures/games/cosmosmash.log -failures/games/quadrupleback.log -failures/lang/pypy.log -failures/net/minio/client.log -failures/security/age.log -failures/security/sn0int.log -failures/shells/elvish.log -failures/sysutils/amazon-ecs-cli.log -failures/sysutils/node_exporter.log -failures/sysutils/restic.log -failures/sysutils/serf.log -failures/www/zola.log -failures/x11/tangerine-icon-theme.log
Re: FreeRDP 2.0.0 released April 9, 2020
On Sun, Apr 19, 2020 at 07:59:04AM +0200, Landry Breuil wrote:
> On Sat, Apr 18, 2020 at 11:29:11PM -0600, Steve Williams wrote:
> > Hi,
> >
> > OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020
> >
> > I am working on trying to get Apache Guacamole working (I've got it
> > compiling) to provide RDP and SSH access to my home network. I have the ssh
> > access working, but Guacamole (guacd) is dumping a core in freerdp
> > (freerdp-2.0.0rc1p4). Based on the stack trace, I am assuming an issue
> > with the more strict malloc that OpenBSD uses. I checked and see that a
> > final release of FreeRDP (2.0.0) was made available April 9, 2020.
> >
> > Is anyone working on porting the new version of FreeRDP? I could not see a
> > "MAINTAINER" in the Makefile.
>
> Newer versions of freerdp needs some methods not available on OpenBSD,
> check
> http://openbsd-archive.7691.n7.nabble.com/x11-freerdp-update-to-2-0-0-rc4-td360502.html#a360567
> and https://marc.info/?t=15248249265=1=2 and
> https://github.com/FreeRDP/FreeRDP/issues/4592.
there's a comment about it in the port Makefile:
# XXX This version has known security issues.
# XXX Can't be updated without either timer_create() and friends or
# an alternative timer implementation (as was done for OSX)
> > I've been using OpenBSD since version 2.7 and am a C programmer of 30+
> > years.
>
> glad if you can help on this then ! build a debug package for the port
> to have proper symbols for the backtrace..
more details on this after i've actually looked - its a cmake port which
doesnt always cope well yet with our DEBUG_PACKAGES framework, you can try with
DEBUG_PACKAGES=${BUILD_PACKAGES} which will give you this:
Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new
Writing /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/PLIST
Renaming /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/debug-pkg/Makefile.new to
Makefile
> Extracting debug info from
> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-hash
> Extracting debug info from
> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/winpr-makecert
> Extracting debug info from
> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/bin/xfreerdp
> Extracting debug info from
> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp-client2.so.0.0
> Extracting debug info from
> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libfreerdp2.so.0.0
> Extracting debug info from
> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr-tools2.so.0.0
> Extracting debug info from
> /usr/obj/ports/freerdp-2.0.0rc1/fake-amd64/usr/local/lib/libwinpr2.so.0.0
Create /usr/ports/packages/amd64/all/freerdp-2.0.0rc1p4.tgz
Creating package freerdp-2.0.0rc1p4
Creating package debug-freerdp-2.0.0rc1p4
Link to /usr/ports/packages/amd64/ftp/freerdp-2.0.0rc1p4.tgz
Link to /usr/ports/packages/amd64/ftp/debug-freerdp-2.0.0rc1p4.tgz
and then install the debug-freerdp package & check if gdb find syms.
Tried it here and it doesnt seem to help (blame cmake that forcefully strips
syms when CMAKE_BUILD_TYPE=Release...):
nikki:~/ $egdb /usr/local/bin/xfreerdp
Reading symbols from /usr/local/bin/xfreerdp...(no debugging symbols
found)...done.
Another option worth a try, you can locally add
-DCMAKE_BUILD_TYPE=RelWithDebInfo to CONFIGURE_ARGS to build a local package
with debug symbols enabled via cmake. Might work.
Landry
Re: FreeRDP 2.0.0 released April 9, 2020
On Sat, Apr 18, 2020 at 11:29:11PM -0600, Steve Williams wrote: > Hi, > > OpenBSD 6.6 (GENERIC.MP) #7: Thu Mar 12 11:55:22 MDT 2020 > > I am working on trying to get Apache Guacamole working (I've got it > compiling) to provide RDP and SSH access to my home network. I have the ssh > access working, but Guacamole (guacd) is dumping a core in freerdp > (freerdp-2.0.0rc1p4). Based on the stack trace, I am assuming an issue > with the more strict malloc that OpenBSD uses. I checked and see that a > final release of FreeRDP (2.0.0) was made available April 9, 2020. > > Is anyone working on porting the new version of FreeRDP? I could not see a > "MAINTAINER" in the Makefile. Newer versions of freerdp needs some methods not available on OpenBSD, check http://openbsd-archive.7691.n7.nabble.com/x11-freerdp-update-to-2-0-0-rc4-td360502.html#a360567 and https://marc.info/?t=15248249265=1=2 and https://github.com/FreeRDP/FreeRDP/issues/4592. > I've been using OpenBSD since version 2.7 and am a C programmer of 30+ > years. glad if you can help on this then ! build a debug package for the port to have proper symbols for the backtrace.. Landry
