On 5/5/21 7:08 PM, Neal Gompa wrote:
On Wed, May 5, 2021 at 11:55 AM Qiyu Yan wrote:
在 2021-05-05星期三的 07:44 +0200，Dan Čermák写道：
przemek klosowski via devel writes:
Is that something we need to worry about? I couldn't think of any new
rules to impose on repositories, but maybe dnf should
On 1/29/21 12:44 PM, Miro Hrončok wrote:
On 29. 01. 21 12:25, Zbigniew Jędrzejewski-Szmek wrote:
Hello fellow packagers!
The subject of bootstrapping came up on fedora-devel recently.
I had the following idea, about which I would love to hear some feedback:
== Problem:
building packages
Dne 18. 01. 21 v 11:29 Kamil Paral napsal(a):
On Mon, Jan 18, 2021 at 9:36 AM Daniel Mach <mailto:dm...@redhat.com>> wrote:
$ dnf offline-upgrade
$ dnf offline-distrosync
* New commands to upgrade your system on reboot
Sounds great. But I don't see those command
Hi,
On behalf of RPM and DNF teams, I would like to highlight changes that
have appeared in our packages in 2020. Thanks everyone for your bug
reports and patches!
RPM
---
$ rpm --eval '%[0 < 1 ? "true" : "false"]'
* Support for complex expressions and conditionals with short-circuit
Dne 05. 01. 21 v 0:50 Kevin Fenzi napsal(a):
On Mon, Jan 04, 2021 at 06:29:13PM -0500, Matthew Miller wrote:
On Mon, Jan 04, 2021 at 10:21:15PM +, Matthew Almond via devel wrote:
There's been a lot of interesting talk about the state and future of
drpm. I'd like to propose we continue
Dne 24. 12. 20 v 22:54 Matthew Almond via devel napsal(a):
Depends on how it got there, and what you asked for. Here's some
examples:
1. cp foo.rpm /var/cache/dnf//Packages/ && dnf install foo
...will fail the librepo full file check, and it'll be re-
downloaded.
2. dnf install
Dne 03. 11. 20 v 13:14 Petr Pisar napsal(a):
On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote:
Daniel Mach writes:
The API is clear: DNF expects additional 'modulemd-obsoletes' YAML
documents in modules.yaml. The new document format is getting into
libmodulemd and there's going
Lazy file list loading? Yes, that's on DNF's TODO list already, but (to
be honest) not on top - there's always something more important. It's
not getting into DNF4, but it may get into DNF5 later on.
Dne 02. 11. 20 v 20:13 clime napsal(a):
On Mon, 2 Nov 2020 at 18:55, Vít Ondruch wrote:
Hi,
Dne 27. 10. 20 v 13:52 Martin Curlej napsal(a):
Hi,
EOL and Obsoletes were planned as a feature of Modularity. The feature
should enable to set shorter/longer life cycles on Modules than the OS
release. The initial idea was to set this information in the disgit
metadata of a Module. As
Hello everyone,
There's a Modularity Improvements Objective draft available[1].
The Objective summarizes the work that is in progress already as well as
highlights our plans for Fedora 34.
We're planning to fix the current modularity in Fedora 33 and 34.
We may look into alternatives or
Dne 17. 07. 20 v 23:14 Aleksei Bavshin napsal(a):
Yes, that's something I already accepted.
The real question is how to do the change in f33 considering that f32
and f33 modules must be built from the same modulemd file. I only see
the ability to disable module stream build for f33.
Hmm, it
Dne 17. 07. 20 v 14:15 Aleksei Bavshin napsal(a):
On 7/17/20 3:27 AM, Daniel Mach wrote:
Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a):
If the package was part of the module during the release of Fedora 32,
dnf will see 2 versions/builds of the module-stream:
- the one that existed
Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a):
On 17. 07. 20 6:47, Aleksei Bavshin wrote:
In an optimistic case I'd like to believe that once the package is
removed from the modulemd file and a new module update is published, the
override magic hacked into dnf would stop masking package from
Dne 24. 06. 20 v 11:56 Petr Pisar napsal(a):
On Wed, Jun 24, 2020 at 11:01:55AM +0200, clime wrote:
On Wed, 24 Jun 2020 at 10:35, Petr Pisar wrote:
On Wed, Jun 24, 2020 at 10:22:38AM +0200, clime wrote:
On Wed, 24 Jun 2020 at 09:40, Petr Pisar wrote:
On Wed, Jun 24, 2020 at 06:51:36AM
Dne 05. 06. 20 v 8:41 Kevin Kofler napsal(a):
The fact that Obsoletes from outdated packages are being considered is the
bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1748187
but the DNF developers refused to acknowledge this and just closed the bug
when the issue was worked around in the
Dne 19. 05. 20 v 16:56 Miro Hrončok napsal(a):
On 19. 05. 20 16:46, Christopher wrote:
Interesting that the survey shows that the most common response was
that people use it "not at all" and the overall response was negative,
but the reaction to that is, "improve the docs" and "works as
Hello everyone,
We have finally evaluated all of your responses to the Modularity
survey. You can find the results posted on the Fedora community blog[1].
Thanks to all of you who filled the survey and provided detailed
explanation of what works and what not.
[1]
Dne 27. 04. 20 v 19:00 Stephen Gallagher napsal(a):
On Mon, Apr 27, 2020 at 10:47 AM Daniel Mach wrote:
I'm wondering if this is your personal initiative or if you're sync with
ELN people. I emailed them in January about the very same idea (and I
used the very same name; we both seem
I'm wondering if this is your personal initiative or if you're sync with
ELN people. I emailed them in January about the very same idea (and I
used the very same name; we both seem to like Gentoo), we exchanged
couple emails, but never got an answer if this is the way to go. Since I
have a lot
I'm wondering if this is your personal initiative or if you're sync with
ELN people. I emailed them in January about the very same idea (and I
used the very same name; we both seem to like Gentoo), we exchanged
couple emails, but never got an answer if this is the way to go. Since I
have a lot
Updated.
Thanks both of you for the suggestion.
Dne 08. 04. 20 v 19:59 Adam Williamson napsal(a):
On Wed, 2020-04-08 at 13:47 -0400, Alex Scheel wrote:
Hey Daniel, do you mind updating the GDPR compliance tag to include
Google?
Right, this is all I intended in the first place :) A simple:
Hello everyone,
On behalf of Red Hat's Modularity team, I'd like to ask you to fill out
a survey on Modularity:
https://docs.google.com/forms/d/e/1FAIpQLScOA97rGONieSOYmlZLsHdkq-EhdePZ4IN3RwOjJKd1F1a9sw/viewform?usp=sf_link
Our goal is to use your feedback to improve Modularity, its
Dne 31. 03. 20 v 10:14 Zbigniew Jędrzejewski-Szmek napsal(a):
On Tue, Mar 31, 2020 at 09:25:45AM +0200, Vít Ondruch wrote:
Wouldn't be easier to use something we already have? E.g.
https://src.fedoraproject.org/rpms/fedora-obsolete-packages
Obsoletes in individual rpms have no effect on
Dne 31. 03. 20 v 10:00 Petr Pisar napsal(a):
On Tue, Mar 31, 2020 at 09:25:45AM +0200, Vít Ondruch wrote:
Wouldn't be easier to use something we already have? E.g.
https://src.fedoraproject.org/rpms/fedora-obsolete-packages
DNF implements modules as an layer above RPM packages. Thus you
Dne 30. 03. 20 v 19:20 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Mar 30, 2020 at 10:30:51AM -0400, Ben Cotton wrote:
document: TBD
version: 1
data:
# A string representing UTC date in ISO 8601 format: -MM-DD[T ]HH:MMZ
# When merging, entries with a newer 'modified' value will
Dne 30. 03. 20 v 17:10 Petr Pisar napsal(a):
On Mon, Mar 30, 2020 at 10:30:51AM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL
[...]
*** When a module stream gets removed from a Fedora release, the
maintainer of the module stream must provide a
Dne 12. 03. 20 v 19:26 Pat Riehecky napsal(a):
I realize I'm thinking about the Pie in the Sky, but:
Would it be possible for 'microdnf' to become the base for 'dnf' so
that extra 'dnf' functionality is added via some kind of
modules/plugins/etc behaviour? Perhaps "somehow" it could (for
Dne 12. 03. 20 v 6:21 Chris Murphy napsal(a):
On Thu, Mar 5, 2020 at 8:30 AM Daniel Mach wrote:
Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
wrote:
Are you going to use sd-bus for the dbus library?
I'd hope not, given
Dne 05. 03. 20 v 19:38 J. Randall Owens napsal(a):
On 04/03/2020 18:03, Daniel Mach wrote:
Hello everyone,
I'm pleased to announce start of DNF 5 development. We are planning to
deliver a module stream or a COPR repo during Fedora 33 development for
early adopters and tool developers
Dne 05. 03. 20 v 13:02 Marcin Juszkiewicz napsal(a):
W dniu 04.03.2020 o 19:03, Daniel Mach pisze:
Hello everyone, I'm pleased to announce start of DNF 5 development.
microdnf
> Microdnf is becoming important because it's part of
many containers due to its small footprint.
[r
Dne 04. 03. 20 v 23:01 Neal Gompa napsal(a):
On Wed, Mar 4, 2020 at 4:37 PM Zbigniew Jędrzejewski-Szmek
wrote:
Are you going to use sd-bus for the dbus library?
I'd hope not, given that we have cross-distro usage of DNF now, and a
couple of them don't have systemd.
Do you know which
Dne 04. 03. 20 v 22:34 Zbigniew Jędrzejewski-Szmek napsal(a):
On Wed, Mar 04, 2020 at 07:03:01PM +0100, Daniel Mach wrote:
Hello everyone,
I'm pleased to announce start of DNF 5 development. We are planning
to deliver a module stream or a COPR repo during Fedora 33
development for early
Hello everyone,
I'm pleased to announce start of DNF 5 development. We are planning to
deliver a module stream or a COPR repo during Fedora 33 development for
early adopters and tool developers and we're hoping in getting a stable
version into Fedora 34.
More details follow.
We've managed
represented by the
software management group, with Daniel Mach coming up with an updated
Modularity Objective in the following weeks.
In essence, everything remains the same; continue using the Pagure
tracker and our IRC channel when interacting with the team -- just
expect to see "new" face
There seem to be 2 related problems:
1) Only the image on docker.io doesn't work. If you use
registry.fedoraproject.org/fedora:rawhide, it works as expected.
2) Fedora infra is unreliable. When the image from
registry.fedoraproject.org cannot be downloaded, there's a fallback to
docker.io
Dne 07. 02. 20 v 13:47 Neal Gompa napsal(a):
On Fri, Feb 7, 2020 at 4:00 AM Daniel Mach wrote >> Dne 06.
02. 20 v 19:54 Zbigniew Jędrzejewski-Szmek napsal(a):
- move the Requires:linux-firmware (or change to Recommends) from kernel-core,
have kernel Requires:linux-firmware
It
Dne 06. 02. 20 v 19:54 Zbigniew Jędrzejewski-Szmek napsal(a):
Hello kernel maintainers, hello Fedora developers,
I'm looking into the split of kernel packages. The split into subpackages
seems interesting, but there are many dependencies between the packages,
so it is usual to end up with all
On 10/7/19 8:55 PM, Simo Sorce wrote:
I have to ask,
given containers are so popular and can deal with any dependency
without conflicting with system installed binaries, should we really
continue with this very complicated modular design ?
There are only few people who fully understand how
Dne 14. 06. 19 v 6:23 Samuel Sieb napsal(a):
After reading the bug report and the discussions, I still don't
understand why dnf is complaining about a conflict with packages
(modules?) that are not installed and are not even trying to be
installed. Can someone explain that?
The dependency
Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to build for Fedora 3x?
Speaking of Mock:
Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to build for Fedora 3x?
Speaking of Mock:
Dne 30. 05. 19 v 17:14 Peter Robinson napsal(a):
What about constrained systems where there's limited CPU, that could
be a container or a low end cloud instance without any guarantee of
resources or a Raspberry Pi.
Raspberry Pi is hard to measure. I'm getting quite random results due to
IO, I
Dne 30. 05. 19 v 17:14 Peter Robinson napsal(a):
What about constrained systems where there's limited CPU, that could
be a container or a low end cloud instance without any guarantee of
resources or a Raspberry Pi.
Raspberry Pi is hard to measure. I'm getting quite random results due to
IO, I
Dne 30. 05. 19 v 14:57 Kevin Kofler napsal(a):
Jason L Tibbitts III wrote:
"BC" == Ben Cotton writes:
BC> * The recommended compression level is 19. The builds will take
BC> longer, but the additional compression time is negligible in the
BC> total build time and it pays off in better
Dne 30. 05. 19 v 8:39 Igor Gnatenko napsal(a):
Last time I was about to propose this in F29, I did mass-rebuild myself
and while decompressing was faster in most of the cases, the size was
definitely worse. So definitely "Lower bandwidth on mirrors if we choose
the highest compression level"
Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a):
I'm pretty sure this would break DeltaRPMs, since none of the drpm
software has been updated to handle zstd compression. Neither drpm nor
deltarpm handle it today.
Thanks for heads-up. We'll look into it and provide a fix soon.
would increase decompression speed significantly.
== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dm...@redhat.com
== Detailed Description ==
* The change requires setting a new compression algorithm in rpm
macros. Then a mass rebuild of all packages is required.
The gcc team often does
On Thu, Jul 19, 2018 at 12:06 AM, Neal Gompa wrote:
> On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé
> wrote:
> >
> > On Wed, Jul 18, 2018 at 03:24:54PM +0200, Daniel Mach wrote:
> > > Hi everyone,
> > > The DNF team is currently reviewing DNF compatibil
On Wed, Jul 18, 2018 at 5:13 PM, Ben Cotton wrote:
> On Wed, Jul 18, 2018 at 11:02 AM Daniel Mach wrote:
>
> > If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
> > there will be continuity in used algorithm and history db checksums.
> > It's impo
>
> What's the benefit in changing to be compatible with YUM as opposed
> to stickin with current alogorithm ?
>
If a user migrates from RHEL 7 to the next version of RHEL (or CentOS),
there will be continuity in used algorithm and history db checksums.
It's important to some enterprise customers
Hi everyone,
The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
like to get feedback on this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1120253
rpmdb checksum is a checksum of all installed RPMs
It has no cryptographical value, it's just an unique ID of RPMs on a
On Thu, Jul 5, 2018 at 9:45 PM, Kevin Fenzi wrote:
> On 06/27/2018 03:18 AM, Lubomír Sedlář wrote:
> > Removing Yyum would mean that there will no longer be /usr/bin/pungi
> > available in Fedora. This is not a problem for any work done by release
> > engineering, but it is still used by people
On Thu, Jun 28, 2018 at 1:35 AM, Adam Williamson wrote:
> On Wed, 2018-06-27 at 18:18 -0400, Josh Boyer wrote:
> > On Wed, Jun 27, 2018 at 4:30 PM Adam Williamson
> > wrote:
> > >
> > > On Wed, 2018-06-27 at 16:25 -0400, Matthew Miller wrote:
> > > > On Wed, Jun 27, 2018 at 02:54:07PM +0200,
On Wed, Jun 27, 2018 at 2:23 PM, Sam Varshavchik
wrote:
> Jan Kurik writes:
>
> = Proposed Self Contained Change: Deprecate YUM 3 =
>> https://fedoraproject.org/wiki/Changes/Deprecate_YUM_3
>>
>>
>> Owner(s):
>> * Daniel Mach
>>
>>
>
We are pleased to announce that development of DNF 3 has started. This
version is focused on performance improvements, new API and consolidating
the whole software management stack.
Please read more details on our blog:
.
It worked fine for for me until Fedora 18.
Unfortunately something changed and I installed Fedora 19 using Anaconda again
(had no time to debug).
I think the only missing steps are to create /etc/fstab and make selinux work
by running `touch /.autorelabel`
- daniel
--
Daniel Mach dm...@redhat.com
a repository is updated, which
for a fast-moving OS like Fedora could happen nearly every day.
--
Daniel Mach dm...@redhat.com
Release Engineering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http
57 matches
Mail list logo
