In D823#12879, @sunnyflunk wrote:

Also I need this patch added and tested https://github.com/ansible/ansible/commit/ed56f51f185a1ffd7ea57130d260098686fcc7c2

In T6#76513, @sixtyfive wrote:

Done, @mcritchlow! Let's hope you're right ;-)

Edit 1 (August 19):

Thanks for the feedback. This is a good feature request. We have added this to our feature request list. Please follow us at http://blog.zoom.us for new product and feature announcements.

Sounds like corporate text modules to me, but we'll see...

Edit 2 (August 21):

I just got another message from one of the "support leads" at Zoom, and that one sounds real good and convinces me that indeed they now have native Snap package generation (not via FPM) in their internal issue tracker. I was also recommended to subscribe to updates to the Linux client at https://support.zoom.us/hc/en-us/articles/205759689 (button labelled "Follow" in the upper right corner).

It would probably still be good if more people followed @mcritchlow and also wrote about this to the Zoom support folk.

I updated my other laptop which is running the lts kernel to the latest sync and get the same error/message. So this isn't something specific to the current kernel, fwiw.

@JoshStrobl - sure thing. I cherry picked a few that I thought were of interest and linked to the full changelog for folks interested in the full details.

add updates and link to changelog

@sixtyfive - yep, I agree and that's essentially how I responded. I will say Zoom's customer service has been surprisingly great. So like I said, I think if others hit them up with the same request it seems reasonably likely to get some traction.

That's awesome, thanks @ikey !

With the recent inclusion of snapcraft in Solus (yay) I've messaged Zoom requesting that they package the app up as a snap. I really think it would make their lives much easier, and ours as end users. Couldn't hurt for others to bother them as well if you agree. The response I got was positive, and they've added it to their feature request list.

Wow, it's case-sensitive.. I had [greeter] at the top, but switching to [Greeter] works. Huh.. Well anyway, thanks @ikey !

In T678#75697, @Timalex wrote:

Will attempt a qualitative argument. The clones I've tried, even the nicely integrated one here, including on Android don't come close to the color filtering quality of f.lux. The clones give the impression that it's just a linear red/yellow color filter slapped on top of the screen. f.lux. has got it down to a science and for example understands that light in the green spectrum affects wakefulness as well. Also movie mode is a very useful compromise when you wan't to watch a movie without turning it off or having too awful colors.

What's wrong with the built in 'Night Light' applet? Are you using Budgie or Gnome? It's been rock solid for me, on Budgie at least, and very well integrated.

switch font files back to otf to match repo

Just realized the name of this repo has otf in it. derp..

beat me to it :)

in my experience, that doesn't scale the entire greeter UI. It just scales the fonts. Which I felt just made the whole thing look.. wonky. Though I guess you can actually read the fonts on the screen.. I guess it depends on your needs, but @kyrios123's suggestion is the best we have with our current greeter.

FWIW - This wasn't accepted previously last time. See T6

Going to drop this. The files are in root /etc/ which seems odd. But can live with as-is and pass in a local config file via alias.

install dir change to /etc/lynx

3.38 has since come out.

reverting config change, leaving at default

@ikey -- Definitely not :) I think I'm unclear based on a change to a different ticket (D365) what the recommended approach/path is for config files. Was the original/default /etc/highlight directory acceptable? I got the sense that it wasn't. Sorry about this.

I noticed libm.so.6 was removed from the abi. I don't see an explicit -lm in the makefile or errors in reference to it, though I do see math.h included in one file. Any thoughts or advice?

added important changes in new version

@Justin @ikey - Is this better practice re: the config files?

Changing config directory to /usr/share/defaults

holy shit, it works! thanks @ikey ! never thought i'd be so happy about a damn touchpad ;)

I feel like there's a joke I'm missing out on.. But happy to make changes needed. After a quick search, I suspect by stateless in this context you're referring to https://clearlinux.org/features/stateless?

Oh.. that helps so much. Thanks again!

@sunnyflunk - Thank you! For my own education, why did inlining the task alongside %make_install work when having it on a separate line did not? The (previous) behavior I saw was that the task didn't have root access to install the generated man page. Just curious, in case I run into this kind of thing again.

properly invoke install-doc

don't bump version twice. that's just crazy.

updated to 1.2.0, in addition to fixing the man page generation

Thanks!

@ikey, was looking back to try and find the commit(s) Masaki was referencing in the 4.10 series.

@JoshStrobl - I think this is good to go now, assuming you approve.

removing libxslt dependency, no longer required

clean up commit formatting

removing NOKOGIRI export line, because confusing developers is mean

test plan and updates seem to have gotten lost. Adding again.

Replaced current bin/vagrant installation with symlink. Added test plan. Cleaned up Description.

cleaned up changelog and added test plan

@JoshStrobl - will do. I need it for an app at work, so I'll get a new patch in for just jp2. Thanks!

Fixed naming versioning naming convention to align with previous pattern

Thanks @ikey , fingers crossed over here ;) Someone is helping out already in that ticket, so I'm cautiously optimistic.

After doing more research, I suspect this is not an issue with Solus, but rather in the kernel. It seems to be a pattern with ALPS touchpads..

@JoshStrobl - So yeah, I believe this is the result of https://github.com/mitchellh/vagrant/pull/8571

In D133#1754, @JoshStrobl wrote:

Concerned about the ABI removals. Is it checking for xslt during configure time, is ours too old and thus it's disabling it, did they drop functionality that would've used it, etc.

Adding a few other logs in case that's helpful:

per @kyrios123 comment above, the work-in-progress issue asking for a release in kbps https://github.com/keybase/kbfs/issues/686

@JoshStrobl will do - thanks for the reminder on this. Will do. Do you have a preference over sticking with the 2.2 series of Ruby vs going to a more recent series such as 2.3 or 2.4? I know rebuilds will be needed, so curious if it makes sense to update to a newer series.

One note on the docs [1] for Fixing a patch that needs changes. After running arc diff I received a prompt to enter a message. It wasn't entirely clear whether this was optional or what it was for. Though it did mention my existing ticket, which was cool. Clearly it adds a comment to go along with the changes, which is great. Maybe call that out? Something like what's written in the arc diff section above?

remove system.devel pkgs, pinentry

Nice! I was thinking of --amend on the git side, wasn't sure what arc would want. It's almost like you all planned ahead for such things :)

@JoshStrobl @ikey - Thanks for the feedback. I'll pull openssl-develand libxml2-devel out. I thought it was worth being explicit, but happy to remove since as you said they're in system.devel