Created attachment 370358 [details] auto-multiple-choice.tar.bz2 Hi ! This is a new ebuild to a software I use as a teacher. It allows to easily create multiple choice (MCQ) and has many functions among mixing questions between students and automatic correction after you have scanned copies. As I wanted to use it on my Gentoo and it is not available in Portage yet I created a specific ebuild. Since this is my first I hope it will be useful to others and that I can benefit from your advice to improve. Is it here that requests for inclusion of new ebuild have to be submitted? Thanks
Comment on attachment 370358 [details] auto-multiple-choice.tar.bz2 Is there a problem with simply attaching text files?
Comment on attachment 370358 [details] auto-multiple-choice.tar.bz2 LICENSE is invalid (you meant GPL-2+ I guess). src_unpack() should be src_prepare() and then you can skip unpack ${A} and cd "${S}". src_compile() defines the default - should be removed. src_install() should not patch files - that's what src_prepare() is for. Other than that, src_install() defines the default and should be removed. ChangeLog and Manifest are written by the maintainer of the package - there is no need to include them. PERLDIR shouldn't be hard-coded in the Makefile patch.
(In reply to Jeroen Roovers from comment #1) > Comment on attachment 370358 [details] > auto-multiple-choice.tar.bz2 > > Is there a problem with simply attaching text files? No problem. I thought it was necessary to submit the ebuild file and all other files and directories. I will proceed differently the next time.
Created attachment 370424 [details] updated ebuild
> LICENSE is invalid (you meant GPL-2+ I guess). Yes, indeed. > src_unpack() should be src_prepare() and then you can skip unpack ${A} and > cd "${S}". > > src_compile() defines the default - should be removed. > > src_install() should not patch files - that's what src_prepare() is for. > Other than that, src_install() defines the default and should be removed. I updated the ebuild file to take account of your comments. > ChangeLog and Manifest are written by the maintainer of the package - there > is no need to include them. As this is a fairly simple software that I use very often and for which I regularly exchange with the developer, I thought I could be the maintainer. Do you think this is possible? I have not seen a procedure for how to do but I am very interested to learn. > PERLDIR shouldn't be hard-coded in the Makefile patch. I made this change because otherwise it was possible to compile the software but not execute it. The following error was displayed: "Can't locate AMC/Basic.pm in @INC (@INC contains: /etc/perl /usr/local/lib64/perl5/5.16.3/x86_64-linux /usr/local/lib64/perl5/5.16.3 /usr/lib64/perl5/vendor_perl/5.16.3/x86_64-linux /usr/lib64/perl5/vendor_perl/5.16.3 /usr/local/lib64/perl5 /usr/lib64/perl5/vendor_perl /usr/lib64/perl5/5.16.3/x86_64-linux /usr/lib64/perl5/5.16.3 .) at /usr/lib/AMC/perl/AMC-gui.pl line 45. BEGIN failed--compilation aborted at /usr/lib/AMC/perl/AMC-gui.pl line 45." I talked with the developer and he told me that this was the solution to implement. Do you know a better alternative?
Hi, I have a couple of comments 1) Description: Isn't it a bit too long? Can you make it shorter? Did you run repoman full on the ebuild to make sure it passes? 2) Why inheriting autotools if you are not using it?
Created attachment 372092 [details] QA ebuild fixed
(In reply to Markos Chandras from comment #6) > Hi, > > I have a couple of comments > > 1) Description: Isn't it a bit too long? Can you make it shorter? Did you > run repoman full on the ebuild to make sure it passes? I didn't know repoman but it is usefull. In fact the description was 109 characters and the max is 100. I updated the field. > 2) Why inheriting autotools if you are not using it? I thinked it was a must have. repoman flag the unused too so I delette it. Now there is no problem anymore with repoman, expect the missing metadata.xml. I had read it will be added by the developer. It's right ?
Yes I will add it for you. I will use the name and email from your bugzilla account.
Could you also attach the 2 patches?
Created attachment 372096 [details, diff] desktop patch
Created attachment 372098 [details, diff] makefile patch
(In reply to Nicolas from comment #12) > Created attachment 372098 [details, diff] [details, diff] > makefile patch Please don't hardcode versions. This will break on perl upgrade.
(In reply to Manuel Rüger from comment #13) > (In reply to Nicolas from comment #12) > > Created attachment 372098 [details, diff] [details, diff] [details, diff] > > makefile patch > > Please don't hardcode versions. This will break on perl upgrade. I suspect it's possible to set this variable within the ebuild to make it more future proof for perl updates? IIRC the perl eclass has functions to get the versions and stuff for the installed perl
Created attachment 373836 [details, diff] makefile patch I removed hardcoded path to PERLDIR
Created attachment 373838 [details, diff] updated ebuild I made 2 updates : 1) Updated the ebuild to know the perl version on the system and then add the PERLDIR depends on it. 2) Add a simple src_install() to avoid some sandbox errors.
(In reply to Nicolas from comment #16) > Created attachment 373838 [details, diff] [details, diff] > updated ebuild > > I made 2 updates : > 1) Updated the ebuild to know the perl version on the system and then add > the PERLDIR depends on it. > 2) Add a simple src_install() to avoid some sandbox errors. This is inapropriate. Please call 'perl_set_version' and then use ${installvendorlib} variable as value for PERLDIR. And don't do sed on Makefile, use 'emake PERLDIR=${...}' Also, src_install looks unneeded and wrong, but perl team can correct me on this.
(In reply to Maxim Koltsov from comment #17) > This is inapropriate. Please call 'perl_set_version' and then use > ${installvendorlib} variable as value for PERLDIR. And don't do sed on > Makefile, use 'emake PERLDIR=${...}' In fact, when I write this lines, the PERLDIR variable is empty : src_compile() { perl_set_version emake PERLDIR=${installvendorlib} } That's why I didn't use it. (I inherit eutils and perl-module)
(In reply to Nicolas from comment #18) > (In reply to Maxim Koltsov from comment #17) > > This is inapropriate. Please call 'perl_set_version' and then use > > ${installvendorlib} variable as value for PERLDIR. And don't do sed on > > Makefile, use 'emake PERLDIR=${...}' > > In fact, when I write this lines, the PERLDIR variable is empty : > src_compile() { > perl_set_version > emake PERLDIR=${installvendorlib} > } > > That's why I didn't use it. (I inherit eutils and perl-module) I also think the /usr/*lib64*/ in the path is wrong. It may break 32-bit architectures. Doesn't what Maxim suggests work for you?
Created attachment 373880 [details, diff] updated ebuild After calling perl_set_version, the ${installvendorlib} was empty, so I found a way to get the right path with perl -V.
CC'ing Perl to get a few more people to review that.
(In reply to Nicolas from comment #20) > Created attachment 373880 [details, diff] [details, diff] > updated ebuild > > After calling perl_set_version, the ${installvendorlib} was empty, so I > found a way to get the right path with perl -V. I don't understand this line eval "$(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )" Would you explain why it's needed?
(In reply to Markos Chandras from comment #22) > (In reply to Nicolas from comment #20) > > Created attachment 373880 [details, diff] [details, diff] [details, diff] > > updated ebuild > > > > After calling perl_set_version, the ${installvendorlib} was empty, so I > > found a way to get the right path with perl -V. > > I don't understand this line > > eval "$(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )" > > Would you explain why it's needed? That's the only way I found to obtain the path because when I use perl_set_version and ${installvendorlib} I have nothing. If I do perl -V:installvendorlib, I have the path like that : installvendorlib='/usr/lib64/perl5/vendor_perl/5.16.3'; To have only /usr/lib64/perl5/vendor_perl/5.16.3, I use the line you quote. I get the tip from #gentoo-perl but there is maybe a better way I don't know.
(In reply to Nicolas from comment #23) > (In reply to Markos Chandras from comment #22) > > (In reply to Nicolas from comment #20) > > > Created attachment 373880 [details, diff] [details, diff] [details, diff] [details, diff] > > > updated ebuild > > > > > > After calling perl_set_version, the ${installvendorlib} was empty, so I > > > found a way to get the right path with perl -V. > > > > I don't understand this line > > > > eval "$(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )" > > > > Would you explain why it's needed? > > That's the only way I found to obtain the path because when I use > perl_set_version and ${installvendorlib} I have nothing. > > If I do perl -V:installvendorlib, I have the path like that : > installvendorlib='/usr/lib64/perl5/vendor_perl/5.16.3'; > > To have only /usr/lib64/perl5/vendor_perl/5.16.3, I use the line you quote. > I get the tip from #gentoo-perl but there is maybe a better way I don't know. I don't know much about perl so if someone in #gentoo-perl said this is an acceptable way I am fine with it. I will commit this later today.
(In reply to Markos Chandras from comment #24) > (In reply to Nicolas from comment #23) > > (In reply to Markos Chandras from comment #22) > > > (In reply to Nicolas from comment #20) > > > > Created attachment 373880 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > updated ebuild > > > > > > > > After calling perl_set_version, the ${installvendorlib} was empty, so I > > > > found a way to get the right path with perl -V. > > > > > > I don't understand this line > > > > > > eval "$(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )" > > > > > > Would you explain why it's needed? > > > > That's the only way I found to obtain the path because when I use > > perl_set_version and ${installvendorlib} I have nothing. > > > > If I do perl -V:installvendorlib, I have the path like that : > > installvendorlib='/usr/lib64/perl5/vendor_perl/5.16.3'; > > > > To have only /usr/lib64/perl5/vendor_perl/5.16.3, I use the line you quote. > > I get the tip from #gentoo-perl but there is maybe a better way I don't know. > > I don't know much about perl so if someone in #gentoo-perl said this is an > acceptable way I am fine with it. I will commit this later today. The app-text/dblatex dependency is not in the portage tree. We need another bug with an ebuild for that package attached there.
(In reply to Markos Chandras from comment #25) > > The app-text/dblatex dependency is not in the portage tree. We need another > bug with an ebuild for that package attached there. You right, I forget I add it first :-/ There is the ebuild of dblatex here https://bugs.gentoo.org/show_bug.cgi?id=129368 but nobody approve it.
(In reply to Nicolas from comment #26) > (In reply to Markos Chandras from comment #25) > > > > The app-text/dblatex dependency is not in the portage tree. We need another > > bug with an ebuild for that package attached there. > > You right, I forget I add it first :-/ > > There is the ebuild of dblatex here > https://bugs.gentoo.org/show_bug.cgi?id=129368 but nobody approve it. Would you like to take care of that as well (though upstream seem a bit dead)?
Created attachment 374820 [details] Slightly revised ebuild I've tried to fix what I could, but still there are many faults. First of all, dblatex installs its .sty's into /usr/share/dblatex/latex/, where texlive can't find them. If I copy them to /usr/share/texmf-site/..., auto-multiple-choice.{en,fr}.tex can't be built: ! LaTeX Error: File `warning' not found. It seems that html/images/*png files are needed to build the docs, and 'warning' must be changed to 'warning.png' in tex files, which are generated from docbook xml files... Seeing that, I gave up with this package. Good luck in trying to hack it to work. P.S. Note that dependecies are far from complete and right.
(In reply to Nicolas from comment #23) > (In reply to Markos Chandras from comment #22) > > > > I don't understand this line > > > > eval "$(perl -V:{version,install{{site,vendor}{arch,lib},archlib}} )" > > > > Would you explain why it's needed? > > That's the only way I found to obtain the path because when I use > perl_set_version and ${installvendorlib} I have nothing. > that was my advice, the line is copied from perl-module.eclass where it extracts the perl installation directories into shell variables
Created attachment 384946 [details] auto-multiple-choice-1.2.1-r1.ebuild
Hello, I had not see this ebuild request before today, and I worked on an ebuild on my side. I combined what I saw here with what I had ; now and I have an ebuild that is working great (with auto-multiple-choice-1.2.1). I'd like to clarify some points in the ebuild currently attached to this bug (called "Slightly revised ebuild") : 1) Aren't DEPEND and RDEPEND swapped ? dev-perl/gtk2-perl is clearly a run-time dependency. Also "media-libs/netpbm" and "media-libs/opencv" are compilation dependencies, IMHO. 2) Using the "perl-module" eclass leads to sandbox violations ; it took me some time to figure it out. Looks like this eclass is for perl modules only (could not confirm via the documentation nor the source code - sorry), so it restricts the writable directories in the sandbox. Not sure about that, but it's my best guess. 3) There are some missing runtime dependencies : dev-perl/Gtk2-Notify, dev-perl/Net-CUPS, dev-perl/Email-Address, dev-perl/Email-MIME, dev-perl/Email-Sender, and aybe more. I spot them using the "--debug" mode while using the GUI. 4) On my computer at least, auto-multiple-choice is not working correctly with "media-gfx/graphicsmagick", whereas it works fine with "media-gfx/imagemagick" (although both are said to be supported). Could be linked to some particular use flags missing on my graphicsmagick installation. 5) The PERLDIR variable is ignore on the emake call (but other variables are used correctly). To fix this, I had to change the 'Makefile.conf' before calling emake (in src_prepare). 6) The provided patch that fixes the .desktop file is not used in the provided ebuild ? -- So... I "fixed" those 6 points and : - I added a conditional dependency ("mail-mta/msmtp") on "msmtp" use flag, so that each user can use an external SMTP to send the correction to the students. - ebuild runs 'texhash' postinst and postrm, so that the provided "/usr/share/texmf/tex/latex/AMC/automultiplechoice.sty" can be used directly. -- There is still the dependency on "app-tex/dblatex" that is still not in the main tree... Bug #129368 mentions "wagnerflo" overlay... but it's no longer available. I found "app-tex/dblatex" in "eva" and "benf" overlays. Both versions do not install TeX ".sty" files in the right directories ; which requires my ebuild to export TEXINPUTS variable before emake to build the documentation correctly. Please let me know what needs to be corrected.
Is anyone still interested in this?
Yes, I use this software on a regular basis for my work (teacher).
It is a package of the maintainer wanted list. Do you wish to become designated proxy maintainer, under the Proxy Maintainer Project?
I am afraid that my programming skills are limited to typing «emerge foo»
I'm using this software (almost daily) and maintaining a couple of ebuilds for it (1.2.1 and live) it in a local overlay. Maybe I can proxy maintain, if you point me to the right documentation explaining what is involved. Thanks
(In reply to po.valles from comment #36) > I'm using this software (almost daily) and maintaining a couple of ebuilds > for it (1.2.1 and live) it in a local overlay. > > Maybe I can proxy maintain, if you point me to the right documentation > explaining what is involved. > > Thanks Thank you (?)po. https://devmanual.gentoo.org/ https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers This must get you started, if not half trained to dev level
> Is anyone still interested in this? I use this quite frequently to, and have it installed via overlay. I'd be happy to see it in portage as well.
Please test!!! commit b182584505203872e04a092e7a6907596afb9161 Author: Andreas K. Hüttel <dilfridge@gentoo.org> Date: Sat Jan 21 01:07:58 2017 +0100 app-office/auto-multiple-choice: New package, bug 501254 Thanks to Nicolas Pujol, Maxim Koltsov, and Pierre-Olivier Vallès for their work app-office/auto-multiple-choice/Manifest | 1 + app-office/auto-multiple-choice/auto-multiple-choice-1.3.0.ebuild | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ app-office/auto-multiple-choice/files/auto-multiple-choice-1.3.0-conf.patch | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ app-office/auto-multiple-choice/files/auto-multiple-choice-1.3.0-desktop.patch | 10 ++++++++++ app-office/auto-multiple-choice/metadata.xml | 16 ++++++++++++++++ 5 files changed, 150 insertions(+) (In reply to po.valles from comment #36) > I'm using this software (almost daily) and maintaining a couple of ebuilds > for it (1.2.1 and live) it in a local overlay. > > Maybe I can proxy maintain, if you point me to the right documentation > explaining what is involved. > > Thanks Pierre-Olivier, Thanks a lot for your offer. I've added you to the maintainers in the metadata.xml, so you get CC'ed in bugs. I had to change quite a lot, I'll send you an e-mail over the next days explaining what I did. Cheers, Andreas
