> > Maybe I need to reboot my system for vim to take over again?
>
> You will at least need to logout and log back in.
You're right, if I force a login instead of plain sudo it becomes apparent:
$ sudo env | grep EDITOR
$ sudo su -c env | grep EDITOR
$ sudo su - -c env | grep EDITOR
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-33-20201203.0):
ID: 735348 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
On 12/3/20 10:52 PM, Dridi Boukelmoune wrote:
puts setting EDITOR environment variable into a file
(vim-default-editor.sh for bash, ksh, sh and zsh, vim-default-editor.csh
for tcsh and vim-default-editor.fish for fish), which is installed under
a specific directory (/etc/profile.d for bash,
> actually Vim ships vim-default-editor subpackage now, which conflicts
I did install it, but that didn't seem to have an immediate effect.
> with nano-default-editor via virtual provide 'system-default-editor'. It
I don't have that package on my system:
$ sudo dnf remove nano-default-editor
On 12/3/20 9:46 PM, Tom Hughes via devel wrote:
>
>> Also from that bug:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1896707#c13
>>> "dnf remove nano-default-editor". Alternatively, you can set "export
>>> EDITOR=vim" in your ~/.bash_profile
>
> Setting EDITOR doesn't really work. I mean I have
https://fedorapeople.org/groups/389ds/ci/nightly/2020/12/04/report-389-ds-base-2.0.1-20201204git2eba8fe.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
in Fedora-Rawhide-20201203.n.0):
ID: 735096 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/735096
ID: 735099 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/735099
ID: 735155 Test: aarch64 Minimal
OLD: Fedora-Rawhide-20201203.n.0
NEW: Fedora-Rawhide-20201203.n.1
= SUMMARY =
Added images:1
Dropped images: 1
Added packages: 15
Dropped packages:0
Upgraded packages: 164
Downgraded packages: 2
Size of added packages: 6.57 MiB
Size of dropped packages:0
https://github.com/389ds/389-ds-base/pull/4474
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
> == Upgrade/compatibility impact ==
>
> The `ntp` package is replaced automatically on upgrade to Fedora 34.
> The configuration file ''/etc/ntp.conf'' is saved as to
> ''/etc/ntp.conf.rpmsave'' and it needs to be renamed to
> ''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will
>
On 12/4/20 1:21 AM, Matthew Miller wrote:
On Thu, Dec 03, 2020 at 07:21:17PM -0500, Matthew Miller wrote:
If you don't have anything interesting to say, it could just be the
description of the package. Or other auto-generated information.
The information can be requested by machines, why would
On Thu, Dec 03, 2020 at 07:21:17PM -0500, Matthew Miller wrote:
> If you don't have anything interesting to say, it could just be the
> description of the package. Or other auto-generated information.
> > The information can be requested by machines, why would a human maintain it?
> It's useful
On Fri, Dec 04, 2020 at 01:17:29AM +0100, Miro Hrončok wrote:
> >We'd drop in a default one and it'd be the responsibility of the maintainers
> >of the various branches.
> So except of maintain the branches, I need to maintain a README for
> my ~200 packages and keep it up to date? That's a big
On 12/4/20 1:01 AM, Matthew Miller wrote:
On Fri, Dec 04, 2020 at 12:43:43AM +0100, Miro Hrončok wrote:
Who maintains this README?
We'd drop in a default one and it'd be the responsibility of the maintainers
of the various branches.
So except of maintain the branches, I need to maintain a
On 12/3/20 10:06 PM, Andrew C Aitchison wrote:
Is %generate_buildrequires suppose to work for packages
which do not used python ?
Yes, see https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
From the name I would expect it to, but reading that doc makes me
think
On 12/3/20 10:06 PM, Andrew C Aitchison wrote:
Is %generate_buildrequires suppose to work for packages
which do not used python ?
Yes, see https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
From the name I would expect it to, but reading that doc makes me
think
On 12/3/20 9:41 PM, Michel Alexandre Salim wrote:
On Thu, 2020-12-03 at 12:32 -0800, Michel Alexandre Salim wrote:
I split my time between the latest Fedora and the latest CentOS these
days, and it would make dogfooding packaging changes for CentOS/EPEL
much easier if all the packager utilities
On Fri, Dec 04, 2020 at 12:43:43AM +0100, Miro Hrončok wrote:
> Who maintains this README?
We'd drop in a default one and it'd be the responsibility of the maintainers
of the various branches.
--
Matthew Miller
Fedora Project Leader
___
devel
On 12/3/20 5:41 PM, Miroslav Suchý wrote:
Dne 03. 12. 20 v 9:52 Vít Ondruch napsal(a):
Yes, that was the idea. I can imagine, that the reason for your proposal is
probably the not so straight forward
transition from upstream name "foo" to Fedora name "python3-foo". But I am not
expert on
On 12/3/20 9:52 AM, Vít Ondruch wrote:
Dne 02. 12. 20 v 22:49 Miroslav Suchý napsal(a):
Dne 02. 12. 20 v 17:19 Vít Ondruch napsal(a):
Why these requires does not follow some standard naming convention possibly
with some prefix?
What do you mean? Like external:python3-foo?
Yes, that was
On 12/3/20 4:39 PM, Petr Šabata wrote:
On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon wrote:
On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
Since I don't see those on the list, does this impact
* rpkg (fedpkg)?
Wrapper to git, should not be impacted. The only thing I could
On 12/3/20 7:50 PM, Matthew Miller wrote:
As an alternate proposal, what is currently "master" could be moved to
"rawhide" and a_new_ "main" branch created explicity to hold just a readme
about that package's packaging details (like which branches are what
when there are module branches or
On 12/3/20 6:08 PM, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
Try this (note the -n):
%pretrans -n doc-en -p
That would have to be:
%pretrans -n sagemath-doc-en -p
because -n takes the full subpackage name, not just the suffix. (That is
normally the entire point of -n, to
On Thu, Dec 3, 2020 at 2:28 PM Peter Robinson wrote:
>
> > We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> > question with regards to opencryptoki-tpmtok if it should be changed in
> > Fedora as well, so I thought I'd see what everyone thinks about future
> > TPM1.2 support
On Thu, Dec 3, 2020, 4:11 PM Colin Walters wrote:
>
>
> On Thu, Dec 3, 2020, at 2:14 PM, Josh Boyer wrote:
>
> > This seems more split on the OS consumption model to me, rather than
> > the tools to make it. The end user shouldn't care at all about what
> > tools make it.
>
> I've been meaning
Also a couple of notes on modularity here:
# By default, module stream name is derived from the branch name
If we have any "master" modules, those will get unexpectedly renamed
as soon as they get rebuilt. This might impact tagging or updates and
cause confusion in general. We should check if
> We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> question with regards to opencryptoki-tpmtok if it should be changed in
> Fedora as well, so I thought I'd see what everyone thinks about future
> TPM1.2 support in Fedora. I know at one point in the last year or so
>
On Thu, Dec 3, 2020, at 2:14 PM, Josh Boyer wrote:
> This seems more split on the OS consumption model to me, rather than
> the tools to make it. The end user shouldn't care at all about what
> tools make it.
I've been meaning to write a longer blog post on this but briefly:
How you build
On Thu, 3 Dec 2020, Michel Alexandre Salim wrote:
Apart from the usual package-not-available story (which I want to fix
as part of my work bringing up the EPEL Packagers SIG), my current
snag is that python-tox-current-env uses %generate_buildrequires which
does not work on CentOS 8:
CentOS 8
Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a):
> Mostly the latter. I don't even really care if they end up keeping the
> distinct os-release and etc.
Is this backed by some numbers and analysis?
My personal usage is that I create **hundred thousands** VM from Fedora cloud
image per year.
And
On Wed, Dec 2, 2020 at 12:52 PM Ben Cotton wrote:
>
> On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote:
>
> > There were a number of people interested in helping with reviving the
> > Server WG, myself included. But we don't know how to have that move
> > forward. We've never really had a
Hello everyone,
My laptop boots but sometimes it has a long gap before it starts, and it
takes forever to turn off.
My 2 cents
Silvia
FAS: Lailah
On Thu, 3 Dec 2020 at 20:40, Andreas Tunek wrote:
> My computer does not boot with later Linux (like
> kernel-5.9.10-200.fc33.x86_64 and
On 03/12/2020 20:41, Ben Cotton wrote:
On Thu, Dec 3, 2020 at 3:32 PM Tom Hughes via devel
wrote:
What exactly does "change the default on upgrade" actually mean
here? Making nano-default-editor a dependency of something else
that people are likely to have installed? Or adding something to
On Thu, Dec 3, 2020 at 3:32 PM Tom Hughes via devel
wrote:
>
> What exactly does "change the default on upgrade" actually mean
> here? Making nano-default-editor a dependency of something else
> that people are likely to have installed? Or adding something to
> some sort of post install script
On Thu, 2020-12-03 at 12:32 -0800, Michel Alexandre Salim wrote:
> I split my time between the latest Fedora and the latest CentOS these
> days, and it would make dogfooding packaging changes for CentOS/EPEL
> much easier if all the packager utilities are available. Right now,
> fedpkg is, but
On Thu, 2020-12-03 at 12:32 -0800, Michel Alexandre Salim wrote:
> I split my time between the latest Fedora and the latest CentOS these
> days, and it would make dogfooding packaging changes for CentOS/EPEL
> much easier if all the packager utilities are available. Right now,
> fedpkg is, but
Can you open a bugzilla requesting the %generate_buildrequires macro be
backported to RHEL 8?
Pat
On Thu, 2020-12-03 at 12:32 -0800, Michel Alexandre Salim wrote:
> I split my time between the latest Fedora and the latest CentOS these
> days, and it would make dogfooding packaging changes for
I split my time between the latest Fedora and the latest CentOS these
days, and it would make dogfooding packaging changes for CentOS/EPEL
much easier if all the packager utilities are available. Right now,
fedpkg is, but fedora-review is not.
Tracking my effort here:
I split my time between the latest Fedora and the latest CentOS these
days, and it would make dogfooding packaging changes for CentOS/EPEL
much easier if all the packager utilities are available. Right now,
fedpkg is, but fedora-review is not.
Tracking my effort here:
On 03/12/2020 20:06, Ben Cotton wrote:
On Thu, Dec 3, 2020 at 2:33 PM Miro Hrončok wrote:
Should we try to "fix" this by ensuring the default does not change on upgrades?
Or should we acknowledge that it does?
I think we should acknowledge that it does because...
Changing the default on
On Thu, 2020-12-03 at 15:22 -0500, Colin Walters wrote:
>
> On Thu, Dec 3, 2020, at 2:48 PM, Adam Williamson wrote:
>
> > I dunno when's the last time anyone tried without it, tbh.
>
> For CoreOS we spent a *lot* of time ensuring that Ignition has first class
> SELinux support, and actually
On Thu, Dec 03, 2020 at 03:25:20PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Dec 03, 2020 at 04:15:24PM +0100, Pierre-Yves Chibon wrote:
> > On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> > > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton wrote:
> > > >
> > > >
On Thu, Dec 3, 2020, at 2:48 PM, Adam Williamson wrote:
> I dunno when's the last time anyone tried without it, tbh.
For CoreOS we spent a *lot* of time ensuring that Ignition has first class
SELinux support, and actually making it work on the Live ISO in a
not-horribly-hacky way required a
No missing expected images.
Failed openQA tests: 1/15 (aarch64)
Old failures (same test failed in Fedora-IoT-33-20201124.0):
ID: 735030 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/735030
Soft failed openQA tests: 1/16 (x86_64)
(Tests
On Thu, Dec 03, 2020 at 03:53:00PM +, Daniel P. Berrangé wrote:
> On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> >
> > == Summary ==
> >
> > This Change will move Fedora git repositories to use "main" as the
>
On Thu, Dec 03, 2020 at 02:32:20PM -0500, Neal Gompa wrote:
> On Thu, Dec 3, 2020 at 2:31 PM Miro Hrončok wrote:
> >
> > Hello,
> >
> > we have changed the default editor from vi to nano on Fedora 33+.
> >
> > The change proposal says:
> >
> > > Will not apply to upgrades.
> >
> >
On Thu, Dec 3, 2020 at 2:33 PM Miro Hrončok wrote:
>
> Should we try to "fix" this by ensuring the default does not change on
> upgrades?
> Or should we acknowledge that it does?
>
I think we should acknowledge that it does because...
> Changing the default on upgrades is good because the
On Thu, Dec 3, 2020 at 7:52 PM Andreas Tunek wrote:
>
>
>
> Den tors 3 dec. 2020 kl 20:49 skrev Peter Robinson :
>>
>> > My computer does not boot with later Linux (like
>> > kernel-5.9.10-200.fc33.x86_64 and 5.9.11-200.fc33) and I reported that in
>> > Bug 1903332. I guess that is a really
On Thu, Dec 03, 2020 at 04:56:09PM +0100, Clement Verna wrote:
>On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon <[1]pin...@pingoured.fr>
>wrote:
>
> On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton
Den tors 3 dec. 2020 kl 20:49 skrev Peter Robinson :
> > My computer does not boot with later Linux (like
> kernel-5.9.10-200.fc33.x86_64 and 5.9.11-200.fc33) and I reported that in
> Bug 1903332. I guess that is a really HW-specific bug since it hasn't been
> discussed here, but I wonder if
> My computer does not boot with later Linux (like
> kernel-5.9.10-200.fc33.x86_64 and 5.9.11-200.fc33) and I reported that in Bug
> 1903332. I guess that is a really HW-specific bug since it hasn't been
> discussed here, but I wonder if anyone else here has the same problem?
>
> I guess I will
On Thu, 2020-12-03 at 14:43 -0500, Matthew Miller wrote:
> On Thu, Dec 03, 2020 at 11:36:32AM -0800, Adam Williamson wrote:
> > > > (Personally I'm really proud that for example our Live ISO ships with
> > > > SELinux enforcing)
> > > This is true of Fedora Workstation and other desktop spin live
On Thu, 2020-12-03 at 14:14 -0500, Josh Boyer wrote:
> >
> > Beyond the pungi-vs-bodhi thing of course, to me it is also very
> > fundamental that our OS build and test process runs natively via podman and
> > Kubernetes (unprivileged). We're telling people to use containers;
> > building the
On Thu, Dec 03, 2020 at 11:36:32AM -0800, Adam Williamson wrote:
> > > (Personally I'm really proud that for example our Live ISO ships with
> > > SELinux enforcing)
> > This is true of Fedora Workstation and other desktop spin live ISOs as well.
> Yes, but the live installer runs 'setenforce 0'
On Thu, Dec 03, 2020 at 09:35:02PM +0200, Alexander Bokovoy wrote:
> >>Server: a install dvd, pxe/netboot
> >>Cloud: a runnable image
> >>Are folks wanting to drop the dvd and netinstall?
> >>Or just market the Cloud image more to server admins that want a ready
> >>to run image?
> >
> >Mostly the
My computer does not boot with later Linux (like
kernel-5.9.10-200.fc33.x86_64 and 5.9.11-200.fc33) and I reported that in
Bug 1903332. I guess that is a really HW-specific bug since it hasn't been
discussed here, but I wonder if anyone else here has the same problem?
I guess I will enable
On Thu, 2020-12-03 at 14:06 -0500, Matthew Miller wrote:
> On Thu, Dec 03, 2020 at 01:58:56PM -0500, Colin Walters wrote:
> > (Personally I'm really proud that for example our Live ISO ships with
> > SELinux enforcing)
>
> This is true of Fedora Workstation and other desktop spin live ISOs as
On to, 03 joulu 2020, Matthew Miller wrote:
On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote:
I suppose we could look into this, but it seems kind of complementary to
me:
Server: a install dvd, pxe/netboot
Cloud: a runnable image
Are folks wanting to drop the dvd and netinstall?
Or
On Thu, Dec 3, 2020 at 2:31 PM Miro Hrončok wrote:
>
> Hello,
>
> we have changed the default editor from vi to nano on Fedora 33+.
>
> The change proposal says:
>
> > Will not apply to upgrades.
>
> https://fedoraproject.org/wiki/Changes/UseNanoByDefault#Upgrade.2Fcompatibility_impact
>
>
On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
> > > I think if we don't want to accept a different
> > > philosophy about release schedule and release engineering we can
> just
> > close
> > > that Change proposal.
> >
> > That's not the outcome I intended, but rather that if we want
Hello,
we have changed the default editor from vi to nano on Fedora 33+.
The change proposal says:
> Will not apply to upgrades.
https://fedoraproject.org/wiki/Changes/UseNanoByDefault#Upgrade.2Fcompatibility_impact
However, currently, it does apply to upgrades:
On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
[big snip]
> To the outside
> > world, there is a strong impression that the thing called "Fedora" is a
> > product or set of products with a release number that gets released
> > every six months. The concept of "Fedora 33 release" or
On Thu, Dec 3, 2020 at 1:59 PM Colin Walters wrote:
>
> On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote:
> >
> >
> > What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> > the context of how CoreOS is built and released? What set of bits will
> > we be deciding to ship
On Thu, Dec 03, 2020 at 01:58:56PM -0500, Colin Walters wrote:
> (Personally I'm really proud that for example our Live ISO ships with
> SELinux enforcing)
This is true of Fedora Workstation and other desktop spin live ISOs as well.
--
Matthew Miller
Fedora Project Leader
On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote:
> I suppose we could look into this, but it seems kind of complementary to
> me:
> Server: a install dvd, pxe/netboot
> Cloud: a runnable image
> Are folks wanting to drop the dvd and netinstall?
> Or just market the Cloud image more to
On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote:
>
>
> What does the question "is Fedora CoreOS 34 ready to go" even mean, in
> the context of how CoreOS is built and released? What set of bits will
> we be deciding to ship or not ship, and how will that have been decided
> and
On Thu, Dec 03, 2020 at 10:29:11AM +0100, Christopher Engelhard wrote:
> On 2020-12-03 09:31, David Kaufmann wrote:
> > On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote:
> > > That would be amazing! In order for it to remain as an edition, we
> > > (speaking
> > > generally for the
On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> Is there a reason why "main" is proposed instead of "rawhide" on src.fp.o?
> For all non-dist-git repositories I am fine with "main", but if we are
> changing this anyway, "rawhide" would actually make more sense for
> dist-git
On Wed, 2 Dec 2020 at 21:22, Adam Williamson
wrote:
> On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote:
> > >
> > > CoreOS is going to be the same only worse, because it's not even built
> > > the same way as the rest of Fedora. It's not built by Pungi, we don't
> > > get the same messages
On Thu, Dec 03, 2020 at 09:31:43AM +0100, David Kaufmann wrote:
> Until now I thought of both as having a very different target audience,
> I've never looked at Cloud Base, as I almost completely self-host.
> I don't really understand why it should be merged, is there some
> document or chat log
Missing expected images:
Xfce raw-xz armhfp
Compose FAILS proposed Rawhide gating check!
5 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 22/180 (x86_64), 22/117 (aarch64)
New failures (same
Dne 03. 12. 20 v 16:02 Ben Cotton napsal(a):
> * Release engineering:
>
>Releng will adjust any scripts that assume 'master' branch to use
> 'main' instead. The list includes and maybe few more
I do not see in the list upstream of dist-git.
I proceeded with:
Missing expected images:
Iot dvd x86_64
Iot dvd aarch64
Failed openQA tests: 4/16 (x86_64), 7/15 (aarch64)
New failures (same test not failed in Fedora-IoT-34-20201202.0):
ID: 734887 Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/734887
ID: 734888
On 03.12.2020 16:02, Ben Cotton wrote:
This Change will move Fedora git repositories to use "main" as the
default git branch instead of "master". Specific repositories will be
manually moved and default git branch for new projects will be set to
use "main".
1. Why "main" and not "rawhide"?
2.
On 12/3/20 8:32 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 5:17 PM Tom Stellard wrote:
On 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here
Ben Cotton wrote:
> This changes is to promote Fedora CoreOS to Edition status alongside
> Workstation, Server and IoT.
IMHO, Fedora CoreOS is still an experiment with way too many limitations and
drawbacks to warrant Edition status.
Don't get me wrong, it is nice to have a place for
Miro Hrončok wrote:
> Try this (note the -n):
>
> %pretrans -n doc-en -p
That would have to be:
%pretrans -n sagemath-doc-en -p
because -n takes the full subpackage name, not just the suffix. (That is
normally the entire point of -n, to allow arbitrary names for subpackages.)
Dear all,
You are kindly invited to the meeting:
EPEL Steering Committee on 2020-12-04 from 17:00:00 to 18:00:00 US/Eastern
At fedora-meet...@irc.freenode.net
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.
A general agenda is the following:
#meetingname
Dne 03. 12. 20 v 16:31 Pierre-Yves Chibon napsal(a):
>>
>> * rpkg (fedpkg)?
>
>Wrapper to git, should not be impacted.
but is impacted.
There is bunch of
if rel == 'master':
return ['master']
which needs to be updated.
Also request_repo have hard-coded "master" name.
>> * COPR?
Dne 03. 12. 20 v 9:52 Vít Ondruch napsal(a):
> Yes, that was the idea. I can imagine, that the reason for your proposal is
> probably the not so straight forward
> transition from upstream name "foo" to Fedora name "python3-foo". But I am
> not expert on Python naming conventions.
The reverse
In my spec files, I use %cmake, %cmake_build and %cmake_install.
A priori, I now that I must add BuildRequires cmake but I don't now the details
of the macro. So, I don't now if the %cmake macro is tuned to build a ninja or
a make project.
I think the cmake should ship a minima the build tools
On 03/12/2020 16:21, Gary Buhrmaster wrote:
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.
On Thu, Dec 3, 2020 at 5:17 PM Tom Stellard wrote:
>
> On 12/3/20 7:39 AM, Fabio Valentini wrote:
> > On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard wrote:
> >>
> >> On 12/2/20 5:45 AM, Artem Tim wrote:
> >>> How to quickly retest packages which listed here
> >>>
On Wed, 2020-12-02 at 21:25 -0500, Dusty Mabe wrote:
>
> Ideally we update our stable stream closer to Fedora's actual release date
> but I think it's
> important to maybe release Fedora CoreOS from the notion that it's tightly
> coupled with the
> Fedora major release date for a few reasons:
On Thu, 3 Dec 2020 at 11:18, Tom Stellard wrote:
> On 12/3/20 7:39 AM, Fabio Valentini wrote:
> > On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard wrote:
> >>
> >> On 12/2/20 5:45 AM, Artem Tim wrote:
> >>> How to quickly retest packages which listed here
>
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 12/3/20 7:39 AM, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here
https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few
locally and in Koji Rawhide
OLD: Fedora-Rawhide-20201202.n.0
NEW: Fedora-Rawhide-20201203.n.0
= SUMMARY =
Added images:2
Dropped images: 2
Added packages: 111
Dropped packages:0
Upgraded packages: 119
Downgraded packages: 1
Size of added packages: 181.80 MiB
Size of dropped packages
On Thu, Dec 03, 2020 at 04:39:35PM +0100, Petr Šabata wrote:
> On Thu, Dec 3, 2020 at 4:34 PM Pierre-Yves Chibon wrote:
> >
> > On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> > > Since I don't see those on the list, does this impact
> > >
> > > * rpkg (fedpkg)?
> >
> > Wrapper to
On Thu, 3 Dec 2020 at 16:21, Pierre-Yves Chibon wrote:
> On Thu, Dec 03, 2020 at 04:08:26PM +0100, Fabio Valentini wrote:
> > On Thu, Dec 3, 2020 at 4:03 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> > >
> > > == Summary ==
> > >
> > > This
On Thu, Dec 3, 2020 at 10:53 AM Daniel P. Berrangé wrote:
>
> On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
> >
> > == Summary ==
> >
> > This Change will move Fedora git repositories to use "main" as the
> > default
On Thu, Dec 03, 2020 at 10:02:34AM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main
>
> == Summary ==
>
> This Change will move Fedora git repositories to use "main" as the
> default git branch instead of "master". Specific repositories will be
> manually
On 03/12/2020 15:39, Fabio Valentini wrote:
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard wrote:
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here
https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few
locally and in Koji Rawhide
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 4:34 PM Pierre-Yves Chibon wrote:
>
> On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> > Since I don't see those on the list, does this impact
> >
> > * rpkg (fedpkg)?
>
> Wrapper to git, should not be impacted. The only thing I could think of was:
> when we
On Thu, Dec 3, 2020 at 4:35 PM Tom Stellard wrote:
>
> On 12/2/20 5:45 AM, Artem Tim wrote:
> > How to quickly retest packages which listed here
> > https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested
> > few locally and in Koji Rawhide scratch, but they are compiled
On 12/2/20 5:45 AM, Artem Tim wrote:
How to quickly retest packages which listed here
https://fedorapeople.org/~tstellar/needs_br_make_packages.txt? I've tested few
locally and in Koji Rawhide scratch, but they are compiled fine.
___
If the packages use make and they BuildRequire: make then
On 12/2/20 2:37 AM, Mark Wielaard wrote:
Hi Tom,
On Mon, 2020-11-30 at 14:06 -0800, Tom Stellard wrote:
As part of the f34 change request[1] for removing make from the
buildroot, I will be doing a mass update of packages[2] to add
BuildRequires: make where it is needed.
As part of a previous
On Thu, Dec 03, 2020 at 04:16:56PM +0100, Petr Šabata wrote:
> Since I don't see those on the list, does this impact
>
> * rpkg (fedpkg)?
Wrapper to git, should not be impacted. The only thing I could think of was:
when we fedpkg clone an empty git repo, have fedpkg do the "git branch -M main"
It is best to open a bugzilla bugs for questions like this.
Each EPEL package is maintained by it's own packager. (Although many
packagers have hundred of packages) And not all packagers are
subscribed to the EPEL mailing list.
In this case, this has already been requested / asked.
1 - 100 of 137 matches
Mail list logo
