Re: REMOVE: x11/partiwm

[Marc Espie]

On Thu, Jul 19, 2018 at 01:26:04PM -0300, Elias M. Mariani wrote:
> OK,
> Nothing personal against the port.
> It's just that I think on this port that:
> - Is "defunct".
> - The only uniqueness is xpra and is now a separate project.
So where is your port of xpra ?...

Think about it.

You're advocating removing something useful without proposing anything
equivalent in exchange.

Why should we do the work for you ?
> - python 2 only. And my personal concern is that the end of support of
> python 2 is coming, of course one can not only remove a port just
> because is not python 3 ready... But in this case in the next years
> wont be any effort in fixing that.

Python 2's death has, unfortunately, been greatly exagerated.

I definitely HATE people who will try bringing it about by just saying
"hey, python 2 is dying, oh look, there's some other old software for
which there is *no equivalent* in the ports tree that's python 2 only.
So I must be right".  Which is *exactly* what you're doing here.

You want to help in killing python 2 ?... figure out how to update ports
that are still relevant because they're python 2 only.

Hint: updating them is updating them, not saying "hey it's old stuff, let's
kill it".

> - I don't think that anyone use that port anymore, but no evidence of
> that, it would be interesting to see the downloads of each package to
> see if is used, not to make decisions based just on that but it would
> help in this cases.
> 
> So, I will forget about removing for now, but keep it in mind for a
> possible port cleanup. :)

Port xpra first.


Another good reason to KEEP x11/partiwm: it's TINY.  My last bulk shows it
taking 41 seconds to build.   FORTY ONE SECONDS. Out of a bulk that takes
about 24 DAYS when you take all the ports into account.

Comparatively, a lot of modern stuff that people have pushed for because,
you know, it "replaces old stuff", takes HUGE amounts of time, cpu, memory
to build.

It's also pushing out old platforms, little by little. Because you know,
that recent hyped stuff uses all the cool new tools and languages.

And a lot of them  do not even build on !amd64. Because you know, anything
!amd64 is old and useless...

Re: NEW: x11/kde-applications/kig

[Elias M. Mariani]

Tested OK.

The only thing that I noticed is that the port have conflicts with:
x11/kde/i18n3
x11/kde4/l10n

List from pkglocatedb attached.

Cheers.
Elias

2018-07-08 5:26 GMT-03:00 Rafael Sadowski :
> *ping* with updated tarball. Fixed @tag and update WANTLIB after kf5
> update.
>
> ok?
>
> On Sun May 06, 2018 at 06:14:07PM +0200, Rafael Sadowski wrote:
>> Please find attached an one by one replacement for x11/kde4/kig.
>>
>> $ cat x11/kde-applications/kig/pkg/DESCR
>> Kig is a program for exploring geometric constructions.
>>
>> It is part of the KDE Education Project.
>>
>> Ok? Comments?
>
>


kig.conflicts
Description: Binary data

Re: PATCH: www/nginx, new modsecurity package

[Klemens Nanni]

On Thu, Jul 19, 2018 at 04:55:19PM +0200, Juan Francisco Cantero Hurtado wrote:
> Builds fine and the debug log says that the module is working. The port
> requires libmodsecurity which I sent a few minutes ago.
sparc64 builds with `COMPILER=ports-gcc' set in security/libmodsecurity.

Update: ruby-mysql2 0.4.9 -> 0.5.2

[Jeremy Evans]

Simple update to the latest release of mysql2.

This drops support for MySQL <5.5, see
https://github.com/brianmario/mysql2/releases for other changes.

Will commit next week unless I hear objections.

Thanks,
Jeremy

Index: Makefile
===
RCS file: /cvs/ports/databases/ruby-mysql2/Makefile,v
retrieving revision 1.25
diff -u -p -r1.25 Makefile
--- Makefile13 Jun 2018 22:26:52 -  1.25
+++ Makefile19 Jul 2018 19:32:59 -
@@ -2,8 +2,7 @@
 
 COMMENT=   modern, simple and very fast MySQL library for Ruby
 
-DISTNAME=  mysql2-0.4.9
-REVISION = 0
+DISTNAME=  mysql2-0.5.2
 CATEGORIES=databases
 
 HOMEPAGE=  https://github.com/brianmario/mysql2
Index: distinfo
===
RCS file: /cvs/ports/databases/ruby-mysql2/distinfo,v
retrieving revision 1.11
diff -u -p -r1.11 distinfo
--- distinfo13 Nov 2017 22:44:53 -  1.11
+++ distinfo19 Jul 2018 19:33:09 -
@@ -1,2 +1,2 @@
-SHA256 (mysql2-0.4.9.gem) = iviz07WqM9imhqHKofis2SmMvrQLCfjCR1puz5CxpiI=
-SIZE (mysql2-0.4.9.gem) = 77312
+SHA256 (mysql2-0.5.2.gem) = JDZz8BVkRJQ5aaW1xQlYYsQVjedK9cpmFjdA/p9sU6g=
+SIZE (mysql2-0.5.2.gem) = 99328
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/ruby-mysql2/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST   5 May 2016 22:46:27 -   1.9
+++ pkg/PLIST   25 May 2018 22:32:57 -
@@ -47,6 +47,7 @@ ${GEM_LIB}/gems/${DISTNAME}/spec/ssl/ser
 ${GEM_LIB}/gems/${DISTNAME}/spec/ssl/server-req.pem
 ${GEM_LIB}/gems/${DISTNAME}/spec/test_data
 ${GEM_LIB}/gems/${DISTNAME}/support/
+${GEM_LIB}/gems/${DISTNAME}/support/5072E1F5.asc
 ${GEM_LIB}/gems/${DISTNAME}/support/libmysql.def
 ${GEM_LIB}/gems/${DISTNAME}/support/mysql_enc_to_ruby.rb
 ${GEM_LIB}/gems/${DISTNAME}/support/ruby_enc_to_mysql.rb

Re: NEW: security/libmodsecurity

[Klemens Nanni]

On Thu, Jul 19, 2018 at 07:23:22PM +0200, Juan Francisco Cantero Hurtado wrote:
> On Thu, Jul 19, 2018 at 06:01:41PM +0200, Juan Francisco Cantero Hurtado 
> wrote:
> > On Thu, Jul 19, 2018 at 05:28:17PM +0200, Klemens Nanni wrote:
> > > On Thu, Jul 19, 2018 at 04:43:30PM +0200, Juan Francisco Cantero Hurtado 
> > > wrote:
> > > > I need the library for the upcoming nginx-modsecurity package.
> > > > C patches by robert@.
> > 
> > Thanks for the review.
> > 
> > > sparc64:
> > > 
> > >   cc1plus: error: unrecognized command line option "-std=c++11"
> > > 
> > 
> > I added COMPILER to the port.
Please add a "C++11" comment above.

> > > Lots of `-O3' as well, please get rid of these and ensure that *FLAGS
> > > get through.
> > 
> > I saw that but our flags are passed at the end and have priority over
> > O3. I just want to avoid the extra patches.
I'm not fond of depending on this, but don't want to bikeshed over it,
either.

> And new tarball with configure args splitted. Sorry for the double
> posting.
Still squashed. I'd also split CONFIURE_ENV; it's in most of our ports
and improves readability.

WANTLIB seems to miss `pcre'.

ruby-amalgalite 1.5.0 -> 1.6.1

[Jeremy Evans]

Simple update to the latest amalgalite release. Changes:

* Fix bug when using the json extension
* Update to SQLite 3.21.0
* source id access methods
  * Amalgalite::SQLite3::Version.compiled_source_id
  * Amalgalite::SQLite3::Version.runtime_source_id
* enable new compile time options
  * SQLITE_ENABLE_DBPAGE_VTAB
  * SQLITE_ENABLE_MEMORY_MANAGEMENT
  * SQLITE_ENABLE_PREUPDATE_HOOK
  * SQLITE_ENABLE_SESSION
  * SQLITE_ENABLE_STMTVTAB

Will commit next week unless I hear objections.

Thanks,
Jeremy

Index: Makefile
===
RCS file: /cvs/ports/databases/ruby-amalgalite/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile13 Jun 2018 22:26:52 -  1.21
+++ Makefile19 Jul 2018 19:41:22 -
@@ -2,8 +2,7 @@
 
 COMMENT =  ruby SQLite3 embedded database library
 
-DISTNAME = amalgalite-1.5.0
-REVISION = 0
+DISTNAME = amalgalite-1.6.1
 CATEGORIES =   databases
 
 HOMEPAGE = https://github.com/copiousfreetime/amalgalite
Index: distinfo
===
RCS file: /cvs/ports/databases/ruby-amalgalite/distinfo,v
retrieving revision 1.6
diff -u -p -r1.6 distinfo
--- distinfo4 Nov 2016 21:27:44 -   1.6
+++ distinfo19 Jul 2018 19:41:28 -
@@ -1,2 +1,2 @@
-SHA256 (amalgalite-1.5.0.gem) = wx09yEHfejqL1lNxthQxMyz9mcuL/qSqIGCxNgoaeaA=
-SIZE (amalgalite-1.5.0.gem) = 1913856
+SHA256 (amalgalite-1.6.1.gem) = Ff/iBFfRAOZsRVRu9qHjpmEML+QEhpdfOQN1i+1v7Eg=
+SIZE (amalgalite-1.6.1.gem) = 2134528
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/ruby-amalgalite/pkg/PLIST,v
retrieving revision 1.6
diff -u -p -r1.6 PLIST
--- pkg/PLIST   4 Nov 2016 21:27:44 -   1.6
+++ pkg/PLIST   19 Jul 2018 19:44:58 -
@@ -84,6 +84,7 @@ ${GEM_LIB}/gems/${DISTNAME}/spec/default
 ${GEM_LIB}/gems/${DISTNAME}/spec/function_spec.rb
 ${GEM_LIB}/gems/${DISTNAME}/spec/integeration_spec.rb
 ${GEM_LIB}/gems/${DISTNAME}/spec/iso_3166_database.rb
+${GEM_LIB}/gems/${DISTNAME}/spec/json_spec.rb
 ${GEM_LIB}/gems/${DISTNAME}/spec/packer_spec.rb
 ${GEM_LIB}/gems/${DISTNAME}/spec/paths_spec.rb
 ${GEM_LIB}/gems/${DISTNAME}/spec/progress_handler_spec.rb

Re: NEW: security/libmodsecurity

[Christian Weisgerber]

On 2018-07-19, Juan Francisco Cantero Hurtado  wrote:

> I saw that but our flags are passed at the end and have priority over
> O3. I just want to avoid the extra patches.

That's insufficient.  If I specify CFLAGS='' that's supposed to work and
should not require -O0.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

ruby-tiny_tds 2.1.0 -> 2.1.2

[Jeremy Evans]

Simple update to the latest tiny_tds release.  Changes:

Use Kernel.BigDecimal vs BigDecimal.new. Fixes #409.
Change DBSETUTF16 abscence warning message. Fixes #410.
Add Windows binary for Ruby-2.5. Fixes #408.
Move message_handler from a shared value to userdata.

Will commit next weeak unless I hear objections.

Thanks,
Jeremy

Index: Makefile
===
RCS file: /cvs/ports/databases/ruby-tiny_tds/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- Makefile13 Jun 2018 22:26:52 -  1.17
+++ Makefile19 Jul 2018 19:36:42 -
@@ -2,8 +2,7 @@
 
 COMMENT =  simple and fast ruby binding to FreeTDS
 
-DISTNAME = tiny_tds-2.1.0
-REVISION = 0
+DISTNAME = tiny_tds-2.1.2
 CATEGORIES =   databases
 
 HOMEPAGE = https://github.com/rails-sqlserver/tiny_tds
Index: distinfo
===
RCS file: /cvs/ports/databases/ruby-tiny_tds/distinfo,v
retrieving revision 1.8
diff -u -p -r1.8 distinfo
--- distinfo13 Nov 2017 22:44:18 -  1.8
+++ distinfo19 Jul 2018 19:36:46 -
@@ -1,2 +1,2 @@
-SHA256 (tiny_tds-2.1.0.gem) = t8kdRwDGobpicLQKfB+6UPls3qfiliH2CLFZ241ugN0=
-SIZE (tiny_tds-2.1.0.gem) = 59904
+SHA256 (tiny_tds-2.1.2.gem) = 13UohfAlOs9rcHhleCXWssWXEV8DIVwrm9+gpjgOVnw=
+SIZE (tiny_tds-2.1.2.gem) = 59904
Index: pkg/PLIST
===
RCS file: /cvs/ports/databases/ruby-tiny_tds/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST   13 Nov 2017 22:44:18 -  1.9
+++ pkg/PLIST   19 Jul 2018 19:39:32 -
@@ -21,7 +21,6 @@ ${GEM_LIB}/gems/${DISTNAME}/appveyor.yml
 ${GEM_LIB}/gems/${DISTNAME}/bin/
 ${GEM_LIB}/gems/${DISTNAME}/bin/defncopy-ttds
 ${GEM_LIB}/gems/${DISTNAME}/bin/tsql-ttds
-${GEM_LIB}/gems/${DISTNAME}/circle.yml
 ${GEM_LIB}/gems/${DISTNAME}/exe/
 ${GEM_LIB}/gems/${DISTNAME}/exe/.keep
 ${GEM_LIB}/gems/${DISTNAME}/lib/

Re: NEW: security/libmodsecurity

[Juan Francisco Cantero Hurtado]

On Thu, Jul 19, 2018 at 06:01:41PM +0200, Juan Francisco Cantero Hurtado wrote:
> On Thu, Jul 19, 2018 at 05:28:17PM +0200, Klemens Nanni wrote:
> > On Thu, Jul 19, 2018 at 04:43:30PM +0200, Juan Francisco Cantero Hurtado 
> > wrote:
> > > I need the library for the upcoming nginx-modsecurity package.
> > > C patches by robert@.
> 
> Thanks for the review.
> 
> > sparc64:
> > 
> > cc1plus: error: unrecognized command line option "-std=c++11"
> > 
> 
> I added COMPILER to the port.
> 
> > Lots of `-O3' as well, please get rid of these and ensure that *FLAGS
> > get through.
> 
> I saw that but our flags are passed at the end and have priority over
> O3. I just want to avoid the extra patches.
> 
> > 
> > Nit picking: Can you split CONFIGURE_ARGS and sort it alphabetically?
> > 
> 
> Done. New tarball attached.

And new tarball with configure args splitted. Sorry for the double
posting.


-- 
Juan Francisco Cantero Hurtado http://juanfra.info


libmodsecurity.tar.gz
Description: application/gzip

Re: troubles building devel/avr

[Stuart Cassoff]

Oh that I know about.
It's the annoying thing that makes 'make plist' take so long now. :D
I didn't think about just using it from the command line, which is handy.


Stu

> -- Original Message --
> From: Rafael Sadowski 
> Date: July 19, 2018 at 11:49 AM
> 
> 
> On Thu Jul 19, 2018 at 11:13:51AM -0400, Stuart Cassoff wrote:
> > Wow, cool tool!
> > How long has pkglocate been around?
> > Why didn't anybody tell me?
> 
> 
> https://marc.info/?l=openbsd-ports-cvs&m=152587428913413&w=2
> https://marc.info/?l=openbsd-ports&m=153020995203980&w=2
> 
> have fun ;)
> 
> > 
> > Stu
> > > -- Original Message --
> > > From: Marc Espie 
> > > Date: July 19, 2018 at 11:00 AM
> > > 
> > > 
> > > On Thu, Jul 19, 2018 at 04:15:43PM +0200, Grégoire Jadi wrote:
> > > > Hello ports@,
> > > > 
> > > > I have troubles building gcc and gdb from devel/avr. avr-binutils and
> > > > avr-libc build fine. I have two boxes: one running the latest snapshot
> > > > and one following -current from sources. I encounter the same problem on
> > > > both boxes.
> > > > 
> > > > # gcc
> > > > 
> > > > I manage to build avr-gcc by removing `-I /usr/local/include' from the
> > > > CFLAGS.
> > > > 
> > > > libiberty includes "ansidecl.h". Because of the -I command, it picked
> > > > the one from /usr/local/include instead of the one bundled with gcc and
> > > > they differ a lot. /usr/local/include/ansidecl.h has no macros PARAMS,
> > > > VA_OPEN, etc.
> > > > 
> > > > I don't understand why the -I command is used but I also don't
> > > > understand why it didn't work for me though someone™ is clearly building
> > > > the binary packages for pkg_add...
> > > 
> > > pkglocate ansidecl.h
> > > will tell you it comes from the gdb port.
> > > 
> > > maybe the guys who built the package didn't have it installed on their
> > > system ? Not that surprising... considering it's not a hugely frequent
> > > dependency. sqlports gives me only qt-creator, ocaml, rust, and gnustep's
> > > projectcenter.
> > > 
> > > Anyway, it's a bug. If you can provide a patch, that will help.
> > > 
> > > 
> > > > - Did I messed up my installations and have the wrong ansidecl.h file?
> > > > - Do package builders use a different configuration than the Makefile in
> > > >   ports? (I've never tried dpb(1))
> > > 
> > > You should :)
> > > 
> > > package builders start builds on clean systems. Personally, I do 
> > > everything
> > > in a separate chroot, and dpb periodically removes dependencies (because
> > > otherwise, it would overflow about everything).
> > > 
> > > You actually *don't* have an ansidecl.h file on a base system. Certainly
> > > not under /usr/local.
> > > 
> > > 
> > > > # gdb
> > > > 
> > > > gdb-6.8.tar.gz cannot be found on any GNU mirrors (the closer is
> > > > gdb-6.8a.tar.gz). And the fallback on OpenBSD distfiles fails too
> > > > because it tries to fetch distfiles/gdb/gdb/gdb-6.8.tar.gz instead of
> > > > distfiles/gdb/gdb-6.8.tar.gz (two /gdb/ is too much).
> > > 
> > > Nope, not any more. You're not -current.  About one week behind, I 
> > > believe.
> > > 
> > > > Hardcoding MASTER_SITES to
> > > > https://ftp.openbsd.org/pub/OpenBSD/distfiles/gdb/ did the trick.
> > > > 
> > > > But again, how can the packages be built if the URLs fails?
> > > 
> > > People did grab the distfiles  before it vanished.
> > > 
> > > > 
> > > > So, what am I doing wrong? Did I miss some configuration steps or
> > > > misread some documentation?
> > > 
> > > You are missing quite a few clues, yes.
> > > 
> > > New to OpenBSD ?...
> > >
> > 
>

Re: NEW: security/libmodsecurity

[Juan Francisco Cantero Hurtado]

On Thu, Jul 19, 2018 at 05:28:17PM +0200, Klemens Nanni wrote:
> On Thu, Jul 19, 2018 at 04:43:30PM +0200, Juan Francisco Cantero Hurtado 
> wrote:
> > I need the library for the upcoming nginx-modsecurity package.
> > C patches by robert@.

Thanks for the review.

> sparc64:
> 
>   cc1plus: error: unrecognized command line option "-std=c++11"
> 

I added COMPILER to the port.

> Lots of `-O3' as well, please get rid of these and ensure that *FLAGS
> get through.

I saw that but our flags are passed at the end and have priority over
O3. I just want to avoid the extra patches.

> 
> Nit picking: Can you split CONFIGURE_ARGS and sort it alphabetically?
> 

Done. New tarball attached.

-- 
Juan Francisco Cantero Hurtado http://juanfra.info


libmodsecurity.tar.gz
Description: application/gzip

Re: REMOVE: x11/partiwm

[Elias M. Mariani]

OK,
Nothing personal against the port.
It's just that I think on this port that:
- Is "defunct".
- The only uniqueness is xpra and is now a separate project.
- python 2 only. And my personal concern is that the end of support of
python 2 is coming, of course one can not only remove a port just
because is not python 3 ready... But in this case in the next years
wont be any effort in fixing that.
- I don't think that anyone use that port anymore, but no evidence of
that, it would be interesting to see the downloads of each package to
see if is used, not to make decisions based just on that but it would
help in this cases.

So, I will forget about removing for now, but keep it in mind for a
possible port cleanup. :)

Cheers.
Elias.

2018-07-19 10:55 GMT-03:00 Anthony J. Bentley :
> Brian Callahan writes:
>>
>> On 07/19/18 06:43, Stuart Henderson wrote:
>> > On 2018/07/19 12:41, Rafael Sadowski wrote:
>> >> On Wed Jul 18, 2018 at 08:47:18AM -0300, Elias M. Mariani wrote:
>> >>> The project is marked as "defunct".
>> >>> 8 Years without a modification.
>> >>>
>> >>> https://github.com/njsmith/partiwm
>> >>> 0*
>> >>> should we remove it?
>> >>>
>> >>> sqlite3 /usr/local/share/sqlports "select * from depends where
>> >>> dependspath like '%partiwm%';"
>> >>> Returns nothing.
>> >>>
>> >>> Cheers.
>> >>> Elias.
>> >> I see no reason to delete it, if it still works.
>> >>
>> > from the second part of DESCR:
>> >
>> > Xpra gives you "persistent remote applications" for X. That is, unlike
>> > normal X applications, applications run with xpra are "persistent" --
>> > you can run them remotely, and they don't die if your connection does.
>> > You can detach them, and reattach them later -- even from another
>> > computer -- with no loss of state. And unlike VNC or RDP, xpra is for
>> > remote applications, not remote desktops -- individual applications show
>> > up as individual windows on your screen, managed by your window manager.
>> >
>> >
>> > That sounds pretty unique. Definitely disagree with removing it if it works
>> .
>> >
>>
>> Neither a vote for or against removal but if there's concern over the
>> stagnation of this port and we would like to keep its uniqueness, there
>> is an active fork of xpra here: http://xpra.org/
>
> Indeed, it's even linked from partiwm's readme:
>
> "If you're looking for xpra, "screen for X", then this is the original
> repository -- but you probably want to instead check out the fork at
> http://xpra.org";
>

Re: troubles building devel/avr

[Rafael Sadowski]

On Thu Jul 19, 2018 at 11:13:51AM -0400, Stuart Cassoff wrote:
> Wow, cool tool!
> How long has pkglocate been around?
> Why didn't anybody tell me?


https://marc.info/?l=openbsd-ports-cvs&m=152587428913413&w=2
https://marc.info/?l=openbsd-ports&m=153020995203980&w=2

have fun ;)

> 
> Stu
> > -- Original Message --
> > From: Marc Espie 
> > Date: July 19, 2018 at 11:00 AM
> > 
> > 
> > On Thu, Jul 19, 2018 at 04:15:43PM +0200, Grégoire Jadi wrote:
> > > Hello ports@,
> > > 
> > > I have troubles building gcc and gdb from devel/avr. avr-binutils and
> > > avr-libc build fine. I have two boxes: one running the latest snapshot
> > > and one following -current from sources. I encounter the same problem on
> > > both boxes.
> > > 
> > > # gcc
> > > 
> > > I manage to build avr-gcc by removing `-I /usr/local/include' from the
> > > CFLAGS.
> > > 
> > > libiberty includes "ansidecl.h". Because of the -I command, it picked
> > > the one from /usr/local/include instead of the one bundled with gcc and
> > > they differ a lot. /usr/local/include/ansidecl.h has no macros PARAMS,
> > > VA_OPEN, etc.
> > > 
> > > I don't understand why the -I command is used but I also don't
> > > understand why it didn't work for me though someone™ is clearly building
> > > the binary packages for pkg_add...
> > 
> > pkglocate ansidecl.h
> > will tell you it comes from the gdb port.
> > 
> > maybe the guys who built the package didn't have it installed on their
> > system ? Not that surprising... considering it's not a hugely frequent
> > dependency. sqlports gives me only qt-creator, ocaml, rust, and gnustep's
> > projectcenter.
> > 
> > Anyway, it's a bug. If you can provide a patch, that will help.
> > 
> > 
> > > - Did I messed up my installations and have the wrong ansidecl.h file?
> > > - Do package builders use a different configuration than the Makefile in
> > >   ports? (I've never tried dpb(1))
> > 
> > You should :)
> > 
> > package builders start builds on clean systems. Personally, I do everything
> > in a separate chroot, and dpb periodically removes dependencies (because
> > otherwise, it would overflow about everything).
> > 
> > You actually *don't* have an ansidecl.h file on a base system. Certainly
> > not under /usr/local.
> > 
> > 
> > > # gdb
> > > 
> > > gdb-6.8.tar.gz cannot be found on any GNU mirrors (the closer is
> > > gdb-6.8a.tar.gz). And the fallback on OpenBSD distfiles fails too
> > > because it tries to fetch distfiles/gdb/gdb/gdb-6.8.tar.gz instead of
> > > distfiles/gdb/gdb-6.8.tar.gz (two /gdb/ is too much).
> > 
> > Nope, not any more. You're not -current.  About one week behind, I believe.
> > 
> > > Hardcoding MASTER_SITES to
> > > https://ftp.openbsd.org/pub/OpenBSD/distfiles/gdb/ did the trick.
> > > 
> > > But again, how can the packages be built if the URLs fails?
> > 
> > People did grab the distfiles  before it vanished.
> > 
> > > 
> > > So, what am I doing wrong? Did I miss some configuration steps or
> > > misread some documentation?
> > 
> > You are missing quite a few clues, yes.
> > 
> > New to OpenBSD ?...
> >
> 

Re: NEW: security/libmodsecurity

[Klemens Nanni]

On Thu, Jul 19, 2018 at 04:43:30PM +0200, Juan Francisco Cantero Hurtado wrote:
> I need the library for the upcoming nginx-modsecurity package.
> C patches by robert@.
sparc64:

cc1plus: error: unrecognized command line option "-std=c++11"

Lots of `-O3' as well, please get rid of these and ensure that *FLAGS
get through.

Nit picking: Can you split CONFIGURE_ARGS and sort it alphabetically?

Re: troubles building devel/avr

[Grégoire Jadi]

Marc Espie  writes:

> On Thu, Jul 19, 2018 at 04:15:43PM +0200, Grégoire Jadi wrote:
>
>> Hello ports@,
>> 
>> I have troubles building gcc and gdb from devel/avr. avr-binutils and
>> avr-libc build fine. I have two boxes: one running the latest snapshot
>> and one following -current from sources. I encounter the same problem on
>> both boxes.
>> 
>> # gcc
>> 
>> I manage to build avr-gcc by removing `-I /usr/local/include' from the
>> CFLAGS.
>> 
>> libiberty includes "ansidecl.h". Because of the -I command, it picked
>> the one from /usr/local/include instead of the one bundled with gcc and
>> they differ a lot. /usr/local/include/ansidecl.h has no macros PARAMS,
>> VA_OPEN, etc.
>> 
>> I don't understand why the -I command is used but I also don't
>> understand why it didn't work for me though someone™ is clearly building
>> the binary packages for pkg_add...
>
> pkglocate ansidecl.h
> will tell you it comes from the gdb port.
>
> maybe the guys who built the package didn't have it installed on their
> system ? Not that surprising... considering it's not a hugely frequent
> dependency. sqlports gives me only qt-creator, ocaml, rust, and gnustep's
> projectcenter.
>
> Anyway, it's a bug. If you can provide a patch, that will help.

What would be a correct fix? Removing the -I command or fixing gdb so
that the includes go into /usr/local/lib/gdb/... (or something similar
but not into /usr/local/include)?

>> - Did I messed up my installations and have the wrong ansidecl.h file?
>> - Do package builders use a different configuration than the Makefile in
>>   ports? (I've never tried dpb(1))
>
> You should :)
>
> package builders start builds on clean systems. Personally, I do everything
> in a separate chroot, and dpb periodically removes dependencies (because
> otherwise, it would overflow about everything).
>
> You actually *don't* have an ansidecl.h file on a base system. Certainly
> not under /usr/local.

Ok, I'll look at dpb :)

>> # gdb
>> 
>> gdb-6.8.tar.gz cannot be found on any GNU mirrors (the closer is
>> gdb-6.8a.tar.gz). And the fallback on OpenBSD distfiles fails too
>> because it tries to fetch distfiles/gdb/gdb/gdb-6.8.tar.gz instead of
>> distfiles/gdb/gdb-6.8.tar.gz (two /gdb/ is too much).
>
> Nope, not any more. You're not -current.  About one week behind, I
> believe.

Ok. I will check, upgrade and report if it fails.

>> Hardcoding MASTER_SITES to
>> https://ftp.openbsd.org/pub/OpenBSD/distfiles/gdb/ did the trick.
>> 
>> But again, how can the packages be built if the URLs fails?
>
> People did grab the distfiles  before it vanished.

Ok. Is it a bug or is it expected?

>> 
>> So, what am I doing wrong? Did I miss some configuration steps or
>> misread some documentation?
>
> You are missing quite a few clues, yes.
>
> New to OpenBSD ?...

Yes. I hope I won't miss the same clues again :)


Thank you for your answers.
Best,

Re: troubles building devel/avr

[Stuart Cassoff]

Wow, cool tool!
How long has pkglocate been around?
Why didn't anybody tell me?

Stu
> -- Original Message --
> From: Marc Espie 
> Date: July 19, 2018 at 11:00 AM
> 
> 
> On Thu, Jul 19, 2018 at 04:15:43PM +0200, Grégoire Jadi wrote:
> > Hello ports@,
> > 
> > I have troubles building gcc and gdb from devel/avr. avr-binutils and
> > avr-libc build fine. I have two boxes: one running the latest snapshot
> > and one following -current from sources. I encounter the same problem on
> > both boxes.
> > 
> > # gcc
> > 
> > I manage to build avr-gcc by removing `-I /usr/local/include' from the
> > CFLAGS.
> > 
> > libiberty includes "ansidecl.h". Because of the -I command, it picked
> > the one from /usr/local/include instead of the one bundled with gcc and
> > they differ a lot. /usr/local/include/ansidecl.h has no macros PARAMS,
> > VA_OPEN, etc.
> > 
> > I don't understand why the -I command is used but I also don't
> > understand why it didn't work for me though someone™ is clearly building
> > the binary packages for pkg_add...
> 
> pkglocate ansidecl.h
> will tell you it comes from the gdb port.
> 
> maybe the guys who built the package didn't have it installed on their
> system ? Not that surprising... considering it's not a hugely frequent
> dependency. sqlports gives me only qt-creator, ocaml, rust, and gnustep's
> projectcenter.
> 
> Anyway, it's a bug. If you can provide a patch, that will help.
> 
> 
> > - Did I messed up my installations and have the wrong ansidecl.h file?
> > - Do package builders use a different configuration than the Makefile in
> >   ports? (I've never tried dpb(1))
> 
> You should :)
> 
> package builders start builds on clean systems. Personally, I do everything
> in a separate chroot, and dpb periodically removes dependencies (because
> otherwise, it would overflow about everything).
> 
> You actually *don't* have an ansidecl.h file on a base system. Certainly
> not under /usr/local.
> 
> 
> > # gdb
> > 
> > gdb-6.8.tar.gz cannot be found on any GNU mirrors (the closer is
> > gdb-6.8a.tar.gz). And the fallback on OpenBSD distfiles fails too
> > because it tries to fetch distfiles/gdb/gdb/gdb-6.8.tar.gz instead of
> > distfiles/gdb/gdb-6.8.tar.gz (two /gdb/ is too much).
> 
> Nope, not any more. You're not -current.  About one week behind, I believe.
> 
> > Hardcoding MASTER_SITES to
> > https://ftp.openbsd.org/pub/OpenBSD/distfiles/gdb/ did the trick.
> > 
> > But again, how can the packages be built if the URLs fails?
> 
> People did grab the distfiles  before it vanished.
> 
> > 
> > So, what am I doing wrong? Did I miss some configuration steps or
> > misread some documentation?
> 
> You are missing quite a few clues, yes.
> 
> New to OpenBSD ?...
>

Re: troubles building devel/avr

[Marc Espie]

