[gentoo-dev] Re: Digest of [e-mail] issue 1125 (56929-56978)

[Liam McLoughlin]

unsubscribe


On 26 December 2012 17:38, <gentoo-dev+help@l.g.o> wrote:

> Topics (messages 56929 through 56978):
>
> [gentoo-dev] Time based retirements
>       56929 - Rich Freeman <rich0@g.o>
>
> [gentoo-dev] About using a CONFIGURATION (or SETUP) file under
> /usr/share/doc for configuration information
>       56930 - Markos Chandras <hwoarang@g.o>
>
> [gentoo-dev] About using a CONFIGURATION (or SETUP) file under
> /usr/share/doc for configuration information
>       56931 - Alexandre Rostovtsev <tetromino@g.o>
>
> [gentoo-dev] About using a CONFIGURATION (or SETUP) file under
> /usr/share/doc for configuration information
>       56932 - Markos Chandras <hwoarang@g.o>
>
> [gentoo-dev] About using a CONFIGURATION (or SETUP) file under
> /usr/share/doc for configuration information
>       56933 - Brian Dolbec <dolsen@g.o>
>
> [gentoo-dev] Proposed removal of service: torrents.gentoo.org
>       56934 - "Robin H. Johnson" <robbat2@g.o>
>
> [gentoo-dev] About using a CONFIGURATION (or SETUP) file under
> /usr/share/doc for configuration information
>       56935 - Zac Medico <zmedico@g.o>
>
> [gentoo-dev] About using a CONFIGURATION (or SETUP) file under
> /usr/share/doc for configuration information
>       56936 - Pacho Ramos <pacho@g.o>
>
> [gentoo-dev] About using a CONFIGURATION (or SETUP) file under
> /usr/share/doc for configuration information
>       56937 - Diego Elio Pettenò <flameeyes@×××××××××.eu>
>
> [gentoo-dev] Automated Package Removal and Addition Tracker, for the week
> ending 2012-12-23 23h59 UTC
>       56939 - "Robin H. Johnson" <robbat2@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56940 - Sebastian Pipping <sping@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56941 - Sebastian Pipping <sping@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56942 - Ulrich Mueller <ulm@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56943 - Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56944 - Michael Mol <mikemol@×××××.com>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56945 - Diego Elio Pettenò <flameeyes@×××××××××.eu>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56946 - Michał Górny <mgorny@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56947 - Ulrich Mueller <ulm@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56949 - Michael Mol <mikemol@×××××.com>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56950 - "vivo75@×××××.com" <vivo75@×××××.com>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56951 - Ulrich Mueller <ulm@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56952 - "Rick "Zero_Chaos" Farina" <zerochaos@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56953 - "Rick "Zero_Chaos" Farina" <zerochaos@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56954 - Diego Elio Pettenò <flameeyes@×××××××××.eu>
>
> [gentoo-dev] gen_usr_ldscript & --libdir=/lib
>       56955 - Mike Frysinger <vapier@g.o>
>
> [gentoo-dev] gen_usr_ldscript & --libdir=/lib
>       56956 - Diego Elio Pettenò <flameeyes@×××××××××.eu>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56957 - Michael Hampicke <gentoo-dev@××××.biz>
>
> [gentoo-dev] Re: Is /var/cache the right place for repositories?
>       56958 - Duncan <1i5t5.duncan@×××.net>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56959 - Ulrich Mueller <ulm@g.o>
>
> [gentoo-dev] Is /var/cache the right place for repositories?
>       56960 - Peter Stuge <peter@×××××.se>
>
> [gentoo-dev] Drop the Perl Modules Guideline?
>       56961 - Torsten Veller <tove@g.o>
>
> [gentoo-dev] tools-portage herd unmaintained packages
>       56962 - Pacho Ramos <pacho@g.o>
>
> [gentoo-dev] tools-portage herd unmaintained packages
>       56965 - Brian Dolbec <dolsen@g.o>
>
> [gentoo-dev] Drop the Perl Modules Guideline?
>       56967 - Sergey Popov <pinkbyte@g.o>
>
> [gentoo-dev] Proposed removal of service: torrents.gentoo.org
>       56968 - Sergey Popov <pinkbyte@g.o>
>
> [gentoo-dev] default mta
>       56969 - Eray Aslan <eras@g.o>
>
> [gentoo-dev] default mta
>       56970 - Mike Pagano <mpagano@g.o>
>
> [gentoo-dev] default mta
>       56971 - Eray Aslan <eras@g.o>
>
> [gentoo-dev] Re: default mta
>       56972 - Duncan <1i5t5.duncan@×××.net>
>
> [gentoo-dev] default mta
>       56973 - Rich Freeman <rich0@g.o>
>
> [gentoo-dev] Attracting developers (Re: Packages up for grabs...)
>       56974 - Kent Fredric <kentfredric@×××××.com>
>
> [gentoo-dev] Call for agenda items -- Council meeting 2013-01-08
>       56975 - "Tony "Chainsaw" Vroon" <chainsaw@g.o>
>
> [gentoo-dev] tools-portage herd unmaintained packages
>       56977 - Paul Varner <fuzzyray@g.o>
>
> [gentoo-dev] Re: [gentoo-dev-announce] Lastrites:
> media-sound/logitechmediaserver-bin, net-dialup/misdn,
> net-dialup/misdnuser, net-misc/asterisk-chan_misdn,
> www-apache/mod_authn_pam, www-apache/mod_cplusplus, net-dialup/ltmodem,
> =dev-libs/gmime-2.2.27-r1, www-apache/mod_spin, www-apache/mod_python,
> dev-dotnet/galago-sharp, sys-apps/galago-daemon, dev-libs/libgalago,
> www-apache/mod_transform, dev-util/monodevelop-java,
> dev-util/monodevelop-python, dev-util/monodevelop-vala, media-libs/libdlna,
> media-video/ushare, app-admin/flexlm, net-misc/cisco-vpnclient-3des,
> app-emulation/systemsim-cell, sys-block/gcloop,
> games-roguelike/noegnud-data, games-roguelike/noegnud-nethack,
> games-roguelike/noegnud-slashem
>       56978 - Markos Chandras <hwoarang@g.o>
>
>
> On Sun, Dec 23, 2012 at 4:39 AM, Markos Chandras <hwoarang@g.o>
> wrote:
> > On 12/23/2012 02:06 AM, Doug Goldstein wrote:
> >> On Fri, Dec 21, 2012 at 7:05 PM, Markos Chandras
> >> <hwoarang@g.o> wrote:
> >>>
> >>>
> >>
> >> I see "free" as "dump a lot of orthogonally related packages on to
> >> the herd that is listed but really the other herd members aren't
> >> interested in those packages.
> >
> > Then that herd should not be on metadata.xml. What's the point of
> > being there if they have absolutely no idea how to maintain the
> package...
>
> Agreed - I suspect that many herds reflect how packages were
> maintained 5 years ago, and not how they are maintained today.  If a
> herd isn't associated with an active project, it should probably be
> dropped.
>
> > *Sigh*. We don't retire people who actively commit. If that person was
> > not capable of maintain this package (say if that package has 20 open
> > bugs for months) then we need to remove him from metadata.xml and say
> > "sorry folks nobody maintains it"
>
> Depends on the bug.  :)  At work most of the systems I work on have
> had hundreds of open bugs for years.  A failure to close a bug is not
> a failure to maintain.
>
> In any case, nobody should be forcibly retired if they're interested
> in sticking around.  However, the fact is that if you guys are sending
> out emails and getting no replies for weeks on end, what else can you
> do?
>
> >
> >> If you need a concrete example of a package, that would be MythTV.
> >> I've been hoping for the day that someone becomes a Gentoo
> >> developer with the goal of maintaining MythTV for nearly a decade
> >> but it hasn't happened.
> > Did you explicitly drop it to maintainer-needed@ so others can know
> > nobody maintains it? Or do you expect them to guess it by leaving bugs
> > open on purpose? Telling people on bugzilla that they are welcome to
> > maintain it is only part of a solution. Did you announce it on a
> > mailing list? Maybe gentoo-users@
>
> Hmm, mythtv is part of its own herd, so I never bothered to add myself
> to the metadata.xml.  Maybe I should do that.  :)
>
> I don't have any plans to go anywhere - in fact I just stuck a new set
> of 0.26 fixes in my overlay for testing (rich0 in layman) and was
> planning on moving them into the tree in a week or so.
>
> > Like I said we are working on a "less brain-dead" policy so I have
> > nothing else to contribute to this thread
>
> Feel free to solicit feedback on such policy from the dev community at
> large.  This is obviously something of general interest.  That isn't
> to say that you can't brainstorm things internally and formulate your
> thoughts as well.
>
> Rich
>
> On 23 December 2012 09:57, Pacho Ramos <pacho@g.o> wrote:
> > El sáb, 22-12-2012 a las 13:53 -0800, Zac Medico escribió:
> >> On 12/22/2012 01:46 PM, Markos Chandras wrote:
> >> > On 22 December 2012 09:26, Pacho Ramos <pacho@g.o> wrote:
> >> >> Hello
> >> >>
> >> >> After seeing:
> >> >> https://bugs.gentoo.org/show_bug.cgi?id=440214
> >> >>
> >> >> Looking to a lot of its blockers shows that we are using "elog"
> messages
> >> >> for informing people about configuration (like pointing people to
> >> >> external links to get proper way of configuring things, tell them to
> add
> >> >> to some system groups...). I thought that maybe this kind of
> information
> >> >> could be simply included in a canonical file under /usr/share/doc/
> >> >> package dir called, for example, CONFIGURATION or SETUP. We would
> them
> >> >> point people (now with a news item, for the long term provably a
> note to
> >> >> handbook to newcomers would be nice) to that file to configure their
> >> >> setups. The main advantages I see:
> >> >> - We will flood less summary.log ;)
> >> >> - The information to configure the package is always present while
> >> >> package is installed, now, if we remove merge produced logs, people
> will
> >> >> need to reemerge the package or read directly the ebuild
> >> >>
> >> >> What do you think?
> >> >
> >> > Correct me if I am wrong but are you suggesting we drop the elog
> >> > messages altogether? I still believe that having the elog messages
> >> > at the end of an 'emerge -uDN world' is more convenient. Maybe it
> >> > makes sense to have both, as in print the elog messages and
> >> > create those CONFIGURATION or SETUP files at the same time.
> >>
> >> As a compromise, you could have the ebuild trigger the elog message only
> >> when there is not a previous version of the package installed.
> >
> > That sounds interesting in combination :O Looking to, for example, e4rat
> > ebuild, it should elog the info to configure it first time and later
> > people could rely on CONFIGURATION doc to recover that information, not
> > flooding summary.log any longer and not losing the info, looks nice :D
>
> But like I said, elog messages are already saved in
> /var/log/portage/elog/$cat/$pf so people can
> read these. Isn't this the same with what you suggest?
>
> --
> Regards,
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
>
> On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> > But like I said, elog messages are already saved in
> > /var/log/portage/elog/$cat/$pf so people can
> > read these. Isn't this the same with what you suggest?
>
> Is that by default? And when was that default added?
>
> I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> (using portage-2.2.0_alpha149), and in fact have never heard of this log
> file before your email.
>
>
> On 23 December 2012 13:58, Alexandre Rostovtsev <tetromino@g.o>
> wrote:
> > On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> >> But like I said, elog messages are already saved in
> >> /var/log/portage/elog/$cat/$pf so people can
> >> read these. Isn't this the same with what you suggest?
> >
> > Is that by default? And when was that default added?
> >
> > I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> > (using portage-2.2.0_alpha149), and in fact have never heard of this log
> > file before your email.
> >
> >
>
> Good question. I believe this is handled by the PORTAGE_ELOG_*
> variables in /etc/portage/make.conf
>
> --
> Regards,
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
>
> On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote:
> > On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> > > But like I said, elog messages are already saved in
> > > /var/log/portage/elog/$cat/$pf so people can
> > > read these. Isn't this the same with what you suggest?
> >
> > Is that by default? And when was that default added?
> >
> > I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> > (using portage-2.2.0_alpha149), and in fact have never heard of this log
> > file before your email.
> >
> >
>
> No, they are not saved there by default.  They must be enabled.
>
> elog messages are not saved there, those are the build logs. They are
> saved in /var/log/portage/elog/  as for example:
>
> app-portage:gentoolkit-0.3.0.7:20121216-000453.log
>
> PLUS, they can be cleaned by emaint or setup to be auto-cleaned by
> emerge as well so as to not fill up the system with old build logs.
>
> emaint -p logs
>
> the default is 7 days old, will be cleaned.  The emaint log module also
> takes a -t, --time option.
>
>
> Pacho was right with his original email.  It would be best to install
> that small text file of info where it can be found for reference later.
> I have often had to go searching ebuilds for elog/einfo data about
> configuring some pkg for such and such long after it's first install due
> to needs changing or some breakage of some kind.
>
> Much like our gentoo handbook, where most of that info can be found
> elswhere on the net, this would extend to pkgs so that that info could
> be compiled together in a place that did not require net access to find
> key info needed.
>
> This proposed method would not apply to all those pkgs with over use of
> elog/einfo either.  Many of those just need to use has_version() to
> reduce the noise.  But there are many such pkgs in the tree that could
> benefit from the dev putting together a small doc of the configuration
> info for gentoo, put it into the files dir to be installed as Pacho
> suggests.  It would likely reduce the number of bugs submitted due to
> bad configuration and make it easier for users to locate (after some
> time to get use to the idea where to find them).
> --
> Brian Dolbec <dolsen@g.o>
>
> torrents.gentoo.org has been down for a few months now, and there have
> been very few comments about it. Up until a few years ago, it was still
> quite useful, but I believe that we have sufficient bandwidth and
> mirror-coverage around the world that it's become a moot point.
>
> If you have any complaints, objections, etc, please respond in this
> thread.
>
> Service:
> ---------
> torrents.gentoo.org
>
> Service termination date:
> -------------------------
> Already (it's been broken a while)
>
> Functions:
> -----------
> - .torrent file hosting
> - BitTorrent tracker
> - BitTorrent stats per .torrent files
>
> Handling of functions going forward:
> ------------------------------------
> If we need torrents in future, we should use public trackers, as there
> is no further need to run our own BitTorrent tracker. The .torrent
> files themselves should live on our own mirrors, with GPG signatures to
> prove authenticity (we actually only need to sign the infohash value).
>
> The only thing we'd actually be losing is statistics on the .torrents,
> which were never that accurate to begin with - people gamed them more
> than once, and we didn't always catch them in time, if anything, what
> statistics we have would currently under-report by some degree, possibly
> as much as 50%.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Developer, Trustee & Infrastructure Lead
> E-Mail     : robbat2@g.o
> GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>
> On 12/23/2012 08:35 AM, Brian Dolbec wrote:
> > On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote:
> >> On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> >>> But like I said, elog messages are already saved in
> >>> /var/log/portage/elog/$cat/$pf so people can
> >>> read these. Isn't this the same with what you suggest?
> >>
> >> Is that by default? And when was that default added?
> >>
> >> I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> >> (using portage-2.2.0_alpha149), and in fact have never heard of this log
> >> file before your email.
> >>
> >>
> >
> > No, they are not saved there by default.  They must be enabled.
>
> /var/log/portage/elog/summary.log is enabled by default though, and
> portage installs /etc/logrotate.d/elog-save-summary to manage it.
> --
> Thanks,
> Zac
>
> El dom, 23-12-2012 a las 13:36 -0800, Zac Medico escribió:
> > On 12/23/2012 08:35 AM, Brian Dolbec wrote:
> > > On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote:
> > >> On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> > >>> But like I said, elog messages are already saved in
> > >>> /var/log/portage/elog/$cat/$pf so people can
> > >>> read these. Isn't this the same with what you suggest?
> > >>
> > >> Is that by default? And when was that default added?
> > >>
> > >> I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> > >> (using portage-2.2.0_alpha149), and in fact have never heard of this
> log
> > >> file before your email.
> > >>
> > >>
> > >
> > > No, they are not saved there by default.  They must be enabled.
> >
> > /var/log/portage/elog/summary.log is enabled by default though, and
> > portage installs /etc/logrotate.d/elog-save-summary to manage it.
>
> But I remember to, for example, this kind of message:
>         elog
>         elog "Please consult the upstream wiki if you need help"
>         elog "configuring your system"
>         elog "http://e4rat.sourceforge.net/wiki/index.php/Main_Page"
>         elog
>
>
> The idea would be to make it to be only shown at first message and,
> later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION
> file if they want to remember that tip
>
>
> On 23/12/2012 23:54, Pacho Ramos wrote:
> > The idea would be to make it to be only shown at first message and,
> > later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION
> > file if they want to remember that tip
>
> So you want in the main documentation a request to read the package
> documentation on where to find the upstream documentation?
>
> --
> Diego Elio Pettenò — Flameeyes
> flameeyes@×××××××××.eu — http://blog.flameeyes.eu/
>
>
> The attached list notes all of the packages that were added or removed
> from the tree, for the week ending 2012-12-23 23h59 UTC.
>
> Removals:
> media-sound/leechcraft-muziczombie      2012-12-18 17:31:53     maksbotan
> media-sound/leechcraft-muziczombie      2012-12-18 18:05:32     maksbotan
> media-sound/leechcraft-lemon            2012-12-20 13:59:21     maksbotan
>
> Additions:
> sec-policy/selinux-openrc               2012-12-17 08:48:02     swift
> net-analyzer/nagios-check_pidfile       2012-12-17 09:15:23     hollow
> dev-ruby/nagios                         2012-12-17 09:31:34     hollow
> app-crypt/cryptkeeper                   2012-12-17 19:31:21     hwoarang
> dev-python/charade                      2012-12-17 19:48:55     radhermit
> games-rpg/penumbra-collection           2012-12-17 21:42:41     hasufell
> dev-python/cx_Freeze                    2012-12-18 07:39:33     pinkbyte
> media-sound/leechcraft-touchstreams     2012-12-18 13:17:56     maksbotan
> media-sound/leechcraft-muziczombie      2012-12-18 13:22:34     maksbotan
> media-sound/leechcraft-lemon            2012-12-18 13:23:19     maksbotan
> media-sound/leechcraft-muziczombie      2012-12-18 17:39:50     maksbotan
> media-sound/leechcraft-musiczombie      2012-12-18 18:52:18     maksbotan
> x11-terms/terminology                   2012-12-19 16:35:13     sera
> x11-libs/pangox-compat                  2012-12-19 16:38:43     tetromino
> dev-python/keyring                      2012-12-19 20:47:59
> prometheanfire
> net-misc/leechcraft-lemon               2012-12-20 13:54:38     maksbotan
> x11-misc/kbdd                           2012-12-21 10:19:36     qnikst
> dev-games/etrophy                       2012-12-21 14:42:02     tommy
> x11-plugins/echievements                2012-12-21 14:45:29     tommy
> media-libs/ethumb                       2012-12-21 20:48:30     tommy
> app-benchmarks/expedite                 2012-12-21 21:08:52     tommy
> virtual/pyparsing                       2012-12-21 21:58:01     mgorny
> dev-python/wsgilog                      2012-12-22 11:56:52     hwoarang
> x11-plugins/leechcraft-lhtr             2012-12-22 15:28:04     maksbotan
> virtual/leechcraft-wysiwyg-editor       2012-12-22 15:31:26     maksbotan
> net-misc/leechcraft-blogique            2012-12-22 15:47:39     maksbotan
> dev-util/open-vcdiff                    2012-12-22 18:28:38     floppym
> dev-cpp/gtkmm-utils                     2012-12-23 09:46:25     hwoarang
> app-text/referencer                     2012-12-23 09:53:09     hwoarang
> dev-lang/rebol                          2012-12-23 10:54:42     patrick
> dev-lang/rebol-bin                      2012-12-23 10:55:09     patrick
> net-libs/libzapojit                     2012-12-23 17:32:45     eva
> net-voip/homer                          2012-12-23 17:50:07     hwoarang
>
> --
> Robin Hugh Johnson
> Gentoo Linux Developer
> E-Mail     : robbat2@g.o
> GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
>
> On 20.12.2012 19:14, Ciaran McCreesh wrote:
> > The tree is a database. It belongs in /var/db/.
>
> I don't see /var/db in the latest release of the Filesystem Hierarchy
> Standard:
>
>   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY
>
> I would prefer something that blends with FHS.
>
> Best,
>
>
>
> Sebastian
>
> On 20.12.2012 18:27, Ulrich Mueller wrote:
> > Now I wonder: After removal of e.g. the Portage tree from a system, it
> > is generally not possible to restore it. (It can be refetched, but not
> > to its previous state.)
> >
> > Same is true for distfiles, at least to some degree. They may have
> > vanished upstream or from mirrors.
> >
> > Maybe /var/lib would be a better choice? It would also take care of
> > the issue with fetch-restricted files.
>
> Thanks for bringing it up.  What you address above is the exact reason
> why Layman's home was moved to /var/lib/layman/ eventually.  It has a
> cache aspect, bit it's not a true cache.
>
> Best,
>
>
>
> Sebastian
>
>
> >>>>> On Mon, 24 Dec 2012, Sebastian Pipping wrote:
>
> > On 20.12.2012 19:14, Ciaran McCreesh wrote:
> >> The tree is a database. It belongs in /var/db/.
>
> > I don't see /var/db in the latest release of the Filesystem
> > Hierarchy Standard:
>
> >   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY
>
> Wrong standard to choose from. ;-) /var/db/ is already required by the
> PMS for /var/db/pkg/.
>
> > I would prefer something that blends with FHS.
>
> Is this important for a Gentoo specific directory?
>
>    /var/db/portage/         PORTDIR
>    /var/db/layman/          layman storage
>    /var/db/pkg/             VDB (no change)
>    /usr/local/portage/      local overlays (no change)
>    /var/cache/distfiles/    DISTDIR
>    /var/cache/packages/     PKGDIR
>
> Alternatively, the last two could be under
> /var/cache/portage/{distfiles,packages}/.
>
> Ulrich
>
> On Mon, 24 Dec 2012 03:17:06 +0100
> Sebastian Pipping <sping@g.o> wrote:
> > On 20.12.2012 19:14, Ciaran McCreesh wrote:
> > > The tree is a database. It belongs in /var/db/.
> >
> > I don't see /var/db in the latest release of the Filesystem Hierarchy
> > Standard:
> >
> >   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY
> >
> > I would prefer something that blends with FHS.
>
> That's ok, Gentoo doesn't follow FHS.
>
> --
> Ciaran McCreesh
>
> On Mon, Dec 24, 2012 at 4:08 AM, Ulrich Mueller <ulm@g.o> wrote:
> >>>>>> On Mon, 24 Dec 2012, Sebastian Pipping wrote:
> >
> >> On 20.12.2012 19:14, Ciaran McCreesh wrote:
> >>> The tree is a database. It belongs in /var/db/.
> >
> >> I don't see /var/db in the latest release of the Filesystem
> >> Hierarchy Standard:
> >
> >>   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY
> >
> > Wrong standard to choose from. ;-) /var/db/ is already required by the
> > PMS for /var/db/pkg/.
> >
> >> I would prefer something that blends with FHS.
> >
> > Is this important for a Gentoo specific directory?
> >
> >    /var/db/portage/         PORTDIR
> >    /var/db/layman/          layman storage
> >    /var/db/pkg/             VDB (no change)
> >    /usr/local/portage/      local overlays (no change)
> >    /var/cache/distfiles/    DISTDIR
> >    /var/cache/packages/     PKGDIR
> >
> > Alternatively, the last two could be under
> > /var/cache/portage/{distfiles,packages}/.
>
> Query that's been percolating in my mind...how much of this is
> specific to Gentoo, and how much has strong overlap with closely
> related distros like Sabayon and Funtoo?
>
> --
> :wq
>
> On 24/12/2012 10:08, Ulrich Mueller wrote:
> >    /var/cache/packages/     PKGDIR
>
> Maybe /var/spool/binpkgs ?
>
> --
> Diego Elio Pettenò — Flameeyes
> flameeyes@×××××××××.eu — http://blog.flameeyes.eu/
>
> On Mon, 24 Dec 2012 10:08:13 +0100
> Ulrich Mueller <ulm@g.o> wrote:
>
> > >>>>> On Mon, 24 Dec 2012, Sebastian Pipping wrote:
> >
> > > On 20.12.2012 19:14, Ciaran McCreesh wrote:
> > >> The tree is a database. It belongs in /var/db/.
> >
> > > I don't see /var/db in the latest release of the Filesystem
> > > Hierarchy Standard:
> >
> > >   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY
> >
> > Wrong standard to choose from. ;-) /var/db/ is already required by the
> > PMS for /var/db/pkg/.
>
> Incorrect. The PMS specifies vdb as being 'unspecified'. The fact that
> it provides a path there doesn't seem really relevant.
>
> --
> Best regards,
> Michał Górny
>
> >>>>> On Mon, 24 Dec 2012, Diego Elio Pettenň wrote:
>
> >> /var/cache/packages/ PKGDIR
>
> > Maybe /var/spool/binpkgs ?
>
> This doesn't look right to me. /var/spool contains things like printer
> queues or outgoing mail that are typically deleted after processing.
>
> Ulrich
>
> On Mon, Dec 24, 2012 at 8:32 AM, Ulrich Mueller <ulm@g.o> wrote:
> >>>>>> On Mon, 24 Dec 2012, Diego Elio Pettenň wrote:
> >
> >>> /var/cache/packages/ PKGDIR
> >
> >> Maybe /var/spool/binpkgs ?
> >
> > This doesn't look right to me. /var/spool contains things like printer
> > queues or outgoing mail that are typically deleted after processing.
>
> Then treat it like garbage collection. Some maintenance action could
> go through and remove the files which aren't fetch-restricted. Portage
> could do this at the end of its cycle, or it could be set up as a cron
> job, or it could require a manual maintenance step.
>
>
> --
> :wq
>
> Il 24/12/2012 10:11, Ciaran McCreesh ha scritto:
>
>> On Mon, 24 Dec 2012 03:17:06 +0100
>> Sebastian Pipping <sping@g.o> wrote:
>>
>>> On 20.12.2012 19:14, Ciaran McCreesh wrote:
>>>
>>>> The tree is a database. It belongs in /var/db/.
>>>>
>>> yes and no,
> yes it contain data and executable needed to update gentoo system, in a
> hierarchical and relational form
> no, it's a cache of a remote database generally mantained from others.
>
> Actually also the difference in importance between /var/db/pkg and
> /????/ebuild_tree is very high.
> Loose the pkg db and your best plan is to re-emerge the entire world,
> provided you still have a copy of /var/lib/portage/world (or equivalent),
> loose the latter and have a laugh.
> To put those in the same category seem risky
>
> Not that I personally care since everything gentoo related is kept in /g
> on my systems, also this for various reason mainly because it's something
> used to mantain a system and if maintainaince is not needed it's very easy
> this way to remove.
>
>  I don't see /var/db in the latest release of the Filesystem Hierarchy
>>> Standard:
>>>
>>>    http://www.pathname.com/fhs/**pub/fhs-2.3.html#**THEVARHIERARCHY<http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY>
>>>
>>> I would prefer something that blends with FHS.
>>>
>> That's ok, Gentoo doesn't follow FHS.
>>
>>  And it's ok to "prefere" to stay near a standard and use it as a
> guideline, for various reason, less difference with others and because a
> bunch of people has already toughted on it, to name just two.
> Raising to "MUST blend" would be indeed not beneficial.
>
> Regards,
> Francesco Riosa
>
> >>>>> On Mon, 24 Dec 2012, Diego Elio Pettenň wrote:
>
> > On 24/12/2012 14:32, Ulrich Mueller wrote:
> >> This doesn't look right to me. /var/spool contains things like
> >> printer queues or outgoing mail that are typically deleted after
> >> processing.
>
> > Not sure how /var/cache fits for binpkgs though, tbh.
>
> Why not? Because they are distributed to other systems?
>
> /var/lib then? (Though FHS acolytes would probably put them in /srv ...)
>
> Ulrich
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/24/2012 04:08 AM, Ulrich Mueller wrote:
> >>>>>> On Mon, 24 Dec 2012, Sebastian Pipping wrote:
> >
> >> On 20.12.2012 19:14, Ciaran McCreesh wrote:
> >>> The tree is a database. It belongs in /var/db/.
> >
> >> I don't see /var/db in the latest release of the Filesystem
> >> Hierarchy Standard:
> >
> >>   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY
> >
> > Wrong standard to choose from. ;-) /var/db/ is already required by the
> > PMS for /var/db/pkg/.
> >
> >> I would prefer something that blends with FHS.
> >
> > Is this important for a Gentoo specific directory?
> >
> >    /var/db/portage/         PORTDIR
> >    /var/db/layman/          layman storage
> >    /var/db/pkg/             VDB (no change)
> >    /usr/local/portage/      local overlays (no change)
> >    /var/cache/distfiles/    DISTDIR
> >    /var/cache/packages/     PKGDIR
> >
> > Alternatively, the last two could be under
> > /var/cache/portage/{distfiles,packages}/.
> >
> I am not 100% on this, but I think this is my first +1 for this thread.
>
> +1
>
> I really like this layout, it almost makes sense.
> I won't be bike shedding on this topic (really don't care that much),
> but I do really like this layout.
>
> - -ZC
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJQ2H3/AAoJEKXdFCfdEflKJMwQALbugkzciQpw3KTr32Dwl2p2
> TFMRClKv4W006SXjbxLciQg+hLDMPBOIjbCl5UtpWcFSsCWWUXGBJIX7A6m7TZ6N
> lj4VGjEDBjCKzkp3XypoRXL1XIiuqQpxv3FAqpFbhLczXRP+oQoP3ZmdbDZF4Dky
> oJf/Pttl4bD8CA6cWZ6tXDvnrZ2w4cJYm/AnuOaCahSM/3MqscWq884lnucbT6Xs
> IBa6DhNV/iqAXTQ5v/54p6izl6EbV/UJEzFjSVOsPAgmCwVjsc1ZFkZi2BAlt8iv
> f+8j0SGHRrUXk22nOIe1bwdg7CTpn0cjrYPTjG+sWcx+tEgNzF7xkLLWgeSj4+jL
> kY7KXvfsmVyamAybySGJNWIjv8n97YkJTy8bT7caIoCB8h0oJvrC2eNRJFISuEjv
> DpKvql1nNyJJ1/k2aUoBLiUjLpSIGeZ0607W4woTM0mrEo8RGvXGV87y8Y4jGML1
> 2ks87XcEb/jBPVxCodITwWyB9/aqzC4K0K5rLj5xqIDdeoxb2A8HVefbUEY2mcD/
> cFXTl7hnX9KdNl4+VrNSVvNNVR+pZIZz8lT8wiu4wqVwm+CjaY+YPMuGy3ps2cmo
> Pq3/HbSSQwhP6bEZfZ5md8dZ2p2LSW9xJzhbxmuFCUrLxDAbZTsjDKeJy0q3aHNG
> Xi+Z+m8PqCDotRD63PWR
> =lGRB
> -----END PGP SIGNATURE-----
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/24/2012 09:00 AM, Diego Elio Pettenò wrote:
> > On 24/12/2012 14:32, Ulrich Mueller wrote:
> >> This doesn't look right to me. /var/spool contains things like printer
> >> queues or outgoing mail that are typically deleted after processing.
> >
> > Not sure how /var/cache fits for binpkgs though, tbh.
> >
> "Application cache data. Such data are locally generated as a result of
> time-consuming I/O or calculation. The application must be able to
> regenerate or restore the data. The cached files can be deleted without
> loss of data."
>
> No sure how it doesn't...
>
> Binpackages are really essentially cache created by portage through
> time-consuming I/O and calculation (compiling) and can easily be
> regenerated locally.  Plus, you can delete all of this and the system is
> still functional.
>
> - -ZC
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJQ2H5HAAoJEKXdFCfdEflKoPEP/14QYZIF/mbquRFkiCnp5KCN
> s11qw4He6yEsgnjvMKA1CCWZ0R85G/wfVnj0DpcK83zXrP9Znbrk4Yatue/7KXaZ
> I/sDg5Woo1FT6Mb9EY7hgpawIS25+6xA3eRsPKIlPzBG+i43ZTM4JhDLJeTs1VSH
> APhkH0EXiA0H8ngCTgP9ReDXoi8KqPbMYGe/t3NVL4KalPdkDsjHeqfUG95C660f
> TM34UvOGBA4HpySmH+FRdsUxV+9tJtdOZFjSm/oQX5IZrzLQA5lOSHe6t8sQJnsk
> /b6TYncolfVpUED6y/8072S4GL+mEucf8NFIyMClpDymfILS7zFR0hEawm+UrLjm
> O2/0ivPHQQA/P4uwTDQzJ1KqHZAgN0lDgbSZYZ5290whypSyJoGIKfVIvSI/qjFR
> JOy5pCMkY9oClOqZB6s32WowKCzPipT7MPvBgotPuBoHaaMJOeW53FJadi/VEyGc
> qL6Uv6jn0WKJJpGrONm7LwXnYB8kVzOmqVLpGEIO1mqEX9QL71qsq/Fw1pAyqqB5
> NSq1dDbKye9C7nH1xSmhzgGFTs3V+IHKAV2iwjeElhZJF/Iv2+nj/6gONpNI7279
> x1Zbi7i3JM1z4EMSaV+Nt60endPeB4KnDFoPXlRLZTlyR2qcLVNVr+qAIWG3m+mM
> QqQCREx2n/KV/hFUUh5U
> =7lrq
> -----END PGP SIGNATURE-----
>
> On 24/12/2012 16:43, Ulrich Mueller wrote:
> > Why not? Because they are distributed to other systems?
>
> More because they can be used as a backup themselves, if I want to keep
> older versions available.
>
> > /var/lib then?
>
> Fine by me.
>
> > (Though FHS acolytes would probably put them in /srv ...)
>
> Let's not get on with /srv right now please.
>
> --
> Diego Elio Pettenò — Flameeyes
> flameeyes@×××××××××.eu — http://blog.flameeyes.eu/
>
> On Friday 14 December 2012 05:43:41 Fabian Groffen wrote:
> > gen_usr_ldscript() vs --libdir=/lib.  Questions on why, and if it makes
> > sense to remove gen_usr_ldscript in favour of --libdir.  WilliamH will
> > open a discussion on gentoo-dev ML.
>
> these are orthogonal issues.  not every package using gen_usr_ldscript has
> a
> --libdir option, and even the ones that do commonly install more than one
> library but we really only want to move one.  plus with static libs,
> --libdir
> will install those into the wrong place.
>
> so for most packages, the choice is either:
>         src_configure() { econf ; }
>         src_install() { default ; gen_usr_ldscript -a bar ; }
> or:
>         src_configure() { econf --libdir=/lib ; }
>         src_install() {
>                 default
>                 dodir /usr/$(get_libdir)
>                 mv "${ED}"/$(get_libdir)/lib{f,x}*
> "${ED}"/usr/$(get_libdir)/ || die
>                 if use static-libs ; then
>                         mv "${ED}"/$(get_libdir)/*.{a,la} \
>                                 "${ED}"/usr/$(get_libdir)/ || die
>                 fi
>         }
>
> the only time --libdir=/lib makes sense to use is when the path itself then
> gets used for things other than just the installation of libraries and
> there's
> no knob to control those other things.  like rules.d files.
>
> i.e. saying "we should get rid of gen_usr_ldscript and use --libdir=/lib"
> makes absolutely no sense.  it's just begging for people to screw things up
> constantly and waste developer time for 0 gain.
> -mike
>
> On 24/12/2012 20:08, Mike Frysinger wrote:
> > i.e. saying "we should get rid of gen_usr_ldscript and use --libdir=/lib"
> > makes absolutely no sense.  it's just begging for people to screw things
> up
> > constantly and waste developer time for 0 gain.
>
> Amen.
>
> --
> Diego Elio Pettenò — Flameeyes
> flameeyes@×××××××××.eu — http://blog.flameeyes.eu/
>
>
> Am 24.12.2012 17:09, schrieb Rick "Zero_Chaos" Farina:
> > On 12/24/2012 09:00 AM, Diego Elio Pettenò wrote:
> >> On 24/12/2012 14:32, Ulrich Mueller wrote:
> >>> This doesn't look right to me. /var/spool contains things like printer
> >>> queues or outgoing mail that are typically deleted after processing.
> >
> >> Not sure how /var/cache fits for binpkgs though, tbh.
> >
> > "Application cache data. Such data are locally generated as a result of
> > time-consuming I/O or calculation. The application must be able to
> > regenerate or restore the data. The cached files can be deleted without
> > loss of data."
> >
> > No sure how it doesn't...
> >
> > Binpackages are really essentially cache created by portage through
> > time-consuming I/O and calculation (compiling) and can easily be
> > regenerated locally.  Plus, you can delete all of this and the system is
> > still functional.
>
> Not that I am opposed to keep binpackages in /var/cache - but people on
> this thread have brought up lot's of reasons why for certain aspects not
> to keep certain data in certain places.
> This just hit my mind: can binpackages easily be regenerated locally if
> their ebuilds are not in portage anymore?
> I mean they can: grab the ebuild, compile it with the ebuild command,
> there you go, but isn't that also true for the whole portage tree?
>
> Michael Hampicke posted on Tue, 25 Dec 2012 10:09:15 +0100 as excerpted:
>
> > Am 24.12.2012 17:09, schrieb Rick "Zero_Chaos" Farina:
> >> On 12/24/2012 09:00 AM, Diego Elio Pettenò wrote:
>
> >>> Not sure how /var/cache fits for binpkgs though, tbh.
> >>
> >> No sure how it doesn't...
> >>
> >> Binpackages are really essentially cache created by portage through
> >> time-consuming I/O and calculation (compiling) and can easily be
> >> regenerated locally.  Plus, you can delete all of this and the system
> >> is still functional.
> >
> > Not that I am opposed to keep binpackages in /var/cache - but people on
> > this thread have brought up lot's of reasons why for certain aspects not
> > to keep certain data in certain places.
>
> Also, consider what happens if gcc or the like breaks.  Normally those
> with FEATURES=binpkg can still revert to their last known working binpkg,
> and this has long been listed as one of the reasons people should
> consider enabling binpkgs.  But if it's gone due to "cache cleanup" and
> gcc is broken...
>
> A system reinstall from binpkgs sure speeds things up if you fatfinger an
> rm --recursive or some such, as well.  Basically, you're installing a
> custom bindistro in that case, making PKGDIR more a binpkg repository
> than a simple cache of individual packages.  It is for this reason I keep
> my binpkgs on a dedicated partition, and back it up, something I do NOT
> do with the gentoo ebuild tree, the kernel tree, or ccache, which to me
> ARE caches, while my binpkg dir isn't.
>
> But I set the vars myself so what the defaults are isn't a big deal, here.
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
> >>>>> On Mon, 24 Dec 2012, Diego Elio Pettenň wrote:
>
> > On 24/12/2012 16:43, Ulrich Mueller wrote:
> >> Why not? Because they are distributed to other systems?
>
> > More because they can be used as a backup themselves, if I want to
> > keep older versions available.
>
> This is a valid argument, of course.
>
> >> /var/lib then?
>
> > Fine by me.
>
> >> (Though FHS acolytes would probably put them in /srv ...)
>
> Insert a smiley of your choice here. ;-)
>
> > Let's not get on with /srv right now please.
>
> Ulrich
>
> Michael Hampicke wrote:
> > can binpackages easily be regenerated locally if their ebuilds are
> > not in portage anymore?
>
> If the package is still installed it is very easy with quickpkg.
>
>
> //Peter
>
> Let's discuss the "specific guideline" for Perl modules. It's as follows:
>
> ,-
> http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect2
> | Perl
> |
> | New Perl modules are to be added to portage only when one of the
> following
> | conditions is met:
> |
> | a) The module(s) fulfill a dependency
> | b) The module(s) cannot be handled by g-cpan
> | c) The module(s) add functionality to existing ebuilds
> | d) The module(s) provide tools, applications or other features (i.e. more
> |    than what their .PM offers)
> |
> | Please make sure that at least one member of the perl herders approves
> | your addition.
> `-
>
> Recently the proxy-maintainer project is repeatedly adding packages
> which aren't following these guideline AFAIK. So maybe we should change
> it.
>
> 444974 a) dev-perl/Text-Format - Various subroutines to format text
> 2012-12-07
> 444976 a) dev-perl/Roman - Perl module for conversion between Roman and
> Arabic numerals.        2012-12-03
> 446710 ?) dev-perl/FLV-AudioExtractor - Extract audio from Flash Videos
> 2012-12-12
> 447724 ?) dev-perl/Email-Send-Gmail - Send Messages using Gmail Mon 10:12
>
> Ad a): This requirement is a little problematic:
> Sometimes perl modules are needed for maintainer-wanted packages.
> Sometimes the perl modules are added to the tree while the
> maintainer-wanted package never are or will be. Sometimes the maintainer
> are waiting for the perl team to do their work.
>
> Ad b): (Judging from bugreports) g-cpan doesn't seem to be really
> reliable these days. I always wanted to test/verify it. But ... (random
> excuse: time, motivation,...)
>
> I guess I don't have no problem with modifying or dropping the
> requirements. The perl overlay contains hundreds of packages which
> should be added to the main tree.
>
> The dev-perl category currently already contains the most packages
> (1140 per packages.g.o).
>
> --
> Best regards
> Torsten
>
> El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió:
> > All:
> >
> > The following packages in the tools-portage herd are effectively
> > unmaintained packages and need a maintainer to step up and maintain them.
> >
> > app-portage/deltup
> > app-portage/epm
> > app-portage/maintainer-helper
> > app-portage/splat
> > app-portage/ufed
> >
> > If no one steps up in the next 30 days, I will be moving them out of the
> > herd and to maintainer-needed and they will be candidates for the
> > treecleaners.
> >
> > Regards,
> > Paul Varner
> > tools-portage lead
> >
> >
>
> What did occur finally with them?
>
> On Tue, 2012-12-25 at 15:09 +0100, Pacho Ramos wrote:
> > El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió:
> > > All:
> > >
> > > The following packages in the tools-portage herd are effectively
> > > unmaintained packages and need a maintainer to step up and maintain
> them.
> > >
> > > app-portage/deltup
>
> homepqge link is broken.  the SF link in the ebuild is a rediredirect to
> www.deltup.org which is a dead link.  The SF page files releases doesn't
> list the 0.4.4 that we have in tree. It stops at 0.4.3
>
> hmm.  I just emerged it,  seems slyfox is maintaining it's dep of
> dev-util/bdelta which has had a release just this last June.  But it's
> homepage link is the same dead deltup.org one.  It is from the same
> author.  The SF deltup pages only have files releases up to 0.1.0 (dated
> 2006) for bdelta.
>
>
> > > app-portage/epm
>
> Nothing
>
> > > app-portage/maintainer-helper
>
> I looked at it, installed it, but had to fix a small bug just to get it
> to run.  Outside of that I heard from no-one about it.  For me, it would
> be easier to add the few capabilities that were actually coded to
> porthole than to learn the code and pyQT to develop it, since the data
> it provided and displayed, porthole already displays and more.
>
> IMHO  tree-clean it
>
> > > app-portage/splat
>
> it's perl :(, I don't do perl.  The homepage link is dead.  Only the
> base net address is alive and is just a resume for the author. I heard
> nothing.
>
>
> > > app-portage/ufed
>
> Several users provided some patches to update it for the make.conf and
> profiles changes.  It has been updated in tree.
>
> > >
> > > If no one steps up in the next 30 days, I will be moving them out of
> the
> > > herd and to maintainer-needed and they will be candidates for the
> > > treecleaners.
> > >
> > > Regards,
> > > Paul Varner
> > > tools-portage lead
> > >
> > >
> >
> > What did occur finally with them?
>
> --
> Brian Dolbec <dolsen@g.o>
>
> 25.12.2012 18:30, Mike Gilbert wrote:
> > On Tue, Dec 25, 2012 at 7:09 AM, Torsten Veller <tove@g.o> wrote:
> >> Let's discuss the "specific guideline" for Perl modules. It's as
> follows:
> >>
> >> ,-
> http://devrel.gentoo.org/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect2
> >> | Perl
> >> |
> >> | New Perl modules are to be added to portage only when one of the
> following
> >> | conditions is met:
> >> |
> >> | a) The module(s) fulfill a dependency
> >> | b) The module(s) cannot be handled by g-cpan
> >> | c) The module(s) add functionality to existing ebuilds
> >> | d) The module(s) provide tools, applications or other features (i.e.
> more
> >> |    than what their .PM offers)
> >> |
> >> | Please make sure that at least one member of the perl herders approves
> >> | your addition.
> >> `-
> >>
> >> Recently the proxy-maintainer project is repeatedly adding packages
> >> which aren't following these guideline AFAIK. So maybe we should change
> >> it.
> >>
> >> 444974 a) dev-perl/Text-Format - Various subroutines to format text
> 2012-12-07
> >> 444976 a) dev-perl/Roman - Perl module for conversion between Roman and
> Arabic numerals.        2012-12-03
> >> 446710 ?) dev-perl/FLV-AudioExtractor - Extract audio from Flash Videos
> 2012-12-12
> >> 447724 ?) dev-perl/Email-Send-Gmail - Send Messages using Gmail Mon
> 10:12
> >>
> >> Ad a): This requirement is a little problematic:
> >> Sometimes perl modules are needed for maintainer-wanted packages.
> >> Sometimes the perl modules are added to the tree while the
> >> maintainer-wanted package never are or will be. Sometimes the maintainer
> >> are waiting for the perl team to do their work.
> >>
> >> Ad b): (Judging from bugreports) g-cpan doesn't seem to be really
> >> reliable these days. I always wanted to test/verify it. But ... (random
> >> excuse: time, motivation,...)
> >>
> >> I guess I don't have no problem with modifying or dropping the
> >> requirements. The perl overlay contains hundreds of packages which
> >> should be added to the main tree.
> >>
> >> The dev-perl category currently already contains the most packages
> >> (1140 per packages.g.o).
> >>
> >> --
> >> Best regards
> >> Torsten
> >>
> >
> > I'm sure I skimmed that section of the handbook at some point for the
> > quizzes, but I don't remember it. I think it is possible that the
> > proxy commiter (pinkbyte) forgot about it too.
>
> No, i do not, i have read this guideline, and yes - it is not mentioned
> directly in Handbook or Devmanual.
> Some of these modules was added cause they are dependencies for other
> packages(which are still waiting for adding in tree, cause they have no
> maintainer yet), others - cause g-cpan generate very ugly ebuilds for them.
>
> > I think that all of those requirements make sense. We might want to
> > formalize a similar guideline for the python herd.
> >
> > Perhaps the requirements list could be copied somewhere more visible?
> > The perl project page might get more traffic for people looking to
> > write perl ebuilds.
> >
>
> Truly, i do not really understand such hard policy for NOT including
> perl modules in tree. I know that perl herd is understaffed, but i do
> not think that this is generally a problem, cause they do not maintain
> recently added packages, but proxy maintainers do.
>
> So, basically, yes, i vote for easing policy a bit.
>
> P.S. CCing maintainer of modules, that i have commited as a proxy, maybe
> he also wants to say something regarding this.
>
> --
> Best regards, Sergey Popov
> Gentoo Linux Developer
> Desktop-effects project lead
>
>
> 23.12.2012 22:49, Robin H. Johnson пишет:
> > torrents.gentoo.org has been down for a few months now, and there have
> > been very few comments about it. Up until a few years ago, it was still
> > quite useful, but I believe that we have sufficient bandwidth and
> > mirror-coverage around the world that it's become a moot point.
> >
> > (snip)
> >
> > If we need torrents in future, we should use public trackers, as there
> > is no further need to run our own BitTorrent tracker. The .torrent
> > files themselves should live on our own mirrors, with GPG signatures to
> > prove authenticity (we actually only need to sign the infohash value).
>
> Personally i have agreed with this point of view. Our own torrent
> service is unneeded anymore - we do not lose anything important if we
> use public trackers for this
>
> --
> Best regards, Sergey Popov
> Gentoo Linux Developer
> Desktop-effects project lead
>
>
> The current default mta in gentoo - ssmtp - has a more or less dead
> upstream and has some outstanding bugs.  It is prudent to change our
> default mta.
>
> Both mail-mta/nullmailer and mail-mta/msmtp are lightweight good mtas.
> Both packages have active development and provide AUTH and SSL/TLS
> support.
>
> Our current mta list is:
>         mail-mta/ssmtp
>         mail-mta/courier
>         rest of the list
>         ...
>
> As net-mail herd, we would like to have the following mta list:
>         mail-mta/nullmailer
>         mail-mta/msmtp
>         mail-mta/ssmtp
>         rest of the list
>         ...
>
> If there are no objections, the above change will be committed in ~10
> days.
>
> --
> Eray Aslan <eras@g.o>
>
> On Wednesday, December 26, 2012 09:46:17 AM Eray Aslan wrote:
> > The current default mta in gentoo - ssmtp - has a more or less dead
> > upstream and has some outstanding bugs.  It is prudent to change our
> > default mta.
> >
> > Both mail-mta/nullmailer and mail-mta/msmtp are lightweight good mtas.
> > Both packages have active development and provide AUTH and SSL/TLS
> > support.
> >
> > Our current mta list is:
> >         mail-mta/ssmtp
> >         mail-mta/courier
> >         rest of the list
> >         ...
> >
> > As net-mail herd, we would like to have the following mta list:
> >         mail-mta/nullmailer
> >         mail-mta/msmtp
> >         mail-mta/ssmtp
> >         rest of the list
> >         ...
> >
> > If there are no objections, the above change will be committed in ~10
> > days.
> >
> >
>
> Would it be prudent to coordinate Gentoo documentation changes with the
> above?
>
> --
> Mike Pagano
> Gentoo Developer - Kernel Project
> Team Lead - Gentoo Sources
> E-Mail     : mpagano@g.o
> GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
> Public Key :
> http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
>
> On Wed, Dec 26, 2012 at 06:42:36AM -0500, Mike Pagano wrote:
> > Would it be prudent to coordinate Gentoo documentation changes with the
> above?
>
> Ugh, I wasn't aware of any documentation that needs to be changed and a
> quick look/search did not turn out anything.  But if there are any,
> sure, I will open the bugs and have it block the move.
>
> --
> Eray Aslan <eras@g.o>
>
> Eray Aslan posted on Wed, 26 Dec 2012 09:46:17 +0000 as excerpted:
>
> > The current default mta in gentoo - ssmtp - has a more or less dead
> > upstream and has some outstanding bugs.  It is prudent to change our
> > default mta.
> >
> > Both mail-mta/nullmailer and mail-mta/msmtp are lightweight good mtas.
> > Both packages have active development and provide AUTH and SSL/TLS
> > support.
>
> I've wondered about this for some time, and now seems as good a time/
> place to ask as any.
>
> Is there any "system-mailer" app that doesn't actually mail anything
> anywhere, nor run  constantly as a daemon, that is simply invokable as
> sendmail when needed, to take a message, format it appropriately, and
> drop it in some local dir (preferably configurably as maildir, mh-format,
> mbox, etc) where a mail client can read it as a local account?  No need
> to run constantly or to have actual network connectivity of any sort,
> just to be invokable when needed.
>
> I ended up creating a script that handles it here, but it'd be great if I
> could find a proper package that handled that, presumably with a few more
> features than the hacked up script I came up with.
>
> Seems to me if there is such a thing, that'd be a great option to be
> recommended in the handbook, for those who don't want to send the mail
> off to the ISP/MSP (to be examined by crackers, three-letter agencies, or
> simply rogue admins at the ISP/MSP), just to pick it up with their mail
> client running on the same machine that sent it in the first place!
>
> --
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master."  Richard Stallman
>
>
> On Dec 26, 2012 8:46 AM, "Eray Aslan" <eras@g.o> wrote:
> >
> > On Wed, Dec 26, 2012 at 06:42:36AM -0500, Mike Pagano wrote:
> > > Would it be prudent to coordinate Gentoo documentation changes with
> the above?
> >
> > Ugh, I wasn't aware of any documentation that needs to be changed and a
> > quick look/search did not turn out anything.  But if there are any,
> > sure, I will open the bugs and have it block the move.
>
> Seems like a good time to add this to the handbook alongside syslog and
> cron, at least for one of the simple solutions. I wouldn't consider it a
> blocker though.
>
> Rich
>
> On 19/12/2012 10:03 p.m., Michał Górny wrote:
>
>> Doesn't this prove that the recruitment process fails to work?
>>
>> If I were to throw random ideas, I'd think about letting new recruits
>> did all commits through a proxy (mentor?). Of course, it all would be
>> easier if we used git.
>>
>>
> I know this side question of "git" migration is one we want to avoid
> discussing, I know its in progress.
>
> But I am literally waiting for it to happen, because for whatever reason,
> the present barriers to contribution are too high for me without it.
>
> I can't put an exact finger on it, but devs seem to think the quiz
> methodology is "easy", but it ( oh, and CVS ) are a high barrier to entry
> for me.
>
> I don't have the time/motivation/focus required to commit to even
> completing the quizzes, and I don't have the time/motivation/focus really
> required to be a "full dev", and I don't even want to be a "Full dev"
> really.
>
> But I basically have found every time I've done the quiz, its eventually
> boiled down to a cycle of
>
> 1. Read quiz
> 2. Find it hard to find documentation on
> 3. Search for
> 4. Get lost
> 5. Find the resulting information I eventually find is vague and confusing
> with regard to the question.
> 6. Eventually get distracted and do something other than the rest of the
> quiz.
>
> I know, it should be easy, and I'm probably making excuses, but it boils
> down to
>
> 1. People in Gentoo have asked me to/encouraged me to do the quizzes
> 2. I've tried several times
> 3. Still not there.
> 4. This problem is not so prevalent in the dozens of other projects I've
> contributed to.
>
> As soon as Git migration is done, then I can just
>
> 1. Fork
> 2. Hack
> 3. Somebody can watch/review/cherry-pick commits I make if they like them,
> if not, I'm not worried.
>
> But the git part aside, back to the quiz.
>
> Surely, I'm not the /only/ person to get roadblocked by the quiz.
>
> The only thing really keeping me around as a half-assed dev is the fact we
> have overlays and the fact that the overlays are git based, and I get
> /some/ notion of contributions being of value there.
>
> Can we short cut the whole quiz process and have some "Inbound" repository
> until we're full git, which people can fork/commit/pull and trusted people
> can review submitted branches and apply them to CVS?
>
> Because I feel its quite possible partly that CVS is due to blame ( due to
> requiring of trusted commit, which requires the questions ) that there is
> difficulty getting devs, and the longer we're stuck with it, the more it
> will be a problem.
>
> It could actually be just the Proxy Maintainer workflow is not clear
> enough, or simple enough, and that we need more push towards a more heavy
> proxy-maintainer based system ( I don't know, I'm ignorant to too much of
> proxy-maintainer-ship stuff,  to discern /why/ that is might be difficult,
> but I'd imagine my ignorance is part of the problem )
>
> Good afternoon,
>
> In less than two weeks, on Tuesday January the 8th, the council will meet
> again.
> Now is the time to prepare & raise items that you feel should be put to a
> vote.
>
> Please reply to this e-mail with any suggested agenda items. Even if you
> have raised
> the issue on a mailing list before, please repeat it now to avoid it being
> missed.
>
> Regards,
> Tony V.
>
> On 12/25/12 12:03, Sven Eden wrote:
> > Hi all,
> >
> > what has happened to app-portage/ufed? I could take care of it. I am
> > no official dev, but maybe via a proxy maintainership? Would that be
> > possible?
>
> Yes, I'm willing to proxy maintain app-portage/ufed.  The sources are
> available from overlays.gentoo.org. See
> http://git.overlays.gentoo.org/gitweb/?p=proj/ufed.git;a=summary.
> Initially, you would need to send me patches or point me to your copy of
> the project to pull from.  However, once I'm comfortable with your work,
> I can grant direct access to the project for pushing commits.
>
> If you do want to proxy maintain it, please send me in private email,
> the email address that you use in Gentoo's bugzilla, so I can update the
> metadata.xml file appropriately.
>
> Regards,
> Paul
>
>
>
>
> On Dec 25, 2012 8:33 PM, "Pacho Ramos" <pacho@g.o> wrote:
> >
> >
> > # Pacho Ramos <pacho@g.o> (25 Dec 2012)
> > # Fails to build with libav-9 (#443238). Removal in a month.
> > media-libs/libdlna
> > media-video/ushare
> >
> This is not a valid reason to remove it. I use it every day. Please remove
> the masking. You should have contacted me first as I think I am on metadata
> (haven't checked yet)
>
>