Re: Unable to disable SysRq

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, but after boot the value is 64, only after a single user mode boot the

Fedora-Cloud-33-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-33-20201116.0): ID: 723455 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: Self Introduction - Jason Edgecombe

On Sun, Nov 15, 2020 at 5:13 PM Jason Edgecombe wrote: > In my personal time, I'm learning a little about fedora packaging in order > to build some Fedora packages on RHEL8/CENTOS8 for my personal use. I'm > somewhat familiar with RPM spec files and building RPMs. Welcome Jason! - Ken __

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

On Mon, Nov 16, 2020 at 1:39 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sun, Nov 15, 2020 at 04:28:36PM -0700, Chris Murphy wrote: > > On Sun, Nov 15, 2020 at 4:12 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote: > > > > * Name: [

Unable to disable SysRq

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, starting that way the SysRq i command.

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

On Mon, 2020-11-16 at 22:07 +, Zbigniew Jędrzejewski-Szmek wrote: > > I have no beef with using a spec file in the upstream repo for CI. I > would do things differently myself, but that doesn't really matter. > I'm only trying to push back against complaints about changes pushed to > dist-git.

Re: NEEDINFO nag 2 days after bug creation?

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 The script runs every 3 weeks, on

NEEDINFO nag 2 days after bug creation?

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 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe sen

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

On Mon, Nov 16, 2020 at 03:31:08PM -0500, Rob Crittenden wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote: > >> On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote: > >>> > >>> (More generally: what would the point of k

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

On Thu, 2020-11-05 at 07:58 -0500, Nico Kadel-Garcia wrote: > On Thu, Nov 5, 2020 at 6:39 AM Petr Menšík wrote: > > No, no, NO again. > > > > nscd has no important active bugs in Fedora. I am not sure what bugs are > > mentioned, but just a few active bugs are on glibc component in Fedora. > > Th

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

On 11/15/20 4:31 PM, Lennart Poettering wrote: > On So, 15.11.20 10:18, Marius Schwarz (fedora...@cloud-foo.de) wrote: > >> Am 11.11.20 um 16:58 schrieb Lennart Poettering: >>> So if you configure 4 DNS servers then each will still get roughly >>> 1/4th of your requests? That's still quite a lot

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

Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote: >> On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote: >>> >>> (More generally: what would the point of keeping an "upstream" spec >>> file be? >> >> One common reason is to integ

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

On Mon, Nov 16, 2020 at 07:45:54AM -0500, Stephen John Smoogen wrote: > On Sun, 15 Nov 2020 at 19:26, Chris Adams 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

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

On Mon, Nov 16, 2020 at 09:01:15AM -0800, Adam Williamson wrote: > On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote: > > > > (More generally: what would the point of keeping an "upstream" spec > > file be? > > One common reason is to integrate maintenance and testing with code

Re: Fedora 32: systemd-homed started, but not enabled or needed

On 16.11.2020 20:56, Marius Schwarz wrote: Any ideas how to disable it permanently? sudo systemctl disable systemd-homed.service sudo systemctl mask systemd-homed.service Is masking the service file enough? Yes. Masked service will never be enabled again. -- Sincerely, Vitaly Zaitsev (v

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

Am 16.11.20 um 00:36 schrieb Samuel Sieb: DoT becomes efficient when we can reuse the established TCP/TLS connection for multiple lookups. But if we'd switch servers all the time, then of course there's no reuse of TCP/TLS connections possible. Same thing here.  Would it be a problem to keep a

Fedora 32: systemd-homed started, but not enabled or needed

Hi, after upgrading from F31 to F32, systemd-homed was running, but according to systemctl it never got enabled and is referenced by static link of some kind: ...     ├─systemd-homed     ├─systemd-journal     ├─systemd-logind     ├─systemd-udevd     ├─systemd-userdbd───3*[

Java reviews (with swaps)

Hi all, I would like to ask for some input from those of you with Java packaging experience. The jsonp package has been orphaned, but the antlr4-project package (which I maintain) still needs it. Since jsonp has transitioned to the eclipse-ee4j project, I thought it best to let the current jsonp

Re: finding recursive builddeps

On Sunday, November 15, 2020 4:10:03 PM CET Jason Edgecombe wrote: > Hi everyone, > > I want to rebuild some of the fedora 33 packages for EL8 (vagrant, for > example), but I'm having trouble getting all of the build dependencies > right. I ran dnf to download the SRPMS with the --resolve option,

[Test-Announce] Proposal to CANCEL: all Fedora QA meetings in December

Hi folks! I'm going to be off work from December 7 to January 4 (got a lot of unused vacation time to use up). December's generally slow because of RH folks taking time off, and so I'm proposing in advance we just skip all the QA meetings in the month - Dec 7, 14, 21 and 28. I'll plan to schedule m

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

On Mon, 2020-11-16 at 09:22 +, Zbigniew Jędrzejewski-Szmek wrote: > > (More generally: what would the point of keeping an "upstream" spec > file be? One common reason is to integrate maintenance and testing with code maintenance and testing, particularly to include package builds in CI runs.

Re: review-stats bot spamming "failed to clear NEEDINFO" messages

Il 16/11/20 09:29, Artur Frenszek-Iwicki ha scritto: >> a) failing to check if the NEEDINFO flag is set for the *submitter*, >>instead of a reviewer >> b) failing to clear the NEEDINFO flag for the submitter > Oops, I barely posted the message and I already spotted that I'm wrong. > > The NEEDI

Re: Two questions on updates

On Mon, Nov 16, 2020 at 5:14 PM Jerry James wrote: > > On Mon, Nov 16, 2020 at 9:09 AM Fabio Valentini wrote: > > Normal updates need at *least* +2 karma so they can be pushed to > > stable *manually*. > > The default of +3 karma only makes bodhi push updates to stable > > *earlier* automatically

Re: Two questions on updates

On Mon, Nov 16, 2020 at 9:09 AM Fabio Valentini wrote: > Normal updates need at *least* +2 karma so they can be pushed to > stable *manually*. > The default of +3 karma only makes bodhi push updates to stable > *earlier* automatically, instead of after 7 days. Gotcha. Somehow I've missed that al

Re: Two questions on updates

On Mon, Nov 16, 2020, 16:54 Jerry James wrote: > > I got email today telling me that this update can be pushed stable now: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-6960d09c20 > > Question 1: why is that? The update needs to be in testing for 7 days > or receive karma of 3 or more.

Two questions on updates

I got email today telling me that this update can be pushed stable now: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6960d09c20 Question 1: why is that? The update needs to be in testing for 7 days or receive karma of 3 or more. It has been in testing for 4 days and has karma of 2. Why

Fedora-IoT-34-20201116.0 compose check report

No missing expected images. Failed openQA tests: 7/15 (aarch64), 2/16 (x86_64) New failures (same test not failed in Fedora-IoT-34-20201115.0): ID: 723431 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/723431 ID: 723435 Test: aarch64

Fedora-Rawhide-20201116.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: 14/115 (aarch64), 14/177 (x86_64) New failures (same test not failed in Fedora-Rawhide-20201115.n.0): ID: 723164 Test: aarch64 Server-dvd-iso install_r

Fwd: Fedora python-lark-parser maintenance

Hello. Does anybody know how to reach Thomas Andrejak (totol)? https://bugzilla.redhat.com/show_bug.cgi?id=1898124 Forwarded Message Subject: Fedora python-lark-parser maintenance Date: Mon, 2 Nov 2020 14:01:15 +0100 From: Miro Hrončok Organization: Red Hat To: Thomas Andreja

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

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. Most of casual packagers simply ignore all p

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

On Sun, 15 Nov 2020 at 19:26, Chris Adams 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 different DNS ser

Re: can't find the format file `latex.fmt' on Rawhide

On Sun, Nov 15, 2020 at 11:25 PM Christoph Junghans wrote: > > On Fri, Nov 13, 2020 at 8:19 AM Christoph Junghans wrote: > > > > Hi, > > > > Using latex in Docker on Rawhide gives an "I can't find the format > > file `latex.fmt'!" error. > > I have seen this before but I don't recall how to fix i

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

Am 16.11.20 um 13:16 schrieb Vitaly Zaitsev via devel: The main upstream for Fedora packages is the Fedora Package Sources. If the package need to be fixed, it must be fixed. I agree with you here. The only point (though important imho) I want to make is that provenpackagers should not "circu

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

On 16.11.2020 11:33, Felix Schwarz wrote: I think the main idea is that we try not to create artificial "hierarchies". Especially for a volunteer maintainer who maintains a few packages there might be a pretty strong emotional attachment to his packages which try to keep up to the highest packa

Fedora rawhide compose report: 20201116.n.0 changes

OLD: Fedora-Rawhide-20201115.n.0 NEW: Fedora-Rawhide-20201116.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 54 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size

Re: transmission-remote-gtk pull requests

Thanks for the reply. Considering transmission-remote-gtk is about to get new release according to https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/109#issuecomment-727668394 I'll wait a bit, redo my pull requests and open bugzilla report then.

Re: transmission-remote-gtk pull requests

Hi Łukasz, Łukasz Patron writes: > Hi, > > I've been trying to get these two pull requests reviewed / merged > https://src.fedoraproject.org/rpms/transmission-remote-gtk/pull-request/1, > https://src.fedoraproject.org/rpms/transmission-remote-gtk/pull-request/2 but > I can't seem to get anyo

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 16 November (today)

Hello everyone, Please join us at the next Open NeuroFedora team meeting today on Monday 16 November at 1300UTC in #fedora-neuro on IRC (Freenode). The meeting is a public meeting, and open for everyone to attend. https://webchat.freenode.net/?channels=#fedora-neuro The channel is bridged to Tel

Fedora-Cloud-31-20201116.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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

Am 16.11.20 um 10:28 schrieb Miro Hrončok: If it is not urgent, provnpackagers should not go and make packaging changes without talking to the maintainer first. +1 I think the main idea is that we try not to create artificial "hierarchies". Especially for a volunteer maintainer who maintains

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

Dne 16. 11. 20 v 10:22 Zbigniew Jędrzejewski-Szmek napsal(a): On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote: On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý wrote: Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a): If you're going to have this kind of "upstream" spec f

Re: Self Introduction - Jason Edgecombe

On Monday, November 16, 2020 12:12:53 AM WET Jason Edgecombe wrote: > Hello everyone, Hi Jason, welcome to Fedora. :-) > 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

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

On 11/16/20 10:23 AM, Miroslav Suchý wrote: Dne 16. 11. 20 v 9:09 Elliott Sales de Andrade napsal(a): This is actually a good idea. I have lots of such spec files. Is it a good idea to document this in Packaging Guidelines? It is already in the guidelines: https://docs.fedoraproject.org/en-US/

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

Dne 16. 11. 20 v 9:09 Elliott Sales de Andrade napsal(a): >> This is actually a good idea. I have lots of such spec files. >> >> Is it a good idea to document this in Packaging Guidelines? > It is already in the guidelines: > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintena

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

On Mon, Nov 16, 2020 at 03:09:13AM -0500, Elliott Sales de Andrade wrote: > On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý wrote: > > > > Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a): > > > If you're going to have this kind of "upstream" spec file...well, I > > > wish you wouldn't. But if you do

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

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

On Sun, Nov 15, 2020 at 04:28:36PM -0700, Chris Murphy wrote: > On Sun, Nov 15, 2020 at 4:12 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Wed, Nov 04, 2020 at 01:12:44PM -0500, Ben Cotton wrote: > > > * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]], > > > [[User:jbaublitz

Re: review-stats bot spamming "failed to clear NEEDINFO" messages

>a) failing to check if the NEEDINFO flag is set for the *submitter*, > instead of a reviewer >b) failing to clear the NEEDINFO flag for the submitter Oops, I barely posted the message and I already spotted that I'm wrong. The NEEDINFO flag, in this case, is set to require action from "nob...@fe

review-stats bot spamming "failed to clear NEEDINFO" messages

Recently we've had a new automation introduced, which seeks out stalled review requests and tries to prod them to move forward. One of the ways it does this is by looking at reviews which have the NEEDINFO flag set and, if the ticket reviewer failed to reply for a long time, it resets the ticket s

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

On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý wrote: > > Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a): > > If you're going to have this kind of "upstream" spec file...well, I > > wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec > > files need to have a clear explanation tha

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

Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a): > If you're going to have this kind of "upstream" spec file...well, I > wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec > files need to have a clear explanation that there is an "upstream" spec > file, with a justification as t