Hi,
On 17/11/24 17:22, whiteman808 wrote:
>
> I need help with writing ebuild. Ebuild fails to merge.
> Necessary information is located in attachments.
I haven't actually built this, but if dobin is failing after this step:
> cp $WORK/b001/exe/a.out goimapnotify
Where is goimapnotify actually
/virtual/rust has been masked & I've been updating pkgs which require it.
One of them is /gnome-base/librsvg , but when I try to update it, I get :
warning: `librsvg` (lib) generated 2 warnings
Running `/opt/rust-bin-1.81.0/bin/rustc --crate-name librsvg_c
--edition=2021 librsvg-c/src/lib
On 11/17/24 1:43 AM, Philip Webb wrote:
> I've searched the bug list for 'librsvg', but nothing seems relevant.
> Can anyone suggest a solution ? -- I can post more info, if needed.
Portage told you which info to post when asking for help. Please include
this information (and in particular note
On 16/11/2024 20:13, Rich Freeman wrote:
Well, drive-managed SMR drives typically have CMR regions for data
caching, and they could also be used to store the bitmap. Cheap
drives might not support trim at all, and would just preserve all data
on write. After all, it isn't performance that is dr
On Sat, Nov 16, 2024 at 05:04:43PM -0500, Jack Ostroff wrote:
> There's been an update to the gkrellm mailing list about progress on the
> gtk3 conversion. It seems much of the work is being done in a specific
> git branch. If I want to create an ebuild to track that branch instead
> of master
Ionen,
Thanks for the feedback.
On 2024.11.16 17:33, Ionen Wolkens wrote:
On Sat, Nov 16, 2024 at 05:04:43PM -0500, Jack Ostroff wrote:
> There's been an update to the gkrellm mailing list about progress
on the
> gtk3 conversion. It seems much of the work is being done in a
specific
> git
There's been an update to the gkrellm mailing list about progress on the
gtk3 conversion. It seems much of the work is being done in a specific
git branch. If I want to create an ebuild to track that branch instead
of master, what would be an appropriate numbering of that ebuild? Just
using
On Sat, Nov 16, 2024 at 2:47 PM Michael wrote:
>
> As I understand it from reading various articles, the constraint of having to
> write sequentially a whole band when a random block changes within a band
> works the same on both HM-SMR and the more common DM-SMR.
Correct.
> What differs with
>
On Saturday 16 November 2024 14:36:02 GMT Rich Freeman wrote:
> On Sat, Nov 16, 2024 at 6:02 AM Michael wrote:
> > I assume (simplistically) with DM-SMRs the
> > discard-garbage collection is managed wholly by the onboard drive
> > controller, while with HM-SMRs the OS will signal the drive to sta
On Sat, Nov 16, 2024 at 6:02 AM Michael wrote:
>
> I assume (simplistically) with DM-SMRs the
> discard-garbage collection is managed wholly by the onboard drive controller,
> while with HM-SMRs the OS will signal the drive to start trimming when the
> workload is low in order to distribute the ti
On Friday 15 November 2024 22:13:27 GMT Rich Freeman wrote:
> On Fri, Nov 15, 2024 at 10:35 AM Michael wrote:
> > Host managed SMRs (HM-SMR) require the OS and FS to be aware of the need
> > for sequential writes and manage submitted data sympathetically to this
> > limitation of the SMR drive, by
11 matches
Mail list logo
