-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python 2.6 in 2015Q1 on OSX looking for hardcoded directory #262
Comments
Hm interesting, thanks. There are pkgsrc checks which should warn about things like this, I'll ensure they are enabled in future builds (and work correctly with the OS X toolchain). |
Oops, sorry, I misreported the version. I actually see this in 2015Q1, which I seem to have accidentally grabbed, meaning to grab 2014Q4. I'm also seeing other weird things in 2015Q1, e.g. running upgrade on a completely fresh install wants to install 1634 new packages (mostly py26-, py27-, and p5-* stuff, but also e.g. ImageMagick). I blew it away and went back to 2014Q4, and everything works fine there. |
Yeh, upgrades across branches can be messy, a number of people have reported the large number of packages that pkgin wants to upgrade thing on SmartOS too - maybe @iMilnb has some ideas there? Again that's something we definitely want to fix. |
* Release 0.12.2 (28-Aug-2016) ** Improved Tor Connection Handler The `tor.control_endpoint` connection handler now properly handles the config.SocksPort response provided by the debian Tor daemon (and possibly others), which included a confusing unix-domain socket in its response. The `tor.socks_port` handler was changed to accept both hostname and port number. Using anything but "localhost" or "127.0.0.1" is highly discouraged, as it would reveal your IP address to (possibly hostile) external hosts. This change was made to support applications (e.g. Tahoe-LAFS) which accept endpoint strings to configure socks_port, but then parse them and reject anything but TCP endpoints (to match Foolscap's current limitations). Such applications ought to warn their users to use only localhost. * Release 0.12.1 (20-Aug-2016) ** Connection Handlers for SOCKS, Tor, I2P Foolscap now includes importable connection handlers for SOCKS(5a), Tor, and I2P. #242, #246, #261 These handlers require additional supporting libraries, so they must be imported separately, and a setuptools "extra feature" declaration must be used to ask for the supporting libs. For example, applications which want to use `tor:` hints (on a host with a Tor daemon running) should have a setup.py with: install_requires=["foolscap[tor]"], and the Tub setup code should do: from foolscap.connections import tor tub.addConnectionHintHandler("tor", tor.default_socks()) Full examples and docs are available in docs/connection-handlers.rst. The default connection-negotiation timeout was increased from 60s to 120s, to accomodate tor/i2p daemon startup times. * Release 0.12.0 (20-Jul-2016) ** API changes: no more automatic configuration Foolscap has moved from automatic listener configuration (randomly-allocated TCP ports, automatically-determined IP address) to using more predictable manual configuration. In our experience, the automatic configuration only worked on hosts which had external IP addresses, which (sadly) is not the case for most computers attached to the modern internet. #252 Applications must now explicitly provide Foolscap with port numbers (for Tub.listenOn) and hostnames (for Tub.setLocation). Applications are encouraged to give users configuration controls to teach Foolscap what hostname and port number it should advertise to external hosts in the FURLs it creates. See https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773 for ideas. The specific API changes were: - Tub.setLocationAutomatically() has been deprecated - Listener.getPortnum() has been deprecated - calling Tub.listenOn("tcp:0") is also deprecated: callers should allocate a port themselves (the foolscap.util.allocate_tcp_port utility function, which does not block, has been added for this purpose). Foolscap tools like "flappserver create" and "flogtool create-gatherer" will no longer try to deduce their external IP address in an attempt to build externally-reachable FURLs, and will no longer accept "tcp:0" as a listening port (they now default to specific port numbers). Instead, they have --location= and --port arguments. The user must provide '--location' with a connection-hint string like 'tcp:hostname.example.org:3117' (which is put into the server's FURLs). This must match the corresponding '--port' argument, if provided. - for all tools, if '--port' is provided, it must not be tcp:0 - 'flappserver create' now requires --location, and '--port' defaults to tcp:3116 - 'flogtool create-gatherer' requires --location, default port is tcp:3117 - 'flogtool create-incident-gatherer' does too, default is tcp:3118 For backwards-compatibility, old flappservers will have "tcp:0" written into their "BASEDIR/port" file, and an empty string in "BASEDIR/location": these must then be edited to allow the flappserver to start. For example, write "tcp:12345" into "BASEDIR/port" to assign a portnumber, and "tcp:HOSTNAME:12345" into "BASEDIR/location" to expose it in the generated FURL. ** Other API changes Tub.listenOn() now takes a string or an Endpoint (something that implements twisted.internet.interfaces.IStreamServerEndpoint). This makes it possible to listen on non-IPv4 sockets (e.g. IPv6-only sockets, or unix-domain sockets, or more exotic endpoints), as long as Tub.setLocation() is set to something which the other end's connection handlers can deal with. #203 #243 The "DefaultTCP" handler (which manages normal "tcp:HOST:PORT" connection hints) has been moved to foolscap.connections.tcp . This makes room for new Tor/I2P/SOCKS handlers to live in e.g. foolscap.connections.tor . #260 Connection handlers are now allowed to return a Deferred from hint_to_endpoint(), which should make some handlers easier to write. #262 Note that RemoteReference.notifyOnDisconnect() will be deprecated in the next release (once all internal uses have been removed from Foolscap). Applications should stop using it as soon as possible. #42 #140 #207 ** Compatibility Changes This release removes support for the old (py2.4) "sets" module. This was retained to support applications which were trying to maintain py2.4 compatibility, but it's been so long since this was necessary, it's time to remove it. ** Other Changes The internal `allocate_tcp_port()` function was fixed: unexpected kernel behavior meant that sometimes it would return a port that was actually in use. This caused unit tests to fail randomly about 5% of the time. #258 IPv6 support is nearly complete: listening on a plain TCP port will typically accept connections via both IPv4 and IPv6, and the DefaultTCP handler will do a hostname lookup that can use both A and AAAA records. So as long as your server has a DNS entry that points at its IPv6 address, and you provide the hostname to Tub.setLocation(), Foolscap will connect over IPv6. There is one piece missing for complete support: the DefaultTCP connection handler must be modified to accept square-bracketed numeric IPv6 addresses, for rare situations where the host has a known (stable) IPv6 address, but no DNS name.
## 1.2.1 * Fixed #272. Workaround Ruby bug 12832 which caused interpreter to hang. See https://bugs.ruby-lang.org/issues/12832. Thanks to @chrisroos & @petems (6f1c8b9b, #273). ## 1.2.0 * Always use prepended module to stub class & instance methods for Ruby v2+ - thanks to @grosser & @chrisroos (43d56671, #244) * Always use prepended module to stub AnyInstance methods in Ruby v2+ - thanks to @chrisroos (#262) * Always set visibility of stub method to match stubbed method on included module - thanks to @grosser & @chrisroos (e87c03b0, #248) * Always set visibility to stub method to match stubbed method on superclass - thanks to @chrisroos (38d902ad) * Allow stubbing of method to which any instance responds (#200) * Allow `includes` matcher to take matcher arguments - thanks to @lazyatom (#217) * Avoid exception in older version of Rubygems - thanks to @chrisroos (78d930a7) * Add licenses to gemspec as requested by @coreyhaines (#201) * Fix typo in README - thanks to @jaredbeck (6119460d) * Added section about using Mocha with RSpec & Rails to README (#221) * Fix documentation for Mocha::API#stub method - thanks to @raeno (599b1dcd) * Added backers and sponsors from OpenCollective - thanks to @piamancini (#253) * Fix typo in docs for equals - thanks to @alexcoco (#254) * Add known issue for Ruby v1.8 to README - thanks to @chrisroos (2c642096)
Version 0.14.2 -------------- Released 2017-01-10 - Fix bug where ``FlaskForm`` assumed ``meta`` argument was not ``None`` if it was passed. (`#278`_) .. _#278: pallets-eco/flask-wtf#278 Version 0.14.1 -------------- Released 2017-01-10 - Fix bug where the file validators would incorrectly identify an empty file as valid data. (`#276`_, `#277`_) - ``FileField`` is no longer deprecated. The data is checked during processing and only set if it's a valid file. - ``has_file`` *is* deprecated; it's now equivalent to ``bool(field.data)``. - ``FileRequired`` and ``FileAllowed`` work with both the Flask-WTF and WTForms ``FileField`` classes. - The ``Optional`` validator now works with ``FileField``. .. _#276: pallets-eco/flask-wtf#276 .. _#277: pallets-eco/flask-wtf#277 Version 0.14 ------------ Released 2017-01-06 - Use itsdangerous to sign CSRF tokens and check expiration instead of doing it ourselves. (`#264`_) - All tokens are URL safe, removing the ``url_safe`` parameter from ``generate_csrf``. (`#206`_) - All tokens store a timestamp, which is checked in ``validate_csrf``. The ``time_limit`` parameter of ``generate_csrf`` is removed. - Remove the ``app`` attribute from ``CsrfProtect``, use ``current_app``. (`#264`_) - ``CsrfProtect`` protects the ``DELETE`` method by default. (`#264`_) - The same CSRF token is generated for the lifetime of a request. It is exposed as ``g.csrf_token`` for use during testing. (`#227`_, `#264`_) - ``CsrfProtect.error_handler`` is deprecated. (`#264`_) - Handlers that return a response work in addition to those that raise an error. The behavior was not clear in previous docs. - (`#200`_, `#209`_, `#243`_, `#252`_) - Use ``Form.Meta`` instead of deprecated ``SecureForm`` for CSRF (and everything else). (`#216`_, `#271`_) - ``csrf_enabled`` parameter is still recognized but deprecated. All other attributes and methods from ``SecureForm`` are removed. (`#271`_) - Provide ``WTF_CSRF_FIELD_NAME`` to configure the name of the CSRF token. (`#271`_) - ``validate_csrf`` raises ``wtforms.ValidationError`` with specific messages instead of returning ``True`` or ``False``. This breaks anything that was calling the method directly. (`#239`_, `#271`_) - CSRF errors are logged as well as raised. (`#239`_) - ``CsrfProtect`` is renamed to ``CSRFProtect``. A deprecation warning is issued when using the old name. ``CsrfError`` is renamed to ``CSRFError`` without deprecation. (`#271`_) - ``FileField`` is deprecated because it no longer provides functionality over the provided validators. Use ``wtforms.FileField`` directly. (`#272`_) .. _`#200`: pallets-eco/flask-wtf#200 .. _`#209`: pallets-eco/flask-wtf#209 .. _`#216`: pallets-eco/flask-wtf#216 .. _`#227`: pallets-eco/flask-wtf#227 .. _`#239`: pallets-eco/flask-wtf#239 .. _`#243`: pallets-eco/flask-wtf#243 .. _`#252`: pallets-eco/flask-wtf#252 .. _`#264`: pallets-eco/flask-wtf#264 .. _`#271`: pallets-eco/flask-wtf#271 .. _`#272`: pallets-eco/flask-wtf#272 Version 0.13.1 -------------- Released 2016/10/6 - Deprecation warning for ``Form`` is shown during ``__init__`` instead of immediately when subclassing. (`#262`_) - Don't use ``pkg_resources`` to get version, for compatibility with GAE. (`#261`_) .. _`#261`: pallets-eco/flask-wtf#261 .. _`#262`: pallets-eco/flask-wtf#262 Version 0.13 ------------ Released 2016/09/29 - ``Form`` is renamed to ``FlaskForm`` in order to avoid name collision with WTForms's base class. Using ``Form`` will show a deprecation warning. (`#250`_) - ``hidden_tag`` no longer wraps the hidden inputs in a hidden div. This is valid HTML5 and any modern HTML parser will behave correctly. (`#217`_, `#193`_) - ``flask_wtf.html5`` is deprecated. Import directly from ``wtforms.fields.html5``. (`#251`_) - ``is_submitted`` is true for ``PATCH`` and ``DELETE`` in addition to ``POST`` and ``PUT``. (`#187`_) - ``generate_csrf`` takes a ``token_key`` parameter to specify the key stored in the session. (`#206`_) - ``generate_csrf`` takes a ``url_safe`` parameter to allow the token to be used in URLs. (`#206`_) - ``form.data`` can be accessed multiple times without raising an exception. (`#248`_) - File extension with multiple parts (``.tar.gz``) can be used in the ``FileAllowed`` validator. (`#201`_) .. _`#187`: pallets-eco/flask-wtf#187 .. _`#193`: pallets-eco/flask-wtf#193 .. _`#201`: pallets-eco/flask-wtf#201 .. _`#206`: pallets-eco/flask-wtf#206 .. _`#217`: pallets-eco/flask-wtf#217 .. _`#248`: pallets-eco/flask-wtf#248 .. _`#250`: pallets-eco/flask-wtf#250 .. _`#251`: pallets-eco/flask-wtf#251
Attempting an upgrade after installing the 2014Q4 bootstrap (was previously on 2014Q3), on OSX 10.10, I get a number of missing dylib warnings similar to this one, referencing what seems to be a hardcoded path from the build machine:
/Users/pbulk/build-2014Q4/geography/qlandkartegt-garmindev/work/garmindev-0.3.4/qlandkartegt/libwhatGarmin.dylib, needed by python26-2.6.9nb4 is not present in this system.
The text was updated successfully, but these errors were encountered: