Forum Replies Created
sorry for the delay.
An update of
ibuswill be available in the next hours but this is probably an optional requirement to fix your issue.
The most important thing is that I noticed that
ibus-daemonjust needs to be started before the desktop session. To accomplish this you may want to try to create a file
~/.xprofilewith the following content:
export QT_IM_MODULE=ibus export GTK_IM_MODULE=ibus export XMODIFIERS=@im=ibus ibus-daemon -drx
Then you may remove the lines you added to .bashrc and reboot.
With this configuration I get a ibus tray icon on the bar where I can change the input method and this now seems to work in KDE Plasma applications.
- This reply was modified 1 month, 2 weeks ago by Silvan.
Yes, the rolling release is maintained and for desktop usage provides the latest KDE Plasma release with a lot of software packages.
Please, feel free to try and see if you like it!
good, thanks for finding and sharing the solution to this problem.
for the sound card problem I’ve looked for the different solutions proposed on the web and wonder if you have tried this:
sudo su echo "options snd-intel-dspcfg dsp_driver=1" > /etc/modprobe.d/snd_intel_dspcfg.conf
About the french language, a method would have been to start by using the
livedvdISO image which provides support for french by selecting the language at boot.
Instead, switching language on a system installed from
livecdrequires some manual changes:
1) make sure that the system-wide LANG environment is set to french, this can be done by editing as root the file
/etc/locale.confand replace the existing line with:
2) install the french langpack:
sudo dnf install langpacks-fr
3) configure the rpm
%install_langsmacro in file
4) packages need to be updated or reinstalled so that translation files for the languages specified in 3) will be kept on local installation
thanks for the information provided.
It seems that the
NetworkManagerpackage is missing in recent livecd ISOs.
If you are just running the live system I suggest waiting for a new release which I’m scheduling for tomorrow.
If you have the system installed the problem might be fixed by manually configuring networking and running
sudo dnf install NetworkManageror manually downloading and installing the
NetworkManagerpackage and its dependencies using an external storage device, e.g. a USB pendrive. Feel free to ask more details if you need more details in this case.
can you please provide the output of the
openmamba-makereportcommands from terminal?
dmesg > ~/Desktop/dmesg.txt
The generated files can be sent to us via
Support -> Send a reportor attached to a post in this thread.
we are happy to add new packages and make openmamba more complete. I didn’t know about Latte-Dock and have made a new package for it. It will be available in the main rolling repository in a few hours, but if you run x86_64 openmamba you can install and try it just now with the following console command:
sudo dnf install latte-dock --enablerepo=unstable-makedist
you’re now enabled to use the web build interface. A basic idea of how it works can be deducted by watching this video, although it relates only to the maintainance of package updates automatically queued.
Here are the available channels that may be of your interest as a developer. These include a new Telegram group which I have just created. Sorry, you might find little or no documentation for some of the processes but you can come in contact with me (and with other developers) by using any of the available channels.
- This reply was modified 1 year ago by Silvan.
welcome and thank you for your interest in openmamba.
I know about Fedora and other distros dropping x86 32 bit support and I understand that this is also a consequence of software components which are progessively dropping interest and support for this target. This adds to distribution maintainers the cost of applying themselves patches (when viable) and the process is becoming more and more complex specially in a long term prospect.
openmamba will continue to maintain its x86 repositories with some installation media and kernel available, although some of the components will be dropped as long as it is not possible or too complex to maintain them.
As for your projects, you may want to think to retarget them to 64 bit hardware, as this will probably be the only viable choice in future…
This said, you are very welcome if you would like to contribute to openmamba. Although it is possible to setup a local build environment, our build processes have been based for years on build servers (one for each target, x86_64, x86, arm) controlled by a web interface called
webbuild. This web interface might seem a complication for the classical command line packager, but it has been very useful when it is necessary to have a few (or a single) person to maintain thousands of packages.
If you want to take a look at this interface you should first request authorization for your account by accessing the menu entry
Development -> Webbuild -> buildvm01on the top of this site.
As the maintainer of openmamba I will be glad to assist you if you have any question about the development processes as well as coordinating any aspect that may require changes to the core and toolchains of the distribution.
Hi duskull and thank you for your feedback.
The RasperryPi image
openmamba diskimg-raspberrypi rollingis known to work with the command reported in the documentation:
gunzip -c openmamba-diskimg-raspberrypi-*.img.gz | dd of=/dev/sdx bs=32M
This RPI target is automatically built every week from the rolling repository but images may not be well tested because the current focus of the distribution is the x86_64 target with KDE desktop. So in your image something may be broken for mainly two reasons:
1) the LXDE desktop is not always tested after updates, so there may be some configuration and/or packaging problems to be fixed
2) the openmamba arm architecture also used in RaspberryPi is 32 bit soft-floating point based (this target is also known as ‘armel’). As of today it is not worth investing too much on it because many recent open source projects, especially graphics and web engines, no longer support armel unless applying patches, when possible, and even after doing this heavy work, the resulting target is not adequate with RPI and other recent arm CPU which have a hardware floating point processor and also 64 bit support
The solution in order to revive arm and RaspberryPi support in openmamba would be to support 32 or 64 bit hard-floating point target, but unfortunately this is a hard work which can’t be a priority now due to the lack of resources willing to do it. I keep maintaining the arm target and would like to do this porting work in the future because I like and use RaspberryPi and other arm based singe-board devices for many applications.
Thank you for proposing to help, this could be done in different ways depending on your skills. Porting the arm target of the distribution to 32 or 64 bits hard-floating point requires high skills because the starting point is packaging the cross-toolchain in openmamba (although this is partially done), then a minimal running O.S. needs to be packaged and bootstrapped with this new architecture. Another way to help would be by testing and reporting problems with the more recent images as you did, then providing fixes or interact with me or other developers in order to fix these problems. Although this has benefits for the whole distribution (e.g. the LXDE target is also used in x86_64 based server installations), the problem that the current soft-float target has no future remains.
this may be similar to a problem I’ve seen on VirtualBox related to the modeset driver.
I would suggest to try booting with the ‘nomodeset’ kernel argument. You may add this argument by editing the kernel command line in the livecd bootloader.
according to how it currently works webbuild should be used to prepare, update, build and send .spec files to repositories and to let other developers know what you are working to prevent overlapping (this are just the basic things webbuild is used for).
ssh is often necessary to debug problems, make patches, etc., but a basic webbuild usage is required and we can get into details by analyzing a real case.
So let’s try, if you send me your ~/.ssh/id_rsa.pub I will then give you instructions on how to access the build vm(s). Being the first time I give this access, this will be experimental.
You may prefer sending your ssh public key by using the ABOUT -> Contact US form on this site.
fixing and maintaining current package updates is very important to keep the distribution alive but so far this activity has taken too much time to allow me to develop new things. So it will be good and very useful if you and others can help in this process which varies from very simple activities on some packages (just like updating the list of files packaged) to difficult ones (for instance chromium update).
I suggest to start with the webbuild, which should always be used as the base, but I should next provide ssh access to build vms for better debugging of build problems.
For you and anyone interested I’ve published a chart of the openmamba development model which I made some time ago which may be useful to know to developers:
As for details on using the webbuild for short questions you can use the “Chat with online developers” box in webbuild pages, so I can quickly give you some hints.
Thanks and best regards,
- This reply was modified 3 years, 10 months ago by Silvan.
you now have access to the webbuild interface with initial permissions to send packages to devel-contrib and devel-misc repositories.
You may create packages from urls or update current packages from repositories.
If you don’t know where to start from to help, here is a list of (automatic) package updates failing:
These packages are managed in “autodist – update for x86_64” and changes applied by specfile patches.
Sorry there is not a guide for the interface and cannot write more details now.
please go to
Development -> Webbuild -> buildvm01 (x86_64)from the top menu of this site.
On that page there should be a dialog stating that you may request authorization by clicking the appropriate button, then wait for my response.
Packaging for openmamba and using the web interface is not a self-explanatory thing and you will maybe need further instructions, but this is the first basic step.