Re: [gentoo-dev] Modular X unported packages
Donnie Berkholz wrote: > With the help of Brian Harring, we've now got a check for unported > packages. It indicates 207 unported packages, of which 93 can > potentially be fixed by stabilizing newer versions and pulling unported > ebuilds from the tree. Having fun again here ... I've made a list of the "violators" (herds or devs) with more than 1 package. There are 62 unmaintained packages, for which the x11 team will probably end up filing stable bugs ourselves when it's possible to fix by stabling. As long as your unported ebuilds are in the tree, there will be many dependency issues because we're forced to leave virtual/x11-7 in to provide for their broken deps. That was a hack to begin with, and it needs to end. 53 xfce 11 video 10 sound 9 desktop-wm 8 media-video 7 cjk 7 afterstep 6 graphics 6 desktop-misc 5 sci 5 taviso 4 stuart 4 dragonheart 3 netmon 3 commonbox 3 vapier 2 zypher 2 usata 2 lordvan 2 dholm 2 azarah 2 X11-drivers 2 net-p2p 2 net-news 2 media-tv 2 games 2 cluster Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: > Correct me if I'm wrong, but this has nothing to do with being > interactive or not. To me, an ebuild that dies (intentionally or due > to a build error) isn't interactive at all. Their phrase, not mine. ;) I think the idea is you should be able to emerge -e world and walk away and not have anything interrupt the process thus requiring the user interact with the system. I'm personally for dying as soon as possible, like before the actual compiling starts, but I don't think that's possible yet. > If a package is known not to work with a certain flag, being able to > emerge it won't change the fact that it doesn't run. If a package is known to not work with a certain flag it should be filtered so it does run. > Plus, if the > solution is considered good for python, I don't understand why it > wouldn't be good for any other package. Are you saying that Paul's > proposition of having the python ebuild die on use of --fast-math > isn't good ? Yes. If yes, why ? And what is your better idea ? I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet ;)) message. * The -ffast-math option is known to break this package and has been filtered from your CFLAGS. Link to Safe CFLAGS wiki page, blah blah blah. I like this better because it informs me of what I did wrong, what was done to correct it, and how I can correct it for myself in the future if I choose to. I don't like artificial barriers and things not working without immediate attention. Call me lazy but it's annoying when you know what you're doing yet you have to jump through hoops to get it done. > Which is exactly the reason why we could benefit of something that > enables us to manage this in a clean and safe way. I'm not saying I > have a candidate for that "something", but I wanted to discuss if > there was an interest in it. > > Let's take again the example of -ftracer which can be enabled by the > -fprofile-use meta-flag. Imagine we have a mechanism somewhere (again, > the reason I'm being vague is that my point isn't to discuss > implementation just yet) that adds -fno-tracer to CFLAGS. In this > case, you're covered wether -ftracer was added directly on indirectly > by fprofile-use, which actually simplifies the number of flags that > you need to blacklist. Thus ebuilds don't have to take care of it, > bugs don't pour into bugzie, and Jakub can avoid overheating. Do you mean for ebuilds that knowingly break with -ftracer, or for everything? There are packages that expect to be built with certain flags; not -ftracer, but others. Fex, libao needs -ffast-math ;). Also, what about ebuilds that do use -fprofile, like gcc itself? I know toolchain.eclass strips all flags, I'm just using it as an example. If you mean just for packages that break with certain flags then absolutely. But such a mechanism would have to be maintained for every different GCC version, since -fprofile might not invoke -ftracer in every version, and indeed some versions might not even recognize -fno-tracer and bail with an error. >> Users playing with CFLAGS get to keep the pieces. Trying to >> dummy-proof the >> system doesn't help anyone but the dummies. ;) > > I'm one of those devs who care for our users. I think it's dangerous > to try and categorize users in, for example, dummies and non-dummies, > as you say. Who are we to judge this or that user is a dummy ? Plus, > we all are the dummy of somebody else. Okay, bad joke aside, there are always going to be users who tweak GCC flags. This has to be expected, as they're mysterious, and technical, and kinda cool. I like the tweaker crowd and I am a dummy, so no offense was intended to either groups. I meant that if you safety-proof a complex system, people never learn that they're doing anything wrong in the first place. > Anyway, I was thinking more in terms of making the job of developers, > bug wranglers, and poor old bugzilla easier, cleaner, safer. How many > bugs do we have that are due to dangerous flags ? Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to automate this in any sane way. > How much time and > effort could we save if we didn't have those ? Also, I was thinking > that if a good solution was found to deal with a dangerous flag in a > certain package, maybe it was a good idea to extend this solution to > other packages. And finally, if said solution becomes common, maybe > it's a good idea to make it system-wide with a possibility to override > the setting by the user or the ebuild. It seems we already have > per-package CFLAGS, so part of this, at least, is already implemented. Right, but how are people supposed to learn something is dangerous if all the sharp edges have been filed off? And how can you decide which flags are "bad" and "good" on a global level when for the most part compiler parameters are akin to black magic? I guess in the end it comes down to personal philosophies on how to handle this, and I'm
Re: [gentoo-dev] Pending Removal of $KV
On Tue, 2006-07-11 at 07:24 +0900, Georgi Georgiev wrote: > - 23 only make .config checks (should be non-fatal anyway) I couldn't agree more. This bites us in the ass every single release. People who make .config checks fatal should be forced to maintain mozilla-* for a month... ;] > - 4 use linux-info to modify runtime behavior Hopefully, these will go away soon, too. Again, this is something that constantly bites us when it comes to releases. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Tue, Jul 11, 2006 at 12:50:12PM +0200, Jose Luis Rivero (YosWinK) wrote: > I would like to nominate kloeri (Bryan Østergaard) to the council if he has > enough free time and if his devrel lead position (where > his work is priceless) doesn't block the nomination. Damn, i wanted to do that for a few days already and now you beat me to it. ;-) cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgppI7j8SVgP0.pgp Description: PGP signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
On Monday 10 July 2006 10:08, Jakub Moc wrote: > Robin H. Johnson wrote: > > On Mon, Jul 10, 2006 at 04:36:55AM +0200, Diego 'Flameeyes' Petten?? wrote: > >> On Monday 10 July 2006 02:25, Luca Barbato wrote: > >>> c is simpler. I like it. > >> > >> Yes, of course if _all wranglers_ respected metadata, instead of > >> stopping to tag and assigning to that even when a particular > >> maintainer is listed. > > > > Actually, this isn't that simple at the moment. There are packages that > > directly list me as the maintainer, but I want bugs for them assigned to > > the herd by default - so that the other folk in the herd can find them > > quickly. > > > > Perhaps this could be alleviated with an explicit assign-to field in > > package metadata? At the same time, it should have an explicit cc-to > > field, for cases where the maintainer is not in the herd. > > Well, that reminds me - just stick [EMAIL PROTECTED] (or whatever else) to > maintainer field then and put it first, enough of a hint for me :) Should we then use this metadata-file (maintainer before herd tag): http://www.gentoo.org/dtd/metadata.dtd";> [EMAIL PROTECTED] Gentoo VDR Project media-tv Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgprl0Gwn2pR4.pgp Description: PGP signature
Re: [gentoo-dev] new herd: vdr - Comprehension
On Sunday 09 July 2006 19:17, Matthias Schwarzott wrote: We will use the alternative c) - as lu_zero and flameeyes suggested. > c) Using media-tv as herd and [EMAIL PROTECTED] (project's mail-address) as > maintainer. Matthias -- Matthias Schwarzott Gentoo Developer http://www.gentoo.org pgpgfOuSENanO.pgp Description: PGP signature
Re: [gentoo-dev] Last rites for net-misc/ssh
Hi, On 7/11/06, Gustavo Felisberto <[EMAIL PROTECTED]> wrote: I'm removing net-misc/ssh from the tree as Tectia no longer provides a "free" version of they're ssh client and server. The last update to this package was one year and half so I'm a bit afraid of security issues that might exist that were not reported. Have you tried contacting them, and asking them for a license for their product, so that you can provide an ebuild for the non-free version? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for net-misc/ssh
I'm removing net-misc/ssh from the tree as Tectia no longer provides a "free" version of they're ssh client and server. The last update to this package was one year and half so I'm a bit afraid of security issues that might exist that were not reported. -- Gustavo Felisberto (HumpBack) Web: http://dev.gentoo.org/~humpback Blog: http://blog.felisberto.net/ It's most certainly GNU/Linux, not Linux. Read more at http://www.gnu.org/gnu/why-gnu-linux.html . - signature.asc Description: OpenPGP digital signature
[gentoo-dev] New USE_EXPAND flag: FOO2ZJS_DEVICES
Hi, As proposed in http://bugs.gentoo.org/show_bug.cgi?id=139987 I would like to add a flag to the foo2zjs printer driver ebuild to select if everything is downloaded or only parts. This makes sense to be done in a special variable. I want to use FOO2ZJS_DEVICES because that seems to be common, I have not seen _DRIVERS somewhere yet and _CARDS does not fit. Any objections? Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
Mike Frysinger wrote: well it's about that time of the year ... time for nominating people for the next Gentoo Council I would like to nominate kloeri (Bryan Østergaard) to the council if he has enough free time and if his devrel lead position (where his work is priceless) doesn't block the nomination. Thanks. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Doc Gentoo/Alpha -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On Mon, 10 Jul 2006 01:18:07 -0500 Andrew Gaffney <[EMAIL PROTECTED]> wrote: | Even if you modify the profile to "mask" gcc-3.3.x, it won't force | people to unmerge their existing gcc-3.3.x since it's slotted and | they would already have gcc-3.4.x emerged, correct? And if we can't | force them to unmerge it, we can't force them to switch which gcc | version is active. Masking in the profile would have no effect if | this is true. Yeah. It's more of a tradition thing than a strict technological enforcement. In the past we've always considered any GCC allowed by the profile (that is to say, not masked or out of the packages range) to be valid. Refusing to take bugs from people who're using a GCC permitted by the profile is rather unfair... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New virtuals: virtual/jre and virtual/jdk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joshua Nichols wrote:
> Krzysiek Pawlik wrote:
>> Two new new-style virtuals have been added today to the tree:
>>
>> - virtual/jdk
>> - virtual/jre
>>
>> This allows migration to generation 2 of Java build system to advance.
>> All virtual/{jdk,jre} have been removed from profiles. The bug for this
>> was #138747.
>>
>>
> Something worth mentioning... If you have problems where dependencies
> fail to resolve, like dev-java/blackdown-1.5, or dev-java/kaffe-1.4, it
> means you have some stale PROVIDE files kicking around. You will likely
> want to run the following to find them:
>
> find /var/db/pkg -name PROVIDE | xargs egrep -l 'virtual/jdk|virtual/jre'
>
> This should give you a list of files to you'll want to delete.
>
> - Josh
Might want to stick this in the java doc(s) then, if you think it's relevant for
any Troubleshooting sections.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEs2nUrsJQqN81j74RAjzbAKC2MsAR5gjzXXs1sAr5ir6lMpLd1gCgjV5i
sh0IqcjFtTsy7Dqe83qgj4g=
=F1Co
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Removing www-servers/resin-ee
Anatoly Shipitsin wrote: >> I've masked www-servers/resin-ee on 1 July, it will be removed from tree >> around friday (14 July) - it's old, binary and there's no version 3 of >> it. Please use www-servers/resin. > it's not replaced by resin pro ? It is - not yet in portage. -- Krzysiek Pawlik key id: 0xBC51 desktop-misc, desktop-dock, desktop-wm, x86, java, apache... signature.asc Description: OpenPGP digital signature
[gentoo-dev] Looking for mozilla maintainers
Hi all. As our old mozilla maintainer was retired a few days ago, we're urgently looking for new maintainers to help with all the mozilla related ebuilds. Stuart Longland (redhatter) kindly offered his assistance with mozilla but to avoid quick burnout we need a couple more persons. Depending on feedback from existing developers I'm probably also going to recruit some new developers for this but I'd like to cover any immediate issues asap. This means that existing ebuild developers are my first priority. Please poke me on irc if you're interested in this (nick is kloeri). Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
