Fixed similiar, as in udev-9999 case :) Tested on animals. --- --- systemd-9999.ebuild 2013-12-04 04:31:33.000000000 +0100 +++ systemd-9999-r1.ebuild 2013-12-28 21:09:27.633579196 +0100 @@ -86,15 +86,17 @@ #if LIVE DEPEND="${DEPEND} dev-libs/gobject-introspection - >=dev-libs/libgcrypt-1.4.5:0 - >=dev-util/gtk-doc-1.18" + >=dev-libs/libgcrypt-1.4.5:0" SRC_URI= KEYWORDS= src_prepare() { - gtkdocize --docdir docs/ || die - + if use doc; then + gtkdocize --docdir docs/ || die + else + echo 'EXTRA_DIST =' > docs/gtk-doc.make + fi autotools-utils_src_prepare } #endif Reproducible: Always
Hacking around deps in -9999 does not make sense. If you really want to use -9999, you play by the rules.
so, why then it's hacked for udev-9999 in main tree?
and anyway, whole #if LIVE is hacked in ebuild. Some of us use Gentoo, because _choice_ and I don't want to use gtk-doc, because I don't need it or use it. Not related to this bug ========================== There is systemd-9999 with added lines for "kdbus" [1] and updated metadata [2]. [1] https://raw.github.com/okias/ixit/master/sys-apps/systemd/systemd-9999-r1.ebuild [2] https://raw.github.com/okias/ixit/master/sys-apps/systemd/metadata.xml
(In reply to David Heidelberger (okias) from comment #2) > so, why then it's hacked for udev-9999 in main tree? Because it is maintained by different people and that's their problem. (In reply to David Heidelberger (okias) from comment #3) > and anyway, whole #if LIVE is hacked in ebuild. And? > Some of us use Gentoo, because _choice_ and I don't want to use gtk-doc, > because I don't need it or use it. And you have the choice of using non-9999 ebuild. Problem solved, let's focus on something useful. Also, you are not supposed to reopen bugs marked as WONTFIX yourself.
Some people would apparently like to improve Gentoo and removing unnecessary dependencies is a part of it, whether it's a live ebuild. When technical reasoning doesn't help, who I need to be friend of to get my or other people's *trivial* bug reports *with * handled? Or what else is needed? Also, could you please point us to some document about what to do when a bug report gets marked WONTFIX and how to deal with -9999 bugs? Thank you. So far I don't know about other ways to appeal a WONTFIX then reopening it a reasonable number of times. Did I miss something?
(In reply to Pavel Šimerda from comment #5) It can be quite a annoying to close a bug with a clear-cut decision, only to have it reopened just to argue about it. In general there is no "appeals" process for a bug closed as WONTFIX; especially for something like a live ebuild. It's up to us (the maintainers) to decided what we want to support. You are welcome to try to convince us to do something, but that doesn't mean you will always get what you want.
(In reply to Mike Gilbert from comment #6) > (In reply to Pavel Šimerda from comment #5) > > It can be quite a annoying to close a bug with a clear-cut decision, only to > have it reopened just to argue about it. Well, I though Gentoo idea is to have only dependencies we need > > In general there is no "appeals" process for a bug closed as WONTFIX; > especially for something like a live ebuild. It's up to us (the maintainers) > to decided what we want to support. Why then we have live ebuild, when I have to mirror it in overlay, to get it correctly compiled? > > You are welcome to try to convince us to do something, but that doesn't mean > you will always get what you want. Well, I wanted systemd ebuild with KDbus support and I have it (in my overlay). My point is to get it available for other people too. I just saying, it may help others...
(In reply to Mike Gilbert from comment #6) > (In reply to Pavel Šimerda from comment #5) > > It can be quite a annoying to close a bug with a clear-cut decision, only to > have it reopened just to argue about it. In other projects, it's quite common to supply clear-cut decisions with clear-cut reasoning. When some published policy is being used, it's usually refered (or even directly linked) from the decision comment. > In general there is no "appeals" process for a bug closed as WONTFIX; Sounds like a decent "fuck off" even for such > especially for something like a live ebuild. It's up to us (the maintainers) > to decided what we want to support. Unfortunately you didn't even state you decided as the maintainer of the live ebuild. The wording actually suggested you aren't. > You are welcome to try to convince us to do something, To do something? The original reporter actually did the work, posted a patch, espected a reasonable answer (either acceptence, conditional denial with instructions or denial with a rationale). After being greeted with ignorance he keeps the improved ebuild in his own overlay. > but that doesn't mean you will always get what you want. I think most Gentoo users and contributors just want to improve Gentoo. I wasn't aware that the Gentoo developers' goals are different. I am repeatedly contacted by other Gentoo users that care and are trying to help. The original reporter of this bug report was thinking about organizing a Gentoo conference in Czech Republic. I, on the other hand, considered becoming a Gentoo developer and work on networking-related projects. But when people's help is not valued in the project, does it mean the preferred way is to start our own overlays and/or distributions instead of giving the results to all Gentoo users via the official portage tree?
(In reply to David Heidelberger (okias) from comment #7) > > You are welcome to try to convince us to do something, but that doesn't mean > > you will always get what you want. > > Well, I wanted systemd ebuild with KDbus support and I have it (in my > overlay). My point is to get it available for other people too. > > I just saying, it may help others... +1 Many Gentoo bugzilla tickets with patches (including this one) are not about getting someone do what we want but actually helping others in the Gentoo community. Blocking potential improvements "because we can" damages the whole Gentoo project in my opinion.
So I took a look at autogen.sh in the source directory, and it seems that systemd upstream already employs this same hack. if which gtkdocize >/dev/null 2>/dev/null; then gtkdocize --docdir docs/ --flavour no-tmpl gtkdocargs=--enable-gtk-doc else echo "You don't have gtk-doc installed, and thus won't be able to generate the documentation." rm -f docs/gtk-doc.make echo 'EXTRA_DIST =' > docs/gtk-doc.make fi Given that, I think we were too quick to jump to a WONTFIX here and I will apply the change as requested.
Thanks!
Ok, should be fixed. + 31 Dec 2013; Mike Gilbert <floppym@gentoo.org> systemd-9999.ebuild: + Stub-out docs/gtk-doc.make if we are not building docs, thanks to David + Heidelberger on bug 496310. If you want to discuss the bug handling stuff further, feel free to reach out via email or IRC.
[QA] (In reply to Pavel Šimerda from comment #5) > When technical > reasoning doesn't help, who I need to be friend of to get my or other > people's *trivial* bug reports *with * handled? Or what else is needed? You can add further comments, get more voice by other users from the forums, get more voice by developers by raising it on the relevant mailing list(s), contact Quality Assurance and Community Relations whom respectively look into quality and communication issues; the latter steps are more severe and exceptional. > Also, could you please point us to some document about what to do when a bug > report gets marked WONTFIX and how to deal with -9999 bugs? Thank you. > > So far I don't know about other ways to appeal a WONTFIX then reopening it a > reasonable number of times. Did I miss something? The steps mentioned above; but just keep the bug closed, because the bug status reflects the response from the developer which is different than "unconfirmed". As for -9999, there is policy available at http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap3_sect4 which has mentions of "work correctly" and "user request"; but parts of that are free for interpretation in this context, we can instead focus on a better experience for both users and developers than to misrepresent this old policy. Feedback and questions are welcome through e-mail or IRC... Happy new year!
(In reply to Tom Wijsman (TomWij) from comment #13) > [QA] > > (In reply to Pavel Šimerda from comment #5) > > When technical > > reasoning doesn't help, who I need to be friend of to get my or other > > people's *trivial* bug reports *with * handled? Or what else is needed? > > You can add further comments, get more voice by other users from the forums, > get more voice by developers by raising it on the relevant mailing list(s), > contact Quality Assurance and Community Relations whom respectively look > into quality and communication issues; the latter steps are more severe and > exceptional. In my opinion, even an ordinary user should be allowed a change to do things right™ and therefore a written policy should be available for everything that is somehow exceptional or varies by project. > > Also, could you please point us to some document about what to do when a bug > > report gets marked WONTFIX and how to deal with -9999 bugs? Thank you. > > > > So far I don't know about other ways to appeal a WONTFIX then reopening it a > > reasonable number of times. Did I miss something? > > The steps mentioned above; but just keep the bug closed, because the bug > status reflects the response from the developer which is different than > "unconfirmed". A link to such a policy would be very welcome. > As for -9999, there is policy available at > > http://www.gentoo.org/proj/en/devrel/handbook/handbook. > xml?part=2&chap=1#doc_chap3_sect4 > > which has mentions of "work correctly" and "user request"; but parts of that > are free for interpretation in this context, we can instead focus on a > better experience for both users and developers than to misrepresent this > old policy. I would indeed be glad to focus on a better experience of all involved parties and especially to avoid building walls between contributors that are formally users but do the work of developers. > Feedback and questions are welcome through e-mail or IRC... Sure.
