Re: Python 2.7 removal outline
On 2021-03-26 15:18, Olivier Certner wrote: Le vendredi 26 mars 2021, 22:43:12 CET Chris a écrit : Honestly. If something "just works", isn't a "security risk". Than don't fix it! Not so simple... But for build-only dependencies, I concur. But anyway, all new security reports for 3.x will be fixed in Tauthon. I've now already reviewed 55 security bugs from PSF and fixed those appropriate (most are either not bugs, or irrelevant, or already fixed in 2.7 or Tauthon proper). I have ~20 more to review (and possibly fix), then I'll test the result and finally push all this upstream. Thank you, Olivier. I *really* appreciate all the work you've put into this. --Chris ___ 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: Proposed ports git transition schedule
* Bob Eager [20210326 20:22]:
> Felix Palmen wrote:
> > I don't get what you mean. Repo details? A URL.
>
> With portsnap, I don't need a URL. It's built in. And that would be
> nice.
Ever had a look in /etc/portsnap.conf? Although it only wants a server
name (well, much of a difference), there's nothing built in. gitup comes
with a working configuration as well.
> > And that's all it does, it doesn't do any "security checks", that's
> > handled by pkg audit.
>
> What does it need a public key for?
Checking integrity of the downloaded snapshots? With fetching from
repositories, integrity checks are built in.
> No, that's not what I'm asking. I'm asking (on behalf of many people,
> I'm sure) just what I have to enter instead of:
>
> $ portsnap fetch extract
$ gitup ports
--
Dipl.-Inform. Felix Palmen ,.//..
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A
signature.asc
Description: PGP signature
Re: Python 2.7 removal outline
Le vendredi 26 mars 2021, 22:43:12 CET Chris a écrit : > Honestly. If something "just works", isn't a "security risk". Than don't fix > it! Not so simple... But for build-only dependencies, I concur. But anyway, all new security reports for 3.x will be fixed in Tauthon. I've now already reviewed 55 security bugs from PSF and fixed those appropriate (most are either not bugs, or irrelevant, or already fixed in 2.7 or Tauthon proper). I have ~20 more to review (and possibly fix), then I'll test the result and finally push all this upstream. -- Olivier Certner ___ 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: Python 2.7 removal outline
On 2021-03-26 12:19, Dan Mahoney (Ports) wrote: More thoughts on mailman, specifically: So, I just went to find an old FB post I made about mailman 2.x: === From the "Load Bearing Bit" department: Pretty much the entire world is stuck using an EOL'd mailing list manager (mailman 2.x), which depends on an EOL'd python (2.7). This includes: * All the gnu mailing lists * All of the linux mailing lists at listman.redhat * all the FreeBSD mailing lists * all the sourceforge mailing lists * all the IETF mailing lists * all of lists.isc.org * NANOG === That’s an AWFUL LOT of sysadmins, network admins, and coders who looked long and hard at Mailman 3 and decided “that’s not ready yet”. I think, if *nothing else*, tauthon needs to be stapled in for mailman, even if it lives under /usr/local/mailman/bin or something (and bakes in the couple of dependencies). I *fully* concur. In fact, at least 2 ports that I maintain added a depends on tauthon. Which really raised my ire hearing it's intended doom announcement. :( Honestly. If something "just works", isn't a "security risk". Than don't fix it! --Chris I know about the archive incompatibility. There *might* be a GSOC project to fix it. Maybe. Other changes can happen with greater use, but clearly there’s a first-mover disadvantage here. -Dan On Mar 26, 2021, at 9:06 AM, Chris wrote: On 2021-03-26 08:44, RW via freebsd-ports wrote: On Fri, 26 Mar 2021 13:55:33 +1100 (EST) Dave Horsfall wrote: On Thu, 25 Mar 2021, George Mitchell wrote: >> [...] it is really not for everybody to use overlays in current >> state (overlays are poor documented at least). [...] > > Until this thread I had never heard of them. -- > George I can't remember the last time I used overlays (certainly with CP/M); I didn't know that FreeBSD even supported them (why bother when you've got VM?). I doubt that meaning of overlay is going to be relevant. I'd not heard of it either, but from looking in ports/Mk/ it seems to be a way of modifying port builds. As I understand it. It allows you to graft out-of-tree ports/versions onto the ports-tree-proper. --Chris ___ 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" ___ 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: Proposed ports git transition schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 26 Mar 2021 19:30:03 +0100 Felix Palmen wrote: > * Bob Eager [20210326 14:27]: > > On Fri, 26 Mar 2021 14:04:17 +0100 > > Felix Palmen wrote: > > > I never used portsnap, but I'd assume net/gitup should serve the > > > same usecase. > > > > > > > Probably. So would git. > > Only that net/gitup is very lightweight and doesn't use git, so if you > want to just get the latest contents of a git repository, that's > probably what you want to use. > > > But portsnap needs no more at all than the above. All of the rest > > (repo details, security checks, etc.) are all done internally. > > I don't get what you mean. Repo details? A URL. With portsnap, I don't need a URL. It's built in. And that would be nice. > There's example > configurations containing the correct ones, just like portsnap has a > server configured where to fetch snapshots from. I'm sure there are. > And that's all it does, it doesn't do any "security checks", that's > handled by pkg audit. What does it need a public key for? > I'd assume (someone may correct me) that portsnap will still be > supported, as the snapshots don't depend on svn or git. But as you > asked for a replacement for git, gitup comes to mind as a simple tool. No, that's not what I'm asking. I'm asking (on behalf of many people, I'm sure) just what I have to enter instead of: $ portsnap fetch extract It's probably more than one command, and/or longer. I just thought it would be useful if everyone was told exactly what to use. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEVgdI2KeVldPAhUYaKBdf2az8e6gFAmBeQpAACgkQKBdf2az8 e6gDbggAwVs+WOBaqO2jN4yBMyF486bQOW8jV2QS9EBBjauSoIi5wkeZj/1ep0R6 xwFIGbLe4x0SkdKzWG+D/8rIgW89luVAQK7dWw2Ag61RbQANSCmjcZNSfdnWb0fY b63tkAB5JqnohBJg9VHy7QQEOpVTof5iig06ShvDojUJo2MxzC1slYeXDDuIm91E PQ2KsuLVuh4uGokAPec5mXUAKef+PS+4k3GWP47u7+7bsNhECjlO0B2Kv5EbkW8t e2UL/JEAc+W813uKuesP1XJaQg3BlOiyIGVung8BrT+P84yhS9lIFrBKSPu5XBxk y1wdcGA76Z+q8VPDborIdMHx18m8sA== =3pXs -END PGP SIGNATURE- ___ 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: Python 2.7 removal outline
On Fri, 26 Mar 2021 14:55:15 -0500 Greg Rivers via freebsd-ports wrote: > On Friday, 26 March 2021 14:19:20 CDT Dan Mahoney (Ports) wrote: > > More thoughts on mailman, specifically: > > > > So, I just went to find an old FB post I made about mailman 2.x: > > > > === > > From the "Load Bearing Bit" department: > > Pretty much the entire world is stuck using an EOL'd mailing list > > manager (mailman 2.x), which depends on an EOL'd python (2.7). This > > includes: > > * All the gnu mailing lists > > * All of the linux mailing lists at listman.redhat > > * all the FreeBSD mailing lists > > * all the sourceforge mailing lists > > * all the IETF mailing lists > > * all of lists.isc.org > > * NANOG > > === > > > > That?s an AWFUL LOT of sysadmins, network admins, and coders who > > looked long and hard at Mailman 3 and decided ?that?s not ready > > yet?. > > > > I think, if *nothing else*, tauthon needs to be stapled in for > > mailman, even if it lives under /usr/local/mailman/bin or something > > (and bakes in the couple of dependencies). > > > > I know about the archive incompatibility. There *might* be a GSOC > > project to fix it. Maybe. Other changes can happen with greater > > use, but clearly there?s a first-mover disadvantage here. > I concur. The thought of losing Mailman 2.x fills me with dread. > Me too. Short term, I shall have it in a non-updated jail. ___ 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: Python 2.7 removal outline
On Fri, 26 Mar 2021 09:06:08 -0700 Chris wrote: > > I doubt that meaning of overlay is going to be relevant. I'd not > > heard of it either, but from looking in ports/Mk/ it seems to be a > > way of modifying port builds. > As I understand it. It allows you to graft out-of-tree ports/versions > onto the ports-tree-proper. Ah, OK. I do that in a limited way. Local stuff that I have no interest in submitting as a port. One new category, 'local'. Easily imported into a new ports tree. ___ 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: Python 2.7 removal outline
On Friday, 26 March 2021 14:19:20 CDT Dan Mahoney (Ports) wrote: > More thoughts on mailman, specifically: > > So, I just went to find an old FB post I made about mailman 2.x: > > === > From the "Load Bearing Bit" department: > Pretty much the entire world is stuck using an EOL'd mailing list manager > (mailman 2.x), which depends on an EOL'd python (2.7). > This includes: > * All the gnu mailing lists > * All of the linux mailing lists at listman.redhat > * all the FreeBSD mailing lists > * all the sourceforge mailing lists > * all the IETF mailing lists > * all of lists.isc.org > * NANOG > === > > That’s an AWFUL LOT of sysadmins, network admins, and coders who looked long > and hard at Mailman 3 and decided “that’s not ready yet”. > > I think, if *nothing else*, tauthon needs to be stapled in for mailman, even > if it lives under /usr/local/mailman/bin or something (and bakes in the > couple of dependencies). > > I know about the archive incompatibility. There *might* be a GSOC project to > fix it. Maybe. Other changes can happen with greater use, but clearly > there’s a first-mover disadvantage here. > I concur. The thought of losing Mailman 2.x fills me with dread. -- Greg ___ 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: Python 2.7 removal outline
More thoughts on mailman, specifically: So, I just went to find an old FB post I made about mailman 2.x: === From the "Load Bearing Bit" department: Pretty much the entire world is stuck using an EOL'd mailing list manager (mailman 2.x), which depends on an EOL'd python (2.7). This includes: * All the gnu mailing lists * All of the linux mailing lists at listman.redhat * all the FreeBSD mailing lists * all the sourceforge mailing lists * all the IETF mailing lists * all of lists.isc.org * NANOG === That’s an AWFUL LOT of sysadmins, network admins, and coders who looked long and hard at Mailman 3 and decided “that’s not ready yet”. I think, if *nothing else*, tauthon needs to be stapled in for mailman, even if it lives under /usr/local/mailman/bin or something (and bakes in the couple of dependencies). I know about the archive incompatibility. There *might* be a GSOC project to fix it. Maybe. Other changes can happen with greater use, but clearly there’s a first-mover disadvantage here. -Dan > On Mar 26, 2021, at 9:06 AM, Chris wrote: > > On 2021-03-26 08:44, RW via freebsd-ports wrote: >> On Fri, 26 Mar 2021 13:55:33 +1100 (EST) >> Dave Horsfall wrote: >>> On Thu, 25 Mar 2021, George Mitchell wrote: >>> >> [...] it is really not for everybody to use overlays in current >>> >> state (overlays are poor documented at least). [...] >>> > >>> > Until this thread I had never heard of them. -- >>> > George >>> I can't remember the last time I used overlays (certainly with CP/M); >>> I didn't know that FreeBSD even supported them (why bother when >>> you've got VM?). >> I doubt that meaning of overlay is going to be relevant. I'd not heard >> of it either, but from looking in ports/Mk/ it seems to be a way of >> modifying port builds. > As I understand it. It allows you to graft out-of-tree ports/versions > onto the ports-tree-proper. > > --Chris >> ___ >> 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" ___ 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: Proposed ports git transition schedule
## Felix Palmen (fe...@palmen-it.de): > I'd assume (someone may correct me) that portsnap will still be > supported, https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html Regards, Christoph -- Spare Space ___ 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: Proposed ports git transition schedule
* Bob Eager [20210326 14:27]:
> On Fri, 26 Mar 2021 14:04:17 +0100
> Felix Palmen wrote:
> > I never used portsnap, but I'd assume net/gitup should serve the same
> > usecase.
> >
>
> Probably. So would git.
Only that net/gitup is very lightweight and doesn't use git, so if you
want to just get the latest contents of a git repository, that's
probably what you want to use.
> But portsnap needs no more at all than the above. All of the rest (repo
> details, security checks, etc.) are all done internally.
I don't get what you mean. Repo details? A URL. There's example
configurations containing the correct ones, just like portsnap has a
server configured where to fetch snapshots from.
And that's all it does, it doesn't do any "security checks", that's
handled by pkg audit.
I'd assume (someone may correct me) that portsnap will still be
supported, as the snapshots don't depend on svn or git. But as you asked
for a replacement for git, gitup comes to mind as a simple tool.
--
Dipl.-Inform. Felix Palmen ,.//..
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A
signature.asc
Description: PGP signature
Re: Python 2.7 removal outline
On 2021-03-26 08:44, RW via freebsd-ports wrote: On Fri, 26 Mar 2021 13:55:33 +1100 (EST) Dave Horsfall wrote: On Thu, 25 Mar 2021, George Mitchell wrote: >> [...] it is really not for everybody to use overlays in current >> state (overlays are poor documented at least). [...] > > Until this thread I had never heard of them. -- > George I can't remember the last time I used overlays (certainly with CP/M); I didn't know that FreeBSD even supported them (why bother when you've got VM?). I doubt that meaning of overlay is going to be relevant. I'd not heard of it either, but from looking in ports/Mk/ it seems to be a way of modifying port builds. As I understand it. It allows you to graft out-of-tree ports/versions onto the ports-tree-proper. --Chris ___ 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: Python 2.7 removal outline
On Fri, 26 Mar 2021 13:55:33 +1100 (EST) Dave Horsfall wrote: > On Thu, 25 Mar 2021, George Mitchell wrote: > > >> [...] it is really not for everybody to use overlays in current > >> state (overlays are poor documented at least). [...] > > > > Until this thread I had never heard of them. -- > > George > > I can't remember the last time I used overlays (certainly with CP/M); > I didn't know that FreeBSD even supported them (why bother when > you've got VM?). I doubt that meaning of overlay is going to be relevant. I'd not heard of it either, but from looking in ports/Mk/ it seems to be a way of modifying port builds. ___ 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: Proposed ports git transition schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 26 Mar 2021 14:04:17 +0100 Felix Palmen wrote: > * Bob Eager [20210326 09:22]: > > Thanks for this. The documentation (although introductory) is quite > > detailed. What would be useful is just to note down the exact > > replacement for: > > > > portsnap fetch > > portsnap extract > > I never used portsnap, but I'd assume net/gitup should serve the same > usecase. > Probably. So would git. But portsnap needs no more at all than the above. All of the rest (repo details, security checks, etc.) are all done internally. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEVgdI2KeVldPAhUYaKBdf2az8e6gFAmBd7z8ACgkQKBdf2az8 e6huSQf+P1l9gMFuqk93s0jkx8939g3jCl6fIHEePkF/H3pxbd9Ivmr7XCateIjs deMJPaRC1kPqhJymh5vsjRBoTAxckMBkCASYaaqrLEC1stl+UyduyDhdmxDcqTRq 49Ehdagfq9bBK+2Qz3+RxNN8iuqaK88ZxjUQF0YIRblJG9CKUdyn0DC1/nMsiqLS fGG2mwS0atXSfzybORdCNTrQ+SGJKSvPJ/lcnWbnPpQ8yl/uLeWAGezFRHa1hvg+ xZSJ/oszVQD+rfdYjYNdp3JrJfuKEgvljG7rIvc/ExdUH9BtAwUEm+oA7oy33G06 nQZO4RMtZYCUoxoEf+zSgrP77GSA/Q== =jHnH -END PGP SIGNATURE- ___ 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: Proposed ports git transition schedule
* Bob Eager [20210326 09:22]:
> Thanks for this. The documentation (although introductory) is quite
> detailed. What would be useful is just to note down the exact
> replacement for:
>
> portsnap fetch
> portsnap extract
I never used portsnap, but I'd assume net/gitup should serve the same
usecase.
--
Dipl.-Inform. Felix Palmen ,.//..
{web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt // """""""""""
{pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A
signature.asc
Description: PGP signature
Re: Proposed ports git transition schedule
On Thu, 25 Mar 2021 21:56:03 -0400 Ed Maste wrote: > When the conversion is complete, Subversion will become read-only with > no further updates to the ports tree. If you are fetching ports using > svn, you will need to switch to the new git repository at the > following URLS: > > Web repository browser: > https://cgit.freebsd.org/ports/ > > Distributed mirrors for anonymous readonly checkout/clone > https://git.freebsd.org/ports.git > ssh://anon...@git.freebsd.org/ports.git Thanks for this. The documentation (although introductory) is quite detailed. What would be useful is just to note down the exact replacement for: portsnap fetch portsnap extract when the migration is complete. A shell script would be even better! ___ 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: multimedia/gstreamer1 build error
On Thu, 18 Mar 2021 14:25:40 -0400 Janos Dohanics wrote: > Hello, > > I have a laptop with FreeBSD 13.0-RC2 amd64 GENERIC 1300139 > 210a1aa0399bb8edf2d74f13171a400c613bee80 and a fully updated ports > tree. > > I get an error when building multimedia/gstreamer1: > > # make 'MAKE_JOBS_UNSAFE=yes' install clean > ===> Building for gstreamer1-1.16.2 > gmake[2]: Entering directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2' gmake > all-recursive gmake[3]: Entering directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2' Making all > in pkgconfig gmake[4]: Entering directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/pkgconfig' > gmake[4]: Nothing to be done for 'all'. gmake[4]: Leaving directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/pkgconfig' > Making all in gst gmake[4]: Entering directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/gst' gmake > all-recursive gmake[5]: Entering directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/gst' Making > all in parse gmake[6]: Entering directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/gst/parse' > /usr/local/bin/bison > -d -v -ppriv_gst_parse_yy ./grammar.y -o grammar.tab.c && \ mv > grammar.tab.c grammar.tab_tmp.c && \ echo '#ifdef HAVE_CONFIG_H' > > grammar.tab_tmp2.c && \ echo '#include ' >> > grammar.tab_tmp2.c && \ echo '#endif' >> grammar.tab_tmp2.c && \ > cat grammar.tab_tmp.c >> grammar.tab_tmp2.c && \ > rm grammar.tab_tmp.c && \ > mv grammar.tab_tmp2.c grammar.tab.c > ./grammar.y:799.1-12: warning: deprecated directive: ??? > %pure-parser???, use ???%define api.pure??? > []8;id=c2c0e10005bdd0ebe4ec21Segmentation fault (core > dumped) gmake[6]: *** [Makefile:842: grammar.tab.h] Error 139 > gmake[6]: Leaving directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/gst/parse' > gmake[5]: *** [Makefile:1813: all-recursive] Error 1 gmake[5]: > Leaving directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/gst' > gmake[4]: *** [Makefile:1011: all] Error 2 gmake[4]: Leaving > directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2/gst' > gmake[3]: *** [Makefile:742: all-recursive] Error 1 gmake[3]: Leaving > directory '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2' > gmake[2]: *** [Makefile:648: all] Error 2 gmake[2]: Leaving directory > '/usr/ports/multimedia/gstreamer1/work/gstreamer-1.16.2' *** Error > code 1 > > Stop. > make[1]: stopped in /usr/ports/multimedia/gstreamer1 > *** Error code 1 > > Stop. > make: stopped in /usr/ports/multimedia/gstreamer1 The error is fixed with this patch: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=222697=diff -- Janos Dohanics ___ 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: Python 2.7 removal outline
On 2021-03-25 22:24, Kurt Jaeger wrote: Hi! Why does our work have so little value that portmgr@ is unwilling to keep us all in the loop, or consider our opinions on such matters? The portmgr@ role is a huge task and all the reasons (limited time, dayjobs, etc) ares valid for those folks from portmgr as for the rest of the ports maintainers and committers. Indeed, and don't think that hadn't occurred to me. In fact I suspected that portmgr@ was feeling a bit overwhelmed, and that *that* triggered the seemingly overreaching python announcement. May I humbly request a petition for such large-sweeping changes? IMHO this will give portmgr@ the opportunity to get caught up, and perhaps get some assistance -- maybe we all come up with an idea that saves _everyones_ bacon. :-) Thanks for the thoughtful reply. --Chris ___ 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"
