Update of ebuild for webmin versions 1.520 (last stable ) and 1.530 (current stable).
Resolved the bug in old release so these don't touch live FS.
Created attachment 256911 [details]
tar.gz containing ebuilds and necessary files
Comment on attachment 256911 [details]
tar.gz containing ebuilds and necessary files
I could not open it.
tar -xvzf webmin.tgz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
Created attachment 257228 [details]
tar.gz containing ebuilds and necessary files
(In reply to comment #2)
> (From update of attachment 256911 [details])
> I could not open it.
> tar -xvzf webmin.tgz
> tar: This does not look like a tar archive
> tar: Skipping to next header
> tar: Exiting with failure status due to previous errors
wrong MIME type for file, now corrected
the new version 1.510 of webmin is now available! What about having an ebuild in portage or in this bug report please?
*** Bug 374933 has been marked as a duplicate of this bug. ***
what happens with webmin in gentoo ? theres no more ebuild in portge ? not even masked / keyworded ? why ?
emerge -pv app-admin/webmin
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds to satisfy "app-admin/webmin".
emerge: searching for similar names...
emerge: Maybe you meant any of these: app-admin/usermin, app-admin/pwgen, app-admin/gamin?
(In reply to comment #7)
> what happens with webmin in gentoo ? theres no more ebuild in portge ? not
> even masked / keyworded ? why ?
Haha they've removed it long ago... with ridiculous excuses btw... I do not think it will ever be back though... or at least not in the next 10 months considering the speed they accept back packages :D
Anyway https://bugs.gentoo.org/show_bug.cgi?id=374933 should work...
I didn't test it, cause i did already install Webmin using its native install script... And guess what... :) My system is still not damaged :D... At least this will save me the troubles of updating to future versions and the reading of the ridiculous explanations and excuses some devs use here :)
Meanwhile you can look at this http://en.wikipedia.org/wiki/Comparison_of_web_hosting_control_panels list and chose something that will do the job you need webmin to do...
for those not knowing how to use this tr.gz, webmin is still in the "menelkir" overlay ( at least ) perhaps the owner of the overlay and Dell'Aica Valentino could work together to get it back in the main portage ? I d be happy to help / test !
The problems with webmin are listed in the $URL. So I guess we need to fix that first before we re-introduce it to portage
Created attachment 284867 [details]
The webmin-1.560.ebuild tree
since obviously no Gentoo dev is interested in fixing Webmin's ebuild issues,
I did created a totally rewritten ebuild for Webmin (using Dell'Aica Valentino's proposed one as base).
The archive I attach has the webmin ebuild tree with the new required Perl module Authen::Libwrap also (I have opened a separate ebuild bug for this module #380931)
The ebuilds, the install script and everything are well commented, so i suppose you will get the idea.
In a few words the webmin ebuild:
- Complies to Gentoo specs not to mess up with the live system except when configuring by user
- Forces using SSL and PAM for security reasons (so ssl flag is a kinda always forced even if you '-ssl' it)
- Doesn't mess up with upstream code
- Has own install/configure script
- Has respect of installed 3rd party Webmin modules
- Provide minimal install too
- The ldap, mysql and postgres use flags are used only to lower dependency requirements, and thus not to install mysql/postgres/ldap if you do not need them.... But actually Webmin will complain later if you decide to use those modules... So I advice turning on all flags
- Gives the user enough info, warns etc while emerging
- Has a --config option with several options to choose from incl 'Hard reset configuration'
- User config sensible when upgrading
etc etc etc... (please read the comments in the ebuild tree)
This ebuild was tested and works ok (incl. Webmin works ok) on a couple of machines amd64 and x86... That is why the arch flags are only those... of course they are "~"'d ;)
Please test and any comments are welcomed....
I hope the Gentoo devs will be fast enough to return webmin back in portage with this ebuild :)... We will see ;)
If someone is interested in proxy-maintain this ebuild please have look here
I can commit these ebuilds on your behalf, but I need to make sure that a dedicated maintainer (hopefully one or more of you who wrote these ebuilds ) will be around to maintain it.
I wrote this ebuild with two things in mind...
To be easily maintained when a new version comes out, and to be well documented so if someone else wants to maintain it, to know its logic...
If i succeeded is up to the users ...
Anyway since i've already told you i am using Webmin on a regular basis, and i am following its new versions, i am quite sure i will upload the new ebuilds when a new version is out...
It will be a kinda interesting though... since you told me you will ignore me from now on... besides i am not into being a subordinate... so i guess i am not fit, though i can maintain it :)
I suppose @Dell'Aica Valentino would like to maintain it together with me ?
@Dell'Aica Valentino ?
You attitude, treating maintainers of open source projects like paid employees who just don't do their job well, is not very motivating for me to work with you. However, when it comes to maintaining a package, I'd rather put personal disputes aside and just do what I have to do to make things work. So, if you want to maintain it that's fine for me. I need to review the ebuild and make sure I understand what is going on before I commit it thought.
(In reply to comment #14)
> You attitude, treating maintainers of open source projects like paid employees
> who just don't do their job well.....
Well though this is a bug system not a forum... I will answer this very shortly...
1. The way i treat SOME open source developers, maybe not be pleasant for them, BUT IT HAS NOTHING TO DO with treating them as paid employees! (That includes EVEN my note on @Diego's blog)
2. Yes i have my own attitude to people. That is not wrong and if someone doesn't like it he is free to not like it and do whatever he likes to do.
3. If you haven't noticed I AM MYSELF a long time open source developer and maintainer of different projects etc... so you may stop treating me like a noob that has no idea of what is going on...
4. There is no personal dispute! I expose my thoughts on a problem we had, you exposed yours... I am not into make you believe in what i believe or vice versa...
As a side note i never doubted your pro when it comes to doing your job here...
With that said, i intend to stop reading/answering any side notes that do not concern a totally Gentoo tech stuff work here...
Have a nice day :)
I reviewed the ebuild and files and I have some comments
line 73: I guess it misses a \$ before first parenthesis
line 81: keepdir is not needed because I think keepdir is default in /etc directory
line 86: why do you need keepdir in /usr/libexec
line 108: wouldn't it be better to have a conf.d file instead of hardcoding paths in init.d file?
It's good you have comments :)
So here are their answers....:
line 73: No it doesn't miss anything... This is not a command substitution, but it is setting the precedence of operators, so the output of both finds is piped to the perl script. i.e. the $(.......) will just execute the pl and cgi scripts found by find and we do not need that :) .....
line 81: keepdir /etc/webmin is needed 'cause it is not put there automatically for the subdirectories in /etc (refer to net-misc/openssh and dev-db/postgresql-base). Some of the 3rd party modules installed by webmin need this dir too (see my next comment for line 86)
line 86: I have already explained it in the comment above that line (i.e. line 84 in the ebuild) but in short, webmin can install other third party modules (webmin ones) and it does this by placing them in /usr/libexec/webmin, so we need that kept... including because someone later may create an ebuild for a specific webmin module (like usermin, virtualmin etc) so we again need that dir kept
line 108: As i have already explained in the comments of the 'init.d.webmin' giving the user a choice to alter pid, conf, exe will messup all the webmin because pid is set in /etc/webmin/miniserv.conf too, which means if the user changes it in /etc/conf.d/webmin, the init.d script should alter that in miniserv.conf and this could be a problem issue on some configs... besides it alters too much the way webmin works and as far as i am aware Gentoo main principle is to alter upstream program as little as possible etc.... I guess no one will need to alter the place of the conf file, nor the name of the perl start script anyway....
Ok understood. I need a bit more time to review the setup script before I commit webmin masked on portage. I plan to do it next weekend at the latest
Ok I am done with the review. I didn't spotted anything bad whatsoever so webmin-1.560 is back to portage tree. It will remain mask for now for broader testing. PhobosK will be the actual maintainer from now on. Thank you all for your contribution
Could you please just tell me about your preferred way of maintaining the future Webmin versions ebuilds...
1. Open a new ebuild bug report here for the new versions
2. Add the ebuild here to this bug
3. Email you the new ebuilds
4. Smth else?
And BTW I think you should officially inform the Webmin team that their application is back to portage... 'cause it was a kinda rude when it was removed...
(In reply to comment #20)
I'd say open a new bug and attach the new ebuild cause I usually forget about e-mails :/
And BTW, could you please change my email address in metadata.xml, ChangeLog etc to the one i originally listed in my ebuild tree here... i.e. phobosk at kbfx.net ... Cause i use the one i am registered here for other specific usage...
(In reply to comment #22)
I can't do that. The e-mail listed in metadata.xml has to be the same you use on gentoo bugzilla so bug-wranglers can assign bugs to a valid registered e-mail. So you either need to change your email in your bugzilla account or keep things the way they are now