Fedora-Cloud-33-20201118.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-20201117.0): ID: 724374 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Announcement: orphaning java-comment-preprocessor

Hello, orphaning java-comment-preprocessor due to missing dependencies for the new version (cannot be rebased) and no other package dependents on it. Regards, Ondrej ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email t

Fedora-Rawhide-20201117.n.0 compose check report

Missing expected images: Xfce raw-xz armhfp Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 9/177 (x86_64), 14/115 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201116.n.0): ID: 724111 Test: x86_64 Workstation-live-iso deskt

[Heads up] Rubberband bugfix update

Dear maintainers, I've built updates bringing Rubberband to version 1.9.0: F33: https://bodhi.fedoraproject.org/updates/FEDORA-2020-378d450ffb F32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a3ca9c95c2 EPEL8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3d4e57454b It's a bugf

Fedora rawhide compose report: 20201117.n.0 changes

OLD: Fedora-Rawhide-20201116.n.0 NEW: Fedora-Rawhide-20201117.n.0 = SUMMARY = Added images:4 Dropped images: 0 Added packages: 15 Dropped packages:0 Upgraded packages: 83 Downgraded packages: 0 Size of added packages: 18.36 MiB Size of dropped packages:0

Fedora-IoT-33-20201117.0 compose check report

No missing expected images. Failed openQA tests: 1/16 (x86_64), 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-33-20201114.0): ID: 723973 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/723973 ID: 723989 Test: aarch64 IoT-dvd_ostree-i

Re: Unable to disable SysRq

On Tue, Nov 17, 2020 at 04:08:19PM +0100, Vitaly Zaitsev via devel wrote: > That's why all user-space "OOM killers" must have the following > lines in their .service files: > > DynamicUser=true > AmbientCapabilities=CAP_KILL CAP_IPC_LOCK > ProtectSystem=strict > ProtectHome=true > > I think FESCo

Re: Self Introduction - Jason Edgecombe

On Sun, Nov 15, 2020 at 07:12:53PM -0500, Jason Edgecombe wrote: > I'm a Linux admin at a university supporting around 100+ EL7/8 and Ubuntu > machines. I've been using Linux as a hobby since around 1994 and > professionally since 1999. My first Linux experience was installing > Slackware from fl

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

Vitaly Zaitsev via devel writes: > On 17.11.2020 18:45, Robbie Harwood wrote: >> Just because it's easier not to follow expected process doesn't mean >> they shouldn't. > > Patching packages by proven packages is a completely normal workflow. Something being normal doesn't mean it's good. >> If

Schedule for Wednesday's FESCo Meeting (2020-11-18)

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-11-18 15:00 UTC' Links to all issues to

Re: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)

On Thu, Nov 05, 2020 at 02:06:37PM +0100, Michal Schorm wrote: > On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini wrote: > > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton wrote: > > > == Contingency Plan == > > > > > > Modules will provide the functional version of MariaDB 10.4, available to > > > a

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

On Tue, Nov 17, 2020 at 12:43 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 17.11.2020 09:46, Felix Schwarz wrote: > > I think this is the root cause and a real problem (I complained about > > this myself several few times on this list). > > Yes, ofc. I've submitted mult

Re: Fedora 34 Change proposal: Stratis 2.2.0 (Self-Contained Change)

Good feedback. I'll adjust the document to integrate your suggestions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

On 17.11.2020 09:46, Felix Schwarz wrote: I think this is the root cause and a real problem (I complained about this myself several few times on this list). Yes, ofc. I've submitted multiple PRs. Some of them haven't been merged. Later I got these packages through the Non-responsive maintainer

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

On 17.11.2020 18:45, Robbie Harwood wrote: Just because it's easier not to follow expected process doesn't mean they shouldn't. Patching packages by proven packages is a completely normal workflow. If waiting too long is a problem, set a timeout - send a PR, if it's not merged in two weeks th

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

Matthew Miller writes: > On Fri, Nov 13, 2020 at 10:52:57PM +0100, Kevin Kofler via devel wrote: >> > I completely agree. This is one of the reasons I switched away from >> > ubuntu years ago (with its 4 (?) tiers of support + repos for its >> > packages ...). >> I agree, Fedora did the Core-Extr

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

Vitaly Zaitsev via devel writes: > On 16.11.2020 13:35, Felix Schwarz wrote: >> The only point (though important imho) I want to make is that >> provenpackagers should not "circumvent" the package maintainer by >> default - even though I can imagine it is way faster just to push your >> change

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

On 11/17/20 4:24 AM, Lennart Poettering wrote: dig @9.9.9.9 +nsid heise.de FWIW, a neat way to look at differences like that is     watch -d dig @9.9.9.9 +nsid heise.de I use it often for looking at hotplugs (watch -d lsusb) etc. ___ devel mailing

Re: AAC-Main patent expiration

We do have FDK-AAC-Free imported for a while. Some functionality was patched out due to various concerns: *https://src.fedoraproject.org/rpms/fdk-aac-free * https://cgit.freedesktop.org/~wtay/fdk-aac/log/?h=fedora вт, 17 нояб. 2020 г. в 16:42, Igor Bukanov : > > AAC-Main audio encoder/decoder pro

Re: AAC-Main patent expiration

On Tue, Nov 17, 2020 at 10:42 AM Igor Bukanov wrote: > > AAC-Main audio encoder/decoder profile was specified as a part of > https://www.iso.org/standard/25035.html standard. That was published in > December 1999. Does it mean that software implementing it like ffmpeg in its > default configur

AAC-Main patent expiration

AAC-Main audio encoder/decoder profile was specified as a part of https://www.iso.org/standard/25035.html standard. That was published in December 1999. Does it mean that software implementing it like ffmpeg in its default configuration can be included into Fedora starting from January 2021? R

Re: NEEDINFO nag 2 days after bug creation?

On Mon, Nov 16, 2020 at 5:10 PM Miro Hrončok wrote: > On 11/16/20 11:31 PM, Richard Shaw wrote: > > The logic behind the NEEDINFO stuff may need to be updated... The > subject says > > it all and it's quite annoying. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1897496 > >

Re: Unable to disable SysRq

On 17.11.2020 13:26, Robert Marcano via devel wrote: User d9k on IRC found the culprit. It is low-memory-monitor. The latest commit [1] for it tries to not mess with the value with 1 is set, but it should not mess with it ever. That's why all user-space "OOM killers" must have the following li

Re: Looking for sponsorship to be a package maintainer

Hi Mattia, The package has now been reviewed and approved: https://bugzilla.redhat.com/show_bug.cgi?id=1894726 I haven't had any offers for sponsorship on the mailing list so I'll try posting an issue on "packager-sponsors." Cheers, Isaac ‐‐‐ Original Message ‐‐‐ On Wednesday, Novemb

Re: Two questions on updates

On Tue, Nov 17, 2020 at 1:25 PM Kevin Kofler via devel wrote: > > Fabio Valentini wrote: > > Normal updates need at *least* +2 karma so they can be pushed to > > stable *manually*. > > Uh, last I checked, normal updates need only +1 (and that's a good thing, > many updates don't even get +1 in a r

Re: Unable to disable SysRq

On 11/17/20 8:26 AM, Robert Marcano wrote: User d9k on IRC found the culprit. It is low-memory-monitor. The latest commit [1] for it tries to not mess with the value with 1 is set, but it should not mess with it ever. The same documentation on that commit references [2] where it says: Note

Re: Unable to disable SysRq

On Tue, Nov 17, 2020 at 01:10:02PM +0100, Kevin Kofler via devel wrote: > Robert Marcano via devel wrote: > > Two times in a week I have killed all processes trying to use Alt+i. Ts > > is to easy to press the Alt and the PrtScr at the same, starting that > > way the SysRq i command. > > > > So be

Re: Unable to disable SysRq

On 11/16/20 8:25 PM, Robert Marcano wrote: I am using a ThinkPad with one of these keyboards where the PrtScr key is between the right Alt and Ctrl, an awful position. Two times in a week I have killed all processes trying to use Alt+i. Ts is to easy to press the Alt and the PrtScr at the same

Re: Two questions on updates

Fabio Valentini wrote: > Normal updates need at *least* +2 karma so they can be pushed to > stable *manually*. Uh, last I checked, normal updates need only +1 (and that's a good thing, many updates don't even get +1 in a reasonable time frame, let alone +2). Only critical path packages and (IIRC

Re: Unable to disable SysRq

Robert Marcano via devel wrote: > Two times in a week I have killed all processes trying to use Alt+i. Ts > is to easy to press the Alt and the PrtScr at the same, starting that > way the SysRq i command. > > So before staring to write a kernel patch to add an option where the > SysRq is only trig

Re: Unable to disable SysRq

On Mon, Nov 16, 2020 at 11:35:41PM -0800, Samuel Sieb wrote: > On 11/16/20 4:25 PM, Robert Marcano via devel wrote: > >My Fedora 33 kernel.sysrq value is 80, the default at > >/usr/lib/sysctl.d/50-default.conf say that it should be 16. > > > >Created /etc/sysctl.d/99-local.conf with kernel.sysrq=0,

Fedora-Cloud-31-20201117.0 compose check report

No missing expected images. Passed openQA tests: 7/7 (x86_64), 7/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le..

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

On So, 15.11.20 18:25, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Stephen John Smoogen said: > > Because a lot of networks use routing tricks to send traffic to particular > > DNS server IP addresses. They may round robin, traffic route, or other > > methods to send you to differe

Fedora-Cloud-32-20201117.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-20201116.0): ID: 723519 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

On So, 15.11.20 15:36, Samuel Sieb (sam...@sieb.net) wrote: > On 11/15/20 7:31 AM, Lennart Poettering wrote: > > Implementing this does not come without drawbacks though: right now > > resolved tries hard to use the same server if at all possible, since > > we want to use newer DNS features if pos

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

On Mo, 16.11.20 21:48, Petr Menšík (pemen...@redhat.com) wrote: > But it does not have to learn everything about a server, because it > switched the active one. If it has to, try to find way to store server > instance features per server IP, not per link. We do exactly this. But we also have a gr

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

Am 16.11.20 um 14:03 schrieb Vitaly Zaitsev via devel: Most of casual packagers simply ignore all pull requests and don't even check their mail. It is much more easier to fix the package manually than waiting 2-3 weeks for a response. I think this is the root cause and a real problem (I compl