[gentoo-dev] Add support for rsync patches
Hi, net-misc/rsync upstream provides a tarball with additional patches that can be useful for some users. I think it would be nice to have them handled automatically by portage using e.g. USE_EXPAND. Of course these patches can be just picked by user an applied using epatch_user, but I think it would be much easier and convenient to do this with just setting a use flag. Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add support for rsync patches
Dnia 2014-01-28, o godz. 11:59:33 Jauhien Piatlicki jpiatli...@gmail.com napisał(a): net-misc/rsync upstream provides a tarball with additional patches that can be useful for some users. I think it would be nice to have them handled automatically by portage using e.g. USE_EXPAND. Of course these patches can be just picked by user an applied using epatch_user, but I think it would be much easier and convenient to do this with just setting a use flag. ...and what do you want from gentoo-dev@? You need someone to file the bug for ya? -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: rfc: revisiting our stabilization policy
Please set your client not to embed people's email addresses in your responses: it's spambait in web archives. Thanks. Tom Wijsman wrote: Steven J. Long wrote: Tom Wijsman wrote: Steven J. Long wrote: What? Without a stable tree, Gentoo is useless afaic. It moves us closer to upstream releases, a little more bleeding edge; a lot of users and developers run that already, it is found to be useful. What? More vague. As are many of your philosophical statements in later and prior mails, so I'll ignore those. It is reality; and thus, without a stable tree, Gentoo is still useful for a lot of users and developers. What is vague about that? moves us closer to bleeding-edge is completely useless; there are already an immense amount of ways to run more up to date software, or you wouldn't have users already doing it. That doesn't detract from the merits of the stabilisation process, which you apparently don't get despite trumpeting your QA membership. The latter leaves me rather worried, to be frank. I don't think that's what was being proposed, though. The question was really the old complaint about slow architectures; the -* arch solution sounds like the most reasonable definition of dropping keywords, in the absence of AT communication otherwise. Dropping keywords and specifying -* are a world apart of each other. That's why it's in quotes. Why is there at all if you intend it to be irrelevant to this thread? What? OFC it's relevant; it's just not dropping keywords, it's dropping the ebuild from most archs, and leaving it in-place for those which haven't stabilised a newer version. You could have worked that out: in fact I assumed you had since it's been stated several times. Thanks for the show of good faith you demand from users: always good to have an example to follow. The former means that it is not ready for wide stable or testing users, the latter means that it has been tested to not work at all; furthermore, we need to explicitly specify which arches in that case. You're missing the point, again. The question was what does dropping keywords mean, when the maintainer has stabilised a newer version on the arch/s s/he has available, but feels that slower archs are holding up that process. Where is that question? *sigh* Are you really saying you don't understand the point of this thread? It's yaf slow archs are slow and i don't want them complaint, which recur every year or so, going back at least 10, though we haven't had this for the last couple of years that I recall; Gentoo has moved pretty quickly. It comes up more from openrc, imo, since the upstream maintainer is also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds for a core system package. That's an old argument, though, and his call. I mention it simply because the QA process for that package is squashed, in comparison to its importance within the framework. Git ebuilds are not the same as distribution stabilisation. No, I'm not expecting it to change. I'm just pointing out that it's very different to the other packages in the tree (being in-house it hasn't gone through any upstream testing at all, since Gentoo is effectively the upstream), and a case could be made that in fact its QA needs better handling, rather than changing policy to the detriment of archs across the board in response to this complaint. I'm slightly at a loss as to why it's such a big deal to just leave the old ebuild as-is, given that anyone on a stabled arch should upgrade automatically. It is when you are running the arch that only has the old version. FGS that's up the AT and their users to collaborate on them with. It's not up to some external developer to tell the AT which ebuilds are stable for their arch: that's their *job*. The ebuild dev only gets to request testing, just like users only get to request a version bump. But given that the maintainer feels they don't want that old ebuild around, and that the arch in question has not got round to testing the new one, for whatever reason (it's their call, after all, as to how their arch progresses), instead of simply removing that ebuild, or bumping it to unstable (which makes zero sense), just leave it stable on the slow arch/s in question, and remove the others. There are situations (security, stability, incompatibility) where keeping it in place becomes a much harder task; at which point, removal is bound to happen. At that point, such action is required. It becomes faster than you think; if you depend on a library, and the compatible range of that library gets wiped by a security bug, your package will suddenly depend on an incompatible newer stabilized version of the library at which point you are up for either a lot of hard work or plain out starting the progress of masking and removing it. Security bugs have a separate process, as you know, and reverse dep
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On 28/01/2014 14:37, Steven J. Long wrote: I concur that QA should be focusing on making stable, actually stable, not more bleeding edge. That's not a performance issue as you put it, except in management nuspeek. It's the whole bloody point of the distro, in overarching terms: to test and stabilise robust ebuilds. That process is what leads to better software, not staying at the bleeding-edge and forgetting about robustness since a new version is out. +1 Nice to see a dev echo my sentiments almost word for word exactly. 9 years later I'm still here, still running Gentoo on all my hosts (over 10 at last count excluding VMs). Why? Because Gentoo just.works.right.every.single.time, even on ~arch - and that is an amazing accomplishment for an distro never mind a USE based one. If I want bleeding edge I'll use funtoo or exherbo or unmask everything -. If I want the latest new! improved! shiny! crap re-implemented yet again and badly, there's Ubuntu or nightlies from rawhide. The joy of Gentoo is that it works on just about anything. Stable well-tested code continues to just work for the most part even on slacker arches even if the ebuild is years old. When stable is just a bit too stable for a specific case, we have overlays and /usr/local/portage/cat/pkg. This is why Gentoo works so well, because the weird arches still get to play on the same playground with the other kids. I work at a carrier ISP and you'd be pleasantly surprised to see just how many gentoo-powered vendor POC blackboxes come through the office from vendors wanting to sell their network magic. Business seems to have cottoned onto the idea that gentoo let's you stop wasting time with make and rather fire off emerge, doesn't matter what the silicon is. Slow arches is the price for supporting everything out there. But so what? If slow_arch_X is stuck on some old version of an @system package, who cares? It's not like portage will pick it for an amd64 box. An old ebuild is a file, it sits next to 178,477 files and does no harm, it only gets used on hardware that needs it. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: Dealing with XDG directories in ebuild environment
Alec Warner wrote: Sorry, I work on Portage. What I'm saying is that We are free to change the behavior of *portage* now; rather than waiting for a new EAPI. If an ebuild needs to define EAPI=eapi-next to 'correctly' use XDG_*, well that is someone else's can of worms. Agreed: portage can clear those vars from the env as mgorny stated on the bug, and an xdg.eclass (or w/e) can setup good defaults for packages which need them. Presumably it'd be inherited by gnome and kde eclasses, for example, so most people wouldn't even see it. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Tue, 28 Jan 2014 12:37:40 + Steven J. Long sl...@rathaus.eclipse.co.uk wrote: Please set your client not to embed people's email addresses in your responses: it's spambait in web archives. Thanks. It's as much a spambait as it is listed in the From: header on the web archives; in other words, it are the web archives that need to fix this. Unless you want to keep spamming this sentence to everyone you talk to; and/or besides that, wasting your time on changing the quote lines. Tom Wijsman wrote: moves us closer to bleeding-edge is completely useless; It might be for you; depends, but not completely useless in general. there are already an immense amount of ways to run more up to date software, or you wouldn't have users already doing it. That doesn't detract from the merits of the stabilisation process, which you apparently don't get despite trumpeting your QA membership. The latter leaves me rather worried, to be frank. For there to be a stabilization process there need to be people; and thus, other solutions need to be explored. And thus some of those other solutions are detracting from the merits of the stabilization process. I don't think that's what was being proposed, though. The question was really the old complaint about slow architectures; the -* arch solution sounds like the most reasonable definition of dropping keywords, in the absence of AT communication otherwise. Dropping keywords and specifying -* are a world apart of each other. That's why it's in quotes. Why is there at all if you intend it to be irrelevant to this thread? What? OFC it's relevant; it's just not dropping keywords, it's dropping the ebuild from most archs, and leaving it in-place for those which haven't stabilised a newer version. Dropping a keyword or ebuild means removing it; -* is a step further than that, and thus beyond the scope of this thread. It is there to indicate the package does not work on that particular architecture, it is a world apart from just dropping the keyword; hence it is irrelevant. The former means that it is not ready for wide stable or testing users, the latter means that it has been tested to not work at all; furthermore, we need to explicitly specify which arches in that case. You're missing the point, again. The question was what does dropping keywords mean, when the maintainer has stabilised a newer version on the arch/s s/he has available, but feels that slower archs are holding up that process. Where is that question? *sigh* Are you really saying you don't understand the point of this thread? It's yaf slow archs are slow and i don't want them complaint, which recur every year or so, going back at least 10, though we haven't had this for the last couple of years that I recall; Gentoo has moved pretty quickly. It comes up more from openrc, imo, since the upstream maintainer is also a Gentoo dev, who doesn't release testing (= hard-masked) ebuilds for a core system package. That's an old argument, though, and his call. I mention it simply because the QA process for that package is squashed, in comparison to its importance within the framework. Git ebuilds are not the same as distribution stabilisation. No, I'm not expecting it to change. I'm just pointing out that it's very different to the other packages in the tree (being in-house it hasn't gone through any upstream testing at all, since Gentoo is effectively the upstream), and a case could be made that in fact its QA needs better handling, rather than changing policy to the detriment of archs across the board in response to this complaint. So, where is that question? I'm slightly at a loss as to why it's such a big deal to just leave the old ebuild as-is, given that anyone on a stabled arch should upgrade automatically. It is when you are running the arch that only has the old version. FGS that's up the AT and their users to collaborate on them with. It's not up to some external developer to tell the AT which ebuilds are stable for their arch: that's their *job*. The ebuild dev only gets to request testing, just like users only get to request a version bump. Sometimes users get to put it in their overlay because their version bump, or even a new package request, yields no succes; in the same way, sometimes there are no people that fill in the *job*, hence we come to the point of this thread to look into options to change it. But given that the maintainer feels they don't want that old ebuild around, and that the arch in question has not got round to testing the new one, for whatever reason (it's their call, after all, as to how their arch progresses), instead of simply removing that ebuild, or bumping it to unstable (which makes zero sense), just leave it stable on the slow arch/s in question, and remove the others. There are situations (security,
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Tue, 28 Jan 2014 14:52:59 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: On 28/01/2014 14:37, Steven J. Long wrote: I concur that QA should be focusing on making stable, actually stable, not more bleeding edge. That's not a performance issue as you put it, except in management nuspeek. It's the whole bloody point of the distro, in overarching terms: to test and stabilise robust ebuilds. That process is what leads to better software, not staying at the bleeding-edge and forgetting about robustness since a new version is out. +1 Nice to see a dev echo my sentiments almost word for word exactly. 9 years later I'm still here, still running Gentoo on all my hosts (over 10 at last count excluding VMs). Why? Because Gentoo just.works.right.every.single.time, even on ~arch - and that is an amazing accomplishment for an distro never mind a USE based one. If I want bleeding edge I'll use funtoo or exherbo or unmask everything -. If I want the latest new! improved! shiny! crap re-implemented yet again and badly, there's Ubuntu or nightlies from rawhide. Bleeding edge in this context is ~arch, this is a contradiction. The joy of Gentoo is that it works on just about anything. Stable well-tested code continues to just work for the most part even on slacker arches even if the ebuild is years old. When stable is just a bit too stable for a specific case, we have overlays and /usr/local/portage/cat/pkg. Do you mean unstable? This is why Gentoo works so well, because the weird arches still get to play on the same playground with the other kids. I work at a carrier ISP and you'd be pleasantly surprised to see just how many gentoo-powered vendor POC blackboxes come through the office from vendors wanting to sell their network magic. Business seems to have cottoned onto the idea that gentoo let's you stop wasting time with make and rather fire off emerge, doesn't matter what the silicon is. +1 but can you please consider to stay on the topic of this thread? Slow arches is the price for supporting everything out there. But so what? If slow_arch_X is stuck on some old version of an @system package, who cares? The people whom process gets blocked do. It's not like portage will pick it for an amd64 box. An old ebuild is a file, it sits next to 178,477 files and does no harm, it only gets used on hardware that needs it. It can harm in the long run, as shown in some of the other sub threads; generalizations like does no harm can very well fit as to what you perceive when you would try it out, but it doesn't exclude harm overall. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] dropping redundant stable keywords
Here's a proposal that may address concerns from the long rfc: revisiting our stabilization policy thread. It seems at least one of the problems is that with old ebuilds being stable on slow arches but not the more recent ebuilds, it is a maintenance burden to keep supporting the old ebuilds even on fast arches where it's still stable. Why not allow maintainers to drop redundant stable and even ~arch keywords from their packages? Then these old ebuilds will stay with _only_ slow arch keywords. If they were working back then, they will continue to work now, since there are not that many changes to break things as opposed to faster-moving arches. What do you think? Please let me know if I should clarify this. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dropping redundant stable keywords
On 28/01/14 11:33 AM, Paweł Hajdan, Jr. wrote: Here's a proposal that may address concerns from the long rfc: revisiting our stabilization policy thread. It seems at least one of the problems is that with old ebuilds being stable on slow arches but not the more recent ebuilds, it is a maintenance burden to keep supporting the old ebuilds even on fast arches where it's still stable. Why not allow maintainers to drop redundant stable and even ~arch keywords from their packages? Then these old ebuilds will stay with _only_ slow arch keywords. If they were working back then, they will continue to work now, since there are not that many changes to break things as opposed to faster-moving arches. What do you think? Please let me know if I should clarify this. Paweł I thought there was a general consensus that only the latest stable on a given arch is considered actually-stable. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] dropping redundant stable keywords
On Tue, 28 Jan 2014 08:33:05 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Why not allow maintainers to drop redundant stable and even ~arch keywords from their packages? We already do that to a great extent; only removing the last keyword present is a bad idea, because in that case the package would need to be masked to indicate its brokenness. Otherwise repoman will warn... ;) Then these old ebuilds will stay with _only_ slow arch keywords. We're already doing this too, that's not the problem in that thread; the problem is that ebuilds stay behind (regardless of dropping keywords), because they block progress as well as require extra maintenance. If they were working back then, they will continue to work now, since there are not that many changes to break things as opposed to faster-moving arches. That's a generalization, I can just as well claim here that if a change does break something that it takes longer for that change to be fixed; especially when we're talking about slow architectures. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
On Mon, Jan 27, 2014 at 6:02 PM, Gilles Dartiguelongue e...@gentoo.org wrote:
People are encouraged to provide a prototype implementation of such
eclass in the previously mentioned bug report.
Ok, lets discuss the eclass approach here. The 4 variables we want to
deal with are:
XDG_DATA_HOME
XDG_CONFIG_HOME
XDG_CACHE_HOME
XDG_RUNTIME_DIR
I see basically 3 options:
Option 1: Create directories in ${T} and set the XDG variables to
these directories.
This is the approach used by gnome2-utils.eclass
(gnome2_environment_reset). This would need to be done in a src
phase so that the directories can be created with the right
permissions and owner. The src_prepare or src_configure phase would
work best here.
The new eclass would simply define a function that creates the
directories and exports the XDG variables, much like
gnome2_environment_reset.
Option 2: Set the variables to ${T}
This makes the timing a bit less important since we are not creating
new directories and do not need to worry about permissions so much. I
think this still needs to be done in a phase function to ensure that
${T} is defined. However, this does not really work for
XDG_RUNTIME_DIR.
This would be implemented the same way as option 1, but without the mkdir call.
Option 3: Unset the variables
This should cause applications to default to locations under ${HOME}.
This could be done in global scope (unless I am overlooking something
in PMS), and so it would not require consumers to invoke anything
explicitly.
The eclass would basically be one unset statement.
Thoughts? I am leaning toward option 3, but if someone knows a reason
that will not work please speak up.
Re: [gentoo-dev] dropping redundant stable keywords
On Tue, 28 Jan 2014 08:33:05 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Why not allow maintainers to drop redundant stable and even ~arch keywords from their packages? This is standard practice already. jer
Re: [gentoo-dev] ekeyword written in python from scratch
On Tuesday, January 28, 2014 05:53:52 Jeroen Roovers wrote: On Mon, 27 Jan 2014 18:14:54 -0500 Mike Frysinger wrote: It's more obvious with the fancy colouring if you dislike the color format, then pick a different one. there are a large number available. I didn't intend that at all. A coloured multiline output would be a nice default, though, since not everyone/everywhere is able to display/read in colours. the script respects portage's NOCOLOR setting as well as its color map. so if you've configured your system correctly, it should automatically pick a usable format (and use colors you're used to). if you can't handle colors and you don't have NOCOLOR turned on, then not much i can do about that ;). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] dropping redundant stable keywords
On Tue, Jan 28, 2014 at 12:23 PM, Jeroen Roovers j...@gentoo.org wrote: On Tue, 28 Jan 2014 08:33:05 -0800 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Why not allow maintainers to drop redundant stable and even ~arch keywords from their packages? This is standard practice already. If there is still pain then maybe we need to re-communicate this, or clarify. To me if a package is in the tree and is outdated, but kept for only the benefit of a few lagging archs, then maintainers can close bugs as WONTFIX if they don't pertain to newer versions. If that is the case then there is no cost to keeping the old packages around. The main concern is around maintenance burden. The only way to reduce maintenance burden is to do less maintenance (I haven't heard any suggestions that will somehow make bugs go away). If maintainers are doing more maintenance than they are required to do, then simply reinforcing existing policy could solve the problem. We just need to align around expectations. Rich
[gentoo-dev] Re: rfc: revisiting our stabilization policy
Tom Wijsman posted on Tue, 28 Jan 2014 14:11:48 +0100 as excerpted: [Seven J. Long wrote...] There's plenty of ways to stay on the bleeding-edge; throwing out the baby with the bathwater will only tip you over it, and bork the distro for the rest of us, and everyone down the line. Why do we have the baby in the first place? IOW, it's not throwing the baby out with the bathwater any longer, as the baby long ago died of old age and is now a decaying corpse; there's no baby to throw out any longer! Going with the analogy, that package has become an adult, grown old, got sick, died, and now there are rather obvious and smelly signs of decay! The neighbors complained (filed bugs) about the smell and when the authorities investigated they found the decaying body (the bugs are blocked pending removal of a long dead and should be gone version)! Yet some slow arch is insisting the corpse is not only alive and well, but that it's still married to it, and the people coming to try and take it away to the morgue aka VCS archives as part of the becoming-a-biohazard cleanup (removing the package, thus unblocking those blocked bugs) are somehow abusing their authority! Until the body becomes a biohazard (long dead package presence blocking bug resolution), it's arguably the business of the deluded husband still refusing to believe the death of his wife, but once it becomes a biohazard the rest of the community is now threatened as well and something must be done, thus this thread. [OK, the analogy triggered my imagination and I went with it...] -- 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] Dealing with XDG directories in ebuild environment
On January 28, 2014 12:03:04 PM EST, Mike Gilbert flop...@gentoo.org wrote:
Option 3: Unset the variables
This should cause applications to default to locations under ${HOME}.
Only those applications that properly comply with standards :)
For instance, glib did not start respecting ${HOME} until version 2.36 if I
remember right; before that, unset XDG_* variables would cause
g_get_user_cache_dir() etc. to fall back to something under /root/ no matter
where ${HOME} pointed. Which is the main reason why gnome2_environment_reset()
was created.
Re: [gentoo-dev] Re: rfc: revisiting our stabilization policy
On Wed, 2014-01-29 at 03:15 +, Duncan wrote: Tom Wijsman posted on Tue, 28 Jan 2014 14:11:48 +0100 as excerpted: [Seven J. Long wrote...] There's plenty of ways to stay on the bleeding-edge; throwing out the baby with the bathwater will only tip you over it, and bork the distro for the rest of us, and everyone down the line. Why do we have the baby in the first place? IOW, it's not throwing the baby out with the bathwater any longer, as the baby long ago died of old age and is now a decaying corpse; there's no baby to throw out any longer! Going with the analogy, that package has become an adult, grown old, got sick, died, and now there are rather obvious and smelly signs of decay! The neighbors complained (filed bugs) about the smell and when the authorities investigated they found the decaying body (the bugs are blocked pending removal of a long dead and should be gone version)! Yet some slow arch is insisting the corpse is not only alive and well, but that it's still married to it, and the people coming to try and take it away to the morgue aka VCS archives as part of the becoming-a-biohazard cleanup (removing the package, thus unblocking those blocked bugs) are somehow abusing their authority! Until the body becomes a biohazard (long dead package presence blocking bug resolution), it's arguably the business of the deluded husband still refusing to believe the death of his wife, but once it becomes a biohazard the rest of the community is now threatened as well and something must be done, thus this thread. [OK, the analogy triggered my imagination and I went with it...] That got dark rather quickly... And the problem isn't that it's some dead thing around that no one wants, at least, no one except the team that it's the ONLY working version... so we go from having a decrepit but working version to... no alternative.
Re: [gentoo-dev] Dealing with XDG directories in ebuild environment
[Replying again since my mailer messed up my original message.]
On Tue, 2014-01-28 at 12:03 -0500, Mike Gilbert wrote:
Option 3: Unset the variables
This should cause applications to default to locations under ${HOME}.
This could be done in global scope (unless I am overlooking something
in PMS), and so it would not require consumers to invoke anything
explicitly.
Only those applications that properly comply with standards :)
For instance, glib did not start respecting ${HOME} until version 2.36
if I remember right; before that, unset XDG_* variables would cause
g_get_user_cache_dir() etc. to fall back to something under /root/ no
matter where ${HOME} pointed. Which is the main reason why
gnome2_environment_reset() was created.
[gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer
Currently, there is no really working version of it in the tree: https://bugs.gentoo.org/show_bug.cgi?id=494624 But due its bumps and current bugs, this needs a maintainer... otherwise, I would treeclean it (the problem is that looks like some people use it, but without none of them willing to maintain it, it will be difficult to handle :( )
[gentoo-portage-dev]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLnjOMACgkQRtClrXBQc7UWQAD8CjdMTbWDlIUDL4NPG3ppY5TU V+IIdrAsroAnNNaKq+QA/2q/MVyQmhOMjw2TUhWRkHHph8OiJ9UJxwPQTHeqb518 =6kSU -END PGP SIGNATURE-
Re: [gentoo-portage-dev]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ooops. Disregard. Am resubscribing with my go account. - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLnjR4ACgkQRtClrXBQc7XEZgEAkm5P1fvKPfqwKUOxzEWktbZn 4PVCz5Qvacedu3xKcM8A/2phDSlpffiOfRGD0VyUNtPvoOoI0hMvMYxLqhrhFlT0 =5jaI -END PGP SIGNATURE-
[gentoo-portage-dev] Heads-up regarding dbapi/vartree.py: dblink._unmerge_pkgfiles
Hi all, I've been working on bugs https://bugs.gentoo.org/291589 and https://bugs.gentoo.org/346203 And that led me to start thinking/attempting to refactor a bit the way dblink._unmerge_pkgfiles does things. I've done few things to try and figure out how the whole function works, not heavy coding yet. So, if anybody is working on vartree.py, particularly with dblink and/or _unmerge_pkgfiles let me know so we don't block or mess each other plans. Cheers, -- Jesus Rivero (Neurogeek) Gentoo Developer
