Search Results: "equinox"

13 December 2010

Joey Hess: snow and stats

It's been an intense couple of days out at the Hollow. Did it only start to snow yesterday? It feels like a long time in winter. Yesterday was the first day that the solar panels produced no power, it was too cloudy and snowing most of the time. I cleaned an inch of slushy snow off the panels to no avail, and wondered if the power would last. But the wood stove has kept it nice and warm, so yesterday was spent cosily in the living room enjoying the snowfall, nethack, and podcasts. Also, I'm very much enjoying cooking on the wood stove. I've never been in a position to cook on one before; when I lived at Wortroot the stove was in the cabin, and the cold kitchen in a different building. So cooking on the stove, or even keeping a kettle on, was mostly only done in emergencies. Here, I am constantly using it, and the propane stove is still on its first 20 pound tank. Long slow cooked beany or roastish stuff does especially well. Yesterday I did a great pork loin roast with homemade quick sauerkraut. Today, after cleaning another 3 inches of snow off the solar panels, and scraping off a layer of ice, I am getting a decent amount of power for a cloudy day with some snow still falling. Turns out it was good I cleaned them yesterday after all, since a part I missed has a inch+ layer of hard ice, which I don't dare chip away at for fear of damaging the panels. I'd not want to live someplace where it snowed a lot with solar panels that didn't have some kind of a heating system. I wish I had a camera to show the long walk down the driveway, through the winter woods, and past the field where the wind blows gusts of snow into the air. But my cell phone is on a Caribbean cruise. I have been recording data ever since the fall equinox, and it's almost to the winter solstice now. Time to geek out with some graphs! Solar production has surely been falling off with the waning days, but it seems like it will get through the shortest day with enough, and from then on, no worries.
Highest watt production seen each day I've been here.
Zero all day yesterday.
Power system voltages.
Charge controller limits it to a maximum of 15 volts during the day.
Originally, it was limiting it to 13 volts.

1 December 2010

Pietro Abate: bypassing the apt-get solver

Here at mancoosi we have been working for quite a while to promote and advance solver technology for FOSS distributions. We are almost at the end of the project and it is important to make the mancoosi technology relevant for the community. On goal of the project is to provide a prototype that uses part of the results of mancoosi that can based to install/remove/upgrade packages on a user machine. We certainly don't want to create yet another meta installer. This would be very time consuming and certainly going beyond the scope of the project. The idea is to create a prototype, that can work as an apt-get drop in replacement that will allow everybody to play with different solvers and installation criteria. A very first integration step is a small shell script apt-mancoosi that tries to put together different tools that we have implemented during the project. Roberto wrote extensively about his experience with apt-mancoosi a while ago showing that somehow the mancoosi tools are already usable, as proof of concept, to experiment with all solvers participating to the Misc competition. On notable obstacle we encountered with apt-mancoosi is how to pipe the result of an external solver to apt-get to effectively install the packages proposed as solution. Apt-mancoosi fails to be a drop-in replacement for apt-get exactly for this reason. The "problem" is quite simple : The idea at the beginning was to pass to apt-get, on the command line, a request that effectively represents a complete solution. We expected that, since this was already a locked-down solution, apt-get would have just installed all packages without any further modification to the proposed installation set. Of course, since apt-get is designed to satisfy a user request, and not just to install packages, we quickly realized that our evil plan was doomed to failure. The only option left, was to use libapt directly, but the idea of programming in c++ quickly made me to desist. After a bit of research (not that much after all), I finally found a viable solution to our problems in ''python-apt'' that is a low level and wrapper around libapt. This definitely made my day. Now the juicy details. the problem was to convince apt to completely bypass the solver part and just call the installer. First a small intro. python-apt has an extensive documentation with a couple of tutorials. Using python-apt is actually pretty easy (some snippet from the python-apt doco) :
import apt

# First of all, open the cache
cache = apt.Cache()
# Now, lets update the package list
cache.update()
here we open the cache (apt.Cache is a wrapper around the low level binding in the apt_pkg module), then we update the package list. This is equivalent to apt-get update . Installing a package is equally easy :
import apt
cache = apt.Cache()
pkg = cache['python-apt']

# Mark python-apt for install
pkg.mark_install()

# Now, really install it
cache.commit()
Now, the method mark_install of the module package will effectively run the solver to resolve and mark all the dependencies of the package python-apt. This is the default behavior when apt-get is used on the command line. This method has however three optional arguments that are just what I was looking for, that is autoFix, autoInst and fromUser . The explanation from the python-apt doco is quite clear.
mark_install(*args, **kwds)
Mark a package for install.
If autoFix is True, the resolver will be run, trying to fix broken packages. This is the default.
If autoInst is True, the dependencies of the packages will be installed automatically. This is the default.
If fromUser is True, this package will not be marked as automatically installed. This is the default. Set it to False if you want to be able to automatically remove the package at a later stage when no other package depends on it.
What we want is to set autoFix and autoInst to false to completely bypass the solver. So imagine that an external solver can give use a string of the form : bash+ dash=1.4 baobab- that basically asks to install bash to the newest version, dash at version 1.4 and remove baobab. Suppose also that this is a complete solution, that is, all dependencies are satisfied and there are no conflicts. The work flow of mpm (mancoosi package manager) is as follows : We already have a first prototype on the mancoosi svn. It's not released yet as we are waiting to do more testing, add more options and make it stable enough for testing. Maybe one day, this will be uploaded to debian. This is the trace of a successful installation of a package in a lenny chroot. The solver used here is the p2 solver
dev:~/mpm# ./mpm.py -c apt.conf install baobab
Running p2cudf-paranoid-1.6 solver ...
Validate solution ...
loading CUDF ...
loading solution ...
Summary of proposed changes:
new: 30
removed: 0
replaced: 0
upgraded: 0
downgraded: 0
unsatisfied recommends:: 8
changed: 30
uptodate: 322
notuptodate: 116

New packages: baobab (2.30.0-2) dbus-x11 (1.2.24-3) gconf2 (2.28.1-5)
gconf2-common (2.28.1-5) gnome-utils-common (2.30.0-2)
libatk1.0-0 (1.30.0-1) libcairo2 (1.8.10-6) libdatrie1 (0.2.4-1)
libdbus-glib-1-2 (0.88-2) libgconf2-4 (2.28.1-5) libgtk2.0-0 (2.20.1-2)
libgtk2.0-common (2.20.1-2) libgtop2-7 (2.28.1-1) libgtop2-common (2.28.1-1)
libidl0 (0.8.14-0.1) libjasper1 (1.900.1-7+b1) liborbit2 (1:2.14.18-0.1)
libpango1.0-0 (1.28.3-1) libpango1.0-common (1.28.3-1)
libpixman-1-0 (0.16.4-1) libthai-data (0.1.14-2) libthai0 (0.1.14-2)
libtiff4 (3.9.4-5) libxcb-render-util0 (0.3.6-1) libxcb-render0 (1.6-1)
libxcomposite1 (1:0.4.2-1) libxcursor1 (1:1.1.10-2) libxrandr2 (2:1.3.0-3)
psmisc (22.11-1) shared-mime-info (0.71-3)
Removed packages:
Replaced packages:
Upgraded packages:

Selecting previously deselected package libatk1.0-0.
(Reading database ... 28065 files and directories currently installed.)
Unpacking libatk1.0-0 (from .../libatk1.0-0_1.30.0-1_i386.deb) ...
Selecting previously deselected package libpixman-1-0.
Unpacking libpixman-1-0 (from .../libpixman-1-0_0.16.4-1_i386.deb) ...
Selecting previously deselected package libxcb-render0.
Unpacking libxcb-render0 (from .../libxcb-render0_1.6-1_i386.deb) ...
Selecting previously deselected package libxcb-render-util0.
Unpacking libxcb-render-util0 (from .../libxcb-render-util0_0.3.6-1_i386.deb) ...
Selecting previously deselected package libcairo2.
Unpacking libcairo2 (from .../libcairo2_1.8.10-6_i386.deb) ...
Selecting previously deselected package libdbus-glib-1-2.
Unpacking libdbus-glib-1-2 (from .../libdbus-glib-1-2_0.88-2_i386.deb) ...
Selecting previously deselected package libidl0.
Unpacking libidl0 (from .../libidl0_0.8.14-0.1_i386.deb) ...
Selecting previously deselected package liborbit2.
Unpacking liborbit2 (from .../liborbit2_1%3a2.14.18-0.1_i386.deb) ...
Selecting previously deselected package gconf2-common.
Unpacking gconf2-common (from .../gconf2-common_2.28.1-5_all.deb) ...
Selecting previously deselected package libgconf2-4.
Unpacking libgconf2-4 (from .../libgconf2-4_2.28.1-5_i386.deb) ...
Selecting previously deselected package libgtk2.0-common.
Unpacking libgtk2.0-common (from .../libgtk2.0-common_2.20.1-2_all.deb) ...
Selecting previously deselected package libjasper1.
Unpacking libjasper1 (from .../libjasper1_1.900.1-7+b1_i386.deb) ...
Selecting previously deselected package libpango1.0-common.
Unpacking libpango1.0-common (from .../libpango1.0-common_1.28.3-1_all.deb) ...
Selecting previously deselected package libdatrie1.
Unpacking libdatrie1 (from .../libdatrie1_0.2.4-1_i386.deb) ...
Selecting previously deselected package libthai-data.
Unpacking libthai-data (from .../libthai-data_0.1.14-2_all.deb) ...
Selecting previously deselected package libthai0.
Unpacking libthai0 (from .../libthai0_0.1.14-2_i386.deb) ...
Selecting previously deselected package libpango1.0-0.
Unpacking libpango1.0-0 (from .../libpango1.0-0_1.28.3-1_i386.deb) ...
Selecting previously deselected package libtiff4.
Unpacking libtiff4 (from .../libtiff4_3.9.4-5_i386.deb) ...
Selecting previously deselected package libxcomposite1.
Unpacking libxcomposite1 (from .../libxcomposite1_1%3a0.4.2-1_i386.deb) ...
Selecting previously deselected package libxcursor1.
Selecting previously deselected package libxrandr2.
Unpacking libxrandr2 (from .../libxrandr2_2%3a1.3.0-3_i386.deb) ...
Selecting previously deselected package shared-mime-info.
Unpacking shared-mime-info (from .../shared-mime-info_0.71-3_i386.deb) ...
Selecting previously deselected package libgtk2.0-0.
Unpacking libgtk2.0-0 (from .../libgtk2.0-0_2.20.1-2_i386.deb) ...
Selecting previously deselected package libgtop2-common.
Unpacking libgtop2-common (from .../libgtop2-common_2.28.1-1_all.deb) ...
Selecting previously deselected package libgtop2-7.
Unpacking libgtop2-7 (from .../libgtop2-7_2.28.1-1_i386.deb) ...
Selecting previously deselected package psmisc.
Unpacking psmisc (from .../psmisc_22.11-1_i386.deb) ...
Selecting previously deselected package dbus-x11.
Unpacking dbus-x11 (from .../dbus-x11_1.2.24-3_i386.deb) ...
Selecting previously deselected package gconf2.
Unpacking gconf2 (from .../gconf2_2.28.1-5_i386.deb) ...
Selecting previously deselected package gnome-utils-common.
Unpacking gnome-utils-common (from .../gnome-utils-common_2.30.0-2_all.deb) ...
Selecting previously deselected package baobab.
Unpacking baobab (from .../baobab_2.30.0-2_i386.deb) ...
Processing triggers for man-db ...
Setting up libatk1.0-0 (1.30.0-1) ...
Setting up libpixman-1-0 (0.16.4-1) ...
Setting up libxcb-render0 (1.6-1) ...
Setting up libxcb-render-util0 (0.3.6-1) ...
Setting up libcairo2 (1.8.10-6) ...
Setting up libdbus-glib-1-2 (0.88-2) ...
Setting up libidl0 (0.8.14-0.1) ...
Setting up liborbit2 (1:2.14.18-0.1) ...
Setting up gconf2-common (2.28.1-5) ...

Creating config file /etc/gconf/2/path with new version
Setting up libgconf2-4 (2.28.1-5) ...
Setting up libgtk2.0-common (2.20.1-2) ...
Setting up libjasper1 (1.900.1-7+b1) ...
Setting up libpango1.0-common (1.28.3-1) ...
Cleaning up font configuration of pango...
Updating font configuration of pango...
Cleaning up category xfont..
Updating category xfont..
Setting up libdatrie1 (0.2.4-1) ...
Setting up libthai-data (0.1.14-2) ...
Setting up libthai0 (0.1.14-2) ...
Setting up libpango1.0-0 (1.28.3-1) ...
Setting up libtiff4 (3.9.4-5) ...
Setting up libxcomposite1 (1:0.4.2-1) ...
Setting up libxcursor1 (1:1.1.10-2) ...
Setting up libxrandr2 (2:1.3.0-3) ...
Setting up shared-mime-info (0.71-3) ...
Setting up libgtk2.0-0 (2.20.1-2) ...
Setting up libgtop2-common (2.28.1-1) ...
Setting up libgtop2-7 (2.28.1-1) ...
Setting up psmisc (22.11-1) ...
Setting up dbus-x11 (1.2.24-3) ...
Setting up gconf2 (2.28.1-5) ...
update-alternatives: using /usr/bin/gconftool-2 to provide /usr/bin/gconftool (gconftool) in auto mode.
Setting up gnome-utils-common (2.30.0-2) ...
Setting up baobab (2.30.0-2) ...
Broken: 0
InstCount: 30
DelCount: 0
dev:~/mpm#
I think we'll keep working on this python prototype for a while, but this is not certainly what we want to propose to the community. The mancoosi package manager is probably going to be written in Ocaml and integrated with dose3 and libcudf. This will allow us to gain speed and have a solid language to develop with (nothing against python, but we don't feel that a scripting language is suitable for an essential component as a package manager). Time will tell. For the moment this is just vapor-ware ...

20 September 2008

MJ Ray: Lots of Days: Software Freedom, British Food and World Peace

Today is Software Freedom Day. It is also the start of British Food Fortnight. (Tip to total coverage cooperative.) There is an open day 11-3 at Thatchers Cider, near here in Sandford. (To get there from Worle by bike, leave through St Georges to Bourton, then Hewish, Puxton, Nye, over the Strawberry Line and you’ll arrive on Nye Road in Sandford - turn right for the cider. I’m not sure of the best way from Locking direction…) Tomorrow is the second equinox and International Day of Peace. (Tip to New Internationalist cooperative.) What are you doing this weekend?

18 September 2006

Evan Prodromou: F te de la Vertu CCXIV

It's the Festival of Virtue today in the French Revolutionary Calendar -- the first of the five wp:sansculottides, festival days at the end of the year just before the fall equinox. The day is dedicated to singing the praises of individuals who've shown especially good qualities. I'd probably start off with the great people involved in Wikitravel -- they've been hugely successful at self-organizing and creating an incredible collection of high-quality travel guides. I'm always amazed at the persistence and goodwill of this great group of unselfish and dedicated travellers. Another is the great local local Montreal Burning Man community, putting together Ignition 2006, the regional burn event here in Quebec. There are people coming out of the woodwork to make this a fun campout, and I'm really looking forward to the event next weekend. There's still a lot to do, but I think it's going great. Who else? The thousands of people making and sharing Open Source software and Open Content music, images, and text continue to astound me. When we're in the thick of it, it's hard to remember how generous and giving you have to be to dedicate time and energy to sharing Free Information with the world and with posterity. It is a saintly pursuit and it deserves praise and support. tags:

17 August 2006

Evan Prodromou: 30 Thermidor CCXIV

I can't believe it's the end of wp:Thermidor already. The summer's going so fast; Fructidor is the last month of the year in the French Revolutionary Calendar, and then it's the fall equinox and things change. Speaking of the fall equinox, the Br leurs de Montr al Burners, the local Burning Man regional organization in Montreal, is planning a decompression regional burn campout event for the weekend of 22-24 September 2006. Folks interested in Burning Man and near Montreal are encouraged (by me) to participate on the Br leurs wiki or join the bruleurs mailing list. And, yes, the event starts on La F te de la R volution on the Republican calendar. Neat. tags:

And you smell like one too As has been mentioned in many other places, yesterday, 16 Aug, was the 13th anniversary of the launch of Debian. It's definitely something to celebrate -- the project continues to be a huge success and a bulwark of Free Software. Robin Millette and the Atelier du Libre will be hosting a Debian birthday party here in Montreal on Saturday the 19th at 8655 rue St Denis, at the Cr mazie metro stop. The event is from 1:30PM to 5:30PM and is open to all. More info at http://rym.waglo.com/wordpress/2006/08/17/party/ . tags:

21 March 2006

Andrew Pollock: [life/americania] Spring has sprung?

So it seems that at least in North America, the seasons don't map directly to the inverse of Australia. Case in point, spring started today, on March 20, when if you were to invert autumn, should have started on the first of the month. In fact, my research seems to suggest that the seasons change around the 20th to the 22nd of the month, but it's all based on on Equinoxes and Solstices, so it wouldn't surprise me if it moves around slightly year to year, like Easter does. That said, the source of all knowledge is trying to tell me that summer in the southern hemisphere begins on November 6, which is news to me. In fact, further research tends to suggest that the northern hemisphere hasn't got a fucking clue when the seasons start, and are all over the place like a dog's breakfast. I'm feeling very seasonally confused.

25 February 2006

Uwe Hermann: Mplayer remote and local vulnerability + security fix

The well-known video player Mplayer is vulnerable to a heap overflow when playing ASF files locally or from remote (streaming). The potential risks:
High (arbitrary remote code execution under the user ID running the player) when streaming an ASF file from a malicious server, medium (local code execution under the user ID running the player) if you play a malicious ASF file locally. At the time the buffer overflow was fixed there was no known exploit.
Users of the older MPlayer 1.0pre7try2 should apply this patch in order to fix the security issue. CVS users should update to the most recent revision. I tried to do the latter, but I stumbled over several problems. First, I noticed and filed a bug (I think) in Debian's libavcodec-dev package which prevented a successful compile. After a few more problems I gave up and stayed with 1.0pre7try2 by applying the above-mentioned patch. I'll wait a few more days until the MPlayer developers fix the build issues in CVS... There's no known exploit in the wild yet, but I bet it won't take too long until one appears. So better fix your Mplayer!