Just a quick note that there's already a diff tool for KDE in Solus called kompare.

I'll make a note in my samba maintainer README.md that cifs-utils needs a rebuild when talloc gets updated (which can actually happen at any time as far as I can tell).

Which fixes are you talking about in particular that affect you? Please provide links.

I cannot reproduce this on the systems on which I've tried.

If zenmap relies on py2 and there's no upstream activity related to porting it to py3, my position is that it ought to be removed as part of the py2 deprecation process.

Thank you for your continued effort and willingness to help work towards a good solution here.

Assuming that we don't try to patch SDDM and lightdm to work like GDM (I'm somewhat wary of carrying too many downstream patches if I'm honest), I'm leaning towards baselayout right now, yes.

In D9020#146888, @serebit wrote:

In D9020#146887, @ermo wrote:

@serebit:
Give me a heads up when this is ready to land? Looks good to me FWIW.

I intended for this to land with the rest of the JDK changes, but I can test it locally with the current version of openjdk-11 if you want to land it sooner than that.

Give me a heads up when this is ready to land? Looks good to me FWIW.

Having thought about this for a while, I think we should do the following for D8989:

Just a heads up that we're still thinking about how best to handle this.

@xulongwu4 : Your efforts here are much appreciated!

This looks good to me.

See T9049#172076 for my notes.

In D8984#146265, @xulongwu4 wrote:

@ermo Yeah I actually looked into the xsession startup script shiped with gdm and sddm. They both source .Xresources along with .profile and .xprofile. lightdm-wrapper will do the same if this patch gets merged.
.Xmodmap is a bit more complicated. sddm does not load it by default. gdm loads it, however, similar to what happend to budgie, gnome-session actually overwrites keymaps later so all changes in .Xmodmap will be lost. In short, .Xmodmap will take effect in MATE. For the other three desktop environments, there are workarounds. sddm users can add xmodmap ~.Xmodmap to ~/.xprofile as that file gets picked up by sddm and that is also a standard file for stuff like setting keyboard and Xresources. For budgie and gnome users, they need to create an autostart script for loading Xmodmap after gnome-session starts.
I think this is the best we can do, as different display managers have different defaults and also work differently. I guess it is reasonable to assume that user of a specific DM will have some knowledge of that DM if they want to do something like setting their own key maps.

In T9049#172048, @xulongwu4 wrote:

This seems a duplicate of T8859. Feel free to close it as I can't figure out how to close it as a duplicate of another issue.

In D8984#146242, @xulongwu4 wrote:

In response to @ermo's comment in D8678 about setting up the same procedure for other Xsessions, I confirmed that .profile and .xprofile is automatically picked up by gdm and sddm so no changes are needed for those two.

This looks interesting!

In T7415#171814, @Alexandru-Balan wrote:

I'd be happy to maintain this package if that's what's holding it back📦 😊

In T8978#171040, @medusalix wrote:

My suggestion was more about that you gate the action of downloading and placing the firmware in the correct place in the filesystem on a post-install user action and not one second before?

I'm currently embedding the firmware in the resulting binary file, so I'd have to make sure the firmware is downloaded before the compilation begins.
I think I'll go with the automatic download though, because that's exactly what scripts like winetricks are doing too. The Update Catalog links to Microsoft's terms of use which - at least to my understanding - explicitly allow end-user use.

In T8978#171037, @medusalix wrote:

Yes, the entire driver package can be downloaded from the Microsoft Update Catalog (search for xbox net).
A direct link to the appropriate download also exists: http://download.windowsupdate.com/c/msdownload/update/driver/drvs/2017/07/1cd6a87c-623f-4407-a52d-c31be49e925c_e19f60808bdcbfbd3c3df6be3e71ffc52e43261e.cab
I would have already implemented the firmware download and extraction process in the Makefile, but the maintainer of the Debian package told me it wouldn't solve the licensing issues (not sure if that's true).

In T8978#171035, @medusalix wrote:

Done. I'll have to admit that it was a bad idea to include the firmware without permission in the first place, but here we are.
I hope Microsoft will let me know of their decision before taking down the whole repository. It might be a better idea to completely remove the firmware.bin from the repository right now.

In T8978#171026, @kaktuspalme wrote:

@ermo I don't know how that could be possible. A Xbox controller can only connect with the dongle if the dongle is initialized. The dongle gets initialized by xow/service. The connection between the dongle and the controller is over wifi but that's just between the dongle and the controller. There's no network traffic or anything. So I can't listen on a socket.

Have you played around with socket activation at all?

If you move "fixes T8978" from the summary line to the description below, phabricator will cross-reference the Task and the Diff for you (making it nicely clickable).

In T8859#171016, @Schteve wrote:

Hello @ermo,
I'm afraid not and I don't think I'm going to be able to do so in the near term.
Apologies, Steven

Any updates on this? =)

Hard-coding the use of internal/vendored libraries in a header file and expecting packagers to create a patch to override this seems odious.

Do you know if xow supports socket activation instead of a service? Assuming that you plug in a dongle, which then establishes a Personal Area Network BT connection to a controller, I would think that "plugging in" the dongle ought to enable the socket-activated service.

Got a build working locally and have tested that I can run the code to print the mandelbrot set from https://julialang.org/learning/code-examples/ and update packages from within the julia REPL.
.

Looks like the reason this hasn't been updated in a while is that compilation fails with an obscure error when building with/against the Solus system LLVM.

Will take a look today.

Where are we on this from your perspective? What's the logical next step?

In T8859#169403, @Schteve wrote:

/usr/share/default/etc/profile instead of /etc/profile

Thanks. Maybe it should be "as well as" rather than "instead of"? /usr/share/defaults/etc/profile seems to source /etc/profile.d/* and someone might expect the regular /etc/profile, currently a symlink, to work?

I looked into it a bit and it turns out that -- since Solus is fond of the stateless principle (where default configuration is shipped under /usr/share such that any customistations in /etc/ can be safely deleted to return to "factory defaults") -- the lightdm wrapper should at the very least source /usr/share/default/etc/profile instead of /etc/profile (since /usr/share/default/etc/profile will itself take care of sourcing /etc/profile).

In T8859#169354, @Schteve wrote:

Yes (I used one VM with them all installed simultaneously, rather than separate VMs for each). At the least, there were several theming issues:

• Budgie: icons/cursors are set from $HOME/.config/gtk-3.0/settings.ini, rather than those previously set. widgets isn't set in settings.ini and defaults to default. Any changes to the icons and cursors in Budgie settings don't persist across sessions. The nautilus file/folder icons also looked different. On reverting to the current lightdm version, theme changes persist.
• KDE: Hadn't used KDE before but the folder/file icons in Dolphin weren't visible.
• MATE: mate-panel doesn't show up, although it was running. Reverting to the current lightdm version didn't solve this.

Have you had a chance to test this on the MATE and Budgie Solus spins?

On the face of it, the implementation you propose seems innocuous enough, but one can never be too sure.

Just checking in to note that you're not forgotten.

Any news on this? What have you had to change on your end so far?

FWIW, I didn't read your description as accusatory.

Would you consider ensuring that his goes upstream so we don't have to carry patches for it? From what I understand, this could potentially benefit all i3 and similar WM users.

In T8629#168370, @Jacalz wrote:

Is there any reason why AVX2 was turned of in the blender update? The summary had no mention of it so I guess it was accidentally left inside the commit after local testing?

Lack of attention probably.

With what we now know, I suppose this knowledge could be captured in the following comment in the build section:

My results with LLVM_PARALLEL_LINK_JOBS=1 on an FX-8350 w/16 GiB RAM + 4GiB swap:

patterns not paterns?

Tested Gaupol. Can open subtitles and convert frame rates back and forth successfully.