<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pkgsrc/lang/python27/buildlink3.mk, branch pkgsrc-2014Q2</title>
<subtitle>[no description]</subtitle>
<id>https://git.osdyson.ru/mirror/pkgsrc/atom?h=pkgsrc-2014Q2</id>
<link rel='self' href='https://git.osdyson.ru/mirror/pkgsrc/atom?h=pkgsrc-2014Q2'/>
<link rel='alternate' type='text/html' href='https://git.osdyson.ru/mirror/pkgsrc/'/>
<updated>2012-05-07T01:53:12Z</updated>
<entry>
<title>Set BUILDLINK_ABI_DEPENDS correctly (with +=, not ?=)</title>
<updated>2012-05-07T01:53:12Z</updated>
<author>
<name>dholland</name>
<email>dholland@pkgsrc.org</email>
</author>
<published>2012-05-07T01:53:12Z</published>
<link rel='alternate' type='text/html' href='https://git.osdyson.ru/mirror/pkgsrc/commit/?id=0bcdacfbcf0a1f7f4455399808295e6e6f7e01bc'/>
<id>urn:sha1:0bcdacfbcf0a1f7f4455399808295e6e6f7e01bc</id>
<content type='text'>
It turns out there were a lot of these.</content>
</entry>
<entry>
<title>recursive bump from gettext-lib shlib bump.</title>
<updated>2011-04-22T13:41:54Z</updated>
<author>
<name>obache</name>
<email>obache@pkgsrc.org</email>
</author>
<published>2011-04-22T13:41:54Z</published>
<link rel='alternate' type='text/html' href='https://git.osdyson.ru/mirror/pkgsrc/commit/?id=0e2c97799a873b423fce3b9a712f48300f567461'/>
<id>urn:sha1:0e2c97799a873b423fce3b9a712f48300f567461</id>
<content type='text'>
</content>
</entry>
<entry>
<title>comment out BUILDLINK_INCDIRS/BUILDLINK_LIBDIRS/BUILDLINK_TRANSFORM</title>
<updated>2011-04-15T17:23:23Z</updated>
<author>
<name>drochner</name>
<email>drochner@pkgsrc.org</email>
</author>
<published>2011-04-15T17:23:23Z</published>
<link rel='alternate' type='text/html' href='https://git.osdyson.ru/mirror/pkgsrc/commit/?id=67808816f60c9e248c799096967ed064989044ab'/>
<id>urn:sha1:67808816f60c9e248c799096967ed064989044ab</id>
<content type='text'>
definitions which do things behind the client pkgs back, in particular
manipulate the library search path
It is well possible that this causes some fallout, but I hope it
will be small and can be dealt with on a per-pkg basis.
(partly) suggested by Mark Davies on tech-pkg</content>
</entry>
<entry>
<title>Fix unprivileged build</title>
<updated>2011-02-22T10:50:37Z</updated>
<author>
<name>adam</name>
<email>adam@pkgsrc.org</email>
</author>
<published>2011-02-22T10:50:37Z</published>
<link rel='alternate' type='text/html' href='https://git.osdyson.ru/mirror/pkgsrc/commit/?id=7fed5c880fc5903bab75eb8acc3477df5764cd54'/>
<id>urn:sha1:7fed5c880fc5903bab75eb8acc3477df5764cd54</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Import python27-2.7.1 as lang/python27.</title>
<updated>2011-02-22T08:51:58Z</updated>
<author>
<name>obache</name>
<email>obache@pkgsrc.org</email>
</author>
<published>2011-02-22T08:51:58Z</published>
<link rel='alternate' type='text/html' href='https://git.osdyson.ru/mirror/pkgsrc/commit/?id=823200efadb3c0f028dc8950276050b6512afaac'/>
<id>urn:sha1:823200efadb3c0f028dc8950276050b6512afaac</id>
<content type='text'>
Python 2.7 is intended to be the last major release in the 2.x series.
The Python maintainers are planning to focus their future efforts on
the Python 3.x series.

This means that 2.7 will remain in place for a long time, running
production systems that have not been ported to Python 3.x.
Two consequences of the long-term significance of 2.7 are:

* It's very likely the 2.7 release will have a longer period of
  maintenance compared to earlier 2.x versions.  Python 2.7 will
  continue to be maintained while the transition to 3.x continues, and
  the developers are planning to support Python 2.7 with bug-fix
  releases beyond the typical two years.

* A policy decision was made to silence warnings only of interest to
  developers.  :exc:`DeprecationWarning` and its
  descendants are now ignored unless otherwise requested, preventing
  users from seeing warnings triggered by an application.  This change
  was also made in the branch that will become Python 3.2. (Discussed
  on stdlib-sig and carried out in :issue:`7319`.)

  In previous releases, :exc:`DeprecationWarning` messages were
  enabled by default, providing Python developers with a clear
  indication of where their code may break in a future major version
  of Python.

  However, there are increasingly many users of Python-based
  applications who are not directly involved in the development of
  those applications.  :exc:`DeprecationWarning` messages are
  irrelevant to such users, making them worry about an application
  that's actually working correctly and burdening application developers
  with responding to these concerns.

  You can re-enable display of :exc:`DeprecationWarning` messages by
  running Python with the :option:`-Wdefault &lt;-W&gt;` (short form:
  :option:`-Wd &lt;-W&gt;`) switch, or by setting the :envvar:`PYTHONWARNINGS`
  environment variable to ``"default"`` (or ``"d"``) before running
  Python.  Python code can also re-enable them
  by calling ``warnings.simplefilter('default')``.</content>
</entry>
</feed>
