Hi, thanks for your comments.
Lone_Wolf wrote:
> timidity++ and fluidsynth are the 2 most common software midi
> synthesizers on archlinux.
> I suggest you list them as optdepends .
Thanks, I did that (and also checked that it works with both of these).
Polarian wrote:
> Appreciate it if you
On 19-02-2024 10:39, Jonas Serych wrote:
The PKGBUILD got sent as a binary mime type, sorry about that. Here it
is as text/plain.
One comment :
upstream readme mnetrions requiring a 'midi sequencer' .
Some soundcards offer that ability in hardware, but the majority doesn't.
timidity++
The PKGBUILD got sent as a binary mime type, sorry about that. Here it
is as text/plain.
# Maintainer: Jonas Serych
pkgname='powertabeditor'
pkgver='2.0.0_alpha19'
pkgrel=1
pkgdesc="Guitar tablature viewer and editor"
arch=('x86_64')
url="https://powertab.github.io/;
license=('GPL-3.0-only')
Hi,
this is my first time creating a PKGBUILD. I tried to follow the
guidelines and the recommended practices for cmake packages, but not
sure I didn't miss something. Thanks for any suggestions.
I checked that it builds in clean chroot. The software seems to work
well, except for JACK server
On 1/8/24 17:52, Doug Newgard wrote:
r(commit count).g(commit)
but that is about the best I was able to work out. If you know some
additional cmake magic I missed that allows grabbing the name from one of the
generated files in a format better than that above, you will have to help me
with
On Mon, 8 Jan 2024 16:56:16 -0600
"David C. Rankin" wrote:
>There is no way to pull from the internal CPACK name to get precisely the
> CPACK_PACKAGE_VERSION out of it. You also cannot simply add a "TZST"
> generator and then either "cmake --build . --target package" or "make
> package" to
On 1/7/24 08:37, Doug Newgard wrote:
If there is
ever an actual "Release" of wiringX, then we can remove the pkgver() function
entirely.
That's not how -git PKGBUILDs work. It builds from HEAD and should always build
from HEAD. You really need to fix the pkgver function. Looking at the upstream
On 1/7/24 08:37, Doug Newgard wrote:
If there is
ever an actual "Release" of wiringX, then we can remove the pkgver() function
entirely.
That's not how -git PKGBUILDs work. It builds from HEAD and should always build
from HEAD. You really need to fix the pkgver function. Looking at the
> If there is
> ever an actual "Release" of wiringX, then we can remove the pkgver() function
> entirely.
That's not how -git PKGBUILDs work. It builds from HEAD and should always build
from HEAD. You really need to fix the pkgver function. Looking at the upstream
CMakeLists.txt, I would
On 1/5/24 21:01, Aaron Liu wrote:
Hmm,
I know nothing on the library side of things, but as Arch conventions dictate:
1. All package titles should be lowercase, so wiringx-git, perhaps?.
2. You should probably do a provides=(libwiringx.so wiringx) so the soname is
searchable and conflicts are
On 1/6/24 11:36, Doug Newgard wrote:
mv "$pkgdir/usr/local/"* "$pkgdir/usr"
rm -r "$pkgdir/usr/local"
Can you not set a prefix? This step should not normally necessary.
Yes it can,
I was reading the cmake documentation wrong:
build() {
cd "${srcdir}/$_gitname/build"
cmake
On 1/6/24 11:36, Doug Newgard wrote:
url="httpx://wiringx.org/"
Typo
fat-fingers
pkgver() {
cd "${srcdir}/$_gitname"
echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD)
}
This will cause problems if there is ever a release. See
On 1/6/24 09:35, Polarian wrote:
The nature of static linking is for portability, and although reading
about it there is some use cases for static libraries [2], most
programs which static link will compile the program from source by
default.
Secondly this is slightly out of the scope of Arch
In addition to things others have said.
> url="httpx://wiringx.org/"
Typo
> pkgver() {
>cd "${srcdir}/$_gitname"
>echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD)
> }
This will cause problems if there is ever a release. See
Hi,
According to manual.wiringx.org , wiringX is only a library and nothing
else. I don't think the splitting into two packages part applies here,
as there is nothing to install other than the library.
--
Cheers,
Aᴀʀᴏɴ
OpenPGP_0x4E85967FC7C436BE.asc
Description: OpenPGP public key
You might also want to look at the CMake package guidelines [1]. In
particular, cmake should be called from build(), not prepare().
[1] https://wiki.archlinux.org/title/CMake_package_guidelines
signature.asc
Description: PGP signature
On 1/6/24 01:22, Jean-Claude wrote:
In addition to what has been said, do not include the package name in
the description in a self-referencing way.[1]
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette
Thanks Aaron and Jean-Claude,
I'll fix those items and put
In addition to what has been said, do not include the package name in
the description in a self-referencing way.[1]
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_etiquette
signature.asc
Description: PGP signature
Hmm,
I know nothing on the library side of things, but as Arch conventions
dictate:
1. All package titles should be lowercase, so wiringx-git, perhaps?.
2. You should probably do a provides=(libwiringx.so wiringx) so the
soname is searchable and conflicts are better detected
3. According to
All,
I'm thinking of adding a wiringX-git package to AUR and wanted to put the
PKGBUILD out for comment and help. It's a simple tiny package used for
embedded development to manipulate GPIO pins.
What I've cobbled together is:
pkgname=wiringX-git
_gitname=wiringX
pkgver=251.54030cd
Le 21/10/2023 à 14:48, Lone_Wolf a écrit :
On 21-10-2023 10:05, Robin Candau wrote:
As such, a package specifically made for derivatives (like this one,
made to be used with the runit init system) is not allowed on the AUR.
On the other hand runit is available from aur and archwiki
On 21-10-2023 10:05, Robin Candau wrote:
As such, a package specifically made for derivatives (like this one,
made to be used with the runit init system) is not allowed on the AUR.
On the other hand runit is available from aur and archwiki describres
how to use it alongside systemd .
Le 21/10/2023 à 00:39, Eric a écrit :
Hi all,
Hi Eric!
I'm working on this PKGBUILD to provide a displaylink-runit service. I
use an Artix based distro using runit instead of systemD as the init system.
Before I publish this, please review this. [...]
The AUR is meant for Arch Linux only
Hi all,
I'm working on this PKGBUILD to provide a displaylink-runit service. I use
an Artix based distro using runit instead of systemD as the init system.
Before I publish this, please review this. I have posted the link to my PR
to a few Linux communities and I have addressed their comments,
On Wed, 22 Mar 2023 07:55:44 -0300
jamil bio wrote:
> Hello!
>
> I would like to introduce my project to the AUR mailing list. I am about to
> upload a PKGBUILD of a `datediff.sh' script which does calendrical
> calculations with shell built-ins, and has got some other few functions as
> well.
On 2023-03-22 at 08:33:59 -0300,
jamil bio wrote:
> > md5 is broken and should not be used, sha256 or similar would be advised.
>
> Will use other checksum algos... Will switch to sha1. Thanks!
SHA1 is broken. As indicated, please use SHA256 (or even SHA512).
> On 22/03/2023 08:16, Martin
> Adding the extension to the executable is non-standard,
Indeed Hroptatyr's 'C-code datediff' already exists in community as
'dateutils'. It is not desirable to install the datediff.sh script as
'datediff' to avoid such instance of conflict.. However, what binary name would
be cool to
> Would installing the script as `datediff.sh' to /usr/bin be standard?
I believe /usr/bin/datediff would.
Adding the extension to the executable is non-standard, lots of
binaries are plaintext, but they do not carry their extension.
Imagine you rewrite your tool to use python instead, now you
That last e-mail encoding looks borked on my mailing list reader (the
terminal), so I am sending the PKGBUILD again.
# Maintainer: Jamil SN
pkgname='datediff.sh'
pkgbase='shellDatediff'
pkgver=0.23.4
pkgrel=1
#epoch=
pkgdesc='Calculate time differences with Ksh, Bash, and Zsh builtins. Check
Hello!
I would like to introduce my project to the AUR mailing list. I am about to
upload a PKGBUILD of a `datediff.sh' script which does calendrical calculations
with shell built-ins, and has got some other few functions as well.
Would installing the script as `datediff.sh' to /usr/bin be
Fabio,
a newbie question:
> there is validpgpkeys but is not checked in source=()
would that suggest changing
source=("git+https://gitlab.com/minecraftchest1/steamdeck-file-share-tool#tag=$pkgver;)
to something like this
Hi,
Here's how I would have wrote it (see commented changes at the bottom):
# Maintainer: Minecraftchest1
pkgname=file-sharing-tool
pkgver=0.2.0
pkgrel=1
pkgdesc="A tool to help setup file sharing using ssh."
arch=('any')
url=
Hello,
> please install the script as file-sharing-tool (without .sh)
This is not always needed, it depends on how you want it to be, for
example "acme.sh" keeps the .sh due to the naming they wanted.
However it is PREFERED to use a shebang to the interpreter needed to run
the script on the
Il 12/12/22 19:03, Wyatt C Jackson ha scritto:
I recently put together a PKGBUILD file for a tool I made and want to put on
the AUR. While I believe it should be fine, I would like to have it reviewed
before I upload it.
---
```
# Maintainer: Minecraftchest1
pkgname=file-sharing-tool
Hello,
This looks good to me, however I advice to omit any opinions which you
have not defined.
Apart from that it looks good, make sure to build and install the
package to ensure everything is working fine, follow the following:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I recently put together a PKGBUILD file for a tool I made and want to put on
the AUR. While I believe it should be fine, I would like to have it reviewed
before I upload it.
- ---
```
# Maintainer: Minecraftchest1
pkgname=file-sharing-tool
I've pushed GCC 10 to the AUR:
https://aur.archlinux.org/packages/gcc10
It's based on the older GCC 9 PKGBUILD [1] with some elements from the
GCC 11 PKGBUILD [2].
It builds, installs, and seemingly runs OK, but it's something with
potential for hidden gotchas so if someone could cast their
Hi Vince,
I understand that you'd like to get REXpaint in the AUR. Rather
than communicating over a long mailing list thread, do you mind
joining us in #archlinux-aurweb at some point on Libera? Could
help out a lot more directly and take a look at things without
producing additions to this
Hi again,
It looks I didn't attach the correct files. I'm not sure what happened.
Regardless, I have attached the files, and uploaded them to ix.io to
be safe. Apologies for the confusion.
PKGBUILD: http://ix.io/3uJY
launcher.desktop: http://ix.io/3uzB
launcher.sh: http://ix.io/3uJZ
Hello aur-general,
Thank you for your help in the previous threads. I'm immensely grateful
for the feedback I got, and hope that I'm not polluting too much.
I have completed a PKGBUILD for REXPaint. I would be grateful if
someone could take a look and make sure that it ticks all the boxes,
and
40 matches
Mail list logo
