Ben Cotton writes:
> https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by
Michal Schorm writes:
> On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood wrote:
>>> Would you see a value in e.g. some kind of a robot reminding
>>> maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
>>> check)
>>
>> Please don't.
>
Michal Schorm writes:
> While playing around with Sourcegraph, which indexed all Fedora
> package repositories, I was able to craft a query listing all '%if'
> conditionals referencing Fedora releases that reached EOL.
>
> Do you agree it would be safe to remove such conditionals and the code
>
"Colin Walters" writes:
> On Tue, Nov 15, 2022, at 12:00 PM, Robbie Harwood wrote:
>
>> If your model doesn't permit the system to cease execution during
>> bootloader updates, then I'm not sure why you need bootupd at all -
>> traditional RPM updating wil
Timothée Ravier writes:
>> Bootloaders are not single files. Consider UEFI:
>>
>> For grub2, there's both a .efi and some configuration that I'll handwave
>> for purposes of this conversation. For shim, it's more like 4 things -
>> the main shim*64.efi, fallback.efi, boot.efi, and boot.csv.
Timothée Ravier writes:
>> As we've talked about before, it's not possible to make updates
>> transactional. It involves, per spec and depending on processor
>> architecture, updating multiple files in different directories,
>> potentially on different filesystems entirely, one of which is
Ben Cotton writes:
> By design, ostree does not manage bootloader updates as they can not
> (yet) happen in a transactional, atomic and safe fashion.
As we've talked about before, it's not possible to make updates
transactional. It involves, per spec and depending on processor
architecture,
Daniel P. Berrangé writes:
> We need PCRs to cover at minimum
>
> 1. Machine firmware
> 2. Bootloader(s)
> 3. Bootloader configuration
> 4. Booted kernel
> 5. Booted initrd
> 6. Booted cmdline
> Item 5 and 6 are a problem, because as mentioned thse are not signed
> by the OS vendor
Daniel P. Berrangé writes:
> The way grub has to write its entire grub.conf into the TPM PCRs is
> totally impractical for anyone wishing to maintain attestation
> policies to verify the OS boot state from the TPM eventlog.
So this has been mentioned in several places, but no one in grub
Adam Williamson writes:
> For background here, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=2049849
>
> right now, when installing Fedora alongside a Windows install with
> BitLocker enabled, trying to boot Windows from the Fedora boot menu
> does not work.
>
> We waived the bug as a
Maxwell G via devel writes:
> I believe Miro uses this for the FTI bugs. It tends to be more accurate,
> especially when there hasn't been a compose for a couple days. If this
> is something people are interested in, I think it's worthwhile to
> include this repo definition in fedora-packager.
Lennart Poettering writes:
> On Di, 05.07.22 01:44, Fedora Development ML (devel@lists.fedoraproject.org)
> wrote:
>
>> Also, if users have "special" hardware, shouldn't they also have
>> security.
>
> if you need a special kernel cmdline to get your system to boot, then
> that's a bug in the
Charalampos Stratakis writes:
> So I presume then that python2.7 in Debian works flawlessly with
> OpenSSL 3.0.0, no regressions, no security issues and no ABI problems
> right?
I'm hearing hostility from you and I don't know why. From your sarcasm,
I take it to mean that no, you haven't
Charalampos Stratakis writes:
> Unfortunately that effort is moot, it's really not possible to make
> python2.7 compatible with OpenSSL 3.0.0, I mean even the latest Python
> versions are not 100% compatible for various reasons.
>
> In trying to make it compatible there are also ABI changes
Vitaly Zaitsev via devel writes:
> On 29/06/2022 01:18, Maxwell G via devel wrote:
>
>> You might also be interested in the Stalled EPEL Requests
>> policy[1]. This would've allowed you to get permissions to branch the
>> package for EPEL without going through the non-responsive maintainer
>>
Maxwell G via devel writes:
> On Tuesday, June 28, 2022 4:30:14 PM CDT Robbie Harwood wrote:
>> I have started the responsive maintainer process due to lack of contact
>> through bugzilla mail. Specifically, this is about an epel9 branch,
>> which has been repeatedly
Alex Chernyakhovsky writes:
> I just replied on bugzilla. No one has attempted to contact me before.
Well... as a Fedora maintainer, there's an expectation that you'll read
your bugzilla email from time to time :) I know stuff happens, and from
your bz comment it sounds like there was some
Hi Alex + Fedora,
I'm trying to contact Alex Chernyakhovsky, the maintainer of mosh. Does
anyone know how to contact them?
I have started the responsive maintainer process due to lack of contact
through bugzilla mail. Specifically, this is about an epel9 branch,
which has been repeatedly
> Demi Marie Obenour wrote:
>> On 6/25/22 07:56, Roberto Ragusa wrote:
>>> On 6/19/22 22:54, Sharpened Blade via devel wrote:
>>>
Use unified kernel images by default for new releases. This can
allow for the local installation to sign the kernel and the initrd,
so the boot chain
Neal Gompa writes:
> I think people assume we do more with the License tag than we actually
> do.
I think this is correct.
> We have no active automated auditing or validation of package license
> tags at this time.
And this is not.
rpminspect is run on every bodhi update. It contains a
Ben Cotton writes:
> https://fedoraproject.org/wiki/Changes/BIOSBootISOWithGrub2
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by
Ben Cotton writes:
> :Don’t prepend a potentially unsafe path to `sys.path`:
If this is a safety/security issue, why not just make it the default for
python itself?
Be well,
--Robbie
signature.asc
Description: PGP signature
___
devel mailing list
Alexander Sosedkin writes:
> crypto-policies' goal is to define system-wide *defaults*.
Well, that's certainly part of it, but...
"The purpose is to unify the crypto policies used by different
applications and libraries. That is allow setting a consistent security
level for crypto on all
JT writes:
>> IMO, there's a rather desperate need to be able to override the
>> system-wide policy for individual processes, maybe via some sort of
>> wrapper around one of the containerization technologies.
>
> Alternatively I wouldn't be surprised if at some point the industry
> doesn't
Hans de Goede writes:
> What I envision for the SIG is:
>
> 1. I'm not sure if it is possible to setup group ownership
> of pkgs in pagure? So to keep things simple the few packages which
> are only necessary for BIOS boot can be handed over to me and then
> I'll just add other people willing to
Hans de Goede writes:
> On 4/13/22 21:27, David Cantrell wrote:
>
>> OK, given this proposal, I'd like the original change proposal
>> amended to essentially say "transfer legacy BIOS boot support to
>> newly formed Legacy BIOS SIG" or something like that. The logistics
>> at that point can be
Neal Gompa writes:
> Alright, I'll bite. I am within my rights to propose any Change I want
> for Fedora Cloud, which I help steward with David Duncan.
As, presumably, is anyone else?
> As an aside, I examined the state of all release blocking Fedora
> deliverables, and something I noticed is
Neal Gompa writes:
> Windows is a niche in the server space, rather than the default
That may be true for many workloads, but I doubt it's true in all cases
- Active Directory has a huge footprint, for instance, and Linux is not
"the default" for identity services.
Be well,
--Robbie
Michel Alexandre Salim writes:
> - as I stated, there are offers to help with getting syslinux replaced
> with GRUB
More generally, I'm concerned that folks think this'll help a lot more
than it actually will. There's a tendency to think in terms of packages
- they're contained units and
Michel Alexandre Salim writes:
> - as I stated, there are offers to help with getting syslinux replaced
> with GRUB. what I've not stated originally is Chris Murphy brought up
> protective MBR and switching all new installs to inst.gpt, which let
> us future proof new installations for
Michel Alexandre Salim writes:
> Would using Grub for legacy boot be more, or less work than continuing
> to support syslinux, assuming people step up to do the development and
> validation?
syslinux is by default only used on the live media. Legacy installs
today provision grub2. So moving
Vitaly Zaitsev via devel writes:
> On 07/04/2022 18:10, Robbie Harwood wrote:
>
>> While we do maintain a large set of patches downstream, due to upstream
>> being inactive for a while, today upstream is alive and very much not
>> abandoned:
>
> Why not upstream all
David Duncan writes:
> it also appears that issues have prevented direct contribution based
> on some sort of misconfiguration in the repository, though it sounds
> like this is fixed as of this discussion. It still speaks to more than
> a year of complication in contribution. Is Neal really the
Michael Catanzaro writes:
> On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez
> wrote:
>> This seems like a strong assumption to me considering that aside from
>> the largest cloud providers (with whom Red Hat is directly working
>> with on UEFI boot features and bug reports), cloud
Robert Marcano via devel writes:
> Is this change only related to install media support for booting with
> BIOS only? Would I be able to install newer Fedora releases using Legacy
> PXE on BIOS only machines?
The intent is to indicate that new legacy installations are not
supported,
Vitaly Zaitsev via devel writes:
> On 07/04/2022 10:43, Lennart Poettering wrote:
>> Do you think the user experience with grub was*good*? Turing complete
>> language? Scripts that generate scripts that generate scripts?
>
> +1. Current GRUB2 is a collection of hacks. Even the upstream abandoned
Demi Marie Obenour writes:
> On 4/6/22 16:59, Robbie Harwood wrote:
>> Demi Marie Obenour writes:
>>
>>> On 4/5/22 12:29, Michael Catanzaro wrote:
>>>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood
>>>> wrote:
>>>>>
Demi Marie Obenour writes:
> On 4/6/22 06:43, Neal Gompa wrote:
>> On Wed, Apr 6, 2022 at 12:04 AM Gary Buhrmaster
>> wrote:
>>>
>>> On Wed, Apr 6, 2022 at 12:59 AM Demi Marie Obenour
>>> wrote:
On 4/5/22 19:38, Chris Murphy wrote:
> We either want users with NVIDIA hardware to
Dominik 'Rathann' Mierzejewski writes:
> On Wednesday, 06 April 2022 at 13:07, Richard Hughes wrote:
>> Dominik 'Rathann' Mierzejewski wrote:
>>
and on its way out. As it ages, maintainability has decreased, and
the status quo of maintaining both stacks in perpetuity is not viable
Demi Marie Obenour writes:
> On 4/5/22 12:29, Michael Catanzaro wrote:
>> On Tue, Apr 5 2022 at 11:56:07 AM -0400, Robbie Harwood
>> wrote:
>>> Users wishing to use NVIDIA hardware have the following options:
>>>
>>> - Use nouveau (free, op
Michael Catanzaro writes:
> Woah, what happened here? Why would any Fedora package ever disable
> pull requests?
I suspect it was an accident. I can't speak to why - if my
co-maintainers know, maybe they can - but it seems possible it got
toggled while someone was looking for something else in
Neal Gompa writes:
> On Wed, Apr 6, 2022 at 10:59 AM Robbie Harwood wrote:
>> Neal Gompa writes:
>>
>>> 3. At various times, people have explicitly said "patches NOT
>>> welcome"
>>
>> I see no evidence of this having happened, and it
Neal Gompa writes:
> On Wed, Apr 6, 2022 at 7:14 AM John Boero wrote:
>>
>> I can fully understand why this would be done. As per the original
>> discussion when Peter Robinson mentioned a Spin to deprecate BIOS,
>> would anybody else be interested in helping with a Spin for legacy
>> BIOS
Chris Murphy writes:
> On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote:
>
>> Legacy BIOS support is not removed, but new non-UEFI installation is
>> not supported on those platforms. This is a first step toward
>> eventually removing legacy BIOS support entirely.
>
> What is the distinction
"Andre Robatino" writes:
> Those figures are recommended minimums, not requirements. I have a
> single core F35 machine which works fine.
It's important to note here that "works fine" isn't the same as "is
supported".
My reading of that document is that if one goes below what's laid out in
Neal Gompa writes:
> This is not a deprecation change, this is effectively a removal
> change. By removing the packages and the tooling support for legacy
> BIOS, it makes several scenarios (including recovery) harder.
> Moreover, it puts the burden on people to figure out if their hardware
>
Vít Ondruch writes:
> Maybe I don't correctly understand the "Legacy BIOS support is not
> removed, but new non-UEFI installation is not supported on those
> platforms." quoted from the the change description, but if you have your
> system installed, it should keep working. You just keep
majid hussain writes:
> hi,
> could someone kindly tell me if my toshiba l750 machine has EFI support?
> i'm blind and efi/bios screens are in accessible.
Easiest is probably to do:
ls /sys/firmware/efi
This tells you whether the machine booted using UEFI. anaconda will set
up a UEFI-capable
Chris Murphy writes:
> On Tue, Apr 5, 2022 at 8:54 AM Ben Cotton wrote:
>
>> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
>> mandates that machines must have been made after 2006).
>
> Where do we require this? I see only one location for such minimums:
>
>
PGNet Dev writes:
> Curious, has anyone from @redhat or @fedora though to actually
> communicate with any of the 'big' hosting providers, to perhaps
> coordinate/influence/compromise/plan?
>
> I'd bet AWS, DigitalOcean & Linode/Akamai -- among this biggest
> hosting providers where 'new
Tom Hughes writes:
> On 05/04/2022 18:51, Robbie Harwood wrote:
>
>> Right, you need the EFI partition (EFI System Partition, or ESP). I
>> don't remember what we default those to these days - I usually make
>> about 600M, but I need it larger for testing stuff. The
Gregory Bartholomew writes:
> But I seem to remember /boot being a separate partition for a long
> time (it used to be required because some older BOISs couldn't read
> beyond a certain sector on the disk). Could not /boot be converted to
> the ESP (i.e. reformatted with FAT32) on such systems?
Peter Boy writes:
> And I also don't understand why we should give up a hallmark of free
> Linux, namely to support old, but still good usable hardware (unlike
> commercial system, not only Windows but also e.g. RHEL).
Developers are free to support whatever systems they like. If someone
wants
Tom Hughes via devel writes:
> On 05/04/2022 15:52, Ben Cotton wrote:
>
>> * There is no migration story from Legacy BIOS to UEFI -
>> repartitioning effectively mandates a reinstall. As a result, we
>> don’t drop support for existing Legacy BIOS systems yet, just new
>> installations.
>
> This
David Duncan writes:
> For similar reasons, I agree with Neal. There are a number of Amazon
> EC2 instance types that would be left out of the next generation. I
> think it would be better to identify the usage in some way and create
> a general awareness that it is being removed prior to
Neal Gompa writes:
> By virtue of how boot stuff is handled in Fedora, the community is
> incapable of working on it.
Not true. Not at all true.
src.fedoraproject.org permits anyone, *anyone* to send PRs to fix issues
in the boot stack, or any other package. Even without it, bugzilla
doesn't
Neal Gompa writes:
> And we've still failed to get ARM and RISC-V broadly on board with
> UEFI
This statement is not correct. ARM in Fedora is UEFI-only, and we were
both in the Plumbers conversation around RISC-V's booting.
> We also lack solutions for dealing with the NVIDIA driver in
>
Kamil Dudka writes:
> On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote:
>
>> - check whether the "new object name" is descendant of
>> (contains) "old build object name" (rather than "old object name", which
>> would forbid any force push)
>> This would allow to rewrite a branch
Miro Hrončok writes:
> If that's the case, can we please stop enforcing the signed-off-by
> thing in Fedora projects (such as various Fedora projects on Pagure or
> Bodhi on GitHub)?
My understanding is that's about provenance, not licensing per se (not a
lawyer etc.). In any case it's up to
David Cantrell writes:
> Why? Since the removal of the i686 kernel in Fedora, we want to
> reduce the number of i686 packages provided in the repo. As time
> marches on, the ability to build a lot of things for i686 becomes
> unrealistic or even impossible. Remember it goes beyond providing
>
Benjamin Berg writes:
> On Wed, 2022-03-09 at 12:35 -0500, Robbie Harwood wrote:
>
>> Speaking of which, what *are* we expected to do? Aleksei on IRC
>> suggested that the preferred solution is to swap the BuildRequires to
>> pkgconfig(libusb) - is that right? Is th
Hi, today I went to build grub2 in rawhide and got this:
DEBUG util.py:444: No matching package to install: 'libusb-devel'
grub2 has a `BuildRequires: libusb-devel`, and suddenly that package
doesn't exist anymore. libusb was apparently dead.package'd two days
ago.
So this is sudden, and
Alexander Sosedkin writes:
> Daniel P. Berrangé wrote:
>
>> Perhaps a useful first step is to just modify the three main
>> crypto libs (gnutls, openssl, and nss) to send a scary warnihg
>> message to stderr/syslog any time they get use of SHA1 in a
>> signature. Leave that active for a release
Neal Gompa writes:
> On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood wrote:
>>
>> Fabio Valentini writes:
>>
>> > For example, as far as I know, you need the 32-bit host libraries for
>> > running 32-bit Windows applications in Wine. Dropping that w
Fabio Valentini writes:
> For example, as far as I know, you need the 32-bit host libraries for
> running 32-bit Windows applications in Wine. Dropping that would make
> our Wine packages almost useless, since a large fraction of Windows
> software still isn't 64-bit.
Would it be possible to
Neal Gompa writes:
> And we're not the first to offer reduced functionality
> FFmpeg (both Debian and openSUSE do too, so we're in good company
> here).
I don't think that's an accurate characterization of what Debian does.
See
Al Stone writes:
> I may be interested in picking this up. I've been doing some UEFI
> dev work on Fedora. Let me take a look at the package and let you
> know in a day or two or three. Anything I should watch out for if
> I do decide to pick this up?
Thanks for your interest! However, the
Zbigniew Jędrzejewski-Szmek writes:
> 1. pc(5) talks about "package", as if one would want to link to a
>whole "package" instead one of the specific library files provided
>by a package. Thankfully most .pc files only list one "-l" in Libs.
>(Counterexamples: tbbmalloc_proxy.pc says
Adam Williamson writes:
> ...and yet despite being so easy to review it somehow had a major
> security vulnerability ever since it was written.
This is not a good metric. easy to review != was sufficiently reviewed,
and getting sufficient code review might be the hardest problem in
software
Miro Hrončok writes:
> On 25. 01. 22 19:53, Robbie Harwood wrote:
>> Miro Hrončok writes:
>>
>>> On 25. 01. 22 19:17, Robbie Harwood wrote:
>>>> Hello, we plan to orphan gnu-efi shortly after I finish fixing the
>>>> FTBFS. There do not appea
Miro Hrončok writes:
> On 25. 01. 22 19:17, Robbie Harwood wrote:
>> Hello, we plan to orphan gnu-efi shortly after I finish fixing the
>> FTBFS. There do not appear to be any consumers:
>>
>> # dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-
Hello, we plan to orphan gnu-efi shortly after I finish fixing the
FTBFS. There do not appear to be any consumers:
# dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel}
--source
Last metadata expiration check: 0:05:32 ago on Tue 25 Jan 2022 01:09:26 PM EST.
Miro Hrončok writes:
> On 13. 01. 22 1:50, Michel Alexandre Salim wrote:
>> On Mon, Jan 10, 2022 at 06:57:34PM +0100, Miro Hrončok wrote:
>>> Package (co)maintainers Status
>>> Change
>>>
Neal Gompa writes:
> On Tue, Jan 4, 2022 at 3:10 PM Robbie Harwood wrote:
>>
>> Neal Gompa writes:
>>
>> > On Tue, Jan 4, 2022 at 2:25 PM Robbie Harwood wrote:
>> >>
>> >> Neal Gompa writes:
>> >>
>> >> >
Neal Gompa writes:
> On Tue, Jan 4, 2022 at 2:25 PM Robbie Harwood wrote:
>>
>> Neal Gompa writes:
>>
>> > SPDX expression logic is identical to Fedora's, so that will not
>> > change.
>>
>> I don't believe that's correct.
>>
Neal Gompa writes:
> SPDX expression logic is identical to Fedora's, so that will not
> change.
I don't believe that's correct.
For instance, for the LGPL, SPDX uses "LGPL-2.0-only" and
"LGPL-2.0-or-later", while Fedora currently uses "LGPLv2" and "LGPLv2+".
(From https://spdx.org/licenses/
Carlos O'Donell writes:
> - Life-cycle management (delete attachments).
Please don't delete attachments. It severely reduces the usefulness of
keeping old bugzillas around - if we're going to do that, we might as
well delete the old bugzilla entries as well, and I don't think anyone
wants
Frantisek Zatloukal writes:
> On Wed, Nov 24, 2021 at 11:58 AM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
>
>> Try removing yourself from ACL, i.e.:
>> 1. Go to https://src.fedoraproject.org/rpms/glabels and login
>> 2. Click on Settings tab
>> 3. Click on Users & Groups
Fabio Valentini writes:
> Since it's not practical to modify almost all Fedora packages to add
> "ExcludeArch: %{ix86}" to them, we'd probably need a different
> machanism for this. I have a vague idea:
Is it really not? This seems the easiest way to go about it, honestly -
just have it be
Vitaly Zaitsev via devel writes:
> On 08/11/2021 16:47, Andreas Schneider wrote:
>> I have electron building offline for Fedora, you can find it here:
>> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
>
> Electron core packaging is a quite trivial task (Arch Linux and
Stephen John Smoogen writes:
> On Mon, 8 Nov 2021 at 04:32, Michael Schroeder wrote:
>>
>> On Sat, Nov 06, 2021 at 07:43:02AM -, Daniel Alley wrote:
>> > Another issue - which is not per-se a security issue but it's still a
>> > problem - is that deltarpm uses md5 checksums pervasively.
Neal Gompa writes:
> Basically, my problem is that I don't think Sahana was prepared on how
> to handle doing this work properly and they just need to be aware that
> communication is extremely important when doing stuff like this.
> Sahara took this over from Tomáš Mráz, who left Red Hat to
Charalampos Stratakis writes:
> Well it seems so. I mean I would get it to an extend if this wasn't a
> *PR*. But anyway yes a two-line diff apparently should be a patch and
> not a sed.
>
> Also according to the PR comments I'm "unwilling" to do that upstream.
That is not how that word is used
Zbigniew Jędrzejewski-Szmek writes:
> And now you are pissed that they didn't provide the two line diff in
> the the format that you like.
This belittling is uncalled for; your escalation here is not needed, nor
is it helpful to keeping the conversation on a technical track.
Thanks,
--Robbie
Miro Hrončok writes:
> On 09. 02. 21 1:54, Robbie Harwood wrote:
>> Miro Hrončok writes:
>>> On 08. 02. 21 20:38, Robbie Harwood wrote:
>>>> Robbie Harwood writes:
>>>>> Ben Cotton writes:
>>>
>>> but doing this downstream onl
Miro Hrončok writes:
> On 08. 02. 21 20:38, Robbie Harwood wrote:
>> Robbie Harwood writes:
>>
>>> Ben Cotton writes:
>>>
>>>> A simple `sed` can be applied in `%prep` as a temporary (or even
>>>> permanent) downstream solution.
>
Robbie Harwood writes:
> Ben Cotton writes:
>
>> A simple `sed` can be applied in `%prep` as a temporary (or even
>> permanent) downstream solution.
>>
>> In most cases, performing the following replacement should be enough:
>>
>> s/^(\s*)import mo
Vít Ondruch writes:
> Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a):
>> Vít Ondruch writes:
>>
>>> Thx everybody for their responses and sorry for such controversial
>>> topic. I am not going to propose this upstream after all. However I
>>> have
Vít Ondruch writes:
> Thx everybody for their responses and sorry for such controversial
> topic. I am not going to propose this upstream after all. However I have
> few takeaways:
>
> 1) I see responses of Fedora long timers and I understand that you
> have polished workflows. But I really
Vít Ondruch writes:
> Dne 27. 01. 21 v 23:21 Gwyn Ciesla via devel napsal(a):
>>> On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
>>>
Hi, I wonder, what would be the sentiment if I proposed to
deprecated the `fedpkg local` command. I don't think it should be
used.
Vít Ondruch writes:
> Hi,
>
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should
> be the preferred way. Would there be anybody really missing this
> functionality?
I would miss it. It's nontrivially
Miro Hrončok writes:
> On 25. 01. 21 19:32, Robbie Harwood wrote:
>> Miro Hrončok writes:
>>
>>> Before I try to word it more carefully I'd like to hear some feedback
>>> on this. What do you think?
>>
>> It seems to me that this problem would b
Miro Hrončok writes:
> Before I try to word it more carefully I'd like to hear some feedback
> on this. What do you think?
I'm struggling to understand what you think this will accomplish.
Leaving aside ideological disagreement about the nature of rawhide (I
don't think rawhide should be
Ben Cotton writes:
> A simple `sed` can be applied in `%prep` as a temporary (or even
> permanent) downstream solution.
>
> In most cases, performing the following replacement should be enough:
>
> s/^(\s*)import mock/\1from unittest import mock/
> s/^(\s*)from mock import /\1from
"Colin Walters" writes:
> On Fri, Jan 15, 2021, at 9:47 AM, Simo Sorce wrote:
>>
>> There is of course no problem to have it in Fedora, but if this is
>> something that is going to end up in RHEL one day, it would be better
>> to do the work now to make it use OpenSSL rather than scramble
Kevin Fenzi writes:
> On Thu, Jan 14, 2021 at 10:12:46PM +0100, Alexander Ploumistos wrote:
>> Hello,
>>
>> Could someone please help me figure out which rule I need to edit over
>> at Fedora Notifications, to stop receiving messages like this one?
>>
>> On Thu, Jan 14, 2021 at 9:53 PM wrote:
Zbigniew Jędrzejewski-Szmek writes:
> On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/golang1.16
>>
>> == Summary ==
>> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
>
> No complaint about the Change, but...
> can we please
Matthew Miller writes:
> Logs can accidentally contain sensitive data, and it's just plain
> faster to work with them when there's less. I propose we set this to
> something like six months by default.
If there are non-negligible speed impacts from large logs, this seems
like a problem with
Dan Čermák writes:
> Robbie Harwood writes:
>
>> Ben Cotton writes:
>>
>>> For swap based actions, systemd-oomd will monitor the system-wide swap
>>> space and act when available swap falls below the configured
>>> threshold, starting
Ben Cotton writes:
> For swap based actions, systemd-oomd will monitor the system-wide swap
> space and act when available swap falls below the configured
> threshold, starting with the cgroups with the highest swap usage to
> the least. Keeping some amount of swap (if enabled) available will
>
1 - 100 of 243 matches
Mail list logo
