Re: github portal hacked?

[Clemens Lang]

On Tue, Aug 04, 2020 at 09:24:47AM -0400, Lenore Horner wrote:
> I was going to file a bug for gnucash 4.1 because even after a clean,
> it fails to build, but when I clicked the github login button from the
> macports page https://trac.macports.org/search?q=gnucash
> , I got a warning from
> Avast that the site contains malware and is a phishing scam.  Or is
> Avast being stupid?

Our GitHub login is a standard OAuth login mechanism. The code that
implements this is the trac-github Trac plugin, which we are developing
in conjunction with two people from the Trac community over at
github.com/trac-hacks/trac-github.

Specifically, the code that handles the login is
https://github.com/trac-hacks/trac-github/blob/master/tracext/github/__init__.py#L158-L226

To my knowledge, none of that is malicious, and I have personally
installed the plugin from this repository on trac.macports.org. I really
think this is a false positive from Avast – however, you should report
this to Avast so that they become aware of the problem and can adjust
their filter mechanisms.

-- 
Clemens

Re: Workarounds for cross compiling to Windows?

[Ces VLC]

On Fri, Jul 10, 2020 at 10:41 AM Ryan Schmidt 
wrote:
>
> [...]
>
> Ports should ideally segregate Mac-specific instructions and patches into
> a "platform darwin" block, but many many ports don't do that and almost
nobody
> tries to use MacPorts in any way on other platforms, though there has
been a
> little interest from a couple people recently in using it in a very
minimal way on
> Linux.
>
> Even though our ports collection is intended for use on macOS, MacPorts
base
> should compile and run on other operating systems. We used to generate
the
> PortIndex files on a Linux server and we also had a buildbot task that
verified that
> every MacPorts base commit built successfully on Linux. But near the end
of 2016
> we moved to new servers and phased out those Linux parts so it's possible
that
> some Linux incompatibilities have crept into base since then.
>
> [...]
>
> It's certainly feasible to make your own private ports collection for
your own purposes.
> I for example have a collection of ports that manage the configuration of
all the ports
> used to drive the buildbot system. There are a few common things I do in
each port
> so I make a new portgroup that I include in each of my ports that does
those things.
>
> So it might be doable to define a new cross-compile-for-Windows portgroup
that you
> could include into each of your custom ports, and the portgroup could
take care of
> setting the compiler variables and flags properly, for example.
>
> The software you want to build will probably also have dependencies on
programs
> that get run at build time, and those would need to be compiled normally
for macOS
> so that they can run on your Mac.
>
> You might be able to set up your custom portgroup to install all your
Windows software
> to a different location, like /opt/windows (maybe setting up a new
variable like $wprefix
> with that value so that you can use it in your portfiles) while leaving
$prefix to be the
> compiled-for-Mac prefix for build dependencies.
>
> Or perhaps Wine figures into your build process, in case you need to run
> compiled-for-Windows programs on your Mac as part of the build.

Thanks a lot for such detailed information, Ryan. It's going to be very
helpful. Yes, I'm going to do a private ports collection for just the
packages I need to cross-compile to Windows. I believe it can be a bit
difficult at the beginning, while I figure out how to do the plumbing, but
it will pay off in the long run, and it's exactly the approach I need.

By the way, I'm sorry for the delay in my reply: your message got into the
spam filter and I hadn't seen it :-(

Kind regards and thanks a lot,

César

Re: Build clang in stages? And how to run "make check-all"

[Ken Cunningham]

> I know there's a supposedly officially supported multistage build in LLVM
> (see https://llvm.org/docs/AdvancedBuilds.html 
> ). I've never used it (mainly
> because LLVM is usually a bit lagging in terms of documentation: before the
> monorepo you even had to guess where each subproject was supposed to be
> downloaded in the tree).
> 
> Anyway, despite not using this official multistaging, I've always built
> LLVM in manual stages (at least two: first stage with my current compiler,
> second stage with the first stage compiler). At the end I issued a "make
> check-all" for checking how the result looks in terms of tests
> passes/failures.
> 
> Now, looking at the portfile, it seems like LLVM/clang is built with one
> stage only in MacPorts and no checks are performed (unless I'm missing some
> bits, because I'm still no expert at portfile syntax).


There are two issues at present (that I know of..) with moving to this method 
of building the llvm tree.
The biggest one is that we have separated llvm from clang, as we use llvm 
standalong with other tools like cctools and ld64 (they use it to support 
link-time optimization etc).

1. building the monorepo and then only installing llvm, or everything except 
llvm, which we’d have to do to keep our current style, is a rather big PITA.

I was considering just installing the entire llvm/clang monorepo when we 
install “llvm” and leaving clang/lldb etc for now at least as empty ports that 
depend on llvm, but that is unlikely to fly very well in an environment where 
specifying a python27 for llvm-3.3 on Tiger generates tremendous discussion. SO 
— I have not bothered to do to that, and left it the way Jeremy had it.


2. We cannot do the llvm Advanced Build in MacPorts until this ticket is 
resolved:

https://trac.macports.org/ticket/59992

and there seems to be no resolution available to that ticket that is 
acceptable. SO we are stuck there.

I have a Portfile that does the MultiStage Advanced build for 
llvm/clang/lldb/flang etc that I use myself, pending some resolution of the 
above two issues.


Best,


Ken

Re: github portal hacked?

[Lothar Haeger]

You may want to ask Avast this question. 

FWIW: the link works for me (FireFox on macOS) and logs me into Trac via Github 
as expected.

github portal hacked?

[Lenore Horner]

I was going to file a bug for gnucash 4.1 because even after a clean, it fails 
to build, but when I clicked the github login button from the macports page 
https://trac.macports.org/search?q=gnucash 
, I got a warning from Avast that 
the site contains malware and is a phishing scam.  Or is Avast being stupid?
Lenore

Build clang in stages? And how to run "make check-all"

[Ces VLC]

Hi!

I've always built the complete LLVM tree manually, on my own, but now for
the sake of more convenient updates and more comfortable patching, I'll
move to the MacPorts LLVM builds (*).

I know there's a supposedly officially supported multistage build in LLVM
(see https://llvm.org/docs/AdvancedBuilds.html). I've never used it (mainly
because LLVM is usually a bit lagging in terms of documentation: before the
monorepo you even had to guess where each subproject was supposed to be
downloaded in the tree).

Anyway, despite not using this official multistaging, I've always built
LLVM in manual stages (at least two: first stage with my current compiler,
second stage with the first stage compiler). At the end I issued a "make
check-all" for checking how the result looks in terms of tests
passes/failures.

Now, looking at the portfile, it seems like LLVM/clang is built with one
stage only in MacPorts and no checks are performed (unless I'm missing some
bits, because I'm still no expert at portfile syntax).

Don't you check the validity of the resulting compiler in some way? I
suppose you do, at least for internal tests, don't you?

Kind regards and thanks a lot,

César
(*) When I say "LLVM", I mean the whole tree (including flang when LLVM 11
gets released --I'm tempted to try the RC1, but there seem to be some fatal
reports from release testers in the mailing list, so maybe it's wiser to
wait for at least RC2 --although the developer doing the MacOS build
reported total success with RC1 --he didn't build flang, though). Looking
at the portfiles, it looks like the port for "everything" is clang rather
than llvm, if I'm not mistaken.