Re: F37 proposal: Emacs 28 (Self-Contained Change proposal)
Jens-Ulrik Petersen skrev: > Do you want to try adding native compilation your package? As it turns out, emacs-vm might not be the best package for this experiment. I could not get VM to work with native compilation. Instead, I had to turn the native compilation off completely for all vm*.el files before I could get emacs-vm usable again. My guess is that it is related to (some of) the warnings issued during compilation. It will be a significant work to get it up to date with the pretty dormant upstreams. It is thus not a good candidate as a guinea pig for bundling native-compiled eln files in add-on packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Emacs 28 (Self-Contained Change proposal)
Jens-Ulrik Petersen skrev: > Also did you see https://bugs.launchpad.net/vm/+bug/1979048 ? > It might help you. Thanks for the pointer. I haven't looked at that particular report yet. I have tried building Mark Diekhans' branch "vm-emacs-28" instead of trunk. (Mark is involved in the bug report I see.) That branch works on the first start but all the warnings that get shown instead of the message and one has to manually fix the presentation buffer. On the second start however, when there are eln files in the home directory, it fails to load complaining about the function "load" having been called with 0 arguments. If I disable native compilation, it keeps on working but the warning messages gets in the way every time. That is how far I have got. It's been a busy week, at work and otherwise, since I discovered this and I haven't had time to do much more debugging. > Do you want to try adding native compilation your package? I would like to in the long run, but my primary goal of course is to get it working at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F37 proposal: Emacs 28 (Self-Contained Change proposal)
Hello, My package (emacs-vm) was one of the ones that broke with the upgrade to Emacs 28 in F36. I'm trying to get it to work again. One of the issues is that it shows up a large number of warnings. After some time I've now understood this is because of the new native compilation feature. Since my package doesn't include any *.eln files and Emacs will do the compilation on first use, and put in the home directory. The VM package has a lot of old code that triggers warnings. Previously those have only shown up at build time, and I have hoped for upstreams to some day fix them. Now they will also show up at run time, which obviously is a more annoying user experience. That brought up a question: what should Emacs add-on packages do when it comes to native compilation? Should they build and bundle native code? If I understand it correctly, that would mean a new patch build of Emacs itself would also require a rebuild of all add-on packages. Or should we let Emacs recompile native files at run time? That would make the recompilation at Emacs upgrades automatic, but it would on the other hand put a copy of all used libraries in each user's home directory. I checked the packaging guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Emacs/) but it didn't mention anything around this as far as I could tell. (It still talks about xemacs which has been retired from the distribution, which tells me it hasn't been updated very recently.) To make things worse for me, with some updates VM initially works after issuing the warnings, but doesn't work on the second start of Emacs, when it doesn't have to recompile the code. But that's a different story. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
f32-backgrounds look like crap
Leigh Scott: > If there any plan to fix them? Pick another if you don't like the default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is there a way to mockbuild systemd?
Göran Uddeborg: > Should I file a bugzilla? Well, obviously not. https://bugzilla.redhat.com/show_bug.cgi?id=1803070 was already filed. I should have found it in my search earlier, but I didn't. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is there a way to mockbuild systemd?
Zbigniew Jędrzejewski-Szmek: > Some ways to avoid the issue: use a newer kernel, It is not completely clear from the bugzilla which version would be needed, but I built it on a machine using 5.5.6-201.fc31. According to comment 10 (https://bugzilla.redhat.com/show_bug.cgi?id=1803070#c10) it even fails with 5.6.3-300.fc32. How new is needed? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Is there a way to mockbuild systemd?
Pavel Raiskup: > Who gave you this suggestion, As the suggestion was sent off list, I didn't want to say that. I don't know the reason he didn't send it to the public list but just to me. > haven't you tried to fill an issue against > systemd No, I have not. I assumed it was something I did wrong, not a bug in systemd. Should I file a bugzilla? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Is there a way to mockbuild systemd?
Just in case someone with the same problem stumbles on my mail when
googling, I'll explain what I did in the end.
I got the suggestion to disable nspawn when building. That solved the
initial problem, but introduced two other. I was able to work around
those too by bind mounting /run and /tmp into the container. Giving
fedpkg the below mock configuration; I was able to build systemd.
config_opts['use_nspawn'] = False
config_opts['plugin_conf']['bind_mount_enable'] = True
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/run', '/run' ))
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/tmp', '/tmp' ))
include('fedora-32-x86_64.cfg')
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Is there a way to mockbuild systemd?
I asked this in ask.fedoraproject (https://ask.fedoraproject.org/t/is-there-a-way-to-mockbuild-systemd), but FranciscoD suggested this might be a better place. I'm trying to build a slightly modified version of systemd. To start with, I tried to do a fedpkg mockbuild of systemd without any modification. The build fails on the test-mountpoint-util test. Is there a way around this? Is there a way to build systemd using mock? The commands I run are these: fedpkg clone systemd cd systemd fedpkg switch-branch f32 fedpkg mockbuild The actual compilation succeeds, but the testing fails as mentioned. If I keep the build root I found these lines in the error log. ids of /proc/filesystems are 1256, 1281 the other path for mnt id 1281 is /proc Assertion ‘path_equal(p, t)’ failed at src/test/test-mountpoint-util.c:94, function test_mnt_id(). Aborting. According to this page https://www.gitmemory.com/issue/systemd/systemd/11505/584844862 this is because the build is done in a pid and mount namespace. The site is about Gentoo builds. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
I was going to argue this would make us lose a lot of hardware and most likely a lot of our the hardware owners as users too. But I see that most of what I planned to say is already said, so I'll just add my: please, don't do this. (My sample from home and work: out of 6 Fedora hosts expected to still live during F32, 2 have AVX2, 3 have AVX only, and one has naither.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
Is there any way for me as a regular packager to test my fixes? The "how to test" section on the wiki (https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot#How_To_Test) still says "mock with configuration provided (TODO)". I tried a standard mock build, with mock version 1.4.8-1, and it succeeded WITHOUT any fix. pgpCZVh8pF95Q.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
Igor Gnatenko: > If you fixed package(s), I haven't yet, but I certainly will fix my packages (emacs-vm mindless ttf2pt1 xpenguins). pgpAihQdfU13Q.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do with application that only works in some desktops
Matthias Clasen: > How did you determine that NotShowIn=GNOME; doesn't have any effect? > It should work fine to hide xpenguins from the places where > applications are normally listed in GNOME (the shell overview and > search). It should? Then I'll try it again; I probably made some kind of mistake when testing. Thanks for your reply. It sounds like creating the blacklist is the best available option after all. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
What to do with application that only works in some desktops
Hello! I would like to ask for some help what to do with https://bugzilla.redhat.com/show_bug.cgi?id=1324881 I've been pondering it for some time, but I know too little to know what to do. It's about the old amusement xpenguins. (A program showing small penguins walking on the windows and jumping between them.) As can be seen in the bug report, it doesn't show anything in e.g. Gnome. From what I understand this is because Gnome doesn't show the actual X root window. It has a second window covering the entire screen as background, and this window hides all the penguins. A first question is if this is indeed correct? If so, could anyone describe it in more technically correct terms. I would like to write a warning about the issue in the description of the package. To handle the issue, I've considered to blacklist environments that do something like the above in the desktop file with a line "NotShowIn=GNOME;..." for Gnome and other environments doing something like this. (I fear that it would mean most modern environments.) Even better would be if there were some way to dynamically check if the "real root window" was available. But I'm not aware of any way to test that, nor any way to let the desktop file use that information if I had it. But a problem is that "NotShowIn=GNOME;" doesn't seem to have any effect in the current Gnome version. There is no menu to exclude xpenguins from, and when I try it seems just as available regardless of that setting. As you may have guessed I'm not a regular Gnome user, but that is what I see when I test it. So a second question is if anyone has any advice on how to best handle this? How to best make sure Gnome users don't get fooled to use a program that do not work in their environment. Any advice on the subject would be appreciated! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaned: emacs-vm emacs-bbdb
> I've just orphaned the emacs-vm and emacs-bbdb packages. Hopefully the > other maintainer (goeran) of these packages will take ownership. Yes, I just did it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
