Hello, Ben Cotton.
Wed, 29 May 2019 16:19:48 -0400 you wrote:
> Switching to zstd would increase decompression speed significantly.
Good change, but it will significantly increase Delta RPM rebuild
process especially on HDD, that's why drpm should be disabled by default
to achieve maximum
Hello, Philip Kovacs via devel.
Wed, 19 Jun 2019 15:28:10 + (UTC) you wrote:
> I notice I am still using the `__make` macro in my specs. While they
> still work, should we proactively replace them with `make` ?
You can use %make_build and %make_install instead.
--
Sincerely,
Vitaly
Hello, Kevin Fenzi.
Wed, 1 May 2019 08:43:23 -0700 you wrote:
> I guess I will enable the From field mitigation for this list, but I
> will not like it.
Now it should work fine. Thanks.
I think it should be an option in mailman's settings. Each user can
enable or disable mitigations for his
Hello, Hedayat Vatankhah.
Sat, 4 May 2019 03:40:57 +0430 you wrote:
> I've even emailed Peter directly, but there is no response
You can start non-responsive maintainer procedure.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel
Hello, Stephen J. Turnbull.
Sun, 5 May 2019 05:58:48 +0900 you wrote:
> As a Mailman developer, I
> will strongly oppose turning on user choice by default because my
> constituents are list owners, not subscribers. But that implies it
> would be rarely available.
That's why it's time to
Hello, qrsBRWN.
Sun, 05 May 2019 10:57:06 +0200 you wrote:
> Exactly what platform did you have in mind?
Discourse[1] for example. GTK developers already testing it[2] as
mailing lists replacement.
1: https://github.com/discourse/discourse
2:
Hello, John Florian.
Mon, 8 Jul 2019 15:45:38 -0400 you wrote:
> Along these lines, what's the status of Plasma on Wayland?
Too unstable. Crashes a lot, especially on NVIDIA.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing
Hello, Nicolas Mailhot via devel.
Mon, 15 Jul 2019 07:35:09 + you wrote:
> It would be much clearer and user-friendly to move I*86 packages out of the
> 64 bit repos and make the i*86 an optional add-on
It will break multilib.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
Hello, Dridi Boukelmoune.
Mon, 15 Jul 2019 08:26:59 + you wrote:
> Emulate as in not run natively even though the hardware might be able to?
Sorry for misinformation. Wine64 is still require 32-bit libraries in
order to run legacy 32-bit Windows PE executables.
Hello, Dridi Boukelmoune.
Mon, 15 Jul 2019 06:59:33 + you wrote:
> game that cannot move to 64bit support because it's dragging binaries
> for which it doesn't have source code.
Wine64 can still emulate 32-bit WinPE executables.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
Hello, John Reiser.
Sun, 14 Jul 2019 14:35:46 -0700 you wrote:
> For some apps 2GB of malloc() arena is plenty, and they run faster
> in 32-bit mode because a 64-byte cache line contains 16 pointers
> instead of only 8.
And such applications became extremely vulnerable due to missing ASLR
Hello, Neal Gompa.
Sun, 14 Jul 2019 17:27:03 -0400 you wrote:
> Building library packages and making your own multilib repo is
> impossible without having both the i686 repo and the x86_64 repo, as
> you need to build for both and then munge them together for a multilib
> repo.
Most of Fedora
Hello, Ben Cotton.
Fri, 12 Jul 2019 09:38:28 -0400 you wrote:
> Update the Mono stack in Fedora from 5.18 to 5.20.
Also please update NuGet package. It was not updated for ages and cannot
install modern dotnet dependencies.
Packaged version: 2.8.7.
Current stable version: 5.0.2.
RHBZ:
Hello, Jiri Vanek.
Mon, 15 Jul 2019 09:22:57 +0200 you wrote:
> That is not enough. See what hapened to Ubuntu once they dropped i686
They decided to remove whole 32-bit support, including multilib support.
We need to drop 32-bit packages, except needed to run Steam and Wine32.
Third-party
I can suggest following:
1. Do review process much more easier by running Fedora Review Tool on
Koji using fedpkg. Output can be sent to email for additional manual checks.
2. Do package revocation procedure from non-responsive maintainers much
more simple and easier. Currently we need to wait 3
On 13.08.2019 16:52, Ernestas Kulik wrote:
> No need to get defensive about this. Provide feedback ahead of time
> and, preferably, help out. Replacing tooling is not just flipping a
> switch.
But he was right. Review process in openSUSE is much more easier, than
in Fedora. Currently no one want
On 13.08.2019 20:01, Adam Williamson wrote:
> This is true, but that's not a reason to stop doing package reviews.
> "Things aren't perfect" is never a good excuse for "...so we can make
> them worse!"
I never asked to stop doing package reviews. Package review is a good
thing. I just asked to
On 13.08.2019 18:34, Adam Williamson wrote:
> And yet this thread demonstrates that without good review, we will get
> garbage packages. Review processes exist for a reason.
Every package can become a garbage, because after package review no one
reviews it again. I see lots of legacy packages,
Hello, Steven A. Falco.
Thu, 1 Aug 2019 14:28:31 -0400 you wrote:
> What is the best way to do that? I can add "%undefine _hardened_build"
> (which I am testing now) but I think that will remove other hardening
> features that I might want to leave enabled.
%global optflags %(echo %{optflags}
On 18.08.2019 2:24, Joseph D. Wagner wrote:
> The Plymouth LUKS password prompt will wait FOREVER for me to type in a
> password
This is intended, because system is not even started yet on
LUKS-encrypted media attach stage.
If you don't want to enter LUKS password on every boot, you should use
On 19.08.2019 8:18, Joseph D. Wagner wrote:
> It is intended to display the same image on the screen continuously
Yes. User must enter LUKS password to continue booting. System cannot be
booted until all drives from /etc/fstab will be unlocked and
successfully mounted.
Screensaver cannot be
On 16.08.2019 6:22, Richard Shaw wrote:
> I assume this is because LibRaw is available in RHEL but only for x86_64
> and ppc64le?
The same as Pidgin and lots of other apps/libs. You need to add
"ExclusiveArch: x86_64 ppc64le" in order to build your package successfully.
--
Sincerely,
Vitaly
On 13.08.2019 12:38, Kamil Dudka wrote:
> So you want to use -flto=auto
Supported only by GCC 10+.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On 21.08.2019 4:59, Chris Murphy wrote:
> The very
> simple work around for the computer shutting off in 3 minutes of
> inactivity and you don't like that?
1. Such unpredicted shutdown can damage headers of LUKS-encrypted volumes.
2. If it will be implemented, it must be an opt-in feature.
--
On 26.08.2019 15:07, mcatanz...@gnome.org wrote:
> Well the thing is, blocknig ports tends to break applications that want
> to use those ports
All ports must be opened explicitly. Current configuration is look like
"come and hack me anyone".
> Unless you have malware installed (in which case,
On 27.08.2019 9:32, mcatanz...@gnome.org wrote:
> This doesn't seem like a serious effort to think about how a firewall
> could be useful, it just seems like an effort to break software.
The current behavior makes a huge security breach in system. It
definitely need to be fixed.
Someone need to
Hello all.
According to non-responsive maintainer procedure for moceap, I'm asking
here if anyone know how to reach out for the maintainer.
RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1740611
RHBZ ticket with countdown:
https://bugzilla.redhat.com/show_bug.cgi?id=1733802
--
Hello all.
Is it okay that firewall is completely disabled by default (opened all
ports 1025-65535) on Fedora Workstation?
I think that this is a major vulnerability and it must be fixed by
changing default zone to public.
firewall-cmd --list-all
FedoraWorkstation (active)
target: default
On 19.08.2019 12:38, Dominique Martinet wrote:
> LCD definitely has this issue - display the same image forever and the
> pixels will remember it / you will be left with an overlay of the
> previously still image.
This is a known IPS displays issue, known as "ghosting". This is not a
burn-in. It
On 27.08.2019 18:14, Björn Persson wrote:
> If it could come from anywhere, then we must assume that it's malicious.
> You executed untrusted code. It's already past your firewall. Game over,
> you're infected. You're closing the stable door after the horse has
> bolted.
Any application can run
On 13.09.2019 17:27, Jerry James wrote:
> To diagnose 32-bit-specific problems in packages.
You don't need to do it anymore on Fedora 31+ due to i686 deprecation
(except of multilib shared libraries, needed by Steam and Wine).
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 13.09.2019 14:53, Ralf Corsepius wrote:
> Understood - Give me a ping when Fedora has a usable infrastructure again.
What is the purpose of using i386 mock today?
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
On 13.09.2019 17:10, Sérgio Basto wrote:
> how you build a multilib in mock or in copr ?
Koji --scratch.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On 9/9/19 11:52 AM, John M. Harris Jr. wrote:
> That's now how vulnerabilities work, and just being 64 bit doesn't solve any
> security issue.
https://en.wikipedia.org/wiki/Address_space_layout_randomization
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 9/9/19 1:47 PM, John M. Harris Jr. wrote:
> ASLR has nothing to do with the wild claims made in that email, that having
> an
> x86 system will somehow taint or 'infect' other systems. Additionally, you
> don't need to run a 64 bit system to get ASLR.
i686 app has only 4 GB of virtual
On 9/7/19 8:44 PM, Victor V. Shkamerda wrote:
> There are reasons why using x86_64 kernel with i686 userland might be a
> better option.
Because i686 has tons of unresolved bugs: it has no upstream support, no
maintainers and even testers with real hardware.
Do **YOU** want to be a i686-arch
Hello all.
While building my Fedora packages for EPEL8, got a very strange error on
aarch64 and s390x architectures:
No matching package to install: 'pkgconfig(pidgin)'
But it builds fine with the same SPEC on x86_64 and ppc64le.
Affected builds:
On 06.08.2019 2:06, Kevin Kofler wrote:
> Well, if there is no testsuite and if the headers are truly
> architecture-independent
Most of modern C++ header-only libraries provides Cmake scripts. Such
scripts will be installed to %{_libdir}/cmake/foo. That's why they
cannot be noarch.
--
Hello, Barry Scott.
Sun, 21 Jul 2019 09:54:32 +0100 you wrote:
> Could not execute update: Could not generate update request: Cannot find
> release associated with build: python-pycxx-7.1.3-1.fc31, tags: ['f31']
Rawhide packages will be automatically pushed to repositories. You don't
need to
Hello, Igor Gnatenko.
Tue, 23 Jul 2019 07:34:06 +0200 you wrote:
> * Define new architecture in RPM/libsolv (let's call it "haswell" or
> "x86_64modern")
I have a better idea: use modules to build special AVX/SSE4 enabled
versions of some packages.
--
Sincerely,
Vitaly Zaitsev
Hello, Zdenek Dohnal.
Thu, 18 Jul 2019 13:44:56 +0200 you wrote:
> What's your opinion? Is it useful feature of Vim and it should stay as
> default, or it needs to be disabled?
I think, that *.spec files on Fedora should be treated as RPM SPEC files
by default.
--
Sincerely,
Vitaly Zaitsev
Hello, Zdenek Dohnal.
Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
> Even the new .spec files, which do not have to be RPM spec files?
> Because Vim provides spec template for such cases.
I never used this feature, so I think it can be disabled by default. But
syntax highlighting for RPM SPEC
Hello, Till Hofmann.
Fri, 19 Jul 2019 08:46:50 +0200 you wrote:
> We also have rpmdev-newspec
Btw, someone need to remove from templates, used by this tool, this row:
rm -rf $RPM_BUILD_ROOT. It forbidden by modern packaging guidelines.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
Hello, Remi Collet.
Thu, 25 Jul 2019 11:16:54 +0200 you wrote:
> Additional question, what will happen when the key will expire ?
Expired keys cannot be used for signing or encrypting. But they still
can be used for decrypting and verifying signatures.
--
Sincerely,
Vitaly Zaitsev
On 26.09.2019 15:10, Pierre-Yves Chibon wrote:
> What makes it a headache? What can we do to not have this be a terrible
> headache? Can we fix/improve the tooling?
I'm not going to log in into web, create a new pr, then merge it. This
is a terrible idea. Do not change current workflow.
--
On 26.09.2019 11:36, Pierre-Yves Chibon wrote:
> ○ Every changes to dist-git is done via pull-requests
No way! This is a terrible idea.
> ○ Every build in koji results automatically in an update in bodhi
Not good too.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 24.09.2019 09:08, Vít Ondruch wrote:
> This sounds interesting, but this tool is probably coming late into play
> to fix early boot thermal throttling issues such as
BTW, I fixed such throttling issues on my ThinkPad T580 with this:
https://github.com/xvitaly/throttling-fix
--
Sincerely,
On 08.11.2019 13:16, Miro Hrončok wrote:
> kf5-baloo
> kf5-frameworkintegration
> kf5-kactivities
> kf5-kactivities-stats
> kf5-kbookmarks
> kf5-kcmutils
> kf5-kconfigwidgets
> kf5-kdeclarative
> kf5-kded
> kf5-kdelibs4support
> kf5-kdesignerplugin
> kf5-kdesu
> kf5-kdewebkit
> kf5-kemoticons
>
On 12.12.2019 21:37, Ben Cotton wrote:
> Proposal to make all Fedora optical media non-blocking. This means
> we'd stop blocking on bugs found during the installation of Fedora
> from optical media (like CDs and DVDs). This doesn't mean that
> installation from optical media would stop working,
Hello.
According to non-responsive maintainer procedure for tchaikov, I'm
asking here if anyone know how to reach out for the maintainer.
RHBZ ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1778081
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 16.10.2019 06:13, Neal Gompa wrote:
> We cannot remove already existing default modules without further
> breaking things. Moreover, DNF will refuse to expose non-modular RPMs
> if it's aware of modular ones that have existed at some point. The
> best we can do is stop people from making more.
On 06.10.2019 09:08, Germano Massullo wrote:
> I would like to package OnlyOffice Desktop Editors [1]
Packaging of Electron is not allowed:
https://fedoraproject.org/wiki/Electron
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel
On 06.10.2019 10:11, Samuel Sieb wrote:
> I don't see anything about it not being allowed
Electron is a full Chromium core with nodejs engine, which contains
ffmpeg library. If you want to redistribute it in official repositories,
you must resolve all legal issues with bundled Chromium by
Hello all.
Is it possible to remove old %changelog entries from SPECs? I can't find
information about this in Fedora packaging guidelines.
All history still can be found in git log.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel
On 14.10.2019 12:16, Kevin Kofler wrote:
> To be clear, I propose the following:
> * All packages MUST have a default version in any given Fedora release.
> * The default version MUST be shipped as non-modular (not as a modular
> default stream).
> * It follows that packages cannot be
Hello.
Fmt 6.1.2 build completed for Rawhide. It include SOVERSION bump. All
dependent packages need to be rebuilded.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
On 20.12.2019 21:30, Jan Kratochvil wrote:
> This is AFAIK not enough for LUKS drives, will it be supported for LUKS?
If you want to enable TRIM for LUKS, you should add discard option to
/etc/crypttab file.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 20.12.2019 21:53, Chris Murphy wrote:
> If your LUKS drives are listed in fstab, they will have fstrim issued
> and it will pass down to the physical drive.
Only with enabled discard option in /etc/crypttab, because trimming of
LUKS significantly decrease security level (everyone even without
On 19.12.2019 22:41, Ben Cotton wrote:
> This is a proposal to enable link time optimization (LTO) of packages
> built with rpmbuild by default. It's an over-simplification, but
> think of LTO as deferring analysis, optimization and code generation
> until creation of an executable or dynamic
On 19.12.2019 22:42, Ben Cotton wrote:
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.
It seems to me that it has already been implemented in old Fedora
releases as well as alternatives for text editors. Later it was decided
to drop
On 18.12.2019 01:43, Brad Hubbard wrote:
> I spoke to the maintainer. He said he'll take a look this weekend. His
> workload is truly enormous and mind boggling so please be patient.
Please ask him to add me as co-maintainer to fmt package. I can help him
with packaging.
My FAS username: xvitaly
Hello.
I'm going to update spdlog package to version 1.4.2 in Rawhide. This is
not a header-only library anymore.
This update can break dependent packages if they don't use
cmake/pkgconfig to import spdlog.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 17.12.2019 20:18, Ken Dreyer wrote:
> Is there a particular Fedora bug that you need Kefu to address?
https://bugzilla.redhat.com/show_bug.cgi?id=1747062
Package fmt need to be updated to version 6.x at least in Rawhide.
Currently it locked 3 of my packages.
If he has no free time, he can
On 20.12.2019 10:23, Lennart Poettering wrote:
> So, if this is desirable, why doesn't the kernel do this on its own?
Kernel's TRIM has issues with data corruption on some SSD controllers.
You can check drivers/ata/libata-core.c of Linux kernel sources for more
information.
--
Sincerely,
On 18.12.2019 09:07, kefu chai wrote:
> Vitaly, sorry for the latency. thanks for your help. already added you
> as an admin of fmt project.
Thanks. Build completed:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1423531
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 28.02.2020 16:04, Orion Poplawski wrote:
> I have already reduced the make parallelism to 1, so not sure what else
> I can do to avoid this other than to exclude it (which I'm probably
> happy to do). Suggestions welcome.
You can try this:
%global optflags %(echo %{optflags} | sed 's/-g /-g1
On 24.02.2020 10:55, Miroslav Suchý wrote:
> Additionally, even when the build in Koji (or Mock in general) is offline,
> the dependencies are installed with internet
> enabled. If you teach Mock how to call native crate/rubygem/.. before the
> actual build start, you will have most of the
>
On 24.02.2020 13:41, Miroslav Suchý wrote:
> Yes. But it is only rpm-build what cannot access network. Mock itself can
> access network.
Mock is using Internet connection only for downloading metadata and
packages from repositories. Then it use systemd-nspawn to create a
protected isolated
On 24.02.2020 14:30, Sandro Mani wrote:
> That's a good point, I've asked upstream if that is actually the case or
> whether the dependency replaced previous logic which would also need to
> be restored to get the same level of accuracy.
You can just revert some upstream commits by downstream
On 05.02.2020 05:05, Code Zombie wrote:
> Is Fedora considering to add it to its packages? Does anyone already
> plan to maintain it or can I take it over?
Currently impossible due to completely broken Java stack in Fedora.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 05.02.2020 10:11, Aleksandar Kurtakov wrote:
> We (Eclipse maintainers in Fedora) are looking into using Flatpak
> instead (https://flathub.org/apps/details/org.eclipse.Java)
Then start building Fedora native flatpaks. Flatpak != Flathub. Flathub
is a third-party repository.
--
Sincerely,
On 18.02.2020 22:29, David Sommerseth wrote:
> We released the OpenVPN 3 Linux v8 beta release early last week [0], with the
> Fedora Copr repository [1] updated as well. Now things are working so well it
> is about time to get this package into the mainline Fedora repositories.
Fedora already
On 19.02.2020 09:32, Tom Hughes wrote:
> In this case I believe that although the client is intended to be
> protocol compatible with openvpn 2 it's basically an entirely new
> program with a totally different architecture and user interface
> so parallel packaging seems reasonable.
I think it
Hello all.
Why we still has ancient Boost 1.69 even in Rawhide? Some packages
require 1.70+ and I cannot update them in repositories.
Latest Boost version is 1.72 (released 2019/12/11).
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel
On 10.02.2020 09:43, John M. Harris Jr wrote:
> As long as it builds and functions, why remove it?
Because it has lots of critical vulnerabilities and endangers end-user
devices.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing
Hello all.
COPR builds from SCM are still failing with no visible errors. Does
anyone know how to fix this?
Full build log:
https://copr.fedorainfracloud.org/coprs/phracek/PyCharm/build/1241112/
P.S. I cannot even upload SRPM due to its size. COPR throw HTTP 500
error when trying to upload SRPM
On 10.01.2020 17:36, Pierre-Yves Chibon wrote:
> Do we want to drop release and changelog from our spec file?
YES. Changelogs can be automatically generated from Fedora Git SCM commits.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel
On 02.01.2020 13:12, Damian Ivanov wrote:
> Peek is on Flathub btw.
Flathub is a third-party repository with low-quality packages. I'm not
going to trust it.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
On 03.01.2020 11:14, Michael Schwendt wrote:
> What sort of "huge headache" would that be?
1. Most of ffmpeg-capable applications use compile-time checks for
available codecs presence.
2. Sync errors between repositories like chromium and
chromium-libs-media-freeworld.
> Third party repos like
On 03.01.2020 20:18, Ben Cotton wrote:
> Workstation working group has discussed "better interactivity in
> low-memory situations" for some months. In certain use cases,
> typically compiling, if all RAM and swap are completely consumed,
> system responsiveness becomes so abysmal that a reasonable
On 03.01.2020 22:27, Neal Gompa wrote:
> and servers...
Admins will be very happy when such user-space killer will kill for
example PgSQL database server and cause DB corruption or loss of banking
transactions.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 03.01.2020 20:01, Michael Schwendt wrote:
> Which is something you can only fix with an RPM Fusion package,
> if you "control" (= build) all depending packages.
RPM Fusion will need to copy and rebuild all such packages and this is a
huge headache for maintainers and currently forbidden by
On 02.01.2020 10:05, Benson Muite wrote:
> I suspect there would be interest in having a royalty free version of FFMPEG
No, please, don't do this. It will be a huge headache for RPM Fusion
maintainers.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 24.12.2019 12:00, Emmanuel wrote:
> Click the "Toggle all" button then the "Create button"
You need only "Create a new issue" permission.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
On 07.01.2020 16:16, Kevin Kofler wrote:
> To me, it looks crystal clear that the new licensing conditions are not
> acceptable for Fedora.
In this case geolite2 packages can be moved to RPM Fusion.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
Hello all.
I think Fedora Koji has major issues with build overrides now.
Previously I waited only 5-10 minutes and then started building my
packages. But during the last month I need to wait more than 2 hours for
a single build override. This is absolutely unacceptable.
--
Sincerely,
Vitaly
On 13.04.2020 18:58, Michael Catanzaro wrote:
> I guess that solves the problem, doesn't it? There is zero reason for
> Fedora to be doing a component build anymore if it's no longer of
> benefit to rpmfusion. Yes?
I think so.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 13.04.2020 18:01, Tom Callaway wrote:
> What I don't understand is _why_ RPM Fusion made that change. Not saying
> it is without merit, just that I don't understand why a total rebuild is
> preferred.
Due to major synchronization problems between Fedora and RPM Fusion
repositories.
Fedora
On 14.04.2020 21:23, Ben Cotton wrote:
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
I've tested systemd-resolved on my laptop for a month. It worked very,
very unstable. Sometimes it stopped responding and I needed to manually
On 14.03.2020 13:05, Marius Schwarz wrote:
> If you encrypt the fedora ( or any ) installation with luks, as
> security of a mobile device indicates, you end up without the
> possibility to enter the password, when you do not have an in/external
> keyboard at hand.
You should use TPM 2.0 LUKS
On 15.03.2020 23:12, Marius Schwarz wrote:
> I knew someone would bring this up: TMP does not protect your drive,
> as you could boot with "init=/bin/bash 1"
You should enable UEFI Secure Boot, create your CA, install systemd-boot
and sign it with your CA.
TPM 2.0 protect full boot chain using
On 29.03.2020 18:24, Kevin Kofler wrote:
> RPM Fusion used to provide compiled kmod packages for years, and those just
> worked. (Well, for the proprietary ones, they only worked as well as
> proprietary drivers work to begin with, but that was no fault of the kmod
> packages.) So why and when
On 30.03.2020 10:45, Daniel Smith wrote:
> The nvidia drivers need to be packaged for Fedora.
This is absolutely impossible. No proprietary software are allowed.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
On 30.04.2020 15:51, Luke Hinds wrote:
> Has anyone seen this before, why would it not be able to find pip.
You cannot use pip/npm/gems in official builds. You must use packaged
versions of such dependencies.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On 01.05.2020 12:52, Peter Robinson wrote:
> I bet this is actually the Intel Dynamic Platform and Thermal
> Framework (DPTF) that's at fault here [1] and so while I'm sure Lenovo
> can approach Intel and assist I'm not sure it's something they can fix
> directly, on the plus side it looks like
On 30.04.2020 23:18, Mark Pearson wrote:
> Adam Williamson suggested I stick a note in the mailing list saying “hi”
> - so I’ve achieved that and officially upgraded myself from lurker! He
> also suggested I take questions from the community - and I’m very happy
> to do that.
Hello, Mark.
When
On 01.05.2020 14:52, Mark Pearson wrote:
> We have to meet some temperature safety requirements when the device is on
> lap. Because Linux doesn't have support for that the device defaults to the
> 'safer'
> power setting and you see thermal throttling (and lower performance than
> Windows).
On 12.05.2020 10:35, Ty Young wrote:
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!
No. Please read Fedora packaging guidelines. All packages **must** be
built from sources.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
On 19.05.2020 10:32, Guido Aulisi wrote:
> It seems GCC 10.0 had some bugs that could be discovered only at
> runtime. Did you have any similar problems?
GCC 10.0.1 was broken. Maintainers of gcc just used SVN trunk in
production without any real tests.
I experienced lots of ICEs and multiple
On 19.05.2020 11:40, Fabio Valentini wrote:
> As I wrote in my direct response to Guido, doing a mass rebuild for
> fedora just isn't possible in released branches. So, the best we can
> do is to deal with issues as people become aware of them and report
> them, and then rebuild those few broken
1 - 100 of 1125 matches
Mail list logo
