Package Details: bsdmainutils 12.1.7-1

Git Clone URL: (read-only, click to copy)
Package Base: bsdmainutils
Description: Some BSD-style programs including ncal and lorder.
Upstream URL:
Licenses: GPL
Submitter: None
Maintainer: zancarius
Last Packager: zancarius
Votes: 30
Popularity: 0.020012
First Submitted: 2011-04-29 15:21
Last Updated: 2021-02-14 21:41

Latest Comments

1 2 Next › Last »

zancarius commented on 2017-12-11 17:47

I caught a comment late last night that doesn't appear to be on here anymore (not sure if it was deleted?). It was posted by a French user who shared the following error during build (error message is posted below as it was originally submitted to me):

Le patch debian/patches/fix-big-1stweek.patch est maintenant au sommet
patching file usr.bin/ncal/Makefile
patching file usr.bin/ncal/Makefile
cc -include ../../freebsd.h  -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -fno-plt -c -o calendar.o calendar.c
calendar.c:38:10: erreur fatale: bsd/stdlib.h : Aucun fichier ou
dossier de ce type
 #include <bsd/stdlib.h>
compilation terminée.
make[1]: *** [../../ calendar.o] Error 1
make: *** [Makefile:11: all] Error 2

I'm pretty sure I missed a dependency required for bsdmainutils, both build and possibly runtime, and have corrected that in the latest pkgrel. If you're receiving a similar error regarding the inclusion of bsd/stdlib.h, that would be why (libbsd needs to be installed).

I would like to thank the user who submitted this error report. Because the original post is no longer visible below, and because I don't know if the submitter deleted it themselves, I'm reluctant to thank them directly for privacy reasons. If they post again, I'll update this comment.

zancarius commented on 2017-11-04 01:19

Thanks for reporting this, Alfredo.

Turns out my first comment was wrong. I expected that was probably the case as I made it in haste and hadn't taken the time to examine the situation closely.

The build issues reported were probably related to (recent?) changes in ncurses. It appears that the symbols upstream expects in ncurses may have been split out into libtinfo, so adding -ltinfo to ncal's Makefile was all that was needed. quilt is now require for building because stateful patch management is necessary to apply everything cleanly. The previous incantation of this package applied the patches manually which worked for a while, so I'm hoping by following Debian's build process a bit more closely, it'll resolve future issues as well.

I'm mostly adding this comment in case anyone runs into this or similar issues in the future on other non-Debian platforms. I can't guarantee this assessment is correct, but the symbols have definitely moved into tinfo.

alfredo.ardito commented on 2017-11-03 07:55

Perfect, works after last commit!

zancarius commented on 2017-11-02 21:30

Upstream has released an update as of about a week ago, but the update is also broken for GCC 7.2.0. I'll look into it and see if I can fix it or find a patch (patches are welcome).

In the meantime, I'd suggest skipping this package (or uninstalling it) if you're updating AUR packages such as via yaourt. I can't give an ETA on when it'll be fixed.

zancarius commented on 2017-11-02 21:14

Looks like this may be due to glibc changes. I'll check the upstream package and see if it's been updated and then investigate further.

alfredo.ardito commented on 2017-11-02 21:10

Error building. Got this error:
ncal.o: In function `highlight':
ncal.c:(.text+0x9ec): undefined reference to `tgetent'
ncal.c:(.text+0xa14): undefined reference to `tgetstr'
ncal.c:(.text+0xa2b): undefined reference to `tgetstr'
collect2: error: ld returned 1 exit status
make[1]: *** [../../ ncal] Error 1
make: *** [Makefile:11: all] Error 2
==> ERROR: A failure occurred in build().
==> ERROR: Makepkg was unable to build bsdmainutils.
==> Restart building bsdmainutils ? [y/N]
==> -------------------------------------

zancarius commented on 2017-06-12 22:47

I changed the architecture to "any" so it matches upstream. It should build now without manual intervention. There's a new version I need to update the package to (9.0.12), but I'll probably get to that later tonight.

The patch warnings shouldn't be an issue. Those are distributed upstream, so if it causes a problem, the Ubuntu maintainers would be the ones to get in touch with (it'd be a bug). If not, then there's nothing to worry about! :)

alkaline commented on 2017-06-09 11:26

I manually added "armv7h" to PKGBUILD and was able to built and install the package.
> makepkg -si

Everything seems ok, though there were a couple of lines in the log that look odd. Don't know if relevant, e.g.:

patching file usr.bin/column/column.c
Hunk #1 succeeded at 76 (offset -3 lines).
Hunk #2 FAILED at 100.
Hunk #3 succeeded at 120 (offset -6 lines).
Hunk #4 succeeded at 294 (offset -37 lines).
1 out of 4 hunks FAILED -- saving rejects to file usr.bin/column/column.c.rej
patching file usr.bin/column/column.1
Hunk #1 FAILED at 40.
Hunk #3 FAILED at 80.
2 out of 3 hunks FAILED -- saving rejects to file usr.bin/column/column.1.rej
patching file usr.bin/column/column.c

zancarius commented on 2017-06-08 17:16

I'm somewhat reluctant to add architectures I don't have access to, but it also appears that upstream has it tagged as "any."

Have you successfully built this package using either `makepkg -A` (to ignore the arch) or by manually adding "armv7h" to the `arch` array?

alkaline commented on 2017-06-08 12:05

Can you please support more architectures, e.g. 'armv7h'?