Planned Outage: darkserver upgrade - 2016-01-29 10:30 UTC
There will be an outage starting at 2016-01-29 10:30 UTC, which will last approximately 3 hours.
During the outage the webservice will not be available for any queries.
To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:
date -d '2016-01-29 10:30 UTC'
Reason for outage: Upgrading darkserver to 1.0 release, this will require some database upgrades.
Affected Services: darkserver.fedoraproject.org
Services not listed are not affected by this outage.
Contact Information: #fedora-admin
Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/5076
Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.
Fedora Cloud Engineer
CPython Core Developer
CentOS Cloud SIG lead
Greetings and happy new year!
You are getting this email because you are in the 'fi-apprentice' group
in the fedora account system (or are reading this on the
Feel free to reply just directly to me, or cc the infrastructure list
for everyone to see and comment on.
At the first of every month(or so), I am going to be sending out an
email like this one. I would like feedback on how things are going for
I'd like to ask for everyone to send me a quick reply with the
following data or anything related you can think of that might help us
make the apprentice program more useful.
0. Whats your fedora account system login?
1. Have you logged in and used your fi-apprentice membership to look at
our machines/setup in the last month? Do you plan to?
2. Has it helped you decide any area you wish to focus on or contribute
3. Have you looked at or been able to work on any of the fi-apprentice
4. Do you still wish to be a member of the group? If not (for whatever
reason) could you provide any hints to help others down the road?
5. Is there any help or communication or ideas you have that would help
you do any of the above?
6. What do you find to be the hardest part of getting involved?
Finding things to work on? Getting attention from others to help you?
Finding tickets in your interest area?
7. Have you been able to make any weekly irc meetings? Do you find them
helpful or interesting?
8. Have you logged into our Gobby instance and read/seen/added to our
meeting agenda? https://fedoraproject.org/wiki/Gobby
9. What are you most looking forward to in 2016?
Any other general feedback is also quite welcome, including
improvements to this email, the wiki page, etc.
Any folks I do not hear from in the next week will be removed from the
group. (Note that it's easy to be readded when you have time or
whatever and it's nothing at all personal, we just want to keep the
group up to date with active folks).
Thanks, and looking forward to your feedback!
The infrastructure team will be having it's weekly meeting tomorrow,
2016-01-21 at 18:00 UTC in #fedora-meeting on the freenode network.
We have a gobby document
(see: https://fedoraproject.org/wiki/Gobby )
fedora-infrastructure-meeting-next is the document.
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.
If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.
= Introduction =
This shared document is for the next fedora infrastructure meeting.
We will use it over the week before the meeting to gather status and info and
discussion items and so forth, then use it in the irc meeting to transfer
information to the meetbot logs.
= Meeting start stuff =
#startmeeting Infrastructure (2016-01-21)
#chair smooge relrod nirik abadger1999 lmacken dgilmore mdomsch threebean pingou puiterwijk pbrobinson
#topic New folks introductions / Apprentice feedback
= Status / information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need to discuss)
(Please use #info <the thing> - your name)
#topic announcements and information
#info Applied updates to most machines (but no reboots) - kevin
#info added some space to ppc, s390, and arm koji storage - kevin
#info composer.stg is now Fedora 23 (to help with pungi4 work) - kevin
#info We now have a manual playbook to sync fas db from prod -> stg - kevin
#info Wrote up info about our datacenter visit last week: - kevin
= Things we should discuss =
We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus or decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use #topic your discussion topic - your username)
#topic Tech Debt Week Retrospective
#topic FY16 items to finish up before the fiscal year ends - kevin
= Learn about some application or setup in infrastructure =
(This section, each week we get 1 person to talk about an application or setup
that we have. Just going over what it is, how to contribute, ideas for improvement,
etc. Whoever would like to do this, just add the info in this section. In the
event we don't find someone to teach about something, we skip this section
and just move on to open floor.)
2016-01-14 - ?
#topic Learn about:
= Meeting end stuff =
#topic Open Floor
This was brought up on the devel list.
I think it's a great idea... standardized subject lines and headers for
our things that send emails seems like a nice idea to me. Not sure how
many places would need adjustment (FMN for sure).
Possibly this would need adjustment in fedmsgs too?
Begin forwarded message:
Date: Sat, 16 Jan 2016 13:34:12 +0000
From: "Richard W.M. Jones" <rjones(a)redhat.com>
Subject: Standard, consistent subject lines for automated emails
Here are a small collection of subject lines of emails sent
automatically to me by various Fedora systems in the past few days:
Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
Subject: rjones's libguestfs-1.33.1-2.fc24 completed
Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
Subject: Broken dependencies: libguestfs
Subject: ABRT report for package gnome-boxes has reached 10 occurrences
Subject: [Bug 1269975] svirt very occasionally prevents parallel
libvirt [..] Subject: Fedora 'packager' sponsor needed for suanand
Subject: sailer's mingw-sqlite-220.127.116.11-1.fc24 failed to build
Subject: libguestfs's builds are back to normal in f24
Subject: dchen pushed to ocaml-lwt (el6). "New upstream version 2.2.0."
The only consistent thing is there's nothing consistent about them :-/
I'd like to propose a very lightweight "standard" for subject lines of
(1) The first word should be the package name which the email
concerns. If the email is not about a package, but about a person,
then the first word should be the FAS username of that person.
(2) The second word should be the status, reflecting what the reader
needs to know or do, for example "succeeded", "failed", "submitted".
The above subject lines might become (chopped to 72 characters to
simulate what you might see in a text-based email reader):
Subject: auto-buildrequires passed: upgradepath FEDORA-2015-850e89be8b
Subject: auto-buildrequires submitted: auto-buildrequires-1.2-1.fc23
Subject: libguestfs completed: rjones's libguestfs-1.33.1-2.fc24 build c
Subject: libguestfs passed: rpmlint libguestfs-1.33.1-2.fc24
Subject: libguestfs failed: Broken dependencies found in package libgues
Subject: gnome-boxes failed: ABRT report for package gnome-boxes has rea
Subject: selinux-policy comment: [Bug 1269975] svirt very occasionally p
Subject: suanand requested: Fedora 'packager' sponsor needed for suanand
Subject: mingw-sqlite failed: sailer's mingw-sqlite-18.104.22.168-1.fc24 fail
Subject: libguestfs passed: libguestfs's builds are back to normal in f2
Subject: ocaml-lwt pushed: dchen pushed to ocaml-lwt (el6). "New upstre
Maybe you have some better ideas?
A related topic is headers, which could be used for filtering.
Various systems add headers -- see examples below -- but again there's
not much consistency and the headers aren't particularly useful for
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones Read my programming and virtualization
blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from
devel mailing list
At Flock, we talked about scheduling some kind of regular
technical-debt-fighting week to happen every so often - some period of
time where we don't do any new features (and even try to de-prioritize
interrupt-driven stuff) and focus on shoring up, cleaning up,
tightening the bolts, etc.
Here are some things broadly to think about:
- Add unit tests where there are none. Increase "code coverage".
- Write docs (and make diagrams!) where there are none.
- Reduce code duplication, and increase code re-use where appropriate.
- Break up ultra long methods, classes, and files into more
- Remove half-implemented features!
- Remove dead code!!
- Add comments where there are none, and correct inaccurate comments.
- Deal with the existential questions facing the code that none of us
wants to touch.
- Increase happiness and general zest for life.
Time-wise, how about we try and schedule a week to try this on the
first week back from the holiday break -- a New Year, a New
Infrastructure(!) That would be January 4-8th.
Here's a question I have. It seems like we could approach this in two
- We could select one or two projects we want to prioritize, and try
to do *all* of the best-practices things to them.
- We could select one or two of the best-practices things, and try to
do them to *all* of our projects.
Or.. something inbetween. If you have a preferences here, chime in on
the list, or we can take this up in our IRC meeting at the beginning
of December, too.
As an aside, it would be especially fun if we could keep track of our
collective damage on some kind of scoreboard (it doesn't have to be
automatic, even manual pen-and-paper would work) so we can produce a
nice summary blogpost at the end and thus herald in 2016, a year of
working code, less fires, and quiet mornings where we sip our coffee
and read email.
 - http://threebean.org/presentations/debt-services-flock15/
 - https://apps.fedoraproject.org/calendar/meeting/3183/
Good Morning everyone,
I just cut a new pkgdb2 release: 2.0.3
Here is the changelog:
* Fri Jan 15 2016 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 2.0.3-1
- Update to 2.0.3
- Fix fedmenu in the timeline page (Mikolaj Izdebski)
- Adjust the example configuration file for fedmenu
- Adjust the runserver script to make it easier to specify a configuration file
- Fix the koschei button so that it doesn't change the monitoring status in the
- Fix link to koji for packages having non-alphanumerical characters in their
name (such as a `+`)
It is happily running in stg and prod.
Smooge (thanks!) is putting together updated yum (uh, and I guess dnf;
time to start calling this collectively something else) stats for me,
and I noticed a really weird thing in the data.
On October 14, 2014 (and consistent with the period before), Fedora 12
through 15 log these numbers: 5913, 5179, 12221, 3370. On the next
day, October 15, they log 293, 167, 155, 115 — and similar ever after.
Releases before F12 continue on the same trend they had previously, as
do F16 and on. (Well, F16 does drop from 5602 to 4305, but the
day-to-day numbers are very bouncy and the trend was in that direction
I had previously assumed that this was some big hosting provider
switching away from F14, but when I looked more closely at the data, I
see it happened for _all_ these releases.
What in the world happened? Did we break something? And if so, how did
we break it so the numbers drop by 97%, but not 100%?
It isn't _necessarily_ relevant to the current numbers, but it's a
really weird data artifact.
I looked back in the mailing list archives for any clues, but the only
thing I can see is that the F21 beta freeze started on the 14th —
which just makes things _weirder_, since it seems _less_ likely that
anything changed. Anyone have any guesses?
Fedora Project Leader