strange error on cross-compiled pike 8

>I cross compiled pike 8.0.498 on an amd64/linux system for use on an >armv5tejl/linux system, and I m getting a strange error when starting it up: > >-:1: Type mismatch for callback function `[]=: >-:1: Expected: scope(0,function(zero, (0=zero) : 0)). >-:1: Got : function(int(128..-129),

//

Windows?

Protocols.HTTP.Server.SSLPort()->create([...], void|int share)

> I'm trying to figure out what the "void|int share" argument of > Protocols.HTTP.Server.SSLPort()->create() really does. The > documentation is less than helpful: > > > Parameter share > > > > If true, the connection will be shared if possible. See > > Stdio.Port.bind for more information > >

Re: New pike.vim (Re: Newlines in strings)

> Stephen R. van den Berg wrote: [...] > Incidentally the docs for Autodoc seem to be incomplete; it fails to > document @global ? It's probably intentional; from Tools.AutoDoc.DocParser: parseError("The @global keyword is obsolete. " "Use @belongs predef::

Port fixes to mktime() and System.TM() from 8.1 to 8.0?

>As a by-product of creating the Val.Timestamp (et al) types, I encountered >numerous bugs and uncertainties in mktime() and System.TM() with regard >to timezone handling/abuse. > >AFAICS, all these bugs have now been dealt with and fixed in 8.1. >Any objections if I port these fixes from 8.1 to

Re: JSON5

>I think adding a new module would be easier. The JSON5 format is very >permissive and would add many new rules (e.g. identifiers as object >keys). I think a new parser (maybe copied from the existing JSON parser) >would make it easier to adjust the grammar. >I am not sure if you like ragel, but I

Re: GTK2.Object()->destroy() checking for no args?

>On Sat, Dec 23, 2017 at 12:42 AM, Henrik Grubbström (Lysator) @ Pike >(-) developers forum <10...@lyskom.lysator.liu.se> wrote: >> Note that AFAIK destruct() in some GTK2 classes is a public function >> (and thus part of the API). > >Do you mean destroy? It got renamed in the big _destruct

GTK2.Object()->destroy() checking for no args?

Note that AFAIK destruct() in some GTK2 classes is a public function (and thus part of the API).

Re: Concurrent and avoid call_out() for most callbacks?

>Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote: >>>I propose ripping out the call_out() method, so that callouts are ran >>>directly in all cases except for the timeout-case. > >>Not a good idea: > >> * Unlimited stack use. > >I re

SCRAM and docs

>>b. Where did the docs go? I can't seem to find them anywhere. > >AFAIK, I copied the current docs to __builtin.Nettle.Hash.SCRAM; it >should show up at the intended places due to inherits, but I haven't >tried building the docs in a while. I just tried building the docs, and SCRAM showed up

SCRAM and docs

>Two things: >a. I see a remark about making that cache-mapping weak. What would that > help (it contains strings only)? If the mapping were to be weak, any strings only referenced from the mapping would be freed whenever the mapping hashtable needs to grow. >b. Where did the docs go? I

Concurrent.Future.zip() ?

>And speaking of Concurrent, since MutexKey is destructed immediately >when it goes out of scope, I think many of the key=0 can be removed >from the code. I've not looked at this specific case, but you have to be careful with tail calls and mutex keys, as it is possible for tail call

Irregularities in HMAC implementation of Pike 8.0 or 8.1?

>Pike v8.0 release 509 running Hilfe v3.5 (Incremental Pike Frontend) >> Crypto.SHA256.HMAC("a")("b"); >(1) Result: >"\b\336""2\231""1\342\225h7v\252\232CR\233\320\262u(m\363\26\3\0\304\233\244\350A\203""0\23" >> Crypto.SHA256.HMAC("a",32)("b"); >(2) Result:

Proposed improvements to Hilfe

>Branch: rosuav/hilfe-improvements > >Two smallish improvements to Hilfe. One is suppressing "quit" and >"exit", per the TODO at the top; fairly simple but I'd like someone >else's eyeballing to make sure it's going about things the right way. Do you handle the case where the user ends the

signals and fork does not mix well

The patch looks good to me.

Unaligned memory access

> Why do we have two sets of unaligned memory access functions? Good question. > Both have exactly the same implementation, except for the obvious > descripancy in the list of arches getting special treatment. > Shouldn't we consolidate this to just one copy of the implementation, > and a

string_assignment

>Since the object storage is zeroed, not calling the initializer is >typically fine, but this initializer does > > SET_SVAL(THIS->lval[0], T_INT, PIKE_T_FREE, integer, 0); > >where PIKE_T_FREE isn't 0, so enabling this code would make a >difference. Looks like a bug.

merging arne/new_buffer

Hi Arne. >I would like to merge the branch arne/new_buffer. It implements >and uses the new dynamic buffer implementation I have talked about on >the conference. The main idea behind this implementation is to help the >compiler generate better code in spite of the aliasing rules of C. In

Arg.pmod changes incomplete?

>Pike 8.1 make doc results in: > >/var/src/roxen/81pike/lib/modules/Arg.pmod:623:Too many arguments to unknown >function (expected 1 arguments). >/var/src/roxen/81pike/lib/modules/Arg.pmod:623:Got : void | int. Oops, seems I forgot to commit some typing fixes for the F_MAGIC_* nodes. Does it

Segfault generating src/post_modules/GL/auto.c on PowerPC

>I noticed that Debian package builds of both 7.8(.866-7) and 8.0(.358-1) have >recently started failing on the powerpc architecture. > >https://buildd.debian.org/status/fetch.php?pkg=pike8.0=powerpc=8.0.358-1=1479857970 > >/«PKGBUILDDIR»/build/linux-3.16.0-4-powerpc64-ppc/pike -DNOT_INSTALLED

Possibly fixed error

I suspect that this behavior is another aspect of [bug 7723], and was fixed with commit 57ebfa38c979402b6bdca02ab6593e570d963342: | commit 57ebfa38c979402b6bdca02ab6593e570d963342 | Author: Henrik Grubbström (Grubba) | Date: Fri Jun 17 17:34:34 2016 +0200 | |

Build of 7.8.866 getting stuck in a loop

>Here are two: >(gdb) bt >#0 0x0055d953 in advance () at ./src/peep.c:910 >#1 asm_opt () at ./src/peep.c:1081 >#2 assemble (store_linenumbers=store_linenumbers@entry=1) at ./src/peep.c:441 [...] >(gdb) cont >Continuing. >^C >Program received signal SIGINT, Interrupt. >0x0048a738

nettle in fedora/centos does not include the secp192 and 224 curves

>hi, Hi Martin. >i just discovered that nettle in fedora/centos does not include the >secp192 and 224 curves. >this is not discovered during build, but instead just leads to a runtime >error. (the installation succeeds despite the error) That's a bit exotic, and would indicate that the

Pike 8.0.294 beta

>Pike 8.0.294 beta/release candidate: > >https://pike.lysator.liu.se/pub/pike/beta/8.0.294/Pike-v8.0.294.tar.gz A corresponding ebuild has now been added to the Gentoo Pike overlay.

f_hash() and endianess

Hi Arne. >The documentation of the new f_hash() claims that its return value is >architecture independent. SipHash reads its input as a series of >little-endian 64 integers, which means that the hash value depends on >endianess for wide strings. Right, I forgot about that case. >I have at some

Documentation breakage

>When preparing a new Debian package of 8.0.240, I noticed that some >documentation disappeared, apparently due to the following. The error >in Nettle.Sign is already corrected but not the others, AFAICT, and >I'm guessing that @exp should be @expr. Patch below, which I home >someone can apply

Error building 8.1: test-pike not found

The precompiler should now work with a Parser.Pike that is more than 3 days old again...

Protocols.WebSocket client mode

>It seems that the 8.1 branch has been rewritten to work with >Stdio.Buffer, which is good. But from what I can tell, SSL.File does >not support that API. Is there a reason for this? It's on the todo list for the SSL module.

Problems building Pike on Mac

> I recetly started getting this build error, which I have absoluteley > no clue what to do about: > > >[ ] > > > In file included from > /Users/ponost/src/pike-git/devel/src/post_modules/Nettle/cipher.cmod:16: > /Users/ponost/src/pike-git/devel/src/module_support.h:47:1: warning: target > does

Re: Stdio.File()->pipe() and PROP_IPC

>On Thu, Apr 28, 2016 at 1:40 AM, Henrik Grubbström (Lysator) @ Pike >(-) developers forum <10...@lyskom.lysator.liu.se> wrote: >>>Consider this usage: >>> >>>object stdout = Stdio.File(); >>>Process.create_process(cmd, (["stdout": stdout->pipe()]); >>> >>>Is this at risk of failing, where

Stdio.File()->pipe() and PROP_IPC

>What exactly does PROP_IPC (fd_INTERPROCESSABLE in the source) permit? Whether sending the file as eg stdin or stdout is supported by the OS. The only platform where this flag is relevant is on WIN32, where notably sockets don't have the flag set (cf src/fdlib.h). >Consider this usage: >

Calendar.Timezone etc. - Up-to-date timezone and daylight savings data

>I'm thinking about getting around to integrating Pike with the tzdata >package in Debian, which I was talking about at the conference some >years ago, but I need to check and understand some things first. > >If I understand correctly, the Calendar module knows about daylight >savings time and

keypair loop

>The PIKE_MAPPING_KEYPAIR_LOOP is not enabled by default. Is this work >in progress? Is it worth keeping? Yes. It would allow for a more static traversal order for mappings.

Over-eager optimization in Pike 8.1

With inlined byte code disassembly (and some braces and newlines): >int main() >{ === 3 1c entry === 3 30 function start === 3 30 mark_at(0) === 3 54 pop to mark === 3 90 fill_stack(4,0) === 3 b6 init_frame(0,4) >array(int) positions=({4,3}); === 4 be constant(0)

Re: Reminder: Pike 8.0 release on Oct 15

>Incidentally, the reason I couldn't check in these fixes earlier is >because they contained a rather oblivious bug. >The code in question ran Thread.Thread(0) at some point (by accident), but >the error message that this generates is devoid of any stacktrace or >source code location information.

Remaining Pike 8.0 issue

It seems something got broken in Stdio.UDP recently. We are investigating... /grubba

The type of %

>So I thought I would fix that Gmp.mpz(3)%2 has the type mixed. My >first quick and dirty fix was to update the type of `% a bit by adding > > tFunc(tObjIs_GMP_MPZ tInt, tObjIs_GMP_MPZ) > >Yes, it ignores the int%mpz and mpz%mpz permutations, but it's a >start. Not the right one apparently, as I

The type of %

>>>Warning: Wong return type. >>>Warning: Expected: { mpz = object(implements _static_modules.Gmp()->mpz) }. >>>Warning: Got : object(is _static_modules.Gmp()->mpz) | mixed. >>> >>>Why is there a "| mixed" in this type? >> >>You probably need to add a tIfNot (or modifying the existing) for the

CID[1317352-1317354]

The three new complaints about Assign instead of compare in pike_tokenizer looks very, very intentional, but I'll leave it up to whoever introduced them (grubba?) to mark them as false positives. I believe that I acknowledged those three yesterday?

switch and Math.nan

I think we should (1) issue a warning when Math.nan is used inside a case and (2) make sure that switch (Math.nan) does not match any case. I believe that the compiler should: - Special case NaN if there's an explicit case-label with NaN. - Map NaN to the default label (if any) otherwise.

assign_array_level*

Looks good to me. I was a bit worried about the first assignment, but as both of the arrays are known to be of the same size, it is correct.

*new*-style tail-recursion

I have been working on refactoring the API of mega_apply and friends. The purpose of that branch is to improve the performance of function calls. More specifically, in some cases (e.g. f_map) frame allocation, setup and deallocation could be avoided if the API permitted it. I will soon push a

Pikefarm revived.

FYI: I've spent the last few days updating Pikefarm to current Xenofarm and to monitoring git and the current branches of Pike. It now seems to work again. Caveat: The put binary in Xenofarm does not support redirects, so the resulturl needs to be updated to pike.lysator.liu.se.

