[gentoo-portage-dev] [PATCH] emerge/actions: Add python version to portage version line
Adds the currently running python version to the portage version line, so that it's immediately obvious what version of python is being used to run portage --- pym/_emerge/actions.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py index 2a1354b..9bc6ed1 100644 --- a/pym/_emerge/actions.py +++ b/pym/_emerge/actions.py @@ -2996,6 +2996,7 @@ def relative_profile_path(portdir, abs_profile): return profilever def getportageversion(portdir, _unused, profile, chost, vardb): + pythonver = 'python %d.%d.%d-%s-%d' % sys.version_info profilever = None repositories = vardb.settings.repositories if profile: @@ -3051,8 +3052,8 @@ def getportageversion(portdir, _unused, profile, chost, vardb): gccver = getgccversion(chost) unameout=platform.release()+ +platform.machine() - return Portage %s (%s, %s, %s, %s) % \ - (portage.VERSION, profilever, gccver, ,.join(libcver), unameout) + return Portage %s (%s, %s, %s, %s, %s) % \ + (portage.VERSION, pythonver, profilever, gccver, ,.join(libcver), unameout) def git_sync_timestamps(portdb, portdir): -- 1.9.1
Re: [gentoo-dev] rfc: status of OpenRC's public API
On Wed, Sep 25, 2013 at 7:08 PM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-09-13, o godz. 19:16:06 William Hubbs willi...@gentoo.org napisał(a): OpenRC currently has a public api, consisting of librc and libeinfo (rc.h and einfo.h are the headers); however, I do not know of any released software that uses these, so, if there is nothing, I am considering making this code private to OpenRC and getting rid of the API. I won't oppose since I don't use OpenRC anymore and therefore my opinion doesn't really matter here. However, I can't help but notice a particular trend since Roy left the project. I see that OpenRC is slowly regressing towards baselayout-1. First the oldnet thingie being made the default back. While I can understand why people wanted it so badly, this doesn't make this less of a carousel for Gentoo users. I mean, changing defaults with every maintainer change. Then, functions.sh split. While itself good, I don't get what's the benefit of converting the bash script from baselayout-1 while a better one was provided with OpenRC. Now removing the public API because you don't care. While it may have been unused indeed, it's simply crippling the thing, not making it more useful. I'd like to see some kind of plan behind all this. Because as far as I can see, it's just new maintainers slowly dropping all the new features they don't care about without any specific vision. No offense intended. If OpenRC really wants to compete with systemd, it should at least have some design plan, and you really should start working on providing useful features rather than reverting, crippling and rewriting for the sake of changing things. Just some material to think about. -- Best regards, Michał Górny I know I'm a bit late to this thread, but mgorny has a point. While it may not be immediately obvious, libeinfo is very useful, especially if your project aims to integrate nicely into a Gentoo system, by providing a standard set of printing functions with the formatting taken care of, resulting in output that is very familiar to users and is easy to scan with the eyes when looking for problems. One potential use-case would be reimplementing eselect in C. Not that I'm saying that this should happen, but anybody who attempts to do this would certainly appreciate having this bit taken care of for them. I would be more than willing to assist with maintenance of the library, even if split out into its own package, since it's small and rather simplistic, so there's unlikely to be any issues. I see no reason why we should remove something that isn't broken and doesn't cause us any maintenance burden. If somebody does open a bug against OpenRC because of an issue they're encountering while trying to use libeinfo, I give full license to assign the bug to me, and I'll happily investigate the issue. -Doug
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-25 23h59 UTC
On Aug 26, 2013 12:06 PM, Robin H. Johnson robb...@gentoo.org wrote: On Mon, Aug 26, 2013 at 11:56:51AM +0200, Tom Wijsman wrote: Seems like a bug with g-d-a because the mail header has not changed. The mail itself is proper, nothing wrong with it; the Reply-To header should not matter with regards to delivery. We might even risk not receiving them if we send them to g-d-a only if there is a bug present. I have fixed the script to add Reply-To. However, where was this change announced to devs? I also can't find any documentation of it. Please update the Developer Handbook [1], quizzes, and possibly also the mailing list page. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?full=1 -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 dilfridge posted to gentoo-dev about a month ago that this was the case: http://www.gossamer-threads.com/lists/gentoo/dev/274905 (But yes, all the docs should be updated to reflect this) -Doug Guy who remembers far too much
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
On Aug 20, 2013 10:58 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2013 06:26 AM, Michał Górny wrote: Hello, fellow developers. I've added a few new fancy features for Gentoo developers to portage git. Sadly, since Zac isn't planning another release until 2.2.0 goes stable, you need to switch to - to use them. But I say to you, it's worth the hassle. Any idea on an eta for that? This is some fantastic looking stuff. I'm really looking forward to using these features. Thanks, Zero Based on the 30 day rule of thumb, and assuming no critical bugs, no sooner than September 11th, and eix 0.29.3's stabilization (30 day rule of thumb here is September 6th) can be considered a blocker, because it has several fixes for behavior that has changed between 2.1 and 2.2 that causes problems for eix users (example: bug 478320 [1]). I participated in the discussion about this very question a few days ago in #gentoo-portage on IRC. -Doug [1]: https://bugs.gentoo.org/show_bug.cgi?id=478320
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
On Aug 20, 2013 11:20 AM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-08-20, o godz. 11:04:35 Alexis Ballier aball...@gentoo.org napisał(a): On Tue, 20 Aug 2013 12:26:03 +0200 Michał Górny mgo...@gentoo.org wrote: 2. FEATURES=network-sandbox does distcc work with this ? You could say that. It just can't connect to any other host :). We may try to handle this somehow but I can't immediately think of any sane way of 'escaping' the sandbox. You could do it the same way as LXC does, with a virtual interface which is then NAT-ed to the real network interface, but I'm not sure I'd consider this sane. The overhead required to set this up on every execution of gcc, let alone the modifications needed for NAT, pretty much makes rules this out completely. You might be able to exploit iptables and ip6tables to allow only distcc to communicate out, but that's still painful and is a hack at best. -Doug
Re: [gentoo-dev] Re: Remember to specify SLOT when adding subslot operator to dependencies
On Aug 5, 2013 8:06 AM, Ulrich Mueller u...@gentoo.org wrote: On Mon, 05 Aug 2013, Samuli Suominen wrote: You don't need to see it, because portage sets implicit subslot /0 in EAPI=5 so it's there, even if you don't see it. Shouldn't the implicit sub-slot be equal to the regular slot? Ulrich Yes, as per EAPI 5 [1], implicit sub-slots are equal to that of the regular slot. As these packages depend specifically on slot 0, the deps could be changed to virtual/jpeg:0 and virtual/openssl:0 respectively, and then updated later should another compatible slot come along (as they'd need to be anyway). Granted, you then lose the automatic rebuild if these packages start using subslots, so it's probably best to leave the slot operator dep. -Doug [1]: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-820008.2.6
Re: [gentoo-dev] Re: [gentoo-dev-announce] OpenRc-0.12 is coming soon
On Aug 3, 2013 6:04 AM, Markos Chandras hwoar...@gentoo.org wrote: On Aug 3, 2013 10:06 AM, Donnie Berkholz dberkh...@gentoo.org wrote: On 15:36 Fri 02 Aug , William Hubbs wrote: All, This message is an announcement and a reminder. OpenRc-0.12 will be introduced to the portage tree in the next few days. If you are using ~arch OpenRc, the standard disclaimer applies: remember that you might be subject to breakage. I do not know of any breakage personally. It does work on my system, and I know of others who are using OpenRc from git successfully. Some are OpenRc team members, and at least one is a Gentoo user. If you are not comfortable with the possibility of breakage, I recommend that you make sure you do not upgrade right away. If, on the other hand, you are comfortable with that possibility and you are willing to help us test and get rid of bugs before we go stable, feel free to run ~arch. In other words, this is the standard Gentoo disclaimer, so consider yourself warned. Man, in terms of how to phrase things, this is way wrong. If you're comfortable with your stuff breaking really? No. If you want to help improve Gentoo. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer, Gentoo Linux http://dberkholz.com Analyst, RedMonk http://redmonk.com/dberkholz/ I am not comfortable with this either. If you think the new openrc will likely break things please mask it for a few days. Do not expect all users to read the mailing list. I personally expect this of ~arch, and am pleasantly surprised every time I update and it still works. As WilliamH mentioned, he's not seen breakage himself, but as with anything undergoing active development, as they say, sh*t happens. People have all sorts of setups (including myself, using a preup function to rename interfaces when using oldnet), and while they try to test everything they can, they can't reproduce every possible scenario. If you're running ~arch, you should assume it might break, and be prepared for that as a possibility. That's why we call it testing, and Debian does this in a similar manner and testing there tends to break in cute ways when they release the freeze after a release, when everything waiting in sid for months suddenly is now in testing. If you know something common will break, or repairing breakage would be a significant PITA, then yes, it should enter the tree masked (see GCC for example), otherwise, imo, entering the tree ~arch is fine. -Doug PS: I'll probably install openrc- on one of my systems today, just to see if anything breaks :)
Re: [gentoo-dev] Base profile changes should be announced/discussed on this list.
On Wed, Jul 31, 2013 at 5:53 AM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Jul 31, 2013 at 08:21:20AM +0200, Michael Weber wrote Mostly everything is configurable, and revertable as user - granted. I'd like to see a announcement and an optional discussion on this list if base profile gets changed [0] - current case bug 449364 [1]. I'm not opposed to the specific change, or base system changes in general, but I don't like seeing them slip thru under the radar. Just have the honesty and brin gsuch changes to public. [In this case] having an working mouse copy'n'paste eases the way from stage3 to a set up X server, X server tends to break, and it doesn't collide with X anymore. So it only needs 1MB data [2], which is very usefull editing stage3 with it's default editor - nano. I see the point that's it's useless on headless virtual boxes. my 2 cents. Hold on a minute. There is a *MAJOR* difference between gpm the USE flag, and sys-libs/gpm the mouse server. I'm one of those weird guys who starts USE with -*. And I do not have gpm the USE flag enabled. I do, however, have sys-libs/gpm running just fine, thank you, minus the gpm flag. I can assure you that gpm works just fine during the install, even without the gpm flag. I see the point that's it's useless on headless virtual boxes Actually, if you ssh into the virtual box from a text console, it still works. If there was a move afoot to remove sys-libs/gpm from the install ISO, I would be part of the crowd up in arms about this. But that's totally a separate item from the USE flag. Since I've never used the gpm USE flag, I have to ask... what additional goodies does USE=gpm bring to the table? How exactly, does it improve things beyond the basic sys-libs/gpm? For most packages, USE=gpm builds them with the gpm library, which generally allows the built program to have the same mouse support on console as it does in an X environment. For example, with vim and USE=X, do ':set mouse=a', and you can use the mouse to navigate and do selections while in X. If you add USE=gpm, you can do the same things in the console environment, which is really handy if you haven't yet mastered vim's myriad of movement commands. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications -Doug
Re: [gentoo-dev] s/disk space/drive space
On Jul 30, 2013 8:19 AM, Alexander Berntsen alexan...@plaimi.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 30/07/13 14:12, Alex Legler wrote: I don't think you're using that right. You get to make statements for future reference if you actually have authority to tell people what to do. Relax. There's even a please in there. 'disk space' is a perfectly valid term even if you have fancy solid state drives these days. It is an established term in technical documentation that everyone understands even if you don't physically use a 'disk'. It's *wrong*. In school we were even taught to avoid it. :-) How is it wrong? We've been using disk space for decades (probably since disks were invented), and as someone who has been using Linux for 5 years, and Windows for 10 years, the only time I've ever heard drive space is in Windows or from not-so-technically savvy friends and relatives. Wikipedia lists 'disk space', not 'drive space' as do two English-* dictionaries I checked. Why should we be coining 'drive space'? free space or space available or similar may be better wordings, though I am used to seeing drive space. however, if many people violently oppose such a change, that's fine then. I would simply prefer a more correct term. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlH3rz8ACgkQRtClrXBQc7VMFwD/aE+cGnDYZOxgesjQ3Kv65zO5 a3NIg+P5vd8piaqOg0YA+gN26Rep4FXBpUVwzAShtUArtE/0hjQ+1ofZzAzd3RPR =X4XV -END PGP SIGNATURE- -Doug
Re: [gentoo-dev] Lastrite: Firmware cleanup, part #1
Combined with various less-than-free licenses, installing one huge blob of firmware is problematic for many users, also from a security point of view. How does having additional firmware installed affect security at all? Firmware is only loaded when specifically requested by a loaded driver that needs to use it, and only if that driver is actually in use. That's like saying a file that can only be written to by root, only normally read when it's specifically needed, and if for some stupid reason is executed by an unprivileged process will just result in a crash, affects security (hint: I just described firmware). -Doug
Re: [gentoo-dev] New, shiny EAPI=5 profiles: volunteer, procedure, preparations
* all 13.0 profiles have been created and are marked stable the same way as 10.0 was * all 10.0 profiles have been removed from profiles.desc * all 10.0 profiles have been deprecated Suggestion: perhaps a news item should be created for the migration to the new profiles? As a Gentoo user who just got a giant red warning from portage that his active profile was deprecated, I feel like many people are going to be confused about this. -Doug
Re: [gentoo-dev] Should portage tree CVS impose a commit moratorium during snapshot creation?
On Thu, Jan 3, 2013 at 5:23 AM, Zac Medico zmed...@gentoo.org wrote: The CVS keyword expansion causes the ebuild digest to mutate during the commit. If we repoman could predict correctly emulate the CVS keywords expansion on the client side, then it could generate a correct Manifest in advance. However, that seems difficult given that the CVS keyword expansion contains a timestamp with 1 second precision. Thought: Do the CVS keyword expansion in repoman, and then feed the expanded file to CVS for commit. This gives you a fixed file, which you can then generate your manifest against. -Doug dwfreed
