Using this on Linux: `can't read "configure.compiler": can't read "compiler.fallback": can't read "os.platform": no such variable`

[barracuda156]

Aside of missing PG which is required by port sync with a patched base, I cannot sync this repo cloned locally (after setting it as a source). Besides of several errors re missing PGs from macstrop, I also get many of these:

Failed to parse file audio/forked-daapd/Portfile: can't read "configure.compiler": can't read "compiler.fallback": can't read "os.platform": no such variable

PGs I can copy from macstrop, but what to do about this one? And how to deal with a need for a local PG for port syncing the master?

[RJVB]

On Wednesday August 07 2024 11:37:57 Sergey Fedorov wrote:

Failed to parse file audio/forked-daapd/Portfile: can't read "configure.compiler": can't read "compiler.fallback": can't read "os.platform": no such variable

Yes, this is one that I haven't yet bothered to fix, as I always specify configure.compiler on the commandline ...

[barracuda156]

With port sync? Never knew it is even supported, I only used it with port build.

[RJVB]

On Wednesday August 07 2024 13:29:14 Sergey Fedorov wrote:

With port sync?

Nope, I don't use that.

Do you get the error when running portindex? If so that's new, if not port sync must do an actual execution of the Portfiles, and in that case adding configure.compiler on the commandline might just work.

But yeah, I'll have to fix this eventually.

[barracuda156]

Yeah, it is portindex does not work now.

[barracuda156]

Apparently the issue is that default_compilers is not set. Adding default_compilers gcc to macports.conf allowed portindex to start adding ports.

[RJVB]

On Wednesday August 07 2024 18:21:41 Sergey Fedorov wrote:

Annoying that portindex trips over this sort of thing now; looks like I'll really have to resume working on that port upgrade!

Apparently the issue is that default_compilers is not set

No, I think the issue is something else, setting default_compilers is just a more convenient version of the fix that I've been using too. The real issue is that portconfigure::get_compiler_fallback hasn't been adapted, but that doesn't explain why the new portindex bothers with the configure stage.

Interestingly I am not getting the compiler error on port:forked-daapd with the "base" version I'm still running.

[barracuda156]

BTW, port index takes forever. I thought Tiger on G4 is doing it slow – well, Linux on 2023 riscv64 is syncing ports from morning until now, and still on sysutils. Dunno how many hours, but it feels insane. (It is not freezing, output shows that the sync is going successfully so far, it is just super slow.)

P. S. Perhaps it matters that it runs from SD card, but still.

[RJVB]

On Thursday August 08 2024 05:30:16 Sergey Fedorov wrote:

BTW, port index takes forever.

Portindex was never fast, and if it now does more work it will be even slower. This is just one of the reasons why I don't call port sync or port selfupdate (AND always use -n when building). There are so many and frequent changes to the port tree that you'd have to do those operations every day in order to keep the time spent on them reasonable.

(It also means that the tree directory gets huge with loads of small files (disk overhead/waste!) and a really large .git directory.)

Currently, I do a git clone -n --depth=1 github:macports/macports-ports mptree-git once every few months and then do git -C mptree checkout master -- category/portname to get the "latest" portdir. You can build those with port -n <stage> mptree-git/category/portname [subport=name] [options]; the only thing that doesn't work with that is port upgrade (you have to use install or archive instead).

It's like with Linux: either you use a distro provides binary packages and doesn't push updates all the time so you can focus on working with it, or you use a bleeding edge version of Arch or Gentoo where everything is built locally. In that case you better have bleeding edge hardware too...

Even with Ubuntu I've learned to be conservative in applying updates, and always look at what gets uninstalled (I once almost lost my DE because the mirror I used was in the process of getting the latest packages itself).

[barracuda156]

Ok, after a day of torture, I have built one port from source LOL bmake for no-version unknown OS and riscv64: https://ports.macports.org/port/bmake/stats

There are multiple issues with how port build [does not] work now. I had to set configure.cflags.riscv64 and the same for archflags (both to nothing) on command line to convince port build that it is a credible build. Muniversal stuff does not even sync (I guess archs have to be fixed), some ports try to look for ncurses-devel (why?) which does not exist. Etc.

At the same time it is kinda functional: perhaps a week or two of work on that, and it will be smooth. (Build system, I mean; of course, not all ports will build.)

[RJVB]

On Thursday August 08 2024 09:00:25 Sergey Fedorov wrote:

There are multiple issues with how port build [does not] work now. I had to set configure.cflags.riscv64 and the same for archflags (both to nothing) on command line to convince port build that it is a credible build.

I warned you that colonising a new architecture would require work!

Muniversal stuff does not even sync

I don't know what that means... but you shouldn't try to build anything +universal on Linux because it doesn't make sense. The existing muniversal PGs should not cause issues just during portfile execution as long as no one tries to be clever and use an arch variable to define muniversal.* settings. Just setting them for known architectures should work as always (as long as they include the muniversal PGs from MacStrop).

, some ports try to look for ncurses-devel (why?) which does not exist. Etc.

None of mine?! You don't see that port listed in devport_db.tcl I hope? That one is created on the fly and but only searches for -dev ports, not -devel ... (I stumbled across a trace of an ancient astyle-dev port in one of my trees on Mac yesterday, which evidently was assumed to contain the development content of port:astyle :) )

[barracuda156]

Re port sync, it literally fails to parse some ports (via sync or portindex). This is likely MacPorts issue, not an issue with your ports or port groups. Something was messed up not too long ago, since three ports fail to parse on powerpc now (for quite some time), throwing errors which look similar.

With ncurses, to make reliable judgement on what goes wrong I need to make through portindex at least once (is it trivial later on, but first index is 30k+ ports, and it eventually frozen up, I had to quit, and now need to do it again). But I do not think MacPorts master can pull in ncurses-dev[el]. And I use a branch which does not have patches to portfiles from my side.

I do not really know how 3 repos work together, and seems you implemented some way to pick portgroups from outside a repo. But honestly I do not know what exactly happens now, since I just applied your patches without reading the code :)

I think it will be easier to make a branch for MP-Linux in my repo, cherry-pick your fixes and PGs and then use that as an overlay with sources. I will obviously need to add fix-ups for riscv too.

Do you think more or less the same gonna work on BSD by the way? I am not a fan on Linux, I am just temporarily forced to used it on riscv, since apparently OpenBSD lacks some hardware drivers and other two won’t even boot. But ideally I would want to use NetBSD or OpenBSD – with MacPorts.

[RJVB]

On Thursday August 08 2024 10:29:19 Sergey Fedorov wrote:

I do not really know how 3 repos work together, and seems you implemented some way to pick portgroups from outside a repo.

Not from outside a repo. The stock way has always been that PGs are loaded from the default repo first so you could override ports but not PGs. All my patch does is to modify the order in which directories are search for PGs, but they still have to be listed as sources in sources.conf .

Do you think more or less the same gonna work on BSD by the way?

It worked for me before on FreeBSD so there is no reason it won't again. IIRC FreeBSD still has some form of support BTW.

since apparently OpenBSD lacks some hardware drivers

That's exactly one of the main reasons why I'm no longer bothering with *BSD.

There's also the small detail of file watching. On *BSD as on Darwin that's done with kqueue events, and you can only have a very limited number of watchers (256 last I checked). KDE is designed on Linux where the inotify mechanism allows arbitrary numbers of such watchers, so code tends to set watchers on all files in a directory rather than on the directory itself. KDevelop is a good example of why that's not a good idea: with bigger projects it not only fail to detect changes to many if not most of their files but it also causes a significant CPU penalty from what I recall. I did patch the code so it sets watchers only on project (sub)dirs and then scans those for changes (or something like that). That works but upstream was never interested in incorporating it.

[barracuda156]

@RJVB By the way, what can I do about this? ncurses needs csh to build, and csh for riscv needs libc6 version way higher than I have, and I cannot upgrade it, since that gonna break something else.

sh-5.1# dpkg -i /home/pine64/Downloads/csh_20240808-1_riscv64.deb 
(Reading database ... 138117 files and directories currently installed.)
Preparing to unpack .../csh_20240808-1_riscv64.deb ...
Unpacking csh (20240808-1) over (20240808-1) ...
dpkg: dependency problems prevent configuration of csh:
 csh depends on libc6 (>= 2.38); however:
  Version of libc6 on system is 2.35-r0.6.

dpkg: error processing package csh (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 csh

[RJVB]

On Friday August 09 2024 12:04:46 Sergey Fedorov wrote:

ncurses needs csh to build

It does??

You could try installing tcsh (one way or another), and then make csh a symlink to it. I use tcsh as my shell so I can vouch that it works (though not that it will satisfy the ncurses build).

Building the deb package you found from source would be an alternative option

[barracuda156]

On Friday August 09 2024 12:04:46 Sergey Fedorov wrote: ncurses needs csh to build It does?? You could try installing tcsh (one way or another), and then make csh a symlink to it. I use tcsh as my shell so I can vouch that it works (though not that it will satisfy the ncurses build). Building the deb package you found from source would be an alternative option

csh is pulled in by save_configure_cmd PG :)

tcsh has the same problem, though I perhaps can install it from pkgsrc and symlink that…

[RJVB]

csh is pulled in by save_configure_cmd PG :)

Ahhh, hold on.

You do have a system "bash"?

[barracuda156]

csh is pulled in by save_configure_cmd PG :) Ahhh, hold on. You do have a system "bash"?

Yeah, that is there. tcsh fails to install btw: https://github.com/tcsh-org/tcsh/issues/111