[Silvan]

Hi,
I’ve updated the kernel to version 6.12.49 and I have included the patch you requested.
The missing files resulting from your build probably are related to a missing dependency that would result by examinating the full build log, maybe kmod.

[Silvan]

You only see a tenth of lines in the Console output box? There should be hundreds if not thousands of lines since the beginning of rpmbuild… maybe the scrollbar is not working?
About not seeing anything “relevant” in /var/webbuild/tmp, did you by chance use the “build” button below the editor or the autodist “build” button in the right?
Additionally, if you clicked on the [x] on the line in the top processes box, then the build log (if done using the “build” button below the editor) is gone.

• This reply was modified 2 weeks ago by Silvan.
• This reply was modified 2 weeks ago by Silvan.

[Silvan]

Addition: as most builds are parallelized you often won’t find the error at the very bottom of the build log. By scrolling up the “Console log” you might find the error information many lines before the end. The Console box tries to help by evidencing possible error lines using a red background.

[Silvan]

When you build a SRPM using the build button of the **Webbuild** you get the build process in a line in the top box. When build is finished by clicking on this line you get the full scrollable build log in the “Console output” box. The build logs for the processes in the top, which you can show in the console output box, are the files located in /var/webbuild/tmp. Or are you looking for something else?

[Silvan]

Hi,
your previous reply was blocked by the antispam mechanism, maybe due to html code and/or urls it contained, and I have later approved it.

Glad you sorted out your issues.

About Docker unfortunately the resolv.conf file will be overwritten the next time you start the container. Public resources say that if you will recreate the container you may run it with docker run --dns 1.1.1.1 --dns 8.8.8.8 ... to have alternative DNS permanently set.

About package build, as I said you may find build requirements missing (flex in this case) because SRPMs specs do not contain a full list of build requirements and the new container has only a basic know set of general requirement installed.

• This reply was modified 2 weeks ago by Silvan.

[Silvan]

This is a Docker issue. If your Docker host is openmamba I can suggest to restart it on the host:
sudo systemctl restart docker.

Possible checks in the running container are the nameservers set in the file /etc/resolv.conf by checking and pinging directly the IP address, by the way this kind of problem when I’ve seen it is usually some sort of problem in docker network interfaces which gets solved when restarting the host service.

[Silvan]

Can you check that the container has access to internet? This is the only explanation I currently have for the “Select a SRPM package” select being empty. You may check if the following command run from a container shell works:

curl https://push.openmamba.org/pub/openmamba/base/SRPMS.base/

The “Select a .spec file” select will be populated when you “Unpack and edit” SRPMS packages.

• This reply was modified 2 weeks, 1 day ago by Silvan.

[Silvan]

Hi,
you should have the “Unpack and edit” button on the right like in the attached image and should start by pressing it.
NOTE: if it is the first time you login press F5 to reload the page, this is a known issue.

Then you get the spec file in the editor and have buttons below. To create a new release add a changelog next to “new release with changelog:” and press the update button. You add the patch from a network url using the “Add patches” box on the right or you should add it manually in the /var/autodist/RPM/SOURCES folder and edit the spec file to add and apply the patch.

Next you may press the “build” button below to start building the package.

These are the very basic things to learn but of course they do not cover everything you may need to know.
By starting a new container you will probably need to install some basic build requirements which are missing.

• This reply was modified 2 weeks, 1 day ago by Silvan.

Attachments:

You must be logged in to view attached files.

[Silvan]

Hi,
although dnf5 is already in the repository to provide at build time the library required by PackageKit, it is not yet tested and supported in openmamba so it should not be installed. If I remember I will write an update in this post when it will be possible to install it.

• This reply was modified 2 months, 1 week ago by Silvan.

[Silvan]

This may be partially redundant with what already written in previous reply:
discovery is a strict requirement of the KDE Plasma desktop environment as it is provided by openmamba so it is by design a requirement of the desktop-base-kde meta package. kwin-x11 is a weak requirement of desktop-base-kde and it is removed because it was installed by desktop-base-kde itself which you are removing, so dnf considers it a leaf which is no longer required. Supported openmamba Plasma desktop users are not expected to remove neither desktop-base-kde nor discover.

By wanting to uninstall discovery you are customizing your desktop installation in a way which is not supported by openmamba, so you will also get desktop-base-kde and, e.g., mambatray tools removed. You can do it but then you have to manage the desktop requirements on your own. You can of course just reinstall kwin-x11 after the removal of desktop-base-kde for your needs. You can also make and maintain your own desktop-base-mycustomkde metapackage if you want and know how to do it.

• This reply was modified 3 months, 2 weeks ago by Silvan.

[Silvan]

By uninstalling discover also desktop-base-kde has been uninstalled. desktop-base-kde is openmamba metapackage which ensures that all requirements for KDE Plasma are installed as expected for openmamba desktop users.

If you remove this metapackage then you need to fulfill the KDE requirements and any required change upon upstream Plasma updates on your own.

Specifically, the missing or broken features you have noticed may depend on plugins that have been moved into the new kwin-x11 package which has not been installed automatically for you because desktop-base-kde has been removed in your previous installation.

[Silvan]

einar.hjortdal wrote:

I believe the update from the 23 june broke plasma-desktop or kwin. I do not have the ability to switch virtual desktops any longer, the virtual desktop widget pager is gone from the panel and windows overlap but cannot be moved. Typical shortcuts to change window sizes do not work.

By not being able to switch virtual desktops you suggest that your plasma desktop is running and you should be able to run programs. If that’s the case you may open a konsole and troubleshoot the problem by yourself by inspecting logs or run the openmamba “system report” and send it via the website if you are expecting suuport from whom is writing.

With the latest upgrades KDE Plasma has been updated to 6.4.0 release and proved to work on some test environments. The kwin package has been split upstream into kwin (wayland) and kwin-x11, by the way both are installed if you have performed a full system upgrade because the desktop-base-kde package will require the new kwin-x11 package as a soft dependency. Provided that all packages have been upgraded the system logs may reveal if there is some plasma component which is reporting errors or crashing.

• This reply was modified 3 months, 2 weeks ago by Silvan.

[Silvan]

Ok. Release 470.256.02-5mamba supposingly fixed it.

[Silvan]

Hi,
does access to any virtual console work by pressing CTRL-ALT-F2..F8? This would allow retrieving log information from the console to identify the cause of the issue.
If not, the only way to get useful information would be to start the kernel with the “debug” menu choice (or removing “quiet splash” from Grub command line).
Did you by any chance install the “nvidia” proprietary driver?

[Silvan]

In order to check for any low level error returned by the authentication layer you may want to login into a tty console after you got the password rejected, then run:

sudo os-makereport

this will create a report file that you can send for us to inspect.

Or if you have the required console skills you can check for any relevant error (maybe reported by PAM) in the user and system journal with sudo journalctl -b or journalctl -b.

[Author]

Posts