[gentoo-dev] Returning dev: Thomas Alan Gall (tgall)
Hi everyone, we have an returning oldtimer here, Thomas Gall aka. tgall. His original bug has been opened in 2003, so he knows gentoo from the early days. He is joining the arm team now and will stabilize mostly for arm64, where he already started to work with a rate of 10 pkgs/day. Happy days for arm users! Some biographic notes from himself: Reenactor of War of 1812, Napoleonic French and US Civil War eras. Long time software engineer currently working for Linaro as the acting director of the Linaro Mobile Group. Former and now returned Gentoo dev interested now days in arm and arm64. Former Mayor of Mantorville. Dad, husband and general jack of all trades. Please join me in welcoming him back! Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Returning dev: Thomas Alan Gall (tgall)
On 7/14/14, 10:26 AM, Justin (jlec) wrote: we have an returning oldtimer here, Thomas Gall aka. tgall. His original bug has been opened in 2003, so he knows gentoo from the early days. He is joining the arm team now and will stabilize mostly for arm64, where he already started to work with a rate of 10 pkgs/day. Happy days for arm users! Some biographic notes from himself: Reenactor of War of 1812, Napoleonic French and US Civil War eras. Long time software engineer currently working for Linaro as the acting director of the Linaro Mobile Group. Former and now returned Gentoo dev interested now days in arm and arm64. Former Mayor of Mantorville. Dad, husband and general jack of all trades. Yay, welcome! Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Returning dev: Thomas Alan Gall (tgall)
Welcome back to the jungle! :) On Mon, 14 Jul 2014 10:26:17 +0200 Justin (jlec) j...@gentoo.org wrote: Hi everyone, we have an returning oldtimer here, Thomas Gall aka. tgall. His original bug has been opened in 2003, so he knows gentoo from the early days. He is joining the arm team now and will stabilize mostly for arm64, where he already started to work with a rate of 10 pkgs/day. Happy days for arm users! Some biographic notes from himself: Reenactor of War of 1812, Napoleonic French and US Civil War eras. Long time software engineer currently working for Linaro as the acting director of the Linaro Mobile Group. Former and now returned Gentoo dev interested now days in arm and arm64. Former Mayor of Mantorville. Dad, husband and general jack of all trades. Please join me in welcoming him back! Justin -- Thank you, Fernando Reyes Mission Accomplish, Inc. http://missionaccomplish.com Tel: 718718 Cell: 3479275477
[gentoo-dev] Re: [gentoo-project] Returning dev: Thomas Alan Gall (tgall)
Welcome back! :) On 07/14/2014 04:26 AM, Justin (jlec) wrote: Hi everyone, we have an returning oldtimer here, Thomas Gall aka. tgall. His original bug has been opened in 2003, so he knows gentoo from the early days. He is joining the arm team now and will stabilize mostly for arm64, where he already started to work with a rate of 10 pkgs/day. Happy days for arm users! Some biographic notes from himself: Reenactor of War of 1812, Napoleonic French and US Civil War eras. Long time software engineer currently working for Linaro as the acting director of the Linaro Mobile Group. Former and now returned Gentoo dev interested now days in arm and arm64. Former Mayor of Mantorville. Dad, husband and general jack of all trades. Please join me in welcoming him back! Justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] PSA: ruby_targets_ruby21 masked on stable
I added the following entry to profiles/base/use.stable.mask: # dev-lang/ruby:2.1 is not stable. ruby_targets_ruby21 This is needed for https://bugs.gentoo.org/show_bug.cgi?id=505920, as otherwise rexical would generate the following repoman error: dependency.bad18 dev-ruby/rexical/rexical-1.0.5-r3.ebuild: DEPEND: x86(default/linux/x86/13.0) ['=dev-ruby/hoe-2.6.2[ruby_targets_ruby21]', '=dev-ruby/hoe-2.6.2[ ruby_targets_ruby21]', 'dev-ruby/test-unit:2[ruby_targets_ruby21]', 'dev-lang/ruby:2.1', 'dev-ruby/rdoc[ruby_targets_ruby21]', 'dev-ruby/rake[ruby_ta rgets_ruby21]', 'virtual/rubygems[ruby_targets_ruby21]', 'virtual/rubygems[ruby_targets_ruby21]'] Feel free to recommend better solutions to this in case I missed something - this error appeared in the middle of this multiple-packages stabilization, and it seemed better than e.g. reverting the keyword changes, especially that they're needed for security bug https://bugs.gentoo.org/show_bug.cgi?id=513290 . Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: The request to abolish games team policy
Vadim A. Misbakh-Soloviov: В письме от Пт, 11 июля 2014 16:24:38 пользователь hasufell написал: However, basically having only a single person that actively does such reviews + no official overlay makes it hard for contributors. As I said previously, you (and any developer else) are free to get a reviewer role for gamerlay (and make it official overlay). But, AFAIR, you're opinion is hat gamerlay must die... So, we fall into infinite circle (exaggeratedly): — There is no official overlay and no reviewers! — You can use gamerlay as a base for that and we can change our workline for you. — Gamerlay is unneded! ... — We need reviewers and official overlay. When I asked you why you don't contribute to sunrise you basically replied on a public channel: Sep 15 18:13:50 hasufell I think you are just too lazy for other contribution channels Sep 15 18:15:25 mva not that you're fully right, but yes, something like that. I'm too lazy to prove something somebody if it takes too much time for me So I think this is maybe also an ego thing (that's why you talk about proving something). I have no tolerance or time for stuff like that. People often reply aggressively to unrequested reviews or not at all, so I stopped doing such reviews and only do it if I see that someone is interested in improving his ebuild skills or when it matters for the tree. That is why gamerlay is going backwards. There is no concept behind gamerlay. The initiator doesn't care about the project anymore, there are no policies to ensure QA or proper workflow. So yes, I don't want to be involved with that. It's not the starting point to improve anything. I'd have to start with removing commit rights in order to force a review-workflow, but I can't and don't even want to do it since it's discouraging.
Re: [gentoo-dev] The request to abolish games team policy
Rich Freeman: On Sat, Jul 12, 2014 at 6:26 PM, Denis Dupeyron calc...@gentoo.org wrote: Rich, if I may have a suggestion, it would be that instead of meddling with projects that have been doing their best with what they have for years, and which need praise rather than hindrance, you instead start a project to get people to think positively and accept criticism. The amount of energy that was spent in this thread and many others in pure loss could have gone a long way. The only thing that I've offered to do is to help people join the games team, which is supposed to be an open team anyway. That is about the extent of the meddling that I've proposed. I've yet to hear anybody on the games team comment that more help would not be welcome. That said, I've also yet to hear from anybody actually interested in joining the games team. So, that idea may not end up going anywhere anyway. The premise has been that there are people interested in working on games but they've been prevented from doing so, and working to help improve the games team from within is better than imposing direction from above. If indeed nobody actually wants to join the games team, then the next question is whether to leave things alone, or to find another solution. Either way I'd like to hear more from anybody who actually wants to maintain games packages but feels they have been unable to do so. Simply changing policies won't make actual work happen. Rich I appreciate your effort, but what can you do about it? a) I'm not sure if I want to be in a team where vapier is lead. I have a lot of respect for his technical skills/knowledge, but I don't have any hopes for him to understand what a project lead is supposed to do (like... answer). b) I don't want the games team to be disbanded like QA, it will probably make the situation worse. I will continue to work with Mr_Bones_, but if any1 says there is no problem with the games project, then he either doesn't know anything about the situation or he doesn't want to know. Again, you seem to be the only council member who cares to mediate here. That is pretty frustrating.
[gentoo-dev] news item: dhcpcd-6.4.2 defaults to stable private ipv6 addresses
All, this is a newsitem I want to post for the newest dhcpcd in the nesxt few days. I'm not interested in commenting out slaac private in the new dhcpcd.conf by default, because as you will see in the references, there are good reasons to keep that setting. However, what I would like to know is whether I can nail down more how to describe when connectivity can be lost so people don't get a surprise after they upgrade. Any suggestions would be helpful. Thanks, William Title: dhcpcd 6.4.2 defaults to stable private ipv6 addresses Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2014-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: net-misc/dhcpcd-6.4.2 dhcpcd-6.4.2 and newer supports ipv6 stable private addresses when using ipv6 stateless address autoconfiguration (SLAAC) as described in RFC-7217 [1]. The configuration file shipped with dhcpcd activates this feature by default, because it means that a machine cannot be tracked across multiple networks since its address will no longer be based on the hardware address of the interface. We did receive a report in testing that ipv6 connectivity was lost due to this change [2]. If you are concerned about losing ipv6 connectivity, I recommend commenting out the line in dhcpcd.conf that says slaac private when you upgrade. See the references below for why the upstream default is to use private addresses. [1] http://tools.ietf.org/html/rfc7217 [2] https://bugs.gentoo.org/show_bug.cgi?id=514198 [3] http://tools.ietf.org/html/draft-ietf-6man-default-iids-00 [4] http://mail-index.netbsd.org/tech-net/2014/06/04/msg004572.html signature.asc Description: Digital signature
Re: [gentoo-dev] news item: dhcpcd-6.4.2 defaults to stable private ipv6 addresses
All, I am reposting this because I got a couple of updates from IRC. Let me know what you think. Thanks, William Title: dhcpcd 6.4.2 defaults to stable private IPv6 addresses Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2014-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =net-misc/dhcpcd-6.4.2 dhcpcd-6.4.2 and newer supports IPv6 stable private addresses when using IPv6 stateless address autoconfiguration (SLAAC) as described in RFC-7217 [1]. The configuration file shipped with dhcpcd activates this feature by default, because it means that a machine cannot be tracked across multiple networks since its address will no longer be based on the hardware address of the interface. We did receive a report in testing that IPv6 connectivity was lost due to this change [2]. If you are concerned about losing IPv6 connectivity, I recommend commenting out the line in dhcpcd.conf that says slaac private when you upgrade. See the references below for why the upstream default is to use private addresses. [1] http://tools.ietf.org/html/rfc7217 [2] https://bugs.gentoo.org/show_bug.cgi?id=514198 [3] http://tools.ietf.org/html/draft-ietf-6man-default-iids-00 [4] http://mail-index.netbsd.org/tech-net/2014/06/04/msg004572.html signature.asc Description: Digital signature
Re: [gentoo-dev] news item: dhcpcd-6.4.2 defaults to stable private ipv6 addresses
All, here is the second update from IRC today. I reworded the title and added more information to the body recommending that users adjust to the new configuration. William Title: dhcpcd = 6.4.2 changes defaults for IPv6 Author: William Hubbs willi...@gentoo.org Content-Type: text/plain Posted: 2014-07-17 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: =net-misc/dhcpcd-6.4.2 dhcpcd-6.4.2 and newer supports IPv6 stable private addresses when using IPv6 stateless address autoconfiguration (SLAAC) as described in RFC-7217 [1]. The configuration file shipped with dhcpcd activates this feature by default, because it means that a machine cannot be tracked across multiple networks since its address will no longer be based on the hardware address of the interface. We did receive a report in testing that IPv6 connectivity was lost due to this change [2]. If you are concerned about losing IPv6 connectivity, I recommend temporarily commenting out the line in dhcpcd.conf that says slaac private until you can adjust to the new configuration. See the references below for why the upstream default is to use stable private instead of hardware-based addresses. [1] http://tools.ietf.org/html/rfc7217 [2] https://bugs.gentoo.org/show_bug.cgi?id=514198 [3] http://tools.ietf.org/html/draft-ietf-6man-default-iids-00 [4] http://mail-index.netbsd.org/tech-net/2014/06/04/msg004572.html signature.asc Description: Digital signature
Re: [gentoo-portage-dev] support multiple eclass variants (aka unstable eclasses)
On 07/08/2014 07:11 PM, Sebastian Luther wrote: Am 08.07.2014 18:58, schrieb Michael Haubenwallner: Hello fellow Portage developers, attached portage patch draft aims to allow for easy distributing eclasses to be tested by multiple tinderboxes on various architectures, without being active for normal installs. What does the patch allow you to do, that you can't do right now? (i.e. put an eclass with the same name in an repository and use eclass-overrides to force its use in another repo?) Is there an easy way to use the eclasses from the overriding tree, but not the (usually newer) ebuilds from there - such as 'configure but disable repo (except for use in eclass-override)'? Thanks! /haubi/
