https://rubygems.org/gems/poppler
dev-ruby/ruby-poppler is part of the ruby-gnome2 package, so all the split packages will need to be bumped, not just ruby-poppler.
Upstream packaging changed to the point that we need changes in our supporting eclass. Also, according to the release notes there are hardly any other changes, so I'm going to give this bug a lower priority.
There seems to be noticeable changes from 0.90.5 to 0.90.8 (e.g. fix crash by GC at exit on 0.90.8) and the current version is almost one year old. How about bumping it to 0.90.8?
(In reply to comment #3) > There seems to be noticeable changes from 0.90.5 to 0.90.8 (e.g. fix crash by > GC at exit on 0.90.8) and the current version is almost one year old. > How about bumping it to 0.90.8? Good idea, but unfortunately we are short on man-power, and this is not a straightforward bump since the eclass needs to take into account the changes in the build system (and still remain compatible at least for a while with the old mechanism). Patches, etc. welcome.
Created attachment 272817 [details, diff] patch for eclass, ebuild and 2 new ebuild I've wrote this patch and test like the following: cd /usr/portage/dev-ruby emerge -1 -j2 `find . -name '*.ebuild' |xargs grep -l ruby-ng-gnome2 |cut -d/ -f 3| sed -e 's/.ebuild$//; s/^/=/'|grep 0.19` # (test old version) emerge -1 -j2 `find . -name '*.ebuild' |xargs grep -l ruby-ng-gnome2 |cut -d/ -f 3| sed -e 's/.ebuild$//; s/^/=/'|grep 0.90` # (test new version) All emerge worked without error, warn and QA notice.
I think it would be better to special-case the old versions instead of the new versions (so to reverse the get_version_component_range check). That way we won't get into trouble if the version changes to e.g. .91 or something similar. Also the LDFLAGS change is a good idea by itself, so it would be good to make that a separate commit. Other than that your changes look fine to me. Please feel free to apply these changes to the tree.
Thanks, I'll commit later. BTW gtksourceview and rsvg changed their directory names to gtksourceview2 and rsvg2. Would it be better to rename the package names?
Created attachment 272865 [details] pkg-config-1.1.1.ebuild I've also forgot to notice that all gnome2 packages depend on new ebuild dev-ruby/pkg-config. Here is pkg-config ebuild.
(In reply to comment #8) > Created attachment 272865 [details] > pkg-config-1.1.1.ebuild > > I've also forgot to notice that all gnome2 packages depend on new ebuild > dev-ruby/pkg-config. Here is pkg-config ebuild. It looks like this package has tests (at least in git). In that case we prefer to run the tests also. Could you have a look at that?
(In reply to comment #9) > (In reply to comment #8) > > Created attachment 272865 [details] > > pkg-config-1.1.1.ebuild > > > > I've also forgot to notice that all gnome2 packages depend on new ebuild > > dev-ruby/pkg-config. Here is pkg-config ebuild. > > It looks like this package has tests (at least in git). In that case we prefer > to run the tests also. Could you have a look at that? I ran the test. The test need unpackaged file "Manifest.txt". And (at least some) tests depend on system status. (e.g. require cairo installed) I don't think it is good idea to add cairo dependency for this simple package...
Created attachment 273963 [details] Manifest.txt needed on test
Created attachment 273965 [details] test enable pkg-config-1.1.1.ebuild This is test enabled pkg-config (still many tests fail)
(In reply to comment #12) > Created attachment 273965 [details] > test enable pkg-config-1.1.1.ebuild > > This is test enabled pkg-config (still many tests fail) The reason that I think test are important is that we are trying to provide our packages for as many ruby implementations as possible, and the tests have proven to be a good way to find the problem spots. But we also need to be pragmatic here, so if pkg-config has this many problems with tests then I'm fine also with adding this new version to the tree with RESTRICT="test". This way it's clear that we know these tests have problems and we might be able to improve them later. pkg-config will be used already when installing the other ruby-gnome packages, so arch teams will implicitly test it anyway.
(In reply to comment #13) > (In reply to comment #12) > > Created attachment 273965 [details] > > test enable pkg-config-1.1.1.ebuild > > > > This is test enabled pkg-config (still many tests fail) > > The reason that I think test are important is that we are trying to provide our > packages for as many ruby implementations as possible, and the tests have > proven to be a good way to find the problem spots. > > But we also need to be pragmatic here, so if pkg-config has this many problems > with tests then I'm fine also with adding this new version to the tree with > RESTRICT="test". This way it's clear that we know these tests have problems and > we might be able to improve them later. > > pkg-config will be used already when installing the other ruby-gnome packages, > so arch teams will implicitly test it anyway. OK .. Is it fine for me to commit RESTRICT="test" version of dev-ruby/pkg-config?
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > OK .. Is it fine for me to commit RESTRICT="test" version of > dev-ruby/pkg-config? Yes, please do. We can try to fix the situation later or on further version bumps. I think it's more important to get a newer ruby-gnome2 version in the tree.
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > (In reply to comment #12) > > > OK .. Is it fine for me to commit RESTRICT="test" version of > > dev-ruby/pkg-config? > > Yes, please do. We can try to fix the situation later or on further version > bumps. I think it's more important to get a newer ruby-gnome2 version in the > tree. Thanks. I've commit the package setting maintainer to me and herd to ruby. Now I'm ready to commit new gnome2 packages. I'll commit them soon after final check.
OK. All changes are now in CVS. Some KEYWORDs dropped due to dev-ruby/pkg-config and some new ruby-gnome2 packages don't have them. (maybe separated bug needed?) List of dropped KEYWORDs ruby-glib2: alpha ia64 ppc ppc64 sparc x86-macos ruby-gdkpixbuf2: alpha ia64 ppc sparc ruby-pango: alpha ia64 ppc sparc ruby-atk: alpha ia64 ppc sparc ruby-gtk2: alpha ia64 ppc sparc ruby-gtkmozembed: ia64 ppc sparc ruby-gtksourceview: ia64 ppc sparc ruby-poppler: ppc ruby-rsvg: ia64 ppc ruby-vte: ppc ruby-gnome2: alpha ia64 ppc sparc
(In reply to comment #17) > OK. All changes are now in CVS. > > Some KEYWORDs dropped due to dev-ruby/pkg-config and some new ruby-gnome2 > packages don't have them. (maybe separated bug needed?) > > List of dropped KEYWORDs > ruby-glib2: alpha ia64 ppc ppc64 sparc x86-macos > ruby-gdkpixbuf2: alpha ia64 ppc sparc > ruby-pango: alpha ia64 ppc sparc > ruby-atk: alpha ia64 ppc sparc > ruby-gtk2: alpha ia64 ppc sparc > ruby-gtkmozembed: ia64 ppc sparc > ruby-gtksourceview: ia64 ppc sparc > ruby-poppler: ppc > ruby-rsvg: ia64 ppc > ruby-vte: ppc > ruby-gnome2: alpha ia64 ppc sparc Yes this can be closed as the bumps are done and a new bug should be opened for the arches to add their keywords.
