Re: Failed RPM database migrations

2022-10-28 Thread Todd Zullinger
Hi,

Richard W.M. Jones wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2
> https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
> https://bugzilla.redhat.com/2042099
> 
> The RPM database is supposed to move from /var/lib/rpm to
> /usr/lib/sysimage/rpm.  This was supposed to happen automatically when
> you upgraded the rpm package from an earlier version to 4.17.0-10.fc36
> (Feb-Mar 2022).
> 
> On several machines it is reported that the migration was only half-
> completed.  The symptoms are that the RPM database is still in
> /var/lib/rpm (/usr contains symlinks to it).  See typical output from
> failed & successful migrations at the end of the email.
> 
> So _if_ you have rpm >= 4.17.0-10.fc36 installed:
> 
>  - Do you see the symptom of a failed migration?  Or does it appear
>to be successful?  (Or neither case??)
> 
>  - Did you:
> * Install F37 or Rawhide from scratch?
> * Upgrade using ordinary dnf update or similar?
> * Upgrade using dnf system-upgrade?
> * Some other install/upgrade method?

I upgraded two systems from f35 to f36 in the past week via
dnf system-upgrade.  Neither of them completed the rpm
migration.

I _think_ the issue is due to the version-release in the
%triggerun which should enable the rpmdb-migrate service.
That is:

%triggerun -- rpm < 4.17.0-7
# Handle rpmdb migrate service on erasure of old to avoid ordering issues
if [ -x /usr/bin/systemctl ]; then
systemctl --no-reload preset rpmdb-migrate ||:
fi

That was accurate when it was added in 0b9f813 (Migrate
rpmdb to /usr/lib/sysimage/rpm (#2042099), 2022-01-26).

However, when rpm was updated in f35 in e9927df (Rebase to
rpm 4.17.1 (http://rpm.org/wiki/Releases/4.17.1),
2022-07-01), which never had the migration code, it
prevented any up-to-date f35 system from triggering the
migration.

Anyone upgrading from f35 after rpm-4.17.1 was pushed to
f35 won't have the rpmdb-migrate service enabled and the
database will remain in /var/lib/rpm (with .migratedb) and
symlinks in /usr/lib/sysimage/rpm.

It seems that it's not so much a failed migration as a
migration which is never attempted. :/

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2138492] New: perl-DateTime-TimeZone-2.56 is available

2022-10-28 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2138492

Bug ID: 2138492
   Summary: perl-DateTime-TimeZone-2.56 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime-TimeZone
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 2.56
Upstream release that is considered latest: 2.56
Current version/release in rawhide: 2.55-1.fc38
URL: http://metacpan.org/dist/DateTime-TimeZone/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2801/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-DateTime-TimeZone


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2138492
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [Test-Announce] 2022-10-31 @ 16:00 UTC - Fedora 37 Blocker Review Meeting

2022-10-28 Thread Gary Buhrmaster
On Sat, Oct 29, 2022 at 12:44 AM Adam Williamson
 wrote:
>
> # F36 Blocker Review meeting

If this was a test to see if anyone noticed the title being
wrong, I am afraid I have failed that test for the entire
cycle.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Test-Announce] 2022-10-31 @ 16:00 UTC - Fedora 37 Blocker Review Meeting

2022-10-28 Thread Adam Williamson
# F36 Blocker Review meeting
# Date: 2022-10-31
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.libera.chat

Hi folks! We have 1 proposed Final freeze exception to review, but also
we can probably kick around the plans for the release process over the
next couple of weeks (hence the wide distribution on this mail - come
along if you want to talk about that!), so let's have a review meeting.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F36 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Test-Announce] Proposal to CANCEL: 2022-10-31 Fedora QA Meeting

2022-10-28 Thread Adam Williamson
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
have anything much for the agenda again. There will be a blocker review
meeting, though.

If you're aware of anything it would be useful to discuss this week,
please do reply to this mail and we can run the meeting.

Thanks folks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


libxml2-2.10.3-1.fc36 breaks (part of) GraphicsMagick

2022-10-28 Thread Michael J Gruber
With this libxml2 update:
```
gm convert -list format
...
gm convert: Unable to load module 
("/usr/lib64/GraphicsMagick-1.3.38/modules-Q16/coders/url.la: file not found")
```
In fact, `url.so` is there but cannot be dlopen'ed. This works after 
downgrading libxml2 to 2.9.
I noticed because my scribus failed to start today, and this was somehow tough 
to track down.
I still don't know whether libxml2 had an abi change without soname bump and 
whether a simple rebuild of GM would solve this (in particular, which one to 
file a big against). But since it was diificult to spot and more packages could 
be broken (without a clear FTI/FTBFS) I wanted to give a heads up here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Heads up home brewers - brewtarget update and license change

2022-10-28 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


CPE Weekly Update – Week 43 2022

2022-10-28 Thread Lenka Segura
*Hi everyone,This is a weekly report from the CPE (Community Platform
Engineering) Team.The report could be found at
https://communityblog.fedoraproject.org/cpe-weekly-update-week-43-2022
/.If
you want to receive weekly reports by emails in the future, please
subscribe to either https://communityblog.fedoraproject.org/
 or
https://discussion.fedoraproject.org/c/news/commblog/61
. We will stop
sending them in 2023.Regards,CPE Team*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread stan via devel
On Fri, 28 Oct 2022 14:59:54 -
"Sergey Mende"  wrote:

> thank you, I got the recipe from the previous conversations. I just
> asked if I could help with logs analysis or somehow else before I fix
> the issue.

Sorry for the misunderstanding.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Sergey Mende
Rich, stan,

thank you, I got the recipe from the previous conversations. I just asked if I 
could help with logs analysis or somehow else before I fix the issue.

Regards,
Sergey
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Richard W.M. Jones
On Fri, Oct 28, 2022 at 07:46:03AM -0700, stan via devel wrote:
> On Fri, 28 Oct 2022 13:08:19 -
> "Sergey Mende"  wrote:
> 
> > I upgraded from 35 to 36 in the beginning of Sept this year. The
> > migration failed. May I help somehow?
> 
> I used the advice from Tom Hughes in his earlier message to complete my
> failed migration.
> 
> # systemctl enable rpmdb-migrate
> # systemctl start rpmdb-migrate
> 
> When that completed, the migration was successfully done.
> 
> I am running F37, started as F35 rawhide, updated using dnf,
> usually daily, with reboots also usually daily.  I am currently running
> rpm-4.18.0-1.fc37.x86_64.

Correct -- while we're trying to find out how widespread the problem
is, the way to fix it on individual machines is as outlined above.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread stan via devel
On Fri, 28 Oct 2022 13:08:19 -
"Sergey Mende"  wrote:

> I upgraded from 35 to 36 in the beginning of Sept this year. The
> migration failed. May I help somehow?

I used the advice from Tom Hughes in his earlier message to complete my
failed migration.

# systemctl enable rpmdb-migrate
# systemctl start rpmdb-migrate

When that completed, the migration was successfully done.

I am running F37, started as F35 rawhide, updated using dnf,
usually daily, with reboots also usually daily.  I am currently running
rpm-4.18.0-1.fc37.x86_64.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: openvdb 10.0.0 build issue

2022-10-28 Thread Richard Shaw
With my zswap doubled I made it to 77% before it failed...

Time to disable LTO?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Sergey Mende
Hi,
I upgraded from 35 to 36 in the beginning of Sept this year. The migration 
failed. 
May I help somehow?

Regards,
Sergey.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


openvdb 10.0.0 build issue

2022-10-28 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Richard W.M. Jones
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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Tom Hughes via devel

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.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Richard W.M. Jones
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?]

> 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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-28 Thread Richard Shaw
On Fri, Oct 28, 2022 at 1:24 AM Adam Williamson 
wrote:

> On Thu, 2022-10-27 at 19:42 -0500, Richard Shaw wrote:
> > On Thu, Oct 27, 2022 at 5:15 PM Tom Rix  wrote:
> >
> > > Sorry, I did not run into the freeglut-devel problem with the manual
> build
> > >
> >
> > I think I have something funny going on with the conditionals. Initially
> > they were negative conditionals:
> >
> > %if ! 0%{?bootstrap} || ! 0%{?rhel}
> > %global docs 1
> > %global tests 1
> > %endif
> >
> >
> > And I noticed that the build was trying to pull in build deps that it
> > should not. As an experiment I changed it to a full positive conditional
> > and that seemed to have *MOSTLY* worked:
> >
> > %if 0%{?bootstrap} || 0%{?rhel}
> > %global docs 0
> > %global tests 0
> > %else
> > %global docs 1
> > %global tests 1
> > %endif
> >
> > The BR's are not getting pulled in, and yet, on the cmake command, both
> > docs and tests are still true, which from what I can tell should not be:
> >
> > %cmake -DCMAKE_CXX_STANDARD=14 \
> >-DOCIO_BUILD_DOCS=%{?docs:ON}%{?!docs:OFF} \
> >-DOCIO_BUILD_TESTS=%{?tests:ON}%{?!tests:OFF} \
> >-DOCIO_USE_HEADLESS=ON \
> >-DOCIO_INSTALL_EXT_PACKAGES=NONE \
> > %ifnarch x86_64
> >-DOCIO_USE_SSE=OFF \
> > %endif
> >-DOpenGL_GL_PREFERENCE=GLVND
> >
> > ...
> >
> > + /usr/bin/cmake -S . -B redhat-linux-build
> > -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> > -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
> > -DCMAKE_INSTALL_PREFIX:PATH=/usr
> > -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> > -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> > -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> > -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_CXX_STANDARD=14
> > *-DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON* -DOCIO_USE_HEADLESS=ON
> > -DOCIO_INSTALL_EXT_PACKAGES=NONE -DOpenGL_GL_PREFERENCE=GLVND
> >
> > So I'm pretty much at a WTF moment...
>
> I think the problem may be that this:
>
> %{?docs:ON}%{?!docs:OFF}
>
> will give you ON if %docs is *defined*, not if it's *truthy*.
>

Gotcha... I figured it was something I did, but I changed the top
conditional because it wasn't working properly, pulling in BRs that should
have been skipped. I'll refactor.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Fedora 37 compose report: 20221028.n.0 changes

2022-10-28 Thread 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 =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2136603] perl-CPAN-Perl-Releases-5.20221020 is available

2022-10-28 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2136603

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0221020-1.fc38  |0221020-1.fc38
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0221020-1.fc36  |0221020-1.fc36
   ||perl-CPAN-Perl-Releases-5.2
   ||0221020-1.fc35



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-b4e6424db7 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2136603
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Alexander Ploumistos
I've just checked 4 systems (2x Workstation, MATE and Cloud), and the
migration was successful on all of them. They were all upgraded to the
latest versions in testing at the time with dnf system-upgrade.
Regular package updates were performed weekly at the latest.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Tom Hughes via devel

The reason it hadn't completed is that rpmdb-migrate.service
was enabled on that machine.

Enabling (and starting) that service made it complete.

Tom

On 28/10/2022 12:24, Tom Hughes via devel wrote:

I have one machine that has failed.

It was an upgrade from 35 to 36 done using dnf distro-sync
but I have plenty of others done the same way that worked.

One difference is that it's a machine that wasn't upgraded
until August while other ones were done back in May as a
result of which the upgrade was:

   from rpm-4.17.1-3.fc35.x86_64
     to rpm-4.17.1-3.fc36.x86_64

while other machines were more like:

   from rpm-4.17.0-4.fc35.x86_64
     to rpm-4.17.0-10.fc36.x86_64

Tom

On 28/10/2022 11:49, Richard W.M. Jones wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
https://bugzilla.redhat.com/2042099

The RPM database is supposed to move from /var/lib/rpm to
/usr/lib/sysimage/rpm.  This was supposed to happen automatically when
you upgraded the rpm package from an earlier version to 4.17.0-10.fc36
(Feb-Mar 2022).

