2017-01-30 13:35 GMT-05:00 David Seifert :
> Please do not resurrect leechcraft unless you're willing to fix the
> bugs with GCC 5 (and GCC 6) and newer dependencies. Personally, I feel
> leechcraft should probably live in an overlay instead of the tree.
I was previously proxy-maintaining it via M
---
eclass/llvm.eclass | 106 +
1 file changed, 106 insertions(+)
create mode 100644 eclass/llvm.eclass
diff --git a/eclass/llvm.eclass b/eclass/llvm.eclass
new file mode 100644
index ..8c001fdbdb97
--- /dev/null
+++ b/eclass/llvm.e
Hi !
Last call, tomorrow I contact the restaurant.
Please update the Wiki page [1].
See you saturday ;)
Xavier.
Le 24/01/17 à 20:34, Xavier Miller a écrit :
> /erratum/
>
> Le 24/01/17 à 20:30, Xavier Miller a écrit :
>> Hi!
>>
>> The traditional Gentoo Dinner @ FOSDEM 2017 comes back!
>> If
On 2017-01-30 14:04, William Hubbs wrote:
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
>
> …
>
> What do folks think here?
>
I looked at Meson a bit, and I liked almost everything, except the
configuration file-based mechanism for cross-compi
On Mon, 30 Jan 2017 14:04:06 -0600
William Hubbs wrote:
> I have been looking at the meson build system [1] [2], and I like what I
> see.
I've still only read the documentation but I agree with your
assessment. It's nice to hear something positive about a build system
for once.
> As I said on t
All,
I have been looking at the meson build system [1] [2], and I like what I
see.
I have opened an issue on OpenRC's github wrt migrating OpenRC to the
meson build system [3].
As I said on the bug, the downside is the addition of py3 and ninja as
build time dependencies, but I think the upside
On 01/30/2017 07:22 PM, Michael Orlitzky wrote:
> On 01/30/2017 01:05 PM, Patrick McLean wrote:
>>
>> No, that is also enabled by default on vanilla kernels, I just verified
>> on my machine running a vanilla kernel. It doesn't matter anyway, since
>> the permissions and ownership information is st
Please do not resurrect leechcraft unless you're willing to fix the
bugs with GCC 5 (and GCC 6) and newer dependencies. Personally, I feel
leechcraft should probably live in an overlay instead of the tree.
# David Seifert (30 Jan 2017)
# No maintainer activity since git migration, dated eclass
#
On 01/30/2017 01:05 PM, Patrick McLean wrote:
>
> No, that is also enabled by default on vanilla kernels, I just verified
> on my machine running a vanilla kernel. It doesn't matter anyway, since
> the permissions and ownership information is stored in the inode, not
> the dentry so all hardlinks
On Mon, 30 Jan 2017 11:29:02 -0500
Michael Orlitzky wrote:
> On 01/30/2017 09:25 AM, Alan McKinnon wrote:
> >>
> >> Any user can create a hard link in its home directory
> >> to /etc/shadow, so long as (a) they live on the same filesystem,
> >> and (b) there are no special kernel protections in p
On 01/30/2017 09:25 AM, Alan McKinnon wrote:
>>
>> Any user can create a hard link in its home directory to /etc/shadow, so
>> long as (a) they live on the same filesystem, and (b) there are no
>> special kernel protections in place to prevent it. If you call chown on
>> that hard link, it will cha
On 30/01/2017 01:04, Michael Orlitzky wrote:
> On 01/29/2017 05:30 PM, Alan McKinnon wrote:
>>
>> Good catch with symlinks.
>> I don't see the point about hardlinks, they are just files with 2
>> dentries. When find gets to the second one it's already changed, so no
>> problem.
>>
>
> Any user can
On 01/27/2017 12:51 PM, NP-Hardass wrote:
> On 01/27/2017 12:25 PM, Michael Orlitzky wrote:
>> Forked from the gdbm/berkdb thread, wall of text ensues...
>>
>>
>> On 01/27/2017 03:32 AM, Fabian Groffen wrote:
>>>
>>> You mention REQUIRED_USE should be used sparingly, I think I see your
>>> reasonin
13 matches
Mail list logo
