Re: Packaging problems

I have added the Arch packages to the repo, as other distros might find them useful. --madmurphy On Mon, Jun 6, 2022 at 7:55 PM Maxime Devos wrote: > Martin Schanzenbach schreef op ma

Re: Packaging problems

Martin Schanzenbach schreef op ma 06-06-2022 om 16:52 [+]: > > As Maxime says, GNUnet takes a long time to compile (when it > actually > > does - I'm having problems with that right now), and presumably > quite > > a > > while to test too. The obvious way to reduce those times is to > simply

Re: Packaging problems

On Thu, 2022-06-02 at 16:29 +0100, Willow Liquorice wrote: > Right. Perhaps the onus is on the developers (i.e. us) to make things > a > bit easier, then? Well, the reason why the "lax" distros have outdated packages is exactly because of that. Somebody decided to contribute once or twice and

Re: Packaging problems

Still, using the proposed high-level categorisation of GNUnet components would be handy for documentation purposes, even if the repo structure only vaguely reflects it, as a lot of service names aren't very indicative of their function or importance to the uninitiated. I'm taking after the

Re: Packaging problems

On 6/3/22 22:37, Willow Liquorice wrote: > Alright, fair point. > > Still, more automated testing/packaging isn't a bad thing. What exactly > does the CI do, right now? I looked in .buildbot in the main repo, and I > guess it just tries to build and install GNUnet from source on whatever > OS

Re: Packaging problems

On 6/4/22 09:43, Schanzenbach, Martin wrote: > > >> On 3. Jun 2022, at 21:44, Christian Grothoff wrote: >> >> Having many packages doesn't usually make it easier for packagers, it just >> means that now they have to deal with even more sources, and create more >> package specifications.

Re: Packaging problems

> On 3. Jun 2022, at 21:44, Christian Grothoff wrote: > > Having many packages doesn't usually make it easier for packagers, it just > means that now they have to deal with even more sources, and create more > package specifications. Moreover, build times go up, as you now need to run >

Re: Packaging problems

Alright, fair point. Still, more automated testing/packaging isn't a bad thing. What exactly does the CI do, right now? I looked in .buildbot in the main repo, and I guess it just tries to build and install GNUnet from source on whatever OS hosts Buildbot? Couldn't see that much automated

Re: Packaging problems

Having many packages doesn't usually make it easier for packagers, it just means that now they have to deal with even more sources, and create more package specifications. Moreover, build times go up, as you now need to run configure many times. Worse, you then need to find out in which order

Re: Packaging problems

Right. Perhaps the onus is on the developers (i.e. us) to make things a bit easier, then? To be honest, I barely understand how the GNUnet project is put together on a source code level, let alone how packaging is done. One of the things I'm going to do with the Sphinx docs is provide a

Re: Packaging problems

Willow Liquorice schreef op do 02-06-2022 om 14:44 [+0100]: > While I was working on the documentation, I decided to put a Repology > badge at the top level of the install page, and then I saw the extent of > GNUnet's packaging woes. There are more distros with severely outdated > versions than