I’m currently in the process of resizing a partition in Solaris 10. So far, the instructions that I’ve found have been quite incorrect, so I’m documenting the steps I’m taking here. In my particular case, I’m resizing a single partition on a non-root disk after increasing it’s size through VMWare.
Ran into this little gem today… I’ve got a project that I’m currently trying to branch. It’s a very simple integration operation from one location to another, nothing crazy. Of course Perforce needs to make it as complicated as possible by throwing me this error for a couple of our files:
cannot submit unicode type file using non-unicode server
Now, this is incredibly nonsensical. I’m integrating an already submitted file from one location to another, and checking it in. Why does Perforce reject it if it’s already been submitted successfully once before?
It turns out that the way perforce handles unicode filetypes changed at some point. Before this change, you could submit unicode files without any problems. After this change, your server needs to be reconfigured as a ‘unicode server’ in order to check in unicode files, even though it’s clearly handling already checked-in files just fine. To me, this seems like an artificial restriction, but I digress.
To resolve this, you just need to reopen the files as text, and resubmit them.
$ p4 reopen -t text
After that, you can work on the files again as normal. I’m not sure what effect this has on the encoding of the files themselves, so as always, YMMV, but at least you’ll be able to get on with your life.
I recently did a migration of source code from one perforce server to another. During the merge process, I ran into an odd warning:
perfmerge++ warning:
No mapping for change 293174 in database /x/sourceserver/server/. Rejecting.
Thinking that it was just a dead or missing changeset, I skipped right along and proceeded to put the server into production. Verify came back ok, so I figured everything was fine.
It was not…
Continue reading »
Jenkins makes adding slaves really easy. For unix machines, the preferred method is to use SSHD, which only requires that the master be able to contact the slave. On windows, however, you are stuck using a JNLP based solution, which requires that the slave be able to access master over the network.
I got stuck in the awkward situation where I had to add a windows machine to our master, but the slave could not even ping it. This could be resolved by updating our routing tables on the slave side, but unfortunately that wasn’t an option here. Instead I chose to try and start the slave using a Windows SSHD solution.
Continue reading »
Here’s a script I whipped up in order to send an email to all recent Perforce users. I needed this because my company uses a shared license, so all user accounts are shared between our perforce servers. When a server needs to go down for maintenance, I like to email only those people who actually use it. This uses python, but it does not require the p4python api (though I imagine it would be quite simpler using it). I’m sure there are some imports that need to be cleaned up, but whatever, it’s just a quickie.
Continue reading »
I often find myself in the situation where I need to delete the perforce account of a user who has left the company. Unfortunately I’m usually unable to do so because they have left files open, resulting in this error:
$ p4 user -d -f SOMEUSER User SOMEUSER has file(s) open on 2 client(s) and can't be deleted.
The solutions posted online usually involve either deleting the clients, or ‘masquerading’ as the client host and reverting the files by hand. This is very tedious, so I wrote a python script to do it instead. It’s a bit crude, but all it does is take usernames off the command line, and proceeds to revert all the files that user has open on the server.
I recently upgraded my work PC from Natty to Oneiric, and discovered that whenever I had a window open that wasn’t maximized, it’s backend process and xorg would use up 100% of the cpu.
I was nearly about to rebuild my machine when I discovered that it only happened for non-maximized GTK windows. As a last ditch effort, I ran gtk-theme-switch2, and switch my theme. Magically, this fixed the problem!
Part of the issue was that I’m running in Fluxbox, not Gnome or Unity. I think somehow it got the theme messed up during the upgrade, and since neither Gnome nor Unity had the chance to set it to a correct theme, it borked.
Yes, I know there is a handy and rather well thought out guide here, but I thought I would post my experiences, especially given that blindly following the aforementioned tutorial resulted in my existing Ubuntu installation being wiped…
Continue reading »
So I ran into this problem earlier this week. Basically we have a Solaris 10 server hosting files over NFS. The NFS server that comes with Solaris 10 supports NFSv4, but doesn’t seem to include idmapd, which is responsible for mapping user and group ids. Everything I’ve read suggests that idmapd is required on both the client and server in order for it to work correctly. Since I had no real desire to screw with the server configuration (and since other machines could mount it correctly) I kept searching.
The solution I found is a bit hacky, but it works for me. Basically it boils down to adding nfsvers=3 to the mount parameters. In my case, I was using automount, so I just added the option to every line in my /etc/auto.master. This just forces it to mount using NFSv3, which works because of it’s simplicity, but is possibly more insecure (and not all NFS servers will support it).
If possible, you should really just consider doing things the proper way, and getting idmapd set up on your servers and clients. This is just a quick work-around for when you are backed into a corner like I am.
So in case you haven’t heard, there was some drama between the Hudson community and Oracle. I won’t go into detail as there are plenty of articles about what went on.
All of the issues that were opened on the Hudson Jira for the Perforce plugin are still open, but I’m unassigning those that are assigned to me. I’ll continue maintaining the Perforce plugin against Jenkins, so bugs will be tracked there, and any fixes I make will be made in the Jenkins repository. Note that the Jenkins version will still work for Hudson until Oracle/Sonatype and/or the Jenkins Community decide to break cross-compatibility.
I’m not saying the Hudson version is dead, just that it doesn’t have an active maintainer. Someone may take over maintaining it, but as far as I know, only one person has been assigned to working on Hudson and the hundreds of plugins written for it.