Re: [gentoo-portage-dev] OT: Screen bragging. Was: [PROPOSAL] Don't split user visible messages across multiple lines
On 03/17/2017 03:51 AM, Brian Dolbec wrote: On Fri, 17 Mar 2017 06:58:23 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: Brian Dolbec posted on Thu, 16 Mar 2017 01:08:30 -0700 as excerpted: We could also increase the max. line length to something like 120 or 130. I think more people should chime in on that. I use vertical splits for the screen when coding, and 120 characters is too long for me, but if the preferred width ends up changing to 120 or 130 I can work with it. You need to get some large 4K monitors... love them :D I treated myself to two 28 inch ones during boxing week sales. My aging eyes love them :) They are so much better than my old 24 inch 1080p monitors. Those were getting tired/starting to loos clarity along with my eyes working at them all week long. I now work with larger fonts which are still physically smaller than my old monitors, but so much clearer. My eyes don't get nearly so tired as they did with my other monitors. ;) Posting resistance failing... Try a 65-inch 4K with a 48-inch 1080p (now the older monitor, often running youtube full-screen) off to the side. =:^) (They're actually TVs used as monitors via the HDMI input, no actual TV hooked up. Above about 32-inch, TVs tend to be cheaper than stand-alone monitors and of course they're the same 4K high or full-hd lower resolution these days.) Six 1280x1080 working windows three wide by two stacked on the 65" 4k, still set for 96 dpi standard, FreeMono Bold 9.0 in my konsole windows, yields: $ echo $COLUMNS x $LINES 179 x 78 And that's six of those on the 65" 4K, PLUS the full-screen 1080p youtube or whatever window on the 48". =:^) This is the first time I can honestly say I have enough screen space that most of the time I'm not actively using it all. =:^) Yeah, I've seen lots of those types of setups. Just a few years ago when I was an A/C mechanic for my day job, I serviced A/C systems at numerous business's trading floors, where many stations ran 2 or 3 pc's mostly to house/power the video cards to drive 4,6, sometimes 8 monitors in a dual high setups, then numerous big screens overhead in various places around the floor... I don't think I could handle the large ones like you have, my eyes haven't got the focal range for that anymore. As it is, I recently had to pull my monitors closer about 8 inches because my eyes were getting too tired by the end of the week. They were just too close to the limits of my eyes and glasses. I do need to get a decent video card to drive these new 4K's, then maybe I'll think about re-connecting the old 24 inch 1080p's back up to the old card too ;) But if I really needed more screen space, I'd pick up 2 more of these 4k's, 2 video cards and spin them vertical ;) That could make for a great driving/flight simulator :D Since we are off topic and I have crappy eyes that have required a couple of surgeries. My current setup that works well is two 40" 4K TV's set to 1080p. Doesn't give me the real estate that 4k would, but my eyeballs love the big crisp fonts and it is more space than I had before.
Re: [gentoo-portage-dev] gentoolkit.git repository reorganized
On 10/21/2015 11:48 PM, Mike Frysinger wrote: > On 22 Oct 2015 00:45, Mike Frysinger wrote: >> On 21 Oct 2015 16:35, Paul Varner wrote: >>> On 10/20/2015 03:34 AM, Alexander Berntsen wrote: >>>> On 15/10/15 19:42, Paul Varner wrote: >>>>> Over the last couple of days, I have done the following: >>>>> 1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git >>>>> repository >>>>> 2. Moved the gentoolkit branch to master on the >>>>> gentoolkit.git repository >>>> Why did you not just make gentoolkit master, and leave gentoolkit-dev as >>>> a branch? That's certainly the common way of using git. >>>> >>> Mainly, because at this point gentoolkit and gentoolkit-dev are now >>> almost completely separate code bases as well as being separate packages. >>> >>> They share a common ancestry and that can be seen looking through the >>> commit log, but starting with gentoolkit-0.2.5, gentoolkit started >>> migrating to python as the only scripting language and utilizing the >>> Portage API with setuptools as the build system. The two remaining bash >>> scripts are being rewritten in python and when that is complete, they >>> will be completely separate code bases. >>> >>> gentoolkit-dev has stayed as a collection of stand-alone scripts written >>> in multiple languages intended mainly for Gentoo developers. >>> >>> Since they really do not share any code anymore, it did not make sense >>> to me keeping gentoolkit-dev as a branch and it should be in its own >>> repository. >> echangelog is the only non-shell/python script, and arguably not useful >> anymore. repoman itself has a changelog option, and since the move to >> git, we don't commit ChangeLog entries anymore. i would just punt it. >> >> there's also eviewcvs written in perl, but that's also dead now that >> we use git, so it should be punted. >> >> that really only leaves three: >> - ebump - bash >> - ekeyword - python >> - imlate - python >> >> why not merge them into a single repo ? you can have a dev/ subdir >> for scripts that are more developer oriented and put them behind a >> USE=dev flag. > another reason i think there should be one: gentoolkit-dev rarely sees > releases, nor is it clear who is supposed to be making them, nor does > it seem like a good use of time to have independent builds/packages. > since gentoolkit is getting rolled, updates could finally go out. > > case in point: ekeyword was rewritten almost 2 years ago and it still > hasn't seen a release. > -mike Thanks for the feedback, this is one reason why I've kept the branch and have not deleted it yet. As far as releases for gentoolkit-dev, idl0r was managing it, but as you have observed that has not been happening. Mike, I know you're busy with other stuff, but if you ever want to see a new gentoolkit/gentoolkit-dev release, consider this your authorization to just do it. The README.dev files state how to make releases. Since, the tools have dwindled down in gentoolkit-dev, I do think it does make sense to keep it in the same repo and merge the packages together behind a USE flag. I will revert the commit, that emptied the genttolkit-dev branch and ask mgorny to nuke the new gentoolkit-dev repository. As I get time, I will work towards moving the gentoolkit-dev tools into gentoolkit and putting them behind a USE flag in the ebuild. Regards, Paul
[gentoo-portage-dev] gentoolkit.git repository reorganized
All: Due to historical reasons the gentoolkit git repository was organized with two branches, gentoolkit and gentoolkit-dev with master effectively being an empty branch. This was confusing to contributers and with git did not make a lot of sense. Over the last couple of days, I have done the following: 1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git repository 2. Moved the gentoolkit branch to master on the gentoolkit.git repository The one thing left to do is to remove the gentoolkit-dev branch from the gentoolkit repository, I'm going to wait for several days to make sure that there is nothing missing in the gentoolkit-dev repo before removing it. Due to the nature of the changes to the repos, I've found that it is easiest to backup the current clone and re-clone the repository to make sure that everything is up to date with the changes. Regards, Paul
[gentoo-portage-dev] Tools-Portage Lead
All: I inherited the tools-portage lead position on 12/1/2008 when genone retired from Gentoo, and have been the lead since that time. Reading GLEP-39, it is not clear to me if a sub-project needs to have their leads elected or not. Anyhow, I'm asking the following: 1. Do we want to elect a tools-portage lead? 2. Do we want the portage lead to select/confirm the tools-portage lead when they are elected? 3. Do we just want continue as we have been until I get tired of the position and step down? 4. Any option not already listed. Since the tools-portage team is quite small, there hasn't been any real issues with the leadership or running the team, our problems are lack of manpower and time. I'm only asking this since the Council would like all projects to consider electing or confirming the project lead(s) If we do decide to hold an election, I will like to nominate myself and Brian as co-leads. Regards, Paul
Re: [gentoo-portage-dev] [RFC] Package description index file format for faster emerge search actions
On 10/14/14 02:40, Zac Medico wrote: Hi, As we all know, emerge --search/--searchdesc actions are embarrassingly slow (from most users' perspectives, anyway), especially in comparison to external tools like eix and esearch. Wouldn't it be nice if the performance of emerge's search functionality was more competitive with other offerings? Then, external search tools might not be seen as an absolute necessity. In order to solve this problem, I suggest that we add support for a package description index file format. For example, the attached script will generate a suitable index formatted as series of lines like this: sys-apps/sandbox-1.6-r2,2.3-r1,2.4,2.5,2.6-r1: sandbox'd LD_PRELOAD hack Using this format, the index file for the entire gentoo-x86 repository consumes approximately 1.5 MB. The whole file can be quickly searched as a stream (the whole file need not be in memory at once), yielding emerge --search/--searchdesc performance that will be competitive with app-portage/esearch. The index can either be generated on the server side by egencache, or on the client side by a post emerge --sync hook. It makes sense to support both modes of operation, so that server side generation is purely optional. What do others think about this proposal? Please do this. Once this is in place, I will probably deprecate esearch and point users to emerge for basic searching and eix for advanced searching. Regards, Paul
Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
On 11/21/13 03:21, Alexander Berntsen wrote: After talking to zmedico privately, and raising the issue and discussing it with people in bug #481578[0], I implemented the behaviour described in a comment[1] on said bug. I sent this to zmedico almost two months ago, but it doesn't look like he's coming back any time soon, so I'm sending it here and ask someone to review and commit it (a role zmedico has typically played for me, as well as being my mentor and guide and so on and so forth for Portage hacking). [0] https://bugs.gentoo.org/show_bug.cgi?id=481578 [1] https://bugs.gentoo.org/show_bug.cgi?id=481578#c10 I turn off autounmask because I don't find it useful. I have found too many times when it wants me to unmask something that really doesn't need to be unmasked. It is not clear to me from the patches if I can still do that. Regards, Paul
Re: [gentoo-portage-dev] tools-portage packages
Based upon all of the responses, this is the list of completely unmaintained packages managed by tools-portage. If no one objects, I will send this list to gentoo-dev in a few days asking for maintainers or they will be last rited. app-portage/deltup app-portage/epm app-portage/maintainer-helper app-portage/splat app-portage/ufed Regards, Paul
[gentoo-portage-dev] tools-portage packages
All:
Sending this here before I send to the gentoo-dev list. Below is the
list of packages that are managed by the tools-portage herd and their
maintainer (if any). I know we have several packages in the herd that
are not being maintained and I would like to either get a maintainer or
last rite the package. I've included comments on what I know about the
packages.
$ equery meta -m $(fgrep tools-portage /usr/portage/*/*/metadata.xml |
awk -F'/' '{printf(%s/%s\n, $4, $5)}')
* app-portage/deltup [gentoo]
None specified
-- I don't know anything about this package.
* app-portage/eclass-manpages [gentoo]
vap...@gentoo.org
-- Actively maintained by Mike.
* app-portage/elogv [gentoo]
fuzzy...@gentoo.org (Paul Varner)
sp...@gentoo.org (Sebastian Pipping)
-- Being maintained more by Sebastian than myself.
* app-portage/elogviewer [gentoo]
fuzzy...@gentoo.org (Paul Varner)
-- Effectively unmaintained, I can't find the upstream repository and I
haven't done anything with it recently.
* app-portage/epm [gentoo]
None specified
-- Old perl script that mimics rpm. I've done some ebuild cleanup, but
otherwise unmaintained.
* app-portage/esearch [gentoo]
None specified
-- Actively maintained by myself and Brian. Upstream repository is on
Github
* app-portage/etc-proposals [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Actively maintained by Brian
* app-portage/euses [gentoo]
j...@gentoo.org (Jeroen Roovers)
-- Actively maintained by Jeroen
* app-portage/genlop [gentoo]
None specified
-- Not actively being maintained although fixes have been made in the
upstream gentoo-perl repository on Github. it might be appropriate to
transfer this to the gentoo-perl herd.
* app-portage/gentoolkit-dev [gentoo]
None specified
-- Actively maintained by Christian.
* app-portage/gentoolkit [gentoo]
None specified
-- Actively maintained by Paul and Brian
* app-portage/gpytage [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Brian took over maintenance. Not sure of active status
* app-portage/layman [gentoo]
dol...@gentoo.org (Brian Dolbec)
-- Brian is actively maintaining
* app-portage/maintainer-helper [local]
None specified
-- Not actively maintained, it really needs a maintainer or be dropped
from the tree.
* app-portage/mirrorselect [gentoo]
None specified
-- Actively maintained by various people.
* app-portage/porthole [gentoo]
dol...@gentoo.org (Brian Dolbec)
Upstream Maintainer (please CC on bugs)
-- Actively maintained by Brian
* app-portage/splat [gentoo]
None specified
-- I don't know anything about this package. Upstream URL is dead.
* app-portage/udept [local]
fuzzy...@gentoo.org
-- Effectively last rited, due to dead upstream. Still in tree in hard
masked status due to no replacement. However, in the time that it has
been hard masked, there has not been anyone to step up and either fork
or create a replacement.
* app-portage/ufed [gentoo]
None specified
-- Not being maintained since Harald retired and needs a maintainer.
Repository is on overlays.g.o
* dev-util/bdelta [gentoo]
sly...@gentoo.org (Sergei Trofimovich)
Primary Maintainer
-- I don't know anything about this package. Based on the ChangeLog,
Sergei is actively maintaining it.
Re: [gentoo-portage-dev] equery displays warnings about masked deps, even when those deps are deeper than --depth specification
On Mon, 2010-01-11 at 15:40 +0200, Amit Dor-Shifer wrote: is this a bug? As the gentoolkit maintainer, I would say that it is a bug. Which version of gentoolkit do you have installed? Regards, Paul
Re: [gentoo-portage-dev] REVDEP-REBUILD and emerge default options
On Mon, 2009-10-26 at 20:04 +0200, Arthur D. wrote: I am very much against allowing EMERGE_DEFAULT_OPTS in revdep-rebuild since I went through hell trying to support it when it was first added as a feature to portage and I really don't want to go through that again. Paul, there's good option to filter _only_ safe options from EMERGE_DEFAULT_OPTS and pass them to emerge. If you don't like to maintain it alone, I will help you. Just forward all tickets connected to EMERGE_DEFAULT_OPTS to me. Deal? The biggest issue is determining that EMERGE_DEFAULT_OPTS is the problem. Anyhow, I'm looking at it to see what can be done. Regards, Paul
Re: [gentoo-portage-dev] RFC: new virtual metadata variable to list combined deps
On Thu, 2006-10-26 at 18:50 +0200, Marius Mauch wrote: So now I was wondering a) if I'm the only one who finds this feature useful and b) if adding it at the dbapi level (in dbapi.aux_get) would be considered a good idea, so it could be used by other tools? Not sure if it would fit better in portage or gentoolkit. Anyhow, one of the big things that I need to do is fix the equery depends command. I see this code as potentially being useful in that regard. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] glsa-check wrong
On Sun, 2006-07-09 at 19:34 +0200, Radoslaw Stachowiak wrote: glsa-check returns errorlevels 255 which results in shell being unable to parse it (anything greater 255 is 0). I've opened Bug #139804 to track this. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] making permission/ownership retention consistent
On Wed, 2006-07-05 at 02:20 -0400, Mike Frysinger wrote: personally i think that we should be retaining the permissions of the file as is instead of resetting it, but i wont fight too hard in either direction ... we just need the behavior to be consistent I agree with retaining permissions of an already existing directory/file. Nothing I hate more as a system admin is having to double check permissions when reinstalling software. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] portage-2.1 and gentoolkit-0.2.2
On Wed, 2006-05-31 at 18:20 -0400, Ned Ludd wrote: Things can be fast tracked if it's better for the overall health of the tree. The 30 thing is just a general guideline and more so before we had any arch teams/ATs/etc... Now that we have arch teams the QA/stable process has been highly improved. On Wed, 2006-05-31 at 14:49 -0500, Paul Varner wrote: If portage-2.1 is requested to be marked stable before then, we need to also make the same request for gentoolkit, so that we don't break it. I don't think that we need to fast track marking gentoolkit-0.2.2 stable at this point. However, as my last paragraph states, if portage-2.1 is going to go stable before then, we should then fast track gentoolkit. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] portage-2.1 and gentoolkit-0.2.2
Just a reminder that due to the changes in portage-2.1, that it breaks gentoolkit-0.2.1 which is the current stable version. I have placed gentoolkit-0.2.2 in the tree which works with portage-2.1 and opened bug #135068 http://bugs.gentoo.org/135068 I have not added the arch teams to the bug since it has obviously not been in the tree for thirty days. I will add the arch teams at that time. If portage-2.1 is requested to be marked stable before then, we need to also make the same request for gentoolkit, so that we don't break it. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Portage-2.1_pre5
On Tue, 2006-02-21 at 20:07 -0500, Alec Warner wrote: Your testing is appreciated. The only thing that I have noted so far is that every emerge command is printing ** before it does anything else. For example: # emerge -pv portage ** These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/portage-2.1_pre5 USE=-build -doc 0 kB [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/portage Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Portage-2.1_pre5
On Tue, 2006-02-21 at 20:07 -0500, Alec Warner wrote: Your testing is appreciated. I'll file a bug for this one, once I investigate further. 'genlop -t' doesn't get along with it very well. # genlop -t screen * app-misc/screen snip Thu Dec 15 23:10:28 2005 app-misc/screen-4.0.2-r4 merge time: 1 minute and 11 seconds. Wed Feb 22 13:11:30 2006 app-misc/screen-4.0.2-r4 merge time: 5 days, 14 hours, 2 minutes and 13 seconds. Wed Feb 22 13:16:04 2006 app-misc/screen-4.0.2-r4 merge time: 5 days, 14 hours, 6 minutes and 47 seconds. Wed Feb 22 13:16:47 2006 app-misc/screen-4.0.2-r4 merge time: 5 days, 14 hours, 7 minutes and 30 seconds. The last three emerges were done with 2.1_pre5 where I was testing the effects of enabling confcache Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Portage-2.1_pre5
On Wed, 2006-02-22 at 18:35 -0800, Zac Medico wrote: After you've updated to the new ebuild (with patch), run `sed -i 's/ Emerging/ emerge/g' /var/log/emerge.log` and genlop should work correctly again. Did all of the above and everything is looking good. Thanks for the quick response Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] emerge-webrsync patch
On Wed, 2005-12-28 at 13:04 +0100, Johannes Fahrenkrug wrote: I put a nice -n 19 in front of the tar, rsync and emerge metadata commands because normally calling emerge-webrsync renders my box unusable for 15 to 20 minutes. You still notice a difference when using nice but everything seems to be at least noticably smoother than before. Instead of hardcoding the nice value, use PORTAGE_NICENESS. Here is how it is done in revdep-rebuild # Obey PORTAGE_NICENESS PORTAGE_NICENESS=$(portageq envvar PORTAGE_NICENESS) [ ! -z $PORTAGE_NICENESS ] renice $PORTAGE_NICENESS $$ /dev/null Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] emerge-webrsync patch
On Wed, 2005-12-28 at 17:38 +0100, Johannes Fahrenkrug wrote: Good point. Is this patch better? Or should it rather be _exactly_ as it is in revdep-rebuild? I personally would do it the same way as revdep-rebuild since that causes the entire script and anything it calls to be run at the value set in PORTAGE_NICENESS. However, the way you have done it works just as well. As far as your patch goes, you don't need to call the emerge metadata with a nice value since the emerge command reads and uses the PORTAGE_NICENESS value. Finally, I am not a portage developer, so if this gets accepted and used depends upon them and not me. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] ECONF_EXTRA handling: bug 38618
On Fri, 2005-10-07 at 16:03 -0500, Brian Harring wrote: It allows for users to override ebuild defined configure options, potentially shooting themselves in the foot, but in the same token they can already shoot themselves in the foot via EXTRA_ECONF... Since EXTRA_ECONF is all about letting users shoot themselves, I see no reason not to. Regards, Paul -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object
On Tue, 2005-09-20 at 19:00 -0500, Brian Harring wrote: On Tue, Sep 20, 2005 at 06:55:44PM -0500, Paul Varner wrote: On Tue, 2005-09-20 at 18:34 -0500, Brian Harring wrote: Updated patch to add a semaphore to control access to the global portage.config object. Unless anyone sees any other issues with this patch, I will be placing it into gentoolkit. Reason for a semaphore over threading.Lock ? No reason other than I'm used to thinking of them as semaphores instead of locks, so semaphore is what I searched for in the Python docs. Need to make some chunks of the rewrite thread safe, so I poked a bit; python -m timeit -n 1 -r 3 -s 'import threading;s=threading.Lock()' 's.acquire();s.release()' around 1us python -m timeit -n 1 -r 3 -s 'import threading;s=threading.Semaphore()' 's.acquire();s.release()' 20us Okay, I've changed the Semaphore to a Lock and removed the self._settings.reset() call. Anything else before I commit this? Regards, Paul PS: As an aside the command 'equery hasuse perl' goes from 34s to 2s on my Pentium 4 with this patch. -- gentoo-portage-dev@gentoo.org mailing list
