On Wed, May 25, 2022 at 8:49 AM Miroslav Suchý wrote:
> I think that we can assume that if
>
> git log --pretty=oneline
>
> contains `spdx` or similar string, than the spec file use the new notation.
That might work only if one required (enforced?)
that the changelog regarding any spdx change
On Thu, May 26, 2022 at 2:27 PM Neal Gompa wrote:
> At least in the MIT license case, the MIT identifier exists there. One
> reason Tom Callaway resisted changing to SPDX in the past was that
> they never resolved the problem with the MIT identifier. It's
> effectively a family identifier, just l
On Thu, May 26, 2022 at 7:16 PM Kevin P. Fleming wrote:
> Fedora uses 'BSD' for a variety of licenses, many of which have specific
> SPDX identifiers. MIT and BSD are the most common problem areas for this
> situation.
Right, but BSD is not in SPDX, it may be BSD-2-Clause
(or BSD-3-Clause).
On Thu, May 26, 2022 at 1:52 PM Miroslav Suchý wrote:
>
> If you already upgraded to Fedora 36 - what is your feedback about
>
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/System_Utilities/#remove-retired-packages
>
> Did you run the command `remove-retired-packages`
On Sun, Jun 5, 2022 at 8:37 AM Neal Gompa wrote:
> H.264 is supported through OpenH264, and H.265 is not a popular codec.
> Aside from Apple services (which are not available to Linux users
> anyway), nobody uses H.265 because of the patent situation with HEVC.
In the US, ATSC 3.0 TV Broadcasts
On Sun, Jun 5, 2022 at 8:33 PM Vitaly Zaitsev via devel
wrote:
>
> On 05/06/2022 10:02, Mattia Verga via devel wrote:
> > We should really start thinking about this.
>
> Yes. Patents for algorithms hinder the development of humankind.
>
> But there is nothing we can do about it, because Red Hat is
On Fri, Jun 10, 2022 at 3:37 AM Neal Gompa wrote:
> Unfortunately, this doesn't apply to decoders in the ffmpeg
> architecture. Worse, some decoders that _could_ be enabled are
> basically broken when hardware support is missing. FFmpeg does not
> correctly invalidate them as choices and the play
On Thu, Jun 16, 2022 at 9:16 PM Richard W.M. Jones wrote:
> Why is this small language bump classified as a system-wide change?
I believe it is the mass rebuild process requirement.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
On Tue, Jun 21, 2022 at 9:58 PM Scott Talbert wrote:
> Unfortunately, the Fedora notification system seems to be suffering from
> massive delays (e.g, several days) lately.
And, as I recall, due to various throttling,
gmail recipients (which the OP appears
to be) have been reported to be among
t
On Thu, Jun 23, 2022 at 6:09 PM Miro Hrončok wrote:
> That's complicated. .
And, while I am sure it could be derived,
it seems to me, as previously stated,
that the python's turn into the most
significant dependency chain.
I am all for deprecating openssl 1.1,
and for package reviews reject
On Thu, Jun 30, 2022 at 3:33 PM Vitaly Zaitsev via devel
wrote:
>
> On 30/06/2022 17:23, Michael Catanzaro wrote:
> > I do not expect Fedora Legal will likely come onto a public mailing list to
> > debate liability with you. Hopefully it should be obvious why that's not a
> > good idea. There's
On Wed, Jul 6, 2022 at 3:45 PM Zbigniew Jędrzejewski-Szmek
wrote:
> https://github.com/systemd/systemd/pull/23924 proposes adding
> SUPPORT_END=-MM-DD to /usr/lib/os-release.
I like the concept, but
(warning, taxonomy discussion)
The announcement for os-release included
the followi
On Mon, Jul 18, 2022 at 6:44 AM Petr Lautrbach wrote:
>
> Dan Čermák writes:
> >
> > Just out of curiosity, how large is the speedup typically?
> >
>
> It depends on the number of threads your machine has. But you could get some
> data for comparison using `fixfiles -T 1 restore` and `fixfiles -
On Fri, Jul 15, 2022 at 9:50 PM Ben Cotton wrote:
> The current minimum at zEC12 is
> targeting hardware that has been already obsoleted by the vendor.
As I understand it, while zEC12 is EOL (you can no longer
purchase it), it is not (yet) EOS, so existing systems can
still obtain service from I
On Wed, Jul 27, 2022 at 12:12 PM Vitaly Zaitsev via devel
wrote:
>
> On 26/07/2022 20:05, Chris Murphy wrote:
> > Thoughts?
>
> e. Switch from GRUB 2 to systemd-boot for the UEFI installations.
Making it easier to choose to install systemd-boot
rather than grub (including signing systemd-boot)
at
On Sat, Aug 6, 2022 at 11:21 AM Kevin Kofler via devel
wrote:
> But then fdk-aac-free is also not allowed in Fedora and should be removed:
> https://fedoraproject.org/wiki/Licensing/FDK-AAC
I have this (very vague) recollection that the
fdk-aac-free package had the patented
algorithm sources str
On Sat, Aug 6, 2022, 10:35 AM Richard Fontana wrote:
> [re FDK-AAC, which has a no-patent-licenses clause]
>
> > That is correct. The clause is considered a no-op and the license
> > isn't approved for use outside of this case.
>
> I think it is correct to bring FDK-AAC up in this discussion.
I
On Thu, Aug 18, 2022 at 9:34 PM Ben Cotton wrote:
> Since this is the first time we've done something like this, it could
> be a little rough.
While I fully expect that this first time is going to be
somewhat "special", I agree with the intent of the
policy, and believe it will result in better
On Fri, Aug 19, 2022 at 10:47 AM P J P wrote:
> * Interesting numbers there.
(see below on another number)
> * While I get that such pruning from time to time is generally good.
> What happens to the packages orphaned by removing inactive packagers?
>
> * Removing orphaned packages may not be
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 determin
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 ef
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 recall
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: h
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
> lib
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 there.
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 -- devel@li
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 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 enough
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 buil
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 lines
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 ru
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 the
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 me
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 have
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 a
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 shou
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 seems
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 fo
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 permissive
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 hardw
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 sta
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 als
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 po
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 t
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 -- devel@lists.fedoraproj
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 packag
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 ou
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 runt
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 added
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 i
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 no
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) varian
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 consid
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 can
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 speci
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 -- devel@lists
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 Mag
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 Fri, Jan 21, 2022 at 3:27 PM Vít Ondruch wrote:
> Isn't it just the standard GMail deduplication?
Likely. For better or worse, that is the way gmail works.
One can see both the advantages and disadvantages
of the gmail approach, but it does catch some of the
people off-guard at least some o
On Tue, Feb 1, 2022 at 9:27 PM Richard Shaw wrote:
>
> I just did a local mock build of the latest version of OpenImageIO which was
> just released and saw this on every cpp line:
>
> annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp:
> Warning: -D_GLIBCXX_ASSERTIONS not
On Fri, Feb 4, 2022 at 11:32 AM Ian McInerney via devel
wrote:
> From a user experience perspective, the mirror lag time on it is very
> annoying. When the update is pushed to testing, Bodhi posts a comment in the
> associated Bugzilla saying that you should "soon" be able to install the
> upd
On Sat, Feb 5, 2022 at 9:04 PM Kevin Fenzi wrote:
> Well, it's not any specific timeframe we can promise here.
Of course not. But it is clearly not "soon".
> Take a look at:
> https://admin.fedoraproject.org/mirrormanager/propagation
>
> You can see the two days recently we got rawhide compose
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel
wrote:
> That is referring to provenpackagers only. I'd like this to be extended
> to users in packagers group also.
Given that provenpackagers are group
that can do the most potential damage,
that process arguably covers the users
in the tru
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel
wrote:
> That is referring to provenpackagers only. I'd like this to be extended
> to users in packagers group also.
FWIW, the last time this came up, there was
a vague idea to require a yearly resigning
of the CLA (or something equivalent,
On Thu, Feb 10, 2022 at 9:58 PM Ben Cotton wrote:
> I have concerns with this approach. I would guess there's a long tail
> of packagers that maintain relatively few packages. These packages
> might not have frequent upstream releases or require new manual
> builds.
There are a lot of packages i
On Fri, Feb 11, 2022 at 10:43 AM Ian McInerney via devel
wrote:
>
> On Fri, Feb 11, 2022 at 10:39 AM Björn Persson wrote:
>>
>> Yes, that's a bad search. Till Maas told me eight years ago that the
>> release monitoring tickets are supposed to remain open when the
>> packages are upgraded. Thus an
On Sun, Feb 20, 2022 at 4:01 PM Demi Marie Obenour
wrote:
> I think we should also require security key-based 2fa for all
> packagers.
In a previous discussion on this topic that was
suggested (and at least partially rejected(*)).
Many (larger) orgs have decided that issuing
hardware security k
On Sun, Feb 20, 2022, 16:09 Adam Williamson
wrote:
> It used to support these, but the support was lost with the recent
> rewrite. However, it supports Google Authenticator-style OTPs. Folks
> with infra privileges on their accounts (like me) are already required
> to use these. It works fine. I
On Mon, Feb 21, 2022 at 8:35 AM Alexander Bokovoy wrote:
> This is not ready for general consumption but we plan to have something
> to submit to Rawhide in a month or so. Enrolling IPA users into this
> would be similar to already existing RADIUS proxy authentication path in
> FreeIPA.
Excellen
On Tue, Feb 22, 2022 at 5:43 PM Zbigniew Jędrzejewski-Szmek
wrote:
> No, no. dnf-makecache.timer is "asynchronous" — it is not part of
> multi-user.target. It is reasonable to order it after network is up
> because this way it can just do its thing without spurious noise about
> failed connection
On Tue, Feb 22, 2022 at 5:42 PM Chris Murphy wrote:
> $ cat /usr/lib/systemd/system/packagekit.service
> [Unit]
> Description=PackageKit Daemon
> # PK doesn't know how to do anything on ostree-managed systems;
> # currently the design is to have dedicated daemons like
> # eos-updater and rpm-ostr
On Tue, Feb 22, 2022 at 9:54 PM Kevin Fenzi wrote:
> I don't think there's any way in IPA to require otp as a requirement for
> group membership currently. (Please let me know if there is).
> Which would leave us checking after the fact and removing people without
> one set, which is a big pile o
On Mon, Feb 21, 2022 at 7:17 PM Vitaly Zaitsev via devel
wrote:
> OTP is absolutely free. FIDO2 requires the purchase of a special
> hardware token.
Not necessarily. Not only can some mobile devices
present the needed credentials (as if they were an
external hardware token), but as I recall U2F
On Wed, Feb 23, 2022 at 11:55 PM Chris Adams wrote:
>
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > So this is the culprit. iscsi.service has Before=remote-fs-pre.target,
> > After=network-online.target, which means that it'll delay the boot.
>
> If that's the problem, there's some ot
On Thu, Feb 24, 2022 at 12:56 AM Chris Murphy wrote:
> And my understanding is it's required for
> Windows 11 preinstallations.
Except if your country has required that TPM not
be used, and as Microsoft did not want to prevent
billions of people from using Windows 11 those
locations are exempt f
On Fri, Feb 25, 2022 at 5:42 PM Ron Olson wrote:
> I guess there was some CPU requirement change that I didn’t catch;
https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
discussed the issue(s), and the x86_64 v2 requirement
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 serve
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 perspec
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 pl
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 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 -- devel@lists.fedorap
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 downl
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 enforc
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 auto
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,
well,
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).
> >
> > Stic
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]. There
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 mes
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 the
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 per
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, perhap
On Sun, Dec 5, 2021 at 4:09 AM Kevin Fenzi wrote:
> yes, yesterday.
>
> See the announcement:
> https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/5UJSW3FBGQMLXWWV7BGHWZTOFLH4NH3G/
*sigh*. Sorry, I missed it (I think I need to
add yet another mail list to
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 referen
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 actually
201 - 300 of 399 matches
Mail list logo
