A 0.6.9 / 0.7.0 release?

[agx]

Is there a chance to have a new release with all the nice addition since 0.6.8? It seems at least chatty (https://source.puri.sm/Librem5/chatty) expects post 0.6.8 (https://source.puri.sm/Librem5/lurch/-/commits/librem5) and with more widespread use it would be great if encryption could work out of the box and distributions prefer to package released versions.

[gkdr]

I would like to, yes. I was planning to make the 0.7.0 cut after I finish the signal API and can delete the horrible current command interface code. I'm basically done with it too, but I got stuck on the "status" signal for chats:
Mods can see all JIDs, so just by checking if I can access the members' JIDs I cannot tell whether a MUC is anonymous or not. Cheap solution is to just write "everything seems fine, but this might not be true if you're a mod", but there is probably a real way to check it.
Maybe someone has a pointer for me?

[DanScharon]

the query for the room config should provide this information: https://xmpp.org/extensions/xep-0045.html#disco-roominfo

But as described here this setting could change anytime so that's why a client must look out for the status codes: https://xmpp.org/extensions/xep-0045.html#security-anon

[gkdr]

@DanScharon Thanks, that's very helpful! I wanted to use locally available information and couldn't find it in the structs the XMPP prpl provides. I just checked and the /config command available in MUCs also just sends a query when it is typed, so this seems the way to do it.

[Neustradamus]

I think that new 0.7.0 will be here after this PR:

• Use dynamically linked libraries axc and omemo #151

@fortysixandtwo, @gkdr: And I hope before the Debian 11 freeze which arrives very soon...

It is the time to merge...

Note: The next Debian 12 will be in 2023...

[agx]

@Neustradamus the freeze does not prevent us from fixing bugs in Debian past that point - both in the freeze and even in stable releases. Please don't pressure upstream maintainers.

[Neustradamus]

@gkdr: Can you create a 0.7.0 version to have the relation with libomemo 0.7.0?

Some OS has only a lurch package and not two packages: lurch + libomemo...
And some OS do not want to update because there is not the lurch 0.7.0.

It is really important to have the perfect OMEMO 0.3.0 with 12-byte IV to be compatible with all clients.

Thanks in advance.

[gkdr]

lurch and libomemo are versioned separately and the similarity in version numbers is just coincidental.

regarding the feature i want for the next release: i am working on the tests. mocking away libpurple is very whitebox-y and hard to maintain but i'm not sure there's another way right now, and setting up integration tests might be very annoying downstream.

[Neustradamus]

@gkdr: Thanks for your reply!

The problem is here for example: AOSC-Dev/aosc-os-abbs#2568.
cc @Fearyncess.

[Neustradamus]

@fortysixandtwo, @henry-nicolas: About the next "0.7.0" release, it will be always good for Debian 11?

@GKR: Some OS maintainers wait the new lurch build because they have not 3 packages (axc/libomemo/lurch).
For example @Fearyncess.

Note: There is a problem with the lurch package name, never same name:

• https://repology.org/project/lurch/versions
• https://repology.org/project/libpurple-lurch/versions
• https://repology.org/project/purple-plugin-lurch/versions
• https://repology.org/project/lurch-purple/versions
• https://repology.org/project/purple-lurch/versions

[henry-nicolas]

I see 2 questions there so let's take those 2 points separately:

1. On version 0.7.0: the soft freeze starts mid Feb (12th Feb) - new releases that did not transition to bullseye before that point will stop transitionning. As @agx pointed out earlier, bugfixing is different but for version updates that is the date, so let's not rush anything. Maintainers can always patch downstream and remove those patches once the fix is merged upstream. You can check the Debian package git repo for purple-lurch here (including patches applied): https://salsa.debian.org/DebianOnMobile-team/purple-lurch

Something else that must be considered (if I got it right): Debian entered the transition freeze already. That means we should not upload new library version that involves API/ABI breakage which would require a transititon request to the release team - not sure if this updated version would fall into that category though (if there are breakages).

2. On the package name: there are different downstreams maintainers for different GNU/Linux distributions. I don't think there's much we can do about that.

[craftyguy]

On the package name: there are different downstreams maintainers for different GNU/Linux distributions. I don't think there's much we can do about that.

Furthermore, some of those names were likely chosen because they follow the same naming format for other purple plugins in the distro. So even though it's inconsistent naming for you, it's consistent naming within the distro (which, arguably, is more valuable for users of the distro...)

[Neustradamus]

@henry-nicolas: I know where are git repositories:

• https://tracker.debian.org/pkg/libomemo
• https://salsa.debian.org/DebianOnMobile-team/libomemo

I think that in Debian 11 Bullseye, 0.7.0 of libomemo will be a 0.6.2+git... and will be same with purple-lurch when 0.7.0 will be here...

• https://tracker.debian.org/pkg/purple-lurch
• https://salsa.debian.org/DebianOnMobile-team/purple-lurch

@hartwork can help you:

• 12 byte IV for outgoing messages libomemo#24 (comment)

@craftyguy: Yes of course, I have not said that OS maintainers have taken a bad name ^^
I inform only that it will be nice to have a perfect name in the main repository :)

[Neustradamus]

@gkdr, @henry-nicolas, @fortysixandtwo: Any progress on it?
People really wait this version with good OMEMO...

[fortysixandtwo]

Rest assured that this has not been forgotten and is being worked on.
See f.e. #151 which probably should be included in a new release.

Thanks for your continuous interest, but please try to be patient.

[Neustradamus]

Yes, it is only because user requests to have the good OMEMO in all OS.
And Debian 11 last date is... 2021-02-12.

[Neustradamus]

I have done a PR to solve a missing part in changelog of libomemo 0.7.0.

[gkdr]

@Neustradamus send me a babysitter and this will be done in no time 🙂

regarding the issue i mentioned initially: i have implemented the status check via a query, but now while manually testing against prosody i witnessed the following: if a non-moderator user joins an anonymous room which is then switched to non-anonymous, the change is somehow not properly communicated to the prpl. that means that the JID is still not accessible until the room is rejoined.
currently, there is a slight bug in my code since i assumed this could not happen at that point in the code (ha-ha). as far as i can tell, this is easily "fixed" by properly checking and asking the user to rejoin i did not see any possibility to re-request "presence" after join while skimming the XEP, so this might be by design? but of course this is more likely to be me, so if anyone has a pointer to a more ergonomic solution, i'll gladly take it.

[gkdr]

i just pushed the switch-over to the api-based command interface in c255455. it was available as /lurch-v2 for some time now, but i guess i didn't really communicate that. so if someone wants to give me some feedback on the new structure/output, it's appreciated. with UI, tiny and easy to fix things can make a huge difference 🙂

[gkdr]

there you go: https://github.com/gkdr/lurch/releases/tag/v0.7.0 😬

[Neustradamus]

@gkdr: Thanks!

Can you look current PRs

• https://github.com/gkdr/lurch/pulls

[gkdr]

by the way, @henry-nicolas - as this is a plugin for libpurple (2), i think there is no api breakage as it did not have any other interface before. now there is the signals API and i'll have to consider that when making breaking changes, but that's a problem for another day.

[henry-nicolas]

Thanks for the heads up @gkdr - that is good to know