Latest Release 3.0.0 on 07/20/2020
Portpeek is alive and well, but this page, not so much. I’ll detail out the optimization changes I did on this release in the near future.
For now, you can view the git log of the last 4 years of changes if you are interested here:
My plan is to update this more frequently as portpeek changes. At least more frequently than once ever 4 years or so.
Latest Release: 2.1.21 on 12/05/2016
Portpeek is still actively maintained and has been receiving features and bug fixes. Feel free to open bugs at http://bugs.gentoo.org if you encounter any issues at all.
For a summary of changes please go to:
http://git.mpagano.com/?p=portpeek.git;a=summary
Portpeek is a script for Gentoo users to use to determine if packages the user has in package.keyword or package.unmask have gone stable and can be removed. The script can also remove these unneeded packages automatically. There is an ebuild available from Gentoo’s portage system.
Screen shot:
Latest Release: 1.8.0
05/14/09
Packaged Masked
Portpeek will now handle the tilde in the package.* files.
It will look for a package > the indicated package and remove
the line if a stabled version is detected. Please backup your files
before trying this feature
04/17/09
Portpeek now shows file information where line was found
Source Download Link (script and man page)
08/29/08
Fixed bug when determining if package is masked
06/26/2008
Remove the use of deprecated portage python modules.
10/10/2007
Packages without atoms (=<>) will not display as stable as this program is intended for managing version specific lines in package.mask and package.keywords
08/02/2007
Fixed a bug where commented lines were removed when they matched a package being removed.
2/18/2007
This version has the ability to turn off the color output.
You guys do a wonderful job! Keep up the good work!!!s
Pingback: Mike Pagano’s Weblog » New version of portpeek 1.6.1
Pingback: Mike Pagano’s Weblog » New version of portpeek 1.6.7
Is it possible to support dirs in /etc/portage? (/etc/portage/{package.unmask,package.mask,package.use}/)
>Is it possible to support dirs in /etc/portage? (/etc/portage
>/{package.unmask,package.mask,package.use}/)
It does support the dirs, are you seeing a situation where it’s not traversing into the directories?
I’m not sure Is it really related to portpeek but all my files in /etc/portage has been deleted.
I’ll test it again.
err… Sorry it’s my fault. I manually removed the entire directory by accident.
Really nice tool, thanks 😉
Pingback: /home/antu » package.* Dateien bereinigen mit Portpeek
Could you please add ‘~’ to the list of acceptable atom types. It is quite similar to ‘=’.
Here’s why I don’t think ~ will work.
Let’s say a user has this:
~kde-base/kdelibs-4.2.1
Which means he wants every -rX release keyworded for installation.
So now let’s say kdelibs-4.2.1-r3 goes stable.
Do we remove his line? What if user wants to stay on top of 4.2.1 releases no matter what so when keyworded kdelibs-4.2.1-r4 comes out, he gets it.
Please elaborate your thoughts if you think I am completely off base here.
1. Great program, my package.keywords would get really messy without it.
2. For ~, it would be good to at least have an option – what if all the -r packages are stable and you still have it in package.keywords (the test should be whether there is a currently installed package that would be masked without that line – true, they might use it so it will update when there’s a new -r, but it’s a weird thing to want if one of them is already stable)
3. Feature request: for folks using package.* sub-directories, could you have it print which file the line in questions is in? Also, have it delete that file if it removes the last line (optional).
4. Bug report: It doesn’t seem to handle packages with blank keywords – I have a line in package.keywords that says x11-plugins/gkacpi * because the package doesn’t have any keywords, but it gets reported in portpeek -ar.
@Eitan – new version (1.7.5) adds filename information
I added x11-plugins/gkacpi * but I don’t see it coming up as a problem. Can you open a bug on bugzilla if this is still a problem?
Pingback: Mike Pagano’s Weblog » New portpeek version 1.8.0
portpeek is fantastic!
any chance to get it to cooperate with paludis? the files in /etc/paludis look very much like the original portage equivalents, so i guess it wouldn’t be terribly complicated to port it, but this is just a wild guess.
anyway, that’d be highly appreciated.
@Nico
Thanks for the kind words.
Could you email me your paludis files? I’ve never seen them before and would like to take a look.
mpagano at gentoo.org
Hi Mike,
portpeek is really very useful… Nice work! I hope to see the latest version in stable as soon as possible.
Just a little request: could you add back the no-color option? I use portpeek in a cron script, and those ANSI codes reduce the readability of the output messages.
Thanks,
Stefano
@Stefano
Thanks for the nice comments.
Color suppression added to portpeek-1.8.1
Hi
I am missing some functionality. I am using directories which portpeek does not read. It would be a nice feature.
# pwd && ls -lR
/etc/portage
.:
total 0
drwxr-xr-x 2 root root 72 Jul 22 08:24 package.keywords
drwxr-xr-x 2 root root 104 Aug 15 14:43 package.use
./package.keywords:
total 4
-rw-r–r– 1 root root 47 Jul 22 08:39 vlc
./package.use:
total 8
-rw-r–r– 1 root root 59 Jul 28 20:50 mediatomb
-rw-r–r– 1 root root 178 Jul 22 09:57 vlc
I was wondering if you’ve had any progress with paludis support? I could sent you my sample files if you like.
@Dave
I’m sorry. I don’t use paludis.
It looks like more recent versions of portage have removed the leading slash from USER_CONFIG_PATH. This causes portpeek to fail unless I add the slash manually. I currently have the following version installed:
[I] sys-apps/portage
Available versions: 2.1.4.5 2.1.6.7 2.1.6.13 ~2.1.7 (~)2.1.7.1 [M]~2.2_rc33 [M]~2.2_rc41 [M]~2.2_rc42 [M]~2.2_rc44 [M]~2.2_rc45 [M]~2.2_rc46 {build doc epydoc linguas_pl python3 selinux}
Installed versions: 2.1.7.1(09:51:06 10/12/09)(python3 -build -doc -epydoc -linguas_pl -selinux)
Homepage: http://www.gentoo.org/proj/en/portage/index.xml
Description: Portage is the package management and distribution system for Gentoo
Nice script. I found it by browsing the app-portage category, but whished such a tool existed for a few months. Thank you!
@Dave
If I remember correctly, Paludis includes a utility script functionally equivalent to portpeek… I just can’t remember what it’s called. (I know it’s not reconcilio though. That’s the revdep-rebuild equivalent)
emerge -av portpeek
These are the packages that would be merged, in order:
Calculating dependencies… done!
[ebuild UD] sys-apps/portage-2.1.8.3 [2.1.9.24] USE=”-build -doc -epydoc -python3 (-selinux) (-ipc%*)” LINGUAS=”-pl” 0 kB
[ebuild N ] app-portage/portpeek-1.5.8.4 0 kB
Total: 2 packages (1 downgrade, 1 new), Size of downloads: 0 kB
Would you like to merge these packages? [Yes/No] n
Quitting.
I’ve portage-2.1.9.24 installed. Portpeek requires portage-2.1.8.3.
@Luis, dependencies should all be sorted out now.
Hi!.
I am using portpeek version 2.0.25, and I am getting the following error (in the bottom of full portpeek log)
Traceback (most recent call last):
File “/usr/bin/portpeek”, line 1370, in
clean_useflagsFile(USER_CONFIG_PATH + “/package.use”)
File “/usr/bin/portpeek”, line 1020, in clean_useflagsFile
cleanuseflagsFile(filename+os.path.sep+file_name)
NameError: global name ‘cleanuseflagsFile’ is not defined
I think it is kind of erratum in the script. Please, fix it.
Not sure if this is still checked/maintained, but I wanted to point out an issue: SLOT-ed package atoms break things. For instance, ‘>=kde-base/lokalize-4.13.3:4’ in my one of my package.use files gives:
Traceback (most recent call last):
File “/usr/lib/python-exec/python2.7/portpeek”, line 1468, in
get_recursive_info(USER_CONFIG_PATH + “/package.use”)
File “/usr/lib/python-exec/python2.7/portpeek”, line 418, in get_recursive_info
get_recursive_info(filename+os.path.sep+file_name)
File “/usr/lib/python-exec/python2.7/portpeek”, line 420, in get_recursive_info
get_info(filename)
File “/usr/lib/python-exec/python2.7/portpeek”, line 446, in get_info
diffs_found = parse_package_use(line,filename)
File “/usr/lib/python-exec/python2.7/portpeek”, line 538, in parse_package_use
if (pkgcmp(pkgsplit(check_pkg),pkgsplit(str(current_package.cpv))) == 0) or (pkgcmp(pkgsplit(check_pkg),pkgsplit(str(current_package.cpv))) == 2):
File “/usr/lib64/python2.7/site-packages/portage/versions.py”, line 292, in pkgcmp
if pkg1[0] != pkg2[0]:
TypeError: ‘NoneType’ object has no attribute ‘__getitem__’
This should be fixed in 2.1.16. Please let me know if you still have issues.
Hi.
Python-3.4 is unmasked in stable portage branch.
Could you please add USE=”python3_4″ to this package?
Thank you.
Currently, if portpeek encounters a symlink to a writeable file in any of its target directories, it clobbers it and replaces it with a real file. Can this behavior be altered, or certain files not be processed at all? I’m attempting to use shared config files to centrally manage packages on many Gentoo boxes.