On 2021-May-19, at 14:17, Mark Millard wrote:
> On 2021-May-19, at 10:29, Mark Millard wrote:
>
>> bob prohaska fbsd at www.zefox.net wrote on
>> Wed May 19 16:09:32 UTC 2021 :
>>
>>> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
>>>
>>> [portmaster background omitted]
On 20/05/2021 1:54 am, Xavier Humbert wrote:
Hi,
I got trouble with python 3.8.10 at reinstall stage :
===> Registering installation for python38-3.8.10
pkg-static: Unable to access file
/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No
s
On 2021-May-19, at 10:29, Mark Millard wrote:
> bob prohaska fbsd at www.zefox.net wrote on
> Wed May 19 16:09:32 UTC 2021 :
>
>> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
>>>
>>
>> [portmaster background omitted]
>>
>>> If you want to give the attached port a try, it
bob prohaska fbsd at www.zefox.net wrote on
Wed May 19 16:09:32 UTC 2021 :
> On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
> >
>
> [portmaster background omitted]
>
> > If you want to give the attached port a try, it will install LUA and some
>
>
> I tried ports-mgmt/portma
On 19/05/2021 19:10, Gleb Popov wrote:
Just a guess - are you building with WITH_DEBUG=yes ?
Actually, no
Xavier
--
Xavier HUMBERT - Unix/Win/MacOSX Sysadmin/Network Senior Engineer
https://www.amdh.fr
___
freebsd-ports@freebsd.org mailing list
htt
On Wed, May 19, 2021 at 6:55 PM Xavier Humbert wrote:
> Hi,
>
> I got trouble with python 3.8.10 at reinstall stage :
>
> > ===> Registering installation for python38-3.8.10
> > pkg-static: Unable to access file
> >
> /usr/ports/lang/python38/work/stage
On Tue, May 18, 2021 at 09:24:00AM +0200, Stefan Esser wrote:
>
[portmaster background omitted]
> If you want to give the attached port a try, it will install LUA and some
I tried ports-mgmt/portmaster, it got stuck the same as make.
Unless the new version behaves very differently I'm doubt
On 19/05/2021 17:54, Xavier Humbert wrote:
Hi,
I got trouble with python 3.8.10 at reinstall stage :
===> Registering installation for python38-3.8.10
pkg-static: Unable to access file
/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No
s
Hi,
I got trouble with python 3.8.10 at reinstall stage :
===> Registering installation for python38-3.8.10
pkg-static: Unable to access file
/usr/ports/lang/python38/work/stage/usr/local/lib/python3.8/lib-dynload/_asyncio.cpython-38.so:No
such file or directory
pkg-static: Unable
ting conflict between versions of python strikes me as more of a
> > > planning problem than a software bug. It may be naive, but I don't see
> > > why python37 and python38 can't use distinct names for files placed in
> > > system directories.
> >
> >
On Mon, May 17, 2021 at 12:28:24PM -0700, Mark Millard via freebsd-ports wrote:
> bob prohaska fbsd at www.zefox.net wrote on
> Mon May 17 15:55:21 UTC 2021 :
>
> > The existing conflict between versions of python strikes me as more of a
> > planning problem than a software
bob prohaska fbsd at www.zefox.net wrote on
Mon May 17 15:55:21 UTC 2021 :
> The existing conflict between versions of python strikes me as more of a
> planning problem than a software bug. It may be naive, but I don't see
> why python37 and python38 can't use distinct names
me ago while trying to compile www/chromium on
a Raspberry Pi3. It seemed more prone to getting stuck than a simple
make -DBATCH
when all the dust settled. A large fraction of stoppages were related to
refusal to upgrade old ports that were already installed. Since portmaster
was advertised as a w
On 5/16/21 10:19 PM, bob prohaska wrote:
[...]
I'd like to see the ports system keep working as it has in the past, but that
seemingly
requires a kind of machine intelligence that hasn't evolved yet. Poudriere
seems like
a brute force approach. [...]
You'll find quite a few remaining fans of
On Mon, May 17, 2021 at 04:44:04AM +, Thomas Mueller wrote:
>
> My question, Bob, is, if you are dissatisfied with poudriere, what do you use
> for FreeBSD ports?
I'm not dissatisfied, I'm overwhelmed.
Usually, a simple
make -DBATCH > make.log &
works.
hth,
bob prohaska
___
> No real favorites. In emergencies I tend to pick up the telephone.
> This doesn't seem like an emergency, and in any case the phone is a poor
> medium for a problem like this. There are some ports under /usr/ports/irc,
> if you have suggestions I could try one or more. If a phone call is
On Sun, May 16, 2021 at 12:24:49PM +1000, Kubilay Kocak wrote:
> On 15/05/2021 2:35 am, bob prohaska wrote:
> >
> > I've never used IRC, is it somehow better than this list?
>
> Quicker isolation of root causes over async back and forth. Happy to go over
> it with you at your favourite 'real-time
On 2021-May-16, at 15:33, Tatsuki Makino wrote:
> Mark Millard wrote on 2021/05/16 17:11:
>> On 2021-May-16, at 00:16, Tatsuki Makino
>> wrote:
>>
>>> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/
>>> -V VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
>>>
>> Bob
Mark Millard wrote on 2021/05/16 17:11:
> On 2021-May-16, at 00:16, Tatsuki Makino
> wrote:
>
>> poudriere jail -c -j main -m 'src=/usr/src' -v `make -C /usr/src/release/ -V
>> VERSION VERSION=\$\{REVISION:Q\}-\$\{BRANCH:Q\}`
>>
> Bob already does a buildworld based on /usr/src for other
> reas
On 2021-May-16, at 00:16, Tatsuki Makino wrote:
> Mark Millard via freebsd-ports wrote on 2021/05/16 10:57:
>> In the form that I use poudriere I use something
>> like the following. I presume here that /usr/src
>> is populated and has the source for the system
>> involved. (I do not remember you
Mark Millard via freebsd-ports wrote on 2021/05/16 10:57:
> In the form that I use poudriere I use something
> like the following. I presume here that /usr/src
> is populated and has the source for the system
> involved. (I do not remember your describing its
> status.)
(Omitted below)
I was just
Something I've not asked about or otherwise referenced
is if you use non-default port options for any of the
ports that you build.
There is:
poudriere options -jmain -c -f ~root/origins/main-origins.txt
or:
poudriere options -jmain -C -f ~root/origins/main-origins.txt
where -c vs. -C is:
QUOTE
On 15/05/2021 2:35 am, bob prohaska wrote:
On Fri, May 14, 2021 at 12:24:06PM +1000, Kubilay Kocak wrote:
happy to help identify the root cause if you can jump on IRC
(#freebsd-python @ freenode)
If sorting out the conflict between python versions helps the
community in general I'm wi
On 2021-May-15, at 16:37, bob prohaska wrote:
> On Fri, May 14, 2021 at 07:29:15PM -0700, Mark Millard wrote:
>> bob prohaska fbsd at www.zefox.net wrote on
>> Fri May 14 01:35:28 UTC 2021 :
>>
>>> Would use of poudriere help with this sort of problem?
>>> It isn't trivial to configure, but t
On Fri, May 14, 2021 at 07:29:15PM -0700, Mark Millard wrote:
> bob prohaska fbsd at www.zefox.net wrote on
> Fri May 14 01:35:28 UTC 2021 :
>
> > Would use of poudriere help with this sort of problem?
> > It isn't trivial to configure, but this sort of difficulty
> > has been growing ever worse.
ome of the time. (Not that when is necessarily
> > obvious up front.)
> >
>
> You give me too much credit 8-)
>
> > Your environment is now based on a mix of python37 and
> > python 38 related materials. You are likely going to
> > need to rework/rebuild/reins
On Fri, May 14, 2021 at 12:24:06PM +1000, Kubilay Kocak wrote:
>
> happy to help identify the root cause if you can jump on IRC
> (#freebsd-python @ freenode)
If sorting out the conflict between python versions helps the
community in general I'm willing to try. I simply use mak
.)
You give me too much credit 8-)
Your environment is now based on a mix of python37 and
python 38 related materials. You are likely going to
need to rework/rebuild/reinstall things to avoid that.
Hints may come from that UPDATING that I quoted but
things are more broken overall than what UPDATING
o much credit 8-)
> Your environment is now based on a mix of python37 and
> python 38 related materials. You are likely going to
> need to rework/rebuild/reinstall things to avoid that.
>
> Hints may come from that UPDATING that I quoted but
> things are more broken overall than wha
On 5/10/21 6:49 PM, Yasuhiro Kimura wrote:
[...] I investigated repository of Python and found following commits
(bpo-43799) are the source of the problem.
[3.8] bpo-43799: OpenSSL 3.0.0: declare OPENSSL_API_COMPAT 1.1.1 (GH-25329)
(GH-25383)
https://github.com/python/cpython/commit
From: Yasuhiro Kimura
Subject: Build of Python 3.8.10/3.9.5 fails on 12.2-RELEASE
Date: Mon, 10 May 2021 16:29:03 +0900 (JST)
> I submitted patches to update lang/python3[89] to 3.8.10/3.9.5
> respectively.
>
> Bug 255729 - lang/python38: Update to 3.8.10
> https://bugs.freeb
out what needs to
be changed. -- George
I left out this crucial detail: I'm running 12.2-RELEASE-p6 r369558.
-- George
After a more careful review of what I am seeing, I realize that both
my earlier messages were wrong, and I have exactly the same failure
that you originally r
On 5/10/21 11:39 AM, George Mitchell wrote:
On 5/10/21 3:29 AM, Yasuhiro Kimura wrote:
> Hello,
>
> I submitted patches to update lang/python3[89] to 3.8.10/3.9.5
> respectively.
>
> Bug 255729 - lang/python38: Update to 3.8.10
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255729
>
On 5/10/21 3:29 AM, Yasuhiro Kimura wrote:
> Hello,
>
> I submitted patches to update lang/python3[89] to 3.8.10/3.9.5
> respectively.
>
> Bug 255729 - lang/python38: Update to 3.8.10
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255729
> [...]
I tried your patch on python38 and did not run
created them on 13.0-RELEASE. But after submitting them I found
build of them fail on 12.2-RELEASE as following.
--
/wrkdirs/usr/ports/lang/python38/work/Python-3.8.10/Modules/_ssl.c:3118:27:
error: implicit declaration of function
Van: Tatsuki Makino
Datum: 2 mei 2021 22:36
Aan: Ronald Klop , freebsd-ports@freebsd.org
Onderwerp: Re: I thought "pkg updating" would alert me about python...?
Ronald Klop wrote on 2021/05/03 05:14:
> The UPDATING entry should have said something like "users of lang/pytho
Ronald Klop wrote on 2021/05/03 05:14:
> The UPDATING entry should have said something like "users of lang/python*" to
> work.
The behavior of this is strange.
I have the following python* in my environment.
python, python27, python3, python37 and python38
AFFECTS: users of py
On 5/2/21 4:20 PM, David Wolfskill wrote:
I just re-verified the behavior, so -- even though I have already
started taking evasive action (updating python), I figured it may be of
use to show what I'm seeing; maybe I'm confused:
Local ports tree is updated; previous ports update was
I just re-verified the behavior, so -- even though I have already
started taking evasive action (updating python), I figured it may be of
use to show what I'm seeing; maybe I'm confused:
Local ports tree is updated; previous ports update was a week ago. I
happen to know that there
On Wed, 28 Apr 2021 03:25:02 -0600
"@lbutlr" wrote:
> > This long command hanle files that requires shebang:
> > portmaster -BvD -y --no-confirm --delete-build-only `grep -rsp
> > "\/python3\.7" /usr/local/ | grep -v '/usr/local/man/' | grep -v
> > '/usr/local/lib/python3' | sed -e 's|:.*||' -e '
On 26 Apr 2021, at 20:43, Rozhuk Ivan wrote:
> This long command hanle files that requires shebang:
> portmaster -BvD -y --no-confirm --delete-build-only `grep -rsp "\/python3\.7"
> /usr/local/ | grep -v '/usr/local/man/' | grep -v '/usr/local/lib/python3' |
> sed -e 's|:.*||' -e 's|Binary file
On Tue, 27 Apr 2021 17:42:19 +0900
Minoru TANABE wrote:
> This maybe /usr/local/bin/g-ir-scannner is python script file, and
> depend on python3.7.
> Please check the first line of /usr/local/bin/g-ir-scannner is
> #!/usr/local/bin/python3.8
> or
> #!/usr/local/bin/python3.7
&g
On Tue, 27 Apr 2021 07:29:01 +0200 (CEST)
obx2...@oldach.net (Helge Oldach) wrote:
> > This long command hanle files that requires shebang:
> > portmaster -BvD -y --no-confirm --delete-build-only `grep -rsp
> > "\/python3\.7" /usr/local/ | grep -v '/usr/local/man/' | grep -v
> > '/usr/local/lib/py
This maybe /usr/local/bin/g-ir-scannner is python script file, and depend
on python3.7.
Please check the first line of /usr/local/bin/g-ir-scannner is
#!/usr/local/bin/python3.8
or
#!/usr/local/bin/python3.7
2021年4月27日(火) 17:18 LuMiWa via freebsd-ports :
> Hi!
>
> I have a problem t
Hi!
I have a problem to update Python on FreeBSD 13.0 RELEASE follow the
rules for portmaster in /usr/ports/UPDATING. It stopped wit py-gobject3:
self.evaluate_codeblock(codeblock)
File
"/usr/local/lib/python3.8/site-packages/mesonbuild/interpreterbase.py",
li
On Mon, 26 Apr 2021 11:55:07 -0400 (EDT)
AN wrote:
> > After doing all manipulations for rebuild and reinstall with
> > pkg+portmaster some files not affected, I suspect that files after
> > shebang fix:
> >
> > # grep -rsp "python3\.7" /usr/local/
> > Binary file /usr/local/bin/youtube-dl matche
Hi:
I am getting the following trying to update ports on 13stable:
On Mon, 26 Apr 2021, Rozhuk Ivan wrote:
> Date: Mon, 26 Apr 2021 16:34:43 +0300
> From: Rozhuk Ivan
> To: k...@freebsd.org, freebsd-ports@freebsd.org
> Subject: Python update 3.7->3.8
>
> Hi!
>
> Af
Hi!
After doing all manipulations for rebuild and reinstall with pkg+portmaster
some files not affected, I suspect that files after shebang fix:
# grep -rsp "python3\.7" /usr/local/
Binary file /usr/local/bin/youtube-dl matches
/usr/local/bin/gsettings-schema-convert:#!/usr/local/bin/python3.7
/u
I build many ports in poudriere with the `-t` (test port) flag. Ports that use
Python-based tools tend to fail with a fs_violation. For instance, FreeCAD:
=>> Checking for filesystem violations... done
=>> Error: Filesystem touched during build:
extra: usr/local/lib/python3.7/s
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 pe
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 gi
ommitters.
> 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? IMH
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
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
(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 AW
t; ===
> > 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
> &g
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
>
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 li
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
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 t
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.
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 petitio
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 m
t all of the replies made
to this announcement. My comments below this initial announcement...
On 2021-03-24 06:03, Rene Ladan wrote:
Hi,
below is an outline continuing the Python 2.7 cleanup:
- all affected ports are now marked as deprecated, with an expiration date
of either 2020-12-31 or 20
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 w
On 26/03/2021 9:25 am, George Mitchell wrote:
> On 3/25/21 6:06 PM, Miroslav Lachman 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
On 3/25/21 6:06 PM, Miroslav Lachman 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
OpenPGP_signature
Description: OpenPGP digital signature
On 25/03/2021 16:03, Baptiste Daroussin wrote:
I will only here answer about the quality of the communication of portmgr, yes
there is room of improvement in general in the current portmgr team as of how we
do communicate about plans and policy and we are working on it.
"There is room of impro
I find this announcement very much disappointing, because the situation for
ports that need Python 2.7 or similar to build doesn't seem to have changed at
all. In short, we are just told (again) that they should disappear.
Many end-users who maintain python2 code, both application and in
Am 24.03.21 um 23:11 schrieb Matthias Andree:
> Am 24.03.21 um 22:50 schrieb Dan Mahoney (Ports):
>
>> There are packages for mailman3 but they’re incomplete and don’t
> result in a working install the way the 2.x build does. You also need
> mysql, django, etc etc.
>
> Dan, please check if we alre
anges hit the public in a hit-and-run
style. Earlier portmgr@'s set higher standards of communicating with the
community. The decision-making does not appear transparent, and the
evaluation of consequences in some cases such as this appears
incomplete, or at least incompletely documented to the
I meant to send this reply to the list. I beg for @bapt's forgiveness
for the inbox echo.
On 3/25/21 8:03 AM, Baptiste Daroussin wrote:
> On Thu, Mar 25, 2021 at 12:02:29PM +0100, Olivier Certner wrote:
>>
>> 2. Leverage overlays to provide additional repos, a bit like AUR for Arch.
>> Here I'm i
, because the situation for
> ports that need Python 2.7 or similar to build doesn't seem to have changed
> at
> all. In short, we are just told (again) that they should disappear.
>
> But now we are told also that there are exceptions to the general rule. And
> even w
Hi,
Maintainer of Tauthon here, and of Pale Moon (for the few hours it lived in
the tree in February; but I'm still pushing updates to PR 251117).
I find this announcement very much disappointing, because the situation for
ports that need Python 2.7 or similar to build doesn't se
On 25/03/2021 07:26, Dewayne Geraghty wrote:
On 25/03/2021 4:01 am, Miroslav Lachman wrote:
I really appreciate the work of ports team, committers and maintainers
but I dislike double standards. All ports requiring Python 2.7 were
marked deprecated the last year almost all of them removed
On 24/3/21 22:50, Dan Mahoney (Ports) wrote:
> There are packages for mailman3 but they’re incomplete and don’t
result in a working install the way the 2.x build does. You also need
mysql, django, etc etc.
>
> Needing django is almost as bad as saying “sure, the web UI depends
on WordPress”.
On 25/03/2021 4:01 am, Miroslav Lachman wrote:
> I really appreciate the work of ports team, committers and maintainers
> but I dislike double standards. All ports requiring Python 2.7 were
> marked deprecated the last year almost all of them removed according to
> expiration date 20
Am 24.03.21 um 22:50 schrieb Dan Mahoney (Ports):
> There are packages for mailman3 but they’re incomplete and don’t
result in a working install the way the 2.x build does. You also need
mysql, django, etc etc.
Dan, please check if we already have bug reports on the mailman 3 issues
and where th
Am 24.03.21 um 14:03 schrieb Rene Ladan:
> Hi,
>
> below is an outline continuing the Python 2.7 cleanup:
>
> - No usage of lang/tauthon by the framework or any port, no excuses.
> - lang/tauthon will be removed on 2021-06-23 as noticed in the port
> itself,
> no
Am 24.03.21 um 22:48 schrieb Baptiste Daroussin:
> On Wed, Mar 24, 2021 at 09:45:09PM +, Bob Eager wrote:
>> On Wed, 24 Mar 2021 13:03:47 +
>> Rene Ladan wrote:
>>
>>> - - mail/mailman is being replaced by clusteradm@ with mlmmj. You
>>> can use `pkg lock` to stick with it after removal,
There are packages for mailman3 but they’re incomplete and don’t result in a
working install the way the 2.x build does. You also need mysql, django, etc
etc.
Needing django is almost as bad as saying “sure, the web UI depends on
WordPress”. It’s not standalone cgi’s that you can just scripta
On Wed, Mar 24, 2021 at 09:45:09PM +, Bob Eager wrote:
> On Wed, 24 Mar 2021 13:03:47 +
> Rene Ladan wrote:
>
> > - - mail/mailman is being replaced by clusteradm@ with mlmmj. You
> > can use `pkg lock` to stick with it after removal, if there is no
> > other way.
>
> Is anyone working
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, 24 Mar 2021 13:03:47 +
Rene Ladan wrote:
> - - mail/mailman is being replaced by clusteradm@ with mlmmj. You
> can use `pkg lock` to stick with it after removal, if there is no
> other way.
Is anyone working on a mailman 3 port?
-
On 24/03/21 14:03, Rene Ladan wrote:
Hi,
below is an outline continuing the Python 2.7 cleanup:
- all affected ports are now marked as deprecated, with an expiration date
of either 2020-12-31 or 2021-06-23.
- we will have to wait for Chromium to fully switch to Python 3 before we
can
On 24/03/2021 14:03, Rene Ladan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
below is an outline continuing the Python 2.7 cleanup:
- - all affected ports are now marked as deprecated, with an expiration date
of either 2020-12-31 or 2021-06-23.
- - we will have to wait for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
below is an outline continuing the Python 2.7 cleanup:
- - all affected ports are now marked as deprecated, with an expiration date
of either 2020-12-31 or 2021-06-23.
- - we will have to wait for Chromium to fully switch to Python 3 before
Holy cow!
This is a future of all python branches. We need to rework our py build system
* bpo-42604: Now all platforms use a value for the “EXT_SUFFIX” build variable
derived from SOABI (for instance in freeBSD, “EXT_SUFFIX” is now
“.cpython-310d.so” instead of “.so”). Previosuly only Linux
/bugzilla/show_bug.cgi?id=252057
--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)
On Wednesday, Dec 23, 2020 at 11:51 AM, wen heping mailto:wenheping2...@hotmail.com)> wrote:
python-3.8 is not the default python version, so we do
On Tue, Dec 22, 2020 at 05:25:41PM -0800, John Kennedy wrote:
> On Tue, Dec 22, 2020 at 08:47:35PM +0100, Christian Ullrich wrote:
> > Hello,
> >
> > I have started to notice poudriere builds of Python ports with compiled
> > extensions failing:
> >
> >
On Tue, Dec 22, 2020 at 08:47:35PM +0100, Christian Ullrich wrote:
> Hello,
>
> I have started to notice poudriere builds of Python ports with compiled
> extensions failing:
>
> [00:00:11] /usr/bin/strip
> /wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/py
Hello,
I have started to notice poudriere builds of Python ports with compiled
extensions failing:
[00:00:11] /usr/bin/strip
/wrkdirs/usr/ports/devel/py-cffi/work-py38/stage/usr/local/lib/python3.8/site-packages/_cffi_backend.so
[00:00:11] strip: open
/wrkdirs/usr/ports/devel/py-cffi/work
Could a committer look into commiting the MythTV family of ports in pr
249484
It would be great to get a working digital video recorder in ports and
remove a dependency on Python 2.7.
Status |Bug Id | Description
ersions => vers in ports tree
- add all deps to port Makefile
- some plugins requires other plugins
On other side, Kodi downloads python plugins into its own work dir, some of
them - same things that in ports tree.
There is 2 ways:
1. Allow HA download and install all deps that required for plu
attrs==19.3.0",
"bcrypt==3.1.7",
"certifi>=2020.6.20",
"ciso8601==2.1.3",
"httpx==0.16.1",
"importlib-metadata==1.6.0;python_version<'3.8'",
"jinja2>=2.11.2",
"PyJWT==1.7.1",
;certifi>=2020.6.20",
"ciso8601==2.1.3",
"httpx==0.16.1",
"importlib-metadata==1.6.0;python_version<'3.8'",
"jinja2>=2.11.2",
"PyJWT==1.7.1",
# PyJWT has loose dependency. We want the latest one.
&
g this?
Regards,
Ronald.
Van: Adriaan de Groot
Datum: maandag, 27 juli 2020 21:36
Aan: freebsd-ports@freebsd.org
Onderwerp: Chromium (& derivatives) and Python 2.7
The Chromium build system -- and as a consequence, also QtWebEngine
-- still
uses Python 2.7. This is going to be a real problem a
this?
>
> Regards,
> Ronald.
>
>
> Van: Adriaan de Groot
> Datum: maandag, 27 juli 2020 21:36
> Aan: freebsd-ports@freebsd.org
> Onderwerp: Chromium (& derivatives) and Python 2.7
>>
>> The Chromium build system -- and as a consequence, also QtWebEngine
&g
other projects (like Debian, etc.) solving this?
Regards,
Ronald.
Van: Adriaan de Groot
Datum: maandag, 27 juli 2020 21:36
Aan: freebsd-ports@freebsd.org
Onderwerp: Chromium (& derivatives) and Python 2.7
The Chromium build system -- and as a consequence, also QtWebEngine -- still
uses Py
## Adriaan de Groot (adr...@freebsd.org):
> The Chromium build system -- and as a consequence, also QtWebEngine -- still
> uses Python 2.7. This is going to be a real problem about six months down the
> line, and I have no idea how upstream is going to deal with it. I've hear
The Chromium build system -- and as a consequence, also QtWebEngine -- still
uses Python 2.7. This is going to be a real problem about six months down the
line, and I have no idea how upstream is going to deal with it. I've heard
there are patches buried deep within the chocolate factory
1 - 100 of 859 matches
Mail list logo
