howdy,
i just tagged a new release of pwdsphinx at
https://github.com/stef/pwdsphinx/releases/tag/v1.99.3-beta
please not that this also depends on a new release of liboprf at
https://github.com/stef/liboprf/releases/tag/v0.6.0
thanks for your kind support!
s
ohio,
i think i got it. thanks to your kind vm contribution Santiago! <3
i put some extra debug output in the code, which showed me that there was
files in the state (stored under /tmp/sphinx-oracle-root.*) that should not
exist. this state is deleted recursively between test cases. and the error
howdy,
i'm upstream.
i regret to say that i cannot reproduce this.
- i clone https://salsa.debian.org/debian/pwdsphinx
- checkout debian/1.99.2-beta-5 and,
- run sbuild on it,
- it all succeeds.
what am i doing wrong?
btw the error it fails on, sounds like the test case for some reason
hey,
i figured it out, the problem is that in src/makefile CFLAGS is only set if no
CFLAGS is passed, and that contains the essential -fpic switch. adding a
simple
CFLAGS+= -fpic
solves the problem for both ppc64 and the hppa archs'
will, submit a fix on salsa asap.
cheers,s
ey try to allocate the memory for all the
state needed during the rest of the protocol. so somewhere here:
https://github.com/stef/liboprf/blob/master/src/tests/tp-dkg.c#L426-L465
and this is all stuff were (a lot) memory is allocated on the stack. and
normally if you allocate too much, you get a
Dear Gui-Ye, Joost,
i added your fixes to upstream (being myself the upstream dev)
https://github.com/stef/liboprf/commit/8129a40faeda9c0457317c3a039c783d57dd4fb6
however i find it curious, that on riscv the test
`ulimit -s 66000; ./tp-dkg-corrupt 3 2 `
segfaults, whil the other
`ulimit -s
On Thu, Aug 08, 2024 at 07:24:06PM +0200, Joost van Baal-Ilić wrote:
> Hi again stef,
>
> On Thu, Aug 08, 2024 at 12:21:10PM +0200, Joost van Baal-Ilić wrote:
> > On Thu, Aug 08, 2024 at 12:06:44PM +0200, stef wrote:
> > > On Thu, Aug 08, 2024 at 07:08:13AM +0200, J
On Thu, Aug 08, 2024 at 07:08:13AM +0200, Joost van Baal-Ilić wrote:
> Hi stef,
>
> I just found out https://pypi.org/project/pysodium/#files lacks a
> pysodium-0.7.18.tar.gz.asc . (It's not published on
> https://github.com/stef/pysodium/releases either.) (You did s
On Thu, Aug 08, 2024 at 07:08:13AM +0200, Joost van Baal-Ilić wrote:
> Hi stef,
>
> I just found out https://pypi.org/project/pysodium/#files lacks a
> pysodium-0.7.18.tar.gz.asc . (It's not published on
pypi does not publish signatures anymore, i did sign it, but pypi ignores
howdy,
(pysodium upstream here)
i just checked it, the culprit is, that back in the days i published 0.7.0 as
0.7.0-0 on pypi. none of the newer version have that -0 postfix, so any later
version should be ok. of course the best would be the latest, 0.7.18.
howdy,
(pysodium upstream here)
i'm a bit confused, 0.7.0 is packaged according to the build log, and it is
called 0.7.0_0 - i have no idea where the _0 postfix comes from.
nota bene pysodium is already are at 0.7.18 and according to
https://pypi.debian.net/pysodium/ there is awareness of a newe
ithub.com/cockpit-project/cockpit/issues/5340
Stef
On 07.11.2016 16:44, Tianon Gravi wrote:
> On 7 November 2016 at 05:34, Stef Walter wrote:
>> The docker package is unfortunately currently broken. It fails to run
>> containers and instead produces the following message:
>>
>> rpc error: code = 2 desc = "oci runt
Package: docker.io
Version: 1.11.2~ds1-6
Severity: grave
Justification: renders package unusable
The docker package is unfortunately currently broken. It fails to run
containers and instead produces the following message:
rpc error: code = 2 desc = "oci runtime error: could not synchronise with
On 16.08.2014 11:35, Martin-Éric Racine wrote:
> Hey Stef!,
>
> As reported at GNOME Bugzilla – Bug 711222 [1] there are some serious
> issues with gnome-keyring that have resulted in the package being
> marked as unfit for release. As you seem to be the main contributor to
> t
i just downgraded libffi6:i386 3.1-2 -> 3.1~rc1+r3.0.13-12
and all seems to be working again. since the patch is against 3.0.12 i suppose
it might not be the solution to this problem, will investigate further.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of
Package: libffi6
Version: 3.1-2
Severity: critical
Tags: security patch
Justification: breaks the whole system
when using grsecurity/pax protections on debian unstable, the newest libffi6
breaks almost everything.
some examples:
> # emacs
> emacs: error while loading shared libraries: libffi.so.6
Right here is the diagnostic of why it fails:
Compiled the stuff with CFLAGS=-g to trace the execution. Here is my diagnostic:
run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -lp
-x '(and (load "init.lisp") (sys::%saveinitmem) (ext::exit))
(ext::exit t)'
Starting program: /hom
triggers for man-db ...
Errors were encountered while processing:
clisp
#
Any idea? Something to try in order to help?
2010/9/27 Peter Van Eynde :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello Stef,
>
> On 22/09/10 21:53, stef louise wrote:
>> I may have some tim
Stéphane
2010/9/17 Peter Van Eynde :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello Stef,
>
> On 16/09/10 21:57, stef louise wrote:
>> /usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp
>> *** - handle_fault error2 ! add
debugging to identify where
> precisely this script fails?
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> Never abandon a theory that explains something until you have a theory that
> explains more. — John McCarthy
>
>
>
> On 16 Sept
Hi,
This bug seems quite quiet for a grave bug (the update manager refuse
to work since then).
I tried to use dpkg which seems to give more accurate messages for
common-lisp installation:
# LANG=C dpkg -i /var/cache/apt/archives/common-lisp-controller_7.4_all.deb
(Reading database ... 196004 file
OK, sorry about that.
I tried to disassemble the code and follow it a little, but one thing is
clear : the level at which the blocking occurs is not the deepest one. It is
too tricky for me to follow at assembly level though, as I am not yet fluent
in PPC assembly.
Moreover, each time I interrupt t
Hi,
I can confirm this bug on PowerPC. When trying to play a song, the processor
use raise to 100% and Rhythmbox stalls. It looks like the usual "let's
assume all char on every plateform are signed char and let's do loops
carelessfully" kind of bug, but I may be wrong.
I tried to make a backtrack
24 matches
Mail list logo
