Ready-to-use package

[bagage]

It would be super convenient if qjournalctl could be launched without having to build it first. There are (too?) many solutions for that:

• docker
• snap
• flatpak
• .deb etc. packages
• something else?

Thanks!

[pentix]

Hi, I see your concerns 😄

docker: In my opinion not a good practice. We wouldn't use the actual containerization, docker would just serve as a convenient tool to serve us all dependencies. Also setting up docker for a GUI application on the actual target host, is way more complex than just running the autogen script 😅

snap, flatpak: Could be a solution. I lack the experience though as I have never worked with them...

.deb: Supplying distribution-specific packages would of course be super convenient. However releasing .debs would probably force me to release at least .rpms too. Or .xz archives, whatever.
The real burden is actually to keep track of all dependencies amongst all distributions (and their versions). libssh might be libssh-dev in Debian X and libssh3.0-dev in Debian Y, probably requiring me to supply two different .deb files. Possibly it would also be libssh-devel in Fedora, just to add some more variance... That's probably the reason why packagers from said distributions package software for their distribution, because it's easier for them to keep track of the 'meta stuff'. Also, qjournalctl is probably a bit too small to be interesting for packagers...

precompiled binaries would solve the build issues, but are bad practice I guess. Also, no clever way to provide dependencies.

It seems like providing distribution specific packages is the way to go, although it adds quite some 'maintainer work' to the project. I'll try to setup a build system to automate the generation and add the packages later somewhere here... This might take some time, I just wanted to let you know what I was thinking :)

[bagage]

Thanks for the long answer @pentix, I agree with most of it! I never experiencied snap and flatpak but I feel snap could be an intermediate (read easier) way of releasing it. But if supplying deb seems doable for you, then that's perfect!

BTW I tried to installed it manually via autogen.sh, but I had compilation errors with libssh headers (didn't install the custom version you linked in README) thus this issue :).

[pentix]

Hi @bagage

I tried to setup a simple build system to create .deb packages for Debian-based distros. You'll find the results in /packaging.
If docker is already setup on your system, changing to packaging/deb and running make should build qjournalctl_0.6-1.deb. If you find some time, I'd be glad if you try to build it 😊

If you don't feel like building it manually, you can also try my build below. (I had to .zip it for GitHub to accept it 🙄 )

Also I'm not a 100% sure about the Ubuntu/Debian dependencies I provided in the control file, maybe qtbase5-dev is overkill? I couldn't find information on a qtbase5 package...

Thank you very much :)

qjournalctl_0.6-1.zip

[bagage]

I could build the deb via docker, however I face the same actual issue: I don't have an enough recent version of libssh (0.8.0~20170825.94fa1e38-1ubuntu0.2 vs 0.8.7 required) so I cannot install it.

