trying to build this package I've faced w/ error at configure stage: ... checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes ./configure: line 2816: syntax error near unexpected token `ac_config_headers="$ac_config_headers config.h"' ./configure: line 2816: `fi ac_config_headers="$ac_config_headers config.h"' which is a result of incorrect configure.ac file. modified libev-pc.patch will fix that error. Reproducible: Always Steps to Reproduce: 1. try to emerge =libev-4.15 2. 3. also I've modified this ebuild to use autotools-multilib instead the old fashioned way...
Created attachment 365802 [details, diff] libev-4.15-r1
Created attachment 365804 [details, diff] required patch moved from ebuild code (sedding) to a patch file
Created attachment 365806 [details, diff] modified libev-pc.patch
/me shown the exact same build error during configure @Alex the libev-4.15-r1 patch doesn't patch hunk2. Or did you mean just to use the last "modified" patch?
Created attachment 365820 [details, diff] turn libev-4.15.ebuild into libev-4.15-r1.ebuild fixed patch
(In reply to Ulenrich from comment #4) > /me shown the exact same build error during configure > > @Alex > the libev-4.15-r1 patch doesn't patch hunk2. fixed. now works fine: zaufi@gentop〉/tmp〉mkdir libev-test-patch zaufi@gentop〉/tmp〉cd libev-test-patch zaufi@gentop〉/tmp/libev-test-patch〉empty dir〉wget -q -O libev-4.15.ebuild.patch https://494924.bugs.gentoo.org/attachment.cgi?id=365820 zaufi@gentop〉/tmp/libev-test-patch〉cp /usr/portage/dev-libs/libev/libev-4.15.ebuild . zaufi@gentop〉/tmp/libev-test-patch〉patch <libev-4.15.ebuild.patch patching file libev-4.15.ebuild zaufi@gentop〉/tmp/libev-test-patch〉
I confirm this libev-4.15-r1.ebuild with both additional patches does compile. 1. But where does epatch_user go? Is it now inherited? 2. @Alex if you reformat your libev-pc.patch in essence I only see these two diffs from Gentoo libev-pc.patch: -AC_INIT +AC_INIT([libev],[4.15]) -AM_INIT_AUTOMAKE(libev,4.15) dnl also update ev.h! +AM_INIT_AUTOMAKE
(In reply to Ulenrich from comment #7) > I confirm this libev-4.15-r1.ebuild > with both additional patches does compile. > > 1. But where does epatch_user go? Is it now inherited? yep. autotools-multilib_src_prepare calls autotools-utils_src_prepare and latter calls epatch_user. > 2. @Alex if you reformat your libev-pc.patch in essence I only see these two > diffs from Gentoo libev-pc.patch: > -AC_INIT > +AC_INIT([libev],[4.15]) > > -AM_INIT_AUTOMAKE(libev,4.15) dnl also update ev.h! > +AM_INIT_AUTOMAKE yep. but, instead of provide a patch for the patch ;-) I've just added a new one to override the old.
Are you sure you have an update version? 20 Dec 2013; Markos Chandras <hwoarang@gentoo.org> +files/libev-4.15-automake-1.14.patch, libev-4.15.ebuild: Add patch to fix building with automake-1.14. Patch by Dennis 'dlan' Lan <dennis.yxun@gmail.com>. Bug #493050
(In reply to Markos Chandras from comment #9) > Are you sure you have an update version? > > 20 Dec 2013; Markos Chandras <hwoarang@gentoo.org> > +files/libev-4.15-automake-1.14.patch, libev-4.15.ebuild: > Add patch to fix building with automake-1.14. Patch by Dennis 'dlan' Lan > <dennis.yxun@gmail.com>. Bug #493050 FYI, that patch did it wrong! It is about decade since AM_INIT_AUTOMAKE has changed (http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html) and mentioned syntax was deprecated. And finally: why, for sake of GOD, WHY, the ebuild was updated w/o version/revision bump???
(In reply to Alex Turbov from comment #10) > (In reply to Markos Chandras from comment #9) > > Are you sure you have an update version? > > > > 20 Dec 2013; Markos Chandras <hwoarang@gentoo.org> > > +files/libev-4.15-automake-1.14.patch, libev-4.15.ebuild: > > Add patch to fix building with automake-1.14. Patch by Dennis 'dlan' Lan > > <dennis.yxun@gmail.com>. Bug #493050 > > FYI, that patch did it wrong! It is about decade since AM_INIT_AUTOMAKE has > changed > (http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html) > and mentioned syntax was deprecated. > > And finally: why, for sake of GOD, WHY, the ebuild was updated w/o > version/revision bump??? The patch works as it is whether you like it or not. Hopefully upstream will commit a better patch. You failed to read the maintenance rules. For build failures, there is no need to revision bump since nobody would have been able to merge the package and it will cause unnecessary rebuild for those who managed to compile. So first read, then scream.
hi @alex, @hwoarang, thanks for trying to solve this problem, and sorry for my delayed response (I have problem with bugzie settings, thus haven't got emails with bugs assigned to me, but should been solved now). 1) it's not necessary to convert the sed method to one sole patch (which I previously convert from patch to sed operation). I tend to not use patch if one line of sed can do the job. 2) I tend to following "one patch do one thing", so it would be great to creat another independent patch for changes to "AC_INIT", "AM_INIT_AUTOMAKE". remember that libev-pc-patch also used by libev-4.11{,-r1}.ebuild, change that patch also need to test those ebuilds, or you may need to introduce another patch which upgrade the revision number (such as libev-pc-r1.patch) for only apply to 4.15 3) multilib improvement sounds good to me, and we can combine this changes into next version bump, thanks 4) unfortunately, we may not get much blessing from upstream, changes such as this may not accept by upstream.. libev-pc.patch was already rejected[1], and this AM_INIT_AUTOMAKE also have little chance[2]. [1] for libev-pc http://lists.schmorp.de/pipermail/libev/2013q1/002130.html http://lists.schmorp.de/pipermail/libev/2013q1/002128.html http://lists.schmorp.de/pipermail/libev/2013q1/002136.html [2] for automake patch http://lists.schmorp.de/pipermail/libev/2013q4/002311.html http://lists.schmorp.de/pipermail/libev/2013q4/002312.html http://lists.schmorp.de/pipermail/libev/2013q4/002313.html
*** This bug has been marked as a duplicate of bug 493050 ***
(In reply to Markos Chandras from comment #11) > > > > FYI, that patch did it wrong! It is about decade since AM_INIT_AUTOMAKE has > > changed > > (http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html) > > and mentioned syntax was deprecated. > > > > And finally: why, for sake of GOD, WHY, the ebuild was updated w/o > > version/revision bump??? > > The patch works as it is whether you like it or not. Hopefully upstream will > commit a better patch. why to do smth *bad* if w/ same (or less) effort it can be done *good*? > For build failures, there is no > need to revision bump since nobody would have been able to merge the package ORLY?! I've found this problem when run paludis to reinstall targets w/ changed metadata! I.e. I had libev-4.15 already installed, then somebody change (and broke) it, and then I (paludis) tried to reinstall it (cuz ebuild has changed w/o version bump!) > and it will cause unnecessary rebuild for those who managed to compile. So > first read, then scream. I scream because running paludis to reinstall all packages w/ changed metadata/ebuilds I've found 389 packages installed in my system w/ changed ebuilds w/o version bump... or are you trying to say that all 389 packages was broken??? Then how they were installed in my system??
(In reply to Dennis 'dlan' Lan from comment #12) > 1) it's not necessary to convert the sed method to one sole patch (which I > previously convert from patch to sed operation). I tend to not use patch if > one line of sed can do the job. I tend to have as minimal (clean, easy to read) ebuild as it possible (if possible w/o sed (and other) "magic"). Reuse inherited eclass code as much as it can... I'm talking about setting PATCH (once) properly instead of doing `epatch` and sed magic spread across ebuild... Same for other things (setting DOCS instead of dodoc & etc)... my prmary goal (as a programmer) just keep it simple (and maintaniable)!
(In reply to Alex Turbov from comment #14) > ORLY?! I've found this problem when run paludis to reinstall targets w/ > changed metadata! > I.e. I had libev-4.15 already installed, then somebody change (and broke) > it, and then I (paludis) tried to reinstall it > (cuz ebuild has changed w/o version bump!) YARLY!(sorry, can not resist) We usually do NOT make any changes in stable ebuilds, unless cosmetic/typo fixes or build-time issue fixes(as said in Gentoo Developmeng Guide) . And when we do them, we check if something broken - that's how it worked for years(and still works now). If you have better solution, then propose it in correct manner, without screaming. The best solution I see here - talk about this problem with upstream. And yes - we have agreement to NOT introduce pkgconfig files without asking from upstream, cause in other case, we would have such situation: 1) Some software developer, who uses Gentoo, will write tool FOO and add dependency to libev via pkgconfig(through autotools for example); 2) Then, he will test building of his FOO tool in other distro(for obvious reasons - it will fail); 3) Then he will wrote tons of workarounds for such stupid situation.
(In reply to Sergey Popov from comment #16) > > We usually do NOT make any changes in stable ebuilds, unless cosmetic/typo > fixes or build-time issue fixes(as said in Gentoo Developmeng Guide) . And Ok, I've got the last question: would you call removing a USE flag a "cosmetic fix"? or maybe "fixing typo"? (like it happened today, and again w/o version bump, for acl-2.2.52.ebuild) (hope it is obvious to you and you'll answer "yes" or "no") > when we do them, we check if something broken - that's how it worked for > years(and still works now). > huh, then there are some things to improve in that process... > If you have better solution, then propose it in correct manner, without > screaming. I feel smth wrong w/ current situation... having gentoo is like walking on a thin ice. "cosmetic fixes" sometimes leads to undesirable side effects which are hard to track, reproduce and sometimes even realize whats happened... what wouldn't happened if a package gets revision bump. > The best solution I see here - talk about this problem with > upstream. I don't care about that particular problem... from 389 "cosmetically" fixed packages I've got 10 build failures (and waste a lot of hours just to investigate whats happened and make a fix for a cosmetic fix)... does it sounds Ok to you?
(In reply to Alex Turbov from comment #17) > from 389 "cosmetically" fixed packages I've got 10 build failures (and waste > a lot of hours just to investigate whats happened and make a fix for a > cosmetic fix)... does it sounds Ok to you? It sounds that something bad happened with your system. I have ~20 servers and couple of desktops(mostly stable with few keyworded packages), dozens of chroots and virtual instances(some are stable, others are complete ~arch) and all seems to be fine, especially with base-system packages(like acl). Now let's stop offtopic here. If you want to propose enhancements to development process - feel free to post about it in gentoo-dev maillist.
