Cool Apps for New Packagers


#127

Thank you, that certainly helped!

Do you know why /usr/local directory is not allowed? That’s where original script installs the “data” directory and driver doesn’t work without it. Maybe there’s some alternative path?


#128

/use/local is for files that are not managed by you package manager.


#129

I think /usr/local is used when a user wants to install software individually, to avoid conflicts with system packages and/or to have a degree of separation. Package managers don’t touch it.


#130

Got it, I’ll try with different paths.

One (hopefully) last question, how do I fix this:

➤ xi mccgdi
Password:
[*] Updating `https://repo.voidlinux.eu/current/musl/x86_64-musl-repodata' ...
x86_64-musl-repodata: 1512KB [avg rate: 111GB/s]
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg kernel-libc-headers-4.9.8_3 (matched by kernel-libc-headers>=0)
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg binutils-2.29.1_3 (matched by binutils>=0)
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg libgcc-7.3.0_3 (matched by libgcc>=0)
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg libstdc++-7.3.0_3 (matched by libstdc++>=0)
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg libstdc++-devel-7.3.0_3 (matched by libstdc++-devel>=0)
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg libgomp-7.3.0_3 (matched by libgomp>=0)
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg gcc-7.3.0_3 (matched by gcc>=0)
CONFLICT: cross-vpkg-dummy-0.25_1 with installed pkg musl-1.1.19_1 (matched by musl>=0)
CONFLICT: musl-1.1.19_1 with cross-vpkg-dummy-0.25_1 in transaction (matched by glibc>=0)
Transaction aborted due to conflicting packages.

If I understand correctly from this issue, it has to do with cross compilation, but I’m building for my host system.

Template:

# Template file for 'mccgdi'
pkgname=mccgdi
version=2.0.10
revision=1
wrksrc=mccgdi-${version}-x86_64
only_for_archs="x86_64 x86_64-musl"
makedepends="cups-filters"
depends="foomatic-db-engine"
short_desc="Panasonic Printer Driver for Linux"
maintainer="Vintodrimmer <vintodrimmer@protonmail.ch>"
license="GPL-2"
homepage="https://panasonic.net/cns/pcc/support/fax/common/table/linuxdriver.html"
distfiles="https://www.psn-web.net/cs/support/fax/common/file/Linux_PrnDriver/Driver_Install_files/mccgdi-2.0.10-x86_64.tar.gz"
checksum=e2532473a3843f859c0207f91483dd4a156a167e5244e7a7fd605578e85163a9

nostrip_files="L_H0JDGCZAZ"

do_install() {
	# create the necessary dirs
	vmkdir usr/lib/cups/filter
	vmkdir usr/share/cups/model/panasonic 755
	vmkdir usr/share/panasonic/printer/data

	# copy libs
	vcopy ./lib/* usr/lib/
	ln -sf L_H0JDJCZAZ.so.1.0.0 $DESTDIS/usr/lib/L_H0JDJCZAZ.so.1
	ln -sf L_H0JDJCZAZ.so.1 $DESTDIS/usr/lib/L_H0JDJCZAZ.so
	ln -sf L_H0JDJCZAZ_2.so.1.0.0 $DESTDIS/usr/lib/L_H0JDJCZAZ_2.so.1
	ln -sf L_H0JDJCZAZ_2.so.1 $DESTDIS/usr/lib/L_H0JDJCZAZ_2.so

	# copy filter
	vcopy ./filter/L_H0JDGCZAZ usr/lib/cups/filter/

	# copy ppds
	vcopy ./ppd/* usr/share/cups/model/panasonic
	
	# copy the data folder
	vcopy ./data/* usr/share/panasonic/printer/data/
}

I compile it with ./xbps-src -f pkg mccgdi and install with xi mccgdi.

EDIT: some relevant output:

=> mccgdi-2.0.10_1: running pre-pkg hook: 04-generate-runtime-deps ...
   SONAME: libpthread.so.0 <-> glibc>=2.26_1
   SONAME: libdl.so.2 <-> glibc>=2.26_1
   SONAME: libstdc++.so.6 <-> libstdc++>=4.4.0_1
   SONAME: libm.so.6 <-> glibc>=2.26_1
   SONAME: libgcc_s.so.1 <-> libgcc>=4.4.0_1
   SONAME: libc.so.6 <-> glibc>=2.26_1

I’m not sure why such dependencies are generated.


Your FTWs (for the wins) and delights in void
#131

You don’t compile the driver from source and the libraries provided in the tarball are built against glibc, not musl libc. So it’s only_for_archs="x86_64". When you try to package it for musl xbps-src tries to find a package which provides glibc and finds it in cross-vpkg-dummy. This causes the error.


#132

That’s unfortunate. Thank you for the answer!


#133

Not exactly a new app, but definitely a packaging issue.

The Vis editor is probably going to change its name, since there is a package with the same name in FreeBSD.

If any of you are using it, you may want to participate in the poll that should decide on the new name.


#134

I’m trying to make a package for scdoc that is currently a dependency for alpha release of sway, but get a strange error:

➤ ./xbps-src pkg scdoc
=> Using `/home/eichhorn/stuff/git/void-packages/hostdir/binpkgs/sway-git-branch' as local repository.
[*] Updating `https://repo.voidlinux.eu/current/musl/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/musl/nonfree/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/nonfree/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/aarch64/x86_64-repodata' ...
ERROR: [reposync] failed to fetch file `https://repo.voidlinux.eu/current/aarch64/x86_64-repodata': Not Found
[*] Updating `https://repo.voidlinux.eu/current/multilib/x86_64-repodata' ...
[*] Updating `https://repo.voidlinux.eu/current/multilib/nonfree/x86_64-repodata' ...
=> scdoc-1.3.3_1: removing autodeps, please wait...
=> scdoc-1.3.3_1: building [gnu-makefile] ...
=> scdoc-1.3.3_1: running do-fetch hook: 00-distfiles ...
=> scdoc-1.3.3_1: running do-extract hook: 00-distfiles ...
=> scdoc-1.3.3_1: extracting distfile(s), please wait...
=> scdoc-1.3.3_1: running post-extract hook: 00-patches ...
=> scdoc-1.3.3_1: running pre-configure hook: 00-gnu-configure-asneeded ...
=> scdoc-1.3.3_1: running pre-configure hook: 01-override-config ...
=> scdoc-1.3.3_1: running pre-configure hook: 02-script-wrapper ...
=> scdoc-1.3.3_1: running pre-build hook: 02-script-wrapper ...
=> scdoc-1.3.3_1: running do_build ...
cc -std=c99 -pedantic -c -o .build/main.o -D_FORTIFY_SOURCE=2 -mtune=generic -march=native -O2 -pipe    -Iinclude src/main.c
cc -std=c99 -pedantic -c -o .build/string.o -D_FORTIFY_SOURCE=2 -mtune=generic -march=native -O2 -pipe    -Iinclude src/string.c
cc -std=c99 -pedantic -c -o .build/utf8_chsize.o -D_FORTIFY_SOURCE=2 -mtune=generic -march=native -O2 -pipe    -Iinclude src/utf8_chsize.c
cc -std=c99 -pedantic -c -o .build/utf8_decode.o -D_FORTIFY_SOURCE=2 -mtune=generic -march=native -O2 -pipe    -Iinclude src/utf8_decode.c
src/main.c: In function 'output_scdoc_preamble':
src/main.c:547:49: error: expected ')' before 'VERSION'
  fprintf(p->output, ".\\\" Generated by scdoc " VERSION "\n");
                                                 ^~~~~~~
make: *** [Makefile:27: .build/main.o] Error 1
make: *** Waiting for unfinished jobs....
=> ERROR: scdoc-1.3.3_1: do_build: '${make_cmd} CC="$CC" CXX="$CXX" LD="$LD" AR="$AR" RANLIB="$RANLIB" CPP="$CPP" AS="$AS" OBJDUMP="$OBJDUMP" CFLAGS="$CFLAGS" LDFLAGS="$LDFLAGS" ${makejobs} ${make_build_args} ${make_build_target}' exited with 2
=> ERROR:   in do_build() at common/build-style/gnu-makefile.sh:9

Can you help me, please? It uses Makefile and Readme instructs to run make and make install, so I assume that the right build_style is “gnu-makefile”, but may be wrong.

Here’s the current template:

# Template file for 'scdoc'
pkgname=scdoc
version=1.3.3
revision=1
build_style=gnu-makefile
short_desc="A simple man page generator written for POSIX systems written in C99"
maintainer=""
license="custom"
homepage="https://git.sr.ht/~sircmpwn/scdoc/"
distfiles="https://git.sr.ht/~sircmpwn/scdoc/snapshot/scdoc-${version}.tar.xz"
checksum=b2f1d7e0d82f87e2490c2c2477396d65710b5f4bb4b6b08428c8d4757fd66ef6

#135

Yep. the gnu-makefile build_style does override the CFLAGS that do get defined in the Makefile.
Add smth like

pre_build() {
    sed -i -e 's/^CFLAGS=/override CFLAGS+=/g' Makefile
    sed -i -e 's/^LDFLAGS=/override LDFLAGS+=/g' Makefile
}

You also could just add make_build_args="-DVERSION=${version}"


(maxice8 alter) #136

There is no need, https://github.com/voidlinux/void-packages/pull/14333