You are not logged in.

#1 2020-07-26 03:22:31

erbrecht
Member
From: United States
Registered: 2016-03-07
Posts: 10

noisetorch PKGBUILD

I started an AUR package for noisetorch, noisetorch-git. I saw this thread and I realize I'm guilty of updating the PKGBUILD when a new release has been made available, but no other changes are present. I'm curious how someone would know there is a newer version to install in this case? Is there something else I should be doing?

I've also been back and forth with the developer of noisetorch regarding the actual packaging of the software. The full discussion is over here, but it boils down to the fact that they were unhappy with the way I patched some of the code to disable a self-update mechanism. My patch originally changed the config file that is generated when the application first runs. I set an EnableUpdates flag to false in this config, which is located in the user's home directory ($HOME/.config/noisetorch/config.toml). The developer would rather have the actual code that checks for updates removed. I made that change and the PKGBUILD is no longer patching the code that generates that config file, but instead it removes the 3 lines responsible for checking for updates. They also asked that I revert the config file in the user's home directory to the default. I'd rather not make a change to a file not owned by the package, but I did add a comment on the package's AUR page stating that the config file should be updated. This brings a few questions to mind:

1. Is it possible to create a package that installs files into a user's home directory, and if so, what would the preferred mechanism be? In the case of the AUR, users are running makepkg, so $HOME properly resolves to their own home directory, but the packaging guidelines state that a package should not contain the /home directory.
2. Should I be modifying a file not owned by the package? My guess is no.
3. Does the noisetorch-git package look ok? I tried to follow the VSC packaging guidelines.

I was reading the Go package guidelines and I'm in the process of updating the PKGBUILD so it does not use the Makefile, but rather builds directly so I can specify the appropriate flags. So that is in the works, but I'd rather not push changes until I have some idea of how to handle the other issues above.

This is the first package I've worked on, so I'm still trying to read and learn all I can. Any help is appreciated.

Offline

#2 2020-07-26 03:31:57

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: noisetorch PKGBUILD

erbrecht wrote:

I'm curious how someone would know there is a newer version to install in this case? Is there something else I should be doing?

There is nothing else you should do.  If there is a big or noteworthy change, you could post a new comment on the AUR page for the package, but that is not necessary.  The whole point of a -git package is that they track current development: there should always be new versions to install.  If upstream development is stalled there's no point in a -git package and you should use a fixed point release.

erbrecht wrote:

1. Is it possible to create a package that installs files into a user's home directory, and if so, what would the preferred mechanism be? In the case of the AUR, users are running makepkg, so $HOME properly resolves to their own home directory, but the packaging guidelines state that a package should not contain the /home directory.

No, absolutely not.  And $HOME will not evaluate to anything in many cases of makepkg being run, while in others it will be wrong as a package can be built on one machine to be used on another.

EDIT: What is this conditional for in the PKGBUILD:

if [[ -d "/usr/share/icons/hicolor/256x256/apps/"  ]]

That's rather nonsensical.  You check if directory exists, and only if it does exist you install a file that belongs there, but you install that file with a flag specifically meant to create that path if it doesn't exist!  This will build a different package on different machines (which PKGBUILDs shouldn't do except for different architectures), and it will fail to install that file when it should anytime one builds in a clean chroot (which you should test your packages in too).  Just get rid of the conditional, and install the icon properly and unconditionally.

Related to that, I suspect the only reason you have the hicolor-icon-theme as an optional dependency is due to this path.  If so, get rid of the optional depdendency.  That doesn't add any additional behavior to the software being packaged.  There are countless repo packages that you can looks to for examples of installing icons and not having (opt)depends on icon themes.  To name a few on my system: feh, qutebrowser, and vim.

Last edited by Trilby (2020-07-26 03:43:30)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2020-07-26 03:47:00

erbrecht
Member
From: United States
Registered: 2016-03-07
Posts: 10

Re: noisetorch PKGBUILD

I'll get rid of the optdepends and the conditional. Thanks for the feedback.

Offline

#4 2020-07-26 04:49:38

erbrecht
Member
From: United States
Registered: 2016-03-07
Posts: 10

Re: noisetorch PKGBUILD

Trilby wrote:

Just get rid of the conditional, and install the icon properly and unconditionally.

Related to that, I suspect the only reason you have the hicolor-icon-theme as an optional dependency is due to this path.  If so, get rid of the optional depdendency.

I removed the hicolor-icon-theme optional dependency and I tried installing the icon unconditionally:

package() {
	cd NoiseTorch
	install -D -m755 bin/noisetorch "${pkgdir}/usr/bin/noisetorch"
	install -D -m644 assets/noisetorch.desktop \
		"${pkgdir}/usr/share/applications/noisetorch.desktop"
	install -D -m644 assets/icon/noisetorch.png \
		"${pkgdir}/usr/share/icons/hicolor/256x256/apps/noisetorch.png"
}

namcap reports an error:

$ cat noisetorch-git-0.5.3.beta.r1.g5ce761a-2-x86_64.pkg.tar.zst-namcap.log
noisetorch-git E: Dependency hicolor-icon-theme detected and not included (needed for hicolor theme hierarchy)
noisetorch-git W: Dependency included and not needed ('pulseaudio')
noisetorch-git W: Dependency included and not needed ('polkit')

Is it safe to ignore that error in this case? Similarly, pulseaudio and polkit are listed as included and not needed. The application requires polkit to work, and it works with pulseaudio. I've been ignoring those warnings since the application couldn't function without those packages installed. I'm guessing there's not really anything I can do about those warnings?

Offline

#5 2020-07-26 05:34:31

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: noisetorch PKGBUILD

namcap isn't very good at detecting when deps are needed. It can only check if the package links to shared libraries provided by the other package, or includes scripts with a shebang provided by the package. Otherwise it is pretty hit-and-miss -- and it misdetects python modules all the time, claiming that python2 modules are missing python3 deps due to files in /usr/lib/python2.7/site-packages/ containing shebangs for "/usr/bin/python" or vice versa.

Never take namcap's word as final. It can help you detect things you forgot about, but if you have reason to think it is triggering false positives, ignore it.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#6 2020-07-26 15:19:51

yochananmarqos
Member
Registered: 2020-02-05
Posts: 194

Re: noisetorch PKGBUILD

erbrecht wrote:

specify the appropriate flags.

You can still use the Makefile this way:

build() {
  cd NoiseTorch
  export CGO_CPPFLAGS="${CPPFLAGS}"
  export CGO_CFLAGS="${CFLAGS}"
  export CGO_CXXFLAGS="${CXXFLAGS}"
  export CGO_LDFLAGS="${LDFLAGS}"
  export GOFLAGS="-buildmode=pie -trimpath -mod=readonly -modcacherw"
  make
}

For some reason the build fails with the CFLAGS enabled, though.
EDIT: Apparently

-fdiagnostics-color=always

cause issues sometimes. Strange.

Last edited by yochananmarqos (2020-07-27 13:15:28)

Offline

#7 2020-07-27 12:06:36

erbrecht
Member
From: United States
Registered: 2016-03-07
Posts: 10

Re: noisetorch PKGBUILD

Thanks for all the help everyone. I'm ignoring those namcap errors/warnings, and I'm exporting the go environment variables and using the Makefile to build.

yochananmarqos wrote:

For some reason the build fails with the CFLAGS enabled, though.

I was able to build successfully with export CGO_CFLAGS="${CFLAGS}" in place, both in a clean chroot (using extra-x86_64-build -c from devtools), and under my regular system. CGO_CFLAGS are the same for me in a clean chroot and on my normal system. I have:

CGO_CPPFLAGS: -D_FORTIFY_SOURCE=2
CGO_CFLAGS:   -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
CGO_CXXFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
CGO_LDFLAGS:  -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
GOFLAGS:      -buildmode=pie -trimpath -mod=readonly -modcacherw

Are they different for you? Also, what error are you getting during the build?

Last edited by erbrecht (2020-07-27 12:33:40)

Offline

#8 2020-07-27 12:11:02

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: noisetorch PKGBUILD

"The build fails" is a completely useless error message.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#9 2020-07-27 12:24:34

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: noisetorch PKGBUILD

I wouldn't say completely ... just mostly - almost entirely.  Something happened.  We could speculate that yochananmarqos has some uncommon setting in his makepkg.conf that might cause a problem, and that'd be worth knowing.  Although this depends on yochananmarqos following up with more information.  In the absence of that I suppose I'd agree a one-and-done drive-by "build fails" would be useless.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2020-07-27 13:18:54

yochananmarqos
Member
Registered: 2020-02-05
Posts: 194

Re: noisetorch PKGBUILD

eschwartz wrote:

"The build fails" is a completely useless error message.

You're right, it is.

Trilby wrote:

We could speculate that yochananmarqos has some uncommon setting in his makepkg.conf that might cause a problem, and that'd be worth knowing.

I edited my post above. Trying to make things look nice can break things. Who knew? ¯\_(ツ)_/¯

Offline

#11 2020-07-27 13:20:55

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: noisetorch PKGBUILD

lol, I had discovered the same thing by sheer coincidence, shortly before this.

-fdiagnostics-color breaks golang due to https://github.com/golang/go/issues/40415

It was very annoying that I needed to test flags one by one, only to discover the most unlikely cause. I left that one for last, because I couldn't imagine how it would cause breakage.

Last edited by eschwartz (2020-07-27 13:23:41)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB