How long does it take?

[dettus]

Hey guys!

So... I have a new project, in which I have created a badass-oldskool looking MP3 player. You can download it here: https://dettus.net/d11amp

And I took the liberty of creating a FreeBSD port for it:

268359 – audio/d11amp 0.59: New Port 2

bugs.freebsd.org

How long does it take to process those?
I would REALLY love to see it becoming part of the official FreeBSD ports tree. Hopefully it meets your standards.

Thomas

 

[cracauer@]

It's random when somebody picks up patch submissions.

One question - why do you have a patch in a port of your own software? Why not change it in the upstream package?

 

[zirias@]

why do you have a patch in a port of your own software? Why not change it in the upstream package?

Great question indeed.

And I have another one: It seems multimedia/audacious already provides a "winamp-like" interface, like x11amp and xmms did, and capable of using the original skins. So, what's different or better here?

edit: don't take that as criticism please, some "redundancy" in the ports tree doesn't hurt of course ... just trying to explain why there wasn't too much interest yet....

 

[zirias@]

BTW, regarding the port itself, please use

USES=           gnome
USE_GNOME=      gdkpixbuf2 gtk40

instead of specifying these dependencies manually.

 

[dettus]

Great question indeed.

And I have another one: It seems multimedia/audacious already provides a "winamp-like" interface, like x11amp and xmms did, and capable of using the original skins. So, what's different or better here?

edit: don't take that as criticism please, some "redundancy" in the ports tree doesn't hurt of course ... just trying to explain why there wasn't too much interest yet....

Hello zirias. Thank you for your great questions.

Actually... "Redundancy" is a matter of philosophy. Believe it or not: I got the question a lot. Some people were siding with me, stating that "one more does not hurt". My personal opinion is that we are doing "OPEN SOURCE". Meaning that a user should have as many options as possible to choose from. And if the choices are not satisfactory (which they weren't in my case), they should write their own. *Please* give my code a chance...


As for "How it is different"...
Here my answer is always that the LICENSING SITUATION is much cleaner with my program. It does not have any ties to a semi-commercial frontend. It relies on the new GTK4 library.
Even the default skin is explicitly available as CC-0. So sharing screenshots will never be a problem.

One question - why do you have a patch in a port of your own software? Why not change it in the upstream package?

I will... In the NEXT release.

The thing is... I finished releasing the software before I started on the ports&packaging process. Whilst doing so, I noticed some issues with it, some typos in the Manpage, and some trouble with the Makefile in OpenBSD, for example. Instead of doing a new release, I decided to patch it. Now I am fine-tuning this one, (for example, adding the USES=... lines). Once THAT is finished, I will go back to the software. And once I know what the ports should look like, I will automate the process. (Yay python)

One thing at a time! I am doing this for fun.

 

[zirias@]

dettus, I just took your PR. Although I don't see how licensing would be an issue with audacious (which seems to be capable of doing the same thing as your project?), I agree there's nothing wrong with having a choice, even between projects seemingly doing the same thing!

Still, I think cracauer@ raised a very valid concern. If you're also the upstream author, please take any portability patches upstream before adding a port. I mean, a new minor release won't hurt, would it? And we're typically trying to push such fixes upstream anyways, keeping the number of local patches in the ports tree as low as possible.

Furthermore, please add the changes (USES=gnome) I suggested!

Thanks for your contribution!

 

[patmaddox]

Sometimes people make software because it's fun and they like doing things their way

 

[zirias@]

Sometimes people make software because it's fun and they like doing things their way

And that's all fine, and I took the PR because I'd really love to carry out the commit for this new port once it's in good shape! I just tried to see why the interest wasn't that great at first ...

And, as already written, there are a few minor issues to fix before commit!

 

[dettus]

Wonderful!
Thank you for taking the PR in.

So, I uploaded a new patch to the GIT repo to bugzilla. One that contains the USES=gnome line. And I ran a "make install" on a freshly installed FreeBSD system with a freshly checked out freebsd-ports repository overnight. There were a few hickups whilst building the dependencies, but my port itself was good.

root@freebsd:/usr/ports/audio/d11amp # make test
===>  Testing for d11amp-0.59
mkdir -p /tmp/d11amp/
./d11amp --dir=/tmp/d11amp/ --gui.theme.dumpdefault=/tmp/d11amp/
if [ "`cat /tmp/d11amp//cc-0-10.txt | sha256 | awk -F' ' '{ print $1; }' - `" = "28e22bf9721e3ac3b9cd59836b215b45e96e1bf31e2d0170896d4b2b501db4a4" ]       ; then echo "check OK" ; else echo "check failed" ; exit 1 ; fi
check OK

REGARDING THE PATCHES: I took a closer look at both of them. One removed a typo in the manpage, the second one was actually a patch to make the build process compatible with your port system. Thus, I would respectfully request that I may be allowed to keep this technique in the future. I can guarantee you that they will decrease in size, but it will never go away, since I am also creating ports for other Operating Systems as well.
(Btw: The code itself was not patched, really just the Makefile)

I mean, a new minor release won't hurt, would it?

Haha. Yes, it does.
Releasing is a MANUAL, laborious process for me at this point.
I will automate it in the future, BUT FIRST I need to know if the general way I am writing FreeBSD ports is good or not.
A simple YES/NO from you would suffice.


TO SUM UP:
1. YOU tell me if my general grasp on FreeBSD ports is a solid one, or if I can improve it.
2. I will then start working on Release 0.60, but that might take some time.
3. It will include the concerns you have raised, but the FreeBSD port for it might (MIGHT!) still contain patches to make it more compatible with the ports system. (Though not as severe as it is at the moment).

Sounds good?

 

[zirias@]

REGARDING THE PATCHES: I took a closer look at both of them. One removed a typo in the manpage, the second one was actually a patch to make the build process compatible with your port system. Thus, I would respectfully request that I may be allowed to keep this technique in the future. I can guarantee you that they will decrease in size, but it will never go away, since I am also creating ports for other Operating Systems as well.
(Btw: The code itself was not patched, really just the Makefile)

Sorry, but this can certainly be done better. Almost all software in ports is not specifically for FreeBSD, and quite often, there are no patches against the build system files (in your case a Makefile) necessary. The key to success is to make everything of relevance (compilers, flags, installation paths, other options, etc) user-overridable on the commandline or through the environment. Then, all it takes for a port is to e.g. set MAKE_ARGS and/or MAKE_ENV if something needs to differ from your upstream defaults for the port.

In a nutshell, it's always possible to have a portable build system for many systems that doesn't require patching, and when the port mantainer is also the upstream author, it makes sense to ask for these changes

BUT FIRST I need to know if the general way I am writing FreeBSD ports is good or not.
A simple YES/NO from you would suffice.

All I can say so far is the port looks perfectly sane. I will also give it some tests of course and get back with details.

 

[dettus]

If you say "It can be done better", it will be done better. Albeit with release 0.60.
That might take me a couple of days though, may I contact you directly once it is finished?

 

[zirias@]

If you say "It can be done better", it will be done better. Albeit with release 0.60.
That might take me a couple of days though, may I contact you directly once it is finished?

Just update the PR . BTW, when you add a new attachment, you get checkboxes to "obsolete" older attachments.

A first test build is running here right now (will take its time as it must build a new rust version first...), will update the PR with the results (plus some really minor stylistic topics).

edit: and if you wonder how the hell rust is necessary for your software, the answer is graphics/librsvg2-rust which is now the default librsvg2-implementation and therefore needed for gtk4.

 

[zirias@]

dettus, just for the fun of it, I converted your project to use my GNU-make based build system here: https://github.com/Zirias/d11amp/commit/9d17f70a7689d2a899df29f55017ea6f0b2c4c8b

It doesn't have built-in support for installing manpages yet, so I hacked that in plain make syntax. And of course this has the drawback to require GNU(!) make, BSD make won't work. Just a little advertising for my project here, it should solve all typical portability issues

edit: don't get me wrong, I really don't suggest you use that, it was really just for fun (and now I know I should add support for installing manpages). There are lots of more advanced build systems (like e.g. cmake) that could do everything. And of course, manually writing portable Makefiles is possible as well, and I really appreciate your effort to do so!

edit2: And I just noticed there's something missing in the default value for MAN1DIR ... oh my, it's late