Reorganization of the py-sqlalchemy ports

[Matthew Seaman]

Dear all,

The state of the SQLAlchemy ports currently in the tree is pretty dire.
SQLAlchemy is perhaps the premiere ORM written in Python and we really
should have decent support for it.  Plus I know of at least two new as
yet uncommitted ports waiting on availability of an up-to-date version.

Can I draw your attention to PRs 191442 and 205852 and Review D908:

   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191442
   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205852
   https://reviews.freebsd.org/D908

The scope of changes involved includes, amongst other things, a
reorganization of what sqlalchemy ports are available in the tree.
Currently we have:

   Port Version Maintainer
   --
   py-sqlalchemy06  0.6.9   ni...@freebsd.org
   py-sqlalchemy0.7.10  ni...@freebsd.org
   py-sqlalchemy-devel  0.8.2   ni...@freebsd.org

I'm proposing the following:

   py-sqlalchemy06  0.6.9   ni...@freebsd.org (Deprecate 2016-08-20)
   py-sqlalchemy07  0.7.10  ni...@freebsd.org (Deprecate 2016-08-20)
   py-sqlalchemy08  0.8.7   ni...@freebsd.org
   py-sqlalchemy09  0.9.10  m.tsatse...@gmail.com
   py-sqlalchemy10  1.0.13  m.tsatse...@gmail.com

I've marked two of the ports for deletion in 3 months time, on the basis
that a) upstream has declared those ports EoL and b) 5 different
versions of the same package is really a bit much.

During that three months, there is further work to do on consumers of
SQLAlchemy in the tree: most consumers should work happily with more
recent versions, but currently most of them are depending on version
0.7.x as the generic 'py-sqlalchemy' port.  This will all need testing,
obviously.

Comments, constructive criticism and reviews welcome.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Re: Why clang++37 behaves differently on 9.3 and 10.3?

[Matthias Andree]

Am 12.05.2016 um 19:59 schrieb Dimitry Andric:
> On 12 May 2016, at 13:33, Yuri wrote:
>>
>> clang++37 compiles this simple program fine on 10.3, but fails on 9.3.
>>
>> Why does it behave differently on different OS versions?
>>
>> It looks like it ignores -std=c++11 on 9.3.
> 
> You cannot compile for C++11 on a 9.x installation, because clang will
> use libstdc++ by default there, and the version of libstdc++ in the
> 9.x base system is not C++11 compatible.
> 
> To be able to use C++11, you must install libc++ first, using for
> example:

[...]

> On FreeBSD 10.x, clang and libc++ are the defaults, and C++11 can be
> used out of the box.

[...]

(Not meaning to pollute bugzilla yet, hence by mail -- feel free to
upload whichever portions of this to the PR that you feel like, unless
you contort the context. Everyone be aware of Jan's CPPFLAGS hints in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209467#c5 that
rawtherapee does not currently set explicitly.)

I was wondering... for the rawtherapee build in the ports framework I'm
doing this (shown below), namely, force the port to use *libc++ with
GCC* (I need(ed) to force GCC because clang used to lack OpenMP support,
and I needed to match the C++ standard library to what the base system
provides by default, that's why it is under the COMPILER_FEATURES check).
I think the original idea was from Baptiste Daroussin.

I was wondering if it would work for Yuri as well on 9.3 (where
graphics/rawtherapee would not normally use it because libc++ isn't part
of COMPILER_FEATURES there).  The key will certainly be -nostdinc++ to
get GNU libstdc++ out of the way and the flags to pull the ports libc++ in.

The additional difficulty will be that the third-party requisite C++
libraries, if any,  would likely have to be recompiled the same way.

Mixing and matching GNU libstdc++ and libc++ in the same executable
won't work (because these two libraries only agree on the API more or
less, but neither the ABI nor the internal structure layouts).



62  .if ${COMPILER_FEATURES:Mlibc++}
63  LDFLAGS+=   -L/usr/local/lib/c++
64  CXXFLAGS+=  -nostdinc++ -isystem /usr/local/include/c++/v1
65  CFLAGS+=-isystem /usr/local/include/c++/v1
66  BUILD_DEPENDS+=
${LOCALBASE}/lib/c++/libstdc++.so:${PORTSDIR}/devel/libc++
67  .endif
___
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
+-+
print/lilypond-devel| 2.19.11 | 2.19.42
+-+
textproc/elasticsearch-plugin-marvel| 1.3.1   | 2.3.3
+-+


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.
___
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: Using the subversion switch command to keep up with quarterly branches

[Torsten Zuehlsdorff]

Hello Mel,


I track the quarterly ports branches so that I can build ports from the
same tree as binary packages so that I don't, for example, have to build
all 2783 packages on my dev VM, just the 13 where I need non-default
options.  Yes I know, "That is not the intended use, ma'am," blah blah
void my warranty, etc.  This is a dev/preprod instance, I am TRYING to
break it.

Since the current quarter's branch name changes each quarter (2016Q1,
2016Q2), you can't just relocate and update, you need to use the switch
command.  I really just want to keep up with the current quarter and
would like to take advantage of already having most of the branch
already downloaded.

Is it safe to use the switch command to jump ports quarterly branches
(assuming a read-only check-out), or are there special gotchas in how
FreeBSD is doing the branches?


Yes, this should be safe. I use the switch command in many different 
projects and it always works fine. Even with local modifications the 
switch works good.


Greetings,
Torsten


___
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: Using the subversion switch command to keep up with quarterly branches

[Thomas Mueller]

Excerpt from Melissa Pilgrim:

> I wasn't aware there was a lightweight git client in base.

I wasn't aware either, still can't find it, looked in /usr/bin and /usr/sbin as 
well as online Porters' Handbook and FreeBSD Handbook.

Where is the lightweight git client?  I know there is an optional svnlite, but 
what is for git?


Tom

___
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: Using the subversion switch command to keep up with quarterly branches

[Kurt Jaeger]

Hi!

> > I wasn't aware there was a lightweight git client in base.
> 
> I wasn't aware either, still can't find it, looked in /usr/bin
> and /usr/sbin as well as online Porters' Handbook and FreeBSD
> Handbook.
> 
> Where is the lightweight git client?  I know there is an optional
> svnlite, but what is for git?

There is no git client in base (yet?).

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
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"

KDE-FreeBSD: commiters and mentors needed

[Ralf Nolden]

Hi all,

the KDE/FreeBSD (k...@freebsd.org) has some commiters that currently check in 
our work to the ports tree (see https://freebsd.kde.org/people.php), which to 
my knowledge are mainly makc and rakuco along with Alonso Schaich.

All three do a really good work in carefully checking which parts to submit 
from our ports tree, however, the amount of ports that we maintain, prepare 
and test are a really large pile. Personal restraints in time available for 
commits and prior testing limit our productivity down to a point where a lot 
of port versions are done only for area51 tree and never make it to the main 
ports tree. Added to those circumstances are the increased speed of releases 
of KDE and Qt, which almost require weekly attention from our side, so we 
would really like to get our "done" pile loaded off to the main ports tree.

To help with the situation, it would be really greatly appreciated if some 
commiters would actually a) help us commit and b) mentor some of us who are 
already doing the porting work in the area51 ports tree so we can merge more 
and sooner than is currently happening due to time constraints of the people 
who took up this task until now. As said, this is not a complaint about the 
people who did the commits up to now, but a realization that the time of the 
people who have commit access does not last to keep up with the speed of 
development, so we need some solution that would help us get things moving.

For commiters willing to help and those who would be willing to mentor us, 
please contact us at #kde-freebsd and/or on k...@freebsd.org.

Thank you for your attention.

-- 
Kind regards,

Ralf Nolden

___
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: Reorganization of the py-sqlalchemy ports

[Olivier Duchateau]

On Wed, 18 May 2016 08:02:59 +0100
Matthew Seaman  wrote:

> 
> Dear all,
> 
> The state of the SQLAlchemy ports currently in the tree is pretty dire.
> SQLAlchemy is perhaps the premiere ORM written in Python and we really
> should have decent support for it.  Plus I know of at least two new as
> yet uncommitted ports waiting on availability of an up-to-date version.
> 
> Can I draw your attention to PRs 191442 and 205852 and Review D908:
> 
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191442
>https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205852
>https://reviews.freebsd.org/D908
> 
> The scope of changes involved includes, amongst other things, a
> reorganization of what sqlalchemy ports are available in the tree.
> Currently we have:
> 
>Port Version Maintainer
>--
>py-sqlalchemy06  0.6.9   ni...@freebsd.org
>py-sqlalchemy0.7.10  ni...@freebsd.org
>py-sqlalchemy-devel  0.8.2   ni...@freebsd.org
> 
> I'm proposing the following:
> 
>py-sqlalchemy06  0.6.9   ni...@freebsd.org (Deprecate 2016-08-20)
>py-sqlalchemy07  0.7.10  ni...@freebsd.org (Deprecate 2016-08-20)
>py-sqlalchemy08  0.8.7   ni...@freebsd.org
>py-sqlalchemy09  0.9.10  m.tsatse...@gmail.com
>py-sqlalchemy10  1.0.13  m.tsatse...@gmail.com

I wonder, why to create as many SQLAlchemy ports as releases (it's just an ORM 
after all).
The easiest way, imho is focusing on 1.0.x releases, and having only one port 
databases/py-sqlalchemy.

> 
> I've marked two of the ports for deletion in 3 months time, on the basis
> that a) upstream has declared those ports EoL and b) 5 different
> versions of the same package is really a bit much.
> 
> During that three months, there is further work to do on consumers of
> SQLAlchemy in the tree: most consumers should work happily with more
> recent versions, but currently most of them are depending on version
> 0.7.x as the generic 'py-sqlalchemy' port.  This will all need testing,
> obviously.
> 
> Comments, constructive criticism and reviews welcome.
> 
>   Cheers,
> 
>   Matthew
> 
> 
> 


-- 
Olivier Duchateau 
___
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"