Heads up home brewers - brewtarget update and license change
by Sandro
I recently adopted brewtarget and updated it to the latest release
(3.0.2). Since this is a major update, it contains quite a few changes.
### License
The new SPDX license string is:
GPL-3.0-or-later AND BSD-2-Clause AND WTFPL AND (CC-BY-SA-3.0 OR
LGPL-3.0-only) AND LGPL-2.1-only
The additional license are mostly for artwork used in the application.
### Changelog
The full changelog is available upstream [1]. It's quite a long list.
### Updating
The update will make changes to the database used for storing recipes.
You are advised to backup your user data (~/.config/brewtarget).
[1] https://github.com/Brewtarget/brewtarget/blob/develop/CHANGES.markdown
Cheers,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
1 year, 5 months
Re: Failed RPM database migrations
by Steven Bonneville
On Fri, Oct 28, 2022 at 13:49:21 +0100, Richard W.M. Jones wrote:
> On Fri, Oct 28, 2022 at 01:45:32PM +0100, Tom Hughes wrote:
> > On 28/10/2022 13:31, Richard W.M. Jones wrote:
> > >On Fri, Oct 28, 2022 at 12:29:30PM +0100, Tom Hughes wrote:
> > >>The reason it hadn't completed is that rpmdb-migrate.service
> > >>was enabled on that machine.
> > >[was not, I guess?]
> >
> > Yes ;-)
> >
> > >>Enabling (and starting) that service made it complete.
> > >
> > >Interesting. The current state of that service is:
> > >
> > >○ rpmdb-migrate.service - RPM database migration to /usr
> > > Loaded: loaded (/usr/lib/systemd/system/rpmdb-migrate.service;
> disabled; vendor preset: enabled)
> > > Active: inactive (dead)
> > >
> > >There are no log entries for this service, but my logs only go back to
> > >around April which is probably too late to see anything.
> > >
> > >After starting the service:
> > >
> > >Oct 28 13:29:33 systemd[1]: Starting rpmdb-migrate.service - RPM
> database migration to /usr...
> > >Oct 28 13:29:35 rpmdb_migrate[1722092]: removed
> '/var/lib/rpm/.migratedb'
> > >Oct 28 13:29:35 rpmdb_migrate[1722092]: removed
> '/var/lib/rpm/rpmdb.sqlite-shm'
> > >Oct 28 13:29:35 rpmdb_migrate[1722092]: removed
> '/var/lib/rpm/rpmdb.sqlite'
> > >Oct 28 13:29:35 rpmdb_migrate[1722092]: removed
> '/var/lib/rpm/rpmdb.sqlite-wal'
> > >Oct 28 13:29:35 rpmdb_migrate[1722092]: removed '/var/lib/rpm/.rpm.lock'
> > >Oct 28 13:29:35 rpmdb_migrate[1722092]: removed directory '/var/lib/rpm'
> > >Oct 28 13:29:35 rpmdb_migrate[1722468]: '/var/lib/rpm' ->
> '../../usr/lib/sysimage/rpm'
> > >Oct 28 13:29:35 systemd[1]: rpmdb-migrate.service: Deactivated
> successfully.
> > >Oct 28 13:29:35 systemd[1]: Finished rpmdb-migrate.service - RPM
> database migration to /usr.
> > >Oct 28 13:29:35 systemd[1]: rpmdb-migrate.service: Consumed 2.433s CPU
> time.
> > >
> > >... and the migration has been successful. So at least we know how to
> > >fix this. Although it's quite curious that the service was installed
> > >and supposed to run but didn't.
> >
> > The idea is that the service is enabled (not sure off hand what is
> > supposed to do that) but not started, so that it runs when you reboot
> > and completes the migration as part of the boot.
> >
> > When it runs it removes /var/lib/rpm/.migratedb which was created
> > by the rpm scripts and hence prevents the service running on future
> > boots as it's no longer needed.
>
> It's hard to tell what happened without logs going back all the way,
> but the machine was rebooted 65 days ago and several times before
> that. Within the available logs there is no mention of the service so
> it may already have tried to run on a boot prior to the logs and
> failed for some reason.
>
> We do have reports of this happening from 3 independent people now so
> it's not a one-off.
I wonder if folks rebooted or shut down the system after upgrading, and
after /var/lib/rpm/.migratedb is removed but before the migration actually
finished. The example above shows the file being removed before the
cleanup completed. That run only took two seconds, so it seems to be an
unlikely cause, but is that typically how long the migration takes?
-- Steve
1 year, 6 months
openvdb 10.0.0 build issue
by Richard Shaw
Since it was released I figured I would just play around building it
locally in mock but I'm running into a failure I haven't seen before at
about 56%:
Container 6cbaadceeecc4c62a1c029207e4389f1 terminated by signal KILL.
So my gut telling me it was a resource issue I ran glances on the next
build attempt, and apparently OpenVDB takes a LOT of memory. It consumeded
all 32GB of memory and my 8GB zswap.
So apparently 32GB ram isn't enough anymore?
I'm going to increase my zswap to 16GB and try again...
Thanks,
Richard
1 year, 6 months
Fedora 37 compose report: 20221028.n.0 changes
by Fedora Rawhide Report
OLD: Fedora-37-20221027.n.0
NEW: Fedora-37-20221028.n.0
===== SUMMARY =====
Added images: 8
Dropped images: 1
Added packages: 0
Dropped packages: 0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages: 0 B
Size of upgraded packages: 0 B
Size of downgraded packages: 0 B
Size change of upgraded packages: 0 B
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-37-20221028.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-37-20221028.n.0.iso
Image: Container_Base docker aarch64
Path: Container/aarch64/images/Fedora-Container-Base-37-20221028.n.0.aarch64.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20221028.n.0.s390x.qcow2
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-37-20221028.n.0.s390x.raw.xz
Image: Container_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Base-37-20221028.n.0.s390x.tar.xz
Image: Container_Minimal_Base docker s390x
Path: Container/s390x/images/Fedora-Container-Minimal-Base-37-20221028.n.0.s390x.tar.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-37-20221028.n.0.iso
===== DROPPED IMAGES =====
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-37-20221027.n.0.iso
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
===== DOWNGRADED PACKAGES =====
1 year, 6 months
F38 proposal: LXQt image for aarch64 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LXQt_image_for_aarch64
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 ==
Generate LXQt image (both iso and disk image) for aarch64 architecture.
== Owner ==
* Name: [[User:Zsun|Zamir SUN]]
* Email: zsun#AT#fedoraproject.org
== Detailed Description ==
LXQt has moved out of 0.x version and is now 1.1.0, so I consider it
to be a pretty stable desktop environment. Recently, 64bit ARM
architecture is becoming more and more popular in laptops and
workstations. By generating a LXQt image for aarch64 will offer
aarch64 another easier option to evaluate and use Fedora.
== Benefit to Fedora ==
Offers users of 64bit ARM architecture another desktop option that
works out-of-the-box.
== Scope ==
* Proposal owners: Nothing. The LXQt packages are already in the
distribution. And the kickstart for generating LXQt image on x86_64
can be directly used.
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issue/11086 11086]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Install using the ISO or the disk image on aarch64 system. The system
should work as it should be by manually installing on top of any
existing aarch64 system.
== User Experience ==
Users of aarch64 systems should be able to directly install from LXQt
ISO or disk image if they want to use LXQt.
== Dependencies ==
We need to ask release engineering team to generate the image.
== Contingency Plan ==
* Contingency mechanism: Just do not ship the newly generated image.
* Contingency deadline: Fedora 38 Beta Freeze
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 6 months
Fedora CoreOS Meeting Minutes 2022-10-26
by Dusty Mabe
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
========================================
#fedora-meeting-1: fedora_coreos_meeting
========================================
Meeting started by dustymabe at 16:30:38 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-10-26/fedora_core...
.
Meeting summary
---------------
* roll call (dustymabe, 16:30:44)
* Action items from last meeting (dustymabe, 16:35:19)
* ACTION: bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re.
VMware (dustymabe, 16:36:05)
* 20221101: CRITICAL OpenSSL vulnerability (dustymabe, 16:36:27)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1329
(dustymabe, 16:36:46)
* LINK:
https://developers.redhat.com/blog/2019/06/24/go-and-fips-140-2-on-red-ha...
(travier, 16:49:25)
* LINK:
https://developers.redhat.com/articles/2022/05/31/your-go-application-fip...
(travier, 16:50:08)
* LINK:
https://developers.redhat.com/articles/2022/05/31/your-go-application-fip...
> this one seems to confirm that this is not the case on Fedora so
we should be good for ignition (travier, 16:51:54)
* we will meet again tomorrow once Fedora decides if F37 will ship
next week to discuss the scenarios here. (dustymabe, 17:17:42)
* including audit in Fedora CoreOS (dustymabe, 17:21:34)
* LINK: https://github.com/coreos/fedora-coreos-tracker/issues/461
(dustymabe, 17:21:40)
* open floor (dustymabe, 17:22:27)
Meeting ended at 17:32:19 UTC.
Action Items
------------
* bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re. VMware
Action Items, by person
-----------------------
* bgilbert
* bgilbert will follow up on
https://github.com/coreos/fedora-coreos-tracker/issues/567 re.
VMware
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dustymabe (99)
* bgilbert (82)
* travier (56)
* zodbot (24)
* jlebon (11)
* lucab (7)
* adamw (5)
* fifofonix (3)
* mnguyen (1)
* gursewak (1)
* jbrooks (1)
* aaradhak (1)
* Nemric (1)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
1 year, 6 months
