| Summary: | emerge --sync and emerge-webrsync fails probably because of timestamp error | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Přemysl Šťastný <p-j> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | aladjev.andrew, contactopublico57, jstein |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 650144 | ||
|
Description
Přemysl Šťastný
2020-04-05 18:50:01 UTC
It started working for me now. But I am not sure, if the problem is really solved. The the emerge --synce key refresh issue and the emerge-webrsync timestamp thing are entirely separate issues. It's not recommended to call emerge-webrsync directly anymore, since it does not refresh keys for you automatically. The recommended way to use emerge-webrsync is to call emerge --sync with a setting like this in repos.conf: > sync-type = webrsync > sync-webrsync-verify-signature = yes The "sync-webrsync-verify-signature = yes" setting is default since bug 689506. Follow up to this issue. Recently, and for no apparent reason sudo emerge-webrsync has failed to download and populate the package tree and gives the following message: rsync warning: some files vanished before they could be transferred (code 24) at main.c(1330) [sender=3.2.3] Cleaning up ... !!! /etc/portage/make.profile is not a symlink and will probably prevent most merges. !!! It should point into a profile within /usr/portage/profiles/ !!! (You can safely ignore this message when syncing. It's harmless.) !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and !!! --version. No profiles and many builds showing zero contents. sudo emerge --sync works but is slow: Number of files: 146,083 (reg: 119,474, dir: 26,609) Number of created files: 145,559 (reg: 119,474, dir: 26,085) Number of deleted files: 6,663 (reg: 3,977, dir: 2,686) Number of regular files transferred: 119,474 Total file size: 218.75M bytes Total transferred file size: 218.75M bytes Literal data: 218.75M bytes Matched data: 0 bytes File list size: 3.61M File list generation time: 0.003 seconds File list transfer time: 0.000 seconds Total bytes sent: 2.41M Total bytes received: 107.63M sent 2.41M bytes received 107.63M bytes 29.86K bytes/sec total size is 218.75M speedup is 1.99 Have tried substitute mirrors, no change in problem. Noticed an updated rsync came out recently but that did not correct the failure to populate the package build tree in /usr/portage. Implementing the criteria in Comment 2 of this bug report did not resolve the issue? Please comment. (In reply to contactopublico57 from comment #3) > Follow up to this issue. > > Recently, and for no apparent reason sudo emerge-webrsync has failed to > download and populate the package tree and gives the following message: Direct call to emerge-webrsync is deprecated, so please try emerge --sync with a setting like this in /etc/portage/repos.conf: [gentoo] sync-type = webrsync Hello everyone, I've lost yesterday evening debugging this issue and found that hkps has been blocked using DPI in my country (Belarus). I've tried to encapsulate (mirror) hkps traffic using some servers outside Belarus and received same issue (KS_GET -- ... Server indicated a failure). I am 100% sure that hkps traffic has been blocked by state firewall. It may be similar for DPI to another blocked protocol. Please don't waste your time debugging it if you are living in any country under the influence of post USSR or China. Low quality developers (maybe from China) implemented low quality DPI, it can ruin everything and nobody will care. Bad state governments just share it between each other and multiply bugs. You have to use vpn today on any machine because of hkps protocol. Please be aware that vpn is not enough: you have to obfuscate vpn protocol, secure it once again and simulate regular https traffic. The only one alternative is to move physically out of countries like Belarus. Thank you. The emerge-webrsync was resolved with a configuration change. As to the Belarus connectivity issue reported by Andrew Aladjev 2021-05-21 10:42:37 UTC Go satellite > Go satellite All direct satellite internet access (without bypassing through state firewall) is banned completely in Belarus. Of course we can use satellite internet as backup access: it is possible to go to the village or some forest and temporaly enable satellite transmitter. But nobody is using it permanently, it is possible to be punished. We are using stunnel + obfs4proxy + openvpn and masking stunnel traffic as regular https traffic. This scenario comes directly from china user experience. Today we are not hiding this https traffic behind amazon/azure/etc corporate networks (known as tor meek transport) like china users, but we have already bough such frontends. We are ready for complete china firewall. I didn't want to use vpn tunnel just on home build server, engaged in procrastination. But state firewall broke hkps protocol this month, so i had to switch to vpn anyway. This state firewall behaviour is actually a bug, i think nobody wanted to broke hkps. Please don't repeat my mistake, if you have received "gpg: keyserver refresh failed: Server indicated a failure" in Belarus - you have to replicate china user vpn installation. Don't waste time on debugging. The organization responsible for partial China firewall installation and management in Belarus is https://belgie.by. Everyone are free to report hkps bug into this organization, i won't do it, didn't respect them. Thank you for attention. |
