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