Ubuntu 20.04 package

[PhilippGackstatter]

It seems the libelektra package is not available on 20.04. It would be great to have it, regarding this issue for the rust bindings.

If it can't easily be published in a timely manner, then I'd suggest to let them remove the package, which means publishing a new version of the rust bindings would not automatically generate docs.
It's not a big deal at the moment, since there is not much activity for the bindings anyway.

If the package can be published to 20.04 repos at a later point, I assume I could ask them to readd it at that point.

So just let me know, if there are currently any plans to add it?
Thanks

[markus2330]

Yes, we want to build Ubuntu packages #2924 and it should not be a big deal to build several versions of it.

@Mistreated what is the status?

[markus2330]

https://wiki.debian.org/DebianRepository/Setup

[PhilippGackstatter]

Seems like this won't be fixed in a short-term time frame. I'll let them know that they can remove the package for now, unless anyone disagrees. I can ask them to readd it, once we've built the packages.

[markus2330]

@Mistreated is already working on it. @Mistreated do you already have an idea when it will be finished?

[dbulatovic]

I already set the repository, need couple of more things to get implemented. Plan is to be implemented this week.

[markus2330]

Great, what is missing?

[dbulatovic]

As soon as master builds the packages, I will put them into the repository and I just need to make the repository public. All will be in the written in the docu as soon as its done.

[mpranj]

@Mistreated will the packages then be based on current master (development version) or the last released version?

[markus2330]

In the (previous) setup it was like that every build of the current master overrides the packages from the previous build. To keep the packages of, e.g., the release, they need to be copied manually to some other place.

The idea of #2530 was to have an extra pipeline, which does all these copy/archive/logging jobs automatically. @Mistreated did not answer yet what of it he will do.

[mpranj]

I just took a look, yes, seems like things are simply overwritten. Interestingly there are currently only debian packages and no bionic packages. There is no real order in the jenkinsfile so it seems that bionic packages would overwrite the debian packages and vice versa depending on the timing (who wrote last to the repo).

If it is possible (and easy) I am also for simply keeping one debian repo for all dists (including ubuntu). If it can be moved away from a7, even better. The community server has much more bandwidth available.

[dbulatovic]

There is no real order in the jenkinsfile so it seems that bionic packages would overwrite the debian packages and vice versa depending on the timing (who wrote last to the repo).

I am gonna make publishing of bionic to community.

If it is possible (and easy) I am also for simply keeping one debian repo for all dists (including ubuntu). If it can be moved away from a7, even better.

I will look into it after I deal with the bionic packages.

[mpranj]

@Mistreated the Jenkinsfile changes are on master. One build failed (without apparent reason) so I triggered a rebuild. Seems nothing was pushed to community.

[dbulatovic]

My bad there, this PR should fix it.
#3429

[mpranj]

Seems to work now but the absolute path was not taken so everything was dropped to /srv/libelektra/srv/repositories/incoming/ instead of /srv/repositories/incoming/.

[dbulatovic]

the absolute path was not taken so everything was dropped to /srv/libelektra/srv/repositories/incoming/ instead of /srv/repositories/incoming

Probably because doc.libelektra.org refers to /srv/libelektra.
Gonna take care of it in the next PR.

[dbulatovic]

Packages are in place.. The only thing needed is to make the repository public. I made a template conf file on community: root/bionicNginx.conf. It needs to be binded with the DNS of your choice @mpranj @markus2330.

After the repo is made public I can write instructions of how to use them in doc/INSTALL.md file.

[mpranj]

@markus2330 can you create an entry for ubuntu-bionic-repo.libelektra.org (or similar) pointing to community?

@Mistreated thank you so much! 🥳The community server is running apache afaik. Can you configure it there once the DNS entry is set?

[markus2330]

I made ubuntu-bionic-repo, ubuntu-eoan-repo, ubuntu-focal-repo, ubuntu-groovy-repo all pointing to 95.217.75.163 (community).

[markus2330]

@raphi011 can you check if the Ubuntu packages work (in your CI of the go-binding repo)?

Docu is available here: #3430

[raphi011]

The travis build is failing. You can see the log here

Executing: /tmp/apt-key-gpghome.c7YMux36RL/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys D919CE8B27A64C16656FCA9FF1532673651F9C6C
gpg: keyserver receive failed: No data

[dbulatovic]

I get this output:

Executing: /tmp/apt-key-gpghome.fOMZJN6tch/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys D919CE8B27A64C16656FCA9FF1532673651F9C6C
gpg: Total number processed: 1
gpg:              unchanged: 1

[raphi011]

Where are you running this? Do you have any idea why this could fail on the travis host?

EDIT:
I've restarted the build and it worked. I've found a few ppl that had the same problem with this command in combination with travis.

To my surprise everything else worked on the first try as well. The go tests were run and are green!

https://travis-ci.org/github/ElektraInitiative/go-elektra/builds/684394127

[mpranj]

I've generally had a bad experience with gpg keyservers. Maybe we could avoid this by providing the gpg key on our own server simply over https.

[markus2330]

Yes, providing the key (also) via https sounds like a good solution here.

[markus2330]

@PhilippGackstatter we now have 20.04 packages, done by @robaerd. What are the requirements for them? Do they simply need a repository with our debs or does it need to be a PPA?

[PhilippGackstatter]

They have a packages.txt which contains the additional packages required to build some crates' documentation and then in their Dockerfile they just do apt-get packages.txt. So to add it back I would add libelektra-dev to that packages.txt. So as long as apt-get libelektra-dev works in a plain focal docker image, it's fine. I don't know a lot about packaging, but I think for that to work it needs to be in the "official" focal repositories, but correct me if I'm wrong.

[mpranj]

I'm afraid a current version of Elektra is not in the official repositories. The ubuntu bionic repositories are hosting Elektra 0.8.14 which was released in 2015. The problem is that we can not directly influence this.

I took a quick look at what they do and yes, it seems they only use official repos. In that case we can't do much about it.

[markus2330]

The trouble seems to be that Ubuntu LTS versions fork from Debian testing and not sid. The version in Debian sid (0.8.14-5.1) we can probably get into Ubuntu by explicitly requesting a sync: https://wiki.ubuntu.com/SyncRequestProcess

But then we would get this super-old version into Ubuntu which is of little use? @PhilippGackstatter can you elaborate what exactly happens with this installed package? It was also outdated before, wasn't it?

If we need a more current version, we need to get our latest version into Debian first (the direct ways to Ubuntu do not make sense for Elektra). But this probably doesn't make sense before 1.0.0.

I think our options are:

• make crates-build-env install from our repo, then we can get the latest versions [preferable option]
• requesting Ubuntu 20.04 to sync Elektra from sid: then we would be stuck with 0.8.14-5.1 for the crates until we get something into Debian again.

[PhilippGackstatter]

Whenever a new version of the Rust bindings is published to crates.io, documentation will automatically be built for it. Since the elektra crate depends on elektra-sys, which generates bindings from kdb.h as it is built, it needs the libelektra-dev package. If the package is missing, none of the documentation can automatically be built and pushed to docs.rs. That's the go-to place for Rust documentation, however the docs can also be built locally in a straightforward way, so it's not the only option. It's more of a usability thing.

make crates-build-env install from our repo, then we can get the latest versions [preferable option]

It seems to me that changing their current package setup for just one package isn't reasonable. It would just make their setup more complicated. And they write that the way to add dependencies is through packages.txt.

until we get something into Debian again.

Wouldn't the best solution be to always have the latest version of elektra in the debian repos? Again, I don't know a lot about packaging other than that it's hard, but it seems that would be the choice for users in the first place.

[mpranj]

Wouldn't the best solution be to always have the latest version of elektra in the debian repos?

It would, but we are not the ones who decide about packages in Debian repos. Since Elektra is not yet widely adopted, Debian maintainers are in no hurry to package Elektra at all.

[markus2330]

Is there maybe a possibility to build the docu (without bindings) without having libelektra-dev installed? Our build system is perfectly capable of having BUILD_FULL, BUILD_SHARED and BUILD_STATIC off (means not building any source) but BUILD_DOCUMENTATION having still on. As a matter of fact we use this to build the doxygen docu.

It's more of a usability thing.

So it is only about getting it uploaded automatically, not about having it there at all. Maybe doing it manually is the best option, as we do not release every week a brand new API.

[PhilippGackstatter]

It would, but we are not the ones who decide about packages in Debian repos. Since Elektra is not yet widely adopted, Debian maintainers are in no hurry to package Elektra at all.

I see. Then maybe we can wait until we have a version 1.0 and add that package to debian. Once 1.0 is released, the API should be stable and future updates to the rust bindings should work with that version.

Is there maybe a possibility to build the docu (without bindings) without having libelektra-dev installed?

I don't think so. Building the docs requires that the package itself can be built.

So it is only about getting it uploaded automatically, not about having it there at all.

I should have been clearer I think. What I mean by, "the docs can be built locally", is that a developer using the Rust-bindings can easily build the documentation for herself, since all dependencies must be there anyway.

Uploading them to docs.rs manually is not possible afaik, it's only possible through the automated build process.

Overall I think we should reevaluate the situation once 1.0 is out or a new update of the Rust bindings is released, whichever comes first. It seems there's no good solution right now and it's not an urgent issue.

[markus2330]

Ok, let us reopen the issue when a new version of Elektra gets into Debian again.