~mil/sxmo-tickets#246: 
1.5.0 Release

TODO:

  1. Update the swipe gestures image (https://git.sr.ht/~mil/sxmo-docs/tree/master/USERGUIDE.md#strongglobal-ui-controlsstrong) and swipe documentation to reflect the change by this patch: https://lists.sr.ht/~mil/sxmo-devel/patches/21982
Status
RESOLVED IMPLEMENTED
Submitter
~anjan
Assigned to
No-one
Submitted
5 months ago
Updated
a month ago
Labels
No labels applied.

~proycon 4 months ago

On 21-04-24 05:34, ~anjan wrote:

TODO:

  1. Update the swipe gestures image (https://git.sr.ht/~mil/sxmo-docs/tree/master/USERGUIDE.md#strongglobal-ui-controlsstrong) to document the change by this patch: https://git.sr.ht/~mil/sxmo-docs/tree/master/USERGUIDE.md#strongglobal-ui-controlsstrong

You linked the same thing twice so I'm not sure what patch you meant ;) I did update the image after the 1.4.0 release.

As for the packaging of 1.5.0, we'll need to upstream the packages to Alpine instead of postmarketOS: https://gitlab.com/postmarketOS/pmaports/-/issues/1068

--

Maarten van Gompel (proycon) https://proycon.anaproy.nl

~anjan 4 months ago

I fixed it with the actual link to the patch ~proycon

~anjan 4 months ago

~proycon 3 months ago

For 1.5.0, we need to add 'pn' as a dependency for sxmo-utils.

~proycon 3 months ago

Aside from the work related to pn, further things that should make it into 1.5.0:

  • the newlock mechanism

~stacyharper 3 months ago

We should notify that we now rely on default hooks for suspension wake ups scripts

~stacyharper 3 months ago

BTW: newlock has been merged

~stacyharper 3 months ago

We should also document that we added an argument to the user inputhandler hook

Yeah we added the argument "$WMNAME" to the user hook as the second argument. Just replace $2 with $3 and you should be fine

https://todo.sr.ht/~mil/sxmo-tickets/273

~anjan 3 months ago

TODO:

  1. Update sxmo-utils package:
  • Remove netsurf as dependancy
  • Add pn as dependancy
  • Add scrot as dependancy

Any other package changes I missed?

~noneofyourbusiness 3 months ago*

Scrot doesn't have to be added, the entries check if it exists - so it's up to you. If you do make sure to remove the check for scrot.

~stacyharper 3 months ago

We must document sxmo_migrate.sh

~anjan 3 months ago

Depending on whether we check whether pmos-tweaks is installed (see: https://lists.sr.ht/~mil/sxmo-devel/%3C20210622042350.13435-1-anjan%40momi.ca%3E). That will decide if we need to add that package as a dependency to sxmo-utils.

~anjan 2 months ago

Okay, so things blocking 1.5.0 release are:

  1. DTMF tones not working
  2. modemmanager patch to fix sms in crust suspend.

To fix 2, I think we can send patch the modemmanager in pmOS until we find a permanent solution with upstream. ~stacyharper do you have a link to the exact patch we would need in pmOS to make sms in crust work?

~kavuskazian 2 months ago*

DTMF tones work fine for me, I tried by calling my boyfriend and sending them. I was also able to check my voicemail and use the DTMF controls.

Also where should I ask about putting foxtrotgps back in? It says it's in in the documentation, but it's not.

~anjan 2 months ago

~kavuskazian, are you on the latest git HEAD or running 1.4.0?

~anjan 2 months ago

~kavuskazian there were multiple bugs with foxtrotgps so we dont really recommend it. You can still install it via apk iirc.

Btw, miles is writing a suckless replacement: https://git.sr.ht/~mil/mepo

~kavuskazian 2 months ago

I'm running 1.4.0 on PMOS v21.06. Which I now realize is probably why it works for me and not for you. I can't get PostmarketOS edge to work. And as for mepo, great! That's really awesome.

~proycon 2 months ago

On 21-07-11 04:42, ~anjan wrote:

Okay, so things blocking 1.5.0 release are:

I think there are some further things with newlock/crust blocking release:

  • the screen blinks too often and sometimes leads to some kind of race conflict between on/off and the screen bleeds out and I need to reboot.
  • I seem to sometimes get an extra black screen stage with no LED on when leaving crust, pressing the power button once again brings things back to normal
  • entering/leaving crust when sound is playing may lead to sound 'hanging' and stuttering indefinitely when coming back from crust, I proposed a simple patch for that already.
  • sxmo_migrate.sh should handle custom hooks, the user's old postwake hook may be out of date with the new requirements and lead to unexpected behaviour.

I wonder if others have similar issues?

Since the newlock is one of the main features of 1.5.0 I think we should ensure it's pretty flawless when we release.

  1. modemmanager patch to fix sms in crust suspend.

To fix 2, I think we can send patch the modemmanager in pmOS until we find a permanent solution with upstream. ~stacyharper do you have a link to the exact patch we would need in pmOS to make sms in crust work?

It seems https://gitlab.freedesktop.org/ is currently having issues so I can't find it either now...

I do propose we do a temporary 'feature freeze' (no major new functionality merges) and focus only on fixing things that are broken until we release 1.5.0..

--

Maarten van Gompel

proycon@anaproy.nl https://proycon.anaproy.nl https://github.com/proycon

GnuPG key: 0x39FE11201A31555C XMPP: proycon@anaproy.nl Matrix: @proycon:matrix.anaproy.nl Telegram: proycon IRC: proycon (libera.chat + oftc) Mastodon: https://social.anaproy.nl/@proycon (@proycon@social.anaproy.nl) Twitter: https://twitter.com/proycon

~stacyharper 2 months ago

~stacyharper do you have a link to the exact patch we would need in pmOS to make sms in crust work?

Absolutely not. I'm not aware of which patch we need or not. I only know that my master version works where the last release dont.

We could probably release a rc with specific master targets.

~stacyharper 2 months ago

My issues :

  • Sometime the cron task does not trigger and leave the phone in lock/off state (not crusted back)
  • Sometime my dwm or X11 is soft lock in shift mode. I dont know how to reproduce it reliably and it seems I'm the one relating this o_O

I also can relate your minor blinking issues but it never has been a real issue in my cases.

  • sxmo_migrate.sh should handle custom hooks, the user's old postwake hook may be out of date with the new requirements and lead to unexpected behaviour.

Yeah I stripped this on last patches but I may be wrong

~proycon 2 months ago

I'm still struggling with the crust/newlock issues, haven't manage to find a proper solution yet. One related issue that is bothering me is that the unlock buttons seem to easily cause a conflict, I often find a terminal or browser gets launched after I tried to unlock.

~baroque0 2 months ago

interesting. running a 24h old build on 21.06, and i have:

  • none of anjan's annoying screen blinking
  • never seen stacy's "soft lock in shift mode"... but i had some strange issues that could be linked to xinput in a twisted way, maybe..?:
    • several time i ended up having gestures that stopped functioning at all. last time was after doing a gesture-based rotate, then immediately attempting to rotate back -> then no gestures worked at all. rotated back manually, no gesture worked either. then sometimes it magically came back.
    • many times already svkbd stayed "locked" on some input, usually left-arrow, until i input anything.

no idea if these things i related... but in all cases a rc makes sense, and the objectives for 1.5.0 seem reasonable and achievable!

go 1.5.0 and beyond! <3

~baroque0 2 months ago

~proycon: "One related issue that is bothering me is that the unlock buttons seem to easily cause a conflict, I often find a terminal or browser gets launched after I tried to unlock."

see what you mean. i frequently have new firefox windows poping up here and there.. :) (esp. embarassing when session gets later restored.. )

maybe we could (temporarily?) gave up on defaulting long_power as equivalent to triple_power? and satisfy ourseves with opening a browser with triple presses on power only? (and whatever clever gesture might come in a near future)?

on a side note i would also strongly advocate for raising the timing for double and triple click as a default... even if they're doable while being focused and with a steady grip, while moving and doing whatever in daily-driving, triple-click at 50ms rate can be pretty challenging to throw...("hadoooken!") i would suggest 80 or 100ms as a new default. trying to throw many of these hardware buttons-shortcut within the same 200msec is probably not so frequent anyways?

but i am nitpicking, just evoking... none of this may need to come before 1.5.0 is released.

~noneofyourbusiness 2 months ago

I do not experience the issue of launching the browser on unlock. Just holding the button down will unlock it, nothing more.

~arjunaithal 2 months ago

The unlock in default_hooks can sometimes start 2 lisgd processes and I see a hung keyboad or 2 keyboards. And i still get this issue - https://todo.sr.ht/~mil/sxmo-tickets/302 at least twice or 3 times in a day.

~proycon 2 months ago

Some update on the unlock issues I was having, it appears it was caused by me removing "sleep 5" from the postwake hook, I've sent a patch with a more robust solution.

~murks 2 months ago

I had some issues with getting the phone in a weird state where it was totally unusable using wakeup/sleep, did some experimentation and found a bunch more issues. I know how to work the buttons such that it works but it's not hard to trigger unintended behavior. I will try to document that cleanly somehow (including button timing, for which I'll need to come up with some syntax) soon™.

~proycon a month ago

I started work on a merge request to Alpine Linux (still in draft): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23729 (the other co-maintainers should be able to push directly to my sxmo1.5.0 branch of aports on gitlab).

I'm also pulling in the latest changes from upstream suckless for our various suckless tools.

~proycon a month ago

Packages tagged for release thus-far:

  • sxmo-st
  • sxmo-dwm
  • sxmo-xdm-config
  • lisgd

The following have no changes and need no new release:

  • clickclack
  • sxmo-dmenu

And the following are still pending and need some action:

  • svkbd (waiting for upstream suckless to do a release, request sent)
  • mnc (waiting for anjan to give push permission so we can merge the latest patches)
  • sxmo-utils (blocked by the above)

~proycon a month ago

mnc and svkbd are tagged for release too now and packages queued in the MR. The final one will be sxmo-utils, stacy's doing some testing with a new build of the modemmanager so I'm holding out that one for now to see what the findings are and if any extra patches are needed.

~proycon a month ago

The MR for Alpine is as good as ready now: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/23729 ... Care to double check if everything seems in order? (especially regarding dependencies).

I also started a draft MR at postmarketos (edge): https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2393

~mil a month ago

Pushed a minor update for pending sxmo-utils 1.5.0 to not set SXMO_SCREEN_LOCK_OFF=1 by default in xinit_template.

https://git.sr.ht/~mil/sxmo-utils/commit/69fe290dfacd9c9930d072ffe1cce423463bae83

Figure this is better default as that's what we reference in docs and was old functionality default too.

~anjan you're more familiar with new lock logic so please comment if there's a reason not to default this (e.g. I assume setting in xinit_template previously was a typo - lmk if not).

~anjan a month ago

~mil looks good to me. ~stacyharper helped alot with the new screenlock mechanism. ~stacyharper, if you see any issue with this, please let us know.

~stacyharper a month ago

This commit loogs good. I dont see a reason for this to be a default

~proycon a month ago

I'll squeeze that patch in for the upcoming release since all three of you agree it shouldn't be the default (I myself am actually more in favour of the screen off default because it means less actions for the user to lock and I don't see much added value in the lock stage with screen on, but it would be a change from before indeed)

~proycon a month ago

The merge requests have been marked as ready now, I'll send out release notes shortly after merge

~proycon REPORTED IMPLEMENTED a month ago

Register here or Log in to comment, or comment via email.