Package Details: fldigi 4.2.06-1

Git Clone URL: https://aur.archlinux.org/fldigi.git (read-only, click to copy)
Package Base: fldigi
Description: Digital Modem Program for Amateur Radio
Upstream URL: http://w1hkj.com
Keywords: ham radio
Licenses: GPL-2.0-or-later
Submitter: Allan
Maintainer: not_anonymous
Last Packager: not_anonymous
Votes: 58
Popularity: 0.079072
First Submitted: 2008-12-19 03:37 (UTC)
Last Updated: 2024-10-15 03:13 (UTC)

Required by (15)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 14 Next › Last »

grandchild commented on 2020-10-22 22:53 (UTC)

you are right, the patch doesn't cleanly apply. and i found out that that is because the lines are fine when the source is first extracted. they only get changed during the build process, by some process that is prefixed with "GUIDE" in the build output. i will try and figure out what that process is, but that's gonna be tomorrow... sleep now. :P

not_anonymous commented on 2020-10-22 22:07 (UTC) (edited on 2020-10-22 22:27 (UTC) by not_anonymous)

Actually that patch is being "rejected" on the latest source.;

a) malformed: i.e. some of the lines begin like this;

\n\iv id=\"toc\">

b) Um...AND the line numbers do not match the source. (Off by one line)

c) finally it is written so to ADD newline characters (which are already there....)

ANYWAYS ...that's why I didn't use it.....Would/could you please check it grandchild ?

grandchild commented on 2020-10-22 21:01 (UTC)

Sorry, but the solution is not to simply conflict with asciidoc. asciidoc is actually an optional make dependency. If it is present, then more things get built.

The solution would either be to apply the patch I made, or to explicitly disable the part that gets built when asciidoc is present. I haven't checked which part that is, and if it has a configure flag to disable it. Maybe it does?

not_anonymous commented on 2020-10-22 20:03 (UTC)

Okey dokey.....made the appropriate change....thanks OM's ...es vy 73

df8oe commented on 2020-10-21 07:47 (UTC) (edited on 2020-10-21 07:48 (UTC) by df8oe)

Thanks for your very fast reactions. I can confirm that "asciidoc" causes the issue. I deinstalled it, after that the build process finished successfully. Then I reinstalled asciidoc. It is a workaround - but it works :)

grandchild commented on 2020-10-20 19:49 (UTC)

Hah, I found it. It fails to compile if you have asciidoc installed!

I guess that technically counts as a problem with this package...

grandchild commented on 2020-10-20 17:16 (UTC)

Alright, in a new Archlinux VM it does compile and work. I will figure out what configure/make does different on my system...

grandchild commented on 2020-10-20 17:00 (UTC)

that this is a java problem surprises me NOT... Hi Hi.

Java? It's not a Java problem. df8oe said something about Javascript, which is irrelevant anyway, since it's an encoding problem in a C++ file.

not_anonymous commented on 2020-10-20 13:59 (UTC) (edited on 2020-10-20 14:09 (UTC) by not_anonymous)

Before I submitted this latest PKGBUILD, I updated my system and then tested both the build and execution of this software WITHOUT ANY PATCHES being applied. i.e. The software package works FB here including the results that the patch supposedly fixes without needing the patch.

SO..; I will spend a couple of days and think through whether this patch should be applied. (And I will go look at Dave's info on what is going on. LOTS of problems, it appears, with other linux distros and Windows.)

For what it is worth; that this is a java problem surprises me NOT... Hi Hi.

P.S.... I'm running jre8 (openjdk) for what it is worth.....hmmm......

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 14 Next › Last »