View Issue Details

IDProjectCategoryView StatusLast Update
0008188Talerdeployment and operationspublic2024-08-28 21:30
Reporterdvn Assigned Todvn Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status closedResolutionfixed 
Target Version0.13Fixed in Version0.13 
Summary0008188: ARM64 Debian Packages for Exchange
DescriptionWe need arm64 debian packages for Exchange

arm64 packages for GNUnet are a prerequisite
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Activities

Christian Grothoff

2024-06-16 16:34

manager   ~0022628

Seems nullptrderef has address this largely, @dvn: can you confirm?

nullptrderef

2024-06-16 16:39

viewer   ~0022629

Last edited: 2024-06-16 17:35

https://buildbot.taler.net/#/builders/19/builds/820 - ARM builds are mostly addressed for exchange (likely large overlap for transplanting into merchant & co.)
RISC-V is (/will, it hasn't yet (and might not if gnunet/1034 completes before it reaches risc-v)) fail due to GNUNet not having RISC-V builds yet. <- I added RISC-V builds (that, once we have gnunet nightly RISC-V, have no reason not to work)

Documentation is still needed for this scripting - the 1xx scripts are generated, and further platform support can be evtl. added to them - however given I'm not familiar with how packaging is setup on whatever server hosts the debs, I'll likely need assistance for specifically distributing packages.

The generation scripts, once also adapted to work in the GNUNet repository, should make it relatively easy to support other distributions (assuming the release server for those distros has been setup) and architectures - architectures usually just involve adding an item to the targets array (distro codenames are the same story for adding more) - and distributions just involve that + adapting the containerfile to the distro.

dvn

2024-06-16 19:06

reporter   ~0022630

Still missing for libeufin, merchant, challenger, wallet-core arm64 packages, so not time to close this unless we want to change it to a ticket just for exchange.

Interesting approach with the generated scripts. A lot of repetition, but maybe we can cut down on that by migrating some of the ideas into the buildbot config itself. Anyway, that could be capture in a different ticket.

Christian Grothoff

2024-06-16 19:25

manager   ~0022631

libeufin and wallet-core should be packaged as arch-independent as far as I see it, as JVM/JavaScript code should be architecture-independent. So those are clearly a quite different story.

As for merchant/challenger/sync/taler-mdb, we should probably just clone the exchange approach (which should be pretty quick), unless you first want to reduce the duplication. But with the *generation* I'm not sure that's too much of a problem, as we primarily care about duplicated source, not duplicated *generated* scripts, right? :-)

nullptrderef

2024-06-23 16:52

viewer   ~0022712

> As for merchant/challenger/sync/taler-mdb, we should probably just clone the exchange approach (which should be pretty quick), unless you first want to reduce the duplication. But with the *generation* I'm not sure that's too much of a problem, as we primarily care about duplicated source, not duplicated *generated* scripts, right? :-)
The generated scripts are already duplicated LOL

> libeufin and wallet-core should be packaged as arch-independent as far as I see it, as JVM/JavaScript code should be architecture-independent. So those are clearly a quite different story.
I'd have the question there of if the metadata is already set to be arch-independent, or if it's set to x86_64 for unknown reasons

nullptrderef

2024-06-23 16:53

viewer   ~0022713

> Still missing for libeufin, merchant, challenger, wallet-core arm64 packages, so not time to close this unless we want to change it to a ticket just for exchange.
My comment (& AFAIK C's aswell) were in regards to a large chunk of the work being done, not the entire ticket :)

dvn

2024-06-24 00:45

reporter   ~0022714

I've scoped this ticket to only Exchange. We can open new tickets for the others, as needed.

GNUnet is done, and so is Exchange as of https://buildbot.taler.net/#/builders/19/builds/820

Issue History

Date ModifiedUsernameFieldChange
2024-01-22 13:33dvnNew Issue
2024-01-22 13:33dvnStatusnew => assigned
2024-01-22 13:33dvnAssigned To => dvn
2024-01-29 13:06Florian DoldTarget Version => 0.11
2024-01-29 23:42Christian GrothoffSeverityminor => feature
2024-05-13 19:26Christian GrothoffTarget Version0.11 => 0.12
2024-06-16 16:34Christian GrothoffNote Added: 0022628
2024-06-16 16:39nullptrderefNote Added: 0022629
2024-06-16 16:44nullptrderefNote Edited: 0022629
2024-06-16 16:58nullptrderefNote Edited: 0022629
2024-06-16 16:59nullptrderefNote Edited: 0022629
2024-06-16 17:03nullptrderefNote Edited: 0022629
2024-06-16 17:03nullptrderefNote Edited: 0022629
2024-06-16 17:35nullptrderefNote Edited: 0022629
2024-06-16 19:06dvnNote Added: 0022630
2024-06-16 19:25Christian GrothoffNote Added: 0022631
2024-06-19 16:09Florian DoldTarget Version0.12 => 0.13
2024-06-23 16:52nullptrderefNote Added: 0022712
2024-06-23 16:53nullptrderefNote Added: 0022713
2024-06-24 00:44dvnSummaryARM64 Debian Packages => ARM64 Debian Packages for Exchange
2024-06-24 00:44dvnDescription Updated
2024-06-24 00:45dvnStatusassigned => informing
2024-06-24 00:45dvnResolutionopen => fixed
2024-06-24 00:45dvnNote Added: 0022714
2024-08-26 20:30Christian GrothoffFixed in Version => 0.13
2024-08-28 21:30Christian GrothoffStatusinforming => closed