On several machines it is reported that the migration was only half-
completed.  The symptoms are that the RPM database is still in
/var/lib/rpm (/usr contains symlinks to it).  See typical output from
failed & successful migrations at the end of the email.

So _if_ you have rpm >= 4.17.0-10.fc36 installed:

  - Do you see the symptom of a failed migration?  Or does it appear
    to be successful?  (Or neither case??)

  - Did you:
 * Install F37 or Rawhide from scratch?
 * Upgrade using ordinary dnf update or similar?
 * Upgrade using dnf system-upgrade?
 * Some other install/upgrade method?

Rich.


** After a failed migration: **

$ ls -la /var/lib/rpm
total 339004
drwxr-xr-x.  2 root root  4096 Feb 16  2022 .
drwxr-xr-x. 76 root root  4096 Aug 23 13:28 ..
-rw-r--r--.  1 root root 0 Oct 18 14:28 .migratedb
-rw-r--r--.  1 root root 347095040 Oct 26 16:50 rpmdb.sqlite
-rw-r--r--.  1 root root 32768 Oct 27 15:28 rpmdb.sqlite-shm
-rw-r--r--.  1 root root 0 Oct 26 16:50 rpmdb.sqlite-wal
-rw-r--r--.  1 root root 0 Feb 16  2022 .rpm.lock

$ ls -la /usr/lib/sysimage/rpm
total 8
drwxr-xr-x. 2 root root 4096 Oct  5 12:05 .
drwxr-xr-x. 3 root root 4096 Feb  9  2022 ..
lrwxrwxrwx. 1 root root   34 Oct 18 14:28 .migratedb -> 
../../../../var/lib/rpm/.migratedb
lrwxrwxrwx. 1 root root   36 Oct 18 14:28 rpmdb.sqlite -> 
../../../../var/lib/rpm/rpmdb.sqlite
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-shm -> 
../../../../var/lib/rpm/rpmdb.sqlite-shm
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-wal -> 
../../../../var/lib/rpm/rpmdb.sqlite-wal
lrwxrwxrwx. 1 root root   33 Oct 18 14:28 .rpm.lock -> 
../../../../var/lib/rpm/.rpm.lock



** After a successful migration: **

$ ls -la /var/lib/rpm
lrwxrwxrwx. 1 root root 26 Sep  5 13:35 /var/lib/rpm -> 
../../usr/lib/sysimage/rpm


$ ls -la /usr/lib/sysimage/rpm
total 316324
drwxr-xr-x. 2 root root    91 Sep 17 23:03 .
drwxr-xr-x. 3 root root    17 Aug  9 14:27 ..
-rw-r--r--. 1 root root 323878912 Oct 27 16:12 rpmdb.sqlite
-rw-r--r--. 1 root root 32768 Oct 28 10:45 rpmdb.sqlite-shm
-rw-r--r--. 1 root root 0 Oct 27 16:12 rpmdb.sqlite-wal
-rw-r--r--. 1 root root 0 Sep  5 13:53 .rpm.lock






--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Failed RPM database migrations

2022-10-28 Thread Tom Hughes via devel

I have one machine that has failed.

It was an upgrade from 35 to 36 done using dnf distro-sync
but I have plenty of others done the same way that worked.

One difference is that it's a machine that wasn't upgraded
until August while other ones were done back in May as a
result of which the upgrade was:

  from rpm-4.17.1-3.fc35.x86_64
to rpm-4.17.1-3.fc36.x86_64

while other machines were more like:

  from rpm-4.17.0-4.fc35.x86_64
to rpm-4.17.0-10.fc36.x86_64

Tom

On 28/10/2022 11:49, Richard W.M. Jones wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
https://bugzilla.redhat.com/2042099

The RPM database is supposed to move from /var/lib/rpm to
/usr/lib/sysimage/rpm.  This was supposed to happen automatically when
you upgraded the rpm package from an earlier version to 4.17.0-10.fc36
(Feb-Mar 2022).

On several machines it is reported that the migration was only half-
completed.  The symptoms are that the RPM database is still in
/var/lib/rpm (/usr contains symlinks to it).  See typical output from
failed & successful migrations at the end of the email.

So _if_ you have rpm >= 4.17.0-10.fc36 installed:

  - Do you see the symptom of a failed migration?  Or does it appear
to be successful?  (Or neither case??)

  - Did you:
 * Install F37 or Rawhide from scratch?
 * Upgrade using ordinary dnf update or similar?
 * Upgrade using dnf system-upgrade?
 * Some other install/upgrade method?

Rich.


** After a failed migration: **

$ ls -la /var/lib/rpm
total 339004
drwxr-xr-x.  2 root root  4096 Feb 16  2022 .
drwxr-xr-x. 76 root root  4096 Aug 23 13:28 ..
-rw-r--r--.  1 root root 0 Oct 18 14:28 .migratedb
-rw-r--r--.  1 root root 347095040 Oct 26 16:50 rpmdb.sqlite
-rw-r--r--.  1 root root 32768 Oct 27 15:28 rpmdb.sqlite-shm
-rw-r--r--.  1 root root 0 Oct 26 16:50 rpmdb.sqlite-wal
-rw-r--r--.  1 root root 0 Feb 16  2022 .rpm.lock

$ ls -la /usr/lib/sysimage/rpm
total 8
drwxr-xr-x. 2 root root 4096 Oct  5 12:05 .
drwxr-xr-x. 3 root root 4096 Feb  9  2022 ..
lrwxrwxrwx. 1 root root   34 Oct 18 14:28 .migratedb -> 
../../../../var/lib/rpm/.migratedb
lrwxrwxrwx. 1 root root   36 Oct 18 14:28 rpmdb.sqlite -> 
../../../../var/lib/rpm/rpmdb.sqlite
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-shm -> 
../../../../var/lib/rpm/rpmdb.sqlite-shm
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-wal -> 
../../../../var/lib/rpm/rpmdb.sqlite-wal
lrwxrwxrwx. 1 root root   33 Oct 18 14:28 .rpm.lock -> 
../../../../var/lib/rpm/.rpm.lock


** After a successful migration: **

$ ls -la /var/lib/rpm
lrwxrwxrwx. 1 root root 26 Sep  5 13:35 /var/lib/rpm -> 
../../usr/lib/sysimage/rpm

$ ls -la /usr/lib/sysimage/rpm
total 316324
drwxr-xr-x. 2 root root91 Sep 17 23:03 .
drwxr-xr-x. 3 root root17 Aug  9 14:27 ..
-rw-r--r--. 1 root root 323878912 Oct 27 16:12 rpmdb.sqlite
-rw-r--r--. 1 root root 32768 Oct 28 10:45 rpmdb.sqlite-shm
-rw-r--r--. 1 root root 0 Oct 27 16:12 rpmdb.sqlite-wal
-rw-r--r--. 1 root root 0 Sep  5 13:53 .rpm.lock




--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2136603] perl-CPAN-Perl-Releases-5.20221020 is available

2022-10-28 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2136603

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0221020-1.fc38  |0221020-1.fc38
   ||perl-CPAN-Perl-Releases-5.2
   ||0221020-1.fc36
 Status|ON_QA   |CLOSED
Last Closed||2022-10-28 11:15:45



--- Comment #7 from Fedora Update System  ---
FEDORA-2022-2fa9c34d68 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2136603
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Failed RPM database migrations

2022-10-28 Thread Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
https://bugzilla.redhat.com/2042099

The RPM database is supposed to move from /var/lib/rpm to
/usr/lib/sysimage/rpm.  This was supposed to happen automatically when
you upgraded the rpm package from an earlier version to 4.17.0-10.fc36
(Feb-Mar 2022).

On several machines it is reported that the migration was only half-
completed.  The symptoms are that the RPM database is still in
/var/lib/rpm (/usr contains symlinks to it).  See typical output from
failed & successful migrations at the end of the email.

So _if_ you have rpm >= 4.17.0-10.fc36 installed:

 - Do you see the symptom of a failed migration?  Or does it appear
   to be successful?  (Or neither case??)

 - Did you:
* Install F37 or Rawhide from scratch?
* Upgrade using ordinary dnf update or similar?
* Upgrade using dnf system-upgrade?
* Some other install/upgrade method?

Rich.


** After a failed migration: **

$ ls -la /var/lib/rpm
total 339004
drwxr-xr-x.  2 root root  4096 Feb 16  2022 .
drwxr-xr-x. 76 root root  4096 Aug 23 13:28 ..
-rw-r--r--.  1 root root 0 Oct 18 14:28 .migratedb
-rw-r--r--.  1 root root 347095040 Oct 26 16:50 rpmdb.sqlite
-rw-r--r--.  1 root root 32768 Oct 27 15:28 rpmdb.sqlite-shm
-rw-r--r--.  1 root root 0 Oct 26 16:50 rpmdb.sqlite-wal
-rw-r--r--.  1 root root 0 Feb 16  2022 .rpm.lock

$ ls -la /usr/lib/sysimage/rpm
total 8
drwxr-xr-x. 2 root root 4096 Oct  5 12:05 .
drwxr-xr-x. 3 root root 4096 Feb  9  2022 ..
lrwxrwxrwx. 1 root root   34 Oct 18 14:28 .migratedb -> 
../../../../var/lib/rpm/.migratedb
lrwxrwxrwx. 1 root root   36 Oct 18 14:28 rpmdb.sqlite -> 
../../../../var/lib/rpm/rpmdb.sqlite
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-shm -> 
../../../../var/lib/rpm/rpmdb.sqlite-shm
lrwxrwxrwx. 1 root root   40 Oct 18 14:28 rpmdb.sqlite-wal -> 
../../../../var/lib/rpm/rpmdb.sqlite-wal
lrwxrwxrwx. 1 root root   33 Oct 18 14:28 .rpm.lock -> 
../../../../var/lib/rpm/.rpm.lock


** After a successful migration: **

$ ls -la /var/lib/rpm
lrwxrwxrwx. 1 root root 26 Sep  5 13:35 /var/lib/rpm -> 
../../usr/lib/sysimage/rpm

$ ls -la /usr/lib/sysimage/rpm
total 316324
drwxr-xr-x. 2 root root91 Sep 17 23:03 .
drwxr-xr-x. 3 root root17 Aug  9 14:27 ..
-rw-r--r--. 1 root root 323878912 Oct 27 16:12 rpmdb.sqlite
-rw-r--r--. 1 root root 32768 Oct 28 10:45 rpmdb.sqlite-shm
-rw-r--r--. 1 root root 0 Oct 27 16:12 rpmdb.sqlite-wal
-rw-r--r--. 1 root root 0 Sep  5 13:53 .rpm.lock


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [Test-Announce] Fedora Linux 37 Final is NO-GO

2022-10-28 Thread Neal Gompa
On Fri, Oct 28, 2022 at 5:27 AM Michael J Gruber  wrote:
>
> In this context, since we are still in freeze:
>
> Can dnf distinguish between updates in testing and updates in testing 
> submitted for stable?
>
> People might want to dist-upgrade to F37 now (I'm not critizing the release 
> decision) and want to get "the same updates as on F36". Ideally, no F36 
> package in stable should be ahead of its F37 counterpart in stable, but due 
> to the long freeze - or urgent fixes - reality might be different.
>
> It's fair enogh to say: If you want beta/RC I'll give you beta (with 
> updates-testing) ... and finally, if you turn off updates-testing at release 
> time, you'll end up with non-testing packages at some point in time after, of 
> course.

No, there's no metadata for distinguishing that, since those queued
for stable are merely waiting for a compose run that allows them to go
through. Keep in mind, most updates in testing today will be queued
for stable in two weeks anyway.


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Inactive packagers to be removed after the F37 release

2022-10-28 Thread Alexander Bokovoy

Hi,

On to, 15 syys 2022, Kevin Fenzi wrote:

> CentOS folks still use certs for their koji:
> https://wiki.centos.org/Authentication#TLS_certificate
> (and thats using the same account system/ipa servers as fedora).
>
> > I hope we can plan to work together on this improvement again, similar
> > how we did with the initial rewrite of Fedora Accounts on top of
> > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> > perhaps CPA team could consider scheduling this effort as part of the
> > initiatives.
>
> Yeah, I would like that. Perhaps we could setup a meeting soon and
> dicuss plans? I'm open to video meeting, but we could also do IRC to
> keep things more open...

I am open to it too, may be in couple weeks or so, to allow interested
parties to prepare.


Sure. Can you schedule something when you are ready/available and we can
go from there.


It took me more than couple weeks...

I have been working on an article to describe what we are doing in
FreeIPA and SSSD world with authentication against various identity
providers and how that could help the Fedora Infrastructure.

Long story short, there are now two articles:

Part 1, where I am talking about Fedora infrastructure aspects: 
https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra/


Part 2, where FreeIPA-specific improvements and details discussed:
https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra-2/



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [Test-Announce] Fedora Linux 37 Final is NO-GO

2022-10-28 Thread Michael J Gruber
In this context, since we are still in freeze:

Can dnf distinguish between updates in testing and updates in testing submitted 
for stable?

People might want to dist-upgrade to F37 now (I'm not critizing the release 
decision) and want to get "the same updates as on F36". Ideally, no F36 package 
in stable should be ahead of its F37 counterpart in stable, but due to the long 
freeze - or urgent fixes - reality might be different.

It's fair enogh to say: If you want beta/RC I'll give you beta (with 
updates-testing) ... and finally, if you turn off updates-testing at release 
time, you'll end up with non-testing packages at some point in time after, of 
course.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-28 Thread Adam Williamson
On Thu, 2022-10-27 at 19:42 -0500, Richard Shaw wrote:
> On Thu, Oct 27, 2022 at 5:15 PM Tom Rix  wrote:
> 
> > Sorry, I did not run into the freeglut-devel problem with the manual build
> > 
> 
> I think I have something funny going on with the conditionals. Initially
> they were negative conditionals:
> 
> %if ! 0%{?bootstrap} || ! 0%{?rhel}
> %global docs 1
> %global tests 1
> %endif
> 
> 
> And I noticed that the build was trying to pull in build deps that it
> should not. As an experiment I changed it to a full positive conditional
> and that seemed to have *MOSTLY* worked:
> 
> %if 0%{?bootstrap} || 0%{?rhel}
> %global docs 0
> %global tests 0
> %else
> %global docs 1
> %global tests 1
> %endif
> 
> The BR's are not getting pulled in, and yet, on the cmake command, both
> docs and tests are still true, which from what I can tell should not be:
> 
> %cmake -DCMAKE_CXX_STANDARD=14 \
>-DOCIO_BUILD_DOCS=%{?docs:ON}%{?!docs:OFF} \
>-DOCIO_BUILD_TESTS=%{?tests:ON}%{?!tests:OFF} \
>-DOCIO_USE_HEADLESS=ON \
>-DOCIO_INSTALL_EXT_PACKAGES=NONE \
> %ifnarch x86_64
>-DOCIO_USE_SSE=OFF \
> %endif
>-DOpenGL_GL_PREFERENCE=GLVND
> 
> ...
> 
> + /usr/bin/cmake -S . -B redhat-linux-build
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
> -DCMAKE_INSTALL_PREFIX:PATH=/usr
> -DINCLUDE_INSTALL_DIR:PATH=/usr/include
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
> -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_CXX_STANDARD=14
> *-DOCIO_BUILD_DOCS=ON -DOCIO_BUILD_TESTS=ON* -DOCIO_USE_HEADLESS=ON
> -DOCIO_INSTALL_EXT_PACKAGES=NONE -DOpenGL_GL_PREFERENCE=GLVND
> 
> So I'm pretty much at a WTF moment...

I think the problem may be that this:

%{?docs:ON}%{?!docs:OFF}

will give you ON if %docs is *defined*, not if it's *truthy*.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue