Self introduction: Stephen Snow <FASID:jakfrost>
by Stephen Snow
Hello,
I would like to start helping with maintaining a/some package(s). I
have read the pre-requisite documents, did the RPM creation tutorial,
and signed up to all the mailing lists.
I am currently self employed providing industrial control services to
some businesses in my area, which is the South Bruce Peninsula in
Ontario Canada. I live in between Lake Huron to the west and Georgian
Bay to the east. It is currently very cold here -10C, but not like out
West (-49C in Saskatchewan).
I am somewhat active in the Fedora community, most recently I am an
editor and writer for Fedora Magazine. I am also a moderator on
discussion.fp.o, where I try to help out when I can and generally enjoy
the community interraction that is to be had there. I have also helped
Silverblue project a bit with documentation in the past, and am an avid
promoter of it as a very stable workstation alternative.
In my day job, which I have been doing in one form or another since
1986, I have had to program or debug programs on a diverse range of
control systems. As a result, I have been exposed to, and in many cases
had to learn a number of different languages. The most relevant of
which would be C/C++ and Java. In industrial settings it is commonly
the standard C lib used, but periphery equipment such as thermal
printers often would accept java code as well as basic if you were so
inclined. In any case, there were also various Unix, Qnx, and
eventually some Linux based control systems in use on the plant floors
I visited.
I would like to put my programming skills to use in the project where I
can, perhaps staring with an orphaned package(s) since I have built
RPM's and flatpaks too for that matter even before doing the tutorial.
Thank you for taking the time to read this, and I look forward to
helping out.
Regards,
Stephen Snow
3 years, 2 months
Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change
proposal)
by Miro Hrončok
On 09. 02. 21 18:28, Robbie Harwood wrote:
> Miro Hrončok <mhroncok(a)redhat.com> writes:
>
>> On 09. 02. 21 17:17, Robbie Harwood wrote:
>>> Miro Hrončok <mhroncok(a)redhat.com> writes:
>>>
>>>> Also note that it is a Pull Request, not a provenpackager mass pushing
>>>> changes.
>>>
>>> Indeed, one step closer to doing this right :)
>>
>> To doing what right? If I am doing something wrong, tell me how exactly and what
>> am I doing. So far you only accused me of doing something I am not doing.
>
> Please calm down!
>
> I don't like provenpackager changes - you seem to know this, from your
> reply pointing out that this was not a provenpackager change. I'm
> trying to express my appreciation for it. If we can't even have that
> exchange, there's no purpose in me trying further.
Your way of expressing appreciation is very unconventional.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 2 months
Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DeprecatePythonMock
== Summary ==
The {{package|python-mock}} ({{package|python3-mock}}) package will be
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated] in [[Releases/34|Fedora 34]]. The package is a standard
library backport for older Pythons, Fedora packages should use
`unittest.mock` instead. Many still depend on `mock`, so we cannot
remove it yet. Packagers are encouraged to work with upstream to
switch to `unittest.mock` when available. A simple `sed` can be
applied in `%prep` as a temporary (or even permanent) downstream
solution.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com
== Detailed Description ==
The {{package|python-mock}} package is the
[https://pypi.org/project/mock/ 3rd party backport of the standard
library `unittest.mock` module].
> mock is now part of the Python standard library, available as [https://docs.python.org/dev/library/unittest.mock.html unittest.mock] in Python 3.3 onwards.
> This package contains a rolling backport of the standard library mock code compatible with Python 3.6 and up.
Fedora has recent enough versions of Python, hence using a library
backport is redundant. Many packages only use it out of habit. We'd
like to encourage both downstream packages and upstreams to switch to
[https://docs.python.org/dev/library/unittest.mock.html unittest.mock]
instead. Eventually, we'd like to drop {{package|python-mock}} from
Fedora entirely, if possible. Before we attempt to remove the package,
we need to stop new packages to (Build)Require
{{package|python3-mock}}, hence we want to have it
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated].
Note that the change owner does not currently officially maintain
{{package|python-mock}} but the Python Maintenance team maintains the
package in RHEL and contributes to the Fedora package when needed. The
Fedora package maintainers have been contacted without response.
=== How to migrate to unittest.mock ===
In most cases, performing the following replacement should be enough:
s/^(\s*)import mock/\1from unittest import mock/
s/^(\s*)from mock import /\1from unittest.mock import /
If upstream really needs to support Python versions without
`unittest.mock`, we recommend using a `try-import` mechanism, such as:
try:
from unittest import mock
except ImportError:
import mock
If dual support for `unittest.mock` and `mock` is required, and the
`mock` package is required in the metadata (such as in the testing
''extras''), conditionalize it, with:
mock;python_version<"3.3"
== Feedback ==
In the past, we've managed to migrate some packages away from
python-mock, without a push back:
* https://src.fedoraproject.org/rpms/python-urllib3/pull-request/13
* https://src.fedoraproject.org/rpms/python-freezegun/pull-request/10
* https://src.fedoraproject.org/rpms/python-hypothesis/c/65a4191709
== Benefit to Fedora ==
Eventually, we might be able to no longer maintain a standard library
backport in a separate package.
== Scope ==
* Proposal owners: Deprecate {{package|python3-mock}} and update the
package description. Provide help migrating to `unittest.mock` to
other packagers who ask for it.
* Other developers: No action needed. Don't add new dependencies on
{{package|python3-mock}}. If interested, migrate existing packages to
`unittest.mock` (feel free to ask for help)
* Release engineering: no impact on Release Engineering is anticipated
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The package will remain available. Only new packages cannot depend on it.
Once retired (in distant future), we don't plan to obsolete/provide
<code>python3-mock</code> from {{package|python3-libs}}, because it
cannot work as drop-in replacement (the import name is different). The
package will eventually be obsoleted by
{{package|fedora-obsolete-packages}} once Python is updated to 3.N+1
after the removal to avoid broken upgrades.
== How To Test ==
$ repoquery --repo=rawhide --provides python3-mock
...
deprecated()
...
== User Experience ==
No changes.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 2 months
minizp soname bump from 2.5 to 3.0
by Patrik Novotny
There will be a soname bump from libminizip.so.2.5 to libminizip.so.3.0.
Change will be build in a side-tag f34-build-side-37055.
--
Patrik Novotný
Associate Software Engineer
Red Hat
panovotn(a)redhat.com
3 years, 2 months
HEADS UP: Unannounced soname bump of minizip, 400 broken packages
by Miro Hrončok
Hello packagers,
minizip was just bumped from libminizip.so.2.5 to libminizip.so.3.0.
Many packages now have broken dependencies in rawhide:
$ repoquery --repo=koji --whatrequires 'libminizip.so.2.5()(64bit)' --exact
R-libSBML-0:5.19.0-3.fc34.x86_64
collada-dom-0:2.5.0-15.fc34.x86_64
dolphin-emu-0:5.0.12716-3.fc34.x86_64
java-libsbml-0:5.19.0-3.fc34.x86_64
librasterlite2-0:1.1.0-0.2.beta1.fc34.x86_64
libsbml-0:5.19.0-3.fc34.x86_64
libspatialite-0:5.0.1-1.fc34.x86_64
libxlsxwriter-0:1.0.0-3.fc34.x86_64
perl-LibSBML-0:5.19.0-3.fc34.x86_64
python3-libsbml-0:5.19.0-3.fc34.x86_64
qmc2-0:0.195-15.fc34.x86_64
qmc2-arcade-0:0.195-15.fc34.x86_64
ruby-SBML-0:5.19.0-3.fc34.x86_64
sigil-0:0.9.14-8.fc34.x86_64
vxl-0:2.0.2-10.fc34.x86_64
xiphos-0:4.2.1-7.fc34.x86_64
zfstream-0:20041202-31.fc34.x86_64
$ repoquery --repo=koji{,-source} --whatrequires 'libminizip.so.2.5()(64bit)'
--recursive | grep src$ | wc -l
100
... | grep -v src$ | wc -l
402
I suggest we untag the build before it reaches compose, tag it into a side tag
and do a targeted rebuild there.
Patrik?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 2 months
linux-firmware heads up for brcmfmac wifi firmware
by Peter Robinson
Hi All,
Just a heads up for those that have a brcmfmac, the Cypress variants
of these WiFi modules (there's 3 vendors that make them: Broadcom,
Cypress/Infineon and now Synaptics) have got new firmwares, I'm giving
a heads up because in some cases the firmwares are being updated from
firmwares that date back to 2014 so no doubt there's quite some
changes here.
If you run into a problem just report it in bugzilla in the usual manner.
On the plus side there's at least one CVE I'm aware of and for some of
the older firmwares I've little doubt there's quite a few more.
3 years, 3 months