Re: Git server migration

Any plans to install GitLab FOSS on the GNUnet git server (i.e., a fork of GitLab with all proprietary code removed)? On Wed, Sep 1, 2021 at 6:21 PM Schanzenbach, Martin wrote: > Hi, > > along with some other services, we are moving the gitolite service t

New library: GNUnet Worker

change quite a bit. In the meanwhile I would be happy if anyone would like to give it a try and experiment with it. The package is now available at https://github.com/madmurphy/libgnunet-worker. I have been already in contact with Christian, Martin and TheJackiMonster, who gave me precious

printf-like output for gnunet-search

best to stick to the coding style of the rest of the program. But a good code review is more than welcomed. Please find attached a patch, or alternatively the single file I have edited. --madmurphy <> <>

Re: printf-like output for gnunet-search

lude/gnunet -o 'gnunet-search-test' gnunet-search.c ./gnunet-search-test -f '%n. %f\n' 'commons' (if you follow these steps the program will be compiled without libextractor and the %t specifier in --prop-printf will not be available.) --madmurphy On Fri, Feb 4,

Re: printf-like output for gnunet-search

reviewed the code further (only minor things) – you can find it attached to this email… Also if this code becomes stable enough, it will become part of GNUnet's code base it can be reused in the future by other GNUnet command line utilities that require printf-like capabilities… --madmurph

Re: printf-like output for gnunet-search

r distractions (if later I want to actually download something I will omit the --printf argument, or use another format that contains the %u specifier). But the possibilities are really many. There is still room for additions, but there is also no hurry. --madmurphy On Mon, Feb 7, 2022 at 12:

libextractor - key-value pairs and mime types

…? EXTRACTOR_METATYPE_MIMETYPE = 1, ...*EXTRACTOR_METATYPE_GNUNET_ORIGINAL_MIMETYPE* = XXX, So, two simple proposals: 1. Create EXTRACTOR_METATYPE_KEY_VALUE_PAIR 2. Create EXTRACTOR_METATYPE_GNUNET_ORIGINAL_MIMETYPE What do you think? Does it make sense? --madmurphy

Re: printf-like output for gnunet-search

p://www.gnu.org/s/gnunet/ General help using GNU software: http://www.gnu.org/gethelp/ What do you think? If it sounds already too hardcore I will go back to the previous version. But then we will not have any means to print only specific metatypes… Please find the new proposal attached. --madmurphy

Re: libextractor - key-value pairs and mime types

a problem, because as the name suggests, *it is not a metatype*. P.S. Sorry for picking the wrong mailing list! On Tue, Feb 8, 2022 at 9:57 AM Christian Grothoff wrote: > Hi madmurphy, > > The 'correct' place for GNU libextractor discussions would be > > https://lists.gn

Re: libextractor - key-value pairs and mime types

I have prepared a mini-patch for explaining better what I mean with the third point (I have used EXTRACTOR_METATYPE_NONE in the end, I think it is more clear). Please find it attached --madmurphy On Tue, Feb 8, 2022 at 1:38 PM madmurphy wrote: > Got it! I agree about your solution for

Re: libextractor - key-value pairs and mime types

case, a comment similar to the one I had left in the patch would also be useful (“used by libextractor only internally; available to the user for marking an enum EXTRACTOR_MetaType as not carrying any meaningful value”). --madmurphy

Re: libextractor - key-value pairs and mime types

Actually, the first thing that I thought when I read EXTRACTOR_METATYPE_RESERVED was “not used today, but tomorrow will be used for the book's cover” :) It definitely needs a renaming! --madmurphy On Tue, Feb 8, 2022 at 5:52 PM madmurphy wrote: > Of course, the

Re: libextractor - key-value pairs and mime types

se the libextractor list... > > -Christian > > On 2/8/22 7:21 PM, madmurphy wrote: > > Actually, the first thing that I thought when I read > > |EXTRACTOR_METATYPE_RESERVED| was “not used today, but tomorrow will be > > used for the book's cover” :) > > > > It def

Re: printf-like output for gnunet-search

I have pushed the new gnunet-search with printf-like capabilities to the git repository. I have also updated the man page. Feel free to play with it and write your feedbacks :) --madmurphy On Tue, Feb 8, 2022 at 1:39 PM madmurphy wrote: > Last proposal about gnunet-search, then I will s

Re: printf-like output for gnunet-search

fied --dir-printf defaults to --printf, a mention of --printf will always be there in a way or another. Maybe we can amend the output of gnunet-search --help that I pasted above directly on this mail thread? I haven't checked the actual man pages yet, so I can't comment on that. Below is

Re: printf-like output for gnunet-search

er-printf use different format specifiers? I would use a unified section for the examples, but I would leave the specifier lists where they are. --madmurphy On Fri, Feb 11, 2022 at 11:56 PM Alessio Vanni wrote: > Before replying on your points, a correction: the line saying "The main

Re: printf-like output for gnunet-search

and --dir-printf arguments - ignored when these are provided by the user) -v, --version print the version number Report bugs to gnunet-developers@gnu.org. Home page: http://www.gnu.org/s/gnunet/ General help using GNU software: http://www.gnu.or

Reducing the number of executables to one

uot;${1}\"." fi (where /foo/bar is the directory where the executables are actually installed.) What do you think? --madmurphy

Re: Attacking the documentation monster

I don't know if this will be a popular proposal, but I really believe that setting up a self-hosted Wiki could be a very good choice. No complicate git clone, no complaints, just read/edit what you need, and distributed responsibilities about its design and direction. My two cents On Tue, Mar 1,

Re: Reducing the number of executables to one

er we decide that it is a script or a C program), so that a user can type gnunet and get the list of commands available – the same way as you can currently type make and get the list of make targets available… --madmurphy On Wed, Mar 2, 2022 at 11:01 PM Christian Grothoff wrote: > Perso

Re: Reducing the number of executables to one

available executables would be generated automatically), and online there are many autocompletion templates for most shells ready to use. On Thu, Mar 3, 2022 at 7:00 AM Schanzenbach, Martin wrote: > > > > On 3. Mar 2022, at 01:51, madmurphy wrote: > > > > Hi Christian, > >

Re: Packaging problems

I have added the Arch packages <https://git.gnunet.org/gnunet.git/tree/contrib/packages/arch?id=22082c234c2013c65fc49a59d01c467a78c12f3e> 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

Small question about gnunet-search

timeout However there is nothing in the source code of src/fs/gnunet-search.c <https://git.gnunet.org/gnunet.git/tree/src/fs/gnunet-search.c?id=b6cbb6f800ef9aeebcfb76a7ba721d4b95a2e2ca> that reacts to the configuration. Was that a planned feature? --madmurphy

Re: Small question about gnunet-search

s (a tilde, “~”?) My two cents --madmurphy On Sun, Jun 26, 2022 at 8:59 PM Christian Grothoff wrote: > On 6/26/22 17:28, madmurphy wrote: > > Hi everyone, > > > > I have a question about something I had noticed some months ago while > > reviewing the man page for |gnunet-

Re: Small question about gnunet-search

That exists, it's just --timeout=forever Alright. So it is only needed to implement the reactivity to the configuration then. And also rewrite the entire FS module afterwards… :) --madmurphy On Mon, Jun 27, 2022 at 7:59 AM Christian Grothoff wrote: > On 6/27/22 08:13, madmurp

About GNUrl and cURL

On Arch GNUnet still depends on GNUrl, but as far as I understood now cURL is preferred. Would I do the right thing if updated the Arch package accordingly and dropped the GNUrl dependency for good? --madmurphy

Re: About GNUrl and cURL

gnunet&id=3693252e6dcdf53bfa428b4c078729c08f68ecde> . --madmurphy On Mon, Sep 5, 2022 at 4:25 PM Christian Grothoff wrote: > If Arch has a curl linked against GnuTLS, then yes. -Christian > > On 9/5/22 17:11, madmurphy wrote: > > On Arch GNUnet still depends on GNUrl, but as far as I understood now > > cU

Re: About GNUrl and cURL

Mmm I just checked better, and the configure script now says: ... HTTP Client:curl-openssl ... That is not a good sign, right? On Mon, Sep 5, 2022 at 5:47 PM madmurphy wrote: > Indeed, there is a dedicated package on Arch, libcurl-gnutls > <https://archlinux.org

Re: About GNUrl and cURL

cml Manual: configure: For detailed setup instructions, type 'info gnunet' after the installation or visit https://docs.gnunet.org/ On Mon, Sep 5, 2022 at 7:14 PM Christian Grothoff wrote: > Did you happen to have both libcurl-gnutls and libcurl-openssl > installed, and maybe co

Re: About GNUrl and cURL

that has a split package of cURL linked against GNU TLS… --madmurphy On Tue, Sep 6, 2022 at 9:59 AM Schanzenbach, Martin wrote: > Ah sorry I just checked: > If "normal" curl is found, the check for curl-gnutls is skipped. > I guess we should prefer curl-gnutls. > > Br >

Re: About GNUrl and cURL

In the meanwhile I have asked <https://bugs.archlinux.org/task/75824> Arch developers to make sure that a libcurl-gnutls.pc file gets installed… --madmurphy On Tue, Sep 6, 2022 at 2:03 PM madmurphy wrote: > Okay, the first thing I notice in the list of the files installed by > li

Re: About GNUrl and cURL

; > check your config.log and check for the test against libcurl-gnutls. > > > There should be test somewhere in there that fails for reasons. > > > > > > BR > > > Martin > > > > > >> On 5. Sep 2022, at 20:21, madmurphy wrote: > > &g

Re: About GNUrl and cURL

No, sorry, I meant it doesn't work :-( Too much expectations, and I read tls instead of ssl... On Tue, Sep 6, 2022 at 1:43 PM madmurphy wrote: > Alright, it works now :-) > > HTTP Client:curl-openssl > > Just out of curiosity, why do

Re: About GNUrl and cURL

:47 PM madmurphy wrote: > I will try to check the configure.ac file. I don't get an error btw, only > that "curl-openssl" http client... > > On Tue, Sep 6, 2022 at 1:45 PM Schanzenbach, Martin < > mschanzenb...@posteo.de> wrote: > >> Yes. I *think* I have

Re: About GNUrl and cURL

he PKGBUILD of libcurl-gnutls attached to this email works well for GNUnet. But for publishing on AUR we would need to rename it in some way. --madmurphy On Tue, Sep 6, 2022 at 9:06 PM Martin Schanzenbach wrote: > Excerpts from Christian Grothoff's message of 2022-09-06 21:34:45 +0200:

Re: About GNUrl and cURL

the official libcurl-gnutls, and on which GNUnet will depend. All this glue package will do is simply creating an unversioned symlink. --madmurphy On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach wrote: > FYI I updated the detection logic again. You may check if that works for > you know

A more general question about curl

missing it might be an opportunity to make libwget grow. A comparison table (by curl): https://curl.se/docs/comparison-table.html --madmurphy

Re: A more general question about curl

utls-devel/2019-June/014051.html --madmurphy On Wed, Sep 7, 2022 at 2:54 PM Schanzenbach, Martin wrote: > We need a non-blocking API such as curl_multi. > Last time I checked, libwget2 does not have that. > > BR > > > On 7. Sep 2022, at 15:46, madmurphy wrote: > > &g

Re: About GNUrl and cURL

I now commited a programmatic check for GnuTLS. Try it out. It should not require your fix. Mmm without my trick the configure script still prints ... HTTP Client:curl (OpenSSL) ... --madmurphy On Wed, Sep 7, 2022 at 3:44 PM Schanzenbach, Martin wrote: > > > &g

Re: About GNUrl and cURL

I tried again, just to be sure. Still get ... HTTP Client:curl (OpenSSL) ... My config.log attached. --madmurphy On Wed, Sep 7, 2022 at 8:17 PM Martin Schanzenbach wrote: > I am quite sure it works now as expected so you would need to provide me > with the config.

Re: About GNUrl and cURL

chlinux.org/packages/libcurl-gnutls-minimal-git>, libcurl3-gnutls <https://aur.archlinux.org/packages/libcurl3-gnutls>. I think I should definitely give them a try. --madmurphy On Thu, Sep 8, 2022 at 7:55 AM Martin Schanzenbach wrote: > I checked the log and the test runs correctly. &

The future of the file-sharing service

