Page MenuHomeSolus

Initial commit of Jekyll
Needs ReviewPublic

Authored by kmdodrill on Aug 4 2019, 10:05 PM.

Details

Reviewers
None
Group Reviewers
Triage Team
Summary
Test Plan

Install the package and run jekyll new test && cd test && bundle exec jekyll serve. Go to the link and check that things are working. cd _posts and make a change and reload to be sure that things check out.

Diff Detail

Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage

Event Timeline

kmdodrill created this revision.Aug 4 2019, 10:05 PM
kmdodrill requested review of this revision.Aug 4 2019, 10:05 PM
kmdodrill retitled this revision from Initial commit of jekyll to [RFC] Initial commit of jekyll.Aug 4 2019, 10:11 PM

Thanks for the patch!
Please reopen T6492 so that it can go through the proper task lifecycle, as you stepped in to be the maintainer of Jekyll. Also, be sure to include a file called MAINTAINERS.md with the following content:

This file is used to indicate responsibility for the maintenance of this package. Individuals on this list should be the sole modifiers of the package, excluding cases where the Solus Team may need to perform necessary rebuilds, upgrades, or security fixes. This list should not be used for any direct contact usage. If you believe this package requires a package update, follow documentation from https://getsol.us/articles/packaging/request-a-package-update/en/. In the event this package no longer becomes sufficiently maintained, Core Team reserves the right to request a new maintainer or remove this package from the repository.

- First and last name
  - IRC: you nickname on IRC
  - Email: your email address

Regarding your test plan, well, you surely test Jekyll on Solus, but you should be more specific about the tests you performed. It doesn't need to be elaborated, just a few steps will do it.

package.yml
15

setup phase is empty, thus it can be removed entirely.

Thanks for the patch!
Please reopen T6492 so that it can go through the proper task lifecycle, as you stepped in to be the maintainer of Jekyll. Also, be sure to include a file called MAINTAINERS.md with the following content:

This file is used to indicate responsibility for the maintenance of this package. Individuals on this list should be the sole modifiers of the package, excluding cases where the Solus Team may need to perform necessary rebuilds, upgrades, or security fixes. This list should not be used for any direct contact usage. If you believe this package requires a package update, follow documentation from https://getsol.us/articles/packaging/request-a-package-update/en/. In the event this package no longer becomes sufficiently maintained, Core Team reserves the right to request a new maintainer or remove this package from the repository.
- First and last name
  - IRC: you nickname on IRC
  - Email: your email address

Regarding your test plan, well, you surely test Jekyll on Solus, but you should be more specific about the tests you performed. It doesn't need to be elaborated, just a few steps will do it.

Hi! Thanks so much for the quick response. I'll get that updated here soon. As for testing, I am unsure how that really works, so I just put a placeholder comment there. Because jekyll is a ruby gem, would being able to run jekyll suffice as a test? Or is there more to it?

Also, I understand that making the package will create the jekyll.eopkg...Do I need to install that to test? Or when making the package, does it install everything?

Sorry for the confusion - only started this all today! :)

kmdodrill updated this revision to Diff 16492.EditedAug 4 2019, 10:39 PM

Add maintainer file and remove setup phase from package.yml

Yeah, install the generated .eopkg file and try to render a super simple website; say some markdown and template syntax.
This is just an example, I don't know Jekyll:

# Test
## This is a simple test
{% variable %}
kmdodrill added a comment.EditedAug 5 2019, 11:11 PM

@livingsilver94 Hi there, thanks for the info! I've been trying to install and test - looks like Jekyll requires some additional gems in order to function correctly. Would it make sense to make Solus packages for these deps?

https://rubygems.org/gems/jekyll/versions/3.8.6

EDIT: Found this - https://koji.fedoraproject.org/koji/rpminfo?rpmID=18395108. I'm guessing that this is what I would need to do (build each package and submit to Solus).

Found this - https://koji.fedoraproject.org/koji/rpminfo?rpmID=18395108. I'm guessing that this is what I would need to do (build each package and submit to Solus).

Correct. You have to package and submit every dependency if not already in the repo.

@livingsilver94 Does it make more sense to name this package ruby-jekyll to conform with other ruby gem packages on Solus?

Also, what do I do if I need an older version of a package that is already in the repository? I need this package: https://dev.getsol.us/source/ruby-i18n/repository/master/ , but an older version of it (0.9.5).

https://github.com/jekyll/jekyll/blob/master/jekyll.gemspec#L39 should be working and you cannot get an older version and we not going to downgrade stuff

@Girtablulu Okay, understood. Apologies if it seemed like I was trying to force a change or anything - just looking for information. :)

Am I incorrect in thinking that I should change the source to https://rubygems.org/gems/jekyll ? I have been looking at a bunch of other ruby gems packages on here and notice that they use rubygems.org as the source.

I was unable to use the tar.gz to get jekyll working - is this because the source should be pointing to the gemspec blob you linked above?

Thank you for the help.

livingsilver94 added a comment.EditedAug 9 2019, 1:33 PM

@livingsilver94 Does it make more sense to name this package ruby-jekyll to conform with other ruby gem packages on Solus?

No, I'd say no. We put the language prefix in the case the package is a library for that language. Jekyll instead is an end-user application, so I'd just call it jekyll.

@livingsilver94 Gotcha, that's what I was thinking but just wanted to check. Thanks!

livingsilver94 added a comment.EditedAug 9 2019, 1:40 PM

Ah, I forgot to say: add Fixes T6492 somewhere in the summary, so that when your patch gets accepted, T6492 will be automatically closed as resolved.

kmdodrill added a comment.EditedAug 9 2019, 7:46 PM

@Girtablulu After doing some testing I've found that the .gemspec fails on https://github.com/jekyll/jekyll/blob/master/jekyll.gemspec#L17.

When building gem from source (the .tar.gz), it errors out there, saying fatal: not a git repository (or any of the parent directories): .git, which of course makes sense because it is not initialized with git.

It does, however, continue to build the gem and install it when using make.

Any ideas on how to fix this?

EDIT: Okay, I've edited my package.yml to include a git source for jekyll. So now it will build properly...however, I'm still at my previous issue that it requires deps that aren't in Solus. I'm still getting errors when running the jekyll command after install that it's looking for it's deps but can't find them.

EDIT 2: Okay, I've switched off of the %gem_install macro because it is set to not install dependencies. After testing using debug, verbose, and backtrace when trying to install the gem, it seems like the source rubygems.org is somehow invalid or does not work. I'm getting the error:

Exception Gem::RemoteFetcher::UnknownHostError' at /usr/lib64/ruby/2.6.0/rubygems/spec_fetcher.rb:269 - no such name (https://rubygems.org/prerelease_specs.4.8.gz)

The source definitely exists, I've even tried removing and re-adding it before gem install. I've looked it up and found that I would need to update rubygems - I've tried gem update --system, but that just brings about the same error.

livingsilver94 added a comment.EditedAug 13 2019, 11:42 AM

@kmdodrill the build environment (solbuild) is set to have networking disabled by default. While you can change this behavior, it's better to have one gem per package instead of having the jekyll package with many gems included. Well, unless the jekyll's deps are a ton. Do you know how many gems it needs?

@livingsilver94 Jekyll has quite a few runtime deps, here's the rubygem link to view them: https://rubygems.org/gems/jekyll.

I have actually already packaged all of the other deps listed there that are not already available on Solus.

However, like I mentioned above, I need a specific package (i18n), but an older version (nothing above 0.X).
The ruby-i18n package on Solus is on the 1.1.1 version, which will not work for Jekyll and will result in a dependency error when trying to run the jekyll command.

I didn't realize that solbuild had networking disabled by default - I guess I should turn this on in order to get the correct packages? Otherwise, I'm not sure how I would package this up. I would greatly appreciate a link to allowing networking when building a package.

I didn't realize that solbuild had networking disabled by default - I guess I should turn this on in order to get the correct packages? Otherwise, I'm not sure how I would package this up. I would greatly appreciate a link to allowing networking when building a package.

you would add networking : yes to package.yml.
Take a look at libreoffice or some other complicated packages to see an example.

kmdodrill added a comment.EditedAug 13 2019, 10:59 PM

@davidjharder Thank you! That helps a lot.

With that, the gems do install correctly, but I've run into another problem. What if someone has one of the dependencies (that are available on Solus) installed? When they try to then install the jekyll package, it will error out with file conflicts, making it impossible to install the package.

What is the best way around this?

So far, I've thought of:

  • EDIT: The best thing I think of right now is to add lines in the install key to do gem install dep and then just use rundeps for the ones we currently have.
  • Having the gems install to a different directory - but this doesn't make sense in the case of having all of our gems in one location so other gems can access them. As dependencies of the jekyll package, it sort of makes sense, but I don't think that's enough.
  • Remove the conflicting packages on the users' computer before installation - is this doable? It doesn't sound like good practice to me.
  • Hope that the user has enough knowledge to understand the file conflicts and will deal with it themselves. Obviously I would like to avoid this.
kmdodrill updated this revision to Diff 16658.Aug 13 2019, 11:43 PM

Update package.yml to my most current implementation

kmdodrill edited the summary of this revision. (Show Details)Aug 13 2019, 11:46 PM
kmdodrill edited the test plan for this revision. (Show Details)
kmdodrill marked an inline comment as done.Sep 23 2019, 12:14 AM

@livingsilver94 Hi there, sorry this has not been updated in awhile. I recently found a new job and had some issues with moving. Now that I am all settled in -

Jekyll has been updated and the dependencies are now different. I believe that it should work with the packages that I will soon be submitting. The version of i18n in Solus's repo should work for this version. :)

I'll update this soon, I'm going to try and get everything working!

kmdodrill updated this revision to Diff 17333.Sep 23 2019, 1:15 AM

Update Jekyll to 4.0.0

@livingsilver94 Great news! Everything works perfectly on Jekyll 4.0.0. I guess they updated their files or something to run the bundler (installs all of the dependencies) when making a new jekyll project, so everything checks out! I'm going to remove my other packages that were deps of this so I can focus purely on Jekyll.

kmdodrill retitled this revision from [RFC] Initial commit of jekyll to Initial commit of Jekyll.Sep 23 2019, 1:18 AM
kmdodrill edited the test plan for this revision. (Show Details)

@livingsilver94 Any updates on this? Is there anything else I need to do?

livingsilver94 added a comment.EditedOct 4 2019, 9:59 PM

It looks good to me, but I don't use Ruby extensively and I'm not part of the Core Team. I cannot accept nor reject your patch, you'll have to wait for a qualified reviewer :)
However...

pspec_x86_64.xml
34–35

You can delete these. Nobody's gonna read the README from local, and the license is already specified in package.yml. I usually delete this kind of files when I submit patches.

kmdodrill updated this revision to Diff 17548.Oct 5 2019, 1:05 PM

Remove README and LICENSE in the pspec xml

kmdodrill marked an inline comment as done.Oct 5 2019, 1:07 PM

@livingsilver94 Thanks for the info and suggestion! Went ahead and removed it. Is there something I can set in the package.yml to strip out files or folders that are not needed?

Nah you did it wrong XD
You don't have to remove the files from pspec, you have to remove them physically from $installdir. In the install phase, use the rm command to get rid of them.

You should also delete abi_used_libs if it's now empty.

kmdodrill updated this revision to Diff 17621.Oct 8 2019, 9:33 PM

Remove un-necessary files such as empty dirs and LICENSE and README through install key
Remove abi_used_libs

@livingsilver94 Gotcha, that makes more sense. Thanks!