Re: List of long term FTBFS packages to be retired in February

2024-02-03 Thread Mamoru TASAKA 

Miro Hrončok wrote on 2024/02/04 2:17:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 40 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 4 weeks, i.e. around 2024-02-28.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f40.

I apologize for starting this process a bit later than required again.
Unfortunately, I had other work obligations.
Volunteers to take over this are always welcome.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 37.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

     Package  (co)maintainers

telepathy-gabble    aperezbios

The following packages require above mentioned packages:

Depending on: telepathy-gabble (31)
 sugar (maintained by: aperezbios, chimosky)
     sugar-0.120-6.fc40.noarch requires telepathy-gabble

 sugar-abacus (maintained by: chimosky)
     sugar-abacus-61-9.fc39.noarch requires sugar


 Too many dependencies for telepathy-gabble, not all listed here



Fixed telepathy-gabble .
Regards,
Mamoru
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Kevin Kofler via devel 
Kevin Kofler via devel wrote:
> Then we will submit 10-15+ *-x11 packages for review. It can be done.

PS: Users will only have to install plasma-workspace-x11. If there is some 
optional library that needs an ld.so.conf.d override or a plugin to support 
X11, it can be conditionally dragged in with a boolean dependency in
plasma-workspace-x11:
Requires: (kf6-foo-x11 if kf6-foo)

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Kevin Kofler via devel 
Steve Cossette wrote:
> There's also a secondary thing that I feel hasn't been discussed here
> though: I know work is being done right now to isolate the x11
> components of plasma and add build-time options to strip out those
> components. What happens when we (as-in, the KDE sig) split off those
> components and now you got 10-15+ x11 packages people gotta install to
> make it all work?

Then we will submit 10-15+ *-x11 packages for review. It can be done.

Thanks to ld.so.conf.d, it is even possible to override libraries with 
versions built with X11 support if it becomes necessary to rebuild, not just 
add, some libraries. I have experience with that (see the now defunct 
freetype-freeworld, only defunct because the patents either expired or were 
declared to be covered by the OIN and the functionality is now part of the 
normal freetype package). There are also packages in Fedora proper making 
use of that linker feature, e.g., it is (or at least used to be) used by 
CPU-optimized BLAS libraries.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Kevin Kofler via devel 
Neal Gompa wrote:
> It's extremely obvious that people want to use it. You replied to
> someone who did and denigrated their opinion. Frankly, I'm
> disappointed in your response as well as the tone of you and Kevin.

I cannot really speak for Sérgio. I do think his choice of words in the 
particular mail you are referring to could have been better. (In particular, 
I would not have used the word "crap" there.) But please keep in mind that 
he (like me) is not a native English speaker.

I can, though, speak for myself, and I am frankly surprised that you are 
offended by the tone of my messages. Are you sure that it is not the content 
that upsets you rather than the tone? And if it is, try asking you why the 
content upsets you. Maybe because it points out inconvenient facts?

> Neither of you are aligning with the Fedora Foundation of Friends, and
> the personal attacks were unwarranted and unwanted.

We (the KDE SIG and me) stopped being Friends when you (the KDE SIG) 
unilaterally decided to ban me from all your communication channels, a ban 
that has still not been lifted years after the alleged misconduct (on IRC 
only, but the ban was extended to the mailing list and even your Pagure 
issue trackers!) you accused me of.

Nevertheless, I am really trying hard to not make this personal. What I 
disagree with is the technical decision to remove X11 support from the 
Fedora Plasma packaging. I also objected right when you filed your Change 
Proposal that the KDE SIG has no authority to declare in the Change that 
Fedora will NOT ship something because other packagers are free to package 
it. A belief that at the time was actually shared by the KDE SIG, or at 
least by the one KDE SIG member who has publicly commented on it:
https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/11
Though the wording in the Change Proposal was not changed. Possibly because 
you did not believe at the time that I was serious about submitting those 
packages, just like others did not believe you were serious about removing 
X11 support from Plasma packaging. But I am of the kind that when I promise 
something, I tend to deliver on it.

> What we're doing is bold for sure, but aligns with two more of the Fedora
> Foundations, First and Features.

I can see how it aligns with "First", but how does removing a major feature 
that users rely on align with "Features"?

I also believe that denying users the choice of continuing to use X11 
despite upstream still supporting it does not align with the "Freedom" and 
"Friends" principles.

> And for the first time in a long time, Fedora KDE has generated
> significant buzz in the community and media.

Any press is good press? I believe that the coverage only hurts the 
reputation of the Fedora KDE SIG. If you see the discussions, many people 
are grabbing their virtual pitchforks, or silently switching distributions 
as a result of the news (even though it is actually fake news because I had 
already stated back in September that I would reintroduce the X11 packages 
should you remove them, a fact that the press has not bothered researching). 
Sure, there are some very vocal fanboys screaming "Death to X11!", but I 
really do not understand why, because nobody is forcing them to use X11. 
There is no need to remove X11 to make Wayland great.

> I'm excited for the future of Fedora KDE with Plasma Wayland, as well
> as what we're doing with the upstream KDE community. :)

And nobody is taking that away.

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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: sd_notify in mock

2024-02-03 Thread Vít Ondruch 

Ping? Anybody?


Vít



Dne 11. 01. 24 v 15:00 Vít Ondruch napsal(a):
Working on update of rubygem-puma, I observe following test failure 
trying build rubygem-rails in Mock:



~~~

/usr/share/ruby/socket.rb:68:in `connect': Errno::EACCES: Permission 
denied - connect(2) for /run/host/notify (Puma::SdNotify::NotifyError)

    from /usr/share/ruby/socket.rb:68:in `connect_internal'
    from /usr/share/ruby/socket.rb:141:in `connect'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:140:in 
`notify'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:53:in 
`ready'
    from 
/usr/share/gems/gems/puma-6.4.2/lib/puma/plugin/systemd.rb:17:in 
`block in start'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in 
`block in fire'

    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `each'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `fire'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:46:in 
`fire_on_booted!'

    from /usr/share/gems/gems/puma-6.4.2/lib/puma/single.rb:58:in `run'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/launcher.rb:194:in 
`run'
    from 
/usr/share/gems/gems/puma-6.4.2/lib/rack/handler/puma.rb:76:in `run'
    from /usr/share/gems/gems/rack-2.2.4/lib/rack/server.rb:327:in 
`start'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:38:in 
`start'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:143:in 
`block in perform'

    from :90:in `tap'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:134:in 
`perform'

    from /usr/share/gems/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
    from /usr/share/gems/gems/thor-1.2.1/lib/thor/invocation.rb:127:in 
`invoke_command'

    from /usr/share/gems/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command/base.rb:87:in 
`perform'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command.rb:48:in 
`invoke'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands.rb:18:in 
`'

    from /usr/share/ruby/bundled_gems.rb:74:in `require'
    from /usr/share/ruby/bundled_gems.rb:74:in `block (2 levels) in 
replace_require'

    from bin/rails:4:in `'
/usr/share/ruby/socket.rb:68:in `connect': Permission denied - 
connect(2) for /run/host/notify (Errno::EACCES)

    from /usr/share/ruby/socket.rb:68:in `connect_internal'
    from /usr/share/ruby/socket.rb:141:in `connect'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:140:in 
`notify'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:53:in 
`ready'
    from 
/usr/share/gems/gems/puma-6.4.2/lib/puma/plugin/systemd.rb:17:in 
`block in start'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in 
`block in fire'

    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `each'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `fire'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:46:in 
`fire_on_booted!'

    from /usr/share/gems/gems/puma-6.4.2/lib/puma/single.rb:58:in `run'
    from /usr/share/gems/gems/puma-6.4.2/lib/puma/launcher.rb:194:in 
`run'
    from 
/usr/share/gems/gems/puma-6.4.2/lib/rack/handler/puma.rb:76:in `run'
    from /usr/share/gems/gems/rack-2.2.4/lib/rack/server.rb:327:in 
`start'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:38:in 
`start'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:143:in 
`block in perform'

    from :90:in `tap'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:134:in 
`perform'

    from /usr/share/gems/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
    from /usr/share/gems/gems/thor-1.2.1/lib/thor/invocation.rb:127:in 
`invoke_command'

    from /usr/share/gems/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command/base.rb:87:in 
`perform'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command.rb:48:in 
`invoke'
    from 
/builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands.rb:18:in 
`'

    from /usr/share/ruby/bundled_gems.rb:74:in `require'
    from /usr/share/ruby/bundled_gems.rb:74:in `block (2 levels) in 
replace_require'

    from bin/rails:4:in `'
.

~~~

The full log is available here for the moment:

https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885294/

This is the sd_noti

Retirement of sundials2 seqan seqan2 wise2

2024-02-03 Thread Antonio T. sagitter 

Hi all.

Following packages will be retired in Rawhide branch:

seqan (deprecated by seqan3), https://src.fedoraproject.org/rpms/seqan

seqan2 (deprecated by seqan3), https://src.fedoraproject.org/rpms/seqan2

wise2 (unmaintained by upstream, no longer needed in Fedora), 
https://src.fedoraproject.org/rpms/wise2


sundials2 (oldest version of current sundials-6*, no longer needed in 
Fedora), https://src.fedoraproject.org/rpms/sundials2



Regards.
--
---
Antonio Trande
Fedora Project
https://fedoraproject.org/wiki/User:Sagitter
mailto: sagit...@fedoraproject.org
GPG key: 0x40FDA7B70789A9CD
GPG keys server: https://keys.openpgp.org/


OpenPGP_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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Dominique Martinet 
(Not involved in any way here so feel free to ignore most of what I'm
saying)

Marc Deop i Argemí wrote on Sat, Feb 03, 2024 at 03:16:47PM +0100:
> - If a user decided to install the X11 package and has an issue: who do you 
> think they are going to reach? who is gonna get the "bad publicity" for the 
> issue? ( specially when we are forced to tell them we don't support X11...)

I don't really understand this one -- why would they reach for the KDE
SIG specifically? What does "support" even mean in this context?


As a fedora user (not even using KDE), I don't care about SIGs, if I
have a problem I'll just open a bz against the package that gives me
trouble.
Now I'm sure some tickets will be open against KDE without specifying
they're using the X11 packages, but at least semi-automated bugs will
have a package list so it shouldn't be _that_ much trouble to just
reassign the bug to the x11 package if required (especially since x11 is
no longer selected by default and requires manual intervention to use,
I'd expect most users who care enough to report a bug to be aware of the
difference)

At this point it's no longer KDE SIG's problem -- it's whoever is
maintaining the package's role to follow up on that bz.
I haven't seen Kevin or anyone else say they'd just close the bugs as
"not my problem" -- x11 is still supported upstream so I'd expect they'd
at least forward the bug there, if they don't look into it themselves
directly.

Also if you're concerend about the "publicity", for users who cannot run
on wayland yet for whatever reason (hardware, buggy drivers...) having
the possibility to use x11 at all is still going to be much better PR
than "nope sorry we don't want to spend time on X11 just suffer through
the wayland bugs" which is exactly how this will sound to them (yes I
can understand the reasons that were given up for this and rationalize
this a bit better, but this isn't how it'll look for someone with
problems)


Long story short, I agree with the "if someone wants to do it let them
do" stance.
I can't speak about your second point (delaying upgrades), but from what
I've read of this thread it doesn't seem like there'd be a huge delay if
some minimal communication is in place, and the suggesstion of having a
KDE X11 sig to ensure it's not just a single person also makes sense
(although if it's a single package just having multiple maintainers to
it sounds enough to me)

-- 
Dominique Martinet | Asmadeus
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failure on fedora default backgrounds

2024-02-03 Thread Luya Tshimbalanga 


On 2024-02-03 12:12, JT wrote:
> Thank you all for the solution. I notice I lack access to commit 
changes on  f21-backgrounds so proven packagers are welcome to do so. 
Thanks


As I said on Monday when I replied to this ticket, I had talked to 
Neil about this already, I'm aware of the fix, but as I am on the road 
and unable to push commits to the repo until Sunday. Others are 
certainly allowed to step in and fix it, if they want to, but the 
problem isn't being ignored. I simply dont have the keys on my laptop 
I have with me to be able to push changes right now.  I will have that 
ability tomorrow.  If you cannot wait another day for this, then by 
all means someone else can push the fix to the various repos.

JT
Ok. You can check if the commits are correct on repository and adjust 
accordingly. Thanks.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failure on fedora default backgrounds

2024-02-03 Thread JT 
>  Thank you all for the solution. I notice I lack access to commit changes
on  f21-backgrounds so proven packagers are welcome to do so. Thanks

As I said on Monday when I replied to this ticket, I had talked to Neil
about this already, I'm aware of the fix, but as I am on the road and
unable to push commits to the repo until Sunday.  Others are certainly
allowed to step in and fix it, if they want to, but the problem isn't being
ignored. I simply dont have the keys on my laptop I have with me to be able
to push changes right now.  I will have that ability tomorrow.  If you
cannot wait another day for this, then by all means someone else can push
the fix to the various repos.
JT

On Sat, Feb 3, 2024 at 2:56 AM  wrote:

>
>
> On 2024-02-01 11:26 p.m., Neal Gompa  wrote:
> > On Fri, Feb 2, 2024 at 2:04 AM Mamoru TASAKA 
> wrote:
> > >
> > > Luya Tshimbalanga wrote on 2024/02/02 10:25:
> > >> Hello team,
> > >>
> > >> It appears a change within %{_kde4_datadir} macro caused failures on
> Rawhide affecting default Fedora backgrounds starting from 21.
> > >> Could someone from KDE SIG address that issue? Thanks.
> > >>
> > >>
> > >> Here is an extract of failure[1]  on for f35-backgrounds built on
> Rawhide:
> > >>
> > >> 
> > >>
> > >> RPM build errors:
> > >> error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > >>   File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > >> Child return code was: 1
> > >> '''
> > >>
> > >> Reference:
> > >> [1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075
> > >>
> > >
> > > I am not KDE sig member, but the above failure is most likely due to
> > > the following change:
> > >
> > >
> https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32
> > >
> > > /usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir}
> macro definition)
> > > was moved from kde-filesystem.rpm to kde4-filesystem.rpm .
> > >
> >
> > Yes, just add "BuildRequires: kde4-filesystem".
> >
>
> Thank you all for the solution. I notice I lack access to commit changes
> on  f21-backgrounds so proven packagers are welcome to do so. Thanks
> --
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failure on fedora default backgrounds

2024-02-03 Thread Luya Tshimbalanga 


On 2024-02-03 01:27, Dan Horák wrote:

On Fri, 2 Feb 2024 23:55:43 -0800
l...@fedoraproject.org  wrote:



On 2024-02-01 11:26 p.m., Neal Gompa  wrote:

On Fri, Feb 2, 2024 at 2:04 AM Mamoru TASAKA  wrote:

Luya Tshimbalanga wrote on 2024/02/02 10:25:

Hello team,

It appears a change within %{_kde4_datadir} macro caused failures on Rawhide 
affecting default Fedora backgrounds starting from 21.
Could someone from KDE SIG address that issue? Thanks.


Here is an extract of failure[1]  on for f35-backgrounds built on Rawhide:



RPM build errors:
error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
   File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
Child return code was: 1
'''

Reference:
[1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075


I am not KDE sig member, but the above failure is most likely due to
the following change:

https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32

/usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro 
definition)
was moved from kde-filesystem.rpm to kde4-filesystem.rpm .


Yes, just add "BuildRequires: kde4-filesystem".


Thank you all for the solution. I notice I lack access to commit changes on  
f21-backgrounds so proven packagers are welcome to do so. Thanks

update to f21-backgrounds pushed into git, no build started

Is the Requires: kde-filesystem in the "kde" subpackage still correct?



Yes, "Requires: kde-filesystem" is still correct after running a built test.

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] [Fedora Test Days] KDE Plasma 6 Test Week

2024-02-03 Thread Sumantro Mukherjee 
Hey Folks,

As many of you may know, FOSDEM is going on but still, we are hosting
the KDE test weeks.
You can still submit the results here[0]. KDE is very important for
our community members
and testing this way ahead of time helps us find bugs and eliminate them!!

Thanks for testing!


[0] https://testdays.fedoraproject.org/events/174

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

List of long term FTBFS packages to be retired in February

2024-02-03 Thread Miro Hrončok 

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 40 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 4 weeks, i.e. around 2024-02-28.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f40.

I apologize for starting this process a bit later than required again.
Unfortunately, I had other work obligations.
Volunteers to take over this are always welcome.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 37.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

Package  (co)maintainers

calendardcantrell, egoode
erlang-jose bowlofeggs, erlang-maint-sig, jcline, peter
ghdlsailer
git-secrets keesdejong
golang-github-acme-lego eclipseo, go-sig
golang-github-gatherstars-com-jwz   eclipseo, go-sig
golang-github-genuinetools-pkg  eclipseo, go-sig
golang-github-gobs-pretty   eclipseo, go-sig
golang-github-jhillyerd-enmime  eclipseo, go-sig
golang-github-pierrre-compare   eclipseo, go-sig
golang-github-smartystreets-goconvey  alexsaezm, go-sig, jchaloup
golang-gopkg-square-jose-2  alexsaezm, go-sig
golang-gvisor   eclipseo, elmarco, go-sig
golang-opentelemetry-otel-0.20  alexsaezm, go-sig
golang-sigs-k8s-kustomize   dcavalca, go-sig
golang-vitess   eclipseo, go-sig
infinipath-psm  honli
j4-dmenu-desktopibotty
jackson-dataformats-binary  mbooth
jackson-dataformats-textmbooth
java-1.8.0-openjdk-aarch32  akasko, jvanek
jreen   rdieter
libdeltacloud   clalance
mingw-clucene   greghellings
mingw-speexdsp  janisozaur
nbd-runner  xiubli
nodejs-generic-pool patches, piotrp
ofono   njha, thunderbirdtr
openni-primesense   cottsay, jkastner, rmattes
pesign-test-app javierm, nfrayer, pjones, rharwood
pthsem  ixs
rust-drgjbtrystram, rust-sig
telepathy-gabbleaperezbios

The following packages require above mentioned packages:
Depending on: erlang-jose (1)
erlang-p1_acme (maintained by: bowlofeggs, erlang-maint-sig, peter)
erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose
erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose

Depending on: golang-github-gatherstars-com-jwz (1)
aerc (maintained by: eclipseo, go-sig)
aerc-0.15.2-2.fc39.src requires 
golang(github.com/gatherstars-com/jwz)

Depending on: golang-github-genuinetools-pkg (1)
reg (maintained by: go-sig, infra-sig, mattia)
reg-0.16.1-15.fc40.src requires 
golang(github.com/genuinetools/pkg/cli)

Depending on: golang-github-gobs-pretty (2)
golang-github-vinyldns (maintained by: eclipseo, go-sig)
		golang-github-vinyldns-0.9.13-1.fc40.2.src requires 
golang(github.com/gobs/pretty)


golang-github-acme-lego (maintained by: eclipseo, go-sig)
		golang-github-acme-lego-4.4.0-8.fc37.src requires 
golang(github.com/vinyldns/go-vinyldns/vinyldns)
		golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires 
golang(github.com/vinyldns/go-vinyldns/vinyldns)


Depending on: golang-github-jhillyerd-enmime (2)
golang-github-gatherstars-com-jwz (maintained by: eclipseo, go-sig)
		golang-github-gatherstars-com-jwz-1.3.0-1.fc37.src requires 
golang(github.com/jhillyerd/enmime)


aerc (maintained by: eclipseo, go-sig)
aerc-0.15.2-2.fc39.src requires 
golang(github.com/gatherstars-com/jwz)

Depending on: golang-github-pierrre-compare (1)
golang-github-pierrre-geohash (maintained by: eclipseo, go-sig)
		golang-github-pierrre-geohash-1.0.0-9.fc40.src requires 
golang(github.com/pierrre/compare)


Depending on: golang-github-smartystreets-goconvey (23)
golang-github-afex-hystrix (maintained by: alexsaezm, go-sig)
		golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires 
golang(github.com/smartystreets/goconvey/convey)


go

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Adam Williamson 

On 2024-02-03 06:16, Marc Deop i Argemí wrote:

- As the packages stand right now, the KDE general updates will have to wait
for the proposed packages to be updated by their maintainers or we will have
to do the updates ourselves (which defeats completely the point of our change
proposal).


Why? This is the part I don't understand. Can you explain it in more 
detail? Thanks.

--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Steven A. Falco 

On 2/3/24 01:12 AM, Kevin Kofler via devel wrote:

Any interested people can already request comaintainership now (e.g., by
replying to this mail), and I will almost certainly grant it (though I will
have reservations about some specific types of requests, such as blanket
admin permissions for the entire @kde-sig group), but of course contingent
on the packages being approved (i.e., the FESCo hold on them being lifted,
and the reviews subsequently passing), because there is nothing to
comaintain before that point and also nowhere I can fill in those
comaintainership requests before the dist-git Pagure repository is created.


I am interested, FAS: stevenfalco
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Marc Deop i Argemí 
On Friday, 2 February 2024 20:56:22 CET Gary Buhrmaster wrote:
> regarding tracking (and taking) bugs, and
> lack of timely updates, for something as
> visible as the entire desktop.

Here you are highlighting some of my (I speak for me, not the KDE SIG) main 
concerns:

- If a user decided to install the X11 package and has an issue: who do you 
think they are going to reach? who is gonna get the "bad publicity" for the 
issue? ( specially when we are forced to tell them we don't support X11...)

- As the packages stand right now, the KDE general updates will have to wait 
for the proposed packages to be updated by their maintainers or we will have 
to do the updates ourselves (which defeats completely the point of our change 
proposal).

Best regards,

Marc

--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Steve Cossette 

On 2024-02-03 9:01 a.m., Björn Persson wrote:

Neal Gompa wrote:

It's extremely obvious that people want to use it.

It's extremely obvious that *some* people want to use Wayland. It's
equally obvious that some other people want to use X. It's also obvious
that certain people want to make *everybody else* use Wayland. On the
other hand I'm not seeing anyone trying to make everybody use X.

Honestly this looks a lot like the usual human desire to force deviants
into the mainstream mold.
In the grand scheme of things, most people are in no way involved in the 
implementation/development of the software we build. So in this case, 
you're right; but at the same time the same remains true for all other 
changes in all other distros: We strive to make it as painless as 
possible for the end user, while doing as much as we can to foster 
development and improvements of new technologies. For me, at least, that 
is one of the major reasons I use Fedora, I love to see what is to come.



Neither of you are aligning with the Fedora Foundation of Friends,

Building artificial obstacles to make it difficult for other people to
use what works best for them is not friendly. I'm seeing people trying
to make it difficult to use X by relegating it to Copr. I have not seen
anyone try to relegate Wayland to Copr. So who's actually being
unfriendly here?

The users will come when Wayland provides a better user experience than
X. For *their* usecases, not only for yours.

Björn Persson


Isn't that pretty much what we potentially risk doing every time we 
submit a change proposal, though? What about when GNOME decides to go 
towards a similar path and put out the xorg libraries from the project? 
Would fedora allow those libraries back through an external package like 
this?



There's also a secondary thing that I feel hasn't been discussed here 
though: I know work is being done right now to isolate the x11 
components of plasma and add build-time options to strip out those 
components. What happens when we (as-in, the KDE sig) split off those 
components and now you got 10-15+ x11 packages people gotta install to 
make it all work?



Things will just be an absolute mess



--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Björn Persson 
Neal Gompa wrote:
> It's extremely obvious that people want to use it.

It's extremely obvious that *some* people want to use Wayland. It's
equally obvious that some other people want to use X. It's also obvious
that certain people want to make *everybody else* use Wayland. On the
other hand I'm not seeing anyone trying to make everybody use X.

Honestly this looks a lot like the usual human desire to force deviants
into the mainstream mold.

> Neither of you are aligning with the Fedora Foundation of Friends,

Building artificial obstacles to make it difficult for other people to
use what works best for them is not friendly. I'm seeing people trying
to make it difficult to use X by relegating it to Copr. I have not seen
anyone try to relegate Wayland to Copr. So who's actually being
unfriendly here?

The users will come when Wayland provides a better user experience than
X. For *their* usecases, not only for yours.

Björn Persson


pgpK3GbmW35Af.pgp
Description: OpenPGP digital signatur
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Figure out what killed an app (rhbz#2253099)

2024-02-03 Thread Ondrej Mosnáček 
On Fri, 2 Feb 2024 at 17:52, Yanko Kaneti  wrote:
>
> On Thu, 2024-02-01 at 09:44 +0100, Ondrej Mosnáček wrote:
> > On Thu, 1 Feb 2024 at 09:13, Milan Crha  wrote:
> > > The kernel tracing log for sig==9 shows:
> > >
> > > gnome-terminal--2924[002] dN.2.  2520.462889: signal_generate:
> > > sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0
> > >
> > > There is no such thing (apart of the tracing log) when Evolution is
> > > suddenly killed, the logs are muted. That makes me believe it's not the
> > > OOM killer whom kills the application. I'm back at square 1; or maybe
> > > square 2, as I know possibly kernel sends it, but not why.
> >
> > Try running `echo stacktrace >/sys/kernel/tracing/trace_options` (as
> > root) and then collect the kernel trace again. That should give you a
> > backtrace of kernel functions from the signal generation, which could
> > help you/us to figure out the reason the process was killed.
>
> So, figured the easiest way to help trigger the kill here is to put load
> on the machine.
>
>  $ stress-ng --cpu -1 --cpu-method all -t 5m --cpu-load 95
>
> then starting evolution seems to do it almost every time shortly after
> start (I have around 200k messages in the folder its trying to display)
>
> I've enabled the stacktrace tracing option and like Milan set a sig==9
> filter. And here is what I got in the trace buffer after it was killed
>
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 34/34   #P:16
> #
> #_-=> irqs-off/BH-disabled
> #   / _=> need-resched
> #  | / _---=> hardirq/softirq
> #  || / _--=> preempt-depth
> #  ||| / _-=> migrate-disable
> #   / delay
> #   TASK-PID CPU#  |  TIMESTAMP  FUNCTION
> #  | | |   | | |
>evolution-9096[002] d..1.  1207.016489: signal_generate: sig=9 
> errno=0 code=128 comm=evolution pid=9096 grp=1 res=0
>evolution-9096[002] d..1.  1207.016495: 
>  => trace_event_raw_event_signal_generate
>  => __send_signal_locked
>  => posix_cpu_timers_work
>  => task_work_run
>  => irqentry_exit_to_user_mode
>  => asm_sysvec_apic_timer_interrupt

So, browsing through the relevant kernel code, it seems the only cases
which could have led to this backtrace are:
1. When a task's RT timeout goes over the RLIMIT_RTTIME hard limit
(see function check_thread_timers() in
kernel/time/posix-cpu-timers.c).
2. When a task's CPU time goes over the RLIMIT_CPU hard limit (see
function check_process_timers() in kernel/time/posix-cpu-timers.c).

I may have missed some code path, but these resource limits should be
the next thing to check.

>evolution-9096[002] d..2.  1207.016564: signal_generate: sig=9 
> errno=0 code=0 comm=bwrap pid=9145 grp=1 res=0
>evolution-9096[002] d..2.  1207.016568: 
>  => trace_event_raw_event_signal_generate
>  => __send_signal_locked
>  => do_send_sig_info
>  => do_exit
>  => do_group_exit
>  => get_signal
>  => arch_do_signal_or_restart
>  => irqentry_exit_to_user_mode
>  => asm_sysvec_apic_timer_interrupt
> ...
> and 32 other events of bwrap cleaning up.
>
> Does that shed any light? Other that is seems to be sending the signal
> to itself.
>
> -Yanko
> --
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

2024-02-03 Thread Neal Gompa 
On Fri, Feb 2, 2024 at 1:05 PM Sérgio Basto  wrote:
>
> On Fri, 2024-02-02 at 01:34 -0600, Jonathan Bennett via devel wrote:
> > Hey folks, outside observer, and long-time Fedora user weighing in
> > with
> > some thoughts. First off, I've been hyped to see Fedora lead the way
> > with finally making a real move to Wayland, and retire X11. And now
> > I'm
> > fairly disappointed to hear that there's a real chance that move will
> > get killed. And especially that it's not because of a technical
> > problem
> > or blocker bug.
>
> I don't understand , why you want the others use a crap of software,
> fully buggy, without many features , which is not supported by many
> (like nvidia) , because is new ?
>
> Who wants use Wayland and test it, may use wayland and test it, it is
> even the default .
>
> It is really difficult to me understand your point of view , users
> should be free to use what they want and have choices, It is really
> weird (for me) that you want that I use wayland and test wayland .
>

All of us in the KDE SIG daily drive Plasma Wayland, and have done so
for quite a while. I (as well as most of the members) have since 2020,
with the two members using NVIDIA beginning daily driving it in 2022
with the 515 driver release. I would not be pushing "crap" or "fully
buggy" software "without many features" that is "not supported by many
(like nvidia)". We literally waited until NVIDIA started properly
supporting it, and spent a lot of time with upstream to improve the
experience. With regards to NVIDIA, this cycle provides a lot of light
at the end of the tunnel because the proprietary driver is optional
for the newest generation of GPUs and eventually will be optional for
the last six years of NVIDIA GPUs. Yes, it's not everything, but it's
a lot and that's a big deal. The SIG has worked methodically and
patiently toward this, in conjunction with upstream (the Fedora way),
for three years.

We're also gathering empirical data through our test week, and the
results have been largely positive:
https://testdays.fedoraproject.org/events/174

It's extremely obvious that people want to use it. You replied to
someone who did and denigrated their opinion. Frankly, I'm
disappointed in your response as well as the tone of you and Kevin.
Neither of you are aligning with the Fedora Foundation of Friends, and
the personal attacks were unwarranted and unwanted. What we're doing
is bold for sure, but aligns with two more of the Fedora Foundations,
First and Features. And for the first time in a long time, Fedora KDE
has generated significant buzz in the community and media.

I'm excited for the future of Fedora KDE with Plasma Wayland, as well
as what we're doing with the upstream KDE community. :)

-- 
真実はいつも一つ！/ 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package review ticket status change after approval

2024-02-03 Thread Neal Gompa 
On Sat, Feb 3, 2024, 11:04 AM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 01/02/24 22:44, Fabio Valentini ha scritto:
> > On Mon, Jan 29, 2024 at 7:47 PM Mattia Verga via devel
> >  wrote:
> > (snip)
> >
> >> That said, I'd like to make a request and maybe make all reviewers aware
> >> of a feature which was implemented some time ago. I've noticed many
> >> reviewers change the ticket status from ASSIGNED to POST when they flag
> >> the package as approved: I'd like to request to not do that.
> >>
> >> The Package Review Tracker webpages make a distinction between packages
> >> approved (fedora-review flag set to +) and packages approved AND being
> >> built in Fedora. That distinction relies on the ticket status change to
> >> POST, which is automatically set when the repository is created in
> src.fp.o.
> > Hum ... am I missing something here?
> >
> > The bot that creates the dist-git repos does *NOT*, in fact, set the
> > bug status to POST:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2260350#c5
> >
> > Fabio
>
> Well... it should:
> https://pagure.io/fedora-infra/toddlers/pull-request/158


That has never worked. Also, POST is the wrong status for that.
RELEASE_PENDING would make more sense 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package review ticket status change after approval

2024-02-03 Thread Mattia Verga via devel 
Il 01/02/24 22:44, Fabio Valentini ha scritto:
> On Mon, Jan 29, 2024 at 7:47 PM Mattia Verga via devel
>  wrote:
> (snip)
>
>> That said, I'd like to make a request and maybe make all reviewers aware
>> of a feature which was implemented some time ago. I've noticed many
>> reviewers change the ticket status from ASSIGNED to POST when they flag
>> the package as approved: I'd like to request to not do that.
>>
>> The Package Review Tracker webpages make a distinction between packages
>> approved (fedora-review flag set to +) and packages approved AND being
>> built in Fedora. That distinction relies on the ticket status change to
>> POST, which is automatically set when the repository is created in src.fp.o.
> Hum ... am I missing something here?
>
> The bot that creates the dist-git repos does *NOT*, in fact, set the
> bug status to POST:
> https://bugzilla.redhat.com/show_bug.cgi?id=2260350#c5
>
> Fabio

Well... it should: https://pagure.io/fedora-infra/toddlers/pull-request/158

Mattia

--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Failure on fedora default backgrounds

2024-02-03 Thread Dan Horák 
On Fri, 2 Feb 2024 23:55:43 -0800
l...@fedoraproject.org wrote:

> 
> 
> On 2024-02-01 11:26 p.m., Neal Gompa  wrote:
> > On Fri, Feb 2, 2024 at 2:04 AM Mamoru TASAKA  
> > wrote:
> > >
> > > Luya Tshimbalanga wrote on 2024/02/02 10:25:
> > >> Hello team,
> > >>
> > >> It appears a change within %{_kde4_datadir} macro caused failures on 
> > >> Rawhide affecting default Fedora backgrounds starting from 21.
> > >> Could someone from KDE SIG address that issue? Thanks.
> > >>
> > >>
> > >> Here is an extract of failure[1]  on for f35-backgrounds built on 
> > >> Rawhide:
> > >>
> > >> 
> > >>
> > >> RPM build errors:
> > >> error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > >>   File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
> > >> Child return code was: 1
> > >> '''
> > >>
> > >> Reference:
> > >> [1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075
> > >>
> > >
> > > I am not KDE sig member, but the above failure is most likely due to
> > > the following change:
> > >
> > > https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32
> > >
> > > /usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro 
> > > definition)
> > > was moved from kde-filesystem.rpm to kde4-filesystem.rpm .
> > >
> > 
> > Yes, just add "BuildRequires: kde4-filesystem".
> > 
> 
> Thank you all for the solution. I notice I lack access to commit changes on  
> f21-backgrounds so proven packagers are welcome to do so. Thanks

update to f21-backgrounds pushed into git, no build started

Is the Requires: kde-filesystem in the "kde" subpackage still correct?


Dan
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue