On 05/11/14 12:16, Michael Orlitzky wrote:
When I was taking my ebuild quizzes, I asked for someone to clarify the
implicit system dependency that we have enshrined in the devmanual:
https://bugs.gentoo.org/show_bug.cgi?id=485356
There is... some agreement, but also special cases and
El dom, 12-10-2014 a las 10:38 +0200, Pacho Ramos escribió:
El dom, 12-10-2014 a las 00:13 +0400, Alexander Tsoy escribió:
[...]
I think we should simply have a keyring USE flag to enable what most
people will want - keyring support.
Some apps have optional support for both
В Thu, 13 Nov 2014 11:53:56 +0100
Pacho Ramos pa...@gentoo.org пишет:
El dom, 12-10-2014 a las 10:38 +0200, Pacho Ramos escribió:
El dom, 12-10-2014 a las 00:13 +0400, Alexander Tsoy escribió:
[...]
I think we should simply have a keyring USE flag to enable what most
people will
El jue, 13-11-2014 a las 14:12 +0300, Alexander Tsoy escribió:
В Thu, 13 Nov 2014 11:53:56 +0100
Pacho Ramos pa...@gentoo.org пишет:
El dom, 12-10-2014 a las 10:38 +0200, Pacho Ramos escribió:
El dom, 12-10-2014 a las 00:13 +0400, Alexander Tsoy escribió:
[...]
I think we
On 11/13/2014 05:30 AM, Michael Palimaka wrote:
Suggested policy to get the ball rolling:
In general, a package must explicitly depend upon what it directly uses.
However, to avoid ebuild complexity and developer burden there are some
exceptions. Packages that appear in the base system set
On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka kensing...@gentoo.org wrote:
In general, a package must explicitly depend upon what it directly uses.
However, to avoid ebuild complexity and developer burden there are some
exceptions. Packages that appear in the base system set may be omitted
On Thu, 13 Nov 2014, Michael Palimaka wrote:
Suggested policy to get the ball rolling:
In general, a package must explicitly depend upon what it directly
uses. However, to avoid ebuild complexity and developer burden there
are some exceptions. Packages that appear in the base system set may
On 14/11/14 01:17, Rich Freeman wrote:
On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka kensing...@gentoo.org
wrote:
In general, a package must explicitly depend upon what it directly uses.
However, to avoid ebuild complexity and developer burden there are some
exceptions. Packages that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/11/14 09:05 AM, Michael Orlitzky wrote:
On 11/13/2014 05:30 AM, Michael Palimaka wrote:
Suggested policy to get the ball rolling:
In general, a package must explicitly depend upon what it
directly uses. However, to avoid ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/11/14 10:17 AM, Ian Stakenvicius wrote:
On 13/11/14 09:05 AM, Michael Orlitzky wrote:
On 11/13/2014 05:30 AM, Michael Palimaka wrote:
Suggested policy to get the ball rolling:
In general, a package must explicitly depend upon what it
On 14/11/14 01:36, Ulrich Mueller wrote:
On Thu, 13 Nov 2014, Michael Palimaka wrote:
Suggested policy to get the ball rolling:
In general, a package must explicitly depend upon what it directly
uses. However, to avoid ebuild complexity and developer burden there
are some exceptions.
On 14/11/14 01:05, Michael Orlitzky wrote:
On 11/13/2014 05:30 AM, Michael Palimaka wrote:
Suggested policy to get the ball rolling:
In general, a package must explicitly depend upon what it directly uses.
However, to avoid ebuild complexity and developer burden there are some
exceptions.
On 11/13/2014 04:27 PM, Michael Palimaka wrote:
* C++ compiler and runtime
Isn't it possible to disable C++ in GCC with USE=-cxx?
It is, but I think if that's disabled you're on your own. :-)
I keep hearing this sentence, but it still doesn't make much sense to
me. Invalid configurations
On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka
kensing...@gentoo.org wrote:
On 14/11/14 01:05, Michael Orlitzky wrote:
Isn't it possible to disable C++ in GCC with USE=-cxx?
It is, but I think if that's disabled you're on your own. :-)
Perhaps we should add a package.use.force entry for
Mike Gilbert wrote:
On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka
kensing...@gentoo.org wrote:
On 14/11/14 01:05, Michael Orlitzky wrote:
Isn't it possible to disable C++ in GCC with USE=-cxx?
It is, but I think if that's disabled you're on your own. :-)
Perhaps we should add a
Dnia 2014-11-13, o godz. 13:13:01
Mike Gilbert flop...@gentoo.org napisał(a):
On Thu, Nov 13, 2014 at 10:27 AM, Michael Palimaka
kensing...@gentoo.org wrote:
On 14/11/14 01:05, Michael Orlitzky wrote:
Isn't it possible to disable C++ in GCC with USE=-cxx?
It is, but I think if that's
On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka
kensing...@gentoo.org wrote:
Ditching implicit dependencies is an interesting idea but not practical.
Nobody wants to the laundry list, and there's little benefit in
maintaining a virtual/system clone of @system.
Well, the idea would be to
On 14/11/14 03:57, hasufell wrote:
On 11/13/2014 04:27 PM, Michael Palimaka wrote:
* C++ compiler and runtime
Isn't it possible to disable C++ in GCC with USE=-cxx?
It is, but I think if that's disabled you're on your own. :-)
I keep hearing this sentence, but it still doesn't make much
On 14/11/14 11:06, Rich Freeman wrote:
On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka
kensing...@gentoo.org wrote:
Ditching implicit dependencies is an interesting idea but not practical.
Nobody wants to the laundry list, and there's little benefit in
maintaining a virtual/system clone
On Mon, 10 Nov 2014 12:23:43 +0100
Pacho Ramos pa...@gentoo.org wrote:
Hello
Hello, this is an individual response.
I would like to see if we could finally try to stabilize java7 on
Gentoo as some external tools start to require it.
There is currently this tracker opened:
On Tue, 11 Nov 2014 16:59:46 +0200
Pavlos Ratis daster...@gentoo.org wrote:
I will also drop myself from the net-proxy herd.
Drawing extra attention to this sentence; it looks like the herd is
(once again) going to be empty, as the result of a lack of interest.
If someone does have a real
Hello all
Due to lack of time I'm giving up some packages. Feel free to take them:
app-admin/ec2-ami-tools
app-admin/ec2-api-tools
These command-line tools serve as the client interface
to the Amazon EC2 web service
app-admin/logmon
On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org wrote:
On 14/11/14 11:06, Rich Freeman wrote:
Well, the idea would be to maintain the virtual INSTEAD of @system, or
have @system just pull in the virtual and make some arch-specific
additions.
Will that work? Some
On 11/13/2014 08:01 PM, Rich Freeman wrote:
On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka kensing...@gentoo.org
wrote:
On 14/11/14 11:06, Rich Freeman wrote:
Well, the idea would be to maintain the virtual INSTEAD of @system, or
have @system just pull in the virtual and make some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 13/11/14 02:22, Zac Medico wrote:
+if case-insensitive-fs in portage.settings.features:
+FIND_EXTANT_CONFIGS = \
+FIND_EXTANT_CONFIGS.replace(-name '._cfg, -iname '._cfg)
+
Splitting inside the replace will look nicer following
On 11/13/2014 02:29 AM, Alexander Berntsen wrote:
On 13/11/14 02:22, Zac Medico wrote:
+if case-insensitive-fs in portage.settings.features:
+FIND_EXTANT_CONFIGS = \
+FIND_EXTANT_CONFIGS.replace(-name '._cfg, -iname '._cfg)
+
Splitting inside the replace will look nicer following
There was a race inside fs_template._ensure_dirs which could cause it to
raise EEXIST if a concurrent process created the directory after
os.path.exists returned False. Fix it by using the util.ensure_dirs
function, which already handles EEXIST.
X-Gentoo-Bug: 529120
X-Gentoo-Bug-URL:
The portageq eroot parameter has been broken since commit
c9f6aa9f0151adb3c86706eaef1914cdbdcf2b6d, due to premature instantiation
of portage.settings (before the ROOT variable was set). Premature access
to the portage.settings attribute must be avoided by using other
available means to determine
28 matches
Mail list logo
