-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
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
-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
-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
-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
-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
-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
-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
-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
-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.
-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
-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
-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
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
Tom Wijsman:
Could it be that your e-mail reader shows quotes in the same color?
No.
-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
-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
-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
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
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
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:
Tom Wijsman:
Eh well, nothing going on here, stuff like this happens every week ...
Not sure if that is relieving.
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.
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
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
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
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
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
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
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.
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
It's called keeping status quo.
Ciaran McCreesh:
Sandboxing isn't about security.
Sure it is.
Ulrich Mueller:
Please fix your overlays if you haven't done so yet.
Thanks for the heads up.
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
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.
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
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
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
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
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
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
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
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?
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
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
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
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
Vadim A. Misbakh-Soloviov:
В письме от Сб, 14 июня 2014 20:06:54 пользователь hasufell написал:
Maxim Koltsov (maksbotan):
...
What about adding such checks in repoman?
which one?
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
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
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
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
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
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
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
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.
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.
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
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.
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
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).
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
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
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
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
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
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.
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
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
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
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
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
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
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.
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
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!
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!
-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
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.
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
Martin Vaeth:
Indeed, it just would just need a little programming.
would you like to implement it?
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
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
301 - 400 of 792 matches
Mail list logo