With that change, the font-size doesn’t seem to affect anything― text is miniscule no matter what.
That’s pretty odd, but I probably won’t be able to debug this until I can reproduce the problem myself. Do you remember changing any related settings on your system between when Emacs last worked correctly and now?
1 Like
I don’t think so, aside from updating (nightly) and probably installing libraries/packages I didn’t have before. I’m planning on doing a fresh install soon, I’ll see if I can reproduce then (and try and keep note of how).
Thanks in advance.
I think I have fixed the bug where fonts end up too small for some people. The fix should end up on the master branch of Emacs soon.
10 Likes
Hi @hgsfghs I confirm that, since a few time ago, I didn’t have the tiny fonts issue anymore (sorry, but don’t remember the version since it was fixed).
Thank you so much for your help! 
Heads up to the packager: the `master’ branch of the Emacs repository is now Emacs 30, while the `emacs-29’ branch contains what will become the next stable release within 6 to 8 months. The recipe should be adjusted to build from the emacs-29 branch, so that Emacs 29.1 can be packaged in the future. Thanks.
2 Likes
I can make the change but it might be a while before I get around to updating the recipe. For the past few weeks, when trying to update to a newer revision I get errors while building because git information is not available inside of the haikuporter chroot. I haven’t had time to look and see how to work around this.
That shouldn’t be an error, really. What does the build say?
I misremembered what the problem was. It’s not a git problem but something with the processing of the emacs.png file. I started looking into it the other day but haven’t had time to fully investigate the problem. I’ve uploaded the build log from haikuporter if you’re interested
Right, thanks. I’ve pacified the error on the Emacs 29 branch: it’s actually inconsequential, since attributes and icons are set on the Emacs binary by the build scripts as well.
The Emacs package has been updated but there is still something funny with the build system. I need to run make twice because it fails the first time in that same area as before. You can see the log from the 64 bit builder but strangely the 32 bit builder didn’t have a problem processing the emacs.png and therefore didn’t need the second make.
That’s really odd. Can you send src/Makefile from the build?
I can’t see any obvious problems here, but what if you make the builder build Emacs with only 1 job?
Doesn’t seem to make a difference with only one job.
Is there a way for me to run the HaikuPorts build process manually, so I can debug this for myself?
You just need to clone the two repositories(haikuports and haikuporter) and then move the haikuports-sample.conf file to ~/config/settings/haikuports.conf and edit as needed. On a 32 bit build you’ll need to set up the conf file for secondary arch and use emacs_x86 as the package name for haikuporter to build, otherwise the package is just named emacs on 64 bit and others.
Edit: You can start a build with a command like ~/haikuporter/haikuporter -S -j8 --get-dependencies --no-source-packages emacs. There will be a work directory in ~/haikuports/app-editors/emacs/work-29.0.60~git/sources/… where you can examine the files. If needed, you can enter the chroot to run commands with haikuporter -E emacs
Thanks, I’ll give that a try tomorrow.
I’m sorry I couldn’t take a look at this earlier. I will be fairly busy for the next 2 weeks to a month and do not have easy access to Haiku at this moment.
If someone else wants to investigate the Makefile (I suspect src/emacs is being created after make tries to call be-resources to generate `Emacs’), that would be great. Thanks in advance.