[gentoo-dev] can we get a clang herd/project?

2014-03-03 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm tired of looking all the maintainers up manually and adding each one to CC list of bug reports. Why is there no herd or project? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTFN+VAAoJECIM0cW97tAgXtgQALWR5rFkNEU8ZEH/1Miw+7dx

Re: [gentoo-dev] Make udev optional in net-wireless/bluez?

2014-03-09 Thread hasufell
Samuli Suominen: On 09/03/14 04:55, Alexandre Rostovtsev wrote: On Sat, 2014-03-08 at 21:23 -0500, Joshua Kinard wrote: So I want to try and play around with a particular network domination tool on my home network, Omphalos. However, its current configure script has a hard dependency on

[gentoo-dev] crossdev and multilib interference

2014-03-12 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 We have a problem where the crossdev pkg-config wrapper scripts interfere with multilib. crossdev for example sets in their pkg-config wrappers: PKG_CONFIG_LIBDIR=${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig Now, SYSROOT is chosen

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-22 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alec Warner: https://wiki.gentoo.org/wiki/Package_Tags Object or forever hold your peace. Or argue for 100 posts, either way. -A Sounds good, but how do we get consistency in there? I mean... this only works if we have some sort of

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-22 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ciaran McCreesh: On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner anta...@gentoo.org wrote: https://wiki.gentoo.org/wiki/Package_Tags And do what with them? Right now this is a solution without a problem. Finding packages. Descriptions are

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-23 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ciaran McCreesh: On Sun, 23 Mar 2014 00:04:08 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: On Sat, 22 Mar 2014 15:33:27 -0700 Alec Warner anta...@gentoo.org wrote: https://wiki.gentoo.org/wiki/Package_Tags And do what

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-23 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alec Warner: On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman tom...@gentoo.org wrote: so I'm not entirely interested in tag consistency What are they for then if I cannot efficiently use them to search for software? (which I cannot, if there is no

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-23 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 hasufell: Alec Warner: On Sun, Mar 23, 2014 at 2:45 AM, Tom Wijsman tom...@gentoo.org wrote: so I'm not entirely interested in tag consistency What are they for then if I cannot efficiently use them to search for software? (which I cannot

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-23 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: Dnia 2014-03-22, o godz. 15:33:27 Alec Warner anta...@gentoo.org napisał(a): https://wiki.gentoo.org/wiki/Package_Tags Object or forever hold your peace. I'd honestly prefer that -- if we should really keep tags in the

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-25 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jan Matejka: I've always wondered is we allowed portage to have one additional level of nesting if that'd help any (i.e., games-* - games/*). Squashing games-*/ to just games/ and defining genre by tags. Seems pretty doable, I like this.

Re: [gentoo-dev] RFC GLEP 1005: Package Tags

2014-03-28 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ciaran McCreesh: On Fri, 28 Mar 2014 15:46:49 -0400 Wyatt Epp wyatt@gmail.com wrote: On Fri, Mar 28, 2014 at 1:14 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 27 Mar 2014 03:53:47 +0100 yac y...@gentoo.org wrote: What

Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?

2014-03-29 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Toralf Förster: On 03/29/2014 08:12 PM, Tom Wijsman wrote: On Sat, 29 Mar 2014 07:15:14 -0400 Alex Xu alex_y...@yahoo.ca wrote: On 29/03/14 06:07 AM, Toralf Förster wrote: WRT to but 504616 I'd like to address my questions made in

Re: [gentoo-dev] New virtuals for libudev and libgudev

2014-04-01 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Samuli Suominen: The same GLEP says, In the case of disagreement among QA members the majority of established QA members must agree with the action. Some examples of disagreements are whether the perceived problem violates the policy or

Re: [gentoo-dev] New virtuals for libudev and libgudev

2014-04-01 Thread hasufell
to hasufell, I just wanted to make clear how relevant parts of QA and appealing work as well as why things were done the way they are. Apart from its speed... Tom... I am not sure if you know that, but your posts are difficult to read. You split up posts horribly and I am often unable to follow what you

Re: [gentoo-dev] New virtuals for libudev and libgudev

2014-04-01 Thread hasufell
Tom Wijsman: Could it be that your e-mail reader shows quotes in the same color? No.

Re: [gentoo-dev] Change or revert the 30 days maintainer timeout stabilization policy

2014-04-02 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm just not sure what any of the randomly filed stablereqs are for. It doesn't help anyone, unless the guy who filed it actually uses it or if it is a blocker for another stabilization. It's annoying me for some time now. I expect maintainers to

Re: [gentoo-dev] Change or revert the 30 days maintainer timeout stabilization policy

2014-04-02 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ok, noted that other people like to have those reminders. Rich Freeman: Another option might be to have a tag in metadata.xml that flags packages as never-stable or indicating that stabilization requires coordination, which might help with

Re: [gentoo-dev] Change or revert the 30 days maintainer timeout stabilization policy

2014-04-02 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Alex Xu: On 02/04/14 04:02 PM, Rich Freeman wrote: Another option might be to have a tag in metadata.xml that flags packages as never-stable Arguments have been made that such packages do not belong in g-x86. I did understand it the way

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-devel/llvm: llvm-3.4.ebuild llvm-9999.ebuild ChangeLog

2014-04-02 Thread hasufell
Maybe it is just me, but I take the chance and responsibility. This commit caused /usr/bin/clang being 32bit on my amd64 system. I compiled it 3 times. I have reverted the commit for the live ebuild, reverted it for 3.4-r1 and hardmasked 3.4 to ensure that people who unmasked 3.4 on stable arch

[gentoo-dev] [PATCH] waf-utils.eclass: respect CFLAGS in linking command

2014-04-06 Thread hasufell
respect CFLAGS in linking command https://bugs.gentoo.org/show_bug.cgi?id=506956 --- eclass/waf-utils.eclass +++ eclass/waf-utils.eclass @@ -56,18 +56,18 @@ [[ -z ${NO_WAF_LIBDIR} ]] libdir=--libdir=${EPREFIX}/usr/$(get_libdir) tc-export AR CC CPP CXX RANLIB - echo

Re: [gentoo-dev] [PATCH] fcaps.eclass: Group name portability

2014-04-12 Thread hasufell
na...@gentoo.org: fcaps.eclass is using group name 'root' which is not available on BSD system. Instead you can use 0, or $(id -g -n 0) if you'd prefer group name Index: fcaps.eclass === RCS file:

Re: [gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2014-04-27 23h59 UTC

2014-04-28 Thread hasufell
Tom Wijsman: Eh well, nothing going on here, stuff like this happens every week ... Not sure if that is relieving.

Re: [gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2014-04-27 23h59 UTC

2014-04-28 Thread hasufell
Tom Wijsman: On Mon, 28 Apr 2014 18:35:20 + hasufell hasuf...@gentoo.org wrote: Tom Wijsman: Eh well, nothing going on here, stuff like this happens every week ... Not sure if that is relieving. If only we could cure an occasional cold. Not sure how every week is occasional.

Re: [gentoo-dev] [PATCH 3/3] Deprecate multilib_for_best_abi().

2014-05-05 Thread hasufell
Michał Górny: This was planned for a while. The concept of 'best' and 'native' that are not always the same ABI is confusing and mostly unnecessary. Additionally, we prefer people using multilib-minimal phases rather than multilib_for* functions. --- eclass/multilib-build.eclass | 3 +++ 1

Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-10 Thread hasufell
Rich Freeman: On Fri, May 9, 2014 at 4:08 PM, Tom Wijsman tom...@gentoo.org wrote: On Fri, 09 May 2014 20:57:29 +0100 Markos Chandras hwoar...@gentoo.org wrote: I was wondering, is there a good reason we keep our own pkgconfig files instead of communicating that to upstream and resolve that

Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-10 Thread hasufell
Markos Chandras: On 05/09/2014 09:32 PM, Tom Wijsman wrote: On Fri, 9 May 2014 16:15:58 -0400 Rich Freeman ri...@gentoo.org wrote: I think fixing upstream is a no-brainer. It indeed is, this is the goal; you can force them in multiple ways, some of which can be found on the Lua bug and

Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-10 Thread hasufell
Markos Chandras: Gentoo, almost all pkgconfig files come from upstream with minimal modification. So a .pc file that is specific to Gentoo is a rare exception, and it could cause confusion for users who installed Gentoo on their development machine and who wish to develop new portable

Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-10 Thread hasufell
Rich Freeman: On Sat, May 10, 2014 at 9:00 AM, hasufell hasuf...@gentoo.org wrote: Our philosophy states that our tools should be a joy to use. If we add random hackery on stuff that affects portability across distros, then this doesn't hold true anymore. Which one of our tools is at risk

Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-11 Thread hasufell
Sure, this is a more complex problem. My point is, for pkg-config files it is relatively easy to fix stuff that depends on non-standard files (I can write a devmanual section about that, but err... this is really trivial). The amount of these downstream pkg-config files is not as big as you might

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/libsdl2/files: libsdl2-2.0.3-static-libs.patch

2014-05-12 Thread hasufell
Samuli Suominen: You know that adding $(LDFLAGS) so late in the linker line makes whole -Wl,--as-needed get ignored? Yes I know and the patch is correct as is.

Re: [gentoo-dev] Re: Banning modification of pkg-config files

2014-05-12 Thread hasufell
Samuli Suominen: On 12/05/14 20:47, Peter Stuge wrote: Rich Freeman wrote: Longterm, this makes it year after year more difficult to develop software for Linux. I'm with you here, but what is the solution? If we say we stick to upstream then we don't provide pkg-config files at all (in

Re: [gentoo-dev] Re: Re: Banning modification of pkg-config files

2014-05-15 Thread hasufell
It's called keeping status quo.

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default

2014-05-15 Thread hasufell
Ciaran McCreesh: Sandboxing isn't about security. Sure it is.

Re: [gentoo-dev] Removal of the as-is (so-called) license

2014-05-19 Thread hasufell
Ulrich Mueller: Please fix your overlays if you haven't done so yet. Thanks for the heads up.

Re: [gentoo-dev] Continuous repoman using travis-ci

2014-05-24 Thread hasufell
Manuel Rüger: Hello, I created a travis script (it's rather a hack and could need some improvements) [1] to run repoman for overlays hosted on github. This might be interesting for your personal and also project overlays. It will run repoman on pull requests, too. If you want to see

Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

2014-05-30 Thread hasufell
Tom Wijsman: Please no p.mask for a single line being wrong... That's nonsense. The amount of wrong lines doesn't matter. A single wrong line in the kernel can break your whole system as well. Please p.mask (or patch) immediately. There is no point in waiting.

Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

2014-05-30 Thread hasufell
Sven Vermeulen: On Fri, May 30, 2014 at 04:34:09PM +, hasufell wrote: Tom Wijsman: Please no p.mask for a single line being wrong... That's nonsense. The amount of wrong lines doesn't matter. A single wrong line in the kernel can break your whole system as well. Please p.mask

Re: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers

2014-05-30 Thread hasufell
Peter Stuge: Ian Stakenvicius wrote: If a user has i.e. SSL=polarssl in make.conf and emerges things that don't have polarssl on their list, then those things won't have SSL support at all, right? Wrong; I would expect emerge to throw an error at me and exit, rather than to fail (build the

Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

2014-06-03 Thread hasufell
Tom Wijsman: On Tue, 3 Jun 2014 20:58:46 +0200 Jeroen Roovers j...@gentoo.org wrote: On Fri, 30 May 2014 19:17:31 +0200 Tom Wijsman tom...@gentoo.org wrote: On Fri, 30 May 2014 18:14:11 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: A more reasonable approach would be for

Re: [gentoo-dev] The state and future of the OpenRC project

2014-06-08 Thread hasufell
Jeroen Roovers: On Sun, 08 Jun 2014 03:05:28 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 07/06/14 23:08, Jeroen Roovers wrote: You can start fixing bugs immediately. You can check out the sources, write patches and attach the patches to the bug reports. Then all it takes is

Re: [gentoo-dev] The state and future of the OpenRC project

2014-06-08 Thread hasufell
Jeroen Roovers: On Sun, 08 Jun 2014 14:41:04 + hasufell hasuf...@gentoo.org wrote: The amount of contributors (with real patches and real ebuilds) is constantly decreasing, As evidenced where exactly? I am not sure if that is a joke. You can pretty much ask most major gentoo

Re: [gentoo-dev] The state and future of the OpenRC project

2014-06-09 Thread hasufell
Thomas Kahle: then they stay in the overlay because people feel it is not worth the effort to fix the QA issues which in turn would be necessary before moving them to the main tree. Probably because no one mentored them on how to fix these QA issues. Otherwise... if that's attitude, then

Re: [gentoo-dev] The state and future of the OpenRC project

2014-06-10 Thread hasufell
Andrew Savchenko: On Tue, 10 Jun 2014 17:49:15 +0200 Alexander Berntsen wrote: On 10/06/14 17:45, Andrew Savchenko wrote: I don't know why CVS is still used for Gentoo main repository, probably some infrastructure elements depends deeply on its internals, because I see of no other reason

Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes?

2014-06-14 Thread hasufell
Ciaran McCreesh: On Sat, 14 Jun 2014 16:41:51 +0200 Michał Górny mgo...@gentoo.org wrote: However, this means that we force much more rebuilds than necessary. This shouldn't be considered to be a problem. Why not?

Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes?

2014-06-14 Thread hasufell
Ciaran McCreesh: On Sat, 14 Jun 2014 15:32:56 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: On Sat, 14 Jun 2014 16:41:51 +0200 Michał Górny mgo...@gentoo.org wrote: However, this means that we force much more rebuilds than necessary. This shouldn't be considered

Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes?

2014-06-14 Thread hasufell
Ian Stakenvicius: I vote that as primary policy/general practice, it only be bumped for (2) -- the primary purpose of subslot rebuilds is to allow portage to figure out the deptree order when a dependency upgrade is going to break a package that may or may not be emerged later. break is

Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes?

2014-06-14 Thread hasufell
Ciaran McCreesh: On Sat, 14 Jun 2014 16:16:20 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: On Sat, 14 Jun 2014 15:32:56 + hasufell hasuf...@gentoo.org wrote: Ciaran McCreesh: On Sat, 14 Jun 2014 16:41:51 +0200 Michał Górny mgo...@gentoo.org wrote: However, this means

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-strategy/openxcom: openxcom-1.0.0.ebuild metadata.xml Manifest ChangeLog

2014-06-14 Thread hasufell
Maxim Koltsov (maksbotan): # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/games-strategy/openxcom/openxcom-1.0.0.ebuild,v 1.1 2014/06/14 16:15:27 maksbotan Exp $ EAPI=5 inherit cmake-utils

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-strategy/openxcom: openxcom-1.0.0.ebuild metadata.xml Manifest ChangeLog

2014-06-14 Thread hasufell
Vadim A. Misbakh-Soloviov: В письме от Сб, 14 июня 2014 20:06:54 пользователь hasufell написал: Maxim Koltsov (maksbotan): ... What about adding such checks in repoman? which one?

Re: [gentoo-dev] [RFC] [epatch_user] Proposal: add possibility to tolerable-fail for some patches (plus add groupping support)

2014-06-15 Thread hasufell
Vadim A. Misbakh-Soloviov: My idea is to allow failing for some patches without breaking build at all. And, in parallel, to add groupping. How I imagine that: etc/portage/patches/app-cat/name/ | | - group_name/ | | | |- 01_foo.patch | |- 02_bar.patch

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-15 Thread hasufell
Steven J. Long: I'll see you when you get there, if you ever get there.. No improvements so far. I am going to hardmask sys-devel/crossdev, unless someone can explain why we are still in broken stage. More packages are popping up that randomly break. Recent failures were related to

Re: [gentoo-dev] Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Ryan Hill: On Sun, 15 Jun 2014 20:35:53 + hasufell hasuf...@gentoo.org wrote: Steven J. Long: I'll see you when you get there, if you ever get there.. No improvements so far. I am going to hardmask sys-devel/crossdev, unless someone can explain why we are still in broken stage

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Chí-Thanh Christopher Nguyễn: hasufell schrieb: No improvements so far. I am going to hardmask sys-devel/crossdev, unless someone can explain why we are still in broken stage. More packages are popping up that randomly break. Recent failures were related to tc-getBUILD_CC. This isn't

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Steev Klimaszewski: I'm someone who uses crossdev (and the cross compilers) quite heavily - can you point me to a bug that you're talking about? I'm not in the toolchain, and while I agree that temporarily adding the cross compiler(s) to the PATH is easy, for some of us, it's easier to allow

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Jeroen Roovers: On Mon, 16 Jun 2014 19:31:58 + hasufell hasuf...@gentoo.org wrote: Also check the history of this thread for a few proposed solutions. The history of this thread and the history of gx86-multilib and crossdev development suggest that crossdev was doing nothing wrong

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Joshua Kinard: On 06/16/2014 15:47, hasufell wrote: Jeroen Roovers: On Mon, 16 Jun 2014 19:31:58 + hasufell hasuf...@gentoo.org wrote: Also check the history of this thread for a few proposed solutions. The history of this thread and the history of gx86-multilib and crossdev

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Steev Klimaszewski: while I agree that temporarily adding the cross compiler(s) to the PATH is easy, for some of us, it's easier to allow Gentoo to do so. I'm not sure if that is reason enough to cause the current breakage crossdev and multilib are in.

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Joshua Kinard: Then, can crossdev be augmented to work around the invalid behavior? Yes, by installing it into prefixes and requiring people to add it to PATH on their own if they need it outside of cross-emerge.

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-16 Thread hasufell
Joshua Kinard: How big of a patch would this change require to the existing crossdev ebuild? Probably quite trivial, but since vapier said bs to that proposal (translates to bullshit I guess) I'll not put any work into that. So there we go. If you are cool, you can just say bs, vanish and

Re: [gentoo-dev] Re: crossdev and multilib interference

2014-06-17 Thread hasufell
Ryan Hill: If doing something dumb like installing a i686 crossdev toolchain on x86_64 breaks things, it's because you've done something dumb. Stop doing that and things should work better. There have been several reasons mentioned to do what you call dumb. I'm not going to repeat them.

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-17 Thread hasufell
Joshua Kinard: On 06/16/2014 21:47, hasufell wrote: Joshua Kinard: How big of a patch would this change require to the existing crossdev ebuild? Probably quite trivial, but since vapier said bs to that proposal (translates to bullshit I guess) I'll not put any work into that. So

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-17 Thread hasufell
Joshua Kinard: Equally using the Council as a hammer all the time doesn't work in the long-term, either. This is exactly the case where the council has to step in to solve global issues and those between projects (here it is embedded gentoo project and multilib project).

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-17 Thread hasufell
Rich Freeman: On Tue, Jun 17, 2014 at 8:30 AM, hasufell hasuf...@gentoo.org wrote: No, that's not how opensource works. You don't work on things after upstream said not interested. That is hardly true though - which is why we have 47 different implementations of everything to debate

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-17 Thread hasufell
Joshua Kinard: upstream didn't say anywhere in that bug that they weren't interested. They countered your reasoning with a technical argument. QA even states that you need to file separate bugs for the various build failures. You could set up a master TRACKER bug for these crossdev-related

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-17 Thread hasufell
Joshua Kinard: I have proposed numerous ways to communicate this problem to the user without touching any of the precious toolchain/embedded packages. If no one responds there, I'll just pick one and apply it. And what I am trying to tell you is that making hardmask threats don't solve the

Re: [gentoo-dev] Re: Re: Re: crossdev and multilib interference

2014-06-17 Thread hasufell
Joshua Kinard: Provide a technical counter-argument to that or propose a solution that people can agree on and you're going to find people are a LOT more willing to stand with you on fixing the perceived problem. I start to think here is some confusion going on. We already proposed solutions

Re: [gentoo-dev] [PATCH] qt4-r2.eclass: simplify doc handling

2014-06-18 Thread hasufell
Sergey Popov: As we should not do anything crazy with DOCS and HTML_DOCS, let's simplify our eclass Just deprecate the whole eclass. I don't see much useful stuff there except running base.eclass phases and that is already discouraged wrt #497050. If you remove those parts, not much is left

Re: [gentoo-dev] Re: Changes in installed ebuilds

2014-06-24 Thread hasufell
Kristian Fiskerstrand: On 06/24/2014 09:25 PM, Jörg Schaible wrote: Alexandre Rostovtsev wrote: On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: So, why the heck, was the dependency to dev-libs/glib changed for an existing ebuild without increasing its version (e.g.

Re: [gentoo-dev] Re: Changes in installed ebuilds

2014-06-24 Thread hasufell
Jörg Schaible: Alexandre Rostovtsev wrote: On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: So, why the heck, was the dependency to dev-libs/glib changed for an existing ebuild without increasing its version (e.g. dbus-glib-0.100.2-r2)? Please see

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

2014-06-29 Thread hasufell
Greg KH: On Sun, Jun 29, 2014 at 05:17:36AM +0200, Jeroen Roovers wrote: On Sat, 28 Jun 2014 19:58:22 -0700 Greg Kroah-Hartman gre...@gentoo.org wrote: Hi Markos, I was wondering why docker 1.0.0 wasn't seeming to get updated on my boxes recently, despite me commiting the update to the cvs

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

2014-06-29 Thread hasufell
Rich Freeman: If the only one testing it is the maintainer then it probably shouldn't go in the tree. However, if the maintainer is working with others to actually test the package, then a short-term mask is probably fine. IMO, if you are testing with others without knowing the outcome

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

2014-06-29 Thread hasufell
Rich Freeman: On Sun, Jun 29, 2014 at 8:12 AM, hasufell hasuf...@gentoo.org wrote: Also, those masks are rarely short-term in practice, because well, see this thread. Is there any evidence to support this statement? You only notice masks when they're a problem, and these kinds of masks

Re: [gentoo-dev] package.mask vs ~arch

2014-06-30 Thread hasufell
Rich Freeman: On Sun, Jun 29, 2014 at 8:36 AM, hasufell hasuf...@gentoo.org wrote: This is still too vague for me. If it's expected to be short-term, then it can as well just land in ~arch. A package that hasn't been tested AT ALL doesn't belong in ~arch. Huh? That's exactly the place

Re: [gentoo-dev] package.mask vs ~arch

2014-07-06 Thread hasufell
Greg KH: On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers wrote: On Mon, 30 Jun 2014 09:25:27 -0400 Rich Freeman ri...@gentoo.org wrote: Agree 100%. I'm taking about masking things that HAVEN'T BEEN TESTED AT ALL. The maintainer knows that they compile, and that is it. Developers

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-08 Thread hasufell
Samuli Suominen: It seems to me like people aren't making the effort of joining to the team and meeting the high quality ebuild syntax they've kept up... There is no games _team_. There is Mr_Bones_ (and I have learned a lot from him and am able to collaborate with him). And that is that.

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-08 Thread hasufell
Pacho Ramos: What kind of games packages does he want to maintain in a strictly way? Maybe one way to cooperate would be to have two herds: - games-base (or similar) - the more stricter and the one Mr_Bones would likely still prefer to handle himself. It would take care of central libs

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-10 Thread hasufell
Samuli Suominen: On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote: В письме от Вт, 8 июля 2014 18:22:50 пользователь Samuli Suominen написал: It seems to me like people aren't making the effort of joining to the team and meeting the high quality ebuild syntax they've kept up... Samuli!

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-11 Thread hasufell
Samuli Suominen: On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote: В письме от Вт, 8 июля 2014 18:22:50 пользователь Samuli Suominen написал: It seems to me like people aren't making the effort of joining to the team and meeting the high quality ebuild syntax they've kept up... Samuli!

[gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

2014-07-12 Thread hasufell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://bugs.gentoo.org/show_bug.cgi?id=508750 http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/ SHA256 139ac81c9478accd38a9eb667623d75997a2197cec36f184cd8d23e98a7e475b (yet none of it is signed) So libressl is meant as a drop-in replacement for

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

2014-07-12 Thread hasufell
Anthony G. Basile: I just did a quick count of all packages which refer to dev-libs/openssl. I'm getting 590 packages. This will be quite a task. For ~arch we could probably do that with a script. For stable arch we should ask maintainers to do it.

Re: [gentoo-dev] The request to abolish games team policy

2014-07-12 Thread hasufell
Denis Dupeyron: I honestly wonder what all the fuss is about. It's about a dying project. I am collaborating with it since ~2 years and it isn't getting any better (afais I'm pretty much the only regular collaborator who is not on the team... many others stopped caring). So, this is about:

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

2014-07-13 Thread hasufell
Dirkjan Ochtman: On Sat, Jul 12, 2014 at 2:37 PM, hasufell hasuf...@gentoo.org wrote: So libressl is meant as a drop-in replacement for openssl. Some caveats have already been discovered: http://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/ Cheers, Dirkjan

Re: [gentoo-dev] Re: The request to abolish games team policy

2014-07-14 Thread hasufell
Vadim A. Misbakh-Soloviov: В письме от Пт, 11 июля 2014 16:24:38 пользователь hasufell написал: However, basically having only a single person that actively does such reviews + no official overlay makes it hard for contributors. As I said previously, you (and any developer else) are free

Re: [gentoo-dev] The request to abolish games team policy

2014-07-14 Thread hasufell
Rich Freeman: On Sat, Jul 12, 2014 at 6:26 PM, Denis Dupeyron calc...@gentoo.org wrote: Rich, if I may have a suggestion, it would be that instead of meddling with projects that have been doing their best with what they have for years, and which need praise rather than hindrance, you instead

Re: [gentoo-dev] [RFC] LibreSSL, introduce virtual/openssl

2014-07-15 Thread hasufell
Matthew Summers: On Sun, Jul 13, 2014 at 12:59 PM, hasufell hasuf...@gentoo.org wrote: Dirkjan Ochtman: On Sat, Jul 12, 2014 at 2:37 PM, hasufell hasuf...@gentoo.org wrote: So libressl is meant as a drop-in replacement for openssl. Some caveats have already been discovered: So, libressl

Re: [gentoo-dev] The request to abolish games team policy

2014-07-16 Thread hasufell
Denis Dupeyron: On Mon, Jul 14, 2014 at 12:11 PM, hasufell hasuf...@gentoo.org wrote: a) I'm not sure if I want to be in a team where vapier is lead. The only position you don't want vapier in is behind you. He humps. I have no idea what to respond to that, except that you seem to ignore

[gentoo-dev] don't rely on dynamic deps

2014-07-21 Thread hasufell
afaiu dynamic deps are broken and not defined in PMS still... people seem to fix deps without revbumping, causing users who either don't use dynamic deps (it's optional for portage through --dynamic-deps=y, although it's on by default) or who use a different PM to not get the fix, at worst

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-21 Thread hasufell
Samuli Suominen: So, -1, useless rebuilds is one of the biggest problems lately I am not sure if that is a joke. We have: * a broken PM which does incomplete dep calculation, gives wrong suggestions to the user, has totally useless error/debug output, randomly fails to remove files, allows to

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-21 Thread hasufell
William Hubbs: I'm picking a random msg to reply to. My concern about doing a revbump just because the deps change is that the new revision has to be committed in ~arch, so we then have to hit the arch teams, which we know are overworked anyway, with stable requests just because we changed

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-22 Thread hasufell
Alexander Berntsen: Julian, would you like to share your experiences with Paludis? My guess is that Paludis is more predictable in this respect. I.e., instead of breaking stuff, I expect Paludis to simply give up. Relying on dynamic deps as they are currently implemented simply causes

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-24 Thread hasufell
Samuli Suominen: On 22/07/14 10:25, Paweł Hajdan, Jr. wrote: On 7/21/14, 11:52 PM, Alexander Berntsen wrote: 2. Remove dynamic-deps. This is what I think currently makes sense. +1 I also think it's the best option. Not before someone has implemented an alternative way to avoid useless

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-25 Thread hasufell
Ian Stakenvicius: Dynamic deps are the best solution outside of the (rather limited) profiles/updates functions we have right now to allow us to make whatever non-files-on-${ROOT} changes we need to make to the vdb. So realistically what we should be doing is either trying to work out a

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-25 Thread hasufell
Ciaran McCreesh: On Fri, 25 Jul 2014 15:09:55 + hasufell hasuf...@gentoo.org wrote: Everyone else who thinks got an idea on how to fix dynamic deps support (or similar) should: * write a PMS patch and get it merged * join the portage team and volunteer to implement it instead of yelling

Re: [gentoo-dev] don't rely on dynamic deps

2014-07-25 Thread hasufell
Ciaran McCreesh: On Fri, 25 Jul 2014 15:23:58 + hasufell hasuf...@gentoo.org wrote: That's not really helpful advice: dynamic dependencies can't be fixed. Instead, you should say that anyone who thinks they have an idea on how to fix dynamic deps should think about it until

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-07-26 Thread hasufell
Ciaran McCreesh: On Sat, 26 Jul 2014 14:33:38 + (UTC) Martin Vaeth mar...@mvath.de wrote: Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: No. PMS does not specify which dependency information has to be taken. Yes it does. Please read PMS, and do not guess as to what it says.

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-07-26 Thread hasufell
Martin Vaeth: Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: But, OK, so I will use your strawman to prove how static deps are broken: This is not broken. This is exactly what is supposed to happen It's not a bug it's a feature Of course, one can always close the eyes when faced

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-07-26 Thread hasufell
Martin Vaeth: Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Martin Vaeth mar...@mvath.de wrote: hasufell hasuf...@gentoo.org wrote: Dynamics deps are already broken, not consistently enabled (e.g. when subslots are in use) Just to make it clear: No, dynamic deps are not broken. Yes

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-07-26 Thread hasufell
Martin Vaeth: Indeed, it just would just need a little programming. would you like to implement it?

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-07-27 Thread hasufell
Samuli Suominen: On 26/07/14 15:49, Ciaran McCreesh wrote: On Sat, 26 Jul 2014 12:41:16 + (UTC) Martin Vaeth mar...@mvath.de wrote: hasufell hasuf...@gentoo.org wrote: Dynamics deps are already broken, not consistently enabled (e.g. when subslots are in use) Just to make it clear

Re: [gentoo-dev] Re: don't rely on dynamic deps

2014-07-27 Thread hasufell
Paweł Hajdan, Jr.: On 7/27/14, 1:42 PM, Samuli Suominen wrote: Only one person said he had to manually build 2 GNOME related packages, simple-scan and something else So, broken? Far from it. More like essential feature. People have just listed some known races dynamic deps have, and I take

<    1   2   3   4   5   6   7   8   >