Conversation
Notices
-
Alright @chimo, could you check if you have my instance in your hubsub table?
SELECT * FROM hubsub WHERE callback LIKE '%social.umeahackerspace.se%';
The 'topic' field should be your site, ending in /1.atom (and don't paste the hashkey or secret fields publically :])
-
@chimo Now I've removed you from my feedsub table, by adding a 'delete inactive' parameter to the !OStatus 'gcfeeds.php' script. Then I resubscribed. I'll just see if you write something and if shows up. :)
-
@chimo And you still don't get any results for the SQL query on hubsub?
-
No, not if it was what I thought... But I'll go eat something and spend some time thinking about something else and then maybe I'll have another insight.
-
starts the petition: "We want our @chimo back in our timelines"
-
btw: !gs shows that @chimo favourited this (1) dent. At least not everything is broken. (1) https://fediverse.com/conversation/503299#notice-504804
-
Looks relevant. And wow. "DB error: unknown error". Very informative. :)
-
@chimo Just so it's not something silly, please check if you have php5-gmp installed.
-
@chimo oh wait, hubsub doesn't do any cryptostuff anyway. My bad.
What would be interesting is if you have a log entry in your !GNUsocial log from this:
common_log(LOG_ERR, "Failed PuSH $mode verify to $sub->callback for $sub->topic: " . $e->getMessage());
(grep 'Failed PuSH subscribe verify to' $SOCIALHOME/social.log)
-
nice
-
This is so weird. I am not sure what would cause this. But apparently you can't insert into feedsub (even though it's an entirely new server and remote profile) and you have problems verifying the subscription for some reason.
Not sure where to start debugging this. I'd just throw a bunch of common_debug(...) calls in HubSub->verify for example and see what each important variable is at each specific line (and especially whether it runs ->update or ->insert).
Same thing with the FeedSub class in the end of the ensureFeed(...) function. What is it trying to insert/update and with what (full) SQL query?
-
If it weren't for your weird database errors I would have asked if you've changed your SSL settings lately (i.e. never/sometimes/always).
Thanks for your patience. Let's hope you don't find the "if user==chimo randomError();" statement that was added as a significant change when going from !sn to !gnusocial (re: http://s.morphtown.de/attachment )/13647
-
...I don't know what, how or why I did with the link there. Time to sleep.
-
I doubt PHP or php5-curl http stuff cares about HSTS :D But I'd love to be proven wrong.
-
Ooooh. Yes, that sounds like you hit the spot! Not the first problem with strict mode I think. Fancy to patch it up?
-
There's also the problem of me not getting a failure to subscribe when you fail to record my subscription... But I'll take care of that. ;) #FIXME
-
@chimo I'll have to look it up, but I don't think so. However I think PuSH 0.4 removed "infinite subscriptions" (a reason why I made Cronish, to be able to check aging subscriptions).
-
@chimo I think that will mean all StatusNet installations likely loose subscription (if the lease time works as it should).
-
@chimo We'll have to accept infinite leases to maintain StatusNet compatibility (sorry if I'm repeating myself).
-
@chimo Yeah, just a unsub/resub cycle will work (or just another subscribe, which scripts should be able to do...)
-
@chimo Alright! And yeah, removing not null is probably the most compatible course of action. That's how it works now anyway, just badly typed.