New package: plptools-1.0.26

[JunePrimavera]

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)
• I built this PR locally for these architectures:
  • x86_64
  • i686

New package for plptools. I have tested for x86_64 glibc and for i686 glibc. I don't have access to ARM hardware to test on, so that has not been tested - I don't see why it wouldn't work, however. This also provides its own service for ncpd; which isn't provided for runit upstream.

[Duncaen]

Suggested change

	build_style=gnu-makefile
	build_style=gnu-configure

And remove the do_configure, do_build and do_install functions, that should fix the build issues, as its standardized and xbps-src will pass all right flags by default.

[JunePrimavera]

Apologies - I've realized I pushed a broken commit, not sure what went wrong.

Is it best to re-open a PR with the changes, or to try and resolve the git history from this PR/my fork?

[Duncaen]

Its better to fix the same branch and use the same PR so that the history is not lost and there is no extra notifications for close/open the same PRs.

If you want to start from scratch on that branch you should be able to git reset --hard master.

[JunePrimavera]

diff --git a/srcpkgs/plptools/template b/srcpkgs/plptools/template
index c385ee09..38fc0be1 100644
--- a/srcpkgs/plptools/template
+++ b/srcpkgs/plptools/template
@@ -2,28 +2,16 @@
 pkgname=plptools
 version=1.0.26
 revision=1
-build_style=gnu-makefile
-short_desc="Utilities for communication with EPOC PDAs, e.g. mounting via FUSE" 
-depends="fuse"
+build_style=gnu-configure
 makedepends="make automake git libtool gnupg tar pkgconf gettext-devel readline-devel"
+depends="fuse"
+short_desc="Utilities for communication with EPOC PDAs, e.g. mounting via FUSE"
 maintainer="Juniper Gardiner <juniper.gardiner@gmail.com>"
 license="GPL-2.0-only"
 homepage="https://github.com/plptools/plptools"
 distfiles="https://github.com/plptools/plptools/releases/download/v${version}/plptools-${version}.tar.gz"
 checksum="5a7faf45e268a5717d0b4e79ba8648983fba1d3629923b371e5ee3dbc80f2a58"
 
-do_configure() {
-       ./configure --prefix=/usr --sbin=/usr/bin --sysconfdir=/etc --host=$XBPS_TARGET_MACHINE
-}
-
-do_build() {
-       make ARCH=$XBPS_TARGET_MACHINE CROSS_COMPILE=${XBPS_CROSS_TRIPLET}- ${makejobs}
-}
-
-do_install() {
-       make DESTDIR=$DESTDIR install
-}
-
 post_install() {
        vsv ncpd
 }

For whatever reason, the diff is what you'd expect despite the commit replacing all of the files in the repository - Might be some odd bug or configuration issue on my system.

[JunePrimavera]

Its better to fix the same branch and use the same PR so that the history is not lost and there is no extra notifications for close/open the same PRs.

If you want to start from scratch on that branch you should be able to git reset --hard master.

I've reset my fork, but the PR closed automatically when I made the commit - I'm not sure if I can reopen it since the git histories do not match?

[Duncaen]

Should just work with resetting, a branch is really just a name pointing to some commit, resetting or diverging is completely normal and part of every rebase.

Github is a bit weird about PRs from branches that were deleted in that case it won't allow to reopen the PR.

Looking at your froks's activity, I think the problem is that you use the master branch. Maybe in that case github also acts weird, there are a few difference between master and other branches.

I'd suggest to always use new branches to create PRs, that allows you to open and work in independent PRs and makes it easy to rebase onto master if the master branch is clean.

https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#creating-updating-and-modifying-packages-in-void-by-yourself

[JunePrimavera]

I've reset the master branch on my fork - Still unable to re-open the PR. I think I may have to open a new one (On a different branch this time!) unless there's another way I can resolve the issue that I am not aware of

Will definitely keep this in mind for future reference, sorry for the inconvenience!