#12929 `fedpkg new-sources` is failed with server error 502
Closed: Fixed by kevin. Opened by fujiwara.

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.

Describe what you would like us to do:


fedpkg new-sources causes 502 server error.

######################################################################## 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).

When do you need this to be done by? (YYYY/MM/DD)


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
└──────────┘ └─────────────────────┘

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!

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata