Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[ego . cordatus]

В Суб, 04/01/2020 в 08:27 +0100, Vitaly Zaitsev via devel пишет:

> I'm strongly against adding of any user-space OOM killers to Fedora
> default images. Users should explicitly enable them only when needed.

Just my 2 cents: i tested early versions of earlyoom and have weird
experience with it: it killing not Chromium or Chromium processes,
instead it killing tiny processes which it shouldn't, probably. I guess
it could kill dnf process as well easily.

I am skeptically too about enabling such things by default, but in same
time would be nice to massively test this.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[Vitaly Zaitsev via devel]

On 03.01.2020 20:01, Michael Schwendt wrote:
> Which is something you can only fix with an RPM Fusion package,
> if you "control" (= build) all depending packages.

RPM Fusion will need to copy and rebuild all such packages and this is a
huge headache for maintainers and currently forbidden by repo's policy.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vitaly Zaitsev via devel]

On 03.01.2020 22:27, Neal Gompa wrote:
> and servers...

Admins will be very happy when such user-space killer will kill for
example PgSQL database server and cause DB corruption or loss of banking
transactions.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Vitaly Zaitsev via devel]

On 03.01.2020 20:18, Ben Cotton wrote:
> Workstation working group has discussed "better interactivity in
> low-memory situations" for some months. In certain use cases,
> typically compiling, if all RAM and swap are completely consumed,
> system responsiveness becomes so abysmal that a reasonable user can
> consider the system "lost", and resorts to forcing a power off. This
> is objective a very bad UX.

I'm strongly against adding of any user-space OOM killers to Fedora
default images. Users should explicitly enable them only when needed.

1. Such applications run with super-user privileges and has full access
to all private memory of all processes and sensitive user data. This is
a huge security breach.

2. It can easily kill KDE/Gnome shell or VM hypervisor, which can cause
data loss.

3. Some implementations are killing all processes with the same name[1]
and their developers think that this is a feature.

4. Super-user daemons should not touch userspace at all. A real
user-space OOM should run with privileges of the same user using
system-user units.

[1]: https://gitlab.freedesktop.org/hadess/low-memory-monitor/issues/8


-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Andreas Tunek]

Den lör 4 jan. 2020 kl 01:53 skrev John M. Harris Jr :

> On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote:
> > in the cases were I could issue syrq+b, responsiveness was so bad
> > it'd take upwards of 15 minutes just to type out the command
>
> In that case, I'd suggest waiting the 15 minutes, and then not bogging
> down
> your system that badly the next time. This is, really, the best option.
>
>
*Remembers to be excellent to each other.*
Or maybe we should try to make operating systems that actually work under
heavy load.

/Andreas


> --
> John M. Harris, Jr.
> Splentity
>
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. wine, dosbox, nextcloud, owncloud)

[Artem Tim]

WINE worries me a lot. Why previous maintainer dropped it? I never have issues 
with WINE package and it was always up to day. Hope someone will save package.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What happened to fedabipkgdiff?

[Richard Shaw]

On Fri, Jan 3, 2020 at 8:41 PM Neal Gompa  wrote:

> On Fri, Jan 3, 2020 at 9:15 PM Richard Shaw  wrote:
> >
> > It no longer seems to be a part of libabigail (or available at all)...
> >
> > I found it very useful.
> >
>
> It moved to the libabigail-fedora package in Fedora 31.
>

Thanks, I tried a direct "dnf install /usr/bin..." approach but must have
typo'd it.

Richard
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What happened to fedabipkgdiff?

[Neal Gompa]

On Fri, Jan 3, 2020 at 9:15 PM Richard Shaw  wrote:
>
> It no longer seems to be a part of libabigail (or available at all)...
>
> I found it very useful.
>

It moved to the libabigail-fedora package in Fedora 31.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

What happened to fedabipkgdiff?

[Richard Shaw]

It no longer seems to be a part of libabigail (or available at all)...

I found it very useful.

Thanks,
Richard
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: koji / bodhi issues status update

[Kevin Fenzi]

On Fri, Jan 03, 2020 at 11:55:27PM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > However, due to the koji issues builds were in a state where bodhi
> > ejected many of them from updates pushes. We are working on cleaning
> > up the state of those updates and there's no need for maintainers to do
> > anything with those updates at this time.
> 
> At least in this case:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-cd4008c5ce
> the reason for the ejection appears to be that Bodhi believes that this 
> update is still pending, but Koji has it already tagged 
> f31-updates-testing (not f31-updates-candidate).
> 
> I guess other ejected updates must be in a similarly inconsistent state.

Yes, they are all because bodhi started composing them, moved their tags
and then failed (because koji wasn't tagging things in a timely manner). 

So, they need to be retagged back and resubmitted, or bodhi tweaked to
see that it's already moved tags and continue processing them. 

In any case, we plan to do this, so if maintainers could please avoid
editing/pushing/unpushing/tweaking or moving these around while we try
and fix it that would be great. 

kevin


signature.asc
Description: PGP signature
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[John M. Harris Jr]

On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote:
> in the cases were I could issue syrq+b, responsiveness was so bad
> it'd take upwards of 15 minutes just to type out the command

In that case, I'd suggest waiting the 15 minutes, and then not bogging down 
your system that badly the next time. This is, really, the best option.

-- 
John M. Harris, Jr.
Splentity

___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: lv2-sorcer is not installable

[Kevin Kofler]

Fabio Valentini wrote:
> Don't blame Miro for doing the necessary things, just because you don't
> like the process.

The issue is that I do not agree that this process is necessary to begin 
with.

> We have asked you multiple times to suggest a policy that works for you
> too, but you haven't done that,

I have. The policy that I have suggested is to just do nothing. FTBFS by 
itself has no impact whatsoever on end users. Only if the package actually 
does not install and/or run, it is appropriate to file a bug, and if that 
bug is not acted upon and cannot be easily fixed by a provenpackager due to 
the FTBFS, to initiate the (existing) non-responsive maintainer policy.

You may not like that proposal, which is your right, but please do not claim 
that it does not exist.

Intermediate concepts between my proposal and the status quo could also be 
considered, e.g., retire the packages if nothing depends on them, but if 
retiring some particular package would break some other package, do nothing 
for that particular package.

> instead you only insulted community members.

As far as I can remember, I have not insulted people. I have only described 
processes (not people) with negative terms that I do not believe to be 
insults (such as "broken" or "defeats all common sense"), and I believe that 
criticism to be objectively true. I am sorry if that offends any of you.

Kevin Kofler
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

On Fri, Jan 3, 2020 at 4:13 PM Tom Seewald  wrote:
>
> I think this would be a really big improvement for workstation and other 
> desktop spins, the handling of out of memory situations have been a 
> consistent paint point on Linux.  However, may I ask why EarlyOOM was chosen 
> over something like NoHang [1]?

The developer/maintainer of nohang (hakavlad) recommended earlyoom.

> I am a bit concerned that EarlyOOM's heuristics may be too coarse, as it does 
> not take into account the newly-added PSI metrics [2][3] that other projects 
> like NoHang, oomd, and low-memory-monitor utilize.  For example, if the 
> system is thrashing, but swap is not full, to my knowledge EarlyOOM will not 
> see a problem, however it would be visible via PSI.

Yep, I wonder about this myself and mention it in the two issues we're
tracking. It's likely true that there will be workloads where earlyoom
doesn't help, but equally important is it doesn't make things worse
(or really weird). It's a complicated problem, and part of the
challenge is how to go about making an incremental improvement while
avoiding regressions.

We also have another issue, #120, to look at making swap smaller,
which absolutely exacerbates the swap thrashing problem. Once a system
is swap thrashing, responsiveness is already cratering.

> To be clear, I'd rather have something in time for 32 to improve OOM handling 
> than wait several release cycles for the ideal solution to be ready.  I'm 
> simply curious about what problems, if any, were encountered with the other 
> potential candidates.

Those discussions you'll find in #98, including oomd and low-memory-monitor.
https://pagure.io/fedora-workstation/issue/98#comment-590690



-- 
Chris Murphy
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

On Fri, Jan 3, 2020 at 3:57 PM John M. Harris Jr  wrote:
>
> There is NO scenario in which hard shutdowns should occur, except battery
> failure on mobile devices. The state of the system on boot will vary wildly
> from what you may expect when it is hard powered off. I would suggest using
> SysRq in such events.

Yes I know all about sysrq. Everyday ordinary users do not, and I'm
not going to teach them about it because

a) I already know the outcome: eyes glaze over, then they say "yeah
whatever I'll just force power off, works fine - except for the data
loss"
b) much of the time, I couldn't get to a VT, and sshd was hung or even
got killed by oom-killer. So I couldn't do sysrq anyway.
c) in the cases were I could issue syrq+b, responsiveness was so bad
it'd take upwards of 15 minutes just to type out the command

So yeah, screw it, I'm pressing the power button

These aren't contrived cases. They are real world. Baremetal and VM
reproducible. And unprivileged processes. This is fully discussed in
detail in the devel@ thread I reference in the proposal, and I'm not
going to repeat myself in this thread.

-- 
Chris Murphy
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Kevin Kofler]

John M. Harris Jr wrote:
> There is NO scenario in which hard shutdowns should occur, except battery
> failure on mobile devices. The state of the system on boot will vary
> wildly from what you may expect when it is hard powered off. I would
> suggest using SysRq in such events.

Unfortunately, SysRq does nothing by default on Fedora, for security 
reasons.

Kevin Kofler
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Tom Seewald]

I think this would be a really big improvement for workstation and other 
desktop spins, the handling of out of memory situations have been a consistent 
paint point on Linux.  However, may I ask why EarlyOOM was chosen over 
something like NoHang [1]?  I am a bit concerned that EarlyOOM's heuristics may 
be too coarse, as it does not take into account the newly-added PSI metrics 
[2][3] that other projects like NoHang, oomd, and low-memory-monitor utilize.  
For example, if the system is thrashing, but swap is not full, to my knowledge 
EarlyOOM will not see a problem, however it would be visible via PSI.

To be clear, I'd rather have something in time for 32 to improve OOM handling 
than wait several release cycles for the ideal solution to be ready.  I'm 
simply curious about what problems, if any, were encountered with the other 
potential candidates.

[1] https://github.com/hakavlad/nohang
[2] https://facebookmicrosites.github.io/psi/docs/overview
[3] https://www.kernel.org/doc/html/latest/accounting/psi.html
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Kevin Kofler]

drago01 wrote:
> The idea might be the implementation is not.
> Using a percentage to decide "almost out of memory" is going to hurt on
> systems with large amounts of memory be it a 32gb desktop or a 2tb server.
> You'd have plenty of memory left and it starts killing processes ...

And it will lead to the opposite problem on systems with lots of swap (e.g., 
my desktop PC that still follows the swap = 2 * RAM recommendation and hence 
has 16 GiB of RAM and 32 GiB of swap): processes can do a lot of swap 
thrashing in 32 * (1-10%) = 28.8 GiB of swap and still ruin the system 
interactivity.

OOM handling really needs to use some interactivity metric, and I think this 
can almost certainly be done reliably only in the kernel, because userspace 
processes do not even get to run if the interactivity is already ruined.

Kevin Kofler
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[John M. Harris Jr]

On Friday, January 3, 2020 3:48:50 PM MST Chris Murphy wrote:
> On Fri, Jan 3, 2020 at 1:51 PM Robbie Harwood  wrote:
> 
> >
> >
> > Another thought.  Wouldn't some of the pain here be alleviated by
> > setting vm.swappiness=0?
> 
> 
> My sample size is not scientific. But, in my testing I can't tell any
> difference for the swap under pressure case we're testing against. The
> system is lost in the same amount of time, system still does not
> recover on its own. Perhaps swappiness matters for the less extreme
> case of incidental swap usage, which is probably what swap was
> originally intended for (?) but that's speculation on my part.
> 
> The central problem as I see it, unprivileged applications *by
> default* are given a memory allocation that they request, without any
> consideration for the health of other processes, even privileged
> processes.
> 
> The kernel oom-killer (with or without earlyoom running), often
> clobbers things like sshd, systemd-journald, sssd, and even user space
> programs (Maps, TextEdit, Terminal) that have nothing to do with
> what's actually eating up CPU and memory. It's pretty atrocious, but
> I've editorialized plenty about that in the cited threads already.
> 
> People smarter than I am are working on more long term solutions for
> this. This is a bit of a hack, intended to return some sense of
> control  back to the user sooner, so they can save their state
> (however they define that) and reboot normally, rather than having to
> force power off. It's unsophisticated and therefore mismatched with a
> complex problem, but elegant because it's simple, easy to test, easy
> to remove or disable.
> 
> Another plus I only briefly mention in the proposal, is that because
> the user is far less likely to hard power off, their system journal
> will have certainly recorded earlyoom's memory report leading up to
> the oom, as well as the complete kernel oom-killer output. Whereas in
> many of my tests without earlyoom, forced power off can cause a lot of
> this information to get lost, especially what action oom-killer took
> assuming it even triggered at all which often it doesn't and the
> system remained wedged in and  unresponsive for 30+ minutes.
> 
> 
> >Currently it seems to be 60, which results in
> >
> > somewhat aggressive swap use; 1 seems better (minimal swapping without
> > disabling), while 0 will disable it for general use (while preserving it
> > for hibernation).  This would at least improve the disk thrashing during
> > OOM situations.
> 
> 
> Sounds right, but in practice I'm not observing this. The two
> observation perspectives I'm using:
> 
> a) GUI responsiveness: ability to drag windows around, scroll in
> Firefox, type text in textedit, open/save files.
> b) remote (ssh) observation with vmstat, iotop, and top

There is NO scenario in which hard shutdowns should occur, except battery 
failure on mobile devices. The state of the system on boot will vary wildly 
from what you may expect when it is hard powered off. I would suggest using 
SysRq in such events.

-- 
John M. Harris, Jr.
Splentity

___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: koji / bodhi issues status update

[Kevin Kofler]

Kevin Fenzi wrote:
> However, due to the koji issues builds were in a state where bodhi
> ejected many of them from updates pushes. We are working on cleaning
> up the state of those updates and there's no need for maintainers to do
> anything with those updates at this time.

At least in this case:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-cd4008c5ce
the reason for the ejection appears to be that Bodhi believes that this 
update is still pending, but Koji has it already tagged 
f31-updates-testing (not f31-updates-candidate).

I guess other ejected updates must be in a similarly inconsistent state.

Kevin Kofler
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

On Fri, Jan 3, 2020 at 3:41 PM drago01  wrote:
>
>
>
> On Friday, January 3, 2020, Neal Gompa  wrote:
>>
>> On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton  wrote:
>> >
>> > https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>> >
>> > == Summary ==
>> > Install earlyoom package, and enable it by default. This will cause
>> > the kernel oomkiller to trigger sooner, but will not affect which
>> > process it chooses to kill off. The idea is to recover from out of
>> > memory situations sooner, rather than the typical complete system hang
>> > in which the user has no other choice but to force power off.
>> >
>>
>> I'd like to see this enabled on all Fedora variants by default. This
>> seems to be generally useful for workstations and servers.
>
>
> The idea might be the implementation is not.
> Using a percentage to decide "almost out of memory" is going to hurt on 
> systems with large amounts of memory be it a 32gb desktop or a 2tb server. 
> You'd have plenty of memory left and it starts killing processes ...

I agree this is the most significant liability of the proposal right
now. I mention it in:
https://pagure.io/fedora-workstation/issue/119#comment-618480

And I will add this caveat to the proposal, because at the moment I
think we need a satisfactory work around in order to proceed with
enabling this feature.


-- 
Chris Murphy
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

On Fri, Jan 3, 2020 at 1:51 PM Robbie Harwood  wrote:
>
> Another thought.  Wouldn't some of the pain here be alleviated by
> setting vm.swappiness=0?

My sample size is not scientific. But, in my testing I can't tell any
difference for the swap under pressure case we're testing against. The
system is lost in the same amount of time, system still does not
recover on its own. Perhaps swappiness matters for the less extreme
case of incidental swap usage, which is probably what swap was
originally intended for (?) but that's speculation on my part.

The central problem as I see it, unprivileged applications *by
default* are given a memory allocation that they request, without any
consideration for the health of other processes, even privileged
processes.

The kernel oom-killer (with or without earlyoom running), often
clobbers things like sshd, systemd-journald, sssd, and even user space
programs (Maps, TextEdit, Terminal) that have nothing to do with
what's actually eating up CPU and memory. It's pretty atrocious, but
I've editorialized plenty about that in the cited threads already.

People smarter than I am are working on more long term solutions for
this. This is a bit of a hack, intended to return some sense of
control  back to the user sooner, so they can save their state
(however they define that) and reboot normally, rather than having to
force power off. It's unsophisticated and therefore mismatched with a
complex problem, but elegant because it's simple, easy to test, easy
to remove or disable.

Another plus I only briefly mention in the proposal, is that because
the user is far less likely to hard power off, their system journal
will have certainly recorded earlyoom's memory report leading up to
the oom, as well as the complete kernel oom-killer output. Whereas in
many of my tests without earlyoom, forced power off can cause a lot of
this information to get lost, especially what action oom-killer took
assuming it even triggered at all which often it doesn't and the
system remained wedged in and  unresponsive for 30+ minutes.

>Currently it seems to be 60, which results in
> somewhat aggressive swap use; 1 seems better (minimal swapping without
> disabling), while 0 will disable it for general use (while preserving it
> for hibernation).  This would at least improve the disk thrashing during
> OOM situations.

Sounds right, but in practice I'm not observing this. The two
observation perspectives I'm using:

a) GUI responsiveness: ability to drag windows around, scroll in
Firefox, type text in textedit, open/save files.
b) remote (ssh) observation with vmstat, iotop, and top



-- 
Chris Murphy
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[drago01]

On Friday, January 3, 2020, Neal Gompa  wrote:

> On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/EnableEarlyoom
> >
> > == Summary ==
> > Install earlyoom package, and enable it by default. This will cause
> > the kernel oomkiller to trigger sooner, but will not affect which
> > process it chooses to kill off. The idea is to recover from out of
> > memory situations sooner, rather than the typical complete system hang
> > in which the user has no other choice but to force power off.
> >
>
> I'd like to see this enabled on all Fedora variants by default. This
> seems to be generally useful for workstations and servers.
>

The idea might be the implementation is not.
Using a percentage to decide "almost out of memory" is going to hurt on
systems with large amounts of memory be it a 32gb desktop or a 2tb server.
You'd have plenty of memory left and it starts killing processes ...
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Why does gdb dlopen() librpm instead of linking to it?

[Neal Gompa]

On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil  wrote:
>
> On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> > Can someone please explain why gdb dlopen()'s librpm instead of just
> > doing proper compile-time linking?
>
> Because when it was written (2008) it was common to transfer /usr/bin/gdb
> binary across OS versions (maybe incl. RHEL) as GDB had only very few shared
> library dependencies (no Python that time) which were ABI compatible.
> After implementing the rpm functionality the DT_NEEDED of librpm was the only
> reason why one could no longer use /usr/bin/gdb across OSes as librpm major
> version changes very often. Therefore I changed the DT_NEEDD to dlopen().
>
> Nowadays there are tons of DT_NEEDED dependencies of /usr/bin/gdb so one does
> not even think about the possibility using the binary on some other OS.
>
> You are right dlopen() could be changed to DT_NEEDED back. But then rather
> this whole librpm dependency patch is being rewritten some other ways (and it
> is longer done by me who wrote it in that 2008). That librpm dependency is
> painful anyway as librpm authors do not like it to be used by 3rd party apps
> and they prefer popen()ing some rpm commands instead:
> rpmdb locking broken by other-arch rpmquery
> https://bugzilla.redhat.com/show_bug.cgi?id=486423#c1
>

I'm not sure the comments there are still valid today. These days,
librpm is used by *a lot* of things, and the the API has been hardened
accordingly. There may be newer APIs that do it better, though, and
that's worth investigating.

>
> > Best I can tell, our patches to GDB support both modes, and it seems to be
> > unnecessarily painful for us to have to track the soversion like that
> > instead of just letting it pick it up.
>
> The positive side is that GDB handles gracefully if the librpm (of proper
> version) is missing. But the gdb.spec correctly fails to build it.
>
> gdb.spec could auto-detect the current librpm version.
>

I think it'd be nice if it auto-detected this stuff. It's weird having
to go and fix that manually.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Why does gdb dlopen() librpm instead of linking to it?

[Jan Kratochvil]

On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> Can someone please explain why gdb dlopen()'s librpm instead of just
> doing proper compile-time linking?

Because when it was written (2008) it was common to transfer /usr/bin/gdb
binary across OS versions (maybe incl. RHEL) as GDB had only very few shared
library dependencies (no Python that time) which were ABI compatible.
After implementing the rpm functionality the DT_NEEDED of librpm was the only
reason why one could no longer use /usr/bin/gdb across OSes as librpm major
version changes very often. Therefore I changed the DT_NEEDD to dlopen().

Nowadays there are tons of DT_NEEDED dependencies of /usr/bin/gdb so one does
not even think about the possibility using the binary on some other OS.

You are right dlopen() could be changed to DT_NEEDED back. But then rather
this whole librpm dependency patch is being rewritten some other ways (and it
is longer done by me who wrote it in that 2008). That librpm dependency is
painful anyway as librpm authors do not like it to be used by 3rd party apps
and they prefer popen()ing some rpm commands instead:
rpmdb locking broken by other-arch rpmquery
https://bugzilla.redhat.com/show_bug.cgi?id=486423#c1


> Best I can tell, our patches to GDB support both modes, and it seems to be
> unnecessarily painful for us to have to track the soversion like that
> instead of just letting it pick it up.

The positive side is that GDB handles gracefully if the librpm (of proper
version) is missing. But the gdb.spec correctly fails to build it.

gdb.spec could auto-detect the current librpm version.


Jan
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Why does gdb dlopen() librpm instead of linking to it?

[Neal Gompa]

Hello,

Can someone please explain why gdb dlopen()'s librpm instead of just
doing proper compile-time linking? Best I can tell, our patches to GDB
support both modes, and it seems to be unnecessarily painful for us to
have to track the soversion like that instead of just letting it pick
it up.

I noticed this while working on GDB packaging for a couple of other
distributions that sync from our package in Fedora (Mageia,
OpenMandriva), and while rebasing to RPM 4.15, I had to go and
manually change things.

This doesn't make sense, and I'm not sure why we're doing this in
Fedora... Anybody know?

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

koji / bodhi issues status update

[Kevin Fenzi]

As some of you may know, we have been having issues with koji and bodhi
over the holidays. :( koji would sometimes not tag builds or error them
with odd error messages and bodhi wasn't pushing updates. 

I'm happy to report that the underlying issue seems to be fixed now. 
We hopefully will have a more detailed root cause next week.

However, due to the koji issues builds were in a state where bodhi
ejected many of them from updates pushes. We are working on cleaning
up the state of those updates and there's no need for maintainers to do
anything with those updates at this time.

Once we get the ejected builds cleaned up we should be able to resume
normal bodhi updates pushes. 

Thanks everyone for your patience on this issue!

kevin


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

koji / bodhi issues status update

[Kevin Fenzi]

As some of you may know, we have been having issues with koji and bodhi
over the holidays. :( koji would sometimes not tag builds or error them
with odd error messages and bodhi wasn't pushing updates. 

I'm happy to report that the underlying issue seems to be fixed now. 
We hopefully will have a more detailed root cause next week.

However, due to the koji issues builds were in a state where bodhi
ejected many of them from updates pushes. We are working on cleaning
up the state of those updates and there's no need for maintainers to do
anything with those updates at this time.

Once we get the ejected builds cleaned up we should be able to resume
normal bodhi updates pushes. 

Thanks everyone for your patience on this issue!

kevin


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1778465



--- Comment #7 from Paul Howarth  ---
(In reply to Emmanuel Seyman from comment #6)
> Re-submitted to stable.

I'm not convinced that's necessary. The package is in the repo (see
https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/p/).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1768303] nagios-plugins-all is missing perl(utf8::all)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1768303



--- Comment #5 from Paul Howarth  ---
(In reply to claudio from comment #4)
> I am still experiencing this issue on RHEL 7.
> what does "updating perl-Dist-CheckConflicts package" mean?

yum update perl-Dist-CheckConflicts ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Neal Gompa]

On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. The idea is to recover from out of
> memory situations sooner, rather than the typical complete system hang
> in which the user has no other choice but to force power off.
>

I'd like to see this enabled on all Fedora variants by default. This
seems to be generally useful for workstations and servers...




--
真実はいつも一つ！/ Always, there's only one truth!
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Frantisek Zatloukal]

On Fri, Jan 3, 2020 at 10:14 PM John M. Harris Jr 
wrote:

> Regardless, if this Change is accepted, it should probably be done on a
> per-
> spin basis. If the GNOME Spin wants this, that's one thing, but I don't
> believe this would be a good idea on servers.
>

Yes, and if you read the change wiki page mentioned in the announcement
email, it's meant only for Workstation:
https://fedoraproject.org/wiki/Changes/EnableEarlyoom#Scope

Restricted to Workstation edition, unless other editions/spins want to
> opt-in.
>

And to be precise, there is Fedora Workstation (Edition of Fedora) and then
there are other Spins. Workstation is not a spin :)
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

On Fri, Jan 3, 2020 at 1:35 PM Robbie Harwood  wrote:
>
> The OOM killer is a kernel function.

Yes, this is indicated in the summary.

>I have no opinion on this proposal
> as it stands, but I would like it to include an explanation of why this
> requires a service in userspace to fix.

The 2nd full paragraph of the "detailed description" section describes
intended kernel function. What I don't say there, is that kernel folks
don't consider the oomkiller behavior to be broken, it's working
exactly as intended. It keeps the kernel alive. Its concern has
nothing to do with keeping user space responsive.



-- 
Chris Murphy
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Chris Murphy]

On Fri, Jan 3, 2020 at 11:48 AM Louis Lagendijk  wrote:
>
> virt-manager does not enable discards on IDE or virtio disks. I think
> it DOES enable discard on SCSI disks. So strictly speaking the above is
> true as long as the default emulation layer is not SCSI but it is a
> matter of a few clicks to enable it.

"hypervisor default" is what virt-manager reports because it doesn't
actually know what the default is.

When the "disk bus" is set to either VirtIO or SCSI, and discard mode
is "hypervisor default", discard pass down is not enabled.

When VirtIO discard mode is "unmap", both blkdiscard and fstrim work
as I'd expect.
When SCSI discard mode is "unmap", fstrim does nothing, but blkdiscard
works as expected. Pretty weird.

Backing device in these cases is a raw file. For SCSI, it's using the
virtio SCSI controller (which is also not added by default in
virt-manager VMs).

So yeah it's really not obvious how to configure all of this, it's
pretty much poke it with a stick and see what happens.


-- 
Chris Murphy
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[John M. Harris Jr]

On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote:
> Robbie Harwood  writes:
> > Ben Cotton  writes:
> >> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
> >> 
> >> == Summary ==
> >> Install earlyoom package, and enable it by default. This will cause
> >> the kernel oomkiller to trigger sooner, but will not affect which
> >> process it chooses to kill off. The idea is to recover from out of
> >> memory situations sooner, rather than the typical complete system hang
> >> in which the user has no other choice but to force power off.
> >> 
> >> # enable earlyoom by default on workstation
> >> enable earlyoom.service
> >> 
> > 
> > The OOM killer is a kernel function.  I have no opinion on this proposal
> > as it stands, but I would like it to include an explanation of why this
> > requires a service in userspace to fix.
> 
> Another thought.  Wouldn't some of the pain here be alleviated by
> setting vm.swappiness=0?  Currently it seems to be 60, which results in
> somewhat aggressive swap use; 1 seems better (minimal swapping without
> disabling), while 0 will disable it for general use (while preserving it
> for hibernation).  This would at least improve the disk thrashing during
> OOM situations.
> 
> Thanks,
> --Robbie

To clarify, according to the Workstation group, hibernation isn't even 
supported.

Regardless, if this Change is accepted, it should probably be done on a per-
spin basis. If the GNOME Spin wants this, that's one thing, but I don't 
believe this would be a good idea on servers.

-- 
John M. Harris, Jr.
Splentity

___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Robbie Harwood]

Robbie Harwood  writes:

> Ben Cotton  writes:
>
>> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>>
>> == Summary ==
>> Install earlyoom package, and enable it by default. This will cause
>> the kernel oomkiller to trigger sooner, but will not affect which
>> process it chooses to kill off. The idea is to recover from out of
>> memory situations sooner, rather than the typical complete system hang
>> in which the user has no other choice but to force power off.
>>
>> # enable earlyoom by default on workstation
>> enable earlyoom.service
>> 
>
> The OOM killer is a kernel function.  I have no opinion on this proposal
> as it stands, but I would like it to include an explanation of why this
> requires a service in userspace to fix.

Another thought.  Wouldn't some of the pain here be alleviated by
setting vm.swappiness=0?  Currently it seems to be 60, which results in
somewhat aggressive swap use; 1 seems better (minimal swapping without
disabling), while 0 will disable it for general use (while preserving it
for hibernation).  This would at least improve the disk thrashing during
OOM situations.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Robbie Harwood]

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. The idea is to recover from out of
> memory situations sooner, rather than the typical complete system hang
> in which the user has no other choice but to force power off.
>
> # enable earlyoom by default on workstation
> enable earlyoom.service
> 

The OOM killer is a kernel function.  I have no opinion on this proposal
as it stands, but I would like it to include an explanation of why this
requires a service in userspace to fix.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. wine, dosbox, nextcloud, owncloud)

[Robbie Harwood]

Robbie Harwood  writes:

> Miro Hrončok  writes:
>
>> The following packages are orphaned and will be retired when they
>> are orphaned for six weeks, unless someone adopts them. If you know for sure
>> that the package should be retired, please do so now with a proper reason:
>> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>>
>> Note: If you received this mail directly you (co)maintain one of the affected
>> packages or a package that depends on one. Please adopt the affected package 
>> or
>> retire your depending package to avoid broken dependencies, otherwise your
>> package will be retired when the affected package gets retired.
>>
>> rxvtorphan 0 weeks 
>> ago
>
> If no one adopts rxvt, I'm happy to provide compat symlinks and such in
> rxvt-unicode.

rxvt has been removed.  rxvt-unicode is now the only rxvt in the distro,
and Obsoletes/provides compat symlink starting in
rxvt-unicode-9.22-21.fc32.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200103.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200101.n.0
NEW: Fedora-Rawhide-20200103.n.0

= SUMMARY =
Added images:3
Dropped images:  1
Added packages:  3
Dropped packages:4
Upgraded packages:   71
Downgraded packages: 0

Size of added packages:  112.70 MiB
Size of dropped packages:3.01 MiB
Size of upgraded packages:   2.00 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -173.33 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20200103.n.0.iso
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-Rawhide-20200103.n.0-sda.raw.xz
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20200103.n.0.aarch64.raw.xz

= DROPPED IMAGES =
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20200101.n.0.iso

= ADDED PACKAGES =
Package: golang-github-google-slothfs-0-0.1.20200101git6b42407.fc32
Summary: FUSE filesystem for light-weight, lazily-loaded, read-only Git
RPMs:golang-github-google-slothfs golang-github-google-slothfs-devel
Size:84.75 MiB

Package: pymol-2.3.0-4.fc32
Summary: PyMOL Molecular Graphics System
RPMs:pymol
Size:27.92 MiB

Package: python-spec-1.4.1-2.fc32
Summary: Specification-style output for python-nose
RPMs:python3-spec
Size:32.47 KiB


= DROPPED PACKAGES =
Package: gap-pkg-carat-2.3-1.fc32
Summary: GAP interface to CARAT
RPMs:gap-pkg-carat gap-pkg-carat-doc
Size:185.09 KiB

Package: hippo-canvas-0.3.0-29.fc31
Summary: A canvas widget
RPMs:hippo-canvas hippo-canvas-devel python2-hippo-canvas
Size:1.08 MiB

Package: sugar-base-0.98.0-17.fc31
Summary: Base Sugar library
RPMs:sugar-base
Size:309.27 KiB

Package: sugar-toolkit-0.112-8.fc31
Summary: Sugar toolkit
RPMs:sugar-toolkit
Size:1.45 MiB


= UPGRADED PACKAGES =
Package:  MUMPS-5.2.1-4.fc32
Old package:  MUMPS-5.2.1-3.fc32
Summary:  A MUltifrontal Massively Parallel sparse direct Solver
RPMs: MUMPS MUMPS-common MUMPS-devel MUMPS-examples MUMPS-mpich 
MUMPS-mpich-devel MUMPS-mpich-examples MUMPS-openmp MUMPS-openmp-devel 
MUMPS-openmp-examples MUMPS-openmpi MUMPS-openmpi-devel MUMPS-openmpi-examples
Size: 75.71 MiB
Size change:  5.41 KiB
Changelog:
  * Wed Jan 01 2020 Antonio Trande  - 5.2.1-4
  - Use libmpiblacs separately with scalapack-2.1.*


Package:  babel-2.8.0-1.fc32
Old package:  babel-2.7.0-7.fc32
Summary:  Tools for internationalizing Python applications
RPMs: babel babel-doc python2-babel python3-babel
Size: 11.65 MiB
Size change:  318.16 KiB
Changelog:
  * Thu Jan 02 2020 Felix Schwarz  - 2.8.0-1
  - update to upstream version 2.8.0


Package:  beep-1.4.7-1.fc32
Old package:  beep-1.4.6-1.fc32
Summary:  Beep the PC speaker any number of ways
RPMs: beep
Size: 215.23 KiB
Size change:  4.69 KiB
Changelog:
  * Wed Jan 01 2020 Hans Ulrich Niedermann  - 1.4.7-1
  - Update to beep-1.4.7
  - Install contrib scripts for both successfully and failing sounding beeps.


Package:  bind-32:9.11.14-2.fc32
Old package:  bind-32:9.11.13-4.fc32
Summary:  The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) 
server
RPMs: bind bind-chroot bind-devel bind-dlz-filesystem bind-dlz-ldap 
bind-dlz-mysql bind-dlz-mysqldyn bind-dlz-sqlite3 bind-dnssec-utils bind-libs 
bind-libs-lite bind-license bind-lite-devel bind-pkcs11 bind-pkcs11-devel 
bind-pkcs11-libs bind-pkcs11-utils bind-sdb bind-sdb-chroot bind-utils 
python3-bind
Size: 32.97 MiB
Size change:  13.99 KiB
Changelog:
  * Thu Dec 19 2019 Petr Menk  - 32:9.11.14-1
  - Update to 9.11.14

  * Thu Dec 19 2019 Petr Menk  - 32:9.11.14-2
  - Include more Thread Sanitizer detected changes (#1736762)


Package:  bval-2.0.3-1.fc32
Old package:  bval-1.1.1-7.fc30
Summary:  Apache Bean Validation
RPMs: bval bval-extras bval-javadoc bval-jsr bval-parent
Dropped RPMs: bval-json bval-xstream
Size: 1.07 MiB
Size change:  32.69 KiB
Changelog:
  * Wed Jul 24 2019 Fedora Release Engineering  - 
1.1.1-8
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Thu Jan 02 2020 Jakub Jelen  - 2.0.3-1
  - Rebase to new upstream release (#1734994)


Package:  cups-1:2.3.1-2.fc32
Old package:  cups-1:2.3.1-1.fc32
Summary:  CUPS printing system
RPMs: cups cups-client cups-devel cups-filesystem cups-ipptool 
cups-libs cups-lpd cups-printerapp
Size: 28.75 MiB
Size change:  4.13 KiB
Changelog:
  * Thu Jan 02 2020 Zdenek Dohnal  - 1:2.3.1-2
  - do not ship ipp backend as 755, breaks kerberized printing
  - https://github.com/apple/cups/pull/5710


Package:  exim-4.92.3-5.fc32
Old package:  exim-4.92.3-4.fc32
Summary:  The exim mail transfer agent
RPMs: exim exim-clamav exim-greylist exim-mon exim-mysql exim-pgsql
Size: 7.23 MiB
Size

Re: Second attempt: Maintainer contact check for Chris Grau (cgrau)

[Frank R Dana Jr.]

Paul Howarth wrote,
>
> perl-Time-Piece was obsoleted by the base perl package way back in> 5.10.0.
>
> perl-Time-Piece-MySQL is an extension to perl-Time-Piece.

Thanks for the info, Paul!

...Does that mean it no longer has any usefulness without perl-Time-Piece,and 
should be similarly orphaned/retired?
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1768303] nagios-plugins-all is missing perl(utf8::all)

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1768303

claudio  changed:

   What|Removed |Added

 CC||cmlomba...@ucsd.edu



--- Comment #4 from claudio  ---
I am still experiencing this issue on RHEL 7.
what does "updating perl-Dist-CheckConflicts package" mean?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1778465



--- Comment #6 from Emmanuel Seyman  ---
Re-submitted to stable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora 32 Self-Contained Change proposal: Mono 6.6

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Mono_6_6

== Summary ==
Update the Mono stack in Fedora from 5.20 to 6.6. We need to do again
a bootstrap build.

== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpoko...@fedoraproject.org

== Detailed Description ==
Even between minor releases, we need to build Mono by doing a bootstrap.
I have successfully built Mono 6.6 without bootstrap, once I have Mono
6.6 installed which was built with bootstrapping enabled.

I would like to request permission to make a one time exception of the
rule for building mono 6.6.0-1 using monolite and the reference
assemblies, later make mono depend again on itself and rebuild mono
6.6.0-2 using mono-6.6.0-1.

Steps for bootstrapping:

* The Monolite binaries are included in the Mono tarball which is
provided by upstream. See also
http://www.mono-project.com/docs/advanced/monolite/
** Monolite is a minimal binary distribution of mcs. This is the
compiler that is able to build the rest of Mono.
* The binary reference assemblies are included in the Mono tarball
which is provided by upstream. The tarball also includes the sources
of the reference assemblies, which are maintained here:
https://github.com/dotnet/source-build
* In the spec file, we usually delete all dlls and executables before
the build section.
* For the bootstrap, we would once keep the monolite binaries and some
binary reference assemblies.
* In the bootstrap, we rebuild the reference assemblies and include
them in the mono-devel package, as well as the mono compiler.
* After Mono has been built for all primary and secondary
architectures, we enable the deletion of the binaries again in the
spec file.


== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software -
we should have the most recent release of Mono 6.x

== Scope ==
* Proposal owners:
Update mono spec and build in koji until it is ready.
Members of the Mono SIG can rebuild their packages with Mono 6.6.
Rebuild of all packages depending on Mono can happen during the
regular mass rebuild.

* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Dependencies ==
This is not a system wide change, but only affects packages depending
on Mono, and should be managed by the members of the [[SIGs/Mono|Mono
SIG]].

== Documentation ==
* https://fedoraproject.org/wiki/Packaging:Mono
* https://github.com/mono/mono
* https://copr.fedorainfracloud.org/coprs/tpokorra/mono-6.6/
* https://github.com/tpokorra/mono-6.x-fedora/tree/master/mono-6.6

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Fedora 33 System-Wide Change proposal: binutils 2.34

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/BINUTILS234

== Summary ==
Rebase the binutils package from version 2.33 to version 2.34.

== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com


== Detailed Description ==
Switch the binutils package from being based on the 2.33 release of
the GNU binutils to
being based on the 2.34 release.  This release will bring in numerous
bug fixes, as well
as coloured ascii art annotation for the disassembler output!

== Benefit to Fedora ==
The main benefit will be the bug fixes and the improvement to the
linker and assembler.
In addition users who look at disassemblies will find the new ascii
art output quite helpful.

== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already fixed.
This is a significant change to the underlying tools used to build
Fedora and so there should be a mass rebuild in order for the changes
to be noticed across the system.

* Other developers:
No other work should be necessary.  Once the rebase is in place and
the buildroot contains the new binutils its use should be automatic.

* Release engineering: [https://pagure.io/releng/issues/9111]  A mass
rebuild will be required.
* Policies and guidelines: No documents need to be updated.
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The binutils are backwards compatible with previous releases, so no
changes should be necessary.

== How To Test ==
The binutils package does include its own set of testsuites which
check basic functionality.
The real test however is by rebuilding other packages which depend
upon the binutils, or
more likely, upon gcc.  If these packages continue to work then the
binutils update has not
broken anything.


== User Experience ==
The change should not be noticeable to the user.

== Dependencies ==
This update has no hard dependencies on any other package.
There are other packages that do depend upon the binutils however.
Most notably gcc and redhat-rpm-config.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Revert to the
2.33 binutils as currently used in rawhide.  This work can be done by
me, should it prove necessary.

* Contingency deadline: Beta freeze.
* Blocks release? No
* Blocks product? None

== Documentation ==
Documentation is not currently available, due to the fact that the
2.34 release has not yet been created.
(It is hoped that the release will happen before the Fedora 33 mass rebuild).


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 Self-Contained Change proposal: Mono 6.6

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Mono_6_6

== Summary ==
Update the Mono stack in Fedora from 5.20 to 6.6. We need to do again
a bootstrap build.

== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpoko...@fedoraproject.org

== Detailed Description ==
Even between minor releases, we need to build Mono by doing a bootstrap.
I have successfully built Mono 6.6 without bootstrap, once I have Mono
6.6 installed which was built with bootstrapping enabled.

I would like to request permission to make a one time exception of the
rule for building mono 6.6.0-1 using monolite and the reference
assemblies, later make mono depend again on itself and rebuild mono
6.6.0-2 using mono-6.6.0-1.

Steps for bootstrapping:

* The Monolite binaries are included in the Mono tarball which is
provided by upstream. See also
http://www.mono-project.com/docs/advanced/monolite/
** Monolite is a minimal binary distribution of mcs. This is the
compiler that is able to build the rest of Mono.
* The binary reference assemblies are included in the Mono tarball
which is provided by upstream. The tarball also includes the sources
of the reference assemblies, which are maintained here:
https://github.com/dotnet/source-build
* In the spec file, we usually delete all dlls and executables before
the build section.
* For the bootstrap, we would once keep the monolite binaries and some
binary reference assemblies.
* In the bootstrap, we rebuild the reference assemblies and include
them in the mono-devel package, as well as the mono compiler.
* After Mono has been built for all primary and secondary
architectures, we enable the deletion of the binaries again in the
spec file.


== Benefit to Fedora ==
Fedora aims to showcase the latest in free and open source software -
we should have the most recent release of Mono 6.x

== Scope ==
* Proposal owners:
Update mono spec and build in koji until it is ready.
Members of the Mono SIG can rebuild their packages with Mono 6.6.
Rebuild of all packages depending on Mono can happen during the
regular mass rebuild.

* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Dependencies ==
This is not a system wide change, but only affects packages depending
on Mono, and should be managed by the members of the [[SIGs/Mono|Mono
SIG]].

== Documentation ==
* https://fedoraproject.org/wiki/Packaging:Mono
* https://github.com/mono/mono
* https://copr.fedorainfracloud.org/coprs/tpokorra/mono-6.6/
* https://github.com/tpokorra/mono-6.x-fedora/tree/master/mono-6.6

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/EnableEarlyoom

== Summary ==
Install earlyoom package, and enable it by default. This will cause
the kernel oomkiller to trigger sooner, but will not affect which
process it chooses to kill off. The idea is to recover from out of
memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.


== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]]
* Email: bugzi...@colorremedies.com

== Detailed Description ==
Workstation working group has discussed "better interactivity in
low-memory situations" for some months. In certain use cases,
typically compiling, if all RAM and swap are completely consumed,
system responsiveness becomes so abysmal that a reasonable user can
consider the system "lost", and resorts to forcing a power off. This
is objective a very bad UX. The broad discussion of this problem, and
some ideas for near term and long term solutions, is located here:

Recent long discussions on "Better interactivity in low-memory situations"
https://pagure.io/fedora-workstation/issue/98
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/

Fedora editions and spins, have the in-kernel OOM (out-of-memory)
manager enabled. The manager's concern is keeping the kernel itself
functioning. It has no concern about user space function or
interactivity. This proposed change attempts to improve the user
experience, in the short term, by triggering the in-kernel process
killing mechanism, sooner. Instead of the system becoming completely
unresponsive for tens of minutes, hours or days, the expectation is an
offending process (determined by oom_score, same as now) will be
killed off within seconds or a few minutes. This is an incremental
improvement in user experience, but admittedly still suboptimal. There
is additional work on-going to improve the user experience further.

Workstation working group discussion specific to enabling earlyoom by default
https://pagure.io/fedora-workstation/issue/119

Other in-progress solutions:
https://gitlab.freedesktop.org/hadess/low-memory-monitor

Background information on this complicated problem:
https://www.kernel.org/doc/gorman/html/understand/understand016.html
https://lwn.net/Articles/317814/

== Benefit to Fedora ==

There are two major benefits to Fedora:

* improved user experience by more quickly regaining control over
one's system, rather than having to force power off in low-memory
situations where there's aggressive swapping. Once a system becomes
unresponsive, it's completely reasonable for the user to assume the
system is lost, but that includes high potential for data loss.

* reducing forced poweroff as the main work around will increase data
collection, improving understanding of low memory situations and how
to handle them better


== Scope ==
* Proposal owners:
a. Modify {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}}
to include earlyoom package for Workstation.
b. Modify 
{{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}}
to include:

# enable earlyoom by default on workstation
enable earlyoom.service


* Other developers:
Restricted to Workstation edition, unless other editions/spins want to opt-in.

* Release engineering: [https://pagure.io/releng/issues #9141] (a
check of an impact with Release Engineering is needed) 

* Policies and guidelines: N/A
* Trademark approval: N/A

== Upgrade/compatibility impact ==
earlyoom.service will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a clean installed system.

== How To Test ==
* Fedora 30/31 users can test today, any edition or spin:
{{code|sudo dnf install earlyoom}}
{{code|sudo systemctl enable --now earlyoom}}

And then attempt to cause an out of memory situation. Examples:
{{code|tail /dev/zero}}
{{code|https://lkml.org/lkml/2019/8/4/15}}

* Fedora Workstation 32 (and Rawhide) users will see this service is
already enabled. It can be toggled with  {{code|sudo systemctl
start/stop earlyoom}}  where start means earlyoom is running, and stop
means earlyoom is not running.

== User Experience ==
The most egregious instances this change is trying to mitigate:
a. RAM is completely used
b. Swap is completely used
c. System becomes unresponsive to the user as swap thrashing has ensued
--> earlyoom disabled, the user often gives up and forces power off
(in my own testing this condition lasts >30 minutes with no kernel
triggered oom killer and no recovery)
--> earlyoom enabled, the system likely still becomes unresponsive but
oom killer is triggered in much less time (seconds or a few minutes,
in my testing, after less than 10% RAM and 10% swap is remaining)

earlyoom starts sending SIGTERM once both memory and swap are below
their respective PERCENT setting, default 10%. It sends SIGKILL once
both are below their respective KILL_PERCENT setting, 

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

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 11/155 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20200101.n.0):

ID: 506583  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/506583
ID: 506588  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/506588
ID: 506602  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/506602
ID: 506643  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/506643
ID: 506645  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/506645
ID: 506646  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/506646
ID: 506652  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/506652

Old failures (same test failed in Fedora-Rawhide-20200101.n.0):

ID: 506600  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/506600
ID: 506615  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/506615
ID: 506655  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/506655
ID: 506663  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/506663
ID: 506733  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/506733

Soft failed openQA tests: 85/155 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20200101.n.0):

ID: 506647  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/506647

Old soft failures (same test soft failed in Fedora-Rawhide-20200101.n.0):

ID: 506581  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/506581
ID: 506582  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/506582
ID: 506586  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/506586
ID: 506587  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/506587
ID: 506589  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/506589
ID: 506590  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/506590
ID: 506591  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/506591
ID: 506592  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/506592
ID: 506594  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/506594
ID: 506595  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/506595
ID: 506606  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/506606
ID: 506611  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/506611
ID: 506614  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/506614
ID: 506620  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/506620
ID: 506621  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/506621
ID: 506629  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/506629
ID: 506634  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/506634
ID: 506657  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/506657
ID: 506658  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/506658
ID: 506659  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/506659
ID: 506660  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/506660
ID: 506661  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/506661
ID: 506664  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/506664
ID: 506665  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/506665
ID: 50  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/50
ID: 

Re: peek package

[Michael Schwendt]

On Fri, 3 Jan 2020 16:30:54 +0100, Vitaly Zaitsev via devel wrote:

> On 03.01.2020 11:14, Michael Schwendt wrote:
> > What sort of "huge headache" would that be?  
> 
> 1. Most of ffmpeg-capable applications use compile-time checks for
> available codecs presence.

Which is something you can only fix with an RPM Fusion package,
if you "control" (= build) all depending packages.

> 2. Sync errors between repositories like chromium and
> chromium-libs-media-freeworld.

Not any more "headaches" than ordinary add-on packages in a 3rd party repo
with dependencies in the base dist repo(s).

> > Third party repos like RPM Fusion can still use package Epoch to replace 
> > base distribution packages.  
> 
> RPM Fusion strictly forbid this.

And yet it would create less problems than conflicting replacement packages.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Louis Lagendijk]

On Fri, 2020-01-03 at 10:21 -0700, Chris Murphy wrote:
> On Fri, Jan 3, 2020 at 9:06 AM Robbie Harwood 
> wrote:
> > Nico Kadel-Garcia  writes:
> > 
> > > On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood <
> > > rharw...@redhat.com> wrote:
> > > > "John M. Harris Jr"  writes:
> > > > > On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy
> > > > > wrote:
> > > > > 
> > > > > > Issuing the command once per week harms no one
> > > > > 
> > > > > Based on what's actual in the Change proposal, this is not
> > > > > the case.
> > > > > 
> > > > > Even if this goes through, in my opinion, it should only
> > > > > affect the
> > > > > GNOME Spin, or perhaps even "all graphical" spins at most.
> > > > 
> > > > No?  This is extremely useful for cloud environments - maybe
> > > > the most
> > > > useful.  It allows VM hosts to reclaim and reuse empty disk
> > > > space;
> > > > otherwise, the disk images just bloat to their maximum allowed
> > > > size.
> > > 
> > > Its most useful for the cloud *providers*, not the cloud clients.
> > > For
> > > the clients, getting the AWS space pre-allocated form EBS is
> > > often a
> > > notable performance improvement, and restoring it to AWS saves
> > > AWS
> > > resources. Not the client system performance.
> > 
> > Sure, but in many cases the client is also the provider.  Consider
> > running kvm on a laptop (which I and many others do for work...) -
> > you'd
> > really like the disk space back you're not using, rather than each
> > VM
> > taking 10-20G it doesn't need.  I end up having to edit every VM
> > configuration in two places after each install/provision in order
> > to get
> > that behavior - that's not reasonable.
> 
> By default, GNOME Boxes and virt-manager VM's, do not enable block
> device discards. So this feature is a 'no op' in that case. And also
> fstrim.service won't run in a container. I've updated the feature to
> reflect these two things.
> 
virt-manager does not enable discards on IDE or virtio disks. I think
it DOES enable discard on SCSI disks. So strictly speaking the above is
true as long as the default emulation layer is not SCSI but it is a
matter of a few clicks to enable it.

> 

___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: lv2-sorcer is not installable

[Fabio Valentini]

On Fri, Jan 3, 2020, 19:25 Kevin Kofler  wrote:

> Zbigniew Jędrzejewski-Szmek wrote:
> > The dep was provided by non-ntk, which got retired about half a year
> > ago [1] after FTBFSing since F29 [2].
>
> Isn't it great when the policy designed to remove
> breakage from the distribution actually CREATES breakage? Retiring
> packages
> with no regards to their reverse dependencies is just broken. It had never
> been done that way in the past, before Miro's recent crackdown, because it
> simply defeats all common sense.
>
> Kevin Kofler
>

Kevin, I agree with you on some topics, but please stop spreading FUD like
this. The maintainers got notifications for *four months* before the
package was retired, and obviously ignored them. Another 5 months passed
without somebody posting this message to the devel list, and nobody
unretired the package during that time. I'd say good riddance to broken and
unmaintained packages like this one.

Don't blame Miro for doing the necessary things, just because you don't
like the process. We have asked you multiple times to suggest a policy that
works for you too, but you haven't done that, instead you only insulted
community members.

Fabio


___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject
> 
>
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: lv2-sorcer is not installable

[Kevin Kofler]

Zbigniew Jędrzejewski-Szmek wrote:
> The dep was provided by non-ntk, which got retired about half a year
> ago [1] after FTBFSing since F29 [2].

Isn't it great when the policy designed to remove 
breakage from the distribution actually CREATES breakage? Retiring packages 
with no regards to their reverse dependencies is just broken. It had never 
been done that way in the past, before Miro's recent crackdown, because it 
simply defeats all common sense.

Kevin Kofler
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Robbie Harwood]

Chris Murphy  writes:

> On Fri, Jan 3, 2020 at 9:06 AM Robbie Harwood  wrote:
>> Nico Kadel-Garcia  writes:
>>> On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood  wrote:
 "John M. Harris Jr"  writes:
> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
>
>> Issuing the command once per week harms no one
>
> Based on what's actual in the Change proposal, this is not the case.
>
> Even if this goes through, in my opinion, it should only affect
> the GNOME Spin, or perhaps even "all graphical" spins at most.

 No?  This is extremely useful for cloud environments - maybe the
 most useful.  It allows VM hosts to reclaim and reuse empty disk
 space; otherwise, the disk images just bloat to their maximum
 allowed size.
>>>
>>> Its most useful for the cloud *providers*, not the cloud
>>> clients. For the clients, getting the AWS space pre-allocated form
>>> EBS is often a notable performance improvement, and restoring it to
>>> AWS saves AWS resources. Not the client system performance.
>>
>> Sure, but in many cases the client is also the provider.  Consider
>> running kvm on a laptop (which I and many others do for work...) -
>> you'd really like the disk space back you're not using, rather than
>> each VM taking 10-20G it doesn't need.  I end up having to edit every
>> VM configuration in two places after each install/provision in order
>> to get that behavior - that's not reasonable.
>
> By default, GNOME Boxes and virt-manager VM's, do not enable block
> device discards. So this feature is a 'no op' in that case. And also
> fstrim.service won't run in a container. I've updated the feature to
> reflect these two things.

Yeah.  They should, but that's maybe a different fight :)

> I'm not certain what the default should be for VMs. I really only ever
> use libvirt managed qemu-kvm these days, so I'm also not sure what the
> defaults are elsewhere for comparison.

If it's not a physical disk, and we know it's not a physical disk,
there's no excuse not to discard/TRIM - there's no worry about hardware
bugs at that point.  But you're right that's not what we do currently.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Daniel P . Berrangé]

On Fri, Jan 03, 2020 at 11:05:43AM -0500, Robbie Harwood wrote:
> Nico Kadel-Garcia  writes:
> 
> > On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood  wrote:
> >> "John M. Harris Jr"  writes:
> >>> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
> >>>
>  Issuing the command once per week harms no one
> >>>
> >>> Based on what's actual in the Change proposal, this is not the case.
> >>>
> >>> Even if this goes through, in my opinion, it should only affect the
> >>> GNOME Spin, or perhaps even "all graphical" spins at most.
> >>
> >> No?  This is extremely useful for cloud environments - maybe the most
> >> useful.  It allows VM hosts to reclaim and reuse empty disk space;
> >> otherwise, the disk images just bloat to their maximum allowed size.
> >
> > Its most useful for the cloud *providers*, not the cloud clients. For
> > the clients, getting the AWS space pre-allocated form EBS is often a
> > notable performance improvement, and restoring it to AWS saves AWS
> > resources. Not the client system performance.
> 
> Sure, but in many cases the client is also the provider.  Consider
> running kvm on a laptop (which I and many others do for work...) - you'd
> really like the disk space back you're not using, rather than each VM
> taking 10-20G it doesn't need.  I end up having to edit every VM
> configuration in two places after each install/provision in order to get
> that behavior - that's not reasonable.

virt-manager at least defaults to requesting full pre-allocation
of guest disks. The reason for this is that if using sparse raw or
grow-on-demand qcow2 files, and the host FS runs out of free space,
the guest OS will silently pause execution (the alternative is to
report EIO which will cause the guest OS to panic and/or set the
FS read-only). Someone using the guest will just see their session
inexplicably hang. If it enabled discard on the disks, this would
defeat the purpose of requesting full preallocation originally.

So it is a trade off between having a guest deployment that is
robust wrt host FS space issues, at the cost of using more disk
space. Of course this doesn't suit everyone's desires, but I think
that it is a reasonable tradeoff for virt-manager/boxes to make.
You can get the full configurable control over this by using the
virt-install tool to provision guests if desired.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Chris Murphy]

On Fri, Jan 3, 2020 at 9:06 AM Robbie Harwood  wrote:
>
> Nico Kadel-Garcia  writes:
>
> > On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood  wrote:
> >> "John M. Harris Jr"  writes:
> >>> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
> >>>
>  Issuing the command once per week harms no one
> >>>
> >>> Based on what's actual in the Change proposal, this is not the case.
> >>>
> >>> Even if this goes through, in my opinion, it should only affect the
> >>> GNOME Spin, or perhaps even "all graphical" spins at most.
> >>
> >> No?  This is extremely useful for cloud environments - maybe the most
> >> useful.  It allows VM hosts to reclaim and reuse empty disk space;
> >> otherwise, the disk images just bloat to their maximum allowed size.
> >
> > Its most useful for the cloud *providers*, not the cloud clients. For
> > the clients, getting the AWS space pre-allocated form EBS is often a
> > notable performance improvement, and restoring it to AWS saves AWS
> > resources. Not the client system performance.
>
> Sure, but in many cases the client is also the provider.  Consider
> running kvm on a laptop (which I and many others do for work...) - you'd
> really like the disk space back you're not using, rather than each VM
> taking 10-20G it doesn't need.  I end up having to edit every VM
> configuration in two places after each install/provision in order to get
> that behavior - that's not reasonable.

By default, GNOME Boxes and virt-manager VM's, do not enable block
device discards. So this feature is a 'no op' in that case. And also
fstrim.service won't run in a container. I've updated the feature to
reflect these two things.

I'm not certain what the default should be for VMs. I really only ever
use libvirt managed qemu-kvm these days, so I'm also not sure what the
defaults are elsewhere for comparison.

-- 
Chris Murphy
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL8: neofetch package request

[Troy Dawson]

Thank you for letting us know.

The need to inform epel-devel of adding a package is only if the
package is a "Limited Arch" package.  Since your package is a noarch
package, and thus will be available for all arches, you do not need to
inform us, nor wait for our approval.
Please proceed with the packaging guidelines and request the branch.

On Fri, Jan 3, 2020 at 7:34 AM Kees de Jong  wrote:
>
> Hi,
>
>
> I got the request to package `neofetch` for EPEL8 [1]. It's already in
> Fedora for quite some time [2]. I have the intention to grant this
> request. According to the EPEL packaging guidelines I need to inform
> you first of this intention [3]. The package should work fine. If there
> are no objections then I'll go through the packaging guidelines and
> request a branch for EPEL8.
>
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1786483
> [2]
> https://src.fedoraproject.org/rpms/neofetch/blob/master/f/neofetch.spec
> [3] https://fedoraproject.org/wiki/EPEL:Packaging
>
>
>
> --
> Met vriendelijke groet,
> Kees de Jong
>
> De informatie opgenomen in deze e-mail kan vertrouwelijk zijn en is
> uitsluitend bestemd voor de geadresseerde(n). Indien u deze e-mail
> onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de
> afzender direct te informeren door de e-mail te retourneren. Aan deze
> e-mail inclusief de bijlagen kunnen geen rechten ontleend worden,
> tenzij schriftelijk anders wordt overeengekomen.
> --
> The information contained in this e-mail may be confidential and is
> intended to be exclusively for the addressee(s). Should you receive
> this e-mail unintentionally, please do not use the contents herein and
> notify the sender immediately by return e-mail. This e-mail including
> the attachments are not legally binding, unless otherwise agreed upon
> in writing.
> --
> OpenPGP fingerprint: 0x0E45C98AB51428E6
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Robbie Harwood]

Nico Kadel-Garcia  writes:

> On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood  wrote:
>> "John M. Harris Jr"  writes:
>>> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
>>>
 Issuing the command once per week harms no one
>>>
>>> Based on what's actual in the Change proposal, this is not the case.
>>>
>>> Even if this goes through, in my opinion, it should only affect the
>>> GNOME Spin, or perhaps even "all graphical" spins at most.
>>
>> No?  This is extremely useful for cloud environments - maybe the most
>> useful.  It allows VM hosts to reclaim and reuse empty disk space;
>> otherwise, the disk images just bloat to their maximum allowed size.
>
> Its most useful for the cloud *providers*, not the cloud clients. For
> the clients, getting the AWS space pre-allocated form EBS is often a
> notable performance improvement, and restoring it to AWS saves AWS
> resources. Not the client system performance.

Sure, but in many cases the client is also the provider.  Consider
running kvm on a laptop (which I and many others do for work...) - you'd
really like the disk space back you're not using, rather than each VM
taking 10-20G it doesn't need.  I end up having to edit every VM
configuration in two places after each install/provision in order to get
that behavior - that's not reasonable.

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: lv2-sorcer is not installable

[Tomasz Torcz]

On Fri, Jan 03, 2020 at 08:36:45AM -0500, Code Zombie wrote:
> Hi
> 
> lv2-sorcer cannot be installed on Fedora 31. Seems like the libntk lib
> needed by the package is not provided by any packages. The full
> installation error is as follows:

  Looks like non-ntk library failed to build for last few releases:
  https://koji.fedoraproject.org/koji/packageinfo?packageID=16952

  It was removed from distribution (retired):
  https://bugzilla.redhat.com/show_bug.cgi?id=1675550

-- 
Tomasz Torcz Morality must always be based on practicality.
to...@pipebreaker.pl — Baron Vladimir Harkonnen
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Account Data Update mufti11

[Dominik 'Rathann' Mierzejewski]

On Friday, 03 January 2020 at 15:03, J. Scheurich wrote:
> 
> 
> On 1/3/20 3:55 PM, Dominik 'Rathann' Mierzejewski wrote:
> > What does
> > ssh -vvv muft...@pkgs.fedoraproject.org
> > say?
> $ ssh -vvv muft...@pkgs.fedoraproject.org
[...]
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/home/mufti/.ssh/id_rsa RSA
> SHA256:5MaDM/d04RmQbj470xty0ov7Bxix6BEtLioUsTkPZgw
> debug3: send packet: type 50
> debug2: we sent a publickey packet, wait for reply
> debug3: receive packet: type 51
> debug1: Authentications that can continue: publickey

Your public key was not accepted. Double check that you have the correct
key configured in your FAS profile. If you're sure the key is correct,
try asking in #fedora-admin on IRC (Freenode network) to check from
the server side.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] EPEL8: neofetch package request

[Kees de Jong]

Hi,


I got the request to package `neofetch` for EPEL8 [1]. It's already in
Fedora for quite some time [2]. I have the intention to grant this
request. According to the EPEL packaging guidelines I need to inform
you first of this intention [3]. The package should work fine. If there
are no objections then I'll go through the packaging guidelines and
request a branch for EPEL8.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1786483
[2] 
https://src.fedoraproject.org/rpms/neofetch/blob/master/f/neofetch.spec
[3] https://fedoraproject.org/wiki/EPEL:Packaging



-- 
Met vriendelijke groet,
Kees de Jong

De informatie opgenomen in deze e-mail kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde(n). Indien u deze e-mail
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de
afzender direct te informeren door de e-mail te retourneren. Aan deze
e-mail inclusief de bijlagen kunnen geen rechten ontleend worden,
tenzij schriftelijk anders wordt overeengekomen.
--
The information contained in this e-mail may be confidential and is
intended to be exclusively for the addressee(s). Should you receive
this e-mail unintentionally, please do not use the contents herein and
notify the sender immediately by return e-mail. This e-mail including
the attachments are not legally binding, unless otherwise agreed upon
in writing.
--
OpenPGP fingerprint: 0x0E45C98AB51428E6


signature.asc
Description: This is a digitally signed message part
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: peek package

[Vitaly Zaitsev via devel]

On 03.01.2020 11:14, Michael Schwendt wrote:
> What sort of "huge headache" would that be?

1. Most of ffmpeg-capable applications use compile-time checks for
available codecs presence.
2. Sync errors between repositories like chromium and
chromium-libs-media-freeworld.

> Third party repos like RPM Fusion can still use package Epoch to replace base 
> distribution packages.

RPM Fusion strictly forbid this.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Account Data Update mufti11

[J. Scheurich]

On 1/3/20 3:55 PM, Dominik 'Rathann' Mierzejewski wrote:

What does
ssh -vvvmuft...@pkgs.fedoraproject.org
say?

$ ssh -vvv muft...@pkgs.fedoraproject.org
OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS  10 Sep 2019
debug1: Reading configuration data /home/home/mufti/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 51: Including file
/etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org
originally pkgs.fedoraproject.org
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: not matched 'final'
debug2: match not found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file
/etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data
/etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-]
debug3: kex names ok:
[curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /home/home/mufti/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 51: Including file
/etc/ssh/ssh_config.d/05-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug2: checking match for 'final all' host pkgs.fedoraproject.org
originally pkgs.fedoraproject.org
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 3: matched 'final'
debug2: match found
debug3: /etc/ssh/ssh_config.d/05-redhat.conf line 5: Including file
/etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data
/etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-gex-sha1-,gss-group14-sha1-,gss-group1-sha1-]
debug3: kex names ok:
[curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]
debug2: resolving "pkgs.fedoraproject.org" port 22
debug2: ssh_connect_direct
debug1: Connecting to pkgs.fedoraproject.org [209.132.181.4] port 22.
debug1: Connection established.
debug1: identity file /home/home/mufti/.ssh/id_rsa type 0
debug1: identity file /home/home/mufti/.ssh/id_rsa-cert type -1
debug1: identity file /home/home/mufti/.ssh/id_dsa type -1
debug1: identity file /home/home/mufti/.ssh/id_dsa-cert type -1
debug1: identity file /home/home/mufti/.ssh/id_ecdsa type -1
debug1: identity file /home/home/mufti/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/home/mufti/.ssh/id_ed25519 type -1
debug1: identity file /home/home/mufti/.ssh/id_ed25519-cert type -1
debug1: identity file /home/home/mufti/.ssh/id_xmss type -1
debug1: identity file /home/home/mufti/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat
OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7*
compat 0x0402
debug2: fd 4 setting O_NONBLOCK
debug1: Authenticating to pkgs.fedoraproject.org:22 as 'mufti11'
debug3: hostkeys_foreach: reading file "/home/home/mufti/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file
/home/home/mufti/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys from pkgs.fedoraproject.org
debug3: order_hostkeyalgs: prefer hostkeyalgs:
rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms:

Re: Fedora Account Data Update mufti11

[Dominik 'Rathann' Mierzejewski]

On Friday, 03 January 2020 at 14:28, J. Scheurich wrote:
> > You might have to wait a bit until the changes have propagated.
> > If it still doesn't work, make sure the .ssh/id_rsa file has mode 600,
> > otherwise OpenSSH will give you errors.
> Thanks, but it still do not work:
> 
> $ ls -l .ssh/id_rsa.pub
> -rw---. 1 mufti mufti 575 Jan  3 13:41 .ssh/id_rsa.pub

I think Fabio meant that the private key (.ssh/id_rsa) should be mode 600.
Public key (.ssh/id_rsa.pub) must be mode 644. What are the permissions
on .ssh directory (ls -ld ~/.ssh)?

What does
ssh -vvv muft...@pkgs.fedoraproject.org
say?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Account Data Update mufti11

[J. Scheurich]

You might have to wait a bit until the changes have propagated.
If it still doesn't work, make sure the .ssh/id_rsa file has mode 600,
otherwise OpenSSH will give you errors.

Thanks, but it still do not work:

$ ls -l .ssh/id_rsa.pub
-rw---. 1 mufti mufti 575 Jan  3 13:41 .ssh/id_rsa.pub
[mufti@linux ~]$ fedpkg clone wdune
Cloning into 'wdune'...
muft...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.

so long
MUFTI
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Account Data Update mufti11

[Fabio Valentini]

On Fri, Jan 3, 2020 at 3:08 PM J. Scheurich  wrote:
>
> Hi,
>
> I tried:
>
> $ fedpkg clone wdune
> Cloning into 'wdune'...
> muft...@pkgs.fedoraproject.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> Could not execute clone: Failed to execute command.
>
>
> I logged into FAS and updated my ssh key and gpg.
>
> I got a email with:
>
> You have just updated information about your account. If you did not request
> these changes please contactad...@fedoraproject.org and let them know. Your
> updated information is:
>
> username: mufti11
> full name: J. "MUFTI" Scheurich
> ircnick: None
> telephone: 071150479845
> locale: en
> timezone: Europe/Berlin
> country code: DE
> latitude: None
> longitude: None
> privacy flag: False
> ssh_key: ssh-rsa
> B3NzaC1yc2EDAQABAAABgQC5dS3z4m/uwKXJqfptOYn7I3bM3aVc0yu/FUD6Ne4O7kiQu5grScVHvn2oSU/3FhWNbriAHuJ6sZ2HWXg/CnS0MeX7KOFznP0YeGmnt0zQKfJ+zH6S2bZI0vZwmr2R5KtVyl7JEEqGI3MF794XflsrQoHku/aYTr69vRSKZW8u9veltI1aSj/c3J9XsvzOEnRiNiix16XSYRZLpm3dXhgFaqDB/HsnK4MxsWC42Pavc0sxQSJNxaD+syCwxM7e69aEqH2Ov38ydR10aXYODwawvqQWndu5ZHSbN5tPGTDN7tuHrG8KDvZY4AHLLrfS1vyCFb4ovu7JszeDcaRwKO3JPqSHBJ0aDNy5STce0cNkReKFiALSUuZ2yNAjatSrUowLmYmt+tfBn4JXbizfUzRQ3Wm8sOToupvpvjBBhLyTQeyk81ZqSGXHAdvqUMwipvTv3Jwc+MadRzRszqKFdzJx8JtTkeQTN3y2X4M4i32B8bHvRsc9ODOh4J+sgbTsiCc=mu...@linux.fritz.box
>
> gpg_keyid: 5269558ED797EDD374D1C844F8FBBEF0632A9918
>
> If the above information is incorrect, please log in and fix it:
>
> https://admin.fedoraproject.org/accounts/user/edit/mufti11
>
>
>
> It looks lik the information is correct:
>
> $ cat ~/.ssh/id_rsa.pub
> ssh-rsa
> B3NzaC1yc2EDAQABAAABgQC5dS3z4m/uwKXJqfptOYn7I3bM3aVc0yu/FUD6Ne4O7kiQu5grScVHvn2oSU/3FhWNbriAHuJ6sZ2HWXg/CnS0MeX7KOFznP0YeGmnt0zQKfJ+zH6S2bZI0vZwmr2R5KtVyl7JEEqGI3MF794XflsrQoHku/aYTr69vRSKZW8u9veltI1aSj/c3J9XsvzOEnRiNiix16XSYRZLpm3dXhgFaqDB/HsnK4MxsWC42Pavc0sxQSJNxaD+syCwxM7e69aEqH2Ov38ydR10aXYODwawvqQWndu5ZHSbN5tPGTDN7tuHrG8KDvZY4AHLLrfS1vyCFb4ovu7JszeDcaRwKO3JPqSHBJ0aDNy5STce0cNkReKFiALSUuZ2yNAjatSrUowLmYmt+tfBn4JXbizfUzRQ3Wm8sOToupvpvjBBhLyTQeyk81ZqSGXHAdvqUMwipvTv3Jwc+MadRzRszqKFdzJx8JtTkeQTN3y2X4M4i32B8bHvRsc9ODOh4J+sgbTsiCc=
> mu...@linux.fritz.box
> $ gpg -ka mufti11
> pub   rsa4096 2019-06-11 [SCEA] [expires: 2020-06-10]
>7686907C86109D8A31A004AC3005F9A641282A81
> uid   [ultimate] Jörg Scheurich (white_dune upstream)
> 
>
> pub   rsa2048 2019-12-23 [SC] [expires: 2021-12-22]
>5269558ED797EDD374D1C844F8FBBEF0632A9918
> uid   [ultimate] J. Sheurih 
> sub   rsa2048 2019-12-23 [E]
>
> But i still get:
>
> $ fedpkg clone wdune
> Cloning into 'wdune'...
> muft...@pkgs.fedoraproject.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> Could not execute clone: Failed to execute command.
>
> Any idears ?

You might have to wait a bit until the changes have propagated.
If it still doesn't work, make sure the .ssh/id_rsa file has mode 600,
otherwise OpenSSH will give you errors.

Fabio

>
> so long
> MUFTI
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self-introduction

[Petr Viktorin]

On 2019-12-31 13:55, Fabian Affolter wrote:

Hi all,

I don't want to repeat myself, please take a look at my wiki page [1].

Why I want to join? I have one too many Python package and I started to
add the python-sig as admin. But it goes both ways, if the SIG has
access to my packages I want to be part of the SIG.  My name is in the
member list [2] for quite a while but I guess that doesn't come with the
right permissions.


Welcome! As the list says, you've been a member of Python SIG for a long 
time. That's basically just people who care about Python on Fedora and 
are on this list :)


The "python-sig" FAS group [3] is something slightly different. It's 
confusingly named (IIRC only groups with "-sig" in their name can get 
some permissions). It's there for people who want to fix Python-related 
issues in all the packages. Something like provenpackagers for Python.
Is that what you want? (From your mail it seems the confusing name got 
you...)


I'm not a sponsor in the FAS group, but I'd be glad to have you on board :)


[1] https://fedoraproject.org/wiki/User:Fab
[2] https://fedoraproject.org/wiki/SIGs/Python/Members_list


[3] https://fedoraproject.org/wiki/SIGs/Python#Python_SIG_FAS_group
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org

Fwd: Fedora Account Data Update mufti11

[J. Scheurich]

Hi,

I tried:

$ fedpkg clone wdune
Cloning into 'wdune'...
muft...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.


I logged into FAS and updated my ssh key and gpg.

I got a email with:

You have just updated information about your account. If you did not request
these changes please contactad...@fedoraproject.org and let them know. Your
updated information is:

username: mufti11
full name: J. "MUFTI" Scheurich
ircnick: None
telephone: 071150479845
locale: en
timezone: Europe/Berlin
country code: DE
latitude: None
longitude: None
privacy flag: False
ssh_key: ssh-rsa
B3NzaC1yc2EDAQABAAABgQC5dS3z4m/uwKXJqfptOYn7I3bM3aVc0yu/FUD6Ne4O7kiQu5grScVHvn2oSU/3FhWNbriAHuJ6sZ2HWXg/CnS0MeX7KOFznP0YeGmnt0zQKfJ+zH6S2bZI0vZwmr2R5KtVyl7JEEqGI3MF794XflsrQoHku/aYTr69vRSKZW8u9veltI1aSj/c3J9XsvzOEnRiNiix16XSYRZLpm3dXhgFaqDB/HsnK4MxsWC42Pavc0sxQSJNxaD+syCwxM7e69aEqH2Ov38ydR10aXYODwawvqQWndu5ZHSbN5tPGTDN7tuHrG8KDvZY4AHLLrfS1vyCFb4ovu7JszeDcaRwKO3JPqSHBJ0aDNy5STce0cNkReKFiALSUuZ2yNAjatSrUowLmYmt+tfBn4JXbizfUzRQ3Wm8sOToupvpvjBBhLyTQeyk81ZqSGXHAdvqUMwipvTv3Jwc+MadRzRszqKFdzJx8JtTkeQTN3y2X4M4i32B8bHvRsc9ODOh4J+sgbTsiCc=mu...@linux.fritz.box

gpg_keyid: 5269558ED797EDD374D1C844F8FBBEF0632A9918

If the above information is incorrect, please log in and fix it:

https://admin.fedoraproject.org/accounts/user/edit/mufti11



It looks lik the information is correct:

$ cat ~/.ssh/id_rsa.pub
ssh-rsa
B3NzaC1yc2EDAQABAAABgQC5dS3z4m/uwKXJqfptOYn7I3bM3aVc0yu/FUD6Ne4O7kiQu5grScVHvn2oSU/3FhWNbriAHuJ6sZ2HWXg/CnS0MeX7KOFznP0YeGmnt0zQKfJ+zH6S2bZI0vZwmr2R5KtVyl7JEEqGI3MF794XflsrQoHku/aYTr69vRSKZW8u9veltI1aSj/c3J9XsvzOEnRiNiix16XSYRZLpm3dXhgFaqDB/HsnK4MxsWC42Pavc0sxQSJNxaD+syCwxM7e69aEqH2Ov38ydR10aXYODwawvqQWndu5ZHSbN5tPGTDN7tuHrG8KDvZY4AHLLrfS1vyCFb4ovu7JszeDcaRwKO3JPqSHBJ0aDNy5STce0cNkReKFiALSUuZ2yNAjatSrUowLmYmt+tfBn4JXbizfUzRQ3Wm8sOToupvpvjBBhLyTQeyk81ZqSGXHAdvqUMwipvTv3Jwc+MadRzRszqKFdzJx8JtTkeQTN3y2X4M4i32B8bHvRsc9ODOh4J+sgbTsiCc=
mu...@linux.fritz.box
$ gpg -ka mufti11
pub   rsa4096 2019-06-11 [SCEA] [expires: 2020-06-10]
  7686907C86109D8A31A004AC3005F9A641282A81
uid   [ultimate] Jörg Scheurich (white_dune upstream)


pub   rsa2048 2019-12-23 [SC] [expires: 2021-12-22]
  5269558ED797EDD374D1C844F8FBBEF0632A9918
uid   [ultimate] J. Sheurih 
sub   rsa2048 2019-12-23 [E]

But i still get:

$ fedpkg clone wdune
Cloning into 'wdune'...
muft...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.

Any idears ?

so long
MUFTI
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: lv2-sorcer is not installable

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 03, 2020 at 08:36:45AM -0500, Code Zombie wrote:
> Hi
> 
> lv2-sorcer cannot be installed on Fedora 31. Seems like the libntk lib
> needed by the package is not provided by any packages. The full
> installation error is as follows:
> 
> ```
>  sudo dnf install lv2-sorcer
> Last metadata expiration check: 0:32:35 ago on Fri 03 Jan 2020 08:00:41 AM
> EST.
> Error:
>  Problem: conflicting requests
>   - nothing provides libntk.so.1()(64bit) needed by
> lv2-sorcer-1.1-2320131104git18e6891.fc31.x86_64
>   - nothing provides libntk_images.so.1()(64bit) needed by
> lv2-sorcer-1.1-2320131104git18e6891.fc31.x86_64
> (try to add '--skip-broken' to skip uninstallable packages)
> ```

The dep was provided by non-ntk, which got retired about half a year
ago [1] after FTBFSing since F29 [2].

[1] 
https://src.fedoraproject.org/rpms/non-ntk/c/d0ea7bd9216c9d2edae690749a58a7bbe36f2c72?branch=master
[2] https://koji.fedoraproject.org/koji/packageinfo?packageID=16952

To keep lv2-sorcer alive, non-ntk would need to be unretired.

Zbyszek
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[Artem Tim]

I did draft package of vokoscreenNG if someone interesting
RR: https://bugzilla.redhat.com/show_bug.cgi?id=1787578

Works without ffmpeg. Thanks for tip @Neal.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1778465

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #5 from Petr Pisar  ---
The package is still properly tagged and should exist in the repository:

$ koji list-tag-history --build perl-Data-Entropy-0.007-11.el8
Sun Dec  8 01:52:46 2019: perl-Data-Entropy-0.007-11.el8 tagged into
epel8-testing-candidate by eseyman
Sun Dec  8 01:56:46 2019: perl-Data-Entropy-0.007-11.el8 tagged into
epel8-signing-pending by bodhi
Sun Dec  8 01:56:48 2019: perl-Data-Entropy-0.007-11.el8 tagged into
epel8-testing-pending by autopen
Sun Dec  8 01:56:48 2019: perl-Data-Entropy-0.007-11.el8 untagged from
epel8-signing-pending by autopen
Mon Dec  9 03:11:28 2019: perl-Data-Entropy-0.007-11.el8 untagged from
epel8-testing-candidate by bodhi
Mon Dec  9 03:11:28 2019: perl-Data-Entropy-0.007-11.el8 tagged into
epel8-testing by bodhi
Mon Dec  9 03:11:43 2019: perl-Data-Entropy-0.007-11.el8 untagged from
epel8-testing-pending by bodhi
Fri Dec 13 15:06:35 2019: perl-Data-Entropy-0.007-11.el8 tagged into
epel8-override by bodhi
Mon Dec 23 03:24:07 2019: perl-Data-Entropy-0.007-11.el8 tagged into
epel8-pending by bodhi
Fri Dec 27 18:05:34 2019: perl-Data-Entropy-0.007-11.el8 tagged into epel8 by
bodhi [still active]
Fri Dec 27 18:05:34 2019: perl-Data-Entropy-0.007-11.el8 untagged from
epel8-testing by bodhi
Sat Dec 28 16:00:03 2019: perl-Data-Entropy-0.007-11.el8 untagged from
epel8-override by bodhi
Fri Jan  3 10:32:40 2020: perl-Data-Entropy-0.007-11.el8 tagged into
epel8-pending by bodhi
Fri Jan  3 10:32:40 2020: perl-Data-Entropy-0.007-11.el8 untagged from
epel8-pending by bodhi
Fri Jan  3 10:44:15 2020: perl-Data-Entropy-0.007-11.el8 untagged from
epel8-pending by bodhi

The spurious message in Bodhi was caused by congested Fedora messaging bus and
subsequent timeouts and restarts of Koji and Bodhi systems. It should not
affect the package.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

lv2-sorcer is not installable

[Code Zombie]

Hi

lv2-sorcer cannot be installed on Fedora 31. Seems like the libntk lib
needed by the package is not provided by any packages. The full
installation error is as follows:

```
 sudo dnf install lv2-sorcer
Last metadata expiration check: 0:32:35 ago on Fri 03 Jan 2020 08:00:41 AM
EST.
Error:
 Problem: conflicting requests
  - nothing provides libntk.so.1()(64bit) needed by
lv2-sorcer-1.1-2320131104git18e6891.fc31.x86_64
  - nothing provides libntk_images.so.1()(64bit) needed by
lv2-sorcer-1.1-2320131104git18e6891.fc31.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
```

- Mehdi
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1778465] [RFE] EPEL-8 branch for perl-Data-Entropy

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1778465

Andrew Bauer  changed:

   What|Removed |Added

 CC||zonexpertconsulting@outlook
   ||.com



--- Comment #4 from Andrew Bauer  ---
perl-Data-Entropy is a new runtime requirement for a soon-to-be-released new
version of ZoneMinder, which lives over in RPMFusion.

Just when it looked like the long wait was over, Bodhi kicked this build out:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6a5f5020bf

Anyone know how to troubleshoot this?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: peek package

[Neal Gompa]

On Fri, Jan 3, 2020 at 5:00 AM František Šumšal  wrote:
>
> On 1/3/20 10:49 AM, Leigh Scott wrote:
> >> But what about users which actually have ffmpeg installed? Do you think
> >> they don't deserve having peek in menu?
> >>
> >> On Fri, Jan 3, 2020, 04:02 John M. Harris Jr  >> wrote:
> >
> > NO, it's not required on cinnamon, users can use the screenshot+ Record 
> > desktop applet instead.
>
> Could you, please, stop with these definitely uncalled for shout outs? Users 
> should definitely
> have a freedom of choice, and as Samuel pointed out in this thread, the 
> package is not installed
> by default, so should you find it unsuitable for your system (either a 
> different DE or missing
> ffmpeg), you can simply uninstall it and replace it with any of the numerous 
> alternatives already
> previously mentioned.
>
> Throwing tantrum because peek doesn't work in your DE won't help in any way 
> apart from causing
> unnecessary flame wars.
>

Well, the truth is, it *does* work. We just don't have a crippled
version of ffmpeg in Fedora. I wish we did, but I vaguely recall
something indicating we can't have one. :(

Anyway, vokoscreen was rewritten to use GStreamer now, so that can be
packaged and used everywhere...
https://github.com/vkohaupt/vokoscreenNG




--
真実はいつも一つ！/ Always, there's only one truth!
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[Michael Schwendt]

On Fri, 3 Jan 2020 12:14:37 +0100, Dominik 'Rathann' Mierzejewski wrote:

> > > > I suspect there would be interest in having a royalty free version of 
> > > > FFMPEG
> > > 
> > > No, please, don't do this. It will be a huge headache for RPM Fusion
> > > maintainers.  
> > 
> > What sort of "huge headache" would that be? Third party repos like RPM 
> > Fusion
> > can still use package Epoch to replace base distribution packages.  
> 
> We have a strict policy of not doing that.

Which implies that the "huge headache" is self-induced.

This has been discussed years ago already for various 3rd party repos, who
did override base dist packages. The policy could be less strict with
regard to add-on packages, which would duplicate a Fedora dist package and
fork it with more features built in.

No need to do that for core system libs like glibc, but sometimes it
would reduce the maintenance requirements. For some apps and libs the
feature set cannot be completed via add-ons/plugins. And RPM Fusion replaces
some base dist packages via conflicts anyway in some cases. Example:
audacity-freeworld vs. audacity

> We do try to maintain add-on
> and alternative packages like chromium-libs-media-freeworld (alternative
> for chromium-libs-media built with all codecs) which is a headache to
> maintain in sync with Fedora's chromium.

Anything with inter-dependencies requires some maintenance. Forked
"alternative packages", which implicitly or explicitly conflict with base
dist packages, don't reduce the maintenance requirements.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: GenericError: cannot update build

[Jan Synacek]

On Fri, Jan 3, 2020 at 12:37 PM Brad Bell  wrote:

> I do not understand this error message; i.e., I have no idea what the
> cause is ?
>
> Looking at the informaiton for the build
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178
>
> The only failure message I see is
>  GenericError: cannot update build 1425936, state: COMPLETE
>
> The output on my screen is:
>
> cppad>fedpkg build
> Building cppad-2020.0-1.fc31 for f31-candidate
> Created task: 40063178
> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178
> Watching tasks (this may be safely interrupted)...
> 40063178 build (f31-candidate,
> /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): free
> 40063178 build (f31-candidate,
> /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): free ->
> open (buildvm-05.phx2.fedoraproject.org)
>40063191 buildArch (cppad-2020.0-1.fc31.src.rpm, ppc64le): open
> (buildvm-ppc64le-14.ppc.fedoraproject.org)
>40063189 buildArch (cppad-2020.0-1.fc31.src.rpm, x86_64): open
> (buildvm-32.phx2.fedoraproject.org)
>40063187 buildArch (cppad-2020.0-1.fc31.src.rpm, armv7hl): open
> (buildvm-armv7-17.arm.fedoraproject.org)
>40063188 buildArch (cppad-2020.0-1.fc31.src.rpm, i686): open (
> buildhw-09.phx2.fedoraproject.org)
>40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): free
>40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): free
>40063179 buildSRPMFromSCM
> (/rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): closed
>40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): free ->
> open
> (buildvm-s390x-24.s390.fedoraproject.org)
>40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): free ->
> open
> (buildvm-aarch64-06.arm.fedoraproject.org)
>40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): open
> (buildvm-s390x-24.s390.fedoraproject.org) -> closed
>0 free  6 open  2 done  0 failed
>40063188 buildArch (cppad-2020.0-1.fc31.src.rpm, i686): open
> (buildhw-09.phx2.fedoraproject.org) -> closed
>0 free  5 open  3 done  0 failed
>40063189 buildArch (cppad-2020.0-1.fc31.src.rpm, x86_64): open
> (buildvm-32.phx2.fedoraproject.org) -> closed
>0 free  4 open  4 done  0 failed
>40063191 buildArch (cppad-2020.0-1.fc31.src.rpm, ppc64le): open
> (buildvm-ppc64le-14.ppc.fedoraproject.org) -> closed
>0 free  3 open  5 done  0 failed
>40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): open
> (buildvm-aarch64-06.arm.fedoraproject.org) -> closed
>0 free  2 open  6 done  0 failed
>40063187 buildArch (cppad-2020.0-1.fc31.src.rpm, armv7hl): open
> (buildvm-armv7-17.arm.fedoraproject.org) -> closed
>0 free  1 open  7 done  0 failed
> 40063178 build (f31-candidate,
> /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): open
> (buildvm-05.phx2.fedoraproject.org) -> FAILED: GenericError: cannot
> update build 1425936, state:
> COMPLETE
>0 free  0 open  7 done  1 failed
>
> 40063178 build (f31-candidate,
> /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664) failed
> cppad>
>

I have already filed https://pagure.io/fedora-infrastructure/issue/8496. It
may not be obvious from the description, but it's the same problem.
-- 
Jan Synacek
Software Engineer, Red Hat
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

GenericError: cannot update build

[Brad Bell]

I do not understand this error message; i.e., I have no idea what the cause is ?

Looking at the informaiton for the build
    https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178

The only failure message I see is
    GenericError: cannot update build 1425936, state: COMPLETE

The output on my screen is:

cppad>fedpkg build
Building cppad-2020.0-1.fc31 for f31-candidate
Created task: 40063178
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178
Watching tasks (this may be safely interrupted)...
40063178 build (f31-candidate, 
/rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): free
40063178 build (f31-candidate, /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): free -> 
open (buildvm-05.phx2.fedoraproject.org)
  40063191 buildArch (cppad-2020.0-1.fc31.src.rpm, ppc64le): open 
(buildvm-ppc64le-14.ppc.fedoraproject.org)
  40063189 buildArch (cppad-2020.0-1.fc31.src.rpm, x86_64): open 
(buildvm-32.phx2.fedoraproject.org)
  40063187 buildArch (cppad-2020.0-1.fc31.src.rpm, armv7hl): open 
(buildvm-armv7-17.arm.fedoraproject.org)

  40063188 buildArch (cppad-2020.0-1.fc31.src.rpm, i686): open 
(buildhw-09.phx2.fedoraproject.org)
  40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): free
  40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): free
  40063179 buildSRPMFromSCM 
(/rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): closed
  40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): free -> open 
(buildvm-s390x-24.s390.fedoraproject.org)
  40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): free -> open 
(buildvm-aarch64-06.arm.fedoraproject.org)
  40063192 buildArch (cppad-2020.0-1.fc31.src.rpm, s390x): open 
(buildvm-s390x-24.s390.fedoraproject.org) -> closed

  0 free  6 open  2 done  0 failed
  40063188 buildArch (cppad-2020.0-1.fc31.src.rpm, i686): open 
(buildhw-09.phx2.fedoraproject.org) -> closed

  0 free  5 open  3 done  0 failed
  40063189 buildArch (cppad-2020.0-1.fc31.src.rpm, x86_64): open 
(buildvm-32.phx2.fedoraproject.org) -> closed

  0 free  4 open  4 done  0 failed
  40063191 buildArch (cppad-2020.0-1.fc31.src.rpm, ppc64le): open 
(buildvm-ppc64le-14.ppc.fedoraproject.org) -> closed

  0 free  3 open  5 done  0 failed
  40063190 buildArch (cppad-2020.0-1.fc31.src.rpm, aarch64): open 
(buildvm-aarch64-06.arm.fedoraproject.org) -> closed

  0 free  2 open  6 done  0 failed
  40063187 buildArch (cppad-2020.0-1.fc31.src.rpm, armv7hl): open 
(buildvm-armv7-17.arm.fedoraproject.org) -> closed

  0 free  1 open  7 done  0 failed
40063178 build (f31-candidate, /rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664): open 
(buildvm-05.phx2.fedoraproject.org) -> FAILED: GenericError: cannot update build 1425936, state: 
COMPLETE

  0 free  0 open  7 done  1 failed

40063178 build (f31-candidate, 
/rpms/cppad.git:82bd2cc17cc49f57aec7aabf1d0aeff9e664) failed
cppad>

___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[Dominik 'Rathann' Mierzejewski]

On Friday, 03 January 2020 at 11:14, Michael Schwendt wrote:
> On Thu, 2 Jan 2020 13:07:40 +0100, Vitaly Zaitsev via devel wrote:
> 
> > On 02.01.2020 10:05, Benson Muite wrote:
> > > I suspect there would be interest in having a royalty free version of 
> > > FFMPEG  
> > 
> > No, please, don't do this. It will be a huge headache for RPM Fusion
> > maintainers.
> 
> What sort of "huge headache" would that be? Third party repos like RPM Fusion
> can still use package Epoch to replace base distribution packages.

We have a strict policy of not doing that. We do try to maintain add-on
and alternative packages like chromium-libs-media-freeworld (alternative
for chromium-libs-media built with all codecs) which is a headache to
maintain in sync with Fedora's chromium.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

[Panu Matilainen]

On 1/3/20 12:43 PM, Neal Gompa wrote:

On Fri, Jan 3, 2020 at 5:42 AM Panu Matilainen  wrote:


On 1/3/20 12:35 PM, Neal Gompa wrote:

On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen  wrote:


On 1/2/20 5:29 PM, Neal Gompa wrote:

On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton  wrote:



For us, since we don't have the SUSE patches that make PreReq do
things, the way we'd declare this with upstream RPM features would be:


Please don't spread misinformation, openSUSE doesn't have patches to
make PreReq anyhow special. They merely undo the deprecation warning
that is issued on PreReq. With or without that, a PreReq will be
translated to Requires(pre,preun) to simulate what the original PreReq did.



Huh, for some reason I thought it also did something else...



Requires: user(wwwrun)
OrderWithRequires: user(wwwrun)


I'm not sure how one is supposed to read the above, but certainly one
does NOT need both Requires and OrderWithRequires on the same thing in a
package. Requires(pre) might be in order because for user/group you
really want them installed first in case of loops, but this is details
without


OtherWithRequires makes it so that if it's in the same transaction,
it'll get installed before this package. Otherwise it doesn't matter,
yes.


Um, what?

OrderWithRequires behaves exactly like Requires for *ordering*. There's
no additional mystery magic there.

OtherWithRequires can be used to affect ordering in the case no hard
dependency exists. With users, there's always a hard dependency, and
OrderWithRequires achieves nothing at all but obfusctation.



Well, then, today I learned I guess. Does Requires(pre) work even
without a %pre script?


Yes, dependency processing is not connected to scriptlets in any way.

- Panu -
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: Updating Python RPM dependency generators

[Miro Hrončok]

On 03. 01. 20 10:33, Miro Hrončok wrote:

On 03. 01. 20 10:26, Miro Hrončok wrote:

On 02. 01. 20 9:59, Miro Hrončok wrote:
Hello, this is just a heads up that we are about to update the Python RPM 
dependency generators to support versions like 1.2.*, the ~= operator etc.


See the PR:

https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/4

The code is tested and no backwards incompatible breakage is anticipated 
(some requirements might end up being a bit different thou). If you get a 
weird behavior or broken deps because of this, please report here or trough 
bugzilla.



https://koschei.fedoraproject.org/package/python-matplotlib?collection=f32

Cannot chain different ops: (python3.8dist(pyparsing) >= 2.0.1 with 
python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0 with 
python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0 with 
python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0)



https://koschei.fedoraproject.org/package/python-sphinx?collection=f32

Cannot chain different ops: (python3.8dist(babel) < 2 or python3.8dist(babel) 
>= 2.0 with python3.8dist(babel) >= 1.3)


Reported at https://github.com/rpm-software-management/rpm/issues/995


Fix pending in https://bodhi.fedoraproject.org/updates/FEDORA-2020-f67e22279d

Hopefully, it will be pushed soon.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

[Neal Gompa]

On Fri, Jan 3, 2020 at 5:42 AM Panu Matilainen  wrote:
>
> On 1/3/20 12:35 PM, Neal Gompa wrote:
> > On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen  wrote:
> >>
> >> On 1/2/20 5:29 PM, Neal Gompa wrote:
> >>> On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton  wrote:
> >>
> >>> For us, since we don't have the SUSE patches that make PreReq do
> >>> things, the way we'd declare this with upstream RPM features would be:
> >>
> >> Please don't spread misinformation, openSUSE doesn't have patches to
> >> make PreReq anyhow special. They merely undo the deprecation warning
> >> that is issued on PreReq. With or without that, a PreReq will be
> >> translated to Requires(pre,preun) to simulate what the original PreReq did.
> >>
> >
> > Huh, for some reason I thought it also did something else...
> >
> >>>
> >>> Requires: user(wwwrun)
> >>> OrderWithRequires: user(wwwrun)
> >>
> >> I'm not sure how one is supposed to read the above, but certainly one
> >> does NOT need both Requires and OrderWithRequires on the same thing in a
> >> package. Requires(pre) might be in order because for user/group you
> >> really want them installed first in case of loops, but this is details
> >> without
> >
> > OtherWithRequires makes it so that if it's in the same transaction,
> > it'll get installed before this package. Otherwise it doesn't matter,
> > yes.
>
> Um, what?
>
> OrderWithRequires behaves exactly like Requires for *ordering*. There's
> no additional mystery magic there.
>
> OtherWithRequires can be used to affect ordering in the case no hard
> dependency exists. With users, there's always a hard dependency, and
> OrderWithRequires achieves nothing at all but obfusctation.
>

Well, then, today I learned I guess. Does Requires(pre) work even
without a %pre script?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

[Panu Matilainen]

On 1/3/20 12:35 PM, Neal Gompa wrote:

On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen  wrote:


On 1/2/20 5:29 PM, Neal Gompa wrote:

On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton  wrote:



For us, since we don't have the SUSE patches that make PreReq do
things, the way we'd declare this with upstream RPM features would be:


Please don't spread misinformation, openSUSE doesn't have patches to
make PreReq anyhow special. They merely undo the deprecation warning
that is issued on PreReq. With or without that, a PreReq will be
translated to Requires(pre,preun) to simulate what the original PreReq did.



Huh, for some reason I thought it also did something else...



Requires: user(wwwrun)
OrderWithRequires: user(wwwrun)


I'm not sure how one is supposed to read the above, but certainly one
does NOT need both Requires and OrderWithRequires on the same thing in a
package. Requires(pre) might be in order because for user/group you
really want them installed first in case of loops, but this is details
without


OtherWithRequires makes it so that if it's in the same transaction,
it'll get installed before this package. Otherwise it doesn't matter,
yes.


Um, what?

OrderWithRequires behaves exactly like Requires for *ordering*. There's 
no additional mystery magic there.


OtherWithRequires can be used to affect ordering in the case no hard 
dependency exists. With users, there's always a hard dependency, and 
OrderWithRequires achieves nothing at all but obfusctation.


- Panu -




___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

[Neal Gompa]

On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen  wrote:
>
> On 1/2/20 5:29 PM, Neal Gompa wrote:
> > On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton  wrote:
>
> > For us, since we don't have the SUSE patches that make PreReq do
> > things, the way we'd declare this with upstream RPM features would be:
>
> Please don't spread misinformation, openSUSE doesn't have patches to
> make PreReq anyhow special. They merely undo the deprecation warning
> that is issued on PreReq. With or without that, a PreReq will be
> translated to Requires(pre,preun) to simulate what the original PreReq did.
>

Huh, for some reason I thought it also did something else...

> >
> > Requires: user(wwwrun)
> > OrderWithRequires: user(wwwrun)
>
> I'm not sure how one is supposed to read the above, but certainly one
> does NOT need both Requires and OrderWithRequires on the same thing in a
> package. Requires(pre) might be in order because for user/group you
> really want them installed first in case of loops, but this is details
> without

OtherWithRequires makes it so that if it's in the same transaction,
it'll get installed before this package. Otherwise it doesn't matter,
yes.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[Michael Schwendt]

On Thu, 2 Jan 2020 13:07:40 +0100, Vitaly Zaitsev via devel wrote:

> On 02.01.2020 10:05, Benson Muite wrote:
> > I suspect there would be interest in having a royalty free version of 
> > FFMPEG  
> 
> No, please, don't do this. It will be a huge headache for RPM Fusion
> maintainers.

What sort of "huge headache" would that be? Third party repos like RPM Fusion
can still use package Epoch to replace base distribution packages.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[František Šumšal]

On 1/3/20 10:49 AM, Leigh Scott wrote:
>> But what about users which actually have ffmpeg installed? Do you think
>> they don't deserve having peek in menu?
>>
>> On Fri, Jan 3, 2020, 04:02 John M. Harris Jr > wrote:
> 
> NO, it's not required on cinnamon, users can use the screenshot+ Record 
> desktop applet instead.

Could you, please, stop with these definitely uncalled for shout outs? Users 
should definitely
have a freedom of choice, and as Samuel pointed out in this thread, the package 
is not installed
by default, so should you find it unsuitable for your system (either a 
different DE or missing
ffmpeg), you can simply uninstall it and replace it with any of the numerous 
alternatives already
previously mentioned.

Throwing tantrum because peek doesn't work in your DE won't help in any way 
apart from causing
unnecessary flame wars.

Thank you.

-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[Leigh Scott]

> But what about users which actually have ffmpeg installed? Do you think
> they don't deserve having peek in menu?
> 
> On Fri, Jan 3, 2020, 04:02 John M. Harris Jr  wrote:

NO, it's not required on cinnamon, users can use the screenshot+ Record desktop 
applet instead.
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: Updating Python RPM dependency generators

[Miro Hrončok]

On 03. 01. 20 10:26, Miro Hrončok wrote:

On 02. 01. 20 9:59, Miro Hrončok wrote:
Hello, this is just a heads up that we are about to update the Python RPM 
dependency generators to support versions like 1.2.*, the ~= operator etc.


See the PR:

https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/4

The code is tested and no backwards incompatible breakage is anticipated (some 
requirements might end up being a bit different thou). If you get a weird 
behavior or broken deps because of this, please report here or trough bugzilla.



https://koschei.fedoraproject.org/package/python-matplotlib?collection=f32

Cannot chain different ops: (python3.8dist(pyparsing) >= 2.0.1 with 
python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0 with 
python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0 with 
python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0)



https://koschei.fedoraproject.org/package/python-sphinx?collection=f32

Cannot chain different ops: (python3.8dist(babel) < 2 or python3.8dist(babel) >= 
2.0 with python3.8dist(babel) >= 1.3)


Reported at https://github.com/rpm-software-management/rpm/issues/995

Will consider reverting.


Other failures:

https://koschei.fedoraproject.org/affected-by/python3-rpm-generators?epoch1=0=9=2.fc31=0=10=1.fc32=f32

ara: Cannot chain different ops: (python3.8dist(pbr) >= 2 with 
python3.8dist(pbr) < 2.1 or python3.8dist(pbr) >= 2.1.0)




--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: Updating Python RPM dependency generators

[Igor Gnatenko]

Ugh, that is a bug in the generator. It should do something like ((x
with y) or (z with 0)).

On Fri, Jan 3, 2020 at 10:26 AM Miro Hrončok  wrote:
>
> On 02. 01. 20 9:59, Miro Hrončok wrote:
> > Hello, this is just a heads up that we are about to update the Python RPM
> > dependency generators to support versions like 1.2.*, the ~= operator etc.
> >
> > See the PR:
> >
> > https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/4
> >
> > The code is tested and no backwards incompatible breakage is anticipated 
> > (some
> > requirements might end up being a bit different thou). If you get a weird
> > behavior or broken deps because of this, please report here or trough 
> > bugzilla.
>
>
> https://koschei.fedoraproject.org/package/python-matplotlib?collection=f32
>
> Cannot chain different ops: (python3.8dist(pyparsing) >= 2.0.1 with
> python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0 with
> python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0 with
> python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0)
>
>
> https://koschei.fedoraproject.org/package/python-sphinx?collection=f32
>
> Cannot chain different ops: (python3.8dist(babel) < 2 or python3.8dist(babel) 
> >=
> 2.0 with python3.8dist(babel) >= 1.3)
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: Updating Python RPM dependency generators

[Miro Hrončok]

On 02. 01. 20 9:59, Miro Hrončok wrote:
Hello, this is just a heads up that we are about to update the Python RPM 
dependency generators to support versions like 1.2.*, the ~= operator etc.


See the PR:

https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/4

The code is tested and no backwards incompatible breakage is anticipated (some 
requirements might end up being a bit different thou). If you get a weird 
behavior or broken deps because of this, please report here or trough bugzilla.



https://koschei.fedoraproject.org/package/python-matplotlib?collection=f32

Cannot chain different ops: (python3.8dist(pyparsing) >= 2.0.1 with 
python3.8dist(pyparsing) < 2.1.2 or python3.8dist(pyparsing) >= 2.1.2.0 with 
python3.8dist(pyparsing) < 2.1.6 or python3.8dist(pyparsing) >= 2.1.6.0 with 
python3.8dist(pyparsing) < 2.0.4 or python3.8dist(pyparsing) >= 2.0.4.0)



https://koschei.fedoraproject.org/package/python-sphinx?collection=f32

Cannot chain different ops: (python3.8dist(babel) < 2 or python3.8dist(babel) >= 
2.0 with python3.8dist(babel) >= 1.3)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: peek package

[Samuel Sieb]

On 1/2/20 6:55 PM, John M. Harris Jr wrote:

On Wednesday, January 1, 2020 7:34:27 PM MST Leigh Scott wrote:

Why we should drop such useful app just because it doesn't work on
Cinnamon? It works on GNOME without ffpmeg and rpm fusion repo, see
screenshot [1].


Please prevent your useless app from displaying in cinnamon menu, I'm sure
Mate, XFCE and LXDE would also like it removed from their menus as well.


Agreed, I'd like to see it removed from Plasma's menu by default as well.


What is the problem?  It's not installed by default.  If you don't want 
it, then don't install it.  But don't block those that do have a use for it.

___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1768799] perl-Test-LWP-UserAgent for EL8

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1768799
Bug 1768799 depends on bug 1744690, which changed state.

Bug 1744690 Summary: [RFE] EPEL8 branch of perl-Plack
https://bugzilla.redhat.com/show_bug.cgi?id=1744690

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1744690

Petr Pisar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-01-03 09:05:51



--- Comment #16 from Petr Pisar  ---
Bodhi probably forgets closing bugs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

[Panu Matilainen]

On 1/2/20 5:29 PM, Neal Gompa wrote:

On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton  wrote:



For us, since we don't have the SUSE patches that make PreReq do
things, the way we'd declare this with upstream RPM features would be:


Please don't spread misinformation, openSUSE doesn't have patches to 
make PreReq anyhow special. They merely undo the deprecation warning 
that is issued on PreReq. With or without that, a PreReq will be 
translated to Requires(pre,preun) to simulate what the original PreReq did.




Requires: user(wwwrun)
OrderWithRequires: user(wwwrun)


I'm not sure how one is supposed to read the above, but certainly one 
does NOT need both Requires and OrderWithRequires on the same thing in a 
package. Requires(pre) might be in order because for user/group you 
really want them installed first in case of loops, but this is details 
without


- Panu -
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1751247] [RFE] EPEL8 branch of perl-Sereal

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1751247

Paul Howarth  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-01-03 08:59:13



--- Comment #14 from Paul Howarth  ---
(In reply to Denis Fateyev from comment #13)
> Are these packages still on QA?

No, they were pushed to stable back in October, as per the previous comment.

I can see them here:
https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/p/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 838679] perl-Plack: EL-6 build

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=838679

Denis Fateyev  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WONTFIX
Last Closed||2020-01-03 08:56:32



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1744690] [RFE] EPEL8 branch of perl-Plack

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1744690



--- Comment #15 from Denis Fateyev  ---
Are these packages still on QA?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1751247] [RFE] EPEL8 branch of perl-Sereal

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1751247



--- Comment #13 from Denis Fateyev  ---
Are these packages still on QA?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: peek package

[Igor Gnatenko]

But what about users which actually have ffmpeg installed? Do you think
they don't deserve having peek in menu?

On Fri, Jan 3, 2020, 04:02 John M. Harris Jr  wrote:

> On Wednesday, January 1, 2020 7:34:27 PM MST Leigh Scott wrote:
> > > Why we should drop such useful app just because it doesn't work on
> > > Cinnamon? It works on GNOME without ffpmeg and rpm fusion repo, see
> > > screenshot [1].
> >
> >
> > Please prevent your useless app from displaying in cinnamon menu, I'm
> sure
> > Mate, XFCE and LXDE would also like it removed from their menus as well.
>
> > Add this to it's desktop file!
> >
> > 'OnlyShowIn=Gnome'
>
> Agreed, I'd like to see it removed from Plasma's menu by default as well.
>
> --
> John M. Harris, Jr.
> Splentity
>
> ___
> 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-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 02, 2020 at 12:27:46PM -0500, Neal Gompa wrote:
> > Would it make you feel better if I added a para to the Change page saying
> > that the sysusers.d definition may be split out into a separate package
> > if desired?
> >
> 
> Yes, it would. Guidelines for these kinds of splits should also be
> drafted for FPC review.

https://fedoraproject.org/w/index.php?title=Changes%2FAdopting_sysusers.d_format=revision=562436=562360

Zbyszek
___
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-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org