Re: NeuroFedora review swaps
by Ankur Sinha
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
>
> > I'd like to get this package reviewed please:
> >
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> >
> > Would anyone like to swap reviews?
>
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
--
Thanks,
Regards,
Ankur Sinha
https://ankursinha.in
Time zone: Europe/London
3 years, 3 months
How to troubleshoot aarch64 and s390x?
by Richard Shaw
I'm working on building the new openexr package but the unit tests are
failing but just on aarch64 and s390x.
The aarch64 test instances are down due to the infra move and there are
none for s390x.
What's the best way to work around this? An emulated aarch64 install of
Fedora?
Thanks,
Richard
3 years, 3 months
Mass spec file change: Adding BuildRequires: make
by Tom Stellard
Hi,
As part of the f34 change request[1] for removing make from the
buildroot, I will be doing a mass update of packages[2] to add
BuildRequires: make where it is needed.
If you are a package maintainer and would prefer to update your packages
on your own, please do so before Dec 14, which is when I will begin
doing the mass update.
I will be doing the updates in batches, so that if there is a mistake
the impact will be limited. Here is the rough schedule of the changes:
Dec 14: Update first 50 packages.
Dec 16: Next 1000.
Dec 18: Next 1000.
Jan 4: Next 1000.
Jan 5: Next 1000.
Jan 6: Next 1000.
Jan 7: Next 1000.
Jan 8: Rest of packages.
The deadline for completing these updates is the start of the f34 mass
rebuild (Jan 20).
Thanks,
Tom
[1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
[2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt
3 years, 3 months
Fedora 34 Change: Ruby 3.0 (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ruby_3.0
== Summary ==
Ruby 3.0 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 2.7 in Fedora 33 to
Ruby 3.0 in Fedora 34, Fedora becomes the superior Ruby development
platform.
== Owner ==
* Name: [[User:vondruch| Vít Ondruch]], [[User:pvalena| Pavel Valena]]
* Email: vondruch(a)redhat.com, pvalena(a)redhat.com
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences
suffices to explain the goal, but the more details you can provide the
better. -->
Ruby 3.0 is upstream's new major release of Ruby. Many new features
and improvements are included.
=== RBS ===
RBS is a language to describe the types of Ruby programs. Type
checkers including type-profiler and other tools supporting RBS will
understand Ruby programs much better with RBS definitions.
You can write down the definition of classes and modules: methods
defined in the class, instance variables and their types, and
inheritance/mix-in relations. The goal of RBS is to support commonly
seen patterns in Ruby programs and it allows writing advanced types
including union types, method overloading, and generics. It also
supports duck typing with interface types.
Ruby 3.0 ships with `rbs` gem, which allows parsing and processing
type definitions written in RBS.
=== Ractor (experimental) ===
Ractor is an Actor-model like concurrent abstraction designed to
provide a parallel execution feature without thread-safety concerns.
You can make multiple ractors and you can run them in parallel. Ractor
enables to make thread-safe parallel programs because ractors can not
share normal objects. Communication between ractors are supported by
message passing.
To limit sharing objects, Ractor introduces several restrictions to
the Ruby’s syntax (without multiple Ractors, there is no changes).
The specification and implementation are not matured and changed in
future, so this feature is marked as experimental and show the
experimental feature warning if Ractor is created.
=== Scheduler (Experimental) ===
`Thread#scheduler` is introduced for intercepting blocking operations.
This allows for light-weight concurrency without changing existing
code.
CAUTION: This feature is strongly experimental. Both the name and
feature will change in next preview release.
=== Other Notable New Features ===
* Rightward assignment statement is added.
* Endless method definition is added.
* Find pattern is added.
* `Hash#except` is now built-in.
* Memory view is added as an experimental feature
=== Performance improvements ===
Many improvements were implemented in MJIT.
=== Other notable changes since 2.7 ===
* Keyword arguments are separated from other arguments.
* The feature of `$SAFE` was completely removed; now it is a normal
global variable.
* The order of backtrace had been reversed at Ruby 2.5, but it was
cancelled. Now it behaves like Ruby 2.4; an error message and the line
number where the exception occurs are printed first, and its callers
are printed later.
* Some standard libraries are updated.
== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.
== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.0. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/70
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).
* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.0 properly.
* Release engineering: [https://pagure.io/releng/issue/9882 #9882] (a
check of an impact with Release Engineering is needed)
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
* User specific Ruby binary extensions need to be rebuild.
== How To Test ==
* No special hardware is needed.
* To test, install Ruby 3.0. The test builds are pusblished in PR or
on Ruby-SIG ML
* Try to locally rebuild your packages using Ruby 3.0.
* Use the packages with your applications previously written in Ruby.
* If something doesn't work as it should, let us know.
== User Experience ==
The Ruby programs/scripts should behave as they were used to.
== Dependencies ==
<pre>
$ dnf repoquery --disablerepo=* --enablerepo=rawhide
--enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' |
sort | uniq | wc -l
138
</pre>
== Contingency Plan ==
* Contingency mechanism: We would like to get a special buildroot tag
to be able to rebuild necessary the packages with Ruby 3.0. If
anything goes wrong, the tag could be easily dropped and previous
version of Ruby 2.7 and its dependencies stays intact. The tag would
be merged into F34 after everything is rebuild.
* Contingency deadline: Mass Rebuild
* Blocks release? No (not a System Wide Change), Yes/No
* Blocks product? No
== Documentation ==
* [http://www.ruby-doc.org/ Help and documentation for the Ruby
programming language]
* [https://github.com/ruby/ruby/blob/v3_0_0_preview1/NEWS.md Ruby
3.0.0.preview1 NEWS]
== Release Notes ==
* The Ruby 3.0 bumps soname, therefore Ruby packages, which use binary
extensions, should be rebuilt. Nevertheless, since upstream paid great
attention to source compatibility, no changes to your code are needed.
https://github.com/ruby/ruby/blob/master/NEWS
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/golang1.16
== Summary ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]], [[User:alexsaezm| Alejandro Sáez
Morollón]]
* Email: jcajka(a)redhat.com, alexsaezm(a)redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.16 in Fedora 34. Golang
1.16 is scheduled to be released in February 2021.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.
== Benefit to Fedora ==
Stay closely behind upstream by providing the latest release of Go,
which includes improved support of the risc-v processor architecture
and added support for aarch64 based darwin(macOS) machines, among
other bug fixes, enhancements and new features. For a complete list of
changes, see upstream change notes at
https://tip.golang.org/doc/go1.16 . Therefore Fedora will be providing
a reliable development platform for Go language and projects written
in it.
== Scope ==
* Proposal owners: Rebase Golang package in Fedora 34, help resolve
possible issues found
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking
issue.[https://pagure.io/releng/issue/9904]
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
;0.
:a) Install golang 1.16 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.16 should work as expected.
== User Experience ==
None
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed ~1600.
</pre>
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.15.X if
significant issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.16
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 3 months
runtime dependencies not in Requires spec section
by Germano Massullo
I am one of the keepassxc maintainers. Bugreport
"Missing dependency: qt5-qtsvg libQt5Svg.so.5"
https://bugzilla.redhat.com/show_bug.cgi?id=1911210
made me wonder about the following thing:
I just installed a basic Fedora server to do a test concerning keepassxc
libs. Keepassxc spec file [1] does not contain any Requires dependency,
but when I install it, it triggers the installation of these libraries
[2] that are needed at runtime.
My question is: how can keepassxc trigger the installation of such
libraries if the spec file does not contain any Requires dependency that
should be the attribute to identify runtime dependencies that are needed
by the package?
Thank you
[1]:
https://src.fedoraproject.org/rpms/keepassxc/blob/master/f/keepassxc.spec
[2]:
fontconfig freetype glx-utils graphite2 harfbuzz langpacks-core-font-en
libICE libSM libX1 libX11-common libX11-xcb libXau libXdamage libXext
libXfixes libXi libXtst libXxf86vm libdrm libevdev libglvnd libglvnd-egl
libglvnd-glx libinput libjpeg-turbo libpciaccess libsodium libwacom
libwacom-data libwayland-client libwayland-server libxcb
libxkbcommon-x11 libxshmfence libyubikey llvm-libs mesa-filesystem
mesa-libEGL mesa-libGL mesa-libgbm mesa-libglapi mtdev pcre2-utf16
qt-settings qt5-qtbase qt5-qtbase-common qt5-qtbase-gui qt5-qtsvg
qt5-qtx11extras quazip-qt5 xcb-util xcb-util-image xcb-util-keysyms
xcb-util-renderutil xcb-util-wm xml-common ykpers Weak dependencies:
mesa-dri-drivers
3 years, 3 months
gpg-agents all over the place
by Marius Schwarz
Hi,
I sorry to tell you, that gpg-agents are inflating on numbers in Fedora
systems:
As far as I understand ssh-agents, you start ONE for each user, but
here, one for each repo is opened by PackageKit:
(today)
root 2530 0.0 0.0 151908 892 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-modular-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2637 0.0 0.0 151908 896 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-free-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2653 0.0 0.0 151908 796 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-nonfree-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2668 0.0 0.0 151908 816 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2693 0.0 0.0 151908 860 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/fedora-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2710 0.0 0.0 151908 708 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/33/metadata/updates-modular-33-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2723 0.0 0.0 151908 896 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/33/metadata/updates-33-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3393 0.0 0.0 151908 892 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-modular-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3404 0.0 0.0 151908 712 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-free-updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3417 0.0 0.0 151908 800 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/updates-modular-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3438 0.0 0.0 151908 812 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-free-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3451 0.0 0.0 151908 808 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-nonfree-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3464 0.0 0.0 151908 936 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3474 0.0 0.0 151908 948 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-nonfree-updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3492 0.0 0.0 151908 768 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/teamviewer-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3512 0.0 0.0 151908 884 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3526 0.0 0.0 151908 888 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-cisco-openh264-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
it would be more effective, if you give any programm who needs it, the
password directly, instead of having useless processes laying around ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1895012
it's not even doing this for every system, as my private pc does not
have those (upgraded by dnf, and yes, it's installed), but others do
(upgraded by packagekit).
Systemd opens gpg-agents even for mailserver daemons, which do not need
nor know how to use them.
https://bugzilla.redhat.com/show_bug.cgi?id=1877308
No idea what caused this invasion lately, but bugreports about it, get
ignored.
Could someone please take a look and fix it, if it's bug.
best regards,
Marius Schwarz
3 years, 3 months
Self Introduction -- Derek Pressnall
by dspgh＠needcaffeine.net
Hello fellow developers.
I've joined this list quite a while ago, mostly to keep a pulse on the Fedora development community, but also to look to become a package contributor. But before getting to that, a few words about myself.
I've been "into computers" since mid-80's, started off with a 4.77 Mhz 8088 (IBM PCjr). I learned Unix in the early 90's on an IBM AIX system, where I picked up C programming and sysadmin experience. Which eventually took me into the world of Linux (I think it was kernel version 0.12, came on a boot disk and root disk pair I grabbed off a BBS, long before there was easy general public Internet access).
Anyway I've been focused on Red Hat based distros for the past 15 years, and at my current employer I oversee about 700 systems installed at customer locations (where I was the resource responsible for packaging our applications and creating system build images).
Any way, what I'd like to give back to the community is a really nice backup system called Snebu (Simple Network Encrypting Backup Utility). I initially developed this more than 8 years ago since there wasn't anything else that fit my needs -- I used it to back up my personal systems, and also in some lab environments. I've read plenty of rants that have been posted about how backups are either too difficult to set up, or don't support multiple clients, or require a repository encryption password to be placed in plain text on clients, and other issues people have. With that in mind, I believe that Snebu can be just what people want.
Before going through and submitting the package for formal review, I'd appreciate some feedback on what I have packaged up so far. The current release is at https://github.com/derekp7/snebu/releases/download/v1.1.0/snebu-1.1.0-1.f..., and the project web site is at https://www.snebu.com.
The main features that it has that are interesting: It maintains a centralized package database on the server (using SQLite3) tracking backup sets and metadata; actual files are stored in the filesystem as lzop compressed files using a file hash for the file name which leads to full cross-system file level de-duplication (so no proprietary file formats); uses a snapshot style backup strategy; it uses GNU tar as a serialization format to shuffle backups to the server which leads to how the public key encryption support was added by developing "tarcrypt"; and it works in single-system installs, client-push or server-pull backups, with no agent required on the client.
Another interesting project that I may spin off is the above mentioned "tarcrypt" command. This acts as a filter for tar files, which adds RSA key data to the header (passphrase protected private key, public key, HMAC signatures, etc), compresses and encrypts the file contents while keeping standard tar headers in place (with the additional encryption metadata added via extended PAX headers). The details on this project is at https://www.snebu.com/tarcrypt.html. So far tarcrypt is part of the Snebu repository, but if there is interest then it may eventually be spun out as an independent project.
BTW, the current .src.rpm file for Snebu mentioned above has passed through a valid build using the Fedora "mock" utility, and passed rpmlint. The only error rpmlint shows is:
snebu.src: W: spelling-error %description -l en_US de -> DE, ed, d
Not sure what that error is saying, as the text at the end of the message doesn't appear anywhere in the .spec file.
Thanks, and I look forward to your feedback.
3 years, 3 months
