XSF Discussion - 2019-02-04

I would assume conversations had to go through the same hassle? Also Signal

Wow I was joking about overthrowing the French govt earlier but maybe it's time

Is there a way to check whether the eventually released French binaries are the same as in other countries?

I'm now wondering how it works with Linux distributions even.

Looks like only apple requires it

Like maybe everyone else should ask the French Kings permission too but just doesn't

They can only enforce it if you go over some software store

Thats the downside if most people only get software through a software store like apple or google store

What about distribution repositories

(Not that I want any of this bs there, just curious)

pep. repositorys are like http servers, i think its too much work for a government or an agency to monitor all possible repositorys

its easy to make one big company follow some rules

because the company wants to make money in this country

Marketing issue: Because we all love the wonderful orange hoodies sold at the summit, we talked about having an "inofficial XMPP brand colour", which more or less matches the hoodies. The XMPP logo has two tones of orange: https://www.color-hex.com/color/e96d1f and https://www.color-hex.com/color/d9541e

The former looks more "aggressive" to me than the latter. I'ld prefer that, but as most software developers, I'm not good when it comes to design and marketing stuff.

debacle: I guess this is something for the board, maybe it should be added to agenda?

goffi, after that you need to change the colour of your SàT starfish :)

I'd like to have a Jabber hoodie.

talk to cisco about that

Ge0rG I think ralphm took them home, so you might be able to have him ship one to you.

Guus, I think that was just a taunt :)

Jabber is only trademarked for computing and communication, right? You can have a Jabber washing powder or Jabber fashion products.

I have all the hoodies here, as well as the XSF flag that Guus has had made.

No, I'm actually interested in having a Jabber hoodie.

print one?

(There's another flag with Daniel, btw)

🤔 can do. Will I violate trademarks?

XMPP is not a trademark, as it was "invented" especially for the purpose of not being one, so that it could be used as the name of a set of protocols with the IETF.

And Jabber logo is officially owned by the XSF.

who cares Ge0rG , XSF is :P

there is still 0 paperwork showing XSF has the right to do anything with jabber

(I.e. the bulb used for the JSF logo, not to be confused with the bulb Jabber, Inc. used)

there is paperwork saying they had rights up until June of 2001 or something, but nothing saying it was extended

moparisthebest: ok great, and now?

find the paperwork or forget about it, in my opinion

long live XMPP, jabber can go die in a fire

That's one viewpoint, sure.

how can a company rely on a grant of use of jabber from the XSF when nothing says the XSF has that right?

I'd like to cut ties with Cisco at some point as well

also, assuming the old expired agreements were extended and still in effect, a company STILL can't rely on it because the XSF has like 30 days to take legal action against trademark abuses, and the XSF doesn't have resources for that?

but we don't even get that far, because there is no such paperwork, is there?

wasn't last time I asked...

moparisthebest: AFAIU, stpeter has the paperwork

that doesn't sound like a legal defense for a company sued by cisco for using jabber

Ge0rG, do you want to get https://github.com/xsf/xeps/pull/739 merged now or do you want to modify it?

moparisthebest, AFAIK, stpeter has always taken some type of action when trademark violations have been reported.

(having reported one or another myself)

jonas’: I've written another mail to standards@ regarding the still open points wrt. error conditions. Would be nice to get some feedback for that first.

when?

because I just replied to the one from tuesday

oh, I didn't read my private mail yet.

what I forgot to write regarding your second point (clearly defining the error condition for "not in room"): we can have '410 advance and adapt it according to changes in '45 later, IMO

jonas’: Warning: The key used to create the signature expired at: Tue 12 Jul 2016 09:13:45 PM CEST

Ge0rG, gpg2 --refresh-keys

why doesn't it do that automagically?

because privacy

jonas’: if I understand your remark here right, there is no need to add those things into 0410 now?

I think the former <not-in-room/> should be added to '410 right now

(and then backported to '45)

the latter (general not-in-room condition, i.e. not-acceptable vs. whatever) should be in '45, and does not need to be added to '410 right now

(former and latter refering to the order of the points made in your original email)

But my former proposal uses the MUC namespace, for which I'm not an authority

that’s kinda true

I’d try it and see if it passes by council? :>

I mean you’re also using identifiers from the muc prefix for disco#info, aren’t you?

That's a very subversive approach

(while obviously pointing council at it to not make it appear like you tried to smuglge something, obviously)

Yeah, right! 😂

jonas’: my laptop is still busy thrashing, so I can't do any meaningful work right now.

sure

Can we merge the existing changes first, and then have a separate pr for the new condition? That surely would make a better proposition for two council votes.

I am fine with that

(fwiw, I’m asking because I’m on a merge spree)

jonas’: engage the merge button!

so I’ll just merge it now!

it will take approx. 3h to appear on the website because there doesn’t seem a way to cancel builds in the new docker hub interface

It also looks like my OOM condition is nearing its end, after I somehow managed to store a 6.5GB session file into 2GB of free disk space, and can see the "quit" button of this application already

hm jonas’ the xor xep is not on the server

ah, the email template is still lacking the "due to unrelated automated processes yada yada will appear soon"

(i.e.: I forgot to push that one before sending out the email)

look again in an hour

docker build takes ages

k thanks

Ge0rG, gentle reminder about your on-list-ing of https://github.com/xsf/xeps/pull/743

jonas’: I still think that the warning text isn't sufficiently bold and red and blinking

Ge0rG, maybe state that on-list then, with an official -1, so we can get the vote over with.

jonas’: but thanks for the reminder. I'll send a mail to the list tomorrow

:)

thank you very much

✏

jonas’, the new inbox stuff is not yet ready?

what new inbox stuff?

I get 404 for XOR

yeah

https://xmpp.org/extensions/inbox/xor.html

see above

oh

should be there in 15min or so

thanks

one day I’ll silently replace the nginx stuff with a reverse-proxy to a host of mine where I can do incremental builds :-X

Or we ditch docker, and design the tool so that it takes the xeps repo as input and a directory for the html as output, and simply let a web server serve that directory to the world

flow, iteam does not want to execute uncontainerised code on the server.

flow, there is already the makefile which does essentially that

jonas’, I know, but I don't really think that this is a good decission

For the wiki, maybe

But not for the editor tooling

I can see why they made that decision, and I’m not the one to overturn that.

I will complain once in a while about the 1h build times, because those are annoying big time

Can't we have a docker image that contains all the tools? Or do we already, and it's the XEP build that takes so long?

jonas’, you are the one with the most "leidensdruck" regarding that, I decided to that I don't want to get invovled with a process which I believe to be fundamentally wrong

Should be doable to not do it from scratch every time?

everything which invovles not doing everything from scratch all the time requires to move the build of the xeps away from docker hub ✏

and that requires a machine which can do the builds

-ENOENT

Ge0rG, why does it have to be docker? as far as I can tell, most tools is simply python. I am not sure about external dependencies, but I've been told there are other solutions for that besides docker

flow, there is one crucial tool

the toolchain which builds the PDFs

this is terrible to set up

it involves some chain of XSL, some tooling called texml I think, and latex to generate the PDFs

parts of wihch are unpackaged, I think

jonas’, true, and PDFs are nice, but that could be done in docker. How many times have people asked you why a PDF is 404, vs the HTML?

I can totally see why you wouldn’t run that automatedly on any server, even if only because of the CPU load caused by a mass rebuild

flow, as a sysadmin I really understand the need for some form of container. This way iteam doesn't have to know what's going on to deploy the app, editors can do whatever they want in it

even if one split the build into HTML (on the server itself) and PDF (on dockerhub or whatever), there needs to be a way to trigger a build from github on the server, which is another thing iteam doesn’t want

pep., I think "just depend on stuff that is in debian stable" could be a feasible policy in this case

(also completely understandable)

no need to dockerize

(I’m still scared of the webhook-website-build-thing I made for another org)

flow, some kind of isolation might also be desirable. If they ever want to run something unrelated to editorial things

flow, to do this totally safely, one would have to split the build tools out in a separate repository; makefile is executable code, you don’t want to have that updated automatedly on the server

jonas’, splitting tooling and xeps was actually what I also suggested back then

makes it more annoying to use by the editor, too

pep., true, but there are also solutions for that that

I can also see why iteam wouldn’t want to maintain the code execution on the server, given that they’re all very busy folks.

I wonder whether there’s something with nginx where you can ask multiple sources for a URL. like, "try local file first, if that’s not found, try this reverse-proxied service, if that’s not found, return not found"

try_files ?

https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files

doesn’t seem to me that could use a reverse-proxied service as fallback

location / { try_files /system/maintenance.html $uri $uri/index.html $uri.html @mongrel; } location @mongrel { proxy_pass http://mongrel; }

ah

that makes sense then

that could allow editors to host builds which are served until the docker build has passed ✏

I mean ideally editors would run the tooling locally and just sync with a remote directory that is served over http(s)

for certain definitions of "sync"

I see the appeal into relying on the repository build and not on people syncing files on the server

mathieui, does it really make a big difference between triggering the docker build vs running the tool localy? Besides the later being finished way earlier than the docker build?

flow, yes, the docker build always yields a consistent result

when multiple people do editor work and everyone syncs parts of their builds up to a server ... that’s meh

mix into that local, uncommitted changes and it’s getting messy quick

Horrible hack: Download existing files (only really need the timestamps) so the thing believes it already built the things it already built

jonas’, one sure could design the tool so that this shouldn't become a real world issue, i'd say

Zash, oh my god

Zash, I like it

hackidy hack hack

flow, not really, unless you let the tool run `git checkout . ; git clean -f`, which no automated tool should run ever.

jonas’, depends, if this is a repo in a shadow directory…

ugh

but yeah, people have different opinions and experiences about "how to do it right"

too dangerous to write those lines in any tool, ever

back to bug hunting

This feels like https://xkcd.com/2044/

Sometimes I wonder how much time you spend on xkcd Zash

he just has a good memory because he doesn’t keep logs and thus has to rely on his brain, in contrast to all of us :(

Logs wasn't a thing when I grew up

I just don't want to clutter my memory with logs, and logs are mostly free :p

I also never learned to take notes in school.

O_O

I'm also really bad at that

It is possible to do an update of https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2018/ ?

update?

what’s missing?

If it's about the url, that was discussed on the commteam channel iirc

2018

the URL cannot be changed anymore

it is linked to from various sources

Neustradamus, see also https://github.com/xsf/xmpp.org/commit/2c9f80b5bd3301f2bab5a18300146dce7b075c9d https://github.com/xsf/xmpp.org/commit/7862fd7c71a531e8875a0731779554b3e896aedd https://github.com/xsf/xmpp.org/commit/7fd06dc8f805776540add7ed0819861ef3d5b783

jonas’, in hugo there's an "aliases" directives

I had lots of fun

pep., hm, aliases

I was thinking ln -s in the docker build :-X

But redirection/alias...

That creates a stub with <meta/>

pelican does not seem to have any alias functionality

Posted by "Seve, jcbrand" -> https://xmpp.org/author/seve-jcbrand.html strange page too

or redirects

Maybe we can just create the page manually

pep., sounds like a plan, go ahead

<meta http-equiv="refresh" content="0; https://foo.bar/2019-1234" />

Okay

Hacks

So many hacks

of course.

Compat compat compat

jonas’, hmm, how do I create a static page? Do I create a .md with html in it directly? :/

look at how the homepage is created, essentially

it’ll be messed with by templates though

so you probably have to create your own template for that page

I think it might be easier to simply hack the symlink creation somewhere into the build process.

:/

It's not a symlink that we want, do we. It's a redirect

So either <meta/>, either nginx

yes, a proper redirect needs to be done by a webserver

I feel meta is better though

meta is never better

Well.. that's an application issue

Also having they date in the slug seems redundant since it's in the path too

hah, true

(this is where someone says it's required because of reasons)

it isn’t, I think

https://github.com/Nitron/pelican-alias hmm.

How do you feel about having one moar plugin

On https://xmpp.org/extensions/inbox/xor.html No new draft information: https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid And 2 mistakes about -> "Jabber" network It is the XMPP network

Re XEP-0335, https://tools.ietf.org/html/rfc7493 might be worth looking at (ping MattJ)