New package: newm-0.2
Dependency: python3-dasbus:
Testing the changes
- I tested the changes in this PR: YES
New package
- This new package conforms to the package requirements: YES
Local build testing
- I built this PR locally for my native architecture, (x86_64-glibc)
Was done to fulfill https://github.com/void-linux/void-packages/issues/49517 request
If you're attempting to package newm-atha, include this package in that PR. Don't submit packages for dependencies piecemeal.
If you're attempting to package
newm-atha, include this package in that PR. Don't submit packages for dependencies piecemeal.
Ok I will. Sorry
If you're attempting to package
newm-atha, include this package in that PR. Don't submit packages for dependencies piecemeal.
I wanted to ask you an advice: what if I have multiple distfiles and i need both of them to go through packaging script - both of them to build separately. Could it be managed within one template?
I'm asking as hewm has separate release for it's engine. I don't want to separate as void packages them because: 1) it'd be too much attention for such thing 2) LICENSE file is able within only one of them
I wanted to ask you an advice: what if I have multiple distfiles and i need both of them to go through packaging script - both of them to build separately. Could it be managed within one template?
I'm asking as hewm has separate release for it's engine. I don't want to separate as void packages them because: 1) it'd be too much attention for such thing 2) LICENSE file is able within only one of them
I found this: https://github.com/void-linux/void-packages/pull/41185#discussion_r1055638769
I wanted to ask you an advice: what if I have multiple distfiles and i need both of them to go through packaging script - both of them to build separately. Could it be managed within one template? I'm asking as hewm has separate release for it's engine. I don't want to separate as void packages them because: 1) it'd be too much attention for such thing 2) LICENSE file is able within only one of them
I found this: #41185 (comment)
Thanks. We'll use 2 packages then...
I don't think packaging an old tag of a now-abandoned repository is a good idea, and the fork recommended by the original maintainer hasn't seen activity in seven months and hasn't tagged any new releases.
Unless something changes upstream, I'd advise against sinking any time into this PR.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.