Re: multiple distfiles from multiple sources and with multiple compression types

On Mar 31, 2016, at 11:35 AM, Rainer Müller wrote: > Using magic bytes would even result in wrong results in some cases. For > example for scapy, the distfile is intentionally a polyglot. It is both > a valid shell script and a zip file: > > $ file -b

Re: [147186] trunk/dports/net/nmap/Portfile

> On Mar 31, 2016, at 1:50 PM, Daniel J. Luke wrote: > > On Mar 31, 2016, at 2:45 PM, Daniel J. Luke wrote: >> Does default_variants not work like other commands? I would have expected >> default_variants-append here (and/or would rather be able to do

Re: checksums help ..

Thanks, I fix my error. It is just an issue with the directory. Thanks for your support. > On Mar 31, 2016, at 5:07 PM, John Patrick wrote: > > What errors do you get as that looks like the correct command line for > digests assuming that file in the current

Re: checksums help ..

What errors do you get as that looks like the correct command line for digests assuming that file in the current directory... John On 31 March 2016 at 17:55, Abdulrahman Alshammari wrote: > Hey, > > When I want to find the correct checksums for my file, I follow what is >

Re: PortGroup directory hierarchy/priority

Rainer Müller wrote: > Does your custom ports tree not just provide a custom implementation of > this port group? Or do the ports using this modified port group not need > any further modifications, but you do not want to copy all Portfiles to > your ports tree? I indeed have custom Qt5 and

Re: [147186] trunk/dports/net/nmap/Portfile

On Mar 31, 2016, at 2:45 PM, Daniel J. Luke wrote: > Does default_variants not work like other commands? I would have expected > default_variants-append here (and/or would rather be able to do > default_variants-delete inside the compatibility variant). answering my own

Re: [147186] trunk/dports/net/nmap/Portfile

On Mar 30, 2016, at 8:44 PM, Ryan Schmidt wrote: > you should provide an upgrade path that preserves the user's choices. Thanks. I knew I forgot something / knew there was some reason I hadn't done this before. This is probably something that should be documented for

Re: [147224] trunk/base/src/pextlib1.0/system.c

On 2016-03-31 18:01, Brandon Allbery wrote: > On Thu, Mar 31, 2016 at 11:56 AM, Rainer Müller wrote: > >> A better way could be to handle SIGINT/SIGQUIT in a custom handler and >> on reception of a signal, we would kill the child process and return the >> error {POSIX SIG

checksums help ..

Hey, When I want to find the correct checksums for my file, I follow what is mentioned in the Macports documents. But I still get different kind of errors. Can someone explain what I have to do please ? %% openssl dgst -rmd160 rrdtool-1.2.23.tar.gz %% openssl dgst -sha256 rrdtool-1.2.23.tar.gz

Re: multiple distfiles from multiple sources and with multiple compression types

On 2016-03-31 03:16, Ryan Schmidt wrote: > libmagic should be used to determine the compression format; filename > extension should not be used. Was there ever a case with a .tar.gz that was actually compressed with bzip2 or something like this? The current approach of 'use_* yes' also assumes

Re: [147224] trunk/base/src/pextlib1.0/system.c

On Thu, Mar 31, 2016 at 11:56 AM, Rainer Müller wrote: > A better way could be to handle SIGINT/SIGQUIT in a custom handler and > on reception of a signal, we would kill the child process and return the > error {POSIX SIG SIGINT} as result of SystemCmd. However, I am unsure

Re: [147224] trunk/base/src/pextlib1.0/system.c

On 2016-03-31 17:53, rai...@macports.org wrote: > Revision: 147224 > https://trac.macports.org/changeset/147224 > Author: rai...@macports.org > Date: 2016-03-31 08:53:21 -0700 (Thu, 31 Mar 2016) > Log Message: > --- > pextlib/system: ignore signals SIGINT/SIGQUIT > > When

Re: html and postscript viewer

That's even better. Thanks! Sent from my iPhone > On Mar 30, 2016, at 9:39 PM, Ryan Schmidt wrote: > >> On Mar 30, 2016, at 21:17, Mark Brethen wrote: >> >> I suppose these launch scripts will need to be installed in ${prefix}/bin. > > No need for custom scripts. Set

Re: PortGroup directory hierarchy/priority

I just wanted to say that I also often experience very strange problems after modifications to any of the PortGroups (of course I do modifications in the local repository rather than the global one that gets synced via rsync as I don't want them to be overwritten). Most often I was getting errors

Re: PortGroup directory hierarchy/priority

On 2016-03-30 19:21, René J. V. Bertin wrote: > Rainer Müller wrote: > >> 1. _resources/port1.0/group/*.tcl in ports tree of this port >> 2. _resources/port1.0/group/*.tcl in default ports tree > > A "check in 1) and then in 2) if not found" even if 1) is inside a tree that > doesn't override

Re: logfile name available in Portfile?

On Thursday March 31 2016 12:02:53 Mojca Miklavec wrote: > It might make more sense if we would solve this "globally", even > though I'm not exactly sure how. We are constantly getting I'd agree. In that case, I'd argue for something like an internal post-post-phase which simply copies

Re: logfile name available in Portfile?

On 31 March 2016 at 11:28, René J.V. wrote: > Hi, > > Quick question: is the name of the logfile available in the Portfile, through > a variable? > Reason: I'd like to save a copy of the file in the work dir during the > post-configure phase, so that the information remains available regardless

logfile name available in Portfile?

Hi, Quick question: is the name of the logfile available in the Portfile, through a variable? Reason: I'd like to save a copy of the file in the work dir during the post-configure phase, so that the information remains available regardless of how I build/install a port. While upgrading one of

Re: multiple distfiles from multiple sources and with multiple compression types

On Wednesday March 30 2016 20:16:37 Ryan Schmidt wrote: >libmagic should be used to determine the compression format; filename >extension should not be used. I'd agree with that - if introducing an additional dependency isn't an issue. I guess that the set of compression formats to recognise is