dex a file when it is missing 7. Autoshare the dynamic content of a directory and update its index in real time (e.g. if I “autoshare” the content of /srv/filesharing/gnunet/madmurphy/, when I add foobar.txt to that directory it must be automatically indexed – the opposite if I

Re: The future of the file-sharing service

ex in real time (e.g. if I “autoshare” the content of /srv/filesharing/gnunet/madmurphy/, when I add foobar.txt to that directory it must be automatically indexed – the opposite if I remove it) 8. Implement file statistics (download counter? last seen? etc.) – this should allow the netwo

Re: The future of the file-sharing service

conflicts. That seems like a complex task, which maybe could be accomplished by a further service on top of FS (something like “FSGIT”)? On Mon, Sep 19, 2022 at 11:39 PM madmurphy wrote: > Here is the list updated with Jacki's suggestion and a further point from > me I had forgotten

Re: The future of the file-sharing service

-URI lookup) 6. Automatically and fully auto-unindex a file when it is missing 7. Autoshare the dynamic content of a directory and update its index in real time (e.g. if I “autoshare” the content of /srv/filesharing/gnunet/madmurphy/, when I add foobar.txt to that directory it must be

Re: The future of the file-sharing service

it?), but what I am suggesting is making it a default GNUnet feature for public files. 1. Automatically and fully auto-unindex a file when it is missing 2. Autoshare the dynamic content of a directory and update its index in real time (e.g. if I “autoshare” the content of /srv/filesharing/gnune

FS as user or not

?id=1672c85ad702146521dc830298dcb3f802533539> was the reason, but it happens also if I restore the configuration before Jacki's commit. So I have no idea what happened. Anyone getting the same behavior? --madmurphy

Re: FS as user or not

is not the reason, then I have no explanations. --madmurphy On Sat, Oct 8, 2022 at 11:08 AM Christian Grothoff wrote: > Hmm. Is your $USER in the 'gnunet' group? > > On 10/6/22 08:54, madmurphy wrote: > > After one of the last commits, if I launch > > > >

Re: contributing

ur message). --madmurphy On Tue, Oct 25, 2022 at 6:28 PM wrote: > Hello, > > there's still TODO wtr link to copyright waiver for contributing in the > docs: > > > file:///home/lash/src/build/gnunet/0.17.6-198-g1436e4266/doc/handbook/html/developers/contributing.htm

Re: FS as user or not

675142d58ab463#n454> . Anyone able to reproduce this bug? Attached is my configuration. --madmurphy On Sun, Oct 9, 2022 at 11:37 AM madmurphy wrote: > Hi Christian, > > Yes, my username has always been in the gnunet group. But in the past I > always used the system services of GN

Re: Search by metadata in GnuNet

function are you looking for, specifically? --madmurphy On Fri, Nov 25, 2022 at 10:36 PM Jimmy Bionic wrote: > Hi there, > > I am keen to find out about one particular aspect of search > implementation in GnuNet. I belong to a small community of like minds who > would like to excha

About gnunet-core -s

. --madmurphy

Re: About gnunet-core -s

the peer I am connected to) is always DESN. Shouldn't I see at least you and Christian and someone else? --madmurphy On Sun, Oct 13, 2024 at 12:53 PM Martin Schanzenbach wrote: > gnunet-core -s returns all your active connections or connection requests, > similar to what gnunet-p

Re: About gnunet-core -s

*Update:* If I launch gnunet-core -m, from time to time I see a key sent message for peers GKZS and VAY0. But it seems these peers don't like me. --madmurphy On Sun, Oct 13, 2024 at 1:59 PM madmurphy wrote: > Thank you Martin. I have been periodically monitoring it since yesterday,

Re: About gnunet-core -s

; In general, from my experience, give the peer some time. Connections are > usually established over time. > Of course, this should happen a lot faster, so something is wrong. > > BR > > On Sun, 2024-10-13 at 14:03 +0100, madmurphy wrote: > > *Update:* If I launch gnunet-core -m, fro

GNUnet and GNUTLS

gnutls/> (Sept. 18, 2024, 11:22 a.m. UTC → 8.10.1) or the last update of gnutls <https://archlinux.org/packages/core/x86_64/gnutls/> (Aug. 16, 2024, 11:25 a.m. UTC → 3.8.7) broke it. Is any of you dealing with the same version numbers in GNUnet's dependencies? --madmurphy

Re: GNUnet and GNUTLS

Martin's patch worked! So it's already online . Thank you! However – this might be totally unrelated – even if the installation works fine, if I launch sudo -u gnunet gnunet-arm -s gnunet-arm -s gnunet-core -m the third