Re: advanced bash-ing for long compiles

2016-10-14 Thread Craig Treleaven 
> On Oct 14, 2016, at 7:37 PM, Clemens Lang  wrote:
> - On 15 Oct, 2016, at 01:05, Fred Wright f...@fwright.net wrote:
> ...
>> One can also accomplish this via:
>> 
>>  sudo touch /opt/local/var/macports/build/.metadata_never_index
>> 
>> Though I don't know if this works across all OS versions.
> 
> Do you have documentation on this? The only documentation I could find
> back then suggested that Spotlight will ignore hidden directories, so
> that's why we made it hidden.
> 
Yes, this came up more than 2 years ago.  I couldn’t find official docs at that 
point.  

http://www.mail-archive.com/macports-dev@lists.macosforge.org/msg26538.html

Only a discussion on apple-stackexchange:

http://apple.stackexchange.com/questions/92784/preventing-spotlight-from-indexing-files-folders

Right now, searches on Apple’s Developer site are just endlessly spinning.

Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Fred Wright 

On Fri, 14 Oct 2016, Ryan Schmidt wrote:
> On Oct 14, 2016, at 09:50, Ken Cunningham  
> wrote:

> > Oh, one more similar question while I'm at it.
> >
> > I notice mdworker seems to go nuts during these long builds, often
> > appearing to soak up lots of cycles. I assume it's trying to index
> > all the build files, etc
> >
> > is it easy to sleep that function and then re-enable it after the compile 
> > is done?
>
> I configure Spotlight not to index the /opt/local/var/macports/build 
> directory (System Preferences)

By default, this isn't possible via the GUI, due to the macports
directory's being hidden.

On Sat, 15 Oct 2016, Joshua Root wrote:

> Not sure why this would be, since we set the hidden flag on
> ${prefix}/var/macports (technically $portdbpath) which should exclude it
> from Spotlight indexing. Maybe that doesn't work on 10.6? You could try
> adding it to the Privacy list in the Spotlight settings manually.

If you can.  See above.

One can also accomplish this via:

sudo touch /opt/local/var/macports/build/.metadata_never_index

Though I don't know if this works across all OS versions.

Hiding the macports directory also gets in the way of attaching build logs
to tickets, since the browser's dialog box can't navigate to them.  I've
unhid this directory in the past for that reason, but every so often
something "fixes" it.  If preventing indexing is the sole reason for
hiding the directory, wouldn't using ".metadata_never_index" be better?

Fred Wright
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Joshua Root 

On 2016-10-15 01:50 , Ken Cunningham wrote:


I notice mdworker seems to go nuts during these long builds, often appearing to 
soak up lots of cycles. I assume it’s trying to index all the build files, etc

is it easy to sleep that function and then re-enable it after the compile is 
done?


Not sure why this would be, since we set the hidden flag on 
${prefix}/var/macports (technically $portdbpath) which should exclude it 
from Spotlight indexing. Maybe that doesn't work on 10.6? You could try 
adding it to the Privacy list in the Spotlight settings manually.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Lawrence Velázquez 
> On Oct 14, 2016, at 10:50 AM, Ken Cunningham 
>  wrote:
> 
> I notice mdworker seems to go nuts during these long builds, often appearing 
> to soak up lots of cycles. I assume it’s trying to index all the build files, 
> etc
> 
> is it easy to sleep that function and then re-enable it after the compile is 
> done?

You should just stop Spotlight from indexing your MacPorts prefix at all
(System Preferences > Spotlight > Privacy).

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Lawrence Velázquez 
> On Oct 14, 2016, at 10:30 AM, Ken Cunningham 
>  wrote:
> 
> long compiles can take hours
> 
> i can ssh into the machine and get it started
> 
> sudo port -v install gcc48 gcc5 gcc6 gcc7
> 
> that, for example, might take several days to finish (if it does
> finish)
> 
> then I control-Z to pause it, and "bg" to throw it into the background
> 
> then I can close my ssh session and the compile proceeds...
> 
> how exactly do I best find that process to "fg" it again? If I just
> log back in and "fg" it, it is not found. but top shows the process is
> humming away in the background, as expected

You can't bring that process back into the foreground because it is no
longer under any shell's job control because you terminated its
controlling shell by exiting the ssh session.

http://mywiki.wooledge.org/BashGuide/JobControl

> is the process different from a local shell vs a remote shell?

There's no real distinction between a "local" shell and a "remote"
shell.

> is this all wrong, and it's way better to use screen or tmux or ???

Yes. Save yourself the headache.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Brandon Allbery 
On Fri, Oct 14, 2016 at 10:30 AM, Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> how exactly do I best find that process to "fg" it again? If I just log
> back in and "fg" it, it is not found. but top shows the process is humming
> away in the background, as expected
>

You can't; it's not a child of your current shell, so you cannot reattach
it. This is why screen and tmux exist.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread David Bariod 
Hi Ken,

I would really use screen instead and disconnect it and reconnect it later.

David

On Fri, Oct 14, 2016 at 4:30 PM, Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> Some advice appreciated ...
>
>
> long compiles can take hours
>
> i can ssh into the machine and get it started
>
> sudo port -v install gcc48 gcc5 gcc6 gcc7
>
> that, for example, might take several days to finish (if it does finish)
>
> then I control-Z to pause it, and "bg" to throw it into the background
>
> then I can close my ssh session and the compile proceeds...
>
> how exactly do I best find that process to "fg" it again? If I just log
> back in and "fg" it, it is not found. but top shows the process is humming
> away in the background, as expected
>
> is the process different from a local shell vs a remote shell?
> is this all wrong, and it's way better to use screen or tmux or ???
>
> Thanks,
>
> K
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: advanced bash-ing for long compiles

2016-10-14 Thread Ken Cunningham 

> On Oct 14, 2016, at 7:30 AM, Ken Cunningham  
> wrote:
> 
> Some advice appreciated …
> 

Oh, one more similar question while I’m at it.

I notice mdworker seems to go nuts during these long builds, often appearing to 
soak up lots of cycles. I assume it’s trying to index all the build files, etc

is it easy to sleep that function and then re-enable it after the compile is 
done?

K
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: trac down?

2016-10-14 Thread Ryan Schmidt 
On Oct 14, 2016, at 09:12, Lawrence Velázquez  wrote:

>> On Oct 14, 2016, at 8:55 AM, René J.V. Bertin  wrote:
>> 
>> I cannot connect to trac but the main site works fine. Is there a problem 
>> with the server?
> 
> I have not been able to reach it since last night (~12 hours ago).

That'll be my fault for trying to fix a DNS problem around that time. (The 
macOS forge servers still aren't aware that we moved MacPorts DNS to NameCheap 
some weeks ago. I was trying to explain it to them.) I reverted my change and 
will ask the Apple DNS team for guidance on how to do it correctly. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: trac down?

2016-10-14 Thread Joshua Root 

On 2016-10-15 01:12 , Lawrence Velázquez wrote:

On Oct 14, 2016, at 8:55 AM, René J.V. Bertin  wrote:

I cannot connect to trac but the main site works fine. Is there a problem with 
the server?


I have not been able to reach it since last night (~12 hours ago).


It loaded fine for me just now, FWIW.

- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: trac down?

2016-10-14 Thread Lawrence Velázquez 
> On Oct 14, 2016, at 8:55 AM, René J.V. Bertin  wrote:
> 
> I cannot connect to trac but the main site works fine. Is there a problem 
> with the server?

I have not been able to reach it since last night (~12 hours ago).

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153826] trunk/dports/net

2016-10-14 Thread mf2k 
Hi Ryan,


Thank you for the the suggestions! I made some changes in r153861. Please feel 
free to make further improvements to the Portfile since it is nomaintainer. 


Cheers!
Frank

> On Oct 13, 2016, at 8:35 AM, Ryan Schmidt  wrote:
> 
> 
>> On Oct 12, 2016, at 4:23 PM, m...@macports.org wrote:
>> 
>> Revision
>> 153826
>> Author
>> m...@macports.org
>> Date
>> 2016-10-12 14:23:02 -0700 (Wed, 12 Oct 2016)
>> Log Message
>> 
>> ldns ldns-tools drill: Merge into single Portfile.
>> Modified Paths
>> 
>>  • trunk/dports/net/ldns/Portfile
>> Removed Paths
>> 
>>  • trunk/dports/net/drill/Portfile
>>  • trunk/dports/net/ldns-tools/Portfile
>> 
> 
> 
> 
>> --- trunk/dports/net/ldns/Portfile   2016-10-12 14:44:21 UTC (rev 153825)
>> +++ trunk/dports/net/ldns/Portfile   2016-10-12 21:23:02 UTC (rev 153826)
>> 
>> @@ -1,18 +1,35 @@
>> 
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> 
>> # $Id$
>> 
>> 
>> 
>> -PortSystem 1.0
>> 
>> +PortSystem  1.0
>> 
>> 
>> 
>> nameldns
>> 
>> +subport ldns-tools {}
>> +subport drill {}
>> +
>> 
>> version 1.6.17
>> 
>> categories  net devel
>> 
>> platforms   darwin
>> 
>> license BSD
>> 
>> maintainers nomaintainer
>> 
>> 
>> 
>> -description DNS library in C
>> -long_descriptionldns is a library with the aim of simplifying DNS \
>> -programming in C. It is heavily based upon the Net::DNS 
>> module from \
>> -Perl.
>> 
>> +if {${subport} eq "ldns"} {
>> +description DNS library in C
>> +long_descriptionldns is a library with the aim of simplifying DNS \
>> +programming in C. It is heavily based upon the 
>> Net::DNS module from \
>> +Perl.
>> +}
>> +if {${subport} eq "ldns-tools"} {
>> +description Tools for working with dns and dnssec.
>> +long_descriptionTools as examples to the ldns library. \
>> +Useful for debugging/querying dns/dnssec servers.
>> +}
>> +if {${subport} eq "drill"} {
>> +description A dig-style dnssec-aware dns debugging tool
>> +long_descriptionDrill is a tool ala dig from BIND. \
>> +It was designed with DNSSEC in mind and should be a 
>> useful \
>> +debugging/query tool for DNSSEC.
>> +}
> 
> When comparing a single variable to several possible values, consider using a 
> switch statement.
> 
> Or, when making subports, consider putting the directives that relate to the 
> subport into the subport directive, rather than declaring an empty subport 
> directive which is a bit more confusing.
> 
> 
>> +if {${subport} ne "ldns"} {
>> +distnameldns-${version}
>> +dist_subdir ldns
>> +}
> 
> The default for distname is ${name}-${version} and the default for 
> dist_subdir is ${name} so now that these are subports in a main port named 
> ldns, these lines aren't necessary anymore.
> 
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

trac down?

2016-10-14 Thread René J . V . Bertin 
Hi,

I cannot connect to trac but the main site works fine. Is there a problem with 
the server?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev