Re: [gentoo-dev] Maintainer-needed on many of my packages
On Sun, Dec 29, 2013 at 8:19 AM, Robin H. Johnson robb...@gentoo.org wrote: Hi all, As a followup on my October email, I'm dropping some more packages. In October, I was still at 300+, now I'm at 195, and I think the ~60 odd below should also go out to other developers. The prior email primarily covered packages where I was there maintainer, and there was no herd to take the package. This email by comparison, is explicitly packages where there is a herd, but I'm explicitly listed as a maintainer. Mostly I'm listing them because I have no further need for the package: either at work, or I haven't personally used it it in more than year. I added some of these a decade ago, when I first joined Gentoo, and needed them for my university classes. The great majority of these work perfectly fine, and in many cases, they are up to date with no bugs. .. net-fs/autofs I'm taking care of this one, and you are only listed as proxy-maintainer ;-) net-libs/cvm net-mail/autorespond net-mail/checkpassword net-mail/qlogtools net-mail/qmail-lint net-mail/qmail-qsanity net-mail/qmailadmin net-mail/qmailanalog net-mail/qmhandle net-mail/qtools net-mail/queue-fix net-mail/relay-ctrl net-mail/safecat net-mail/vqadmin net-misc/dcetest net-misc/nstx net-misc/suite3270 net-misc/vmnet net-misc/vmpsd net-misc/zsync net-nds/led sci-mathematics/glpk # university... sci-mathematics/nusmv # university... sci-physics/xfoil # university... sys-apps/vbetool sys-block/qla-fc-firmware # stack, hardware isn't obsolete yet sys-cluster/corosync -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Introduce global dmalloc USE flag?
On Fri, Jun 21, 2013 at 2:34 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/06/13 01:05 AM, Michał Górny wrote: Dnia 2013-06-13, o godz. 09:35:54 Dennis Lan (dlan) dennis.y...@gmail.com napisał(a): also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7) net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd use dmalloc but controlled under USE=debug Do those use USE=debug solely for dmalloc or does it imply other stuff? Therefore: will it be possible to use USE=dmalloc in those packages? HI mgorny, as I look into those ebuilds all of them use the USE=debug flag for dmalloc only, not for other debugging control so, as your second question, of course it's possible to switch to USE=dmalloc and to follow up, if we assume that USE=debug does more than just build the package against the dmalloc lib (which is likely), is there Yes, if this case exist.. then the separation would be good any particular benefit to USE=debug -dmalloc ? Or USE=dmalloc - -debug ? I'm not sure, probably the befefits would be that we can have more accurate/explicit control, USE=dmalloc is for debugging memory usage stuff (allocation, free, fence-post overwritten control) and USE=debug for other stuff? This is a slightly improvement, but I'm also totally fine to keep current state as it is.. no big deal -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlHDSyEACgkQ2ugaI38ACPAHUwEAqFFDyarLSE8I/k8eKBUibmxu qZT2pnaaMj3nPEqrFxYBAIsIP8HAHR5mIaLBHKPiR6/oI/cxcu3h1XFodpbERO4t =T2KX -END PGP SIGNATURE-
[gentoo-dev] Introduce global dmalloc USE flag?
HI ALL: Is it ok to introduce USE=dmalloc global flag? description as following dmalloc - Enable debugging with the dmalloc library current consumers: 1) net-fs/autofs 2) net-misc/directvnc 3) sci-biology/yass also 4) app-admin/conserver 5) net-nds/ypbind 6) net-fs/samba 7) net-analyzer/scli 8) net-analyzer/traceproto 6) net-misc/siproxd use dmalloc but controlled under USE=debug Dennis Lan
Re: [gentoo-dev] app-dict team needs help
On Sat, Jun 8, 2013 at 5:00 PM, Tomáš Chvátal tomas.chva...@gmail.comwrote: 2013/6/7 Dennis Lan (dlan) dennis.y...@gmail.com stardict: trivial bugs around but i don't use stardict. Hi Tomas I'm a stardict user, let me know what I can help Hello Dennis, Currently there are 18 open bugs [1], so just looking into them would be nice. Checking if the ebuilds could be moved to latest eapi and cleaned up might be good. Opening stabilisation bug requests for various dictionaries that are for 3+ years in testing is also good idea :-) Also if you have any diffs just sent the mail to me or proxy-ma...@g.oand we shall include it in cvs (gosh I want git and gerrit). Cheers Tom [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=stardict Hi Tom: ok, I'd plan to bump stardict first, there is already one in gentoo-zh overlay will reach you when I'm ready.. Later I will go through the bugs.. I'm using git, can send you patches, but I'm not sure how we can cooperate with gerrit. Dennis Lan
[gentoo-dev] app-dict team needs help
On Tuesday, June 4, 2013, Tomáš Chvátal wrote: Hello guys, the app-dict team is almost-non existent altho it provides one of the most core features for our daily desktop usage as without dictionaries and spell checking we could not imagine much work nowdays. So what is needed there: aspell - all various bugs around, per language file bumps here and there, cleanup and provide new eclass for aspell packages, current one is needlesly complex. myspell(hunspell): finish migration to myspell-r1 on the remaining packages, find more upstreams and include the lang files into the distribution. Most important here is that we have dicts for english from 2007 and they were updated a lot in last 6 years when i check the git in libreoffice dicts (but there is no upstream indication). stardict: trivial bugs around but i don't use stardict. Hi Tomas I'm a stardict user, let me know what I can help I check this herd as I need it for nice and compfy libreoffice usage, but mostly I am not devoting much to it, so if you guys happen to have spare cycles, please take look for your languages/etc and updatedcleanup, also if you happen to fill stablereq, just cc arches directly there. Cheers Tom
[gentoo-dev] net-fs/autofs needs a new maintainer
On Sunday, June 2, 2013, Markos Chandras wrote: Hi, The previous maintainer of net-fs/autofs has gone MIA so the package needs a new maintainer. There are quite a few bugs[1] as well. If a user wants to help, please reply here and contact proxy-maint_at_gentoo_dot_org [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=net-fs%2Fautofs -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang Hi Markos, Others I'm willing to step in as a co-maintainer, if Dustin? Or anyone else still willing to take care of this little package. I tried to add a few comments to those bugs on #bugzilla ... Dennis
[gentoo-dev] net-fs/autofs needs a new maintainer
On Friday, June 7, 2013, Robin H. Johnson wrote: On Fri, Jun 07, 2013 at 12:52:50AM +0800, Dennis Lan (dlan) wrote: On Sunday, June 2, 2013, Markos Chandras wrote: Hi, The previous maintainer of net-fs/autofs has gone MIA so the package needs a new maintainer. There are quite a few bugs[1] as well. If a user wants to help, please reply here and contact proxy-maint_at_gentoo_dot_org [1] https://bugs.gentoo.org/buglist.cgi?quicksearch=net-fs%2Fautofs Hi Markos, Others I'm willing to step in as a co-maintainer, if Dustin? Or anyone else still willing to take care of this little package. I tried to add a few comments to those bugs on #bugzilla ... As the maintainer of autofs from 2005, if you're willing to put your work in an overlay and handle the bugs, I'd be more than willing to merge from there for you. Will do, I may talk to you via IRC tomorrow... I'd plan to cook a 5.0.7-r2 (address the bugs) It's great if you can keep ones eyes on me, thanks -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Should we list sys-apps/sed in DEPEND
Hi thomas, @all: Thanks for bring up this for discussion.. I think 'embedded' profile have only one sys-apps/busybox as system package, but seems this profile haven't updated for long time, and may become obsolete.. Dennis On Tue, Feb 19, 2013 at 9:10 PM, Thomas Kahle to...@gentoo.org wrote: ... if it is used in the ebuild? It is a system package here on amd64, but is it everywhere? Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/
Re: [gentoo-dev] Packages up for grabs due lack of time
Hi ALL: I'd like to help with following packages (will proxy via tomka) dev-libs/libev which I see one open bug, but trivial to fix #429526https://bugs.gentoo.org/show_bug.cgi?id=429526 net-misc/ofono need version bump (current 1.10, upstream release 1.12) If any developer willing to help, would be great! ~ and feel free to touch the ebuilds which I maintain Dennis On Wed, Feb 6, 2013 at 4:29 PM, Thomas Kahle to...@gentoo.org wrote: On 13:46 Sun 03 Feb 2013, Pacho Ramos wrote: Due matsuu lack of time the following packages are up for grabs: dev-cpp/gtest I'll take this one. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/
Re: [gentoo-dev] frozen overlay Re: Please stop useless removals
HI Michael: I can think of it's almost kind of a staging area, some package may be partial broken(or partial functional), but still useful for user. Generally speaking, It should be a good idea! The end users will benefit a lot. Also if user show his interests, then he can report bug, send patch, or step in to active maintain the package. Leave a opportunity to him... Dennis On Fri, Feb 1, 2013 at 4:53 PM, Michael Weber x...@gentoo.org wrote: On 02/01/2013 09:21 AM, Alec Warner wrote: On Thu, Jan 31, 2013 at 11:36 PM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: # Upstream is dead and gone. # Masked for removal on 20130302 Erm, so this is the _only_ reason - dead upstream? If folks do not want to maintain it anymore, then it will be removed. Feel free to contribute to Gentoo and maintain the packages. Hereby done, becoming a dev is a big step for just one package a user would keep. Ihmo, what you call upstream dead is a kind of positive situation. If the author has no longer time to contribute (we all have a real life) then it's ok, no need to wipe his contribution from the face of the world. If the software is just working as the author intendend, and it has no major bugs, then there's no need to do further trivial releases just to keep the disto maintainers busy. If it's broken, uncompatible and nobody steps up, drop it, agreed. You are destroying the charme of gentoo by systematically removing all these little tools and toys. The availability of a lot of software was once a strength of gentoo, so removing these things is really bad, especially if it happens for no real reason. We need to maintain a certain quality. Sheer mass does has no charm, if nothing works. But I'd rather like to see gentoo as a broad selection of tools, that build. maybe some really cool stuff nobody else has. Gentoo is not a software archival service. I was understanding if e.g. someting was removed which needs the gtk-2 or qt-4 framework or something similar and had a dead upstream. But just needing a small tool like imake (xboing) or having open feature requestes (epm) or even nothing and just dead upstream is IMHO really not a reason. If something really does not compile anymore and nobody cares, then remove keywords (or, for god's sake, mask it); if something might theoretically become a security issue (xpdf) then it should be masked. But please do not throw things out of the tree unless really necessary: It does not hurt anybody to have such package in the tree, but removing it - especially if upstream is dead - means that the tarbalös will be removed from the mirrors and thus nobody is able anymore to install it (even if he would care and fix some minor issues) unless he had kept a copy on his local machine (which will mean in the future that he can only do it if he had used gentoo already many years ago and cared during the time of the removal). Again I highly recommend archiving the software yourself; but I don't think Gentoo should be doing it. It costs resources: - distfiles and all their mirrors accumulate - emerge dependency calculation If it's out-waged by increasing disc capacity and processor power is up to discussion. Last but not least, we have gattered some extra info besides the tarballs, our precious ebuild scripts. Which is why I started my involvement with Gentoo (maybe somebody should have told me about BSDs tree before that). As Martin said, tarballs get lost. I steal them from debian mirror on a regular basis, maybe we should contribute ourselves. PROPOSAL Let's create an overlay frozen stuff which contains all the software no longer developed with following features: Users showed interest in having them Web-presence to be picked up on Google search. (viewvc.cgi show dead is kinda hidden [1]) Separate distfile mirror no need to stress our mirror peers make it a sepearate repo, feed by upstream and mirror://gentoo I can contribute the space/bandwith. Feedback/Bugs/Voting can be handled inside b.g.o no need for extra login, frozen-bugs can be auto-generated, whitelist [frozen] just like the sunrise tracker bugs. BENEFIT User can choose whether or not layman -a frozen. Non-trivial ebuilds are preserved. Tarballs are preserved. Nobody gets hurt. Comments? [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/ -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
