bugzilla-noreply | 1 Oct 15:32 2014
Picon

[Bug 191943] lang/python34 won't build in jail if software and kernel versions doesn't match

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

Eir Nym <eirnym <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |Issue Resolved
         Resolution|---                         |FIXED

--- Comment #13 from Eir Nym <eirnym <at> gmail.com> ---
I think it better to has less hijacking to set this variables this way.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
Ewout Boks | 1 Oct 09:18 2014
Picon

FreeBSD Port: wxglade-0.6.8_4

Hi,

I wanted to let you know that wxGlade, as it is configured in FreeBSD at the moment, is non-functional.
wxGlade 0.6.8 must be used with wxpython 2.8 . It is incompatible with wxpython-3.0  :

from http://wxglade.sourceforge.net/ :

2014‑08‑31 News from next release:
The next release will be a major release. It will introduce the support for generating code for wxWidgets
3.0. But wxGlade will still not running with Python3. 
General changes:

Could you please revert it to wxpython 2.8 ?

With best regards,

Ewout Boks
_______________________________________________
freebsd-python <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-python
To unsubscribe, send any mail to "freebsd-python-unsubscribe <at> freebsd.org"
bugzilla-noreply | 30 Sep 22:52 2014
Picon

[Bug 191943] lang/python34 won't build in jail if software and kernel versions doesn't match

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

--- Comment #12 from Bryan Drewery <bdrewery <at> FreeBSD.org> ---
(In reply to Eir Nym from comment #11)
> Thank you! This fixes issue... but
> 
> Why can't I pass UNAME_r in /etc/make.conf ?

You can, see /usr/ports/CHANGES for example:

OSVERSION+=     1100036
UNAME_ENV+=     OSVERSION=${OSVERSION}
UNAME_ENV+=     UNAME_s=FreeBSD
UNAME_ENV+=     UNAME_r=11.0-CURRENT
UNAME_ENV+=     UNAME_v="${UNAME_s} ${UNAME_r}"
.MAKEFLAGS:     ${UNAME_ENV}
MAKE_ENV+=      ${UNAME_ENV}
CONFIGURE_ENV+= ${UNAME_ENV}
SCRIPTS_ENV+=   ${UNAME_ENV}

Perhaps I should make it simpler so that setting UNAME_* auto propagates to the
environment.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
bugzilla-noreply | 30 Sep 22:50 2014
Picon

[Bug 191943] lang/python34 won't build in jail if software and kernel versions doesn't match

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

--- Comment #11 from Eir Nym <eirnym <at> gmail.com> ---
Thank you! This fixes issue... but

Why can't I pass UNAME_r in /etc/make.conf ?

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
bugzilla-noreply | 30 Sep 18:22 2014
Picon

[Bug 191943] lang/python34 won't build in jail if software and kernel versions doesn't match

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

--- Comment #10 from commit-hook <at> freebsd.org ---
A commit references this bug:

Author: bdrewery
Date: Tue Sep 30 16:22:06 UTC 2014
New revision: 369644
URL: https://svnweb.freebsd.org/changeset/ports/369644

Log:
  If either of OSVERSION or UNAME_r is improperly set when building in a
  jail/chroot, a number of unexpected errors can occur.

    1. autotools fixup may not run when needed. This could be avoided by always
       running it [PR 177980, 177403].
    2. Not having UNAME_r set will cause many unknown
       errors. Many ports use OSREL (derived from UNAME_r) to determine the
name
       of files. This is usually also due to the port build itself using uname
-r
       to derive filenames or 'built for' messages. [PR 192449, 191943] Without
       having these sanity checks it is very easy for users to get into
       situations where "everything worked" until they touch a certain port
that
       reads uname(1) output or OSVERSION. It has always been necessary to
define
       all of the UNAME_ vars and OSVERSION (or have a proper sys/param.h
       present), but many users do not know this.

(Continue reading)

bugzilla-noreply | 30 Sep 15:55 2014
Picon

[Bug 193787] [MAINTAINER] devel/py-robotframework-selenium2library: convert to USES=python

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

William Grzybowski <wg <at> FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wg <at> FreeBSD.org
           Assignee|python <at> FreeBSD.org          |wg <at> FreeBSD.org

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
portscout | 30 Sep 12:05 2014
Picon

FreeBSD ports you maintain which are out of date

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/python <at> freebsd.org.html

Port                                            | Current version | New version
------------------------------------------------+-----------------+------------
www/xist                                        | 3.25            | 5.9.1
------------------------------------------------+-----------------+------------

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

Thanks.
Thomas Mueller | 30 Sep 09:46 2014
Picon

py-sqlite3 fails on missing _ctypes

Trying to update www/seamonkey, I failed on an error in databases/py-sqlite3 relating to _ctypes, am not
really familiar with that.

I am on FreeBSD-current amd64, updated from source yesterday.

I tried to portmaster databases/py-sqlite3 separately after initial failure, to isolate the error.

Log file is short:

===>>> Currently installed version: py27-sqlite3-2.7.6_4
===>>> Port directory: /usr/ports/databases/py-sqlite3

===>>> Gathering distinfo list for installed ports

===>>> Launching 'make checksum' for databases/py-sqlite3 in background
===>>> Gathering dependency list for databases/py-sqlite3 from ports
===>>> Initial dependency check complete for databases/py-sqlite3

]0;portmaster: py27-sqlite3-2.7.6_4
===>>> Starting build for databases/py-sqlite3 <<<===

===>>> All dependencies are up to date

===>  Cleaning for py27-sqlite3-2.7.8_5
===>  License PSFL accepted by the user
===>   py27-sqlite3-2.7.8_5 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by py27-sqlite3-2.7.8_5 for building
===>  Extracting for py27-sqlite3-2.7.8_5
=> SHA256 Checksum OK for python/Python-2.7.8.tar.xz.
===>  Patching for py27-sqlite3-2.7.8_5
(Continue reading)

Dmitry Sivachenko | 30 Sep 09:23 2014
Picon

Re: svn commit: r369447 - head/math/py-numpy


On 30 сент. 2014 г., at 2:06, Thierry Thomas <thierry <at> FreeBSD.org> wrote:

> Le lun 29 sep 14 à 19:43:52 +0200, Thierry Thomas <thierry <at> FreeBSD.org>
> écrivait :
> 
>>> No idea, I have 11-CURRENT/amd64 here and it fails too.
>>> 
>>> So at least FreeBSD version does not matter.
>> 
>> I'll just build it successfully in poudriere for 92i386 and 10amd64.
>> 
>> To be continued...
> 
> Sorry: I was not testing science/py-scipy!
> 
> Now I have been able to reproduce the failure and to fix it: I don't
> really understand why, but it builds libraries without '-shared'!
> 
> Just adding `LDFLAGS+= -shared' fixes it (see the attached patch).
> I'm not sure if this is related to the patch of numpy or to the upgrade
> of Gcc 4.7 to 4.8?
> 
> Anyway, this port is full of warnings...
> 

Thanks, Thierry.

See also http://package20.nyi.freebsd.org/data/91amd64-default-baseline/369506/logs/errors/py27-symeig-1.5_1.log
Looks like the same issue.
(Continue reading)

Baptiste Daroussin | 29 Sep 10:01 2014
Picon

Re: incorrect dependency registration?

On Mon, Sep 29, 2014 at 11:52:50AM +0400, Dmitry Sivachenko wrote:
> Hello,
> 
> I am using FreeBSD-10/stable and pkg-1.3.8.
> 
> Consider py-dateutil port, it depends on py-six.
> 
> First, I installed py33-dateutil (with py33-six), for python3.
> 
> Now I install py-dateutil for python2.  Upon installation, I get the following waring:
> ===>  Installing for py27-dateutil-2.2
> ===>   py27-dateutil-2.2 depends on package: py27-six>0 - found
> ===>   py27-dateutil-2.2 depends on package: py27-setuptools27>0 - found
> ===>   py27-dateutil-2.2 depends on file: /usr/local/bin/python2.7 - found
> ===>  Checking if py27-dateutil already installed
> ===>   Registering installation for py27-dateutil-2.2
> pkg-static: py27-dateutil-2.2: duplicate dependency listing: py33-six-1.5.2, ignoring
> 
> When I try to deinstall py27-six, I get:
> 
> # pkg delete py27-six
> Checking integrity... done (0 conflicting)
> Deinstallation has been requested for the following 3 packages (of 0 packages in the universe):
> 
> Installed packages to be REMOVED:
>         py27-six-1.8.0
>         py33-dateutil-2.1_3 (depends on py27-six-1.8.0)
>         py27-dateutil-2.2 (depends on py27-six-1.8.0)
> 
> The operation will free 1 MB.
(Continue reading)

Alfred Perlstein | 29 Sep 06:13 2014

Re: help on freefall please? virtualenv + django? sqlite doesn't work?

OK, I sort of get it but...

This had to happen:
env CFLAGS=-I/usr/local/include pip install pysqlite

That is not intuitive, why do users need to do this on FreeBSD?  No 
other platform requires this.

I thought this was fixed a while back, is this still a problem on 
mainstream FreeBSD?

-Alfred

On 9/28/14, 9:08 PM, Alfred Perlstein wrote:
> I don't get it, why is there no sqlite?
>
> Is this just "freefall" that is broken... or is it FreeBSD in general 
> that you can't virtualenv+django with?  halp!!
>
> (github2bugzilla).(04:01:24)(alfred <at> freefall.freebsd.org)
> ~/github2bugzilla/ghb % python manage.py
> Traceback (most recent call last):
>   File "manage.py", line 10, in <module>
>     execute_from_command_line(sys.argv)
>   File 
>
"/home/alfred/github2bugzilla/lib/python2.7/site-packages/django/core/management/__init__.py", 
> line 385, in execute_from_command_line
>     utility.execute()
>   File 
(Continue reading)


Gmane