Re: [gentoo-dev] Reminder: open season on robbat2's packages
Am Wed, 30 Oct 2013 22:10:27 + schrieb "Robin H. Johnson" : > Hi all, > > Since it's been nearly a year since I last sent this email (and I got > poked with a stick about this), it's time for a reminder. I hope that > in future, if we get a non-maintainer update GLEP [1], this will > become unneeded, as it can be on api.gentoo.org. > > 1. http://thread.gmane.org/gmane.linux.gentoo.devel/86359 > > Over the years, I've come to be the maintainer a huge number of > packages (300+) Many of them are from inheriting packages when other > developers have retired - the upstream may also be dead, but there is > nothing that supersedes the functionality of the package, so if I use > it, it lives. > > If you're a developer waiting for an action on one of them, and > you've attached a fix to a bug, you should mostly feel free to go > ahead any just apply your patch. If you break it, I'll hunt you down. > > If you think you want to take over the package instead, or it should > go for last-rites/tree-cleaners etc; please claim it here or drop me > an email; or for the last category: just take it and leave a note. > > Notable changes from last year: > - I'm releasing mogilefs and perlbal. > - new category of stuff people are welcome to take. > > Exceptions: > dev-db/mariadb, dev-db/mysql - mysql herd > sys-libs/db - base-system > sys-fs/lvm2 - please be careful! > > Packages where I am the upstream, and feature requests probably won't > go far without large good patches: > app-admin/diradm > app-shells/localshell > sys-apps/readahead-list > dev-perl/WattsUp-Daemon > > Packages for tree-cleaner consideration: > dev-vcs/gitosis > dev-vcs/gitosis-gentoo > net-mail/vqadmin > > Here's a list of every package where I'm a maintainer and there is no > herd listed (but their might be other maintainers), and I slightly > care about the package: > app-admin/cancd > app-arch/duff > app-arch/unadf > app-backup/mirdir > app-crypt/af_alg > app-crypt/gpg-ringmgr > app-crypt/mhash > app-misc/ddccontrol > app-misc/egads > app-misc/g15composer > app-misc/g15daemon > app-misc/g15macro > app-misc/g15message > app-misc/g15stats > app-misc/gcalcli > app-text/sloccount > app-text/unrtf > dev-libs/libg15 > dev-libs/libg15render > dev-libs/libmcal > dev-libs/libmelf > dev-libs/libmemcache > dev-libs/libmemcached > dev-python/google-api-python-client > dev-vcs/cvs2svn > dev-vcs/git > net-analyzer/ipaudit > net-analyzer/ipv6-toolkit > net-analyzer/poink > net-analyzer/raddump > net-analyzer/sslsniff > net-analyzer/thrulay > net-dns/ndu > net-misc/adjtimex > net-misc/aggregate > net-misc/aggregate-flim > net-misc/ifenslave > net-misc/memcached > net-misc/netdate > net-misc/nstx > net-misc/pcapfix > net-nds/nsscache > net-wireless/bss > net-wireless/spectools > sys-apps/clrngd > sys-apps/input-utils > sys-apps/linux-misc-apps > sys-apps/usbmon > sys-auth/icmpdn > sys-auth/nss_ldap > sys-block/btrace > sys-block/fio > sys-block/scsiping > sys-block/scsirastools > sys-block/seekwatcher > sys-block/tw_cli > sys-power/iasl > sys-power/nut > sys-power/pmtools > sys-process/audit > > Items in this list, you're welcome to take them, just leave a note; > they will still work last I checked, and I do use them occasionally, > but I'm not fussy about them. > app-emulation/qenv > app-misc/dnetc > app-misc/interceptty > app-text/binfind > app-text/convmv > dev-cpp/threadpool > dev-db/libdbi > dev-db/libdbi-drivers > dev-lang/snobol > dev-libs/bglibs > dev-libs/OpenSRF > dev-libs/yaz > dev-lua/lgi > dev-util/checkbashisms > dev-util/fuzz > dev-util/idutils > dev-util/its4 > dev-util/mpatch > dev-util/pscan > dev-util/rats > dev-util/re2c > dev-util/sgb > dev-util/wiggle > media-gfx/monica > media-gfx/springgraph > net-firewall/ipset > net-libs/cvm > net-misc/dcetest > net-misc/openrdate > net-misc/rdate > net-misc/tiers > net-misc/valve > net-misc/vmnet > net-misc/vmpsd > net-misc/zsync > net-nds/led > net-proxy/piper > sys-apps/hwinfo > sys-libs/openhpi > > app-misc/g15composer app-misc/g15daemon app-misc/g15macro app-misc/g15message app-misc/g15stats dev-libs/libg15 dev-libs/libg15render I could help maintaining these as I am using a Logitech G15 and have a Logitech G19 in my locker. dev-vcs/git I'd be interested in this as well although like promethanfire I might be overwhelmed with the mere amount of code in the ebuilds. app-text/convmv I will take it. -- Lars Wendler Gentoo package maintainer signature.asc Description: PGP signature
[gentoo-dev] Re: Reminder: open season on robbat2's packages
On 31/10/2013 09:10, Robin H. Johnson wrote: dev-util/checkbashisms As described in bug #426828, this package currently uses an abandoned upstream, with a much more recent version maintained by Debian. I'd like to, at a minimum, update to a newer version. The better long-term solution is to package debian-devscripts properly and remove this package, which I'm interested in doing.
Re: [gentoo-dev] Reminder: open season on robbat2's packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/10/13 06:10 PM, Robin H. Johnson wrote: > sys-block/tw_cli I've got hardware for this one, so I can take it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlJyWs8ACgkQ2ugaI38ACPDOBQD+ITeE69Q3L0YOD/GkNH13GTsc L0kyMuo9k3aFcoqJzjEA/3kYpnGfOXq2r99WSQxrn6wTndUsMr0wsRMNHE553iXv =nyNR -END PGP SIGNATURE-
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On Thu, Oct 31, 2013 at 10:09:19AM +0100, Lars Wendler wrote: > app-misc/g15composer > app-misc/g15daemon > app-misc/g15macro > app-misc/g15message > app-misc/g15stats > dev-libs/libg15 > dev-libs/libg15render > I could help maintaining these as I am using a Logitech G15 and have a > Logitech G19 in my locker. I've got a G510 here, and recently met the Logitech team responsible for the product development on these; I'm discussing with them about having some actual specifications. You're welcome to help co-maintain for now, I might up end up as upstream instead. > dev-vcs/git > I'd be interested in this as well although like promethanfire I might > be overwhelmed with the mere amount of code in the ebuilds. Add yourselves to it. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] open season on other-dev's packages -- policy change?
Rich Freeman wrote: > If a package has a responsive maintainer, then pinging them isn't > really much of a hurdle. I'm not so sure. Waiting for a human round trip which due merely to time zones might occupy my attention for 24 hours (even if I obviously do other things meanwhile) is IMO quite significantly different from the 24 seconds it might take for me to commit a fix. //Peter
[gentoo-dev] vim and gvim package split
I guess this is an already debated topic, but I only found this very old thread on the subject: http://article.gmane.org/gmane.linux.gentoo.devel/4328 which contains the original communication of the ebuild split and some discussions and observations that probably are no more applicable. I'm absolutely convinced that one of the gentoo strengths is the USE variable handling compile time options, so I do not see any points to split packages when not absolutely needed. In case of vim-core/vim/gvim (and vim-qt?), I cannot understand the reason... Are still there advantages in doing so? Thanks for your time -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: [gentoo-dev] vim and gvim package split
On 1 November 2013 11:02, Alessandro DE LAURENZIS wrote:
>
> In case of vim-core/vim/gvim (and vim-qt?), I cannot understand
> the reason... Are still there advantages in doing so?
Useflags have their perks for giving variations on behaviour, but having 3
effective packages in one, governed by useflags, means you'll have 3 much
more tightly coupled packages, and the code will be much messier with
useflag conditionals to pull dependencies.
If you imagine useflags like "if" statements, and ebuilds like independent
classes where "dependencies" are a kind of inheritance, you may find
theres' reasonable benefits for the maintenance side
e.g.: people checking reverse deps for QT don't have to worry about changes
in QT breaking vim and gvim because those packages are independent of QT
interaction
Fixes that need to go in to make building vs QT mean only the qvim ebuild
gets updated and the rest are fine as-is.
The only real downside is if you're building all 3 {q,g,}vim there's a
little compile time overhead as a result ( Though I'm not sure what the
difference is in real terms )
But by having them seperate, we enjoy a more robust installation,
especially for people who only want one of the 3, then they're not
needlessly burdened by logic to handle things they're not using, which
could break.
Not to mention you have to deal with overheads introduced by having to work
out the equivalent of all three of the above having vastly different
useflags and making useflags conditional upon each other as a result to
codify the same behaviour, again, further raising the odds that a
situtation will arise where things break and the dependencies/use flags
are a mess.
--
Kent
