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

[MacPorts] #50080: clang-3.8+universal fails to build
by MacPorts 12 Jan '16

12 Jan '16

#50080: clang-3.8+universal fails to build --------------------------+-------------------------------- Reporter: nneonneo@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: buildfailure | Port: clang-3.8 --------------------------+-------------------------------- While trying to upgrade clang-3.8 today, I received a build failure. I have the +universal variant selected. The problem appears to be due to ThreadSanitizer being enabled on the 32-bit build: {{{ :info:build In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_sea.us.rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/clang-3.8/work/trunk/projects /compiler-rt/lib/tsan/rtl/tsan_flags.cc:18: :info:build In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_sea.us.rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/clang-3.8/work/trunk/projects /compiler-rt/lib/tsan/rtl/tsan_rtl.h:44: :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_sea.us.rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/clang-3.8/work/trunk/projects /compiler-rt/lib/tsan/rtl/tsan_platform.h:19:3: error: "Only 64-bit is supported" }}} The complete build log is attached. -- Ticket URL: <https://trac.macports.org/ticket/50080> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #50291: Portfile submission: p5-crypt-generatepassword @0.05
by MacPorts 12 Jan '16

12 Jan '16

#50291: Portfile submission: p5-crypt-generatepassword @0.05 ------------------------+--------------------------------------- Reporter: karl@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: p5-crypt-generatepassword ------------------------+--------------------------------------- Hello! I have a ticket that I'd like to submit, for the Perl module Crypt::GeneratePassword. The Portfile is being attached once the ticket is created. I've set up the Portfile to cover all versions of Perl starting at 5.16 (since the dependency, Data::Dumper, isn't available until 5.16). I'm contributing this Portfile because this Perl module is being used by another piece of software that I'm writing a Portfile for. I tested the Portfile by running these commands, after I created the Portfile and ran `portindex`: sudo port test p5.16-crypt-generatepassword sudo port test p5.18-crypt-generatepassword sudo port test p5.20-crypt-generatepassword sudo port test p5.22-crypt-generatepassword Please let me know if I'm missing anything, or if there's anything I need to change! -- Ticket URL: <https://trac.macports.org/ticket/50291> MacPorts <https://www.macports.org/> Ports system for OS X

1 4

[MacPorts] #48690: Upgrading "guile18" fails
by MacPorts 11 Jan '16

11 Jan '16

#48690: Upgrading "guile18" fails --------------------+-------------------------------- Reporter: dave@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: guile18 --------------------+-------------------------------- Uograding MacPorts failed when building "guile18": ---> Staging guile18 into destroot Error: org.macports.destroot for port guile18 returned: command execution failed Please see the log file for port guile18 for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_guile18/guile18/main.log Error: Unable to upgrade port: 1 Error rebuilding guile18 while executing "error "Error rebuilding $portname"" (procedure "revupgrade_scanandrebuild" line 395) invoked from within "revupgrade_scanandrebuild broken_port_counts $opts" (procedure "macports::revupgrade" line 5) invoked from within "macports::revupgrade $opts" (procedure "action_revupgrade" line 2) invoked from within "action_revupgrade $action $portlist $opts" (procedure "action_upgrade" line 25) invoked from within "$action_proc $action $portlist [array get global_options]" (procedure "process_cmd" line 103) invoked from within "process_cmd $remaining_args" invoked from within "if { [llength $remaining_args] > 0 } { # If there are remaining arguments, process those as a command set exit_status [process_cmd $remaining..." (file "/opt/local/bin/port" line 5268) ozzie:~ dave$ -- Ticket URL: <https://trac.macports.org/ticket/48690> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #50190: MacPorts infrastructure inaccessible from Internet2
by MacPorts 11 Jan '16

11 Jan '16

#50190: MacPorts infrastructure inaccessible from Internet2 ----------------------------+--------------------- Reporter: bgilbert@… | Owner: admin@… Type: defect | Status: new Priority: Normal | Milestone: Component: server/hosting | Version: Keywords: | Port: ----------------------------+--------------------- *.macports.org hosts have been inaccessible from the cmu.edu network (via Internet2) since around December 12th. Affected hosts include packages.macports.org, rsync, svn, trac, and www. The sea.us.rsync.macports.org mirror is still accessible, which of course doesn't help with non-mirrored services such as svn. # traceroute -I svn.macports.org -m 60 traceroute to svn.macports.org (17.251.224.213), 60 hops max, 60 byte packets [...] 5 POD-I-DCNS-CORE0.GW.CMU.NET (128.2.0.194) 0.589 ms 0.528 ms 0.508 ms 6 transitrail.cmu.3rox.net (147.73.16.111) 2411.780 ms 2411.568 ms 2411.424 ms 7 et-7-0-0.513.rtr.eqch.net.internet2.edu (198.71.47.183) 13.728 ms 13.710 ms 13.608 ms 8 ae-2.0.rtr.ashb.net.internet2.edu (64.57.20.218) 18.285 ms 18.246 ms 18.201 ms 9 17.1.144.1 (17.1.144.1) 18.306 ms 18.362 ms 18.222 ms 10 17.0.148.76 (17.0.148.76) 81.052 ms 81.673 ms 81.368 ms 11 17.0.148.91 (17.0.148.91) 78.764 ms 78.762 ms 78.744 ms 12 17.0.136.75 (17.0.136.75) 78.692 ms 78.756 ms 78.662 ms 13 * * * 14 * * * 15 * * * [...] I'm happy to help with troubleshooting on this end. -- Ticket URL: <https://trac.macports.org/ticket/50190> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #46717: xfwm4: improved stacking in rooted mode
by MacPorts 11 Jan '16

11 Jan '16

#46717: xfwm4: improved stacking in rooted mode -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: xfwm4 -------------------------+-------------------------------- Most window managers are not prepared, when running under XQuartz or similar in rooted mode, to restack X11 windows outside of the stacking location the X server is itself in. As a result, clicking on a background X11 window will make the X server active and raise the X window w.r.t. other X windows, but it will not raise the window from behind "native" (Cocoa/Aqua) windows. I'm attaching a patch that (re)enables this for "global" restacking operations (i.e. when xfwm4 does not try to restack a window w.r.t. some sibling window). Bonus screenshot: xfwm4 with the Mint-X theme, epiphany using the GTk3 theme from port:oxygen-gtk3 and the +infinality variants of port:freetype, port:fontconfig and port:cairo. -- Ticket URL: <https://trac.macports.org/ticket/46717> MacPorts <https://www.macports.org/> Ports system for OS X

1 8

[MacPorts] #50271: CMake Portgroup: activate CMAKE_EXPORT_COMPILE_COMMANDS
by MacPorts 11 Jan '16

11 Jan '16

#50271: CMake Portgroup: activate CMAKE_EXPORT_COMPILE_COMMANDS -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: cmake -------------------------+-------------------------------- This is an enhancement suggestion complementary to the one filed under ticked #50246 . CMake has the option to generate an additional file in the build directory, that contains the compile commands.This file is of little interest for building a port (it is comparable to the .CC_OPTIONS file) but its creation comes at negligible cost. It is however of considerable interest when the build directory is used with certain IDEs : KDevelop5 uses it to obtain the project contents. When absent, it will invoke a default cmake command with just enough arguments to interfere with the proper settings determined by the port. My suggestion is thus to add `-DCMAKE_EXPORT_COMPILE_COMMANDS=on` to the list of cmake arguments, and to add a `touch ${build.dir}/compile_commands.json` to the post-configure block that also creates the cmake invocation file. -- Ticket URL: <https://trac.macports.org/ticket/50271> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #50280: arm-none-eabi-gcc @5.1.0_1 does not build on OS X Lion using clang
by MacPorts 11 Jan '16

11 Jan '16

#50280: arm-none-eabi-gcc @5.1.0_1 does not build on OS X Lion using clang ----------------------+-------------------------------- Reporter: daniel@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: arm-none-eabi-gcc ----------------------+-------------------------------- On OS X Lion (10.7.5, Darwin 11.4.2), the default compiler (Clang as `Apple LLVM version 4.2 (clang-425.0.28)`) bails out with an error during build: {{{ :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_tarballs_ports_cross_arm-none-eabi-gcc/arm-none-eabi- gcc/work/gcc-5.1.0/gcc/config/arm/neon.md:3463:10917: fatal error: parser recursion limit reached, program too complex }}} Solution is to blacklist all clang versions in the Portfile by being more inclusive: {{{ compiler.blacklist {clang < 500} }}} This forces the compiler chosen to be `Xcode LLVM-GCC 4.2`, which results in a succesful build, although it complains during staging: {{{ ---> Building arm-none-eabi-gcc ---> Staging arm-none-eabi-gcc into destroot Warning: arm-none-eabi-gcc installs files outside the common directory structure. ---> Installing arm-none-eabi-gcc @5.1.0_1 ---> Cleaning arm-none-eabi-gcc ---> Computing dependencies for arm-none-eabi-gcc ---> Deactivating arm-none-eabi-gcc @4.7.2_0 ---> Cleaning arm-none-eabi-gcc ---> Activating arm-none-eabi-gcc @5.1.0_1 ---> Cleaning arm-none-eabi-gcc }}} -- Ticket URL: <https://trac.macports.org/ticket/50280> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #49787: Mailing list messages not delivered, subscriptions disabled due to Yahoo Mail now requiring DMARC
by MacPorts 11 Jan '16

11 Jan '16

#49787: Mailing list messages not delivered, subscriptions disabled due to Yahoo Mail now requiring DMARC ----------------------------+--------------------- Reporter: ryandesign@… | Owner: admin@… Type: defect | Status: new Priority: High | Milestone: Component: server/hosting | Version: Keywords: | Port: ----------------------------+--------------------- At 2:29 PM Central time today we received 42 mailing list subscription disabled bounces. They said things like: {{{ 552 l8Eq1r00M0drVCp018ErwH Message fails DMARC verification. }}} {{{ 554 5.7.9 Message not accepted for policy reasons. See https://help.yahoo.com/kb/postmaster/SLN7253.html }}} {{{ 550 5.7.1 The messages violates the DMARC policy of yahoo.com (d8c59a45 -921e-11e5-a822-db253d9e0b64) }}} {{{ 550 5.2.0 l8Eq1r05C0bG8YH018Er6K Message rejected due to DMARC. Please see http://postmaster.comcast.net/smtp-error-codes.php#DM000001 }}} {{{ 550 5.7.0 (COL004-MC6F14) Unfortunately, messages from (17.151.62.25) on behalf of (yahoo.com) could not be delivered due to domain owner policy restrictions. }}} It sounds like Yahoo's mail server now requires messages to be sent in compliance with [https://dmarc.org/ DMARC], and our mailing lists do not do this. The effect is that when a Yahoo Mail user who has subscribed to one of our lists sends a message to the list, it gets sent by our list to the other subscribers. For those subscribers using a mail service that checks DMARC, their mail servers reject the message because the DMARC verification fails because the message was actually sent by our server not by a Yahoo Mail server. This causes the subscriber's mail server to send a bounce back to our mailing list server, and after a few of those, our mailing list server disables the subscriber's subscription. [https://help.yahoo.com/kb/postmaster/SLN7253.html Yahoo's own page on this problem] suggests we "Follow industry standards" and: > change your sending behavior by adding the mailing lists’ address to the "From:" line, rather than the sender’s address. Also, enter the actual user/sender address into the "Reply-To:" line." I do not believe we should do this, because this contradicts RFC2822 which states: > When the "Reply-To:" field is present, it indicates the mailbox(es) to which the author of the message suggests that replies be sent. Our mailing list is not the author of the message, so our mailing list may not change the Reply-To line. See also [https://woozle.org/~neale/papers /reply-to-still-harmful.html “Reply-To” Munging Still Considered Harmful. Really.] The [https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoper… DMARC FAQ] has an entry about what list operators should do, but there are several choices and I don't know which, if any, are appropriate. -- Ticket URL: <https://trac.macports.org/ticket/49787> MacPorts <https://www.macports.org/> Ports system for OS X

1 6

Re: [MacPorts] #18849: inkscape : build an application
by MacPorts 11 Jan '16

11 Jan '16

#18849: inkscape : build an application --------------------------+---------------------- Reporter: neric27@… | Owner: devans@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: quartz Port: inkscape | --------------------------+---------------------- Changes (by jmr@…): * priority: High => Normal * type: defect => enhancement * component: server/hosting => ports -- Ticket URL: <https://trac.macports.org/ticket/18849#comment:13> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #47403: New port: pgcli
by MacPorts 11 Jan '16

11 Jan '16

#47403: New port: pgcli ---------------------------+-------------------------------- Reporter: xeron.oskom@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: pgcli ---------------------------+-------------------------------- Portfile attached. Depends on: #47399 #47400 #47401 #47402. -- Ticket URL: <https://trac.macports.org/ticket/47403> MacPorts <https://www.macports.org/> Ports system for OS X

1 10