Re: [gentoo-dev] Is /var/cache the right place for repositories?
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
Re: [gentoo-dev] Is /var/cache the right place for repositories?
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
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-12-23 23h59 UTC
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-lemon2012-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_Freeze2012-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-lemon2012-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/echievements2012-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-blogique2012-12-22 15:47:39 maksbotan dev-util/open-vcdiff2012-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 : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-sound/leechcraft-muziczombie,removed,maksbotan,2012-12-18 17:31:53 media-sound/leechcraft-muziczombie,removed,maksbotan,2012-12-18 18:05:32 media-sound/leechcraft-lemon,removed,maksbotan,2012-12-20 13:59:21 Added Packages: sec-policy/selinux-openrc,added,swift,2012-12-17 08:48:02 net-analyzer/nagios-check_pidfile,added,hollow,2012-12-17 09:15:23 dev-ruby/nagios,added,hollow,2012-12-17 09:31:34 app-crypt/cryptkeeper,added,hwoarang,2012-12-17 19:31:21 dev-python/charade,added,radhermit,2012-12-17 19:48:55 games-rpg/penumbra-collection,added,hasufell,2012-12-17 21:42:41 dev-python/cx_Freeze,added,pinkbyte,2012-12-18 07:39:33 media-sound/leechcraft-touchstreams,added,maksbotan,2012-12-18 13:17:56 media-sound/leechcraft-muziczombie,added,maksbotan,2012-12-18 13:22:34 media-sound/leechcraft-lemon,added,maksbotan,2012-12-18 13:23:19 media-sound/leechcraft-muziczombie,added,maksbotan,2012-12-18 17:39:50 media-sound/leechcraft-musiczombie,added,maksbotan,2012-12-18 18:52:18 x11-terms/terminology,added,sera,2012-12-19 16:35:13 x11-libs/pangox-compat,added,tetromino,2012-12-19 16:38:43 dev-python/keyring,added,prometheanfire,2012-12-19 20:47:59 net-misc/leechcraft-lemon,added,maksbotan,2012-12-20 13:54:38 x11-misc/kbdd,added,qnikst,2012-12-21 10:19:36 dev-games/etrophy,added,tommy,2012-12-21 14:42:02 x11-plugins/echievements,added,tommy,2012-12-21 14:45:29 media-libs/ethumb,added,tommy,2012-12-21 20:48:30 app-benchmarks/expedite,added,tommy,2012-12-21 21:08:52 virtual/pyparsing,added,mgorny,2012-12-21 21:58:01 dev-python/wsgilog,added,hwoarang,2012-12-22 11:56:52 x11-plugins/leechcraft-lhtr,added,maksbotan,2012-12-22 15:28:04 virtual/leechcraft-wysiwyg-editor,added,maksbotan,2012-12-22 15:31:26 net-misc/leechcraft-blogique,added,maksbotan,2012-12-22 15:47:39 dev-util/open-vcdiff,added,floppym,2012-12-22 18:28:38 dev-cpp/gtkmm-utils,added,hwoarang,2012-12-23 09:46:25 app-text/referencer,added,hwoarang,2012-12-23 09:53:09 dev-lang/rebol,added,patrick,2012-12-23 10:54:42 dev-lang/rebol-bin,added,patrick,2012-12-23 10:55:09 net-libs/libzapojit,adde
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El lun, 24-12-2012 a las 00:17 +0100, Diego Elio Pettenò escribió: > 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? > I want to have a permanent reference of current elog messages simply showing configuration tips to: 1. Show them via elog messages only first time package is installed 2. Not need to read ebuild directly once people remove summary.log signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
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 flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
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 +, 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
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 +, 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
[gentoo-dev] Proposed removal of service: torrents.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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote: > On Sun, 2012-12-23 at 12:20 +, 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 23 December 2012 13:58, Alexandre Rostovtsev wrote: > On Sun, 2012-12-23 at 12:20 +, 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
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On Sun, 2012-12-23 at 12:20 +, 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.
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 23 December 2012 09:57, Pacho Ramos 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 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
Re: [gentoo-dev] Time based retirements
On Sun, Dec 23, 2012 at 4:39 AM, Markos Chandras wrote: > On 12/23/2012 02:06 AM, Doug Goldstein wrote: >> On Fri, Dec 21, 2012 at 7:05 PM, Markos Chandras >> 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
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
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 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 22-12-2012 a las 21:46 +, Markos Chandras escribió: > On 22 December 2012 09:26, Pacho Ramos 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? No, only to drop its usage for configuration stuff (like that kind of message telling you to go to page to know how to configure your app) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Time based retirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/23/2012 02:06 AM, Doug Goldstein wrote: > On Fri, Dec 21, 2012 at 7:05 PM, Markos Chandras > 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... > > IMHO, if you're really after finding others to take care of > packages that appear abandoned then you should contact the inactive > people to see if there's any packages they'd be ok with giving up > to the proxy-maintainers project or to another developer, but don't > retire them. We working on such a policy. > If the goal here really is to ensure well maintained packages then > retiring people is akin to treating a screw like a nail and banging > it in with a hammer, wrong tool... wrong job. For some packages you > may find another developer right away with interest to fix it, or a > proxy maintainer but in some cases you might have just kicked the > only person who had any inclination to fix the package. Some > packages have 50 users and 49 of them are Gentoo developers or > would step up and become Gentoo developers to fix the package > should it become unmaintained and that's great. But some packages > have 200 users and 1 person willing to be the developer to maintain > it. You retire that person and you might have well just told those > 200 people to pick a different distro because inevitably their > package will be treecleaned. > *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" > 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@ > > Regarding my use of the words "brain dead", notice I never said > "Markos is brain dead". What I said was the policy of retiring > people when what you really want is an active maintainer of > packages is brain dead. Now I understand that you're involved with > the enforcement of that policy and therefore identify with it, but > I would have to encourage you to separate yourself from a policy. I > unfortunately feel after reading all the comments in this whole > thread that my original statement is still true. Like I said we are working on a "less brain-dead" policy so I have nothing else to contribute to this thread - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJQ1tFWAAoJEPqDWhW0r/LCUD8P/RRTW8hseUTLn3wxJ8VD6u5y 9FlRJk9ddg4fFxRVdWwUsMXUxUgL83OdXZ/VTfZnubb2Qon5gnuJkjzYLiL7r8Lq Mig/xTb62xIot6hmr8oKmwX3dDxyN+awwb165GWLoZBM3QbK6Q9yC6OB35pE3fiz dAx35ANhmjZQRO6ivI6TPjtsp3pTXsL5tDZrWfwLGjnZE9D4XxSxMQAqHC99RVAz FN/4Vl2NbJpTUsWNtPi3T6+lakiKCdYP0aFS2Vx9qglMLsPtu3bza3yOxMGGaiLe AXnM553IzENSihRH4a2WT7hNrvfX9GRllZ2FUSWm8CmBcMc8KQbKS8ENeXM2ZFhE bAN/4zZdWcAih+NTLV6j05fDXCFceUzjHdmcY83Z8S0y1ZT3mUliS9ygCNHQ66Zr 1Pxe/vRX4OVZbayb9URsUJ1bsPS1mM1cl81iMSynfWp8OQGX6HtMz3MhSRFiioRm 9RfsTcInEgdP0mhgsTD91quL8VlTYVHp42EnVVDudOFEBPuFiBJHxMKpi2NWAydb vu7+nWAJOR2ODPQDBULnocJTApXhj+2oW7dqnqUwfbSu1HVIUDMASwBTILDrK1c4 A+XqwRjXnixSZE0v9CW8tDDAx5SuCqaocZnqkGIIgzTFGfDTkO4UJE2HGf1E+kXD YpmY1+aTPd7JWiWT30wK =j85U -END PGP SIGNATURE-
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17 December 2012 18:55, Tomáš Chvátal wrote: > 2012/12/17 Ben de Groot : > > Please don't. For most users this is a waste of resources. > > > On first look it seems like waste of resources. > On second hand it makes stuff easy wrt bugreports provided by users. > And believe me when I say most upstreams are pissed by gentoo reports > because they lack any good debuginfo features, nor they know how to > tell users how to make their systems contain debug informations. I > have seen quite few upstreams rejecting all by Gentoo reported issues > because of this, plus they were quite suprised that I actually can > generate any sane debug informations with it. > > I still think it is a bad idea to enable something that is not necessary for most users by default. For your purposes it should be enough to update our existing documentation about debugging, and link to it from the handbook. Let the user make an informed choice by himself. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
