libunwind wants it
1) bug wrongly assigned 2) RepoMan scours the neighborhood... dependency.bad 2 sys-libs/libunwind/libunwind-1.1.ebuild: DEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/9.0) ['dev-libs/libatomic_ops'] sys-libs/libunwind/libunwind-1.1.ebuild: DEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/9.1) ['dev-libs/libatomic_ops'] 3) $ head -n 20 profiles/arch/amd64-fbsd/todo/package.use.mask # Copyright 1999-2012 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/profiles/arch/amd64-fbsd/todo/package.use.mask,v 1.298 2013/01/15 13:10:56 aballier Exp $ # Mask useflags that require deps with missing keywords. # Anyone is allowed and _very welcome_ to add masks there. # We will pick them up and keyword as time permits and prefer having a sane # deptree with missing features than a broken one. # Do *NOT* add a ChangeLog entry when modifying this file: it is intended as # temporary and cvs log is more than enough for getting its history. # # Syntax is: # mising dep(s) # mask # Keep it simple, we do not really care about the date or who masked it, we want # to be easily able to determine what we need to keyword. done anyway...
(In reply to comment #1) apologies for wasting my time. i won't bother with notification in the future.
(In reply to comment #2) > (In reply to comment #1) > > apologies for wasting my time. i won't bother with notification in the > future. nice behavior: notifications are good, breaking the tree is not. Don't get me wrong: If you are unable to apply standard policy wrt keywords, filling it in 3) is good enough for us, serves as notification and has the advantage of not breaking the deptree... CC'ing devrel since that's certainly not the first time you deliberately break the fbsd dep tree and it's becoming clear to me I won't be able to make you change your mind.
Nothing for devrel to do here at the moment. If you want to take that road do it properly http://www.gentoo.org/proj/en/devrel/policy.xml
(In reply to comment #3) the tree wasn't "broken" as the flag in question was never enabled. if you're just going to get pissy when a bug is filed for you, i won't bother filing bugs.
(In reply to comment #5) > (In reply to comment #3) > > the tree wasn't "broken" as the flag in question was never enabled. enabled by whom ? it wasn't masked, thus the deptree broken... > if > you're just going to get pissy when a bug is filed for you, i won't bother > filing bugs. I was not pissy at first, only pointing out you have simpler and better ways (in case you didn't know about this package.use.mask file). Ignoring the remark and claiming you'll do worse in the future (comment #2) got me pissy, sorry.
(In reply to comment #6) all i've seen is that if i go out of my way to file a bug for the bsd team to get their arches straight, i get back noise & drama. thus, it's not worth my time if i'm just going to get back gruff for it.
(In reply to comment #7) All I've seen is a single developer that, I have no idea why and even after multiple remarks, prefers to break bsd deptree instead of doing as he does for the rest of the arches.
(In reply to comment #8) then you're clearly not paying attention to anything. other packages get new optional deps which "break" arches and they get bugs requesting keywords. the response, however, is to not moan but to actually fix it. this is SOP for all the arches that actually matter. i don't care about how you want to manage your keyword. that's your problem. but arch maintainers shouldn't be pissing all over ebuild maintainers for no good reason. thus if your response is to do just that, you get to deal with it.
(In reply to comment #9) so why did you commit the change with a broken dep instead of following the SOP by removing amd64-fbsd keywords and filling the same bug ?
