Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

On 24.08.2016 09:36 PM, Lawrence Velázquez wrote: > But those Perl ports are always leaves (w.r.t. `cpuid`) because they are > build dependencies. There's no need to revbump if you're just updating build > dependencies. Aren't build dependencies included in the DB? I typically run

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

On 24.08.2016 09:02 PM, René J.V. Bertin wrote: > On Wednesday August 24 2016 20:43:08 Mihai Moldovan wrote: > >> It will need a revbump once that's done, but otherwise yes. > > That shouldn't actually be necessary; "base" ought to track which PortGroup &

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

On 24.08.2016 08:28 PM, MacPorts wrote: > #52081: Ports should require perl5.24 instead of 5.22 > Comment (by rjvbertin@…): > > Not that I can commit it anyway, but I had a look at my `port:cpuid`. > Turns out it depends on `port:p${perl5.major}-foo` ; am I right that this > means it'll

Re: [150874] trunk/dports/lang/python32

On 01.08.2016 08:39 PM, Lawrence Velázquez wrote: > Not to pick on you, Mihai, but have we ever considered getting rid of (or at > least revising) the guideline that implies that these new, sprawling, > indecipherable patch names are somehow more "correct" than the old ones? I > have never

Re: llvm / clang / cctools / ld64 version consistency question

