Emerging ecasound failed with "DSO missing from command line". After reading
https://stackoverflow.com/questions/19901934/libpthread-so-0-error-adding-symbols-dso-missing-from-command-line
I did export LDFLAGS="-Wl,--copy-dt-needed-entries" and then it
emerged successfully.
Bug? (upstream? in the
On Mon, Apr 27, 2020 at 3:07 PM antlists wrote:
>
> On 27/04/2020 17:59, Rich Freeman wrote:
> > Really though a better solution than any of this is for the filesystem
> > to be more SSD-aware and just only perform writes on entire erase
> > regions at one time. If the drive is told to write
On 27/04/2020 17:59, Rich Freeman wrote:
Really though a better solution than any of this is for the filesystem
to be more SSD-aware and just only perform writes on entire erase
regions at one time. If the drive is told to write blocks 1-32 then
it can just blindly erase their contents first
On 2020.04.27 12:47, Jorge Almeida wrote:
On Mon, Apr 27, 2020 at 4:27 PM Jack
wrote:
>
I just checked "emerge -pe zoom" and the only unstable qt listed is
qtdiag, which has no stable versions in the tree. In fact, of the
483 packages listed, only five are unstable. If it pulls in lots
On Mon, Apr 27, 2020 at 12:20 PM wrote:
>
> The kernel is keep track of all, which already has been fstrimmed and
> avoids to retrimm the same data.
> This knowledge gets lost, when the PC is powercycled or rebooted.
>
I imagine this is filesystem-specific. When I checked the ext4 source
I
On Mon, Apr 27, 2020 at 4:27 PM Jack wrote:
>
>
> I just checked "emerge -pe zoom" and the only unstable qt listed is
> qtdiag, which has no stable versions in the tree. In fact, of the 483
> packages listed, only five are unstable. If it pulls in lots of
> unstable qt for you, I'd try to
On 04/28 03:12, Kent Fredric wrote:
> On Sun, 26 Apr 2020 18:15:51 +0200
> tu...@posteo.de wrote:
>
> > Filesystem Size Used Avail Use% Mounted on
> > /dev/root 246G 45G 189G 20% /
>
> Given that (Size - Used) is roughly 200G, it suggests to me that
> perhaps, some process
On Mon, Apr 27, 2020 at 11:31:57PM +1200, Kent Fredric wrote:
> On Wed, 22 Apr 2020 19:14:55 +0300
> lego12...@yandex.ru wrote:
>
> > portage must be in C and statically linked.
>
> Do you want Segfaults?
Certainly no :-). Like any other :-).
> Because that's how you get segfaults :p.
No-no
On 2020.04.26 19:42, Jorge Almeida wrote:
On Mon, Apr 27, 2020 at 12:03 AM Jack
wrote:
> On 2020.04.26 18:22, Jorge Almeida wrote:
The slack ebuild might go stable, but the zoom one seems to change
too often to last 30 days before an update, so stable seems
unlikely. At least I don't
On Sun, 26 Apr 2020 18:15:51 +0200
tu...@posteo.de wrote:
> Filesystem Size Used Avail Use% Mounted on
> /dev/root 246G 45G 189G 20% /
Given that (Size - Used) is roughly 200G, it suggests to me that
perhaps, some process somewhere is creating and deleting a lot of
temporary
On Wed, 22 Apr 2020 19:14:55 +0300
lego12...@yandex.ru wrote:
> portage must be in C and statically linked.
Do you want Segfaults?
Because that's how you get segfaults :p.
Maybe Rust or something like it, but I don't really trust our capacity
to implement something this complicated in C.
Hello, Rich.
On Sun, Apr 26, 2020 at 15:29:40 -0400, Rich Freeman wrote:
[ ]
> Incidentally, in the other thread the reason that dry-run didn't
> report anything to be trimmed is that this is hard-coded:
> printf(_("%s: 0 B (dry run) trimmed on %s\n"), path, devname);
>
On 27/4/20 11:14 am, tu...@posteo.de wrote:
On 04/26 09:58, Rich Freeman wrote:
/ on a btrfs raid10 (1x500G and 3x120G SSD)
"fstrim -v /" about 2 hrs apart:
rattus ~ # fstrim -v /
/: 680.6 GiB (730744291328 bytes) trimmed
rattus ~ # fstrim -v /
/: 17.8 GiB (19087859712 bytes) trimmed
13 matches
Mail list logo
