Package maintaining

[ghost]

I am currently maintaining ckb-git (based on master) and ckb-git-latest (based on testing) for Arch Linux. What should I do? Replace them with this fork? Create new ones? Wait until the fork becomes more stable and/or more developers join?

[mattanger]

Awesome! At some point in the near future, you may want to change to this fork. @tatokis has been working on getting all of the pull requests merged in. We're also going to be working on getting some of the changes in the other branches merged into master. So, you may want to wait a bit so that we can be sure this fork's master is as stable as it can be.

Also, we're probably going to do a name change so people have and easier time finding this fork and differentiating it.

We can keep this thread open and keep you posted about when we feel that everything is good to go, and I can help out testing any packages if you'd like.

[ghost]

Great, thanks.

[hevanaa]

Hi there. Just wanted to mention that there is a Fedora repository that now has switched to the latest master of ckb-next at https://copr.fedorainfracloud.org/coprs/johanh/ckb/

It has packages for Fedora 24, 25 and CentOS/RHEL 7.

(I've created the Fedora spec and maintain it currently).

[ghost]

@hevanaa hi. Thanks for packaging this repo. Please take a look at #41. Is it okay?

[hevanaa]

Hi. That's Ok.

[ghost]

TODO: update AUR packages.

[ghost]

New ckb-next packages are in the AUR now too:
https://aur.archlinux.org/packages/ckb-next-git
https://aur.archlinux.org/packages/ckb-next-latest-git

[skogsmaskin]

Thank you for fixing the package @light2yellow (ref. https://aur.archlinux.org/packages/ckb-next-git). pacaur has stopped nagging about a new version available now. Looking forward for the next release 👍

[pseudoArchaea]

@light2yellow
Please add qt5ct as a dependency for ckb-next package, the color selection doesn't work without it.

ccMSC/ckb#500

[ghost]

@pseudoArchaea I don't think this is the right decision. Take a look at the Arch Linux thread mentioned in #70 (comment) and other issues here and there, this is clearly an issue around Qt 5.7.x and is not ckb-next's dependency, neither straightforward nor optional.

[mooop12]

@light2yellow ckb-next-git is not buildable, makepkg throws this error:

fatal: No names found, cannot describe anything.
==> ERROR: pkgver is not allowed to be empty.
==> ERROR: pkgver() generated an invalid version:

[fleischie]

This is probably due to git describe, which operates on tags but the repository does not include any tags (in src/ckb-next-git).

Removing the pkgver() function in the PKGBUILD does fix the most superficial issue at hand: makepkg breaks because of no valid pkgver() result.

[ghost]

@mooop12 sorry, we were deleting old tags and forgot about the consequences for packages. Will fix it ASAP. And thanks for reporting!

[ghost]

Both packages in the AUR work again. Moreover, now they follow AUR's guidelines and have a proper version -- 0.2.7 instead of a misleading 0.2.4.

[fleischie]

I'm closing this issue for now as it seems to be resolved. Please open a new one, if the packaging comes up again. 👍

[ghost]

Well, our README tells to contact maintainers or ask questions regarding packaging in this particular issue, so either don't close it or edit the document.

[fleischie]

Well, I'm sorry. Although you cannot blame me for not remembering all that's in the README.md. 🤷

P.S. I wanted to reduce the README.md a little and put more into the wiki. People don't read the README anyway... 😅

[fleischie]

Well, I'm sorry. Although you cannot blame me for not remembering all that's in the README.md. 🤷

P.S. I wanted to reduce the README.md a little and put more into the wiki. People don't read the README anyway... 😅

[ghost]

Yeah, that's a TODO. It also needs to be updated, especially on Known bugs and Troubleshooting. Ironically, a proper TODO (e.g. up-to-date roadmap) is also a TODO.

…

On May 6, 2017, 00:17, at 00:17, Karl Fleischmann ***@***.***> wrote: Well, I'm sorry. Although you cannot blame me for not remembering all that's in the README.md. 🤷 P.S. I wanted to reduce the README.md a little and put more into the wiki. People don't read the README anyway... 😅 -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #5 (comment)

[nazar-pc]

I've just got M65 Pro RGB and would be happy to see Ubuntu/deb package.
Maybe consider openSUSE Build Service? It works for a variety of distributions, you can easily cover most popular ones.

[ghost]

@nazar-pc
@tatokis was going to create an Ubuntu package. It's end of the school year right now, therefore not much activity on the project. Maybe in July :)

[ghost]

@nazar-pc
I'll try following Archwiki instuctions on creation of packages for other distributions, Debian and openSUSE in particular.

@mrueg
Would you be so kind to package this project for Gentoo as well like you did with ckb? The examples of existing packages can be found at https://github.com/mattanger/ckb-next#pre-made-packages

[mrueg]

@light2yellow I was waiting for 0.2.9 to be released (especially due to "ckb is now ckb-next, but the binaries will be renamed in v0.2.9")

[ghost]

Alright, thanks.

[mrueg]

@light2yellow @mattanger any plans for the 0.2.9 release?

[ghost]

@mrueg

Speaking of myself, I'm currently working on CMake as not only qmake is hardly configurable/extensible/leaves a lot of things up to source files, but recently has proven itself as not reliable. When it's ready I was going to make a PR and propose slightly new project structure that will make it incompatible with 0.2.8. We'll see how it goes.

If I understand correctly, the main source of hesitance for you on package creation is that the binaries still collide with the old ckb and there's no real difference. In fact, we can rename them while qmake is still in use, but I'm in favor of a bit more comprehensive approach. If we just rename the binaries, we'd need to edit plists, different resource files etc. Readme will be misleading (not that it isn't a bit outdated already, but still). People will install it and have daemons' interference. I'd rather prefer one-time, but fully integrated component-wise change so that there's a clear step from 0.2.8 to 0.2.9 for example, and not something in-between that requires manual intervention.

But these are just my own thoughts, I'd rather ask @tatokis on it as he is currently the project leader.

[dameikle]

@nazar-pc I took a bash at creating an Ubuntu package (for 16.04,16.10 and 17.04) some time ago when I got my K70, happy to turn this into something more production ready.

[dameikle]

I've added a Personal PPA for the latest release version (i.e. 0.2.8) here. It's my first bit of Ubuntu packaging work so hopefully can get feedback from those using Ubuntu.

I am planning to add a daily build from master now, just trying to figure out Launchpads Bzr<>Git sync to make it easier to maintain.

[dameikle]

I've added a daily build one too here based on a personal fork (so I could add packaging code). Will aim to keep both up to date and will now try to get an official package accepted. Happy for the release PPA to be added in the README.md file.

[tatokis]

@dameikle Since I run Ubuntu, I had some WIP packages, that never saw the light of day. Thanks for your effort, I'll look into it soon and see if I have anything to contribute. Much appreciated.

Just something to keep in mind, we are going to be considerably modifying the paths where ckb-next gets installed, and we'll also be switching to cmake. You can get a rough idea from the cmake branch. So be prepared to have a migration plan for future packages.

[dameikle]

Thanks @tatokis. This is my first Ubuntu package, so any comments / feedback welcome. Brilliant, will take a look at that branch.

[GloriousEggroll]

problems with the Arch linux AUR ckb-next-git PKGBUILD regarding invalid pkgname with %-VCS for cding into src directory.

resolved by changing source=('ckb-next:: to source=('ckb-next-git::

see attached

PKGBUILD.txt

[ghost]

@GloriousEggroll fixed. It worked for me like that, and didn't work for me when being correct, but it turned out to be an incorrect local makepkg.conf configuration.

[Arzte]

Was this supposed to be closed?

[nazar-pc]

Repository was migrated, take a look at readme