Hi, Everyone.
My name is Jun Miao(Fedora People: miaojun0823) and I'm a linux software engineer on Linux OS Systems Engineering at Intel.
In my position I work with Operation System Vendor, develop and enable cloud software with Intel platforms and technologies,
solve customer issues in Linux kernel side, make Intel software deployment plan, increase customer adherence to Intel platform and technologies.
For the intel some new features work well and powerfully, at the same time I`m also very interested in becoming a Fedora package Co- maintainer to provide the latest performance optimizations and enable some feature platforms on CentOS Stream, Fedora and RHEL. My now responsibility is maintaining Tboot/TDX/SGX Fedora package in future.
Although I`m using RHEL for a long time to build kernel and workstation, I join to ramping up Fedora packaging last year.
I've learned about Fedora project from member@yunyings @gang wei.
And learn to how to create a RPM from spec file, Using the Koji build system, join the review Request mail list to learn, and help to comment others new package review request .
Such as: Bug 2036288 Bug 2036105 Bug 2036468 Bug 2028189 Bug 2036399 Bug 2038730 Bug 2036105.
I need a kindly sponsor help me to package Group to co- maintainer about Tboot/TDX/SGX and so on.
I have submit a request in packager-sponsors: https://pagure.io/packager-sponsors/issue/513
I live in Peking from CN. Outside of work I love swimming(training for Increase freestyle speed), playing piano, music and so on. I have two boys and a kindly Schnauze dog.
I have wanted for some time to contribute to the community and I am looking forward to being a part of it now.
Looking forward to contributing where I can.
Best wishes
Jun
Greetings,
I'm Garry Williams and I recently retired from a software development
job and now want to spend more time contributing to Fedora.
My developer experience started in the late sixties with IBM S/370
Assembler. I had various jobs programming and software support of IBM
MVT and MVS operating systems, mostly with Amdahl Corporation. After
that I started working with Unix and Solaris 2.6 in the late nineties.
My first Linux experience was Red Hat Linux 5.2 (if I remember
correctly :-). Later I used Mandrake, later still Mandriva after that
and came to Fedora with Fedora Core 5. I've used Fedora ever since
for my personal machines. My last job (Comcast) involved development
of Web-based services and applications that deployed on Debian
machines in various company data centers around the US.
I have not contributed much aside from regular bug reports and a few
PRs here and there over the years. In my spare time, I am an avid
bridge player. That brings me to a simple package I have prepared,
deal - a Bridge Hand Generator. My review request is:
https://bugzilla.redhat.com/show_bug.cgi?id=2040118
--
Garry T. Williams
In accordance with the Fedora non-responsive maintainer policy, I am
attempting to contact Aaron Conole (aconole).
Does anyone know how to contact this package maintainer? Direct email and
bug reports have had no response.
This is in reference to these open bugs with lldpd:
https://bugzilla.redhat.com/show_bug.cgi?id=1797336https://bugzilla.redhat.com/show_bug.cgi?id=1921441https://bugzilla.redhat.com/show_bug.cgi?id=1984478https://bugzilla.redhat.com/show_bug.cgi?id=2040390
Non-responsive bug has been filed:
https://bugzilla.redhat.com/show_bug.cgi?id=2041362
Output from fedora-active-user:
Last action on koji:
Fri, 24 Sep 2021 tag_package_owners entry created by mohanboddu [still
active]
Last package update on bodhi:
No activity found on bodhi
Last actions performed according to fedmsg:
- david.sastre(a)redhat.com commented on RHBZ#2041362 'Non-responsive
maintainer check for acon...' on 2022-01-17 09:33:36
- david.sastre(a)redhat.com filed a new bug RHBZ#2041362 'Non-responsive
maintainer check for acon...' on 2022-01-17 09:33:36
- david.sastre(a)redhat.com updated 'cc' on RHBZ#2040390 'CVE-2021-43612
lldpd: heap-based buffer ...' on 2022-01-17 09:19:56
- bcotton(a)redhat.com updated 'bug_status' and 'resolution' on
RHBZ#1921441 'CVE-2020-27827 lldpd: lldp/openvswitch: ...' on 2021-11-30
18:51:21
- bcotton(a)redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd:
lldp/openvswitch: ...' on 2021-11-30 18:51:21
- bcotton(a)redhat.com commented on RHBZ#1876763 'F33FailsToInstall: lldpd'
on 2021-11-30 18:40:14
- bcotton(a)redhat.com updated 'bug_status' and 'resolution' on
RHBZ#1876763 'F33FailsToInstall: lldpd' on 2021-11-30 18:40:14
- bcotton(a)redhat.com commented on RHBZ#1876763 'F33FailsToInstall: lldpd'
on 2021-11-04 17:21:25
- bcotton(a)redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd:
lldp/openvswitch: ...' on 2021-11-04 17:11:37
- jose.p.oliveira.oss(a)gmail.com updated 'isobsolete' on RHBZ#1797336
'lldpd-1.0.12 is available' on 2021-09-19 02:30:31
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr
== Summary ==
Currently, the RPM databases is located in `/var`. Let's move it to
`/usr`. The move is already under way in rpm-ostree-based
installations, and in (open)SUSE.
== Owner ==
* Name: [[User:chrismurphy| Chris Murphy]], [[User:Salimma|Michel
Alexandre Salim]], [[User:Ngompa|Neal Gompa]]
* Email: bugzilla(a)colorremedies.com, michel(a)michel-slm.name, ngompa13(a)gmail.com
== Detailed Description ==
=== Current location ===
<pre>/var/lib/rpm</pre>
=== New location ===
<pre>/usr/lib/sysimage/rpm</pre>
<code>/var/lib/rpm</code> will be a symlink pointing to
<code>/usr/lib/sysimage/rpm</code>
Changing the file system layout to accommodate a snapshot+rollback
regime is implied, but not required by this proposal. For example,
Fedora has long placed `/home` on a separate subvolume (or file
system) so it can be isolated from system root. Likewise, it makes
sense to isolate `/var/log` and possibly `/var/lib/libvirt/images` so
these locations continue to carry forward in time, even if the system
root does a rollback.
== Feedback ==
There will be no change to DNF as part of this change proposal. DNF's
history will remain in `/var` until DNF 5. Discussion continues about
the effect of a snapshot+rollback regime on DNF history.
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000769.html
Relocate DNF history to /usr.]
Upstream RPM accept the change, but institutionally don't like the
loss or weakening of a
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
very well known location] for the database, and
[http://lists.rpm.org/pipermail/rpm-ecosystem/2021-December/000781.html
anticipate complaints].
== Benefit to Fedora ==
* The RPM database primarily describes the state of `/usr`. Storing
the databases in `/usr` will more easily facilitate OS rollback,
without affecting `/var`.
* Helps align Fedora variants with each other
** rpm-ostree based systems (including CoreOS, IoT, Silverblue,
Kinoite) already use `/usr/lib/sysimage` for rpmdb.
* Consistency with another RPM-based distro, (open)SUSE has made this change
* Accounts for various snapshot+rollback regimes, i.e. it's a
beneficial change whether Btrfs or device-mapper based regimes.
== Scope ==
* Proposal owners:
** changes in rpm package
*** create the new path
*** create a symlink for the old path pointing to new path
* Other developers:
** changes in SElinux policy
* Release engineering: [https://pagure.io/releng/issue/10441 #Releng
issue 10441]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Change will be applied to offline upgrades, similar to the RPM sqlite
database change. A systemd service will move the rpmdb from /var to
/usr, then create a symlink pointing to /usr from /var.
# Create `/usr/lib/sysimage/rpm` (rpm package will do this at preinst)
# Create symlinks in `/usr/lib/sysimage/rpm/` pointing to files in
`/var/lib/rpm/` (rpm package will do this at preinst)
# Change the dbpath in `/usr/lib/rpm/macros` to
`/usr/lib/sysimage/rpm` (rpm package will be patched to do this on
F36+)
# Request rpm rebuild the database (done via systemd service)
# Remove `/var/lib/rpm` and create a symlink `/var/lib/rpm` ->
`/usr/lib/sysimage/rpm` (done via systemd service)
== How To Test ==
# Perform a new clean install, or upgrade a system
# Check that `/var/lib/rpm` is a symlink to `/usr/lib/sysimage/rpm`
# Check that `/usr/lib/sysimage/rpm` is populated with at least
`rpmdb.sqlite`, possibly also `rpmdb.sqlite-shm` and
`rpmdb.sqlite-wal`
# Confirm `rpm -q <package>` and/or `rpm -qa` still work
== User Experience ==
* symlink `/var/lib/rpm` -> `/usr/lib/sysimage/rpm`
Otherwise, the change should be invisible to users.
== Dependencies ==
* `rpm-ostree` probably should make `/usr/share/rpm` a symlink to
`/usr/lib/sysimage/rpm`, rather than the reverse as it is currently.
* `PackageKit` might use inotify on `/var/lib/rpm` need to check if it
does and whether it should be changed or add the additional path
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? Yes
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi all,
I’ve had a review of the retry tool at https://bugzilla.redhat.com/show_bug.cgi?id=2017119, but I need help with a sponsor.
Happy to try review some other packages in return, but will need a bit of hand holding.
Regards,
Graham
—
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20220116.0):
ID: 1106135 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1106135
ID: 1106146 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1106146
Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg