Lots of people have made cool and useful programs, but they aren't used as much as they should be. Part of the reason is that when presented with two solutions for a problem, a user tends to go for the one that is already packaged and a simple "pkg_add" or "apt install" away, rather than needing to clone a repo from github, install it in some non-standard way and maybe even fix compilation errors. Or maybe they don't even know about your program, because when looking for solutions they just use "apt search".

So, to increase the number of users of nixers software, I want to start a community initiative to start packaging software that appears on http://git.nixers.net.

Here's what I've started doing (and I want others to join in). Anyone who wants their project packaged should make a repo, push it to git.nixers.net and make their desire known in this thread. Then, we go through the projects and:

* Help the authors to clean up platform-specific code
* Try to build and use their software on many operating systems and architectures to find bugs, issues
* And finally, submit packages to Debian, Fedora, {Open,Free}BSD, pkgsrc, etc.

Once a project is packaged for even one distro, it will become a lot easier to package for others since the decisions about where in the filesystem to install files etc. will have already been made. And this will spread the word about nixers.net in the best way possible.

If you would like someone to help package your project, post in this thread and get your project on http://git.nixers.net. I think you have to contact z3bra for that. Or just post your SSH public key as part of your request for help.

If you're willing to help others package their projects, also post in this thread. Include the operating systems you want to make packages for and your SSH public key (if you want access to git.nixers.net). Then make a well named repo (like "freebsd-ports" "debian-packages" or something) and get to work!

I an 100% certain there is demand for the type of software nixers users write: I got 2bwm accepted into the OpenBSD packages very quickly just yesterday. Also this is a great way to give back to the community of whichever OS it is you use.

I can write ports for OpenBSD. My SSH public key is:


The repository I made is http://git.nixers.net/openbsd-ports/log.html. If you want to contribute, please add the thing you're working on to the TODO file, so there's no duplicated work.

(27-07-2017, 01:08 PM)pizzaroll1 Wrote: I an 100% certain there is demand for the type of software nixers users write: I got 2bwm accepted into the OpenBSD packages very quickly just yesterday. Also this is a great way to give back to the community of whichever OS it is you use.

That's great!

I've pushed two projects that might be interesting (or not):

• ascii2svg convert ascii/ansi art to svg
  
• Ricerous A diary-like program to keep track of rice
  

I'm not sure ricerous "update" function still work but for the rest I've been using it every time I've switched machine to keep track and to go through whatever I've customized.

As for the ascii2svg it's a very simple script.

I'm just starting to get into FreeBSD packaging so I'd be happy to help in that regard.

Here's my pubkey

Your key is already in the server. Next time you send a private message, make sure you don't disable them in your account, so people can reply :)

Aww shoot I didn't notice that setting was turned on... Don't I feel sheepish :)

Thanks z3bra

I can help with Fedora packaging although they have some rules for what they accept on their repositories (mostly licensing issues), at least we can have our packages as third-party if not accepted and available for download.

I can package them for crux if your build process is not too complex

I can package for the Arch User Repository.

There are a lot of distros we can package for. Question is, should we create a repo for build files for each distro or should we store these in some `contrib/` directory in the project? Or perhaps we should hide these repos from the main git.nixers.net view?

I don't like exceptions. So I'm not for "hiding" it. I must admit I think the same about it though. At some point we'll have openbsd-ports archlinux-pkgbuilds, alpine-aports, void-srcpkg, freebsd-ports, pkgsrc-ports, .... It will cluter the view for no reason.

I'd go for something less generic than "contrib" though. Something like "packing" or "multi-ports"

How about

yeah that would do it as well

(28-07-2017, 05:34 PM)evbo Wrote: How about
/ports/{openbsd,freebsd,crux}/

I'm down for this one, even like it.

The goal for me is that our ports repos will be transient. Once we package everything and they are added to the OS repositories, there is no need to keep them around: the history of updates etc. will be stored in the version control of the OS you added the package to.

Hence, I approve of literally any scheme of naming the repos, since they will disappear eventually.

Quote:the history of updates etc. will be stored in the version control of the OS you added the package to.

I did not consider that, but that makes a lot of sense.

Well, I don't know how it works for some Linux distros. But for {Free,Open,Net}BSD, Gentoo, the port/ebuild itself ends up in a version-controlled tree with the rest of the ports so there's no point keeping our tree around after it's added.

Debian is a bit weirder, I think, since there's supposed to be a "debian" directory in the source tarball or something? I don't know, really.

(29-07-2017, 09:49 AM)pizzaroll1 Wrote: Well, I don't know how it works for some Linux distros. But for {Free,Open,Net}BSD, Gentoo, the port/ebuild itself ends up in a version-controlled tree with the rest of the ports so there's no point keeping our tree around after it's added.

Debian is a bit weirder, I think, since there's supposed to be a "debian" directory in the source tarball or something? I don't know, really.

.deb packages are cpio archives containing a tarball of the sources, and a bunch of metadata files (or something close to that). RPMs are somewhat similar.

I've pushed a patched up version of thingmenu to the git.
It adds support for Xft and a dotted (eye-candy) background.

Can anyone test it on their machine?

It works on my machine with a few tweaks:

http://ix.io/yW4

The first patch adds X11INC and freetype2 to INCS, this fixes the build on OpenBSD.

The second is optional and removes all of the "echo CC ..." and @ in the Makefile. I don't understand why projects do that, anyway, surely it just makes it harder to see what the invocation was when something goes wrong? I removed it and discovered the reason why it wasn't building, so it's unhelpful to see "CC" instead of the actual command run.

Other than that, it does work with some xft fonts on my system, so you can chalk this one up as a success, I think.

Ok to commit the patches? Thoughts?

(06-08-2017, 10:15 PM)pizzaroll1 Wrote: The first patch adds X11INC and freetype2 to INCS, this fixes the build on OpenBSD.

The second is optional and removes all of the "echo CC ..." and @ in the Makefile. I don't understand why projects do that, anyway, surely it just makes it harder to see what the invocation was when something goes wrong? I removed it and discovered the reason why it wasn't building, so it's unhelpful to see "CC" instead of the actual command run.

This sounds good, thanks for patching the build process.

(06-08-2017, 10:15 PM)pizzaroll1 Wrote: Ok to commit the patches? Thoughts?

Sure go on, commit those.

I decided to package wmutils for OpenBSD and it was committed to the ports tree! Take a look here.

wmutils was written by some members of our community, including z3bra, dcat and many others (including people not from nixers): https://github.com/wmutils/core.

I'll continue porting nixers-related software, window managers, cool utilities, etc to OpenBSD. If anyone wants something ported or has any more ideas on what to port, don't hesitate to:

(a) Do it yourself you lazy fucks

(b) Tell me to do it, I'm happy to help! The only problem is I have no idea how to package stuff for Arch, Debian, etc, only OpenBSD, so you'll have to refer to (a) if you want something packaged for those operating systems.

Is anyone responsible for void linux packaging? If not, I could do that, since I run void on my current machine.

No-one's doing Void yet. Actually we only have stuff for FreeBSD and OpenBSD right now. I'm not 100% familiar with how Void Linux packaging works, but it looks to me (from looking at this) like it's not too complicated. Feel free to start making some packages.

If you can get them added to the main repository in Void, that would be great too: that's the end goal. I don't know how difficult that is, I guess for Void you just send a PR to their GitHub repo.

If you want to know what has been packaged so far, look at the TODO files in the repo. If you want to get push access to the repo, post your SSH key and z3bra (who runs the git AFAIK) will probably add you.

I've already done some packaging, although nothing too serious, for void. And yes, it's done via GitHub, the maintainers are really nice there, and from what I know about them, they shouldn't have a problem with the software,

And for z3bra, or whoever needs it, here's my public key: