Gitlab-Port: short status message
[forgot to add ruby@ to receiver; therefore email just for ruby@ ;) ]
Hello All,
thanks to all your work and feedback the gitlab-port creation proceeded
steadily :)
We've reached a point, we're only 3 PRs for rubygem dependencies are open:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199695
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200462
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199756
I've defined the list of dependencies in the Makefile and also added
some options for configuration.
Next monday i will start with the next part: getting gitlab to run. :)
Feel free to test until here or giving any feedback or advise. I've
attached the current progress. :)
Greetings,
Torsten
# Created by: Torsten Zühlsdorff
# $FreeBSD$
PORTNAME= gitlab
DISTVERSION=v7.9.4
CATEGORIES= www devel
MAINTAINER= po...@toco-domains.de
COMMENT=Web GUI for managing git repositories
LICENSE=MIT
BUILD_DEPENDS= ruby>=2.1:${PORTSDIR}/lang/ruby21 \
ruby-gems:${PORTSDIR}/devel/ruby-gems
RUN_DEPENDS=git:${PORTSDIR}/devel/git \
redis:${PORTSDIR}/databases/redis \
rubygem-rails4>=4.1.0:${PORTSDIR}/www/rubygem-rails4 \
rubygem-rails_autolink>=1.1.0:${PORTSDIR}/www/rubygem-rails_autolink \
rubygem-default_value_for>=3.0.0:${PORTSDIR}/devel/rubygem-default_value_for \
rubygem-mysql:${PORTSDIR}/databases/rubygem-mysql2 \
rubygem-pg:${PORTSDIR}/databases/rubygem-pg \
rubygem-devise>=3.2.4:${PORTSDIR}/devel/rubygem-devise \
rubygem-devise-async>=0.9.0:${PORTSDIR}/devel/rubygem-devise-async \
rubygem-doorkeeper>=2.1.0:${PORTSDIR}/security/rubygem-doorkeeper \
rubygem-rack-oauth2>=1.0.5:${PORTSDIR}/security/rubygem-rack-oauth2 \
rubygem-browser:${PORTSDIR}/www/rubygem-browser \
rubygem-gitlab_git>=7.1.2:${PORTSDIR}/devel/rubygem-gitlab_git \
rubygem-gitlab-grack>=2.0.0:${PORTSDIR}/www/rubygem-gitlab-grack \
rubygem-gollum-lib>=4.0.0:${PORTSDIR}/www/rubygem-gollum-lib \
rubygem-gitlab-linguist>=3.0.1:${PORTSDIR}/textproc/rubygem-gitlab-linguist \
rubygem-grape>=0.6.1:${PORTSDIR}/devel/rubygem-grape \
rubygem-grape-entity>=0.4.2:${PORTSDIR}/devel/rubygem-grape-entity \
rubygem-rack-cors:${PORTSDIR}/www/rubygem-rack-cors \
rubygem-stamp:${PORTSDIR}/textproc/rubygem-stamp \
rubygem-enumerize:${PORTSDIR}/devel/rubygem-enumerize \
rubygem-kaminari>=0.15.1:${PORTSDIR}/www/rubygem-kaminari \
rubygem-haml-rails4:${PORTSDIR}/www/rubygem-haml-rails-rails4 \
rubygem-carrierwave:${PORTSDIR}/www/rubygem-carrierwave \
rubygem-dropzonejs-rails:${PORTSDIR}/www/rubygem-dropzonejs-rails \
rubygem-fog>=1.14:${PORTSDIR}/devel/rubygem-fog \
rubygem-unf:${PORTSDIR}/textproc/rubygem-unf \
rubygem-six:${PORTSDIR}/security/rubygem-six \
rubygem-seed-fu:${PORTSDIR}/databases/rubygem-seed-fu \
rubygem-html-pipeline-gitlab>=0.1:${PORTSDIR}/textproc/rubygem-html-pipeline-gitlab
\
rubygem-github-markup:${PORTSDIR}/textproc/rubygem-github-markup \
rubygem-redcarpet>=3.1.2:${PORTSDIR}/textproc/rubygem-redcarpet \
rubygem-redcloth:${PORTSDIR}/www/rubygem-redcloth \
rubygem-rdoc>=3.6:${PORTSDIR}/devel/rubygem-rdoc \
rubygem-org-ruby>=0.9.12:${PORTSDIR}/textproc/rubygem-org-ruby \
rubygem-creole>=0.3.6:${PORTSDIR}/textproc/rubygem-creole \
rubygem-wikicloth>=0.8.1:${PORTSDIR}/textproc/rubygem-wikicloth \
rubygem-asciidoctor>=0.1.4:${PORTSDIR}/textproc/rubygem-asciidoctor \
rubygem-diffy>=3.0.3:${PORTSDIR}/textproc/rubygem-diffy \
rubygem-unicorn>=4.6.3:${PORTSDIR}/www/rubygem-unicorn \
rubygem-unicorn-worker-killer:${PORTSDIR}/www/rubygem-unicorn-worker-killer \
rubygem-state_machine:${PORTSDIR}/devel/rubygem-state_machine \
rubygem-acts-as-taggable-on:${PORTSDIR}/www/rubygem-acts-as-taggable-on3 \
rubygem-slim:${PORTSDIR}/devel/rubygem-slim \
rubygem-sinatra:${PORTSDIR}/www/rubygem-sinatra \
rubygem-sidekiq>=3.3:${PORTSDIR}/devel/rubygem-sidekiq \
rubygem-httparty:${PORTSDIR}/www/rubygem-httparty \
rubygem-colored:${PORTSDIR}/textproc/rubygem-colored \
rubygem-settingslogic:${PORTSDIR}/devel/rubygem-settingslogic \
rubygem-foreman:${PORTSDIR}/devel/rubygem-foreman \
rubygem-version_sorter:${PORTSDIR}/textproc/rubygem-version_sorter \
rubygem-redis-rails:${PORTSDIR}/www/rubygem-redis-rails \
rubygem-tinder>=1.9.2:${PORTSDIR}/net-im/rubygem-tinder \
rubygem-hipchat>=1.4.0:${PORTSDIR}/net-im/rubygem-hipchat \
rubygem-gitlab-flowdock-git-hook>=0.4.2:${PORTSDIR}/www/rubygem-gitlab-flowdock-git-hook
\
rubygem-gemnasium-gitlab-service>=0.2:${PORTSDIR}/devel/rubygem-gemnasium-gitlab-service
\
rubygem-slack-notifier>=1.0.0:${PORTSDIR}/devel/rubygem-slack-noti
[Gitlab] Current status (and problem ;)) of the new port
Hello all, the work at the gitlab-port is slow but steadily. :) The current version of my work can be found here with anonymous access: svn://svn.toco-domains.de/freebsd-ports/www/gitlab Currently all dependencies are defined and also in the needed version in the ports-tree. :) Attention: when trying to install the port, there will be at least 274 rubygems needed/installed ;) Basis commands like make install, make reinstall, make deinstall, make stage-qa already works. Also all defined options (except Kerberos-support) are working. The needed change of the Gemfile when selecting an option is already done. At the moment i stuck at the point, when trying to create the database tables for gitlab. After an: # cd /usr/local/www/gitlab && rake gitlab:setup I get this error message: === Start === Bundler could not find compatible versions for gem "rack": In Gemfile: rack (>= 1.1) ruby gitlab-grack (>= 2.0.0.rc2) ruby depends on rack (~> 1.5.1) ruby rack (>= 0) ruby rack (~> 1.4) ruby rack (~> 1.0) ruby rack (>= 1.0) ruby rack (>= 1.3.0) ruby rack (>= 0) ruby rack (>= 0.4) ruby rack (>= 0) ruby rack (>= 1.0.0) ruby rack (~> 1.5) ruby html-pipeline-gitlab (>= 0.1) ruby depends on actionpack (~> 4) ruby depends on rack (~> 1.6) ruby rack (>= 1.0) ruby rack (~> 1.0) ruby === End === While fixing an similar error message for rubygem-twitter-stream i have problems to even understand from which gem this error comes from. Or why it comes. The following rack-versions are already installed: # pkg info | grep rubygem-rack rubygem-rack-1.4.7,3 Rack, a Ruby Webserver Interface rubygem-rack15-1.5.5,4 Rack, a Ruby Webserver Interface rubygem-rack16-1.6.4 Rack, a Ruby Webserver Interface Has somebody an idea from which port the message comes or what needs to be patched to get around this? Thanks and greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Call for help / ideas
Hello, Second: gitlab is based at Rails 4.1.11, while we provide 4.2 in the ports-tree. When using 4.1.x the installation went fine. The behavior of activerecord changed between 4.1 and 4.2. I'd ask the GitLab people if they're switching to rails 4.2 soon and hope for a "yes". While creating rails41 ports is not completely impossible, it would be quite a burden and GitLab will need to switch to a newer rails in some time anyway. There is ongoing effort to switch to rails 4.2 since November 2014. I do not believe that the will adopt quickly to rails 4.2. :( It seems a big problem for many gems they used. So this will take a while. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Call for help / ideas
Hello, rails has 58 gem port dependencies. Its possible you'd need 59 new ports (though unlikely). I suspect about 27 are likely to be incompatible. As this seems a major problem (not only for Gitlab) i created a port for rails 4.1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201828 At least "just" 16 Ports where needed. I would definitely prefer option #2. I prefer it too, but i have no time to a) fix the bugs and b) get the upstream to merge them. With a look at the already used interval for this support Gitlab needed (without succeeding) it will be much easier to go this route. And we can use it for other gems to. Also the upstream is not happy with the support of rails 4.1 and 4.2 and sticks to one version until everything is ported. This could take a while. As for the gitlab port: i've updated it to the new version 7.13.0. Next step is to fix dependencies, which uses rails 4.1. ;) Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
[Gitlab] Current Status of the port
Hello all, after porting GitLab to support Rails 4.2 was not very successful, i've started to get Rails 4.1 back into ports. You've already seen the PRs ;) Normally i do not talk much if i'm not confident in the things i'm saying. But today i reached a point, where i would say, that only some work is left to finish the port. :) Currently there are 3 problems open on my list: - even if the git user is added to the redis group, gitlab is not able to use the redis socket. I could change the permission to 777 for the socket, but this seems very dirty to me - the executable files in bin/ need an o+x currently. I believe this could be fixed in the rc-script - the rc-script makes me unhappy. i used the one from gitlab-recipes, but its not as good as i want it. For example it do not check rc.conf for gitlab_enable="YES" You are welcome to have a look at my current work: svn checkout svn://svn.toco-domains.de/freebsd-ports/www/gitlab BUT it is not usable for you. To build the Port 40 Rails 4.1 (slave-)ports are needed. There are all finished (and need a last check), but i will convert them to PRs just after i finished the work at the Gitlab port. I've also started a documentation for the users: https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md English is not my native language. Feel free to improve everything ;) Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello Steve, after porting GitLab to support Rails 4.2 was not very successful, i've started to get Rails 4.1 back into ports. You've already seen the PRs ;) Normally i do not talk much if i'm not confident in the things i'm saying. But today i reached a point, where i would say, that only some work is left to finish the port. :) Thank you for working on this. It's great to see. Before we work on getting all the ports committed, I'd like to be confident we can have something that functions properly.Do the problems you mention below mean that GitLab doesn't work? Or only works if you make some manual changes? Currently manual changes are needed. But i've fix 2 of the 3 since i wrote the email. As usual i have some ideas right after hitting the "Send" button ;) Currently there are 3 problems open on my list: - even if the git user is added to the redis group, gitlab is not able to use the redis socket. I could change the permission to 777 for the socket, but this seems very dirty to me This is fixed. I've used the wrong command when writing the documentation. Usage of the parameter in the correct order make it work with permisson 770. - the executable files in bin/ need an o+x currently. I believe this could be fixed in the rc-script This is fixed. I've set user, group and rights in the pkg-plist. - the rc-script makes me unhappy. i used the one from gitlab-recipes, but its not as good as i want it. For example it do not check rc.conf for gitlab_enable="YES" I can help with the rc script. We could perhaps write our own from scratch that calls another script, or whatever is needed. Help with the rc script would be great. :) I would try to stay as near as possible at the shipped one from gitlab. This will make porting later changes easier. But i've never wrote one before - so i have no experience. You are welcome to have a look at my current work: svn checkout svn://svn.toco-domains.de/freebsd-ports/www/gitlab BUT it is not usable for you. To build the Port 40 Rails 4.1 (slave-)ports are needed. There are all finished (and need a last check), but i will convert them to PRs just after i finished the work at the Gitlab port. I've also started a documentation for the users: https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md English is not my native language. Feel free to improve everything ;) I'll try to checkout your current work and see if I can get it working. As mentioned you will needed 40 currently uncommited ports. Today i have not enough time to create a patch for you. But i try to get this done tomorrow! Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello Steve,
As mentioned you will needed 40 currently uncommited ports. Today i have
not enough time to create a patch for you. But i try to get this done
tomorrow!
After grabbing the shars that are in bugzilla at the moment, it seems these
ports are still missing:
[..] list of missing ports
Can you point me where I can find your copies of them?
You was a little bit faster than me. Today i compiled a number of
changes needed to get GitLab build. I've found some minor problems and
fixed them too.
You need 3 steps to get the ports-tree in the correct shape:
1. apply the attachment gitlab-portstree-patch.diff to /usr/ports/
2. save the attachment gitlab-with-dependencies.shar in /usr/ports/ and
extract it
3. get the most actual GitLab copy from
svn://svn.toco-domains.de/freebsd-ports/www/gitlab
Now you should be able to build GitLab. :)
Please make sure, that there is no older or newer version of Rails is
installed. I removed every Rubygem before testing to avoid conflicts.
To setup GitLab follow the quide:
https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md
I've created a basic working configuration for default. You just should
change the "host" in config/gitlab.yml, if you want to use something
other than "localhost". The rest should work. But please test carefully,
i've done many changes in the last months.
The part to setup the nginx vhost is currently missing. If you're
familar with the setup, there will be no big problems. I did not see the
default configuration for a long time; therefore i need to figure it out
to adjust the guide. -.-
If I can get this all verified as working, then perhaps we can just clean it up
and commit it all without having to open bugzilla PRs for every port.
That would be fine. :)
Also, we need to run portlint on everything, I notice it reports a few issues
with www/gitlab at the moment. I usually use "portlint -ACNc", fwiw.
Yes. I run portlint on everything attached, but it throws 3 errors for
every slave-port. If i fix there errors, the ports don't work. Here i
need you're feedback what to do.
Have a nice weekend,
Torsten
Index: devel/rubygem-devise/Makefile
===
--- devel/rubygem-devise/Makefile (Revision 392971)
+++ devel/rubygem-devise/Makefile (Arbeitskopie)
@@ -26,18 +26,26 @@
SLAVEDIRS= rubygem-devise-rails4
OPTIONS_SINGLE= RAILS
-OPTIONS_SINGLE_RAILS= RAILS3 RAILS4
+OPTIONS_SINGLE_RAILS= RAILS3 RAILS41 RAILS4
+
+.if defined(RAILS3)
+OPTIONS_DEFAULT= RAILS3
+.endif
+.if defined(RAILS41)
+OPTIONS_DEFAULT= RAILS41
+.endif
.if defined(RAILS4)
OPTIONS_DEFAULT= RAILS4
-.else
-OPTIONS_DEFAULT= RAILS3
.endif
RAILS3_DESC= Use Rails 3 as backend
-RAILS4_DESC= Use Rails 4 as backend
+RAILS41_DESC= Use Rails 4.1 as backend
+RAILS4_DESC= Use Rails 4.2 as backend
RAILS3_RUN_DEPENDS= rubygem-railties>=3.2.6:${PORTSDIR}/www/rubygem-railties \
rubygem-responders-rails3>=0:${PORTSDIR}/www/rubygem-responders-rails3
+RAILS41_RUN_DEPENDS= rubygem-railties41>=4.1.1:${PORTSDIR}/www/rubygem-railties41 \
+ rubygem-responders1=1.1.2:${PORTSDIR}/www/rubygem-responders1
RAILS4_RUN_DEPENDS= rubygem-railties4>=4.1.1:${PORTSDIR}/www/rubygem-railties4 \
rubygem-responders>=0:${PORTSDIR}/www/rubygem-responders
Index: security/rubygem-doorkeeper/Makefile
===
--- security/rubygem-doorkeeper/Makefile (Revision 392971)
+++ security/rubygem-doorkeeper/Makefile (Arbeitskopie)
@@ -11,15 +11,25 @@
LICENSE= MIT
OPTIONS_SINGLE= SG1
-OPTIONS_SINGLE_SG1= RAILTIES RAILTIES4
+OPTIONS_SINGLE_SG1= RAILTIES RAILTIES41 RAILTIES42
RAILTIES_DESC= Use Railties 3
-RAILTIES4_DESC= Use Railties 4
+RAILTIES41_DESC= Use Railties 4.1
+RAILTIES42_DESC= Use Railties 4.2
-OPTIONS_DEFAULT= RAILTIES4
+.if defined(RAILTIES)
+OPTIONS_DEFAULT= RAILTIES
+.endif
+.if defined(RAILTIES41)
+OPTIONS_DEFAULT= RAILTIES41
+.endif
+.if defined(RAILTIES42)
+OPTIONS_DEFAULT= RAILTIES42
+.endif
RAILTIES_RUN_DEPENDS= rubygem-railties>=3.2:${PORTSDIR}/www/rubygem-railties
-RAILTIES4_RUN_DEPENDS= rubygem-railties4>=4.0:${PORTSDIR}/www/rubygem-railties4
+RAILTIES41_RUN_DEPENDS= rubygem-railties41>=4.1.12:${PORTSDIR}/www/rubygem-railties41
+RAILTIES42_RUN_DEPENDS= rubygem-railties4>=4.2:${PORTSDIR}/www/rubygem-railties4
NO_ARCH= yes
USE_RUBY= yes
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# databases/rubygem-activemodel41
# databases/rubygem-activemodel41/distinfo
# databases/rubygem-activemodel41/pkg-descr
# databases/rubygem-activemodel41/Makefile
# databases/rubygem-activerecord41
# databases/rubygem-activerecord41/distinfo
# databases/rub
Re: [Gitlab] Current Status of the port
Hello,
You was a little bit faster than me. Today i compiled a number of
changes needed to get GitLab build. I've found some minor problems and
fixed them too.
You need 3 steps to get the ports-tree in the correct shape:
1. apply the attachment gitlab-portstree-patch.diff to /usr/ports/
2. save the attachment gitlab-with-dependencies.shar in /usr/ports/ and
extract it
Awesome, thanks. The shar seems to include both the diff an older version of
the same shar. No worries tho. Glad it doesn't include the Makefile~ files that
the shars in bugzilla have. :)
Sorry, i overlooked this. I have attached a clean one ;)
3. get the most actual GitLab copy from
svn://svn.toco-domains.de/freebsd-ports/www/gitlab
Seems identical to the one in the shar, as far as I can tell.
Fine. It shouldn't be in the shar, but its okay ;)
Now you should be able to build GitLab. :)
Almost. Seems a patch to update devel/rubygem-gitlab_git to 7.2.5 (or newer?)
is missing, maybe others:
===> gitlab-v7.13.2 depends on file: rubygem-gitlab_git-rails41>=7.2.5 - not
found
This patch is already in the ports-tree since 2015-07-25:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201764
Is your ports-tree actual?
Please make sure, that there is no older or newer version of Rails is
installed. I removed every Rubygem before testing to avoid conflicts.
To setup GitLab follow the quide:
https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md
I've created a basic working configuration for default. You just should
change the "host" in config/gitlab.yml, if you want to use something
other than "localhost". The rest should work. But please test carefully,
i've done many changes in the last months.
The part to setup the nginx vhost is currently missing. If you're
familar with the setup, there will be no big problems. I did not see the
default configuration for a long time; therefore i need to figure it out
to adjust the guide. -.-
Ok, I was planning to build packages in poudriere and install those in a new
empty jail and use my existing proxy to proxy things to it.
That sounds fine! :)
Yes. I run portlint on everything attached, but it throws 3 errors for
every slave-port. If i fix there errors, the ports don't work. Here i
need you're feedback what to do.
Need details on this.
# cd /usr/ports/devel/rubygem-gitlab_git-rails41
# portlint -AC
FATAL: Makefile: the last line of a slave port's Makefile has to be
.include "${MASTERDIR}/Makefile"
FATAL: Makefile: extra item "MASTERDIR" placed in the PORTNAME section.
FATAL: Makefile: extra item "PKGNAMESUFFIX" placed in the LICENSE section.
WARN: Consider to set DEVELOPER=yes in /etc/make.conf
3 fatal errors and 1 warning found.
When including the Master-Makefile in the last line, the PKGNAMESUFFIX
for example is not used.
Greetings,
Torsten
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# databases/rubygem-activemodel41
# databases/rubygem-activemodel41/distinfo
# databases/rubygem-activemodel41/pkg-descr
# databases/rubygem-activemodel41/Makefile
# databases/rubygem-activerecord41
# databases/rubygem-activerecord41/distinfo
# databases/rubygem-activerecord41/Makefile
# databases/rubygem-activerecord41/pkg-descr
# databases/rubygem-redis-actionpack-rails41
# databases/rubygem-redis-actionpack-rails41/Makefile
# databases/rubygem-seed-fu-rails41
# databases/rubygem-seed-fu-rails41/Makefile
# devel/rubygem-actionview41
# devel/rubygem-actionview41/distinfo
# devel/rubygem-actionview41/Makefile
# devel/rubygem-actionview41/pkg-descr
# devel/rubygem-activesupport41
# devel/rubygem-activesupport41/distinfo
# devel/rubygem-activesupport41/Makefile
# devel/rubygem-activesupport41/pkg-descr
# devel/rubygem-coffee-rails41
# devel/rubygem-coffee-rails41/Makefile
# devel/rubygem-default_value_for-rails41
# devel/rubygem-default_value_for-rails41/Makefile
# devel/rubygem-devise-async-rails41
# devel/rubygem-devise-async-rails41/Makefile
# devel/rubygem-devise-rails41
# devel/rubygem-devise-rails41/Makefile
# devel/rubygem-enumerize-rails41
# devel/rubygem-enumerize-rails41/Makefile
# devel/rubygem-font-awesome-rails-rails41
# devel/rubygem-font-awesome-rails-rails41/Makefile
# devel/rubygem-gitlab_git-rails41
# devel/rubygem-gitlab_git-rails41/Makefile
# devel/rubygem-grape-entity-rails41
# devel/rubygem-grape-entity-rails41/Makefile
# devel/rubygem-grape-rails41
# devel/rubygem-grape-rails41/Makefile
# devel/rubygem-ice_cube
# devel/rubygem-ice_cube/distinfo
# devel/rubygem-ice_cube/Ma
Re: [Gitlab] Current Status of the port
Hello,
# cd /usr/ports/devel/rubygem-gitlab_git-rails41
# portlint -AC
FATAL: Makefile: the last line of a slave port's Makefile has to be
.include "${MASTERDIR}/Makefile"
FATAL: Makefile: extra item "MASTERDIR" placed in the PORTNAME section.
FATAL: Makefile: extra item "PKGNAMESUFFIX" placed in the LICENSE section.
WARN: Consider to set DEVELOPER=yes in /etc/make.conf
3 fatal errors and 1 warning found.
portlint doesn't really fully grok slave ports, unless I'm mistaken, so use
your judgement here, but the include does need to be last.
Okay, will fix.
When including the Master-Makefile in the last line, the PKGNAMESUFFIX
for example is not used.
Change the master port to use ?= instead of = for the things you want to
override.
This works, but increases the number of changed ports ;)
Also it just remove one FATAL error. This other 2 persists. Is this
enough or should i do further research?
Greetings,
Torsten
___
freebsd-ruby@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ruby
To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello, To setup GitLab follow the quide: https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md I've created a basic working configuration for default. You just should change the "host" in config/gitlab.yml, if you want to use something other than "localhost". The rest should work. But please test carefully, i've done many changes in the last months. I built the packages and installed them in a jail, then followed the guide. Setting up redis, the database, config, precompiling assets, etc. went fine. When I tried to startup gitlab, I get this in the unicorn log: I, [2015-07-31T19:00:43.855792 #80415] INFO -- : Refreshing Gem list /usr/local/www/gitlab/app/controllers/import/bitbucket_controller.rb:5:in `': uninitialized constant Import::BitbucketController::OAuth (NameError) from /usr/local/www/gitlab/app/controllers/import/bitbucket_controller.rb:1:in `' After commenting out line 5 of: /usr/local/www/gitlab/app/controllers/import/bitbucket_controller.rb /usr/local/www/gitlab/app/controllers/import/gitlab_controller.rb I have gitlab up and running. This may be related to some local patches I have to ruby and gem. Anyway, I'll keep testing it. So far so good! Okay, i could reproduce this problem. It exists, when the Bitbucket option is not used. This seems a little odd, because no other OAuth Provider makes this error. I will have a look. The error is not in your local patches! Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello, To setup GitLab follow the quide: https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md I've created a basic working configuration for default. You just should change the "host" in config/gitlab.yml, if you want to use something other than "localhost". The rest should work. But please test carefully, i've done many changes in the last months. I built the packages and installed them in a jail, then followed the guide. Setting up redis, the database, config, precompiling assets, etc. went fine. When I tried to startup gitlab, I get this in the unicorn log: I, [2015-07-31T19:00:43.855792 #80415] INFO -- : Refreshing Gem list /usr/local/www/gitlab/app/controllers/import/bitbucket_controller.rb:5:in `': uninitialized constant Import::BitbucketController::OAuth (NameError) from /usr/local/www/gitlab/app/controllers/import/bitbucket_controller.rb:1:in `' After commenting out line 5 of: /usr/local/www/gitlab/app/controllers/import/bitbucket_controller.rb /usr/local/www/gitlab/app/controllers/import/gitlab_controller.rb I have gitlab up and running. This may be related to some local patches I have to ruby and gem. Anyway, I'll keep testing it. So far so good! After some testing and research i tend to remove the options and enable the providers by default. The documentation advises the user to enable the OAuth(2) methods by simply configure them. Therefore they should already be installed. At the moment you can choose between MySQL and PostgreSQL, but the project highly advises against MySQL. In conclusion i would remove all options, make the OAuth providers installed by default and remove the MySQL completely. Is somebody against this approach? Otherwise i will try to get this ready today/tomorrow :) Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello, I've created a basic working configuration for default. You just should change the "host" in config/gitlab.yml, if you want to use something other than "localhost". The rest should work. But please test carefully, i've done many changes in the last months. I built the packages and installed them in a jail, then followed the guide. Setting up redis, the database, config, precompiling assets, etc. went fine. When I tried to startup gitlab, I get this in the unicorn log: I, [2015-07-31T19:00:43.855792 #80415] INFO -- : Refreshing Gem list [.. ] After commenting out line 5 of: /usr/local/www/gitlab/app/controllers/import/bitbucket_controller.rb /usr/local/www/gitlab/app/controllers/import/gitlab_controller.rb I have gitlab up and running. This may be related to some local patches I have to ruby and gem. Anyway, I'll keep testing it. So far so good! After some testing and research i tend to remove the options and enable the providers by default. The documentation advises the user to enable the OAuth(2) methods by simply configure them. Therefore they should already be installed. At the moment you can choose between MySQL and PostgreSQL, but the project highly advises against MySQL. In conclusion i would remove all options, make the OAuth providers installed by default and remove the MySQL completely. Assuming BitBucket OAuth is installed, can people login to my (hypothetical) GitLab installation without further configuration or explicitly enabling it from my side? You need explicitly enabling it in config/gitlab.yml. Gitlab needs the Gem installed, but for further use you need explicit configuration. Its commented out by default. Is somebody against this approach? Otherwise i will try to get this ready today/tomorrow :) /holds hand up up/ Personally, I like PostgreSQL much better than MySQL, but for the port, I don't think we should force users to give up on their MySQL/MariaDB installations just because. There are a lot of FreeBSD+MySQL/MariaDB users out there. Thats the case why i originally added to option. But i changed my mind after reading this again and again: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/database_mysql.md This implies that the usage of MySQL will come with various problems, which won't be fixed. Could you just make postgres the default one, so that the packages are built with it and everything else needs extra work for those who desparately want it? Yes. I removed this an hour ago for further tests. But of cause i can bring it back. Do you hold your hands still up? Then i will bring it back. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello, You need explicitly enabling it in config/gitlab.yml. Gitlab needs the Gem installed, but for further use you need explicit configuration. Its commented out by default. So it's required to run but not enabled by default? Sounds like it should go into RUN_DEPENDS then. No they are right there :) Is somebody against this approach? Otherwise i will try to get this ready today/tomorrow :) /holds hand up up/ Personally, I like PostgreSQL much better than MySQL, but for the port, I don't think we should force users to give up on their MySQL/MariaDB installations just because. There are a lot of FreeBSD+MySQL/MariaDB users out there. Thats the case why i originally added to option. But i changed my mind after reading this again and again: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/database_mysql.md This implies that the usage of MySQL will come with various problems, which won't be fixed. Could you just make postgres the default one, so that the packages are built with it and everything else needs extra work for those who desparately want it? Yes. I removed this an hour ago for further tests. But of cause i can bring it back. Do you hold your hands still up? Then i will bring it back. Let's go without the mysql option for now and we can bring it back later if someone really wants it. Or if I'm understanding right, they could just go ahead and install the gems needed and mysql themselves and make it work. So we're not really preventing anything. Okay. I removed the mysql option. But its just a revert to get it back, if you want. I also reworked all the slave-ports and created a new patch. After unpacking the attached .shar file apply the contained patch gitlab.diff to /usr/ports. Than get the newest version from svn://svn.toco-domains.de/freebsd-ports/www/gitlab and have fun! :) The bitbucket related problem should also be fixed with this patch! Greetings, Torsten # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # databases/rubygem-activemodel41 # databases/rubygem-activemodel41/distinfo # databases/rubygem-activemodel41/pkg-descr # databases/rubygem-activemodel41/Makefile # databases/rubygem-activerecord41 # databases/rubygem-activerecord41/distinfo # databases/rubygem-activerecord41/Makefile # databases/rubygem-activerecord41/pkg-descr # databases/rubygem-redis-actionpack-rails41 # databases/rubygem-redis-actionpack-rails41/Makefile # databases/rubygem-seed-fu-rails41 # databases/rubygem-seed-fu-rails41/Makefile # devel/rubygem-actionview41 # devel/rubygem-actionview41/distinfo # devel/rubygem-actionview41/Makefile # devel/rubygem-actionview41/pkg-descr # devel/rubygem-activesupport41 # devel/rubygem-activesupport41/distinfo # devel/rubygem-activesupport41/Makefile # devel/rubygem-activesupport41/pkg-descr # devel/rubygem-coffee-rails41 # devel/rubygem-coffee-rails41/Makefile # devel/rubygem-default_value_for-rails41 # devel/rubygem-default_value_for-rails41/Makefile # devel/rubygem-devise-async-rails41 # devel/rubygem-devise-async-rails41/Makefile # devel/rubygem-devise-rails41 # devel/rubygem-devise-rails41/Makefile # devel/rubygem-enumerize-rails41 # devel/rubygem-enumerize-rails41/Makefile # devel/rubygem-font-awesome-rails-rails41 # devel/rubygem-font-awesome-rails-rails41/Makefile # devel/rubygem-gitlab_git-rails41 # devel/rubygem-gitlab_git-rails41/Makefile # devel/rubygem-grape-entity-rails41 # devel/rubygem-grape-entity-rails41/Makefile # devel/rubygem-grape-rails41 # devel/rubygem-grape-rails41/Makefile # devel/rubygem-ice_cube # devel/rubygem-ice_cube/distinfo # devel/rubygem-ice_cube/Makefile # devel/rubygem-ice_cube/pkg-descr # devel/rubygem-jbuilder-rails41 # devel/rubygem-jbuilder-rails41/Makefile # devel/rubygem-rails-deprecated_sanitizer-rails41 # devel/rubygem-rails-deprecated_sanitizer-rails41/Makefile # devel/rubygem-rails-observers-rails41 # devel/rubygem-rails-observers-rails41/Makefile # devel/rubygem-redis-activesupport-rails41 # devel/rubygem-redis-activesupport-rails41/Makefile # devel/rubygem-rotp # devel/rubygem-rotp/distinfo # devel/rubygem-rotp/Makefile # devel/rubygem-rotp/pkg-descr # devel/rubygem-sidetiq # devel/rubygem-sidetiq/distinfo # devel/rubygem-sidetiq/Makefile # devel/rubygem-sidetiq/pkg-descr # devel/rubygem-sidetiq/files # devel/rubygem-sidetiq/files/patch-sidetiq.gemspec # devel/rubygem-sprockets-rails41 # devel/rubygem-sprocke
Re: [Gitlab] Current Status of the port
On 03.08.2015 23:58, Steve Wills wrote: Okay. I removed the mysql option. But its just a revert to get it back, if you want. I also reworked all the slave-ports and created a new patch. After unpacking the attached .shar file apply the contained patch gitlab.diff to /usr/ports. Than get the newest version from svn://svn.toco-domains.de/freebsd-ports/www/gitlab and have fun! :) The bitbucket related problem should also be fixed with this patch! Seems better now. Before I wasn't able to create a project. Now I can do that, but I still hit this error when trying to view the project once I add a README.md to it: ActionView::Template::Error (uninitialized constant Gitlab::Markdown::AutolinkFilter::Rinku): Any ideas? Ideas not, but i also found this error yesterday afternoon. In Admin Settings -> Service Templates -> Jira. Also in some others, but not all. I will investigate this further. Also, in the gitlab port, instead of setting DISTVERSION, do this: PORTVERSION=7.13.2 DISTVERSIONPREFIX= v Done, thanks! Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
On 03.08.2015 23:58, Steve Wills wrote: Okay. I removed the mysql option. But its just a revert to get it back, if you want. I also reworked all the slave-ports and created a new patch. After unpacking the attached .shar file apply the contained patch gitlab.diff to /usr/ports. Than get the newest version from svn://svn.toco-domains.de/freebsd-ports/www/gitlab and have fun! :) The bitbucket related problem should also be fixed with this patch! Seems better now. Before I wasn't able to create a project. Now I can do that, but I still hit this error when trying to view the project once I add a README.md to it: ActionView::Template::Error (uninitialized constant Gitlab::Markdown::AutolinkFilter::Rinku): Any ideas? I fixed the bug. Just checkout the newest port version. :) I will push the fix to upstream - its not clear to me, why this should work. Using Rinku without requiring it in Source and/or as Gemfile looks like a bug to me. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello, I will see tomorrow, if i can make portlint happier :) Greet news! Can i help you in any way? There is an update to GitLab: https://about.gitlab.com/2015/08/04/gitlab-7-dot-13-dot-3-released/ if you want to see about updating that'd be cool. Done. Also, I noticed that after setting up the GitHub token, trying to import a project from GitHub doesn't work. It gets the list of projects, but the Import button does nothing. If you could figure that out, that'd be great. I will have a look at it. Is there anything in "Admin Area" -> "Logs" which could be helpful? Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
On 05.08.2015 19:10, Steve Wills wrote: I will have a look at it. Is there anything in "Admin Area" -> "Logs" which could be helpful? No, it looks to be a javascript issue, clicking the button doesn't even trigger any sort of http request, it just does nothing. I think I may have figured out the issue. jquery 4.x isn't compatible with rails 4.1, it needs 4.2: https://github.com/rails/jquery-rails/blob/master/CHANGELOG.md So we need jqueyr 3.1.3 and friends. I'll have a look at changing that locally to test. Looks like cal-heatmap-rails upgrade from 0.0.1 to 3.5.1 was the real issue. Tho I think we may want to consider dropping jquery-rails back to 3.1.3 just to be safe and what I said about changing ~> to => in Gemfile still applies. Okay, i will create a port for the old jquery-rails. Currently there is a pending slave-port "rubygem-jquery-rails41" for GitLab. I could rewrite it to use 3.1.3. Or should i replace it with an explicit "rubygem-jquery*3*-rails41"? In this case we can omit the other one. Also i will rework the Gemfile patches to be less optimistic. This week i haven't much time left. I can't guarantee to get it done before monday. Sorry. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
On 06.08.2015 17:16, Steve Wills wrote: I will have a look at it. Is there anything in "Admin Area" -> "Logs" which could be helpful? No, it looks to be a javascript issue, clicking the button doesn't even trigger any sort of http request, it just does nothing. I think I may have figured out the issue. jquery 4.x isn't compatible with rails 4.1, it needs 4.2: https://github.com/rails/jquery-rails/blob/master/CHANGELOG.md So we need jqueyr 3.1.3 and friends. I'll have a look at changing that locally to test. Looks like cal-heatmap-rails upgrade from 0.0.1 to 3.5.1 was the real issue. Tho I think we may want to consider dropping jquery-rails back to 3.1.3 just to be safe and what I said about changing ~> to => in Gemfile still applies. Okay, i will create a port for the old jquery-rails. Currently there is a pending slave-port "rubygem-jquery-rails41" for GitLab. I could rewrite it to use 3.1.3. Or should i replace it with an explicit "rubygem-jquery*3*-rails41"? In this case we can omit the other one. Either way is fine. In this case i will create "rubygem-jquery*3*-rails41". This avoid an "unwanted" update to the actual version. This week i haven't much time left. I can't guarantee to get it done before monday. Sorry. There's no rush, I can work on getting some of the things committed some this weekend too, hopefully. I may try to work on getting the older rubygem-cal-heatmap-rails in too, that seems more critical. I could create this too next week. Than you can focus on the other parts. Everything depends on Rails 4.1 anyway. Thanks again for all your hard work! Thank you too! Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
On 06.08.2015 17:52, Steve Wills wrote: I will have a look at it. Is there anything in "Admin Area" -> "Logs" which could be helpful? No, it looks to be a javascript issue, clicking the button doesn't even trigger any sort of http request, it just does nothing. I think I may have figured out the issue. jquery 4.x isn't compatible with rails 4.1, it needs 4.2: https://github.com/rails/jquery-rails/blob/master/CHANGELOG.md So we need jqueyr 3.1.3 and friends. I'll have a look at changing that locally to test. Looks like cal-heatmap-rails upgrade from 0.0.1 to 3.5.1 was the real issue. Tho I think we may want to consider dropping jquery-rails back to 3.1.3 just to be safe and what I said about changing ~> to => in Gemfile still applies. Okay, i will create a port for the old jquery-rails. Currently there is a pending slave-port "rubygem-jquery-rails41" for GitLab. I could rewrite it to use 3.1.3. Or should i replace it with an explicit "rubygem-jquery*3*-rails41"? In this case we can omit the other one. Either way is fine. In this case i will create "rubygem-jquery*3*-rails41". This avoid an "unwanted" update to the actual version. Sounds good, you'll want to put a PORTSCOUT line in there too. Good pointer. There is another port which needs this line. Thanks! Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Gitlab] Current Status of the port
Hello, I will have a look at it. Is there anything in "Admin Area" -> "Logs" which could be helpful? No, it looks to be a javascript issue, clicking the button doesn't even trigger any sort of http request, it just does nothing. I think I may have figured out the issue. jquery 4.x isn't compatible with rails 4.1, it needs 4.2: https://github.com/rails/jquery-rails/blob/master/CHANGELOG.md So we need jqueyr 3.1.3 and friends. I'll have a look at changing that locally to test. Looks like cal-heatmap-rails upgrade from 0.0.1 to 3.5.1 was the real issue. Tho I think we may want to consider dropping jquery-rails back to 3.1.3 just to be safe and what I said about changing ~> to => in Gemfile still applies. Okay, i will create a port for the old jquery-rails. Currently there is a pending slave-port "rubygem-jquery-rails41" for GitLab. I could rewrite it to use 3.1.3. Or should i replace it with an explicit "rubygem-jquery*3*-rails41"? In this case we can omit the other one. Either way is fine. In this case i will create "rubygem-jquery*3*-rails41". This avoid an "unwanted" update to the actual version. Sounds good, you'll want to put a PORTSCOUT line in there too. In my "big patch with GitLab" there was already a port "rubygem-jquery-rails-railties41" which has the jquery-rails 3 dependency within. (But there is an error in its dependency definition) After some confusion about the package names, should this new port named "rubygem-jquery-rails-railties41" or "rubygem-jquery-rails-rails41". It seems that when ports defines a dependency to railties there name is suffixed with "-rails". I suffixed them with "-railties" because for my novice sense, this was not the same. ;) But to stay coherent i should use "-rails41" as suffix - am i right? Next question: what should i do with the number of slave ports? Should i create a PR with a big patch including GitLab? Or should i open PRs for the slave ports and GitLab itself? I saw that you committed many of the PRs. Thank you very much for your work! Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
GitLab 8 released - already working on it :)
Hello, GitLab 8 was already released. Current version is GitLab 8.0.2 to be pedantic. ;) While GitLab 7.14 is not in the ports yet, i will work on an update. To make the live of Philip hopefully easier, i've decided to handle GitLab 8 as an update of GitLab 7.14. This means while working on the new version Philip can uninterrupted work on getting the previous version into the portstree. :) I've already paired up with Michael Fausten again. We will store our work here: svn://svn.toco-domains.de/freebsd-ports/www/gitlab8 In the first step i've removed no longer needed dependencies from the list. Also i adjusted the needed versions of the needed gems and started an testrun. All needed gems which are already in the portstree have the needed version. This is very fine :) The next days Michael and i will create the new dependencies, adjusting the documentation and start testing the new version. @Philip: if you need anything from us to come along better with the existing PRs: just say it. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
[GitLab] can't modify frozen ActiveSupport::HashWithIndifferentAccess - again
Hello, after finishing all dependencies and sidework on the port for GitLab 8.3.x i stumpled accross the same error like before: $ rake gitlab:setup RAILS_ENV=production [..] == Seed from /usr/local/www/gitlab/db/fixtures/production/001_admin.rb rake aborted! can't modify frozen ActiveSupport::HashWithIndifferentAccess (eval):9:in `block (2 levels) in run_file' /usr/local/www/gitlab/lib/tasks/gitlab/setup.rake:20:in `setup_db' /usr/local/www/gitlab/lib/tasks/gitlab/setup.rake:4:in `block (2 levels) in ' Tasks: TOP => db:seed_fu (See full trace by running task with --trace) This is a little bit frustrating, because this is exactly the error which drove me to resurrect RAILS 4.1. With Rails 4.1 the error did not occur. :D My ruby is not good enough do fix it. Can somebody help? Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Obsoleting Rails 3.x?
On 21.01.2016 17:51, Steve Wills wrote: while working on many ports i figured out there are a bunch of dependencies to our Rails 3 port. But for many rubygems this is not needed - they already work with Rails 4.2. Often this results in a port based on Rails 3 and a slave port with Rails 4.2. This will become even more bad because Rails 5 is already on its way. Also when i'm understanding the release notices correct (i found them quite confusing) they state: - Rails 3.2 will only fix really bad security issues (while letting "normal" security issues intact) - you seem to get the fixes just if you pay So i would announce, that we go through the gems and do a little cleanup. If a gem will work with Rails 4.2 we should switch its dependency to this version instead of Rails 3. Your thoughts? Objections? Sounds good, let's do it. Fine! :) I will start next week! Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Obsoleting Rails 3.x?
On 22.01.2016 11:15, Torsten Zuehlsdorff wrote: On 21.01.2016 17:51, Steve Wills wrote: while working on many ports i figured out there are a bunch of dependencies to our Rails 3 port. But for many rubygems this is not needed - they already work with Rails 4.2. Often this results in a port based on Rails 3 and a slave port with Rails 4.2. This will become even more bad because Rails 5 is already on its way. Also when i'm understanding the release notices correct (i found them quite confusing) they state: - Rails 3.2 will only fix really bad security issues (while letting "normal" security issues intact) - you seem to get the fixes just if you pay So i would announce, that we go through the gems and do a little cleanup. If a gem will work with Rails 4.2 we should switch its dependency to this version instead of Rails 3. Your thoughts? Objections? Sounds good, let's do it. Fine! :) I will start next week! Okay, i did start, but with another step. First i set all Rails 4.1 ports deprecated. I introduced them just for the GitLab port, which no longer needs them: https://github.com/t-zuehlsdorff/freebsd-ports/tree/remove_rails41 I will create review and PR soon. First i need to take care about another PR. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Obsoleting Rails 3.x?
On 25.01.2016 13:01, Torsten Zuehlsdorff wrote: while working on many ports i figured out there are a bunch of dependencies to our Rails 3 port. But for many rubygems this is not needed - they already work with Rails 4.2. Often this results in a port based on Rails 3 and a slave port with Rails 4.2. This will become even more bad because Rails 5 is already on its way. Also when i'm understanding the release notices correct (i found them quite confusing) they state: - Rails 3.2 will only fix really bad security issues (while letting "normal" security issues intact) - you seem to get the fixes just if you pay So i would announce, that we go through the gems and do a little cleanup. If a gem will work with Rails 4.2 we should switch its dependency to this version instead of Rails 3. Your thoughts? Objections? Sounds good, let's do it. Fine! :) I will start next week! Okay, i did start, but with another step. First i set all Rails 4.1 ports deprecated. I introduced them just for the GitLab port, which no longer needs them: https://github.com/t-zuehlsdorff/freebsd-ports/tree/remove_rails41 I will create review and PR soon. First i need to take care about another PR. Here is the PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206735 In the next step i will wrote updates for all the ports depending on Rails 3. When there are no dependencies left, i will write a patch to expire Rails 3. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [package - 101i386-quarterly][databases/rubygem-activemodel4] Failed for rubygem-activemodel4-4.2.5.1 in run-depends
Hello, === === ===> rubygem-activemodel4-4.2.5.1 depends on package: rubygem-activesupport4>=4.2.5.1 - not found ===> Installing existing package /packages/All/rubygem-activesupport4-4.2.5.txz [101i386-quarterly-job-06] Installing rubygem-activesupport4-4.2.5... [101i386-quarterly-job-06] `-- Installing rubygem-json-1.8.3... [101i386-quarterly-job-06] `-- Extracting rubygem-json-1.8.3: .. done [101i386-quarterly-job-06] `-- Installing rubygem-minitest-5.8.3... [101i386-quarterly-job-06] `-- Extracting rubygem-minitest-5.8.3: .. done [101i386-quarterly-job-06] `-- Installing rubygem-i18n-0.7.0,2... [101i386-quarterly-job-06] `-- Extracting rubygem-i18n-0.7.0,2: .. done [101i386-quarterly-job-06] `-- Installing rubygem-thread_safe-0.3.5... [101i386-quarterly-job-06] `-- Extracting rubygem-thread_safe-0.3.5: .. done [101i386-quarterly-job-06] `-- Installing rubygem-tzinfo-1.2.2_1... [101i386-quarterly-job-06] | `-- Installing rubygem-thread_safe1-0.1.3... [101i386-quarterly-job-06] | | `-- Installing rubygem-atomic-1.1.99... [101i386-quarterly-job-06] | | `-- Extracting rubygem-atomic-1.1.99: .. done [101i386-quarterly-job-06] | `-- Extracting rubygem-thread_safe1-0.1.3: .. done [101i386-quarterly-job-06] `-- Extracting rubygem-tzinfo-1.2.2_1: .. done [101i386-quarterly-job-06] Extracting rubygem-activesupport4-4.2.5: .. done ===> rubygem-activemodel4-4.2.5.1 depends on package: rubygem-activesupport4>=4.2.5.1 - not found for the work on the GitLab port i already did a full update of Rails to 4.2.5.1. You can get it from here: https://github.com/t-zuehlsdorff/freebsd-ports/tree/gitlab If you need a patch just say so, i will send one. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
[Redmine] Remove %%RUBY_SUFFIX%% from make check-plist?
Hello, i'm currently working on an update for redmine and make some good progress: https://github.com/t-zuehlsdorff/freebsd-ports/tree/redmine/www/redmine But i am stuck at stage-qa/check-plist. Whenever i do a make check-plist i got errors like this: > Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: %%WWWDIR%%/db/migrate/0%%RUBY_SUFFIX%%_add_tracker_position.rb [..] ===> Checking for items in pkg-plist which are not in STAGEDIR Error: Missing: %%WWWDIR%%/db/migrate/012_add_tracker_position.rb Please note the %%RUBY_SUFFIX%% in the first message. It occurs multiple times and replaces the value "12". I have no idea why %%RUBY_SUFFIX%% is there and how to get rid of it. Can anyone help please? Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Redmine] Remove %%RUBY_SUFFIX%% from make check-plist?
On 10.02.2016 14:05, Steve Wills wrote: I've had this problem too. Set PLIST_SUB_SED_MIN=3 in make.conf (if you're using poudriere, set it in /usr/local/etc/poudriere.d/make.conf). This will prevent the plist sub script from using such short values. This helped! Thank you very much, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: default ruby version
Hi, Just FYI, baring any objections or major issues coming up, I plan to make Ruby 2.2 the default Ruby in the ports tree on March 1. No objections here. :) Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: default ruby version
Hello Miroslav, On 23.02.2016 15:47, Miroslav Lachman wrote: Steve Wills wrote on 02/17/2016 06:47: Hi, Just FYI, baring any objections or major issues coming up, I plan to make Ruby 2.2 the default Ruby in the ports tree on March 1. Puppet users in particular probably want to migrate to sysutils/puppet4 or work on testing some sort of patch that makes puppet 3.x work with ruby 2.2 before then. Steve Will it be another breakage of www/redmine? (it is known to have problems with many dependencies after updates) I'm currently working on an update for redmine to version 3.2. This will make it much more stable for updates. Did you have any interest in testing the update? Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: svn commit: r412530 - head/www/gitlab
Hello, i can now confirm safely that www/gitlab runs with Ruby 2.2. :) Since the direct dependency to 2.1 was dropped already, there is nothing to do. Greetings, Torsten On 05.04.2016 10:25, Torsten Zühlsdorff wrote: Hello, i would follow your suggestion, but after some research i found this: https://gitlab.com/gitlab-org/gitlab-ce/issues/3340 There is a closed issue and a merge for Ruby 2.2 support. But the documentation clearly states no support for 2.2. I'm currently installing an 2.2 based version of GitLab and will look what happens. :D Greetings, Torsten On 05.04.2016 03:42, Steve Wills wrote: Ah, that's rather disappointing. Well, thanks for letting me know. Torsten, do you have ideas? Or should we just mark it broken with ruby 2.2 and then only folks who build their own packages with 2.1 as default will have it? Steve On 04/ 4/16 09:32 PM, Pierre Guinoiseau wrote: GitLab actually specifically needs Ruby 2.1. Ruby 2.2 and 2.3 are currently not supported according to documentation: https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md#2-ruby On 04/04/2016 21:34:29, Steve Wills wrote: Author: swills Date: Mon Apr 4 21:34:29 2016 New Revision: 412530 URL: https://svnweb.freebsd.org/changeset/ports/412530 Log: www/gitlab: remove unneeded dependency on ruby Modified: head/www/gitlab/Makefile Modified: head/www/gitlab/Makefile == --- head/www/gitlab/MakefileMon Apr 4 20:46:22 2016(r412529) +++ head/www/gitlab/MakefileMon Apr 4 21:34:29 2016(r412530) @@ -11,8 +11,7 @@ COMMENT=Web GUI for managing git reposi LICENSE=MIT -BUILD_DEPENDS=ruby>=2.1.8:lang/ruby21 \ -gem:devel/ruby-gems +BUILD_DEPENDS=gem:devel/ruby-gems RUN_DEPENDS=git>=2.4.3:devel/git \ gitlab-shell>=2.6.10:devel/gitlab-shell\ gitlab-workhorse>=0.6.4:www/gitlab-workhorse \ ___ svn-ports-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-ports-all To unsubscribe, send any mail to "svn-ports-all-unsubscr...@freebsd.org" ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org" ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: FreeBSD Port: www/redmine
Hello Vinícius, there is already a patch for the update to 3.2. There are two open issues. Hopefully i find time next week to fix them and bring the patch into an PR :) Greetings, Torsten On 20.05.2016 06:52, Vinícius Ferrão wrote: Hello Ruby, There are any prevision of updating this port to the 3.x release? Thanks in advance, Vinícius ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org" ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Feedback needed: www/redmine Update
Hello, i wrote an update for www/redmine. It would be very nice if some more people can test it, since its skipping multiple major versions. The patch brings the port from 2.6.9 to 3.2.2. Also i notices some more ports related to www/redmine. Namley: $ cd /usr/ports/ && find . -name "*redmine*" -type d ./devel/rubygem-redmine_plugin_support ./www/redmine-backlogs ./www/redmine-basecamp ./www/redmine-http-auth ./www/redmine-sidebar_hide ./www/redmine ./www/rubygem-redmine_acts_as_taggable_on ./www/redmine-default_assign ./www/redmine-graphs ./www/redmine-issue_templates ./www/redmine-knowledgebase ./www/redmine-qa_contact ./www/redmine-redcarpet_formatter ./www/redmine-stuff_to_do ./www/redmine-wiki_notes Is there anybody who uses this ports and could verify if they still work after the update? Thank you! Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Feedback needed: www/redmine Update
Hello, i wrote an update for www/redmine. It would be very nice if some more people can test it, since its skipping multiple major versions. The patch brings the port from 2.6.9 to 3.2.2. Also i notices some more ports related to www/redmine. Namley: $ cd /usr/ports/ && find . -name "*redmine*" -type d ./devel/rubygem-redmine_plugin_support ./www/redmine-backlogs ./www/redmine-basecamp ./www/redmine-http-auth ./www/redmine-sidebar_hide ./www/redmine ./www/rubygem-redmine_acts_as_taggable_on ./www/redmine-default_assign ./www/redmine-graphs ./www/redmine-issue_templates ./www/redmine-knowledgebase ./www/redmine-qa_contact ./www/redmine-redcarpet_formatter ./www/redmine-stuff_to_do ./www/redmine-wiki_notes Is there anybody who uses this ports and could verify if they still work after the update? Thank you! Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Feedback needed: www/redmine Update
Aloha, i wrote an update for www/redmine. It would be very nice if some more people can test it, That's awesome, I'm glad to hear that, thanks for the work! I have an install of redmine that I could use for testing. Where is the patch? The patch can be found here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209938 since its skipping multiple major versions. The patch brings the port from 2.6.9 to 3.2.2. Wouldn't that just be upgrading by one major version from 2.x to 3.x? If i read the scheming correct, 3.0 and 3.1 were also major version. But since i'm not a user, i'm not sure. Also i notices some more ports related to www/redmine. Namley: $ cd /usr/ports/ && find . -name "*redmine*" -type d ./devel/rubygem-redmine_plugin_support ./www/redmine-backlogs ./www/redmine-basecamp ./www/redmine-http-auth ./www/redmine-sidebar_hide ./www/redmine ./www/rubygem-redmine_acts_as_taggable_on ./www/redmine-default_assign ./www/redmine-graphs ./www/redmine-issue_templates ./www/redmine-knowledgebase ./www/redmine-qa_contact ./www/redmine-redcarpet_formatter ./www/redmine-stuff_to_do ./www/redmine-wiki_notes Is there anybody who uses this ports and could verify if they still work after the update? Do the plugins need to be updated too? Or just tested that they still work? My install uses the sidebar_hide plugin and maybe one or two others (can't recall right now, but will test). This could be differ. I researched some, for example www/redmine-backlogs. There homepage http://www.redminebacklogs.net/ states, that it only works with redmine 2.2 or 2.3. Since we have 2.6 in the ports i'm not sure, that the port really works. Maybe it does and will against 3.2 also. Since i'm not using any of them, i'm not sure if i could state, that the ports will work correctly after the update, even if i install everyone. I just would not know how to long for. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Obsoleting Rails 3: how to handle different cases
Hello, while working on obsoleting Rails 3 from the ports, i stumble across various unclear cases. For example: 1) how to handle different copies of an gem with different rails-dependencies. For example www/rubygem-haml-rails and www/rubygem-haml-rails-rails4. Both have the same function, but the first is outdated. 2) how to handle ports which seems not to be required any more. databases/rubygem-dm-* for example seems to be left alone and there is no non-rubygem-port requiring this. I would set the complete tree of ports to expiration in this case. 3) how to handle slaves? there were -rails4 ports which are purely slaves to set the dependency to rails 4 instead of 3. Updating the master to rails 4 dependency obsoletes the slave. I would prefer to: update the master, obsolete the slave and switch dependencies of ports from the slaves to the master. What is your opinion? Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Feedback needed: www/redmine Update
On 06.06.2016 22:22, Steve Wills wrote: Hi, On 06/ 6/16 12:23 PM, Steve Wills wrote: Hi, On 06/ 6/16 08:10 AM, Torsten Zuehlsdorff wrote: Aloha, The patch can be found here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209938 I updated the PR with a new patch. With that, it works fine for me. I also tested backlogs and sidebar_hide. Sidebar_hide works fine, backlogs does not. For the archive: the new patch was very fine. I've updated it to the newest version and committed it some minutes ago :) Thanks to all supporter! Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Patch for Rails 4.2.7.1 Update
Hello, i'm currently working on an update to Rails 4.2.7.1 (which of course is needed by GitLab :D). Since its a security update it would be fine to get it into the ports-tree. My first attempt was to update all rails-* ports but swills pointed me to a simple test, by running "rails new foo" on a clean installation. This reveals 16 needed updates. 15 of them are included in the attached diff, just the new port turbolinks-source is missing. I did not find any time for it. Most of the updates are fairly easy and safe to commit, but since there are so many i found some more testers out there. Please check the updates by yourself and give feedback. Feel also free to commit them by yourself if you want. Also: can anybody point me to the location were the needed dependencies were defined? I want to adjust the Makefiles but i can't figure out where they come from. I even make a clean install on a fresh ports-tree and did a "grep -RH" about all work-dirs, but did not find any clue. Any help would be great. Greetings, Torsten Index: databases/rubygem-activemodel4/Makefile === --- databases/rubygem-activemodel4/Makefile (Revision 422485) +++ databases/rubygem-activemodel4/Makefile (Arbeitskopie) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= activemodel -PORTVERSION= 4.2.6 +PORTVERSION= 4.2.7.1 CATEGORIES= databases rubygems MASTER_SITES= RG PKGNAMESUFFIX= 4 Index: databases/rubygem-activemodel4/distinfo === --- databases/rubygem-activemodel4/distinfo (Revision 422485) +++ databases/rubygem-activemodel4/distinfo (Arbeitskopie) @@ -1,2 +1,3 @@ -SHA256 (rubygem/activemodel-4.2.6.gem) = 4230930ea7ba04b6af940f9a393a821601e99cce387d964eea8d1215f8417145 -SIZE (rubygem/activemodel-4.2.6.gem) = 45568 +TIMESTAMP = 1471421091 +SHA256 (rubygem/activemodel-4.2.7.1.gem) = 65a7631d487b9642c6877dd404667991e36cdd75e588406c4d4c435557059f29 +SIZE (rubygem/activemodel-4.2.7.1.gem) = 45568 Index: databases/rubygem-activerecord4/Makefile === --- databases/rubygem-activerecord4/Makefile (Revision 422485) +++ databases/rubygem-activerecord4/Makefile (Arbeitskopie) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= activerecord -PORTVERSION= 4.2.6 +PORTVERSION= 4.2.7.1 CATEGORIES= databases rubygems MASTER_SITES= RG PKGNAMESUFFIX= 4 Index: databases/rubygem-activerecord4/distinfo === --- databases/rubygem-activerecord4/distinfo (Revision 422485) +++ databases/rubygem-activerecord4/distinfo (Arbeitskopie) @@ -1,2 +1,3 @@ -SHA256 (rubygem/activerecord-4.2.6.gem) = bfcf285ddf5ba4ce8f45c3472a8d827a2c35ab5ba0e4186af13db35c4f7653ae -SIZE (rubygem/activerecord-4.2.6.gem) = 330752 +TIMESTAMP = 1471420281 +SHA256 (rubygem/activerecord-4.2.7.1.gem) = 923a64e2ebb9c4529761bf65ed37601a7000af2f3b18f12ea00e9f9ba2a168d2 +SIZE (rubygem/activerecord-4.2.7.1.gem) = 331776 Index: databases/rubygem-globalid/Makefile === --- databases/rubygem-globalid/Makefile (Revision 422485) +++ databases/rubygem-globalid/Makefile (Arbeitskopie) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= globalid -PORTVERSION= 0.3.6 +PORTVERSION= 0.3.7 CATEGORIES= databases rubygems MASTER_SITES= RG Index: databases/rubygem-globalid/distinfo === --- databases/rubygem-globalid/distinfo (Revision 422485) +++ databases/rubygem-globalid/distinfo (Arbeitskopie) @@ -1,2 +1,3 @@ -SHA256 (rubygem/globalid-0.3.6.gem) = 2189faa079709772a0f64ac8df61dbcd84c5112a0a9b3c86971887eef4cdbd90 -SIZE (rubygem/globalid-0.3.6.gem) = 10752 +TIMESTAMP = 1473687260 +SHA256 (rubygem/globalid-0.3.7.gem) = 53414b2d226b722409167098acab75e47bfeee7e3130a6852733f141fd9bf486 +SIZE (rubygem/globalid-0.3.7.gem) = 12288 Index: devel/rubygem-actionview/Makefile === --- devel/rubygem-actionview/Makefile (Revision 422485) +++ devel/rubygem-actionview/Makefile (Arbeitskopie) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= actionview -PORTVERSION= 4.2.6 +PORTVERSION= 4.2.7.1 CATEGORIES= devel rubygems MASTER_SITES= RG @@ -16,7 +16,7 @@ rubygem-builder32>=3.2:devel/rubygem-builder32 \ rubygem-erubis>=2.7.0:www/rubygem-erubis \ rubygem-rails-dom-testing>=1.0.5:textproc/rubygem-rails-dom-testing \ - rubygem-rails-html-sanitizer>=1.0.1:textproc/rubygem-rails-html-sanitizer + rubygem-rails-html-sanitizer>=1.0.2:textproc/rubygem-rails-html-sanitizer NO_ARCH= yes USE_RUBY= yes Index: devel/rubygem-actionview/distinfo === --- devel/rubygem-actionview/distinfo (Revision 422485) +++ devel/rubygem-actionview/distinfo (Arbeitskopie) @@ -1,2 +1,3 @@ -SHA256 (rubygem/actionview-4.2.6.gem) = 8758ee3acfe8305fcc26b80
Feature-Request: pessimistic operator in ports-tree
Aloha, i'm working quite a while on the ruby-ports and it is often annoying. Even after excessive testing and some more real-world testing (thanks to all helpers!) its totally normal, that thinks break. I found one of the main problems is the pessimistic operator in the gemspecs/Gemfiles. Buildtests of all dependencies run fine, we commit the update and than some Gem break, because it defined ~> 1.5.2 and you just updated to 1.6. In the Makefile >= 1.5.2 says everything is fine. I personally think most of the rubygem breakage can be prevented by teaching the ports-tree about the pessimistic operator. It is far easier to build-test 300 dependencies than to really check if they are able to start. Or even if they run correctly. What do you think about this? Also i believe its not a rubygem only feature. I stumbled across multiple software which expect an explicit version or an version range or even disallow a single version and accept all other. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Feature-Request: pessimistic operator in ports-tree
Aloha, i'm working quite a while on the ruby-ports and it is often annoying. Even after excessive testing and some more real-world testing (thanks to all helpers!) its totally normal, that thinks break. I found one of the main problems is the pessimistic operator in the gemspecs/Gemfiles. Buildtests of all dependencies run fine, we commit the update and than some Gem break, because it defined ~> 1.5.2 and you just updated to 1.6. In the Makefile >= 1.5.2 says everything is fine. To me it seem rather that the problem is gemspecs over-using or mis-using the pessimistic operator. If the gemspec correctly specified what actually worked, this wouldn't be an issue. That is, of course, correct. ;) But we have more than 1.000 rubygem-ports and it isn't going to happen that all of them teaches the gemfiles the correct version. This isn't even needed since gem files are designed to work right this way. Its more a problem on our site than on the ruby-site. I personally think most of the rubygem breakage can be prevented by teaching the ports-tree about the pessimistic operator. It is far easier to build-test 300 dependencies than to really check if they are able to start. Or even if they run correctly. How would this help exactly? It seems to me it would make it easier to figure out where the mismatch is but wouldn't actually solve the problem. And this isn't even the hard part, building all the packages doesn't really take much time. But you would still have to correct the gemspec or create multiple ports/pkgs for each version needed. What am I missing? The part with breaking everything after an successful build. For GitLab i build around 300+ Packages. Every time all packages were build correctly, but only one time an update did not break something. A correct build nearly means nothing for rubygems. If the Gemfile uses the pessimistic operator and forbid using the version just updated, nothing will happen. It builds fine. You have to runtime-check every version depending on that. And sometimes this are many (multiple hundreds yesterday). An pessimistic operator support would ease the detection part. The buildtest can fail and you know where to look at. This would be a great option added. Also: even if we patch the gemspec to the use of the newer version, this is also error prone. I saw this for GitLab. A specific Gem just runs fine the complete time, except one user wanted one option, which is no longer supported by the gem in this syntax. So GitLab fails because of the update, but only if this option is used. All other parts of GitLab using the exact same (but wrong) version of the Gem works fine. What do you think about this? Also i believe its not a rubygem only feature. I stumbled across multiple software which expect an explicit version or an version range or even disallow a single version and accept all other. I think a patch would help discussion. I'm not unsympathetic, it is a pain. But I just don't understand how this would fix anything. Perhaps some sort of tool that would check these things would be helpful? It would not fix anything, it would just ease the detection of such an error vector. Rubygem dependencies were designed in a very specific way and we currently just ignore this and came up with various problems around this. Yes, some sort of tool could do this also. I experimented a little and its a great help, but it is one more tool to use. I think every ruby-committer will use it, but for example every new external user sending patches need to learn it. Integrated in core there is no need for user learning this behavior and therefore one more error possibility gone. After some more thinking i doubt its easy to realize, especially the part were more than 1.000 ports need a update to benefit from the change. Mh, i add the idea to my port-rewrite-project. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
GitLab user and tester wanted!
Hello,
since GitLab is a very complex port things get regularly broken, even
with my quite excessive amount of testing.
To improve the situation i'm looking for persons using the port and
which are able to test updates.
Attached a patch for the update to version 8.11.10. It is relative small
and only the normal update routines apply. If somebody is interested in,
just try it (after an backup of course!) and give same feedback. If you
are interested in a monthly update patch please let me know. Every help
is appreciated!
Thank you very much,
Torsten
Index: devel/gitlab-shell/Makefile
===
--- devel/gitlab-shell/Makefile (Revision 425382)
+++ devel/gitlab-shell/Makefile (Arbeitskopie)
@@ -1,8 +1,8 @@
-# Created by: Torsten Zuehlsdorff
# $FreeBSD$
PORTNAME= gitlab-shell
-PORTVERSION= 3.2.1
+PORTVERSION= 3.4.0
CATEGORIES= devel
MASTER_SITES= https://gitlab.com/gitlab-org/${PORTNAME}/repository/archive.tar.gz?ref=v${PORTVERSION}&dummy=/
DISTNAME= ${PORTNAME}-v${PORTVERSION}
Index: devel/gitlab-shell/distinfo
===
--- devel/gitlab-shell/distinfo (Revision 425382)
+++ devel/gitlab-shell/distinfo (Arbeitskopie)
@@ -1,3 +1,3 @@
-TIMESTAMP = 1470988234
-SHA256 (gitlab-shell-v3.2.1.tar.gz) = ad21f8676901b9d90a1c8016b5fe2ad73f9a7966ab378ce244b12fc0373e9f46
-SIZE (gitlab-shell-v3.2.1.tar.gz) = 68788
+TIMESTAMP = 1476972305
+SHA256 (gitlab-shell-v3.4.0.tar.gz) = 0ac8f18b1615194943e935b670d630a1ba9870ad876f7486256972c7be1d45d4
+SIZE (gitlab-shell-v3.4.0.tar.gz) = 71972
Index: devel/rubygem-newrelic_rpm/Makefile
===
--- devel/rubygem-newrelic_rpm/Makefile (Revision 425382)
+++ devel/rubygem-newrelic_rpm/Makefile (Arbeitskopie)
@@ -1,7 +1,7 @@
# $FreeBSD$
PORTNAME= newrelic_rpm
-PORTVERSION= 3.15.0.314
+PORTVERSION= 3.16.3.323
CATEGORIES= devel rubygems
MASTER_SITES= RG
Index: devel/rubygem-newrelic_rpm/distinfo
===
--- devel/rubygem-newrelic_rpm/distinfo (Revision 425382)
+++ devel/rubygem-newrelic_rpm/distinfo (Arbeitskopie)
@@ -1,2 +1,3 @@
-SHA256 (rubygem/newrelic_rpm-3.15.0.314.gem) = 30e1239e18358bb3fe84f6a2789f6c244d403e2d28b2690c9d7314067144f788
-SIZE (rubygem/newrelic_rpm-3.15.0.314.gem) = 736768
+TIMESTAMP = 1476972968
+SHA256 (rubygem/newrelic_rpm-3.16.3.323.gem) = 82a4216743a34bdc766838f3af2d4e174fb0672443ea8f730c9bf84243fb896c
+SIZE (rubygem/newrelic_rpm-3.16.3.323.gem) = 754688
Index: textproc/rubygem-version_sorter/Makefile
===
--- textproc/rubygem-version_sorter/Makefile (Revision 425382)
+++ textproc/rubygem-version_sorter/Makefile (Arbeitskopie)
@@ -2,7 +2,7 @@
# $FreeBSD$
PORTNAME= version_sorter
-PORTVERSION= 2.0.0
+PORTVERSION= 2.1.0
CATEGORIES= textproc rubygems
MASTER_SITES= RG
Index: textproc/rubygem-version_sorter/distinfo
===
--- textproc/rubygem-version_sorter/distinfo (Revision 425382)
+++ textproc/rubygem-version_sorter/distinfo (Arbeitskopie)
@@ -1,2 +1,3 @@
-SHA256 (rubygem/version_sorter-2.0.0.gem) = deec62d586da2a2648a4329d1aa6dfd1c37ae9332a9ea276fdae0b3e084b4dd1
-SIZE (rubygem/version_sorter-2.0.0.gem) = 6656
+TIMESTAMP = 1476972624
+SHA256 (rubygem/version_sorter-2.1.0.gem) = b971598582cb657c1403180c5bf97e97568b9378ee4e4b0218a2bf8bdc02b1ea
+SIZE (rubygem/version_sorter-2.1.0.gem) = 6656
Index: www/gitlab/Makefile
===
--- www/gitlab/Makefile (Revision 425382)
+++ www/gitlab/Makefile (Arbeitskopie)
@@ -1,8 +1,8 @@
-# Created by: Torsten Zuehlsdorff
+# Created by: Torsten Zuehlsdorff
# $FreeBSD$
PORTNAME= gitlab
-PORTVERSION= 8.10.13
+PORTVERSION= 8.11.10
DISTVERSIONPREFIX= v
CATEGORIES= www devel
@@ -16,13 +16,14 @@
# the rubygems of RUN_DEPENDS matches the order of the Gemfile
# which makes maintaining this long list much easier!
RUN_DEPENDS= git>=2.7.4:devel/git \
- gitlab-shell>=3.2.1:devel/gitlab-shell\
- gitlab-workhorse>=0.7.8:www/gitlab-workhorse \
+ gitlab-shell>=3.4.0:devel/gitlab-shell\
+ gitlab-workhorse>=0.7.11:www/gitlab-workhorse \
redis>=2.8.23:databases/redis \
rubygem-rails4>=4.2.7.1:www/rubygem-rails4 \
rubygem-rails-deprecated_sanitizer>=1.0.3:devel/rubygem-rails-deprecated_sanitizer \
rubygem-responders>=2.0:www/rubygem-responders \
rubygem-sprockets3>=3.6:devel/rubygem-sprockets3 \
+ rubygem-sprockets-es6>=0:devel/rubygem-sprockets-es6 \
rubygem-default_value_for>=3.0.1:devel/rubygem-default_value_for \
rubygem-pg>=0.18.2:databases/rubygem-pg \
rubygem-devise>=4.0:devel/rubygem-devise \
@@ -49,12 +50,12 @@
rubygem-attr_encrypted>=3.0.0:security/rubygem-attr_encrypted \
rubygem-u2f>=0.2.1:net/rubygem-u2f
Re: GitLab user and tester wanted!
Aloha Johannes, Can you please update it past 8.11.10? It has a CVE outstanding: http://cve.circl.lu/cve/CVE-2016-9086 Yes, will do. Interest in testing? Next time i will post a patch which will actually work. I forget to add the new ports :D Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
GitLab 8.11.11 (was: Re: GitLab user and tester wanted!)
Aloha,
Can you please update it past 8.11.10? It has a CVE outstanding:
attached a full patch to bring GitLab to 8.11.11. It includes all needed
new ports and dependency updates.
The update documentation is also there - i just need to push it, but it
hasn't changed since last time. :)
So every test and feedback would be fine! (Never forget the backup!)
Greetings,
Torsten
Index: devel/gitlab-shell/Makefile
===
--- devel/gitlab-shell/Makefile (Revision 425795)
+++ devel/gitlab-shell/Makefile (Arbeitskopie)
@@ -1,8 +1,8 @@
-# Created by: Torsten Zuehlsdorff
# $FreeBSD$
PORTNAME= gitlab-shell
-PORTVERSION= 3.2.1
+PORTVERSION= 3.4.0
CATEGORIES= devel
MASTER_SITES= https://gitlab.com/gitlab-org/${PORTNAME}/repository/archive.tar.gz?ref=v${PORTVERSION}&dummy=/
DISTNAME= ${PORTNAME}-v${PORTVERSION}
Index: devel/gitlab-shell/distinfo
===
--- devel/gitlab-shell/distinfo (Revision 425795)
+++ devel/gitlab-shell/distinfo (Arbeitskopie)
@@ -1,3 +1,3 @@
-TIMESTAMP = 1470988234
-SHA256 (gitlab-shell-v3.2.1.tar.gz) = ad21f8676901b9d90a1c8016b5fe2ad73f9a7966ab378ce244b12fc0373e9f46
-SIZE (gitlab-shell-v3.2.1.tar.gz) = 68788
+TIMESTAMP = 1476972305
+SHA256 (gitlab-shell-v3.4.0.tar.gz) = 0ac8f18b1615194943e935b670d630a1ba9870ad876f7486256972c7be1d45d4
+SIZE (gitlab-shell-v3.4.0.tar.gz) = 71972
Index: devel/rubygem-newrelic_rpm/Makefile
===
--- devel/rubygem-newrelic_rpm/Makefile (Revision 425795)
+++ devel/rubygem-newrelic_rpm/Makefile (Arbeitskopie)
@@ -1,7 +1,7 @@
# $FreeBSD$
PORTNAME= newrelic_rpm
-PORTVERSION= 3.15.0.314
+PORTVERSION= 3.16.3.323
CATEGORIES= devel rubygems
MASTER_SITES= RG
Index: devel/rubygem-newrelic_rpm/distinfo
===
--- devel/rubygem-newrelic_rpm/distinfo (Revision 425795)
+++ devel/rubygem-newrelic_rpm/distinfo (Arbeitskopie)
@@ -1,2 +1,3 @@
-SHA256 (rubygem/newrelic_rpm-3.15.0.314.gem) = 30e1239e18358bb3fe84f6a2789f6c244d403e2d28b2690c9d7314067144f788
-SIZE (rubygem/newrelic_rpm-3.15.0.314.gem) = 736768
+TIMESTAMP = 1476972968
+SHA256 (rubygem/newrelic_rpm-3.16.3.323.gem) = 82a4216743a34bdc766838f3af2d4e174fb0672443ea8f730c9bf84243fb896c
+SIZE (rubygem/newrelic_rpm-3.16.3.323.gem) = 754688
Index: devel/rubygem-sprockets-es6/Makefile
===
--- devel/rubygem-sprockets-es6/Makefile (nicht existent)
+++ devel/rubygem-sprockets-es6/Makefile (Arbeitskopie)
@@ -0,0 +1,23 @@
+# Created by: Torsten Zuehlsdorff
+# $FreeBSD$
+
+PORTNAME= sprockets-es6
+PORTVERSION= 0.9.2
+CATEGORIES= devel rubygems
+MASTER_SITES= RG
+
+MAINTAINER= r...@freebsd.org
+COMMENT= Converts ES6 code into vanilla ES5 with Babel JS
+
+LICENSE= MIT
+LICENSE_FILE= ${WRKSRC}/LICENSE
+
+RUN_DEPENDS= rubygem-babel-source>=5.8.11:textproc/rubygem-babel-source \
+ rubygem-babel-transpiler>=0:textproc/rubygem-babel-transpiler \
+ rubygem-sprockets3>=3.0:devel/rubygem-sprockets3
+
+NO_ARCH= yes
+USE_RUBY= yes
+USES= gem
+
+.include
Eigenschaftsänderungen: devel/rubygem-sprockets-es6/Makefile
___
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:keywords
## -0,0 +1 ##
+FreeBSD=%H
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: devel/rubygem-sprockets-es6/distinfo
===
--- devel/rubygem-sprockets-es6/distinfo (nicht existent)
+++ devel/rubygem-sprockets-es6/distinfo (Arbeitskopie)
@@ -0,0 +1,3 @@
+TIMESTAMP = 1478261213
+SHA256 (rubygem/sprockets-es6-0.9.2.gem) = c383e06a234dfe5f15f3b9d59bd47471ef653133ea87308961087c69f7800814
+SIZE (rubygem/sprockets-es6-0.9.2.gem) = 6656
Eigenschaftsänderungen: devel/rubygem-sprockets-es6/distinfo
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: devel/rubygem-sprockets-es6/pkg-descr
===
--- devel/rubygem-sprockets-es6/pkg-descr (nicht existent)
+++ devel/rubygem-sprockets-es6/pkg-descr (Arbeitskopie)
@@ -0,0 +1,3 @@
+A Sprockets transformer that converts ES6 code into vanilla ES5 with Babel JS.
+
+WWW: https://github.com/TannerRogalsky/sprockets-es6
Eigenschaftsänderungen: devel/rubygem-sprockets-es6/pkg-descr
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No
Re: GitLab 8.11.11
Aloha,
Can you please update it past 8.11.10? It has a CVE outstanding:
attached a full patch to bring GitLab to 8.11.11. It includes all needed
new ports and dependency updates.
The update documentation is also there - i just need to push it, but it
hasn't changed since last time. :)
So every test and feedback would be fine! (Never forget the backup!)
Attached updated patch. The needed new ports are now committed. If there
is positive feedback i can commit the rest! :)
Greetings,
Torsten
Index: devel/gitlab-shell/Makefile
===
--- devel/gitlab-shell/Makefile (Revision 426098)
+++ devel/gitlab-shell/Makefile (Arbeitskopie)
@@ -1,8 +1,8 @@
-# Created by: Torsten Zuehlsdorff
# $FreeBSD$
PORTNAME= gitlab-shell
-PORTVERSION= 3.2.1
+PORTVERSION= 3.4.0
CATEGORIES= devel
MASTER_SITES= https://gitlab.com/gitlab-org/${PORTNAME}/repository/archive.tar.gz?ref=v${PORTVERSION}&dummy=/
DISTNAME= ${PORTNAME}-v${PORTVERSION}
Index: devel/gitlab-shell/distinfo
===
--- devel/gitlab-shell/distinfo (Revision 426098)
+++ devel/gitlab-shell/distinfo (Arbeitskopie)
@@ -1,3 +1,3 @@
-TIMESTAMP = 1470988234
-SHA256 (gitlab-shell-v3.2.1.tar.gz) = ad21f8676901b9d90a1c8016b5fe2ad73f9a7966ab378ce244b12fc0373e9f46
-SIZE (gitlab-shell-v3.2.1.tar.gz) = 68788
+TIMESTAMP = 1476972305
+SHA256 (gitlab-shell-v3.4.0.tar.gz) = 0ac8f18b1615194943e935b670d630a1ba9870ad876f7486256972c7be1d45d4
+SIZE (gitlab-shell-v3.4.0.tar.gz) = 71972
Index: devel/rubygem-newrelic_rpm/Makefile
===
--- devel/rubygem-newrelic_rpm/Makefile (Revision 426098)
+++ devel/rubygem-newrelic_rpm/Makefile (Arbeitskopie)
@@ -1,7 +1,7 @@
# $FreeBSD$
PORTNAME= newrelic_rpm
-PORTVERSION= 3.15.0.314
+PORTVERSION= 3.16.3.323
CATEGORIES= devel rubygems
MASTER_SITES= RG
Index: devel/rubygem-newrelic_rpm/distinfo
===
--- devel/rubygem-newrelic_rpm/distinfo (Revision 426098)
+++ devel/rubygem-newrelic_rpm/distinfo (Arbeitskopie)
@@ -1,2 +1,3 @@
-SHA256 (rubygem/newrelic_rpm-3.15.0.314.gem) = 30e1239e18358bb3fe84f6a2789f6c244d403e2d28b2690c9d7314067144f788
-SIZE (rubygem/newrelic_rpm-3.15.0.314.gem) = 736768
+TIMESTAMP = 1476972968
+SHA256 (rubygem/newrelic_rpm-3.16.3.323.gem) = 82a4216743a34bdc766838f3af2d4e174fb0672443ea8f730c9bf84243fb896c
+SIZE (rubygem/newrelic_rpm-3.16.3.323.gem) = 754688
Index: textproc/rubygem-version_sorter/Makefile
===
--- textproc/rubygem-version_sorter/Makefile (Revision 426098)
+++ textproc/rubygem-version_sorter/Makefile (Arbeitskopie)
@@ -2,7 +2,7 @@
# $FreeBSD$
PORTNAME= version_sorter
-PORTVERSION= 2.0.0
+PORTVERSION= 2.1.0
CATEGORIES= textproc rubygems
MASTER_SITES= RG
Index: textproc/rubygem-version_sorter/distinfo
===
--- textproc/rubygem-version_sorter/distinfo (Revision 426098)
+++ textproc/rubygem-version_sorter/distinfo (Arbeitskopie)
@@ -1,2 +1,3 @@
-SHA256 (rubygem/version_sorter-2.0.0.gem) = deec62d586da2a2648a4329d1aa6dfd1c37ae9332a9ea276fdae0b3e084b4dd1
-SIZE (rubygem/version_sorter-2.0.0.gem) = 6656
+TIMESTAMP = 1476972624
+SHA256 (rubygem/version_sorter-2.1.0.gem) = b971598582cb657c1403180c5bf97e97568b9378ee4e4b0218a2bf8bdc02b1ea
+SIZE (rubygem/version_sorter-2.1.0.gem) = 6656
Index: www/gitlab/Makefile
===
--- www/gitlab/Makefile (Revision 426098)
+++ www/gitlab/Makefile (Arbeitskopie)
@@ -1,8 +1,8 @@
-# Created by: Torsten Zuehlsdorff
+# Created by: Torsten Zuehlsdorff
# $FreeBSD$
PORTNAME= gitlab
-PORTVERSION= 8.10.13
+PORTVERSION= 8.11.11
DISTVERSIONPREFIX= v
CATEGORIES= www devel
@@ -16,13 +16,14 @@
# the rubygems of RUN_DEPENDS matches the order of the Gemfile
# which makes maintaining this long list much easier!
RUN_DEPENDS= git>=2.7.4:devel/git \
- gitlab-shell>=3.2.1:devel/gitlab-shell\
- gitlab-workhorse>=0.7.8:www/gitlab-workhorse \
+ gitlab-shell>=3.4.0:devel/gitlab-shell\
+ gitlab-workhorse>=0.7.11:www/gitlab-workhorse \
redis>=2.8.23:databases/redis \
rubygem-rails4>=4.2.7.1:www/rubygem-rails4 \
rubygem-rails-deprecated_sanitizer>=1.0.3:devel/rubygem-rails-deprecated_sanitizer \
rubygem-responders>=2.0:www/rubygem-responders \
rubygem-sprockets3>=3.6:devel/rubygem-sprockets3 \
+ rubygem-sprockets-es6>=0:devel/rubygem-sprockets-es6 \
rubygem-default_value_for>=3.0.1:devel/rubygem-default_value_for \
rubygem-pg>=0.18.2:databases/rubygem-pg \
rubygem-devise>=4.0:devel/rubygem-devise \
@@ -49,12 +50,12 @@
rubygem-attr_encrypted>=3.0.0:security/rubygem-attr_encrypted \
rubygem-u2f>=0.2.1:net/rubygem-u2f \
rubygem-browser>=2.2:www/rubygem-browser \
- rub
Re: FreeBSD ports you maintain which are out of date
On 14.12.2016 12:33, Johannes Jost Meixner wrote: Given that we've killed rails 3.x we can probably kill the -rails4 port; they're otherwise identical (not counting pkgnamesuffix). Maybe, maybe not. We should aim to include Rails 5 into the portstree. Therefore this convention could be recycled later. Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: svn commit: r434380 - in head: . Mk accessibility/qt4-accessible astro/xglobe/files audio/qmpdclient cad/klayout/files chinese/qt4-codecs-cn chinese/qt4-codecs-tw comms/hamfax/files comms/qt5-conn
On 18.02.2017 20:48, Tobias C. Berner wrote:
Author: tcberner
Date: Sat Feb 18 19:48:05 2017
New Revision: 434380
URL: https://svnweb.freebsd.org/changeset/ports/434380
Log:
Update Qt5 to 5.7.1, and unify the Qt4 and Qt5 ports some more
* Update Qt5 to 5.7.1
* Move Qt4 binaries to lib/qt4/bin
* Move Qt5 libraries to lib/qt5/lib
By moving the libraries we should finally be able to get rid of the inplace
upgrade bug (see ports bugs 194088, 195105 and 198720): when Qt5's
libraries
were lying in /usr/local/lib, which would often get added by pkgconfig to
the
linker paths via dependencies, the already installed libraries were linked
against, instead of the ones that were being built. This forced us to make
sure, that -L${WRKSRC}/lib was always coming before -L/usr/local/lib in the
linker flags. With this change this should no longer be the case.
* Rename some ports to match the rest (foo-qtX -> qtX-foo)
* Depend on new port misc/qtchooser [see UPDATING & CHANGES]
The new port misc/qtchooser conflics with
textproc/rubygem-github-linguist. When trying to install www/gitlab it
breaks with:
===> Installing for rubygem-github-linguist-5.0.0
===> Checking if rubygem-github-linguist already installed
===> Registering installation for rubygem-github-linguist-5.0.0 as
automatic
Installing rubygem-github-linguist-5.0.0...
pkg-static: rubygem-github-linguist-5.0.0 conflicts with qtchooser-39
(installs files into the same place). Problematic file:
/usr/local/bin/linguist
*** Error code 70
I have no solution right now, but at least a CONFLICT could be a start?
Any ideas?
Greetings,
Torsten
___
freebsd-ruby@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ruby
To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Help needed: net/rubygem-grpc
Hello,
in order to bring www/gitlab to its next big version, i need a Gem in
the ports-tree i'm struggling with. Its net/rubygem-rpc, here you find
its details:
https://rubygems.org/gems/grpc
https://github.com/grpc/grpc/tree/master/src/ruby
I created attached port (and various others), but always the error:
=== start ===
make[1]: illegal argument to -j -- must be positive integer!
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details.
You may
need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/local/bin/$(RUBY_BASE_NAME)23
extconf failed, exit code 1
=== end ===
If i remove usage of "gem" and use gmake instead, it will compile much
more and results in:
=== start ===
[C] Compiling src/core/lib/iomgr/socket_utils_linux.c
src/core/lib/iomgr/socket_utils_common_posix.c:101:39: error: use of
undeclared identifier 'IP_PKTINFO'
if (0 != setsockopt(fd, IPPROTO_IP, IP_PKTINFO, &get_local_ip,
^
1 error generated.
[C] Compiling src/core/lib/iomgr/socket_utils_posix.c
gmake[1]: *** [Makefile:2080:
/usr/ports/net/rubygem-grpc/work/grpc-1.0.0/objs/opt/src/core/lib/iomgr/socket_utils_common_posix.o]
Error 1
gmake[1]: *** Waiting for unfinished jobs
[C] Compiling src/core/lib/iomgr/socket_windows.c
gmake[1]: Leaving directory '/usr/ports/net/rubygem-grpc/work/grpc-1.0.0'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
===
This looks more familiar to typical linux/FreeBSD differences.
Is there anybody with advise/help out there to get this port run? GitLab
has currently security issues and the update is needed to fix them.
Greetings,
Torsten
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# rubygem-grpc/
# rubygem-grpc/distinfo
# rubygem-grpc/Makefile
# rubygem-grpc/pkg-descr
#
echo c - rubygem-grpc/
mkdir -p rubygem-grpc/ > /dev/null 2>&1
echo x - rubygem-grpc/distinfo
sed 's/^X//' >rubygem-grpc/distinfo << '2d532f1709f8f378a9a4a334b078'
XTIMESTAMP = 1497439725
XSHA256 (rubygem/grpc-1.0.0.gem) =
c4f908bdd1629bb56fa516bb5ed442187758853f285f31a805b2b940584c6835
XSIZE (rubygem/grpc-1.0.0.gem) = 2291712
2d532f1709f8f378a9a4a334b078
echo x - rubygem-grpc/Makefile
sed 's/^X//' >rubygem-grpc/Makefile << '20ba66e1f049c3d5d5dacedc2a057cc5'
X# $FreeBSD$
X
XPORTNAME= grpc
XPORTVERSION= 1.0.0
XCATEGORIES=net rubygems
XMASTER_SITES= RG
X
XMAINTAINER=t...@freebsd.org
XCOMMENT= Ruby implementation of gRPC
X
XLICENSE= BSD3CLAUSE
X
XMAKE_JOBS_UNSAFE=yes
X
XRUN_DEPENDS= grpc>=0:devel/grpc \
X rubygem-googleauth>=0.5.1:security/rubygem-googleauth \
X rubygem-google-protobuf>=3.0:devel/rubygem-google-protobuf
X
XNO_ARCH= yes
XUSE_RUBY= yes
XUSES= gem
X
X.include
20ba66e1f049c3d5d5dacedc2a057cc5
echo x - rubygem-grpc/pkg-descr
sed 's/^X//' >rubygem-grpc/pkg-descr << 'c0598ba2d5eca2594d23caf7882e7efa'
XA Ruby implementation of gRPC.
X
XWWW: https://github.com/grpc/grpc/tree/master/src/ruby
c0598ba2d5eca2594d23caf7882e7efa
exit
___
freebsd-ruby@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ruby
To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: Help needed: net/rubygem-grpc
On 28.06.2017 17:41, Matthias Fechner wrote: Hi Steve, Am 28.06.2017 um 04:14 schrieb Steve Wills: I was taking a look at this. It looks like several things are going on. As you noticed, it's going to have to use gmake, you can patch the extconf.rb for that. But then you run into other issues. It's expecting a pkg-config file for openssl, which we don't have for the openssl in base (src). I think this is the only thing in base lacking a .pc file. We will have to patch the Makefile for that. It would be best not to use any of the bundled things and instead use the versions from ports. I noticed there's a newer version, 1.4.0, but it has the same issues. Will the newer gitlab work with the 1.4.0 version of the grpc gem? regarding the comment here: https://gitlab.com/gitlab-org/gitaly/issues/154#note_33314534 I think gitlab should work with version 1.4.0, but I think a test is always a good idea. Thanks for your time Steve! To add something to Matthias comment: there is already a devel/grpc port, which seems to be very similar to the needed rubygem. Maybe this could help us? Greetings, Torsten ___ freebsd-ruby@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ruby To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
[Stage-QA] Gemfile-Check - WIP
Aloha,
inspired by lifanov and his work in PR 220605 to add a check for
.gemspec of rubygems i tried myself with Gemfile.
Background is, that checking the actual Gemfile of non rubygem-* ports
is often very time-consuming. When building Gitlab, Redmine or others,
everything is fine. But when executing they fail - because the Gemfile
is not satisfied.
Its WIP and my first try for an stage-qa script, so every comment is
appreciated. It adds a stage-qa stage for every non rubygem- port. When
executed i (intent) to scan for Gemfiles and checking every file with
bundle check. If bundle fails, the stage-qa fails.
It worked for simple test. If no Gemfile was present the test was
skipped. If it is, bundle is executed. When removing a needed dependency
it is found. Its also found when the dependency is indirect (not in
Gemfile itself, but a dependency of an dependency listed there).
But it don't work for net-im/mikutter for example and i don't know why.
So any feedback would be fine! :)
Greetings,
Torsten
--
Support me at:
https://www.patreon.com/TorstenZuehlsdorff
Index: Mk/Scripts/qa.sh
===
--- Mk/Scripts/qa.sh (Revision 447112)
+++ Mk/Scripts/qa.sh (Arbeitskopie)
@@ -822,10 +822,41 @@
return $rc
}
+# If an non rubygem-port has a 'Gemfile' file
+# it is checked with bundle to be sure
+# all dependencies are satisfied.
+# Without the check missing/wrong dependencies
+# are just found when executing the applicationx
+gemfiledeps()
+{
+ # check is only done for non rubygem-* ports
+ if [ "${PKGBASE%%-*}" != "rubygem" ]; then
+# locate the Gemfile(s)
+while read -r Gemfile; do
+
+ # if there is none everything is fine - stop here
+ ! [ -f "${Gemfile}" ] && return 0;
+
+ # use bundle to check if Gemfile is satisfied
+ bundle check --dry-run --gemfile ${Gemfile}
+
+ # if bundle returns 1 the Gemfile is not satisfied
+ # and so stage-qa isn't also
+ if [ $? -eq 1 ]; then
+ return 1;
+ fi
+
+done <<-EOF
+ $(find ${STAGEDIR} -name Gemfile)
+ EOF
+ fi
+ return 0
+}
+
checks="shebang symlinks paths stripped desktopfileutils sharedmimeinfo"
checks="$checks suidfiles libtool libperl prefixvar baselibs terminfo"
-checks="$checks proxydeps sonames perlcore no_arch"
+checks="$checks proxydeps sonames perlcore no_arch gemfiledeps"
ret=0
cd ${STAGEDIR}
___
freebsd-ruby@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ruby
To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
Re: [Stage-QA] Gemfile-Check - WIP
On 04.08.2017 15:48, Nikolai Lifanov wrote:
On 8/4/17 8:51 AM, Torsten Zuehlsdorff wrote:
Aloha,
inspired by lifanov and his work in PR 220605 to add a check for
.gemspec of rubygems i tried myself with Gemfile.
Background is, that checking the actual Gemfile of non rubygem-* ports
is often very time-consuming. When building Gitlab, Redmine or others,
everything is fine. But when executing they fail - because the Gemfile
is not satisfied.
Its WIP and my first try for an stage-qa script, so every comment is
appreciated. It adds a stage-qa stage for every non rubygem- port. When
executed i (intent) to scan for Gemfiles and checking every file with
bundle check. If bundle fails, the stage-qa fails.
It worked for simple test. If no Gemfile was present the test was
skipped. If it is, bundle is executed. When removing a needed dependency
it is found. Its also found when the dependency is indirect (not in
Gemfile itself, but a dependency of an dependency listed there).
But it don't work for net-im/mikutter for example and i don't know why.
So any feedback would be fine! :)
Greetings,
Torsten
Hi!
I think for something like this, a better initial approach is to make
this stage-qa target non-fatal, so warnings instead of errors.
At least initially it will cause less disruption and give porters an
opportunity to fix the errors.
Or we fix all issues before submitting - because the ports are broken if
this fails. The could not be used in any way.
I have two thoughts on it so far:
$(find ${STAGEDIR} -name Gemfile) is pretty heavy to do on every port.
Can we export something to QA_ENV from USE_RUBY and check for this instead?
I would like to make it optional, but i have no idea how
Is "bundle" guaranteed to be installed for ports that ship a Gemfile?
No.
Otherwise, it looks good and only has minor nits. Can we move this to
Phabricator? This will make it easier to review and iterate on.
I was in doubt it is already good enough for a review. But here we go:
https://reviews.freebsd.org/D11865
Greetings and thanks,
Torsten
--
Support me at:
https://www.patreon.com/TorstenZuehlsdorff
___
freebsd-ruby@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ruby
To unsubscribe, send any mail to "freebsd-ruby-unsubscr...@freebsd.org"
