tickets #154252
closedman.opensuse.org no longer updated since 11.11.2023
Added by dimstar 4 months ago. Updated 21 days ago.
100%
Description
Forwarding to openSUSE Heroes:
Whenever a new openSUSE Tumbleweed snapshot is scheduled for publish
(on pontifex), a task to regenerate/publish man pages on
man.opensuse.org is triggered.
The process would be to rsync from pontifex over to
man.infra.opensuse.org ; manpages.o.o claims this has last been updated
on 11.11.2023 - which is probably around the time when the datacenter
move has happened.
I presume there is a firewall in the way, blocking this update (I have
since lost access to pontifex, so I can not give more technical detauls
that what I see as a user: the manpages are not being updated)
Cheers,
Dominique
Updated by crameleon 4 months ago
- Category set to Manpages (service)
- Assignee set to opensuse-admin-obs
- Private changed from Yes to No
Hi @dimstar,
thanks for reporting. Pontifex was moved to the build service infrastructure as part of the migration, hence there no longer is direct connectivity between it and the openSUSE (Heroes) infrastructure. I do remember us considering this requirement for man.i.o.o but cannot recall the agreement.
Hi build team (pontifex maintainers) and @kukuk (man.i.o.o maintainer),
this is about man.i.o.o which relies on data generated on Pontifex, I think using rpm2docserv. Have there been any considerations regarding this already? If not, I could offer to listen for rsync on a designated port on our openSUSE proxy server, forwarded to man.i.o.o. I'd just need to know which IP address (preferably IPv6) I should allow the traffic from from in our firewall.
Of course, also happy to discuss any other solution suggestions.
Cheers,
Georg
Updated by kukuk 4 months ago
crameleon wrote in #note-1:
Hi build team (pontifex maintainers) and @kukuk (man.i.o.o maintainer),
this is about man.i.o.o which relies on data generated on Pontifex, I think using rpm2docserv. Have there been any considerations regarding this already?
Nobody spoke with me and all I can say is, I need the data on man.i.o.o, however and whereever it is generated and pushed to that machine. Since I don't know how the build setup works, I cannot help here with a different solution.
Updated by crameleon 3 months ago
- Status changed from New to In Progress
- Assignee changed from opensuse-admin-obs to crameleon
- % Done changed from 0 to 50
Deployed https://code.opensuse.org/heroes/salt/c/6131b7f3998279221099743d3afe29578d79c147?branch=production, waiting for first push to test functionality.
Updated by crameleon 3 months ago
- Status changed from In Progress to Blocked
- % Done changed from 50 to 70
Connectivity and sync seem to generally be operational. However the tool on the source side is broken, only a small amount of data is synchronized, then it fails:
# lots of packages starting with "a" ...
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/aalib/asciiview.1.en.gz 739 44
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/aalib/asciiview.1.en.html.gz 4614 4654
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/aalib/aview.1.en.html.gz 4610 4650
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/aalib/index.html 12602 812
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcde/abcde.1.en.gz 11280 104
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcde/abcde.1.en.html.gz 17163 1195
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcde/cddb-tool.1.en.gz 1126 44
Feb 16 21:13:06 man rsyncd[6699]: rsync: [generator] write error: Broken pipe (32)
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcde/cddb-tool.1.en.html.gz 5157 1021
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcde/index.html 12515 723
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcm2ps/abcm2ps.1.en.gz 7532 7572
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcm2ps/abcm2ps.1.en.html.gz 12106 12146
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abcm2ps/index.html 12436 808
Feb 16 21:13:06 man rsyncd[6699]: atlas1.infra.opensuse.org recv Tumbleweed/abi-compliance-checker/abi-compliance-checker.1.en.gz 6007 72
Feb 16 21:13:06 man rsyncd[6699]: rsync error: error in socket IO (code 10) at io.c(848) [generator=3.2.7]
Feb 16 21:13:06 man systemd[1]: rsyncd@812-2a07:de40:b27e:1203::130:873-2a07:de40:b27e:1204::11:56400.service: Main process exited, code=exited, status=10/n/a
Feb 16 21:13:06 man systemd[1]: rsyncd@812-2a07:de40:b27e:1203::130:873-2a07:de40:b27e:1204::11:56400.service: Failed with result 'exit-code'.
Sometimes it continues up to packages starting with "f".
Marcus also opened https://bugzilla.suse.com/show_bug.cgi?id=1220024 for you.
Updated by dimstar 3 months ago
- Status changed from Resolved to Workable
crameleon wrote in #note-8:
Given your comment in the bug report, it sounds like there is no interest in having this fully working.
Say what? The resource is spent on fixing the underlying RPM packages that result in the error. Sure, would be nice if rpm2docserv would not be failing on this - but that's no reason to just dismiss the ticket.
The last 'half sync;' was generated on Feb 16. freeradius-server has been fixed since then. And even if not: the 'half sync' up to this package should still have happened in the last days, but did not (latest published snapshot is 0220 - which does not match the time generated seen on https://manpages.opensuse.org)
Updated by crameleon 3 months ago
- Assignee changed from crameleon to kukuk
Hi,
sorry, but the only thing that was missing from my end is observing one full sync, which seems not possible without a resolution for the origin problem - since the proxy and network implementations seem to work, I figured that to be sufficient help, allowing the man.o.o maintainers to continue as needed.
I can hand the ticket back to the maintainer of man.i.o.o, as to keep the issue tracked here - @kukuk, please update respectively.
Cheers,
Georg
Updated by dimstar 3 months ago
- Assignee changed from kukuk to opensuse-admin-obs
crameleon wrote in #note-10:
Hi,
sorry, but the only thing that was missing from my end is observing one full sync, which seems not possible without a resolution for the origin problem - since the proxy and network implementations seem to work, I figured that to be sufficient help, allowing the man.o.o maintainers to continue as needed.
Ok, miscommunication / miswording in this case. The issue is being addressed, the failing packages are identified and being fixed - so the 'close as no interest' sounded strange and rude.
I can hand the ticket back to the maintainer of man.i.o.o, as to keep the issue tracked here - @kukuk, please update respectively.
I learned via slack that the issue is that the job was disabled on pontifex - nothing do be done on man.o.o in this case; ticket to stay with autobuild team (who is maintaining pontifex)
Updated by crameleon 3 months ago
- Status changed from Workable to Feedback
- Assignee changed from opensuse-admin-obs to crameleon
- % Done changed from 70 to 90
Hi,
Marcus and me worked some more on this now.
I think we made it work with a combination of:
- patches to rpm2docserv to not fail with broken packages: https://build.opensuse.org/package/revisions/home:darix:apps/rpm2docserv
- patches to the proxy to increase the timeouts (the transfer took a very long time) and to use version 1 of the PROXY protocol: https://code.opensuse.org/heroes/salt/c/f1f138527dd711ab6903e039cc2dd7b2ea9e866d, https://code.opensuse.org/heroes/salt/c/46a501e5144d7ac2261b6b9676330920c1867f90
I can see "Page last updated 2024-02-23T00:04:24Z" on https://man.opensuse.org now, can you confirm if this is now up to date?
Marcus also added the job to a systemd timer to run on a schedule going forward.
Cheers,
Georg