@mpdesouza @sj @monsieuricon Yeah sure, I was not sure what to ask. I guess the thing to ask would be one dependency that at least suse does not seem to have: perl-Inline-C

OpenSUSE has perl-Inline and perl-Inline-Python packages only.

Flatpak package would be probably solution that would acceptable for most kernel developers because anyone can install it. The only glitch in that would be flatpak run prefix but that is not a big deal.

@mpdesouza @sj BTW, I went through all public inbox packages in OBS but none seem to work out of the box (tried locally both with osc and rpmbuild). I tried tune them various ways but without any mentionable success..

One working way would be probably to use OCI container, flatpak, appimage or something that containerizes all the perl shenanigans but gave up for the moment with this...

@sj @mpdesouza never heard but look worth of giving a shot!

BTW, thanks for the earlier busybox tip @ncopa! I might start using Alpine for testing x86 because for such a set n stone platform it is pretty efficient :-) I.e. the robustness that BuildRoot provides when working with SoC's, SBC's, FPGA's and that sort of stuff is not really required for x86.

For the record, for ad-hoc images I always use BuildRoot but it is nice to see also bigger features running as part of distribution kernel. In this case it is SGX cgroups which I have already smoked tested with kernel/busybox/notmuchelse style payload.

wondering that when compiling a Git tree that is packaged like distro kernel RPM packages for OpenSUSE is it enough to just point LINUX_GIT to a kernel tree clone?

I made this conclusion from: https://github.com/openSUSE/kernel-source/blob/master/scripts/linux_git.sh

But there's bunch of scripts so possibly something else needs also to be taken into account. I just thought that this is easier path to test a few patches vs using patch sequencing which would make more sense, if contributing to the downtstream kernel itself.

Cool story about 3M floppies https://spectrum.ieee.org/3m-floppy #floppy

@mpdesouza I've piped the pages a few times with wget, w3m and grep to check some info, ok maybe this does not count as "convenient" :-) does the job...

this would be something where rust port would be applauded given how many dependencies you need to process email properly...

@mpdesouza That said, I gotta say that I love the site's web design :-) Supported browsers include curl and wget. https://public-inbox.org/ #nojoke

@mpdesouza Yeah, it looks like awesome tool so it is a shame. Like something less involved than full subscription to a new subsystem ML.

Lately I helped a bit with tracing subsystem in Linux but otherwise it is not what I'm working on so in that sort of scenario lei would probably help somewhat...

@itaru @LWN For Linux kernel it is best thing to get bird eye view "what has been going on past week".. With the amount of traffic at LKML would be practically impossible to keep track of everything that way. So it is a necessity to exist, not just valuable :-)

Does not recognize any of the lei commands tho (tried ls-search, edit-search and up).

Took the symlink install route:

git clone https://public-inbox.org/public-inbox.git && cd public-inbox
perl Makefile.PL
make symlink-install prefix=$HOME/.local

There’s a spec file in OBS but no official package to this date (b4 has an official package).

@Aissen @liw clippy with all and pedantic for every commit.

Is there off-the-shelf OpenSUSE RPM package of local email interface (lei)?

I also tried to seek for the source code but it is not available here: https://git.kernel.org/pub/scm/utils

After trial and error (earlier post), I’ve found out that only three steps that are required to migrate SDDM/KDE to a Wayland-only system in OpenSUSE Tumbleweed:

# systemctl disable xdm.service
# systemctl enable sddm.service
# cat > /etc/sddm.conf.d/10-display-server.conf << EOF
[General]
DisplayServer=wayland

[Wayland]
CompositorCommand=kwin_wayland --drm --no-global-shortcuts --no-lockscreen --locale1
EOF

End result:

$ pstree `pidof sddm`
sddm─┬─sddm-helper───startplasma-way───{startplasma-way}
     └─{sddm}

Also sanity-checked ps aux | grep -i xorg. Makes sense now that I know the steps but was pretty hard to find the correct steps because did not really know what I was doing :-) The default value for DisplayServer is x11 and then default value for CompositorCommand is weston. Thus both need to be updated.

#OpenSUSE #Wayland #KDE

@Conan_Kudo @fedora that utpm error is weird and does not report where it tries access the accounting db so i just ignore it for now :-) no idea how to tackle the problem right now

@Conan_Kudo @fedora Deleted my own config. It seems to use /usr/lib/sddm/sddm.conf.d/11-kwin_wayland.conf as long as sddm.service is enabled instead of xdm.service.

@Conan_Kudo @fedora

With trial and error I got OpenSUSE working with only Wayland. I did first:

$ sudo systemctl disable xdm.service
$ sudo systemctl enable sddm.service

And created a config file:

$ cat /etc/sddm.conf.d/wayland.conf 
[General]
DisplayServer=wayland
GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell

[Wayland]
EnableHiDPI=true

Only glitch I see is in systemctl status sddm:

Apr 01 17:58:05 suppilovahvero sddm-helper[2368]: Failed to write utmpx:  No such file or directory

Not sure what kind of side-effects that might have…

@Conan_Kudo @fedora Actually in my running session also:

$ echo $WINDOWMANAGER 
/usr/bin/startplasma-x11

I’d expect it to be different within the session, does not feel aligned with the value of XGD_SESSION_TYPE but I don’t have deep knowledge of their semantics so I guess I’m lacking some knowledge.