Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate RPM packages #2757

Merged
merged 1 commit into from Aug 11, 2019

Conversation

@HebaruSan
Copy link
Member

commented May 9, 2019

Motivation

We generate .deb files as of #2187, but users of Linux distributions that aren't Debian-derived have to use the plain ckan.exe file. This means they miss out on:

  • Having ckan in the system $PATH
  • Having a ckan icon in the system app menus
  • An out of date man page
  • Falling back to ConsoleUI if $DISPLAY isn't defined

Some users may even assume that the lack of an .rpm file means they can't use CKAN, even though they can.

Changes

Now we also generate .rpm files, so Fedora users can enjoy the above benefits. This is done with a simple Makefile and a .spec file, sharing a few files with the .deb package. The build system is updated to include the .rpm file as a release asset.

To try it via the command line:

./build rpm

Fixes #2748.

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

@enderger, could you please try this test build and report any problems you have with it? I don't have an RPM-based distro available for testing.

  • (link removed)
@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

I will do so at home. It may take awhile, given the upcoming potential flooding.

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

YAST claims that the package is unsigned.

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

Can you bypass that? It's definitely unsigned, since I just compiled it for this test.

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

No other issues occur during install. YAST sees the dependences and I told the package manager to ignore the "error".

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

The thing loads, but seems to think that the run uses Windows 95.

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

Screenshot_20190509_172307

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

Test launch works

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

Yup, that's what WinForms apps look like. Thanks for checking it out!
Mind opening a terminal and confirming that "man ckan" prints the man page?

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

Man page works:
Screenshot_20190509_172935

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

Screenshot_20190509_173210

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

That field's label is incomplete

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

Can you show us? Maybe there's a font difference that's affecting the alignment:

image

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

That's the entire text string

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

OK, but we can't fix it if we can't see the problem :)

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

Screenshot_20190509_174049

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

Huh; all of your labels are being truncated by one word. That's weird, because they all have AutoSize set to true, so they should all be sizing to fit the text.

image

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

This is happening on KDE, I'll try with a DEB install in a VM

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

Out of curiosity, which version of Mono are you running (mono --version)? If it happens to be an old one, maybe this was a bug that got fixed at some point.

@DasSkelett

This comment has been minimized.

Copy link
Member

commented May 9, 2019

This is happening on KDE, I'll try with a DEB install in a VM

I'm using KDE too, and it's working for me. (Not installed with the rpm, but I don't think that's the cause.)

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

The one listed in the DEB. It was autoinstalled with CKAN

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented May 9, 2019

The .deb and .rpm packages don't specify a precise version for the mono dependency; which one is installed on your system?

@enderger

This comment has been minimized.

Copy link

commented May 9, 2019

5.10.1.47

@DasSkelett

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

Bugreport closed:

The problem is, that we cannot build csc.exe from source yet. This would require Roslyn, msbuild etc. I hope when the effort to bring .NET Core into Fedora succeeds, then msbuild and csc will be available in Fedora as well. [...]
I cannot find the exact sentence in the packaging guidelines at the moment, but I know we are not allowed to use binaries, that have not been built in Fedora, except for bootstrapping.

I think we both kinda expected this.

But it sounds like there's something going on to bring .NET Core to Fedora, this might allow them to build csc from source (is it even Open Source?).

So I myself now go ahead and install rpm on my main system, this should allow me to build rpms. Then I can test it in the Fedora VM.
For possible future contributors/users who want to build the rpm themselves,
should I add a note to https://github.com/KSP-CKAN/CKAN/wiki/Build-Environment?

@DasSkelett

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

Okay this is weird.

user@localhost CKAN]$ sudo rpm -i *.rpm
Error: Failed dependencies:
	mono(system) = 2.0.0.0 is required by ckan-1.26.3-1.noarch
	mono(System.Transactions) = 2.0.0.0 required by ckan-1.26.3-1.noarch
	mono(mscorlib) = 2.0.0.0 is required by ckan-1.26.3-1.noarch

So the only change is that mono is no longer on that list.
Querying the dependencies of the rpm file returns this (arrows added by me):

[user@localhost CKAN]$ sudo rpm -qp --requires *.rpm
/bin/sh
mono(Microsoft.CSharp) = 4.0.0.0
mono(System) = 2.0.0.0                <---------
mono(System) = 4.0.0.0
mono(System.Configuration) = 4.0.0.0
mono(System.Core) = 4.0.0.0
mono(System.Data) = 4.0.0.0
mono(System.Drawing) = 4.0.0.0
mono(System.Numerics) = 4.0.0.0
mono(System.Runtime.Serialization) = 4.0.0.0
mono(System.Transactions) = 2.0.0.0    <---------
mono(System.Transactions) = 4.0.0.0
mono(System.Web) = 4.0.0.0
mono(System.Windows.Forms) = 4.0.0.0
mono(System.Xml) = 4.0.0.0
mono(System.Xml.Linq) = 4.0.0.0
mono(mscorlib) = 2.0.0.0               <---------
mono(mscorlib) = 4.0.0.0
mono-complete
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

So it is asking two times for those three libraries, one time an older version.
I can't read anything like this out of rpm/ckan.spec...

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 8, 2019

OK, I set up a Fedora guest under VirtualBox. Any idea how to make it mount the shared folder I configured so I can access the generated RPM file? Host:

image

Guest:

[osboxes@localhost log]$ lsmod|grep vbox
vboxguest              45056  4
vboxvideo              40960  2
drm_kms_helper        212992  1 vboxvideo
ttm                   114688  1 vboxvideo
drm                   491520  5 drm_kms_helper,vboxvideo,ttm
[osboxes@localhost log]$ ls /ckan
[osboxes@localhost log]$ mount|grep ckan
[osboxes@localhost log]$ sudo mount -t vboxsf CKAN /ckan
/sbin/mount.vboxsf: mounting failed with the error: No such device
[osboxes@localhost log]$ sudo mount -t vboxsf ckan /ckan
/sbin/mount.vboxsf: mounting failed with the error: No such device
@DasSkelett

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

OK, I set up a Fedora guest under VirtualBox. Any idea how to make it mount the shared folder I configured so I can access the generated RPM file?

I have no idea. I tried everything you mentioned too, and the folder is always created, but it's empty.
Neither does copy-pasting files work, only text.
VB guest additions seem to be installed, and clipboard/drag-and-drop are set to bidirectional, but nothing of that works.

I ended up using the file transfer tool of VirtualBox (under Machine > File Manager or something like that).

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

The file manager's Create Session button does nothing for me, not even an error message. :(

@DasSkelett

This comment has been minimized.

Copy link
Member

commented Jun 9, 2019

The file manager's Create Session button does nothing for me, not even an error message. :(

With your guest system credentials entered? Hmm...
Guest additions are installed? (Should be by default with the normal Fesora Workstation edition)

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

OK, I may have broken it by installing from my VirtualBox's ISO. /var/log/vboxadd-setup.log says:

VBoxClient: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

... and presumably the built-in version would be linked correctly.

Hmm, no. It's the Fedora package; no change after uninstall and reinstall.

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

Ah! I had the username wrong! It's "osboxes", but it's displayed as "osboxes.org" in most places so I was trying that. File manager working now.

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

user@localhost CKAN]$ sudo rpm -i *.rpm
Error: Failed dependencies:
	mono(system) = 2.0.0.0 is required by ckan-1.26.3-1.noarch
	mono(System.Transactions) = 2.0.0.0 required by ckan-1.26.3-1.noarch
	mono(mscorlib) = 2.0.0.0 is required by ckan-1.26.3-1.noarch

I believe those are "automatic dependencies":

https://rpm.org/user_doc/more_dependencies.html

Automatic Dependencies

To reduce the amount of work required by the package builder, RPM scans the file list of a package when it is being built. Any files in the file list which require shared libraries to work (as determined by ldd) cause that package to require the shared library.

So rpmbuild is scanning a Debian system for things it might need on Fedora and confusing the heck out of itself in the process. I've just pushed a commit that hopefully turns that off (and depends on mono-core instead, since I think we're not supposed to depend on mono-complete just like on Debian). You might need to run ./build rpm-clean to make sure these changes are applied. I can now install the CKAN RPM, but I get certificate errors running it, so I'm going to see whether the old solutions to that help...

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

Added a post-install script to sync the certs, since that fixed the errors I was seeing.

@DasSkelett

This comment has been minimized.

Copy link
Member

commented Jun 9, 2019

Yep, I can give a go for the rpm on Fedora.
Now installs fine even without preinstalled mono via the Software application and/or yum.
The rpm command can't install dependencies for you, but a clear needs mono-core >= 5.0 is returned, so everybody using that should now what to do.

@enderger

This comment has been minimized.

Copy link

commented Jun 9, 2019

If issues persist, maybe opensuse may have better luck(Tumbleweed seems up to date)

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

The issues are fixed on Fedora now, but testing on openSUSE as well is a good idea, downloading VM now...

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

@enderger, your display issues are caused by font hinting.

https://stackoverflow.com/a/445063/2422988

I saw the same problem initially on my openSUSE VM. I installed Fontweak and unchecked this checkbox:

image

And now it works as expected:

image

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

It seems that changing the hint style to full works as well:

image

The default for me was a hint style of 'none' with the checkbox enabled. I suspect that Mono auto sizes its labels based on the hinting checkbox, but when it renders them the hint style 'none' makes the font larger than expected.

@enderger

This comment has been minimized.

Copy link

commented Jun 9, 2019

Just made a bug report

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

So @enderger have you confirmed that changing the setting to hintfull fixes it for you?

I already have a copy of the mono source, so I might look into submitting a fix for this...

@enderger

This comment has been minimized.

Copy link

commented Jun 9, 2019

I had to change to a different linux distro after my wifi driver went kaput

@enderger

This comment has been minimized.

Copy link

commented Jun 9, 2019

The labels work on the new install, though

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jun 9, 2019

@enderger So what distro are you using now? Still RPM-based? Are you installing via the RPM?

@enderger

This comment has been minimized.

Copy link

commented Jun 10, 2019

I went with mint, as it works with my wifi card more easily than rpm distros. I can’t move off until the card driver gets better

@Olympic1

This comment has been minimized.

Copy link
Member

commented Jul 18, 2019

@enderger Have you had some time to test this?

@HebaruSan

This comment has been minimized.

Copy link
Member Author

commented Jul 23, 2019

@Olympic1, I think he switched to a non-RPM distro (Linux Mint is based on Ubuntu is based on Debian), so he can't test this anymore. It looked good on my Fedora and openSUSE VMs though.

@HebaruSan HebaruSan force-pushed the HebaruSan:feature/rpm branch from 951e70b to c5e6e92 Aug 9, 2019
Copy link
Member

left a comment

I'm approving this now. I didn't test it on OpenSUSE, but we should be okay. If it doesn't work on real machines as opposed to VMs for whatever reason, it's no big issue, nothing relies on it, there are the old ways of installing until we fix it.

@HebaruSan HebaruSan merged commit c5e6e92 into KSP-CKAN:master Aug 11, 2019
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
HebaruSan added a commit that referenced this pull request Aug 11, 2019
@HebaruSan HebaruSan deleted the HebaruSan:feature/rpm branch Aug 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.