Development
Notes and stuff related to software development.
Wednesday, June 16, 2021 6:19 AM
Ran into an error like the following when trying to build etcd as a CentOS 7 package:
go: github.com/prometheus/client_golang@v1.0.0 requires
github.com/prometheus/common@v0.4.1 requires
github.com/prometheus/procfs@v0.0.0-20181005140218-185b4288413d: invalid version: git fetch --unshallow -f origin in /root/go/pkg/mod/cache/vcs/0ab7c7bc964e6f4054247fed3ac8d636309918420efe8a7cabef12d9f9904311: exit status 128:
fatal: git fetch-pack: expected shallow list
or sometimes this:
go: golang.org/x/crypto@v0.0.0-20200622213623-75b288015ac9 requires
golang.org/x/net@v0.0.0-20190404232315-eb5bcb51f2a3 requires
golang.org/x/crypto@v0.0.0-20190308221718-c2843e01d9a2: invalid version: git fetch --unshallow -f origin in /root/go/pkg/mod/cache/vcs/f72f7a6f267d2fe79b1e174efab21a591b07c84ef53364f65b8281fda7000b49: exit status 128:
fatal: git fetch-pack: expected shallow list
The mysterious thing was, the build had previously completed without issue many times, and there were no obvious changes in any of the build elements involved.
This issue does resemble that described in golang GitHub issue #38373; the workaround suggested by the poster involves resolving version references in the go.mod
file. However that did not seem feasible for this build, which indirectly pulls in a large number of golang modules from various git repositories, which would make tracking down any version reference issues a somewhat Herculean task.
It was however possible to resolve the error (as suggested in a comment on the issue) by upgrading the git
package to a more recent one, as the default CentOS 7 version is a very dated 1.8.x (released in 2014 or earlier).
Recent git packages for CentOS 7 can be obtained from the Endpoint repository here: https://packages.endpoint.com/rhel/7/os/x86_64/.
Monday, June 7, 2021 5:51 AM
Ran into this error when trying to build the PostgreSQL documentation as a PDF file on CentOS 8:
$ make postgres-A4.pdf
/usr/bin/xmllint --path . --noout --valid postgres.sgml
/usr/bin/xsltproc --path . --stringparam pg.version '14beta1' --stringparam img.src.path './' --stringparam paper.type A4 -o postgres-A4.fo stylesheet-fo.xsl postgres.sgml
Making portrait pages on A4 paper (210mmx297mm)
/bin/sh ../../../config/missing fop -fo postgres-A4.fo -pdf postgres-A4.pdf
***
ERROR: `fop' is missing on your system.
***
make: *** [Makefile:178: postgres-A4.pdf] Error 1
As with many things, there doesn't appear to be a CentOS package for this (and given recent developments there might never be). However as fop is a Java-based tool, it's simple enough to install locally.
- Download the latest distribution from https://xmlgraphics.apache.org/fop/download.html
- create a directory (say
~/fop/
)
- Extract the following files/directories from the downloard
.tar.gz
file to ~/fop/
:
fop
build/
lib/
Then ensure ~/fop/
is included in the PATH
variable when performing any tasks where it is required.
Note: for the PostgreSQL documentation build, both the top-level source ./configure
and make
(in the doc/
directory) need to be run again so the build system detects the location of fop
.
DISCLAIMER: there is probably a more elegant way of doing this, but the above sufficed for a quick workaround in the heat of the moment.
Friday, January 29, 2021 12:28 AM
I was recently stumped by the following error emitted from deep within a build process:
fd:4: hClose: resource vanished (Broken pipe)
It turned out to be coming from an invocation of pandoc
with the --filter
option, where the filter script was failing due to missing package dependencies (an artefact of the python2
→ python3
transition, aargh).
Tuesday, August 27, 2019 10:25 PM
Recently I had to work with some Python code which needs to be compatible with both the hopefully-soon-to-be-finally-deprecated Python 2.7 and recent 3.x versions.
String handling can be a tricky issue, particularly if the string in question needs to be cast to a Unicode object. Take the following example:
#!/usr/bin/env python
import ipaddress
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
for address in addresses:
print(address)
This does of course fail in Python 3.x with an error like:
Traceback (most recent call last):
File "./python.py", line 5, in
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
NameError: name 'unicode' is not defined
Remove the unicode()
wrapper and it fails in Python 2.x with:
ipaddress.AddressValueError: '192.168.1.0/24' does not appear to be an IPv4 or IPv6 network. Did you pass in a bytes (str in Python 2) instead of a unicode object?
The solution is to use the "six
" compatibility layer and add the following directive, which reassigns unicode()
to a mutually compatible function:
#!/usr/bin/env python
import ipaddress
from six import u as unicode
addresses = list(ipaddress.ip_network(unicode('192.168.1.0/24')));
for address in addresses:
print(address)
Note that the "six
" compatibility layer may need to be installed separately, in RedHat et al via the packages python2x-six
and python3x-six
respectively.
Useful links
Monday, November 17, 2014 5:08 AM
I was setting up a cronjob and it kept failing with the very unhelpful util.c: No such file or directory. After much headscratching it turns out this is a gnuplot error message, meaning it is unable to read from or write to a file (in this case the latter). The file in question is not of course util.c.
Saturday, September 27, 2014 1:42 AM
I was bemused by the below error when attempting to run an Ansible playbook on a new (Linux) server for the first time:
PLAY [someserver] *****************************************************************
GATHERING FACTS ***************************************************************
failed: [someserver] => {"failed": true, "parsed": false}
SUDO-SUCCESS-fdhntaxupgygzrcocwghbosdkgbgguvy
/bin/sh: 1: powershell: not found
This happened with gather_facts set to true. Setting it to false worked around the issue, however I'm pretty sure powershell hasn't been ported to Debian... Ansible version:
$ ansible-playbook --version
ansible-playbook 1.8 (devel ffee9a8fe0) last updated 2014/09/27 14:24:58 (GMT +900)
The actual cause was the absence of python on the target server; this will need to be manually installed before Ansible can be of much use.