SSL curve ciphers

See branch: rosuav/curve_crypto_guard Merged, thanks.

config error

Looks like a quoting error.

8.0

I don't think I have any known major issues left to fix. There was an issue with compiling Pike 8.x on machines without a pike. Fixed in current Pike 8.x.

8.0

Add a test case to the testsuite?

8.0

Would anyone object to releasing 8.0 from 8.0.38? Sounds good to me. I don't think I have any known major issues left to fix.

Re: cycle detection and destroy()

Stephen R. van den Berg wrote: Arne Goedeke wrote: What kinds of things can safely be done from within destroy() and should we document them? Well, I for one, discovered that *if* any code in destroy() can throw an exception, you must explicitly catch it, because if you don't the exception will

%x on strings

Sounds ok to me.

%x on strings

So '%...x,str' would be equivalent to '%@...x,values(str)' for any value of '...' I take it? I.e. you would use 'sprintf(%02x, Hej)' as a shorthand for 'sprintf(%@02x, values(Hej))'? That's what I assume, though I'd prefer sprintf(%...x, Gmp.bignum(str, 256)) as equivalent in the first case

Re: Autodoc 8.1 complains about removed namespaces

Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote: No, you could still call them. I kept them in because just because it was compatibility with old data, not old code. Ok, misjudgement from my side then. Are there really permanently stored datastructures that need to be

visit to Link�ping

I$-1òùll be in Link-Aöping visiting with Tobi and Company the weekend of December 5-7. If anyone is interested, perhaps we could broaden the scope to have more of a general Pike development meeting. Feel free to drop a note (this list is probably a fine place) if anyone$-1òùs-A

Re: Freeze of Debian 8.0 jessie

On Wed, Oct 15, 2014 at 1:00 AM, Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum 10...@lyskom.lysator.liu.se wrote: What do we need to make a 8.0 release this week, even if it is only for Debian? Possibly fix the docs building, which (last I checked) is failing in 8.1 and 8.0.

Freeze of Debian 8.0 jessie

What do we need to make a 8.0 release this week, even if it is only for Debian? Left on my TODO-list for 8.0 is supporting the set_buffer_mode() API in SSL.File (both for the SSL.File itself, and being set on the supplied socket), but it can probably be left out in an initial release.

_crypt

WIN32 eller WinSock.

Array augmented assignment doesn't always work

Apologies for the non-minimality of the test-case, but this is a smidge weird. The changes made in b2d25e Compiler: Improved soundness of the op-assign optimizer seem to have broken this: Thanks, that gave a hit at whet the problem was. In theory, the three forms of element removal ought to be

Program.all_inherits needs documentation... or a better spec

Program.all_inherits has a FIXME asking for docs. But its definition is a little odd: it returns a list of the given program's inherits, and everything they inherit - but not recursively. Not quite... Take a closer look at the loop -- It isn't a foreach()... I could document it as such, but it

Removal of 7.2 compat broke Stdio.read_file

Test case: int main() {write(Stdio.read_file(readfileboom.pike));} Oddly enough, this works fine if run from a non-installed Pike: rosuav@sikorsky:~/pike$ bin/pike readfileboom.pike int main() {write(Stdio.read_file(readfileboom.pike));} But installing it and using that causes a crash: Thanks

Linux 3.13

Does it work with a Pike version that is a few hundred revisions old? In that case bisect.

Re: Linux 3.13

Fixed.

Re: Linux 3.13

/home/nilsson/pike/src/testsuite.in:570: Test 140 (shift 2) failed. 1: mixed a() { return sprintf(%O, typeof(sprintf(%c, 1023))); ; } 2: mixed b() { return string(1023..1023); } 3: o-a(): string o-b(): string(1023..1023) The above test is now fixed. It was due to sprintf(%c, 1023)

Does this fix a real bug?

While browsing some code (what else to do with your spare time ;-), I find (not committed yet): :-) diff --git a/src/stralloc.c b/src/stralloc.c index 7cd709c..6ca0a02 100644 --- a/src/stralloc.c +++ b/src/stralloc.c @@ -3221,10 +3221,8 @@ PMOD_EXPORT void free_string_builder(struct

Build fail

Did you run ./run_autoconfig ? It seems configure thinks that its a good idea to rerun the main script in subdirectories that don't have their own configure scripts...

Re: Casting int to float broken in 8.0 on amd64 Linux

Isn't also TYPE_SUBTYPE wrong in the big endian case? It seems to me that on a 64bit big endian machine both subtype and type would always end up being 0. Correct. Fixed last night. like so? #define TYPE_SUBTYPE(X,Y) (((Y)|((X)16)) (sizeof(ptrdiff_t) - 32)) No, sizeof(ptrdiff_t) needs to be

Memory use

The large wide strings at startup are most likely the bytecode for the master and related modules.

7.8 feedback

Does anyone have any feedback that would prevent me from announcing 7.8.856 as the new stable build? I was hoping to make some headway on the windows ell problem I noticed, but if Peter’s build doesn’t have that problem, I’m not too worried about having an answer to the problem beforehand.

Parent lost, cannot clone program.

Hi Arne. I get the above error with the following code. Shouldn't that work? The parent use detector is overzealous... arne - class A { object D(string n) { return C.D(this, E(n)); The problem here is that D has been marked as PROGRAM_USES_PARENT, but is indexed directly

old style encoding

I would like to merge arne/slim into 8.0. It reduces text size with -O3 by about 100k. Most changes are probably harmless, however one disables support for decoding programs with old style encoding and adds a configure argument to turn it back on. I assume that part of the decoder is not normally

new 7.8 stable feedback?

There are some changes in the 7.8 git repository that would be nice to have in the release to support the (soon to be released?) next version of Nettle.

new 7.8 stable feedback?

Hello all, It's been a little over a week since I posted a new alpha version, 7.8.852. Does anyone have any further feedback that needs to be addressed before I announce it as a beta version on the primary list? No objections here. If I don't hear anything in the next day or so, I'll move it

new 7.8 alpha

I’ve uploaded a new 7.8 alpha, incorporating the latest changes for bignum and clang. Please give it a spin. If I don’t hear anything I’ll promote it to beta and make an announcement on the main pike list. Pike-v7.8.852.tar.gz Great! I've now updated the Gentoo Pike overlay

New 7.8 alpha

Good day, Hi Bill. I've prepared and uploaded a new Pike 7.8 alpha. This includes all of the backports and has an up-to-date changelog. I've verified the build passes tests* on OSX 10.9. Please have a look and let me know if there aren't any problems. If all goes well, I'll upgrade it to beta

Re: bash/dash

I believe using a here-document would be more portable. I've used several UNIX(tm) systems that have lacked printf(1).

Re: pike.lysator access

Hi Grubba, Hi Bill. Thanks for looking into this for me. I just tried to log in to pike.lysator.liu.se and was prompted for a password. I did verify that both ida and git accounts work properly with the keys I'm using. Can you take a look to make sure things are okay? After some

pike.lysator access

I've got a pike 7.8 alpha prepared, but I'm having trouble logging in to pike.lysator.liu.se. Can someone with access verify my account (bill) and key? You should now have an account on pike.lysator.liu.se authenticated with your usual set of ssh keys. BTW: The ftp site is mounted from

Re: Pike 8 @ Pike conf 2013

This looks like a good opportunity to mention a few patches that I haven't heard back regarding. They're mostly fairly trivial/simple. Is there a better way to suggest patches than posting them to this list or pike@roxen? Either works. Applied all of them except for the low_read_file() patch,

Pike 8 @ Pike conf 2013

Consolidated notes from the Pike conference regarding Pike 8. Pike 8 branch - [/] Update the CHANGES file. [ ] Make the branch. [...] As far as I can see, there are no blockers left for making the branch. If nobody protests, I'll make the branch later today. And now the

Re: Pike 7.6 Debian wheezy

However, nettle-2.1 patch failed on both 7.6.112 and 7.8.700 sources. Thus, i stole src/post_modules/Nettle/cipher.c[mod] from 7.8.352, put it in 7.6.112, applied the nettle-2.1 patch from 7.8-stable/debian and ended up with: [...]

build failure on Windows

So I took a look at the code now. Moveing from 2K (0x501) to XP (0x501) APIs fixed the IPv6 problems. Ok, I've bumped the value to 0x5ff in Pike 7.9.

build failure on Windows

I'm trying to boot up my old Windows build environment, and I'm getting a new and exiting build error from master. Haven't looked at the code, but will do that tomorrow night if no one has done it before then: Making static: modules/_Stdio Compiling modules/_Stdio/udp.c

Benchmark output

Sounds good to me.

DEBUG_MALLOC

Before I try to work around that: What kinds of malloc misuses and memory access errors will DEBUG_MALLOC actually detect, which valgrind won't? Is it something we want to keep? The main feature of DEBUG_MALLOC, is that it often is capable of determining where the bug that generated the leak is

Pike 8

- Test that exported source and exported builds compile/installs/work. I believe that most of the decode_value-related problems have now been fixed. Remaining to do is support for encoding of programs using variants (the decoder should already be ok). Implemented support for dumping of

Pike 8

Progress report: The consensus was to attempt to push for a 8.0 release, given the large amount of changes since 7.0, and to make that release with the current feature set. The task list for that on a high level is - Fork a 8.0 and next branch (9.0?) soonish (within a week?) - Fix compilation

Re: Pike 8

On Sat, 15 Jun 2013, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote: There are quite a few CritBit-related failures right now. Could they be related to the renumbering of PIKE_T_*? I think that is related to the stack renumbering. But I did not bisect and also didnt

Re: Pike on Hurd

On torsdagen den 6 juni 2013, Magnus Holmgren wrote: Excerpt from config.log: configure:75019: checking if dynamic loading works /home/holmgren/pike7.8-7.8.700/bin/smartlink gcc -c -g -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -O3 -pipe - ggdb3 -fPIC

FYI/RFC: Variant functions in Pike 7.9

FYI: The support for variant function (aka polymorphic overloading) has now reached a semi-useable state in Pike 7.9: | Pike v7.9 release 5 running Hilfe v3.5 (Incremental Pike Frontend) | class foo { | variant int bar(int a) { return a*2; } | variant string bar(string s) { return FOO + s +

Re: Bug#692212: unblock (pre-approval): pike7.8/7.8.700-2

Magnus Holmgren wrote: On onsdagen den 6 mars 2013, Neil McGovern wrote: So, unfortunately the release team removed Pike entirely from the next stable release of Debian, because I said that some of the bugs fixed by 7.8.700 were rather serious. Can you help me elaborate on that?

hex2int

was about twice as slow as the array_sscanf approach. Is that because some special sscanf handling? Probably due to the use of a lookup table. BTW: Why don't you use wide_string_to_svalue_inumber() or STRTOL_PCHARP()?

hex2int

Yes, but wasn't sscanf the fast code? Anyway, if you want to try something exotic, you can try: int low_hex2int(int c) { int q = c 0x40; return (c + (q3) + (q6)) 0xf; }

signal_handler changes

Oops, fixed.

Re: overflow

I can't reproduce the problem on the main branch: | Pike v7.9 release 5 running Hilfe v3.5 (Incremental Pike Frontend) | -0x7fff; | (1) Result: -2147483647 | -0x7fff - 1; | (2) Result: -2147483648 | -0x7fff - 2; | (3) Result: -2147483649 | Pike.get_runtime_info(); | (4) Result: ([

Re: overflow

-NUMBER [(-$1a) 0] : NEG_NUMBER (-$1a) -NEG_NUMBER [(-$1a) = 0] : NUMBER (-$1a) +NUMBER [ !INT32_NEG_OVERFLOW($1a) (-$1a) 0] : NEG_NUMBER (-$1a) +NEG_NUMBER [ !INT32_NEG_OVERFLOW($1a) (-$1a) = 0] : NUMBER (-$1a) Hmm, the above changes hints that the problem is caused by a more aggressive

git access

Hi Bill. Can someone grant me the ability to push branches? I've got a few feature branches I'd like to get feedback on but I can't push them because they have slashes in them (I assume it's preferred that I not clutter the branch namespace unnecessarily.) I believe that you should already

More aggressive gc of weak mappings in Pike 7.9

Hi. I've now implemented the new rehash behaviour that we discussed during the conference ~2 months ago. This means that weak mappings that contain the only reference to a reference-counted object will free the object when the hashtable is resized. Note that this only takes care of the most

Planned outage of pike.lysator.liu.se

It should be up now.

Assign where compare meant

The fixes look good to me.

7.6 Beta: 7.6.128

I've prepared a beta release of 7.6 that contains all of the fixes from the past few years, up through last week. Sadly, it doesn't contain the clang patch that was just committed by mc, but I think it wouldn't have made a big difference in overall clang compatibility. I realize that many

Updated keys for git

I've just had to change my ssh keys due to a theft of equipment, and I need to get my git access back. Can someone update my key(s)? I've placed the new key(s) in my authorized_keys file on pike.ida.liu.se Done.

<    1   2   3   4   5   >