January 2016 - macports-tickets - lists.macosforge.org

[MacPorts] #49122: tmux-pasteboard is outdated
by MacPorts 27 Jan '16

27 Jan '16

#49122: tmux-pasteboard is outdated -------------------------+-------------------------------- Reporter: hotpxless@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: tmux-pasteboard -------------------------+-------------------------------- It has updated to 2.4 on Github. Otherwise it outputs some warning message on El Capitan -- Ticket URL: <https://trac.macports.org/ticket/49122> MacPorts <https://www.macports.org/> Ports system for OS X

1 12

[MacPorts] #49181: tmux-pasteboard cannot be installed with tmux-devel
by MacPorts 27 Jan '16

27 Jan '16

#49181: tmux-pasteboard cannot be installed with tmux-devel -------------------------+-------------------------------- Reporter: hotpxless@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: tmux-pasteboard -------------------------+-------------------------------- I think it works with both versions, so can you modify the portfile so that it could use either one? Otherwise installing tmux-pasteboard will try to install tmux, which in turn conflicts with tmux-devel -- Ticket URL: <https://trac.macports.org/ticket/49181> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #49858: fakeroot @1.19-2_0 build failure
by MacPorts 27 Jan '16

27 Jan '16

#49858: fakeroot @1.19-2_0 build failure --------------------------+-------------------------------- Reporter: liam.sharp@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: fakeroot --------------------------+-------------------------------- I'm using OS X 10.10.5 with XCode 7.1.1 (7B1005) and I'm unable to install fakeroot. sudo port clean fakeroot Password: ---> Cleaning fakeroot sudo port install fakeroot ---> Computing dependencies for fakeroot ---> Fetching archive for fakeroot ---> Attempting to fetch fakeroot-1.19-2_0+universal.darwin_14.i386-x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/fakeroot ---> Attempting to fetch fakeroot-1.19-2_0+universal.darwin_14.i386-x86_64.tbz2 from http://lil.fr.packages.macports.org/fakeroot ---> Attempting to fetch fakeroot-1.19-2_0+universal.darwin_14.i386-x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/fakeroot ---> Fetching distfiles for fakeroot ---> Verifying checksums for fakeroot ---> Extracting fakeroot ---> Configuring fakeroot Error: org.macports.build for port fakeroot returned: command execution failed Please see the log file for port fakeroot for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_fakeroot/fakeroot/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port fakeroot failed Compilation error from log file is: ./wraptmpf.h:571:12: error: conflicting types for 'openat' I'll attach the log file. -- Ticket URL: <https://trac.macports.org/ticket/49858> MacPorts <https://www.macports.org/> Ports system for OS X

1 15

[MacPorts] #50437: nghttp2 @1.6.0_0: update to 1.7.0
by MacPorts 27 Jan '16

27 Jan '16

#50437: nghttp2 @1.6.0_0: update to 1.7.0 ---------------------------------+-------------------------------- Reporter: mschamschula@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: haspatch maintainer | Port: nghttp2 ---------------------------------+-------------------------------- nghttp2 has been updated to version 1.7.0. New this version: * Reset (RST_STREAM) stream if flow control window gets overflow * Validate :authroity, host, and :scheme value more strictly * Check request/response submission error based side of session * Strict outgoing idle stream detection * Return error from nghttp2_submit_{headers,request} when self dependency is made * Add -ldl to APPLDFLAGS for static openssl linking * asio: Stop acceptor on server::http2::stop * asio: Rename http2::get_io_services() as http2::io_services() * h2load: Support UNIX domain socket * h2load: Improve readability of traffic numbers * h2load: Remove "auto" for -m option * h2load: Show progress in rate mode * h2load: Perform sampling for request and connection timings to reduce memory consumption * nghttpd: Add --no-content-length option to omit content-length in response * nghttpx: Interleave pushed streams with the associated stream if pushed streams are javascript and CSS resources * nghttpx: The initial value of request/response buffer is increased to 128K * nghttpx: Fix bug that --listener-disable-timeout option is not used * nghttpx: Don't emit :authority if request does not contain authority information * nghttpx: Add clarification of quotes in configuration file * nghttpx: Don't allow certain characters in host and :scheme header field * nghttpx: Add RFC 7239 Forwarded header field support * nghttpx: Fix crash when running on IPv6 only * nghttpx: Take into account of trailers when applying max_header_fields * nghttpx: Don't apply max_header_fields and header_field_buffer limit to response * nghttpx: Strict validation for header fields given in configuration * nghttpx: header value should not be lower-cased -- Ticket URL: <https://trac.macports.org/ticket/50437> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

Re: [MacPorts] #42693: [NEW] py-pyinstaller
by MacPorts 26 Jan '16

26 Jan '16

#42693: [NEW] py-pyinstaller -----------------------------+-------------------------------- Reporter: jul_bsd@… | Owner: macports-tickets@… Type: submission | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Resolution: fixed | Keywords: Port: py-pyinstaller | -----------------------------+-------------------------------- Changes (by adfernandes@…): * status: new => closed * resolution: => fixed Comment: r145141 -- Ticket URL: <https://trac.macports.org/ticket/42693#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #50449: vcdimager @0.7.24_4 fails build on Mac PPC/G4 Tiger/10.4.11
by MacPorts 26 Jan '16

26 Jan '16

#50449: vcdimager @0.7.24_4 fails build on Mac PPC/G4 Tiger/10.4.11 ------------------------+-------------------------------- Reporter: zffjcgni@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: rpath | Port: vcdimager ------------------------+-------------------------------- See attached log. {{{ ---> Building vcdimager Error: org.macports.build for port vcdimager returned: command execution failed Please see the log file for port vcdimager for details: ... :info:build ld: -rpath can only be used when targeting Mac OS X 10.5 or later }}} -- Ticket URL: <https://trac.macports.org/ticket/50449> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

Re: [MacPorts] #28756: gthumb 2.12.2 image edit tools greyed out
by MacPorts 26 Jan '16

26 Jan '16

#28756: gthumb 2.12.2 image edit tools greyed out ----------------------+-------------------------------- Reporter: sandy@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Resolution: | Keywords: Port: gthumb | ----------------------+-------------------------------- Comment (by jmr@…): Is this still a problem with 3.4.1? -- Ticket URL: <https://trac.macports.org/ticket/28756#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #28684: Clojure won't compile my programs
by MacPorts 26 Jan '16

26 Jan '16

#28684: Clojure won't compile my programs ----------------------------------+-------------------------------- Reporter: andrew.pennebaker@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Resolution: | Keywords: Port: clojure | ----------------------------------+-------------------------------- Comment (by jmr@…): Is this still a problem with 1.7.0? -- Ticket URL: <https://trac.macports.org/ticket/28684#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #28611: mspgcc4 port submission
by MacPorts 26 Jan '16

26 Jan '16

#28611: mspgcc4 port submission -------------------------+-------------------------------- Reporter: nf6x@… | Owner: macports-tickets@… Type: submission | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Resolution: wontfix | Keywords: lack-of-interest Port: mspgcc4 | -------------------------+-------------------------------- Changes (by jmr@…): * keywords: mspgcc4 MSP430 => lack-of-interest * status: new => closed * resolution: => wontfix Comment: Closing due to lack of activity. Please feel free to reopen if you are interested in working on this. -- Ticket URL: <https://trac.macports.org/ticket/28611#comment:12> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #50448: Change filenames of binary packages built against libc++ on < 10.9
by MacPorts 26 Jan '16

26 Jan '16

#50448: Change filenames of binary packages built against libc++ on < 10.9 -------------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.4 Keywords: | Port: -------------------------+-------------------------------- This ticket is meant for discussion about the implementation of unique filenames for packages built against `libc++` on OS X versions prior to 10.9, so that we could eventually set up a buildslave and distribute binaries for that configuration as described in [[LibcxxOnOlderSystems]]. There are three (four) categories of packages: * `noarch` * C++ programs and libraries (that link against libc++ or libstdc++) * packages that require C++11 and thus link against libc++ even where default is libstdc++ (like `clang-3.X`, `root6`, ... ) * packages that don't require stdlib My suggestion: * no changes are needed for `noarch` (but when setting up a new buildslave we should make sure to only upload packages from one of them) * packages that link against stdlib * I would suggest to make no changes on >= 10.9 * we should add something like `libc++` to the name (or potentially something shorter) * while we could add `stdlibc++` to the name of default configuration, I don't see any reason to do so as it would only require extra work (unless we start differentiating between package with/without the need for stdlib) * package that don't link against stdlib * we could do a similar analysis as for `noarch` and differentiate between packages that link against stdlib and those that don't with a special flag; but we need to remember that there might be further differences between the packages built on the old buildslaves and those built on the new one, for example due to `delete_la_files` setting; my suggestion would be not to worry about differentiating packages that link against stdlib and those that don't, but that's certainly debatable * If it's easy enough to implement, we could do it for reasons of "purism". The question is then: should packages contain a similar keyword as `noarch`? Who would add those flags? If we do something about that, OS X versions >= 10.9 should be affected as well and we should change the names (and either rebuild or rename the packages) there as well. * packages that link against `libc++` * if we want a quck & dirty solution: don't bother about those special cases (the package would only have `libc++` in the name if it was built on the new buildslave and we would still ship two version) * if we want to optimize space and only upload the package once, we would have to do some major cleanup on the existing buildbots (due to `delete_la_files` etc) and most likely ship the files from the new buildbot Basically we have two ways: * do it right (quite a bit of effort) * do it in a quick and dirty way (but make it work faster) While discussing this it might be worth thinking about potential (simultaneous) switch to `*.tar.xz` for archives which could save quite some space both for end users as well as on the buildbots / servers with packages. -- Ticket URL: <https://trac.macports.org/ticket/50448> MacPorts <https://www.macports.org/> Ports system for OS X

1 0