In the original multibuild.eclass code I tried to somehow achieve very
fast merging via avoiding actually copying anything. I used the 'cp -al'
call that used hardlinks to avoid copying data but that actually made
copying non-clobbering and less portable (BSD used a tar fallback, for
example, due t
On Fri, Apr 04, 2014 at 12:30:31AM +0200, Michał Górny wrote:
> + if cp --reflink=auto --version &>/dev/null; then
> + # enable reflinking if possible to make this faster
> + cp_args+=( --reflink=auto )
> fi
>
> + cp -P -R -p "${cp_args[@]}" "${src}"/. "${des
In the original multibuild.eclass code I tried to somehow achieve very
fast merging via avoiding actually copying anything. I used the 'cp -al'
call that used hardlinks to avoid copying data but that actually made
copying non-clobbering and less portable (BSD used a tar fallback, for
example, due t
Kfir Lavi posted on Wed, 02 Apr 2014 13:38:47 +0300 as excerpted:
> What I don't understand is, why it needs to get write permissions to
> /etc/mtab ?
That is a worrisome indeed, since /etc/mtab is now often a symlink to
/proc/self/mounts (or to /proc/mounts which in symlinks to /proc/self/
moun
Rick \"Zero_Chaos\" Farina posted on Wed, 02 Apr 2014 16:15:28 -0400 as
excerpted:
> On 02/24/2014 12:32 AM, Samuli Suominen wrote:
>> If it's okay, I'd want to post this fast, before adding KEYWORDS to
>> sys-fs/udev-209's ebuild
>>
>>
> Should means required now? Man if I only knew that last w
Thomas Kahle posted on Wed, 02 Apr 2014 22:18:52 +0200 as excerpted:
> www-apps/tt-rss is configured through a file config.php sitting in its
> install directory. At the moment the file is overwritten when upgrading
> with webapp-config. Who is responsible for config-protecting this file?
>
> a
Michał Górny posted on Tue, 01 Apr 2014 19:15:26 +0200 as excerpted:
> If nobody minds, I'm doing a repoman run now and in a few hours I should
> have a list of packages that need to be stabilized in order to clean up
> the dependency trees for multilib packages.
All this seems sane by me. Thank
02.04.2014 20:52, Samuli Suominen пишет:
> The "30 days maintainer time out" stabilization policy isn't working
> when package has multiple SLOTs, because
> the bugs are filed for only latest SLOT, where as some packages require
> stabilization in sync at both SLOTs
>
> Option 1:
>
> Either revert
