Summary/Minutes from today's FESCo Meeting (2020-05-04)
by Fabio Valentini
=====================================
#fedora-meeting-1: FESCO (2020-05-04)
=====================================
Meeting started by decathorpe at 15:02:52 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-04/fesco.2020-...
.
Meeting summary
---------------
* Init Process (decathorpe, 15:03:09)
* #2372 F33 Self-contained Change: Network Time Security (decathorpe,
15:07:59)
* AGREED: Ask change owners to update the Change proposal to not
change the default configuration (+6, 1, -0) (decathorpe, 15:35:22)
* #2381 F33 System-Wide Change: systemd-resolved (decathorpe, 15:36:51)
* AGREED: Post feedback on the devel list and restart discussion (+7,
0, -0) (decathorpe, 15:45:16)
* Next week's chair (decathorpe, 15:45:33)
* ACTION: ignatenkobrain will chair next meeting (decathorpe,
15:46:38)
* Open Floor (decathorpe, 15:46:51)
* ACTION: decathorpe and sgallagh will respond to the devel list
concerning FESCo election questionnaire (decathorpe, 15:53:58)
* AGREED: Collect more questions on devel list, ask FPgM to curate,
and FESCo will approve questions (+5, 0, -0) (decathorpe, 16:05:05)
* ACTION: bcotton to ask for questions on the devel list (decathorpe,
16:05:18)
* ACTION: mhroncok to open fesco ticket about Security Policy
(decathorpe, 16:14:14)
Meeting ended at 16:16:06 UTC.
Action Items
------------
* ignatenkobrain will chair next meeting
* decathorpe and sgallagh will respond to the devel list concerning
FESCo election questionnaire
* bcotton to ask for questions on the devel list
* mhroncok to open fesco ticket about Security Policy
Action Items, by person
-----------------------
* bcotton
* bcotton to ask for questions on the devel list
* decathorpe
* decathorpe and sgallagh will respond to the devel list concerning
FESCo election questionnaire
* ignatenkobrain
* ignatenkobrain will chair next meeting
* mhroncok
* mhroncok to open fesco ticket about Security Policy
* sgallagh
* decathorpe and sgallagh will respond to the devel list concerning
FESCo election questionnaire
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* decathorpe (63)
* mhroncok (56)
* nirik (33)
* sgallagh (29)
* bookwar (25)
* zbyszek (21)
* zodbot (18)
* bcotton (13)
* dcantrell (8)
* ignatenkobrain (0)
* contyk (0)
4 years, 1 month
error in spec file
by Globe Trotter
Hello,
I have been trying to package franz from here:
https://github.com/meetfranz/franz/archive/v5.5.0.tar.gz
and I have the following spec file at:
UNTITLED - Pastebin Service
|
|
| |
UNTITLED - Pastebin Service
|
|
|
However, I get a bunch of warnings and errors and I am not sure how to get around this. Because it is a long list, here it is as a file:
UNTITLED - Pastebin Service
|
|
| |
UNTITLED - Pastebin Service
|
|
|
Any suggestions as to what I am doing wrong is very appreciated.
TIA!
4 years, 1 month
Orphaned maven-release
by Markku Korkeala
Hi,
I just orphaned maven-release package, I took this package last week as
my package depended on maven-release, but then I was able to build it
without the maven-release dependency (thanks Fabian!).
Best regards,
Markku Korkeala
4 years, 1 month
Re: F33 system wide change, java-11-openjdk as system jdk
by Jiri Vanek
On 5/3/20 10:56 PM, Iñaki Ucar wrote:
> Hi,
>
Hi Iñaki!
I have CCed devel(a)lists.fedoraproject.org as this issue may be shared. I have not yet written it to
https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can... as
I hope it will be rare.
Generally, no program can say, that do not support jdk11, because any javac/java application can be
*hacked* to work with java11 - see
https://jvanek.fedorapeople.org/devconf/2017/portingjavaInternalToJdk9/po...
(really all except package split over modules, which is impossible)
Now above mentione approaches are indeed *hacked*, and I discourage everybody to do so.
If you package is really bound to jdk8, you can move to the version-full requires:
BuildRequires: java-1.8.0-openjdk-devel (or java-devel <= 1:1.8.0 or similar)
...
Requires: java-1.8.0-openjdk(-headless) (or java(-headless) <= 1:1.8.0 or similar)
However there is an trap - packages you depends on. Once some of your dependencies will be compiled
with --target > 8, you are doomed, and you have to bundle it or create its compact version. By doing
so you can easily end in dependency hell.
With GWT, I'm afraid you will need to try this approach, as it is to complex framework that any
hacking on this field is really risky. And I'm sorry to hear they are not on jdk11 already, as this
fate can likely met many other packages.
Looking to spec of rstudio, and considering it have nearly no not-bundled dependence, and its
upstream being stuck on jdk8, requiring jdk8 looks like correct step for a while. If yo have any
influence in upstream, please be force GWT to move to jdk11.
Be aware, that you may end in needing to adapt also launcher, as japackage-tools will be enforcing
java-11-openjdk. You can easily do it by exporting JAVA_HOME with /usr/lib/jvm/java-1.8.0-openjdk value
Good luck,
Please let me know once you success with it. I willa dd an chapter to
https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can...
tahnx!
J.
> I'm the maintainer of RStudio, which is failing. RStudio uses a
> bundled version of Google's GWT to compile some web components, and
> upstream indicates that Java 11 is not supported [1, 2]. Maye a future
> version of RStudio brings a newer GWT that supports Java 11, but I'm
> not sure. Anyways, for the time being, we're stuck with Java 8. What
> should I do keep RStudio working on rawhide?
>
> [1] https://github.com/rstudio/rstudio/issues/6088
> [2] https://github.com/gwtproject/gwt/issues/9626
> [3] https://github.com/rstudio/rstudio/issues/6694
>
> Regards,
> Iñaki
>
> On Sun, 3 May 2020 at 21:49, <jvanek(a)redhat.com> wrote:
>>
>> Hello fellow java package maintainer iucar!
>>
>> We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk for F33. Please see https://fedoraproject.org/wiki/Changes/Java11
>>
>> Short Story:
>> * according to package database, you (co)maintain at least 1 java packages, be aware that we are bumping JDK in rawhide
>> * Ensure your package builds and runs fine with JDK11 (see the https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/)
>> * there is special tooling ready for this, before mass rebuild is launched
>> ** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild
>> * If you do not want Fedora rotten with JDK8 for ever, continue reading
>>
>> Long Story:
>> We ran a preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" instead of "25" at the bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. You can see, the result was quite dramatic:
>> 1225 total; attempted to rebuild
>> 483 failed; from those 191 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that)
>> 186 succeeded
>> 556 orphans or dead or otherwise tragic so the build did not even start
>>
>> From those you (co)own following: rstudio
>>
>> If some of your packages is missing here at all, and you think it should be included, don't hesitate to email/ping me or the mailing lists. It could happen you have some very indirect requires or you require namely java-1.8.0-openjdk(-devel). In that case yo should bump it according to packaging guidelines to java(-devel), verify you run against JDK11 in my copr. Feel free to ask me to include such an package in my copr. I will gladly do so.
>>
>>
>>
>> Your summary is:
>> 0 passed
>> 0 are missing, delete, retired or somehow else utterly missing in action (see lower)
>> 1 failed, from those 0 failed very quickly (see lower)
>>
>> Details:
>> * Passed: N/A
>> * Missing: N/A
>> is/are probably orphan. If it is intentional, you may ignore it. If it is error, you should resurrect the package and if in that, ensure it runs against JDK11 (see failed)
>> * Failed, suspiciously quickly: N/A
>> those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target lower then 1.6 JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to allow existence of compact 1.8 packages alongside main javastack. See https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. Don't forget to upstream the patch, or maybe it is enough to update to more fresh upstream release which supports JDK11? it may happen, that after the fix, your build will fail in more terrible way (see bellow)
>> * Failed: rstudio
>> those packages failed. Very often the scary error may be fixed by bump to latest upstream version. JDK 11 is out for several years. Please,
>> try to fix the package. Don't hesitate to ask on devel(a)lists.fedoraproject.org or java-devel(a)lists.fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to share your fix, it may help others.
>> We are trying to gather the most common issues at https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can... . Feel free to enhance the page, or write us your case (possibly both with solution and without) so we can add it here.
>>
>>
>> Debugging Your failures.
>> The copr repo we maintain, contains builds of java-11-openjdk as system JDK, javapackages-tools honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this copr repo in several ways.
>> * first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your build (select "all" instead of "25" at the bottom),
>> ** Click its number, select chroot (currently fedora-32-x86_64 ) and check the logs. Main log is build.log.gz.
>> * anything you push to rawhide, will automatically rebuild here in f32 chroot (we have a JDK in rawhide broken a bit currently)
>> ** It is the best approach. If you can fix your package in rawhide directly, without breaking the rawhide too much, go for it
>> ** If you need to experiment, I have a mock config for you (generated from copr-cli mock-config jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use - https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . Eg:
>>
>> sudo cp downloaded-fedora-32-x86_64.cfg /etc/mock/jvanek-java11-fedora-32-x86_64.cfg
>> or
>> cp downloaded-fedora-32-x86_64.cfg ~/.config/mock/jvanek-java11-fedora-32-x86_64.cfg
>> then
>> # change spec, bump sources, apply patches
>> fedpkg srpm
>> mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm
>>
>> Or any other packaging workflow you use, and you can use against the copr repo.
>> Thank you very much for your help, there are 500 failures, and 1000 java packagers, but only 2 active members of java sig. Without your help, the JDK bump will be very hard.
>>
>> Thank You!
>> J.
>>
>> Those should be links to build logs:
>> FAIL https://download.copr.fedorainfracloud.org/results/jvanek/java11/fedora-3...
>> MISSING: N/A
>>
>> --
>> Jiri Vanek
>> jvanek(a)redhat.com
>> +420 775 39 01 09
>>
>
>
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
4 years, 1 month
Grub, EFI, and SELinux
by Christopher
Can anybody tell me why the grub package seems to want to label files
on the EFI partition during updates?
I had thought that, by definition, EFI partitions were basically FAT,
which doesn't support the extended attributes for SELinux contexts...
So, why does the Grub package insist on attempting to label the EFI
partition, as in the following?
Upgrading : grub2-common-1:2.04-15.fc32.noarch
2/127
error: lsetfilecon: (/boot/efi/EFI/fedora,
system_u:object_r:boot_t:s0) Operation not supported
I noticed this first on F31 for the first time, awhile back, but I
figured it was harmless and would be fixed eventually. However, since
it has been happening for months on F31, and still is happening on F32
now that I've upgraded, I'm wondering if there's a good reason why
it's trying to do this.
Thanks,
Christopher
4 years, 1 month
CPE WEeekly: 2020-05-02
by Aoife Moloney
# CPE Weekly: 2020-05-02
---
title: CPE Weekly status email
tags: CPE Weekly, email
---
Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS.Check out our teams
info here https://docs.fedoraproject.org/en-US/cpe/
## GitForge Updates
* We are tracking our progress here (nothing new added yet, fyi)
https://fedoraproject.org/wiki/Git_forge_update
* We are still doing a technical deep-dive with our own team on what
we need from GitLab and will have a technical plan developed and
publically available in the coming weeks - thanks again for your
patience, this will take some time to map out.
* Fedora have also released a blog post
https://communityblog.fedoraproject.org/fedora-council-and-the-git-forge/and
* And the council are tracking the community issues in this ticket
https://pagure.io/Fedora-Council/tickets/issue/292
* We are looking at ways to engage closer with the community too so I
will have an *optional* office hours slot on #fedora-meeting @
1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can
talk about Gitforge, or not :)
## Releases!!
* F32 released! Congrats to all those who helped make this such an
awesome release :)
* Lenovo are releasing Fedora as a standard desktop offering!
* CentOS 7.8.2003 was released for x86_64, aarch64,ppc64, ppc64le and
armhfp architectures, including Cloud images (on
https://cloud.centos.org)!
### Data Centre Move
* Communishift is still out, est back online 11th May.
* Full amended schedule will be published week ending 8th May to
hackmd & will be sent to the devel & infra lists.
* Connectivity is now in place in IAD2 and should be in place in
RDU-CC over the weekend.
* In particular, a HUGE shout out to Stephen Smoogen who has been
working all the hours in every day for the last few weeks/months to
get this phase of the move operatoinal for the Fedora infrastructure -
we would not be able to do this without you Smooge :)
* This is literally a two man team of Kevin Fenzi and Stephen Smoogen,
who are carrying the weight of this infrastructure on their shoulders
and are invaluable to the success of this multi-team and multi-month
project, so thank you both.
* Given the pressures on the Infra folks, a general ask for patience
if your ticket / request / ping takes a little bit longer to reply to
### AAA Replacement
* The team will work with openSUSE to deploy FreeIPA + Noggin to
deploy it in their infra before we do!
* This is really exciting and the team are looking forward to seeing
how the solution works in another infrastructure!
* You can view the teams current, completed and backlog work here
https://github.com/orgs/fedora-infra/projects/6
### Sustaining Team
* The team are using this dashboard to track their work
https://github.com/fedora-infra/mbbox/projects/1
* Mbbox Upgrade
* Zuul CI set up is done
* Koji-hub TLS support added to CR
* Set up ReadTheDocs documentation - webhook missing for automatic build
* Identity container for testing
* Koji-builder CRD PR rebase - SSL authentication with koji-hub
* Refactor molecule test suite to share tests
## CentOS Updates
### CentOS CI
* OpenShift upgrade
* OpenStack to OpenNebula migration scripts
* Ansible playbooks to manage the creation and bootstrapping of
bare metal nodes with RHCOS
* Packaging work (fixing dependencies)
* Updated ci-user list on efforts we are putting for CI Infrastructure
### CentOS
* CentOS 7.8.2003 was released for x86_64, aarch64,ppc64, ppc64le and
armhfp architectures. Including Cloud images (on
https://cloud.centos.org) -
https://blog.centos.org/2020/04/release-centos-linux-7-2003/
### CentOS Stream
* Congratulations to Brian Stinson on his excellent session of Ask The
Expert, facilitated by Rich Bowen during Red Hat Summit - we hope you
caught it, it was really good!
* Using CentOS Stream in the CentOS QA group to prep for 8.2
As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.
Have a great week ahead!
Aoife
Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
4 years, 1 month
nettle 3.6 soname bump
by Daiki Ueno
Hello,
I'm going to build nettle in rawhide, with the following soname bumps:
- libnettle.so.7 -> libnettle.so.8
- libhogweed.so.5 -> libhogweed.so.6
I will enable bootstrapping in the package so it shouldn't break
anything, but the dependent packages are suggested to be rebuilt against
the newer libs.
Regards,
--
Daiki Ueno
4 years, 1 month
