NOTE
If your issue is for security or deals with sensitive info please mark it as private using the checkbox below.
Please check https://www.fedorastatus.org for known outages before filing a ticket about an outage.
fedpkg new-sources causes 502 server error.
fedpkg new-sources
######################################################################## 100.0% Could not execute new_sources: Fail to upload files. Server returns status 502
I tried more than 10 times now(Sat Nov 22 14:25:20 GMT 2025) and 6 hour ago(Sat Nov 22 07:00:00 GMT 2025).
Maybe 2025/11/23 or 2025/11/24
This is due to scraper/DDOS on pkgs.
Will try and mitigate. ;(
Metadata Update from @kevin: - Issue assigned to kevin - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: high-gain, medium-trouble, ops
ok. Should be back to normal now.
Sorry for the trouble.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
I failed 3 times and succeeded 1 time. Thank you.
I doubt the normal mode is still unstable.
Failed situation:
~~~ Fedora Project ~~~ │ Internet │ ┌──┴──┐ │ Router ├────────┐ └──┬──┘ │ │ │ Wireless Wired ┌──┴───────┐ ┌──┴──────────────────┐ │ Host-A │ │ Host-B │ │ Git and Tarball Repo │ │ Run ssh Host-A & fedpkg new-sources │ └──────────┘ └─────────────────────┘
ssh Host-A
Succeeded situation:
~~~ Fedora Project ~~~ │ Internet │ ┌──┴──┐ │ Router │ └──┬──┘ │ Wired ┌──┴──────────────────────┐ │ Host-A │ │ Git and Tarball Repo and Run fedpkg new-sources │ └─────────────────────────┘
ok. Is this ipv6 or ipv4? Can you provide a traceroute to src.fedoraproject.org ? And I assume it used to be ok, but now is not?
I use IPv4.
% traceroute src.fedoraproject.org traceroute to src.fedoraproject.org (38.145.32.21), 30 hops max, 60 byte packets 1 corpha1-int.rdu.redhat.com (192.168.1.1) 1.410 ms 3.026 ms 3.001 ms 2 wireless (192.168.0.1) 4.833 ms 4.809 ms 4.787 ms 3 10.152.64.1 (10.152.64.1) 15.065 ms 16.413 ms 16.817 ms 4 h219-110-8-009.catv02.itscom.jp (219.110.8.9) 15.944 ms 15.279 ms 16.567 ms 5 h220-215-129-172.catv02.itscom.jp (220.215.129.172) 17.872 ms 18.375 ms 18.353 ms 6 h220-215-130-170.catv02.itscom.jp (220.215.130.170) 18.331 ms 14.196 ms 13.374 ms 7 core1-ichi.ngbb.itscom.jp (175.177.7.45) 13.946 ms 13.915 ms 14.588 ms 8 asbr1-kote.bb.itscom.jp (219.110.0.237) 15.786 ms 18.410 ms 17.780 ms 9 111.87.18.1 (111.87.18.1) 16.704 ms 21.635 ms 22.163 ms 10 27.85.199.13 (27.85.199.13) 23.680 ms 27.85.199.9 (27.85.199.9) 22.118 ms 27.85.199.13 (27.85.199.13) 24.499 ms 11 106.187.13.46 (106.187.13.46) 143.066 ms 106.187.13.6 (106.187.13.6) 134.235 ms 27.85.199.13 (27.85.199.13) 138.441 ms 12 111.87.3.114 (111.87.3.114) 134.342 ms 111.87.3.110 (111.87.3.110) 114.503 ms 111.87.3.106 (111.87.3.106) 126.820 ms 13 * * * 14 * * be3669.ccr21.sfo01.atlas.cogentco.com (154.54.43.9) 117.753 ms 15 be3670.ccr22.sfo01.atlas.cogentco.com (154.54.43.13) 125.220 ms be3906.ccr82.slc03.atlas.cogentco.com (154.54.5.153) 143.502 ms 147.426 ms 16 be3322.ccr22.den01.atlas.cogentco.com (154.54.163.249) 150.444 ms 157.074 ms be3906.ccr82.slc03.atlas.cogentco.com (154.54.5.153) 149.224 ms 17 be3272.ccr81.den01.atlas.cogentco.com (154.54.83.70) 154.875 ms 155.793 ms be3486.ccr82.den01.atlas.cogentco.com (154.54.90.22) 141.674 ms 18 be8568.ccr32.oma02.atlas.cogentco.com (154.54.95.110) 152.246 ms be3272.ccr81.den01.atlas.cogentco.com (154.54.83.70) 150.507 ms be6904.ccr31.oma02.atlas.cogentco.com (154.54.95.98) 163.633 ms 19 be5068.ccr42.ord01.atlas.cogentco.com (154.54.166.74) 166.554 ms be6904.ccr31.oma02.atlas.cogentco.com (154.54.95.98) 160.861 ms be5068.ccr42.ord01.atlas.cogentco.com (154.54.166.74) 161.261 ms 20 port-channel2717.ccr91.cle04.atlas.cogentco.com (154.54.6.222) 167.026 ms 172.277 ms 181.696 ms 21 port-channel2717.ccr91.cle04.atlas.cogentco.com (154.54.6.222) 179.948 ms port-channel2718.ccr92.cle04.atlas.cogentco.com (154.54.7.130) 166.215 ms 166.666 ms 22 be8194.rcr21.clt01.atlas.cogentco.com (154.54.170.226) 196.821 ms be8193.rcr21.clt01.atlas.cogentco.com (154.54.170.82) 196.306 ms port-channel9259.ccr92.dca04.atlas.cogentco.com (154.54.173.98) 188.252 ms 23 be9067.rcr71.rdu02.atlas.cogentco.com (154.54.171.210) 196.913 ms 201.380 ms be8193.rcr21.clt01.atlas.cogentco.com (154.54.170.82) 197.008 ms 24 te0-0-0-12.nr61.b055125-0.rdu02.atlas.cogentco.com (154.24.79.138) 210.829 ms 209.009 ms be9067.rcr71.rdu02.atlas.cogentco.com (154.54.171.210) 202.401 ms 25 38.32.212.41 (38.32.212.41) 191.757 ms te0-0-0-24.nr61.b055125-0.rdu02.atlas.cogentco.com (154.24.79.142) 208.253 ms 38.32.212.41 (38.32.212.41) 190.974 ms 26 209.132.181.204 (209.132.181.204) 206.358 ms 207.237 ms 212.456 ms 27 * 209.132.181.204 (209.132.181.204) 214.629 ms * 28 * * * 29 * * * 30 * * *
I think the original problem is fixed but I still have the fedpkg problem.
My upload is 1.5Mbps and I always failed if I use the failed situation above. I have to reconfigure the hardware to use the succeeded situation above whenever I run fedpkg new-sources.
E.g. I tried fedpkg with https://github.com/unicode-org/cldr/archive/refs/tags/release-37.zip
% fedpkg new-sources cldr-release-37.zip Uploading: cldr-release-37.zip to https://src.fedoraproject.org/repo/pkgs/upload.cgi Uploading: cldr-release-37.zip ######################################################################## 100.0% Could not execute new_sources: Fail to upload files. Server returns status 502
I guess it might be succeeded if I could put files with sftp to https://src.fedoraproject.org/repo/pkgs/cldr-emoji-annotation/ directly.
Has it always behaved this way? or only recently?
Nothing should have changed here except we did move datacenters in july...
I'll reopen this as someone on devel list has seen it as well...
Metadata Update from @kevin: - Issue status updated to: Open (was: Closed)
FWIW I think this has been happening to me too, as recently as a few days ago (when I did my last package builds). I wrote it off as being just more infra flakiness so didn't bother reporting it ...
And to be clear only on uploading new sources ?
Yes. fedpkg new-sources sometimes fails with an 502 error.
Seems the issue was fixed. I don't have to set up the workaround of the network hardwares.
I just got back from holidays today so I didn't do anything here. ;(
So, must have been some network path causing problems that was fixed.
Glad it's working for you now!