Re: [gentoo-dev] "frozen" overlay Re: Please stop useless removals

[Dennis Lan (dlan)]

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  wrote:

> On 02/01/2013 09:21 AM, Alec Warner wrote:
> > On Thu, Jan 31, 2013 at 11:36 PM, Vaeth
> >  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  >> 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 
>
>

Re: [gentoo-dev] Packages up for grabs due lack of time

[Dennis Lan (dlan)]

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
#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  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] Should we list sys-apps/sed in DEPEND

[Dennis Lan (dlan)]

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  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/
>

[gentoo-dev] net-fs/autofs needs a new maintainer

[Dennis Lan (dlan)]

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

[Dennis Lan (dlan)]

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
>
>

[gentoo-dev] app-dict team needs help

[Dennis Lan (dlan)]

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 updated&cleanup, also
> if
> you happen to fill stablereq, just cc arches directly there.
>
> Cheers
>
> Tom

Re: [gentoo-dev] app-dict team needs help

[Dennis Lan (dlan)]

On Sat, Jun 8, 2013 at 5:00 PM, Tomáš Chvátal wrote:

> 2013/6/7 Dennis Lan (dlan) 
>
>
>> 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] Introduce global dmalloc USE flag?

[Dennis Lan (dlan)]

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] Introduce global dmalloc USE flag?

[Dennis Lan (dlan)]

On Fri, Jun 21, 2013 at 2:34 AM, Ian Stakenvicius  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)"
>>  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-
>

Re: [gentoo-dev] Maintainer-needed on many of my packages

[Dennis Lan (dlan)]

On Sun, Dec 29, 2013 at 8:19 AM, Robin H. Johnson  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
>