Hello, all:
As - F14 feature freeze is tomorrow ! - Mohammed's ruby srpm was almost complete (as far as I tried using): http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm
I slightly modified Mohammed's srpm and imported into rawhide build tree. Now it is available on http://koji.fedoraproject.org/koji/buildinfo?buildID=186570
A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13: - Some cleanups - Make -irb, -rdoc subpackage noarch - Make dependencies between arch-dependent subpackages isa specific - Improve sample documentation gathering
I hope the imported new ruby won't break things (so much). I appreciate all peoples' contributing to ruby 187 packages.
Regards, Mamoru
On Mon, Jul 26, 2010 at 2:53 PM, Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp wrote:
Hello, all:
As
- F14 feature freeze is tomorrow !
- Mohammed's ruby srpm was almost complete (as far as I tried using):
http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm
I slightly modified Mohammed's srpm and imported into rawhide build tree. Now it is available on http://koji.fedoraproject.org/koji/buildinfo?buildID=186570
A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13:
- Some cleanups
- Make -irb, -rdoc subpackage noarch
- Make dependencies between arch-dependent subpackages isa specific
- Improve sample documentation gathering
I hope the imported new ruby won't break things (so much). I appreciate all peoples' contributing to ruby 187 packages.
Regards, Mamoru _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I assume we will send an update on-list (and probably on -devel as well) so that we can recompile rubygems as needed and such in rawhide?
stahnma
Michael Stahnke wrote, at 07/27/2010 07:01 AM +9:00:
On Mon, Jul 26, 2010 at 2:53 PM, Mamoru Tasaka mtasaka@ioa.s.u-tokyo.ac.jp wrote:
Hello, all:
As
- F14 feature freeze is tomorrow !
- Mohammed's ruby srpm was almost complete (as far as I tried using): http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm
I slightly modified Mohammed's srpm and imported into rawhide build tree. Now it is available on http://koji.fedoraproject.org/koji/buildinfo?buildID=186570
A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13:
- Some cleanups
- Make -irb, -rdoc subpackage noarch
- Make dependencies between arch-dependent subpackages isa specific
- Improve sample documentation gathering
I hope the imported new ruby won't break things (so much). I appreciate all peoples' contributing to ruby 187 packages.
Regards, Mamoru _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I assume we will send an update on-list (and probably on -devel as well) so that we can recompile rubygems as needed and such in rawhide?
stahnma
Well, no package should need recompiling against new ruby. Just updating ruby rpm (and its subpackages) should work.
Regards, Mamoru
Michael Stahnke wrote, at 07/27/2010 10:55 AM +9:00:
Well, no package should need recompiling against new ruby. Just updating ruby rpm (and its subpackages) should work.
What about gems that require ruby-devel to build? Have any C files been updated? ruby-ldap and most db connection gems come to mind.
stahnma
Even ruby related rpms which are arch-dependent should just be fine with new ruby without recompiling.
Regards, Mamoru
On 07/26/2010 03:53 PM, Mamoru Tasaka wrote:
Hello, all:
As
- F14 feature freeze is tomorrow !
- Mohammed's ruby srpm was almost complete (as far as I tried using): http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm
I slightly modified Mohammed's srpm and imported into rawhide build tree. Now it is available on http://koji.fedoraproject.org/koji/buildinfo?buildID=186570
A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13:
- Some cleanups
- Make -irb, -rdoc subpackage noarch
- Make dependencies between arch-dependent subpackages isa specific
- Improve sample documentation gathering
I hope the imported new ruby won't break things (so much). I appreciate all peoples' contributing to ruby 187 packages.
Regards, Mamoru
Thanks for this Mamoru, just went through and rebuilt your srpm, and have a couple of comments:
Some rpmlint output:
$ rpmlint /home/mmorsi/rpmbuild/SRPMS/ruby-1.8.7.299-4.fc13.src.rpm
ruby.src: W: no-cleaning-of-buildroot %install ruby.src: W: no-buildroot-tag
Are the result of removing "BuildRoot" and "rm -rf $RPM_BUILD_ROOT " as per the following guidelines, and can be ignored correct?
http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag
ruby.src:264: W: mixed-use-of-spaces-and-tabs (spaces: line 264, tab:
line 1)
You have a tab on the "-mindepth 1 " line in the spec, this should be removed.
$ rpmlint /home/mmorsi/rpmbuild/RPMS/x86_64/ruby-1.8.7.299-4.fc13.x86_64.rpm
ruby.x86_64: W: obsolete-not-provided ruby-mode ruby.x86_64: W: obsolete-not-provided ruby-docs
In my latest spec I got around these by adding a 'Provides' for both ruby-mode / ruby-docs, where as you explicitly state "no Provides here". Is this the correct approach to do so? Eg if the emacs package provides the ruby-mode functionality, shouldn't it be that package that obsoletes and provides ruby-mode? Also since our package Obsoletes ruby-doc shouldn't it provide it as well?
ruby.x86_64: E: wrong-script-interpreter
/usr/share/doc/ruby-1.8.7.299/sample/mpart.rb ./ruby
I had gotten around this by adding the following to my spec (in the section the other interpreter paths get corrected)
sed -i -e 's/^#!\s*./ruby/#! /usr/bin/ruby/' sample/mpart.rb
$ rpmlint /home/mmorsi/rpmbuild/RPMS/x86_64/ruby-tcltk-1.8.7.299-4.fc13.x86_64.rpm
ruby-tcltk.x86_64: E: non-executable-script
/usr/lib/ruby/1.8/tkextlib/pkg_checker.rb 0644L /usr/bin/env
I got around this by removing the shebang from the top of the file like so.
sed -i -e '/^#!.*/,1D' ext/tk/lib/tkextlib/pkg_checker.rb
===
AFAIK all the other rpmlint warnings can be ignored. Just going through the spec file itself, I'm just wondering why the complexity for the iconv stuff. Unless I missed something major, I just went through the files rpmlint was stating weren't utf-8 and ran "iconv -f iso8859-1 -t utf-8" on them to take care of the issue. No need for any sed'ing. Did I oversimplify the issue?
Also I can't help but feel that we should put some of this stuff in the source %prep section, not in the %install section, and would be interested in seeing what (if anything) the guidelines say about this. Regardless these last couple are not big issues, I wouldn't have a problem with the Ruby rpms going in without them being resolved.
BTW I tested this latest RPM in a VM and am happy to say via some light surface testing: rake, rack, rails, rspec, and gem work out of the box, and the puppet, rails, and deltacloud test/spec suites work in the same manner as they do against 1.8.6.
We should be good to go for F14, though I don't think we'll pass through 100% unscathed. There might be a few bug reports against some specific gems, but the major ones (and I'm guessing most others) should work fine and what doesn't can be taken on a case-by-case basis as they will need to be anyway.
Once again, thanks for the updated rpms and reviews.
-Mo
Hello:
Mohammed Morsi wrote, at 07/29/2010 10:16 AM +9:00:
On 07/26/2010 03:53 PM, Mamoru Tasaka wrote:
Hello, all:
As
- F14 feature freeze is tomorrow !
- Mohammed's ruby srpm was almost complete (as far as I tried using):
http://mo.morsi.org/files/rpms/ruby-1.8.7.299-3.fc13.src.rpm
I slightly modified Mohammed's srpm and imported into rawhide build tree. Now it is available on http://koji.fedoraproject.org/koji/buildinfo?buildID=186570
A summary of changes from Mohammed's ruby-1.8.7.299-3.fc13:
- Some cleanups
- Make -irb, -rdoc subpackage noarch
- Make dependencies between arch-dependent subpackages isa specific
- Improve sample documentation gathering
I hope the imported new ruby won't break things (so much). I appreciate all peoples' contributing to ruby 187 packages.
Regards, Mamoru
Thanks for this Mamoru, just went through and rebuilt your srpm, and have a couple of comments:
Thank you for feedback.
Some rpmlint output: $ rpmlint /home/mmorsi/rpmbuild/SRPMS/ruby-1.8.7.299-4.fc13.src.rpm
ruby.src: W: no-cleaning-of-buildroot %install ruby.src: W: no-buildroot-tag
Are the result of removing "BuildRoot" and "rm -rf $RPM_BUILD_ROOT " as per the following guidelines, and can be ignored correct?
http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag
- Yes, BuildRoot tag, cleaning %buildroot at %install are no longer needed.
ruby.src:264: W: mixed-use-of-spaces-and-tabs (spaces: line 264, tab: line 1)
You have a tab on the "-mindepth 1 " line in the spec, this should be removed.
- Actually I removed a space on this line. Now rpmlint warns that spaces are used in %changelog section, however I won't modify old %changelog entry for this (we can consider moving the old %changelog entry out of the spec file as you did)
$ rpmlint /home/mmorsi/rpmbuild/RPMS/x86_64/ruby-1.8.7.299-4.fc13.x86_64.rpm
ruby.x86_64: W: obsolete-not-provided ruby-mode ruby.x86_64: W: obsolete-not-provided ruby-docs
In my latest spec I got around these by adding a 'Provides' for both ruby-mode / ruby-docs, where as you explicitly state "no Provides here". Is this the correct approach to do so? Eg if the emacs package provides the ruby-mode functionality, shouldn't it be that package that obsoletes and provides ruby-mode? Also since our package Obsoletes ruby-doc shouldn't it provide it as well?
- In this case corresponding Provides should not be added. - Adding "Provides: ruby-mode" in emacs is confusing. as "emacs" and "ruby" have little relation, and so it is not desired for maintainability. - Now no package "actually" provides what was in ruby-doc.
ruby.x86_64: E: wrong-script-interpreter /usr/share/doc/ruby-1.8.7.299/sample/mpart.rb ./ruby
I had gotten around this by adding the following to my spec (in the section the other interpreter paths get corrected) sed -i -e 's/^#!\s*./ruby/#! /usr/bin/ruby/' sample/mpart.rb
- Fixed.
$ rpmlint /home/mmorsi/rpmbuild/RPMS/x86_64/ruby-tcltk-1.8.7.299-4.fc13.x86_64.rpm
ruby-tcltk.x86_64: E: non-executable-script /usr/lib/ruby/1.8/tkextlib/pkg_checker.rb 0644L /usr/bin/env
I got around this by removing the shebang from the top of the file like so. sed -i -e '/^#!.*/,1D' ext/tk/lib/tkextlib/pkg_checker.rb
- Instead I marked this file executable because this script can actually be executed. Now this script reports some errors, however as this script says "Shown status may be wrong" (and as I don't know how to fix the reported errors) I leave it for now...
===
AFAIK all the other rpmlint warnings can be ignored. Just going through the spec file itself, I'm just wondering why the complexity for the iconv stuff. Unless I missed something major, I just went through the files rpmlint was stating weren't utf-8 and ran "iconv -f iso8859-1 -t utf-8" on them to take care of the issue. No need for any sed'ing. Did I oversimplify the issue?
- Actually as shown in build.log, actually some files are in EUC-JP (not ISO-8859-1) and some are in ISO-8859-1. - EUC-JP encoding is commonly used in (UNIX) Japanese texts (even now). Unfortunately rpmlint cannot detect EUC-JP encoding (which is Japanese specific), and sometimes rpmlint reports 'it is under ISO-8859-1', and sometimes rpmlint says nothing.
- Some texts have 'EUC-JP' string in them, and after changing encoding, such strings must also be changed (On some ruby scripts this is critical because if trying to execute such scripts which are converted from EUC-JP to UTF-8 but still contain "EUC-JP" string, this causes some unexpected behavior)
Also I can't help but feel that we should put some of this stuff in the source %prep section, not in the %install section, and would be interested in seeing what (if anything) the guidelines say about this. Regardless these last couple are not big issues, I wouldn't have a problem with the Ruby rpms going in without them being resolved.
BTW I tested this latest RPM in a VM and am happy to say via some light surface testing: rake, rack, rails, rspec, and gem work out of the box, and the puppet, rails, and deltacloud test/spec suites work in the same manner as they do against 1.8.6.
Thank you for testing. By the way, if rails 2.3.8 is ready, would you upgrade Fedora's rails related packages to 2.3.8 for rawhide/F-14 for now?
- Fixing encoding or using massive "sed" on files only for sample files which are actually to be installed (i.e. executing this under tmp-ruby-docs) is much safer than executing these in %prep, so I think we need not move this to %prep.
Committed in -5.
Regards, Mamoru
Hello there dear fedorian/rubyists...
Finally i made it, and now i'm an official fedora packager. I'll do my best to help ruby at fedora and according to my skills (not much) :)
Count me in :)
Guillermo (gomix)
On 08/01/2010 02:52 PM, Mamoru Tasaka wrote:
<snip> > === > > AFAIK all the other rpmlint warnings can be ignored. Just going through the spec file itself, > I'm just wondering why the complexity for the iconv stuff. Unless I missed something major, > I just went through the files rpmlint was stating weren't utf-8 and ran "iconv -f iso8859-1 -t utf-8" > on them to take care of the issue. No need for any sed'ing. Did I oversimplify the issue? - Actually as shown in build.log, actually some files are in EUC-JP (not ISO-8859-1) and some are in ISO-8859-1. - EUC-JP encoding is commonly used in (UNIX) Japanese texts (even now). Unfortunately rpmlint cannot detect EUC-JP encoding (which is Japanese specific), and sometimes rpmlint reports 'it is under ISO-8859-1', and sometimes rpmlint says nothing.
- Some texts have 'EUC-JP' string in them, and after changing encoding, such strings must also be changed (On some ruby scripts this is critical because if trying to execute such scripts which are converted from EUC-JP to UTF-8 but still contain "EUC-JP" string, this causes some unexpected behavior)
This is good to know, thanks for the tip.
BTW I tested this latest RPM in a VM and am happy to say via some light surface testing: rake, rack, rails, rspec, and gem work out of the box, and the puppet, rails, and deltacloud test/spec suites work in the same manner as they do against 1.8.6.
Thank you for testing. By the way, if rails 2.3.8 is ready, would you upgrade Fedora's rails related packages to 2.3.8 for rawhide/F-14 for now?
I just went through and cleaned up and updated the Rails 2.3.8 rpms.
I uploaded the new srpms to my blog here http://mo.morsi.org/blog/node/325
All the issues that I could find are now taken care of, and the rpms work fine against Ruby 1.8.7 being shipped w/ F14.
I tested rails as far as creating a new project, generating a new controller with a 'hello world' action / view, interfacing with the sqlite3-ruby gem, and running ./script/server and verifying the results. Everything worked as it should without errors.
If anything looks off, shout out, else it would be good to start pushing for these to be updated in Fedora.
-Mo
Mohammed Morsi wrote, at 08/11/2010 01:49 AM +9:00:
On 08/01/2010 02:52 PM, Mamoru Tasaka wrote:
<snip> > ===
BTW I tested this latest RPM in a VM and am happy to say via some light surface testing: rake, rack, rails, rspec, and gem work out of the box, and the puppet, rails, and deltacloud test/spec suites work in the same manner as they do against 1.8.6.
Thank you for testing. By the way, if rails 2.3.8 is ready, would you upgrade Fedora's rails related packages to 2.3.8 for rawhide/F-14 for now?
I just went through and cleaned up and updated the Rails 2.3.8 rpms.
I uploaded the new srpms to my blog here http://mo.morsi.org/blog/node/325 All the issues that I could find are now taken care of, and the rpms work fine against Ruby 1.8.7 being shipped w/ F14.
I tested rails as far as creating a new project, generating a new controller with a 'hello world' action / view, interfacing with the sqlite3-ruby gem, and running ./script/server and verifying the results. Everything worked as it should without errors.
If anything looks off, shout out, else it would be good to start pushing for these to be updated in Fedora.
-Mo
First of all, I appreciate your contribution to rails 2.3.8 srpms.
Well, I am not familiar with rails so I cannot do "detailed" test for new gem related srpms. So for now I just took diffs of the spec files between on current Fedora SCM and in your srpms. Then some notes:
- Would you check (and update) the dependency for each binary rpm? At least it seems - -actionpack rpm now should have R: rubygem(rack) >= 1.1.0. By the way current latest rack version is 1.2.1, however can actionpack (2.3.8) work with rack 1.2.x? actionpack 2.3.8 metadata seems to have "~> 1.1.0" dependency for rack, so rack 1.2.x and actionpack 2.3.8 seems incompatible "as it is".
- About activerecord-2.3.8-sqlite3-compat.patch in -activerecord srpm: - Does this patch work after sqlite3-ruby is updated to the latest? (i.e. is SQLite3::Version::STRING defined in sqlite3-ruby 1.3.1?) If not, I think the applied patch should be revised so that patches activerecord 2.3.8 works with both sqlite3-ruby 1.2.4 (current Fedora) and 1.3.1 (latest).
Something like below? if current_adapter?(:SQLite3Adapter) && defined?(SQLite3::Version::VERSION) && SQLite3::Version::VERSION > '1.2.5'
Regards, Mamoru
On 08/10/2010 02:30 PM, Mamoru Tasaka wrote:
Mohammed Morsi wrote, at 08/11/2010 01:49 AM +9:00:
On 08/01/2010 02:52 PM, Mamoru Tasaka wrote:
<snip> > === > BTW I tested this latest RPM in a VM and am happy to say via some light surface testing: > rake, rack, rails, rspec, and gem work out of the box, and the puppet, rails, and deltacloud > test/spec suites work in the same manner as they do against 1.8.6. Thank you for testing. By the way, if rails 2.3.8 is ready, would you upgrade Fedora's rails related packages to 2.3.8 for rawhide/F-14 for now?
I just went through and cleaned up and updated the Rails 2.3.8 rpms.
I uploaded the new srpms to my blog here http://mo.morsi.org/blog/node/325 All the issues that I could find are now taken care of, and the rpms work fine against Ruby 1.8.7 being shipped w/ F14.
I tested rails as far as creating a new project, generating a new controller with a 'hello world' action / view, interfacing with the sqlite3-ruby gem, and running ./script/server and verifying the results. Everything worked as it should without errors.
If anything looks off, shout out, else it would be good to start pushing for these to be updated in Fedora.
-Mo
First of all, I appreciate your contribution to rails 2.3.8 srpms.
Well, I am not familiar with rails so I cannot do "detailed" test for new gem related srpms. So for now I just took diffs of the spec files between on current Fedora SCM and in your srpms. Then some notes:
- Would you check (and update) the dependency for each binary rpm? At least it seems
- -actionpack rpm now should have R: rubygem(rack)>= 1.1.0. By the way current latest rack version is 1.2.1, however can actionpack (2.3.8) work with rack 1.2.x? actionpack 2.3.8 metadata seems to have "~> 1.1.0" dependency for rack, so rack 1.2.x and actionpack 2.3.8 seems incompatible "as it is".
Done, updated actionpack rpm here:
http://mo.morsi.org/files/rpms/rubygem-actionpack-2.3.8-2.fc13.src.rpm
I believe actionpack should work with rack 1.2.x as indicated by this upstream commit
http://github.com/rails/rails/commit/f3bb185b03e746b52a4035a6df002597d8552e7...
Should there be some issues when we update rack, most likely they will just entail finding the upstream commits which fix those and apply them to the rpm (if not just rebasing the rpm itself to a more updated actionpack version with the fixes included).
About activerecord-2.3.8-sqlite3-compat.patch in -activerecord srpm:
Does this patch work after sqlite3-ruby is updated to the latest? (i.e. is SQLite3::Version::STRING defined in sqlite3-ruby 1.3.1?) If not, I think the applied patch should be revised so that patches activerecord 2.3.8 works with both sqlite3-ruby 1.2.4 (current Fedora) and 1.3.1 (latest).
Something like below? if current_adapter?(:SQLite3Adapter)&& defined?(SQLite3::Version::VERSION)&& SQLite3::Version::VERSION> '1.2.5'
The way I did it should work against both 1.2.4 and 1.3.1 since both define Version::STRING, where as only version 1.3.1 defines Version::VERSION.
Regardless, your way also works, and with the goal of getting these updates into Fedora asap, I updated the SRPM which can be found here:
http://mo.morsi.org/files/rpms/rubygem-activerecord-2.3.8-2.fc13.src.rpm
-Mo
Hello:
Mohammed Morsi wrote, at 08/13/2010 03:45 AM +9:00:
On 08/10/2010 02:30 PM, Mamoru Tasaka wrote:
Mohammed Morsi wrote, at 08/11/2010 01:49 AM +9:00:
On 08/01/2010 02:52 PM, Mamoru Tasaka wrote:
<snip> > === > BTW I tested this latest RPM in a VM and am happy to say via some light surface testing: > rake, rack, rails, rspec, and gem work out of the box, and the puppet, rails, and deltacloud > test/spec suites work in the same manner as they do against 1.8.6. Thank you for testing. By the way, if rails 2.3.8 is ready, would you upgrade Fedora's rails related packages to 2.3.8 for rawhide/F-14 for now?
I just went through and cleaned up and updated the Rails 2.3.8 rpms.
I uploaded the new srpms to my blog here http://mo.morsi.org/blog/node/325 All the issues that I could find are now taken care of, and the rpms work fine against Ruby 1.8.7 being shipped w/ F14.
I tested rails as far as creating a new project, generating a new controller with a 'hello world' action / view, interfacing with the sqlite3-ruby gem, and running ./script/server and verifying the results. Everything worked as it should without errors.
If anything looks off, shout out, else it would be good to start pushing for these to be updated in Fedora.
-Mo
First of all, I appreciate your contribution to rails 2.3.8 srpms.
Well, I am not familiar with rails so I cannot do "detailed" test for new gem related srpms. So for now I just took diffs of the spec files between on current Fedora SCM and in your srpms. Then some notes:
- Would you check (and update) the dependency for each binary rpm?
At least it seems
- -actionpack rpm now should have R: rubygem(rack)>= 1.1.0.
By the way current latest rack version is 1.2.1, however can actionpack (2.3.8) work with rack 1.2.x? actionpack 2.3.8 metadata seems to have "~> 1.1.0" dependency for rack, so rack 1.2.x and actionpack 2.3.8 seems incompatible "as it is".
Done, updated actionpack rpm here:
http://mo.morsi.org/files/rpms/rubygem-actionpack-2.3.8-2.fc13.src.rpm
I believe actionpack should work with rack 1.2.x as indicated by this upstream commit
http://github.com/rails/rails/commit/f3bb185b03e746b52a4035a6df002597d8552e7...
Should there be some issues when we update rack, most likely they will just entail finding the upstream commits which fix those and apply them to the rpm (if not just rebasing the rpm itself to a more updated actionpack version with the fixes included).
- About activerecord-2.3.8-sqlite3-compat.patch in -activerecord srpm:
- Does this patch work after sqlite3-ruby is updated to the latest?
(i.e. is SQLite3::Version::STRING defined in sqlite3-ruby 1.3.1?) If not, I think the applied patch should be revised so that patches activerecord 2.3.8 works with both sqlite3-ruby 1.2.4 (current Fedora) and 1.3.1 (latest).
Something like below? if current_adapter?(:SQLite3Adapter)&& defined?(SQLite3::Version::VERSION)&& SQLite3::Version::VERSION> '1.2.5'
The way I did it should work against both 1.2.4 and 1.3.1 since both define Version::STRING, where as only version 1.3.1 defines Version::VERSION.
Regardless, your way also works, and with the goal of getting these updates into Fedora asap, I updated the SRPM which can be found here:
http://mo.morsi.org/files/rpms/rubygem-activerecord-2.3.8-2.fc13.src.rpm
-Mo
Again I just checked spec files (and patches) only (because I don't know about rails well), however on my eyes now your srpms are good. Now I think these srpms should be imported into F15 / F14 (at least F14-testing) tree ASAP so that people can test them.
Opinions welcome.
Regards, Mamoru
ruby-sig@lists.fedoraproject.org
-
"Guillermo Gómez S." -
Mamoru Tasaka -
Michael Stahnke -
Mo Morsi