Package Details: yosys-git 0.41+111.r13563.a84e4f44f-1

Git Clone URL: https://aur.archlinux.org/yosys-git.git (read-only, click to copy)
Package Base: yosys-git
Description: A framework for RTL synthesis
Upstream URL: https://yosyshq.net/yosys/
Keywords: fpga
Licenses: custom:ISC
Conflicts: yosys
Provides: yosys
Submitter: sebo
Maintainer: thasti
Last Packager: thasti
Votes: 18
Popularity: 0.21
First Submitted: 2015-10-05 19:00 (UTC)
Last Updated: 2024-05-31 09:13 (UTC)

Dependencies (11)

Required by (19)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

xiretza commented on 2020-10-20 06:26 (UTC)

Sorry to bug you again, but could you also switch to a versioned provides (provides=("yosys=$pkgver"))?

thasti commented on 2020-10-19 18:07 (UTC)

Absolutely. I'm test-building this and will push it here soon.

xiretza commented on 2020-10-19 15:59 (UTC)

Hey, would you be open to adding upstream's YOSYS_VER to $pkgver? Something like this:

pkgver() {
    cd "${srcdir}/yosys"
    printf "%s.r%s.%s" "$(make echo-yosys-ver)" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

Resulting in e.g. 0.9+3624.r10271.ac0bd2ff. Combined with provides=("yosys=$pkgver"), this would allow other packages to specify a minimum required yosys revision, e.g. depends=('yosys>=0.9+3468'), which is sometimes necessary due to the infrequency of upstream releases.

thasti commented on 2020-09-30 05:40 (UTC)

I confirm. A recent change in the upstream makefile requires new flags to steer the python installation. I'm testing a fix and will be pushing it here soon.

The breaking upstream commit is 9266d20afc7f3571ffee5edc27afe19dc54bb356.

kbeckmann commented on 2020-09-29 22:17 (UTC) (edited on 2020-09-30 06:56 (UTC) by kbeckmann)

Edit: This issue is now fixed upstream!

I'm not able to build this anymore. I am getting the following error (tried building inside a clean docker):

mkdir: cannot create directory ‘/usr/lib/python3.8/site-packages/pyosys’: Permission denied

Trying to figure out which change that broke it, as I was able to build just fine a few weeks ago, but I haven't found it yet.

Edit: Seems to be caused by the commit e8c9e541a735894a974aaebfb88dfaa9aa3e0f31

ignilux commented on 2020-05-19 23:35 (UTC)

Well, after a couple of hours down the pwmconfig / lm_sensors rabbit hole, it looks like it was indeed a thermal issue. In the end I wound up applying fresh thermal paste and cleaning out the fans, closing everything but the single terminal running the build, and manually setting all fans to max. The CPU somehow STILL managed to get up to 80+ C during the process. Looks like I have some more investigating to do, but the build did succeed.

Anyway, thanks for helping me troubleshoot!

thasti commented on 2020-05-19 16:41 (UTC)

Okay, I'm running a similar setup here, so the amount of RAM appears not to be the issue. Normally efficient CPU usage is a good thing, and other processes that need CPU time should still receive it. One option you could explore is reducing the number of utilized CPUs (configured in /etc/makepkg.conf using MAKEFLAGS=jX, at least on Arch Linux).

Given that I don't see how software could cause a full reboot otherwise, can you rule out a thermal problem? Watching lm-sensors might be helpful here. I have no other good ideas how to get more specific debug output for your problem, at least nothing specific to yosys/abc comes to mind.

ignilux commented on 2020-05-19 16:33 (UTC)

Hi thasti, thanks for the quick reply. I'm running a Core i7 with 8 GB RAM, and an 8.8 GB swap partition located on the same SSD as the filesystem. It seemed like a reasonable explanation, though, so I went ahead and tried the build while monitoring htop. Memory usage never exceeded about 3.7 / 8 GB, and at the time of the crash it was down around 2.4 GB.

What I did find surprising was that all four physical and all four logical cores were pegged at 100% usage for the entire process. Could this be a problem, or is the kernel simply dynamically allocating anything unused by other processes to gcc?

thasti commented on 2020-05-19 16:04 (UTC)

Hi ignilux. Is it possible your machine is killing processes due to insufficient RAM being available during the build process? I just tried building the package and had no issues during compilation of abc.

You could try to monitor RAM usage during the build process (using htop or something similar), or perhaps keep an eye on dmesg during this phase of the build (to see if the out-of-memory killer kicks in). Creating and using a swap file might help out in that case - I don't know whether Manjaro uses one by default or not.

ignilux commented on 2020-05-19 15:31 (UTC)

I'm having issues building this from Pamac in a fresh install of Manjaro. Mirrors and package databases are up to date, and the build will consistently fail at the same point. This happens from both the UI and from command line. The failure is in the form of an immediate reboot with no warning or delay, with seemingly nothing wrong once logged back in.

Unfortunately neither journalctl nor the Pamac log seem to have any information that might be helpful, but I did happen to notice that the last few lines printed to the screen are something like:

[94%] abc ... compiling src/misc/zlib
[94%] abc ... compiling src/misc/bzlib

I'd be happy to provide more information if anyone can guide me on how to produce it, and I'd appreciate any and all help I can get.

« First ‹ Previous 1 2 3 4 5 6 Next › Last »