New package proposal: zpaqfranz

fcorbelli · 2022-04-03 17:10:56

Hello everyone, I would like some feedback on the possibility of submitting a new package, zpaqfranz, which is an updated fork of the archiver with deduplication zpaq

This is the "old" zpaq (alread deployed)
https://aur.archlinux.org/packages/zpaq

and this is my fork
https://github.com/fcorbelli/zpaqfranz

Could it be interesting, for the archlinux community, or... not?

Today's Makefile is for UNIX machines (and writes by default in /usr/local/bin, which is highly discouraged for archlinux, so beware!!)

It is not difficult to compile, it has no dependencies, it is made up of a single file, and actually just doing this

g++ -Dunix -O3 -march=native zpaqfranz.cpp -o zpaqfranz -pthread -static

is enough (of course with gcc or "whatever" installed)

I ask for suggestions before starting to study the archlinux "packer"
Thanks for any reply

This is the "very first" PKGBUILD (not tested at all, some help needed, just a draft)

# Maintainer: Franco Corbelli <dottcorbelli@gmail.com>


pkgname=zpaqfranz
pkgdesc='Deduplicating archiver with encryption and paranoid-level tests. Swiss army knife for the serious backup and disaster recovery manager. zpaq fork'
url='https://github.com/fcorbelli/zpaqfranz'
pkgver=54.13


arch=(i686 x86_64)
license=(custom MIT)

source=(https://downgit.github.io/#/home?url=https://github.com/fcorbelli/zpaqfranz/blob/main/zpaqfranz.cpp)
sha512sums=('737b1b984a1baf5cc49ca30cfdc847878c3d750a1e41cec3f877edc3137ae992569e70dac89aa8d9d8e7de67231e3eaf6a3b977086f301bd4374ee99bfb5aab5')

build()
{
	cd "$srcdir"

	msg 'Building zpaqfranz'
	g++ -Dunix -O3 -march=native zpaqfranz.cpp -o zpaqfranz -pthread -static
}


package()
{
	install -Dm 755 zpaqfranz       "$pkgdir/usr/bin/zpaqfranz"
}

Trilby · 2022-04-03 17:28:39

fcorbelli wrote:

Today's Makefile is for UNIX machines (and writes by default in /usr/local/bin, which is highly discouraged for archlinux, so beware!!

If it's your makefile, and you know it's wrong, why haven't you fixed it. PREFIX should be set conditionally rather than unconditionally.

FabioLolix · 2022-04-03 20:47:11

Revisioned pkgbuild (to note that the zpaq pkgbuild isn't that great)

# Maintainer: Franco Corbelli <dottcorbelli@gmail.com>
pkgname=zpaqfranz
pkgver=54_12
pkgrel=1
pkgdesc='Deduplicating archiver with encryption and paranoid-level tests. Swiss army knife for the serious backup and disaster recovery manager. zpaq fork'
arch=(i686 x86_64)
url='https://github.com/fcorbelli/zpaqfranz'
license=(MIT)
source=("${pkgname}-${pkgver}.tar.gz::https://github.com/fcorbelli/zpaqfranz/archive/refs/tags/${pkgver}.tar.gz")
sha512sums=('5874c30a63e2ee7a964e9526adbfcac102ca0c6cff016f1a84cb72842eb8b63f16e583b1fdb1b5e3c472ac0952256eb247f0d5023028f12b817015199543e1aa')
build() {
cd "${srcdir}/${pkgname}-${pkgver}"
make
}
package() {
cd "${srcdir}/${pkgname}-${pkgver}"
install -Dm 755 zpaqfranz "$pkgdir/usr/bin/zpaqfranz"
#make DESTDIR="${pkgdir}" install
#install -D LICENSE -t "${pkgdir}/usr/share/licenses/${pkgname}"
}

The original zpaq software also have a library, header, manpage and license which your fork don't have or don't produce,

looking at the git history https://github.com/fcorbelli/zpaqfranz/ … ranch=main we can see that you uploaded cherry picked files instead of uploading the whole source from the last archive or even better forked from https://github.com/zpaq/zpaq which would preserve the git history

fcorbelli · 2022-04-04 11:14:09

Trilby wrote:

fcorbelli wrote:
Today's Makefile is for UNIX machines (and writes by default in /usr/local/bin, which is highly discouraged for archlinux, so beware!!
If it's your makefile, and you know it's wrong, why haven't you fixed it. PREFIX should be set conditionally rather than unconditionally.

My normal everyday systems are UNIX (FreeBSD and Solaris) and I don't use Makefile at all.
I discovered, just yesterday, that on archlinux it is highly discouraged to use local (despite everything I have read a little documentation on arch's PKG, before writing on this forum)
I will try to improve the Makefile for archlinux users as well

It is not so easy to make a "universal" one, there are many different systems, each with its own peculiarities

Last edited by fcorbelli (2022-04-04 11:28:51)

fcorbelli · 2022-04-04 11:20:21

FabioLolix wrote:

Revisioned pkgbuild (to note that the zpaq pkgbuild isn't that great)
(...)
The original zpaq software also have a library, header, manpage and license which your fork don't have or don't produce,

It is true, no library, no nothing

looking at the git history https://github.com/fcorbelli/zpaqfranz/ … ranch=main we can see that you uploaded cherry picked files instead of uploading the whole source from the last archive or even better forked from https://github.com/zpaq/zpaq which would preserve the git history

My fork is purposely composed of a single source file (actually two for Win64, if you want hardware acceleration for BLAKE3)

I spent a lot of time and effort just to get to this point, otherwise it is almost impossible to compile on "strange" systems such as vSphere or Qnap NAS
No make necessary, at all

Regarding the PKG, browsing with other packages already made, I saw that it seems possible to download directly from github

And, in fact, your template just does it
Some questions for a newbie on archlinux

1) Is this a "recommended" policy (by the arch community) or is a "static" link (a non-dynamic URL) preferred?
2) Is a Makefile mandatory or not (I do not need some dependency on make, cmake or whatever)?
3) Is -static disapproved on arch (it is, on macos for example)?
4) Is -check really necessary? (https://wiki.archlinux.org/title/creating_packages)?

My "current" PKGBUILD is this one (to be checked, of course)

# Maintainer: Franco Corbelli <dottcorbelli@gmail.com>

pkgname=zpaqfranz
pkgver=54.13
pkgrel=1
pkgdesc='Deduplicating archiver with encryption and paranoid-level tests. Swiss army knife for the serious backup and disaster recovery manager. zpaq fork'
arch=(i686 x86_64)
url='https://github.com/fcorbelli/zpaqfranz'
license=(MIT)
source=("${pkgname}-${pkgver}.tar.gz::https://github.com/fcorbelli/zpaqfranz/archive/refs/tags/${pkgver}.tar.gz")
sha512sums=('80b262536916f8b597f64f41c710e6116cf324689e602ea2b65ee86b290ab4784f4a4d03886cd66be4a77b03fc17c67852e411b36c89c451ad38683464dc3ab1')

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  g++ -Dunix -O3 -march=native zpaqfranz.cpp -o zpaqfranz -pthread -static
}

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  install -Dm 755 zpaqfranz  "$pkgdir/usr/bin/zpaqfranz"
  install -D COPYING -t "${pkgdir}/usr/share/licenses/${pkgname}"
}

And...

[archlinux@archlinux2022 zarch]$ namcap *.zst
zpaqfranz W: ELF file ('usr/bin/zpaqfranz') lacks FULL RELRO, check LDFLAGS.
zpaqfranz W: ELF file ('usr/bin/zpaqfranz') lacks PIE.

Two warnings seems to be related to "hardening" ELF, but zpaqfranz is not a demon, therefore I do not think this should be a big deal

5) Are they really necessary?

Thanks for the tips!

Last edited by fcorbelli (2022-04-04 13:29:07)

fcorbelli · 2022-08-16 14:02:35

As a newbie to archlinux, I would need help on how to compile a normal C ++ file with the right options to avoid these warnings.
Thanks

[archlinux@archlinux2022 zarch]$ namcap *.zst
zpaqfranz W: ELF file ('usr/bin/zpaqfranz') lacks FULL RELRO, check LDFLAGS.
zpaqfranz W: ELF file ('usr/bin/zpaqfranz') lacks PIE.

Trilby · 2022-08-16 14:55:35

fcorbelli wrote:

I discovered, just yesterday, that on archlinux it is highly discouraged to use local

It's highly discouraged to hardcode any such path for any OS. This is not a linux / archlinux idea - this is just good / bad practice for software development on any platform.

fcorbelli wrote:

It is not so easy to make a "universal" one, there are many different systems, each with its own peculiarities

Nonsense. Those "peculiarities" are all covered by writing a standards-conforming makefile that uses the relevant environment variables.

Don't hardcode paths. Don't explicitly override settings (conditionally set, or append). Use implicit rules where possible. E.g.,

CXX      ?= g++
CPPFLAGS += -Dunix
PREFIX   ?= /usr/local
LDLIBS   += -pthread

all: zpaqfranz

install: zpaqfranz
	install -Dm755 zpaqfranz $(DESTDIR)$(PREFIX)/bin/zpaqfranz

clean:
	rm -f zpaqfranz

check: zpaqfranz
	rm archive.zpaq
	./zpaqfranz a archive.zpaq zpaqfranz.cpp
	./zpaqfranz t archive.zpaq -verify
	rm archive.zpaq

Last edited by Trilby (2022-08-16 15:04:05)

fcorbelli · 2022-08-16 15:31:32

I wish the "world" were that easy, but it isn't
Not "everything" works like a Linux system, and neither like a Unix one, and there are also several (mainly two) Unixes, each with its own "distros" (obviously they are not distros)
Then there are the derived systems (Mac), then the modified ones (NAS), then those that go back to Centos 3.9 32-bit (ESXi), then there is Android ... then ... then ...

The paths are the least of the problems, the most trivial to solve. These are trivial refinements to do AFTER the system works

CXX=g++
CPPFLAGS+=-Dunix
CXXFLAGS=-O3 -march=native
PREFIX=/usr/local
BINDIR=$(PREFIX)/bin

all: zpaqfranz

zpaqfranz:
        $(CXX) $(CPPFLAGS) $(CXXFLAGS) zpaqfranz.cpp  -o $@ -pthread -static

install: zpaqfranz
        install -m 0755 -d $(DESTDIR)$(BINDIR)
        install -m 0755 zpaqfranz $(DESTDIR)$(BINDIR)

clean:
        rm -f zpaqfranz

Anyway my question is this: what are the compilation and linking parameters to avoid these warnings?
I tried the ones for fedora and red hat, but the help of an arch expert would save me a lot of time
I don't think I'm, after all, the very first to compile a C ++ program on Arch

zpaqfranz W: ELF file ('usr/bin/zpaqfranz') lacks FULL RELRO, check LDFLAGS.
zpaqfranz W: ELF file ('usr/bin/zpaqfranz') lacks PIE.

Last edited by fcorbelli (2022-08-16 15:35:23)

Scimmia · 2022-08-16 15:38:32

The warnings are because of exactly what Trilby told you. You're unconditionally overriding things you shouldn't be. Hard-coding march=native is a terrible idea all around, even if that's not causing the warnings.

Last edited by Scimmia (2022-08-16 15:39:41)

fcorbelli · 2022-08-16 15:53:20

One step ahead: arch does not "like" statically linked executables

g++ -Dlinux -g -O3 -Wl,-z,relro,-z,now -o zpaqfranz zpaqfranz.cpp -pthread -s
=> full RELRO e PIE

g++ -Dlinux -g -O3 -Wl,-z,relro,-z,now -o zpaqfranz zpaqfranz.cpp -pthread -static -s
=> partial RELRO, no PIE
do not "like" -static

loqs · 2022-08-16 16:06:44

  g++ -Dunix $CPPFLAGS $CXXFLAGS $LDFLAGS zpaqfranz.cpp -o zpaqfranz -pthread

fcorbelli · 2022-08-16 16:07:37

Scimmia wrote:

The warnings are because of exactly what Trilby told you. You're unconditionally overriding things you shouldn't be. Hard-coding march=native is a terrible idea all around, even if that's not causing the warnings.

In fact no, no because there is a JIT compiler inside the source, that translate ZPAQL opcodes into x86 (SSE) machine-language (on amd64 or i386 with SSE)
On "other things" a -DNOJIT is mandatory (but, AFAIK, arch is about 100% amd64-based)

The answer seems:
arch does not like statically linked executables at all
I am not sure why (maybe a Red Hat heritage?)

Anyway this is the "current" that seems to work [in the sense prepare without warnings] (some refactoring needed)

# Maintainer: Franco Corbelli <franco su francocorbelli.com>

pkgname=zpaqfranz
pkgver=55.10
pkgrel=1
pkgdesc='Deduplicating archiver with encryption and paranoid-level tests. Swiss army knife f
or the serious backup and disaster recovery manager. zpaq fork'
arch=(x86_64)
depends=('gcc-libs')
url='https://github.com/fcorbelli/zpaqfranz'
license=(MIT)
source=("${pkgname}-${pkgver}.tar.gz::https://github.com/fcorbelli/zpaqfranz/archive/refs/ta
gs/${pkgver}.tar.gz")
sha512sums=('570902fa81e9d0757ca08fb34afaba145c10b0f8c44ff33c0016a82ce1d0d4341eac092c8064850
4115b1e543447c5859668f89e777510b62389962e76b9440e')

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
g++ -Dlinux -g -O3 -Wl,-z,relro,-z,now -o zpaqfranz zpaqfranz.cpp -pthread -static-libstdc++ -s

}

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  install -Dm 755 zpaqfranz  "$pkgdir/usr/bin/zpaqfranz"
  install -D COPYING -t "${pkgdir}/usr/share/licenses/${pkgname}"
}

Last edited by fcorbelli (2022-08-16 16:10:54)

loqs · 2022-08-16 16:20:50

fcorbelli wrote:

Scimmia wrote:
The warnings are because of exactly what Trilby told you. You're unconditionally overriding things you shouldn't be. Hard-coding march=native is a terrible idea all around, even if that's not causing the warnings.
In fact no, no because there is a JIT compiler inside the source, that translate ZPAQL opcodes into x86 (SSE) machine-language (on amd64 or i386 with SSE)
On "other things" a -DNOJIT is mandatory (but, AFAIK, arch is about 100% amd64-based)

Why with run time CPU feature detection do you need march=native?

    p=(U8*)mmap(0, newsize, PROT_READ|PROT_WRITE|PROT_EXEC,
                MAP_PRIVATE|MAP_ANON, -1, 0);

Writeable and executable memory segment. Why are you concerned about PIE / RELRO when the executable can rewrite itself?

fcorbelli · 2022-08-16 16:23:45

loqs wrote:

Why with run time CPU feature detection do you need march=native?

Not always needed, on some kind of older FreeBSD

Why are you concerned about PIE / RELRO when the executable can rewrite itself?

I am not, at all

It is namcap that seems to trigger warning for statically-linked executables, with PIE and RELRO too
Therefore the question is (doing a package for arch)
can I ignore without mercy namcap's warnings? or
is better to NOT make a static file?

As I have said several times I have not been an arch-fedora-red hat developer for years, I am not used to these "peculiarities"

Last edited by fcorbelli (2022-08-16 16:26:40)

loqs · 2022-08-16 16:32:02

Have you encountered any issues with a none static binary produced using Arch's standard flags? (As in post #11)

Trilby · 2022-08-16 16:34:01

fcorbelli wrote:

arch does not like statically linked executables at all

More nonsense. I suspect you are now just trolling as you refuse to accept any sound advice and seem to think you're the first person to every try to write cross-platform code when clearly you don't know what you are doing. Ignorance is fine, but not when it's paired with an arrogance that prevents you from learning the proper approaches while you instead just assume other systems are faulty rather than taking a moment to consider that your code is not perfect.

I also find it ironic that you are throwing around so much disdain for arch linux when your only purpose here is to push your own software into this community. How about this: if any arch user wants your software, let them package it as they're more likely to be open to doing so properly.

Last edited by Trilby (2022-08-16 16:36:36)

fcorbelli · 2022-08-16 16:37:26

loqs wrote:

Have you encountered any issues with a none static binary produced using Arch's standard flags? (As in post #11)

I have no idea, a bit of (euphemism for several) testing is needed

BTW it is "normal" that the packager write (into .BUILDINFO) all the packages of my system?
Is better to start with an "empty" arch (to get the smaller package)?

And is it possible to DO NOT use pkgrel, to get a 55.10 package, instead of 55.10-1 (or something)?
Thank you very much

format = 2
pkgname = zpaqfranz
pkgbase = zpaqfranz
pkgver = 55.10-1
pkgarch = x86_64
pkgbuild_sha256sum = 87a400e6bc31fe291ae35753891b682890a44b3d1b4b8da3331e866aebe5e76b
packager = Unknown Packager
builddate = 1660665765
builddir = /tmp/zarch
startdir = /tmp/zarch
buildtool = makepkg
buildtoolver = 6.0.1
buildenv = !distcc
buildenv = color
buildenv = !ccache
buildenv = check
buildenv = !sign
options = strip
options = docs
options = !libtool
options = !staticlibs
options = emptydirs
options = zipman
options = purge
options = !debug
options = !lto
installed = acl-2.3.1-2-x86_64
installed = archlinux-keyring-20220224-1-any
installed = argon2-20190702-4-x86_64
installed = attr-2.5.1-2-x86_64
installed = audit-3.0.7-1-x86_64
installed = autoconf-2.71-1-any
installed = automake-1.16.5-1-any
installed = base-2-2-any
installed = bash-5.1.016-1-x86_64
installed = binutils-2.38-3-x86_64
installed = bison-3.8.2-3-x86_64
installed = bluez-libs-5.64-2-x86_64
installed = brotli-1.0.9-7-x86_64
installed = bzip2-1.0.8-4-x86_64
installed = ca-certificates-20210603-1-any
installed = ca-certificates-mozilla-3.77-1-x86_64
installed = ca-certificates-utils-20210603-1-any
installed = checksec-2.6.0-1-any
installed = coreutils-9.0-2-x86_64
installed = cryptsetup-2.4.3-2-x86_64
installed = curl-7.82.0-2-x86_64
installed = db-5.3.28-5-x86_64
installed = dbus-1.14.0-1-x86_64
installed = device-mapper-2.03.15-1-x86_64
installed = diffutils-3.8-1-x86_64
installed = dnssec-anchors-20190629-3-any
installed = dos2unix-7.4.2-1-x86_64
installed = e2fsprogs-1.46.5-3-x86_64
installed = elfutils-0.186-5-x86_64
installed = expat-2.4.7-1-x86_64
installed = fakeroot-1.28-1-x86_64
installed = file-5.41-1-x86_64
installed = filesystem-2021.12.07-1-x86_64
installed = findutils-4.9.0-1-x86_64
installed = flex-2.6.4-3-x86_64
installed = gawk-5.1.1-1-x86_64
installed = gc-8.2.0-3-x86_64
installed = gcc-11.2.0-4-x86_64
installed = gcc-libs-11.2.0-4-x86_64
installed = gdbm-1.23-1-x86_64
installed = gettext-0.21-2-x86_64
installed = git-2.35.1-1-x86_64
installed = glib2-2.72.0-1-x86_64
installed = glibc-2.35-3-x86_64
installed = gmp-6.2.1-1-x86_64
installed = gnupg-2.2.32-2-x86_64
installed = gnutls-3.7.4-1-x86_64
installed = gpgme-1.17.1-1-x86_64
installed = gpm-1.20.7.r38.ge82d1a6-4-x86_64
installed = grep-3.7-1-x86_64
installed = groff-1.22.4-7-x86_64
installed = grub-2:2.06-5-x86_64
installed = guile-2.2.7-2-x86_64
installed = gzip-1.11-1-x86_64
installed = hwdata-0.357-1-any
installed = iana-etc-20220205-1-any
installed = icu-70.1-1-x86_64
installed = inetutils-2.2-1-x86_64
installed = iproute2-5.17.0-1-x86_64
installed = iptables-1:1.8.7-1-x86_64
installed = iputils-20211215-1-x86_64
installed = jansson-2.14-1-x86_64
installed = json-c-0.15-3-x86_64
installed = kbd-2.4.0-2-x86_64
installed = keyutils-1.6.3-1-x86_64
installed = kmod-29-2-x86_64
installed = krb5-1.19.2-2-x86_64
installed = ldns-1.8.1-1-x86_64
installed = less-1:590-1-x86_64
installed = libarchive-3.6.0-2-x86_64
installed = libassuan-2.5.5-1-x86_64
installed = libcap-2.63-2-x86_64
installed = libcap-ng-0.8.2-7-x86_64
installed = libcroco-0.6.13-2-x86_64
installed = libdaemon-0.14-5-x86_64
installed = libedit-20210910_3.1-1-x86_64
installed = libelf-0.186-5-x86_64
installed = libffi-3.4.2-4-x86_64
installed = libgcrypt-1.10.1-1-x86_64
installed = libgpg-error-1.44-1-x86_64
installed = libidn2-2.3.2-1-x86_64
installed = libisl-0.24-4-x86_64
installed = libksba-1.6.0-1-x86_64
installed = libldap-2.6.1-1-x86_64
installed = libmm-glib-1.18.6-1-x86_64
installed = libmnl-1.0.4-3-x86_64
installed = libmpc-1.2.1-2-x86_64
installed = libndp-1.8-1-x86_64
installed = libnetfilter_conntrack-1.0.9-1-x86_64
installed = libnewt-0.52.21-8-x86_64
installed = libnfnetlink-1.0.1-4-x86_64
installed = libnftnl-1.2.1-1-x86_64
installed = libnghttp2-1.47.0-1-x86_64
installed = libnl-3.5.0-3-x86_64
installed = libnm-1.36.4-1-x86_64
installed = libnsl-2.0.0-2-x86_64
installed = libp11-kit-0.24.1-1-x86_64
installed = libpcap-1.10.1-2-x86_64
installed = libpgm-5.3.128-1-x86_64
installed = libpsl-0.21.1-1-x86_64
installed = libsasl-2.1.27-3-x86_64
installed = libseccomp-2.5.3-3-x86_64
installed = libsecret-0.20.5-1-x86_64
installed = libsodium-1.0.18-2-x86_64
installed = libssh2-1.10.0-1-x86_64
installed = libsysprof-capture-3.44.0-1-x86_64
installed = libtasn1-4.18.0-1-x86_64
installed = libteam-1.31-5-x86_64
installed = libtirpc-1.3.2-1-x86_64
installed = libtool-2.4.7-1-x86_64
installed = libunistring-0.9.10-3-x86_64
installed = libxcrypt-4.4.28-2-x86_64
installed = libxml2-2.9.13-1-x86_64
installed = licenses-20220125-1-any
installed = linux-5.17.1.arch1-1-x86_64
installed = linux-api-headers-5.16.8-1-any
installed = linux-firmware-20220309.cd01f85-1-any
installed = linux-firmware-whence-20220309.cd01f85-1-any
installed = lz4-1:1.9.3-2-x86_64
installed = m4-1.4.19-1-x86_64
installed = make-4.3-3-x86_64
installed = mkinitcpio-31-2-any
installed = mkinitcpio-busybox-1.35.0-1-x86_64
installed = mobile-broadband-provider-info-20220315-1-any
installed = mpfr-4.1.0.p13-2-x86_64
installed = namcap-3.2.10-5-any
installed = ncurses-6.3-2-x86_64
installed = net-tools-2.10-1-x86_64
installed = nettle-3.7.3-1-x86_64
installed = networkmanager-1.36.4-1-x86_64
installed = npth-1.6-3-x86_64
installed = nspr-4.33-1-x86_64
installed = nss-3.77-1-x86_64
installed = openssh-8.9p1-1-x86_64
installed = openssl-1.1.1.n-1-x86_64
installed = p11-kit-0.24.1-1-x86_64
installed = pacman-6.0.1-4-x86_64
installed = pacman-mirrorlist-20220227-1-any
installed = pam-1.5.2-1-x86_64
installed = pambase-20211210-1-any
installed = patch-2.7.6-8-x86_64
installed = pciutils-3.7.0-2-x86_64
installed = pcre-8.45-1-x86_64
installed = pcre2-10.39-1-x86_64
installed = perl-5.34.1-1-x86_64
installed = perl-error-0.17029-3-any
installed = perl-mailtools-2.21-5-any
installed = perl-timedate-2.33-3-any
installed = pinentry-1.2.0-1-x86_64
installed = pkgconf-1.8.0-1-x86_64
installed = popt-1.18-3-x86_64
installed = procps-ng-3.3.17-1-x86_64
installed = psmisc-23.4-1-x86_64
installed = pyalpm-0.10.6-4-x86_64
installed = python-3.10.4-1-x86_64
installed = python-pyelftools-0.28-1-any
installed = readline-8.1.002-1-x86_64
installed = sed-4.8-1-x86_64
installed = shadow-4.11.1-1-x86_64
installed = slang-2.3.2-2-x86_64
installed = sqlite-3.38.2-1-x86_64
installed = sudo-1.9.10-1-x86_64
installed = systemd-250.4-2-x86_64
installed = systemd-libs-250.4-2-x86_64
installed = systemd-sysvcompat-250.4-2-x86_64
installed = tar-1.34-1-x86_64
installed = texinfo-6.8-2-x86_64
installed = tpm2-tss-3.2.0-1-x86_64
installed = tzdata-2022a-1-x86_64
installed = util-linux-2.38-1-x86_64
installed = util-linux-libs-2.38-1-x86_64
installed = vi-1:070224-5-x86_64
installed = which-2.21-5-x86_64
installed = wpa_supplicant-2:2.10-3-x86_64
installed = xz-5.2.5-2-x86_64
installed = zeromq-4.3.4-2-x86_64
installed = zlib-1:1.2.12-1-x86_64
installed = zpaqfranz-54.13-1-x86_64
installed = zstd-1.5.2-3-x86_64

EDIT: please do not answer
The Arch system is perfect, and therefore it will certainly do well in any case
(sarcasm)

Last edited by fcorbelli (2022-08-16 16:48:29)

fcorbelli · 2022-08-16 16:47:24

Trilby wrote:

fcorbelli wrote:
arch does not like statically linked executables at all
More nonsense. I suspect you are now just trolling as you refuse to accept any sound advice and seem to think you're the first person to every try to write cross-platform code when clearly you don't know what you are doing. Ignorance is fine, but not when it's paired with an arrogance that prevents you from learning the proper approaches while you instead just assume other systems are faulty rather than taking a moment to consider that your code is not perfect.
I also find it ironic that you are throwing around so much disdain for arch linux when your only purpose here is to push your own software into this community. How about this: if any arch user wants your software, let them package it as they're more likely to be open to doing so properly.

I don't know why so much acrimony, you clearly don't have any idea this type of software, but OK.

If you think you can do better, please prove it: hic Rhodus, hic salta

You obviously have difficulty understanding simple concepts
The package system of each system is different.
Although I have 35 years of experience writing C++ programs that you don't even dream of, I have never once written a package for Arch
It's not that it's good or bad (Arch)
I just don't know him

As you know, or maybe not, there is no PIE on OmniOS, for example
No RELRO on ESXi

My interest in Arch just ended here and now
Thank you

PS as you may know, or maybe not, you/I don't earn anything with opensource software.

The opensource spirit should be to make your work available for free.
Nobody then forces you to use it.
You are obviously totally devoid of this collaborative spirit
---
You focus on a trivial problem (substitute some placeholders for the paths)
Even one of my secretaries can do it

I, on the other hand, focus on an issue that I don't know, and that you don't seem to know either
That is the (perhaps) "incompatibility" of statically linked binaries with "silencing" the warnings on Arch
As you can see, we both learned something
Have a nice day

Last edited by fcorbelli (2022-08-16 16:51:19)

fcorbelli · 2022-08-16 16:54:41

One last thing: Red Hat does not like statically linked files, too

https://access.redhat.com/documentation … -libraries

16.2. Static and dynamic linking
Developers have a choice of using static or dynamic linking when building applications with fully compiled languages. This section lists the differences, particularly in the contexti of using the C and C++ languages on Red Hat Enterprise Linux. To summarize, Red Hat discourages the use of static linking in applications for Red Hat Enterprise Linux.

fcorbelli · 2023-09-19 13:59:27

With "some" (aka: a lot) helpful... help... the AUR is done, or at least I hope so

https://aur.archlinux.org/packages/zpaqfranz-git

Thank you all for your valuable comments

Arch Linux

#1 2022-04-03 17:10:56

New package proposal: zpaqfranz

#2 2022-04-03 17:28:39

Re: New package proposal: zpaqfranz

#3 2022-04-03 20:47:11

Re: New package proposal: zpaqfranz

#4 2022-04-04 11:14:09

Re: New package proposal: zpaqfranz

#5 2022-04-04 11:20:21

Re: New package proposal: zpaqfranz

#6 2022-08-16 14:02:35

Re: New package proposal: zpaqfranz

#7 2022-08-16 14:55:35

Re: New package proposal: zpaqfranz

#8 2022-08-16 15:31:32

Re: New package proposal: zpaqfranz

#9 2022-08-16 15:38:32

Re: New package proposal: zpaqfranz

#10 2022-08-16 15:53:20

Re: New package proposal: zpaqfranz

#11 2022-08-16 16:06:44

Re: New package proposal: zpaqfranz

#12 2022-08-16 16:07:37

Re: New package proposal: zpaqfranz

#13 2022-08-16 16:20:50

Re: New package proposal: zpaqfranz

#14 2022-08-16 16:23:45

Re: New package proposal: zpaqfranz

#15 2022-08-16 16:32:02

Re: New package proposal: zpaqfranz

#16 2022-08-16 16:34:01

Re: New package proposal: zpaqfranz

#17 2022-08-16 16:37:26

Re: New package proposal: zpaqfranz

#18 2022-08-16 16:47:24

Re: New package proposal: zpaqfranz

#19 2022-08-16 16:54:41

Re: New package proposal: zpaqfranz

#20 2023-09-19 13:59:27

Re: New package proposal: zpaqfranz

Board footer