Is there a reason for having a recent libssh version for qjournalctl? Cannot it deal with older versions? (I'm running ubuntu LTS, like many ppl I guess). As it is only useful for remote access, I would be great if it could be an optional dependency and thus be ignored in case of not matching version. I'd personally use qjournalctl only locally.

Anyway, thanks for the quick work, it will still be definitely useful!

[pentix]

Hey, thanks for reporting back! Good thing the docker stuff works 😊

Sadly, yes, there's a reason for using libssh > 0.8.7. I remember trying to get things running with the old versions but it seemed they changed/renamed some (really important) functions of their API, that's when I decided to stick to the new version.

I see this is cumbersome and causes additional trouble for users whose distributions keep old versions in their repositories; I'm not really happy about it. 😅

I think the best thing I can do is to provide detailed instructions on how to get the required version running in a distro that does not ship the current version itself, I really tried to do this. Also, Ubuntu's next release is shipping libssh 0.9.0 so the problem should be fixed in the future...

For the optional dependency, I think that's actually a good idea. It would be nice if qjournalctl would check for the existence of libssh at runtime, I'm not sure how much it takes to get this running everywhere.

I'll definitely keep this open and come back when I find some time. Thank you 😄

[pentix]

Hey, I finally tried to build a flatpak package... It was a bit more involved than I thought, everything builds fine, the files that should be there are there, I finish the build and export the bundled flatpak, installation works well, however running gives me strange errors, as if the built binary was not inside the bundle. (It should be, since it is there in the 'virtual file system' before bundling everything, yet:
bwrap: execvp qjournalctl: No such file or directory

I googled and found that also other system libraries might interfere (yes, they shouldn't...)

If you find some time, could you try the attached flatpak bundle?

flatpak install qjournalctl_v0.6.flatpak should do the trick, again I had to .gzip it, for GitHub to upload it.

The build process is a bit involved, as I'm still figuring out how flatpak works, I couldn't automatize it yet, also it requires manual tweaks in the qjournalctl.pro file, since for a flatpak build paths have to be adjusted (manually again, since auto stuff didn't work out 😂)

qjournalctl_v0.6.tar.gz

[bagage]

Hey @pentix thanks for putting efforts into that :). I tried your tar gz and I end up in the same dead-end bwrap: execvp qjournalctl: No such file or directory.

I have no experience with developping flatpak buildfiles but also poor experience with flatpak in general. I tend to think that snap is much more stable and polished - but no dev experience with it either :/. Anyway, I'd glad to help if I can (at least for testing!). Thanks 👍

[pentix]

Sorry for letting you wait, I tried to look into snap but did not have the time yet to setup a demo environment. (Also a stupid hardware failure took a lot of my time 😅 But I definitely think those packages are a good idea, so I will keep on trying 😄 )

I'll keep you updated 😉

[bagage]

Sure no rush, I managed to install it manually for now 😉.

[pentix]

I agree with snap being much more stable and polished and I may finally present some results here 😄

Again, only running make (in the packaging/snap directory) should be sufficient.

In the snap branch referenced above I added a snapcraft.yaml file which gets copied into a temporary Ubuntu docker instance, gathering all dependencies, running snapcraft and then building and snapping libssh+qjournalctl.

Interestingly this seems to be somewhat non-deterministically, as the resulting snap sizes differ every time in a few MB. Also, after building the snaps several times, snapcraft came up with new errors 😄

It would be nice to hear if you can build and install the resulting snap.
Network utilization is heavy since it's basically emulating Ubuntu twice and has to get all dependencies right, also the build takes ~ 6 minutes 🙄

No rush, if it's not possible I'll try to test it somewhere else.

[bagage]

I had a first error regarding a debian package that couldn't be downloaded:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/llvm-toolchain-8/libllvm8_8-3~ubuntu18.04.1_amd64.deb  Undetermined Error [IP: 91.189.88.173 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

I retried (because it probably was just a network error) and then I got an error that a docker container already existed:

docker run --rm -id --workdir=/snap --name=qjournalctl-snap --volume=/home/gpelloux/perso/qjournalctl/packaging/snap:/out ubuntu
docker: Error response from daemon: Conflict. The container name "/qjournalctl-snap" is already in use by container "31d1e16647dcbca1fad17a06491e4d75307f75b8ab305617df2ecf30427a95f6". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 125

So I removed that one with docker rm 31d1e16647dcbca1fad17a06491e4d75307f75b8ab305617df2ecf30427a95f6

Then I rerun make again and it worked 👏. However when running snap install qjournalctl_0.6_amd64.snap, I'm getting a metadata signature error:

error: cannot find signatures with metadata for snap "qjournalctl_0.6_amd64.snap"

But I believe we're not far away!

edit: Ok actually regarding SO, I have to use snap install --dangerous qjournalctl*snap because it's a non signed package which is fine. But it is not sandboxed so I also have to use --classic.

[bagage]

OK I managed to install it but when running qjournalctl it hangs, doing nothing? even --help or --debug just hangs.

[pentix]

Hey, thanks for your fast feedback :)

I definitely need to look into the meta part of snap, i.e. setting meta data correctly
and signing stuff, afterwards I might even push it to the snapcraft store...

I guess I had to define classic somewhere, so it would have access to the the network and actually be able to run software (journalctl) in a non-isolated way; maybe there's a better option to this.

Oh no... Might not be that easy then.. Let me experiment some more with snap then, I thought it would work when running inside the box. I'll try to reproduce this as soon as I have access to "solid hardware and network". Sorry for the inconvenience, but thanks again for your early feedback!

[pentix]

The GUI is running fine now and seems to have access to all system resources.
I'm not sure whether the classic isolation mode prevented it from running properly,
additionally it needed some more X11 libs to be present, also GUI need "additional" additional
treatment for accessing X resources, also additional Qt5 stuff is required.

The result is a build time of ~ 10 minutes and a resulting snap of 103MB 😅

I'll try to strip this down, e.g. trying to remove snap dependencies again, but you might already try
to build and run it now, if you wish :)

(I started ~ 15 builds in the past hours, none of them actually showed those 'arbitrary' network errors, it seems to run fine...)

It worked after installing in devmode
snap install --dangerous --devmode qjournalctl_0.6_amd64.snap

Maybe classic would be sufficient
snap install --dangerous --classic qjournalctl_0.6_amd64.snap

Edit: this does not work:
error: snap "qjournalctl_0.6_amd64.snap" requires devmode or confinement override
I couldn't find how to force the override...

[pentix]

As it seems it's currently not possible for me to run QJournalctl in classic mode. Something is restricted and the application won't start, other users seem to be affected by the same strange behavior: (https://forum.snapcraft.io/t/failed-to-launch-apps-with-classic-confinement/5181)

However I managed to remove some redundant libraries and reduce the snap to 84MB.

[bagage]

Thanks to your latest fixes, I can now indeed install and launch qjournalctl 👍 🎉. Via ssh works too, that's awesome!

[bagage]

One thing that I see missing yet, it's the application menu entry (.desktop or equivalent): qjournalctl does not appear as an available application, you have to start it manually.

[pentix]

Sounds cool, great it finally works :)

Oh, I didn't know snapcraft would add application starters, but it seem I'll have to add a additional entry.

(Only for later reference: https://forum.snapcraft.io/t/automatically-copy-desktop-file-to-local-share-applications/4427)

I'll try to do this next. Also it seems as I have to fix the CI as well 😅

[pentix]

@bagage As far as I understood the .desktop file should now be included and be properly referenced in the snapcraft configuration. I can't really test this, as it's built/installed anyway on my system...

Does this fix your issue? 😄

[bagage]

I'm getting an issue about desktop file:

Failed to generate snap metadata: The path '/usr/share/applications/qjournalctl.desktop' set for 'desktop' in 'qjournalctl' does not exist. Make sure that the files are in the prime directory.
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 2

[pentix]

Thanks for trying to build the snap!
I did not encounter this error when building the snap on my system, I think it depends on the host.

I'm trying to not use a dockered Ubuntu for the build, let me see how this works out...

[pentix]

Hi @bagage

I desperately spent some time on trying to get the snap build setup running again, it seems like I had to reconfigure a few dependencies and it seems as building snapd as well as building the actual snap package in the docker container doesn't really work for me anymore / right now...

I really wanted to provide a .snap for the latest release :/ In case you want to look into this, I pushed some changes to the snap branch :)

[bagage]

Thanks for keeping me informed @pentix :). For now, I've been using the version I built manually and had been happy with that - I think others might enjoy it too!
I'm not sure I'll find time right now to dig into that, but I keep it in mind.