Re: Any ports committers able to review a new port request

[Adam Jimerson]

Hi,

Yes I will be fixing that in a new patch. The yadm tool has seen a new
update just
the other day so I'll merge this patch and the update into one ticket and
skip
messing with having to bump the PORTREVISION for that port.

On Mon, Aug 10, 2020 at 2:43 PM Kurt Jaeger  wrote:

> Hi!
>
> > > A few months ago I opened a bug report to add a new port
> textproc/py-j2cli
> > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245783) that I
> will be the
> > > maintainer of. This will be an optional runtime dependency of
> sysutils/yadm
> > > to allow for Jinja2 template files.
> >
> > Committed, thanks!
>
> Btw, will you fix the patch in
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245593
>
> ?
>
> --
> p...@opsec.eu+49 171 3101372Now what ?
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Any ports committers able to review a new port request

[Kurt Jaeger]

Hi!

> > A few months ago I opened a bug report to add a new port textproc/py-j2cli 
> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245783) that I will be 
> > the 
> > maintainer of. This will be an optional runtime dependency of sysutils/yadm
> > to allow for Jinja2 template files.
> 
> Committed, thanks!

Btw, will you fix the patch in

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245593

?

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADS UP] Planned deprecation of portsnap

[Brooks Davis]

On Fri, Aug 07, 2020 at 11:48:34AM -0400, Greg Veldman wrote:
> On Fri, Aug 07, 2020 at 03:43:38PM +0200, Michael Gmelin wrote:
> > The real question is: Will we design things in a way that we expect ports 
> > tree users to always install git and its dependencies on their system or 
> > not (long term)?
> > 
> > For developers it???s a no-brainer (obviously yes), but ports tree users 
> > aren???t developers. 
> 
> Or alternatively, will there be a git/gitlite or similar utility
> included in base that can be used to bootstrap one's ports tree?

We'd love to have something, but we aren't going to hold up progress
indefinitely waiting for one to be implemented in an acceptable language
with an acceptable license.

-- Brooks


signature.asc
Description: PGP signature

Re: [HEADS UP] Planned deprecation of portsnap

[Dima Pasechnik]

On Mon, Aug 10, 2020 at 3:21 PM Steve Wills  wrote:
> On 8/10/20 9:28 AM, Lars Engels wrote:
> > On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote:
> >
> > I'm probably fine with this and I think that all of the (now) supported
> > methods have pros and cons.
> > To leverage the UX flaws of git and svn(lite) compared to portsnap
> > having a wrapper script around the two tools would be very appreciated.
> >
> > Something like
> >
> > # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch 
> > extract
> >The package devel/git does not seem to be installed, do you want to 
> > install it? (Y/n) _
> >
> > With sane defaults, so you can just run portsnap fetch extract like
> > you're used to and this
> > downloads the latest ports tree to /usr/ports using base svnlite(1).
> >
> > While we're here: Can we please have a separate user that is used to
> > checkout the tree?
> >
> > Lars
> >
> >
> > P.S.: Please DO NOT name the wrapper portsnap-ng. :-)
> >
>
> I think something like this will likely in many ways perpetuate many of
> the problems I listed in my original email, particularly with folks
> being on the wrong branch and not properly generating patches.

This seems to be an orthogonal issue. IMHO workflows to fix/update
code which do not use a VCS are totally outdated. There should be no
patches to fix things, but (git - if your VCS is git) branches.

Then all these problems of "being on a wrong branch" are not there.

Dima



>
> Steve
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Any ports committers able to review a new port request

[Kurt Jaeger]

Hi!

> A few months ago I opened a bug report to add a new port textproc/py-j2cli 
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245783) that I will be the 
> maintainer of. This will be an optional runtime dependency of sysutils/yadm
> to allow for Jinja2 template files.

Committed, thanks!

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADS UP] Planned deprecation of portsnap

[Robert Huff]

Michael Gmelin writes:

>  There are many users who never create any patches, but simply use
>  the ports tree to install software.

Add my name to that list.
(Used to use cvsup ... now subversion ... soon git ... where will 
the insanity end?   :-) )


Respectfully,


Robert Huff



-- 

Get it right: _physical_ distancing; _social_ cohesion
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADS UP] Planned deprecation of portsnap

[Michael Gmelin]

> On 10. Aug 2020, at 16:22, Steve Wills  wrote:
> 
> Hi,
> 
>> On 8/10/20 9:28 AM, Lars Engels wrote:
>> On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote:
>> I'm probably fine with this and I think that all of the (now) supported
>> methods have pros and cons.
>> To leverage the UX flaws of git and svn(lite) compared to portsnap
>> having a wrapper script around the two tools would be very appreciated.
>> Something like
>> # portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch 
>> extract
>>   The package devel/git does not seem to be installed, do you want to 
>> install it? (Y/n) _
>> With sane defaults, so you can just run portsnap fetch extract like
>> you're used to and this
>> downloads the latest ports tree to /usr/ports using base svnlite(1).
>> While we're here: Can we please have a separate user that is used to
>> checkout the tree?
>> Lars
>> P.S.: Please DO NOT name the wrapper portsnap-ng. :-)
> 
> I think something like this will likely in many ways perpetuate many of the 
> problems I listed in my original email, particularly with folks being on the 
> wrong branch and not properly generating patches.

There are many users who never create any patches, but simply use the ports 
tree to install software. Please make sure the ports collection keeps working 
for them.

Michael



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADS UP] Planned deprecation of portsnap

[Steve Wills]

Hi,

On 8/10/20 9:28 AM, Lars Engels wrote:

On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote:

I'm probably fine with this and I think that all of the (now) supported
methods have pros and cons.
To leverage the UX flaws of git and svn(lite) compared to portsnap
having a wrapper script around the two tools would be very appreciated.

Something like

# portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch 
extract
   The package devel/git does not seem to be installed, do you want to install 
it? (Y/n) _

With sane defaults, so you can just run portsnap fetch extract like
you're used to and this
downloads the latest ports tree to /usr/ports using base svnlite(1).

While we're here: Can we please have a separate user that is used to
checkout the tree?

Lars


P.S.: Please DO NOT name the wrapper portsnap-ng. :-)



I think something like this will likely in many ways perpetuate many of 
the problems I listed in my original email, particularly with folks 
being on the wrong branch and not properly generating patches.


Steve
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [HEADS UP] Planned deprecation of portsnap

[Lars Engels]

On Tue, Aug 04, 2020 at 02:43:20PM -0400, Steve Wills wrote:
> 
> We are planning to deprecate use of portsnap in ports.
> 
> The reasons are as follows (in no particular order):
> 
> * Portsnap doesn't support quarterly branches, even years after 
> quarterly branches were created and changed to the default for non-HEAD 
> packages.
> 
> * Portsnap doesn't seem to save disk space compared to svn or git, if 
> you count the metadata (stored in /var/db/portsnap by default) and you 
> do an apples-to-apples comparison of svn or git without history and 
> ignoring possible ZFS compression. That is, you use "svn export" or git 
> "clone --depth 1", you see this disk usage:
> 
>  342Msvnexport
>  426Mgit
>  477Mportsnap
> 
> * Portsnap also doesn't work offline which git does. With git, you can 
> also easily add the history by running "git pull --unshallow"
> 
> * This migration away from portsnap fits well with the planned migration 
> to git.
> 
> * Also based on the patches we've seen in Bugzilla for some time, usage 
> of portsnap causes folks to too easily accidentally submit patches to 
> Bugzilla which don't apply easily.
> 
> * Since portsnap doesn't support quarterly branches, it often causes 
> users to build on the wrong branch or end up with mismatched packages. 
> That is, they install packages from quarterly via pkg, then want to 
> customize so run portsnap and build from head, which can cause problems, 
> as we often see. Even when this doesn't happen, it adds to 
> troubleshooting to verify that it didn't.
> 
> We are aware people have gotten used to portsnap, but believe:
> 
> * People should be able to easily use svnlite in base or git from pkgs. 
> (Very few people seem to actually use WITHOUT_SVNLITE).
> 
> * There is also the possibility of falling back to fetching a tar or zip 
> from https://cgit-beta.freebsd.org/ports/ although this does make 
> updating harder.
> 
> How it will be done, in order:
> 
> * Update poudriere to use svn by default. This is already done:
> 
>https://github.com/freebsd/poudriere/pull/764
>  
> https://github.com/freebsd/poudriere/commit/bd68f30654e2a8e965fbdc09aad238c8bf5cdc10
> 
> * Update docs not to mention portsnap. This is already in progress:
> 
>https://reviews.freebsd.org/D25800
>https://reviews.freebsd.org/D25801
>https://reviews.freebsd.org/D25803
>https://reviews.freebsd.org/D25805
>https://reviews.freebsd.org/D25808
>https://svnweb.freebsd.org/changeset/base/363798
> 
>Many thanks to the folks who have worked and are working on this!
> 
> * Make WITHOUT_PORTSNAP default in base. Currently not certain when this 
> will happen. May not happen before 13.0, but hopefully it will.
> 
> * Eventually, portsnap servers will see low enough usage they can be 
> disabled.
> 
> We welcome any constructive feedback. All input would be heard, and if 
> the plans need to be amended, we will come back to you with the amended 
> plan in a couple of weeks. This process will take some time and 
> hopefully won't be too disruptive to anyone's usual workflow.
> 

I'm probably fine with this and I think that all of the (now) supported
methods have pros and cons.
To leverage the UX flaws of git and svn(lite) compared to portsnap
having a wrapper script around the two tools would be very appreciated.

Something like

# portsnap-ng --mode git --branch 2020Q2 --destination /ports/2020Q2 fetch 
extract
  The package devel/git does not seem to be installed, do you want to install 
it? (Y/n) _

With sane defaults, so you can just run portsnap fetch extract like
you're used to and this
downloads the latest ports tree to /usr/ports using base svnlite(1).

While we're here: Can we please have a separate user that is used to
checkout the tree? 

Lars


P.S.: Please DO NOT name the wrapper portsnap-ng. :-)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Any ports committers able to review a new port request

[Adam Jimerson]

Hello,

A few months ago I opened a bug report to add a new port textproc/py-j2cli 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245783) that I will be the 
maintainer of. This will be an optional runtime dependency of sysutils/yadm to 
allow for Jinja2 template files.

signature.asc
Description: This is a digitally signed message part.

Re: Crashing net/microsocks if DNS being proxied

[Pavel Timofeev]

вс, 9 авг. 2020 г. в 16:30, Pavel Timofeev :

>
>  Pavel Timofeev :
>
>> Hello
>>
>> I'd like to take advantage of net/microsocks port - a small SOCKSv5
>> server.
>> It's v1.0.1 (https://github.com/rofl0r/microsocks/tree/v1.0.1) under
>> 12.1 RELEASE amd64.
>> It works OK with firefox until I ask firefox to proxy DNS via socks also.
>> It cashes after getaddrinfo() call.
>> I have quite poor C knowledge and I can't understand what's wrong with it.
>> Parameters passed to getaddrinfo() looks OK
>> Can anybody advise where to look at also?
>>
>>
>>
>> $ gdb92 microsocks microsocks.core
>>
>>
>> GNU gdb (GDB) 9.2 [GDB v9.2 for FreeBSD]
>>
>> Copyright (C) 2020 Free Software Foundation, Inc.
>>
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>>
>>
>> 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-portbld-freebsd12.1".
>>
>>
>> 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 microsocks...
>>
>> [New LWP 100579]
>> [New LWP 100347]
>> Core was generated by `./microsocks'.
>>
>> Program terminated with signal SIGSEGV, Segmentation fault.
>>
>>
>> #0  0x0008003e5467 in _getht (hostf=0x7fffdfffd238,
>> name=0x7fffdfffda20 "freebsd.org",
>>
>>
>> pai=0x7fffdfffd5a0, cur=0x7fffdfffd240) at
>> /usr/src/lib/libc/net/getaddrinfo.c:2476
>>
>>
>> 2476{
>> [Current thread is 1 (LWP 100579)]
>>
>> (gdb) bt
>> #0  0x0008003e5467 in _getht (hostf=0x7fffdfffd238,
>> name=0x7fffdfffda20 "freebsd.org", pai=0x7fffdfffd5a0,
>> cur=0x7fffdfffd240) at /usr/src/lib/libc/net/getaddrinfo.c:2476
>> #1  0x0008003e4990 in _files_getaddrinfo (rv=0x7fffdfffd670,
>> cb_data=, ap=) at
>> /usr/src/lib/libc/net/getaddrinfo.c:2515
>> #2  0x00080040df6c in _nsdispatch (retval=0x7fffdfffd670,
>> disp_tab=0x8004482e0, database=, method_name=0x8002bafb7
>> "getaddrinfo", defaults=)
>> at /usr/src/lib/libc/net/nsdispatch.c:716
>> #3  0x0008003e30b3 in explore_fqdn (pai=0x1, hostname=> out>, servname=0x7fffdfffd860 "80", res=) at
>> /usr/src/lib/libc/net/getaddrinfo.c:1945
>> #4  getaddrinfo (hostname=, servname=0x7fffdfffd860 "80",
>> hints=, res=0x7fffdfffda18) at
>> /usr/src/lib/libc/net/getaddrinfo.c:576
>> #5  0x002037f6 in resolve (host=0x7fffdfffda20 "freebsd.org",
>> port=80, addr=0x7fffdfffda18) at server.c:14
>> #6  0x002030e8 in connect_socks_target (buf=0x7fffdfffdba0
>> "\005\001", n=18, client=0x800689038) at sockssrv.c:136
>> #7  0x002029e3 in clientthread (data=0x800689030) at
>> sockssrv.c:317
>> #8  0x00080025a736 in thread_start (curthread=0x800683500) at
>> /usr/src/lib/libthr/thread/thr_create.c:292
>> #9  0x in ?? ()
>> Backtrace stopped: Cannot access memory at address 0x7fffdfffe000
>> (gdb) f 5
>> #5  0x002037f6 in resolve (host=0x7fffdfffda20 "freebsd.org",
>> port=80, addr=0x7fffdfffda18) at server.c:14
>> 14  return getaddrinfo(host, port_buf, , addr);
>> (gdb) p host
>> $1 = 0x7fffdfffda20 "freebsd.org"
>> (gdb) p port_buf
>> $2 = "80\000\000\b\000\000"
>> (gdb) p hints
>> $3 = {ai_flags = 1, ai_family = 0, ai_socktype = 1, ai_protocol = 0,
>> ai_addrlen = 0, ai_canonname = 0x0, ai_addr = 0x0, ai_next = 0x0}
>> (gdb) p *addr
>> $4 = (struct addrinfo *) 0x0
>> (gdb) list
>> 9   .ai_socktype = SOCK_STREAM,
>> 10  .ai_flags = AI_PASSIVE,
>> 11  };
>> 12  char port_buf[8];
>> 13  snprintf(port_buf, sizeof port_buf, "%u", port);
>> 14  return getaddrinfo(host, port_buf, , addr);
>> 15  }
>> 16
>> 17  int server_bindtoip(const struct server *server, int fd) {
>> 18  if(server->bindaddr.v4.sin_family != AF_UNSPEC)
>>
>>
>>
>> However, it works OK under Linux no matter if DNS proxied or not.
>> Thank you!
>>
>
>
>
> I'm not asking for full debug session, just a few clues or an advice which
> way to dig probably.
>


Ahh, it fiddles with PTHREAD_STACK_MIN. It's the root cause.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD ports you maintain which are out of date

[portscout]

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
databases/sql-workbench | 118 | 136
+-+
lang/snobol4| 2.0 | 2.1.6
+-+
net-mgmt/netdata| 1.23.1  | v1.24.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"