Re: Fedora 33 Self-Contained Change proposal: No more automagic Python bytecompilation phase 3

[Lumir Balhar]

Hello.

The change has been accepted and implemented in: 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-922b21ffde


This means that the affected packages will FTBFS with the following error:

%_python_bytecompile_extra is discontinued, use %py_byte_compile instead.
See: 
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation_phase_3

error: Bad exit status from /var/tmp/rpm-tmp.T6T9xw (%install)

How to fix it?

1. Check a previous build of a package and answer the question: "Do you
   really need to ship byte-compiled Python modules outside the
   standard location?"
1. If the answer is no, simply remove the
   "_python_bytecompile_extra" from a specfile.
2. If the answer is yes, use %py_byte_compile macro to compile them
   manually. Docs:
   
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#manual-bytecompilation

Feel free to ask for any assistance.

Lumír

Affected packages:

bugzilla
calamares
ceph
chromium
cinnamon-screensaver
edk2
eog-plugins
fish
fleet-commander-admin
fleet-commander-client
freecad
gaupol
gdb
gedit
gedit-latex
gedit-plugins
git-cola
glusterfs
gnome-code-assistance
gnome-devel-docs
grass
gtk-doc
gtranslator
ibus-anthy
ibus
ibus-hangul
ibus-libpinyin
ibus-libzhuyin
ibus-pinyin
ibus-table
ibus-typing-booster
ibus-uniemoji
kajongg
kdevelop-python
klatexformula
libpeas
libreoffice
libsmbios
libunity
lirc
lyx
mate-menu
mingw-glib2
mirrormanager2
odcs
onboard
otf2
paraview
pcs
php-opencloud-openstack
pygobject2
pygtk2
python-cherrypy
python-flask-silk
python-genshi
python-pycurl
python-reportlab
qpid-dispatch
rhythmbox
sems
sigul
soundconverter
sugar-maze
sugar-measure
sugar
sugar-abacus
sugar-browse
sugar-calculator
sugar-memorize
sugar-castle
sugar-moon
sugar-chat
sugar-nutrition
sugar-paint
sugar-clock
sugar-colordeducto
sugar-physics
sugar-pippy
sugar-playgo
sugar-countries
sugar-portfolio
sugar-read
sugar-deducto
sugar-distance
sugar-recall
sugar-finance
sugar-record
sugar-flip
sugar-ruler
sugar-speak
sugar-srilanka
sugar-flipsticks
sugar-fototoon
sugar-fractionbounce
sugar-getiabooks
sugar-imageviewer
sugar-implode
sugar-infoslicer
sugar-starchart
sugar-stopwatch
sugar-jukebox
sugar-kuku
sugar-labyrinth
sugar-locosugar
sugar-story
sugar-terminal
sugar-log
sugar-turtleart
sugar-words
sugar-write
sugar-pukllanapac
sugar-typing-turtle
sugar-view-slides
sugar-visualmatch
sugar-xoeditor
sugar-xoirc
sugar-yupana
synfigstudio
system-config-repo
system-switch-java
system-switch-mail
texlive
totem
transmageddon
ufw-kde
variety
virt-manager
vtk
xed

On 5/28/20 9:49 PM, Ben Cotton wrote:

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

== Summary ==
See [[Changes/No_more_automagic_Python_bytecompilation]] and
[[Changes/No_more_automagic_Python_bytecompilation_phase_2]]. Now,
%global _python_bytecompile_extra 1 won't be allowed
anymore and raises an error with a link to this change.

== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbal...@redhat.com


== Detailed Description ==

See the 
[[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of the previous Change Proposal]] and the
[[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed
Description of its phase 2]].

Currently, Fedora rawhide contains ~130 packages with `%global
_python_bytecompile_extra 1` in their specfiles but surprisingly only
42 of them actually ship any .pyc files outside the standard location
/usr/lib(64)?/python[0-9]\.[0-9]+. That might be caused
by either of the following:

* there is nothing to byte-compile — the statement is a leftover to be removed

* The automagic bytecompilation uses /usr/bin/python by
default (for historical reasons) but /usr/bin/python is
not present in the buildroot by default.

Our plan is to finish the announced removal of this automagic Python
bytecompilation, remove it from packages where it's not necessary and
fix it with %py_byte_compile for packages where it's
needed.

The 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#manual-bytecompilation
documentation] already contains the following paragraph:

  If you have *.py files outside of the /usr/lib(64)?/pythonX.Y/
directories and you require those files to be byte compiled (e.g. it’s
an importable Python module) you MUST compile them explicitly using
the %py_byte_compile macro. Note that not all Python files are
importable Python modules; when in doubt, grep the sources for the
appropriate import statement.

so no changes have to be made there.

=== Affected packages ===

 From 2020-05-20.

  bugzilla
  calamares
  ceph
  chromium
  cinnamon-screensaver
  edk2
  eog-plugins
  fish
  fleet-commander-admin
  fleet-commander-client
  freecad
  gaupol
  gazebo
  gdb
  gedit
  gedit-latex
  gedit-plugins
  git-cola
  glusterfs
  gnome-code-assistance
  gnome-devel-docs
  grass
  gtk-doc
  gtranslator
  ibus
  ibus-anthy
 

Re: Update ejected from the push

[Mattia Verga via devel]

Il 16/06/20 03:47, Kevin Fenzi ha scritto:
>
> Can you file a releng ticket and we can sort out whats going on.
> https://pagure.io/releng/new_issue
>
> It seems like the sidetag setup has some issues still. ;(
>
> kevin

There have been some improvements in sidetag workflow in Bodhi master 
branch, which hopefully should resolve some of these issues when 5.3 
will be released.

Bodhi prod is still on 5.2.2. I think cverna was waiting for a bunch of 
other PRs to be included in the final version, but now with the 
datacenter move times are getting larger without the possibility to test 
in staging first.

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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 03:47 +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
> 
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
> 
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just
> plain
>    %cmake?

I forgot that it does not use %cmake, so I think we should change it
too. In that case, we should also update change page.

> 2. If a construct like this is used, I guess we will end up with a
> VPATH
>    inside %{_target_platform}? So the -debugsource package will have
> a
>    nested structure like Russian matrioshka puppets or Chinese boxes?

Example above will stop working, but we definitely do not want to have
build tree in x86_64-redhat-linux-gnu/x86_64-redhat-linux-gnu/.

> > Defaults matter. And upstreams complain about us not doing out of
> > tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
> 
> It is unfortunate that some upstreams (including parts of KDE) are
> doing 
> this. This is a very pointless and unhelpful thing to do. I see no
> benefit 
> from disallowing in-source builds, it is just a simple special case
> and 
> normally requires no extra code to support.

With this change, everyone will be more happier. Essentially we will
always do out-of-source build that is recommended by upstreams and you
won't have to think whether you need to build in-source or out-of-
source because it will just work.

> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oV0MACgkQEV1auJxc
Hh7dxg//bGpoju+h0HS+ZqVUQxnHreOZeGM+/OoGwaut3M/tbHYqoSCHHFVGuCPe
e3SwVpdeFxnAvGpa6w5KAuVYTz1bwje8wSDDAmdAF7mUQCgCofZOwVwaqTkCIAVj
UCsZP4K+khwLNSZtrlvqHzp1qvweOk33MykqepG3IrwzX+QtaMkyciAZmxqewE1P
yqpVYtHJeeu4JSg2rcBWswTC08NOPImc/uMfwqSfB9kXUuzoF55iEvWSaYYSHVRa
J2J1MIC+COaj2TODb6F5kbjjasM3sX2QC4e0P6S/R1r+1Kh5Nt8lCYhiCBR86t6S
rTbMMMch+mkOjRdphmbF6NtJBE4q0YlDQfZDB2jhXk/4/PD9wMqOJwk62oobLIv8
qFFNmI62ROzdr44fOG/MsobgKeDI9Xn/VgMsPdeXFMa3hDVvAOKSDrRuHXwUTCX9
/+G1kXhnhhO5uxHtWdHlCGJOFplixELz371lOC8sLVkxYGNpX0vtLtfdMwK6bqLB
RFyJzqBDn0UWMGw+2OIAUw7lAydMXWvLUu781PfW87MIZotM1cu/b23mC4kbMKdT
Cn1vgFLE9VlKh9olB8dCcVBB55Oxk2JbtYNlffT2lZ6U618icoG5XRgqv5WauM6Y
oMpOw0OISRjteYNPNjx2FiIW92Elt8UCs84za27KXyQSDZORvCY=
=ZOqQ
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2020-06-16 at 02:21 +0200, Kevin Kofler wrote:
> Ben Cotton wrote:
> > == Summary ==
> > %cmake macro will be adjusted (-B
> > parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the
> > older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> > 
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> > 
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org, 
> > besse...@fedoraproject.org,
> > ngomp...@gmail.com
> 
> How does this affect the many packages that already build in a
> separate 
> build folder manually? There are even several specfile templates that
> contain the boilerplate for that.

If they assume that builddir will be in `.`, they will break. And we
will fix them.

To prevent breaking, it is enough to specify `-B .` or setting
`%{_vpath_builddir}` to `.`.

> And why is it worth making a potentially incompatible change to the
> %cmake 
> macro when it can already be done with the existing one?

Not sure if I follow, what means "can already be done with the existing
one"? Does it mean that you can already specify a build dir via CLI and
some packages already do (e.g. libsolv)?
> 
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7oVDMACgkQEV1auJxc
Hh6eAA//Zcu6swqz5QBUW/Tof+UrTZrYYSVomGuqp7ramJFlDjEOT2Vi8turzz+a
WUkFp3ITGml9W324Y75+TMq9nAnoAwiuEjhnknEQ1aO+U5n9wiCRQx+t0Gtw8sHT
BsP+vu1FbXVN9NgQxmVXfKlD4yB6JAzU1XvVF8szXpHpiJEA3fstMf4wtCJkWRNa
3jHpByUsLijgYoddTO/DCdqIBOtXUhoEHfm98ZmLI4rBvF85vAA67ylcKuWjXHNw
OKtVnTOYBxP16XLEQuP4MyjeZDcBbWxJgAWfaEE4ozhV+D8zRKYAuiRVi29ANJN/
D3QxwZVjMIOyPciT7yrurApP+njMsf58MNs5jVdW2PZX2Kx2unU0ojv+01jBz5qs
hYDlKTmk+zvYrLtG30HXSSoe+WuO2pzeQPAKrCODm89fteyzOfj0ZHW7j02vB/7O
d3WIw9KpKbvBdxTVlfL4aEBxvm3WXfjW2zcXCSCmxUHCX9Hs5pDqOK5KOHpdxWj5
n3msgjAJrF8Vap2cqPwWcbX0plyrKiTHspQuD5mj9j1jG9VjPK6ynNvmrzXJMn0D
wxrkJBA3FpLtNhI7XOdlHPKWVuiwVV369NKkavgKY3ea2QzHGJsnPOaaVoXCtMNl
90pSjpLh1jTntN0VlMMXN3pJaoC+QZw7i76WQJ6wIYp0VKN9j5E=
=SoZw
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Update ejected from the push

[Alexander Ploumistos]

On Tue, Jun 16, 2020 at 4:24 AM Kevin Fenzi  wrote:
>
> On Tue, Jun 16, 2020 at 03:23:30AM +0200, Alexander Ploumistos wrote:
> > On Tue, Jun 16, 2020 at 2:43 AM Alexander Ploumistos
> >  wrote:
> > >
> > > The other update doesn't seem to be moving, but at least
> > > it hasn't been ejected (yet).
> >
> > And the second one was just cast out as well.
>
> Can you file a releng ticket and we can sort out whats going on.
> https://pagure.io/releng/new_issue

Thanks Kevin, I've opened #9532.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Mon, Jun 15, 2020 at 10:25 PM Kevin Kofler  wrote:
>
> Neal Gompa wrote:
> > If they build a separate folder manually and are already using the
> > VPATH macros, then there's no change. If they're using a different
> > structure, we can adapt them to the standard VPATH macros, and do
> > other adjustments as needed.
>
> The common idiom in KDE packages is:
> mkdir %{_target_platform}
> pushd %{_target_platform}
> %{cmake_kf5} ..
> popd
>
> So:
> 1. Are you going to apply this change also to %{cmake_kf5} or just plain
>%cmake?

Yeah, this will get applied to %cmake_kf5 as well.

> 2. If a construct like this is used, I guess we will end up with a VPATH
>inside %{_target_platform}? So the -debugsource package will have a
>nested structure like Russian matrioshka puppets or Chinese boxes?
>

%_vpath_builddir already is set to %_target_platform, so we'd just
swap one for the other.

> > Defaults matter. And upstreams complain about us not doing out of tree
> > builds by default. Some projects even intentionally break in-source
> > builds and packagers shouldn't struggle to figure out how to do the
> > right thing in that circumstance.
>
> It is unfortunate that some upstreams (including parts of KDE) are doing
> this. This is a very pointless and unhelpful thing to do. I see no benefit
> from disallowing in-source builds, it is just a simple special case and
> normally requires no extra code to support.
>

CMake themselves do not recommend doing in-source builds (and they've
already warned that this will eventually stop working). Meson doesn't
even permit it. These days, Autotools is the weird exception that
mostly mandates in-source builds.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Neal Gompa wrote:
> If they build a separate folder manually and are already using the
> VPATH macros, then there's no change. If they're using a different
> structure, we can adapt them to the standard VPATH macros, and do
> other adjustments as needed.

The common idiom in KDE packages is:
mkdir %{_target_platform}
pushd %{_target_platform}
%{cmake_kf5} ..
popd

So:
1. Are you going to apply this change also to %{cmake_kf5} or just plain
   %cmake?
2. If a construct like this is used, I guess we will end up with a VPATH
   inside %{_target_platform}? So the -debugsource package will have a
   nested structure like Russian matrioshka puppets or Chinese boxes?

> Defaults matter. And upstreams complain about us not doing out of tree
> builds by default. Some projects even intentionally break in-source
> builds and packagers shouldn't struggle to figure out how to do the
> right thing in that circumstance.

It is unfortunate that some upstreams (including parts of KDE) are doing 
this. This is a very pointless and unhelpful thing to do. I see no benefit 
from disallowing in-source builds, it is just a simple special case and 
normally requires no extra code to support.

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

Re: Update ejected from the push

[Kevin Fenzi]

On Tue, Jun 16, 2020 at 03:23:30AM +0200, Alexander Ploumistos wrote:
> On Tue, Jun 16, 2020 at 2:43 AM Alexander Ploumistos
>  wrote:
> >
> > The other update doesn't seem to be moving, but at least
> > it hasn't been ejected (yet).
> 
> And the second one was just cast out as well.

Can you file a releng ticket and we can sort out whats going on. 
https://pagure.io/releng/new_issue

It seems like the sidetag setup has some issues still. ;( 

kevin


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

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5f91ab971e   
wordpress-5.1.6-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

php-horde-horde-5.2.23-1.el6
tcpreplay-4.3.3-1.el6

Details about builds:



 php-horde-horde-5.2.23-1.el6 (FEDORA-EPEL-2020-e982b1bb7c)
 Horde Application Framework

Update Information:

**horde 5.2.23**  * [mjr] SECURITY: Fix javascript injection vulnerability in
mobile login page. * [mjr] Fix broken cloud search in portal block.

ChangeLog:

* Mon Jun 15 2020 Remi Collet  - 5.2.23-1
- update to 5.2.23




 tcpreplay-4.3.3-1.el6 (FEDORA-EPEL-2020-be517af396)
 Replay captured network traffic

Update Information:

This release contains bug fixes only (which includes security fixes):  -
Increase cache buffers size to accomodate VLAN edits (#594) - Correct L2 header
length to correct IP header offset (#583) - Fix warnings from gcc version 10
(#580) - Heap Buffer Overflow in randomize_iparp (#579) - Use after free in
get_ipv6_next (#578) - Heap Buffer Overflow in git_ipv6_next (#576) - Call
pcap_freecode() on pcap_compile() (#572) - Increase max snaplen to 262144 (#571)
- Fix divide by zero in fuzzing (#570) - Unique IP repeats at very high
iteration counts (#566) - Fails to compile on FreeBSD amd64 13.0 (#558) - Heap
Buffer Overflow in do_checksum (#556) (#577) - Attempt to correct corrupt pcap
files, if possible (#557) - Fix GCC v10 warnings (#555) - Remove some duplicated
SOURCES entries (#551) - Expand /dev/bpfX hard limit to fix macOS Mojave (#550)
- Implement --loopdelay-ms when using --loop=0 (#546) - Heap overflow
packet2tree and get_l2len (#530)

ChangeLog:

* Mon Jun 15 2020 Bojan Smojver  - 4.3.3-1
- bump up to 4.3.3
- CVE-2020-12740
* Fri Jan 31 2020 Fedora Release Engineering  - 
4.3.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Sat Jul 27 2019 Fedora Release Engineering  - 
4.3.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

References:

  [ 1 ] Bug #1678246 - CVE-2019-8377 tcpreplay: null pointer dereference in 
function get_ipv6_l4proto() in get.c [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1678246
  [ 2 ] Bug #1835343 - CVE-2020-12740 tcpreplay: Heap-based buffer over-read in 
function get_ipv6_next() at common/get.c [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1835343


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

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Kevin Fenzi]

On Mon, Jun 15, 2020 at 09:05:42PM -0400, Neal Gompa wrote:
> 
> So I'm confused here, does anyone know why the animated wallpapers
> don't work in KDE Plasma or any other desktop? I personally love
> animated wallpapers and I'd like to see this on my KDE Plasma desktop
> too...

I think KDE does support some kind of live/dynamic wallpaper, but it's
done in a completely different way from the gnome implementation. 
As far as I know there's no standard there.

Xfce has never supported live wallpapers, the code simply does not
exist. 

kevin


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

Re: Update ejected from the push

[Alexander Ploumistos]

On Tue, Jun 16, 2020 at 2:43 AM Alexander Ploumistos
 wrote:
>
> The other update doesn't seem to be moving, but at least
> it hasn't been ejected (yet).

And the second one was just cast out as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Carson Black]

That depends on the format of the animated wallpapers, which I can't
seem to figure out from this thread nor the changes page.

-- Carson Black [ jan Pontajosi ]

Am Mo., 15. Juni 2020 um 21:06 Uhr schrieb Neal Gompa :
>
> On Mon, Jun 15, 2020 at 4:11 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground
> >
> > == Summary ==
> > Fedora Workstation 33 uses animate background as default.
> >
> > == Owner ==
> > * Name: [[User:luya| Luya Tshimbalanga]]
> > * Email: luyaATfedoraproject.org
> > * Product: Workstation
> >
> >
> > == Detailed Description ==
> >
> > Starting from Release 33, Fedora Workstation uses default animated
> > background as a visual showcase. Spins and lab maintainers running on
> > desktop environment unable to support animated wallpaper will be able
> > to select a different frame from the default (and variant) background.
> >
> > == Benefit to Fedora ==
> >
> > Fedora Workstation will showcase its animated background seamlessly as 
> > default.
> >
> > Does this improve specific Spins or Editions?
> >   Design Suite Labs, which is based from Workstation, and
> > Fedora Silverblue will take advantage of its change. Other Spins and
> > Labs will remains unaffected unless their respective maintainers wish
> > to use the default animated background.
> >
> >
> > == Scope ==
> > * Proposal owners:
> > Fedora Workstation may need a slight increase of its ISO file size in
> > order to implement the animated backgrounds which are in PNG format.
> > Each frame from animation will be selectable from the Background
> > Settings.
> >
>
> So I'm confused here, does anyone know why the animated wallpapers
> don't work in KDE Plasma or any other desktop? I personally love
> animated wallpapers and I'd like to see this on my KDE Plasma desktop
> too...
>
>
>
> --
> 真実はいつも一つ！/ 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Neal Gompa]

On Mon, Jun 15, 2020 at 4:11 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground
>
> == Summary ==
> Fedora Workstation 33 uses animate background as default.
>
> == Owner ==
> * Name: [[User:luya| Luya Tshimbalanga]]
> * Email: luyaATfedoraproject.org
> * Product: Workstation
>
>
> == Detailed Description ==
>
> Starting from Release 33, Fedora Workstation uses default animated
> background as a visual showcase. Spins and lab maintainers running on
> desktop environment unable to support animated wallpaper will be able
> to select a different frame from the default (and variant) background.
>
> == Benefit to Fedora ==
>
> Fedora Workstation will showcase its animated background seamlessly as 
> default.
>
> Does this improve specific Spins or Editions?
>   Design Suite Labs, which is based from Workstation, and
> Fedora Silverblue will take advantage of its change. Other Spins and
> Labs will remains unaffected unless their respective maintainers wish
> to use the default animated background.
>
>
> == Scope ==
> * Proposal owners:
> Fedora Workstation may need a slight increase of its ISO file size in
> order to implement the animated backgrounds which are in PNG format.
> Each frame from animation will be selectable from the Background
> Settings.
>

So I'm confused here, does anyone know why the animated wallpapers
don't work in KDE Plasma or any other desktop? I personally love
animated wallpapers and I'd like to see this on my KDE Plasma desktop
too...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Neal Gompa]

On Mon, Jun 15, 2020 at 8:22 PM Kevin Kofler  wrote:
>
> Ben Cotton wrote:
> > == Summary ==
> > %cmake macro will be adjusted (-B parameter)
> > to use separate build folder (already standardized
> > %{_vpath_builddir} macro). Additionally,
> > %cmake_build, %cmake_install and
> > %ctest macro will be created (and backported to the older
> > supported Fedora releases) to perform various operations that are
> > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > etc.) way.
> >
> > Packages that will stop building are trivial to fix and will be
> > adjusted either by maintainers or change owners.
> >
> > == Owner ==
> > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > Esser]], [[User:ngompa|Neal Gompa]]
> > * Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
> > ngomp...@gmail.com
>
> How does this affect the many packages that already build in a separate
> build folder manually? There are even several specfile templates that
> contain the boilerplate for that.
>

If they build a separate folder manually and are already using the
VPATH macros, then there's no change. If they're using a different
structure, we can adapt them to the standard VPATH macros, and do
other adjustments as needed.

> And why is it worth making a potentially incompatible change to the %cmake
> macro when it can already be done with the existing one?
>

Defaults matter. And upstreams complain about us not doing out of tree
builds by default. Some projects even intentionally break in-source
builds and packagers shouldn't struggle to figure out how to do the
right thing in that circumstance.

There's also interest in making it straightforward for bigger CMake
builds to use Ninja instead of Make for performance.

Other RPM distributions have made this change with very little pain,
this just brings us in-line with the rest of the RPM distributions.



-- 
真実はいつも一つ！/ 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

Update ejected from the push

[Alexander Ploumistos]

Hello,

A few hours ago I submitted a couple of updates[0,1] that I had built
in side-tags. When I saw that after 7 hours they were still "pending"
I got in touch with infra on irc and Mohan gave them a push. I've just
received a notification that one of them was ejected from the push
because "None of ['f32-updates-testing-pending'] are in" a bunch of
other tags. The other update doesn't seem to be moving, but at least
it hasn't been ejected (yet). This looks a lot like an issue we had a
few months back[2]. Is there something I need to do?

Best regards,
A.


0. https://bodhi.fedoraproject.org/updates/FEDORA-2020-eec8591e24
1. https://bodhi.fedoraproject.org/updates/FEDORA-2020-44477df31a
2. https://pagure.io/fedora-infrastructure/issue/8477
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Kevin Kofler]

Ben Cotton wrote:
> == Summary ==
> Fedora Workstation 33 uses animate background as default.
> 
> == Owner ==
> * Name: [[User:luya| Luya Tshimbalanga]]
> * Email: luyaATfedoraproject.org
> * Product: Workstation

Is this gimmick really worth the extra space used on all deliverables?

> == Detailed Description ==
> 
> Starting from Release 33, Fedora Workstation uses default animated
> background as a visual showcase. Spins and lab maintainers running on
> desktop environment unable to support animated wallpaper will be able
> to select a different frame from the default (and variant) background.

"select a different frame"? Does that imply that you want to ship the full 
animated package on all spins, even those that do not support animated 
backgrounds, and let each spin pick its own preferred version out of the 
list (because all will be shipped anyway)? As opposed to the current state, 
where there is a distrowide default static version and the spins that do not 
use animated backgrounds require only that subpackage? That change would be 
a significant waste of space with no benefit to the user.

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Miro Hrončok]

On 15. 06. 20 21:47, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages

== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.


My general feedback:

+ I agree that removing retired and otherwise removed packages on release 
boundary upgrade is a reasonable default (with possible opt out).


- I do not think that doing this via obsoletes is the best way to achieve that 
goal. Already now, the situation is confusing to users wrt 
fedora-obsolete-packages. (However I realize that this is something that can be 
driven by a proposal like this easier than driving dnf system upgrade behavior 
changes.)


- I do not want to maintain the information in the package metadata and keep it 
up to date. Who does this? Note that releng does not follow the linked 
sop_retire_orphaned_packages.rst at all. And even if we manage to get "fedpkg 
retire" do the thing 100 % automatically, note that if a package gets removed 
from Fedora N, and is obsoleted via fedora-obsolete-packages (or 
fedora-retired-packages in case of this proposal), every time it is updated in 
Fedora N-1 and/or Fedora N-2, the obsoleted version must be updated. There is no 
automation for this and I have been doing it manually when people file bugzillas 
or complain on the mailing lists. It is an ungrateful, tedious and never ending job.


- There are retired packages ("components", "source packages") and removed 
packages ("built packages", "binary", "subpackages"). The problem is that when 
we retire a component, we need to obsolete all packages it (used to) create. 
Naturally, this is not always easy to grasp for packagers: Even the change does 
not consider the difference at all. Retirement also isn't the only way to remove 
a package (subpackages get removed as well).




Generally, I think we should instead strive to have configurable bahavior of dnf 
system-upgrade:


 option 1) broken deps block upgrades, user go figure (status quo)
 option 2) broken deps of packages not part of distupgrade repository behave 
like --allowerasing
 option 3) all packages not part of distupgrade repository are removed on 
distro boundary upgrade

 option 4) --allowerasing (already possible)

With alterations for 2/3:

 suboption a) this affects all packages
 suboption b) this affects only packages installed from "system repos"

(Suboption b) can be achieved trough a .repo file configuration option.)

Then we can have a discussion about the best default for Fedora.

Such solution obviously requires somebody to design it, code it, test it, 
support it and maintain it. I cannot speak for the software management team, but 
I guess they would have reasons not to do that (such as capacity reasons).



The solution proposed in the change OTOH requires somebody to create the 
package, create the automation, keep it up to date, explain to users how to opt 
out, explain to packagers what to do, fight broken data, keep it up to date 
after the data has been changed by a provenpackager who doesn't understand this 
(happens every once in a while with fedora-obsolete-packages), test it 
continuously, support different datasets for up to 4 different releases.


As one of the fedora-obsoelte-packages maintainers, I have capacity reasons not 
to do this.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Kevin Kofler]

Ben Cotton wrote:
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
> 
> == Owner ==
> * Name: [[User:msuchy| Miroslav Suchý]]
> * Email: msu...@redhat.com

Absolute -1!

IMHO, removing working packages from users' systems just because the new 
release no longer ships them is entirely unnecessary and a total disservice 
to users.

> == Upgrade/compatibility impact ==
> During an upgrade, all retired packages will be automatically removed.
> 
> User may opt-out by:
> 
> $ cat /etc/dnf/dnf.conf
> [main]
> ...
> exclude=fedora-retired-packages
> 

Is this actually honored by all tools, including PackageKit? (Last I 
checked, PackageKit ignored dnf.conf entirely.) The opt-out needs to work 
with PackageKit to be of any 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

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Kevin Kofler]

Ben Cotton wrote:
> == Summary ==
> %cmake macro will be adjusted (-B parameter)
> to use separate build folder (already standardized
> %{_vpath_builddir} macro). Additionally,
> %cmake_build, %cmake_install and
> %ctest macro will be created (and backported to the older
> supported Fedora releases) to perform various operations that are
> commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> etc.) way.
> 
> Packages that will stop building are trivial to fix and will be
> adjusted either by maintainers or change owners.
> 
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> Esser]], [[User:ngompa|Neal Gompa]]
> * Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
> ngomp...@gmail.com

How does this affect the many packages that already build in a separate 
build folder manually? There are even several specfile templates that 
contain the boilerplate for that.

And why is it worth making a potentially incompatible change to the %cmake 
macro when it can already be done with the existing one?

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

Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

[Miro Hrončok]

On 16. 06. 20 1:31, Miroslav Suchý wrote:

Dne 15. 06. 20 v 22:10 Ben Cotton napsal(a):

We install/keep fedora-repos-modular by default, users (admins) can
uninstall it if desired. No defaults are changed


How you manage to have it installed by default? It is not obvious from the 
linked PR to me.


I don't know yet. There are 3 possible ways I was abele to think of:

 - kickstarts
 - comps
 - compose configuration?

Originally, I was thinking I'll just add it to the same kickstart/comps as 
fedora-repos, unfortunately, I cannot see fedora-repos in either, so I will have 
to figure out trough what does the fedora-repos go in (I guess it is 
fedora-release-common).


I think we can add it to fedora-repo.ks or @core but I will yet to consult this 
with releng.



I just want to be sure it will be installed when @buildsys-build group is 
installed. Otherwise some mock builds may fail.


What kind of mock builds need Fedora modular repos? Could you elaborate? I 
thought mock uses repos defined in mock roots configuration.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is there way to include some sensitive credentials in builds?

[Kevin Kofler]

Igor Raits wrote:
> I am packaging one nice GUI application (newsflash) that is working
> with API of some services like feedly. Those require some API key, but
> I think it is against their rules to have it included in the plain-text
> format in git. I am curious if there is a way how to get those passed
> during the build. The key can be passed as an environment variable on
> the user's system, but there is no way everybody will be getting their
> own keys and I think this is non-trivial process.

Unfortunately, this whole API key concept is inherently incompatible with 
the concept of Free Software.

The only thing that you can do is to get an API key for Fedora, ship it in 
dist-git no matter what the service's TOS say, and hope they won't ban the 
key. (Most services actually don't, because they know that their rules are 
not realistically enforcible to the letter for Free Software.) If they do 
ban the key, there is not much we can do unfortunately.

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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Solomon Peachy]

On Tue, Jun 16, 2020 at 12:46:30AM +0200, Miroslav Suchý wrote:
> Can you give example?

I have a F30 system running the F29 mailgraph package, which was 
retired.  It was the last remaining blocker preventing that system from 
being upgraded to F31.  (The others were due to non-fedora-packaged 
deprecated perl stuff..)

(I have since rebuilt the package for F31, and I will be using that 
self-maintained package instead of having to come up with something to 
replace mailgraph's functionality.  Not to mention historical data..)

> > What about software installed from 3rd-party repositories?  What about 
> > packages that were downloaded and installed directly from ISVs?
> 
> Should not be affected.

So why would software supplied by fedora be treated differently than 
third-party software?  

> PlayOnLinux - this is a piece of SW I used to use. It caused an issue 
> during upgrade to F32 and it has been added to 
> fedora-obsolete-packages. Yet, when DNF told me it has to be removed, 
> I reacted "WTF, I am using it". I looked up the information and then I 
> made an informed decision.

So did you make the informed decision to not upgrade, or to remove it 
anyway?

(playonlinux was one of the many casualties of the python2 retirement
 debacle.  Not Fedora's fault..)

> libgltf - This is actually a random package with *fc29* on my 
> workstation. Hmm, one moment - yeah, dead package. I do not even know 
> what it does, why it happened to be on my computer. Hmmm, yes - 
> nothing requires it. It can be safely removed. And it is gone. Is it 

Yup; you made that decision -- because DNF couldn't have known if you 
needed it or not -- this is especially true for a leaf library.  What if 
you had some software you'd compiled from source that relied on that 
library?

By all means, let's obsolete stuff that has proper replacements (eg 
library or package renames) but auto-removing software simply because 
fedora no longer packages it is not user-friendly and leads to 
unpleaseant surprises.

And yes, I know the 'dnf system-upgrade download' output will list stuff 
it's removing, but it's all too easy to miss something in that 3000-odd 
line dump.  I consider an explicit error to be far more informative, 
although I suppose splitting apart those "retired packages causing 
conflicts" packages into a separate list on the system-upgrade output 
would IMO be a much better approach.

(Did I miss when Fedora changed their policies to auto-remove 
 applications or libraries simply because they're no longer packaged?  
 The python2->3 debacle notwithstanding...)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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

Re: Datacenter move day 2

[Kevin Kofler]

Ben Cotton wrote:
> The badge claim URL should be valid for a few days beyond the end of
> the voting period. If anyone is unable to claim the badge, they can
> open an issue at https://pagure.io/fedora-project-schedule/new_issue
> and I will manually award badges when the system is back online.

By the way, the badge description is outdated:
"I voted: Fedora 32 -- Participated in the Fedora 30 Elections!"

Is this whole badge thing really worth the effort of keeping it all running? 
Even correct descriptions seem to be too much work!

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

Re: Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

[Miroslav Suchý]

Dne 15. 06. 20 v 22:10 Ben Cotton napsal(a):
> We install/keep fedora-repos-modular by default, users (admins) can
> uninstall it if desired. No defaults are changed

How you manage to have it installed by default? It is not obvious from the 
linked PR to me.
I just want to be sure it will be installed when @buildsys-build group is 
installed. Otherwise some mock builds may fail.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Miroslav Suchý]

Dne 16. 06. 20 v 0:37 James Cassell napsal(a):
> Please not using mechanism. Make it easy to opt out, or better yet opt-in.

On package level, there is likely no other way. DNF team will have no 
time/resources to implement this on DNF level.
I can only thing of /usr/sbin/remove-retired-package which would be a wrapper 
for
  dnf remove $list $of $retired $package
Does that sounds better?

Is there some way how to get this information from PDC?

> Probably better to just advertise `yum list extras` which has existed since 
> at least Fedora 12.

Will be my mom able to write something like:
 dnf remove $(dnf list extras | awk '{print $1} | grep -v 
"package-I-still-want")
?
On my system this prints 124 package. Half of them are from 3rd party 
repositories or from command line and I want to
preserver them. So I even cannot use the command above. And it is easier to 
remove them one by one. This is painful.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Miroslav Suchý]

Dne 16. 06. 20 v 0:40 Ian McInerney napsal(a):
> and then cleaned them off manually (listing them through `rpm -qa | grep 
> fcXX` and then manually removing them), but I
> think it would be better to warn on upgrade when those packages don't exist 
> in the newer release to tell the user they
> aren't around. Then they can make the decision on what to do with them.

This is what actually `fedora-upgrade(8)` does at the end of upgrade. The 
problem is that every release, we have some
fail-to-build package in the compose and the new release contains the package 
from the previous release. But they should
not be removed. E.g., In Fedora 32 is js-html5shiv.fc31

https://src.fedoraproject.org/rpms/js-html5shiv/tree/master
https://koji.fedoraproject.org/koji/packageinfo?packageID=26061

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Miroslav Suchý]

Dne 15. 06. 20 v 22:43 Solomon Peachy napsal(a):
> This will silently break otherwise-working software on production 
> systems, and provide no straightforward way to get back to a working 
> state.

Can you give example?

> What about software installed from 3rd-party repositories?  What about 
> packages that were downloaded and installed directly from ISVs?

Should not be affected.


> This is a laudable goal, but... surely a better approach is to improve 
> the diagnostics when faced with upgrade failures?  That way the user 
> will be able to make an informed choice at the time the problem would 
> have occurred, rather than having the software (which they might be 
> reliant upon) silently disappearing.

Informed choice...?

I'll give two use-cases.

PlayOnLinux - this is a piece of SW I used to use. It caused an issue during 
upgrade to F32 and it has been added to
fedora-obsolete-packages. Yet, when DNF told me it has to be removed, I reacted 
"WTF, I am using it". I looked up the
information and then I made an informed decision.

libgltf - This is actually a random package with *fc29* on my workstation. Hmm, 
one moment - yeah, dead package. I do
not even know what it does, why it happened to be on my computer. Hmmm, yes - 
nothing requires it. It can be safely
removed. And it is gone. Is it something silently using this, when it is 
present? Does it have some security issues? I
thought that when I was doing "dnf upgrade" every week, that I have secure 
system. Do I want to spend some time on this
to make informed decision? No. Too many question, I have other things to do.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys



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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Ian McInerney]

>
> ...snip...
>
> What I propose is: As part of the retirement process we add the to
> fedora-retired-packages:
>   Obsoletes: foo < %{latestversion+1}
> And during upgrade from F37->F38 the package will be removed.
>
>
I am not a fan of this part. One release cycle seems awfully tight for
this, and it also doesn't give the user an obvious override. I have had
packages in the past hang around (I recently cleaned off some f27-era
packages from my laptop when I upgraded it to f31) and then cleaned them
off manually (listing them through `rpm -qa | grep fcXX` and then manually
removing them), but I think it would be better to warn on upgrade when
those packages don't exist in the newer release to tell the user they
aren't around. Then they can make the decision on what to do with them.
(how this is exposed in UIs, I am not sure).


> If the user wants to preserve the package (e.g., because it moved to
> Copr), he simply uninstalls and protects the installation of
> fedora-retired-packages. But that will be an informed decision.
>
> The benefits are:
>  * we do not leave unmaintained packages on a user's machine.
>  * We make sure that archaic packages do not break upgrade between two
> versions of Fedora.
>

How large a problem is this? I have had several f27-f30 packages installed
on a machine that was successfully upgraded to f31 (and several others in
between) with no issues. I am fine with saying if a package could cause
upgrade issues then we explicitly remove it (like what was done for the
python2 packages on the f31->f32 upgrade by marking them in
fedora-obsolete-packages). I would imagine that this isn't a large problem
for leaf packages at first, but could be a larger issue if a library they
required was removed.


>
> == Feedback ==
>
> After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
> discussion with fedora-obsolete-package maintainer] I filed this
> Change proposal to include a wider audience.
>
> See relevant [
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UTHLSBCLDTFOVEDVQR4XOMNKBJXSHOTF/#Z5D77LVDWWTO7HSP43MYQ7F5MKL6D6TK
> thread on devel mailing list].
>
> == Benefit to Fedora ==
>  * We do not leave unmaintained packages on a user's machine.
>  * We make sure that archaic packages do not break upgrade between two
> versions of Fedora.
>
> == Scope ==
> * Proposal owners:
>
> Create package `fedora-retired-packages` as sub-package of
> `fedora-obsolete-packages`
> [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
> Edit
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
> guidelines with:
>
> The retired package should be obsoleted by one of:
>
>  * fedora-obsoleted-packages - if the package can cause problem during
> upgrade to next version of Fedora
>  * fedora-retired-packages - in all other cases
>

Isn't this split between the two packages basically saying this change
doesn't have the second benefit that is claimed above? If packages that
would break an upgrade are added to fedora-obsolete-packages, then the only
benefit left would appear to be that no unmaintained packages are left on a
user's machine - the archaic packages that could break an upgrade can
already be fixed by adding them to fedora-obsolete-packages without this
change.


>
> It is enough to open an issue on
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages
>
> * Other developers:
> No other work should be necessary.
>
> * Release engineering:
> This is optional. I may work with rel-eng to change
>
> https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_packages.rst
> to automatically create PR for `fedora-obsolete-packages`
>
>
How would unretirement of a package marked in fedora-retired-packages work?
Would there be a similar automatic method to unretire the package and push
an update to the fedora-retired-packages package so that it can be
installed again? Would this list of retired packages be checked on every
transaction, or just on system upgrades?


> * Policies and guidelines: As stated above
>
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
> will need an update.
>
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> During an upgrade, all retired packages will be automatically removed.
>
> User may opt-out by:
> 
> $ cat /etc/dnf/dnf.conf
> [main]
> ...
> exclude=fedora-retired-packages
> 
>

This seems very drastic if the user just wanted one package to stay. This
would basically revert to the old behavior in that case.


>
> ...snip...
>

-Ian
___
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:

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[James Cassell]

On Mon, Jun 15, 2020, at 6:07 PM, Kevin Fenzi wrote:
> On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
> 
> ...snip...

Please not using mechanism. Make it easy to opt out, or better yet opt-in. 
Probably better to just advertise `yum list extras` which has existed since at 
least Fedora 12.

> 
> > If the user wants to preserve the package (e.g., because it moved to
> > Copr), he simply uninstalls and protects the installation of
> > fedora-retired-packages. But that will be an informed decision.
> 
> How is this discoverable? It's already really unclear that
> fedora-obsolete-packages should be excluded if you want to keep obsolete
> packages. :( 
> 

Agreed. We should kill the auto destruct on this package. It makes it very 
confusing why something it's being removed. Or at least make it obvious in the 
output why things are being removed.


V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Upcoming fedoraproject Datacenter move reminder and plans

[Kevin Fenzi]

On Fri, Jun 05, 2020 at 01:39:51PM +0200, Miro Hrončok wrote:
> 
> Is there a publicly available more or less up to date mirror of
> src.fedoraproject.org git repos?
> 
> I know there is https://fedoraproject.org/wiki/Infrastructure/Grokmirror
> 
> But I'd rather not set it up myself, if there is some instance I can use.

Nope. Not that I know of. If there's interest we could perhaps look at
standing one up? It would give us another copy somewhere else which is
nice.

kevin


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

Re: F30 security update submitted for stable "marked obsolete" instead of being pushed

[Kevin Fenzi]

On Wed, May 27, 2020 at 06:16:24PM +0200, Tomasz Torcz wrote:
> On Wed, May 27, 2020 at 09:39:47AM -0500, Richard Shaw wrote:
> > > Yeah, I think that'd be better then simply dropping them, if it's
> > > reasonably easy to implement. By releasing those updates we make
> > > things a bit nicer for users who are staying on a
> > > now-slightly-but-as-time-goes-on-more-and-more-so out-of-date release,
> > > and we'd be conserving the work of our packagers. But if it would be a
> > > major hassle for infra or releng, then meh.
> > >
> > 
> > I think a phased approach would be (hopefully) easy to implement.
> > 
> > 1. Stop builds at 
> > 2. Stop submitting updates on +1 week
> 
>  2½. Push to stable all updates with non-negative karma at +2 weeks?
> 
> > 3. Stop allowing pushes to stable on +2 weeks.

I don't think we need a bunch of process here. 

How about just saying that the last push will be at 14:00UTC on the last
day of life of the release and maintainers can adjust based on that... 

There's all kinds of corner cases that wouldn't be handled by a big
heavy process like above... and it would result in having to remember a
bunch of deadlines instead of just one. 

Also, I don't think its good to just push everything at the end.
In some cases, sure, it might be fine, but not others, and we really
should err on the side of caution here because we can't fix anything
after that and the release has been fine for ~18months without update X
anyhow. 

kevin


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

Re: [Regression] Blender build failure on armv7 architecture

[Kalev Lember]

On Mon, Jun 15, 2020 at 10:06 PM Andy Mender 
wrote:

> On Fri, 12 Jun 2020 at 04:58, Luya Tshimbalanga 
> wrote:
>
>> Hello team,
>>
>> Blender 2.83.0 successfuly built on all but one architecture: armv7h.
>>
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1522859
>>
>> Could these maintainers investigate the cause ? I intend to temporarly
>> exclude it until the fix is publishe.
>>
>> Thanks
>>
>> I'm not a maintainer, but I had a quick look at the build log and other
> than a lot of regular compiler warnings, it doesn't seem clear why the
> build fails. Could it be that the environment ran out of disk space? I've
> seen this happen in my COPR builds on arm.
>

I looked in the logs a bit and found the actual error:

[ 84%] Building C object
source/blender/makesdna/intern/CMakeFiles/bf_dna.dir/dna_verify.c.o
cd 
/builddir/build/BUILD/blender-2.83.0/cmake-make/source/blender/makesdna/intern
&& /usr/bin/cc -DNDEBUG -DWITH_ASSERT_ABORT -DWITH_DNA_GHASH
-DWITH_FREESTYLE -DWITH_OPENGL -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -D__LITTLE_ENDIAN__
-I/builddir/build/BUILD/blender-2.83.0/intern/atomic
-I/builddir/build/BUILD/blender-2.83.0/intern/guardedalloc
-I/builddir/build/BUILD/blender-2.83.0/source/blender/blenlib
-I/builddir/build/BUILD/blender-2.83.0/source/blender/makesdna
-I/builddir/build/BUILD/blender-2.83.0/cmake-make/source/blender/makesdna/intern
 -Wall -Wcast-align -Werror=implicit-function-declaration
-Werror=return-type -Werror=vla -Wstrict-prototypes
-Wmissing-prototypes -Wno-char-subscripts -Wno-unknown-pragmas
-Wpointer-arith -Wunused-parameter -Wwrite-strings -Wlogical-op
-Wundef -Winit-self -Wmissing-include-dirs -Wno-div-by-zero
-Wtype-limits -Wformat-signedness -Wrestrict -Wnonnull
-Wabsolute-value -Wuninitialized -Wredundant-decls -Wshadow
-Wno-error=unused-but-set-variable -Wimplicit-fallthrough=5 -O2 -g
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a
-mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux
-mfloat-abi=hard -fuse-ld=gold -fopenmp -std=gnu11 -pipe -fPIC
-funsigned-char -fno-strict-aliasing -DNDEBUG   -o
CMakeFiles/bf_dna.dir/dna_verify.c.o   -c
/builddir/build/BUILD/blender-2.83.0/cmake-make/source/blender/makesdna/intern/dna_verify.c
In file included from
/builddir/build/BUILD/blender-2.83.0/cmake-make/source/blender/makesdna/intern/dna_verify.c:2:
/builddir/build/BUILD/blender-2.83.0/source/blender/blenlib/BLI_assert.h:102:37:
error: static assertion failed: "DNA struct size verify"
  102 | #  define BLI_STATIC_ASSERT(a, msg) _Static_assert(a, msg);
  | ^~
/builddir/build/BUILD/blender-2.83.0/cmake-make/source/blender/makesdna/intern/dna_verify.c:9269:1:
note: in expansion of macro 'BLI_STATIC_ASSERT'
 9269 | BLI_STATIC_ASSERT(sizeof(struct Scene) == 6124, "DNA struct
size verify");
  | ^
make[2]: *** 
[source/blender/makesdna/intern/CMakeFiles/bf_dna.dir/build.make:148:
source/blender/makesdna/intern/CMakeFiles/bf_dna.dir/dna_verify.c.o]
Error 1


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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Kevin Fenzi]

On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages

...snip...

> If the user wants to preserve the package (e.g., because it moved to
> Copr), he simply uninstalls and protects the installation of
> fedora-retired-packages. But that will be an informed decision.

How is this discoverable? It's already really unclear that
fedora-obsolete-packages should be excluded if you want to keep obsolete
packages. :( 

kevin


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

Re: [Regression] Blender build failure on armv7 architecture

[Kevin Fenzi]

On Mon, Jun 15, 2020 at 10:05:38PM +0200, Andy Mender wrote:
> On Fri, 12 Jun 2020 at 04:58, Luya Tshimbalanga 
> wrote:
> 
> > Hello team,
> >
> > Blender 2.83.0 successfuly built on all but one architecture: armv7h.
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1522859
> >
> > Could these maintainers investigate the cause ? I intend to temporarly
> > exclude it until the fix is publishe.
> >
> > Thanks
> >
> > I'm not a maintainer, but I had a quick look at the build log and other
> than a lot of regular compiler warnings, it doesn't seem clear why the
> build fails. Could it be that the environment ran out of disk space? I've
> seen this happen in my COPR builds on arm.

Seems unlikely: 
https://kojipkgs.fedoraproject.org//work/tasks/4706/45594706/hw_info.log

Storage:
Filesystem  Size  Used Avail Use% Mounted on
/dev/vda2   135G  4.1G  124G   4% /

kevin


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

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Miro Hrončok]

On 15. 06. 20 21:56, Igor Raits wrote:

I fully agree with the benefits, however I do not like the approach.
Why not to teach DNF system-upgrade about special flag (like --remove-
unmaintained-packages) that will take installed packages, available
packages and remove those that do not exist in the target repo?


I also think this is better than the proposed change.

However, if we cannot have this yet, maybe the change is the best we could get 
now?

That said, without 100 % automation, the proposed system is not manageable 
either.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Solomon Peachy]

On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
> What I propose is: As part of the retirement process we add the to
> fedora-retired-packages:
>   Obsoletes: foo < %{latestversion+1}
> And during upgrade from F37->F38 the package will be removed.

Gah, no.  Just.. no.

This will silently break otherwise-working software on production 
systems, and provide no straightforward way to get back to a working 
state.

> If the user wants to preserve the package (e.g., because it moved to
> Copr), he simply uninstalls and protects the installation of
> fedora-retired-packages. But that will be an informed decision.

So.. the package is dropped because it's not being maintained, yet.. 
it's being maintained in copr?  How often does this really happen?

> The benefits are:
>  * we do not leave unmaintained packages on a user's machine.

What about software installed from 3rd-party repositories?  What about 
packages that were downloaded and installed directly from ISVs?

>  * We make sure that archaic packages do not break upgrade between two
> versions of Fedora.

This is a laudable goal, but... surely a better approach is to improve 
the diagnostics when faced with upgrade failures?  That way the user 
will be able to make an informed choice at the time the problem would 
have occurred, rather than having the software (which they might be 
reliant upon) silently disappearing.

I say this as someone who has run into this problem quite often over the 
years, including on the machine I'm using to write this email.  
Sometimes the correct solution is to remove the old package, but other 
times that package is in active use.


 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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

Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground
> 
> == Summary ==
> Fedora Workstation 33 uses animate background as default.
> 
> == Owner ==
> * Name: [[User:luya| Luya Tshimbalanga]]
> * Email: luyaATfedoraproject.org
> * Product: Workstation
> 
> 
> == Detailed Description ==
> 
> Starting from Release 33, Fedora Workstation uses default animated
> background as a visual showcase. Spins and lab maintainers running on
> desktop environment unable to support animated wallpaper will be able
> to select a different frame from the default (and variant)
> background.

I was actually surprised that we don't do that already!

> == Benefit to Fedora ==
> 
> Fedora Workstation will showcase its animated background seamlessly
> as default.

I am not sure if the Change Proposal is actually needed for this, but
thanks for working on it.

> Does this improve specific Spins or Editions?
>   Design Suite Labs, which is based from Workstation, and
> Fedora Silverblue will take advantage of its change. Other Spins and
> Labs will remains unaffected unless their respective maintainers wish
> to use the default animated background.
> 
> 
> == Scope ==
> * Proposal owners:
> Fedora Workstation may need a slight increase of its ISO file size in
> order to implement the animated backgrounds which are in PNG format.
> Each frame from animation will be selectable from the Background
> Settings.
> 
> * Other developers: N/A (not a System Wide Change)
> * Release engineering: Possibly a slight increase of ISO file.
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> N/A (not a System Wide Change)
> 
> == How To Test ==
> N/A (not a System Wide Change)
> 
> == User Experience ==
> Users will notice an animation of the default background related to
> the time of the day.
> 
> == Dependencies ==
> N/A (not a System Wide Change)
> 
> == Contingency Plan ==
> * Contingency mechanism: Revert to the default static background
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change)
> 
> == Documentation ==
> N/A (not a System Wide Change)
> 
> == Release Notes ==
> N/A
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to  
> devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct:  
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:  
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:  
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n2A8ACgkQEV1auJxc
Hh5RFg//Sl5dAmadTFxJipPKtYbNdXINFBwjdqO0Ww2GjrJo7STOLhbGkGTS+hVH
4phJxONNml8PW9RbNBEzMJwhR+U8Ma5ghD8bslMYanmpjCwoTAVkSlttu9AvdFNp
VZcEE3p4TNIKiygELl22EsIj2APm//cDoq7bY/Ltx9tIdJDob4G9aur7g631rzQm
p0f60HznSHQdLE/5MmBfgWPu9TAh9IzFvXxXarmmDzg3njYlurfFhNUaBh3ZrwwR
upAgjSgyL5YDqCE6PTuj1pAR/ZLlajXgdSiVKQmO5UTI4svC06iuMlBUFOIl2f11
+dhLWv4o13GWACEWnM+TD88vVYEwRGWLgbOn+wpz2GHPYBDyavtIhOZXUPHY4+lV
GivFrdzstW6U1nC4VOwin2FpX3uJGSFw9XUgiRhEWbVngco9mR9/zSSXqyS06DFH
ojvHO81FZiObZsuTkhaPKB9aNaZ9AtXWsRZ8ykYoJZNo7pL1K1y81hy0lRmGr6nE
T3jq/c8mn/w8zKYSOvO+0OcyA17fTlnxwHtQKycZH2xRcikPlkUtXuBME4W2TDFH
yNDQJj/B9+cBO6LsY6XyPQf+8NZpadTHvqhOKM1QWWhLMtMf3bwEFA1Q16ozrKKr
pfqz3WEncKAF4/9wqOAJz1YoKP4jXMag7yLM10D8He787YMF20Q=
=9nHC
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/NSSDBMRemoval
> 
> == Summary ==
> Network Security Services (NSS) historically supports 2 different
> database backends, based on SQLite and dbm. Since Fedora 28, the
> SQLite backend has been used by default and the dbm backend has been
> deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format
> SQL]]). This Change is about removing the support for the dbm backend
> entirely.
> 
> == Owner ==
> * Name: [[User:ueno| Daiki Ueno]]
> * Email: du...@redhat.com
> 
> == Detailed Description ==
> Applications that use the NSS library often use a database for
> storage
> of keys, certificates and trust. NSS supports two different storage
> formats, one is based on SQLite and another one is based on dbm
> files.
> 
> Today's default file format used by NSS, used when applications omit
> the type parameter, is the SQLite file format, and the older dbm
> format has been considered as deprecated since Fedora 28, because it
> has several drawbacks such as lack of support for parallel access to
> the storage.
> 
> As the default change was made 2 years ago, and NSS provides a
> transparent migration mechanism from the dbm format to the SQLite
> format, the suggestion is to completely disable the dbm backend.
> 
> == Benefit to Fedora ==
> There are a few benefits:
> * By disabling the dbm database, the size of the library binary will
> be slightly smaller
> * The NSS developers will be able to focus on the new file format
> 
> == Scope ==
> * Proposal owners:
> A build time environment variable (NSS_DISABLE_DBM) needs to be set.
> 
> * Other developers: N/A
> * Policies and guidelines: N/A (not a System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> The impact should be limited, as long as the users always update from
> the previous version. That would ensure the existing databases on the
> system are properly migrated. Therefore, we propose this as a Self
> Contained Change, rather than a System Wide Change.

Does it mean that people who upgrade from F31 to F33 will work just
fine?

> In the discussion on the fedora-devel list, it was pointed that
> pesign
> package embedded the dbm format database. It has now been resolved in
> [https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902].
> 
> == How To Test ==
> N/A (not a System Wide Change)
> 
> == User Experience ==
> No user visible changes.
> 
> == Dependencies ==
> N/A (not a System Wide Change)
> 
> == Contingency Plan ==
> * Contingency mechanism: Revert the shipped configuration
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? No
> 
> 
> 
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to 
> devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n12oACgkQEV1auJxc
Hh69AhAAqMcmdCbus8WJVDLeNcLl2o9jIMWGgcIzPcz0wrC70yGG46mkrlD47h/s
c3ZuzhiCWi3xZ9NHOwkWpF46DJE9ac5/4bJjxv6doJNfRCoUIgdTYQpmXoYzWXqq
mfQK8f2qD2PHaBkK+0Cq2z9TJ/7xigsPKxHPDbzwfjOV4IodTk/0RO6SxsdF6Y2V
rOeaPVp+Lf+QRMKVGwpkRidMxwKxEsYN09MJc8yj9M+LL+lqepSzqB4oG1IevOlt
3xb1FG53W5WGe7SOEz4Gej3MVRt/YnZwsiIQD8ztEH8udp9+VBEEtyfVeNkcel0A
t5Uq5sJccmWGARmua++4HC9lSPI92MbEITzePfBi8yPquXfhz7pBypKQ4922HarL
0Y4hj1D2hPCySXeFQ9sD0iccgcyew9a2Z/S//aCUIaMY2TTaqgPN2lo9MdD1MbFY
r1YD24RA/ogSc+dyK01u354hsPvg0u/hfaZwmyBlXNLWmLu2nPHywhwrKbkPDppC
G0dVqgHYSVVnFHuXmviuhWMyrUjiJJY7LDccXGrQEUoIAvU1nYw6HgWB7e/O8dwV
OS+XOJDxlzdHolNxOXI+FUaL1r7MlbsAOAkFdS5lFBHSK81yU6BGn1KNPZ9K9z/T
uFBZLsIr/T+/iT3pn+1N3DlLLXdAdw67N7MNh2mzwHWWIMv/6m4=
=nJVu
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 Self-Contained Change proposal: LXQt 0.15.0

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LXQt_0.15.0

== Summary ==

Update LXQt to 0.15.0 or later in Fedora.

== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org

== Detailed Description ==

LXQt 0.15.0 just released with a bunch of bugfixes and enhancements.
It's always good to keep Fedora users running on most recent software.

Detailed LXQt release note is available
https://lxqt.github.io/release/2020/04/24/lxqt-0-15-0/ here].

== Benefit to Fedora ==

This change brings bug fixes and enhancements to LXQt in Fedora.

== Scope ==
* Proposal owners:
1. Update all the LXQt related packages in Fedora.
2. Make lxqt-l10n noarch
3. Fix comps and/or kickstart if needed.

* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/9530 #9530]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== User Experience ==
Users shouldn't feel any difference rather than bug fixes and new features.

== Dependencies ==
The package libqtxdg is updated. Only Deepin related packages depends
on this. I am also part of the DeepinDE SIG and I've reminded our
packagers. So no risk here now.

== Contingency Plan ==
* Contingency mechanism: Not announcing the update.
* Contingency deadline: Fedora 33 Beta Freeze
* Blocks release? N/A (not a System Wide Change)

== Documentation ==



N/A (not a System Wide Change)



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

Fedora 33 Self-Contained Change proposal: Distribute .repo files for modular repositories from a separate package

[Ben Cotton]

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

== Summary ==
Reintroduce the fedora-repos-modular package. Have the
/etc/yum.repos.d/*-modular.repo files in it instead of
fedora-repos.
We install/keep fedora-repos-modular by default, users (admins) can
uninstall it if desired. No defaults are changed.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
As a Fedora user, who doesn't consume any modules, I'd like an easy
way to disable modular repos to save some traffic, disk space and
time.

Currently, I can do it by editing all
/etc/yum.repos.d/*-modular.repo files and changing:

 enabled=1

To:

 enabled=0

This has downsides: When the files are changed in next update, I won't
get them updated, because they are shipped as
%config(noreplace). (If they were not shipped as
%config(noreplace), it would be even worse, as my changes
would be overridden.) It's also multiple files. I can make mistakes
and break other files by accident.

In order to not to have to resort to manually editing RPM-package
shipped configuration, I propose to have a better way of disabling
modular repos, namely via: sudo dnf remove
fedora-repos-modular.

In this change, we move modular repos into a separate package
(subpackage of fedora-repos).

Basically revert this plus some extra comps/kickstarts changes:

https://src.fedoraproject.org/rpms/fedora-repos/c/7b32bee388d093c446017f1e33309d9b96b24e15

Current fedora-repos Pull Request:

https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62


== Feedback ==
This was proposed in early May 2020 on the devel mailing list:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QMUHN3VF5F56JOEHO4MTVST262II7XXA/

The proposal received only positive feedback.

This was then opened as a pull request in:

https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62

Where it received thorough review and positive feedback, until it was
blocked by an unrelated modularity discussion that slightly touched
this topic. FESCo sentiment was positive or neutral (however, one
FESCo member doubted the usefulness of this, saying it is pointless).

https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62#comment-45303

https://pagure.io/fesco/issue/2114#comment-654115 and below

Later, the spirit of this change was approved by FESCo in
https://pagure.io/fesco/issue/2406

== Why don't we...? ==

=== Why don't we have config overrides for system provided repo files? ===

It would be great if DNF supported system-repos in
/usr/share and override options in /etc, but
that is not (yet) the case. Feel free to work on this feature, but the
change owner won't.

=== Why don't we disable modular repos by default? ===

This would require much bigger and heated discussion. Let it happen
elsewhere. This self-contained change proposal maintains the status
quo and only creates a way for users to opt out form the modular
repos, when they so desire. It does not disable anything.

=== Why are you against ...? ===

This change is not against modularity, it is not against default
modular streams, it is not against the people who created modularity,
it is not against ELN, it is not against you. This change proposal
maintains the status quo by default and only creates a way for users
to opt out form the modular repos, when they so desire. The
maintenance burden of having one extra repo package is considered
insignificant compared to the benefit. This is not a death of a
thousands cuts proposal with a hidden agenda, this is a proposal that
adds a significant benefit.

== Benefit to Fedora ==
Users who don't consume modules have the ability to disable modular
repositories in a safe and supported way. This can save their traffic,
disk space and time.

Container maintainers can benefit form this change as well by
disabling modular repos first by a single command or not having it at
all from start, if they so desire.

Package maintainers can benefit from this change by not using modular
repos when repoquerying non-modular repos, if they so desire.

Mirror operators can benefit from this change by saving their traffic
if the users actually do disable the repos, while there is no downside
if they don't.

== Scope ==
* Proposal owners:
* Finish and merge https://pagure.io/fesco/issue/2114
* Ensure fedora-repos-modular are installed by default on Fedora 33
(fresh installs)
* Ensure fedora-repos-modular are installed by default on Fedora 33
(upgrades from previous releases)

* Other developers: no action required
* Release engineering: no action required (possibly building the
updated fedora-repos package if provenpackagers can't)
* Policies and guidelines: nada
* Trademark approval: zip


== Upgrade/compatibility impact ==
It is expected that users who upgrade from previous Fedora releases
will have fedora-repos-modular installed during the upgrade to Fedora
33 or 34.
It is expected that rawhide users who will have fe

Fedora 33 Self-Contained Change proposal: NSS dbm support removal

[Ben Cotton]

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

== Summary ==
Network Security Services (NSS) historically supports 2 different
database backends, based on SQLite and dbm. Since Fedora 28, the
SQLite backend has been used by default and the dbm backend has been
deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format
SQL]]). This Change is about removing the support for the dbm backend
entirely.

== Owner ==
* Name: [[User:ueno| Daiki Ueno]]
* Email: du...@redhat.com

== Detailed Description ==
Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different storage
formats, one is based on SQLite and another one is based on dbm files.

Today's default file format used by NSS, used when applications omit
the type parameter, is the SQLite file format, and the older dbm
format has been considered as deprecated since Fedora 28, because it
has several drawbacks such as lack of support for parallel access to
the storage.

As the default change was made 2 years ago, and NSS provides a
transparent migration mechanism from the dbm format to the SQLite
format, the suggestion is to completely disable the dbm backend.

== Benefit to Fedora ==
There are a few benefits:
* By disabling the dbm database, the size of the library binary will
be slightly smaller
* The NSS developers will be able to focus on the new file format

== Scope ==
* Proposal owners:
A build time environment variable (NSS_DISABLE_DBM) needs to be set.

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

== Upgrade/compatibility impact ==
The impact should be limited, as long as the users always update from
the previous version. That would ensure the existing databases on the
system are properly migrated. Therefore, we propose this as a Self
Contained Change, rather than a System Wide Change.

In the discussion on the fedora-devel list, it was pointed that pesign
package embedded the dbm format database. It has now been resolved in
[https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902].

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
No user visible changes.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No





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

Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation

[Ben Cotton]

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

== Summary ==
Fedora Workstation 33 uses animate background as default.

== Owner ==
* Name: [[User:luya| Luya Tshimbalanga]]
* Email: luyaATfedoraproject.org
* Product: Workstation


== Detailed Description ==

Starting from Release 33, Fedora Workstation uses default animated
background as a visual showcase. Spins and lab maintainers running on
desktop environment unable to support animated wallpaper will be able
to select a different frame from the default (and variant) background.

== Benefit to Fedora ==

Fedora Workstation will showcase its animated background seamlessly as default.

Does this improve specific Spins or Editions?
  Design Suite Labs, which is based from Workstation, and
Fedora Silverblue will take advantage of its change. Other Spins and
Labs will remains unaffected unless their respective maintainers wish
to use the default animated background.


== Scope ==
* Proposal owners:
Fedora Workstation may need a slight increase of its ISO file size in
order to implement the animated backgrounds which are in PNG format.
Each frame from animation will be selectable from the Background
Settings.

* Other developers: N/A (not a System Wide Change)
* Release engineering: Possibly a slight increase of ISO file.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==
N/A (not a System Wide Change)

== User Experience ==
Users will notice an animation of the default background related to
the time of the day.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: Revert to the default static background
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
N/A


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

Re: [Regression] Blender build failure on armv7 architecture

[Andy Mender]

On Fri, 12 Jun 2020 at 04:58, Luya Tshimbalanga 
wrote:

> Hello team,
>
> Blender 2.83.0 successfuly built on all but one architecture: armv7h.
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1522859
>
> Could these maintainers investigate the cause ? I intend to temporarly
> exclude it until the fix is publishe.
>
> Thanks
>
> I'm not a maintainer, but I had a quick look at the build log and other
than a lot of regular compiler warnings, it doesn't seem clear why the
build fails. Could it be that the environment ran out of disk space? I've
seen this happen in my COPR builds on arm.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-06-15 at 15:47 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
> 
> == Summary ==
> All retired packages are obsoleted by `fedora-retired-packages`.
> 
> == Owner ==
> * Name: [[User:msuchy| Miroslav Suchý]]
> * Email: msu...@redhat.com
> 
> == Detailed Description ==
> Right now `fedora-obsoletes-package` retires packages which cause an
> issue during an upgrade. We do nothing about all other retired
> packages. Now imagine the following story (it already happened many
> times):
> 
> We have package "foo". It is a leaf package. No one requires it. It
> uses just basic libraries.
> A user installs it during F32 lifetime.
> 
> Around F35 the upstream dies. Around F37 Fedora maintainer retires
> the
> package (or orphan and it later become retired).
> 
> Because the package is a leaf package, it causes no pain during
> upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
> then during upgrade to F43 it suddenly causes a problem. But because
> it is .fc37 everyone will hesitate to add it
> fedora-obsolete-packages.fc43.
> 
> Additionally, during F38-F43, users may expect that their system is
> fully updated and they have no security issues. But it is not true
> about package "foo", which no one maintains. And users are not aware
> of that because he does not follow fedora-devel mailing list.
> Obviously.
> 
> What I propose is: As part of the retirement process we add the to
> fedora-retired-packages:
>   Obsoletes: foo < %{latestversion+1}
> And during upgrade from F37->F38 the package will be removed.
> 
> If the user wants to preserve the package (e.g., because it moved to
> Copr), he simply uninstalls and protects the installation of
> fedora-retired-packages. But that will be an informed decision.
> 
> The benefits are:
>  * we do not leave unmaintained packages on a user's machine.
>  * We make sure that archaic packages do not break upgrade between
> two
> versions of Fedora.

I fully agree with the benefits, however I do not like the approach.
Why not to teach DNF system-upgrade about special flag (like --remove-
unmaintained-packages) that will take installed packages, available
packages and remove those that do not exist in the target repo?

> == Feedback ==
> 
> After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
> discussion with fedora-obsolete-package maintainer] I filed this
> Change proposal to include a wider audience.
> 
> See relevant [
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UTHLSBCLDTFOVEDVQR4XOMNKBJXSHOTF/#Z5D77LVDWWTO7HSP43MYQ7F5MKL6D6TK
> thread on devel mailing list].
> 
> == Benefit to Fedora ==
>  * We do not leave unmaintained packages on a user's machine.
>  * We make sure that archaic packages do not break upgrade between
> two
> versions of Fedora.
> 
> == Scope ==
> * Proposal owners:
> 
> Create package `fedora-retired-packages` as sub-package of
> `fedora-obsolete-packages`
> [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
> Edit 
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
> guidelines with:
> 
> The retired package should be obsoleted by one of:
> 
>  * fedora-obsoleted-packages - if the package can cause problem
> during
> upgrade to next version of Fedora
>  * fedora-retired-packages - in all other cases
> 
> It is enough to open an issue on
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages
> 
> * Other developers:
> No other work should be necessary.
> 
> * Release engineering:
> This is optional. I may work with rel-eng to change
> https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_packages.rst
> to automatically create PR for `fedora-obsolete-packages`
> 
> * Policies and guidelines: As stated above
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
> will need an update.
> 
> * Trademark approval: N/A (not needed for this Change)
> 
> 
> == Upgrade/compatibility impact ==
> During an upgrade, all retired packages will be automatically
> removed.
> 
> User may opt-out by:
> 
> $ cat /etc/dnf/dnf.conf
> [main]
> ...
> exclude=fedora-retired-packages
> 
> 
> 
> == How To Test ==
> 1. Upgrade to next version of Fedora.
> 2. Check all retired packages are removed.
> 
> == User Experience ==
>  - Packages that are no longer maintained are removed during a
> distribution upgrade.
> 
> == Dependencies ==
> This update has no dependencies on any other package.
> 
> == Contingency Plan ==
> * Contingency mechanism: Drop `fedora-retired-package`. Or remove
> `Obsoletes` from this sub-package.
> * Contingency deadline: Beta freeze
> * Blocks release? No
> 
> == Documentation ==
> TBD
> 
> == Release Notes ==
> TBD
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> 

Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages

== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.

== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msu...@redhat.com

== Detailed Description ==
Right now `fedora-obsoletes-package` retires packages which cause an
issue during an upgrade. We do nothing about all other retired
packages. Now imagine the following story (it already happened many
times):

We have package "foo". It is a leaf package. No one requires it. It
uses just basic libraries.
A user installs it during F32 lifetime.

Around F35 the upstream dies. Around F37 Fedora maintainer retires the
package (or orphan and it later become retired).

Because the package is a leaf package, it causes no pain during
upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
then during upgrade to F43 it suddenly causes a problem. But because
it is .fc37 everyone will hesitate to add it
fedora-obsolete-packages.fc43.

Additionally, during F38-F43, users may expect that their system is
fully updated and they have no security issues. But it is not true
about package "foo", which no one maintains. And users are not aware
of that because he does not follow fedora-devel mailing list.
Obviously.

What I propose is: As part of the retirement process we add the to
fedora-retired-packages:
  Obsoletes: foo < %{latestversion+1}
And during upgrade from F37->F38 the package will be removed.

If the user wants to preserve the package (e.g., because it moved to
Copr), he simply uninstalls and protects the installation of
fedora-retired-packages. But that will be an informed decision.

The benefits are:
 * we do not leave unmaintained packages on a user's machine.
 * We make sure that archaic packages do not break upgrade between two
versions of Fedora.

== Feedback ==

After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
discussion with fedora-obsolete-package maintainer] I filed this
Change proposal to include a wider audience.

See relevant 
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UTHLSBCLDTFOVEDVQR4XOMNKBJXSHOTF/#Z5D77LVDWWTO7HSP43MYQ7F5MKL6D6TK
thread on devel mailing list].

== Benefit to Fedora ==
 * We do not leave unmaintained packages on a user's machine.
 * We make sure that archaic packages do not break upgrade between two
versions of Fedora.

== Scope ==
* Proposal owners:

Create package `fedora-retired-packages` as sub-package of
`fedora-obsolete-packages`
[https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
Edit 
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
guidelines with:

The retired package should be obsoleted by one of:

 * fedora-obsoleted-packages - if the package can cause problem during
upgrade to next version of Fedora
 * fedora-retired-packages - in all other cases

It is enough to open an issue on
https://src.fedoraproject.org/rpms/fedora-obsolete-packages

* Other developers:
No other work should be necessary.

* Release engineering:
This is optional. I may work with rel-eng to change
https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_packages.rst
to automatically create PR for `fedora-obsolete-packages`

* Policies and guidelines: As stated above
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obsoleting_Packages
will need an update.

* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
During an upgrade, all retired packages will be automatically removed.

User may opt-out by:

$ cat /etc/dnf/dnf.conf
[main]
...
exclude=fedora-retired-packages



== How To Test ==
1. Upgrade to next version of Fedora.
2. Check all retired packages are removed.

== User Experience ==
 - Packages that are no longer maintained are removed during a
distribution upgrade.

== Dependencies ==
This update has no dependencies on any other package.

== Contingency Plan ==
* Contingency mechanism: Drop `fedora-retired-package`. Or remove
`Obsoletes` from this sub-package.
* Contingency deadline: Beta freeze
* Blocks release? No

== Documentation ==
TBD

== Release Notes ==
TBD


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

Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds

== Summary ==
%cmake macro will be adjusted (-B parameter)
to use separate build folder (already standardized
%{_vpath_builddir} macro). Additionally,
%cmake_build, %cmake_install and
%ctest macro will be created (and backported to the older
supported Fedora releases) to perform various operations that are
commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
etc.) way.

Packages that will stop building are trivial to fix and will be
adjusted either by maintainers or change owners.

== Owner ==
* Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
Esser]], [[User:ngompa|Neal Gompa]]
* Email: ignatenkobr...@fedoraproject.org, besse...@fedoraproject.org,
ngomp...@gmail.com

== Detailed Description ==
Historically, software builds had a singular build configuration and
required running the build within the project root. Nowadays, there
are many build modes and options that can be configured in projects,
different build settings (e.g. compiler flags) / types (release,
debug) that can be applied and different tools that can be used to
actually execute builds (compilers like gcc/clang, build job
schedulers like make/ninja, and so on). Thus, CMake upstream strongly
discourages users of doing in-source builds and recommends doing
out-of-source builds.

From cmake.1:


To maintain a pristine source tree, perform an out-of-source build by
using a separate dedicated build tree. An in-source build in which the
build tree is placed in the same directory as the source tree is also
supported, but discouraged.


The other part of the change is introduction of additional macros is
creation of set of macro that can build, install and run tests in a
backend-agnostic, vpath-aware (out-of-source, in-source) way.

=== Migration ===

 %cmake + %(make|ninja)_(build|install) 

There are multiple paths to complete the migration:

* Add -C "%{_vpath_builddir}" to the %(make|ninja)_*
* Replace %(make|ninja)_build and
%(make|ninja)_install with %cmake_build and
%cmake_install respectively
* Redefine vpath builddir %global _vpath_builddir . to
continue performing in-source builds (and optionally converting to the
%cmake_*)

Depending on the package, one of these options may be used to adapt to
this change.

 %cmake -B builddir +
%(make|ninja)_(build|install) -C builddir 

No changes are needed.

== Benefit to Fedora ==
* Follow CMake upstream recommendations when building packages
* Brings Fedora package builds more in-line with how upstream projects
expect them to be built
* Improve compatibility with other RPM distributions that already do this
* Support backend-agnostic way of building CMake projects

== Scope ==
* Proposal owners: Implement necessary macros, try to build packages
that BuildRequires: cmake in a side tag, analyze failures
and fix the relevant ones (introduced by this change).
* Other developers: While proposal owners will try to fix all affected
packages, there might be some cases where package is already FTBFS so
the fix can't be performed. Other package maintainers will have to fix
the issue themselves after they fix FTBFS.
* Release engineering: [https://pagure.io/releng/issue/9524 #9524]
* Policies and guidelines: CMake page will be adjusted to mention
newly created macros and the documentation about relevant VPATH macros
needs to be restructured a bit (they are already documented on the
Meson page, they need to be moved to the separate page and referenced
both from CMake and Meson page).
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Existing packages can (and most likely will) become FTBFS, but
proposal owners will fix as many Fedora packages as possible. However
fixing third-party packages is not possible and out of scope.
Third-party packagers will need to adapt based on the recommendations
noted in this Change.

== How To Test ==
# Grab the new cmake RPM from the Koji sidetag (TBC)
# Try to build package that uses %cmake,
%cmake_build, %cmake_install and
%ctest macro

== User Experience ==
The end-users (non-packagers) will not notice any changes.

== Dependencies ==
There are around 1100 RPMs in Fedora that depend on CMake at
build-time. All proposal owners are provenpackagers so they are able
to commit necessary fixes. No external dependencies.

== Contingency Plan ==
* Contingency mechanism: Proposal owners will adjust macros to not do
out-of-source builds by default, but will preserve newly created macro
(essentially to bring them to the targeted state of older supported
Fedora releases).
* Contingency deadline: Beta freeze.
* Blocks release? No

== Documentation ==
The only place that needs to be adjusted is packaging guidelines.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To u

Review Swap: python-ouimeaux - Open source control for Belkin WeMo devices

[Andrew Bauer]

Looking for someone to review the following python package: 
https://bugzilla.redhat.com/show_bug.cgi?id=1839242

It's not complicated by any means. 
I'll be glad to review another package in return. Thank you.
___
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

ocaml-bin-prot license change

[Jerry James]

I just built version 0.13.0 of ocaml-bin-prot for Rawhide and Fedora
32.  The license has changed from "LGPLv2+ with exceptions" to "MIT
and BSD".
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: swap on zram

[Chris Murphy]

Help needed!

We're discussing the parameters of the test day, and the difficulty is
answering: "what are the test cases?"

This comment and the one after it:
https://pagure.io/fedora-qa/issue/632#comment-658340

What language simply and properly conveys that the "test case" is
essentially created on-the-fly by the user, based on their expectation
of a particular workload they know stresses their system? We aren't
looking for test cases that would blow up the system whether it's
using disk-based or zram-based swap. We want to discover cases where
things work with disk-based swap, but not zram-based swap.

A generic description might be: a workload that you perform that
results in OOM 50% of the time. OK now try that workload using
swap-on-zram, does it succeed or fail more often than 50% of the time?

Thanks!

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

Re: protobuf update coming to rawhide

[Robert-André Mauchin]

On Monday, 15 June 2020 06:51:32 CEST Adrian Reber wrote:
> The following packages are failing:
> 
> clementine

I rebuild the dep which was causing issue with clementine (libqxt-qt5, 
https://koji.fedoraproject.org/koji/buildinfo?buildID=1507034), would you mind 
retrying the rebuild of Clementine?

Best regards,

Robert-André

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

Re: Orphaned packages looking for new maintainers

[Artur Iwicki]

Took over both "fritzing" and "fritzing-parts". If anyone would like to join as 
co-maintainer, let me know.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Artur Iwicki]

>fritzing  logic, orphan1 weeks ago
>fritzing-partslogic, orphan1 weeks ago
I'd be willing to help with this one, but since there already is a 
co-maintainer listed, I'll ask first if they're willing to step up to be the 
main 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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-06-15.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

CutyCapt  orphan   4 weeks ago
abgraph   orphan   2 weeks ago
accrete   orphan   2 weeks ago
amqp  irina, orphan1 weeks ago
apache-commons-vfsmizdebsk, orphan 4 weeks ago
astronomy-backgrounds orphan   2 weeks ago
astronomy-bookmarks   orphan   2 weeks ago
cdk   cicku, fale, orphan  2 weeks ago
cinnamon-applet-globalappmenu orphan   7 weeks ago
coro-mock orphan   1 weeks ago
csvdiff   orphan   1 weeks ago
cvsgraph  bojan, orphan2 weeks ago
cvsplot   orphan   2 weeks ago
cvsweborphan   2 weeks ago
datanucleus-maven-parent  orphan   0 weeks ago
dateformatorphan   4 weeks ago
drawtkorphan   3 weeks ago
ebay-cors-filter  orphan   0 weeks ago
eris  bruno, orphan2 weeks ago
felix-framework   mizdebsk, msimacek, orphan   5 weeks ago
felix-osgi-obr-resolver   orphan   5 weeks ago
fritzing  logic, orphan1 weeks ago
fritzing-partslogic, orphan1 weeks ago
gcx   orphan   2 weeks ago
ggobi orphan   2 weeks ago
glassfish-hk2 orphan   3 weeks ago
gnome-themes  alexl, caillon, caolanm, 4 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, rstrode, ssp
gobby05   kevin, orphan1 weeks ago
gpredict  orphan   2 weeks ago
gtkglextmmchurchyard, orphan   1 weeks ago
invokebinder  mmorsi, orphan   1 weeks ago
ircd-ratbox   orphan   2 weeks ago
jasmine   nodejs-sig, orphan, patches  4 weeks ago
jasmine-node  nodejs-sig, orphan, patches  4 weeks ago
javolutionorphan   0 weeks ago
jp2a  mayorga, orphan  1 weeks ago
js-jquery-datetimepicker  orphan   0 weeks ago
js-json   nodejs-sig, orphan   4 weeks ago
js-zlib   nodejs-sig, orphan, patches, 4 weeks ago
  zbyszek
json-tableorphan   1 weeks ago
kchildlockorphan   3 weeks ago
kitsune   orphan   4 weeks ago
maven-release jcapik, orphan   6 weeks ago
mencalorphan   2 weeks ago
mercator  bruno, orphan2 weeks ago
mnemosyne itamarjp, jpopelka, orphan,  0 weeks ago
  rathann
mocha nodejs-sig, orphan, patches  4 weeks ago
nexcontrolorphan   2 wee

Re: Summary/Minutes from today's FESCo Meeting (2020-06-15)

[Felix Schwarz]

Am 15.06.20 um 19:00 schrieb Petr Šabata:

* What is the scope of Modularity?  (contyk, 15:35:03)
   * AGREED: Modular-only packages are not allowed and modular versions
 are only be allowed as alternatives to non-modular packages. (+9, 0,
 -0)  (contyk, 15:58:47)

(...)

Thank you, FESCo :-)
___
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

Summary/Minutes from today's FESCo Meeting (2020-06-15)

[Petr Šabata]

=
#fedora-meeting-1: FESCO (2020-06-15)
=


Meeting started by contyk at 15:00:27 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-06-15/fesco.2020-06-15-15.00.log.html


Meeting summary
---
* init process  (contyk, 15:00:33)

* Welcome new FESCo members & Meeting time  (contyk, 15:02:15)
  * The new meeting time is Wednesday, 1400 UTC, starting June 24.
(contyk, 15:18:33)

* Council Engineering Representative  (contyk, 15:21:17)
  * LINK:
https://docs.fedoraproject.org/en-US/fesco/Fedora_Council_Engineering_Rep/
(contyk, 15:21:33)
  * contyk will step down from the Council Engineering representative
position; FESCo will process the nominations in #2405 over the next
week.  (contyk, 15:24:20)

* #2400 F34 System-Wide Change: NSS CK_GCM_PARAMS change  (contyk,
  15:24:55)
  * AGREED: FESCo asks rrelyea to rephrase the request and add details
about the expected impact, particularly on rebuilds and revisit in a
week (+8, 0, -0)  (contyk, 15:34:38)

* What is the scope of Modularity?  (contyk, 15:35:03)
  * AGREED: Modular-only packages are not allowed and modular versions
are only be allowed as alternatives to non-modular packages. (+9, 0,
-0)  (contyk, 15:58:47)
  * There is an exception to this rule: if the package does not function
in non-modular Fedora (with reasonable amount of work), it is
permitted to have it in module only. As an example if non-modular
Fedora has dnf 4, and there is module with dnf 5, a package that
only works with dnf 5 can remain modular only, until dnf 5 is
included in non-modular Fedora. For the time being, such  (contyk,
15:58:54)
  * AGREED: Default streams are not allowed in Fedora. This may be
revised in the future, especially if the functionality of default
streams is improved. (+9, 0, -0)  (contyk, 16:00:26)
  * AGREED: Encourage compatibility packages rather than modules
wherever reasonable (e.g., libraries, language interpreters, …, and
anything that can benefit from parallel installability). (+9, 0, -0)
(contyk, 16:02:07)
  * AGREED: Make *modular*.repo optional by splitting them into a
separate package. (+8, 1, -0)  (contyk, 16:03:24)
  * AGREED: Disable *modular*.repo by default in new installations. (2,
0, -7)  (contyk, 16:04:58)
  * Modular repo will remain enabled.  (contyk, 16:05:05)
  * AGREED: Defer to the next meeting. Meanwhile sgallagh will work on
improving policy for those modules with feedback from FESCo members.
(+9, 0, -0)  (contyk, 16:52:36)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EJD3V43ONMVE37DQO6RVQ5ZGN6PJXDBC/
is the case on fedora-devel today.  (zbyszek, 16:52:38)

* Next week's chair  (contyk, 16:52:56)
  * ACTION: ignatenkobrain will chair the next meeting.  (contyk,
16:53:25)

* Open Floor  (contyk, 16:53:32)
  * LINK: https://docs.fedoraproject.org/en-US/fesco/ is not getting
updated.  (zbyszek, 16:55:06)
  * LINK: https://pagure.io/fedora-infrastructure/issue/8964   (bcotton,
16:56:54)

Meeting ended at 16:59:24 UTC.


Action Items

* ignatenkobrain will chair the next meeting.


Action Items, by person
---
* ignatenkobrain
  * ignatenkobrain will chair the next meeting.


People Present (lines said)
---
* mhroncok (153)
* sgallagh (120)
* contyk (107)
* zbyszek (70)
* nirik (57)
* King_InuYasha (54)
* ignatenkobrain (51)
* dcantrell (49)
* zodbot (34)
* cverna (30)
* decathorpe (28)
* bookwar (21)
* bcotton (9)
* Conan_Kudo (0)
* Eighth_Doctor (0)
* Sir_Gallantmon (0)
* Son_Goku (0)
* Pharaoh_Atem (0)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Easier way to autogenerate Provides?

[Richard W.M. Jones]

On Mon, Jun 15, 2020 at 07:50:11AM -0400, Neal Gompa wrote:
> On Mon, Jun 15, 2020 at 7:49 AM Neal Gompa  wrote:
> >
> > On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones  
> > wrote:
> > >
> > > We autogenerate RPM Requires/Provides in a few projects, and it's
> > > quite nice.  eg: supermin-devel has:
> > >
> > >   $ rpm -ql supermin-devel
> > >   /usr/lib/rpm/fileattrs/supermin.attr
> > >   /usr/lib/rpm/supermin-find-requires
> > >
> > > and this means other packages that contain supermin appliances can
> > > simply put their appliance in a particular directory matching the name
> > > "*/supermin.d/packages/" and (since they have to BuildRequire
> > > supermin-devel anyway) RPM will create the correct dependencies
> > > automatically.
> > >
> > > Great!  But ...
> > >
> > > I'd like to use it to autogenerate nbdkit plugin Provides, where the
> > > presence of a file named something like %{_libdir}/nbdkit/plugins/*.so
> > > should generate a Provides with the plugin name, eg:
> > >
> > >   $ rpm -qf --provides /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
> > >   nbdkit-curl-plugin = 1.21.7-1.fc33
> > >
> > > Right now we list them explicitly:
> > >
> > >   https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_161
> > >
> > > The problem is all the current plugins exist in nbdkit itself.  nbdkit
> > > is not a BuildRequire of nbdkit, so it cannot provide RPM rules for
> > > itself.  Doing so would create a nasty circular dependency that makes
> > > bootstrapping awkward.
> > >
> > > I could create a subpackage with the RPM rules, which is still a
> > > circular dependency but at least the subpackage would be noarch and
> > > wouldn't depend on anything else.
> > >
> > > This is getting complicated - is there some easier thing I'm missing here?
> > >
> >
> > I *think* you can include your own Provides generator script and just
> > define the macros in the spec like you would in an attr file, and it
> > should work.
> >
> > Something like so:
> >
> > %__nbdkitplugins_provides %{SOURCE11}
> > %__nbdkitplugins_path ...
> >
> >
> 
> Blech, I mean:
> 
> %global __nbdkitplugins_provides ...
> %global __nbdkitplugins_path ...

Is there an actual example of this?

As far as I can tell this replaces the entire dependency generator,
rather than enhancing it, but I'm probably wrong as the documentation
is extremely oblique.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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

Unexpected find of the week: Pagure & Dist Git Watch List

[Nils Philippsen]

Hi everybody!

We were discussing getting CCs for bugs of components which you no
longer maintain over in #fedora-admin, and I figured that Pagure should
be able to tell me what components I'm watching, just in case I wanted
to remove myself preemptively, before my inbox gets clogged up.

Turns out that the "Pagure Watch List" was news to other people, too,
so here are the links in case you missed the memo, too! ;)

- Dist Git: https://src.fedoraproject.org/dashboard/watchlist
- Pagure.io: https://pagure.io/dashboard/watchlist

Ciao,
Nils
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:  D0C1 1576 CDA6 5B6E BBAE  95B2 7D53 7FCA E9F6 395D
old:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Schedule for Mondays's FESCo Meeting (2020-06-15)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jun 15, 2020 at 11:04:18AM +0200, Petr Šabata wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
> irc.freenode.net.
> 
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
> 
> or run:
>   date -d '2020-06-15 15:00 UTC'
> 
> 
> Links to all issues to be discussed can be found at:
> https://pagure.io/fesco/report/meeting_agenda
> 
> = Special topics =
> 
> #topic Welcome new FESCo members & Meeting time
> https://pagure.io/fesco/issue/2407
> 
> #topic Council Engineering Representative
> #link 
> https://docs.fedoraproject.org/en-US/fesco/Fedora_Council_Engineering_Rep/
> https://pagure.io/fesco/issue/2405
> 
> = Discussed and Voted in the Ticket =
> 
> F33 Self-Contained Change: Drop mod_php
> https://pagure.io/fesco/issue/2402
> APPROVED (+4, 2, -0)
> 
> F33 Self-Contained Change: No more automagic Python bytecompilation (phase 3)
> https://pagure.io/fesco/issue/2401
> APPROVED (+6, 0, -0)
> 
> F33 System-Wide Change: Node.js 14.x by default
> https://pagure.io/fesco/issue/2391
> APPROVED (+5, 0, -0)
> 
> = Followups =
> 
> #topic What is the scope of Modularity?
> https://pagure.io/fesco/issue/2114

2406 contains the latest proposal and discussion on the subject.

Zbyszek

> #topic Request to permit module default streams in ELN
> https://pagure.io/fesco/issue/2390
> 
> = New business =
> 
> #topic #2400 F34 System-Wide Change: NSS CK_GCM_PARAMS change
> https://pagure.io/fesco/issue/2400
> 
> = Open Floor =
> 
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
> 
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Requesting changes/updates to Fedora kde spin page

[Harsh Jain]

Thanks a lot :)

On Mon, Jun 15, 2020 at 6:24 PM Neal Gompa  wrote:

> On Mon, Jun 15, 2020 at 8:50 AM Harsh Jain  wrote:
> >
> > Hey everyone ,
> > I recently downloaded the fedora kde spin and noticed there were some
> differences among the apps that came with it . On the site [1] the web
> browser that comes with the spin is told to be konqueror , but firefox and
> falkon are included in the spin instead . I think there were other apps
> that are shown on the site but are not there in the spin .
> > I request that the web page be changed/updated to display the correct
> set of apps .
> >
> > Should I be filing a bug for this ?
> >
> > [1]-https://spins.fedoraproject.org/kde/
> >
>
> The site is managed here: https://pagure.io/fedora-websites
>
> You can file a bug there. :)
>
>
>
> --
> 真実はいつも一つ！/ 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New protobuf blocked by old protobuf from module [f32]

[Petr Pisar]

On Mon, Jun 15, 2020 at 11:31:09AM +0100, Daniel P. Berrangé wrote:
> I'm trying to install gmic on my Fedora 32 system, which requries opencv,
> which requires protobuf 3.11
> 
> DNF refuses to install any of them though, because protobuf 3.11 is blocked
> by modularity:
> 
>   - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular filtering
>   - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular filtering
> 
> All I can see with "dnf list" is a seriously outdated  version from an unknown
> module:
> 
> protobuf.x86_64
> 3.6.1-6.module_f32+6163+c0e6dcb2 
> fedora-modular   
> protobuf.x86_64
> 3.6.1-6.module_f32+6163+c0e6dcb2 
> updates-modular  
> 
> What is the right way to fix this ?  dnf module list shows me loads of
> modules, but I'm not seing how to determine which of them are enabled vs
> disabled,

"dnf module list" marks enabled streams with "[e]" in a Stream column. (There
also used to be "[d]" for the default streams that were active (read
"pre-enabled") by default, but default streams are now banned and should not
exist in Fedora repositories (since Fedora 32?).)

"dnf module list --enabled" restricts the list to enabled modules only.

> and more importantly which is providing this bogus outdated
> protobuf ?
>

"dnf module provides protobuf-3.6.1-6.module_f32+6163+c0e6dcb2" returns
eclipse:2019-06:3220190902131726:a48fff9b:x86_64 module. Thus you need to
unenable eclipse:2019-06 stream ("dnf module reset eclipse:2019-06"), or
disable the eclipse module completely ("dnf module disable eclipse").

-- Petr


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

Re: New protobuf blocked by old protobuf from module [f32]

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-06-15 at 13:52 +0200, Tomasz Torcz wrote:
> On Mon, Jun 15, 2020 at 12:43:37PM +0200, Igor Raits wrote:
> > >   - package protobuf-3.11.2-2.fc32.i686 is filtered out by
> > > modular
> > > filtering
> > >   - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by
> > > modular
> > > filtering
> > > 
> > > What is the right way to fix this ?  dnf module list shows me
> > > loads
> > > of
> > > modules, but I'm not seing how to determine which of them are
> > > enabled
> > > vs
> > > disabled, and more importantly which is providing this bogus
> > > outdated
> > > protobuf ?
> > 
> > dnf module reset eclipse
> 
>   Could you please explain the steps how to arrive to this "magic"
> invocation?

dnf list on Daniel's system shows only one protobuf build - protobuf-
3.6.1-6.module_f32+6163+c0e6dcb2. Doing koji list-tags --build
protobuf-3.6.1-6.module_f32+6163+c0e6dcb2 shows:

module-eclipse-2019-06-3220190902131726-a48fff9b
module-eclipse-2019-06-3220190902131726-a48fff9b-build


- From where it is easy to figure out which module it is coming from :)

> -- 
> Tomasz Torcz “God, root, what's the difference?”
> to...@pipebreaker.pl   “God is more forgiving.”
> ___
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7nc1MACgkQEV1auJxc
Hh6v0w//ZbRTLiJQJl664pTAPB4WMHhVtYqfCtnOVuA98oxo6VZRgVxK8VK6Lnv7
RQtVcljb11ObQs1Fbr0JijdTERqcRww9W//kYYXOGgs+PI7sZB/y2SnQ3jVybnXm
cXDOHUvROjHPW9vhCM3N0wbDFSq/VWPoXHlUuejEZzt9m7OXGfqP4f/APbt2xyGX
cttvLve7yg5EdjNwMqEDiaipThpFrqd/RCy2qWb8qBauHVm0AHDruGEcjL3oknoF
CtzexxXXgs6eaoNnBpSkAer+iCRdhFhEmkBVk9kPYhNmUelKc8eYKTFDE1gVmpsB
4gHoxZMkTsc6MaAtlhbzPIYwx7Yfwa/spuQZdkp6Shew1fxjlEj4vq9kHZyuSFmW
ir8SneTaqW+Aohv8Xs6E/hBIwm/LfrW+5yWXCeNP9uOwZCi1S+v1IaoxMj0q1o9q
MbLLtXGjdjv9iHiEm5enr0FM/4Z/ls/ob9IQ2boWbqWHuNSTngR26BRKAFbcNcGG
htj5VR6JDu14gsxA1bgQxZQtm90f0UPD+T44VIFR4G1IqGIp82Q5DuZrqbBUCaNZ
B4WuFrooORL/mwwDKIleuWailAyeLQo5bQ8PTSH0EBwUM+sYdHigNYcO6tBQP5Kx
JoDlkYuoXH2/ShRc2zqUg95IHRCslQan4YpUo834p+sUA6XPYCY=
=MuWT
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Requesting changes/updates to Fedora kde spin page

[Neal Gompa]

On Mon, Jun 15, 2020 at 8:50 AM Harsh Jain  wrote:
>
> Hey everyone ,
> I recently downloaded the fedora kde spin and noticed there were some 
> differences among the apps that came with it . On the site [1] the web 
> browser that comes with the spin is told to be konqueror , but firefox and 
> falkon are included in the spin instead . I think there were other apps that 
> are shown on the site but are not there in the spin .
> I request that the web page be changed/updated to display the correct set of 
> apps .
>
> Should I be filing a bug for this ?
>
> [1]-https://spins.fedoraproject.org/kde/
>

The site is managed here: https://pagure.io/fedora-websites

You can file a bug there. :)



-- 
真実はいつも一つ！/ 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

Requesting changes/updates to Fedora kde spin page

[Harsh Jain]

Hey everyone ,
I recently downloaded the fedora kde spin and noticed there were some
differences among the apps that came with it . On the site [1] the web
browser that comes with the spin is told to be konqueror , but firefox and
falkon are included in the spin instead . I think there were other apps
that are shown on the site but are not there in the spin .
I request that the web page be changed/updated to display the correct set
of apps .

Should I be filing a bug for this ?

[1]-https://spins.fedoraproject.org/kde/

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

Re: wt (C++ Web Toolkit) package looking for a new maintainer

[Jonathan Wakely]

On 15/06/20 11:04 +0200, Michal Minar wrote:

Hello,

I've just orphaned wt  package in
fedora.
It now fails to install in Fedora 33
 and I have no longer
free cycles to maintain it.
I'll be happy to assist if anybody is interested to take over.


I don't want to maintain it, but the fix to get it building in F33 was
trivial:

@@ -33,7 +33,8 @@ Patch1: ssl-default-cipher-list.patch

 BuildRequires:  cmake >= 3.1 boost-devel >= 1.41 gcc-c++ openssl-devel doxygen
 BuildRequires:  GraphicsMagick-devel pango-devel sqlite-devel libpq-devel
-BuildRequires:  mariadb-connector-c-devel libharu-devel fcgi-devel zlib-devel 
qt5-devel
+BuildRequires:  mariadb-connector-c-devel libharu-devel fcgi-devel zlib-devel
+BuildRequires:  qt5-qtbase-devel

 # Don't use bundled glew on fedora >= 21
 %if 0%{?fedora} >= 21
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New protobuf blocked by old protobuf from module [f32]

[Daniel P . Berrangé]

On Mon, Jun 15, 2020 at 12:43:37PM +0200, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Mon, 2020-06-15 at 11:31 +0100, Daniel P. Berrangé wrote:
> > I'm trying to install gmic on my Fedora 32 system, which requries
> > opencv,
> > which requires protobuf 3.11
> > 
> > DNF refuses to install any of them though, because protobuf 3.11 is
> > blocked
> > by modularity:
> > 
> >   - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular
> > filtering
> >   - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular
> > filtering
> > 
> > All I can see with "dnf list" is a seriously outdated  version from
> > an unknown
> > module:
> > 
> > protobuf.x86_64 
> > 3.6.1-6.module_f32+6163+c0e6dcb2
> > fedora-modular   
> > protobuf.x86_64 
> > 3.6.1-6.module_f32+6163+c0e6dcb2
> > updates-modular  
> > 
> > What is the right way to fix this ?  dnf module list shows me loads
> > of
> > modules, but I'm not seing how to determine which of them are enabled
> > vs
> > disabled, and more importantly which is providing this bogus outdated
> > protobuf ?
> 
> dnf module reset eclipse

Thank you, that solves it. I'm still wondering how I was supposed
to find out that "eclipse" was the module providing this bogus outdated
"protobuf" RPM to start with ?  Is there some query command that would
do it ? I tried  "dnf module repoquery" and "dnf module provides" with
no luck, but perhaps I got wrong syntax ?

I then had a problem with "dnf install scala" reporting that "scala"
was blocked by a module. Strangely disabling the "scala" module let me
install the "scala" RPM.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New protobuf blocked by old protobuf from module [f32]

[Tomasz Torcz]

On Mon, Jun 15, 2020 at 12:43:37PM +0200, Igor Raits wrote:
> >   - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular
> > filtering
> >   - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular
> > filtering
> > 
> > What is the right way to fix this ?  dnf module list shows me loads
> > of
> > modules, but I'm not seing how to determine which of them are enabled
> > vs
> > disabled, and more importantly which is providing this bogus outdated
> > protobuf ?
> 
> dnf module reset eclipse

  Could you please explain the steps how to arrive to this "magic"
invocation?

-- 
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl   “God is more forgiving.”
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Easier way to autogenerate Provides?

[Neal Gompa]

On Mon, Jun 15, 2020 at 7:49 AM Neal Gompa  wrote:
>
> On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones  wrote:
> >
> > We autogenerate RPM Requires/Provides in a few projects, and it's
> > quite nice.  eg: supermin-devel has:
> >
> >   $ rpm -ql supermin-devel
> >   /usr/lib/rpm/fileattrs/supermin.attr
> >   /usr/lib/rpm/supermin-find-requires
> >
> > and this means other packages that contain supermin appliances can
> > simply put their appliance in a particular directory matching the name
> > "*/supermin.d/packages/" and (since they have to BuildRequire
> > supermin-devel anyway) RPM will create the correct dependencies
> > automatically.
> >
> > Great!  But ...
> >
> > I'd like to use it to autogenerate nbdkit plugin Provides, where the
> > presence of a file named something like %{_libdir}/nbdkit/plugins/*.so
> > should generate a Provides with the plugin name, eg:
> >
> >   $ rpm -qf --provides /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
> >   nbdkit-curl-plugin = 1.21.7-1.fc33
> >
> > Right now we list them explicitly:
> >
> >   https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_161
> >
> > The problem is all the current plugins exist in nbdkit itself.  nbdkit
> > is not a BuildRequire of nbdkit, so it cannot provide RPM rules for
> > itself.  Doing so would create a nasty circular dependency that makes
> > bootstrapping awkward.
> >
> > I could create a subpackage with the RPM rules, which is still a
> > circular dependency but at least the subpackage would be noarch and
> > wouldn't depend on anything else.
> >
> > This is getting complicated - is there some easier thing I'm missing here?
> >
>
> I *think* you can include your own Provides generator script and just
> define the macros in the spec like you would in an attr file, and it
> should work.
>
> Something like so:
>
> %__nbdkitplugins_provides %{SOURCE11}
> %__nbdkitplugins_path ...
>
>

Blech, I mean:

%global __nbdkitplugins_provides ...
%global __nbdkitplugins_path ...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Easier way to autogenerate Provides?

[Neal Gompa]

On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones  wrote:
>
> We autogenerate RPM Requires/Provides in a few projects, and it's
> quite nice.  eg: supermin-devel has:
>
>   $ rpm -ql supermin-devel
>   /usr/lib/rpm/fileattrs/supermin.attr
>   /usr/lib/rpm/supermin-find-requires
>
> and this means other packages that contain supermin appliances can
> simply put their appliance in a particular directory matching the name
> "*/supermin.d/packages/" and (since they have to BuildRequire
> supermin-devel anyway) RPM will create the correct dependencies
> automatically.
>
> Great!  But ...
>
> I'd like to use it to autogenerate nbdkit plugin Provides, where the
> presence of a file named something like %{_libdir}/nbdkit/plugins/*.so
> should generate a Provides with the plugin name, eg:
>
>   $ rpm -qf --provides /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
>   nbdkit-curl-plugin = 1.21.7-1.fc33
>
> Right now we list them explicitly:
>
>   https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_161
>
> The problem is all the current plugins exist in nbdkit itself.  nbdkit
> is not a BuildRequire of nbdkit, so it cannot provide RPM rules for
> itself.  Doing so would create a nasty circular dependency that makes
> bootstrapping awkward.
>
> I could create a subpackage with the RPM rules, which is still a
> circular dependency but at least the subpackage would be noarch and
> wouldn't depend on anything else.
>
> This is getting complicated - is there some easier thing I'm missing here?
>

I *think* you can include your own Provides generator script and just
define the macros in the spec like you would in an attr file, and it
should work.

Something like so:

%__nbdkitplugins_provides %{SOURCE11}
%__nbdkitplugins_path ...



-- 
真実はいつも一つ！/ 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

Easier way to autogenerate Provides?

[Richard W.M. Jones]

We autogenerate RPM Requires/Provides in a few projects, and it's
quite nice.  eg: supermin-devel has:

  $ rpm -ql supermin-devel
  /usr/lib/rpm/fileattrs/supermin.attr
  /usr/lib/rpm/supermin-find-requires

and this means other packages that contain supermin appliances can
simply put their appliance in a particular directory matching the name
"*/supermin.d/packages/" and (since they have to BuildRequire
supermin-devel anyway) RPM will create the correct dependencies
automatically.

Great!  But ...

I'd like to use it to autogenerate nbdkit plugin Provides, where the
presence of a file named something like %{_libdir}/nbdkit/plugins/*.so
should generate a Provides with the plugin name, eg:

  $ rpm -qf --provides /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so 
  nbdkit-curl-plugin = 1.21.7-1.fc33

Right now we list them explicitly:

  https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_161

The problem is all the current plugins exist in nbdkit itself.  nbdkit
is not a BuildRequire of nbdkit, so it cannot provide RPM rules for
itself.  Doing so would create a nasty circular dependency that makes
bootstrapping awkward.

I could create a subpackage with the RPM rules, which is still a
circular dependency but at least the subpackage would be noarch and
wouldn't depend on anything else.

This is getting complicated - is there some easier thing I'm missing here?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New protobuf blocked by old protobuf from module [f32]

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-06-15 at 11:31 +0100, Daniel P. Berrangé wrote:
> I'm trying to install gmic on my Fedora 32 system, which requries
> opencv,
> which requires protobuf 3.11
> 
> DNF refuses to install any of them though, because protobuf 3.11 is
> blocked
> by modularity:
> 
>   - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular
> filtering
>   - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular
> filtering
> 
> All I can see with "dnf list" is a seriously outdated  version from
> an unknown
> module:
> 
> protobuf.x86_64 
> 3.6.1-6.module_f32+6163+c0e6dcb2
> fedora-modular   
> protobuf.x86_64 
> 3.6.1-6.module_f32+6163+c0e6dcb2
> updates-modular  
> 
> What is the right way to fix this ?  dnf module list shows me loads
> of
> modules, but I'm not seing how to determine which of them are enabled
> vs
> disabled, and more importantly which is providing this bogus outdated
> protobuf ?

dnf module reset eclipse

> 
> Regards,
> Daniel
> -- 
> > : https://berrange.com  -o-
> > https://www.flickr.com/photos/dberrange :|
> > : https://libvirt.org -o-
> > https://fstop138.berrange.com :|
> > : https://entangle-photo.org-o-
> > https://www.instagram.com/dberrange :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7nUNkACgkQEV1auJxc
Hh4Ijw/+LN9prD1aH0AiNQGExJA1wtq2AMK1rCUGDgUwuC0AbGf0Iw6gf03DgvDL
636ncSbApXlmxR+LhAhyCriAaa7CpMciB3YJvlLrGR7NLGkNLj7zMvETpueXTq7d
D/Qj6gnTL90asfHNip8EiXRj4zIRhexf6kVNXnmthfnlU8+44RQcOc5bGztJ633D
u8cMo2ksKLWni2n+Or7Oh6LO0Pob0LxH/iaSOVg+TIoQ84/6nHWZFIarrmzC8D+H
d0xuSBGcQFDw+5gXA4dVXz0FhYPIYDBtV7ZzCEgn9uNyY4BpMrfIlxF1DGiLMSIz
NCiLtpiUEvukWzmKWkUDHk5//NawtNPRzOT7WaKdvbcHr43fouZrPKw1mNU3AmgJ
zAgkvMSTpKzGOG328y9XEx/mYcHC/rw/+ct+1m2ctCp8NR3/oPRUUQ5CIt0Y0Vbk
oOPnFghGF8wbSd+jdqgRyTsKBI0OSwQCaVBsNM9lx81J6zVfWTCaNiOgrRy/jWrd
w2btjd/TagDMKgj2PBcPTPrLjU1BAXZWbT58XFMsM8AGfUrUryE894o2eW+qPeNv
f2ruwOsG4uh1qnJh7KKUQCnmpqbWPK1ACwqHdcGdAnqXtqmlCF9PyyVynZ9R3KlH
sF1B0oY1/FofziAClw88zyvqBEc6vsEfPGbJo6N5h/UoAtcSqNk=
=d4WE
-END 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

New protobuf blocked by old protobuf from module [f32]

[Daniel P . Berrangé]

I'm trying to install gmic on my Fedora 32 system, which requries opencv,
which requires protobuf 3.11

DNF refuses to install any of them though, because protobuf 3.11 is blocked
by modularity:

  - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular filtering
  - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular filtering

All I can see with "dnf list" is a seriously outdated  version from an unknown
module:

protobuf.x86_64
3.6.1-6.module_f32+6163+c0e6dcb2 fedora-modular 
  
protobuf.x86_64
3.6.1-6.module_f32+6163+c0e6dcb2 
updates-modular  

What is the right way to fix this ?  dnf module list shows me loads of
modules, but I'm not seing how to determine which of them are enabled vs
disabled, and more importantly which is providing this bogus outdated
protobuf ?


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

soname bump: librealsense

[Till Hofmann]

Hi all,

I'm updating librealsense to 2.35.2 in Rawhide. The only dependency is
fawkes, which is currently FTBFS because gazebo fails to install.

Kind regards,
Till
___
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

Schedule for Mondays's FESCo Meeting (2020-06-15)

[Petr Šabata]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-06-15 15:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Special topics =

#topic Welcome new FESCo members & Meeting time
https://pagure.io/fesco/issue/2407

#topic Council Engineering Representative
#link https://docs.fedoraproject.org/en-US/fesco/Fedora_Council_Engineering_Rep/
https://pagure.io/fesco/issue/2405

= Discussed and Voted in the Ticket =

F33 Self-Contained Change: Drop mod_php
https://pagure.io/fesco/issue/2402
APPROVED (+4, 2, -0)

F33 Self-Contained Change: No more automagic Python bytecompilation (phase 3)
https://pagure.io/fesco/issue/2401
APPROVED (+6, 0, -0)

F33 System-Wide Change: Node.js 14.x by default
https://pagure.io/fesco/issue/2391
APPROVED (+5, 0, -0)

= Followups =

#topic What is the scope of Modularity?
https://pagure.io/fesco/issue/2114

#topic Request to permit module default streams in ELN
https://pagure.io/fesco/issue/2390

= New business =

#topic #2400 F34 System-Wide Change: NSS CK_GCM_PARAMS change
https://pagure.io/fesco/issue/2400

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
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

wt (C++ Web Toolkit) package looking for a new maintainer

[Michal Minar]

Hello,

I've just orphaned wt  package in
fedora.
It now fails to install in Fedora 33
 and I have no longer
free cycles to maintain it.
I'll be happy to assist if anybody is interested to take over.

Best regards,
Michal

-- 

Michal Minář

SENIOR SOFTWARE ON-SITE ENGINEER @ SAP LINUXLAB

Red Hat GmbH , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas
Savage

mimi...@redhat.com
M: +49-173-592- <+49-179-531-3672>2662 IM: miminarTelegram:
@miminarht 

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

Re: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

[Florian Weimer]

* Jiri Vanek:

> Is there some replacemnt for this subpackage? At least theoretical?

For the JDBC connector to SQLite, there's sqlite-jdbc and javasqlite.
But the on-disk format will be different.

For the key-value store, there is the je package, but again the on-disk
format is different.

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

Re: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

[Ondrej Dubaj]

Agree,

I am not aware of any replacement of this JDBC connector. As you said, it
can be easily returned if it would be missed.

On Mon, Jun 15, 2020 at 9:27 AM Jiri Vanek  wrote:

> On 6/15/20 9:13 AM, Florian Weimer wrote:
> > * Ondrej Dubaj:
> >
> >> The problem is unknown runtime behaviour of libdb-java (build with
> >> jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an
> >> active user of libdb java ?
> >
> > I am not.
> >
> > Upon second thought, it doesn't seem to make sense to preserve
> > libdb-java (although I expect that it's only necessary to fix the
> > autoconf check).
>
>  Maybe. However upstream of is dead. And usptream confirmed that they are
> unable to verify that it
> works in JDK11.
>
> Imho droppoing such possibly instbale package is probably good way.  If it
> will be missed, then it
> can be returned, and the one wishing its return will be used as tester.
>
> Is there some replacemnt for this subpackage? At least theoretical?
> >
> > Thanks,
> > Florian
> > ___
> > java-devel mailing list -- java-de...@lists.fedoraproject.org
> > To unsubscribe send an email to java-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/java-de...@lists.fedoraproject.org
> >
>
>
> --
> Jiri Vanek
> Senior QE engineer, OpenJDK QE lead, Mgr.
> Red Hat Czech
> jva...@redhat.comM: +420775390109
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

[Ondrej Dubaj]

I edited the autoconf check and it seems there are other issues, which are
causing problems. I also contacted upstream and they do not have any
experience with this version working with jdk-11 or jvm-11. I see it as a
high risk to "somehow" rebuild it
 and push it to rawhide. In addition, there is a deprecation announcement
to whole libdb, so I consider this as a good first step.

Thanks,
Ondrej

On Mon, Jun 15, 2020 at 9:13 AM Florian Weimer  wrote:

> * Ondrej Dubaj:
>
> > The problem is unknown runtime behaviour of libdb-java (build with
> > jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an
> > active user of libdb java ?
>
> I am not.
>
> Upon second thought, it doesn't seem to make sense to preserve
> libdb-java (although I expect that it's only necessary to fix the
> autoconf check).
>
> Thanks,
> Florian
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

[Jiri Vanek]

On 6/15/20 9:13 AM, Florian Weimer wrote:
> * Ondrej Dubaj:
> 
>> The problem is unknown runtime behaviour of libdb-java (build with
>> jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an
>> active user of libdb java ?
> 
> I am not.
> 
> Upon second thought, it doesn't seem to make sense to preserve
> libdb-java (although I expect that it's only necessary to fix the
> autoconf check).

 Maybe. However upstream of is dead. And usptream confirmed that they are 
unable to verify that it
works in JDK11.

Imho droppoing such possibly instbale package is probably good way.  If it will 
be missed, then it
can be returned, and the one wishing its return will be used as tester.

Is there some replacemnt for this subpackage? At least theoretical?
> 
> Thanks,
> Florian
> ___
> java-devel mailing list -- java-de...@lists.fedoraproject.org
> To unsubscribe send an email to java-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/java-de...@lists.fedoraproject.org
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jva...@redhat.comM: +420775390109
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to create a bodhi update from f32-kde tag?

[Robin Lee]

On Mon, Jun 15, 2020 at 2:59 PM Kalev Lember  wrote:
>
> On 6/15/20 03:55, Robin Lee wrote:
> > Hi,
> >
> > I rebuilt some packages to the f32-kde tag for Qt 5.14.2. And after the new
> > qt package being pushed to stable, I want to create an update for my 
> > packages.
> >
> > But bodhi request failed:
> > $ bodhi updates new --type bugfix --notes 'Deepin rebuilds for Qt
> > 5.14.2' --request testing --autotime --autokarma --suggest logout
> > --user cheeselee
> > deepin-kwin-0.1.0-7.fc32,deepin-qt-dbus-factory-5.0.1-5.fc32,dtkwidget-2.1.1-5.fc32,deepin-qt5integration-5.0.0-5.fc32,deepin-launcher-5.0.0-5.fc32,deepin-file-manager-5.0.0-7.fc32,deepin-editor-1.2.9.1-5.fc32
> >
> > Cannot find release associated with build: deepin-kwin-0.1.0-7.fc32,
> > tags: ['f32-kde']
> >
> > So, which is the proper way to create to the update?
>
> Hi Robin,
>
> You need to tag them over to the regular updates-candidate tag first before 
> submitting the bodhi update:
>
> $ koji tag-build f32-updates-candidate deepin-kwin-0.1.0-7.fc32 
> deepin-qt-dbus-factory-5.0.1-5.fc32 dtkwidget-2.1.1-5.fc32 
> deepin-qt5integration-5.0.0-5.fc32 deepin-launcher-5.0.0-5.fc32 
> deepin-file-manager-5.0.0-7.fc32 deepin-editor-1.2.9.1-5.fc32

Thanks! New update is created.

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

Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

[Florian Weimer]

* Ondrej Dubaj:

> The problem is unknown runtime behaviour of libdb-java (build with
> jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an
> active user of libdb java ?

I am not.

Upon second thought, it doesn't seem to make sense to preserve
libdb-java (although I expect that it's only necessary to fix the
autoconf check).

Thanks,
Florian
___
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