Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
version bump ebuild for nvu 0.6 Reproducible: Always Steps to Reproduce:
Created an attachment (id=45369) [details] nvu-0.60.ebuild
basic: please add a comment, if you provide an modified ebuild. also the header in invalid -> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3
Created an attachment (id=45385) [details] nvu-0.60.ebuild second try, fixed the header. Sorry, forgot to mention this: This is a slightly modified ebuild from the 0.50 version. I changed (aside from the header), the KEYWORDS definition, the 2 lines starting with 'epatch' to use the patches for 0.50 (I checked that they apply cleanly).
Created an attachment (id=45386) [details] diff oops, uploaded the wrong file! Here's a diff. with the header fixed (finally).
Created an attachment (id=45488) [details] diff v2 with the previous ebuild, it seems to default to for --enable-optimize=-O . That causes nvu to crash on startup on my system (gcc 3.3.4-r1 x86). In this diff, I moved the patching and mozconfig stuff to src_unpack. Additionally, I copied the logic for --enable-optimize from mozilla.eclass .
Created an attachment (id=45489) [details] mozconfig.patch Here's a patch to remove --enable-strip from mozconfig and let portage handle stripping for easier debugging
Created an attachment (id=45500) [details] patch v3 forgot that src_unpack does not default to the source dir (got part of it right and part of it wrong :P). This adds a cd ${S} at the top.
Created an attachment (id=45501) [details] patch v3-r1 oops uploaded the wrong file. This one should work (famous last words...)
Everything looked pretty much ok. Only comment I have to make is that when bumping ebuilds, if the previous ebuild (0.50 say) had: ~foo ~bar ~foobar 0.60 keeps the same ~arch keywords. However, if it had: foo bar ~foobar Stable would get downgraded to unstable in the next version, so: ~foo ~bar ~foobar and unstable would stay unstable. The only time that keyword dropping really occurs is: a) The next version uses some special library that some arches haven't marked b) The next version is INSANELY rebuilt c) It's a new ebuild, and someone submits it with a huge number of arches that they haven't tested These are really the only reasons we'd ever drop keywords. Otherwise, the basic policy applies.
