kellin reported a new issue against the project: `pungi-fedora` that you are following:
The way we rsync composes today is a one-liner bash script that is not very durable and requires that a release engineer babysit it through the entire four hour rsync process.
I am going to make this more durable, however, it will also slightly change our process behind the scenes.
Today if a process works or is DOOMED after a full run it is assigned an RC release number. (EG: 1.1, 1.2, 1.3, etc). If the compose fails quickly from something such as a failure to have signed packages then it will not be assigned a release candidate.
Per @mohanboddu there is not a durable way to identify the all of the different ways the special case DOOMed composes occur so they will be assigned an RC number after the automation is deployed.
The only visible change will be extra gaps in the RC composes in /pub/alt/stage that represent these extra numbers being inserted to the sequence.
@mohanboddu is fine with this change; does anyone else have objections?
@ausil , @kevin , @puiterwijk please let me know. The initial script PR will be coming within the next two business days.
To reply, visit the link below or just reply to this email
(Posting to many mailing lists for visibility. I apologize if you see
this more times than you'd like.)
You may have already seen my Community Blog post about changing the
Release Readiness meeting process. The meeting has questionable value
in the current state, so I want to make it more useful. We'll do this
by having teams self-report readiness issues on a dedicated wiki
page beginning now. This gives the community time to chip in and
help with areas that need help without waiting until days before the
I invite teams to identify a representative to keep the wiki page up
to date. Update it as your status changes and I'll post help requests
in my weekly CommBlog posts and the FPgM office hours IRC
meeting. The Release Readiness meeting will be shortened to one hour
and will review open concerns instead of polling for teams that may or
may not be there. We will use the logistics mailing list to discuss
issues and make announcements, so I encourage representatives to join
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Based on https://framadate.org/fedorareleng we decided to move the
releng meeting to every Tuesday starting at 16:00 UTC and it will be
an hour long meeting which will end at 17:00 UTC.
Please update your calendars and hope to see you all at our next
meeting on March 03 2020 at 16:00 UTC.
I don't have an answer for your questions, so I have copied the
Release Engineering team who can give you the answers you need. I love
this spin idea, and am happy to help in whatever way I can.
On Tue, Feb 4, 2020 at 11:59 AM Vojtech Polasek <vpolasek(a)redhat.com> wrote:
> Hello Ben,
> my name is Vojta and I am a blind software engineer working for RH in
> Brno, Czech Republic. I am working in platform security, but this is not
> that important for this mail.
> Me and several other friends from RH are working on a special Linux
> distribution for blind and visually impaired users. This distribution is
> currently based on Fedora. We would like to make a spin from it. But I
> have a special question, see below.
> I know that if I apply for a spin, the lab infrastructure can create ISO
> live images from kickstarts. That is nice. But...
> While demonstrating our distro to potential users, we chose a bit
> different way than others. Instead of live images shipped on USB drives,
> we chose to create a full installation of the system and place it on the
> USB drive. This has several benefits compared to live images:
> - changes made by users are persistent and not limited to 4 Gb
> - it is possible to partition the USB drive and create an additional
> partition formatted as Exfat for transfering data between Linux and
> non-Linux world
> - users can come to whatever computer and boot the system with their
> personal configuration, data, software...
> - users can have almost the same experience as if the system was
> installed on their primary hard drive
> It can have its drawbacks but we used this approach already two times
> while presenting our "spin" on special workshops and we think it worked
> very well.
> I am not against live images and if we create a Fedora spin, we will
> definitely offer them as well. But I believe the described alternative
> approach has its benefits-
> The whole process is described here:
> Currently we use a VM to perform an automated kickstart installation and
> then we transfer the raw image on an USB drive.
> My question now is: could the infrastructure used for production of
> Fedora spins be used to create not only live images but also our custom
> raw disk images? If not, could we at least use those resources to store
> such images?
> Feel free to ask if you need further clarifications etc.
> Best regards,
He / Him / His
Fedora Program Manager
Dear Fedora release engineers,
I am trying to working on a bootstrap on a new arch for Fedora, but I
would like to know the big picture of dependency info among a lot of
I know how to get this info of one rpm. But for 10s, 100s, or even
1000s rpms, Do we have existing scripts to help engineers to figure
out the dependency info among a lot of them?
Maybe there are some existing scripts we can use, or please provide
some advice or suggestion??
Senior Software Engineer
Red Hat Software (Beijing) Co.,Ltd.
Ph: +86 18102768846 (mobile)
Level 9, North Tower C,Raycom Infotech Park,
No.2 Ke Xue Yuan Nanlu, Zhongguancun,
Haidian District, Beijing,China
You are kindly invited to the meeting:
Fedora Release Engineering on 2020-02-26 from 16:00:00 to 17:00:00 UTC
The meeting will be about:
Fedora Release Engineering weekly meeting
On Sat, 2020-02-22 at 12:42 -0800, Kevin Fenzi wrote:
> On Tue, Feb 18, 2020 at 09:33:42PM -0700, Ken Dreyer wrote:
> > On Mon, Feb 17, 2020 at 10:52 AM Adam Williamson
> > <adamwill(a)fedoraproject.org> wrote:
> > > Since this is an API endpoint of a real system which needs to be
> > > updated correctly when the release events actually happen, it
> > > should
> > > have the benefits pkgdb used to be (the information should be
> > > reliable
> > > and timely)
> > Do we have stats on how many hits per second that current endpoint
> > receives?
> It looks like it gets less than 100k/day. So, one or less per second.
Are they evenly-spaced, though? I don't recall exactly how fancy the
GNOME Software code is, but it seems at least possible that these
check-ins aren't evenly spaced out but come in clumps...
BTW, I've ported fedfind from collections to Bodhi in 4.4.0, 4.4.1 is
in updates-testing now.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP adamw AT happyassassin . net