search

Dr-Terrible / ineluctable-overlay

Ineluctable Overlay offers a repository of Gentoo ebuilds for projects that I am interested in, or are not yet available through Portage tree.
GNU General Public License v2.0
11 stars 4 forks source link

Fix travis errors #10

Closed bpinto closed 7 years ago

bpinto commented 7 years ago

I'm trying to fix every error/warning that travis is displaying.

TODO:

Dr-Terrible commented 7 years ago

Cool! Thank you, @bpinto

I have removed vagrant as I believe we can use the gentoo's overlay already

I agree.

[app-doc/dexy] Remove old ebuilds

Unfortunately, I need those old ebuilds. They are used by some very old python libs and occasionally I use them. For now I'll keep the old ebuilds around, until I'll find a proper replacement for the python libs; then I intend to entirely remove dexy (which is no more maintained by upstream) from the overlay.

Do we still need the upstream.workaround for Mongrel?

I don't use Mongrel2 any more since I switched to Go some years ago, but I know that there are users using it from my overlay. So, I suggest to upgrade Mongrel2 to the last release (v1.11.0) and verify if the workaround is still required, and in case report it upstream. I'll do it in the next days, so feel free to skip it from the PR. Meanwhile, I'm fixing CodeXL to use the last snapshot (it's a PITA), so Mongrel2 will take some time before to be pushed into the overlay.

bpinto commented 7 years ago

Unfortunately, I need those old ebuilds. They are used by some very old python libs and occasionally I use them. For now I'll keep the old ebuilds around, until I'll find a proper replacement for the python libs; then I intend to entirely remove dexy (which is no more maintained by upstream) from the overlay.

Oh okay, I did a grep on the code and only found a reference to the 0.6.0 version but it could be a dependency for an external library, I'm going to remove this commit.

Dr-Terrible commented 7 years ago

I'm going to remove this commit.

When you're confident that all the repoman's warnings/errors are fixed, squash your commits into a single one with git rebase -i, and then merge the PR ;)

p.s.: beware before to remove packages, I may need them; if in doubt, ask me. I know that there is a lot of crap inside this overlay, but it came into existence in the 2006, thus it has accumulated a lot of old legacy packages over the years which I still use :D

bpinto commented 7 years ago

@Dr-Terrible Do you want to squash the commits even though they are separated by packages?

I'm a very picky person regarding commits and always ensure they are rebased on top of master before merging and that they are concise. If this was not an overlay I'd probably have a single commit for removing old packages, a single commit for shortening the descriptions and fixing the metadata.

The reason why I have more than those two commits is because they are separated per package and I believe this separation per package is interesting.

If you prefer to squash always however, I believe there is a way to configure github to do this via the merge button. Which would make it easier for contributors as you wouldn't need them to do this themselves (so you wouldn't wait on someone else doing this).

Update: I forgot about the travis script update, that would be a third commit. :)

Update 2: It is already possible to squash and merge without any extra configuration on github. It's on the dropdown next to the merge button.

image

bpinto commented 7 years ago

@Dr-Terrible Thanks for the invitation!

I have removed the doxy commit so its ebuilds remain untouched.

bpinto commented 7 years ago

I have brought the fix from #9 for the travis error related to polybar into this PR.

The fix was to remove an old polybar version.

Dr-Terrible commented 7 years ago

The reason why I have more than those two commits is because they are separated per package and I believe this separation per package is interesting.

You're right, squashing doesn't make sense for this PR.

If you prefer to squash always however, I believe there is a way to configure github to do this via the merge button. Which would make it easier for contributors as you wouldn't need them to do this themselves (so you wouldn't wait on someone else doing this).

Oh right, I forgot about the GitHub built-in feature.

I'm not going to force a "squash always" rule; it only makes sense if the commits are related to the same ebuild. I'm going to update the README.md to make that part less ambiguous.

@Dr-Terrible Thanks for the invitation!

You are welcome.

The PR SGTM, feel free to merge it ;)

bpinto commented 7 years ago

:rocket: