emerging of app-vim/css-color-20230308 goes smoothly, up to the point where file collisions are detected: * Detected file collision(s): * * /usr/share/vim/vimfiles/after/syntax/c.vim * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * app-vim/gtk-syntax-20130716:0::gentoo * /usr/share/vim/vimfiles/after/syntax/c.vim * * Package 'app-vim/css-color-20230308' NOT merged due to file * collisions. If necessary, refer to your elog messages for the whole * content of the above message.
I can't reproduce this locally. Please attach a full build.log and the output or emerge --info.
Created attachment 873751 [details] Build log As you can see, there is nothing more in the build log, that what I have already reported...
Created attachment 873752 [details] Emerge info To my eyes, there is absolutely nothing relevant to the reported problem here, but anyway, here it is... I post only a redacted version of "emerge --info" - just tell me if you need specific parts I omitted.
Created attachment 873753 [details] Output of "equery files app-vim/gtk-syntax-20130716" As you can see, /usr/share/vim/vimfiles/after/syntax/c.vim is indeed one of the files installed by app-vim/gtk-syntax-20130716. This package was installed in 2019 here and has never been upgraded since: eix gtk-syntax [I] app-vim/gtk-syntax Available versions: 20130716 Installed versions: 20130716(12:12:39 AM 01/05/2019) Homepage: https://www.vim.org/scripts/script.php?script_id=1000 Description: vim plugin: Syntax highlighting for GLib, Gtk+, Xlib, Gimp, Gnome, and more
Just an idea: Maybe it is a kind of "race condition" between ebuilds. Maybe, if you install css-color first and gtk-syntax afterwards, gtk-syntax will take care to not try to copy its version of /usr/share/vim/vimfiles/after/syntax/c.vim But if you install gtk-syntax first and then try to install css-color, as I did, then you get a collision - maybe... I don't know which version is "better", though. I can imagine that the version of css-color is more up-to-date, as it will contain instructions for CSS colors too...so maybe you should enforce the overwriting...?
It's not a race condition. The only way I can think of where this can happen is if app-vim/css-color/css-color-20230308.ebuild is not EAPI 8. In your build log, it says Repository: XXX. I assume you are not installing it from guru, you are installing it from a different overlay and reporting the bug to guru. Please update guru to the latest and compare the ebuild from guru with the ebuild you are using.
(In reply to Viorel Munteanu from comment #6) > It's not a race condition. The only way I can think of where this can > happen is if app-vim/css-color/css-color-20230308.ebuild is not EAPI 8. > > In your build log, it says Repository: XXX. I assume you are not installing > it from guru, you are installing it from a different overlay and reporting > the bug to guru. > > Please update guru to the latest and compare the ebuild from guru with the > ebuild you are using. Wow, you are spot-on! :-) XXX is the name of my private, local repository, where I copy the ebuilds before merging them. This is necessary, because most of the time I do have to make minor modifications (e.g. regarding the PYTHON_COMPAT array), or I just want to keep them around. In this case I had to - tataaa! - change EAPI from 8 to 7, as this is an old system that has gone ~20 months without full system upgrading: # Lowered EAPI from 8 to 7. EAPI=7 EAPI 8 does not work, it brings during "ebuild ... digest" the error: * ERROR: app-vim/css-color-20230308::XXX failed (depend phase): * EAPI 8 unsupported (too old) * * Call stack: * ebuild.sh, line 618: Called source '/usr/local/portage/overlays/XXX/app-vim/css-color/css-color-20230308.ebuild' * css-color-20230308.ebuild, line 9: Called inherit 'vim-plugin' * ebuild.sh, line 298: Called __qa_source '/usr/portage/eclass/vim-plugin.eclass' * ebuild.sh, line 114: Called source '/usr/portage/eclass/vim-plugin.eclass' * vim-plugin.eclass, line 17: Called die * The specific snippet of code: * *) die "EAPI ${EAPI:-0} unsupported (too old)";; (actually, it should say "too new", not "too old"...) , so I thought I'd lower it to work with my ~20 months old portage eclasses. This is a change I often have to make, as the system becomes older. Most of the time, it works fine. I would never imagine that an EAPI change might have such "side effects"... Any suggestions now? I might go and replace one or two eclasses from the eclass repository (the vim-plugin.eclass maybe?), if you suggest so and if you are confident that the eclasses are not coupled to other ones...Actually, as I see it, replacing vim-plugin.eclass with the current version should suffice, if this eclass is self-contained and decoupled from the rest of eclasses. What do you think?
You can try, of course, see what it does. But my advice would be to find some time and upgrade your machine to something more recent, the more you wait the harder it will get and at some point it may become unmaintainable and impossible to upgrade. It already sounds like a Frankengentoo. Thank you for replying, I will close the bug.
(In reply to Viorel Munteanu from comment #8) > ...the harder it will get and at some point it may become unmaintainable > and impossible to upgrade. In the almost 20 years I have been using Gentoo, it has never been really impossible to upgrade my system. It is the same system I started with back in ~2005, when I was struggling to compile X for an "ATI Rage 128 Mobility" graphics card...It was 32 (bit) back then, now it's 64 - and still we did not separate, only cross-compiled¹. "Will you love me, when I'm 64?" - did you sing that to *your* system? :-))) Or did you let it down for a younger, fresh stage-3 tarball? ;-p >It already sounds like a Frankengentoo. Frankengentoo... :-))))))) But no, you are doing it great injustice in calling it like that. It's a great system, very well organized, with no problems, ultra-stable, although I'm pushing it hard with dozens and dozens of open programs at any given time: ps acux | wc -l 1021 uptime -p up 1 year, 1 week, 6 days, 17 hours, 3 minutes But I digress... I'll replace vim-plugin.eclass and see if the issue goes away. --- ¹ See http://achurch.org/gentoo-x86-32-to-64.html for a starting point, in case you are curious.
Replacing vimp-plugin.eclass with a newer one: mv /usr/portage/eclass/vim-plugin.eclass /usr/portage/eclass-XXXXXXXX/ wget https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/vim-plugin.eclass mv vim-plugin.eclass /usr/portage/eclass/ results in a new error, this time for vim-doc: ebuild css-color-20230308.ebuild digest * ERROR: app-vim/css-color-20230308::XXX failed (depend phase): * vim-doc: EAPI 8 not supported * * Call stack: * ebuild.sh, line 618: Called source '/usr/local/portage/overlays/XXX/app-vim/css-color/css-color-20230308.ebuild' * css-color-20230308.ebuild, line 9: Called inherit 'vim-plugin' * ebuild.sh, line 298: Called __qa_source '/usr/portage/eclass/vim-plugin.eclass' * ebuild.sh, line 114: Called source '/usr/portage/eclass/vim-plugin.eclass' * vim-plugin.eclass, line 23: Called inherit 'vim-doc' * ebuild.sh, line 298: Called __qa_source '/usr/portage/eclass/vim-doc.eclass' * ebuild.sh, line 114: Called source '/usr/portage/eclass/vim-doc.eclass' * vim-doc.eclass, line 21: Called die * The specific snippet of code: * *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; Let's replace vim-doc too: mv /usr/portage/eclass/vim-doc.eclass /usr/portage/eclass-XXXXXXXX/ wget https://gitweb.gentoo.org/repo/gentoo.git/plain/eclass/vim-doc.eclass mv vim-doc.eclass /usr/portage/eclass/ This time ebuild css-color-20230308.ebuild digest succeeded! For the sake of completeness, I replaced vim-spell.eclass with the current copy from the online repository too, although not strictly needed by this ebuild. Installation succeeds too! :-) With the new eclasses, the ebuild does not try to install /usr/share/vim/vimfiles/after/syntax/c.vim - it installs /usr/share/vim/vimfiles/after/syntax/c/css-color.vim instead. I would never suspect such effects - I have always thought that the list of files to install is fixed and depends on the source code ONLY... css-color works wonderfully - only thing is that it colors unquoted hex colors only, i.e. it colors #ad2e0b, but not '#ad2e0b'. I have a dynamic CSS file, one that contains PHP code intermixed with pure CSS directives and I have to use quoted strings whose values are hex color codes. If you have any tips, I'd love to hear them. Thank you for making this ebuild. Now I don't have to remember how they look all those colors anymore. :-)
Great success! I did not make this ebuild, I only looked inside to see why it doesn't work in your case.
(In reply to segmentation fault from comment #10) > css-color works wonderfully - only thing is that it colors unquoted hex > colors only, i.e. it colors #ad2e0b, but not '#ad2e0b'. I have a dynamic CSS > file, one that contains PHP code intermixed with pure CSS directives and I > have to use quoted strings whose values are hex color codes. If you have any > tips, I'd love to hear them. In case someone has the same problem, I have written up a solution here: How to enable color highlighting for strings in CSS https://github.com/ap/vim-css-color/issues/190
