[HEADS UP] udftools is going to be updated to 2.3
by Jiri Kucera
Hello,
I am going to update udftools to 2.3 plus backport the latest upstream
fixes introduced after this release. This should have no negative impact
(no library is distributed and dnf tells me that nothing depends on
udftools).
The list of changes according to upstream:
* mkudffs:
* Added support for creating Multisession UDF disc images via new
--startblock option
* Added new options for specifying owner, organization and contact
information
* Added new option --bootarea=mbr:sec-size to allow specifying MBR sector
size
* Added udftools version string into Application Identifier
* Fixed default value of Packet Length in Sparable Partition for UDF 1.50
and 2.00 rev to 32 blocks
* Fixed detecting all 33 types of optical discs defined in all versions
of SCSI MMC specifications
* Fixed filling CHS sector number into MBR partition table
* Fixed alignment of VAT block for CD-R, DVD-R and BD-R disc
* Fixed alignment for CD-R discs
* Fixed generating unclosed CD-R image with blocks more than 3072
* udfinfo & udflabel:
* Added support for Multisession UDF optical discs via new --startblock
and --lastblock options
* Added support for showing and changing owner, organization, contact,
appid and impid UDF identifiers
* Added more checks to validation of UDF structures
* Throw error when trying to modify UDF disc with unsupported Pseudo
OverWrite partition
* pktsetup:
* Added new option -i to ignore errors when device is already mapped or
unmapped
* Added new tool pktcdvd-check which checks if optical disc can be used
by kernel pktcdvd.ko driver for write operations
* Update udev rule to map only optical discs which are supported for
write operation (check done by pktcdvd-check tool)
* cdrwtool:
* Fixed formatting of CD-RW disc in modern optical drives according to
MMC-6 standard (via Format Code 1)
* Fixed support for progress bar
Regards,
Jiri
2 years, 11 months
abseil-cpp 20210324.2 coming to rawhide
by Rich Mattes
Hi all,
I will be updating abseil-cpp to version 20210324.2 in rawhide. I'll
handle rebuilding the following dependencies as well:
bloaty
fcitx5-mozc
grpc
Rich
2 years, 11 months
Use of Epoch/improper ordering
by Greg Hellings
Quick question about the Epoch tag in a spec file: I goofed during F34's
rawhide series and packaged an RC of my package with the wrong version name
(1.9.0RC3-1 instead of 1.9.0-0.1) which causes it to sort higher in
ordering than the final 1.9.0-5. From what I can gather, the proper
resolution for this is to add an Epoch tag to the SRPM file and build
1:1.9.0-5. However, adding the epoch tag seems to have no effect. When I
try to build, I'm told version 1.9.0-5 is already built for Rawhide/Fedora
34.
Is there a way to claw back the improperly versioned 1.9.0RC3 package from
ages ago? Is there some magic to enable the Epoch tag that I'm missing? How
do I get 1.9.0 final package out into Fedora?
TIA
--Greg
2 years, 11 months
Fedora for WSL
by Greg Hellings
I may be hair-brained to do this, but I've put together an installer for
Fedora on WSL.
It mostly follows the procedures that had been much talked about in a blog
post about running Fedora 33 in the WSL2, but it uses the direct installer
rather than the manual side-loads. It also will install Fedora 34.
Obviously, it's not released into the Windows Store as that requires more
than just some technical bit wrangling. But if you're feeling adventurous,
and you are sometimes relegated to the world of Windows but want to bring
your Fedora along, you can find it here:
https://github.com/greg-hellings/FedoraWSL
Am I crazy? Yep.
Does it work? "Works in dev."
Anything to watch out for? It uses the trustywolf/wslu COPR repository for
installing WSL integration packages. Otherwise it's just raw Fedora bits.
Feel free to flame me if this was a terrible idea.
--Greg
2 years, 11 months
Self Introduction: Sam Clements
by Sam Clements
Hi!
My name is Sam, a DevOps engineer maintaining build and release pipelines.
I've previously published my own open-source projects (including
python-colorlog which is already distributed in Fedora). I'll be working
with Neal Gompa and Dalton Miner, and learning about packaging from them.
Cheers,
Sam Clements
2 years, 11 months
rpmautospec: Invitiation to Test
by Nils Philippsen
Hey everybody,
we've recently deployed the changes needed to enable automatic RPM
release numbers and changelogs to Koji in staging, and now we want you
to throw things at it!
Detailed information is below, but the gist is: it looks like this will
be real sometime soon. This is the time to ensure we folks working on
it over the past weeks haven't left in any glaring errors.
We look forward to hearing from you!
Cheers,
Nils
-------
Background----------
In 2020, a prototype of rpmautospec was developed as feature for the
Koji build system to relieve Fedora contributors from manually
maintaining the release field and changelog of RPM packages. The
results were presented at Nest in August and were met with a positive
response.
FESCo accepted this feature to be implemented with changes to the
underlying release enumeration logic for the Fedora 35 release, and
subsequently a CPE team resumed work on the project in April 2021 to
bring the revised proposal to fruition. After about 6 weeks of
development, the team are pleased to announce that a first version of
rpmautospec based on the new logic is ready to be tested in staging.
Changed requirements in comparison to the prototype--------------------
-------------------------------
FESCO asked the team to implement a simplified release enumeration
algorithm. It basically just considers the number of commits since the
last time the version was changed and avoids storing information about
historical builds in git tags.
What it does at this stage of development
-----------------------------------------
* When building packages in Koji/staging, the release field and
changelog are maintained automatically from the commits and their
log entries (more specifically, their subject lines) in the git
repository. The contents of a changelog file, if present in the
repository, will override any older commit log information, to allow
correcting/amending changelog entries after the fact.
* For the release field, flags for pre-release versions,
snapshot/extra version information and release number offset exist
and are honoured. This isn’t yet implemented for changelog entries,
though, i.e. generated changelog entries will have the plain release
number in their header even for pre-release or snapshot versions.
* The new git history traversal code follows forks in order to support
merging branches. For changelog generation, this means it follows a
parent with the same tree to support git merge -s ours. Unresolvable
merges (with content from disparate branches) won’t fail a build,
but this problem will be flagged in the changelog (as the oldest
entry).
* An API function is provided allowing 3rd party users like fedpkg,
rpmdev-bumpspec to check if rpmautospec features are used and adapt
to it where necessary. Pull requests to use this have been submitted
to rpmdev-bumpspec and fedpkg/rpkg.
What’s yet to come
------------------
* Reflect flags to %autorelease in generated changelog entries.
* Have `fedpkg local`, `fedpkg mockbuild` (possibly `fedpkg srpm`)
support rpmautospec features, i.e. prepare the SRPM on the fly as
Koji would do it before building.
* Allow for uncommitted changes in local builds with fedpkg, i.e. bump
the release number by one and generate a boilerplate “- uncommitted
changes” RPM changelog entry.
* Up-to-date and more complete documentation (real soon now).
Testing Information
-------------------
* Source code can be found here: https://pagure.io/fedora-
infra/rpmautospec
* Installable packages are available for all supported Fedora
versions,
from 33 onwards.
* Quick Start:
- The staging environment is separate from what you use day to day,
recent
changes to your account might not have made it there. Ensure you can
log
into your Fedora account on staging, and that it is part of the
necessary
groups (e.g. packager): https://accounts.stg.fedoraproject.org
If you have issues with your staging account, please log a ticket
with
Fedora Infrastructure here: https://pagure.io/fedora-
infrastructure/new_issue
- Clone the staging repository of a package: `fedpkg-stage clone ...`
- Move the existing changelog entries beneath %changelog in the spec
file
into a file named changelog in that same directory and add that file
to
be tracked by git.
- Enable automatic release number enumeration and changelog generation
in
the spec file:
... Release: %autorelease ... %changelog %autochangelog
- Commit these changes to git, push and build:
git commit -m "Use automatic release and changelog" git push
fedpkg-stage build
- If you want to use the Koji CLI tool, point it at staging this way:
koji --profile=stg ...
* We are interested in issues concerning using rpmautospec, if you
need help
but also where its behavior is unexpected or even disruptive, such
as:
- (How) Can I do …?
- My package doesn’t build if I use automatic release and/or
changelog.
- The automatically generated changelog of my package looks weird.
- The documented way to do … doesn’t work.
- I don’t use rpmautospec features, but it still touches my package.
* If you have questions, contact us on IRC, the people on the team
hang around
e.g. in the #fedora-apps channel (among others) on irc.libera.chat.
* Please file bugs here: https://pagure.io/fedora-
infra/rpmautospec/new_issue
Mind that time is scarce and therefore we have to triage/prioritize,
i.e.
not all bugs/issues may be addressed before we deploy to production.
* For a quick turnaround, we will redeploy changes/fixes to the
builders in
staging without prior notice at any time, this can affect unfinished
test
builds at the time.
Production-Ready Plans
----------------------
The team are on track to deploy the project to production by end of
June 2021. We will coordinate the deployment in production with the
people from the Fedora Infra & Release Engineering teams and announce
it with more precise dates separately.
Feature ideas for future development------------------------------------
These items are out of scope for the initiative but we would like to
have them at some point. We might get around to some of these if time
permits, but no promises.
* Convenience tooling like “convert spec file to using automatic
release and changelog”, “freeze generated changelog to file for
editing”, “show me the NVR of the next build”, etc.
* “Magic comments” to e.g. skip commit logs for the changelog.
* Longer changelog messages than just the commit log subject.
Links
-----
* Project Repository: https://pagure.io/fedora-infra/rpmautospec
* Nest Slides (Prototype):
https://nphilipp.fedorapeople.org/nest2020-rpmautospec-slides/
--
Nils Philippsen "Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
2 years, 11 months
valgrinded executable seem to run far more slowly in Rawhide
by Richard W.M. Jones
I haven't filed a bug yet because I'm not sure what component to
assign this too. I upgraded to Rawhide this morning and noticed that
some tests that previously ran OK are now timing out. It turned out
that the tests were failing because a valgrinded executable runs much
more slowly in Rawhide today.
Here's my test:
Upgrade to Rawhide and install these additional packages:
# dnf install libnbd nbdkit valgrind
Unpack the certificates from
http://oirase.annexia.org/tmp/rawhide-valgrind-bug/pki.tar.gz into /tmp
Run this command as NON-root (it's self-contained and just connects
the two commands together over localhost port 10809):
$ time nbdkit --tls=require --tls-certificates=/tmp/pki null --run 'valgrind nbdinfo nbds://localhost'
For me this takes over 40 seconds in Rawhide, versus a couple of
seconds in Fedora 33/34. Also if you remove "valgrind" it runs
instantaneously even in Rawhide. If you run it as root, it runs
quickly again (WTF!)
The perf flamegraph seems to indicate it's doing a lot of stuff with
DWARF 3 symbols.
http://oirase.annexia.org/tmp/rawhide-valgrind-bug/libnbd.svg
Uninstalling all relevant debuginfo packages didn't seem to help.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2 years, 11 months