error building from pkgsrc-wip -- Package 'x11' not found

kc9udx

pfr I think so, but I don't recall how just now. Surely you can export it in the current shell before running make
But hopefully someone else here can confirm that, as due to severe weather, I must now have much less sleep than you.

I can't recommend ignoring the checksum anymore in this case: it does seem like something went wrong this time. But keep it in mind for future reference.

pfr Question: Can I use NO_CHECKSUM=yes as a command line option with make?

Forgot to answer this ...

Yes, you simply run make NO_CHECKSUM=yes instead. The real question is ... why on earth would you want to do this?!

===> Installing dependencies for rust-1.76.0nb1
==========================================================================
The supported build options for rust are:

	rust-cargo-static rust-docs rust-internal-llvm

You can select which build options to use by setting PKG_DEFAULT_OPTIONS
or the following variable.  Its current value is shown:

	PKG_OPTIONS.rust (not defined)

==========================================================================
==========================================================================
The following variables will affect the build process of this package,
rust-1.76.0nb1.  Their current value is shown below:

        * KRB5_DEFAULT = heimdal
        * PYTHON_VERSION_DEFAULT = 311
        * SSLBASE = /usr
        * SSLCERTBUNDLE (not defined)
        * SSLCERTS = /etc/openssl/certs
        * SSLDIR = /etc/openssl
        * SSLKEYS = /etc/openssl/private
        * TERMINFO_DEFAULT = terminfo

Based on these variables, the following variables have been set:

        * KRB5BASE (defined, but empty)
        * KRB5_TYPE = heimdal
        * PYPACKAGE = python311
        * TERMINFO_TYPE = terminfo

You may want to abort the process now with CTRL-C and change the value
of variables in the first group before continuing.  Be sure to run
`/usr/bin/make clean' after the changes.
==========================================================================
=> Tool dependency cmake-[0-9]*: found cmake-3.29.2
=> Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.7nb1
=> Tool dependency mktools-[0-9]*: found mktools-20220614
=> Tool dependency bash-[0-9]*: found bash-5.2.26nb1
=> Tool dependency gmake>=3.81: found gmake-4.4.1
=> Tool dependency gtar-base>=1.13.25: found gtar-base-1.35
=> Tool dependency perl>=5.0: found perl-5.38.2
=> Tool dependency pkgconf-[0-9]*: found pkgconf-2.2.0
=> Tool dependency cwrappers>=20150314: found cwrappers-20220403
=> Tool dependency checkperms>=1.1: found checkperms-1.12
=> Build dependency python311>=3.11.0: found python311-3.11.9
=> Full dependency libunwind>=17.0.0<18: found libunwind-17.0.6
=> Full dependency llvm>=17.0.0<18: found llvm-17.0.6
=> Full dependency curl>=8.4.0nb1: found curl-8.7.1
===> Skipping vulnerability checks.
WARNING: No /usr/pkg/pkgdb/pkg-vulnerabilities file found.
WARNING: To fix run: `/usr/pkg/sbin/pkg_admin -K /usr/pkg/pkgdb fetch-pkg-vulnerabilities'.
===> Overriding tools for rust-1.76.0nb1
===> Extracting for rust-1.76.0nb1

Notice the lines

=> Checksum BLAKE2s OK for rust-1.75.0-x86_64-unknown-netbsd.tar.xz
=> Checksum SHA512 OK for rust-1.75.0-x86_64-unknown-netbsd.tar.xz
=> Checksum BLAKE2s OK for rust-std-1.75.0-x86_64-unknown-netbsd.tar.xz
=> Checksum SHA512 OK for rust-std-1.75.0-x86_64-unknown-netbsd.tar.xz
=> Checksum BLAKE2s OK for rustc-1.76.0-src.tar.gz
=> Checksum SHA512 OK for rustc-1.76.0-src.tar.gz

are missing when comparing to my earlier output above.

kc9udx

why on earth would you want to do this?

I wouldn't in this case because you have verified that the archive is correct. But I've run into situations where (I assume that) someone upstream changed the archive and the checksum won't match.

kc9udx But I've run into situations where (I assume that) someone upstream changed the archive and the checksum won't match

Unfortunately, this happens sometimes. The most common reason is some Github hosted project realizing they just pushed a tag and promote that to release. Or, even more annoying when people think they can just quickly fix a bug in a release by simply push the new code into it.

When this happens, I always ask them to avoid this. But, some never learn.

rvp

pin Honestly, I have no interest in an archived, unmaintained package.

Maybe @pfr should since a) he wants it and b) it's in WIP.

pfr

pin
I can confirm the package now builds and installs without fail.

rvp Maybe @pfr should since a) he wants it and b) it's in WIP.

I mean, I would... but who's going to give me the keys to submit packages to pkgsrc, I certainly wouldn't.
But, I do want this package to remain available, so how can I help?

kc9udx

pfr 1) make sure you are listed as the maintainer.
2) subscribe to pkgsrc-users and ask someone to commit it.
3) monitor the list so that when someone says "since no one uses this, can I delete it?" you can reply, "here am I."

rvp

pfr but who's going to give me the keys to submit packages to pkgsrc

There's a page for this.

pfr

kc9udx 1) make sure you are listed as the maintainer.

How does one become listed as a pkg maintainer, and do I actually need to "maintain" the package? I'm happy to be the pkg Caretaker and speak up when needed.

kc9udx

pfr This doesn't specifically pertain to your situation but I think you'll find what you need in it.

kc9udx

rvp I think the one you're meaning is this

(Or perhaps not because that's just how to add a brand new package to WIP, not how to make a WIP package a pkgsrc package)

rvp

kc9udx I think the one you're meaning is this

That one's better!

wip access, isn't hard to get. But, if we are referring to the specific case of pinentry-dmenu, than I would suggest @pfr to try removing the flags and check if the package still builds.

Still ... I wouldn't import it into main., it's archived and has an inactive (dead?) upstream.

pfr

pin (dead?)

I think it's simply feature complete... ?

pfr I think it's simply feature complete... ?

That's what they always say.

EDIT: I'd say, if something is feature complete, than keep the repository alive for potential bug fixes and simply refuse new features. Don't just archive it!

« Previous Page