On 28.07.2016 04:26 AM, Mihai Moldovan wrote: > On 27.07.2016 03:22 PM, Ken Cunningham wrote: >> Also, cctools and ld64 also have a specific variant for each version of >> llvm, it >> appears from the following command. > > The MacPorts-provided compilers (gcc-mp-*, c

Re: llvm / clang / cctools / ld64 version consistency question

On 27.07.2016 03:22 PM, Ken Cunningham wrote: > Having run into an unexpected problem with clang-3.7 segfaulting not long ago > after a 3.7 minor version update, and then an interesting libLTO incorrect > "version error" when I tried to upgrade the compiler chain from clang-3.7 to > clang-3.8, I'd

Re: [148665] trunk/dports/net/aria2/Portfile

[resent now that I can finally send mails to the list again] On 16.05.2016 08:57 AM, Ryan Schmidt wrote: >> Thus, "use_autoreconf yes" essentially had no effect. > > "use_autoreconf yes" will still have the effect that it will cause MacPorts > to run autoreconf prior to running ./configure.

Re: [149178] trunk/dports/audio/pulseaudio/Portfile

[resent now that I can finally send mails to the list again] On 05.06.2016 08:14 AM, Ryan Schmidt wrote: > Don't change it now, but why the revbump? Forcing the users to rebuild the > port will not change anything. > > Had you added a new default variant, that would warrant a revbump, because

Test only, please disregard EOM

signature.asc Description: OpenPGP digital signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [146024] trunk/dports/sysutils

On 26.02.2016 08:37 PM, Ryan Schmidt wrote: > That uses /opt/local/bin/perl, which might not be perl5.22, depending on > which variant of the perl5 port the user has installed. If you declare a > dependency on a p5.22 module, you must use the perl5.22 executable. Thanks, I think I got confused

Re: [146024] trunk/dports/sysutils

On 26.02.2016 09:38 AM, Ryan Schmidt wrote: >> +depends_run port:p5.22-soap-lite > > I see you've added a dependency on port:p5.22-soap-lite but I don't see how > you've informed the program that it should use /opt/local/bin/perl5.22, which > would be necessary for this to work. Via

Re: GSoC port-util project

On 16.02.2016 01:34 AM, Michael Dickens wrote: > +1: I like this idea, or at least what I think you're getting at. I'd > love to have a MP-sanctioned port related utility app for doing common > tasks -for developers-. > > An example would be a "check and try update" task that would: do a >

Re: Trac down?

On 11.02.2016 07:59 PM, Craig Treleaven wrote: > It seems that https://trac.macports.org is unreachable. SVN as such still works. I think I broke it with a few SVN prop updates on files, but not too sure about this. CCing Ryan. Mihai signature.asc Description: OpenPGP digital signature

Re: Trac down?

On 11.02.2016 08:38 PM, Ryan Schmidt wrote: > There was high memory usage for an unknown reason, which caused the OS to > start killing processes, including the web server, to free memory. I rebooted > the server and it's working again. Thanks for that, but Trac has also stopped updating after

Re: reduce emacs dependency

On 29.01.2016 11:52 PM, Mark Brethen wrote: > I was thinking something like > > depends_build-append [port:emacs || port:emacs-app || port:emacs-mac-app || > etc.] > > but this isn’t very elegant. Can you use regex with a depends statement? Base currently does not support alternatives, short

Subversion Component Down

Dear Developers and Users The subversion server seems to eventually also be affected by recent server problems and is currently effectively down. This is a continuation of the general problems we have experienced with the rsync server and, to some extent, trac. For the time being, please stash

Re: macports-dev Digest, Vol 109, Issue 41

On 30.09.2015 07:09 PM, Damian Rouson wrote: > Yes, please include the OpenCoarrays port if at all possible! We’ve > responded to every concern raised in the 4 months since we first submitted > the Portfile. In that time frame, we have released OpenCoarrays 1.0.0, > 1.0.1, and 1.0.2. We’re

Re: r140185: tarsnap: Update to 1.0.36.1

On 11.09.2015 09:49 PM, Benjamin Gilbert wrote: > On Fri, Sep 11, 2015 at 3:13 PM, Mihai Moldovan <io...@macports.org > <mailto:io...@macports.org>> wrote: > > [05:41:47] < irker342> bgilb...@macports.org > <mailto:bgilb...@macports.org> * >

Re: r140185: tarsnap: Update to 1.0.36.1

On 13.09.2015 12:41 AM, Brandon Allbery wrote: > I think you're still misunderstanding: it has support for both compiled in, > and > detects the cpu *when it is run* to see if it can use SSE2. The same > executable > will work regardless, it's just faster when SSE2 is available. > There are

Re: r140185: tarsnap: Update to 1.0.36.1

[05:41:47] < irker342> bgilb...@macports.org * https://trac.macports.org/changeset/140185 /trunk/dports/sysutils/tarsnap/Portfile: [05:41:48] < irker342> tarsnap: Update to 1.0.36.1 [05:41:48] < irker342> SSE2 is now autodetected. Careful, this could be a problem. Depending on what the compiler

Re: Fwd: [MacPorts] #48365: Ports should require perl5.22 instead of 5.16

On 07.09.2015 10:29 PM, Damien Bobillot wrote: > I’m not allowed to post on macports-dev lists. > Maybe you can answer, ionic. > [...] >> Début du message réexpédié : >> >> De: Damien Bobillot >> Objet: Rép : [MacPorts] #48365: Ports should require perl5.22 instead of

Re: mkpwd: update to 1.6

On 01.09.2015 01:32 AM, Michael Beasley wrote: > Attached are patches for sysutils/mkpwd v1.6. (current version 0.8) > [...] A couple of comments on that one: Due to the project now using autotools, a lot of stuff can be simplified. For instance, explicitly defining the universal variant is not

Re: [139676] branches/gsoc15-dependency/base/vendor/libsolv.tar.gz

On 26.08.2015 06:49 PM, Clemens Lang wrote: - On 25 Aug, 2015, at 16:20, Bradley Giesbrecht pixi...@macports.org wrote: Why not a patch file? It would be pretty large because we're adding an autoconf-based build system on top of upstream's sources. I don't think a patch file is the

Re: Connectivity problems with master server (distfiles.macports.org/rsync.macports.org)

Hi As previously announced, here is the archive link to my former message: https://lists.macosforge.org/pipermail/macports-users/2015-August/039111.html This will hopefully ease information spread. Mihai signature.asc Description: OpenPGP digital signature

Re: Connectivity problems with master server (distfiles.macports.org/rsync.macports.org)

On 25.08.2015 09:35 PM, Mihai Moldovan wrote: As previously announced, here is the archive link to my former message: https://lists.macosforge.org/pipermail/macports-users/2015-August/039111.html This will hopefully ease information spread. And as Jeremy pointed out, it is easy to imagine

Connectivity problems with master server (distfiles.macports.org/rsync.macports.org)

Hi For the last few days, I have increasingly seen reports of problems reaching the master server (distfiles.macports.org/rsync.macports.org) with symptoms ranging from low throughput (tens of KB/s with an otherwise idle connection on the user's end), stalling of downloads with eventual

Re: [139660] trunk/dports/_resources/port1.0/group/qt4-1.0.tcl

On 24.08.2015 05:07 PM, Michael Dickens wrote: This directory and -any- Qt directory should not make a difference if the port is using this PortGroup and the project honors the variables found in QMake (and here). I have no objection to the changes, except that they should not be needed. Now

Re: [139614] trunk/dports/graphics/libvisio-0.1/Portfile

Hi Dave I would appreciate you taking a look at that thing. Since boost was updated, libvisio-0.1 fails to build for me (you probably upgraded libvisio-0.1 on your system prior to the boost update, so got out free.) I don't know what causes the problem exactly, but libvisio-0.1 never intended

Re: [139614] trunk/dports/graphics/libvisio-0.1/Portfile

On 21.08.2015 07:32 PM, David Evans wrote: Will take a look. Thanks for the heads-up and your temporary fix. Without looking as yet, I wonder if this effects the other librevenge based ports as well. Maybe, but I don't know. No other librevenge-based port has been outdated on my system, so

Re: size of distfile mirror?

On 20.08.2015 03:49 AM, Arno Hautala wrote: Thanks, That is a lot of bits. Well, it's 258GB for distfiles (base 1024.) Compared to packages, that's still moderate, although you should expect the distfiles to always grow. Packages are somewhat special in that old versions are unregularly

Re: size of distfile mirror?

On 20.08.2015 03:31 AM, Arno Hautala wrote: Thanks, I've sent a question to a couple of them and I'll post back any responses I get. I'm not quite sure how I missed seeing the admin email address column. Current utilization on my mirror for the different submodules: 258Gdistfiles 469G

Re: size of distfile mirror?

On 20.08.2015 07:33 AM, Sterling Smith wrote: Monotonically growing as well… :-) On Aug 19, 2015, at 7:10PM, Mihai Moldovan io...@macports.org wrote: Distfiles are monotonously growing. Haha, indeed. Luckily both words kind of fit. ;) Mihai signature.asc Description: OpenPGP

Re: size of distfile mirror?

On 20.08.2015 07:33 AM, Sterling Smith wrote: Monotonically growing as well… :-) On Aug 19, 2015, at 7:10PM, Mihai Moldovan io...@macports.org wrote: Distfiles are monotonously growing. Haha, indeed. Luckily both words kind of fit. ;) Mihai signature.asc Description: OpenPGP digital

OT [was: Re: size of distfile mirror?]

Wait, wrong failed recipient. Your GAT mail server is still blocking any mails from my server. :( Mihai signature.asc Description: OpenPGP digital signature ___ macports-dev mailing list macports-dev@lists.macosforge.org

Re: yosemite buildbot

On 18.08.2015 05:45 PM, Jonathan Stickel wrote: I've got a few updates today, and none of them seem to have binary packages available (e.g., llvm-3.5-3.5.2_5.darwin_14.x86_64.tbz2). Is the buildbot having issues? IIRC all buildslaves have stalled. C.f. https://trac.macports.org/ticket/48596

libressl maintainer

Hi Jeremy If you do not plan to maintain libressl, please set it to nomaintainer, otherwise add yourself to the maintainer list and openmaintainer. Openmaintainer should never be the only maintainer - that's what nomaintainer is for. Mihai signature.asc Description: OpenPGP digital

Re: SVN authorization

On 06.08.2015 02:53 AM, Craig Treleaven wrote: I vaguely recall running an svn command to add MacPorts as a trusted server (or some-such) but I don’t recall the details. Could someone point me in the right direction? Refer to https://trac.macports.org/wiki/howto/SyncingWithSVN and

Spam in Trac

https://trac.macports.org/ticket/48474 https://trac.macports.org/ticket/48475 https://trac.macports.org/ticket/48476 https://trac.macports.org/ticket/48477 https://trac.macports.org/ticket/48478 https://trac.macports.org/ticket/48479 https://trac.macports.org/ticket/48480 From:

Re: Commit jmol update

On 28.07.2015 05:45 PM, Peter Brommer wrote: could somebody with commit privileges take a peek at https://trac.macports.org/ticket/48414 - and, if it finds approval, commit the maintainer-provided patch? r139017 Mihai signature.asc Description: OpenPGP digital signature

Re: Looking for some testers for Pallet

On 20.07.2015 10:44 PM, Jake Petroules wrote: 1. Why are you using Garbage Collection? The GC runtime will be outright removed from OS X in 10.12. You absolutely cannot use this - convert it to ARC. I think he likely knows. It's a non-trivial task though and he probably holds it off to some

Re: How to deal with tickets on trac with lots of subscribers and lots of trivial additions?

On 15.07.2015 04:13 PM, Mojca Miklavec wrote: Is there any sane way to allow silent changes in tickets where zillions of ports need to be changes (and lots of maintainers have to be subscribed)? No, hence: a comment that is periodically updated (which is quiet when being edited.) Developers

Re: How to deal with tickets on trac with lots of subscribers and lots of trivial additions?

On 15.07.2015 05:40 PM, Mojca Miklavec wrote: I'm still optimistic that someone will point out some useful trac plugin to fix the issue. Trac plugins need to be installed by the MacOS Forge Admins... I'm still waiting for https://trac.macports.org/ticket/40987 to land... After some more

Re: [MacPorts] #48365: Ports should require perl5.22 instead of 5.16

On 15.07.2015 03:24 PM, MacPorts wrote: #48365: Ports should require perl5.22 instead of 5.16 pulseaudio: done r138665 Mihai signature.asc Description: OpenPGP digital signature ___ macports-dev mailing list macports-dev@lists.macosforge.org

Re: [MacPorts] #48365: Ports should require perl5.22 instead of 5.16

On 15.07.2015 04:41 PM, René J.V. Bertin wrote: I think port:cpuid should be fine already, given how it depends on the 2 perl ports it requires for building: {{{ depends_build port:p${perl5.major}-pathtools \ port:p${perl5.major}-scalar-list-utils }}} It will need

Re: [138658] trunk/dports/science/ifeffit/Portfile

On 15.07.2015 02:08 AM, Ryan Schmidt wrote: How do you know? Is that based only on the tag name 1.2.final? I didn't see anything on the github page or in the ChangeLog file about this being the end. Maybe this? http://cars9.uchicago.edu/ifeffit/Downloads Mihai signature.asc Description:

Re: [138221] trunk/dports/multimedia/mpv

On 05.07.2015 10:32 AM, Ryan Schmidt wrote: On Jul 2, 2015, at 11:14 AM, io...@macports.org wrote: +# Remove after 06-28-2016. +variant mp3 description {Legacy compatibility variant for MP3 support via mpg123. Will be removed soon.} { +notes-append + You have enabled

Re: [138297] trunk/dports/math/octave-control/Portfile

On 05.07.2015 09:01 AM, Ryan Schmidt wrote: octave doesn't contain any static libraries, so we're talking about a dynamic library... wouldn't octave-control then simply use the newer octave dynamic library when octave is updated? Please make that up with Marius. I do not use octave, but

Re: [138297] trunk/dports/math/octave-control/Portfile

On 05.07.2015 05:48 AM, Ryan Schmidt wrote: Could you be more specific about why a revbump of octave-control was needed? I understand a revbump of octave was needed following the updates to the gcc48 and gcc49 ports, but how does that translate into requiring octave-control to be revbumped?

Re: [138098] trunk/dports/science/magicspp/Portfile

On 29.06.2015 03:26 PM, Takeshi Enomoto wrote: I wonder if anyone could help me with this. I can build this port fine on my machines but I get errors on the buildbot. The buildbot fails to find the glib2 include path and the configuration fails. Please try building the port on your machine

Re: [138119] users/elelay/ports/devel/gtk-osx-application/Portfile

On 29.06.2015 10:14 PM, David Evans wrote: One small additional suggestion. The error message that is emitted when one of the subports is attempted without +quartz still refers to gtk-osx-application rather than the subport name. Changing ${name} to ${name}-${gtk_version} in that message

Notes in gpodder

Hi Eric Please do not append or prepend stars or anything else to attract attention to notes. Notes of a specific port are not more or less important than of any other port. Mihai signature.asc Description: OpenPGP digital signature ___

Re: Notes in gpodder

Btw, your host just rejected my message due to being on a FusionRBL blacklist... signature.asc Description: OpenPGP digital signature ___ macports-dev mailing list macports-dev@lists.macosforge.org

Re: Notes in gpodder

On 27.06.2015 12:04 AM, Lawrence Velázquez wrote: I believe the instructions for activating startupitems are also printed inline. That's because they are using ui_msg... because there's no easy way of using the notes feature within base. We'd have to reimplement it using callbacks or

Re: Notes in gpodder

On 27.06.2015 12:59 AM, Lawrence Velázquez wrote: That's because they are using ui_msg... because there's no easy way of using the notes feature within base. And why not? [inappropriate response here] I don't know exactly. I've been asking you and Clemens the same question and you said

Re: Notes in gpodder

On 26.06.2015 11:44 PM, Sterling Smith wrote: While I don’t think that the notes of any port are more important than any other port, there is a problem seeing the notes as they fly by in the barrage of output as a given port with all of its dependencies is installed. There was a thread in

Re: Notes in gpodder

On 27.06.2015 12:04 AM, Clemens Lang wrote: On June 26, 2015 11:46:51 PM GMT+02:00, Mihai Moldovan io...@macports.org wrote: On 26.06.2015 11:44 PM, Sterling Smith wrote: Presumably the port dependencies that need to be installed are stored and it would be nice if at the end of a `port

Re: Diskspace exceeded on packages.macports.org?

[Resent because I forgot to change the envelope address again...] On 25.06.2015 09:04 PM, Ryan Schmidt wrote: MacPorts people: Do we clean up old archives? If not, we probably should. If we do, we probably should clean out more to avoid this? We don't delete old packages or distfiles. We

Re: Diskspace exceeded on packages.macports.org?

On 26.06.2015 03:17 AM, Ryan Schmidt wrote: I've filed a ticket for the problem now, and mentioned the script. https://trac.macports.org/ticket/48174 Doesn't portmgr have access to packages.macports.org? Can't you login and run it manually (or probably better wait for Josh to do it, because

Re: [137639] trunk/dports/security/gpg-agent/Portfile

On 15.06.2015 08:57 PM, Lawrence Velázquez wrote: Missing patch? Please also add it to gnupg2. I cannot find any patch named like this in the whole tree, or else would have copied it from another location. Mihai signature.asc Description: OpenPGP digital signature

Re: [137005] trunk/dports/aqua/qt4-mac

On 02.06.2015 04:38 PM, Ryan Schmidt wrote: On Jun 2, 2015, at 8:48 AM, michae...@macports.org wrote: [...] + allow for jpeg or jpeg-turbo; Can't do that right now; they don't have the same library version. You should put it back to port:jpeg. It's okay. Installing jpeg-turbo is not

Re: port activate instead

On 25.05.2015 05:50 PM, René J.V. Bertin wrote: % sudo port activate --instead_of -f libVLC-devel libVLC@2.2.1_0+dbus+qtkit+quartz+x11 (or --replace or --swap or some other more appropriate term) instead of % sudo port deactivate -f

Re: port activate instead

On 25.05.2015 07:20 PM, René J.V. Bertin wrote: On Monday May 25 2015 18:30:48 Mihai Moldovan wrote: Semantically, your instead_of proposal isn't great due to the fact that multiple ports can conflict, with count 2. Also, the conflicts can be based upon orthogonal reasons and you wouldn't

Re: libssh01 Removal

On 24.05.2015 09:16 AM, Ryan Schmidt wrote: On May 23, 2015, at 8:54 PM, Mihai Moldovan wrote: Without replacing it with libssh first or revbumping and erroring out in pre-configure? Okay. I don't see a benefit to that in this case, do you? Revbumping and erroring out would have had

Re: buildports-snowleopard-x86_64 buildbot is broken

On 23.05.2015 11:56 PM, David Evans wrote: Apparently a corrupted database issue. Output from the write portlist phase shows Also see thread Snow Leopard builder failing on SQLite database corruption Mihai signature.asc Description: OpenPGP digital signature

libssh01 Removal

Hi Ryan, I see we currently have 3 variants of libssh: libssh (the one from libssh.org), libssh01 (a *very*, *very*, *very* old version of the one from libssh.org) and libssh2 (completely unrelated software from libssh2.org.) libssh01 has no dependents. Can I deprecate it? Mihai

Re: libssh01 Removal

On 24.05.2015 03:23 AM, Ryan Schmidt wrote: So yes, feel free to kill libssh01 immediately. Without replacing it with libssh first or revbumping and erroring out in pre-configure? Okay. Mihai signature.asc Description: OpenPGP digital signature

Re: r136284: ghostscript: update to 9.16

On 17.05.2015 11:17 PM, petr wrote: I saw this with ImageMagick, which was rev bumped, but (1) the upgrade order has some influence, and (2) I have an non-default variants installation so I need to build anyway from source. I guess, all is okay. I just missed the second changeset. Ah,

Re: r136284: ghostscript: update to 9.16

On 17.05.2015 10:07 PM, Peter Danecek wrote: `libgs` uses the softwares version no. as library version, which is probably not correct. As a result, the all dependencies are broken and will be rebuild on rev-upgrade. In case we do not want to fix library versioning (not 100% sure it is

Re: r136284: ghostscript: update to 9.16

[Copy to Mailing list] On 17 May 2015, at 22:09, Mihai Moldovan io...@macports.org wrote: Have you looked at https://trac.macports.org/changeset/136285? Did I miss anything? Ahhh, there it is! Sorry for the buzz. I saw the rev-upgrade build, and looked for the cause. Well, no, it's

Re: upgrading/installing in a background process

On 05.05.2015 10:09 AM, René J.V. Bertin wrote: I'd launched a `port upgrade outdated` on Bradley's VM late yesterday, connected over SSH, and pushed the process to the background when I had to call it a night. I left the SSH connection open but suspended my own machine. Just now I connected

Re: standard way to require c++11?

On 30.04.2015 03:56 AM, Ryan Schmidt wrote: On Apr 29, 2015, at 1:37 AM, Ryan Schmidt wrote: That was going to be my suggestion, to avoid a proliferation of portgroups that all do something similar. For example, right now I'm dealing with the fact that gpsd 3.14 requires C11 (not C++11),

Re: Buildbot buildports-lion-x86_64 stalled for over 12 hours

On 28.04.2015 11:30 PM, Ryan Schmidt wrote: [...] I wish we had a standard way (directive or portgroup) to indicate that. I know... I'm on it... Mihai signature.asc Description: OpenPGP digital signature ___ macports-dev mailing list

Re: standard way to require c++11?

On 14.04.2015 07:44 AM, Mojca Miklavec wrote: Could something like that be added to the compiler_blacklist PortGroup? I believe that pure C++11 projects need consistent handling and it would be very handy to allow a keyword like compiler.c++11 or compiler.something c++11 to replace all of the

Re: [135656] trunk/dports/_resources/port1.0/group/cxx11-1.0.tcl

On 29.04.2015 06:51 AM, Ryan Schmidt wrote: Enclosing *gcc* and macports-clang-3.[0-2] in curly brackets looks strange to me. The reason clang 500 is quoted is so that it will be interpreted as a single value and parsed by the compilers_blacklist_versions portgroup, but *gcc* is already

Re: standard way to require c++11?

On 29.04.2015 06:55 AM, Ryan Schmidt wrote: On Apr 28, 2015, at 11:39 PM, Mihai Moldovan wrote: On 14.04.2015 07:44 AM, Mojca Miklavec wrote: Could something like that be added to the compiler_blacklist PortGroup? I believe that pure C++11 projects need consistent handling and it would

Re: [135541] trunk/dports/audio/pulseaudio

On 27.04.2015 06:56 PM, René J.V. Bertin wrote: On Monday April 27 2015 18:41:50 Mihai Moldovan wrote: port info --maintainer VLC-devel maintainer: nomaintainer I didn't claim that my version was committed yet ... I haven't been talking about your version. I meant to imply that the port

Re: [135601] trunk/dports/audio/pulseaudio

On 28.04.2015 02:37 AM, Ryan Schmidt wrote: On Apr 27, 2015, at 4:00 PM, io...@macports.org wrote: Revision 135601 Author io...@macports.org Date 2015-04-27 14:00:35 -0700 (Mon, 27 Apr 2015) Log Message pulseaudio: add record and playback module arguments for CoreAudio modules. ---

Re: [135541] trunk/dports/audio/pulseaudio

On 27.04.2015 09:21 AM, René JV Bertin wrote: Is there any reason to build the PA bits of VLC, given that VLC has native audio support? I removed the dependency from my own VLC port version, and everything works just fine. port info --maintainer VLC-devel maintainer: nomaintainer I asked

Re: Ticket #47500: fix version number in git-flow-devel (haspatch)

On 23.04.2015 04:16 PM, Davide Liessi wrote: Can you please have a look at https://trac.macports.org/ticket/47500 and commit it? * The maintainer of the git-flow* ports hasn't answered yet. * The port is openmaintainer. * The change is very simple and is needed in case of future updates.

GCC driver-driver [was: Re: standard way to require c++11?]

On 22.04.2015 07:39 PM, Jeremy Huddleston Sequoia wrote: On Apr 22, 2015, at 10:30, Lawrence Velázquez lar...@macports.org wrote: On Apr 21, 2015, at 5:14 AM, Jeremy Huddleston Sequoia jerem...@apple.com wrote: On Apr 20, 2015, at 23:51, Mihai Moldovan io...@macports.org wrote

Re: GCC driver-driver [was: Re: standard way to require c++11?]

On 22.04.2015 08:41 PM, Ryan Schmidt wrote: On Apr 22, 2015, at 1:23 PM, Mihai Moldovan wrote: You're right. The proper solution would be to add the old driver-driver back to FSF GCC and get it upstreamed, instead of relying even more on muniversal. Personally, I do not wish to do so

Re: GCC driver-driver [was: Re: standard way to require c++11?]

On 22.04.2015 08:47 PM, Ryan Schmidt wrote: On Apr 22, 2015, at 1:45 PM, Mihai Moldovan wrote: On 22.04.2015 08:41 PM, Ryan Schmidt wrote: Too bad Apple didn't contribute the code back to FSF. Or maybe they did and they didn't accept it for some reason? I don't know. But this is the kind

Re: std::log2 not in c++11 on 10.6 BuiltBot?

On 22.04.2015 09:51 PM, Michael Dickens wrote: One of my ports won't build on the 10.6 buildbot, because it claims the following (snipped for brevity): {{{ /opt/local/bin/g++-mp-4.9 [snip] -std=c++11 -o FILE.cc.o -c FILE.cc FILE.cc: In constructor FILE(std::vectorstd::vectorfloat ):

Re: std::log2 not in c++11 on 10.6 BuiltBot?

On 23.04.2015 01:39 AM, Michael Dickens wrote: Interesting; the macro is actually _GLIBCXX_USE_C99_MATH_TR1, with just 1 preceding _; at least on my 10.8 10.10 installs. Err, sorry. Yes. This macro is set at /opt/local/include/gcc49/c++/x86_64-apple-darwin12/bits/c++config.h:1276 on my

Re: std::log2 not in c++11 on 10.6 BuiltBot?

On 22.04.2015 10:39 PM, Michael Dickens wrote: Yes, the code includes cmathv (indirectly). This code works on the other buildbots; just not on the 10.6 one. Is 10.6's GCC 4.9 special somehow? Maybe I need to include cmath directly? - MLD I can reproduce your problem in my 10.6 VM. std::log2()

Re: Ports not listed as outdated

On 22.04.2015 12:00 PM, Mojca Miklavec wrote: Thanks again and sorry for the noise, No, not noise. Let me explain why. Hm. Interesting. Thank you, it seems that running portindex solved the problem indeed. I now got a long list of outdated ports. That's interesting indeed. I didn't

Re: Ports not listed as outdated

On 22.04.2015 12:28 PM, René J.V. Bertin wrote: On Wednesday April 22 2015 12:14:09 Mihai Moldovan wrote: The portindex is generated on the rsync machine, which is running Linux. If doing funky stuff that happens to abort Portfile parsing ungracefully (like not wrapping sysctl stuff in catch

Re: Ports not listed as outdated

On 22.04.2015 09:00 AM, Mojca Miklavec wrote: MacPorts is behaving a bit weird. It doesn't report some outdated ports and as a consequence doesn't upgrade them. I need some clues about where I could look to diagnose the source of the problem. port installed texlive-bin The following ports

Re: standard way to require c++11?

. On 15.04.2015 10:45 AM, Mojca Miklavec wrote: On Wed, Apr 15, 2015 at 9:42 AM, Mihai Moldovan wrote: On 14.04.2015 10:02 AM, Jeremy Huddleston Sequoia wrote: Because the above is completely entirely true. You can have multiple versions of C++ runtimes in the same process (even libc

Re: [135031] trunk/dports/multimedia

On 18.04.2015 10:13 PM, Jeremy Huddleston Sequoia wrote: Please fix this in the next couple days, or I will do what I can to fix these missteps. This The system libraries in OS X 10.8 and lower use libstdc++. Thus, libstdc++ is not supported for this port. Nit: I even made a libstdc++/libc++

Re: Tickets past maintainer timeout

[Resend with correct address...] On 15.04.2015 09:38 PM, Marius Schamschula wrote: The following tickets are well past maintainer timeout: Update libktorrent to 1.3.1: https://trac.macports.org/ticket/46773 2/5 Still TBD. Update multitail to 6.4.1: https://trac.macports.org/ticket/46855

Re: standard way to require c++11?

[This message is merging Mojca's and Jeremy's answers] On 14.04.2015 09:11 AM, Mojca Miklavec wrote: On Tue, Apr 14, 2015 at 8:18 AM, Mihai Moldovan wrote: On 14.04.2015 07:44 AM, Mojca Miklavec wrote: On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan wrote: Could something like that be added

Re: Where are our mirror scripts defined?

On 14.04.2015 11:12 PM, Clemens Lang wrote: Hi *, I am looking for information on our mirroring infrastructure, especially on the job that does the initial mirroring and puts it to the distfiles.macports.org machine from where all other mirrors download it. I think there might be a few

Re: standard way to require c++11?

On 14.04.2015 07:44 AM, Mojca Miklavec wrote: On Tue, Apr 14, 2015 at 3:54 AM, Mihai Moldovan io...@macports.org wrote: Could something like that be added to the compiler_blacklist PortGroup? I believe that pure C++11 projects need consistent handling and it would be very handy to allow

Re: standard way to require c++11?

On 14.04.2015 04:01 PM, Brandon Allbery wrote: The main problem is that Apple's own C++ stuff is based on either a pre-C++11 libstdc++ or a C++11 libc++. You could probably build an official GPL3-d libstdc++ with C++11 support and it would probably even work (that being one of the points of

Re: standard way to require c++11?

As a reply to what we discussed on IRC today, here's the relevant changes for the C++11 on steroids part of one of my ports (audacious-core): Revision: 135031 https://trac.macports.org/changeset/135031 Author: ionic at macports.org Date: 2015-04-13 09:24:21 -0700 (Mon, 13 Apr

Re: [135005] trunk/dports/x11/xinit/Portfile

On 13.04.2015 12:17 PM, Ryan Schmidt wrote: On Apr 12, 2015, at 10:29 PM, io...@macports.org wrote: Revision 135005 Author io...@macports.org Date 2015-04-12 20:29:57 -0700 (Sun, 12 Apr 2015) Log Message xinit: port to notes. Modified Paths • trunk/dports/x11/xinit/Portfile

Re: [135005] trunk/dports/x11/xinit/Portfile

On 13.04.2015 05:15 PM, Rainer Müller wrote: On 2015-04-13 17:01, Lawrence Velázquez wrote: On Apr 13, 2015, at 10:38 AM, Mihai Moldovan io...@macports.org wrote: The problem is that this is not a real block but a list element. While a newline at the beginning is generally ignored

Re: [135005] trunk/dports/x11/xinit/Portfile

On 13.04.2015 05:01 PM, Lawrence Velázquez wrote: On Apr 13, 2015, at 10:38 AM, Mihai Moldovan io...@macports.org wrote: The problem is that this is not a real block but a list element. While a newline at the beginning is generally ignored by the notes base code, newlines at the end

Re: [135005] trunk/dports/x11/xinit/Portfile

[Resent to the mailing list only] On 13.04.2015 05:10 PM, Mihai Moldovan wrote: On 13.04.2015 05:01 PM, Lawrence Velázquez wrote: On Apr 13, 2015, at 10:38 AM, Mihai Moldovan io...@macports.org wrote: The problem is that this is not a real block but a list element. While a newline

  1   2   >