On Sat, Feb 8, 2020 at 5:08 PM Sérgio Basto wrote:
> and why gradle was retired ? is easy unretire it ?
Announced here (with reasons):
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/BMJXGWKXXFOOBQON3XFYPFBOWEZMAKKU/
On Tue, Feb 11, 2020 at 5:10 PM Chris Murphy wrote:
> A further possibility as it relates to hibernation, is having systemd
> activate a swap partition (or even a swapfile) only at hibernation
> time. That would block it from being used during normal usage,
> preserving it (in effect) for just
On Mon, Jan 6, 2020 at 4:22 PM drago01 wrote:
> What does windows do? Is it the equivalent of the discard mount option or is
> it more like fstrim?
Well, as I understand it(*), it's complicated, and there are a
lot of various tuning knobs one can use to change behavior.
But typically, with
On Tue, Jan 7, 2020 at 9:00 AM Kevin Kofler wrote:
> I think increasing the size of the live images, also affecting the download
> time and the time to write the image to media (even USB sticks are not
> instant), to get a one-time installation speedup is a very bad tradeoff.
While not exactly
On Tue, Mar 10, 2020 at 3:07 AM Orion Poplawski wrote:
> One notable change is that it appears that perl-devel ->
> perl-interpreter no longer brings in the AutoLoader, blib, FindBin,
> sigtrap, Tie::Scalar, and perhaps other modules. Is that intentional?
The changelog certainly documents that
On Fri, Apr 10, 2020 at 2:12 AM Todd Zullinger wrote:
> Checking each of those deps, openssh-clients grew a dep on
> libfido2, which in turn requires u2f-hidraw-policy that is
> provided by systemd. That looks like the main chain which
> leads to the additional packages installed in a mock
On Sun, Apr 5, 2020 at 9:03 AM Leigh Scott wrote:
> Aren't external kernel modules banned by fedora packaging rules?
My recollection (from some time ago) was there was
a process to request a (short term) exception to
allow one to ship a kernel module if the kernel
module developer (not the
On Tue, Mar 31, 2020 at 3:57 PM Kevin Kofler wrote:
> But ideally
You seem to have a lot of thoughts about changes
and improvements to the process.
When should the RPMFusion community expect
you to complete those improvements?
___
devel mailing
On Tue, Mar 31, 2020 at 6:43 AM Panu Matilainen wrote:
> Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
> packages relying on this behavior, which will need fixing to be
> buildable with 4.16.
Is there a list of those thirty something packages
somewhere so that those
On Mon, May 11, 2020 at 7:40 PM Chris Murphy wrote:
> Bias is not the same thing as a conflict of interest. And it doesn't
> inherently result in unfairness.
Sometimes it is a matter avoiding even the appearance
of impropriety that could be raised at a later date to
question the
On Mon, May 11, 2020 at 4:16 PM Alex Scheel wrote:
> Abstaining is in two categories:
There is (at least) one additional category, which
is that the issue involves various levels of self
interest. Technically that is really called a recusal,
but the result is the same when it comes time
to
On Fri, Mar 20, 2020 at 3:20 PM Rob Crittenden wrote:
> Closing a bug doesn't clear the needinfo.
I consider that a mis-feature, but I have
learned to live with it.
> As a package owner I like the daily reminder. If it only happened
> monthly then bad timing could make it so I miss a reminder
On Sun, Sep 6, 2020 at 8:21 AM Andy Mender wrote:
> Will this affect COPR-hosted projects? So far I've been considering both
> i386 and s390 on equal terms to x86_64.
As I recall, copr supports building for the s390x (the 64-bit variant)
and not the s390 (the 32-bit (31 bit addressing)
On Tue, Sep 15, 2020 at 11:47 PM Kevin Kofler wrote:
> There still exist connections as slow as 33 kbps.
And no doubt you can find people still using 300 baud
TI Silent 700 terminals. However, the global internet
speed tests show that the numbers are much higher
on average, and we should
On Sun, Oct 18, 2020 at 9:32 PM Miro Hrončok wrote:
> For the record: Not sure if this was fixed on server side or some polices have
> changed, however I have not needed to apply the workaround, my email works out
> of the box after the upgrade.
You could probably use openssl connect to
On Mon, Oct 19, 2020 at 5:46 PM Damian Ivanov wrote:
>
> >> This proposal was soundly rejected, so don't worry about it.
> >
> > That's great news. Thank you!
> I am not thrilled that this has been rejected since efi support is not
> so good on Fedora.
> Devices that are BIOS can IIRC still use
On Tue, Aug 25, 2020 at 10:51 PM Michel Alexandre Salim
wrote:
> Also, should we add WireGuard to this list for future-proofing?
I had thought about explicitly suggesting
wireguard, but then thought that we should
focus on what is currently being used, and
while *I* use wireguard, it is still
On Sat, Aug 22, 2020 at 12:12 AM Adam Williamson
wrote:
> It must be possible to establish both IPv4 and IPv6 network connections
> using DHCP and static addressing.
For IPV6, SLAAC is more common than DHCP(v6)
(especially) in the consumer space. I would like
to see a SLAAC requirement be
On Sun, Aug 23, 2020 at 2:27 AM Kevin Kofler wrote:
> While I understand the motivation behind the RFC (interoperability, safety
> against intentionally or unintentionally bad parameters), hardcoded
> parameters sound suspicious to me.
I'll note that the RFC 7919 values were added
as available
On Thu, Oct 1, 2020 at 3:48 PM Neal Gompa wrote:
>
> On Thu, Oct 1, 2020 at 11:45 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 01.10.2020 16:54, Petr Menšík wrote:
> > > But DNS over TLS does not bring you more privacy usually.
> >
> > It does. DoT and DoH encrypt all DNS traffic. Your ISP
On Thu, Oct 1, 2020 at 5:21 PM Simo Sorce wrote:
> Note that at this point in time (2020), this is a server bug not a
> Fedora policy problem.
Regardless, as (especially) corporate services tend
to have lives that are excessively longer than updates
in security policies, it might deserve a
On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote:
> Most of those are the libcroco->gettext breakage, no?
From a very cursory scan (not at all scientific),
some percentage are the cmake macro changes.
___
devel mailing list --
On Mon, Aug 3, 2020 at 4:24 PM Peter Robinson wrote:
> There's also a bunch of CMake related ones and I'm not even sure how
> to deal with that.
The proposal owners stated that:
Existing packages can (and most likely will) become FTBFS, but
proposal owners will fix as many Fedora
On Sat, Aug 1, 2020 at 9:23 PM Kevin Kofler wrote:
> Especially the CMake one was completely pointless.
The goal was not pointless, but I will assert that the
implementation was flawed in practice.
I would suggest that a lesson to be learned is that changes
that are expected to require updates
On Mon, Aug 3, 2020 at 7:32 PM Peter Robinson wrote:
> The changes should have landed _BEFORE_ mass rebuild, if the change
> owner didn't have the permissions they should have done PRs for all
> the packages rather than having zero direct comms to affected package
> owners and having them find
On Sat, Aug 8, 2020 at 10:03 PM Jeff Law wrote:
> So I've done two passes over the F33 build failures here:
Thank you for taking ownership and responsibility
for those things that you can control. It is a model
for other change owners to attempt to achieve.
On Tue, Aug 11, 2020 at 2:11 PM Dave Love wrote:
> Is there the possibility of building packages with dummy shims for
> proprietary dynamic libraries that could be substituted at runtime
> (i.e. a package BRs dummy-libthing-devel, and dynamic linker paths
> provide the nasty real libthing at
On Tue, Jul 7, 2020 at 7:04 PM Till Maas wrote:
>
> Hi,
>
> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
> branch for Fedora Rawhide "rawhide" to clarify the purpose of that
> branch. There was also some feedback that Rawhide might not be the best
> name and it could be
On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr wrote:
>
> Why should I have to switch the system that's being used, and potentially
> break these servers, just because a package isn't being compiled anymore? It
> still works, and it works very well. It has less overhead than php-fpm, even!
>
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 numbers from a reputable source(*).
(*) Preferably for sites that actually are more than
On Wed, Jun 17, 2020 at 5:41 AM Igor Raits
wrote:
>
> %if (0%{?rhel} && 0%{?rhel}) <= 8 || (0%{?fedora} && 0%{?fedora} <= 32)
>
Yes, I have written such spec file lines, and while
they are correct, they tend to be ugly to parse for
humans.
While I know it is personal preference, I tend to
On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
>
I am in favor of the intention that when you upgrade,
those packages from previous releases
On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton wrote:
> == Summary ==
> %cmake macro will be adjusted (-B parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro).
While there is certainly no requirement for different
distributions to work the same, as I
On Fri, Jun 26, 2020 at 2:46 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault
>
A few claims (without justification):
There is no "average" Fedora user.
There is no "average" Fedora system.
There is also no "average" workload on the
(non) average system (some
On Tue, Jun 9, 2020 at 9:42 PM TI_Eugene wrote:
>
> What's happened with koji?
Koji has a scheduled outage due to the
(well) documented datacenter move. At
any single point the services will be in
"interesting" operational modes.
___
devel mailing
On Sun, Dec 27, 2020 at 3:12 PM Matthew Miller wrote:
> It's been talked about before but no one has done it.
There was also smolt, which collected some
system information (and could be extended
to collect more) However, not only did the
upstream die, follow-on proposals never
took off, and
On Tue, Dec 15, 2020 at 11:45 PM Adam Williamson
wrote:
> I wrote in the update that in my opinion the solution for this bug
> can't involve expecting add-ons to suddenly get re-signed en masse, or
> users to change their local configuration. It needs to keep working as
> it did before. If the
On Thu, Dec 3, 2020 at 3:08 PM Fabio Valentini wrote:
> Is there a reason why "main" is proposed instead of "rawhide" on src.fp.o?
Aligning as much as possible with what appears
to be the industry consensus ("main") makes sense
to me, as I will be able to (re)train my finger muscle
memory in
On Thu, Dec 3, 2020 at 3:39 PM Fabio Valentini wrote:
> I still think a lot of those are "false positives".
> CMake has a hard Requires on make, so if I BuildRequires cmake, adding
> "BuildRequires: make" is just redundant.
> https://src.fedoraproject.org/rpms/cmake/blob/master/f/cmake.spec#_185
On Fri, Dec 4, 2020 at 12:55 PM Miro Hrončok wrote:
> For what's it worth I think that packages that only use make via cmake should
> not have an explcit dependency on make. Packages that use make directly should
> have an explicit dependency on make (even if they already BR cmake).
Does that
On Fri, Dec 4, 2020 at 9:24 PM DJ Delorie wrote:
> But fedoras aren't made of sheets of main, they're made from sheets of
> rawhide...
Actually, fedoras can be made from many different
source materials (straw, cotton, hemp, etc.) in
addition to rawhide.
There are some workflows such that I
On Tue, Nov 24, 2020 at 8:11 PM Ben Cotton wrote:
> Rename `libusb` to `libusb-compat`
It was my recollection that I thought lib-compat package
naming was deprecated in favor of lib1 package
naming (or lib_1 if the last X was a number)
for a .1 soname example.
On Tue, Nov 24, 2020 at 8:05 PM Neal Gompa wrote:
> But that said, I would like to backport all the packaging changes to
> Fedora 33 too. It's not actually *hard* to do, it's just a matter of
> getting everyone to agree to get it to happen.
I think that being able to easily install/revert and
On Wed, Dec 9, 2020 at 4:52 PM Adam Williamson
wrote:
> For some folks / maintenance styles this might still be an issue, but
> it should work OK in quite a lot of cases. It's not like you're running
> Rawhide.
For those that want the equivalent of a point release,
I would think they should be
On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel
wrote:
>
> Maybe Fedora should add 2FA support and require it for the most powerful
> groups?
>
It does support it, but AFAIK does not require it.
Arguably those with elevated access (provenpackagers(*))
should be required to use a
On Mon, Dec 21, 2020 at 7:25 PM Richard Shaw wrote:
> I would say so...
>
> $ dmesg | grep -c audit
> 767
>
> $ dmesg | grep -cv audit
> 30
>
You will likely have to share some of the audit
entries.
That last time I recall seeing so many audit entries
in dmesg I had set selinux to be
On Wed, Dec 23, 2020 at 8:43 PM Matthew Miller wrote:
> I'm not in favor of that -- I think it's generally not the best policy
Correct, that is what FIDO2 biometrics are designed to
replace entirely. Passwords, in general, must die.
> and doesn't address the issue directly.
Agreed, as was
On Sat, Dec 5, 2020 at 6:24 PM Kevin Fenzi wrote:
> I'm a bit torn by this. The rawhide report has actually triggered
> conversation (less than 3 weeks ago) and I find it usefull to point out
> things.
I also find the rawhide reports (at least occasionally)
useful, as being the early canaries
On Mon, Dec 14, 2020 at 3:30 PM Christopher wrote:
>
> Even if people don't agree that "main" is better for other reasons, surely
> people can agree that "rawhide" is much better than "master"
I disagree, my opinion is that main is better than
master, and master is better than rawhide.
One
On Mon, Dec 14, 2020 at 9:49 PM Mauro Carvalho Chehab
wrote:
> # dnf swap pulseaudio pipewire-pulseaudio --allowerasing
I needed to add --enablerepo=updates-testing
Also, you may need to (as yourself) perform a
$ systemctl --user enable pipewire pipewire-pulse
In limited testing it
On Mon, Nov 9, 2020 at 9:04 PM Sérgio Basto wrote:
> Like tftp we may replace xinetd by systemd service files [1] ,
> if we replace cvs-inetd by a systemd service, the problem is solved.
I am pretty sure cvs already ships systemd service files.
The issue is that there is also a sub-package
On Wed, Nov 11, 2020 at 3:01 PM Chris Adams wrote:
> Are there replacements for the old services built in to xinetd?
Not that I know of as being integrated, although
writing such servers (often in perl) can often be
seen in training materials about network socket
programming in a few dozen
On Mon, Nov 9, 2020 at 3:15 PM Tom Hughes via devel
wrote:
> Well that's a packaging issue so it's not something that
> would normally go upstream, or does upstream have a spec
> file that you are using?
For this package there are upstream (prototype) spec files
in the repo.
I don't know
On Mon, Nov 2, 2020 at 9:36 PM Nico Kadel-Garcia wrote:
> So, use "chrony" instead?
For some use cases, there is also the option of
systemd-timesyncd as a ntp client.
> Is the functionality sufficient
As always, given the different use cases, the answer
is maybe.
Here is a quick comparison:
On Wed, Nov 4, 2020 at 7:15 PM Neal Gompa wrote:
> When did this happen? CMake should not be requiring Make at runtime,
> especially now that the CMake macros let you trivially use either Make
> or Ninja.
rhbz#1862014
___
devel mailing list --
On Wed, Nov 4, 2020 at 6:50 PM Richard Shaw wrote:
>
> Is the expectation to explicitly BR: make?
>
> Or would pulling in autotools/automake/cmake suffice?
The cmake package currently requires make. I do
not believe the auto packages requires make,
so you would need to add make explicitly
On Wed, Nov 4, 2020 at 8:48 AM Petr Lautrbach wrote:
> As none of packages which require either libsepol or libsemanage use dropped
> symbols and in order not to break build root during soname bumps I've added
> temporary
> subpackages with original library versions - libsepol-compat with
>
On Thu, Nov 5, 2020 at 3:44 PM Robbie Harwood wrote:
>
> Ben Cotton writes:
> >
> > The spec file updates will be automated and changes will be pushed
> > directly to dist-git once they are ready.
>
> -1. I think you should use pull requests for this, and continue to
> believe that mass-pushing
On Thu, Oct 29, 2020 at 10:49 PM Barry wrote:
> After the trauma of the 3.0 release it would be mad to do a python 4.0 for
> such a trivial reason as packagers that assumed, wrongly, that version can
> only have single digits.
And/or codes did character comparisons on version values.
I
On Tue, Jan 5, 2021 at 3:46 PM Florian Weimer wrote:
> The metadata would also be much larger, and so would be the battery
> usage to recompress the payload. 8-(
And while the bandwidth reduction has value,
cpu and wallclock time to rebuild the rpm is
substantially increased for low end devices
On Fri, Jan 22, 2021 at 3:39 AM Andrew Toskin wrote:
>
> Is there a ballpark estimate on when we'll switch to the new account system?
>
When it is ready? (that is a joke, mostly).
Late last February there was a post from the
CPE AAA team with a status update on the
project, which had a
On Fri, Jan 22, 2021 at 9:54 AM Miro Hrončok wrote:
> OTOH many Fedora systems use the FAS name as an identifier so even if the
> account system supports this, it will confuse badges, etc.
I do not recall the various related dependency status,
but I am pretty sure the case of badges was
On Fri, Jan 22, 2021 at 5:37 PM Kevin Fenzi wrote:
> Soon. We have staging pretty close to all working, so I would expect
> sometime in the next weeks. We will announce deployment plans as we make
> them.
Excellent news! Do let us know if/how we can
help by testing (no change in AAA systems
On Tue, Jun 15, 2021 at 9:55 PM Neal Gompa wrote:
> Yeah, I think that proposal was not workable because of AVX2. The
> x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
> current x86_64 baseline. All of these instructions were present in the
> first Intel Macs launched in
On Wed, May 12, 2021 at 9:49 AM Евгений Пивнев wrote:
>
> Is there any real package .spec that use cc-toolset-9 as example?
> SCL documentation is too extensive and mostly about creating new SCL,
> I cannot find short description how simply to make one new package using
> modern C++.
>
Not sure
On Fri, May 28, 2021 at 4:42 PM PGNet Dev wrote:
> I'd bet $0.05 and a half-eaten donut that most folks
*Most* folks are not the deciders. The deciders
(for their particular projects) have decided,
presumably based on what they believe is best
for their community. In this case, for
On Wed, Jul 7, 2021 at 8:23 AM Vitaly Zaitsev via devel
wrote:
>
> On 06/07/2021 23:27, Christian Stadelmann wrote:
> > In other words: I think it is too early to drop non-(U)EFI BIOS support.
>
> Btw, the upcoming Windows 11 will require full UEFI support, enabled
> UEFI Secure Boot and TPM 2.0.
On Wed, Jun 23, 2021 at 8:58 AM Nico Kadel-Garcia wrote:
> I can't find *anyone* who likes modularity.
I like the concept of modules. But primarily
only if someone else is doing the actual
hard work that ends up being necessary
to build them.
___
On Thu, Jul 1, 2021 at 8:57 AM Miroslav Suchý wrote:
> Hmm, this should be easy to implement. Just one wiki page. I created:
>
> https://fedoraproject.org/wiki/Packagers_for_hire
>
> Comments?
Rather than a wiki for which people may not
reliably curate (i.e. remove themselves) or
respond to
On Mon, Jul 12, 2021 at 12:54 AM Jakub Kadlcik wrote:
> I am happy to announce that I deployed this little site
> https://docs.pagure.org/fedora-sponsors/
Thank you for doing this. Anything that reduces
the impedance for new people is overwhelming
a good thing.
It is easy for forget
On Fri, Apr 30, 2021 at 5:18 PM Vitaly Zaitsev via devel
wrote:
>
> On 30.04.2021 16:23, Richard W.M. Jones wrote:
> > Because distributing SSH keys to temporary VMs is hard?
>
> Kickstart + Ansible will fix all these issues.
Or, perhaps, cloud-init, for those using that approach.
On Fri, Apr 23, 2021 at 3:19 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/CompilerPolicy
>
Ultimately, I think what the packaging guidelines should be if
the proposal is accepted are essentially:
For C/C++ projects:
If the upstream has no stated preference for the
On Fri, Apr 23, 2021 at 3:30 PM Ben Cotton wrote:
> Or is it just a way of saying "we trust you to exercise good judgment"?
If one does not trust the packagers good
judgement you likely have a bigger
issue to address.
I doubt many packagers are going to
change from the default compiler
unless
On Fri, Apr 23, 2021 at 3:57 PM Daniel P. Berrangé wrote:
> This is quite a niche problem that's unlikely to cause issues
> for most people, but its a illustration that swapping compilers
> out can have unexpected consequences/complications.
Presuming I am remembering my s390x history
On Fri, Apr 23, 2021 at 3:38 PM Neal Gompa wrote:
> To me, this sounds like an excuse to avoid doing the right thing and
> leveraging the toolchain that offers the highest quality code
> generation (performance, security, etc.).
I am not in favor of switching the distro (or any
package) to the
On Tue, Mar 30, 2021 at 6:18 PM Zbigniew Jędrzejewski-Szmek
wrote:
> There is no good way to do this.
This is one of those cases where I occasionally
miss a mainframe fix update feature to prevent
certain bad automated results.
In SMP/E, there was the concept of HOLD's for
a fix. There were a
On Fri, Apr 16, 2021 at 4:31 PM David Cantrell wrote:
> 2) I'm curious why GDBM was chosen instead of something like sqlite.
I believe sasldb only supports gdbm and
ndbm as alternatives to bdb.
___
devel mailing list -- devel@lists.fedoraproject.org
On Mon, Feb 15, 2021 at 6:39 PM Dan Horák wrote:
> The open question still is whether we should try to keep 64k as default
> as it would allow to find the remaining bugs and offer 4k kernel variant
> (COPR for ppc64le should be coming back soon), similar for the
> installer (a new remix/spin).
On Sat, Feb 13, 2021 at 1:10 AM Kevin Kofler via devel
wrote:
>
> Kevin Kofler via devel wrote:
> > And why would I want to do Red Hat's / IBM's work for free?
> >
> > Contributing to Fedora provides value to me because I use Fedora myself.
> > In contrast, what would I gain from contributing to
On Wed, Sep 15, 2021 at 9:40 PM Fabio Valentini wrote:
> Thanks, that did the trick.
> But of course somebody built stuff during the side-tag window and now
> it can't be pushed. *le big sigh*
This seems to happen every time there is a
large(ish) side-tag. I do wish that (probably
using a
On Wed, Jul 28, 2021 at 5:28 PM Vitaly Zaitsev via devel
wrote:
>
> On 28/07/2021 15:07, Ben Cotton wrote:
> > Updates of user services take effect immediately (if so configured in
> > the providing packages).
>
> Restarting plasma-ksmserver.service, plasma-kwin_x11.service, etc. will
> cause a
On Mon, Oct 4, 2021 at 11:08 PM Gary Buhrmaster
wrote:
>
> On Mon, Oct 4, 2021 at 10:21 PM Peter Robinson wrote:
>
> > I was going to ask people if they
> > were interested in them but I decided to straight up orphan them so
> > they#ll can go through the usual garbag
On Mon, Oct 4, 2021 at 10:21 PM Peter Robinson wrote:
> I was going to ask people if they
> were interested in them but I decided to straight up orphan them so
> they#ll can go through the usual garbage collection process unless
> someone claims them.
> libcec
> platform
I'll volunteer to take
On Tue, Oct 5, 2021 at 12:21 AM Sérgio Basto wrote:
> I wonder if kodi shouldn't use cec from kernel [1] instead libcec
Perhaps, perhaps not. The recent libcec
for Linux uses the kernel functionality, but
(mostly) maintains the existing API. So
for an application which is trying to be
cross
On Mon, Oct 4, 2021 at 8:58 AM Vít Ondruch wrote:
> Thoughts?
Anything that improves the onboarding
process can only be a good thing.
I would recommend that before going
too deep into weeds that you need a
small group of "non-packagers"(*) to
see if this is the right approach from
their
On Mon, Nov 29, 2021, 10:06 Michael Catanzaro wrote:
> Hi, I have a question for the FESCo and Council candidates: do you
> support allowing Fedora src-git repositories to be hosted on
> gitlab.com, which a proprietary software git forge?
>
One should have proposed such a question
during the
On Mon, Nov 29, 2021 at 7:05 PM Matthew Miller wrote:
> I mean... that would have been a good way to make sure everyone at least
> provided some answer, but I don't think we have (or should have) any rule
> against asking FESCo or Council people questions at other times.
I think asking FESCo or
Now that CentOS Stream 9 is announced as
available, is there a schedule for when EPEL-9
branches can be made, and when one can
(start to) ask others to build for EPEL-9
(it would be nice if a number of the EPEL-9
packages were preliminarily ready at the time
of the EL-9 formal release (just,
On Sat, Dec 25, 2021 at 8:16 PM Fabio Valentini wrote:
> (the community blog might be the right place for some of those,
> but it is a higher barrier to actually write a blog post that gets
> edited etc. instead of writing an e-mail to a mailing list).
The Fedora Community Blog and the Fedora
On Wed, Dec 22, 2021 at 11:56 PM Jakub Kadlčík wrote:
> TL;DR What about a place where people could ask for something to be
> packaged in Fedora?
There is https://fedoraproject.org/wiki/Package_maintainers_wishlist
___
devel mailing list --
On Tue, Jan 4, 2022 at 10:09 AM Florian Weimer wrote:
>
> Or is it still banned in Fedora?
>
> We have some scripts that are dual Python 2/Python 3, and Fedora tooling
> forced us to carry a downstream-only patch to replace /usr/bin/python
> with /usr/bin/python3. I'd like to remove this patch.
On Thu, Nov 18, 2021 at 2:32 AM Josh Stone wrote:
>
> On 11/16/21 7:05 PM, Kevin Kofler via devel wrote:
> > Realistically, they will just stick to Fedora 36 forever and just stop
> > updating the devices (or try updating them anyway and get no updates from
> > the server, obviously).
> >
> >
On Thu, Nov 18, 2021 at 11:10 PM Arthur Bols wrote:
>
> Hi,
>
> Does anyone know if Seth Jennings (sjenning) is stil active in Fedora? I
> sent him an email in June without response.
> The package pam-u2f has been outdated for a while and I've created the
> non-responsive maintainer bug [1].
On Mon, Nov 15, 2021 at 7:16 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/RetireARMv7
>
I cannot recall the last time I tried to run a full armv7 desktop
(which, I would guess, generate a significant percentage of
the large app build failures since the "desktop" apps are,
On Thu, Nov 11, 2021 at 2:55 PM Miro Hrončok wrote:
>
> Hello,
>
> Since this update:
>
> https://src.fedoraproject.org/rpms/libnsl2/c/d2e2fab5e3ab07228a34f35ab8ec1954581153d0?branch=rawhide
>
> Nothing in rawhide builds, because Python and hence dnf is not installable:
>
Is it possible to
On Thu, Nov 25, 2021 at 8:05 AM Miroslav Suchý wrote:
> I wrote down the possible options and their pros and cons and I done my best
> to catch all the feedback here.
Thanks.
Another idea occurred to me, similar to "D"
(use alternatives) and incorporates "A" (delete
the current epel-8) for
On Mon, Nov 22, 2021 at 2:01 PM Pavel Raiskup wrote:
> First I don't feel comfortable announcing this, I'm not happy about the
> situation and so I don't want to be the lightning rod :-).
I do not believe anyone should blame you for bringing
this up (although, it should be noted, killing the
On Tue, Nov 2, 2021 at 7:30 PM Adam Williamson
wrote:
> Further to this .
Thanks for the report on your research.
When there are enough fragile moving parts,
sooner or later something goes sideways
___
devel mailing list --
On Tue, Nov 9, 2021 at 8:42 AM Aleksei Bavshin
wrote:
> A module can load a firmware binary with the `request_firmware` API at
> any moment of it's lifetime. Usually, this happens when the module is
> initialized or discovers a new supported device, but I don't believe
> that is a strictly
On Sun, Nov 7, 2021 at 2:22 AM Demi Marie Obenour wrote:
> I have almost always seen it *increase* download times,
In my experience, while the download times may
be (slightly) reduced, on a number of my (slower)
systems, the rebuild of the rpm itself took longer
then it would have taken to
1 - 100 of 334 matches
Mail list logo
