Hello,
I maintain a small application hosted on GitHub. (https://github.com/darrylb123/usbrelay)
It allows control of USB connected electrical relays. Originally it was a simple command line application.
Over the years, it has accumulated additional features such as a python interface, and an mqtt daemon.
There is a debian package that has not been maintained for many years. We are endeavouring to fix that.
As a long term Fedora user, I would love to get it into Fedora. However I have never attempted to create an rpm package. The more I read, the more confused I am.
Questions on Issues like:
- How to clone the GitHub repository in the spec file
- should there be one package or a separate python package.
- what about the daemon/ systemd service...
Any help greatly appreciated
Darryl
Hi folks,
I want to add "intro to IMA signing" instructions to
https://docs.pagure.org/koji/signing/ . I wrote a basic PR at
https://pagure.io/koji/pull-request/3206 but it lacks technical
details.
- How do I generate my own new keypair so I can IMA-sign an RPM?
- Can I use my existing GPG keypair?
- How do I IMA-sign files in an RPM locally (apart from Koji)? (Is it
the --signfiles option from rpmsign(8)?)
- How do I inspect the IMA signatures on an existing RPM?
- When I gpg-sign an RPM with "Key A" and IMA-sign an RPM with "Key
B", does Koji "know" about Key B at all?
- Ken
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_7.0
== Summary ==
Ruby on Rails 7.0 is the latest version of well known web framework
written in Ruby.
== Owner ==
* Name: [[User:pvalena| Pavel Valena]], [[User:jprokop| Jarek Prokop]]
* Email: pvalena(a)redhat.com, jprokop(a)redhat.com,
ruby-sig(a)lists.fedoraproject.org
== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 6.1 in Fedora 35 to 7.0 (latest version) in Fedora 36.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.
== Benefit to Fedora ==
This update will keep Fedora up-to-date and will ensure that the
current Ruby on Rails developers stay with us as they will get support
for system-packaged Ruby on Rails of the latest version. Update to
Rails 7.0 contains hundreds of fixes and improvements across all the
frameworks. For new features, please see [#User_Experience User
Experience].
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated.
** Some dependencies of the Rails stack will need update.
=== Packages need to be created/updated ===
* Rails bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2032639 #2032639]
** Specific changes: (see wiki)
* Current development state can be observed in
[https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/
pvalena/ruby-on-rails] COPR repository.
** Current status: '''version 7.0.0''' built and tested
* Other developers: Update Rails dependent packages to be working with
Ruby on Rails 7.0
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Web applications build above Ruby on Rails framework might need to be
updated. Official upstream upgrade guide might come handy:
http://guides.rubyonrails.org/upgrading_ruby_on_rails.html
== How To Test ==
* No special hardware is needed.
* Some additional adjustments to dependencies are needed to start the
default app. Example:
** https://github.com/pvalena/theprototype/blob/main/rails/test.sh
=== To test only Rails itself ===
<pre>
dnf install rubygem-rails
rails new app
cd app && rails s
</pre>
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 7.0.x
=== To test the complete feature including generating a new Rails app
using RPM ===
<pre>
dnf group install 'Ruby on Rails'
rails new app --skip-bundle && cd app
rails s
</pre>
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 7.0.x
== User Experience ==
* New version of Ruby on Rails (7.0) available
* The most significant Rails 7.0 features:
** No-Node default approach to the front end
** Hotwire’s combination of Turbo and Stimulus
** Easily use any JavaScript bundler
** Encrypted attributes in Active Record
** Asynchronous Query Loading
** Zeitwerk autoloader is used exclusively
== Dependencies ==
* There are several packages, which depends on Ruby on Rails framework.
* These needs to be surely updated:
** (none)
* Following gems don't support Rails 7.0 right now and would be broken
by the update:
** (none)
* As Rails requires Ruby >= 2.7, the platform less than the version
can not use Rails 7.0.
== Contingency Plan ==
* Contingency mechanism: None needed. Rails stack won't be updated
until all its dependencies are in Rawhide. After that, it will be a
simple matter of updating the core packages (and their dependencies)
via side-tag.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
* Blocks product? No
== Documentation ==
* http://api.rubyonrails.org/
== Release Notes ==
* https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision
* https://edgeguides.rubyonrails.org/7_0_release_notes.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/F36MLT-7
== Summary ==
update MLT to version 7.4 (latest version)
== Owner ==
* Name: [[User:sergiomb| Sérgio Basto]]
* Email: sergiomb(a)fedoraproject.org
== Detailed Description ==
Update of MLT from v6 to v7 breaks the builds, binaries changed the
name and devel files changed the location [1], authors argue that
facilitates have 2 versions of MLT at same time, but I personally
don't want keep to versions of MLT because MLT just 3 or 5 projects
that use it,
[1]
https://github.com/mltframework/mlt/issues/713
== Benefit to Fedora ==
Up-to-date and latest MLT release will be delivered to Fedora users.
== Scope ==
* Proposal owners: [[User:Sergiomb | Sérgio Basto]]
[[https://accounts.fedoraproject.org/user/martinkg/ | Martin
Gansser]]
* Other developers: [[User:Kwizart | Nicolas Chauvet]]
* Release engineering:
* 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 ==
We need update ETL , synfig and synfigstudio from version 1.40 to
version 1.5.1 .
webvfx (THE PROJECT IS DEPRECATED BY THE MLT TEAM AND NO LONGER
MAINTAINED) we may retire it or build it without MLT support.
== How To Test ==
Run the new synfigstudio and work with it, testing the tasks that user
already did with the previous version
== User Experience ==
They will have updated tools
== Dependencies ==
Already explained on Upgrade/compatibility impact
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) (not a System
Wide Change) report upstream and apply fixes ASAP
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
https://www.mltframework.org/docs/
== Release Notes ==
post https://www.mltframework.org/blog/v7.0.0_released/
and blog it self https://www.mltframework.org/blog/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hello maintainers.
Currently, we build all EPEL variants against CentOS "base" in Fedora
Copr, i.e. epel-* configs means CentOS+EPEL. By the end of January 2022
CentOS 8 mirrors will start disappearing, pushing us to change the configs
to avoid build failures.
We would like to start the migration to the RHEL base as soon as possible,
so we are at least a bit "ahead" the change. So we can start resolving
the issues.
There doesn't seem to be a real blocker, or known issue.
- We got enough subscriptions from Red Hat for Fedora Copr purposes to
start building against official RHEL channels.
- The Mock + configs is stuck in Bodhi for now, but it doesn't block
Copr to apply for the change earlier. This is mostly about community
decision that 'fedpkg mockbuild' is not aligned, yet, not that Mock is
broken.
- The remaining problem seemed to be the s390x architecture, as the
emulation being _currently_ done wouldn't work with Red Hat
subscriptions, see details in [1] discussion. But thanks to IBM
sponsoring us IBM Cloud access we should be OK to deploy the s390x
arch support in Fedora Copr at the same time with the EPEL change
(this will go in a separate announcement).
**So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.** If
everything works well at least.
Side note from me... Note that EPEL 9 in Fedora Copr is still CentOS
Stream 9 + EPEL 9 ATM. This will change to "RHEL 9 + EPEL 9" once RHEL 9
is generally available (subscribed content). Might seem as a
complication for users, but it's actually not - it is good thing we can
start working on EPEL 9 now. So I want to congratulate to EPEL community
here, the fact we have stream in place allows us to bring EPEL 9 up before
actually RHEL is available. That's an awesome step (jump) forward
compared to previous releases!
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Pavel
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20220117.0):
ID: 1107475 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1107475
ID: 1107486 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1107486
Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose