flatpak: vendor launchpad-only deps (intltool + libdbusmenu) to fix CI flakiness - #517
flatpak: vendor launchpad-only deps (intltool + libdbusmenu) to fix CI flakiness#517got3nks wants to merge 1 commit into
Conversation
Both intltool 0.51.0 and libdbusmenu 16.04.0 live exclusively on launchpad.net (Debian/Ubuntu ship a .1 point release of libdbusmenu with a different sha256, and snapshot.debian.org doesn't carry the 0.51.0 source archive). launchpad.net's CDN times out frequently enough to fail the Flatpak build at random — we've hit it twice in the last two days, the second time blocking the first amule-project/amule:master Packaging run. Vendor both tarballs in-tree at packaging/deps/ and switch the manifest from a fetched 'url:' source to a local 'path:' source. flatpak-builder still verifies the sha256 at extract time, so corruption (in-repo or in-transit) is caught the same way as before; the only change is where the bytes come from. Combined size of the two tarballs is ~900 KB — a once-only ~900 KB hit on every clone. Worth the trade for a reliable build. packaging/deps/README.md documents both files: upstream URL, sha256, update procedure if either upstream ever ships a new release, and the rationale for choosing in-tree vendoring over Git LFS or release-asset hosting at this scale. The other packaging deps (cryptopp / wxwidgets / boost / libgd / pupnp / libmaxminddb / AyatanaIndicators) come from GitHub release assets and have not been a problem; they stay as 'url:' fetches. Verified locally: both files' sha256 matches the values pinned in the manifest, byte-for-byte the same content as the launchpad upstream.
|
Instead of vendoring dead code, we should maybe just switch to something that's maintained. Gettext learned many more stuff it can extract, and we could've used it since 0.18. For libdbus, I didn't really get what it's good for, or how it's used at all in amule. |
|
Fair architectural point, and you're right that intltool is dead code we'd love to drop. The piece this PR doesn't surface clearly: aMule itself doesn't use intltool (just one match in So this is the dependency chain: libdbusmenu is the D-Bus menu protocol that backs the SNI tray items the icon-modernise PR wired up (#508). If we drop libdbusmenu we drop the whole AyatanaIndicators stack and fall back to legacy The proper architectural fix is migrating to So I'd frame the choice as:
My read: option 1 buys us reliable CI today and parks option 2 as a documented follow-up (already noted in the manifest comment). But happy to take option 2 if you'd rather rip the band-aid; I can prepare that PR instead and close this one. |
|
So it's either shipping dead code for an almost dead dep, or need to watch out what's coming? What about not shiping flatpaks? |
|
Fair concern, and honestly tempting — the Flatpak module tree is the heaviest part of the manifest by a wide margin. Before going there I'd like to try option A first: migrate to Closing this PR either way — vendoring dead code isn't the right answer. I'll come back with one of:
Sound good? |
|
Quick correction on my comment above: I named the wrong repo. There is no That changes the migration scope significantly: it's not a manifest swap, it's a source-code change in Combined with the survey of how Qt / Electron apps avoid this problem entirely (built-in SNI in their toolkits) while the GTK-based tray-icon ecosystem (Blueman, Mint indicators, etc.) is collectively still on the deprecated lib, it doesn't feel like aMule should be the project leading this transition. Concretely: I'm parking both options A and B for now. Letting launchpad recover on its own and revisiting when the wider ecosystem moves to |
…-project#517) amulegui could manage the friends list but never exchange messages. Two gaps: the chat send path is compiled out under CLIENT_GUI, and a headless daemon dropped incoming peer messages entirely — CUpDownClient::Process- ChatMessage was a hard no-op stub under AMULE_DAEMON, so the GUI notify it would have fired was never reached, and no EC code carried a message. Surface received friend/chat messages read-only in the remote GUI: - Daemon now processes incoming chat headlessly: a real ProcessChatMessage under AMULE_DAEMON applies the message filter and fires the notify (the interactive spam-captcha stays GUI-only). IsMessageFiltered moves out of the GUI-only block since it is prefs-based and GUI-free. - New EC codes: EC_OP_GET_CHAT_MESSAGES / EC_OP_CHAT_MESSAGES, EC_TAG_CHAT (+ EC_TAG_CHAT_CLIENT_ID child) and the EC_TAG_CAN_CHAT capability (abstract + hand-maintained ECCodes.h; also fills the missing EC_OP_VERIFY_LOCAL_DATA debug-name case). - The notify routes to a per-connection chat queue on each chat-capable CECServerSocket (per-client, like the partial-update valuemaps), drained on EC_OP_GET_CHAT_MESSAGES. Capability negotiated in AUTH_OK. - Client lib advertises EC_TAG_CAN_CHAT and exposes ServerSupportsChat(). - amulegui polls unconditionally (so the new-message blink fires from any tab) and feeds messages through the existing CChatWnd::ProcessMessage path; the Send button and compose box are disabled (receive-only). Sending remains unwired; it would need a client->daemon send op.
…mule-project#519) The read-only chat relay (amule-project#517) split ProcessChatMessage into a daemon definition and a GUI definition under #ifdef AMULE_DAEMON, duplicating the message-filter entry and the log + IncMessagesReceived + Notify_ChatProcessMsg tail across both. Collapse to a single definition and guard only the parts that are genuinely GUI-only — the advanced spam filter (captcha challenge + URL heuristic), which depends on CCaptchaGenerator (compiled only into the monolithic target, pulls wxImage) and touches the chat window. On the daemon that block compiles out and the function falls through to the shared notify tail: identical behaviour, one copy of the shared logic. The captcha stubs for the daemon stay as-is. No functional change. Built amuled + amule (monolithic) + amulegui.
2 participants
Summary
Both
intltool 0.51.0andlibdbusmenu 16.04.0live exclusively onlaunchpad.net:.1point release of libdbusmenu with a different sha256 — can't be used as a mirror.snapshot.debian.orgdoesn't carry the 0.51.0 source archive — no mirror.launchpad.net's CDN times out frequently enough to fail the Flatpak build at random — we hit it twice in the last two days, the second time blocking the firstamule-project/amule:masterPackaging run after #510-#515 merged.This PR vendors both tarballs in-tree at
packaging/deps/and switches the Flatpak manifest from a fetchedurl:source to a localpath:source. flatpak-builder still verifies the sha256 at extract time, so corruption (in-repo or in-transit) is caught the same way as before; the only change is where the bytes come from.Files
intltool-0.51.0.tar.gz67c74d94…b334e959cdlibdbusmenu-16.04.0.tar.gzb9cc4a2a…1bfa878aCombined: ~900 KB once-only hit on every clone. Worth the trade for a reliable build.
Why in-tree vs LFS / release assets
packaging/deps/README.mddocuments the rationale; quoting:The other Flatpak deps (
cryptopp/wxwidgets/boost/libgd/pupnp/libmaxminddb/ the AyatanaIndicators libs) come from GitHub release assets and have not been a problem; they stay asurl:fetches.What's NOT in this PR
packaging/deps/README.md.Test plan
libayatana-indicator's release URL — unrelated to the vendoring change), the build completes successfully. Both arches now pass on the same fork tip.