Re: [Mageia-dev] Need mentor(s) to become a Mageia packager
On 21 July 2011 22:14, Vincent vincent.hervi...@gmail.com wrote: Hi All, I am still trying to pack ZoneMinder for Cauldron. Now rpms are generated and rpmlint is not complaining, but I am still sure, it's not OK :) , that's why I need help. Attached is the spec file, if somebody could have a look. Here are my questions: - where should go the installed files? (Zoneminder provides perl modules, the site itself, CGI services , doc and conf). - some files have no path's variable: /usr/share/man/lib/perl5/5.14.1/x86_64-linux-thread-multi/perllocal.pod.xz /usr/local/share/man/man3/ZoneMinder.3pm ... Any idea, what it should be? - what should be the permissions for the site under the apache server? - should the %install section creates the database table/permissions for ZoneMinder? If so, is there any example how to achieve this? - should the %install section creates the service launcher scripts? If so, is there any example how to achieve this? Thanks in advance for you help! Vincent FWIW, Fedora has a zoneminder package http://pkgs.fedoraproject.org/gitweb/?p=zoneminder.git They've had it for a long time, so you should find loads of clues over there. -- Ahmad Samir
Re: [Mageia-dev] Need mentor(s) to become a Mageia packager
On 22 July 2011 07:43, Vincent vincent.hervi...@gmail.com wrote:
On 07/22/2011 01:46 AM, Michael Scherer wrote:
Le jeudi 21 juillet 2011 à 16:14 -0400, Vincent a écrit :
Hi All,
I am still trying to pack ZoneMinder for Cauldron.
Now rpms are generated and rpmlint is not complaining, but I am still
sure, it's not OK :) , that's why I need help.
Attached is the spec file, if somebody could have a look.
Here are my questions:
- where should go the installed files? (Zoneminder provides perl
modules, the site itself, CGI services , doc and conf).
conf - /etc/ . I would try to see how does others distribution, to have
at least a similar path to ease the work of people changing distribution
site - /var/www/zoneminder. Outside of the webroot, so people can
modify it with apache configuration
apache configuration - /etc/httpd/conf.d/webapps.d/ , iirc
perl module - like the other ( maybe jq can tell us the details )
cgi - I think there is something in /usr/lib/cgi-bin, not sure. I guess
checking other cgi would help.
I don't have a /usr/lib/cgi-bi, but I have a /var/www/cgi-bin. Can I put
them into /var/www/cgi-bin/Zonedaemon ?
doc - /usr/sharedoc, marked as such with %doc
- some files have no path's variable:
/usr/share/man/lib/perl5/5.14.1/x86_64-linux-thread-multi/perllocal.pod.xz
/usr/local/share/man/man3/ZoneMinder.3pm
...
Any idea, what it should be?
I do not understand the question :/
I don't know how to specify another path for those entries:
/usr/local/share/man/man3/ZoneMinder.3pm
In makefile I get the following:
INST_MAN3DIR = blib/man3
Without looking closely I'd say you can use something like:
%makeinstall INST_MAN3DIR=%{_mandir}/man3
(note that the Fedora spec doesn't do this, so it mightn't be needed).
(One more thing, all package names should be lowercase if possible, so
zoneminder).
How to change this blib path not to point to /usr/local/... ?
- what should be the permissions for the site under the apache server?
that depend on what does the site. There is basically some people that
say this should be 127.0.0.1 by default, and those that say if people
installed it, they want to use it on a network and are able to configure
apache properly, so it should be opened
- should the %install section creates the database table/permissions
for ZoneMinder? If so, is there any example how to achieve this?
Unfortunately, no. A server can be password protected, on another
computer, or using a specific database name.
I always wanted to have a proper framework for that ( like saying this
is the sql file and let some helper script take care of the rest, based
on configuration or offering a easy to use tools to create and install
database after installation ), but never wrote anything :)
- should the %install section creates the service launcher scripts? If
so, is there any example how to achieve this?
Yes. It was not migrated yet ( or maybe it was ), but this should be a
good start :
http://wiki.mandriva.com/en/Development/Howto/Initscripts
Thanks for your help!
Vincent
--
Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release less-444-1.mga2
On 13 July 2011 10:30, Mageia Team buildsystem-dae...@mageia.org wrote: ahmad ahmad 444-1.mga2: + Revision: 123678 - Update to 444 - Update lesspipe to 1.71 - Rediff patch2 (posix) - Drop patch5, fixed differently upstream - Disable the lesspipe tests, (e.g. one of them requires unrar) + tmb tmb - imported package less I don't understand. This is not the first time I see a newly imported package whereas it already existed in mga#1: $ rpm -q less --changelog | head -7 * gwe Gen 07 2011 tmb tmb 436-5.mga1 + Revision: 275 - imported package less * gwe Gen 07 2011 Thomas Backlund t...@mageia.org 436-5.mga1 - initial import And indeed cauldron changelog shows a doble import: * mer Gou 13 2011 ahmad ahmad 444-1.mga2 + Revision: 123678 - Update to 444 - Update lesspipe to 1.71 - Rediff patch2 (posix) - Drop patch5, fixed differently upstream - Disable the lesspipe tests, (e.g. one of them requires unrar) + tmb tmb - imported package less * gwe Gen 07 2011 Thomas Backlund t...@mageia.org 436-5.mga1 - initial import A bug in mgareport that enables to import twice the same package?
Re: [Mageia-dev] Finalizing update process
On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. -- Ahmad Samir
Re: [Mageia-dev] [RPM] cauldron core/release unknown-horizons-2011-1.mga2
On 13 July 2011 13:53, Balcaen John mik...@mageia.org wrote: The group Amusements/Games/Strategy/Real Time doesn't exist in Mageia. 3 different packagers haven't seen this ? :) Maybe we should check it via rpmlint on package upload ? It used to be. I had enabled this @mdv for years.
Re: [Mageia-dev] Finalizing update process
Le vendredi 22 juillet 2011 à 11:04 +0300, Ahmad Samir a écrit : On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. If the only problem is to reassign bugs, then we can write a script. My main worries are that given that right now, there is 1 single person in the group, that change nothing. I would even add that it proves my point, using alias mean that people do not know who they assign the bugs to. So while you think there is no point of failure, but there is, and you do not see nor know it. Also, assigning thing to a group of people tend to make them think someone else will do it :/ Finally, if the problem is someone can leave and we have to reassign bug, there is nothing special regarding security bugs to that regard, and we have the need to reassign others bugs too, and yet, we do not use aliases. So why make a exception just for that ? -- Michael Scherer
Re: [Mageia-dev] Need mentor(s) to become a Mageia packager
Vincent a écrit :
Hi All,
I am still trying to pack ZoneMinder for Cauldron.
Now rpms are generated and rpmlint is not complaining, but I am still
sure, it's not OK :) , that's why I need help.
Attached is the spec file, if somebody could have a look.
Here are my questions:
- where should go the installed files? (Zoneminder provides perl
modules, the site itself, CGI services , doc and conf).
- some files have no path's variable:
/usr/share/man/lib/perl5/5.14.1/x86_64-linux-thread-multi/perllocal.pod.xz
/usr/local/share/man/man3/ZoneMinder.3pm
...
Any idea, what it should be?
- what should be the permissions for the site under the apache server?
- should the %install section creates the database table/permissions
for ZoneMinder? If so, is there any example how to achieve this?
- should the %install section creates the service launcher scripts? If
so, is there any example how to achieve this?
Thanks in advance for you help!
Vincent
I'm not sure about all your questions, but I can give you a few tips to improve
your spec file.
1) The name, version, and release should be defined directly on the first 3
lines. These entries define the %{name}, %{version}, and %{release} macros, so
in lines 9/10/11 you are redefining them to themselves.
2) Use macros whenever possible. This makes it easier to maintain the spec
file, as the value will be defined in only one place.
The build system will automatically use the correct name.
As well, it makes it easier to use the spec file in another distro. The more
distros do this, the easier it is to share, a big plus of open source/free
software in general and Linux in particular.
e.g.
for man you should use %{_mandir} ... which is /usr/share/man/ in Mageia
(your spec puts such files in /usr/local/share/man/..., incorrect for Mageia.)
for executables either %{_bindir} ... for /usr/bin
or if a system type of utility, %{_sbindir} ... for /usr/sbin/
By the way, do you have a mentor ?
If not, you should be in the apprentice table at
http://www.mageia.org/wiki/doku.php?id=packages_mentoring#packager_apprentice_table
Let me know :)
--
André
Re: [Mageia-dev] Finalizing update process
On 22 July 2011 11:27, Michael Scherer m...@zarb.org wrote: Le vendredi 22 juillet 2011 à 11:04 +0300, Ahmad Samir a écrit : On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. If the only problem is to reassign bugs, then we can write a script. My main worries are that given that right now, there is 1 single person in the group, that change nothing. I would even add that it proves my point, using alias mean that people do not know who they assign the bugs to. So while you think there is no point of failure, but there is, and you do not see nor know it. Right. Sorry for wasting your time with my waffling then. Also, assigning thing to a group of people tend to make them think someone else will do it :/ Finally, if the problem is someone can leave and we have to reassign bug, there is nothing special regarding security bugs to that regard, and we have the need to reassign others bugs too, and yet, we do not use aliases. So why make a exception just for that ? -- Michael Scherer -- Ahmad Samir
[Mageia-dev] RFC: gtk-doc proposed changes
ATM gtk-doc requires dblatex which requires texlive - texlive-texmf; due to the outrageous size of texlive-texmf, building packages in local chroots becomes a bit of pain/burden on my HDD, also each of texlive and xmltex have I/O intensive postinstall scriptlets. I see the texlive-texmf issue is being discussed in another thread so I'll keep this one about gtk-doc; here're a couple of points: - Some packages have BR gtk-doc but it's redundant: o They don't have --enable-gtk-doc passed to ./configure, which means that BR isn't used at all o Most of those packages already bundle html gtk-doc's; is there any benefit rebuilding those docs when building the package? or should the gtk-doc BR get dropped in such cases (since no one complained about those html docs all those years)? - I am thinking of splitting gtk-doc itself, putting gtkdoc-mkpdf in a separate sub-package which will require dblatex: o AFAICS dblatex is only used for creating PDF's from XML sources, so only useful for gtkdoc-mkpdf o This will result in less HDD grinding due to texlive-texmf and xmltex being, unnecessarily, pulled in chroots (either local ones or on the BS). Note that for most of the packages I saw, --enable-gtk-doc-html is the default (assuming only --enable-gtk-doc was passed to configure). o I don't see any packages with pdf gtk-doc documentation: $ urpmf /usr/share/gtk-doc | grep pdf gives nothing at all. So, theoretically, this split shouldn't break any packages (there're 144 SRPMS that have BR gtk-doc and 5 -devel packages that require gtk-doc). And if any package breaks due to the split, the fix is simply adding BR gtk-doc-pdf. Of course we can make it more painful and require that those 149 packages get a test build before the split is OK'ed... WDYT? -- Ahmad Samir
Re: [Mageia-dev] RFC: gtk-doc proposed changes
On Fri, 22 Jul 2011, Ahmad Samir wrote: ATM gtk-doc requires dblatex which requires texlive - texlive-texmf; due to the outrageous size of texlive-texmf, building packages in local chroots becomes a bit of pain/burden on my HDD, also each of texlive and xmltex have I/O intensive postinstall scriptlets. The best solution for that may be to put the chroot in a tmpfs. I see the texlive-texmf issue is being discussed in another thread so I'll keep this one about gtk-doc; here're a couple of points: Too bad since this appears to be strongly related to the gtk-doc issue you mention. I mean, providing a minimal set of texlive packages may fix this gtk-doc problem. - Some packages have BR gtk-doc but it's redundant: o They don't have --enable-gtk-doc passed to ./configure, which means that BR isn't used at all o Most of those packages already bundle html gtk-doc's; is there any benefit rebuilding those docs when building the package? or should the gtk-doc BR get dropped in such cases (since no one complained about those html docs all those years)? In general I think it's best to generate everything from original sources [1]. It makes sure all build scripts/code/documentation is generated using the tools in the distro which may be newer and/or have patches compared to the tools used to generate the files shipped with the source code. It also ensures we can support such packages, because when someone reports a bug in a generated file we should never patch that file directly but its source. - I am thinking of splitting gtk-doc itself, putting gtkdoc-mkpdf in a separate sub-package which will require dblatex: o AFAICS dblatex is only used for creating PDF's from XML sources, so only useful for gtkdoc-mkpdf Interesting. o This will result in less HDD grinding due to texlive-texmf and xmltex being, unnecessarily, pulled in chroots (either local ones or on the BS). Note that for most of the packages I saw, --enable-gtk-doc-html is the default (assuming only --enable-gtk-doc was passed to configure). o I don't see any packages with pdf gtk-doc documentation: $ urpmf /usr/share/gtk-doc | grep pdf gives nothing at all. So, theoretically, this split shouldn't break any packages (there're 144 SRPMS that have BR gtk-doc and 5 -devel packages that require gtk-doc). And if any package breaks due to the split, the fix is simply adding BR gtk-doc-pdf. Of course we can make it more painful and require that those 149 packages get a test build before the split is OK'ed... Maybe we should first set as policy to provide HTML developer documentation and not PDFs when there is a choice. Note however that HTML docs generated by doxygen can take a lot of space. Christiaan [1] that's why I'd like to ask you not to remove any autoreconf/autotools/etc. calls from %build (:
Re: [Mageia-dev] [RPM] cauldron core/release mgarepo-1.9.11-1.mga2
On 12 July 2011 23:28, Mageia Team buildsystem-dae...@mageia.org wrote: boklm boklm 1.9.11-1.mga2: + Revision: 123440 - Version 1.9.11: add maintdb command + ahmad ahmad - Fix the URL tag Could you backport it to mga1 please?
Re: [Mageia-dev] [RPM] cauldron core/release mgarepo-1.9.11-1.mga2
Thierry Vignaud skrev 22.7.2011 18:42: On 12 July 2011 23:28, Mageia Teambuildsystem-dae...@mageia.org wrote: boklmboklm 1.9.11-1.mga2: + Revision: 123440 - Version 1.9.11: add maintdb command + ahmadahmad - Fix the URL tag Could you backport it to mga1 please? It actually got pushed as an update to mga1, so it's available... -- Thomas
[Mageia-dev] Bug report for iputils
I've noticed that iputils is in Core Updates Testing, and have tested it on my i586 system, but I can't find a bug report for it. Is there one? Regards, Dave Hodgins
