[PATCH] Stop nightly testing dnf composes
by lubomir.sedlar＠gmail.com
From: Lubomír Sedlář <lsedlar(a)redhat.com>
When Pungi gained the ability to use DNF instead of Yym, a compose was
set up to run depsolving and generate diffs against the real rawhide
compose. Since regular rawhide is now using DNF, so there's nothing to
compare anymore and we can get rid of this.
Signed-off-by: Lubomír Sedlář <lsedlar(a)redhat.com>
---
roles/releng/files/rawhide | 1 -
1 file changed, 1 deletion(-)
diff --git a/roles/releng/files/rawhide b/roles/releng/files/rawhide
index 78c56fd..e715fbd 100644
--- a/roles/releng/files/rawhide
+++ b/roles/releng/files/rawhide
@@ -1,5 +1,4 @@
# rawhide compose
MAILTO=releng-cron(a)lists.fedoraproject.org
15 5 * * * root TMPDIR=`mktemp -d /tmp/rawhide.XXXXXX` && cd $TMPDIR && git clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && LANG=en_US.UTF-8 ./nightly.sh && sudo -u ftpsync /usr/local/bin/update-fullfiletimelist -l /pub/fedora-secondary/update-fullfiletimelist.lock -t /pub fedora fedora-secondary
-15 17 * * * root TMPDIR=$(mktemp -d /tmp/rawhide-dnf.XXXXXX) && cd $TMPDIR && git clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && LANG=en_US.UTF-8 ./nightly-dnf.sh
15 18 * * * root TMPDIR=$(mktemp -d /tmp/rawhide-modular.XXXXXX) && cd $TMPDIR && git clone https://pagure.io/pungi-fedora.git && cd pungi-fedora && LANG=en_US.UTF-8 ./nightly-modular.sh
--
2.9.5
6 years, 8 months
SSH known_hosts changed
by Patrick Uiterwijk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
As of right now, the ssh known_hosts file has been basically rewritten to use SSH CA certificates.
The actual SSH keys for our servers should not have changed, but the known_hosts file has been shortened signifcantly.
Do note that for some servers (specifically cloud), might have now switched from their ECDSA to RSA keys, which means that if you only had the host-specific known_hosts line, you might need to add the CA.
You should be able to replace your entire ~/.ssh/known_hosts for Fedora with https://admin.fedoraproject.org/ssh_known_hosts .
Please let me know if you find any hosts that don't work yet, as they should just need the hostname or domain in the list.
Patrick
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZlKCOAAoJEIZXmA2atR5Qw8MQAKqTrC1s8sMD6ujKPMIKNDrD
aacmoyVIXq2gcvM/C4J/wp8yemIAXEv410xJ7+SP9fOcC49oThjqVca5pAq/Y9nS
x4HWCDUNN4aQptwGOA2cwbjwopc44ClLV/oKW5NA1QEiSEfro5Op1/PM7n4iCMs4
3JWX9pSERVzuU52ewYzOubYYaaDpfOx49FW+LfmhZmFDj+NJIYet/USqmXFdDvLZ
iVpWCVZ/k6DmVudofwTwa1iTgbxlx3NK6NaGHBV1D1saBg5qmUOx2g6KZlT78XH2
8SgioFZ9KYGahtDAP251BIejfHFR52/A7CBMZutN+JKriYaSRKbJZywQS5pzzz/q
ay6qGs3qflSF7mGkpbpyzkFi96kFy2rHOhdnXb237kROCwSqAXRchpAYLPhf5uaZ
BNPy0EPylbTBDsNff2uucCMa+BpErysKrA8R5TIt/7WdmzMBZlks0xwOhx5C9pJh
Jaucy309j1GAXh0cNlMxqjuVAhrYoLbGygevFJTd++m5vrShqNfUvUV23oFwOcJd
U1bjEax0GzJLz8egW0b5RyN/9TCfmEyPZ1IEsRpyKdfgeHn+i5OmyNNnIdgtarEd
kzm6liilcEo+PIwGtjM5LuQLGoz8k0KlZl9wAEO9lEg8JdMqxK0ta9gjFs4QO5MK
cE7/fpE6IpIfjS2kPtVV
=yULk
-----END PGP SIGNATURE-----
6 years, 8 months
Infra tags changes
by Patrick Uiterwijk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi all,
As of a bit ago, I have made a few small changes to the Infrastructure tags in koji.
The basic change is that now, after you tagged it $dist-infra-candidate (or built for the "$dist-infra" target), it will still get signed, but NOT tagged into $dist-infra.
Instead, the build will be tagged into $dist-infra-stg.
This is an additional set of tags that gets put into a set of repositories enabled on staging, but not production, machines.
This allows you to test the build thoroughly.
After you have tested the build, you can promote it to production.
For instructions on that, see the Promoting topic in [1], but in short it's really just a koji move.
If you need any more information, just let me know.
Regards,
Patrick
[1]: https://infrastructure.fedoraproject.org/infra/docs/docs/sysadmin-guide/s...
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZjdYTAAoJEIZXmA2atR5QnIcP/3OqZDGzq9cV+2xCzzOQH5fL
toWCLUwFKolVpD1PCauN7jhGEWt2wLaQlnO7MCWCN7vv+f4pu4zS6vwNt8zNPEFI
V3Zs10P45s/m4SAOoOOggGtNz7RoVTh9Mg1ZVTmqJixafT8GI/tJir3W2WxcS3mC
MPHbRRi5GbFgC47Em0XTJPtf+cCY1BtqMuW8MwC5IKA+MVRHsZhsCbezpowcqMMi
1At/1UuHTkhoCjcb3+bEoIGJLSivoYeK2Z2TXld2o8J9oOGxY8EGJ4RDPTmMQQZK
ZQ/W2EiEGGM8QCE67XVf5Ff8tE7/y0a1381y6d34wbgz5Hk4bvZ2WKXcjcefLy2w
yo2+EqCHDaWVBf6g9SgvUBN8jmIOP/35s4LLfDkySzl8WQOpQgt3NE4jKpUQYLOW
sxETK/E7E8qvtunsY+rEpoTj0ovzZnKNpmHI8Gx2IbxGeKRsjKYuA5AtGz/nb0Tv
0AbWJPl9Wn8ujA8kkpEssT5eQfiuiiot8c0W4QnwXE+3FU4Tf5mCYZEW05ulxoeU
Jr0mG6SzywwdfD6LHZZa0lQsqriYCgv3rS4jlDOOLiMHY8ulfvk1wJxYnhufzL04
pGWA+DGQVy25K7boA2Bgr+q6bGEkkkg4b9bL1JGvPqSa4Bs4/03VwnBcBgYYTDwa
L301mf7iJMuMqBxg+/8P
=G2qN
-----END PGP SIGNATURE-----
6 years, 8 months
Proposal: Use a calendar to limit rate of change
by Randy Barlow
Hello!
I was chatting with puiterwijk this morning (well, I guess his afternoon
☺) about the difficult week the systems team has had. There were quite a
few changes all happening at once this week:
* The update/reboot cycles
* RHEL 7.4 was released
* Pagure over dist-git was turned on
* Bodhi was reconfigured to talk to Pagure instead of Pkgdb
* A fedmsg update
* More things?
Patrick told me that it's been a huge amount of work for him and I
assume others this week, because many of the above didn't go so smoothly.
I think it's expected and frankly normal for updates to not go smoothly
- we are all stretched pretty thin and we don't have a formal QE team to
make sure that our infra apps are ready to ship. Thus, I think we should
expect changes like the above to be "bumpy" and instead should develop a
plan to help smooth out the bumps.
I propose that we use our infra calendar (or even a new calendar if
preferred) to more formally schedule infrastructure changes, with the
goal being to avoid weeks like this one (where so many large changes
landed at once). i.e., if I want to make a Bodhi deployment on Monday
and I see that there's a Pagure deployment already scheduled for Monday,
I should consider a different day.
Of course, we can always have exceptions. Sometimes we might have "flag
days" where we do want/need two apps to upgrade together. Or maybe
sometimes we do want to take advantage of an update/reboot cycle to
sneak in an app upgrade, if the systems team is comfortable of course.
That's fine when needed, but when not needed I think spreading out the
changes will help our systems team avoid insane weeks like this one.
Thoughts?
6 years, 8 months
How to contribute?
by Reza Seyf
Hello group,
I'm new to this mailing list and I want to ask for help to contribute in Fedora infrastructure.
Is there any ways to figure out how do you work in infrastructures of Fedora project?
Thanks.
Reza
6 years, 8 months
Meeting Agenda Item: Introduction Yoann
by YLB
Hello world! :-)
A quick intro following the checklist on the wiki:
- My IRC handle: vbird.
- Skills I have: Linux sysadmin for roughly 15 years (including 13+
in a professional capacity); PHP developer in my early years; system
scripting (mostly bash and Perl); VoIP / SIP with Asterisk (at a time
it still looked like a revolution!); virtualisation (but mostly
proprietary products); dozens of irrelevant technos that--if
mentioned--would probably make some of us suddenly feel older; Indian
food cooking (says my wife...)
- Skills I'd like to learn (or improve): Python (a bit rusty), Ruby,
Ansible, Docker & OpenShift, KVM, OpenStack, anything else that could
be fun playing with.
- Associations I have: not a lot anymore (I was more active when I
was younger). Self-employed with customers mostly in the financial
sector.
- Location & timezone: Luxembourg, CET/UTC+1 (or CEST/UTC+2 in the summer.)
- What to work on: first things first, joining the fi-apprentice
group to have a look at how things work here.
Cheers,
Yoann E. A. Le Bihan
[[ www.Yoann.info ]]
6 years, 8 months
