Package Details: slrn 1.0.3-4

Git Clone URL: https://aur.archlinux.org/slrn.git (read-only, click to copy)
Package Base: slrn
Description: An open source text-based news client
Upstream URL: http://www.slrn.org/
Licenses: GPL
Submitter: Barthalion
Maintainer: apetresc
Last Packager: benoliver999
Votes: 2
Popularity: 0.000000
First Submitted: 2018-01-05 16:49 (UTC)
Last Updated: 2018-07-13 14:44 (UTC)

Latest Comments

1 2 Next › Last »

rek2 commented on 2022-11-10 01:23 (UTC)

easier to do env SLRN_NO_UU=true makepkg -s

kseistrup commented on 2022-09-11 11:55 (UTC)

@ln0ml Great!

ln0ml commented on 2022-09-11 10:28 (UTC)

@kseistrup, you are right, if you remove the lines:

--with-uulib=/usr/lib/uudeview \
 --with-uuinc=/usr/include/uudeview \
 make UUDEVIEW_LIB="/usr/lib/uudeview/*.o"

It compiles and works fine.

kseistrup commented on 2022-09-11 07:36 (UTC)

@apetresc Does your slrn crash if you compile it without uudeview? I am packaging (and using) the slrn-snapshot* packages and I haven't experienced that. How did you make it crash?

I can't say how many are using uuencoding on today's Usenet. Personally I only read text groups (and the servers my server is peering with don't allow binaries at all).

apetresc commented on 2022-09-11 04:30 (UTC)

Okay, never mind, it's not that simple. The reason the community package hasn't been recompiled is because some of the warnings in its source have been upgraded to errors in the latest GCC, and upstream hasn't touched it since 2004. So it's unlikely this dependency will ever be fixed.

With that in mind, I guess it is reasonable to just build slrn without uuencoding support. Does anyone confidently know how common uuencoding is in today's Usenet? How many problems will this practically cause?

apetresc commented on 2022-09-11 04:17 (UTC)

I adopted this package and hope to fix the build soon :)

Remove the linkage to uudeview as kseistrup suggested would work, but cause crashes at runtime. The issue is simply that uudeview's community package needs to be rebuilt. This has recently been reported here: https://bugs.archlinux.org/task/75290

Once this is resolved things should work again. Please vote for that task if you want to see it fixed :)

kseistrup commented on 2022-03-24 08:37 (UTC)

On 2022-02-07 the uudeview package had

./configure --prefix=/usr --mandir=/usr/share/man

changed to

./configure --prefix=/usr --mandir=/usr/share/man CFLAGS="-ffat-lto-objects"

I assume this is where LTO got into it, and I guess that is where any bug reports should go.

See https://github.com/archlinux/svntogit-community/commit/c1b47c6ed3fcaf5a914520e3d1414c8e771a1995 for details.

kseistrup commented on 2022-03-24 08:20 (UTC)

I maintain another slrn package and it suffers from the same problem.

It seems it is the uudeview stuff that is causing troubles. If I remove the two --with-uu* lines from the PKGBUILD and change

make UUDEVIEW_LIB="/usr/lib/uudeview/*.o"

to just

make

then this package (and my own) will build on my computer.

Retro64XYZ commented on 2022-03-23 19:26 (UTC)

https://pastebin.com/pXqTLt4E

That is the output. It does not build. I can build from source using configure, make, and then make install and it works fine. Using the AUR it errors out as in the pastebin.

kseistrup commented on 2022-03-23 06:33 (UTC)

@Retro64XYZ It looks like a link-time optimization compiler error, not an error that PKGBUILD can mitigate.

What do you mean when you say that “[you are] unable to get the application to work at this time”?