Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

2021-08-06 Thread Sahana Prasad 
On Thu, Aug 5, 2021 at 11:51 AM Miro Hrončok  wrote:

> On 05. 08. 21 11:03, Sahana Prasad wrote:
> > Hello everyone,
> >
> > As per the F36 schedule [1], rawhide starts F36 development on
> 2021-08-10.
> > I would like to bring in OpenSSL 3.0.0 [2] and the compat package [3]
> (along
> > with devel subpackage) into rawhide.
> >
> > I would like your opinion/suggestion on:
> > 1. Merging it and building it directly in rawhide. This will make
> OpenSSL 3.0.0
> > available by default for immediate use in rawhide.
> > FTBFS bugs can be reported when there is a mass-rebuild as per [1]
> >  versus
> > 2. Building it in a side-tag, adding all packages. Allowing the packages
> to
> > port and fix build failures
> > on the side-tag and finally merge the side-tag. FTBFS bugs can be
> reported
> > immediately.
> >
> > I have a slight preference for option 1:
> >
> > 1. As rawhide enables us to try out stuff like this.
> > 2. It is very early in the cycle to bring this change.
> > 3. Many upstream packages have been ported (or are in the process of
> porting) to
> > OpenSSL 3.0.0
> > 4. Compat package (rebased to 1.1.1k version) is available with devel
> files.
> >
> > Although option 2 sounds more organized.
> >
> > But I could be missing some information/details. It would be nice to
> hear about
> > the experiences in the past and the preferred method by the community.
>
> Is it not probable that when the rebuilds happen gradually, weird stuff
> will
> happen?
>
> E.g. when:
>
> - python links to libopenssl 3
> - libdnf or similar links to openssl 1.x
>
> An application, such as dnf, uses both. Can that be a problem?
>
> 
>
> To minimize unknown problems like this, I suggest to:
>
> 1. define a minimal acceptance criteria (e.g. "dnf works")
> 2. test (1) in copr, do not open the side tag until verified there
> 3. open a side tag
> 4. build openssl 3 in it
> 5. build as much packages linking to openssl in it as possible
> 6. verify (1), improvise until it is a success
> 7. merge the side tag
> 8. rebuild "misfits" once again (packages that succeeded in (5) but
> packagers
> rebuilt them in regular rawhide while the side tag was open)
>

Thank you for these helpful steps Miro. I'll follow them.

>
> This is different from your proposed side tag solution because there is no
> window left for "allowing the packages to port and fix build failures on
> the
> side-tag". Side tags are painful when opened for a long.
>
> IMHO This combines benefits of both of your solutions:
>

>   - it is fast
>   - it is more or less atomic, sans the packages that FTBFS
>

Yes, I agree.

Thank you,
Regards,
Sahana Prasad

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

Re: Systemd unit files installed into unowned directories

2021-08-06 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Aug 06, 2021 at 01:44:25AM +0200, Björn Persson wrote:
> Petr Menšík wrote:
> > No, that is the reason why I proposed it. Guidelines already state
> > *-filesystem packages does not have to be depended on [1]. Just one,
> > probably systemd or systemd-libs, should depend on it to get it
> > installed. All other can then just ignore the directory exactly as you
> > have proposed. In this case it would not be breaking guidelines, but
> > according to them instead.
> > 
> > 1.
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership
> 
> That is contradicted by the following quote from the Packaging
> Guidelines:
> 
> | Sometimes, it may be preferable for such directories to be owned by
> | an "artificial filesystem" package, such as mozilla-filesystem. These
> | packages are designed to be explicitly required when other packages
> | store files in their directories, thus, in such situations, these
> | packages should explicitly Require the artificial filesystem package
> | and not multiply own those directories.
> 
> That is, each of those 1600 packages would need to require
> systemd-filesystem.
> 
> Perhaps the filesystem package should own these directories? Not
> systemd-filesystem, just filesystem. The case is rather similar to
> /usr/share/bash-completion, /usr/share/man, /usr/share/info and various
> other directories that filesystem owns.

I guess that'd make sense. If somebody were to propose a patch for
filesystem, I'd be all for it.

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

Fedora-Cloud-33-20210806.0 compose check report

2021-08-06 Thread Fedora compose checker 
No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20210805.0):

ID: 942385  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/942385
ID: 942393  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/942393

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: HEADS UP: OpenEXR 3.X coming soon!

2021-08-06 Thread Miro Hrončok 

On 06. 08. 21 4:17, Richard Shaw wrote:
On Thu, Aug 5, 2021 at 12:37 PM Richard Shaw > wrote:


On Thu, Aug 5, 2021 at 12:32 PM Miro Hrončok mailto:mhron...@redhat.com>> wrote:

On 05. 08. 21 19:01, Richard Shaw wrote:
 > prusa-slicer - Expects openvdb to use IlmBase::Half

That one should be fixed.


Could very well be that my notes are stale. Lots of moving parts to this
update :)


Well kinda... The patch fixes building for rawhide but it fails on f34. Doesn't 
look like the "fix" is backwards compatible...


The patch is only applied on F35+. It is not the best solution, but it is 
pragmatic.


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

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

2021-08-06 Thread Miro Hrončok 

On 06. 08. 21 7:44, Milan Crha wrote:

On Thu, 2021-08-05 at 14:20 -0400, Yaakov Selkowitz wrote:

The former owner appears to also be the upstream, so they might be
back, but at least in the meantime, do you want to take it now that
it's building again?


Hi,
I'm not sure I'm the best person, I do not follow the development of
the libpst at all, neither I've any idea about its internals. A simple
revert of the orphan would be the best choice, from my point of view,
because the orphan was kind of mistake, due to no problem with the
package itself. I do not know why it had been missed earlier. It
happens. If there's no other choice, I can take it temporarily.


The orphaning was no mistake, the maintainer was not responding to installation 
failure for many weeks.


If they wish to take the package back, they can do that.

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

Re: Systemd unit files installed into unowned directories

2021-08-06 Thread Vít Ondruch 


Dne 05. 08. 21 v 18:47 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, Aug 05, 2021 at 04:45:31PM +0200, Petr Menšík wrote:

Depends on how many maintainers should fix their package, more below.

On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Aug 04, 2021 at 10:27:10AM +0200, Petr Menšík wrote:

Hi Zbyszek,

thanks for your comment. Wouldn't it be much clearer instead of turning
bind eye on the issue creating noarch systemd-filesystem subpackage,
which would own:

%files filesystem
%dir %_unitdir
%dir %_userunitdir
%dir %_tmpfilesdir
%dir %_sysusersdir

I don't think so. This is an intrusive solution: visible to users
in package upgrade outputs, annoying to package maintainers.

Does it bother users to include new dependencies during upgrades? I
would not certainly notice when I upgrade ~500 packages every week.
Annoying to how many package maintainers? Would owning those directories
by every package using those directories would be less annoying?

Alternative would be moving these empty directories into systemd-libs,
which is installed in fedora:rawhide podman container. It seems also in
mock build environments. No public visible changes, what would you think?

[root@8fec9bc0b895 /]# rpm -qf /usr/lib/systemd/system/
file /usr/lib/systemd/system is not owned by any package


and systemd would just contain requirement on it

Requires: %{name}-filesystem

This would be 100% according to the Guidelines, every automated tools
should not raise any warning and developers would not have to pretend
they haven't seen it. Instead of silently breaching our guidelines, can
we adjust it to follow them?

Shall I try a pull request on systemd?

No, I don't think -filesystem packages are a solution we should be
recommending nowadays. If you want strict conformance to the guidelines,
insert '%dir %_unitdir' in the package: this is also a one-line solution
and doesn't require any other changes.

What I don't like about this approach, it would result in ~1600 times
single line for every package delivering some unit file. Or the same
number of rules violation. Versus single package change working for all
of them. I admit it would mean your package should be updated instead of
mine (and others). I would update it if I were in your position.

But most of those 1600 packages would need to add Requires:systemd-filesystem.
(As discussed earlier in the thread, no Requires:systemd dependency is
needed nowadays.)

N.B.: If we're going to add a line to 1600 packages, I think it's much better
to add one line in %files



Not expert on systemd or unit files, but if there is some directory 
structure, where there is basically just one file, isn't it better to 
own some of the top levels of the directory structure instead of the 
specific file? Maybe the guidelines should be updated to specify the 
package should own %_unitdir instead of the unit file.



Vít



, directly adjacent to the line for the unit file,
then one or two lines somewhere in the header part of the spec file. (I
say two, because you'd probably also want a comment explaining why that line
is added.)


Are *-filesystem packages considered deprecated?

Officially, no. But we certainly don't add as many new ones as in the
past.

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

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20210806.0 compose check report

2021-08-06 Thread Fedora compose checker 
No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20210805.0):

ID: 942401  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/942401
ID: 942409  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/942409

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

2021-08-06 Thread Felix Schwarz 


Am 05.08.21 um 14:00 schrieb Miro Hrončok:

eclipse akurtakov, dbhole, eclipse-sig,    11 weeks
     jerboaa, jjohnstn, lef, mbooth,
     oliver, rgrunber


What is the idea here? Is that a fallout of the Javapocalypse/the state of Java 
in Fedora? Will users be able to get Eclipse from Fedora for F35+?


(I'm using Eclipse + pydev a lot so I'm interested in having these packages 
available. However I can't take any more packages.)


Felix
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Systemd unit files installed into unowned directories

2021-08-06 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Aug 06, 2021 at 11:43:52AM +0200, Vít Ondruch wrote:
> 
> Dne 05. 08. 21 v 18:47 Zbigniew Jędrzejewski-Szmek napsal(a):
> >On Thu, Aug 05, 2021 at 04:45:31PM +0200, Petr Menšík wrote:
> >>Depends on how many maintainers should fix their package, more below.
> >>
> >>On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >>>On Wed, Aug 04, 2021 at 10:27:10AM +0200, Petr Menšík wrote:
> Hi Zbyszek,
> 
> thanks for your comment. Wouldn't it be much clearer instead of turning
> bind eye on the issue creating noarch systemd-filesystem subpackage,
> which would own:
> 
> %files filesystem
> %dir %_unitdir
> %dir %_userunitdir
> %dir %_tmpfilesdir
> %dir %_sysusersdir
> >>>I don't think so. This is an intrusive solution: visible to users
> >>>in package upgrade outputs, annoying to package maintainers.
> >>Does it bother users to include new dependencies during upgrades? I
> >>would not certainly notice when I upgrade ~500 packages every week.
> >>Annoying to how many package maintainers? Would owning those directories
> >>by every package using those directories would be less annoying?
> >>
> >>Alternative would be moving these empty directories into systemd-libs,
> >>which is installed in fedora:rawhide podman container. It seems also in
> >>mock build environments. No public visible changes, what would you think?
> >>
> >>[root@8fec9bc0b895 /]# rpm -qf /usr/lib/systemd/system/
> >>file /usr/lib/systemd/system is not owned by any package
> >>
> and systemd would just contain requirement on it
> 
> Requires: %{name}-filesystem
> 
> This would be 100% according to the Guidelines, every automated tools
> should not raise any warning and developers would not have to pretend
> they haven't seen it. Instead of silently breaching our guidelines, can
> we adjust it to follow them?
> 
> Shall I try a pull request on systemd?
> >>>No, I don't think -filesystem packages are a solution we should be
> >>>recommending nowadays. If you want strict conformance to the guidelines,
> >>>insert '%dir %_unitdir' in the package: this is also a one-line solution
> >>>and doesn't require any other changes.
> >>What I don't like about this approach, it would result in ~1600 times
> >>single line for every package delivering some unit file. Or the same
> >>number of rules violation. Versus single package change working for all
> >>of them. I admit it would mean your package should be updated instead of
> >>mine (and others). I would update it if I were in your position.
> >But most of those 1600 packages would need to add 
> >Requires:systemd-filesystem.
> >(As discussed earlier in the thread, no Requires:systemd dependency is
> >needed nowadays.)
> >
> >N.B.: If we're going to add a line to 1600 packages, I think it's much better
> >to add one line in %files
> 
> 
> Not expert on systemd or unit files, but if there is some directory
> structure, where there is basically just one file, isn't it better
> to own some of the top levels of the directory structure instead of
> the specific file? Maybe the guidelines should be updated to specify
> the package should own %_unitdir instead of the unit file.

The guidelines already specify that. (They say that package must either
depend on a package that owns the directory, which would generally be
systemd, though there are other packages which co-own the directory,
or own the directory itself.) We're discussing how to satisfy this without
depending on systemd. Björn's idea of adding it to filesystem I think is
the most reasonable solution.

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

Re: Systemd unit files installed into unowned directories

2021-08-06 Thread Vitaly Zaitsev via devel 

On 06/08/2021 01:44, Björn Persson wrote:

That is, each of those 1600 packages would need to require
systemd-filesystem.


Perhaps this can be done automatically on the rpmbuild side: if a unit 
file is present, add a dependency on the systemd-filesystem package, as 
has already been done with CMake.


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

Re: HEADS UP: OpenEXR 3.X coming soon!

2021-08-06 Thread Mamoru TASAKA 

Richard Shaw wrote on 2021/08/06 2:01:

Current status:



blender - seems to be failing for Python related issue


Already reported upstream:
https://developer.blender.org/T89931

Currently no active response so far.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

2021-08-06 Thread Miro Hrončok 

On 06. 08. 21 12:31, Felix Schwarz wrote:


Am 05.08.21 um 14:00 schrieb Miro Hrončok:

eclipse akurtakov, dbhole, eclipse-sig,    11 weeks
 jerboaa, jjohnstn, lef, mbooth,
 oliver, rgrunber


What is the idea here? Is that a fallout of the Javapocalypse/the state of Java 
in Fedora? Will users be able to get Eclipse from Fedora for F35+?


Yes, this is a fallout of the broken Java in Fedora.

At this point no. Eclipse is not installable on Fedora 35, hence Fedora 35 user 
will not be able to use it.


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

Re: how to update ssh public key

2021-08-06 Thread Xiao Ni 
On Fri, Aug 6, 2021 at 1:17 AM Ankur Sinha  wrote:
>
> I have multiple ssh keys, so I need to have this in my ~/.ssh/config to
> specify which should be used for Fedora services:
>
> HOST *.fedoraproject.org fedorapeople.org *.pagure.io
> IdentityFile ~/.ssh/
> User 
>
Hi Ankur

Thanks for the help. I thought it could search for the proper key automatically.
It works now.

Regards
Xiao
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: HEADS UP: OpenEXR 3.X coming soon!

2021-08-06 Thread Richard Shaw 
On Fri, Aug 6, 2021 at 3:57 AM Miro Hrončok  wrote:

> On 06. 08. 21 4:17, Richard Shaw wrote:
> > On Thu, Aug 5, 2021 at 12:37 PM Richard Shaw  > > wrote:
> >
> > On Thu, Aug 5, 2021 at 12:32 PM Miro Hrončok  > > wrote:
> >
> > On 05. 08. 21 19:01, Richard Shaw wrote:
> >  > prusa-slicer - Expects openvdb to use IlmBase::Half
> >
> > That one should be fixed.
> >
> >
> > Could very well be that my notes are stale. Lots of moving parts to
> this
> > update :)
> >
> >
> > Well kinda... The patch fixes building for rawhide but it fails on f34.
> Doesn't
> > look like the "fix" is backwards compatible...
>
> The patch is only applied on F35+. It is not the best solution, but it is
> pragmatic.
>

Well an %if 0%{?fedora} > 34 fixed that, but there's a stranger issue I
still need to investigate as I've seen this in more than one package, but
specifically on prusa-slicer...

CMake detects Imath, has include and link commands during compilation (only
links with target sla_print_tests), but Imath isn't in the Requires of the
RPMs. It doesn't need OpenEXR anymore because OpenVDB doesn't need it, so
that part of the mystery is solved.

Here's a scratch build which hasn't finished but but I assume will show the
above:
https://kojipkgs.fedoraproject.org//work/tasks/5228/73385228/build.log

Similarly in openshadinglanguage (but slightly different) it detects both
OpenEXR 3 and Imath 3, it only links with Imath[1], but then Imath doesn't
end up in the Requires[2] of the RPMs.

Thanks,
Richard

[1]
https://kojipkgs.fedoraproject.org//packages/openshadinglanguage/1.11.14.2/5.fc35/data/logs/x86_64/build.log
[2] https://koji.fedoraproject.org/koji/rpminfo?rpmID=27306586
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: how to update ssh public key

2021-08-06 Thread Xiao Ni 
On Thu, Aug 5, 2021 at 10:21 PM Kevin Fenzi  wrote:
>
> Are you entering your username there, not your email address?
> (The old account system would accept email address, but the new one does
> not).
>
> Do you have a otp enrolled? If so, you need to append your otp to the
> end of your password in the password field when logging in.
>
> Drop an email to ad...@fedoraproject.org and we can debug further.

Hi Kevin

I use my fedora account. I can login successfully. Thanks for the help.

Best regards
Xiao
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Systemd unit files installed into unowned directories

2021-08-06 Thread Vít Ondruch 


Dne 06. 08. 21 v 12:56 Zbigniew Jędrzejewski-Szmek napsal(a):

On Fri, Aug 06, 2021 at 11:43:52AM +0200, Vít Ondruch wrote:

Dne 05. 08. 21 v 18:47 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, Aug 05, 2021 at 04:45:31PM +0200, Petr Menšík wrote:

Depends on how many maintainers should fix their package, more below.

On 8/4/21 4:22 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Aug 04, 2021 at 10:27:10AM +0200, Petr Menšík wrote:

Hi Zbyszek,

thanks for your comment. Wouldn't it be much clearer instead of turning
bind eye on the issue creating noarch systemd-filesystem subpackage,
which would own:

%files filesystem
%dir %_unitdir
%dir %_userunitdir
%dir %_tmpfilesdir
%dir %_sysusersdir

I don't think so. This is an intrusive solution: visible to users
in package upgrade outputs, annoying to package maintainers.

Does it bother users to include new dependencies during upgrades? I
would not certainly notice when I upgrade ~500 packages every week.
Annoying to how many package maintainers? Would owning those directories
by every package using those directories would be less annoying?

Alternative would be moving these empty directories into systemd-libs,
which is installed in fedora:rawhide podman container. It seems also in
mock build environments. No public visible changes, what would you think?

[root@8fec9bc0b895 /]# rpm -qf /usr/lib/systemd/system/
file /usr/lib/systemd/system is not owned by any package


and systemd would just contain requirement on it

Requires: %{name}-filesystem

This would be 100% according to the Guidelines, every automated tools
should not raise any warning and developers would not have to pretend
they haven't seen it. Instead of silently breaching our guidelines, can
we adjust it to follow them?

Shall I try a pull request on systemd?

No, I don't think -filesystem packages are a solution we should be
recommending nowadays. If you want strict conformance to the guidelines,
insert '%dir %_unitdir' in the package: this is also a one-line solution
and doesn't require any other changes.

What I don't like about this approach, it would result in ~1600 times
single line for every package delivering some unit file. Or the same
number of rules violation. Versus single package change working for all
of them. I admit it would mean your package should be updated instead of
mine (and others). I would update it if I were in your position.

But most of those 1600 packages would need to add Requires:systemd-filesystem.
(As discussed earlier in the thread, no Requires:systemd dependency is
needed nowadays.)

N.B.: If we're going to add a line to 1600 packages, I think it's much better
to add one line in %files


Not expert on systemd or unit files, but if there is some directory
structure, where there is basically just one file, isn't it better
to own some of the top levels of the directory structure instead of
the specific file? Maybe the guidelines should be updated to specify
the package should own %_unitdir instead of the unit file.

The guidelines already specify that. (They say that package must either
depend on a package that owns the directory, which would generally be
systemd, though there are other packages which co-own the directory,
or own the directory itself.) We're discussing how to satisfy this without
depending on systemd. Björn's idea of adding it to filesystem I think is
the most reasonable solution.



Sorry, I think I did not explained it understandably. So there is this 
%files section [1] in the systemd guidelines where could be something like:



~~~

Do not list each individual unit file in the %files section. Instead 
list just /usr/lib/systemd (or whatever suitable macro there is) 
directory to properly own the unit files as well as the directory 
structure where they reside.


~~~


IOW if there was %{sytemd_unit_files} macro which would be listed in 
%files section and it would expand to /usr/lib/systemd, that would be 
enough. This will do its job correctly unless there are some other files 
in the directory structure, which I assume is unlikely.



This is very naive example for Postgres:


~~~

$ git diff
diff --git a/postgresql.spec b/postgresql.spec
index cc59dd4..29cf2fe 100644
--- a/postgresql.spec
+++ b/postgresql.spec
@@ -1136,7 +1136,7 @@ make -C postgresql-setup-%{setup_version} check
 %{_mandir}/man1/postmaster.*
 %{_sbindir}/postgresql-new-systemd-unit
 %{_tmpfilesdir}/postgresql.conf
-%{_unitdir}/*postgresql*.service
+/usr/lib/systemd
 %attr(700,postgres,postgres) %dir %{?_localstatedir}/lib/pgsql
 %attr(644,postgres,postgres) %config(noreplace) 
%{?_localstatedir}/lib/pgsql/.bash_profile

 %attr(700,postgres,postgres) %dir %{?_localstatedir}/lib/pgsql/backups

~~~


Vít


[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#_files_section






Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora C

Fedora rawhide compose report: 20210806.n.0 changes

2021-08-06 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20210805.n.0
NEW: Fedora-Rawhide-20210806.n.0

= SUMMARY =
Added images:4
Dropped images:  3
Added packages:  15
Dropped packages:4
Upgraded packages:   125
Downgraded packages: 0

Size of added packages:  9.31 MiB
Size of dropped packages:337.69 KiB
Size of upgraded packages:   1.93 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-Rawhide-20210806.n.0.armhfp.raw.xz
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20210806.n.0.iso
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20210806.n.0.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20210806.n.0.iso

= DROPPED IMAGES =
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20210805.n.0.iso
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20210805.n.0.ppc64le.tar.xz
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20210805.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: golang-github-adalogics-fuzz-headers-0-0.1.20210805git6c3934b.fc35
Summary: Helper functions to be used with go-fuzz
RPMs:golang-github-adalogics-fuzz-headers-devel
Size:16.12 KiB

Package: golang-github-aquarapid-vaultlib-0.5.1-1.fc35
Summary: Lightweight Go client library for reading Vault kv secrets
RPMs:golang-github-aquarapid-vaultlib-devel
Size:20.85 KiB

Package: golang-github-nozzle-throttler-1.1-1.fc35
Summary: Throttler - intelligent WaitGroups
RPMs:golang-github-nozzle-throttler-devel
Size:17.07 KiB

Package: golang-github-planetscale-pargzip-0-0.1.20210805git90c7fc0.fc35
Summary: Parallel gzip writer implementation
RPMs:golang-github-planetscale-pargzip-devel
Size:12.63 KiB

Package: golang-github-planetscale-tengo-0.10.1~ps.v6~vitess-2.fc35
Summary: Go La Tengo: a MySQL automation library
RPMs:golang-github-planetscale-tengo-devel
Size:99.59 KiB

Package: golang-github-spyzhov-ajson-0.4.2-1.fc35
Summary: Abstract JSON for Golang with JSONPath support
RPMs:golang-github-spyzhov-ajson golang-github-spyzhov-ajson-devel
Size:8.55 MiB

Package: rust-bytecheck-0.6.4-2.fc35
Summary: Derive macro for bytecheck
RPMs:rust-bytecheck+default-devel rust-bytecheck+simdutf8-devel 
rust-bytecheck+simdutf8_std-devel rust-bytecheck+std-devel 
rust-bytecheck+uuid-devel rust-bytecheck+verbose-devel rust-bytecheck-devel
Size:59.05 KiB

Package: rust-bytecheck_derive-0.6.4-1.fc35
Summary: Derive macro for bytecheck
RPMs:rust-bytecheck_derive+default-devel rust-bytecheck_derive+std-devel 
rust-bytecheck_derive-devel
Size:26.89 KiB

Package: rust-num0.3-0.3.1-1.fc35
Summary: Collection of numeric types and traits for Rust
RPMs:rust-num0.3+alloc-devel rust-num0.3+default-devel 
rust-num0.3+libm-devel rust-num0.3+num-bigint-devel rust-num0.3+rand-devel 
rust-num0.3+serde-devel rust-num0.3+std-devel rust-num0.3-devel
Size:69.34 KiB

Package: rust-ptr_meta-0.1.4-1.fc35
Summary: Radioactive stabilization of the ptr_meta rfc
RPMs:rust-ptr_meta+default-devel rust-ptr_meta+std-devel rust-ptr_meta-devel
Size:28.14 KiB

Package: rust-ptr_meta_derive-0.1.4-1.fc35
Summary: Macros for ptr_meta
RPMs:rust-ptr_meta_derive+default-devel rust-ptr_meta_derive-devel
Size:17.45 KiB

Package: rust-rend-0.3.1-2.fc35
Summary: Endian-aware primitives for Rust
RPMs:rust-rend+bytecheck-devel rust-rend+default-devel rust-rend+std-devel 
rust-rend+validation-devel rust-rend-devel
Size:45.05 KiB

Package: rust-rkyv-0.7.5-3.fc35
Summary: Zero-copy deserialization framework for Rust
RPMs:rust-rkyv+alloc-devel rust-rkyv+arbitrary_enum_discriminant-devel 
rust-rkyv+archive_be-devel rust-rkyv+archive_le-devel rust-rkyv+bytecheck-devel 
rust-rkyv+copy-devel rust-rkyv+copy_unsafe-devel rust-rkyv+default-devel 
rust-rkyv+hashbrown-devel rust-rkyv+indexmap-devel rust-rkyv+rend-devel 
rust-rkyv+size_16-devel rust-rkyv+size_32-devel rust-rkyv+size_64-devel 
rust-rkyv+std-devel rust-rkyv+strict-devel rust-rkyv+tinyvec-devel 
rust-rkyv+tinyvec_alloc-devel rust-rkyv+uuid-devel rust-rkyv+uuid_std-devel 
rust-rkyv+validation-devel rust-rkyv-devel
Size:241.45 KiB

Package: rust-rkyv_derive-0.7.5-1.fc35
Summary: Derive macro for rkyv
RPMs:rust-rkyv_derive+arbitrary_enum_discriminant-devel 
rust-rkyv_derive+archive_be-devel rust-rkyv_derive+archive_le-devel 
rust-rkyv_derive+copy-devel rust-rkyv_derive+default-devel 
rust-rkyv_derive+strict-devel rust-rkyv_derive-devel
Size:62.88 KiB

Package: rust-simdutf8-0.1.3-1.fc35
Summary: SIMD-accelerated UTF-8 validation
RPMs:rust-simdutf8+aarch64_neon-devel

Re: how to update ssh public key

2021-08-06 Thread Ankur Sinha 
On Fri, Aug 06, 2021 20:38:54 +0800, Xiao Ni wrote:
> On Fri, Aug 6, 2021 at 1:17 AM Ankur Sinha  wrote:
> >
> > I have multiple ssh keys, so I need to have this in my ~/.ssh/config to
> > specify which should be used for Fedora services:
> >
> > HOST *.fedoraproject.org fedorapeople.org *.pagure.io
> > IdentityFile ~/.ssh/
> > User 
> >
> Hi Ankur
> 
> Thanks for the help. I thought it could search for the proper key 
> automatically.
> It works now.

Ah, that's great! I think when you have multiple keys, you may need to
specify which one. I'm not too sure if it cycles through trying each
key---will have to read the man pages to confirm :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

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

2021-08-06 Thread Fedora compose checker 
No missing expected images.

Compose FAILS proposed Rawhide gating check!
1 of 43 required test results missing
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud

Failed openQA tests: 5/204 (x86_64), 8/139 (aarch64)

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

ID: 942557  Test: x86_64 Server-dvd-iso install_resize_lvm
URL: https://openqa.fedoraproject.org/tests/942557
ID: 942610  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/942610
ID: 942617  Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/942617
ID: 942823  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/942823
ID: 942834  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/942834
ID: 942848  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/942848
ID: 942869  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/942869

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

ID: 942616  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/942616
ID: 942710  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/942710
ID: 942729  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/942729
ID: 942736  Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/942736
ID: 942809  Test: x86_64 universal memtest
URL: https://openqa.fedoraproject.org/tests/942809
ID: 942867  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/942867

Soft failed openQA tests: 22/204 (x86_64), 15/139 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 942771  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/942771
ID: 942787  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/942787
ID: 942845  Test: aarch64 universal install_kickstart_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/942845
ID: 942851  Test: aarch64 universal upgrade_2_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/942851

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

ID: 942528  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/942528
ID: 942529  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/942529
ID: 942584  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/942584
ID: 942585  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/942585
ID: 942649  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/942649
ID: 942655  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/942655
ID: 942664  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/942664
ID: 942712  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/942712
ID: 942740  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/942740
ID: 942747  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/942747
ID: 942750  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/942750
ID: 942753  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/942753
ID: 942758  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/942758
ID: 942760  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/942760
ID: 942770  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/942770
ID: 942773  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/942773
ID: 942776  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/942776
ID: 942785  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/942785
ID: 942786  Test: x86_64 universal install_kickstart_user_creation
URL: https://op

Re: [fedora-java] Packages that fail to install in Fedora 35 and might be retired one week before the beta freeze

2021-08-06 Thread Sérgio 
Hey (IMO) the packages should be orphan first , to know the impact of the 
retirement , no ?

A 5 de agosto de 2021 13:00:23 WEST, "Miro Hrončok"  
escreveu:
>Hello,
>here are the packages that should be retired according to the policy one week 
>before the beta freeze, that is on 2021-08-17.
>
>If you see a pacakge that you would rather fix than retire, please assign the 
>bugzilla (move it to ASSIGNED or higher) and start working on the fix.
>
>https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
> 
>(point 9)
>
>Criterion:
>
>  - fails to install for 8+ weeks (estimated as of 2021-08-17)
>  - bugzilla in NEW
>  - at least two reminders in the bugzilla
>
>Bugzilla link:
>
>https://bugzilla.redhat.com/buglist.cgi?bug_id=1897089,1897607,1899122,1900756,1907450,1926069,1926086,1926209,1926211,1926215,1926222,1926350,1926357,1926613,1926616,1935721,1957797,1958156,1959330,1962230,1962449,1964630,1964642,1965616,1965617,1965623,1967196,1968780,1968843,1968948,1968957,1968976,1968977,1969083,1969084,1969130,1969814,1969815,1969818,1969822,1969823
>
>
>  Package  (co)maintainers  Est. BZ age
>==
>autoarchive orphan 27 weeks
>bugzilla2fedmsg orphan 10 weeks
>eclipse akurtakov, dbhole, eclipse-sig,11 weeks
> jerboaa, jjohnstn, lef, mbooth,
> oliver, rgrunber
>eclipse-m2e-coreakurtakov, eclipse-sig, galileo,   11 weeks
> mbooth, mizdebsk
>eclipse-mpc akurtakov, eclipse-sig, kdaniel,   11 weeks
> mbooth, rgrunber
>gnome-gmail orphan 14 weeks
>jboss-jsp-2.2-api   cerberus   9 weeks
>kawamoceap 9 weeks
>libprelude  fab, orphan10 weeks
>libpst  orphan 39 weeks
>maven-license-pluginorphan 11 weeks
>module-build-servicebreilly, orphan10 weeks
>msv filiperosset, mizdebsk 9 weeks
>python-aenumorphan 38 weeks
>python-aiostreamorphan 14 weeks
>python-compreffor   orphan 26 weeks
>python-databay  orphan 10 weeks
>python-diskcacheorphan 12 weeks
>python-django-post_office   orphan 10 weeks
>python-docx orphan 27 weeks
>python-flask-autoindex  orphan 10 weeks
>python-flask-silk   orphan 10 weeks
>python-furl orphan 27 weeks
>python-jsonfieldorphan 12 weeks
>python-jsonsorphan 35 weeks
>python-losant-rest  orphan 26 weeks
>python-lzo  orphan 39 weeks
>python-minibelt orphan 27 weeks
>python-mtg  orphan 27 weeks
>python-orderedmultidict orphan 27 weeks
>python-praw fale, orphan   10 weeks
>python-prawcore orphan 10 weeks
>python-schedule orphan 27 weeks
>python-siosocks orphan 10 weeks
>python-soco orphan 23 weeks
>python-stompest orphan 27 weeks
>python-testfixtures orphan 38 weeks
>python-twilio   orphan 13 weeks
>sunflow michalvala 9 weeks
>xmms-pulse  orphan 11 weeks
>xstream dchen, mizdebsk, msimacek  9 weeks
>
>The following packages require above mentioned packages:
>Depending on: eclipse (33)
>   eclipse (maintained by: akurtakov, dbhole, eclipse-sig, jerboaa, 
> jjohnstn, 
>lef, mbooth, oliver, rgrunber)
>   eclipse-1:4.19-5.fc35.src requires eclipse-ecf-core = 
> 3.14.19-2.fc34, 
>eclipse-emf-core = 1:2.25.0-1.fc35, eclipse-pde = 1:4.19-5.fc35, tycho = 
>2.2.0-4.fc34

[HEADS UP] Fedora 35 Boost 1.76 rebuilds starting in a side tag

2021-08-06 Thread Jonathan Wakely 
We are starting the rebuilds for
https://fedoraproject.org/wiki/Changes/F35Boost176 in the f35-boost
side tag.

If your package depends on Boost, or just if you see a "Rebuilt for
Boost 1.76" commit pushed to your package's dist-git repo, please
co-ordinate with me and Tom Rodgers (CC'd) about any updates to the
package. If you need to push other changes to rawhide then you will
need to build in the side tag, or we'll have to rebuild it multiple
times.

I hope we'll merge the side tag back to rawhide on Monday.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Font Awesome version 5

2021-08-06 Thread Kevin Kofler via devel 
Aleksei Bavshin wrote:
> 4 and 5 (and 6) are not backward compatible. Glyphs are missing,
> replaced, changed codepoints, etc... Not all things could be ported and
> I don't believe we'll ever get rid of 4.
> 
> 
> 
> Good thing is that _some_ of the packages with `Requires:
> fontawesome-fonts` already require v5 and work with v4 only partially.

There is also ForkAwesome, a fork of FontAwesome 4:
https://forkaweso.me/Fork-Awesome/
that some projects use.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure