Re: spin-kickstarts package

[Casper]

Neal Gompa a écrit :
> On Wed, Nov 23, 2022 at 2:52 PM Kevin Fenzi  wrote:
> >
> > Greetings everyone.
> >
> > So, we used to have a release requirement that we package up and release
> > along side the release a spin-kickstarts rpm package with the current
> > kickstarts used for that release.
> >
> > This resulted in a bunch of last minute scrambling and blockers, and
> > even then, we often pushed fixes after release and people would get the
> > out of date one in the package and get confused.
> >
> > So, we changed that requirement, but then since there was no
> > requirement, we haven't really been updating the rpm much.
> > (see https://bugzilla.redhat.com/show_bug.cgi?id=2144207 )
> >
> > I'd like to just retire the rpm package and point folks to the git repo.
> > I think this will get people up to date versions of things,
> > and avoid pointlessly updating a package.
> >
> > Anyone have any arguments to save the rpm version?
> > Or shall I just retire it/update docs?
> >
> 
> Is there a reason we couldn't just automatically update the package
> once we're in freeze so that it has what we're shipping? By the time
> we're down to the wire for final freeze, we're not changing the
> kickstarts that often.
> 

Yes, Freeze exception, forever.

I'm currently using that package especially, using symlinks to
officials kickstarts in that package. Everything will go to trash
now... :(

( https://fedorapeople.org/cgit/fantom/public_git/im-kickstarts.git/tree/ )

-- 
GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org
CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der
Jabber/XMPP Messaging: cas...@casperlefantom.net


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should the policy documents better reflect real package maintenance practice?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Nov 23, 2022 at 04:04:59PM -0800, Gordon Messmer wrote:
> In the wild, I often see Fedora described as a "semi-rolling" release. As a
> policy matter, the distribution promises to be mostly stable, but I find it
> increasingly hard to honestly present it as such.
> 
> As a couple of quick examples, I'd point out that in Fedora 35, Blender
> updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs
> updated from version 27 to 28.  I've read in the KDE Matrix channel that KDE
> will be updated in Fedora 36 to 5.26, even though it has already been
> updated from 5.24 -> 5.25 (my reading of the KDE update policy is that
> Fedora used to update all releases with every KDE release, but decided to
> stop).  Firefox and Thunderbird get updates in most releases, even when they
> contain API-breaking changes  (those really should have an explicit
> exception, IMHO.)  I could offer more, but my point is simply that examples
> of updates in prominent packages isn't hard to find.

FWIW, I was sure that we have an explicit exception for Firefox. But
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#exceptions-list
doesn't list it.

Yeah, I think that the way updates are managed has in practice changed a lot.
This is at least partially caused by the slow change in relationship between
upstreams and our packaging: the distro is inching ever closer to being a
thin delivery mechanism for upstream code and upstream build system and
upstream packaging decisions and upstream release cadence. Even a few years
ago it was fairly common for the packaging to be a big affair with tweaks
to the upstream build system or even a completely custom build, downstream
patches, and many modifications to the final layout. There still are packages
like this, but less and less. If the upstream is sane, there is no need to
deal with any of that.

Another aspect that has changed is that many upstreams are better at keeping
backwards compatibility. E.g. in Rust and Python ecosystems, semver is now
the norm, and in my experience the associated understanding that breaking API
is bad is more widespread. So there are less reasons for us not to update.
At the same time, software is ever more complicated and moves ever faster,
so maintaining multiple versions in parallel is a lot of work.

Combining all that (bigger and more complicated packages, saner upstream
updates, and our packaging being closer to upstream), just makes it less
work for the packager to release the same upstream version in all Fedora
releases.

Then there's the aspect that for fast-moving software, the latest version
may be the only usable version.

> That's not necessarily to object to those changes (though I did have to do
> some minor fixes after the emacs update, and I grumbled quietly), and I
> don't want to disrupt users getting new features if that's what everyone
> actually wants.  But, it does bother me that the documentation doesn't seem
> to reflect reality.  I think that the documentation should offer users a
> realistic expectation of what they'll get from Fedora.
> 
> Does anyone else feel like the documentation should be updated, or am I
> making too much of this?

I think the documentation should be updated to follow the changing practice.
I'd change the policy to allow packages to update to latest versions
if deemed the best option by the maintainers. (Guidance when it is
actually the best option would need to be provided too of course.)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: zdohnal pushed to tests/vim (main). "upstream-unittests: Apply RPM workaround for package notes from Ruby (..more)"

[Zdenek Dohnal]

Thanks, Mamoru!

Looks like a race condition between me and Vita :D

Either way, I've tested whether Vim with Ruby interpreter can be built 
without Ruby's LDFLAGS and it worked fine, so I've sent a patch which 
removes Ruby's LDFLAGS from Vim. The patch was accepted, so hopefully I 
can avoid such errors in Vim in the future even without such workarounds.



Zdenek

On 11/23/22 13:20, Mamoru TASAKA wrote:

notificati...@fedoraproject.org wrote on 2022/11/23 20:34:

Notification time stamped 2022-11-23 11:34:19 UTC

 From 1f016e5dedbb5bc7293c1638e1238989d6fabaa5 Mon Sep 17 00:00:00 2001
From: Zdenek Dohnal 
Date: Nov 23 2022 11:30:01 +
Subject: upstream-unittests: Apply RPM workaround for package notes 
from Ruby



Vim adds Ruby LDFLAGS during configuration, which (due Ruby's decision
to embed flags from the building time) contains flags from buildsystem
environment, especially package notes. This flag expects additional
environment variables to be set and they aren't set in normal
environment.

I've reported it to Vim upstream with PR which removes Ruby LDFLAGS from
configure script https://github.com/vim/vim/pull/11592 .



And ruby (on rawhide for now) removed package_notes again because
currently non-rpmbuild build is broken with embedded package_notes flag:

https://src.fedoraproject.org/rpms/ruby/c/1d0c071aebd50621eb049a2ab8d20da3133f9f16 


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

Regards,
Mamoru



---

diff --git a/Sanity/upstream-unittests/runtest.sh 
b/Sanity/upstream-unittests/runtest.sh

index 1919bd4..6f22812 100755
--- a/Sanity/upstream-unittests/runtest.sh
+++ b/Sanity/upstream-unittests/runtest.sh
@@ -70,6 +70,10 @@ rlJournalStart
  rlRun "RUBY_CFLAGS='`ruby -r rbconfig -e "puts 
RbConfig::CONFIG['CFLAGS']"`'" 0 "Get ruby CFLAGS"

  rlRun "export CFLAGS='$RUBY_CFLAGS'" 0 "Set ruby CFLAGS"
  +    # newer redhat-rpm-config brings in packager-notes script, 
which breaks LDFLAGS we get from Ruby
+    # we need to set several env variable randomly to get 
configure working again...
+    rlRun "RPM_WORKAROUND='RPM_ARCH=\"x86_64\" 
RPM_PACKAGE_RELEASE=\"1\" RPM_PACKAGE_VERSION=\"1\" 
RPM_PACKAGE_NAME=\"vim\"'"

+
  # show relevant info & ENV variables
  rlLog "TEST:   $TEST"
  rlLog "CONFOPT:    $CONFOPT"
@@ -85,8 +89,8 @@ rlJournalStart
  rlRun "TERM=$TERM_type"
    # following block of code is taken from upstream travis.yml
-    rlRun "su $TESTER -c './configure ${CONFOPT} 
CFLAGS=\"${CFLAGS} $RUBY_FLAGS\"'" 0 "Configure Vim"
-    rlRun "su $TESTER -c 'make'" 0 "Build the binary which we 
substitute"
+    rlRun "su $TESTER -c './configure ${CONFOPT} 
CFLAGS=\"${CFLAGS} $RUBY_FLAGS\" $RPM_WORKAROUND'" 0 "Configure Vim"
+    rlRun "su $TESTER -c '$RPM_WORKAROUND make'" 0 "Build the 
binary which we substitute"
  rlRun "su $TESTER -c 'ln -sf /usr/bin/vim src/vim'"    0   
"Create symlink to installed vim for testing"
  rlRun "su $TESTER -c 'make ${TEST} |& tee output'" 0,2 "Run 
tests (skip builtin terminal errors)"

  _res_=$?


https://src.fedoraproject.org/tests/vim/c/1f016e5dedbb5bc7293c1638e1238989d6fabaa5?branch=main 


___
scm-commits mailing list -- scm-comm...@lists.fedoraproject.org
To unsubscribe send an email to 
scm-commits-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/scm-comm...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue



--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2142699] Please build perl-Lchown for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Lchown-1.01-24.el9
Last Closed||2022-11-24 03:41:07



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-2a08eba2b7 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2142699
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2130616] Please branch and build perl-Inline-C in epel9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-11-24 03:41:04



--- Comment #9 from Fedora Update System  ---
FEDORA-EPEL-2022-8170747ecb has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2130616
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GSSDP and GUPnP 1.6 coming to Rawhide

[Elliott Sales de Andrade]

On Mon, Nov 21, 2022 at 2:04 PM David King  wrote:
>
> The 1.6 series of both GSSDP and GUPnP was released a while ago, and the
> 1.6.2 releases contain an important fix for Rygel (which itself depends
> on the 1.6 series in the latest version):
>
> https://discourse.gnome.org/t/important-gssdp-gupnp-1-6-2/12394
>
> As these versions bring new sonames, I have built them in a side tag for
> Rawhide, and plan to merge that in a week or so. I have already built
> Rygel and gupnp-tools in the side tag, but there are several other
> packages which depend on gupnp and gssdp, at least those below:
>

The biggest change between 1.4 and 1.6 is the port to libsoup3. Should
this be coordinated with those Changes?

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Maxwell G via devel]

On Thu Nov 24, 2022 at 02:39 +0100, Miro Hrončok wrote:
> go-compilers
> go-srpm-macros

These should both be orphaned. go-srpm-macros has been retired, as it's
now a subpackage of go-rpm-macros. go-compilers is Obsoleted by
go-rpm-macros itself, but it looks like it has not yet been retired.
I've gone ahead and done that. This split happened a few years ago, but
the old packages were never properly removed.

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: spin-kickstarts package

[Neal Gompa]

On Wed, Nov 23, 2022 at 2:52 PM Kevin Fenzi  wrote:
>
> Greetings everyone.
>
> So, we used to have a release requirement that we package up and release
> along side the release a spin-kickstarts rpm package with the current
> kickstarts used for that release.
>
> This resulted in a bunch of last minute scrambling and blockers, and
> even then, we often pushed fixes after release and people would get the
> out of date one in the package and get confused.
>
> So, we changed that requirement, but then since there was no
> requirement, we haven't really been updating the rpm much.
> (see https://bugzilla.redhat.com/show_bug.cgi?id=2144207 )
>
> I'd like to just retire the rpm package and point folks to the git repo.
> I think this will get people up to date versions of things,
> and avoid pointlessly updating a package.
>
> Anyone have any arguments to save the rpm version?
> Or shall I just retire it/update docs?
>

Is there a reason we couldn't just automatically update the package
once we're in freeze so that it has what we're shipping? By the time
we're down to the wire for final freeze, we're not changing the
kickstarts that often.


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

[EPEL-devel] Re: EPEL 10 proposal

[Carl George]

On Wed, Nov 23, 2022 at 2:27 PM Maxwell G via epel-devel
 wrote:
>
> On Wed Nov 23, 2022 at 00:52 CST, Carl George wrote:
> > I would also ask that feedback be provided there instead of as email
> > replies here on the list.
>
> I don't think there's been a formal discussion about moving EPEL
> discussions over to the forums. We already have communication split
> between the issue tracker and the ML, so I'm -1 to also adding the
> forums. In general, I find it easier to keep up with and participate in
> discussions on mailing lists than on forums. However, it seems to me
> that this is just for this one proposal, so I guess my comment is off
> topic.
>
> --
> Best,
>
> Maxwell G (@gotmax23)
> Pronouns: He/Him/His
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

EPEL is part of Fedora.  discussion.fpo is one of the official places
to talk about Fedora things [0].  We already have an #epel tag there
with multiple posts [1].  The platform (discourse) has some support
for email if you prefer that.  On the tag page there is a bell icon
that lets you subscribe to a tag, which I believe will email you for
every topic started in that tag.  You can reply to topics by replying
to those emails.  The regular mailing lists are also a valid place to
discuss Fedora things, but in this instance I wanted to use
discussion.fpo for two specific reasons: 1) I wanted to use markdown
tables, and 2) I wanted to be able to edit the original post to add
FAQ items as feedback comes in.

[0] https://docs.fedoraproject.org/en-US/project/help/#_fedora_discussion
[1] https://discussion.fedoraproject.org/tag/epel

-- 
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20221123.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221122.n.0
NEW: Fedora-Rawhide-20221123.n.1

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  2
Dropped packages:8
Upgraded packages:   148
Downgraded packages: 0

Size of added packages:  152.05 KiB
Size of dropped packages:15.73 MiB
Size of upgraded packages:   4.08 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   48.01 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20221123.n.1.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20221123.n.1.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20221123.n.1.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20221123.n.1.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-opytimark-1.0.8-2.fc38
Summary: Python implementation of Optimization Benchmarking Functions
RPMs:python3-opytimark
Size:119.89 KiB

Package: python-uhashring-2.1-1.fc38
Summary: Python module uhashring
RPMs:python3-uhashring
Size:32.16 KiB


= DROPPED PACKAGES =
Package: golang-github-anaskhan96-soup-1.2.4-6.fc37
Summary: Web Scraper in Go, similar to BeautifulSoup
RPMs:golang-github-anaskhan96-soup-devel
Size:20.74 KiB

Package: golang-github-hajimehoshi-mp3-0.3.1-5.fc37
Summary: MP3 decoder in pure Go
RPMs:golang-github-hajimehoshi-mp3-devel
Size:11.06 MiB

Package: golang-github-hajimehoshi-oto-0.7.1-4.fc36
Summary: Low-level library to play sound on multiple platforms
RPMs:golang-github-hajimehoshi-oto-devel
Size:39.42 KiB

Package: rubygem-POpen4-0.1.4-23.fc37
Summary: Open4 cross-platform
RPMs:rubygem-POpen4 rubygem-POpen4-doc
Size:289.74 KiB

Package: rubygem-Platform-0.4.2-1.fc38
Summary: Hopefully robust platform sensing
RPMs:rubygem-Platform rubygem-Platform-doc
Size:277.41 KiB

Package: rubygem-arel-9.0.0-11.fc37
Summary: Arel is a SQL AST manager for Ruby
RPMs:rubygem-arel rubygem-arel-doc
Size:743.61 KiB

Package: rust-base100-0.4.1-18.fc37
Summary: Encode your data into emoji
RPMs:base100
Size:1.44 MiB

Package: rust-pommes-0.0.2-8.fc37
Summary: Project object model model (and parser using serde)
RPMs:pommes rust-pommes+default-devel rust-pommes-devel
Size:1.89 MiB


= UPGRADED PACKAGES =
Package:  ModemManager-1.20.2-1.fc38
Old package:  ModemManager-1.18.8-2.fc37
Summary:  Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib 
ModemManager-glib-devel ModemManager-vala
Size: 11.92 MiB
Size change:  998.12 KiB
Changelog:
  * Tue Nov 22 2022 Lubomir Rintel  - 1.20.2-1
  - Update to 1.20.2


Package:  angelscript-2.35.1-1.fc38
Old package:  angelscript-2.32.0-14.fc37
Summary:  Flexible cross-platform scripting library
RPMs: angelscript angelscript-devel
Size: 4.86 MiB
Size change:  304.62 KiB
Changelog:
  * Mon Nov 21 2022 Pete Walter  - 2.35.1-1
  - Update to 2.35.1


Package:  ansible-collections-openstack-2.0.0-0.1.ed36d82git.fc38
Old package:  ansible-collections-openstack-1.7.1-4.938abd0git.fc37
Summary:  Openstack Ansible collections
RPMs: ansible-collections-openstack
Size: 164.41 KiB
Size change:  5.00 KiB
Changelog:
  * Wed Nov 23 2022 Alfredo Moralejo  - 
2.0.0-0.1.ed36d82git
  - Update to pre-2.0.0 commit (ed36d82a0c60a841d2f30c61a50d60531481b2cc)


Package:  apt-2.5.4-1.fc38
Old package:  apt-2.5.3-1.fc38
Summary:  Command-line package manager for Debian packages
RPMs: apt apt-apidoc apt-devel apt-doc apt-libs apt-utils
Size: 13.82 MiB
Size change:  -5.78 KiB
Changelog:
  * Wed Nov 23 2022 S??rgio Basto  - 2.5.4-1
  - Update apt to 2.5.4 (#2138830)


Package:  blueman-1:2.3.5-1.fc38
Old package:  blueman-1:2.3.4-1.fc38
Summary:  GTK+ Bluetooth Manager
RPMs: blueman blueman-caja blueman-nautilus blueman-nemo
Size: 6.26 MiB
Size change:  19.40 KiB
Changelog:
  * Tue Nov 22 2022 Artur Frenszek-Iwicki  - 1:2.3.5-1
  - Update to v2.3.5


Package:  carat-1:2.1-1.20211018gitfd0b757.fc38
Old package:  carat-2.1b1.2020.06.04-4.fc37
Summary:  Crystallographic AlgoRithms And Tables
RPMs: carat carat-doc carat-tables
Size: 19.90 MiB
Size change:  -318.58 KiB
Changelog:
  * Tue Nov 22 2022 Jerry James  - 
1:2.1-1.20211018gitfd0b757
  - Version 2.1 plus bug fixes from git
  - Bump epoch to fix broken upgrade path
  - License change from GPLv3+ to GPL-2.0-or-later
  - Move manual into the doc subpackage


Package:  castxml-0.4.8-1.fc38
Old package:  castxml-0.4.7-1.fc38
Summary:  C-family abstract syntax tree XML output tool
RPMs: castxml
Size: 2.90 MiB
Size change:  1.56 KiB

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Miro Hrončok]

On 23. 11. 22 21:17, Jan Chaloupka wrote:

I you want all your golang packages reassigned to eclipseo, all you need is to 
tell me to do it and I'll do it.


That would be great. By all means. Thank you. Also, thank you eclipseo for 
taking care of the packages.


In progress. This is what was left when I grepped golang. What about them? I 
suppose the go ones should be transferred as well ?


cadvisor
etcd
glide
go-compilers
go-srpm-macros
godep
golint
gotags
kubernetes-ansible


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Should the policy documents better reflect real package maintenance practice?

[Gordon Messmer]

In the wild, I often see Fedora described as a "semi-rolling" release. 
As a policy matter, the distribution promises to be mostly stable, but I 
find it increasingly hard to honestly present it as such.


As a couple of quick examples, I'd point out that in Fedora 35, Blender 
updated from 2.93 (an LTS version) to version 3.  In Fedora 36, Emacs 
updated from version 27 to 28.  I've read in the KDE Matrix channel that 
KDE will be updated in Fedora 36 to 5.26, even though it has already 
been updated from 5.24 -> 5.25 (my reading of the KDE update policy is 
that Fedora used to update all releases with every KDE release, but 
decided to stop).  Firefox and Thunderbird get updates in most releases, 
even when they contain API-breaking changes  (those really should have 
an explicit exception, IMHO.)  I could offer more, but my point is 
simply that examples of updates in prominent packages isn't hard to find.


That's not necessarily to object to those changes (though I did have to 
do some minor fixes after the emacs update, and I grumbled quietly), and 
I don't want to disrupt users getting new features if that's what 
everyone actually wants.  But, it does bother me that the documentation 
doesn't seem to reflect reality.  I think that the documentation should 
offer users a realistic expectation of what they'll get from Fedora.


Does anyone else feel like the documentation should be updated, or am I 
making too much of this?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FESCo election nominations are now open

[Ben Cotton]

This is your reminder that nominations are open through 30 November.
There are currently four nominations for five open seats.

On Wed, Nov 16, 2022 at 12:49 PM Ben Cotton  wrote:
>
> Now through 30 November, you may nominate candidates for the open
> seats on the Fedora Engineering Steering Committee (FESCo).
>
> To nominate yourself (or others, if you check with them first), visit:
> https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
>
> FESCo is currently selecting the questions for the interview
> questionnaire, which will be finalized before the beginning of the
> interview period.
>
> For more information, see the Community Blog post:
> https://communityblog.fedoraproject.org/f37-election-nominations-now-open/
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2147442] New: perl-DBIx-Class-Schema-Loader-0.07051 is available

[bugzilla]

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

Bug ID: 2147442
   Summary: perl-DBIx-Class-Schema-Loader-0.07051 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBIx-Class-Schema-Loader
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.07051
Upstream release that is considered latest: 0.07051
Current version/release in rawhide: 0.07050-1.fc38
URL: http://search.cpan.org/dist/DBIx-Class-Schema-Loader/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/6653/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-DBIx-Class-Schema-Loader


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2147442
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: EPEL 10 proposal

[Maxwell G via epel-devel]

On Wed Nov 23, 2022 at 00:52 CST, Carl George wrote:
> I would also ask that feedback be provided there instead of as email
> replies here on the list.

I don't think there's been a formal discussion about moving EPEL
discussions over to the forums. We already have communication split
between the issue tracker and the ML, so I'm -1 to also adding the
forums. In general, I find it easier to keep up with and participate in
discussions on mailing lists than on forums. However, it seems to me
that this is just for this one proposal, so I guess my comment is off
topic.

--
Best,

Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Jan Chaloupka]

> I you want all your golang packages reassigned to eclipseo, all you need is 
> to tell me to do it and I'll do it.

That would be great. By all means. Thank you. Also, thank you eclipseo for 
taking care of the packages.

Jan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Miro Hrončok]

On 23. 11. 22 17:35, Jan Chaloupka wrote:

Hi Robert-André,

Checking the consul it looks like I need to create a ticket for all orphaned 
package to change their point of contact. Assuming the same holds for all other 
orphaned packages one ticket with request to change their PoC is more practical 
than creating one for each. Feel free to open the ticket. I will give my +1 
wherever needed.


I you want all your golang packages reassigned to eclipseo, all you need is to 
tell me to do it and I'll do it.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Add {{package|fedora-autofirstboot}} to desktop variants to run a
predetermined set of tasks on first boot after post installation,
notably installing codecs and cleaning up installer packages from the
installed system.

== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngomp...@gmail.com


== Detailed Description ==
{{package|fedora-autofirstboot}} is a collection of scripts that
invoke on firstboot of a freshly installed system to run a set of
predetermined tasks. It also provides a framework for third-parties to
introduce their own firstboot tasks to run through this framework. The
initial services included are to install OpenH264 and remove Anaconda.


== Benefit to Fedora ==
The main benefit is to smooth out the new user experience for new
Fedora Linux installations. In particular, we can deal with a
long-standing sticking point that Anaconda remains installed on the
user's machine when it is not useful to do so.

== Scope ==
* Proposal owners:
** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
** Add a preset to {{package|fedora-release}} for
fedora-autofirstboot.service

* Other developers: N/A (not needed for this Change)

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


== Upgrade/compatibility impact ==
This will have no impact on upgraded systems, since the firstboot
condition is not true in that case.


== How To Test ==

# Install Fedora Workstation, KDE, etc.
# Reboot into installed environment
# Check to see openh264 is installed and
anaconda-core is not.

== User Experience ==
The first boot will be slightly slower because of these tasks running,
though they should happily run in the background as other services
start up, so it should not be noticeable.

== Dependencies ==
The main dependency is {{package|fedora-release}}, though we will need
to ensure all {{package|udisks2}} plugins get pulled in as
dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
they don't get uninstalled when Anaconda is.


== Contingency Plan ==
* Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
the kickstarts
* Contingency deadline: Final freeze
* Blocks release? No


== Documentation ==
There is not currently much documentation in
[https://pagure.io/fedora-autofirstboot the upstream project], though
contributions are welcome.

== Release Notes ==
Fedora Linux now ships with a framework for setting up first-boot
services and uses this to install multimedia software and remove the
installer software from the system after installation.

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

F38 proposal: LLVM 16 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LLVM-16

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Update all llvm sub-projects in Fedora Linux to version 16.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 16, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang15 and llvm15 will be added to ensure that
packages that currently depend on clang and llvm version 15 libraries
will continue to work.

In addition, the default LTO mode for Fedora packages compiling with
clang will be changed from "Full LTO" to "Thin LTO".  "Thin LTO" uses
much less compiler resources than "Full LTO", and is better tested and
supported by upstream.  Note that this will not be a change to clang
itself, but rather a change to the compiler flags for clang in
redhat-rpm-config.


== Benefit to Fedora ==

New features and bug fixes provided by the latest version of LLVM.

== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Build release candidates into @fedora-llvm-team/llvm16 COPR.
** Build final release (March 2023) into Rawhide and F38 branches.


* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang15 and llvm15
compatibility packages if they want to rebuild their package and it
does not work with LLVM 16 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
16 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.


* Release engineering: [https://pagure.io/releng/issues/11150]

* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==


== How To Test ==


== User Experience ==


== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 15 will need to
update their spec file on their first rebuild after this change.


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?)  Contingency
mechanism: (What to do? Who will do it?): If there are major problems
with LLVM 16, the compatibility package provide a way for other
packages to continue using LLVM 15.
* Contingency deadline: Final Freeze
* Blocks release? No

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 16:

llvm
clang
lld
lldb
compiler-rt
libomp
llvm-test-suite
libcxx
libcxxabi
python-lit
flang
mlir
polly
libclc
llvm-unwind
llvm-bolt


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

F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Add {{package|fedora-autofirstboot}} to desktop variants to run a
predetermined set of tasks on first boot after post installation,
notably installing codecs and cleaning up installer packages from the
installed system.

== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngomp...@gmail.com


== Detailed Description ==
{{package|fedora-autofirstboot}} is a collection of scripts that
invoke on firstboot of a freshly installed system to run a set of
predetermined tasks. It also provides a framework for third-parties to
introduce their own firstboot tasks to run through this framework. The
initial services included are to install OpenH264 and remove Anaconda.


== Benefit to Fedora ==
The main benefit is to smooth out the new user experience for new
Fedora Linux installations. In particular, we can deal with a
long-standing sticking point that Anaconda remains installed on the
user's machine when it is not useful to do so.

== Scope ==
* Proposal owners:
** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
** Add a preset to {{package|fedora-release}} for
fedora-autofirstboot.service

* Other developers: N/A (not needed for this Change)

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


== Upgrade/compatibility impact ==
This will have no impact on upgraded systems, since the firstboot
condition is not true in that case.


== How To Test ==

# Install Fedora Workstation, KDE, etc.
# Reboot into installed environment
# Check to see openh264 is installed and
anaconda-core is not.

== User Experience ==
The first boot will be slightly slower because of these tasks running,
though they should happily run in the background as other services
start up, so it should not be noticeable.

== Dependencies ==
The main dependency is {{package|fedora-release}}, though we will need
to ensure all {{package|udisks2}} plugins get pulled in as
dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
they don't get uninstalled when Anaconda is.


== Contingency Plan ==
* Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
the kickstarts
* Contingency deadline: Final freeze
* Blocks release? No


== Documentation ==
There is not currently much documentation in
[https://pagure.io/fedora-autofirstboot the upstream project], though
contributions are welcome.

== Release Notes ==
Fedora Linux now ships with a framework for setting up first-boot
services and uses this to install multimedia software and remove the
installer software from the system after installation.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F38 proposal: LLVM 16 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LLVM-16

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Update all llvm sub-projects in Fedora Linux to version 16.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 16, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang15 and llvm15 will be added to ensure that
packages that currently depend on clang and llvm version 15 libraries
will continue to work.

In addition, the default LTO mode for Fedora packages compiling with
clang will be changed from "Full LTO" to "Thin LTO".  "Thin LTO" uses
much less compiler resources than "Full LTO", and is better tested and
supported by upstream.  Note that this will not be a change to clang
itself, but rather a change to the compiler flags for clang in
redhat-rpm-config.


== Benefit to Fedora ==

New features and bug fixes provided by the latest version of LLVM.

== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Build release candidates into @fedora-llvm-team/llvm16 COPR.
** Build final release (March 2023) into Rawhide and F38 branches.


* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang15 and llvm15
compatibility packages if they want to rebuild their package and it
does not work with LLVM 16 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
16 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.


* Release engineering: [https://pagure.io/releng/issues/11150]

* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==


== How To Test ==


== User Experience ==


== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 15 will need to
update their spec file on their first rebuild after this change.


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?)  Contingency
mechanism: (What to do? Who will do it?): If there are major problems
with LLVM 16, the compatibility package provide a way for other
packages to continue using LLVM 15.
* Contingency deadline: Final Freeze
* Blocks release? No

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 16:

llvm
clang
lld
lldb
compiler-rt
libomp
llvm-test-suite
libcxx
libcxxabi
python-lit
flang
mlir
polly
libclc
llvm-unwind
llvm-bolt


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Kevin Fenzi]

On Wed, Nov 23, 2022 at 05:44:01PM +, Daniel P. Berrangé wrote:
> 
> The mitigation/successor strategy is to have comaintainers for every
> package.
> 
> Unfortunately our tools enforce the notion of a "main admin" and
> if that person leaves that role has to be given to another
> comaintainer explicitly.

Thats due to bugzilla really. bugzilla only supports assigning a bug to
1 account. ;( 

> IMHO we would be better off eliminating the notion of 'main admin'
> entirely and have all co-maintainers be at the equal level, so there
> is no need for a dance to give packages to comaintainers. There
> should only be manual action needed if the last comaintainer quits.

+100

> A workaround for the 'main admin' problem is to have a robot account
> as the 'main admin' and all the real people as merely 'admin', so
> the main admin never leaves, but that's a bit tedious to setup.

I agree, but it would be a good deal of work to switch to.

I'd definitely like to do this when/if we move away from bugzilla.

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

spin-kickstarts package

[Kevin Fenzi]

Greetings everyone. 

So, we used to have a release requirement that we package up and release
along side the release a spin-kickstarts rpm package with the current
kickstarts used for that release. 

This resulted in a bunch of last minute scrambling and blockers, and
even then, we often pushed fixes after release and people would get the
out of date one in the package and get confused. 

So, we changed that requirement, but then since there was no
requirement, we haven't really been updating the rpm much. 
(see https://bugzilla.redhat.com/show_bug.cgi?id=2144207 )

I'd like to just retire the rpm package and point folks to the git repo.
I think this will get people up to date versions of things,
and avoid pointlessly updating a package. 

Anyone have any arguments to save the rpm version?
Or shall I just retire it/update docs?

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

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Steven A. Falco]

On 11/23/22 12:58 PM, Steven A. Falco wrote:

On 11/23/22 12:23 PM, Scott Talbert wrote:

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is 
currently built with OpenGL EGL support) and several package users which are 
expecting OpenGL GLX support, I need to rebuild wxWidgets with a different 
configuration option.  Unfortunately, this results in an ABI change, so all 
packages that link with libwx_gtk3u_gl-3.2.so.0 need to be rebuilt.  
Unfortunately #2, this also needs to be done in F37.  I've opened two side tags 
to do the rebuilds for F37 and F38.

F37: f37-build-side-60200
F38: f38-build-side-60198


Builds for kicad started:

f37: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463878
f38: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463846


The kicad builds failed.  Here is a link to one of the build logs: 
https://kojipkgs.fedoraproject.org//work/tasks/4020/94464020/build.log

The errors start around line 1846 in that log.  Apparently I'll need to remove 
the EGL flag and try again.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

A very brief introduction.

[Jaime Andres Torres Bermejo]

Hello there, i'm Jaime Andres Torres Bermejo, and i'm currently a student
in Colombia (My current time zone is UTC -5, as a result), and i'm
currently trying to find places where i could help in fedora, this being my
first sent contact. My previous experiences with python include being able
to teach it as part of Stanford's CS Bridge program and also being involved
in the development of robotics projects on it, mostly concerning computer
vision. Besides this, i've also worked on a few integrations between C++
and Python for Robotics, but either way, i'm interested in contributing to
Fedora's integration with Python. Package Management and Review seems
interesting, however i'm up for recommendations of what kind of work is
there to do, if there's anything that comes up, please let me know.

Best regards,

Jaime Andres Torres.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Steven A. Falco]

On 11/23/22 12:23 PM, Scott Talbert wrote:

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is 
currently built with OpenGL EGL support) and several package users which are 
expecting OpenGL GLX support, I need to rebuild wxWidgets with a different 
configuration option.  Unfortunately, this results in an ABI change, so all 
packages that link with libwx_gtk3u_gl-3.2.so.0 need to be rebuilt.  
Unfortunately #2, this also needs to be done in F37.  I've opened two side tags 
to do the rebuilds for F37 and F38.

F37: f37-build-side-60200
F38: f38-build-side-60198


Builds for kicad started:

f37: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463878
f38: https://koji.fedoraproject.org/koji/taskinfo?taskID=94463846

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Daniel P . Berrangé]

On Wed, Nov 23, 2022 at 01:20:24PM +0100, Ralf Corsépius wrote:
> 
> 
> Am 23.11.22 um 12:20 schrieb Miro Hrončok:
> > Hello.
> > 
> > Based on my conversation with Fridolín Pokorný @fpokorny, I've removed
> > them from their Fedora packages.
> > 
> > They left Red Hat and are no longer interested in maintaining Fedora
> > packages.
> 
> I am wondering, why Red Hat/FESCO/... still hasn't found some "formal"
> successor regulations/proceedures to migitate such cases, provided they have
> happened many times before, in all the years, Fedora is around?

The mitigation/successor strategy is to have comaintainers for every
package.

Unfortunately our tools enforce the notion of a "main admin" and
if that person leaves that role has to be given to another
comaintainer explicitly.

IMHO we would be better off eliminating the notion of 'main admin'
entirely and have all co-maintainers be at the equal level, so there
is no need for a dance to give packages to comaintainers. There
should only be manual action needed if the last comaintainer quits.

A workaround for the 'main admin' problem is to have a robot account
as the 'main admin' and all the real people as merely 'admin', so
the main admin never leaves, but that's a bit tedious to setup.

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

Fedora CoreOS Meeting Minutes 2022-11-23

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-23/fedora_coreos_meeting.2022-11-23-16.29.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-23/fedora_coreos_meeting.2022-11-23-16.29.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-23/fedora_coreos_meeting.2022-11-23-16.29.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:29:39 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-23/fedora_coreos_meeting.2022-11-23-16.29.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:29:45)

* Action items from last meeting   (dustymabe, 16:32:34)

* FOSDEM 2023: Image Based Linux dev room  (dustymabe, 16:32:55)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1348
(dustymabe, 16:32:59)

* amd-gpu-firmware no longer being installed between stable to testing
  (dustymabe, 16:36:24)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1345
(dustymabe, 16:36:29)
  * AGREED: we will add the amd-gpu-firmware intel-gpu-firmware
nvidia-gpu-firmware packages back to FCOS to restore the previous
functionality we had and open a new ticket to discuss the merits of
these packages and if we ever want to remove them in the future.
(dustymabe, 16:57:09)

* open floor  (dustymabe, 16:58:27)
  * LINK:
https://fedoraproject.org/wiki/Changes/Linux_Firmware_Minimization
(travier, 17:00:36)
  * LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=2089044
> I can see them here indeed  (travier, 17:01:32)
  * LINK:

https://src.fedoraproject.org/rpms/linux-firmware/blob/rawhide/f/linux-firmware.spec#_23
(travier, 17:02:29)
  * LINK:

https://github.com/coreos/fedora-coreos-config/pull/2083#issuecomment-1312052842
(dustymabe, 17:08:55)

Meeting ended at 17:22:11 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (82)
* travier (54)
* jlebon (31)
* zodbot (21)
* anthr76[m] (20)
* fifofonix (3)
* c4rt0 (2)
* walters (1)
* mnguyen (1)
* ravanelli (1)
* lorbus (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Scott Talbert]

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is 
currently built with OpenGL EGL support) and several package users which 
are expecting OpenGL GLX support, I need to rebuild wxWidgets with a 
different configuration option.  Unfortunately, this results in an ABI 
change, so all packages that link with libwx_gtk3u_gl-3.2.so.0 need to be 
rebuilt.  Unfortunately #2, this also needs to be done in F37.  I've 
opened two side tags to do the rebuilds for F37 and F38.


F37: f37-build-side-60200
F38: f38-build-side-60198

The following packages need to be rebuilt in the above side tags (note, 
I've already taken care of python-wxpython4 and CubicSDR, which are also 
affected):


0ad
OpenSceneGraph
erlang
hugin
kicad
mrpt
panoglview
visualboyadvance-m
wxmacmolplt

If the maintainers of those packages could rebuild their packages in both 
of the above side tags, it would be creatly appreciated.  After a week, 
I'll flag down a provenpackager to assist with the rest.


Thanks,
Scott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: %{bash_completions_dir} or %{%bash_completion_dir} what is the correct macro ?

[Todd Zullinger]

Sérgio Basto wrote:
> I fully agree with this commit, maybe you can go ahead with an official
> PR.

Done, thanks!

EPEL8 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/57
EPEL7 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/58

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Jan Chaloupka]

Hi Robert-André,

Checking the consul it looks like I need to create a ticket for all orphaned 
package to change their point of contact. Assuming the same holds for all other 
orphaned packages one ticket with request to change their PoC is more practical 
than creating one for each. Feel free to open the ticket. I will give my +1 
wherever needed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update: Porting to Modern C

[Richard W.M. Jones]

On Wed, Nov 23, 2022 at 04:48:08PM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> > Quite hard to scan this list without having maintainer names,
> 
> What's the name of the script that does the mapping?  In Debian it's
> called dd-list, but I can't find the Fedora equivalent.

find-package-maintainers from:
https://pagure.io/fedora-misc-package-utilities/tree/master

> > but I would just comment that:
> >
> >> mingw-gcc
> >
> > ... this is just GCC with different compilation options, and hopefully
> > GCC maintainers know about this :-)  GCC 12.2.1 at time of writing.
> 
> Yes, I have some patches to backport to GCC 12 upstream.  I had to fix
> these issues for building the instrumented GCC itself. 8->

It'll get updated to the newer version of GCC (to synch with GCC in
Rawhide) after a while.

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

Re: Update: Porting to Modern C

[Florian Weimer]

* Richard W. M. Jones:

> Quite hard to scan this list without having maintainer names,

What's the name of the script that does the mapping?  In Debian it's
called dd-list, but I can't find the Fedora equivalent.

> but I would just comment that:
>
>> mingw-gcc
>
> ... this is just GCC with different compilation options, and hopefully
> GCC maintainers know about this :-)  GCC 12.2.1 at time of writing.

Yes, I have some patches to backport to GCC 12 upstream.  I had to fix
these issues for building the instrumented GCC itself. 8->

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

Re: Update: Porting to Modern C

[Richard W.M. Jones]

On Mon, Nov 21, 2022 at 08:58:12AM +0100, Florian Weimer wrote:
> I'm still in the process of setting thigs up.  I've created a wiki page
> separately from the change proposal that documents some project
> procedures:
> 
>   
> 
> It has some instructions how to test things locally.  Thanks to Kevin's
> help, we should soon have a special buildroot in Koji which will be
> useful for testing as well.
> 
> The first pass will focus on implicit ints and implicit function
> declarations, simply because we have to start somewhere, and I've got an
> instrumented GCC for this.
> 
> Below, I'm listing packages which use implicit ints and call an
> undeclared “exit” function.  Detection is therefore extremely reliable.
> (In general, implicit function declarations are hard to detect because
> sometimes there are calls to functions from configure checks which are
> expected to be missing in Fedora, such as “getmntinfo”.  No such problem
> with “exit” or implicit ints, though.)  In the list, I have excluded
> issues that have already been fixed in rawhide, or for which I have
> filed help-needed Bugzilla bugs (I hope I haven't missed anything).
> 
> I'll try to capture the work we do in a tracking repository, so that
> other distributions can find it:
> 
>   
> 
> If you find something, please submit an MR to this repository.  (If we
> can make this repository or another one editable by Fedora packages,
> that would be fine, too.)
> 
> Thanks,
> Florian

Quite hard to scan this list without having maintainer names, but
I would just comment that:

> mingw-gcc

... this is just GCC with different compilation options, and hopefully
GCC maintainers know about this :-)  GCC 12.2.1 at time of writing.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2145192] New: perl-Mojolicious-9.30 is available

[bugzilla]

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

Bug ID: 2145192
   Summary: perl-Mojolicious-9.30 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mojolicious
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 9.30
Upstream release that is considered latest: 9.30
Current version/release in rawhide: 9.29-1.fc38
URL: https://metacpan.org/release/Mojolicious

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/5966/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Mojolicious


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2145192
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: %{bash_completions_dir} or %{%bash_completion_dir} what is the correct macro ?

[Sérgio Basto]

On Tue, 2022-11-22 at 20:55 -0500, Todd Zullinger wrote:
> Sérgio Basto wrote:
> > in an effort to do things correctly and without hacks
> > I noticed that redhat-rpm-config-202-1.fc35.noarch defines
> > %bash_completions_dir and epel-rpm-macros %defines
> > bash_completion_dir 
> > 
> > Which one is the correct ? hopefully we have a few case [1] (18) vs
> > [2]
> > (14) 
> > I think the bash_completions_dir is the right one ... , what is you
> > opinion ? 
> 
> I agree, for that's worth. :)
> 
> In EPEL, `bash_completion_dir` was added to epel-rpm-macros
> in 46557e2 (Add %bash_completion_dir., 2016-08-11) on the
> epel7 branch.  I don't know if there is any corresponding
> list discussion of that change, but I didn't spend any time
> searching outside of Git and Pagure.  The commit message
> doesn't reference any ticket or discussion.
> 
> The change was copied into the epel8 and epel9 branches when
> they were initialized.
> 
> In Fedora, `bash_completions_dir` was added to
> redhat-rpm-config in 483a3b8 (Add macros.shell-completions,
> 2022-06-25), per PR#206¹.
> 
> Subsequently, this change was made for EPEL on the epel9
> branch in c212ede (Backport macros.shell-completions from
> Fedora, 2022-09-01), via PR#49².
> 
> While the non-plural form in EPEL predates what is in
> Fedora, I think that the plural form as used in Fedora and
> EPEL-9 would be best going forward.  That just requires
> adding macros.shell-completions to the epel7³ and epel8⁴
> branches of epel-rpm-macros.  (I didn't test the changes, I
> only prepared them to get a start on the work if that
> direction is desirable.)
> 
> The existing `bash_completion_dir` could be changed to point
> to `bash_completions_dir` to avoid breaking any users of it
> while also making it clearer to folks reading the macros
> files which is the preferred spelling.
> 
> ¹
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/206
> ² https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/49
> ³
> https://src.fedoraproject.org/fork/tmz/rpms/epel-rpm-macros/c/9c7b88b
> ⁴
> https://src.fedoraproject.org/fork/tmz/rpms/epel-rpm-macros/c/dc9df62
> 

I fully agree with this commit, maybe you can go ahead with an official
PR.


Thank you,
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Future of BIOS RAID support in the installer

[Vojtech Trefny]

Hi, I am planning to change how we support BIOS RAID (sometimes also
called Firmware or Fake RAID) in the installer in the future. I plan
to go through the official Fedora change process for Fedora 38, but
I'd like to get some feedback first.

We are currently using dmraid to support these types of RAIDs in
blivet[1] (storage library the Anaconda installer uses) and we would
like to replace it with mdadm. The main reason is that dmraid is no
longer actively maintained, but it will also mean one less dependency
for the installer (we use mdadm for the software RAID support) and one
less service running during boot (dmraid-activation.service).

The potential issue here is that mdadm doesn't support all BIOS RAID
types. mdadm supports only Common RAID Disk Data Format standard[2]
(DDF) and Intel Matrix Storage Technology (IMSM) so by switching to
mdadm we would remove support for some of the older formats that
existed before DDF was standardized. I am not sure how many people are
still using these older RAIDs and the main reason for sending this
email is to find out. So if you are using a BIOS RAID on your system,
can you check what kind? You can find out simply by checking the
filesystem type on the underlying disk(s) reported by for example
`lsblk -f`. Types supported by mdadm are "ddf_raid_member" and
"isw_raid_member". Types supported only by dmraid are
"adaptec_raid_member", "hpt***_raid_member", "jmicron_raid_member",
"lsi_mega_raid_member", "nvidia_raid_member",
"silicon_medley_raid_member" and "via_raid_member". So if you have one
of the latter ones and you'd be impacted by this change, please let me
know so we can reconsider this change. Note that this would affect
only the installation process, I know some external and NAS drives use
BIOS RAID and these won't be affected, dmraid is not being removed
from the repositories (at least I am not aware of this right now, some
distributions are already planning to remove dmraid completely).

[1] https://github.com/storaged-project/blivet
[2] https://www.snia.org/tech_activities/standards/curr_standards/ddf

Regards

Vojtech Trefny
vtre...@redhat.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Ralf Corsépius]

Am 23.11.22 um 12:20 schrieb Miro Hrončok:

Hello.

Based on my conversation with Fridolín Pokorný @fpokorny, I've removed 
them from their Fedora packages.


They left Red Hat and are no longer interested in maintaining Fedora 
packages.


I am wondering, why Red Hat/FESCO/... still hasn't found some "formal" 
successor regulations/proceedures to migitate such cases, provided they 
have happened many times before, in all the years, Fedora is around?


Ralf

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: zdohnal pushed to tests/vim (main). "upstream-unittests: Apply RPM workaround for package notes from Ruby (..more)"

[Mamoru TASAKA]

notificati...@fedoraproject.org wrote on 2022/11/23 20:34:

Notification time stamped 2022-11-23 11:34:19 UTC

 From 1f016e5dedbb5bc7293c1638e1238989d6fabaa5 Mon Sep 17 00:00:00 2001
From: Zdenek Dohnal 
Date: Nov 23 2022 11:30:01 +
Subject: upstream-unittests: Apply RPM workaround for package notes from Ruby


Vim adds Ruby LDFLAGS during configuration, which (due Ruby's decision
to embed flags from the building time) contains flags from buildsystem
environment, especially package notes. This flag expects additional
environment variables to be set and they aren't set in normal
environment.

I've reported it to Vim upstream with PR which removes Ruby LDFLAGS from
configure script https://github.com/vim/vim/pull/11592 .



And ruby (on rawhide for now) removed package_notes again because
currently non-rpmbuild build is broken with embedded package_notes flag:

https://src.fedoraproject.org/rpms/ruby/c/1d0c071aebd50621eb049a2ab8d20da3133f9f16
https://bugzilla.redhat.com/show_bug.cgi?id=2142119
https://bugzilla.redhat.com/show_bug.cgi?id=2043092

Regards,
Mamoru



---

diff --git a/Sanity/upstream-unittests/runtest.sh 
b/Sanity/upstream-unittests/runtest.sh
index 1919bd4..6f22812 100755
--- a/Sanity/upstream-unittests/runtest.sh
+++ b/Sanity/upstream-unittests/runtest.sh
@@ -70,6 +70,10 @@ rlJournalStart
  rlRun "RUBY_CFLAGS='`ruby -r rbconfig -e "puts RbConfig::CONFIG['CFLAGS']"`'" 0 
"Get ruby CFLAGS"
  rlRun "export CFLAGS='$RUBY_CFLAGS'"  0 
"Set ruby CFLAGS"
  
+# newer redhat-rpm-config brings in packager-notes script, which breaks LDFLAGS we get from Ruby

+# we need to set several env variable randomly to get configure 
working again...
+rlRun "RPM_WORKAROUND='RPM_ARCH=\"x86_64\" RPM_PACKAGE_RELEASE=\"1\" 
RPM_PACKAGE_VERSION=\"1\" RPM_PACKAGE_NAME=\"vim\"'"
+
  # show relevant info & ENV variables
  rlLog "TEST:   $TEST"
  rlLog "CONFOPT:$CONFOPT"
@@ -85,8 +89,8 @@ rlJournalStart
  rlRun "TERM=$TERM_type"
  
  # following block of code is taken from upstream travis.yml

-rlRun "su $TESTER -c './configure ${CONFOPT} CFLAGS=\"${CFLAGS} $RUBY_FLAGS\"'" 
0 "Configure Vim"
-rlRun "su $TESTER -c 'make'" 0 "Build the binary which we substitute"
+rlRun "su $TESTER -c './configure ${CONFOPT} CFLAGS=\"${CFLAGS} $RUBY_FLAGS\" 
$RPM_WORKAROUND'" 0 "Configure Vim"
+rlRun "su $TESTER -c '$RPM_WORKAROUND make'" 0 "Build the binary which we 
substitute"
  rlRun "su $TESTER -c 'ln -sf /usr/bin/vim  src/vim'"0   "Create 
symlink to installed vim for testing"
  rlRun "su $TESTER -c 'make ${TEST} |& tee output'" 0,2 "Run tests (skip 
builtin terminal errors)"
  _res_=$?



https://src.fedoraproject.org/tests/vim/c/1f016e5dedbb5bc7293c1638e1238989d6fabaa5?branch=main
___
scm-commits mailing list -- scm-comm...@lists.fedoraproject.org
To unsubscribe send an email to scm-commits-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/scm-comm...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Miro Hrončok]

On 23. 11. 22 13:03, Miro Hrončok wrote:
Also jchaloup is also out of the picture, could you see with him for 
orphaning is golang packages too?


I can try.


I do not think they left Red Hat.

If you want, you can follow the nonresponsive packager policy or email them 
yourself on their email address in FAS.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Miro Hrončok]

On 23. 11. 22 12:45, Bob Mauchin wrote:



On Wed, 23 Nov 2022, 12:21 Miro Hrončok, > wrote:


Hello.

Based on my conversation with Fridolín Pokorný @fpokorny, I've removed them
from their Fedora packages.

They left Red Hat and are no longer interested in maintaining Fedora 
packages.

Co-maintainers BCC'ed.

fpokorny is main admin of rpms/consul
    rpms/consul co-maintainers: @jchaloup
    fpokorny is no longer the main admin of rpms/consul...



Hi,

Is there a way to assign them all to me? I'm already taking of them with the 
sig.


In progress.

I've skipped "consul" as it is not named golang-. If you actually wanted it 
too, take it manually please.


Also jchaloup is also out of the picture, could you see with him for orphaning 
is golang packages too?


I can try.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Bob Mauchin]

On Wed, 23 Nov 2022, 12:21 Miro Hrončok,  wrote:

> Hello.
>
> Based on my conversation with Fridolín Pokorný @fpokorny, I've removed
> them
> from their Fedora packages.
>
> They left Red Hat and are no longer interested in maintaining Fedora
> packages.
>
> Co-maintainers BCC'ed.
>
> fpokorny is main admin of rpms/consul
>rpms/consul co-maintainers: @jchaloup
>fpokorny is no longer the main admin of rpms/consul
> fpokorny has a bugzilla override on rpms/consul
>fpokorny has no longer a bugzilla overrides on rpms/consul
> fpokorny is maintainer of rpms/docker-machine
>fpokorny is no longer maintaining rpms/docker-machine
>fpokorny is no longer watching rpms/docker-machine
> fpokorny is maintainer of rpms/docker-swarm
>fpokorny is no longer maintaining rpms/docker-swarm
>fpokorny is no longer watching rpms/docker-swarm
> fpokorny is watching rpms/gawk
>fpokorny is no longer watching rpms/gawk
> fpokorny is maintainer of rpms/go-compilers
>fpokorny is no longer maintaining rpms/go-compilers
>fpokorny is no longer watching rpms/go-compilers
> fpokorny is main admin of rpms/golang-bitbucket-kardianos-osext
>rpms/golang-bitbucket-kardianos-osext co-maintainers: @jchaloup,
> @maxamillion, @tdawson, @vbatts
>fpokorny is no longer the main admin of
> rpms/golang-bitbucket-kardianos-osext
> fpokorny is main admin of rpms/golang-bitbucket-ww-goautoneg
>rpms/golang-bitbucket-ww-goautoneg co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-bitbucket-ww-goautoneg
> fpokorny is watching rpms/golang-github-10gen-openssl
>fpokorny is no longer watching rpms/golang-github-10gen-openssl
> fpokorny is main admin of rpms/golang-github-AdRoll-goamz
>rpms/golang-github-AdRoll-goamz co-maintainers: @jchaloup
>fpokorny is no longer the main admin of rpms/golang-github-AdRoll-goamz
> fpokorny is main admin of rpms/golang-github-Azure-azure-sdk-for-go
>rpms/golang-github-Azure-azure-sdk-for-go co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-Azure-azure-sdk-for-go
> fpokorny is main admin of rpms/golang-github-BurntSushi-toml
>rpms/golang-github-BurntSushi-toml co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-BurntSushi-toml
> fpokorny is main admin of rpms/golang-github-DATA-DOG-go-sqlmock
>rpms/golang-github-DATA-DOG-go-sqlmock co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-DATA-DOG-go-sqlmock
> fpokorny is maintainer of rpms/golang-github-DataDog-datadog-go
>fpokorny is no longer maintaining rpms/golang-github-DataDog-datadog-go
>fpokorny is no longer watching rpms/golang-github-DataDog-datadog-go
> fpokorny is main admin of rpms/golang-github-MakeNowJust-heredoc
>rpms/golang-github-MakeNowJust-heredoc co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-MakeNowJust-heredoc
> fpokorny is main admin of rpms/golang-github-RangelReale-osin
>rpms/golang-github-RangelReale-osin co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-RangelReale-osin
> fpokorny is main admin of rpms/golang-github-RangelReale-osincli
>rpms/golang-github-RangelReale-osincli co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-RangelReale-osincli
> fpokorny is main admin of rpms/golang-github-SeanDolphin-bqschema
>rpms/golang-github-SeanDolphin-bqschema co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-SeanDolphin-bqschema
> fpokorny is main admin of rpms/golang-github-Sirupsen-logrus
>rpms/golang-github-Sirupsen-logrus co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-Sirupsen-logrus
> fpokorny is main admin of rpms/golang-github-abbot-go-http-auth
>rpms/golang-github-abbot-go-http-auth co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-abbot-go-http-auth
> fpokorny is main admin of rpms/golang-github-agl-ed25519
>rpms/golang-github-agl-ed25519 co-maintainers: @jchaloup
>fpokorny is no longer the main admin of rpms/golang-github-agl-ed25519
> fpokorny is main admin of rpms/golang-github-appc-spec
>rpms/golang-github-appc-spec co-maintainers: @jchaloup
>fpokorny is no longer the main admin of rpms/golang-github-appc-spec
> fpokorny is main admin of rpms/golang-github-armon-circbuf
>rpms/golang-github-armon-circbuf co-maintainers: @jchaloup
>fpokorny is no longer the main admin of rpms/golang-github-armon-circbuf
> fpokorny is main admin of rpms/golang-github-armon-go-metrics
>rpms/golang-github-armon-go-metrics co-maintainers: @jchaloup
>fpokorny is no longer the main admin of
> rpms/golang-github-armon-go-metrics
> fpokorny is main admin of rpms/golang-github-armon-go-radix
>rpms/golang-github-armon-go-radix 

Orphaned a lot of (mostly) Go packages owned by @fpokorny

[Miro Hrončok]

Hello.

Based on my conversation with Fridolín Pokorný @fpokorny, I've removed them 
from their Fedora packages.


They left Red Hat and are no longer interested in maintaining Fedora packages.

Co-maintainers BCC'ed.

fpokorny is main admin of rpms/consul
  rpms/consul co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/consul
fpokorny has a bugzilla override on rpms/consul
  fpokorny has no longer a bugzilla overrides on rpms/consul
fpokorny is maintainer of rpms/docker-machine
  fpokorny is no longer maintaining rpms/docker-machine
  fpokorny is no longer watching rpms/docker-machine
fpokorny is maintainer of rpms/docker-swarm
  fpokorny is no longer maintaining rpms/docker-swarm
  fpokorny is no longer watching rpms/docker-swarm
fpokorny is watching rpms/gawk
  fpokorny is no longer watching rpms/gawk
fpokorny is maintainer of rpms/go-compilers
  fpokorny is no longer maintaining rpms/go-compilers
  fpokorny is no longer watching rpms/go-compilers
fpokorny is main admin of rpms/golang-bitbucket-kardianos-osext
  rpms/golang-bitbucket-kardianos-osext co-maintainers: @jchaloup, 
@maxamillion, @tdawson, @vbatts

  fpokorny is no longer the main admin of rpms/golang-bitbucket-kardianos-osext
fpokorny is main admin of rpms/golang-bitbucket-ww-goautoneg
  rpms/golang-bitbucket-ww-goautoneg co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-bitbucket-ww-goautoneg
fpokorny is watching rpms/golang-github-10gen-openssl
  fpokorny is no longer watching rpms/golang-github-10gen-openssl
fpokorny is main admin of rpms/golang-github-AdRoll-goamz
  rpms/golang-github-AdRoll-goamz co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-AdRoll-goamz
fpokorny is main admin of rpms/golang-github-Azure-azure-sdk-for-go
  rpms/golang-github-Azure-azure-sdk-for-go co-maintainers: @jchaloup
  fpokorny is no longer the main admin of 
rpms/golang-github-Azure-azure-sdk-for-go

fpokorny is main admin of rpms/golang-github-BurntSushi-toml
  rpms/golang-github-BurntSushi-toml co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-BurntSushi-toml
fpokorny is main admin of rpms/golang-github-DATA-DOG-go-sqlmock
  rpms/golang-github-DATA-DOG-go-sqlmock co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-DATA-DOG-go-sqlmock
fpokorny is maintainer of rpms/golang-github-DataDog-datadog-go
  fpokorny is no longer maintaining rpms/golang-github-DataDog-datadog-go
  fpokorny is no longer watching rpms/golang-github-DataDog-datadog-go
fpokorny is main admin of rpms/golang-github-MakeNowJust-heredoc
  rpms/golang-github-MakeNowJust-heredoc co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-MakeNowJust-heredoc
fpokorny is main admin of rpms/golang-github-RangelReale-osin
  rpms/golang-github-RangelReale-osin co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-RangelReale-osin
fpokorny is main admin of rpms/golang-github-RangelReale-osincli
  rpms/golang-github-RangelReale-osincli co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-RangelReale-osincli
fpokorny is main admin of rpms/golang-github-SeanDolphin-bqschema
  rpms/golang-github-SeanDolphin-bqschema co-maintainers: @jchaloup
  fpokorny is no longer the main admin of 
rpms/golang-github-SeanDolphin-bqschema
fpokorny is main admin of rpms/golang-github-Sirupsen-logrus
  rpms/golang-github-Sirupsen-logrus co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-Sirupsen-logrus
fpokorny is main admin of rpms/golang-github-abbot-go-http-auth
  rpms/golang-github-abbot-go-http-auth co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-abbot-go-http-auth
fpokorny is main admin of rpms/golang-github-agl-ed25519
  rpms/golang-github-agl-ed25519 co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-agl-ed25519
fpokorny is main admin of rpms/golang-github-appc-spec
  rpms/golang-github-appc-spec co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-appc-spec
fpokorny is main admin of rpms/golang-github-armon-circbuf
  rpms/golang-github-armon-circbuf co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-armon-circbuf
fpokorny is main admin of rpms/golang-github-armon-go-metrics
  rpms/golang-github-armon-go-metrics co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-armon-go-metrics
fpokorny is main admin of rpms/golang-github-armon-go-radix
  rpms/golang-github-armon-go-radix co-maintainers: @jchaloup
  fpokorny is no longer the main admin of rpms/golang-github-armon-go-radix
fpokorny is main admin of rpms/golang-github-armon-gomdb
  rpms/golang-github-armon-gomdb co-maintainers: @jchaloup
  fpokorny is no longer the main admin of 

[rpms/perl-Convert-BER] PR #1: Package tests and update license to SPDX format

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-Convert-BER` that you 
are following.

Merged pull-request:

``
Package tests and update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Convert-BER/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Jaroslav Mracek]

> Dne 25. 10. 22 v 14:00 Jaroslav Mracek napsal(a):
> 
> 
> That is nice, but honestly who reads man pages? And especially who reads 
> man pages of SW they are not using (assuming that the manpage will be 
> part of DNF5 and not DNF).

Thank you for very much for a good point. We already played with this topic for 
DNF but that game was primary focused for RHEL and required by RHEL, therefore 
it was delivered to Fedora after many users already accepted DNF. If you type 
`man yum` you will get man pages for DNF with note that ` yum - redirecting to 
DNF Command Reference`. I think that this kind of approach can be used also for 
DNF5. You can also try `yum --help` and you will see `usage: yum [options] 
COMMAND`. Please all of those examples requires `yum` package installed.

> 
> I understand that deprecation warning has their own issues, but if you 
> already put some thoughts into that topic, I'd like you to elaborate 
> more then just provide statements like above.

DNF in early versions (1.1) provided a warning when `yum` was called. It was 
nice and transparent way how to send a message about redirection to DNF, but we 
got very strong negative feedback about that, therefore we removed it. I don't 
think we should repeat that approach. Personally I don't feel comfortable with 
education of our users using warnings, because they have value at first 
occurrence but then they are annoying.

> 
> 
> Vít

Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Convert-BER] PR #1: Package tests and update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Convert-BER` that 
you are following:
``
Package tests and update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Convert-BER/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

New Anaconda Web UI preview image is public -- looking for feedback!

[Jiri Konecny]

Hi everyone,

We are excited to announce that Anaconda Web UI preview image mentioned 
by Fedora change[0] is now public for testing and providing feedback.


You can find more information here:

https://fedoramagazine.org/anaconda-web-ui-preview-image-now-public

Feel free to download the ISO, test it and please provide us feedback as 
written in the article.


Please note, we are now fixing size of the ISO (it has 7 GB because of 
the problem with a build of ISO), hopefully it should be resolved soon.


Best Regards,
Jirka on behalf of the Anaconda team


[0]: https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FF 107.0 scratch builds - just for fun

[Vít Ondruch]

Dne 22. 11. 22 v 20:41 Adam Williamson napsal(a):

On Tue, 2022-11-22 at 12:48 +0100, Vít Ondruch wrote:

Would it be possible to develop a way to better manage updates of some
interconnected packages? FF + NSS would be one case, but when we are
doing Ruby on Rails update, it always involve more packages. Or probably
gcc + annobin are pair of packages which needs to always go together
(unless I am mistaken).

E.g. the build of NSS would automatically triggered side creation and
waited for updated FF.

well...there's always room for improvement, but it strikes me that
would be rather complicated. It's not the case that *every* rebuild of
NSS requires a rebuild of Firefox, so whatever is implementing this
would need to be quite smart to know when it's necessary and when it
isn't.



It could be just simple waiver.




Frankly, the existing tools are fine for the purpose. It is not hard to
create a side tag, nor to put builds in it. Multiple other maintainers
and teams manage this just fine, with much larger sets of packages: the
desktop and KDE teams both do this very well, all the time, with dozens
of packages.

Bluntly, I don't think there is really a tooling problem here, there is
a "getting the maintainers to understand the requirements and use the
tooling properly" problem.



Tooling can do this indeed. Unfortunately, sometimes the information 
about the tooling capabilities just does not reach the right people. 
Other times it is just silly mistake. I'm just thinking how to make it 
more robust.



Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Regular crash of the internal DirectoryServer389 replication

[Dip Barua]

Is the server crashing, or is replication not working?  There's a big
difference between the two.

If it's crashing please obtain a stack trace from the core file:

https://www.port389.org/docs/389ds/FAQ/faq.html#sts=Debugging%C2%A0Crashes

If it's just replication not working then we need a lot more
information.  Access logs, error logs with replication logging enabled,
and the replication agreements.

Look through your access log and track down what client is opening
conn=36614.  is this a replica or some other client?


The Replication is not working?  I mean there is the crash of Replications.


Below list of error are shown in the access logs :

[25/Oct/2022:02:03:15.698645866 +0200] - ERR - slapi_ldap_bind - Could not send 
bind
request for id [cn=Directory Manager] authentication mechanism [SIMPLE]: error 
-1
(Can't contact LDAP server), system error -5987 (Invalid function argument.), 
network
error 107 (Transport endpoint is not connected, host "myserver:389")

[25/Oct/2022:02:06:27.558971677 +0200] - INFO - NSMMReplicationPlugin - 
bind_and_check_pwp
- agmt="cn=lpfroot12" (wa2p:389): Replication bind with SIMPLE auth resumed

[25/Oct/2022:07:25:15.490236609 +0200] - ERR - log_ber_too_big_error - 
conn=36614 fd=78
Incoming BER Element may be misformed. This may indicate an attempt to use TLS 
on a
plaintext port, IE ldaps://localhost:389. Check your client's LDAP_URI settings.

[25/Oct/2022:12:10:07.709047940 +0200] - ERR - NSMMReplicationPlugin -
repl5_inc_waitfor_async_results - Timed out waiting for responses: 330754 330879


can you suggest to me exactly what I should look for when it is related to 
replication crashes?

Thanks in advance for your help. 






 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Building Python 3.12 with no-omit-frame-pointer

[Petr Viktorin]

On 22. 11. 22 18:30, Miro Hrončok wrote:

On 21. 11. 22 11:01, Petr Viktorin wrote:
And since the Python slowdown comes from a single weird function, I 
think that Fedora should ignore the Python benchmarks when evaluating 
the distro default -- and if Fedora switches to no-omit-frame-pointer, 
Python 3.11 should be an exception (to be re-evaluated for 3.12).


Do I interpret correctly?

If (and only if) Fedora switches to -fno-omit-frame-pointer, python3.11 
(and possibly older Pythons) will explicitly use -fomit-frame-pointer 
instead (aka opt-out).


Yes. If the change allows software to opt out (e.g. if it's slowed down 
too much), then, based on the benchmarks, Python 3.11 should do that.



python3.12 will do the same for now.


Or not, if that would help testing. I don't think the speed of the 
preview Python matters that much.


Once the massive changes to _PyEval_EvalFrameDefault land in Python 
3.12, we will re-evaluate whether to use -fomit-frame-pointer or 
-fno-omit-frame-pointer (regardless of the Fedora global flags).


That might not be a single point in time, so let's perhaps re-evaluate 
around Beta?

___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

How to choose paper for custom a baord book?

[chen mark]

What paper is used for printing board books? For many authors who are print 
their board books for the first time, most of them don't know use what kind of 
paper to print their board books. Combine with my years of board book printing 
experiences. Let us detail discuss this issue. In fact, in the board book 
printing field, the book printing factory and clients often choose below two 
types of paper to print the board books.

1. Two one side coated paper mounting together

Why use one side coated paper isn't use other types of paper to print board 
books? Because one side coated paper has below advantages. 

(1.) One side coated paper with high color reproduction

Whether the printing effect of single-sided coated paper is good or not. An 
important criterion is for judging whether its color reproduction is high. 
Because one side coated paper with special coated on the surface. Thus, one 
side coated paper can perfect print the image's original color, make which 
printing color are more lifelike. And more close to the color what we watch on 
the computer. So that to reduce chromatic aberration. Use one side costed paper 
to custom board book printing, it can make the pattern more bright, colorful, 
and looks more realized.

(2.) The thickness of one side coated paper is suitable

Because custom board book has a requirement for paper thickness. If the paper 
is too thick, it will increase the weight of the board book, and not be 
convenient to read. Then will decrease readers' interest in reading. But if the 
paper is too thin, when the children read the book, its paper is too light and 
not easier to flip the book. The paper is too thin, will make the book without 
good touching and decrease the grade of the book. But the one side coated paper 
can perfect solve this problem. Moreover, the hardness of one side coated paper 
is enough to make the paper stand up and more convenient for children to read. 
Thus, a suitable thickness of one side coated paper is more suitable for custom 
board book printing.

(3.) The price of one side coated paper is cheaper

We compare other types of paper. The price of one side coated paper is cheaper 
and the cost effective is high. One side coated paper can better solve the cost 
problem from board book printers and publishers. For the board book printers, 
custom the board book needs more paper than ordinary children's book, and the 
requirement of crafts skills are higher than other printing product. For 
publishers, one side coated paper can meet their color printing needs and save 
much cost. So most of the board book printers and publishers choose one side 
coated paper to do board book printing.

(4.) One side coated paper with high flatness, smoothness and whiteness

Because one side coated paper with high smoothness, flatness and brightness. 
Using it to custom board book is more suitable. When the children open the 
board book, good touching and attractive sight experience will bring them 
better reading experience.

(5.) One side coated paper with good ink adaptability

The ink adaptability of one side coated paper is good than offset paper. No 
matter does color printing or black and white printing, the printing effect of 
one side coated paper is very good. And it is not easier to fade. Board book 
often with a lot of pictures inside. We print the patterns on coated paper is 
more bright and realized. So when printing board books with one side coated 
paper, which printing effect is better than other paper.

2.Two one side coated paper mounting a gray board 

Apart from mounting two one side coated paper to custom board books. Some 
publishers will choose two one side coated paper mounting a gray board. To make 
the book look more thick and strong. But use two one side coated paper mounting 
a gray board to custom board books. The cost is higher than two one side coated 
paper mounting together. Only a bit of publishers are choosing this kind of 
paper.

If you don't know to choose the paper types or paper weight to print your own 
board book. Don't worry about that. BookPrintingChina has over 20 years of 
board book printing experiences. We provide various of custom board book 
printing services for you to choose from. Such as photo board book printing, 
custom board book with puzzle, pup up board book, etc. We had helped hundreds 
of self-publishers and publishers print their own board book and sell well in 
the book market. For your own board book printing, we can give you the optimal 
suggestion for paper types and paper weight. Now contact us to start your board 
book printing.
Article source: 
https://www.bookprintingchina.com/Blog/What-Paper-Is-Used-For-Printing-Board-Books
___
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: