Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-fonts/font-misc-misc: ChangeLog font-misc-misc-1.0.0.ebuild
On Tue, 23 Nov 2010 14:52:11 -0600 Jeremy Olexa wrote: > On Sat, 20 Nov 2010 17:34:32 + (UTC), Michal Gorny (mgorny) > wrote: > > mgorny 10/11/20 17:34:32 > > > > Modified: ChangeLog > > Removed: font-misc-misc-1.0.0.ebuild > > Log: > > Remove redundant version. > > Since when is it ok to ignore [easily avoided] repoman warnings? My bad. Too many packages mangled over a short period of time, and my eyes missed them. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Change policy about live ebuilds
Markos Chandras said: > Hi there, > > The official policy for live ebuilds is the following one: > > http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html > > I don't quite agree with this policy and I guess most of you don't agree > either looking at the number of live ebuilds/package.mask entries. > > My proposal is to keep empty keywords on live ebuilds without masking > them via package.mask > > Users interpret this as a 'double masking' which in fact it is since > they need to touch two files before they are able to use the package. > > I also know that we can use overlays for that, but distribute the > ebuilds among dev/proj overlays is not always a solution. I'm personally against such a change and would infact like to see all live packages nuked from the tree and moved to some experimental tree. If you move them there, I don't care what policies you apply, but we should try to maintain a solid set of working packages in the main tree, which no one can guarantee with a live ebuild. I know most people aren't going to agree with me, but I felt the need to say it anyway. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Tue, 23 Nov 2010 06:36:15 + Graham Murray wrote: > Mike Frysinger 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. Gotcha. > 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? At least for gcc I put bug numbers and info into the ChangeLog. If you're fanatic you can subscribe to the gentoo-commits ml and set up some filters (that's what I do ;)). Generally if you're not actively hitting a showstopping bug, you don't need the update. And if you are, you're probably on the CC list in bugzilla. > 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. As Mike said, this was adding support for other architectures that were previously not keyworded. -- 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 media-fonts/font-misc-misc: ChangeLog font-misc-misc-1.0.0.ebuild
On Sat, 20 Nov 2010 17:34:32 + (UTC), Michal Gorny (mgorny) wrote: mgorny 10/11/20 17:34:32 Modified: ChangeLog Removed: font-misc-misc-1.0.0.ebuild Log: Remove redundant version. Since when is it ok to ignore [easily avoided] repoman warnings? KEYWORDS.dropped 2 media-fonts/font-misc-misc/font-misc-misc-1.1.0.ebuild: amd64-linux ppc-macos sparc-solaris x64-solaris x86-interix x86-linux x86-macos x86-solaris media-fonts/font-misc-misc/font-misc-misc-1.1.2.ebuild: amd64-linux ppc-macos sparc-solaris x64-solaris x86-interix x86-linux x86-macos x86-solaris which causes issues like https://bugs.gentoo.org/346411 -Jeremy
Re: [gentoo-dev] Re: Change policy about live ebuilds
On 11/23/10 02:46, Markos Chandras wrote: > 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? +1 on exactly that. Sebastian
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
On 11/23/10 11:43, Branko Badrljica wrote: > I figured it still beats classic interpreter. Have you compared to optimized Python byte code, i.e. .pyo files? Sebastian
Re: [gentoo-dev] dev-lang/v8 SONAME
On 10/29/10 11:33 AM, James Rowe wrote: > * "Paweł Hajdan, Jr." (phajdan...@gentoo.org) wrote: >> I'm curious: do you have some more ebuilds using v8? It'd be great to >> add them to the portage tree at some point, if possible. Or maybe >> sunrise overlay... > > We took the easy way out and chose Debian because v8/nodejs were > packaged when we needed them, but we'd prefer to be using Gentoo. That > is the reason I jumped straight in when I saw the mail subject. FYI, dev-lang/v8 is now in ~arch. If you'd like some additional packages in portage like nodejs, please file bugs. Feel free to CC me. Also, let me know if the v8 support in Gentoo can be somehow improved, even if you're not using it yet. I'd like to get feedback from people who are using it for other applications than www-client/chromium. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites for dev-cpp/libgtksourceviewmm
# Gilles Dartiguelongue (23 Nov 2010) # Last rites: dev-cpp/libgtksourceviewmm # Removal: 2010-12-23 # Bug: #298158 # Old name of gtksourceviewmm, not used by anything in tree. # Masked with approval of remi. dev-cpp/libgtksourceviewmm -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
S, René 'Necoro' Neumann piše: Don't forget, that Cobra compiles to C# which then is compiled to .NET CLI. I don't think, that anyone here feels really good about having the core package of Gentoo to require Mono. Uh. I didn't know that. I've read only that it gets compiled into bytecode, which is then compiled into native code. It seemed convoluted, but what the heck, I figured it still beats classic interpreter. I didn't know it uses Mono etc. In that case, forget that I asked - this thing seems awkward from more than one angle...
[gentoo-dev] Re: GCC 4.5 unmasking tomorrow
Hi, Nikos Chantziaras : > On 11/23/2010 09:32 AM, Mike Frysinger wrote: > > On Tuesday, November 23, 2010 01:36:15 Graham Murray wrote: > >> Mike Frysinger 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. Sometimes it is not a mistake but laziness. Some minor fixes in configuration files are quite common. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GCC 4.5 unmasking tomorrow
On Tuesday, November 23, 2010 02:56:17 Nikos Chantziaras wrote: > On 11/23/2010 09:32 AM, Mike Frysinger wrote: > > On Tuesday, November 23, 2010 01:36:15 Graham Murray wrote: > >> Mike Frysinger 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. now you're talking about a bug that should be reported -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Cobra as a Python replacement for portage infra...
Am 23.11.2010 09:52, schrieb Branko Badrljica: > > 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... Don't forget, that Cobra compiles to C# which then is compiled to .NET CLI. I don't think, that anyone here feels really good about having the core package of Gentoo to require Mono. > Has anyone of Pythonistas tried to give Cobra a look or two ? One and a half year ago, yes. Looked nice, but the language then was still in a flow, and I didn't get used to mono and all the 'what libraries is he going to use from where?' stuff. I then even tried to make an ebuild, but this didn't work out. Might be different now. - Necoro signature.asc Description: OpenPGP digital signature
