CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/04 23:40:30 Modified files: x11/kde-applications/cervisia: Makefile x11/kde-applications/cervisia/pkg: PLIST x11/kde-applications/filelight: Makefile x11/kde-applications/filelight/pkg: PLIST x11/kde-applications/grantleetheme: Makefile x11/kde-applications/grantleetheme/pkg: PLIST x11/kde-applications/gwenview: Makefile x11/kde-applications/gwenview/pkg: PLIST x11/kde-applications/juk: Makefile x11/kde-applications/juk/pkg: PLIST x11/kde-applications/kalzium: Makefile x11/kde-applications/kalzium/pkg: PLIST x11/kde-applications/kamera: Makefile x11/kde-applications/kamera/pkg: PLIST x11/kde-applications/kanagram: Makefile x11/kde-applications/kanagram/pkg: PLIST x11/kde-applications/kapptemplate: Makefile x11/kde-applications/kapptemplate/pkg: PLIST x11/kde-applications/kbackup: Makefile x11/kde-applications/kbackup/pkg: PLIST x11/kde-applications/kbruch: Makefile x11/kde-applications/kbruch/pkg: PLIST x11/kde-applications/kcachegrind: Makefile x11/kde-applications/kcachegrind/pkg: PLIST x11/kde-applications/kcharselect: Makefile x11/kde-applications/kcharselect/pkg: PLIST x11/kde-applications/kcolorchooser: Makefile x11/kde-applications/kcolorchooser/pkg: PLIST x11/kde-applications/kcron: Makefile x11/kde-applications/kcron/pkg: PLIST x11/kde-applications/kde-dev-utils: Makefile x11/kde-applications/kde-dev-utils/pkg: PLIST x11/kde-applications/kdenetwork-filesharing: Makefile x11/kde-applications/kdenetwork-filesharing/pkg: PLIST x11/kde-applications/kdesdk-thumbnailers: Makefile x11/kde-applications/kdesdk-thumbnailers/pkg: PLIST x11/kde-applications/kdf: Makefile x11/kde-applications/kdf/pkg: PLIST x11/kde-applications/kdialog: Makefile x11/kde-applications/kdialog/pkg: PLIST x11/kde-applications/keditbookmarks: Makefile x11/kde-applications/keditbookmarks/pkg: PLIST x11/kde-applications/kfind: Makefile x11/kde-applications/kfind/pkg: PLIST x11/kde-applications/kfloppy: Makefile x11/kde-applications/kfloppy/pkg: PLIST x11/kde-applications/kgeography: Makefile x11/kde-applications/kgeography/pkg: PLIST x11/kde-applications/khangman: Makefile x11/kde-applications/khangman/pkg: PLIST x11/kde-applications/khelpcenter: Makefile x11/kde-applications/khelpcenter/pkg: PLIST x11/kde-applications/kig: Makefile x11/kde-applications/kig/pkg: PLIST x11/kde-applications/kiten: Makefile x11/kde-applications/kiten/pkg: PLIST x11/kde-applications/kleopatra: Makefile x11/kde-applications/kleopatra/pkg: PLIST x11/kde-applications/klettres: Makefile x11/kde-applications/klettres/pkg: PLIST x11/kde-applications/kmag: Makefile x11/kde-applications/kmag/pkg: PLIST x11/kde-applications/kmines: Makefile x11/kde-applications/kmines/pkg: PLIST x11/kde-applications/kmix: Makefile x11/kde-applications/kmix/pkg: PLIST x11/kde-applications/kmouth: Makefile x11/kde-applications/kmouth/pkg: PLIST x11/kde-applications/kmplot: Makefile x11/kde-applications/kmplot/pkg: PLIST x11/kde-applications/kolourpaint: Makefile x11/kde-applications/kolourpaint/pkg: PLIST x11/kde-applications/kompare: Makefile x11/kde-applications/kompare/pkg: PLIST x11/kde-applications/konquest: Makefile x11/kde-applications/konquest/pkg: PLIST x11/kde-applications/krdc: Makefile x11/kde-applications/krdc/pkg: PLIST x11/kde-applications/krfb: Makefile x11/kde-applications/krfb/pkg: PLIST x11/kde-applications/kruler: Makefile x11/kde-applications/kruler/pkg: PLIST x11/kde-applications/kshisen: Makefile x11/kde-applications/kshisen/pkg: PLIST x11/kde-applications/kspaceduel: Makefile x11/kde-applications/kspaceduel/pkg: PLIST x11/kde-applications/ksystemlog: Makefile x11/kde-applications/ksystemlog/pkg: PLIST x11/kde-applications/kteatime: Makefile x11/kde-applications/kteatime/pkg: PLIST x11/kde-applications/ktimer: Makefile x11/kde-applications/ktimer/pkg: PLIST x11/kde-applications/ktuberling: Makefile x11/kde-applications/ktuberling/pkg: PLIST x11/kde-applications/kturtle: Makefile x11/kde-applications/kturtle/pkg: PLIST x11/kde-applications/kwalletmanager: Makefile
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/04 23:28:13 Modified files: devel/kf5 : kf5.port.mk Added files: devel/kf5 : PFRAG.i18n Log message: Add MODKF5_I18N_CONFLICT helper Simple helper function to mark conflicts with kde-i18n-* packages.
Making a FreeCAD Port
Hi @ports, Is there anyone working on FreeCAD? It's not in /usr/ports/cad, and I searched the mailing list and did not find anything fruitful. If not, would like to give it a shot if possible - this would be my first port. If there is anyone working on it, please let me know how I can contribute. Thank you
Re: curl with libidn
> On Jun 4, 2020, at 4:13 PM, Alex Free wrote: > > Why are flavors in common libraries a big problem putting aside the > security issues and quality of code in this case? Every flavored library has an exponential impact on the number of configurations that ports depending on that library must support.
Re: [new] sysutils/web2ldap and co
On Thu, Jun 04, 2020 at 03:18:39PM +0200, Landry Breuil wrote:
> On Wed, Jun 03, 2020 at 08:12:48PM -0500, Lucas Raab wrote:
> > On Wed, Jun 03, 2020 at 07:06:28AM -0500, Lucas Raab wrote:
> > > On Wed, Jun 03, 2020 at 12:56:00PM +0100, Stuart Henderson wrote:
> > > > On 2020/06/03 06:02, Lucas Raab wrote:
> > > > > On Wed, Jun 03, 2020 at 08:19:40AM +0200, Landry Breuil wrote:
> > > > > > On Tue, Jun 02, 2020 at 05:01:06PM -0500, Lucas Raab wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > Here are three new ports, two deps, and the one piece de
> > > > > > > resistance,
> > > > > > > web2ldap.
>
>
>
> > > > Rather than putting files in share/examples/web2ldap/templates and
> > > > @sample'ing them across, another option is to put them in
> > > > share/web2ldap/templates and installing a symlink at pkg_add time,
> > > > something like this should work (untested):
> > > >
> > > > @exec-add [ -e ${SYSCONFDIR}/web2ldap ] || ln -s
> > > > %D/share/web2ldap/templates ${SYSCONFDIR}/web2ldap/
> > > >
> > > > That allows using the templates directory by default, but still
> > > > allows pointing the link elsewhere if you want to customise them.
> > > >
> > > > tls/ca-bundle.pem should just use the system file instead,
> > > > /etc/ssl/cert.pem (_don't_ use ${SYSCONFDIR} for that one).
> > >
> > > Got it, I'll give that a whirl. Thanks!
> > >
> > > >
> > > > > > - instead of using 'nobody', create a new separate user for the
> > > > > > daemon,
> > > > > > look for examples in other ports' PLIST (@newuser/@newgroup, +
> > > > > > db/user.list line)
> > > > >
> > > > > My rationale here was that there aren't any files that an extra user
> > > > > would need to own for web2ldap to run. Using nobody seemed the
> > > > > simplest
> > > > > approach to nulling out any privileges for the service to work.
> > > >
> > > > "nobody" is absolutely not allowed.
> > > >
> > > > $ getent passwd nobody
> > > > nobody:*:32767:32767:Unprivileged user for
> > > > NFS:/nonexistent:/sbin/nologin
> > > >
> > > Aha, that makes sense now. Consider myself chastised :)
> > >
> >
> > Updated ports attached.
> >
> > Changes:
> > * py-ldap0 WANTLIB to use $(MODPY_WANTLIB} instead
> > * use MODPY_EGG_VERSION in place of $V for web2ldap
> > * new user _web2ldap to run the service
> > * I backed off a bit from the two step install. I included a README to
> > instruct the user to copy the template folder over. The templates can
> > be customized, new ones added, etc so it didn't seem right to do a
> > symlink. Thoughts?
> > * Looking in hosts.py, the ca-bundle.pem file isn't specifically
> > referenced. Instead, I added some words to the README mentioning
> > that if a user needs to connect to TLS enabled servers, then he/she
> > should point to /etc/ssl/cert.pem (unless otherwise needed). I forgot
> > that that's what I ended up doing, looking at my own configuration.
>
> after building the ports, tests fail the samefor py-ldap0 and web2ldap:
>
> ==
> ERROR: tests (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: tests
> Traceback (most recent call last):
> File "/usr/local/lib/python3.7/unittest/loader.py", line 154, in
> loadTestsFromName
> module = __import__(module_name)
> ModuleNotFoundError: No module named 'tests'
>
> tests fail for py-xlwt:
>
> File "/usr/local/lib/python3.7/unittest/loader.py", line 205, in
> loadTestsFromName
> test = obj()
> TypeError: __init__() missing 2 required positional arguments: 'colx' and
> 'parent_sheet'
* I added NO_TEST to py-ldap0. Looking at the repo, the tests look to
assume that they're running in the container in .gitlab-ci.yml
* I added MODPY_PYTEST=Yes to py-xlwt, tests fine after that
* I added MODPY_PYTEST=Yes to web2ldap, but for some reason, the tests
don't seem to be picked up. I'm not sure what to do there. Nothing
stood out to me as being obviously wrong.
>
>
> something i spotted - MODPY_BIN should be used in pkg/web2ldap.rc, dont
> hardcode python3.7.
Updated, thanks for catching that.
>
> Im a bit confused by the README, why not patching the code (or the conf) to
> make etc/ssl/cert.pem the default value ?
web2ldap allows global defaults and per-server TLS configurations. It
could be specified that /etc/ssl/cert.pem is the global default and
that leaves the user free to define other CAs in per server configs
(I've done this at my workplace). The default hosts.py makes no
assumptions about what the user wants (the TLS cert options are all
commented out). I don't think it's unreasonable to assume that a global
default could be set to /etc/ssl/cert.pem and still allow the user to
have their overrides. I've updated the README to make it clearer.
>
> The default should work ootb, now if i try to run it, here's what i get at the
> first hit:
>
>
Re: curl with libidn
> Sent: Friday, June 05, 2020 at 1:03 AM > From: "Stuart Henderson" > To: "Alex Free" > Cc: "f.holop" , ports@openbsd.org > Subject: Re: curl with libidn > > On 2020/06/05 00:21, Alex Free wrote: > > > Sent: Friday, June 05, 2020 at 12:05 AM > > > From: "Stuart Henderson" > > > To: "Alex Free" > > > Cc: "f.holop" , ports@openbsd.org > > > Subject: Re: curl with libidn > > > > > > On 2020/06/04 22:39, Alex Free wrote: > > > > > Sent: Thursday, June 04, 2020 at 4:53 PM > > > > > From: "f.holop" > > > > > To: ports@openbsd.org > > > > > Subject: curl with libidn > > > > > > > > > > hi, > > > > > > > > > > atm curl is unable to open non ascii domains. > > > > > is there a reason why it's not compiled with libidn? > > > > > (same goes for lynx) > > > > > > > > > > -f > > > > > -- > > > > > > > > > > > > > > > > > > If it compiles fine a flavor should be added to both. > > > > > > hahaha no. > > > > > > > > > > Your right it should just be a dependency to both. > > If it's readded at all then it should just be a dependency (flavours > in common libraries are a big problem). (it would be libidn2 not libidn, > they are different codebases and supporting different IDNA specs). > > When IDN support was removed from the curl port before, upstream had > hurriedly switched from libidn to libidn2 (despite at the time libidn > being fairly well updated, and libidn2 having been mostly dead for > about 5 years). IIRC this was to avoid problems with differences > between the two IDNA specs (afaik both of which are still in use, > though I have some recollection of at least some TLDs disallowing > domains which conflict between the two? not sure..). > > Adding it would add more code to something that is quite a common > dependency. Maybe it's useful enough to be worth it (being from a > country with mostly 7-bit charset I don't get much of a vote in this ;) > but along with the upside of support IDNs, there is a downside to > pulling in (historically a bit buggy) code to all ports using the > library. > > FWIW here are some of the more important libidn2 bugs. > > CVE-2019-12290 > > GNU libidn2 before 2.2.0 fails to perform the roundtrip checks specified > in RFC3490 Section 4.2 when converting A-labels to U-labels. This makes > it possible in some circumstances for one domain to impersonate another. > By creating a malicious domain that matches a target domain except for > the inclusion of certain punycoded Unicode characters (that would be > discarded when converted first to a Unicode label and then back to an > ASCII label), arbitrary domains can be impersonated. > > CVE-2019-18224 > > idn2_to_ascii_4i in lib/lookup.c in GNU libidn2 before 2.1.1 has a > heap-based buffer overflow via a long domain string. > > CVE-2017-14062 > > Integer overflow in the decode_digit function in puny_decode.c in > Libidn2 before 2.0.4 allows remote attackers to cause a denial of > service or possibly have unspecified other impact. > > CVE-2017-14061 > > Integer overflow in the _isBidi function in bidi.c in Libidn2 before > 2.0.4 allows remote attackers to cause a denial of service or possibly > have unspecified other impact. > Why are flavors in common libraries a big problem putting aside the security issues and quality of code in this case?
Re: curl with libidn
On 2020/06/05 00:21, Alex Free wrote: > > Sent: Friday, June 05, 2020 at 12:05 AM > > From: "Stuart Henderson" > > To: "Alex Free" > > Cc: "f.holop" , ports@openbsd.org > > Subject: Re: curl with libidn > > > > On 2020/06/04 22:39, Alex Free wrote: > > > > Sent: Thursday, June 04, 2020 at 4:53 PM > > > > From: "f.holop" > > > > To: ports@openbsd.org > > > > Subject: curl with libidn > > > > > > > > hi, > > > > > > > > atm curl is unable to open non ascii domains. > > > > is there a reason why it's not compiled with libidn? > > > > (same goes for lynx) > > > > > > > > -f > > > > -- > > > > > > > > > > > > > > If it compiles fine a flavor should be added to both. > > > > hahaha no. > > > > > > Your right it should just be a dependency to both. If it's readded at all then it should just be a dependency (flavours in common libraries are a big problem). (it would be libidn2 not libidn, they are different codebases and supporting different IDNA specs). When IDN support was removed from the curl port before, upstream had hurriedly switched from libidn to libidn2 (despite at the time libidn being fairly well updated, and libidn2 having been mostly dead for about 5 years). IIRC this was to avoid problems with differences between the two IDNA specs (afaik both of which are still in use, though I have some recollection of at least some TLDs disallowing domains which conflict between the two? not sure..). Adding it would add more code to something that is quite a common dependency. Maybe it's useful enough to be worth it (being from a country with mostly 7-bit charset I don't get much of a vote in this ;) but along with the upside of support IDNs, there is a downside to pulling in (historically a bit buggy) code to all ports using the library. FWIW here are some of the more important libidn2 bugs. CVE-2019-12290 GNU libidn2 before 2.2.0 fails to perform the roundtrip checks specified in RFC3490 Section 4.2 when converting A-labels to U-labels. This makes it possible in some circumstances for one domain to impersonate another. By creating a malicious domain that matches a target domain except for the inclusion of certain punycoded Unicode characters (that would be discarded when converted first to a Unicode label and then back to an ASCII label), arbitrary domains can be impersonated. CVE-2019-18224 idn2_to_ascii_4i in lib/lookup.c in GNU libidn2 before 2.1.1 has a heap-based buffer overflow via a long domain string. CVE-2017-14062 Integer overflow in the decode_digit function in puny_decode.c in Libidn2 before 2.0.4 allows remote attackers to cause a denial of service or possibly have unspecified other impact. CVE-2017-14061 Integer overflow in the _isBidi function in bidi.c in Libidn2 before 2.0.4 allows remote attackers to cause a denial of service or possibly have unspecified other impact.
Re: curl with libidn
> Sent: Friday, June 05, 2020 at 12:05 AM > From: "Stuart Henderson" > To: "Alex Free" > Cc: "f.holop" , ports@openbsd.org > Subject: Re: curl with libidn > > On 2020/06/04 22:39, Alex Free wrote: > > > Sent: Thursday, June 04, 2020 at 4:53 PM > > > From: "f.holop" > > > To: ports@openbsd.org > > > Subject: curl with libidn > > > > > > hi, > > > > > > atm curl is unable to open non ascii domains. > > > is there a reason why it's not compiled with libidn? > > > (same goes for lynx) > > > > > > -f > > > -- > > > > > > > > > > If it compiles fine a flavor should be added to both. > > hahaha no. > > Your right it should just be a dependency to both.
ok? [new] sysutils/cdirip
Extracts the proprietary DiscJugglar .cdi format. New versions of this software are under GPL but not compatible with big endian so version 0.6.2 is used instead. cdirip.tgz Description: GNU Zip compressed data
Re: curl with libidn
On 2020/06/04 22:39, Alex Free wrote: > > Sent: Thursday, June 04, 2020 at 4:53 PM > > From: "f.holop" > > To: ports@openbsd.org > > Subject: curl with libidn > > > > hi, > > > > atm curl is unable to open non ascii domains. > > is there a reason why it's not compiled with libidn? > > (same goes for lynx) > > > > -f > > -- > > > > > > If it compiles fine a flavor should be added to both. hahaha no.
Re: does a new port have to be the latest version?
On 2020/06/04 22:28, Alex Free wrote: > Does everything look ok on the email I sent to ports? > > https://marc.info/?l=openbsd-ports=159123552330253=2 Not had time to look closely yet. I think the | characters in PERMIT_* are a problem. And please just send a tar.gz not a diff for new ports
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2020/06/04 14:50:39 Modified files: telephony/resiprocate: Makefile Added files: telephony/resiprocate/patches: patch-rutil_stun_Stun_cxx Log message: Just use arc4random() and skip the whole convoluted and incomplete attempt to read architecture or OS-specific timers or random values to seed srandom(). Fixes the build on non-x86. ok feinerer@
Re: curl with libidn
> Sent: Thursday, June 04, 2020 at 4:53 PM > From: "f.holop" > To: ports@openbsd.org > Subject: curl with libidn > > hi, > > atm curl is unable to open non ascii domains. > is there a reason why it's not compiled with libidn? > (same goes for lynx) > > -f > -- > > If it compiles fine a flavor should be added to both.
Re: pkg_check on 6.7: texmf packages have too many dependencies
On Thu, Jun 04, 2020 at 02:29:06PM +0100, Edd Barrett wrote: > Hi Folks, > > I recently received an email from a user (in CC) who reported that if > you install texlive_texmf-full on 6.7 then pkg_check will complain. > > I installed 6.7 in a VM and tried. Sure enough: > > ``` > openbsd67# pkg_check > Packing-list sanity: ok > texlive_texmf-minimal-2019 has too many dependencies: > texlive_mktexlsr-2019 > Remove missing dependencies: texlive_mktexlsr-2019 ? [y/N/a] > texlive_texmf-full-2019 has too many dependencies: texlive_mktexlsr-2019 > Remove missing dependencies: texlive_mktexlsr-2019 ? [y/N/a] > ``` It's not specific to 6.7 It's on my list of things to look at eventually...
Re: does a new port have to be the latest version?
> Sent: Wednesday, June 03, 2020 at 4:05 PM > From: "Stuart Henderson" > To: "Alex Free" > Cc: "Renaud Allard" , ports@openbsd.org > Subject: Re: does a new port have to be the latest version? > > On 2020/06/03 14:58, Alex Free wrote: > > > Sent: Wednesday, June 03, 2020 at 2:24 PM > > > From: "Stuart Henderson" > > > To: "Renaud Allard" > > > Cc: ports@openbsd.org > > > Subject: Re: does a new port have to be the latest version? > > > > > > On 2020/06/03 14:17, Renaud Allard wrote: > > > > > > > > > > > > On 6/3/20 2:11 PM, Stuart Henderson wrote: > > > > > On 2020/06/03 13:54, Alex Free wrote: > > > > > > > > > > > > > > What is the program? > > > > > > > > > > > > > > > > > > > CDIrip, the current GitHub is at https://github.com/jozip/cdirip . > > > > > > > > > > > > > > > > yes 0.6.3 looks to be a bit of a step backwards there. looking at the > > > > > diff > > > > > it did also remove a duplicate write of though. > > > > > > > > > > Note that it doesn't have proper licensing so will need to be marked > > > > > as > > > > > PERMIT_PACKAGE/PERMIT_DISTFILES=no license (some mention of "version > > > > > developed on sourceforge under gpl" isn't a valid license grant). > > > > > > > > > https://github.com/jozip/cdirip/blob/master/LICENSE > > > > > > > > Mentions GPLV2 > > > > > > > > > > That is just a file in the distribution of the version on github. There's > > > no > > > indication that it was added by the original author of the code and the > > > "How > > > to Apply These Terms to Your New Programs" section hasn't been followed > > > in particular there is no "Copyright XXX you can redistribute it" etc. > > > The only valid copyright information I see in the whole distribution is > > > the one in https://github.com/jozip/cdirip/blob/master/audio.c which says > > > > > > /* Copyright (C) 1988-1991 Apple Computer, Inc. > > > * All rights reserved. > > > > > > and does not grant redistribution. > > > > > > > > > > Previous versions were not under the GPL, but the > > original author released 0.6.3 under the GPL. > > Just saying "released under GPL" without doing other steps isn't enough. > It needs at least a copyright line with a license grant somewhere > preferably on each file, that's why the license goes to some lengths to > explain how to do it. > > Also releasing some version under GPL doesn't mean that previous versions > are also automatically released under GPL. > > > Source for all previous versions were always > > available, and still are on the wayback machine of > > the original homepage. > > > > Essentially pre 0.6.3 is just source available. > > > > Dist file mirroring is okay right? Besides the > > I don't think it is OK for OpenBSD to do this (as in PERMIT_* etc can't > be set to Yes and it would need building from ports not installing from > packages). If you want to mirror the distfile yourself that would be your > responsibility. > > > wayback machine there is exactly one place I can > > find 0.6.2, and it’s on a gnome related mirror > > and in zip format. Right now I have the port’s > > master site set to my own with a .tar.gz of the > > source. > > I found it at > https://nold.in/lib/exe/fetch.php?media=projects:consoles:dreamcast:cdirip-0.6.2-linux.tar.bz2 > (a path like this requires certain fiddling to use as a source in ports, > should be possible but is annoying!). > > ... > > > Is the code actually invalid GPL due to the Apple code? NetBSD is > > hosting dist files containing the Apple code so is it ok? License > > newbie, thanks for your patience. > > IANAL and it may vary between jurisdictions anyway but my understanding > is "if you don't include a Copyright line and grant some specific rights > to allow redistribution then it can't be redistributed". Some OS care > more about this for things in packages than others (Debian in particular > usually get this right) some others seem to rely on "meh nobody's really > going to complain are they". > > Does everything look ok on the email I sent to ports? https://marc.info/?l=openbsd-ports=159123552330253=2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2020/06/04 13:43:35 Modified files: editors/nano : Makefile distinfo Log message: Update to 4.9.3 for some bug fixes. Enable debug package.
Re: telephony/resiprocate: fix build on !x86
Remember that srandom() + random() will do arc4random() internally,
unless srandom_determinisitic() is called.
But I guess the idiocy is the code ahead of srandom...
Christian Weisgerber wrote:
> telephony/resiprocate fails to build on non-x86 architectures.
>
> The reason is amazing:
> error: Need some way to seed the random number generator
> http://build-failures.rhaalovely.net/aarch64/2020-05-30/telephony/resiprocate%2C.log
>
> The culprit is stunRand() in rutil/stun/Stun.cxx. Depending on
> operating system and architecture, this function tries to query
> some high resolution timer or get a piece of random data, which it
> uses to seed srandom(), and then calls random(). It's an inconsistent
> mess (why build a 64-bit seed? does it return 32 or 31 bits?).
> Oh, and it uses rdtsc on __i386__, an instruction that appeared on
> the Pentium.
>
> I already spent too much time looking at this; here's a patch that
> simply bypasses the whole mess.
>
> OK?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/telephony/resiprocate/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 29 May 2020 21:41:23 - 1.1.1.1
> +++ Makefile 4 Jun 2020 16:28:51 -
> @@ -6,6 +6,7 @@ COMMENT-return = reSIProcate STUN/TURN c
>
> V = 1.12.0
> DISTNAME = resiprocate-${V}
> +REVISION = 0
> PKGNAME-main = resiprocate-${V}
> PKGNAME-repro = resiprocate-repro-${V}
> PKGNAME-return = resiprocate-return-${V}
> Index: patches/patch-rutil_stun_Stun_cxx
> ===
> RCS file: patches/patch-rutil_stun_Stun_cxx
> diff -N patches/patch-rutil_stun_Stun_cxx
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-rutil_stun_Stun_cxx 4 Jun 2020 16:28:51 -
> @@ -0,0 +1,23 @@
> +$OpenBSD$
> +
> +Index: rutil/stun/Stun.cxx
> +--- rutil/stun/Stun.cxx.orig
> rutil/stun/Stun.cxx
> +@@ -802,6 +802,9 @@ stunRand()
> + {
> +// return 32 bits of random stuff
> +resip_assert( sizeof(int) == 4 );
> ++#if defined(__OpenBSD__)
> ++ return arc4random();
> ++#else
> +static bool init=false;
> +if ( !init )
> +{
> +@@ -857,6 +860,7 @@ stunRand()
> +return ret;
> + #else
> +return random();
> ++#endif
> + #endif
> + }
> +
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
telephony/resiprocate: fix build on !x86
telephony/resiprocate fails to build on non-x86 architectures.
The reason is amazing:
error: Need some way to seed the random number generator
http://build-failures.rhaalovely.net/aarch64/2020-05-30/telephony/resiprocate%2C.log
The culprit is stunRand() in rutil/stun/Stun.cxx. Depending on
operating system and architecture, this function tries to query
some high resolution timer or get a piece of random data, which it
uses to seed srandom(), and then calls random(). It's an inconsistent
mess (why build a 64-bit seed? does it return 32 or 31 bits?).
Oh, and it uses rdtsc on __i386__, an instruction that appeared on
the Pentium.
I already spent too much time looking at this; here's a patch that
simply bypasses the whole mess.
OK?
Index: Makefile
===
RCS file: /cvs/ports/telephony/resiprocate/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile29 May 2020 21:41:23 - 1.1.1.1
+++ Makefile4 Jun 2020 16:28:51 -
@@ -6,6 +6,7 @@ COMMENT-return =reSIProcate STUN/TURN c
V =1.12.0
DISTNAME = resiprocate-${V}
+REVISION = 0
PKGNAME-main = resiprocate-${V}
PKGNAME-repro =resiprocate-repro-${V}
PKGNAME-return = resiprocate-return-${V}
Index: patches/patch-rutil_stun_Stun_cxx
===
RCS file: patches/patch-rutil_stun_Stun_cxx
diff -N patches/patch-rutil_stun_Stun_cxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-rutil_stun_Stun_cxx 4 Jun 2020 16:28:51 -
@@ -0,0 +1,23 @@
+$OpenBSD$
+
+Index: rutil/stun/Stun.cxx
+--- rutil/stun/Stun.cxx.orig
rutil/stun/Stun.cxx
+@@ -802,6 +802,9 @@ stunRand()
+ {
+// return 32 bits of random stuff
+resip_assert( sizeof(int) == 4 );
++#if defined(__OpenBSD__)
++ return arc4random();
++#else
+static bool init=false;
+if ( !init )
+{
+@@ -857,6 +860,7 @@ stunRand()
+return ret;
+ #else
+return random();
++#endif
+ #endif
+ }
+
--
Christian "naddy" Weisgerber na...@mips.inka.de
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 09:55:27 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.18.72.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 09:55:14 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.13.22.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 09:54:58 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py3-botocore-1.16.22.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/04 09:39:09 Modified files: net/kea: Makefile distinfo Log message: update to kea-1.7.8
Re: [NEW] sysutils/kubectl
On Thu, Jun 04, 2020 at 02:43:24PM +0200, karlis.mikels...@lf.lv wrote:
> Please find attached port for kubectl latest stable version:
> "The Kubernetes command-line tool, kubectl, allows you to run commands
> against Kubernetes clusters. You can use kubectl to deploy applications,
> inspect and manage cluster resources, and view logs."
Thanks a lot for your port! Installing it via `go get' already worked
but proper packages are much nicer :)
> Tested on amd64, package works fine, but seems to ignore version parameters
> set in MODGO_LDFLAGS:
> $ kubectl version --client=true
> Client Version: version.Info{Major:"", Minor:"",
> GitVersion:"v0.0.0-master+2e7996e3e2712",
> GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"",
> BuildDate:"1970-01-01T00:00:00Z", GoVersion:"go1.13.9", Compiler:"gc",
> Platform:"openbsd/amd64"}
>
> I would appreciate if someone could point me in the right direction how to
> set them up properly.
FreeBSD seems to use the very same ldflags, do you know if it works for
them?
Why overwrite version and date in the first place? Does it matter?
Your port looks good, however pre-configure looks a bit odd; I've
removed the entire target and simply set `ALL_TARGET = k8s.io/kubernetes'
instead; I'm not yet sure if this does the same thing or causes more
stuff to be built, but it works, looks cleaner and resulting kubectl
works also.
Can you check if I missed something with ALL_TARGET?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2020/06/04 09:01:53 Modified files: www/chromium : Makefile distinfo www/chromium/patches: patch-BUILD_gn patch-build_config_compiler_BUILD_gn patch-content_public_common_content_features_cc patch-net_nqe_network_quality_estimator_cc Log message: update to 83.0.4103.97
curl with libidn
hi, atm curl is unable to open non ascii domains. is there a reason why it's not compiled with libidn? (same goes for lynx) -f --
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/04 08:18:57 Modified files: x11/qt5/qtwebengine: Makefile Log message: mark BROKEN-i386, this can't be built on the build machines. it maybe possible to get it building with -Wl,--no-keep-memory or maybe by using ld.bfd instead of LLD, if someone wants to figure out the qmake/gn bits needed I can test diffs
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org 2020/06/04 08:14:27
Modified files:
x11/qt5: Makefile.inc
Log message:
x11/qt5: allow ONLY_FOR_ARCHS to be overridden by ports underneath this dir.
-ONLY_FOR_ARCHS = ${GCC4_ARCHS} ${CLANG_ARCHS}
+ONLY_FOR_ARCHS ?= ${GCC4_ARCHS} ${CLANG_ARCHS}
The only port changed by this is qtwebengine, making it honour the more
restrictive ONLY_FOR_ARCHS setting in its Makefile.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/04 07:51:00 Modified files: net/dhcpcd : Tag: OPENBSD_6_7 Makefile distinfo net/dhcpcd/pkg : Tag: OPENBSD_6_7 PLIST Log message: MFC dhcpcd 9.1.1 update; as well as adding pledge this also fixes a bug resulting in multiple IPv6 addresses being added under some circumstances where temporary addresses are enabled, as found the hard way by naddy@.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/06/04 07:45:11 Modified files: net/dhcpcd : Makefile distinfo net/dhcpcd/pkg : PLIST Log message: update to dhcpcd-9.1.1. dhcpcd now uses pledge(), there are some articles with findings from the process that may be of interest to readers: https://roy.marples.name/blog/capsicum_vs_pledge.html https://roy.marples.name/blog/capsicum_vs_pledge_part2.html port change: move the homedir for the @newuser to /var/empty now that dhcpcd no longer requires files inside the chroot directory.
pkg_check on 6.7: texmf packages have too many dependencies
Hi Folks, I recently received an email from a user (in CC) who reported that if you install texlive_texmf-full on 6.7 then pkg_check will complain. I installed 6.7 in a VM and tried. Sure enough: ``` openbsd67# pkg_check Packing-list sanity: ok texlive_texmf-minimal-2019 has too many dependencies: texlive_mktexlsr-2019 Remove missing dependencies: texlive_mktexlsr-2019 ? [y/N/a] texlive_texmf-full-2019 has too many dependencies: texlive_mktexlsr-2019 Remove missing dependencies: texlive_mktexlsr-2019 ? [y/N/a] ``` Does anyone understand why this may be though? texlive_mktexlsr-2019 is not a direct dependency of these two packages, but it is an indirect dependency (via texlive_base)... Thanks -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: [new] sysutils/web2ldap and co
On Wed, Jun 03, 2020 at 08:12:48PM -0500, Lucas Raab wrote:
> On Wed, Jun 03, 2020 at 07:06:28AM -0500, Lucas Raab wrote:
> > On Wed, Jun 03, 2020 at 12:56:00PM +0100, Stuart Henderson wrote:
> > > On 2020/06/03 06:02, Lucas Raab wrote:
> > > > On Wed, Jun 03, 2020 at 08:19:40AM +0200, Landry Breuil wrote:
> > > > > On Tue, Jun 02, 2020 at 05:01:06PM -0500, Lucas Raab wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Here are three new ports, two deps, and the one piece de resistance,
> > > > > > web2ldap.
> > > Rather than putting files in share/examples/web2ldap/templates and
> > > @sample'ing them across, another option is to put them in
> > > share/web2ldap/templates and installing a symlink at pkg_add time,
> > > something like this should work (untested):
> > >
> > > @exec-add [ -e ${SYSCONFDIR}/web2ldap ] || ln -s
> > > %D/share/web2ldap/templates ${SYSCONFDIR}/web2ldap/
> > >
> > > That allows using the templates directory by default, but still
> > > allows pointing the link elsewhere if you want to customise them.
> > >
> > > tls/ca-bundle.pem should just use the system file instead,
> > > /etc/ssl/cert.pem (_don't_ use ${SYSCONFDIR} for that one).
> >
> > Got it, I'll give that a whirl. Thanks!
> >
> > >
> > > > > - instead of using 'nobody', create a new separate user for the
> > > > > daemon,
> > > > > look for examples in other ports' PLIST (@newuser/@newgroup, +
> > > > > db/user.list line)
> > > >
> > > > My rationale here was that there aren't any files that an extra user
> > > > would need to own for web2ldap to run. Using nobody seemed the simplest
> > > > approach to nulling out any privileges for the service to work.
> > >
> > > "nobody" is absolutely not allowed.
> > >
> > > $ getent passwd nobody
> > > nobody:*:32767:32767:Unprivileged user for NFS:/nonexistent:/sbin/nologin
> > >
> > Aha, that makes sense now. Consider myself chastised :)
> >
>
> Updated ports attached.
>
> Changes:
> * py-ldap0 WANTLIB to use $(MODPY_WANTLIB} instead
> * use MODPY_EGG_VERSION in place of $V for web2ldap
> * new user _web2ldap to run the service
> * I backed off a bit from the two step install. I included a README to
> instruct the user to copy the template folder over. The templates can
> be customized, new ones added, etc so it didn't seem right to do a
> symlink. Thoughts?
> * Looking in hosts.py, the ca-bundle.pem file isn't specifically
> referenced. Instead, I added some words to the README mentioning
> that if a user needs to connect to TLS enabled servers, then he/she
> should point to /etc/ssl/cert.pem (unless otherwise needed). I forgot
> that that's what I ended up doing, looking at my own configuration.
after building the ports, tests fail the samefor py-ldap0 and web2ldap:
==
ERROR: tests (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: tests
Traceback (most recent call last):
File "/usr/local/lib/python3.7/unittest/loader.py", line 154, in
loadTestsFromName
module = __import__(module_name)
ModuleNotFoundError: No module named 'tests'
tests fail for py-xlwt:
File "/usr/local/lib/python3.7/unittest/loader.py", line 205, in
loadTestsFromName
test = obj()
TypeError: __init__() missing 2 required positional arguments: 'colx' and
'parent_sheet'
something i spotted - MODPY_BIN should be used in pkg/web2ldap.rc, dont
hardcode python3.7.
Im a bit confused by the README, why not patching the code (or the conf) to
make etc/ssl/cert.pem the default value ?
The default should work ootb, now if i try to run it, here's what i get at the
first hit:
2020-06-04 15:01:30 WARNING: AppHandler[135494693050] ErrorExit: 'I/O error
during reading connect form template file.'
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/web2ldap/app/gui.py", line 94,
in read_template
with open(tmpl_filename, 'rb') as tmpl_fileobj:
FileNotFoundError: [Errno 2] No such file or directory:
'/etc/web2ldap/templates/connect.html'
once i've symlinked the template dir under /etc/web2ldap it works (not saying
that's what has to be done, but its a solution):
$doas ln -s /usr/local/share/examples/web2ldap/templates /etc/web2ldap/templates
Adding BUILD_DEPENDS to RUN_DEPENDS is to be avoided, for example here it
installed devel/ccache for example..
other than that, managed to run it locally to connect to some servers at work
ssh forwarding the relevant ports, it seems to 'work' fine in basic testing,
binding as admin to the directory, etc..
Landry
[NEW] sysutils/kubectl
Hello,
Please find attached port for kubectl latest stable version:
"The Kubernetes command-line tool, kubectl, allows you to run commands
against Kubernetes clusters. You can use kubectl to deploy applications,
inspect and manage cluster resources, and view logs."
Tested on amd64, package works fine, but seems to ignore version
parameters
set in MODGO_LDFLAGS:
$ kubectl version --client=true
Client Version: version.Info{Major:"", Minor:"",
GitVersion:"v0.0.0-master+2e7996e3e2712",
GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"",
BuildDate:"1970-01-01T00:00:00Z", GoVersion:"go1.13.9", Compiler:"gc",
Platform:"openbsd/amd64"}
I would appreciate if someone could point me in the right direction how
to
set them up properly.
Kind regards,
Karlis
kubectl.tar.gz
Description: GNU Zip compressed data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 04:06:31 Modified files: security/gnutls: Tag: OPENBSD_6_7 Makefile Added files: security/gnutls/patches: Tag: OPENBSD_6_7 patch-lib_stek_c Log message: Merge fix for CVE-2020-13777.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 03:08:22 Modified files: security/gnutls: Makefile distinfo security/gnutls/pkg: PLIST Log message: SECURITY update to gnutls-3.6.14.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 02:46:22 Modified files: x11/dbus : Tag: OPENBSD_6_7 Makefile Added files: x11/dbus/patches: Tag: OPENBSD_6_7 patch-dbus_dbus-sysdeps-unix_c Log message: Merge upstream fix for CVE-2020-12049.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 02:44:14 Modified files: x11/dbus : Makefile distinfo Log message: SECURITY update to dbus-1.12.18. - CVE-2020-12049
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/04 02:07:00 Modified files: sysutils/borgmatic: Makefile distinfo sysutils/borgmatic/pkg: PLIST Log message: update to borgmatic-1.5.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/04 02:00:34 Modified files: devel/radare2 : Makefile.inc devel/radare2/main: Makefile Log message: give regress tests a chance to run
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2020/06/04 01:50:07 Modified files: emulators/sameboy: Makefile distinfo emulators/sameboy/patches: patch-Makefile patch-libretro_Makefile emulators/sameboy/pkg: PLIST-main Log message: Update to sameboy-0.13.1. Release notes: https://github.com/LIJI32/SameBoy/releases/tag/v0.13 https://github.com/LIJI32/SameBoy/releases/tag/v0.13.1
Re: Inconsolata 3.0 is no longer fixed width.
Hi,
On Sat, May 30, 2020 at 2:16 PM Marc Espie wrote:
> On Sat, May 30, 2020 at 01:00:17PM -0600, Anthony J. Bentley wrote:
> > Matthieu Herrb writes:
> > > This github issue does pretty much explain what's going on:
> > > https://github.com/googlefonts/Inconsolata/issues/42 :
> >
> > I see nothing as extreme as the screenshots in that link in my xterm.
> > But the new font is certainly wider than the previous one.
> >
> > So we should keep the old font, probably.
> >
> > Should we import the old one as inconsolata-old?
> > Or revert + set EPOCH, and import the new one as inconsolata-new?
> > The latter would avoid breaking people's setups.
>
> Later scheme would be less disturbing
Attached is a revert of inconsolata-font and a tarball of the current
state of the port as inconsolata-new.
I marked them with @conflict for two reasons: inconsolata-new will
conflict with the current version of inconsolata-font, and it seems
problematic to have different versions of the same font with the same
family name installed at the same time.
ok?
--
Anthony J. Bentley
Index: Makefile
===
RCS file: /cvs/ports/fonts/inconsolata-font/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile 25 May 2020 07:08:52 - 1.11
+++ Makefile 4 Jun 2020 07:36:18 -
@@ -1,31 +1,29 @@
-# $OpenBSD: Makefile,v 1.11 2020/05/25 07:08:52 bentley Exp $
+# $OpenBSD: Makefile,v 1.10 2020/01/26 11:14:31 jasper Exp $
-COMMENT= monospace font designed for coders
+COMMENT = monospace font designed for coders (old version)
-V = 3.000
-DISTNAME = inconsolata-font-$V
+TYPEFACE= inconsolata
+DISTNAME= Inconsolata
+PKGNAME= ${TYPEFACE}-font-0.1
+EPOCH = 0
CATEGORIES= fonts x11
HOMEPAGE = https://www.levien.com/type/myfonts/inconsolata.html
-DIST_SUBDIR = inconsolata-$V
-MASTER_SITES = https://github.com/googlefonts/Inconsolata/releases/download/v$V/
-DISTFILES = fonts_ttf.zip \
- fonts_otf.zip
+MASTER_SITES= https://distfiles.sigtrap.nl/
+EXTRACT_SUFX= .otf
+EXTRACT_ONLY=
# SIL OFL 1.1
PERMIT_PACKAGE= Yes
+MODULES= font
+FONTTYPES= otf
+
NO_BUILD= Yes
NO_TEST= Yes
-PKG_ARCH = *
-
-WRKDIST = ${WRKDIR}/fonts
-
-do-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/fonts/inconsolata
- ${INSTALL_DATA} ${WRKSRC}/ttf/*.ttf ${PREFIX}/share/fonts/inconsolata
- ${INSTALL_DATA} ${WRKSRC}/otf/*.otf ${PREFIX}/share/fonts/inconsolata
+pre-install:
+ cp ${FULLDISTDIR}/${DISTFILES} ${WRKSRC}
.include
Index: distinfo
===
RCS file: /cvs/ports/fonts/inconsolata-font/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo 25 May 2020 07:08:52 - 1.3
+++ distinfo 4 Jun 2020 07:36:18 -
@@ -1,4 +1,2 @@
-SHA256 (inconsolata-3.000/fonts_otf.zip) = odMMzRzpKY+48XLfPnP7hx6Z7wp72rp0qVhza9DeW/E=
-SHA256 (inconsolata-3.000/fonts_ttf.zip) = Ym6O4HUB27VEtQqlmsLkueyGuBBnAVilnHo8uvR1VIo=
-SIZE (inconsolata-3.000/fonts_otf.zip) = 2912828
-SIZE (inconsolata-3.000/fonts_ttf.zip) = 4019918
+SHA256 (Inconsolata.otf) = FWHmFsQUobgtbm370Y5XJv1lAokTreGR5fo4tuw3Who=
+SIZE (Inconsolata.otf) = 58464
Index: pkg/DESCR
===
RCS file: /cvs/ports/fonts/inconsolata-font/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 19 Jul 2011 09:16:06 - 1.1.1.1
+++ pkg/DESCR 4 Jun 2020 07:36:18 -
@@ -2,3 +2,6 @@ Inconsolata is a monospace font, designe
like, in print. There are a great many "programmer fonts," designed
primarily for use on the screen, but in most cases do not have the
attention to detail for high resolution rendering.
+
+This version of the font is very old (circa 2009). A newer version
+is available in the 'inconsolata-new' package.
Index: pkg/PLIST
===
RCS file: /cvs/ports/fonts/inconsolata-font/pkg/PLIST,v
retrieving revision 1.4
diff -u -p -r1.4 PLIST
--- pkg/PLIST 25 May 2020 07:08:52 - 1.4
+++ pkg/PLIST 4 Jun 2020 07:36:18 -
@@ -1,152 +1,6 @@
@comment $OpenBSD: PLIST,v 1.4 2020/05/25 07:08:52 bentley Exp $
+@conflict inconsolata-new-*
@pkgpath x11/inconsolata-font
share/fonts/
@fontdir share/fonts/inconsolata/
-share/fonts/inconsolata/Inconsolata-Black.otf
-share/fonts/inconsolata/Inconsolata-Black.ttf
-share/fonts/inconsolata/Inconsolata-Bold.otf
-share/fonts/inconsolata/Inconsolata-Bold.ttf
-share/fonts/inconsolata/Inconsolata-Condensed.otf
-share/fonts/inconsolata/Inconsolata-Condensed.ttf
-share/fonts/inconsolata/Inconsolata-CondensedBlack.otf
-share/fonts/inconsolata/Inconsolata-CondensedBlack.ttf
-share/fonts/inconsolata/Inconsolata-CondensedBold.otf
-share/fonts/inconsolata/Inconsolata-CondensedBold.ttf
-share/fonts/inconsolata/Inconsolata-CondensedExtraBold.otf
-share/fonts/inconsolata/Inconsolata-CondensedExtraBold.ttf
-share/fonts/inconsolata/Inconsolata-CondensedExtraLight.otf
Re: lang/guile2 info doc
On Tue, Jun 02, 2020 at 05:15:17PM +0200, Jan Šmydke wrote:
> Hello,
>
> I would like lang/guile2 did not delete the info pages at installation. It
> is very convenient (or rather a must) for coding in one tmux pane and
> browse the info library reference in the other pane.
>
> It seems there is no maintainer of the package now. Could somebody just
> comment out the last line of the Makefile (i.e. "rm -rf ${PREFIX}/info")
> and commit?
>
> Perhaps not many users need guile installed, but for those who do, the
> documentation is crucial.
Hi.
Fixed in current, thanks.
Initially we installed info files from guile and not guile2 (they conflict); I
have reversed that logic.
--
Antoine
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2020/06/04 01:36:10 Modified files: lang/guile : Makefile lang/guile/pkg : PLIST lang/guile2: Makefile lang/guile2/pkg: PLIST Log message: Install info files from guile2 instead of guile.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/04 01:34:31 Modified files: x11/gnome/shell: Makefile distinfo x11/gnome/shell/pkg: PLIST Log message: update to gnome-shell-3.36.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/04 01:33:49 Modified files: x11/gnome/mutter: Makefile distinfo Log message: update to mutter-3.36.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/04 01:24:06 Modified files: sysutils : Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm sysutils/py-pynetbox: Makefile distinfo sysutils/py-pynetbox/pkg: PLIST Log message: - update to pynetbox-4.3.1 - make this python3-only
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2020/06/04 01:19:25 Modified files: net/py-netmiko : Makefile distinfo net/py-netmiko/pkg: PLIST Log message: update to py3-netmiko-3.1.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2020/06/04 00:19:35 Modified files: devel/qt-creator: Makefile distinfo Log message: Update qt-creator to 4.12.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/04 00:09:39 Modified files: mail/mozilla-thunderbird: Makefile distinfo mail/thunderbird-i18n: Makefile.inc distinfo Log message: Update to thunderbird 68.9.0. See https://www.thunderbird.net/en-US/thunderbird/68.9.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2020-22/ (not there yet)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2020/06/04 00:06:59 Modified files: www/mozilla-firefox: Makefile distinfo www/firefox-i18n: Makefile.inc distinfo Log message: Bugfix update to firefox 77.0.1. See https://www.mozilla.org/en-US/firefox/77.0.1/releasenotes/ Fixes an issue with DNS over HTTPS rollout but TRR is disabled by default for us anyway.
