[gentoo-dev] [liveebuild] Standard eclass interface for vcs
Something I'd like to have to ease the live template implementation would be a standardized eclass interface for every vcs, right now every eclass does more or less the same things BUT with slight differences and obviously with different names. Now, I'd like to know which interface you'd consider good. The live ebuild needs a way to preserve a reference (revision/hash/timestamp), right now some eclasses have variables to store the revision to be fetched from which branch that defaults to the main branch and the tip of it if unset. Leaving those unset in the template and saving those post install in the vdb should suffice. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Joe Peterson [EMAIL PROTECTED] wrote: As for why it would be more useful than eerror/ewarn without an argument: it would potentially allow for intelligent context-based coloring of the * (based on surrounding lines). Well, this is true and it isn't... In the case of: ewarn line one eblank ewarn line two Obviously it would be the same as ewarn. However, what about here: ewarn line one eblank elog line two eblank einfo line three I'm not sure how you could make a function like that smart enough to really know what to do... so perhaps since the author is the only one who can really know what colour they intend, they should just use the appropriate ewarn/elog/einfo without args. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Benedikt Morbach [EMAIL PROTECTED] wrote: On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov [EMAIL PROTECTED] wrote: But speaking about names of options - -A and -B are easier to remember as -A stands for above and -B for below and grep users already knew that. for grep -A means after and -B before ;) Maybe we could have '-^' and '-v' then? I do kind of like the idea of making these flags available for people who think it makes their ebuilds prettier... I just don't think I'll even use them. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] OT: OpenRC - thanks Roy
Hi, bit off topic, but there hasn't been much discussion of the OpenRC progress recently - I just wanted to say a bit thanks to Roy for his work on this - it's been working well on my vservers for a good few months now, but I hadn't realised just how fast it was until I converted my mythtv box to OpenRC... At first I thought my splash screen was busted, but no it booted the whole machine and had the window manager running in about the time is used to take the splash screen to start to spin... Absolutely stunning! Thanks Roy and hope we can look forward to this becoming stable in the near future? Ed W -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Jim Ramsay [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 16 Jun 2008 08:34:01 -0400: Joe Peterson [EMAIL PROTECTED] wrote: As for why it would be more useful than eerror/ewarn without an argument: it would potentially allow for intelligent context-based coloring of the * (based on surrounding lines). Well, this is true and it isn't... In the case of: ewarn line one eblank ewarn line two Obviously it would be the same as ewarn. However, what about here: ewarn line one eblank elog line two eblank einfo line three Here's a novel idea, let blank lines be /real/ blank lines! =8^) Seriously, when it's different messages, having a * of /any/ color between them only confuses the case, that they /are/ different messages. If it's paragraphs of the same message, then the color of the * isn't an issue, just make it the same color as that for the other content lines of the message. Sometimes I'll check the messages, and see two or three different logs/ warnings/whatever discussed in what appears to be the same message. That shouldn't be the case. I should be able to scan thru them and as soon as I note that it's a message I've read before, be able to skip to the next one. As it is, I have to read thru the entire message just to see if something new got added to the end. Talking about which, what I'd like would be a date-stamp noting when the message was added, or better yet, some indication of the message being either new or something that's necessary to check each time, even on -r updates and remerges. If I'm updating something that has a number of messages and is frequently updated, I should be able to see immediately the new messages added since the last time I updated, and the ones that always apply. Of course, that's not entirely practical to try to implement, but it'd be nice, and it does reinforce why I'd prefer /real/ blanks between messages, not ones with colored stars that may or may not make it look like the entire group of messages are just one single long message, depending on whether they're all the same color or not. -- 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@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Duncan wrote: Jim Ramsay [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 16 Jun 2008 08:34:01 -0400: Well, this is true and it isn't... In the case of: ewarn line one eblank ewarn line two Obviously it would be the same as ewarn. However, what about here: ewarn line one eblank elog line two eblank einfo line three Yes, this is a tricky case. In the case where the previous and next output lines differ like this, a grey * could be used, or perhaps a green one. However, read more below on my response to Duncan. Here's a novel idea, let blank lines be /real/ blank lines! =8^) Duncan, your point is well-taken. Taking that idea one step further, how about using a neutral color for the * when eblank is used. For example, a medium grey. This would avoid needing logic to guess the correct color, and it would nicely integrate with the rest of the visual flow/look of the output. Although I was originally imagining a context-based color picker, this may be, indeed (as some have pointed out) overkill. The actual issue has mostly to do with conditionals like in the example I gave a while back (in which the blank lines need to be within the conditionals to avoid bunching up of blank lines when the conditionals are false). Currently, I tend to color the * the same as the preceding lines (I have no choice bu to pick some color), but this doesn't really look right, depending on how the conditionals play out. I am leaning more and more toward the idea of a neutral color for eblanks, as this would indeed be trivial to code and it would make output make more sense, especially for conditionals, but for other cases as well. -Joe -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Joe Peterson [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 16 Jun 2008 10:41:55 -0600: I am leaning more and more toward the idea of a neutral color for eblanks, as this would indeed be trivial to code and it would make output make more sense, especially for conditionals, but for other cases as well. Yes, a neutral grey, as you suggested, makes sense. That'd cure my problem of visual separator as well, and as you said, would be trivial to code compared to the complexity of trying to figure out dynamically which color to use. I like it! =8^) -- 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@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
On Sun, 2008-06-15 at 14:02 +0400, Peter Volkov wrote: В Срд, 11/06/2008 в 19:45 -0400, Jim Ramsay пишет: Vlastimil Babka [EMAIL PROTECTED] wrote: I would prefer something that doesn't add extra lines to ebuild. I think I would disagree with you here. I think that having a special 'eblank' or 'eseparator' command is much more readable in an ebuild. Taking into account that as einfo, ewarn and eerror work without any arguments too are there any benefits from eblank/eseparator? Not really and part of my thought process was less lines, less code. Not more or staying the same. No matter what it is, typing anything on a single line to get a new line is more than should be required IMHO. Want a single line of output with blanks lines before and after. One has to code 3 lines in ebuild. That should be 1 line to get 1 comment, with auto-blanks per flag/switch, or etc. 1 line of code 3 lines of output, efficient. 3 lines of code, 3 lines of output. Not so much. -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
On Mon, 2008-06-16 at 17:01 +, Duncan wrote: Joe Peterson [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 16 Jun 2008 10:41:55 -0600: I am leaning more and more toward the idea of a neutral color for eblanks, as this would indeed be trivial to code and it would make output make more sense, especially for conditionals, but for other cases as well. Yes, a neutral grey, as you suggested, makes sense. That'd cure my problem of visual separator as well, and as you said, would be trivial to code compared to the complexity of trying to figure out dynamically which color to use. I like it! =8^) With flags/switches coloring is moot. One can always add a different switch/flag to get a diff color line before or after any one section. Which is easier IMHO, less logic in detecting and setting the right color. Which is pretty moot per my initial thoughts. Which was just to reduce size of ebuilds (slightly), write less code. -- William L. Thomson Jr. amd64/Java/Trustees Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] tetex maintainance (RFH?)
Dear all, app-text/tetex is currently assigned to tex as maintainer, but, in my opinion, that's a lie. I have not seen any movement on tetex bugs for a while. I have opened a tracker bug (#227443, [1]), if someone feels the courage of picking it up. I don't have neither the time nor the will to do it myself. While it has been stated since more than two years on tetex's homepage that people should use texlive [2], we still cannot really remove it from our tree. What I'm planning to do, if nobody comes to maintain it, is to reassign its bugs to maintainer-needed and update its metadata.xml to reflect that. In case we have someone crazy enough to pick it up, I am of course available to try to answer any question. The other option is to p.mask and last rite it, breaking mips and s390 trees, leaving them without tex support at all. This would also leave arm and sh with only ptex as tex support. Thus that is not really an option yet, but I suppose there is no point in waiting forever on this. Regards, Alexis. [1] https://bugs.gentoo.org/show_bug.cgi?id=227443 [2] http://tug.org/teTeX/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
On N, 2008-06-05 at 17:34 +0200, Diego 'Flameeyes' Pettenò wrote: Łukasz Damentko [EMAIL PROTECTED] writes: Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). I wish to nominate Halcy0n, Cardoe and leio. Thanks, I accept. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: tetex maintainance (RFH?)
On Mon, 16 Jun 2008 19:57:45 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: The other option is to p.mask and last rite it, breaking mips and s390 trees, leaving them without tex support at all. This would also leave arm and sh with only ptex as tex support. Thus that is not really an option yet, but I suppose there is no point in waiting forever on this. chutzpah is supposed to be sending me a new O2 so i can ravage its power supply and get mine running again. hopefully i can get mips up to speed soon. i also left gnome hanging, sorry about that guys. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: A few questions to our nominees
On Sat, 14 Jun 2008 22:16:36 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Bernd Steinhauser wrote: Wow, impressive. Actually, you can't be serious... I am. GLEP 54 for quite some time now and it works very well. adds nothing to - and sets usage as is. I just don't see any benefit from your proposal, on the contrary there are issues. No. Yes. And that includes the ordering. No. Yes. GLEP 54 is fine as is. Not one person has expressed approval at your current proprosal, and many people from many different viewpoints have expressed disapproval. Simplying saying no does not make these criticisms go away. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Council nominations deadline
On Sun, 15 Jun 2008 12:16:00 + Jorge Manuel B. S. Vicetto [EMAIL PROTECTED] wrote: The current nominees and the state of their acceptance can be checked on http://www.gentoo.org/proj/en/council/voting-logs/council-2008-nominees.xml If there's someone else you would like to nominate or if you have been nominated and haven't announced yet whether you accept or not, please hurry. Just for completenessess sake, i was nominated and declined. No one likes my idea of teaming up with McDonalds to create the McGentoo meal (each includes a free collectible developer bobblehead and maintainer-needed bug). -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: tetex maintainance (RFH?)
On Mon, 16 Jun 2008 20:45:35 -0600 Ryan Hill [EMAIL PROTECTED] wrote: On Mon, 16 Jun 2008 19:57:45 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: The other option is to p.mask and last rite it, breaking mips and s390 trees, leaving them without tex support at all. This would also leave arm and sh with only ptex as tex support. Thus that is not really an option yet, but I suppose there is no point in waiting forever on this. chutzpah is supposed to be sending me a new O2 so i can ravage its power supply and get mine running again. hopefully i can get mips up to speed soon. i also left gnome hanging, sorry about that guys. By the way, this was not really a rant; if there is anything I can do to help there, feel free to poke me. TeX is something that isn't that hard to test on a distant machine. It's just that I never heard anything back from those arches. Alexis. signature.asc Description: PGP signature
