|
|
South Australians in the Linux and/or Free/Open-Source community... |
Brandon Keepers at JSDay:
JavaScript is no longer a toy language. Many of our applications can’t function without it. If we are going to use JavaScript to do real things, we need to treat it like a real language, adopting the same practices we use with real languages.
I’ll admit that I still write a lot of JavaScript in toy-like style. Brandon’s presentation is both motivating and informative for anyone wanting to improve their use of JavaScript.
I am about to head to Dayton for the Hamvention, so took the opportunity to bring my web site up to date. The Codec 2 page includes our latest plans on building a Linux/Windows GUI Application for HF Digital Voice, has updates on recent algorithm developments, links to conference videos, and lots of figures explaining how Codec 2 works. I have added a FDMDV modem page, and updated my About Page to reflect my current projects and motivation. The Media page includes updates on recent conferences and radio interviews, and has a section on how this post on busting my daughters party with a Fluksometer went viral around the world, ending up back at my local newspaper!
With a $150 per month reduction in the minimum dedicated database price, Heroku suddenly becomes viable for many more of our apps.
A blog post at The Serval Project
on what one of our incredibly talented engineers has come up with to help me in my major reworking of the Serval UI for our upcoming major release.
This is somewhat old news but last September Fongtil and I won an award for our work on the Dili Village Telco. Here is the ISIF press release. We were selected from a group of about 50 ISIF funded projects for the award. Here is a photo of Lemi (2nd from right) accepting the award in Nairobi, Kenya:
Although this project was my first developing world deployment and I worked hard to make sure we did a good job, soaking up experience and knowledge from others where I could.
I think we got it about 70% right. Many things (ease of use, training, enthusiasm for local assembly and installation) worked really well. However being an Engineer there are still some remaining “bugs” I feel compelled to work on, for example there are still lingering issues with Wifi link quality, and a sustainable business model. Importantly, I haven’t seen viral growth, either in Timor or other Village Telco deployments. This is important for me – my goal for the Village Telco was to help a lot of people in the developing world get telephony. This can only happen if the local people embrace the technology and grow the networks themselves without reliance on grants or 1st world technical input. I do think many of the pieces for this are in place. “The Engineer” in me would love to have a go at really fixing those remaining issues! Still, this award confirms we did pretty well over all.
Although the funded part of the project officially ended in 2011, Fongtil are continuing to work on the project using internal resources and have also secured a further ISOC grant. They continue to train people, install nodes, evangelise with government (e.g. installing Mesh Potatoes in the National Parliament building), and have plans to fix the Wifi link issues in Dili:
I have moved my time and attention to other projects for now, but would love to get back to Timor some time to help out if I can. In the mean time Village Telco development and deployment work continues in Timor Leste and around the world.
Just finishing up an offlineimap(1) sync to a new laptop. 5 years of email has taken 2.5 days to sync. And that's over a fast network. I'm thinking twice about syncing the larger corpus of older mail.
National Lampoon at their finest satirizing dating for ‘the kids’. Pre Internet, feel free to add it to the list of pernicious activities encompassed within the helpful guide to staying that all important NICE – you know, asRepublicans only are. They NEVER do anything bad. etc;).
Wow. Again.
Google I/O 2012 sells out in 20 minutes. Compare that to the last few years.
Always the way, you upgrade the massively old Linux box you've been using as a VT100 to find that everything has changed. For a serial dongle connected to a router's console port to have a stable name, to be usable by all, and to be ignored by ModemManager then /etc/udev/rules.d/99-local.rules should read like this on a recent distribution:
SUBSYSTEM=="tty", ATTRS{idVendor}=="06cd", ATTRS{idProduct}=="0121", GROUP="users", MODE="0660", SYMLINK+="router"
ACTION=="add|change", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="06cd", ATTRS{idProduct}=="0121", ENV{ID_MM_DEVICE_IGNORE}="1"
Note that I am also putting the device into the "users" group, so that anyone can access the serial dongle to the router.
After editing the file you can reload udev with the command udevadm control --reload-rules. You can see udev's view of things with udevadm info --query=all --name=/dev/router --attribute-walk.
Let's say you've got a modern Linux distribution and you want to step back in time and use it like a VT-100 terminal. For example, routers often have serial consoles. For that you need some cables, Minicom, and a serial dongle.
When you plug in the serial dongle Linux will give it a name like /dev/ttyUSB0 and then NetworkManager will probe it for a modem. This can suck:
The device at the other end of the cable may not appreciate being probed with AT modem command sequences.
If you also have a 3G modem plugged in then there will be a whole forest of ttyUSBs, and so you'll have to reconfigure Minicom with the correct serial port every time.
A udev rule can fix both of these things. In this example I'm using a Keyspan USA-19HS RS-232/USB dongle with USB identifier 06cd:0121. Adjust the following for your own results from lsusb.
Create a new file for your own udev rules, I like /etc/udev/rules.d/99-local.rules. Edit it to add:
KERNEL=="ttyUSB[0-9]*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="06cd", ATTRS{idProduct}=="0121", SYMLINK+="router", ID_MM_PORT_BLACKLISTED=1
Now when you plug in the serial dongle Linux will give it a name like /dev/ttyUSB0. udev will create a symbolic link /dev/router to point to that name. udev will instruct NetworkManager not to probe the port.
Start Minicom in setup mode with sudo minicom -s and configure Minicom to use the serial port /dev/router, at 9600bps, 8 data bits, no parity, one stop bit, hardware handshaking, delete any dial strings. Save the configuration as router.
For every user who you want to use that serial connection, add them to the group dialout with a command like:
$ sudo usermod --append --groups dialout glen
Restart udev (sudo systemctl restart udev.service or sudo restart udev). Login again to grab your additional group membership (use id to display those).
When you want to use a RS-232 dongle to connect to the serial console of a router, then plug in the serial dongle and start Minicom with minicom router. No need to be root. No need to reconfigure Minicom depending if you plugged a 3G modem in first or not, no line noise from NetworkManager probing for a modem.
These instructions are for programming a Yamaha RX-V361 AV receiver remote control so it can control a Panasonic TV:
Key points that are not made clear in the manual: you must use the DTV/CBL input when programming the remote to control a TV (you don’t need to have this input selected to control the TV once it is programmed though); the RemoteSetup NG/OK/display stuff as outlined above.
This took me a while to get right the first time, and I neglected to write it down. Hopefully this will help someone out.
On a friend’s recommendation, I purchased a Logitech Harmony universal remote. Some quick searching online suggested that the unofficial community Linux support for this device was decent.
It took a bit of extra futzing around to get it working under Linux (Fedora 14 in my case), but I got there in the end. Amazingly it supports all my devices (TV, PVR, DVD, RX) despite some of them being ancient and obscure, for example a cheap and cheerful Telefunken DVD player.
Logitech has a web site for configuring and downloading the settings needed to control up to five of your AV devices with the Harmony remote. Unfortunately, the current configuration site balks with an ‘unsupported operating system’ / missing plugin error when visited from a browser running on Linux. Time to head off the beaten track…
The ‘congruity’ package provides a graphical setup for the Logitech Harmony. The process still involves configuring the device from a Logitech website, but at an alternative URL, and some preparation is required:
sudo yum install congruityNow go through the following process:
However, in my case the remote control detection phrase failed. This was overcome by updating the concordance package from 0.21 to 0.23 and trying again. See further below for the sordid details.
I was then able to select my four devices and program the Harmony remote control unit.
I encountered some teething issues when attempting some tasks with the remote, e.g. the wrong AV input was selected on the TV or the DVD player wouldn’t switch off, but I pressed the ‘help’ button on the remote and it tried some things and made it work!
The only thing I couldn’t get to work was changing the band (AM/FM) on the radio tuner of the AV receiver (Yamaha RX-V361).
Now, provided the devices are in standby mode, it is a one touch action to have everything setup to watch TV, then another to watch a DVD and so on. This saves a lot of fiddling and lengthy explanations to visitors of how correctly set all the various remotes to watch TV, not to mention removing some clutter.
It’s a shame that the Linux configuration is not smoother. Perhaps it could work better by separating out the concordance device identification data, and provide a mechanism for updating that alone, without having to recompile or rebuild the whole package.
It’s also a bit unsettling that future reprogramming of the remote is dependent on Logitech’s website being operational. It feels all too inevitable that bit-rot will set in once Logitech’s priorities shift onto newer products.
Nevertheless, it’s working just well enough for now.
Sordid details:
In different attempts the following errors occurred during the detection phase within the Congruity graphical app:
LibConcordException: libconcord function 'init_concord' failed with error code 11 ('Error connecting or finding the remote')
…and…
LibConcordException: libconcord function 'get_identity' failed with error code 1 ('Unknown error')
Now for the investigative diagnostics:
Running the ‘concordance’ command line app to display detected info also failed to find the device in my case: sudo concordance -i
Concordance 0.21 Copyright 2007 Kevin Timmerman and Phil Dibowitz This software is distributed under the GPLv3. ERROR: failed to requesting identity Requesting Identity: Failed with error 1
Digging a bit deeper reveals the relevant USB device ID information, and shows that at some level the operating system is aware of the device:
lsusb | grep -i logitech
Bus 005 Device 006: ID 046d:c122 Logitech, Inc. Harmony 700 Remote
dmesg
[ 8041.000104] usb 5-1: new full speed USB device using uhci_hcd and address 6 [ 8042.176170] usb 5-1: New USB device found, idVendor=046d, idProduct=c122 [ 8042.176181] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 8042.176189] usb 5-1: Product: Harmony Remote 0-0.2.0 [ 8042.176195] usb 5-1: Manufacturer: Harmony Remote 0-0.2.0
Interestingly, while my particular unit was marketed as a “Logitech Harmony 600 Five-In-One Universal Remote”, lsusb reports it as a Logitech Harmony 700 Remote.
Some web searching turned up a useful thread on troubleshooting Harmony software setup with Congruity and Concordance:
i had the same problem.
I bought a Harmony 650, and concordance (0.21) doesnt detect it.
Easy solution: install concordance 0.23″
Now, I tend to prefer the clean solution to the easy one. In Fedora that involves building and upgrading relevant RPM packages (as opposed to downloading the tarball and doing a make install as root, which doesn’t have the traceability that RPM packaging gives).
Here is an outline of the steps:
sudo yum remove congruitysudo yum install libusb-devel python-devel yumdownloader --source --disablerepo=ifedora --enablerepo=fedora libconcord concordance#Patch0: libconcord-0.21-mime-type-def.patch
#%patch0 -p1
# Comment out mime file
#%{_datadir}/mime/packages/%{name}.xml
The patch lines need to be removed to avoid errors during the rpmbuild phase like the following:
Reversed (or previously applied) patch detected! Assume -R? [n] n
RPM build errors:
File not found: /home/makerpm/rpmbuild/BUILDROOT/libconcord-0.23-1.fc14.x86_64/usr/share/mime/packages/libconcord.xml
su - makerpm and copy the spec files in the SPECS directory and the tarball into the SOURCES directory.rpmbuild -ba libconcord.specsudo yum localinstall --nogpgcheck /home/makerpm/rpmbuild/RPMS/x86_64/libconcord-python-0.23-1.fc14.x86_64.rpmerror: Failed build dependencies: libconcord-devel >= 0.23 is needed by concordance-0.23-1.fc14.x86_64
concordance.spec and change all occurrences of the version 0.21 to 0.23rpmbuild -ba SPECS/concordance.specyum localinstall --nogpgcheck /home/makerpm/rpmbuild/RPMS/x86_64/libconcord-python-0.23-1.fc14.x86_64.rpmyum localinstall --nogpgcheck /home/makerpm/rpmbuild/RPMS/x86_64/concordance-0.23-1.fc14.x86_64.rpm
sudo yum install congruityNote that I’ve missed some steps above, e.g. some variant of rpmbuild --rebuild xyz.srpm which is left as an exercise for the reader.
Now the concordance tool will be cleanly installed and should show up the device:
[root@orange etc]# concordance -i Concordance 0.23 Copyright 2007 Kevin Timmerman and Phil Dibowitz This software is distributed under the GPLv3. Requesting Identity: 100% done Model: Logitech Harmony 700 (Molson) Firmware Version: 0.2 Hardware Version: 1.1 Config Flash Used: 12% (473 of 3904 KiB)
The Ubuntu forum thread also mentioned the following which may be required in some cases:
echo 'SYSFS{idVendor}=="046d", SYSFS{idProduct}=="c122", MODE="666"' |tee /etc/udev/rules.d/custom-concordance.rules
Also tried changing SYSFS to ATTR, based on warnings in /var/log/messages
At this point, the web configuration steps outlined earlier in the post should work, with congruity successfully detecting the Harmony remote, allowing subsequent software setup.
I have the opportunity to use a Google Nexus S for a period of time, so I figured I would use my time with it to document my subjective comparison of webOS and Android.
Before I do so, I’ll make some introductory statements, so this blog entry is not misinterpreted or used in a way for which it is not intended.
Firstly, a smartphone operating system (like a desktop operating system) is a tool, not a religion.
Blindly advocating one smartphone operating system without having any real exposure to it’s competitors is like believing in one religion without having any exposure to any of the others, or saying that your country is the best in the world without ever leaving it’s borders or having an awareness of foreign places and cultures.
A good craftsman is able to subjectively compare tools from different vendors unemotionally, and choose the best heterogeneous set of tools for their own personal toolbox, rather than just blindly purchasing all their tools from the one vendor. However, compatibility between tools and suitability of a particular tool to a particular user may require a less than optimal single item to be purchased for the overall benefit of the efficacy of the complete set. Life is full of trade-offs and compromises, and ideals are rarely achieved.
Smartphones in particular are very personal items, and therefore subject to the whims of individual tastes, prejudices, legacies and routines. What works best for one person may be unusable for another, and vice versa.
Secondly, in general I don’t care what your opinion about smartphone operating systems is, and usually prefer not to get involved in arguments over subjective opinions. I choose the set of tools that work best for me, not the set of tools that work best for you or for anyone else. I don’t care whether one smartphone operating system has a higher number of users than another – I care only whether it works best for me. I don’t care whether one smartphone operating system has a higher number of available applications than another – I care only whether it has the applications that I need to use. I don’t care what market analysts think – the goals that they have when making smartphone operating system comparisons are very different from mine. I’m a developer, and in general if my need for some application or feature is strong, then I’ll either write it myself or choose to live without it if that is not possible. So I don’t necessarily need to follow the herd, but may choose to follow the path of least resistance to achieve my goals for the task at hand.
Please don’t waste your time trying to convince me that my subjective opinions are wrong, because they are not. Subjective opinions are just that – subjective, and opinions. Subjective opinions only apply to the person who made them, and cannot be used as some sort of objective truth that can be applied to another person. They also cannot be used by a second party as some sort of weapon against a third party – subjective opinions are not transitive.
Thirdly, most folks who read this will know that I founded and lead an open source development group called WebOS Internals. When people put a lot of time and effort in to the creation and growth of something, they are very likely to have a strong bias towards that thing. I am no different. My biases will affect my subjective opinions, and that’s fine – they are subjective opinions formed by me, not objective truths that apply to you.
Finally, to put to rest any conspiracy theories that may result from this post: doing a subjective comparison between two smartphone operating systems is not an indication of the death of one smartphone operating system, or the supreme superiority of another. Nor is it an indication of any change in direction of any development group. Nor is it a vote of confidence or no-confidence in any particular vendor. Nor is it a threat, a weapon, or a sell-out.
Put simply, if you find yourself wanting to use this post for any reason of than to appraise yourself of Rod Whitby’s subjective opinion about Android and webOS (as deployed on specific hardware as mentioned), then you should stop now and take a good hard look at yourself, cause you didn’t really read anything I wrote above.
With all that said, let’s begin the comparison. The items that are being compared are Android 2.3.4 running on a Google Nexus S and webOS 2.1.0 running on a Palm Pre 2.
[To be continued ...]
by lucychili (noreply@blogger.com) at January 04, 2010 11:23 AM
So two weeks back was the Official Handing Over Of The SAMBA Team T-shirt! Since then I have done my first serious push to the git tree, and received spam from the build farm about it (false positives, AFAICT).
I'm still maintinging virtio and the module and parameter code of course. But the kernel has slowly morphed into a complicated and hairy place. Formality has crept in, and the pile of prerequisites grows higher (eg. git, checkpatch.pl, Signed-off-by). This is maturity, but it raises the question: when will some neat lean OS without all this baggage come along?
SMP, micro-optimizations, multithreading and extreme portability are responsible for much of the added coding burdens, but also hyper-distributed development means many coders shy away from changes which would break APIs. The suboptimality accretes and this method of working becomes the new norm. BUG_ON() for API misuse is now seen as unduly harsh, but undefined APIs make the next change harder, and WARN_ON() tends to stay around forever.
SAMBA has some brilliant ideas which coding a joy (talloc chief among them, but there are other gems to be found). Hell, it even has a testsuite! But of course it has its own issues; the SAMBA 3/4 split, lack of the kernel's massive human resources and the inevitable code quality issues. Ask me again in a few years to do a comparison...
After the Preware 0.9.4 release, which included Applications, Themes, and Patches, and offers over 670 homebrew packages for installation, we (webos-internals.org) started getting reports of the Palm App Catalog “hanging” the user interface for 30 seconds or more when the installation of a new application is initiated, but only when the Package Manager Service (the service which does all the Linux-level work for the Preware front-end) was installed.
After some analysis, I found that disabling all the feeds in Preware reduced the “hang” from more than 30 seconds to less than a second.
Looking through the output of ‘dbus-util –capture’ showed that the “hang” was during the call to the queryInstallCapacity method of the com.palm.appinstaller service, the routine that the Palm App Catalog application uses to determine whether there is enough space to install a new application from the Palm App Catalog. Yes, this is the method which is at the heart of the dreaded “Too many applications” errors that people are seeing when they have a number of homebrew applications installed and try to install a new application from the Palm App Catalog.
Watching the output of ‘ps -ef’ during calls to this method (you can call it manually using luna-send) showed that palm was calling “ipkg -o /var list”. Curious. Why would you want to know the *complete* list of all *available* applications when determining whether there is room to install one known new application. I suspect that Palm should be calling “ipkg -o /var list_installed” instead (which just lists the installed applications). Note that Palm doesn’t use feeds the way that Preware does, so for Palm’s official use of ipkg, list and list_installed would return the same thing in their testing, but list_installed is definitely what they should be using to determine the size of installed applications.
The plot thickens when you use strace (which Palm conveniently includes in the official firmware image) on the running LunaSysMgr process.
It seems that LunaSysMgr calls “ipkg -o /var list” to get a list of installed packages (the probably intend to just get the list of installed packages, but when you have Preware installed and have feed configuration files in /var/etc/ipkg/*.conf, it actually returns a list of all *available packages).
LunaSysMgr then does an execve of “/usr/bin/du -s /var/usr/palm/applications/package” for each package in that list. (BTW Palm, you seem to have a bug in the logic of that code, cause it’s running du on random garbage strings after the end of the real package list)
Yes, that’s right. A call to queryInstallCapacity spawns a new program (“du”) once for each package returned by “ipkg -o /var list”. No wonder the UI hangs for 30 seconds or more!
A single “du -s /var/usr/palm/applications/*” would be a far more efficient way to get exactly the same information, but again, Palm would not see this difference in testing because they do not support the third-party Preware application usage of ipkg feeds.
You can imagine that this behaviour is probably related to the app install limit that many people are experiencing too. Unfortunately, I’ll have to reduce my /var partition size down from it’s current 2GB size (courtesy of the WebOS Internals Meta-Doctor) to be able to investigate this one.
Now the webos-internals.org developers need to develop a new method of installing homebrew applications so that this bug in Palm’s appInstaller service is not triggered.
In the meantime, the work-around is to go into the Preware Preferences screen, hit the “Feeds” button in the top-right corner, and disable all the feeds while you use the Palm App Catalog application in another card. No need to exit the Feeds screen, just toggle all the button to “Off”, and then toggle them back to “On” when you’re finished with the App Catalog.
For the solution to this problem, see Update #2, below.
I’ve created a thread on PreCentral where this issue can be discussed. As I uncover more information, I’ll publish my finding here.
Update #1: I’ve now webOS Doctored my Pre in the name of science, and have tested the limits of installing applications.
If you run “du -s /var/usr/palm/applications/*”, and add up all the numbers in the first column, then as soon as you hit the 62367 1K blocks limit of the addition of the sizes reported by that “du” command and the size of the app you with to install, you will get the dreaded “Sorry, Not Enough Memory” error from the Palm App Catalog application (and any other installer, like fileCoaster or PreLoad, which uses the palm appInstaller API). It doesn’t matter whether you have 192MB free in your /var partition, it will max out at just under 64MB of application usage.
Update #2: I have now created a Linux Application called “Fair Dinkum App Limit” (org.webosinternals.fairdinkum), which removes both the “hang” and the arbitrary application limit. You can find it in Preware. Just install it (no need to even run anything – if it is installed, it’s working), and you’re ready to install more applications than you can poke a stick at …
Fair Dinkum App Limit works by simply putting a couple of wrapper scripts in /usr/local/bin, which returns a size of zero when du is called, and returns the output of “ipkg -o /var list_installed” when “ipkg -o /var list” is called. In the future, the wrappers will be made much more sophisticated than they are right now to prevent operation outside of the specific cases where they need to fool LunaSysMgr, and to also include a safety buffer so that users do not fill the /var partition. This is a tactical response to a problem that people using homebrew applications are experiencing. Hopefully, Palm will provide the long term solution for limits on application installation in a release in the near future.
Notes for Palm, if you happen to read this:
1) We fully appreciate that the usage of the ipkg database in /var for homebrew applications is a choice that the homebrew community has made, and is not supported by Palm.
2) We fully agree that the use of “ipkg -o /var list” instead of “ipkg -o /var list_installed” would work perfectly fine for the way that Palm is officially using the ipkg database in /var/usr/lib/ipkg, but we contend that the “list” and “list_installed” commands have clear intended usage, and the one to find the list of installed applications for checking available disk space should be “list_installed”.
3) We fully realise that the initial version of the FairDinkum scripts are unsafe. Returning a zero value for du is a temporary solution while we work out how to achieve the same result safely. The intention is to only return false values when du is being called from LunaSysMgr, and to make sure that a safety buffer is kept so that users do not fill the /var partition.
4) I would be very happy to discuss these issues with anyone at Palm (Chuq and Google both have my email address), and would hope that we can together architect a solution for supporting homebrew application installation which does not require these work-arounds.
5) We have designed these work-arounds in a way which does not collide with Palm OTA Updates, and in a way that we can update them automatically using the Preware installer application, and in a way that we can cause them to self-remove when Palm releases a long term solution.
Update #3:
It seems that there is yet another limit on application installation imposed by LunaSysMgr. Once the used space on /var crosses around 60%, LunaSysMgr will once again refuse to install applications.
I’m going to need to webOS Doctor my Pre yet again (to reallocate 2GB to /var) to determine whether this limit is a fixed percentage, or a fixed number of blocks.
Update #4:
The limit is 102400 free blocks. Mystery solved. That also means the Fair Dinkum App Limit cannot cause your /var to be filled.
Update #5:
Thanks to Carl Thompson, an improved version of Fair Dinkum App Limit which does not alter the operation of ‘du’ has been released.
If you've ever written a stack of SQL inserts using Perl and wondered if there was a better way to do it, and that gets around these issues:
then this piece of code will help:
use strict;
use DBI qw(:sql_types);
my $dbname = "christest";
my $dbh = DBI->connect("dbi:Pg:dbname=$dbname", "", "",
{ RaiseError => 1, AutoCommit => 0 });
# using the DBI statement handler's bind_param() feature, bind the
# given SQL parameters to the prepared query.
#
# To be eval'ed from sql_insert()
#
# Args:
# - reference to statement handler (i.e. \$sth)
# - remaining args are arrary references representing
# value and type pairs - e.g. ["fred", SQL_VARCHAR]
#
# Returns:
# nothing
#
sub bind_query {
St George supply a shared library for RedHat Linux 9 at https://www.ipg.stgeorge.com.au We want it to run it using FreeBSD for various reasons, the least of which is that RH9 hasn't been supported for more than a year. (Actually, the real reason is that we have a client using FreeBSD that doesn't want to use the Java API.)
The current version (released Jan 2004) will work under FreeBSD 4 with a few steps:
emulators/linux_base-rh-9
devel/linux_devtools
devel/linux-glib2
RPMFLAGS="--root /compat/linux --dbpath /var/lib/rpm --nodeps --replacepkgs --ignoreos --ignorearch"
rpm -U $RPMFLAGS krb5-libs-1.2.7-10.i386.rpm
rpm -U $RPMFLAGS openssl-0.9.7a-20.2.i386.rpm
Last updated:
May 17, 2012 03:00 AM
All times are UTC.
Powered by:
http://www.planetplanet.org
Maintained by:
mrda and g.