On Thu, Jul 19, 2018 at 04:15:43PM +0200, Grégoire Jadi wrote:
> Hello ports@,
> 
> I have troubles building gcc and gdb from devel/avr. avr-binutils and
> avr-libc build fine. I have two boxes: one running the latest snapshot
> and one following -current from sources. I encounter the same problem on
> both boxes.
> 
> # gcc
> 
> I manage to build avr-gcc by removing `-I /usr/local/include' from the
> CFLAGS.
> 
> libiberty includes "ansidecl.h". Because of the -I command, it picked
> the one from /usr/local/include instead of the one bundled with gcc and
> they differ a lot. /usr/local/include/ansidecl.h has no macros PARAMS,
> VA_OPEN, etc.
> 
> I don't understand why the -I command is used but I also don't
> understand why it didn't work for me though someone™ is clearly building
> the binary packages for pkg_add...

pkglocate ansidecl.h
will tell you it comes from the gdb port.

maybe the guys who built the package didn't have it installed on their
system ? Not that surprising... considering it's not a hugely frequent
dependency. sqlports gives me only qt-creator, ocaml, rust, and gnustep's
projectcenter.

Anyway, it's a bug. If you can provide a patch, that will help.


> - Did I messed up my installations and have the wrong ansidecl.h file?
> - Do package builders use a different configuration than the Makefile in
>   ports? (I've never tried dpb(1))

You should :)

package builders start builds on clean systems. Personally, I do everything
in a separate chroot, and dpb periodically removes dependencies (because
otherwise, it would overflow about everything).

You actually *don't* have an ansidecl.h file on a base system. Certainly
not under /usr/local.


> # gdb
> 
> gdb-6.8.tar.gz cannot be found on any GNU mirrors (the closer is
> gdb-6.8a.tar.gz). And the fallback on OpenBSD distfiles fails too
> because it tries to fetch distfiles/gdb/gdb/gdb-6.8.tar.gz instead of
> distfiles/gdb/gdb-6.8.tar.gz (two /gdb/ is too much).

Nope, not any more. You're not -current.  About one week behind, I believe.

> Hardcoding MASTER_SITES to
> https://ftp.openbsd.org/pub/OpenBSD/distfiles/gdb/ did the trick.
> 
> But again, how can the packages be built if the URLs fails?

People did grab the distfiles  before it vanished.

> 
> So, what am I doing wrong? Did I miss some configuration steps or
> misread some documentation?

You are missing quite a few clues, yes.

New to OpenBSD ?...

PATCH: www/nginx, new modsecurity package

[Juan Francisco Cantero Hurtado]

Builds fine and the debug log says that the module is working. The port
requires libmodsecurity which I sent a few minutes ago.

OK?


Index: Makefile
===
--- Makefile(revision 130669)
+++ Makefile(working copy)
@@ -13,8 +13,10 @@
 COMMENT-headers_more=  nginx module for setting/adding/clearing headers
 COMMENT-perl=  nginx perl scripting module
 COMMENT-passenger= nginx passenger (ruby/python/nodejs) integration module
+COMMENT-modsecurity=   nginx modsecurity module
 
 VERSION=   1.14.0
+REVISION=  0
 DISTNAME=  nginx-${VERSION}
 CATEGORIES=www
 
@@ -29,6 +31,7 @@
 PKGNAME-headers_more=  nginx-headers-more-${VERSION}
 PKGNAME-perl=  nginx-perl-${VERSION}
 PKGNAME-passenger= nginx-passenger-${VERSION}
+PKGNAME-modsecurity=   nginx-modsecurity-${VERSION}
 
 MASTER_SITES=  https://nginx.org/download/
 MASTER_SITES0= https://github.com/simpl/ngx_devel_kit/archive/
@@ -36,12 +39,14 @@
 MASTER_SITES2= https://github.com/openresty/lua-nginx-module/archive/
 MASTER_SITES3= 
https://raw.githubusercontent.com/rnagy/nginx_chroot_patch/master/
 MASTER_SITES4= https://github.com/openresty/headers-more-nginx-module/archive/
+MASTER_SITES5= 
https://github.com/SpiderLabs/ModSecurity-nginx/releases/download/v1.0.0/
 
 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} \
ngx_devel_kit-v0.3.0.tar.gz{v0.3.0.tar.gz}:0 \
naxsi-0.55.3.tar.gz{0.55.3.tar.gz}:1 \
lua-nginx-module-v0.10.11.tar.gz{v0.10.11.tar.gz}:2 \
-   headers-more-nginx-module-v0.33.tar.gz{v0.33.tar.gz}:4
+   headers-more-nginx-module-v0.33.tar.gz{v0.33.tar.gz}:4 \
+   modsecurity-nginx-v1.0.0.tar.gz:5
 
 HOMEPAGE=  http://nginx.org/
 
@@ -51,7 +56,7 @@
 PERMIT_PACKAGE_CDROM=  yes
 
 MULTI_PACKAGES =   -main -image_filter -geoip -xslt -mailproxy -stream \
-   -naxsi -perl -passenger -headers_more -lua
+   -naxsi -perl -passenger -headers_more -lua -modsecurity
 
 FLAVOR ?=
 PSEUDO_FLAVORS =   no_lua
@@ -69,6 +74,7 @@
 WANTLIB-headers_more=
 WANTLIB-perl=  c m perl
 WANTLIB-passenger= m pthread ${COMPILER_LIBCXX}
+WANTLIB-modsecurity=   modsecurity
 
 BUILD_DEPENDS+=
${MODRUBY_PKG_PREFIX}-passenger-*:www/ruby-passenger
 
@@ -78,6 +84,7 @@
 LIB_DEPENDS-image_filter=graphics/gd
 LIB_DEPENDS-geoip= net/GeoIP
 LIB_DEPENDS-lua=   ${MODLUA_LIB_DEPENDS}
+LIB_DEPENDS-modsecurity=security/libmodsecurity
 
 RUN_DEPENDS-main=  # blank (override addition from lua.port.mk)
 RUN_DEPENDS-mailproxy= www/nginx,-main=${VERSION}
@@ -91,6 +98,7 @@
 RUN_DEPENDS-perl=  www/nginx,-main=${VERSION}
 RUN_DEPENDS-passenger= www/nginx,-main=${VERSION} \
ruby*-passenger-*:www/ruby-passenger
+RUN_DEPENDS-modsecurity=www/nginx,-main=${VERSION}
 
 NGINX_DIR= /var/www
 SUBST_VARS=NGINX_DIR
@@ -104,6 +112,7 @@
 PREFIX-lua=${NGINX_MODULES_DIR}
 PREFIX-headers_more=   ${NGINX_MODULES_DIR}
 PREFIX-passenger=  ${NGINX_MODULES_DIR}
+PREFIX-modsecurity=${NGINX_MODULES_DIR}
 
 CFLAGS+=   -Wall -Wpointer-arith \
-I "${LOCALBASE}/include/libxml2" \
@@ -122,7 +131,9 @@
 .if ${BUILD_PACKAGES:M-lua}
 MODULES+=  lang/lua
 CONFIGURE_ENV+=MODLUA_INCL_DIR=${MODLUA_INCL_DIR} \
-   MODLUA_LIB=${MODLUA_LIB}
+   MODLUA_LIB=${MODLUA_LIB} \
+   MODSECURITY_INC="${LOCALBASE}/include/modsecurity" \
+   MODSECURITY_LIB="${LOCALBASE}/lib"
 CONFIGURE_ARGS+=   --add-dynamic-module=${WRKSRC}/lua-nginx-module
 .endif
 
@@ -157,7 +168,8 @@
--add-dynamic-module=${WRKSRC}/naxsi/naxsi_src/ \
--add-dynamic-module=${WRKSRC}/ngx_devel_kit \

--add-dynamic-module=${WRKSRC}/headers-more-nginx-module \
-   
--add-dynamic-module=${LOCALBASE}/lib/phusion-passenger${GEM_BIN_SUFFIX}/src/nginx_module
+   
--add-dynamic-module=${LOCALBASE}/lib/phusion-passenger${GEM_BIN_SUFFIX}/src/nginx_module
 \
+   --add-dynamic-module=${WRKSRC}/modsecurity-nginx
 
 SUBSTFILES=conf/nginx.conf \
lua-nginx-module/config
@@ -171,7 +183,8 @@
cd ${WRKSRC} && \
mv ../ngx_devel_kit-* ngx_devel_kit && \
mv ../lua-nginx-module-* lua-nginx-module && \
-   mv ../headers-more-nginx-module-* headers-more-nginx-module
+   mv ../headers-more-nginx-module-* headers-more-nginx-module && \
+   mv ../modsecurity-nginx-* modsecurity-nginx
 
 pre-configure:
@cd ${WRKSRC} && ${SUBST_CMD} ${SUBSTFILES}
Index: distinfo
===
--- distinfo(revision 130669)
+++ distinfo(working copy)
@@ -1,5 +1,6 @@
 SHA256 (headers-more-ngin

Re: REMOVE: x11/partiwm

[Renaud Allard]

On 07/19/2018 03:55 PM, Anthony J. Bentley wrote:


That sounds pretty unique. Definitely disagree with removing it if it works

.




Neither a vote for or against removal but if there's concern over the
stagnation of this port and we would like to keep its uniqueness, there
is an active fork of xpra here: http://xpra.org/


Indeed, it's even linked from partiwm's readme:

"If you're looking for xpra, "screen for X", then this is the original
repository -- but you probably want to instead check out the fork at
http://xpra.org";



I haven't used it for a while now, but if I remember well, the code at 
xpra.org doesn't compile properly on OpenBSD and/or is not fully 
functional without other components which don't compile properly.
So, unless someone make a functional port from xpra.org, it's better to 
keep partiwm.




smime.p7s
Description: S/MIME Cryptographic Signature

NEW: security/libmodsecurity

[Juan Francisco Cantero Hurtado]

I need the library for the upcoming nginx-modsecurity package.
C patches by robert@.

OK?

Comment:
library used by the modsecurity modules

Description:
ModSecurity is an open source, cross platform web application firewall (WAF)
engine for Apache and Nginx that is developed by Trustwave's SpiderLabs.
It has a robust event-based programming language which provides protection from
a range of attacks against web applications and allows for HTTP traffic
monitoring, logging and real-time analysis.

This package provides the common library needed by the server modules.

Maintainer: The OpenBSD ports mailing-list 

WWW: https://github.com/SpiderLabs/ModSecurity




libmodsecurity.tar.gz
Description: application/gzip

Re: shells/ksh93 no distfiles available, new github repo with Meson build

[Pascal Stumpf]

On Mon, 16 Jul 2018 12:16:21 +0200, Andreas Kusalananda =?iso-8859-1?B?S+Ro5HJp
?= wrote:
> 
> Hi,
> 
> I noticed the other day that the shells/ksh93 port stopped building due
> to none of the distfiles being available.
> 
> I also noticed that the ksh93 shell now has a GitHub repository set
> up at https://github.com/att/ast (the license is EPL-1.0) and that
> it _finally_ uses a more modern build system (Meson, and it builds
> surprisingly quickly).
> 
> The shell is still ksh93u+, but there's also a ksh93v- (beta?) release.
> 
> Before I start writing a patch for this, are you (Pascal) planning on
> updating the port?

I'm working on an update to ksh93v-, although the build system is still
the traditional one in that particular tarball.  It may be best to wait
for a final release that builds with meson.

> Regards,
> 
> -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure
> Sweden (NBIS), Uppsala University, Sweden.
> 
> 
> 
> 
> 
> 
> 
> 
> När du har kontakt med oss på Uppsala universitet med e-post
> så innebär det att vi behandlar dina personuppgifter.
> För att läsa mer om hur vi gör det kan du läsa här:
> http://www.uu.se/om-uu/dataskydd-personuppgifter/
> 
> E-mailing Uppsala University means that we will process your personal
> data. For more information on how this is performed, please read here:
> http://www.uu.se/om-uu/dataskydd-personuppgifter/

troubles building devel/avr

[Grégoire Jadi]

Hello ports@,

I have troubles building gcc and gdb from devel/avr. avr-binutils and
avr-libc build fine. I have two boxes: one running the latest snapshot
and one following -current from sources. I encounter the same problem on
both boxes.

# gcc

I manage to build avr-gcc by removing `-I /usr/local/include' from the
CFLAGS.

libiberty includes "ansidecl.h". Because of the -I command, it picked
the one from /usr/local/include instead of the one bundled with gcc and
they differ a lot. /usr/local/include/ansidecl.h has no macros PARAMS,
VA_OPEN, etc.

I don't understand why the -I command is used but I also don't
understand why it didn't work for me though someone™ is clearly building
the binary packages for pkg_add...

- Did I messed up my installations and have the wrong ansidecl.h file?
- Do package builders use a different configuration than the Makefile in
  ports? (I've never tried dpb(1))

# gdb

gdb-6.8.tar.gz cannot be found on any GNU mirrors (the closer is
gdb-6.8a.tar.gz). And the fallback on OpenBSD distfiles fails too
because it tries to fetch distfiles/gdb/gdb/gdb-6.8.tar.gz instead of
distfiles/gdb/gdb-6.8.tar.gz (two /gdb/ is too much).

Hardcoding MASTER_SITES to
https://ftp.openbsd.org/pub/OpenBSD/distfiles/gdb/ did the trick.

But again, how can the packages be built if the URLs fails?


So, what am I doing wrong? Did I miss some configuration steps or
misread some documentation?

Best,

Re: REMOVE: x11/partiwm

[Anthony J. Bentley]

Brian Callahan writes:
> 
> On 07/19/18 06:43, Stuart Henderson wrote:
> > On 2018/07/19 12:41, Rafael Sadowski wrote:
> >> On Wed Jul 18, 2018 at 08:47:18AM -0300, Elias M. Mariani wrote:
> >>> The project is marked as "defunct".
> >>> 8 Years without a modification.
> >>>
> >>> https://github.com/njsmith/partiwm
> >>> 0*
> >>> should we remove it?
> >>>
> >>> sqlite3 /usr/local/share/sqlports "select * from depends where
> >>> dependspath like '%partiwm%';"
> >>> Returns nothing.
> >>>
> >>> Cheers.
> >>> Elias.
> >> I see no reason to delete it, if it still works.
> >>
> > from the second part of DESCR:
> >
> > Xpra gives you "persistent remote applications" for X. That is, unlike
> > normal X applications, applications run with xpra are "persistent" --
> > you can run them remotely, and they don't die if your connection does.
> > You can detach them, and reattach them later -- even from another
> > computer -- with no loss of state. And unlike VNC or RDP, xpra is for
> > remote applications, not remote desktops -- individual applications show
> > up as individual windows on your screen, managed by your window manager.
> >
> >
> > That sounds pretty unique. Definitely disagree with removing it if it works
> .
> >
>
> Neither a vote for or against removal but if there's concern over the 
> stagnation of this port and we would like to keep its uniqueness, there 
> is an active fork of xpra here: http://xpra.org/

Indeed, it's even linked from partiwm's readme:

"If you're looking for xpra, "screen for X", then this is the original
repository -- but you probably want to instead check out the fork at
http://xpra.org";

Re: REMOVE: x11/partiwm

[Brian Callahan]

On 07/19/18 06:43, Stuart Henderson wrote:

On 2018/07/19 12:41, Rafael Sadowski wrote:

On Wed Jul 18, 2018 at 08:47:18AM -0300, Elias M. Mariani wrote:

The project is marked as "defunct".
8 Years without a modification.

https://github.com/njsmith/partiwm
0*
should we remove it?

sqlite3 /usr/local/share/sqlports "select * from depends where
dependspath like '%partiwm%';"
Returns nothing.

Cheers.
Elias.

I see no reason to delete it, if it still works.


from the second part of DESCR:

Xpra gives you "persistent remote applications" for X. That is, unlike
normal X applications, applications run with xpra are "persistent" --
you can run them remotely, and they don't die if your connection does.
You can detach them, and reattach them later -- even from another
computer -- with no loss of state. And unlike VNC or RDP, xpra is for
remote applications, not remote desktops -- individual applications show
up as individual windows on your screen, managed by your window manager.


That sounds pretty unique. Definitely disagree with removing it if it works.



Neither a vote for or against removal but if there's concern over the 
stagnation of this port and we would like to keep its uniqueness, there 
is an active fork of xpra here: http://xpra.org/


~Brian

Re: [patch] audio/openal: ugly update to 1.18.2

[Leonid Bobrov]

From: Alexandre Ratchov 

If I understand correctly, 1.18.2 playback support works, but the new
recording support breaks few programs. If so, if we upgrade to 1.18.2
with recording disabled, we'd get the same functionality as the
current port. Is this correct.

If so, I'd suggest to quickly switch to 1.18.2, then fix recording in
tree on a more recent code base. Would that make sense?

Yes, that will make giving patches to upstream easier so we won't need
them in the future...

Re: [patch] audio/openal: ugly update to 1.18.2

[David CARLIER]

I do agree I tested locally the unpatched version with few softwares
and worked fine.
On Thu, 19 Jul 2018 at 11:18, Alexandre Ratchov  wrote:
>
> On Thu, Jul 19, 2018 at 11:56:14AM +0300, Leonid Bobrov wrote:
> >   From: Alexandre Ratchov 
> >
> >   On Mon, Jul 16, 2018 at 12:06:33AM +0300, Leonid Bobrov wrote:
> >   > update to openal 1.18.2 and use only portaudio?
> >
> >   What's wrong with 1.18.2's sndio bits? Is it a regression in upstream
> >   sndio support? You mentionned crashes, could you provide more details,
> >   especially what crashes, how to reproduce them so they get fixed?
> >
> > Just compile openal 1.18.2 with sndio support at any OS, then start any
> > application depending on openal and using audio input. After start you
> > get segmentation fault immediately. No need to know steps to reproduce
> > this, I am sure kcat after writting Alc/backends/sndio.c didn't try to
> > actually start any application which uses audio input.
>
> If I understand correctly, 1.18.2 playback support works, but the new
> recording support breaks few programs. If so, if we upgrade to 1.18.2
> with recording disabled, we'd get the same functionality as the
> current port. Is this correct.
>
> If so, I'd suggest to quickly switch to 1.18.2, then fix recording in
> tree on a more recent code base. Would that make sense?

Re: shells/ksh93 no distfiles available, new github repo with Meson build

[Marc Espie]

On Thu, Jul 19, 2018 at 11:49:12AM +0100, Stuart Henderson wrote:
> On 2018/07/19 12:41, Rafael Sadowski wrote:
> > On Mon Jul 16, 2018 at 12:16:21PM +0200, Andreas Kusalananda Kähäri wrote:
> > > 
> > > Hi,
> > > 
> > > I noticed the other day that the shells/ksh93 port stopped building due
> > > to none of the distfiles being available.
> 
> I've just put a copy of these on my mirror and updated MASTER_SITES in the
> port, but it shouldn't have prevented the port from building as they're
> available on ftp.openbsd.org.

... except that the port has a DIST_SUBDIR... I fixed that very recently
when I got MASTER_SITE_BACKUP cleaned up.

Re: shells/ksh93 no distfiles available, new github repo with Meson build

[Marc Espie]

On Thu, Jul 19, 2018 at 12:41:53PM +0200, Rafael Sadowski wrote:
> On Mon Jul 16, 2018 at 12:16:21PM +0200, Andreas Kusalananda Kähäri wrote:
> > 
> > Hi,
> > 
> > I noticed the other day that the shells/ksh93 port stopped building due
> > to none of the distfiles being available.

Nope, it was actually a bug in mirror handling that got fixed since then.

The backup copy on ftp.openbsd.org is alive and well.

Re: [patch] audio/openal: ugly update to 1.18.2

[Alexandre Ratchov]

On Thu, Jul 19, 2018 at 11:56:14AM +0300, Leonid Bobrov wrote:
>   From: Alexandre Ratchov 
> 
>   On Mon, Jul 16, 2018 at 12:06:33AM +0300, Leonid Bobrov wrote:
>   > update to openal 1.18.2 and use only portaudio?
> 
>   What's wrong with 1.18.2's sndio bits? Is it a regression in upstream
>   sndio support? You mentionned crashes, could you provide more details,
>   especially what crashes, how to reproduce them so they get fixed?
> 
> Just compile openal 1.18.2 with sndio support at any OS, then start any
> application depending on openal and using audio input. After start you
> get segmentation fault immediately. No need to know steps to reproduce
> this, I am sure kcat after writting Alc/backends/sndio.c didn't try to
> actually start any application which uses audio input.

If I understand correctly, 1.18.2 playback support works, but the new
recording support breaks few programs. If so, if we upgrade to 1.18.2
with recording disabled, we'd get the same functionality as the
current port. Is this correct.

If so, I'd suggest to quickly switch to 1.18.2, then fix recording in
tree on a more recent code base. Would that make sense?

Re: shells/ksh93 no distfiles available, new github repo with Meson build

[Stuart Henderson]

On 2018/07/19 12:41, Rafael Sadowski wrote:
> On Mon Jul 16, 2018 at 12:16:21PM +0200, Andreas Kusalananda Kähäri wrote:
> > 
> > Hi,
> > 
> > I noticed the other day that the shells/ksh93 port stopped building due
> > to none of the distfiles being available.

I've just put a copy of these on my mirror and updated MASTER_SITES in the
port, but it shouldn't have prevented the port from building as they're
available on ftp.openbsd.org.

Re: REMOVE: x11/partiwm

[Stuart Henderson]

On 2018/07/19 12:41, Rafael Sadowski wrote:
> On Wed Jul 18, 2018 at 08:47:18AM -0300, Elias M. Mariani wrote:
> > The project is marked as "defunct".
> > 8 Years without a modification.
> > 
> > https://github.com/njsmith/partiwm
> > 
> > should we remove it?
> > 
> > sqlite3 /usr/local/share/sqlports "select * from depends where
> > dependspath like '%partiwm%';"
> > Returns nothing.
> > 
> > Cheers.
> > Elias.
> 
> I see no reason to delete it, if it still works.
> 

from the second part of DESCR:

Xpra gives you "persistent remote applications" for X. That is, unlike
normal X applications, applications run with xpra are "persistent" --
you can run them remotely, and they don't die if your connection does.
You can detach them, and reattach them later -- even from another
computer -- with no loss of state. And unlike VNC or RDP, xpra is for
remote applications, not remote desktops -- individual applications show
up as individual windows on your screen, managed by your window manager.


That sounds pretty unique. Definitely disagree with removing it if it works.

Re: shells/ksh93 no distfiles available, new github repo with Meson build

[Rafael Sadowski]

On Mon Jul 16, 2018 at 12:16:21PM +0200, Andreas Kusalananda Kähäri wrote:
> 
> Hi,
> 
> I noticed the other day that the shells/ksh93 port stopped building due
> to none of the distfiles being available.
> 
> I also noticed that the ksh93 shell now has a GitHub repository set
> up at https://github.com/att/ast (the license is EPL-1.0) and that
> it _finally_ uses a more modern build system (Meson, and it builds
> surprisingly quickly).
> 
> The shell is still ksh93u+, but there's also a ksh93v- (beta?) release.
> 
> Before I start writing a patch for this, are you (Pascal) planning on
> updating the port?
> 
Personally I would like to see an update. I have a math/graphviz update
diff in my pipeline, so I could tests your work with upcoming graphviz
test suite.

Re: REMOVE: x11/partiwm

[Rafael Sadowski]

On Wed Jul 18, 2018 at 08:47:18AM -0300, Elias M. Mariani wrote:
> The project is marked as "defunct".
> 8 Years without a modification.
> 
> https://github.com/njsmith/partiwm
> 
> should we remove it?
> 
> sqlite3 /usr/local/share/sqlports "select * from depends where
> dependspath like '%partiwm%';"
> Returns nothing.
> 
> Cheers.
> Elias.

I see no reason to delete it, if it still works.

Re: [patch] audio/openal: ugly update to 1.18.2

[Stuart Henderson]

On 2018/07/19 12:39, Leonid Bobrov wrote:
>   From: David CARLIER 
> 
>   But the unpatched version does not support recording if I m not
>   mistaken ? Maybe then the software is looking for a device recording
>   which does not exist ? I forgot the name of the functions but
>   definitively a stacktrace would help (we got a crash with ioquake3
>   last year because of this it assumed there was a recoding device).
> 
> Sure it doesn't have recording support, I told that from the beginning.
> 
> Sure, software is looking for 3 "non existing" microphones connected to
> my laptop.
> 
> How am I supposed to send a stacktrace if something strips debug symbols
> after compiling audio/openal with MODCMAKE_DEBUG?
> 

MODCMAKE_DEBUG doesn't do what you think.

Build with DEBUG=-g, the same as is expected to work with the base OS
and most ports.

Re: [patch] audio/openal: ugly update to 1.18.2

[Leonid Bobrov]

From: David CARLIER 

But the unpatched version does not support recording if I m not
mistaken ? Maybe then the software is looking for a device recording
which does not exist ? I forgot the name of the functions but
definitively a stacktrace would help (we got a crash with ioquake3
last year because of this it assumed there was a recoding device).

Sure it doesn't have recording support, I told that from the beginning.

Sure, software is looking for 3 "non existing" microphones connected to
my laptop.

How am I supposed to send a stacktrace if something strips debug symbols
after compiling audio/openal with MODCMAKE_DEBUG?

Re: [patch] audio/openal: ugly update to 1.18.2

[Leonid Bobrov]

From: David CARLIER 

By the way when you said you tested 1.18.2 was it the patched (with
recording supoprt) or unpatched ? Because I tried for couple of hours
the unpatched version with couple of video games and worked ok.

Unpatched. Do those games use audio input (that is, microphone, mixer,
something else)? If not, I am not surpriced they didn't crash.

Re: [patch] audio/openal: ugly update to 1.18.2

[David CARLIER]

Hi Leonid.
 No need to know steps to reproduce
> this, I am sure kcat after writting Alc/backends/sndio.c didn't try to

Did he ? I know him enough as he s more into Linux (we "see" each
other occasionally into gzdoom and openal)
but maybe you re right.

> actually start any application which uses audio input.

The more I read the messages I start to think like others, personal
settings issues. I feel hopeful having pure sndio play/record finally,
changing my mind :-).

Re: [patch] audio/openal: ugly update to 1.18.2

[Leonid Bobrov]

From: Alexandre Ratchov 

On Mon, Jul 16, 2018 at 12:06:33AM +0300, Leonid Bobrov wrote:
> update to openal 1.18.2 and use only portaudio?

What's wrong with 1.18.2's sndio bits? Is it a regression in upstream
sndio support? You mentionned crashes, could you provide more details,
especially what crashes, how to reproduce them so they get fixed?

Just compile openal 1.18.2 with sndio support at any OS, then start any
application depending on openal and using audio input. After start you
get segmentation fault immediately. No need to know steps to reproduce
this, I am sure kcat after writting Alc/backends/sndio.c didn't try to
actually start any application which uses audio input.

Re: [patch] audio/openal: ugly update to 1.18.2

[Alexandre Ratchov]

On Thu, Jul 19, 2018 at 11:24:16AM +0300, Leonid Bobrov wrote:
>   From: Alexandre Ratchov 
> 
>   On Sun, Jul 15, 2018 at 06:40:54AM +0300, Leonid Bobrov wrote:
>   > 
>   > The diff I use is initial one:
>   > https://marc.info/?l=openbsd-ports&m=152807586927014&w=2
>   > 
>   > ratchov@'s sndio backend is not ready yet, plus I'm afraid to keep
>   > testing it, because that made kernel panic, after that panic I 
> rebooted
>   > with corrupted FFS (I should read about sending bug reports).
>   > 
> 
>   Please let me know what doesn't work, including steps to reproduce the
>   problem. If the problem is specific to your machines, at least provide
>   a stack trace.
> 
>   The kernel crashes you mentioned (unrelated to openal) and are very
>   important to fix, see sthen@ suggestion on how to handle them.
> 
>   Note that the diff I sent doesn't affect the playback direction, so
>   verifying that it doesn't cause regressions would help as well.
> 
> The steps to reproduce are: install net/toxic, install your latest diff
> to audio/openal:
> https://marc.info/?l=openbsd-ports&m=152817852312699&w=2
> 
> Then start Toxic
> $ toxic
> and make audiocall to anybody. If you don't have contacts to test
> audiocall, add echobot to your contact list:
> /add echo...@toxme.io
> Wait few seconds, switch to buffer with echobot and use:
> /call
> Then when you're done testing audio input, end audio call:
> /hangup
> And that'll lead to segmentation fault.
> 

thanks, that's useful.

> There is a chance to catch kernel panic when testing audio call in
> Toxic with your diff to audio/openal, before I report to bugs@ I have
> to read FAQ first, then get yet another kernel panic. I should have a
> backup machine tomorrow so I won't have to worry about my personal data
> being lost when FFS will corrupt again thanks to panic.

that'd be useful starting point to analyse the kernel crash as well.

Re: [patch] audio/openal: ugly update to 1.18.2

[Alexandre Ratchov]

On Mon, Jul 16, 2018 at 12:06:33AM +0300, Leonid Bobrov wrote:
> I finished building with make(1) like Stuart Henderson suggested, no
> errors in build time, all ports built fine.
> 
> So, what's next? Make openal 1.17.2 use both sndio and portaudio, or

why? i still don't understand what's wrong with the sndio recording
code that I sent you last month. The kernel panics are unrelated.

As I mentioned, stacking multiple audio frameworks often leads to poor
audio quality (stuttering, less stable audio, broken on certain setups
etc).

> update to openal 1.18.2 and use only portaudio?

What's wrong with 1.18.2's sndio bits? Is it a regression in upstream
sndio support? You mentionned crashes, could you provide more details,
especially what crashes, how to reproduce them so they get fixed?

Re: [patch] audio/openal: ugly update to 1.18.2

[Leonid Bobrov]

From: Alexandre Ratchov 

On Sun, Jul 15, 2018 at 06:40:54AM +0300, Leonid Bobrov wrote:
> 
> The diff I use is initial one:
> https://marc.info/?l=openbsd-ports&m=152807586927014&w=2
> 
> ratchov@'s sndio backend is not ready yet, plus I'm afraid to keep
> testing it, because that made kernel panic, after that panic I 
rebooted
> with corrupted FFS (I should read about sending bug reports).
> 

Please let me know what doesn't work, including steps to reproduce the
problem. If the problem is specific to your machines, at least provide
a stack trace.

The kernel crashes you mentioned (unrelated to openal) and are very
important to fix, see sthen@ suggestion on how to handle them.

Note that the diff I sent doesn't affect the playback direction, so
verifying that it doesn't cause regressions would help as well.

The steps to reproduce are: install net/toxic, install your latest diff
to audio/openal:
https://marc.info/?l=openbsd-ports&m=152817852312699&w=2

Then start Toxic
$ toxic
and make audiocall to anybody. If you don't have contacts to test
audiocall, add echobot to your contact list:
/add echo...@toxme.io
Wait few seconds, switch to buffer with echobot and use:
/call
Then when you're done testing audio input, end audio call:
/hangup
And that'll lead to segmentation fault.

Unfortunately the trace I've sent is useless, something strips debug
symbols after I compile audio/openal with debug.

There is a chance to catch kernel panic when testing audio call in
Toxic with your diff to audio/openal, before I report to bugs@ I have
to read FAQ first, then get yet another kernel panic. I should have a
backup machine tomorrow so I won't have to worry about my personal data
being lost when FFS will corrupt again thanks to panic.

Re: [patch] audio/openal: ugly update to 1.18.2

[Alexandre Ratchov]

On Sun, Jul 15, 2018 at 06:40:54AM +0300, Leonid Bobrov wrote:
> 
> The diff I use is initial one:
> https://marc.info/?l=openbsd-ports&m=152807586927014&w=2
> 
> ratchov@'s sndio backend is not ready yet, plus I'm afraid to keep
> testing it, because that made kernel panic, after that panic I rebooted
> with corrupted FFS (I should read about sending bug reports).
> 

Please let me know what doesn't work, including steps to reproduce the
problem. If the problem is specific to your machines, at least provide
a stack trace.

The kernel crashes you mentioned (unrelated to openal) and are very
important to fix, see sthen@ suggestion on how to handle them.

Note that the diff I sent doesn't affect the playback direction, so
verifying that it doesn't cause regressions would help as well.

Re: Mark www/vimb broken

[Leonid Bobrov]

From lan...@openbsd.org Thu Jul 19 09:16:39 2018

On Thu, Jul 19, 2018 at 12:42:45AM +0300, Leonid Bobrov wrote:
> This is what I get at latest snapshot at amd64:
> https://transfer.sh/gnUY6/vimb.mpg

You've been told to use ktrace or LD_DEBUG=1 to figure out what happens
in your environment. Something is wrong *in your environment*, as vimb
works for other people. Posting a screen capture like this isnt helpful,
as you're asking ppl to do your homework.

Landry


LD_DEBUG output is not clear (there is a useless spam I am unable to
copy because it is so long that tmux doesn't scroll up to the beginning)
this all what I see when the GUI stops working:
free tib=0x1a73b4bb4600
tib new=0x1a7433e63000
tib new=0x1a748c5de400

ktrace.out is 14.5M big, so I am not sure it is a good idea to attach it
directly in mail: https://transfer.sh/Mqb9Y/ktrace.out

And GDB output:
mazocomp$ egdb vimb
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.3".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vimb...done.
(gdb) run
Starting program: /usr/local/bin/vimb
[New process 25947]
[New process 25947]
[New process 25947]
[New thread 222575]
[New thread 212795]
[New thread 340723]
[New thread 388577]
[New thread 452316]
[New thread 401452]
[New thread 584335]

Thread 1 received signal SIGUSR1, User defined signal 1.
_thread_sys_poll () at -:3
3   -: No such file or directory.
(gdb) bt
#0  _thread_sys_poll () at -:3
#1  0x139e2f33dffe in _libc_poll_cancel (fds=0x139d610ca2a0, nfds=3, 
timeout=1827315591) at /usr/src/lib/libc/sys/w_poll.c:27
#2  0x139e2885bc37 in g_main_context_poll (priority=0, context=, timeout=, fds=, n_fds=) at 
gmain.c:4204
#3  g_main_context_iterate (context=, block=, 
dispatch=, self=) at gmain.c:3898
#4  0x139e2885c08f in g_main_loop_run (loop=0x139e4449cdd0) at gmain.c:4099
#5  0x139e0e26be08 in gtk_main () at gtkmain.c:1323
#6  0x139b52608936 in main (argc=, argv=) at 
main.c:1986
(gdb) bt full
#0  _thread_sys_poll () at -:3
No locals.
#1  0x139e2f33dffe in _libc_poll_cancel (fds=0x139d610ca2a0, nfds=3, 
timeout=1827315591) at /usr/src/lib/libc/sys/w_poll.c:27
_tib = 0x139d9d7cd140
#2  0x139e2885bc37 in g_main_context_poll (priority=0, context=, timeout=, fds=, n_fds=) at 
gmain.c:4204
ret = 
errsv = 
poll_func = 0x139e2886cfa0 
#3  g_main_context_iterate (context=, block=, 
dispatch=, self=) at gmain.c:3898
fds = 0x139d610ca2a0
allocated_nfds = 3
max_priority = 
nfds = 3
timeout = 1827315591
some_ready = 
#4  0x139e2885c08f in g_main_loop_run (loop=0x139e4449cdd0) at gmain.c:4099
No locals.
#5  0x139e0e26be08 in gtk_main () at gtkmain.c:1323
loop = 0x139e4449cdd0
#6  0x139b52608936 in main (argc=, argv=) at 
main.c:1986
opts = {{long_name = 0x139b5271ea9a "embed", short_name = 101 'e', 
flags = 0, arg = G_OPTION_ARG_STRING, arg_data = 0x7f7e3508, description = 
0x139b5271eaa0 "Reparents to window specified by xid",
arg_description = 0x0}, {long_name = 0x139b5271eac5 "config", 
short_name = 99 'c', flags = 0, arg = G_OPTION_ARG_FILENAME, arg_data = 
0x139b52829110 ,
description = 0x139b5271eacc "Custom configuration file", 
arg_description = 0x0}, {long_name = 0x139b5271eae6 "profile", short_name = 112 
'p', flags = 0, arg = G_OPTION_ARG_CALLBACK,
arg_data = 0x139b52608a80 , description = 
0x139b5271eaee "Profile name", arg_description = 0x0}, {long_name = 
0x139b5271eb01 "version", short_name = 118 'v', flags = 0,
arg = G_OPTION_ARG_NONE, arg_data = 0x7f7e3504, description = 
0x139b5271eafb "Print version", arg_description = 0x0}, {long_name = 
0x139b5271eb09 "bug-info", short_name = 0 '\000', flags = 0,
arg = G_OPTION_ARG_NONE, arg_data = 0x7f7e3500, description = 
0x139b5271eb12 "Print used library versions", arg_description = 0x0}, 
{long_name = 0x0, short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_NONE,
arg_data = 0x0, description = 0x0, arg_description = 0x0}}
ver = 
buginfo = 
winid = 
err = 
pidstr = 
c = 0x139e455fe260
(gdb)