Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 501254 - app-office/auto-multiple-choice - a piece of software that can help you creating and managing multiple choice questionnaires (MCQ)
Summary: app-office/auto-multiple-choice - a piece of software that can help you creat...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: Normal enhancement with 2 votes (vote)
Assignee: Default Assignee for New Packages
URL: http://home.gna.org/auto-qcm/
Whiteboard:
Keywords:
Depends on: 129368
Blocks: 654502
  Show dependency tree
 
Reported: 2014-02-13 21:49 UTC by Nicolas
Modified: 2018-05-01 09:33 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
auto-multiple-choice.tar.bz2 (auto-multiple-choice.tar.bz2,2.65 KB, application/x-bzip-compressed-tar)
2014-02-13 21:49 UTC, Nicolas
Details
updated ebuild (auto-multiple-choice-1.2.1.ebuild,897 bytes, text/plain)
2014-02-14 19:55 UTC, Nicolas
Details
QA ebuild fixed (auto-multiple-choice-1.2.1.ebuild,861 bytes, text/plain)
2014-03-08 18:03 UTC, Nicolas
Details
desktop patch (correct-desktop.patch,633 bytes, patch)
2014-03-08 18:14 UTC, Nicolas
Details | Diff
makefile patch (correct-Makefile.patch,304 bytes, patch)
2014-03-08 18:15 UTC, Nicolas
Details | Diff
makefile patch (correct-Makefile.patch,249 bytes, patch)
2014-03-29 17:06 UTC, Nicolas
Details | Diff
updated ebuild (auto-multiple-choice-1.2.1.ebuild,1.06 KB, patch)
2014-03-29 17:12 UTC, Nicolas
Details | Diff
updated ebuild (auto-multiple-choice-1.2.1.ebuild,1.09 KB, patch)
2014-03-30 10:11 UTC, Nicolas
Details | Diff
Slightly revised ebuild (auto-multiple-choice-1.2.1.ebuild,1009 bytes, text/plain)
2014-04-12 15:51 UTC, Maxim Koltsov
Details
auto-multiple-choice-1.2.1-r1.ebuild (auto-multiple-choice-1.2.1-r1.ebuild,1.91 KB, text/plain)
2014-09-17 16:08 UTC, po.valles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas 2014-02-13 21:49:32 UTC
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 1 Jeroen Roovers gentoo-dev 2014-02-14 13:47:43 UTC
Comment on attachment 370358 [details]
auto-multiple-choice.tar.bz2

Is there a problem with simply attaching text files?
Comment 2 Jeroen Roovers gentoo-dev 2014-02-14 13:54:18 UTC
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.
Comment 3 Nicolas 2014-02-14 19:41:14 UTC
(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.
Comment 4 Nicolas 2014-02-14 19:55:52 UTC
Created attachment 370424 [details]
updated ebuild
Comment 5 Nicolas 2014-02-14 20:02:18 UTC
> 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?
Comment 6 Markos Chandras (RETIRED) gentoo-dev 2014-03-08 17:34:08 UTC
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?
Comment 7 Nicolas 2014-03-08 18:03:13 UTC
Created attachment 372092 [details]
QA ebuild fixed
Comment 8 Nicolas 2014-03-08 18:08:21 UTC
(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 ?
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2014-03-08 18:11:36 UTC
Yes I will add it for you. I will use the name and email from your bugzilla account.
Comment 10 Markos Chandras (RETIRED) gentoo-dev 2014-03-08 18:12:59 UTC
Could you also attach the 2 patches?
Comment 11 Nicolas 2014-03-08 18:14:47 UTC
Created attachment 372096 [details, diff]
desktop patch
Comment 12 Nicolas 2014-03-08 18:15:05 UTC
Created attachment 372098 [details, diff]
makefile patch
Comment 13 Manuel Rüger (RETIRED) gentoo-dev 2014-03-08 18:21:15 UTC
(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.
Comment 14 Markos Chandras (RETIRED) gentoo-dev 2014-03-08 18:28:09 UTC
(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
Comment 15 Nicolas 2014-03-29 17:06:55 UTC
Created attachment 373836 [details, diff]
makefile patch

I removed hardcoded path to PERLDIR
Comment 16 Nicolas 2014-03-29 17:12:57 UTC
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.
Comment 17 Maxim Koltsov gentoo-dev 2014-03-29 18:39:28 UTC
(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.
Comment 18 Nicolas 2014-03-29 19:17:43 UTC
(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)
Comment 19 Markos Chandras (RETIRED) gentoo-dev 2014-03-29 23:23:40 UTC
(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?
Comment 20 Nicolas 2014-03-30 10:11:14 UTC
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.
Comment 21 Markos Chandras (RETIRED) gentoo-dev 2014-03-30 11:29:04 UTC
CC'ing Perl to get a few more people to review that.
Comment 22 Markos Chandras (RETIRED) gentoo-dev 2014-04-12 11:58:52 UTC
(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?
Comment 23 Nicolas 2014-04-12 12:16:10 UTC
(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.
Comment 24 Markos Chandras (RETIRED) gentoo-dev 2014-04-12 12:20:01 UTC
(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.
Comment 25 Markos Chandras (RETIRED) gentoo-dev 2014-04-12 12:25:03 UTC
(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.
Comment 26 Nicolas 2014-04-12 12:59:06 UTC
(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.
Comment 27 Markos Chandras (RETIRED) gentoo-dev 2014-04-12 13:29:23 UTC
(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)?
Comment 28 Maxim Koltsov gentoo-dev 2014-04-12 15:51:50 UTC
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.
Comment 29 Andreas K. Hüttel gentoo-dev 2014-04-14 17:01:09 UTC
(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
Comment 30 po.valles 2014-09-17 16:08:58 UTC
Created attachment 384946 [details]
auto-multiple-choice-1.2.1-r1.ebuild
Comment 31 po.valles 2014-09-17 16:14:04 UTC
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.
Comment 32 Andreas K. Hüttel gentoo-dev 2016-05-21 21:30:30 UTC
Is anyone still interested in this?
Comment 33 Pierre AUSSAGUEL 2016-05-21 22:13:54 UTC
Yes, I use this software on a regular basis for my work (teacher).
Comment 34 Ian Delaney (RETIRED) gentoo-dev 2016-05-22 08:39:13 UTC
It is a package of the maintainer wanted list. Do you wish to become designated proxy maintainer, under the Proxy Maintainer Project?
Comment 35 Pierre AUSSAGUEL 2016-05-22 09:25:12 UTC
I am afraid that my programming skills are limited to typing «emerge foo»
Comment 36 po.valles 2016-05-23 08:18:56 UTC
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
Comment 37 Ian Delaney (RETIRED) gentoo-dev 2016-05-26 06:22:06 UTC
(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
Comment 38 Carl Michal 2016-11-06 16:30:09 UTC
> 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.
Comment 39 Andreas K. Hüttel gentoo-dev 2017-01-21 21:18:36 UTC
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