How to mark pull request as ready for review?

[Brian Weitzner]

Hello,

I am a first-time contributor fixing a port I depend on that has no maintainer. 
I have opened a pull request here: 
https://github.com/macports/macports-ports/pull/11151 
 and it passes all of 
the build checks. What are the next steps for getting this approved and merged 
in? Thanks!

-- 
Brian Weitzner

MacPorts 2.7.1 - Availability for GitHub CI Jobs, as well as Buildbots?

[Christopher Nielsen]

While I realize MacPorts 2.7.1 was just released, is there an ETA on when it 
will be available for both CI, as well as our buildbots?

There’s certainly no rush. But the bug fix for issue 56793 (slow installs of 
ports with tens of thousands of files) would be hugely beneficial 
across-the-board.

Also, it looks like the GitHub CI jobs may still be utilizing 2.6.4…?

Re: Freenode IRC

[g5pw]

> On 26 May 2021, at 22:20, Joshua Root  wrote:
> 
> The mpbridge bot that connects IRC with RocketChat also needs to be added to 
> the new channel (but doesn't necessarily have to be removed from the old one 
> yet.)

I’ll take care of it today/tomorrow… I’ll configure it so it bridges both 
channels.

g5pw

Re: Freenode IRC

[Joshua Root]

On 2021-5-27 06:09 , Rainer Müller wrote:

I moved the mplog bot to Libera.Chat. It is now announcing commits in
#macports and #macports-commits, as it did previously.

I also updated the wiki page and added that to the IRC channel topic:
https://trac.macports.org/wiki/Chat


The mpbridge bot that connects IRC with RocketChat also needs to be 
added to the new channel (but doesn't necessarily have to be removed 
from the old one yet.)


- Josh

Re: Freenode IRC

[Rainer Müller]

On 26/05/2021 11.19, Joshua Root wrote:
> On 2021-5-26 14:39 , Thomas R. Murphy wrote:
>> As continued malicious behavior continues on the current network for
>> #macports, I'm quite interested in seeing a move for the project.

I agree, it is about time now.

> The channel is all set up on Libera, we just need to move the rest of
> the bots over.
I moved the mplog bot to Libera.Chat. It is now announcing commits in
#macports and #macports-commits, as it did previously.

I also updated the wiki page and added that to the IRC channel topic:
https://trac.macports.org/wiki/Chat

Website still needs to be updated via the macports-www repository.

Rainer

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

[Christopher Nielsen]

I’m referring to debug output like the following, in this cases taken from one 
of our builtbot logs. Some of these are generated by base, while others are 
generated by the portgroups themselves.

While I’m not necessarily advocating that we hide all of these (via output at 
level debug2 or debug3), we’d have the option.

Does that make sense?

DEBUG: Sourcing PortGroup legacysupport 1.1 from 
/opt/bblocal/var/buildworker/ports/build/ports/_resources/port1.0/group/legacysupport-1.1.tcl
DEBUG: Sourcing PortGroup compiler_wrapper 1.0 from 
/opt/bblocal/var/buildworker/ports/build/ports/_resources/port1.0/group/compiler_wrapper-1.0.tcl
DEBUG: Re-registering default for universal_variant
DEBUG: Re-registering default for use_configure
DEBUG: Re-registering default for dist_subdir
DEBUG: Re-registering default for worksrcdir
DEBUG: Re-registering default for build.cmd
DEBUG: Re-registering default for build.target
DEBUG: Re-registering default for test.cmd
DEBUG: Re-registering default for test.target
DEBUG: Re-registering default for configure.env
DEBUG: Sourcing PortGroup golang 1.0 from 
/opt/bblocal/var/buildworker/ports/build/ports/_resources/port1.0/group/golang-1.0.tcl
DEBUG: Re-registering default for legacysupport.newest_darwin_requires_legacy
DEBUG: Will append MACPORTS_LEGACY_SUPPORT_DISABLED=1 to extract.env
DEBUG: Will append MACPORTS_LEGACY_SUPPORT_DISABLED=1 to configure.env
DEBUG: Will append MACPORTS_LEGACY_SUPPORT_DISABLED=1 to build.env
DEBUG: Will append MACPORTS_LEGACY_SUPPORT_DISABLED=1 to destroot.env
DEBUG: Will append MACPORTS_LEGACY_SUPPORT_DISABLED=1 to test.env
DEBUG: Re-registering default for legacysupport.header_search
DEBUG: Re-registering default for legacysupport.library_name
DEBUG: Re-registering default for legacysupport.use_static
DEBUG: Re-registering default for legacysupport.redirect_bins
DEBUG: Sourcing PortGroup legacysupport 1.1 from 
/opt/bblocal/var/buildworker/ports/build/ports/_resources/port1.0/group/legacysupport-1.1.tcl
DEBUG: Sourcing PortGroup github 1.0 from 
/opt/bblocal/var/buildworker/ports/build/ports/_resources/port1.0/group/github-1.0.tcl
DEBUG: Re-registering default for livecheck.url
DEBUG: Re-registering default for livecheck.regex
DEBUG: universal_variant is false, so not adding the default universal variant
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Running callback legacysupport::add_legacysupport



> On 2021-05-26-W, at 09:30, Ryan Schmidt  wrote:
> 
>> On May 26, 2021, at 06:07, Christopher Nielsen wrote:
>> 
>> Great question!
>> 
>> One of the key things this would allow us to do, is reduce our current Debug 
>> output, by outputting less-important details at Debug2 or Debug3. For 
>> example, if we don’t want to see some of the ui_debug messages from our 
>> various portgroups - like, say, the numerous messages related to adding port 
>> callbacks - we could modify those to output some things at ui_debug2 or 
>> ui_debug3.
>> 
>> So if we needed to diagnose precisely what portgroup callbacks are added, 
>> those diagnostic messages could be enabled by setting the output level [via 
>> the port command] to Debug2 or Debug3. But at the current Debug level, 
>> they’d be hidden, making things less verbose.
>> 
>> Does that make sense?
> 
> I'm not familiar with "numerous messages related to adding port callbacks". 
> Is this information MacPorts automatically prints when adding a callback, or 
> something individual portgroups are printing - if so why?

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

[Ryan Schmidt]

On May 26, 2021, at 06:07, Christopher Nielsen wrote:

> Great question!
> 
> One of the key things this would allow us to do, is reduce our current Debug 
> output, by outputting less-important details at Debug2 or Debug3. For 
> example, if we don’t want to see some of the ui_debug messages from our 
> various portgroups - like, say, the numerous messages related to adding port 
> callbacks - we could modify those to output some things at ui_debug2 or 
> ui_debug3.
> 
> So if we needed to diagnose precisely what portgroup callbacks are added, 
> those diagnostic messages could be enabled by setting the output level [via 
> the port command] to Debug2 or Debug3. But at the current Debug level, they’d 
> be hidden, making things less verbose.
> 
> Does that make sense?

I'm not familiar with "numerous messages related to adding port callbacks". Is 
this information MacPorts automatically prints when adding a callback, or 
something individual portgroups are printing - if so why?

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

[Christopher Nielsen]

Great question!

One of the key things this would allow us to do, is reduce our current Debug 
output, by outputting less-important details at Debug2 or Debug3. For example, 
if we don’t want to see some of the ui_debug messages from our various 
portgroups - like, say, the numerous messages related to adding port callbacks 
- we could modify those to output some things at ui_debug2 or ui_debug3.

So if we needed to diagnose precisely what portgroup callbacks are added, those 
diagnostic messages could be enabled by setting the output level [via the port 
command] to Debug2 or Debug3. But at the current Debug level, they’d be hidden, 
making things less verbose.

Does that make sense?


> On 2021-05-26-W, at 04:39, Ryan Schmidt  wrote:
> 
>> On May 24, 2021, at 10:13, Christopher Nielsen wrote:
>> 
>> Has there been any thoughts/interest in implementing another level (or two) 
>> of debug output, providing more detail than we get at Debug? That would 
>> allow us to optionally output more diagnostic info in various areas, such as 
>> our portgroups, without flooding the logs when running at our present Debug 
>> level.
> 
> I personally find debug mode too verbose already and think we should reduce 
> the amount of information produced by debug mode. Consider the amount of 
> information printed by a port that does a batch reinplace -q over every file, 
> for example, or the amount of information printed about each dependency.
> 
> Can you give specific examples of the type of information you would like to 
> see in your proposed new output mode?

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

[Ryan Schmidt]

On May 26, 2021, at 04:53, Georges Martin wrote:

>> I personally find debug mode too verbose already and think we should reduce 
>> the amount of information produced by debug mode.
> 
> I don’t know enough about Tcl logging but in Python you can have separate, 
> hierarchical loggers for each major modules in your system and then activate 
> and set the logging level for each of them.
> 
> It means you could have a top logger (« macports ») set to INFO…
> 
>>> That would allow us to optionally output more diagnostic info in various 
>>> areas, such as our portgroups,
> 
> …and several module loggers (« macports.portgroups », « 
> macports.portgroups.compiler_blacklist »,…) set to DEBUG.
> 
> The advantage is that you keep a manageable, standard set of logging levels 
> and have a small set of functional module loggers.

In MacPorts, there are six output "levels": error, warn, msg, notice, info, 
debug. Each piece of code that wishes to produce output decides the appropriate 
level for each line of output. The main.log contains all output, in a similar 
but different format to that which you get if you use the debug flag (-d). The 
verbose flag (-v) gives you less output than debug, and normal mode (no flag) 
gives you less output than that.

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

[Georges Martin]

> I personally find debug mode too verbose already and think we should reduce 
> the amount of information produced by debug mode.


I don’t know enough about Tcl logging but in Python you can have separate, 
hierarchical loggers for each major modules in your system and then activate 
and set the logging level for each of them.

It means you could have a top logger (« macports ») set to INFO…

>> That would allow us to optionally output more diagnostic info in various 
>> areas, such as our portgroups,

…and several module loggers (« macports.portgroups », « 
macports.portgroups.compiler_blacklist »,…) set to DEBUG.

The advantage is that you keep a manageable, standard set of logging levels and 
have a small set of functional module loggers.

G.

Re: Freenode IRC

[Joshua Root]

On 2021-5-26 14:39 , Thomas R. Murphy wrote:
As continued malicious behavior continues on the current network for 
#macports, I'm quite interested in seeing a move for the project.


The channel is all set up on Libera, we just need to move the rest of 
the bots over.


Wikimedia has this guide for migrating: 
. Some of 
it is specific to their project, but quite a bit is universally applicable.


- Josh

Re: MacPorts Base: Support for a lower level of debug output, like ui_trace, or ui_debug2/ui_debug3?

[Ryan Schmidt]

On May 24, 2021, at 10:13, Christopher Nielsen wrote:

> Has there been any thoughts/interest in implementing another level (or two) 
> of debug output, providing more detail than we get at Debug? That would allow 
> us to optionally output more diagnostic info in various areas, such as our 
> portgroups, without flooding the logs when running at our present Debug level.
> 
> I’ve found this extremely helpful in the various projects I’ve worked on over 
> the years. And it would certainly benefit us too.
> 
> In many of the common logging frameworks, such a level is sometimes called 
> Trace. That terminology might be confusing within MacPorts, given that we 
> support trace mode. So perhaps we would want to name it differently. (Debug2 
> and Debug3?)
> 
> But naming aside, has anyone else considered the general idea? Thoughts?

I don't believe this has been proposed before.

(I did propose a "developer" mode before, where developers could opt in to 
receive information that is relevant for developers but which would only 
confuse users, either globally or possibly limited just to ports they maintain 
for example.)

I personally find debug mode too verbose already and think we should reduce the 
amount of information produced by debug mode. Consider the amount of 
information printed by a port that does a batch reinplace -q over every file, 
for example, or the amount of information printed about each dependency.

Can you give specific examples of the type of information you would like to see 
in your proposed new output mode?