On Mon, Jan 06, 2025 at 09:36:33AM +, Stuart Henderson wrote:
> > Assuming the rest of the i386 build goes well, ok to update?
> i386 was good, and tb@ kindly ran it through a bulk on amd64 as well,
> no problems.
> ok to commit it?
ok kmos
--Kurt
> > Index: p
ago and that was clean) - there's a small chance that some
> non-i386 ports need a tweak but if so it will be minimal (and I think
> it's unlikely).
>
> Assuming the rest of the i386 build goes well, ok to update?
i386 was good, and tb@ kindly ran it through a bulk on amd64
ak but if so it will be minimal (and I think
it's unlikely).
Assuming the rest of the i386 build goes well, ok to update?
Index: py-setuptools/Makefile
===
RCS file: /cvs/ports/devel/py-setuptools/Makefile,v
diff -u -p -r1.57 M
On Mon, Oct 07, 2024 at 02:23:11PM +0100, Stuart Henderson wrote:
> On 2024/10/05 17:22, Theo Buehler wrote:
> > > Updating to 69.5.1 seems simpler (I fixed persistent breakage in a
> > > couple of ports) and at least gets us beyond the current patches.
> > I saw no fallout in an amd64 bulk. I can
On 2024/10/05 17:22, Theo Buehler wrote:
> > Updating to 69.5.1 seems simpler (I fixed persistent breakage in a
> > couple of ports) and at least gets us beyond the current patches.
>
> I saw no fallout in an amd64 bulk. I can't recall having seen this
> spidermonkey issue ever.
>
> ok tb
Thanks
> Updating to 69.5.1 seems simpler (I fixed persistent breakage in a
> couple of ports) and at least gets us beyond the current patches.
I saw no fallout in an amd64 bulk. I can't recall having seen this
spidermonkey issue ever.
ok tb
l for anyone?
Log at the bottom of this mail.
If anyone's starting a test bulk build on an arch with wider coverage
(something 64-bit at least, pref amd64/aarch64) could you try this
in it please?
(Diff also removes MODPY_SETUPUTILS_DEPEND which is obsolete after
moving this port to MODPY_P
On Fri, 30 Oct 2020, Kurt Mosiejczuk wrote:
> Ping. I've added py-packaging to TEST_DEPENDS to fix the issue daniel@ saw.
> (I don't see it because the tests using py-packaging don't run when using
> PORTS_PRIVSEP).
>
> So this went throught a sparc64 bulk without issues.
>
> ok?
>
seems li
work (since I'm running PORTS_PRIVSEP).
Ping. I've added py-packaging to TEST_DEPENDS to fix the issue daniel@ saw.
(I don't see it because the tests using py-packaging don't run when using
PORTS_PRIVSEP).
So this went throught a sparc64 bulk without issues.
ok?
--Kurt
I
't get that. Are you perhaps not running PORTS_PRIVSEP? I think
those tests are for pulling from the network and it skips them for me
since it can't get to the network (since I'm running PORTS_PRIVSEP).
--Kurt
>
> On Fri, 23 Oct 2020, Kurt Mosiejczuk wrote:
>
> &g
R:Mpython3}
TEST_DEPENDS+=devel/py-futures
.endif
Under python3 it complained about "No module named 'packaging'"
On Fri, 23 Oct 2020, Kurt Mosiejczuk wrote:
> This updates py-setuptools to the last version that still supports python
> 2.7, 44.1.1.
>
>
This updates py-setuptools to the last version that still supports python
2.7, 44.1.1.
I've run a bulk build on my sparc64 test cluster and didn't have any failures
due to the update. That was a shorter build though because of the
spidermonkey update, so I wouldn't be opposed if s
On 2019/11/19 15:07, Kurt Mosiejczuk wrote:
> I took out the old PFRAG stuff in favor of current PLIST practices.
I like that, but you'll need to add MODPY_FLAVOR to SUBST_VARS, it
isn't present by default.
Apart from that, given what you've already tested I don't think a bulk
will show up anythi
On 2019/11/19 20:04, Stuart Henderson wrote:
> On 2019/11/19 15:00, Kurt Mosiejczuk wrote:
> > On Tue, Nov 19, 2019 at 07:40:37PM +, Stuart Henderson wrote:
> > > The actual packaged plist is the same either way for a py3-only port,
> > > MODPY_COMMENT expands to nothing. So it's just down to w
On 2019/11/19 15:00, Kurt Mosiejczuk wrote:
> On Tue, Nov 19, 2019 at 07:40:37PM +, Stuart Henderson wrote:
> > The actual packaged plist is the same either way for a py3-only port,
> > MODPY_COMMENT expands to nothing. So it's just down to whether the package
> > contents change or not.
>
> T
ov 19, 2019 at 01:55:45PM -0500, Kurt Mosiejczuk wrote:
I'm working on an update to devel/py-setuptools and so far the only port
I've found that is unhappy with it is ansible-lint. Upstream refactored
their setup.py for the next release to drop support for old versions and
it works swimm
On 2019/04/17 21:28, Daniel Jakots wrote:
> On Mon, 8 Apr 2019 00:11:59 -0400, Kurt Mosiejczuk
> wrote:
>
> > While I'm here, I figure I'll take maintainer unless someone has an
> > objection.
>
> You should get it in a bulk next time, instead of just caring about one
> category. Because it will
d it sthen@ asked me to bump in python.port.mk
# The setuptools module provides a package locator (site.py) that is
# required at runtime for the pkg_resources stuff to work
MODPY_SETUPUTILS_DEPEND ?= devel/py-setuptools${MODPY_FLAVOR}>=39.0.1v0
because then you don't have to bump every po
someone has an
:objection.
:
:--Kurt
:
:Index: Makefile
:===========
:RCS file: /cvs/ports/devel/py-setuptools/Makefile,v
:retrieving revision 1.32
:diff -u -p -r1.32 Makefile
:--- Makefile 30 Jul 2018 08:15:30 - 1.32
:+++ Makef
WRKDIST = ${WRKDIR}/RuleDispatch
Index: devel/py-setuptools/Makefile
===
RCS file: /cvs/ports/devel/py-setuptools/Makefile,v
retrieving revision 1.30
diff -u -p -r1.30 Makefile
--- devel/py-setuptools/Makefile3 Jan 2017 19:1
st release. Small tweak.
Anybody can done bulk build?
--
Alexandr Shadchin
Index: Makefile
=======
RCS file: /cvs/ports/devel/py-setuptools/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile29 Sep 2015 10:52:11 - 1.28
+++ Makefile8 Oct 2016 17:
Daniel Jakots, 30 Sep 2016 08:52:
> Which ports did you test, and how did you test them?
well..
i tested _a_ setuptools inside pyvenv-3.5
pip (8.1.1)
setuptools (20.10.1)
then another one inside virtualenv:
pip (8.1.2)
setuptools (28.2.0)
and as py-virtualenv-15.0.3 is supposed to come with
set
On Thu, 29 Sep 2016 23:44:01 +0200, frantisek holop
wrote:
> please test and commit.
>
> -f
Which ports did you test, and how did you test them?
please test and commit.
-f
--
no generalization is wholly true, not even this one.
Index: Makefile
===
RCS file: /cvs/ports/devel/py-setuptools/Makefile,v
retrieving revision 1.28
diff -u -p -r1.28 Makefile
--- Makefile29 Sep
king at setting PKGSPEC for setuputils to reduce the need
> > for future bumps..
>
> So I'm looking again at this update.
> I looked at PKGSPEC. I looked at the +CONTENTS in a package that
> depends on setuptools and there is :
> @depend devel/py-setuptools:py-setuptools-&g
ps..
So I'm looking again at this update.
I looked at PKGSPEC. I looked at the +CONTENTS in a package that
depends on setuptools and there is :
@depend devel/py-setuptools:py-setuptools->=18.2v0:py-setuptools-18.2p0v0
which must comes from
MODPY_SETUPUTILS_DEPEND ?= devel/py-setuptools${MODP
ommit the py-setuptools diff
2. commit the python.port.mk diff
3. bump every port that have a RUN_DEPENDS on py-setuptools
to be sure that every thing use the new version of py-setuptools. Am I
right?
, I understand that it should be:
1. commit the py-setuptools diff
2. commit the python.port.mk diff
3. bump every port that have a RUN_DEPENDS on py-setuptools
to be sure that every thing use the new version of py-setuptools. Am I
right?
On Sat, 27 Aug 2016 18:08:32 +0200, Daniel Jakots
wrote:
> Hi,
>
> I'd like to update py-setuptools to not to lag too much on upstream. I
> cooked a diff that I used on a test machine (i386 fwiw).
This time it's attached to it won't
Hi,
I'd like to update py-setuptools to not to lag too much on upstream. I
cooked a diff that I used on a test machine (i386 fwiw).
I looked for any need to change the plist for a few ports
(py-werkzeug, py-requests, youtube-dl, beets and py-cares), nothing
came up.
I asked aja to put the
Hey,
Thanks for looking into this Kili.
On Tue, Sep 22, 2015 at 10:39:25PM +0200, Matthias Kilian wrote:
> > Index: devel/py-certifi/pkg/PLIST
> > ===
> > RCS file: /home/edd/cvsync/ports/devel/py-certifi/pkg/PLIST,v
> [...]
> > -lib
Hi,
On Tue, Sep 01, 2015 at 06:33:05PM +0100, Edd Barrett wrote:
> The diff below updates py-setuptools and fixes obvious fallout.
>
> I found fallout by doing a partial bulk with anything needing setuptools as
> a BUILD_DEPENDS or RUN_DEPENDS.
>
> The breakage is (mostly)
Hi,
Remi and I were reflecting on how we have fallen behind with
py-setuptools. So I dived in...
The diff below updates py-setuptools and fixes obvious fallout.
I found fallout by doing a partial bulk with anything needing setuptools as
a BUILD_DEPENDS or RUN_DEPENDS.
The breakage is (mostly
t; Jason Tubnor said:
>> What is the history on holding back py-setuptools to 3.4.4 ?
>
> $ grep MAINTAINER devel/py-setuptools/Makefile
> $
>
> --
> Dmitrij D. Czarkoff
--
"Roads? Where we're going, we don't need roads" - Dr. Emmett "Doc" Brown
Jason Tubnor said:
> What is the history on holding back py-setuptools to 3.4.4 ?
$ grep MAINTAINER devel/py-setuptools/Makefile
$
--
Dmitrij D. Czarkoff
Hi,
What is the history on holding back py-setuptools to 3.4.4 ?
Portroach is stating that the latest is 12.0.1
http://portroach.openbsd.org/the%20openbsd%20ports%20mailing-list%20%3cpo...@openbsd.org%3E.html
Reason: I am working on a port of nikola (http://getnikola.com) which
has a few
This tweaks conflict markers for py-setuptools and py-distribute.
Packages fine on i386. Okay?
--
WBR,
Vadim Zhukov
Index: py-distribute/Makefile
===
RCS file: /cvs/ports/devel/py-distribute/Makefile,v
retrieving revision 1.7
===
RCS file: /cvs/ports/devel/py-setuptools/Makefile,v
retrieving revision 1.21
diff -u -p -r1.21 Makefile
--- Makefile20 Sep 2013 11:24:32 - 1.21
+++ Makefile13 Apr 2014 07:36:42 -
@@ -2,7 +2,7 @@
COMMENT= simplified packaging system for Python modules
On Fri, Sep 20, 2013 at 9:38 AM, Remi Pointel wrote:
> On Thu, 19 Sep 2013 21:42:25 +0100
> Edd Barrett wrote:
>> Hi,
>>
>> I noticed that our py-setuptools ports is quite lagging. The following
>> diff brings it up to date.
>>
>> Presumably setupto
On Thu, 19 Sep 2013 21:42:25 +0100
Edd Barrett wrote:
> Hi,
>
> I noticed that our py-setuptools ports is quite lagging. The following
> diff brings it up to date.
>
> Presumably setuptools is mostly used for building/installing python
> packages, so to test I have ch
Hi,
I noticed that our py-setuptools ports is quite lagging. The following
diff brings it up to date.
Presumably setuptools is mostly used for building/installing python
packages, so to test I have checked that every port depending upon this
still packages. I did this on a fresh install using a
On 2010/09/08 10:10, Joachim Schipper wrote:
> [Sorry, terribly busy and spotty internet - no patch!]
>
> I just noticed that math/py-numpy uses, but does not depend on,
> devel/py-setuptools.
http://undeadly.org/cgi?action=article&sid=20100902211748&mode=flat&count=0
On Wed, 8 Sep 2010, Joachim Schipper wrote:
> [Sorry, terribly busy and spotty internet - no patch!]
>
> I just noticed that math/py-numpy uses, but does not depend on,
> devel/py-setuptools.
Sure it does.
$ cd /usr/ports/math/py-numpy/ && make show=BUILD_DEPENDS
::lan
[Sorry, terribly busy and spotty internet - no patch!]
I just noticed that math/py-numpy uses, but does not depend on,
devel/py-setuptools.
Joachim
Replace the `c' in the version number by a `.' and add an epoch
number to make updates possible again.
ok?
Index: Makefile
===
RCS file: /cvs/ports/devel/py-setuptools/Makefile,v
retrieving revision 1.12
diff -u -p -r1.1
On Thu, 21 Sep 2006, Joerg Zinke wrote:
> On Thu, 21 Sep 2006 16:54:50 +1000 (EST)
> Damien Miller <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Any comments on this? I'm particulalry interested in comments/criticsm
> > of the changes to python.port.mk
> >
> > Once this is in, I have a complete
encies on its own and do not ignore pkg_* tools.
so its possible better to install sqlobject, turbogears, ...
with classic distutils and without easy_install. this should be no
problem because easy_install is compatible with distutils.
anyway: its good to have a port of py-setuptools, but i thi
Hi,
Any comments on this? I'm particulalry interested in comments/criticsm
of the changes to python.port.mk
Once this is in, I have a complete port of the Pylons web application
framework and its dependencies (inc. SQLObject and SQLAlchemy)
ready...
-d
On Mon, 18 Sep 2006, Damien Miller wrote:
On Mon, Sep 18, 2006 at 04:11:08AM +1000, Damien Miller wrote:
> Attached is a port of "setuptools" for Python. setuptools is a
> mostly-compatible replacement for the standard distutils library
> that lots of packages are starting to require.
[...]
> Also attached is a patch to lang/python/python
ned(MODPY_SETUPTOOLS) && ${MODPY_SETUPTOOLS:U} == YES
+_MODPY_LIB_DEPENDS?= :py-setuptools-*:devel/py-setuptools
+LIB_DEPENDS+= ${_MODPY_LIB_DEPENDS}
+.endif
+
.if !defined(NO_SHARED_LIBS) || ${NO_SHARED_LIBS:U} != YES
MODPY_EXPAT_DEPENDS=
:python-expat-${MODPY_VERSION}*:lang/py
50 matches
Mail list logo
