[gentoo-dev] Re: app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
Ciaran McCreesh posted on Mon, 07 Jun 2010 19:53:22 +0100 as excerpted: > On Mon, 7 Jun 2010 14:44:32 -0400 > Jim Ramsay wrote: >> There is an ancient bug[1] dealing with the "vim-with-x" USE flag. >> >> I think it makes sense to rename this flag from 'vim-with-x' to just >> 'X', but thought I'd raise the issue here since this USE flag has been >> around since before time began. > > It's there because if you break your X you probably want a usable editor > to help you fix it. That's a good point, but it would be much like links, with the X (and several others, jpeg, png, tiff, etc) USE flags. Many people use it primarily or exclusively as a console browser and don't want it broken if those libraries are, despite the fact that they use X (and the image libraries) by default, and thus have those USE flags enabled by default. IOW. that's what package.use is for (with portage, anyway, no idea what the alternative PMs use, but portage is the default, anyway). There are packages where one doesn't want the global flags enabled, and there are mechanisms in place for just that USE (heh!) case. Use 'em for what they're designed for! =:^) -- 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
[gentoo-dev] Retiring
Hi guys, Since I have not been active for a long time and I have no motivation at the moment to spend more time on Gentoo, I'll be retiring as a Gentoo dev. This is just for personal reasons; it's not because of Gentoo. There are only a few packages I was maintaining, so if anyone would like to take over maintenance feel free to change the metadata. The packages are: dev-util/valgrind net-im/pyaim-t net-im/pyicq-t net-im/pymsn-t net-mail/tpop3d net-proxy/http-replicator Regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer griffo...@gentoo.orghttp://www.gentoo.org Gnome Planner Developer griffo...@kfk4ever.com http://live.gnome.org/Planner pgpOH5MprETOa.pgp Description: PGP signature
Re: [gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
Ciaran McCreesh wrote: > On Mon, 7 Jun 2010 23:05:27 +0400 > dev-ran...@mail.ru wrote: > > On Mon, Jun 07, 2010 at 07:53:22PM +0100, Ciaran McCreesh wrote: > > > It's there because if you break your X you probably want a usable > > > editor to help you fix it. > > > > vim, compiled with "vim-with-x" works correctly when X is broken. It > > doesn't enable X11-based UI, like flag "X" suggests. It just enables > > optional connection to x-server to use its clipboard, and vim still > > works if that connection fails. > > It does not, however, work if your X libraries are broken. I certainly agree with you that removing the linkage to a handful of X libraries makes vim more robust if those particular libraries fail. However even with USE="-vim-with-x", there are a number of other libraries that, if broken, will still render vim useless, such as ncurses, perl, python, and ruby. I suspect if one really wants a fail-proof editor, one would either be building vim with USE="minimal" which will ignore the 'vim-with-x' or 'X' USE flag (regardless of what we call it) and also ignore any perl/python/ruby libraries, or one would want something more trim, like busybox vi. Or even better yet, busybox vi with USE="static". Of course changing the USE flag name to 'X' would still let users decide to *not* link their app-editors/vim against any X libraries via per-package USE flags. The main difference in changing the name from 'vim-with-x' to 'X' is that instead of enforcing a default behaviour of "Vim will not link against X unless explicitly told to do so", we will be enforcing a policy of "Vim will link against X when USE='X'". I suppose this is a bit like a transition from an opt-in policy to an opt-out policy, with the caveat that by enabling USE=X globally, a user has already declared their intent: opt-in to linking against X in all packages where there is a choice to do so. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
On Mon, 7 Jun 2010 23:05:27 +0400 dev-ran...@mail.ru wrote: > On Mon, Jun 07, 2010 at 07:53:22PM +0100, Ciaran McCreesh wrote: > > It's there because if you break your X you probably want a usable > > editor to help you fix it. > > vim, compiled with "vim-with-x" works correctly when X is broken. It > doesn't enable X11-based UI, like flag "X" suggests. It just enables > optional connection to x-server to use its clipboard, and vim still > works if that connection fails. It does not, however, work if your X libraries are broken. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
On Mon, Jun 07, 2010 at 07:53:22PM +0100, Ciaran McCreesh wrote: > It's there because if you break your X you probably want a usable > editor to help you fix it. vim, compiled with "vim-with-x" works correctly when X is broken. It doesn't enable X11-based UI, like flag "X" suggests. It just enables optional connection to x-server to use its clipboard, and vim still works if that connection fails. X11-based UI is in separate package, "app-editors/gvim"
Re: [gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
On Mon, 7 Jun 2010 14:44:32 -0400 Jim Ramsay wrote: > There is an ancient bug[1] dealing with the "vim-with-x" USE flag. > > I think it makes sense to rename this flag from 'vim-with-x' to just > 'X', but thought I'd raise the issue here since this USE flag has been > around since before time began. It's there because if you break your X you probably want a usable editor to help you fix it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 7.6.2010 20:44, Jim Ramsay napsal(a): > There is an ancient bug[1] dealing with the "vim-with-x" USE flag. > > I think it makes sense to rename this flag from 'vim-with-x' to just > 'X', but thought I'd raise the issue here since this USE flag has been > around since before time began. > > Does anyone care? > > References: > [1] http://bugs.gentoo.org/94171 > I would support having it under X useflag, when i do new installs i usually have to recompile vim because i forget to enable vim-with-x :] Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwNP6oACgkQHB6c3gNBRYd6XACgoKIa0+25wqdnvjS5RQa9gtP/ MC4AnRA60zU+0J/2pORXnM/jZ/quPAA+ =1LHm -END PGP SIGNATURE-
[gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
There is an ancient bug[1] dealing with the "vim-with-x" USE flag. I think it makes sense to rename this flag from 'vim-with-x' to just 'X', but thought I'd raise the issue here since this USE flag has been around since before time began. Does anyone care? References: [1] http://bugs.gentoo.org/94171 -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
you make valid points regarding the overall improvement of the handling of test suites. I am not opposed to something like that being done... it still seems like there is agreement around the fact that something needs to be done about src_test. currently you cant run a system which generally enables this phase. however, the fact that different people see different problems, should not stop us of from solving any problem. so as a small incremental step, the method of RESTRICTing failing tests is acceptable despite the negative consquences you mention. thanks kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
On 6/7/10 12:10 PM, Thilo Bangert wrote: > as it seems, there is disagreement about the issue among developers. > Perhaps the council would like to settle this, so that we can go on with > our lives. > > i do agree, that all packages should build successfully including the test > phase. RESTRICTing the test and an open bug when this is not the case. Thilo, I'm trying not to touch the issue of test failures at all. Also, my feeling is that although not too many people commented here, we have a consensus in favor of my suggestion. And my suggestion is to replace FEATURES="test" in the developer profile with FEATURES="test test-fail-continue" to make us developers actually use it. I've been running my dev box with FEATURES="test test-fail-continue" and I'm happy. I'm filing bugs for the test failures, but the packages get installed regardless of that (i.e. I get the work done). If it does answer your doubts, then great. If it doesn't, please let me know what I'm missing. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
On 05/04/2010 03:43, Ben de Groot wrote: On 5 April 2010 03:13, Joshua Saddler wrote: Let the renderer take care of the final rendering, as really, tags and markup are all arbitrary. What should matter is how it appears in your webbrowser, since that'll vary from the source view anyways. So why are you such a staunch defender of GuideXML then? If markup is arbitrary really, then why not allow people to use what is convenient? I do think arguing about the syntax is the wrong target (as I think you agree above). The magic of a wiki is: - Focus on the text and not on the formatting - Goal of simplicity to bang in a bunch of content without needing to worry about formatting - Granularity of edits, eg edit a single word and not get overwritten by another change which edits a different single word - Web based editing from any machine without installing stuff - Extremely low barriers to contributing I think these goals could be satisfied by a decent system around GuideXML as much as from an arbitrary Wiki engine? The real magic is in getting lots of users to start contributing and that largely comes from having very few barriers to contributing. If you remember the original Wikipedia it involved requiring to pass some tests to become a contributor and it was basically a closed editor system. It failed dismally... The revamped wikipedia allowed anyone to edit and whilst we can debate the merits of the final product, it's certainly been popular. So I claim that low barriers to entry and ease of editing is the real target - the markup is important, but definitely secondary to the engine itself Good luck Ed W
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Hi Show me a wiki that makes it easy to create tables, for example, compare RadeonProgram from the x.org wiki: http://www.x.org/wiki/RadeonProgram?action=edit ||<-2 style="text-align: center; background-color: #66"> '''Native''' || '''R100''' || '''R200''' || '''R300''' || '''R400''' || '''RS690''' || '''R500''' || '''R600''' || '''R700''' || . . . that's one line of cells. One. Ugly. Compare it to: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap5_pre1 Foo Bar This is an example for indentation more stuff Which is easier to read and instantly comprehend? Yes, but the wiki layout is badly written, you should be comparing it to: || '''Native''' || '''R100''' || '''R200''' || '''R300''' || '''R400''' || '''RS690''' || '''R500''' || '''R600''' || '''R700''' || I think this reads ok? In fact with a bit of thought from some premade styles even the ''' bit should go? By moving to a wiki, you'll lose a huge percentage of what GuideXML can do, in exchange for "quicker" and "easier" editing and creation of docs, though neither of these have been qualified. I think this summarises the basic tradeoff - you trade editing speed for "simplicity" of syntax and readability. Clearly as your example shows it's possible to write complicated looking stuff in any syntax though, but in general wiki's win where the content is most important and styling is done separately using CSS (a bit like guideXML really) As some others on this list have mentioned, wiki syntax is downright ugly and simply not as consistent or readable as plain ol' XML or HTML. I think this is a point of contention. Certainly it was a design goal for the wiki syntax to be simple and easily readable, but one man's "simple" is another mans XML... From what I've seen, the biggest objection to GuideXML is folks don't want to take the time to learn a few tags. Well, you'll have to learn tags and syntax for either system, so pick your poison. I've yet to see a wiki that even has as much sense as HTML, which is pretty low on the totem pole of consistency. Actually I think GuideXML is excellent - if there is a wiki style engine which allows you to post in GuideXML then we should do it? I think it's not an objection to the GuideXML which is the problem, but creating a system which can be edited quickly and easily in a granular fashion. Eg imagine all the guideXML docs being in a git repo with open access to pull/push changes - you could build a web engine around that which rebuilds the web pages interactively as people push edits and this would be cool! In the meantime wiki's are just trying to solve the same goal of easy edits with small granularity of edits However, I love the idea of a "wiki" based around git using GuideXML! (probably it kind of works like this right now - I think it's the access control which is the secret sauce...) I ain't out to stop ya'll from using a wiki. I do agree that they have some advantages. However, I will point out how limited wikis are. They're not a magic bullet that will solve all our problems. Definitely. Good luck Ed W
Re: [gentoo-dev] Re: RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
On Mon, 7 Jun 2010 12:10:04 +0200 Thilo Bangert wrote: > i do agree, that all packages should build successfully including the > test phase. RESTRICTing the test and an open bug when this is not the > case. I see more and more calls for either 1) "fixing the test suite", as if that is suddenly not an UPSTREAM issue but the ebuilds' maintainers' or 2) setting RESTRICT=test, which would have everyone ignore the useful aspects of a package's test suite. The main problem with RESTRICT=test is that it's too restrictive - it prevents a normal emerge(1) or ebuild(1) run from entering the test phase at all, with no way to work around it, except by editing the ebuild to remove the restriction. == marga /keeps/gentoo/local/app-portage/foobar # ebuild foobar-1.ebuild test Forcing test. * checking ebuild checksums ;-) ...[ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * CPV: app-portage/foobar-1 * REPO: JeR * USE: elibc_glibc kernel_linux ppc test userland_GNU >>> Unpacking source... >>> Source unpacked in /var/tmp/portage/app-portage/foobar-1/work >>> Compiling source in /var/tmp/portage/app-portage/foobar-1/work ... >>> Source compiled. * Skipping make test/check due to ebuild restriction. >>> Test phase [explicitly disabled]: app-portage/foobar-1 marga /keeps/gentoo/local/app-portage/foobar # cat foobar-1.ebuild # Copyright 1999-2010 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ SLOT="0" RESTRICT="test" == If you believe that test suites are a Good Thing, then you should view RESTRICT=test as the ultimate solution to fix the problem of a broken test suite that will never be fixed. Now, in case a test suite could actually be destructive, dangerous to run on an unprepared system, then there RESTRICT=test is a fine solution. When instead a test suite should do a SKIP but erroneously does a FAIL, then RESTRICT=test is not the solution. Fixing the test suite is, but then that's not the maintainer's problem, but upstream's. Oddly enough we have QA checks in place (for ICEs, for instance) that direct users directly to upstream (through the HOMEPAGE variable), when it's suddenly the maintainer's problem if a package fails its test suite (because of FEATURES=userpriv or a missing kernel feature, perhaps - nothing the maintainer can prepare the user's system for). There's currently no way to describe the test suite's requirements to the user except by building in many checks or perhaps by simply listing them in an ewarn. Since the variable will be passed on to every next ebuild you're stuck with it, unless you are prepared to edit out RESTRICT=test, see if the new version still fails, then edit it in again when you find nothing has been fixed. This in turn doesn't make for easy ebuild maintenance. There's something wrong with the way we do test phases, the way some of us rely on them to foretell the stability or quality of a package version, and the way we stop test suites from failing (by only having a binary RESTRICT=test). We could easily extend metadata.xml to describe the test phase to the developer and user right now, for one thing, and aim for a more automated approach to fixing the binary problem in the future. Another solution is to change how emerge(1) and ebuild(1) deal with RESTRICT=test. On the one hand FEATURES=test should be enabled by testers and users with caution, as many test suites simply don't do what you might think they do - there is no guarantee that a program will run well in the Real World by merely satisfying its (limited?) test conditions. With that in mind, RESTRICT=test should perhaps not block testing the way that it does now. jer
Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05-06-2010 11:12, Anders Hellgren wrote: > On Sat, 5 Jun 2010, Torsten Veller wrote: > >> Hello fellow developers and users. >> >> Nominations for the Gentoo Council 2010/2011 are now open for the next >> two weeks (until 23:59 UTC, 18/06/2010). >> >> All nominations must be sent to the gentoo-dev mailing list. If you >> were nominated and want to run, you have to accept your nomination on >> the same mailing list. >> > > I'd like to nominate jmbsvicetto and solar. Anders, thank you for the nomination. I accept. > /Anders - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMDNhxAAoJEC8ZTXQF1qEPTu4P+QEXi2tAI5XBp1IVqcWd9BqK VQzX8jZ+XRbzEjMmBsi1rYW64fHPrOLxBBZlpfqh9E5rSnGYREnJt+tDP5TGnw2a OlyLRBv3LX1RlLpgVN5RyNxse1o+vYylZiJ94feORokhmhBJbi/siSRnbfpCb8m2 xMzC1sjS6xrWdVipcG1I3A/fg/qXOGq1Ol4l6V1b+6ipCAbdsnMsfKK1dlxiahFj /rjm5ICvvBKxWrSMsZ6CqxYjxgY4QEul9sHC6su0Fp/tOGHJ5hH3x1i/wxec8m4A 5Jn9KBWvvB06SLOEUoKGcP+DxP9tCEDvaK8TFH9ZDbwEw0ySTzMw/7zqpkT0wl5p glZyRBOyvE7QdT0jtNtAppKiTPBv0Din2IIFIXtoAx+IL6/U1U+UpRjl3giFQRFL c5gAKg4BrcPtMiAvgAqyhOaOTQGq7ysRvH4hze3TuddzpEbojGl4iFWcFd2vJYUD TQjm2dkhWFYLFIJ2AAiSuCSRUVE1WgMG2ZLwtBVSHs9iK/AcC/KgwNCcOuAR15gv q08OohrjN+azZeRWlv2d7tXascXFX3cJMOwQmmxZzrH9mraxqOLI50CaYHc8DJNF XLv+G5lg3F9TybjIqWnKy/m+0nfRZN3FiQTRF6Hw9Mld05bzdUlosmWNBTLMg3ly n3QvFxNRud6SbCy2Wyj2 =zvGx -END PGP SIGNATURE-
Re: [gentoo-dev] Re: RFC: changing the developer profile: FEATURES="test" -> FEATURES="test-fail-continue"
Ryan Hill said: > On Fri, 04 Jun 2010 17:11:45 +0200 > > "Paweł Hajdan, Jr." wrote: > > What do you think about doing the following change in > > /usr/portage/profiles/targets/developer/make.defaults: > > > > replace "test" with "test-fail-continue" to make it just less > > frustrating (we still have a lot of test failures) > > > > Hopefully that will also make more of us use the developer profile, > > and detect test failures. > > > > What do you think? > > I would say it's an improvement only because it might prevent one or > two people from completely disabling it first chance they get. :) > > IMO, test failures should be given the same status as build failures. > Packages shouldn't be commited until they're fixed or bypassed. > Following that reasoning, FEATURES="test" is the correct setting for > the dev profile. It _should_ be annoying when you hit it, that's the > point. Fix it! What's the point of even having a test suite if it > always fails? You'd be better off to RESTRICT it and save yourself > some bug reports from me and all the other users you're foisting build > errors on. > > But in the real world it seems it's just never going to happen. I've > been arguing this for years but people simply don't care. It doesn't > help that we don't have any finer control than "on" or "off". I'd > like to be able to say things like "these tests should only be run by > developers" or "some failures are normal" or "hope you have 10 hours > to run this" or "don't run these as root" or "don't run tests on arm" > etc etc. I'd like a pony while I'm at it. > > Sorry about the rant. This is one of my biggest long-standing > annoyances. > > Um, so yeah. For it! as it seems, there is disagreement about the issue among developers. Perhaps the council would like to settle this, so that we can go on with our lives. i do agree, that all packages should build successfully including the test phase. RESTRICTing the test and an open bug when this is not the case. thanks Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open
On 06/05/10 13:36, Dirkjan Ochtman wrote: > On Sat, Jun 5, 2010 at 02:00, Torsten Veller wrote: >> Nominations for the Gentoo Council 2010/2011 are now open for the next >> two weeks (until 23:59 UTC, 18/06/2010). > > I'd like to nominate patrick I accept the nomination. > and vapier. > > Cheers, > > Dirkjan >
