Hi,
Steve McIntyre wrote:
> the external API for libjte is *very* close to what we had before.
Now i'm curious. I expected no need for a change, assumed that you'd
automagically detect the checksum type from the lines in the -md5-list
file.
> I've got a simple diff right now that I'm
> just cle
Hi,
after finding
https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=log;h=refs/heads/sha256
https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=blob;f=libjte/libjte.h;hb=refs/heads/sha256
i now believe to understand that the new API call
int libjte_set_checksum_algorithm(struct
On Mon, Nov 11, 2019 at 10:30:09PM +0100, Richard Atterer wrote:
>Hi Steve,
>
>thank you very much for continuing to take care of jigdo! It's been a loong
>time since I actively worked on it. (Must have been ~2000 that I started
>creating it.)
>
>I've updated my site to point to the URL you gave
On Tue, Nov 12, 2019 at 09:15:34AM +0100, Thomas Schmitt wrote:
>Hi,
>
>Steve McIntyre wrote:
>> the external API for libjte is *very* close to what we had before.
>
>Now i'm curious. I expected no need for a change, assumed that you'd
>automagically detect the checksum type from the lines in the -
Arg, and our mails have just crossed I see! :-)
On Tue, Nov 12, 2019 at 07:24:16PM +0100, Thomas Schmitt wrote:
>Hi,
>
>after finding
>
> https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=log;h=refs/heads/sha256
>
> https://git.einval.com/cgi-bin/gitweb.cgi?p=jigit.git;a=blob;f=libjte/li
Hi,
i wrote:
> > libjte_set_checksum_algorithm() became necessary
Steve McIntyre wrote:
> ACK. I'd not thought that through fully myself here, but yes.
Here you see why it is good to have a mutually curious user-developer
relation. :))
> I'm open to changing things like option names here, obvi
Hello,
Downloading both the latest weekly (20191028) and daily build (2019110) of
debian-testing-amd64-netinst.iso the following error message is displayed:
"No kernel modules were found. This is probably due to a mismatch between the
kernel used by this version of the installer and the version of
Hi,
while exploring the need for adaptions in the build system of libsofs,
i wonder whether it is really necessary to create LIBJTE2 in libjte.ver.
Adding new functions is upward compatible.
In my libraries i add them to the current (and only) SONAME version.
Fine check for compatibility happens
Hi,
SONAME comes from libjte/configure.ac. Dunno from where libburn got the
slightly braindamaged way to compose it. From there it spread over the
other libraries. libjte is its youngest victim. Shrug.
The upstream revision "2.0.0" is not necessarily the .so suffix.
The macro values from libjte.h
Samuel Thibault, le ven. 23 août 2019 22:03:23 +0200, a ecrit:
> Steve McIntyre, le ven. 23 août 2019 21:00:19 +0100, a ecrit:
> > Once you've done that, I'll backport it for buster builds too.
>
> Thanks, I have pushed the fix.
FI, I tested the fix in the stretch branch of debian-installer, it w
10 matches
Mail list logo
