Re: Retiring ntp

On Mon, Nov 02, 2020 at 11:58:53PM -0600, Alex Thomas wrote: > Question : I know that FreeIPA at one point did not work well with > chrony and required the installation of ntp. This might cause an > issue. That's not a problem anymore. Support for chrony was added in 4.7.0, released in 2018, so

Re: Deprecating SCP

On 11/2/20 4:05 PM, Marius Schwarz wrote: Am 02.11.20 um 15:44 schrieb Jakub Jelen: Hi Fedora users! Over the last years, there were several issues in the SCP protocol, which lead us into discussions if we can get rid of it in upstream [1]. Most of the voices there said that they use SCP most

Re: Deprecating SCP

On 11/2/20 10:29 PM, David Howells wrote: Jakub Jelen wrote: Today, I set up a copr repository with the current openssh from Fedora + the patch [2] for anyone to test and provide feedback, either here on the mailing list, or in the github PR according to ones preferences. Does it work with c

Re: Self Introduction: John Kacur

Hello, John! On Tuesday, 03 November 2020 at 03:20, John Kacur wrote: > Hello. My name is John Kacur > I'm a real-time developer with Red Hat, who I've been with for over 11 years. > Before that I worked for approximately 8 years with IBM on the compiler team. > > I am the upstream co-maintainer

Fedora 33 redhat-rpm-config package update stuck in pending

This update: appears to be stuck in the pending state. What can I do to move it forward? Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 15324

Fedora-Cloud-32-20201103.0 compose check report

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-32-20201102.0): ID: 714229 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: Retiring ntp

On Mon, Nov 02, 2020 at 09:52:59PM +, Gary Buhrmaster wrote: > 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. timesyncd is a very minimal NTP client. It can be r

Re: Fedora Security Team

Hello Marek, On Tuesday, 3 November, 2020, 5:38:39 am IST, Michael Catanzaro wrote:  >On Tue, Nov 3, 2020 at 12:53 am, Marek Marczykowski-Górecki > wrote: >> How are in practice security issues handled in Fedora? Is there an >> active security team to help patching those in timely manner? Or is

Re: Fedora 33 redhat-rpm-config package update stuck in pending

On Tue, Nov 3, 2020 at 10:13 AM Florian Weimer wrote: > > This update: > > > > appears to be stuck in the pending state. > > What can I do to move it forward? > > Thanks, > Florian There's an "Actions" dropdown next to the update'

Packaging rules for build from source vs BPF byte code ?

In QEMU there's a desire to make use of BPF programs for implementing some networking features. The current patches are proposing adding prebuilt BPF byte code to the QEMU repo, with source available, but not actually building from source during a build. I was wondering if we had any specific gui

Re: Fedora 33 redhat-rpm-config package update stuck in pending

* Fabio Valentini: > On Tue, Nov 3, 2020 at 10:13 AM Florian Weimer wrote: >> >> This update: >> >> >> >> appears to be stuck in the pending state. >> >> What can I do to move it forward? >> >> Thanks, >> Florian > > There's an "A

Depend on git-core instead of git if possible

On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote: > git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) > git.src requires cvs > git-cvs.noarch requires cvs > >( ) >requires git > > Note that if xinetd indeed goes

Re: Fedora 33 redhat-rpm-config package update stuck in pending

On Tue, Nov 3, 2020 at 11:52 AM Florian Weimer wrote: > > * Fabio Valentini: > > > On Tue, Nov 3, 2020 at 10:13 AM Florian Weimer wrote: > >> > >> This update: > >> > >> > >> > >> appears to be stuck in the pending state. > >> > >

Re: Packaging rules for build from source vs BPF byte code ?

* Daniel P. Berrangé: > In QEMU there's a desire to make use of BPF programs for implementing > some networking features. The current patches are proposing adding > prebuilt BPF byte code to the QEMU repo, with source available, but > not actually building from source during a build. > > I was wo

Re: Packaging rules for build from source vs BPF byte code ?

On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé wrote: > > In QEMU there's a desire to make use of BPF programs for implementing > some networking features. The current patches are proposing adding > prebuilt BPF byte code to the QEMU repo, with source available, but > not actually building fro

Re: Packaging rules for build from source vs BPF byte code ?

On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote: > On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé > wrote: > > > > In QEMU there's a desire to make use of BPF programs for implementing > > some networking features. The current patches are proposing adding > > prebuilt BPF byte

Re: Packaging rules for build from source vs BPF byte code ?

On Tue, Nov 03, 2020 at 11:58:32AM +0100, Florian Weimer wrote: > * Daniel P. Berrangé: > > > In QEMU there's a desire to make use of BPF programs for implementing > > some networking features. The current patches are proposing adding > > prebuilt BPF byte code to the QEMU repo, with source avail

Re: Packaging rules for build from source vs BPF byte code ?

* Daniel P. Berrangé: > On Tue, Nov 03, 2020 at 11:58:32AM +0100, Florian Weimer wrote: >> * Daniel P. Berrangé: >> >> > In QEMU there's a desire to make use of BPF programs for implementing >> > some networking features. The current patches are proposing adding >> > prebuilt BPF byte code to th

Re: Packaging rules for build from source vs BPF byte code ?

On Tue, Nov 03, 2020 at 11:13:53AM +, Daniel P. Berrangé wrote: > On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote: > > On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé > > wrote: > > > > > > In QEMU there's a desire to make use of BPF programs for implementing > > > some net

Re: Packaging rules for build from source vs BPF byte code ?

On 03.11.2020 11:48, Daniel P. Berrangé wrote: We do have the exception that allows firmware to be shipped as pre-built blobs, but I'm thinking that BPF programs could not be considered as firmware. According to Fedora packaging guidelines, all packages must be built from sources. No exception

Re: EOL and Obsoletes in Modularity

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 to be documentation on how to write it

Re: EOL and Obsoletes in Modularity

On Mon, Nov 02, 2020 at 12:33:23PM +0100, Daniel Mach wrote: > From DNF team's perspective, a packaging system is not complete without > Obsoletes. That's why we believe module Obsoletes are a must have to ensure > smooth system upgrades and regular updates on systems consuming Rawhide (or > any ot

Re: Repository metadata signing?

On Tue, Nov 3, 2020, at 12:16 AM, Marek Marczykowski-Górecki wrote: > Is there any dnf command similar to `rpm --import`, to preemptively > import the key, or the only option is to accept the prompt? I can't find > anything about it in dnf's man page... See also https://github.com/rpm-software-

Re: EOL and Obsoletes in Modularity

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 to

Re: EOL and Obsoletes in Modularity

On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar wrote: > Another option would be adding the EOL data into modules dist-git > repositories. To the same branches where modules are built from. But > a different file. Pungi would enumarate all module builds directed to > a compose, locate their dist-git sou

Re: EOL and Obsoletes in Modularity

On Tue, Nov 03, 2020 at 02:17:59PM +0100, Petr Šabata wrote: > On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar wrote: > > Another option would be adding the EOL data into modules dist-git > > repositories. To the same branches where modules are built from. But > > a different file. Pungi would enumarate

Re: EOL and Obsoletes in Modularity

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 to b

Re: Repository metadata signing?

On Tue, Nov 03, 2020 at 12:24:45AM -0500, Neal Gompa wrote: > On Tue, Nov 3, 2020 at 12:16 AM Marek Marczykowski-Górecki > wrote: > > Is it possible to enable the first one, but leave the second to the > > user, until DNF is adjusted for better UX around the keys? That would > > allow power users

Re: Depend on git-core instead of git if possible

Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a): On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote: git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) git.src requires cvs git-cvs.noarch requires cvs ( ) req

Re: EOL and Obsoletes in Modularity

On Tue, Nov 03, 2020 at 03:22:45PM +0100, Vít Ondruch wrote: > Have anybody considered to use AppData for that information? Or at least > similar approach? > I haven't. AppData looks very similar to our use case. Thanks for the pointer. -- Petr signature.asc Description: PGP signature _

Re: Self Introduction: John Kacur

On Mon, Nov 02, 2020 at 09:20:40PM -0500, John Kacur wrote: > I have mostly been a lurker when it comes to Fedora development, but > hopefully that will change soon! Welcome, and thanks for de-lurking! Let me know if there's anything I can do to help! -- Matthew Miller Fedora Project Leader ___

Re: ld segfaults on rawhide

On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes wrote: > > On Sat, Oct 31, 2020 at 10:32 AM Jeff Law wrote: > > > > > > On 10/31/20 9:13 AM, Christoph Junghans wrote: > > > Hi, > > > > > > I am getting the following error on all archs on rawhide: > > > collect2: fatal error: ld terminated with sign

Re: Depend on git-core instead of git if possible

On Tue, 3 Nov 2020 at 15:40, Vít Ondruch wrote: > > > Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a): > > On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote: > > git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) > git.src requires cvs > git-cvs.noarch requires cvs > > ( ) >

Re: Fedora Security Team

On Tue, Nov 03, 2020 at 10:02:24AM +, P J P wrote: > * Right, Fedora package CVEs and relevant bugs are filed by Red Hat Product > security team. > > * CVEs/bugs are fixed in the upstream sources first. Fedora package > maintainers do rebuild >   of the package with released fixes. I see cu

Re: Looking for sponsorship to be a package maintainer

On Mon, Nov 02, 2020 at 10:19:32PM +, Isaac True wrote: > Hello all, > > I'm hoping to become the maintainer of an orphaned package (gr-iio, GNU Radio > blocks for Analog Devices platforms) but I need some sponsorship to become a > package maintainer. The releng team recommended that I send

Re: Depend on git-core instead of git if possible

>> Or switch to depend on `%{_bindir}/git`? > > If we do it like this, we will never be able drop repo download times > for Fedora users. Files in %{_bindir} already end up in the primary metadata, don't they? Is this about removing them? They are just 36,217 lines out of 2,253,333, or something

Re: Fedora Security Team

Marek Marczykowski-Górecki wrote on Tue, Nov 03, 2020: > Do you know if some parts of the above already exist? I know Debian has > automatic checks for latest upstream versions, but I haven't seen it in > Fedora. Fedora has "Upstream Release Monitoring" https://fedoraproject.org/wiki/Upstream_rel

Re: Repository metadata signing?

On Tue, Nov 03, 2020 at 03:28:02PM +0100, Marek Marczykowski-Górecki wrote: > On Tue, Nov 03, 2020 at 12:24:45AM -0500, Neal Gompa wrote: > > On Tue, Nov 3, 2020 at 12:16 AM Marek Marczykowski-Górecki > > wrote: > > > Is it possible to enable the first one, but leave the second to the > > > user,

Re: Depend on git-core instead of git if possible

On 11/3/20 5:10 PM, clime wrote: On Tue, 3 Nov 2020 at 15:40, Vít Ondruch wrote: Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a): On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote: git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) git.src requires cvs git-cvs.noarch re

Re: ld segfaults on rawhide

On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote: > On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes wrote: > > > > On Sat, Oct 31, 2020 at 10:32 AM Jeff Law wrote: > > > > > > > > > On 10/31/20 9:13 AM, Christoph Junghans wrote: > > > > Hi, > > > > > > > > I am getting the following er

Re: ld segfaults on rawhide

On 10/31/20 4:13 PM, Christoph Junghans wrote: Hi, I am getting the following error on all archs on rawhide: collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped in https://koji.fedoraproject.org/koji/taskinfo?taskID=54629411 any ideas? Yes, see: https://list

Re: ld segfaults on rawhide

On 11/3/20 9:56 AM, Kevin Fenzi wrote: > On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote: >> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes wrote: >>> On Sat, Oct 31, 2020 at 10:32 AM Jeff Law wrote: On 10/31/20 9:13 AM, Christoph Junghans wrote: > Hi, > > I am

Re: ld segfaults on rawhide

On 11/3/20 6:08 PM, Jeff Law wrote: On 11/3/20 9:56 AM, Kevin Fenzi wrote: On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote: On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes wrote: On Sat, Oct 31, 2020 at 10:32 AM Jeff Law wrote: On 10/31/20 9:13 AM, Christoph Junghans wrote: H

Re: Depend on git-core instead of git if possible

Dne 03. 11. 20 v 17:55 Miro Hrončok napsal(a): On 11/3/20 5:10 PM, clime wrote: On Tue, 3 Nov 2020 at 15:40, Vít Ondruch wrote: Dne 03. 11. 20 v 11:54 Petr Pisar napsal(a): On Mon, Nov 02, 2020 at 12:03:12PM +0100, Miro Hrončok wrote: git (amahdal, besser82, chrisw, pcahyna, pstodulk, ski

Re: ld segfaults on rawhide

On Tue, Nov 3, 2020 at 11:17 AM Miro Hrončok wrote: > > On 11/3/20 6:08 PM, Jeff Law wrote: > > > > On 11/3/20 9:56 AM, Kevin Fenzi wrote: > >> On Tue, Nov 03, 2020 at 09:57:48AM -0600, Justin Forbes wrote: > >>> On Mon, Nov 2, 2020 at 10:38 AM Justin Forbes > >>> wrote: > On Sat, Oct 31, 2

Re: Depend on git-core instead of git if possible

On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote: > > >> Or switch to depend on `%{_bindir}/git`? > > > > If we do it like this, we will never be able drop repo download times > > for Fedora users. > > Files in %{_bindir} already end up in the primary metadata, don't they? Ok, I didn't know that

Re: Depend on git-core instead of git if possible

Dne 03. 11. 20 v 19:07 clime napsal(a): On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote: Or switch to depend on `%{_bindir}/git`? If we do it like this, we will never be able drop repo download times for Fedora users. Files in %{_bindir} already end up in the primary metadata, don't they?

Re: Depend on git-core instead of git if possible

On Tue, Nov 3, 2020 at 1:08 PM clime wrote: > > On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote: > > > > >> Or switch to depend on `%{_bindir}/git`? > > > > > > If we do it like this, we will never be able drop repo download times > > > for Fedora users. > > > > Files in %{_bindir} already end

Re: Repository metadata signing?

On Tue, Nov 03, 2020 at 08:52:09AM -0800, Kevin Fenzi wrote: > Yes, it's possible... but it needs work in both pungi and robosignatory. Oh, that's unfortunate. I thought it was already supported. > If you're interested in moving it forward, please work with the > robosignatory and pungi develope

Re: Depend on git-core instead of git if possible

On Tue, 3 Nov 2020 at 19:25, Neal Gompa wrote: > > On Tue, Nov 3, 2020 at 1:08 PM clime wrote: > > > > On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote: > > > > > > >> Or switch to depend on `%{_bindir}/git`? > > > > > > > > If we do it like this, we will never be able drop repo download times

Re: Depend on git-core instead of git if possible

On Tue, 3 Nov 2020 at 21:22, clime wrote: > > On Tue, 3 Nov 2020 at 19:25, Neal Gompa wrote: > > > > On Tue, Nov 3, 2020 at 1:08 PM clime wrote: > > > > > > On Tue, 3 Nov 2020 at 17:42, Florian Weimer wrote: > > > > > > > > >> Or switch to depend on `%{_bindir}/git`? > > > > > > > > > > If we d

Re: [Fedocal] Reminder meeting : Prioritized bugs and issues

On Tue, Nov 3, 2020 at 6:01 AM wrote: > > You are kindly invited to the meeting: >Prioritized bugs and issues on 2020-11-04 from 11:00:00 to 12:00:00 > America/Indiana/Indianapolis >At fedora-meet...@irc.freenode.net > > The meeting will be about: > Evaluation meeting > > More information

Fedora-IoT-33-20201104.1 compose check report

No missing expected images. Failed openQA tests: 1/16 (x86_64), 2/15 (aarch64) New failures (same test not failed in Fedora-IoT-33-20201102.0): ID: 714779 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/714779 ID: 714787 Test: aarch64

Fedora-Cloud-33-20201104.0 compose check report

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-20201103.0): ID: 714798 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op