https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/13/report-389-ds-base-1.4.4.4-20200712git318a3ce.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
On Sun, Jul 12, 2020 at 5:33 PM Tom Seewald wrote:
>
> > What changes?
>
> I don't see a reason for this level of snark, in your next paragraph you
> described the changes I'm talking about.
>
> > Discussion is happening upstream to determine the best location for
> > such optimization to
> What changes?
I don't see a reason for this level of snark, in your next paragraph you
described the changes I'm talking about.
> Discussion is happening upstream to determine the best location for
> such optimization to happen.
I'm glad work is happening upstream and I hope it goes
On Sun, Jul 12, 2020 at 1:31 PM Tom Seewald wrote:
>
> > (Yes, that means applications need to start being concious of what fs
> > they are being run on, or at least the fedora configuration needs to do
> > that check for them)
>
> Right, and it's concerning to me that Fedora is committing to
On Saturday, July 11, 2020 2:36:04 PM MST Neal Gompa wrote:
> There's a difference between half-baked and a roadmap of incremental
> improvement. This Change is an example of the latter. If anything,
> your fanciful and speculative conjecture has done only harm for your
> credibility. You continue
On Saturday, July 11, 2020 3:14:06 PM MST Gary Buhrmaster wrote:
> On Sat, Jul 11, 2020 at 9:11 PM John M. Harris Jr
> wrote:
>
> > None of this is relevant ... (to) ... a package which is ...
> > widely used, however.
>
>
> You keep making that assertion. Please provide
> the audited
On Sun, Jul 12, 2020, at 4:07 PM, Kevin Fenzi wrote:
> On Sun, Jul 05, 2020 at 02:15:23PM +0200, Nicolas Mailhot via devel wrote:
> > Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann'
> > Mierzejewski a écrit :
> > >
> > > > To get beautiful changelogs, you also need to add
> > > >
>
On Sunday, 12 July 2020 22:13:54 CEST Luya Tshimbalanga wrote:
> Thank you for Thumbleweed spec file. With some adjustment, the build
> almost succeed as the shaders path managed to fail.
>
> On 2020-07-11 12:46 p.m., Robert-André Mauchin wrote:
>
> >
> >
> > %cmake \
> >
> > -B build \
>
Thank you for Thumbleweed spec file. With some adjustment, the build
almost succeed as the shaders path managed to fail.
On 2020-07-11 12:46 p.m., Robert-André Mauchin wrote:
%cmake \
-B build \
-DUSE_BOOST_WAVE=ON \
-DUSE_PARTIO=OFF \
-DCMAKE_CXX_STANDARD=14 \
On Sun, Jul 05, 2020 at 02:15:23PM +0200, Nicolas Mailhot via devel wrote:
> Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann'
> Mierzejewski a écrit :
> >
> > > To get beautiful changelogs, you also need to add
> > >
> > >
> > > %buildsys_name Your name
> > > %buildsys_email Your
> (Yes, that means applications need to start being concious of what fs
> they are being run on, or at least the fedora configuration needs to do
> that check for them)
Right, and it's concerning to me that Fedora is committing to btrfs by default
before important applications have become more
On Sat, Jul 11, 2020 at 10:26 AM Jiri Vanek wrote:
>
> Hello!
>
> toatal packages: 610
> passed: 427
> failed: 176
>
> From the failures, there is 29 which passed in the copr before, and now are
> thus failing from two
> reasons - unrelated change, or non-intel64-arch failure. I will put this to
https://bugzilla.redhat.com/show_bug.cgi?id=1855962
Emmanuel Seyman changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=1852302
Emmanuel Seyman changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1854712
Emmanuel Seyman changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1854677
Emmanuel Seyman changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1855829
Emmanuel Seyman changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1854706
Emmanuel Seyman changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
On Sun, Jul 12, 2020 at 5:39 AM Andy Mender wrote:
>
>On updates, a single automatic corrupted snapshot can
> potentially hose the entire snapshotted volume.
How do you mean? If this is a sort of superficial corruption like a
bad/failed/partial update, inconsistency between package manager and
https://bugzilla.redhat.com/show_bug.cgi?id=1856074
Bug ID: 1856074
Summary: perl-Log-Handler-0.89 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Log-Handler
Keywords: FutureFeature, Triaged
On Sun, Jul 12, 2020 at 7:51 AM Dominique Martinet
wrote:
> (Yes, that means applications need to start being concious of what fs
> they are being run on, or at least the fedora configuration needs to do
> that check for them)
Good luck with that. It's a direct violation of the "object
On Thu, 2020-07-09 at 07:51 -0700, John M. Harris Jr wrote:
> What's the KDE SIG's rationale behind supporting this? This actively limits
> the amount of RAM that end users are able to make use of. The more RAM the
> end
> user has, the more RAM is not available for use, because EarlyOOM will
On Sun, Jul 12, 2020 at 12:46 PM Jonathan Wakely
wrote:
> On 12/07/20 12:33 +0100, Ian McInerney wrote:
>This is what the upstream project explicitly says to do when using LLVM10:
> >
> https://github.com/imageworks/OpenShadingLanguage/blob/master/src/cmake/externalpackages.cmake#L248
> .
> >As
Vitaly Zaitsev via devel wrote on Sun, Jul 12, 2020:
> On 11.07.2020 14:20, Dominique Martinet wrote:
> > BTW, given the size gains ws. time difference for compression I would
> > advocate for default zstd compression instead of :1 -- I'd think another
> > 12% compression improvement[1] for almost
On 12/07/20 12:33 +0100, Ian McInerney wrote:
On Sun, Jul 12, 2020 at 12:15 PM Andy Mender
wrote:
On Sat, 11 Jul 2020 at 21:47, Robert-André Mauchin
wrote:
%build
%cmake \
-B build \
-DUSE_BOOST_WAVE=ON \
-DUSE_PARTIO=OFF \
-DCMAKE_CXX_STANDARD=14 \
-DLLVM_STATIC=0 \
On Sun, 2020-07-12 at 12:46 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > There's a difference between half-baked and a roadmap of incremental
> > improvement. This Change is an example of the latter.
>
> No, it is actually an example of deliberately implementing a simplistic
> "solution"
On Sat, 11 Jul 2020 at 18:05, Neal Becker wrote:
> I think if we really want to advocate for btrfs, we also should provide
> the
> tools to take full advantage of it. I've been using btrfs since it was
> offered as an option on Fedora. On Ubuntu, there is a tool "snapper" to
> help manage
On Sun, Jul 12, 2020 at 12:15 PM Andy Mender
wrote:
> On Sat, 11 Jul 2020 at 21:47, Robert-André Mauchin
> wrote:
>
>> %build
>> %cmake \
>>-B build \
>>-DUSE_BOOST_WAVE=ON \
>>-DUSE_PARTIO=OFF \
>>-DCMAKE_CXX_STANDARD=14 \
>>-DLLVM_STATIC=0 \
>>-DENABLERTTI=ON \
>>
On Sat, 11 Jul 2020 at 21:47, Robert-André Mauchin
wrote:
> %build
> %cmake \
>-B build \
>-DUSE_BOOST_WAVE=ON \
>-DUSE_PARTIO=OFF \
>-DCMAKE_CXX_STANDARD=14 \
>-DLLVM_STATIC=0 \
>-DENABLERTTI=ON \
>-DSTOP_ON_WARNING=OFF \
>-DOSL_BUILD_MATERIALX:BOOL=ON \
>
Neal Gompa wrote:
> There's a difference between half-baked and a roadmap of incremental
> improvement. This Change is an example of the latter.
No, it is actually an example of deliberately implementing a simplistic
"solution" that lags behind the state of the art on the grounds that it is
On Tue, Jul 07, 2020 at 04:57:53PM -0400, Elliott Sales de Andrade wrote:
On Tue, 7 Jul 2020 at 13:05, Fabio Valentini wrote:
Hi everybody,
I have to finally admit that I'll never again be able to play catch-up
with the ever-changing sprawling go library dependency tree of
syncthing.
I have
On 11.07.2020 17:28, Chris Murphy wrote:
> The paper is with respect to metadata write amplification. This has no
> effect on data writes. Compression applies to data writes, not
> metadata. As the data amount is significantly larger than metadata
> (the file system itself), any reduction in data
On 11.07.2020 14:20, Dominique Martinet wrote:
> BTW, given the size gains ws. time difference for compression I would
> advocate for default zstd compression instead of :1 -- I'd think another
> 12% compression improvement[1] for almost no time difference isn't to be
> sneezed at?
Now please
33 matches
Mail list logo
