On Fri, Jul 10, 2020 at 02:35:05PM -0700, John M. Harris Jr wrote:
> On Friday, July 10, 2020 4:39:21 AM MST Miro Hrončok wrote:
> > On 09. 07. 20 14:24, Petr Pisar wrote:
> >
> > > On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
> > >
> > >> One just noticed that `dnf autoremove` is
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 happen.
> 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 smoothly,
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 btrf
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 number
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 \
-DLLVM_STATI
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 em
> (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 en
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
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
wh
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 oriented"
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 ki
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 \
-DEN
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" th
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 snaps
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 \
>>-D
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 \
>-DCM
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
"sim
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
24 matches
Mail list logo