[gentoo-dev] Re: RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
Samuli Suominen posted on Tue, 26 Apr 2011 21:56:06 +0300 as excerpted: You have 24 hours to comment on this news item. Sorry to put it so bluntly but this is required for major security bug (#364973). See attachment. Title: Upgrade to GLIB 2.28 Author: GNOME Team gn...@gentoo.org Content-Type: text/plain Posted: 2011-04-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-libs/glib-2.28 The way of setting default URI handlers has changed since dev-libs/glib-2.28 and above. If you used the GConf registry to set them before, they will now be ignored. If you use GNOME, you must upgrade gnome-session and gnome-control-center and set your default browser/mail-client again. If you don't use GNOME, you should ensure that the file ~/.local/share/applications/mimeapps.list has the following content: [Added Associations] x-scheme-handler/http=$browser_name.desktop; x-scheme-handler/https=$browser_name.desktop; x-scheme-handler/mailto=$mailclient_name.desktop; Replace $browser_name.desktop and $mailclient_name.desktop with the appropriate file from /usr/share/applications that can handle http/https/mailto URIs. Please make sure that your browsers and mail clients have been upgraded to the latest stable versions before doing all this. This is unclear. Should non-gnome users (I'm a kde user) set this to prepare for the upgrade, or as a workaround until one actually completes the upgrade? The question comes up, because I'm on 2.28.6, which should be above the threshold for the notice, and I have that file in my home dir, but do NOT have those entries in it, which the notice appears to imply I should. Second point: To clarify, you're asking presumably admin users to set this in their homedir config, right? There's absolutely nothing in the proposed news item (and no link with it as a further detail) explaining this rather unprecedented tampering with a user's private homedir config, nor anything explaining what happens if it isn't done. Should an admin by arbitrary fiat edit the entries for *ALL* users? Just his own? If this is intended to be a system level policy edit, why isn't it *AT* they system level? If there is indeed technical reason to go editing individual user's homedir configs, then PLEASE make it MUCH CLEARER just WHICH user configs need to be edited (presumably all of them), and provide some justification, technical or otherwise, why editing the user config is the chosen solution. Note that as I implied above, a further details link is very likely appropriate, since news items are normally quite brief, serving in many cases more as an alert to check the details elsewhere than a full explanation and instructions. -- 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
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
I updated http://euscan.iksaif.net yesterday. I also added some overlays, and I now use local portage portage trees instead of system trees (a script to do that is available in euscanwww/script). New features: - Handle overlays correctly (special column for overlays) - Add some charts (small bar charts in table, pies at the bottom) - Less false positives with euscan I'll try to add all time line charts this week. Thanks, -- Corentin Chary http://xf.iksaif.net
[gentoo-dev] Re: Disabling locale at emerge output
On Tue, 26 Apr 2011 06:02:37 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 25 Apr 2011 20:05:03 -0600 Ryan Hill dirtye...@gentoo.org wrote: You want to force English on all our users because you can't be bothered to ask a reporter to repost an error message using LC_ALL=C? Are you saying you are setting up the tree-wide project that automatically translates LC_MESSAGES? Round of applause! Nope, but I am raising donations to fund an instructive manual on the usage of the NEEDINFO resolution. For a growing portion of our user base it's not nice to see these messages in their native language, it's fucking necessary. Another round of applause for the appalling attitude. Could you elaborate on the need to read error messages in your own language? How is the sys-apps/portage translation project doing anyway? Still only in Polish, hm? :) Que? Are you saying that because portage is in English that people that don't speak English don't use Gentoo? I would have to disagree. If you think that getting the occasional bug report in a language you aren't familiar with is annoying, imagine how not being able to get any build output you can read might feel, especially if the reason is only because some dev couldn't be bothered to occasionally ask someone to repost an error message in English. This reminds me of the time someone wanted to ban inline `emerge --info` postings in bugzilla (ie. attachments only) because they found scrolling through them bothersome. In other words, suck it up. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-admin/gentoo-rsync-mirror: metadata.xml ChangeLog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2011 12:01 AM, Jeremy Olexa wrote: On 04/26/2011 07:17 PM, Dane Smith (c1pher) wrote: c1pher 11/04/27 00:17:00 Modified: metadata.xml ChangeLog Log: app-admin/gentoo-rsync-mirror: Updated maintainer info in metadata. Hmm, I was thinking about removing this package on behalf of mirror-admins, because we haven't kept it up to date. Is it actually useful to install a few config files? -Jeremy Index: metadata.xml === RCS file: /var/cvsroot/gentoo-x86/app-admin/gentoo-rsync-mirror/metadata.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- metadata.xml2 Jun 2010 06:42:03 -1.5 +++ metadata.xml27 Apr 2011 00:16:59 -1.6 @@ -3,6 +3,12 @@ pkgmetadata herdno-herd/herd maintainer -emailmaintainer-nee...@gentoo.org/email +emailc1p...@gentoo.org/email +nameDane Smith/name +/maintainer +maintainer +emailrgkm...@gmail.com/email +nameRobert Kowalski/name +descriptionProxy Maintainer. CC on bugs/description /maintainer /pkgmetadata I forwarded this on to the proxy. I don't know much about the package at this point save that someone is interested in it. - -- Dane Smith (c1pher) Gentoo Linux Developer -- QA / Crypto / Sunrise / x86 RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531op=index -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNuASKAAoJEEsurZwMLhUxkZIP/RO2MoO8ESlZmXAZagKOEumh a4MlS5osR0ZEVOx4OK16qmq3zj6pclmfRXQTfwMt+eXSd4sg44bd3bsxUDmPDeon eHeG/VBmeYj6rqhiMPzj2K6GDKnFLqoHfxdJylpVmFMyj4F8/Gal9Jc72t4T7dT5 STTedxzb/mrELCIibgMUCZiikUB7LlTUGuDvz/Vc98uNRI/5rXUbf9bBe+4TVZtK /rymkN2K3whHalQai0UfXQkGmJ4JxZNCjv5PGDY1HKHwfnhmUoseMgNSdzqDHpmp 4nl5ioHdpOgqLp0WdBxFOaJ4eFEcSvvnCXsE3utb1R7KKKRQuYNJbasfGOgfhmuc 0gZZJJB/bLeWaPO4Hfwzby7qHdJxXNj892FimdHJb0xJ71pQEcKlkJN6py1XDI4/ /uaNlXYemb5IwgSMGrhZPXoqauz2AygPN9GENn036AIw1Pzbh+W0VRv5DlUO8mQl 8C/mAer3zlVHECKT3lHhkXpZv5jUKsVzQ6q3H/EqXl4u9g6KXabQlAaZX56ubTw1 t2ipqMO+51gpbZrgnGhvLkQ8qS5mygphzieabWCOSbVt2zagO/bP9kZ5cBMtBFg9 qukVjGPQlE3I6+ejhXwmz1CJQ5rc2uELQ5uVzugVNmJn66LgPv74P9mOJ9stHUzt m2LzgcaG8yQBk0G2c10I =4WYo -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
On 04/26/2011 09:56 PM, Samuli Suominen wrote: You have 24 hours to comment on this news item. Sorry to put it so bluntly but this is required for major security bug (#364973). See attachment. Based on some comments posted here, and IRC, here is an updated news item. Title: Upgrade to GLIB 2.28 Author: GNOME Team gn...@gentoo.org Content-Type: text/plain Posted: 2011-04-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-libs/glib-2.28 The way of setting default URI handlers has changed since dev-libs/glib-2.28 and above. If you used the GConf registry to set them before, they will now be ignored. If you use GNOME, you must upgrade gnome-session and gnome-control-center and set your default browser/mail-client again. If you don't use GNOME, you should ensure that the file ~/.local/share/applications/mimeapps.list has the following content: [Added Associations] x-scheme-handler/http=$browser_name.desktop; x-scheme-handler/https=$browser_name.desktop; x-scheme-handler/mailto=$mailclient_name.desktop; Replace $browser_name.desktop and $mailclient_name.desktop with the appropriate file from /usr/share/applications that can handle http/https/mailto URIs. The system-wide version of the file is often at /usr/share/applications/defaults.list instead. Please make sure that your browsers and mail clients have been upgraded to the latest stable versions before doing all this. More information about using defaults.list and mimeapps.list at: http://www.freedesktop.org/wiki/Specifications/mime-actions-spec
Re: [gentoo-dev] Re: RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
On 04/27/2011 10:46 AM, Duncan wrote: Samuli Suominen posted on Tue, 26 Apr 2011 21:56:06 +0300 as excerpted: You have 24 hours to comment on this news item. Sorry to put it so bluntly but this is required for major security bug (#364973). See attachment. Title: Upgrade to GLIB 2.28 Author: GNOME Team gn...@gentoo.org Content-Type: text/plain Posted: 2011-04-26 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: dev-libs/glib-2.28 The way of setting default URI handlers has changed since dev-libs/glib-2.28 and above. If you used the GConf registry to set them before, they will now be ignored. If you use GNOME, you must upgrade gnome-session and gnome-control-center and set your default browser/mail-client again. If you don't use GNOME, you should ensure that the file ~/.local/share/applications/mimeapps.list has the following content: [Added Associations] x-scheme-handler/http=$browser_name.desktop; x-scheme-handler/https=$browser_name.desktop; x-scheme-handler/mailto=$mailclient_name.desktop; Replace $browser_name.desktop and $mailclient_name.desktop with the appropriate file from /usr/share/applications that can handle http/https/mailto URIs. Please make sure that your browsers and mail clients have been upgraded to the latest stable versions before doing all this. This is unclear. Should non-gnome users (I'm a kde user) set this to prepare for the upgrade, or as a workaround until one actually completes the upgrade? It's a permanent thing... I think the item is clear on that... The default way has changed, no where implying this would go away or be temporary, or a workaround The KDE desktop should set those mime's already, if you have selected default browser/mailclient from the desktops GUI apps. If not, file a bug for the KDE people. The question comes up, because I'm on 2.28.6, which should be above the threshold for the notice, and I have that file in my home dir, but do NOT have those entries in it, which the notice appears to imply I should. The news item is targeted for stable users... presumably ~arch users know what they are doing. Hence the Display-If-Installed. Second point: To clarify, you're asking presumably admin users to set this in their homedir config, right? There's absolutely nothing in the proposed news item (and no link with it as a further detail) explaining this rather unprecedented tampering with a user's private homedir config, nor anything explaining what happens if it isn't done. Should an admin by arbitrary fiat edit the entries for *ALL* users? Just his own? If this is intended to be a system level policy edit, why isn't it *AT* they system level? If there is indeed technical reason to go editing individual user's homedir configs, then PLEASE make it MUCH CLEARER just WHICH user configs need to be edited (presumably all of them), and provide some justification, technical or otherwise, why editing the user config is the chosen solution. Note that as I implied above, a further details link is very likely appropriate, since news items are normally quite brief, serving in many cases more as an alert to check the details elsewhere than a full explanation and instructions. Addressed the system-wide vs. user defined issue in the new draft (responded to the original post of this thread with it). Has a link now too.
[gentoo-dev] Re: RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
Samuli Suominen posted on Wed, 27 Apr 2011 15:17:57 +0300 as excerpted: On 04/27/2011 10:46 AM, Duncan wrote: Samuli Suominen posted on Tue, 26 Apr 2011 21:56:06 +0300 as excerpted: You have 24 hours to comment on this news item. Sorry to put it so bluntly but this is required for major security bug (#364973). This is unclear. Should non-gnome users (I'm a kde user) set this to prepare for the upgrade, or as a workaround until one actually completes the upgrade? It's a permanent thing... I think the item is clear on that... The default way has changed, no where implying this would go away or be temporary, or a workaround FWIW, yes, the default way has changed bit was clear. It simply wasn't (and remains not in the updated news item itself, but there's a link with more info now...) immediately clear how the config changes we were being asked to do related to that... in part because of the user vs. system question. But the updated version is all around better. The KDE desktop should set those mime's already, if you have selected default browser/mailclient from the desktops GUI apps. If not, file a bug for the KDE people. Yes. I found the settings in the system-wide file. I've had no reason to change them from system defaults, so they weren't in the user config, only the system config. The new version allows that information to be discovered far easier. =:^) The news item is targeted for stable users... presumably ~arch users know what they are doing. Hence the Display-If-Installed. To the extent that everything seems to be working, yes. However, in the context of a security bump with instructions for config entries I don't see, that I don't fully understand the significance of and with no link to further details, as I suppose most admins, I start asking questions! Addressed the system-wide vs. user defined issue in the new draft (responded to the original post of this thread with it). Has a link now too. Indeed. Much /much/ better now. =:^) Thanks! =:^) -- 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
Re: [gentoo-dev] Re: RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
On 04/27/2011 03:46 PM, Duncan wrote: [ .. ] Just to make it clear: The only relationship this news item has to the security bump is the fact that the unvulnerable polkit is just needing newer glib as a dependency for other reasons
Re: [gentoo-dev] RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
On 15:05 Wed 27 Apr , Samuli Suominen wrote: The way of setting default URI handlers has changed since dev-libs/glib-2.28 and above. If you used the GConf registry to set them before, they will now be ignored. Do you think all our users will even understand what this means? Can you provide a more plain-English explanation, and give specific examples? For example: The method for setting default applications for specific URI types (https://, mailto://, etc.) changed in dev-libs/glib-2.28 and newer. If you previously set them in GConf using the Configuration Editor, they will now be ignored. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpLMYrMOIz33.pgp Description: PGP signature
Re: [gentoo-dev] RFC: 24 hour review for = dev-libs/glib-2.28 stable news item
On 04/27/2011 11:13 AM, Donnie Berkholz wrote: On 15:05 Wed 27 Apr , Samuli Suominen wrote: The way of setting default URI handlers has changed since dev-libs/glib-2.28 and above. If you used the GConf registry to set them before, they will now be ignored. Do you think all our users will even understand what this means? Can you provide a more plain-English explanation, and give specific examples? For example: The method for setting default applications for specific URI types (https://, mailto://, etc.) changed in dev-libs/glib-2.28 and newer. If you previously set them in GConf using the Configuration Editor, they will now be ignored. Maybe I expect too much from people... I changed it to the way you put it, works just as fine. Also the news item is now committed, a bit sooner than 24 hours but close enough Now arch teams can move forward with the security bug, it's A1 Critical afterall
Re: [gentoo-dev] Re: Disabling locale at emerge output
On Wed, 27 Apr 2011 02:47:46 -0600 Ryan Hill dirtye...@gentoo.org wrote: Are you saying you are setting up the tree-wide project that automatically translates LC_MESSAGES? Round of applause! Nope, but I am raising donations to fund an instructive manual on the usage of the NEEDINFO resolution. As already explained, requesting information and temporarily closing bug reports happens a lot already, but usually greatly stalls a bug's resolution. Developers have to make time to investigate the problem and lose time when they have to wait for additional information and need to reschedule. For a growing portion of our user base it's not nice to see these messages in their native language, it's fucking necessary. Another round of applause for the appalling attitude. Could you elaborate on the need to read error messages in your own language? How is the sys-apps/portage translation project doing anyway? Still only in Polish, hm? :) Que? Are you saying that because portage is in English that people that don't speak English don't use Gentoo? I would have to disagree. Obvious straw man. If you think that getting the occasional bug report in a language you aren't familiar with is annoying, You are obviously unaware of the scale of the problem. Devoting time to a bug becomes a serious problem when requested information takes a day or more to arrive, if at all. imagine how not being able to get any build output you can read might feel, especially if the reason is only because some dev couldn't be bothered to occasionally ask someone to repost an error message in English. You underestimate the vastness of my imagination. This reminds me of the time someone wanted to ban inline `emerge --info` postings in bugzilla (ie. attachments only) because they found scrolling through them bothersome. I think you mean the time when I was requesting ATs not to post such information on stabilisation bugs just to confirm it was alright to stabilise. You know what? - I'll talk on that obviously tangential argument. That (arch team specific) policy was apparently abandoned, because it doesn't happen now. Perhaps I didn't cry victory on that one --- perhaps I should have specially informed you, since you seem to think this reflects on any future argument. A course in informal logic might do you well. You still haven't elaborated on the need to read build output in non-English, btw. You could have argued for non-English users' rights, or pushed for that LC_MESSAGES auto-translation project (I wasn't kidding), or you could have argued for a bug reporting tool that includes all the right information in the right language automatically. Look here, I am even willing to argue on your side just to possibly extract a meaningful objection to fixing LC_MESSAGES in sys-apps/portage. I can explain my position better on having LC_MESSAGES in the same language as sys-apps/portage appears to non-Polish readers, though. When someone has to read the English error output that sys-apps/portage tacks onto the end of the real error (possibly output long gone from the scroll buffer because it was an early sub-make that failed), doesn't want to go all technical and find that error message, and therefore needs to be asked to attach the entire thing or does that of her own accord, then why should the actual error message (foo/include/header.h: No such file or directory, in Simplified Chinese) be printed in a language the developer cannot read? The user only cares about using blender or openoffice - the user couldn't care less about the crufty build system of a DEPEND packages needed only at build time, or the language it prints. jer
Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 27.4.2011 10:04, Corentin Chary napsal(a): I updated http://euscan.iksaif.net yesterday. I also added some overlays, and I now use local portage portage trees instead of system trees (a script to do that is available in euscanwww/script). New features: - Handle overlays correctly (special column for overlays) - Add some charts (small bar charts in table, pies at the bottom) - Less false positives with euscan I'll try to add all time line charts this week. Thanks, Found another issue, package stays there even if it was removed from the portage tree (kde-misc/plasmaboard is a good example). Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk24WiAACgkQHB6c3gNBRYeUEwCgwGaQUFSJQ3WyEYqNrsuE3XQE I7IAnR/5srqiiin56N/sK2mO+uMuk4ew =FzoM -END PGP SIGNATURE-
[gentoo-dev] Camellia?
Is there any specific reason why smtp.gentoo and pigeon.gentoo use camellia for their outbound smtp starttls connections? Not complaining or anything. Just curious. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: [gentoo-pms] Clarify wording on self-blockers
On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote: Uh, no, that's the entire point of EAPIs. This is a common misconception. Uh, no. You are completely and horribly wrong. EAPIs were introduced to avoid the problems that we used to have where different versions of Portage did different things with the same input (including, but not limited to, difficulties in adding new features). From ebuild developer point of view - EAPI specification should provide all knowledge required to create ebuilds along with detailed and unambiguous description of what to expect from package manager that is compliant with said EAPI. Oh heck no. That really isn't the point at all. But it is. Discussion about blocks is precisely about what is expected package manager behaviour for self-mutual blocks (in EAPI=2) in such case. And what you propose is 'behaviour is undefined for self-mutual blocks' - if so, why are they permitted by specification and not banned instead? The way you understand the word 'specification' doesn't really allow any specs bugfixes since they would magically invalidate any existing implementations, unless there is just one (and actually there *is* just one *supported*) so that specification could be kept in sync with it. How does Paludis handle normal and/or strong self-blocks? And how PkgCore does? Is blocks situation ever going to be clarified/improved in package manager level? What with other PMS issues? No, specification will be out of sync because every single random package manager developer will implement it his/her way, and then claim said package manager is compliant and specification cannot be fixed since it changes behaviour. No, it doesn't change behaviour of any implementation - it will make it possible to determine that some particular implementation is not compliant. It is to mean that some ancient portage is not compliant with hopefully-soon-to-be-updated specification? Yes indeed, that's the result of updating *specification*. Maybe also the point. From an ebuild developer's point of view, PMS describes (or at least tries to describe -- the case under discussion here is one where PMS probably needs fixing) what can and cannot be relied upon from the package manager. The EAPI feature is used to restrict your ebuild's availability to *all* package manager versions supporting a particular set of features. Not the most recent Portage version. *ALL* versions of Portage that claim support for the EAPI in question. (I'm tempted to quote some random definition for fun) Ebuild developer looks at PMS through a view called EAPI so ebuild developer is interested in package manager behaviour in said EAPI that's why I said EAPI not PMS. And Portage is frankly the only supported package manager in Gentoo. If one wanted PMS to document behaviour of all known portage/paludis/pkgcore versions in PMS, one would need to be much more specific: what behaviour applies to what versions of particular package manager so that one really knows what can and what cannot be relied upon. But I suppose it's not the point. I thought PMS is specification and not a documentation - hence it should specify (to document would be poor choice of words.. ) intended, widely agreed behaviour and *defined* behaviour so that ebuild developer knows how to write ebuilds that work against PM *compliant* with specification and package manager developer knows how to write *compliant* PM. And because there are many places where PMS is too vague, it misses those goals. Old package managers and their expected behaviour is irrelevant as soon as migration path to recent version exists for them. Again, you are deeply confused. It is required that an upgrade path for old package managers is kept around for as long as possible by not using newer EAPIs for certain key system packages. This is entirely different to what you're saying -- it means that certain packages should be kept at low EAPIs for as long as possible, not that EAPIs are whatever the latest Portage version does. No, you're making it up here. Since intended behaviour for normal vs strong blocks is like Ulrich specified, and migration path to the most recent from first portage supporting EAPI-2 exists - argument to block specification update is invalid. That doesn't follow at all. What happens if someone has an old Portage installed and the migration path includes things that rely upon a changed behaviour? It wouldn't be a migration path, would it? Since you're trying to retroactively define a particular behaviour for all EAPIs that doesn't match what some old Portage versions do, your upgrade path is screwed. No, I'm supporting *defining* behaviour as it's intended so that package managers are able to know whether they are correct. You're making all of them correct by explicitly allowing them to do anything here and there - it's not helping. This sort of thing really
[gentoo-dev] Re: [gentoo-pms] Clarify wording on self-blockers
On Wednesday 27 of April 2011 23:30:22 Maciej Mrozowski wrote: Please ignore me, unintentional cross-post. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Disabling locale at emerge output
Jeroen Roovers schrieb: Look here, I am even willing to argue on your side just to possibly extract a meaningful objection to fixing LC_MESSAGES in sys-apps/portage. I now tend to agree that LC_MESSAGES should be set to C by default. However I suggest to put it in the default make.conf, together with a comment remove this line if you want build messages in your locale Regards, Chi-Thanh Christopher Nguyen
Re: [gentoo-dev] Re: Disabling locale at emerge output
2011/4/27 Chí-Thanh Christopher Nguyễn chith...@gentoo.org Jeroen Roovers schrieb: Look here, I am even willing to argue on your side just to possibly extract a meaningful objection to fixing LC_MESSAGES in sys-apps/portage. I now tend to agree that LC_MESSAGES should be set to C by default. However I suggest to put it in the default make.conf, together with a comment remove this line if you want build messages in your locale Perhaps with a warning that bugs should be filed with LC_MESSAGES set to C. -Ross Regards, Chi-Thanh Christopher Nguyen
Re: [gentoo-dev] Camellia?
On Wed, Apr 27, 2011 at 03:38:16PM -0400, James Cloos wrote: Is there any specific reason why smtp.gentoo and pigeon.gentoo use camellia for their outbound smtp starttls connections? Probably it is the strongest cipher supported. One can do $ openssl ciphers -v 'ALL:@STRENGTH' on those machines and see what comes up top. An upgrade might be in order. -- Eray Aslan Developer, Gentoo Linux eras at gentoo.org
[gentoo-dev] Re: Disabling locale at emerge output
On Wed, 27 Apr 2011 18:26:02 +0200 Jeroen Roovers j...@gentoo.org wrote: On Wed, 27 Apr 2011 02:47:46 -0600 Ryan Hill dirtye...@gentoo.org wrote: Are you saying you are setting up the tree-wide project that automatically translates LC_MESSAGES? Round of applause! Nope, but I am raising donations to fund an instructive manual on the usage of the NEEDINFO resolution. As already explained, requesting information and temporarily closing bug reports happens a lot already, but usually greatly stalls a bug's resolution. Developers have to make time to investigate the problem and lose time when they have to wait for additional information and need to reschedule. Maybe I'm just lucky, but the number of times I've had a bug where such a conversation had to take place could be counted on my toes. I imagine being a bug wrangler you see it far more often, but what are we talking here? 1/100? 1/500? Can you compare this to the number of times that someone doesn't include emerge --info, which has a similar halting effect? And yes, the times I have gotten non-english errors in bug reports I have found it annoying. It just hasn't happen often enough to have driven me crazy, which may be the case here. Que? Are you saying that because portage is in English that people that don't speak English don't use Gentoo? I would have to disagree. Obvious straw man. Working for the font team a couple years ago I went to some of the language-specific mailing lists asking if there was any language-specific fonts people required that weren't yet in Gentoo. I had to work through interpreters because many of the people I wanted to talk to didn't speak a lick of English. imagine how not being able to get any build output you can read might feel, especially if the reason is only because some dev couldn't be bothered to occasionally ask someone to repost an error message in English. You underestimate the vastness of my imagination. Okay... I'm not actually sure what that means. This reminds me of the time someone wanted to ban inline `emerge --info` postings in bugzilla (ie. attachments only) because they found scrolling through them bothersome. I think you mean the time when I was requesting ATs not to post such information on stabilisation bugs just to confirm it was alright to stabilise. No, it wasn't you. I would have remembered. This person was talking in the general sense. And it was a silly reason, not like yours. You still haven't elaborated on the need to read build output in non-English, btw. You could have argued for non-English users' rights, or pushed for that LC_MESSAGES auto-translation project (I wasn't kidding), or you could have argued for a bug reporting tool that includes all the right information in the right language automatically. I _am_ arguing for non-English user's rights. That's the whole reason I'm here, annoying you and whatnot. When someone has to read the English error output that sys-apps/portage tacks onto the end of the real error (possibly output long gone from the scroll buffer because it was an early sub-make that failed), doesn't want to go all technical and find that error message, and therefore needs to be asked to attach the entire thing or does that of her own accord, then why should the actual error message (foo/include/header.h: No such file or directory, in Simplified Chinese) be printed in a language the developer cannot read? See, you're thinking primarily in terms of bugzilla. Like the only reason someone would want to see this stuff is to paste it to a bug report for a developer to look at. I'm saying someone who doesn't speak English at all (who won't be filing bugs btw) might want to be able to understand the error the compiler just dumped on them without needing a translator. But whatever, I appear to be the only person who has a problem with this. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
