Same here. Thanks for the hint. Now I am stuck with typing or pressing in the passcode. Simply does not work or is so laggy. No chance.
Man, you make it hard to help …
The password is 123456
Make sure that you have VT-x enabled in your BIOS/UEFI. Qemu is laggy running inside Debian and PureOS, but it is usable.
I know, thanks. I can not type it in.
What does that mean? How to?
Before I was wrong. There are missing translations. Did one for Chatty and now raised an issue in source.puri.sm asking developers to merge it into repo. Hope that works out well. When successfully done, I will do more translations.
See: https://www.howtogeek.com/213795/how-to-enable-intel-vt-x-in-your-computers-bios-or-uefi-firmware/
You can also type the password with the keyboard. For me, I think that the mouse problem only happened the first time using the VM. I think if I get past the login screen, the mouse works and if I reboot, the mouse works on the login screen. However, it has been a long time since I have used the Qemu image since I already have a Librem 5.
Now I tried to pull the .yaml files for translation from git, finalize them and commit them back to master branch. --> Error message.
Is there a how to … work with gitlab in source.puri.sm anywhere?
Or am I just not allowed to push back files to repository.
Again: Hard to help for non-developers, but still struggling to cross the boundaries.
There is the Contributing page which covers quite a lot of different things, including submitting patches. The way that most repositories are set up on source.puri.sm means that you can’t push to the master branch. Usually, you have to follow these steps:
- Fork the repository on source.puri.sm so that your account has a copy of it.
- Clone the repository locally.
- Create a branch for the changes you want to make, then make the changes:
git checkout -b <name>
wherenameis something meaningful. - Commit the changes.
- Push the commit back to your fork at source.puri.sm:
git push origin <name>
wherenameis the branch name you used.
This last step should result in a message telling you how to make a merge request for your changes.
There is another way to do things but I think the workflow is not quite optimal. This is to create an issue first, then create a merge request for that issue by clicking the Create merge request button. However, I think the instructions it gives when you click the Check out branch button are not correct for the workflow we have. 
A workaround that might be easier is to create an issue in your own fork of the repository, then click Create merge request for that issue. Unfortunately, that wouldn’t help for existing issues.
2 Likes
Hi, I tried to download qemu-x86_64.qcow2 as mentioned in the manual (2.), but i cant’t find it :-(.
It should be available from this page, at least for a few days. The Image Build page lists the images for different hardware.
Thanks, I got it.
Any idea if contributing to translations will be made easier (or even possible) anytime soon? Any movement on DamnedLies integration problems (like translations being in limbo) or any of the other issues with the process?
That would be great. I am done with translations (approx. 0,5 h for Chatty). Now trying to merge that into repository and struggling with non-developer ready documentation (apporx. 3 h). That does not pay off. I am close to giving up helping.
@david.boddie You urgently have to ease this process or describe it in a better way. So more people can help. Because I think there are others also willing, but not capable of doing so.
@aircan, Did you try filing an issue report and attaching your file to the report?
I think that is the best solution for non-developers who are unfamiliar with git.
How can I run the image:
I use Aquemu 0.9.2 (ubuntu 20.04), using instructions shown here: https://wiki.ubuntuusers.de/AQEMU/
and got the following screen:
Is this your translation?
I noticed that there is an FAQ about translations that mentions just attaching the PO file to an issue. I guess the documentation needs to be updated to mention that - it’s news to me that translations can be added that way.
Yes. After I found out, that there are two german files (de.yaml and de_DE.yaml) I finalized the second one, too and attached it just before these lines here.
A bit more context would be very helpful, since a sole English word e.g. “copy” can be a german verb or noun and is then translated differently (‘kopieren’ vs. ‘Kopie’).
Context shall come from e.g. qemu that I am still not able to run smoothly. I still do not get behind the “enter password screen”.
That’s part of the problem - one listed in translations thread - as currently it is not clear how translations should be done (even with my or @amosbatto’s advises since we’re guessing from the outside and do not know what’s is supposed to be happening). There area issues, like, if commits are done in DL, they do not update and apprently need to be uploaded by hand - which also kinda borks any version control as the files are with each translator… etc. Moving to DL seems to have been a huge mistake if it can’t be fixed and automated.
I myself would be interested in assisting would the first reply by @amosbatto still be applicable to today? I’m pretty good at catching bugs and writing detailed reports.
On a side note I eventually would like to assist software side particularly in making existing applications more responsive and some GTK development. Any suggestions on how I can make my way towards doing that? Many thank yous in advance.
Yes, it is still very relevant today.
Read the documentation for libhandy to learn how to use the Handy classes to make GTK software adaptive. Also see the developer documentation. If you have questions, you can ask on the Matrix channel #libhandy:talk.puri.sm
If you want to make Qt/KDE software adaptive, then learn how to use Kirigami.
Then, check this list for apps that need work to become adaptive.
2 Likes