[gentoo-dev] Kernel maintainers that use genpatches
For all the kernel maintainers that use genpatches in their kernel package, please make sure you are subscribed to gentoo-kernel so that I know I can reach all of you easily. Thanks, -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Lead E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index
Re: [gentoo-dev] Re: Change policy about live ebuilds
On 11/21/2010 09:54 PM, Ulrich Mueller wrote: On Sun, 21 Nov 2010, Alexis Ballier wrote: Also, for an ebuild with empty KEYWORDS, repoman will not indicate any problems with dependencies. by default with a p.mask it doesnt either. Yes, but it has an option to enable it, whereas there isn't such an option for empty KEYWORDS. I suppose the repoman --without-mask option can be modified to act as if ACCEPT_KEYWORDS=**. -- Thanks, Zac
Re: [gentoo-dev] Re: Change policy about live ebuilds
On 11/22/2010 09:09 AM, Zac Medico wrote: On 11/21/2010 09:54 PM, Ulrich Mueller wrote: On Sun, 21 Nov 2010, Alexis Ballier wrote: Also, for an ebuild with empty KEYWORDS, repoman will not indicate any problems with dependencies. by default with a p.mask it doesnt either. Yes, but it has an option to enable it, whereas there isn't such an option for empty KEYWORDS. I suppose the repoman --without-mask option can be modified to act as if ACCEPT_KEYWORDS=**. Well, after looking into it, --without-mask isn't necessarily related. Anyway, there's support for checking dependencies with empty KEYWORDS here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9ed6332f2015e41f072f897764f550c5574ea96f -- Thanks, Zac
Re: [gentoo-dev] Re: Change policy about live ebuilds
On Mon, Nov 22, 2010 at 05:30:16PM -0800, Zac Medico wrote: On 11/22/2010 09:09 AM, Zac Medico wrote: On 11/21/2010 09:54 PM, Ulrich Mueller wrote: On Sun, 21 Nov 2010, Alexis Ballier wrote: Also, for an ebuild with empty KEYWORDS, repoman will not indicate any problems with dependencies. by default with a p.mask it doesnt either. Yes, but it has an option to enable it, whereas there isn't such an option for empty KEYWORDS. I suppose the repoman --without-mask option can be modified to act as if ACCEPT_KEYWORDS=**. Well, after looking into it, --without-mask isn't necessarily related. Anyway, there's support for checking dependencies with empty KEYWORDS here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9ed6332f2015e41f072f897764f550c5574ea96f -- Thanks, Zac Thank you. Like the fellow devs said before, KEYWORDS are there to indicate whether a package works for an arch or not. Empty keywords simply means hey, this package is not tested in this arch which is the exact point of a live ebuild. However, p.mask is for more severe issues which might not always apply on live ebuilds. p.mask entry should be *optional* not mandatory. Afterall, few of us use p.mask for live ebuilds. Why not make it official policy anyway? -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org Key ID: 441AC410 Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 pgp3bYBOFu8L5.pgp Description: PGP signature
[gentoo-dev] Cobra as a Python replacement for portage infra...
Hi to all, I am sorry if I'm wasting bandwidth on gentoo-dev with this, but I have found no good answere elsewhere. I have accidentally stumbled on Codelite ( at the first glance ) _great_ IDE for C/C++/Python ( www.codelite.org). While toying with its settings for various language syntaxes, I have glanced at Language named Cobra. Since emerge -s cobra gave me nothing, I took a peek at: www.cobra-language.org. It seems interesting- compiled Python-like language, that is speedwise much closer to C++ than to Python, static/dynamic binding, optional static variable typing etc... My question is, could existing Portage infrastructure be ported to such language with minimal effort and would it be worthwile to even try ? There are many operations that now take portage ages to complete, so it seems that this could be benefitial... Has anyone of Pythonistas tried to give Cobra a look or two ?
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
Erm, link is http://cobra-language.com http://cobra-language.com/
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
dont hijack threads. write a new e-mail from scratch rather than picking some random e-mail and hitting reply and deleting all the text. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
Mike Frysinger vap...@gentoo.org writes: well, not quite. the way we agreed in the past was to not revbump the masked package, but once it was unmasked, we revbump it just once at that point. Is there somewhere which tells users when there are upgrades to toolchain packages which are not revbumped once they have been unmasked and in ~arch? A case in point, glibc-2.12.1-r3. When I rebuilt this following the merging of linux-headers-2.6.36, the rebuilt downloaded about 700K of patches.
[gentoo-dev] Cobra as a Python replacement for portage infra...
( reposted as a new thread. Sorry for inconvenience.) Hi to all, I am sorry if I'm wasting bandwidth on gentoo-dev with this, but I have found no good answere elsewhere. I have accidentally stumbled on Codelite ( at the first glance ) _great_ IDE for C/C++/Python ( http://www.codelite.org ). While toying with its settings for various language syntaxes, I have glanced at Language named Cobra. Since emerge -s cobra gave me nothing, I took a peek at: www.cobra-language.com It seems interesting- compiled Python-like language, that is speedwise much closer to C++ than to Python, static/dynamic binding, optional static variable typing etc... My question is, could existing Portage infrastructure be ported to such language with minimal effort and would it be worthwile to even try ? There are many operations that now take portage ages to complete, so it seems that this could be benefitial... Has anyone of Pythonistas tried to give Cobra a look or two ?
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
On Tue, Nov 23, 2010 at 09:52, Branko Badrljica bran...@avtomatika.com wrote: My question is, could existing Portage infrastructure be ported to such language with minimal effort and would it be worthwile to even try ? I'm guessing not. There are many operations that now take portage ages to complete, so it seems that this could be benefitial... It seems unlikely that just porting Portage to another language would yield a faster implementation soon. Instead, one should focus on identifying bottlenecks in Portage and look at ways to solve them. And if you really want a faster language implementation, maybe look into Unladen Sparrow (slated to be merged into Python 3.3) or PyPy. Has anyone of Pythonistas tried to give Cobra a look or two ? No. And I don't really think this question is very on-topic for gentoo-dev. Cheers, Dirkjan
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Tuesday, November 23, 2010 01:36:15 Graham Murray wrote: Mike Frysinger vap...@gentoo.org writes: well, not quite. the way we agreed in the past was to not revbump the masked package, but once it was unmasked, we revbump it just once at that point. Is there somewhere which tells users when there are upgrades to toolchain packages which are not revbumped once they have been unmasked and in ~arch? if they arent revbumped, then the changes dont matter to you A case in point, glibc-2.12.1-r3. When I rebuilt this following the merging of linux-headers-2.6.36, the rebuilt downloaded about 700K of patches. irrelevant to your KEYWORD -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On 11/23/2010 09:32 AM, Mike Frysinger wrote: On Tuesday, November 23, 2010 01:36:15 Graham Murray wrote: Mike Frysingervap...@gentoo.org writes: well, not quite. the way we agreed in the past was to not revbump the masked package, but once it was unmasked, we revbump it just once at that point. Is there somewhere which tells users when there are upgrades to toolchain packages which are not revbumped once they have been unmasked and in ~arch? if they arent revbumped, then the changes dont matter to you This isn't always the case though, due to developer mistakes. Sometimes when doing emerge -e system, there are changes in /etc files that affect runtime behavior rather than build behavior. And it seems to happen quite often. This is with non-masked packages though. It's the reason I do emerge -e system quite often (every 3 months or so); runtime fixes are applied by devs without revbumps.
