Search Results: "pm"

19 June 2007

Scott James Remnant: Automatix and Upgrading

It also seems that several of the dapper to edgy upgrade problems are caused by the use of Automatix; a tool to perform common customisations to Ubuntu, such as replace the pre-installed software with alternatives and install packages that Ubuntu is unable to pre-install due to patent or other legal issues. Henrink has a few good points about this, however I feel that it’s also important to remember that the Ubuntu community does not only consist of the core developers. Automatix, and its like, are by their very definition, tools to reduce the amount of your system that the core developers will support. The default set of installed packages is not arbitrary, and one may be selected over your preferred solution simply because we do not have the expertise in the team to deal with the other, or even because the other is not supported upstream! We therefore rely on the wider community to take ownership of these packages, and support them within the community structure. Support, in the development sense, doesn’t just consist of security updates either; it also consists of keeping the software up to date, fixing bugs, and most importantly of all; testing it before we release. The right approach to making sure that Automatix users are not bitten again during the edgy to feisty upgrade in 6 months time is for members of the community to come together and form a team to support it. The existing Automatix team in Launchpad is probably a good start. One of the goals of this team should be to make sure that throughout feisty’s development cycle, upgrading from an edgy box with Automatix installed works flawlessly. Where it doesn’t, they should take effort to ensure that useful bugs are filed (e.g. “foo 1.1-2 contains same file as bar 1.0-1 but neither Replaces nor Conflicts it”) so that the problems can be fixed. Likewise where community members suggest that a user install software from outside the main component, or even outside the Ubuntu repository entirely, they should keep in mind that they’re likely to cause that user problems when it’s time for upgrade. If you’re running a repository of your own right now, have you considered that you need to start testing upgrades from edgy with your packages installed to feisty? Testing when feisty releases is too late!

Scott James Remnant: Slippery Slopes

One of the most interesting thing about slippery slopes is how you never seem to be standing at the top of them, looking down. The slope seems fine at the top, and it’s only once you start down it that you realise this could end up with some broken limbs. When Ubuntu was formed, Debian were having a debate about how to treat GFDL documentation. It was their opinion that the GFDL was inherently non-free, and they’ve since taken steps to remove all such licensed documentation from their main distribution. We took a more pragmatic approach, and decided that it maintained the spirit of freedom, and thus we continue to this day to ship that documentation in our main distribution. A similar discussion resulted in the handling of data files such as graphics, icons, fonts, etc. We decided that such things didn’t necessarily need to ship with corresponding source code, as frequently they don’t have any such thing or when they do, it’s just as easy to modify the data file directly. The slope didn’t seem at all slippery back then. Then came the issue of firmware, binary blobs in the kernel which are uploaded into a flash (or similar) chip in the hardware. Could we distribute these? On one hand, these blobs have always existed, they just used to be in ROM in the hardware; the move to firmware doesn’t change that. On the other hand, they’re machine code and if we had the source, we could improve the hardware as well. And what if we didn’t distribute them? Our users would be stuck without being able to use some fairly (to them) critical parts of their computer. In the end, the argument that firmware isn’t inherently any less free on the disk than in the ROM won, so we opted to continue to ship it. Perhaps that slope is a bit slippery, but we’ve got a good foothold. Of course, at that point somebody notices the binary “Hardware Access Layer” in the Atheros WiFi card driver. It’s not firmware, it’s run on the host processor, and is separate to “comply with FCC law”. (The ipw3495 driver has a binary daemon that allegedly performs the same legal function). Again, if we don’t distribute that, a large section of laptop users will not be able to use their WiFi cards. A compromise was reached; because the driver is necessary we’d ship it, but in a special restricted component that makes it absolutely clear that it’s not completely free. Users could choose to remove that component and any packages from it, to keep their system untainted. Ok, foothold wasn’t as strong as we thought; tumbled a bit, but we’re definitely on solid ground now! That’s what we thought, anyway. Unfortunately it seems that there’s a point a little bit lower down the slope which has a fantastic vista. The views from there are just incredible, people are saying, much prettier than where we are now. The only trouble is that we’re not sure there’s a foothold down there, if we try for the better view, we could end up broken at the bottom. I’m talking, of course, about the NVIDIA binary X driver. (Some reports/blogs/etc. indicate we’re also considering the ATI fglrx driver, this isn’t true – that driver doesn’t support AIGLX, so it’s not being considered.) We’ve shipped this driver in our restricted section, but not enabled it by default. It’s been there for people who want it to switch on, if they know how, but the default driver has always been the free (albeit obfuscated) one in the Xorg distribution. The problem is that users do not need this driver, they can get decent enough 2D graphics support from the free(ish) driver. In the long term, they may even get decent 3D graphics support from the nouveau driver effort. What’s the problem then? Simple, other operating systems use the 3D GPU to make the desktop seriously beautiful. If Linux doesn’t catch up and do the same, then we’ll be considered obsolete again. And just to drive the point home, some of our Linux friends shipped similar support in their last releases. They don’t enable the NVIDIA binary driver, but this means that a large percentage of their user base can’t get the bling without manual hackery. We needed a way to catch up with both the commerical operating systems and other Linux distributions; we have a policy of not doing our own software development, but only packaging what others have developed, so the only way for us to get ahead was to package something that others wouldn’t. Which brings us back to the NVIDIA binary driver. If we install that by default, we’ll be bringing a 3D desktop to more people. And we’ll gain a step ahead of the other distributions. Will our users care? To be brutally honest, I think the answer is no! In fact, I suspect our users will largely love us for this decision. Most probably already install the NVIDIA driver anyway, because they think it’s better, or because (sadly, like me) they have a card combination not supported by the free one. Will this make any difference to the effort to get NVIDIA to free up the driver, or at least the specs? Sorry, but to be honest again, I don’t think it’ll make one little difference. Linux distributions have been refusing to install it for years, and yet NVIDIA haven’t budged in their position. Perhaps a new tactic is required. Maybe if we do install it, we’ll be more likely to be chosen by OEMs as we can actually support the hardware they install. Then later, we may be able to actually affect their decision as to what hardware they install, and maybe then NVIDIA will pay attention. Will this change the perception of Ubuntu in the Linux developer community? I’m not sure about this one, I think that those who already feel strongly about the distribution of binary drivers are probably already pretty grumpy at us distributing things like the Atheros and ipw3495 drivers. I suspect this will change the opinion of a lot of people who’ve been on the fence until now, probably equal in both directions. Will we be able to sleep at night? Despite all of the above, personally I still think that installing and using the nvidia driver by default, when the nv driver would do, is the wrong decision. If the nv driver doesn’t work, I’m willing to accept the nvidia driver being used; provided that there’s some message informing the user what’s happened, why it has happened, and which alternate graphics cards they can purchase if they aren’t willing to accept a non-free binary driver. If the nv driver is good enough for 2D, I would prefer that we instead disabled the 3D desktop effects for this group of users (by default). A similar message could explain why this is disabled, again which alternate graphics cards provide this by default, but also provide a button for the user to enable it if they wish. While we should make the correct moral decision for the defaults, we shouldn’t stand in the way of users who wish to make a different decision for themselves. Later as the nouveau driver becomes stable, we may be able to activate 3D support for nvidia users by default. I think that preserves our current foothold, we’d only activate it if there is no free alternative. Where there is, we’d be educating users about why they may wish to consider alternatives to NVIDIA in future, while at the same time not getting too much in their way if they want to see the better view down the slope. Unfortunately it’s not my decision, and I suspect that the lure of the bling will win out. With any luck, we’ll find a foothold there, and the fallout of doing so won’t be too bad. I’m just worried that once we compromise on this, we’ll start compromising on other things … would we replace Firefox with a non-free web browser that rendered web pages “better”? The slippery slope only gets steeper from here on …

Russell Coker: Who Benefits when Cheap Electricity is used?

In a comment on my previous blog post a question was asked as to who benefits when customers are able to use cheap electricity. The answer is that the electricity company benefits the most! When electricity sources such as wind and solar power which can vary in capacity are used the electricity would be cheaper when there is adequate or excess supply. The electricity would be cheaper then to encourage customers to use power hungry devices at those times rather than when the electricity supply is reduced. The larger the capacity of back-up power plants such as gas-fired plants the larger the overall cost of the system (having extra peak-load capacity that is unused most of the time is a waste of money). However the company that I once worked for on a project related to this was not an electricity company. I can’t name the company due to the confidentiality agreement but if the project ever goes into production I’ll blog about it. Recently some of the major investment banks have been focussing on how climate change affects business. I think that with these developments there will be a lot of new investment in environment related technologies. Probably if a few people started work on an embedded Linux box for scheduling power use they could have a good chance of getting some investment. The ideal feature list would include control and monitoring over the Internet, the ability to schedule operations based on power price (received from the grid via a technology similar to X10) and local conditions (how charged the batteries are in your photo-voltaic system). It would control devices via standard X10 modules (which can control the power to the device) as well as directly interfacing with machines that need to be turned on all the time. I would be happy to offer more suggestions via private email to anyone who is interested in implementing this.

Joey Hess: night venue/ept

Hmm, it's funny to be asked to blog about something. By mupltiple people. I could talk about an old church filled with a 100+ geeks, an organ played by Keith Packard, wine and cheese from all over the world, etc, but ok, I'll bite: Now that I got it working, Enrico's ept-cache is pretty neat. It found a lot of odd cruft on my laptop, along with some packages you probably don't know about that I'd be happy to chat about. termnet - Simple Telnet replacement for termnetd
grunt - Secure remote execution via UUCP or e-mail using GPG
longrun - Transmeta Crusoe LongRun control utility
iconc - Compiler for Icon, a high-level programming language
dbacl - digramic Bayesian text classifier
icont - Interpreter for Icon, a high-level programming language
bogl-bterm - Ben's Own Graphics Library - graphical terminal
intercal - an INTERCAL de-obfuscator
geotoad - geocaching query tool
libnet-openid-consumer-perl - library for consumers of OpenID identities
libapm-dev - Library for interacting with APM driver in kernel
libtextwrap-dev - text-wrapping library with i18n - development files
libklibc-dev - kernel headers used during the build of klibc
fuzz - stress-test programs by giving them random input
libdebconfclient0-dev - Development files for cdebconf
libslang2-pic - The S-Lang programming library, shared library subset kit
libnewt-pic - Not Erik's Windowing Toolkit, shared library subset kit
gnats-user - The GNU problem report management system (client tools)
libdebian-installer4-dev - Library of common debian-installer functions
mailfilter - A program that filters your incoming e-mail to help remove spam
buici-clock - attractive desktop clock)
atari800 - Atari emulator for X/curses/SDL
hercules - System/370, ESA/390 and z/Architecture Emulator This does make for fun conversations..

Gustavo R. Montesino: The world is full of (different) bugzillas....

... but the KDE's wins the strangeness award so far...


>>> import urllib2
>>> opener = urllib2.build_opener()
>>> f = opener.open("http://bugs.kde.org")
>>> print f.read()

[...]

<h1>Page not found</h1>

<p>KDE has switched to bugzilla. Please go to the <a href="/">main page</a>
to search for your bug.</p>

[...]

>>> opener.addheaders = [("User-agent", "bzutils")]
>>> f = opener.open("http://bugs.kde.org")
>>> print f.read()

[...]

<h1>KDE Bug Tracking System</h1>
<p>This is KDE's bug tracking system which files details of wishes, bugs and crashes
reported by users and developers. Each report is given a number, and is kept on file until it is
marked as having been dealt with. For participating you need a personal account which will gain
you the ability to post reports and comments as well as voting for specific reports and observe
development. You'll need to enable cookies for this site for staying logged in.</p>


Questions:
1) Why does kde bugzilla require user-agent to work?
2) Why it doesn't return something more descriptive?

18 June 2007

Pablo S. Torralba: IPMI

IPMI stands for "Intelligent Platform Management Interface", an interesting feature deployed on nowadays servers. I can't forget that question I made some months ago about an extra ethernet port on the IBM server machines we were working with on those days. The answer was quite simple: it is almost of no use at all; at most you can get some stats and diagnostics but it is mainly intended for hardware technicians.

Liars (or ignorants)! Anyway, it is quite useful. It is the IPMI port which can be used for several managements actions (even from the running system) such as power cycle the machine, get some stats, establish a watchdog interface and the like.

Uses?, are they need to be told?. As a first glance you can get reports about the machine from the operating system itself without the need of physical access to the datacenter. You can also restart a machine which is failing to reboot by itself in case you can login one more time in the system. But... even more, you can do all that (and more) from a remote system (don't exhitate, it is password protected, at least, in case you configure it so). So the next obvious uses are for cluster fencing and stonith (shot the other node in the head) without the need of power control hardware.

It is a pity we didn't knew that when we configured the SAP cluster in my previous job despite the serial cable almost did it work. Sure Mr Navas will be interested in knowing about this technology :-)

Oh, a simple example:

# ipmitool -I open chassis status
System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false
Sleep Button Disable : not allowed
Diag Button Disable : allowed
Reset Button Disable : not allowed
Power Button Disable : allowed
Sleep Button Disabled: false
Diag Button Disabled : true
Reset Button Disabled: false
Power Button Disabled: true


Another one:

ipmitool -I open chassis power reset

Ooooooops. Next post after crash :-)

Andrew Pollock: [life] So close and yet so far...

I went out drinking last night, and got fairly plastered in process. I staggered back to the hostel at about 10pm, and amazingly, had the presence of mind to plug my laptop in to charge - to mean feat, given I had to assemble the three bits of the iGo charger. I woke up this morning feeling pretty pleased with myself (albeit in a seedy kind of way), until I discovered that I'd either failed to plug the cable into the laptop, or it fell out overnight, so it was all for nothing in the end. Oh well. It gets light here extremely early, and I woke up at about 4:30am and couldn't get back to sleep, so after a few more hours of lying around being seedy, I headed out for a brief reconnoitre before heading in to the morning sessions. I love this city! It's just so old. Edinburgh Castle looks really cool. I'm looking forward to checking it out.

17 June 2007

Stefano Zacchiroli: packages svn maintained on alioth

Figures About SVN-Maintained Packages For fun and profit I and gares have just harvested a bit alioth to discover how many packages are currently maintained using subversion. The overall result is larger than I expected 3492 source packages (to be compared with 11786 total packages in unstable) are maintained using Subversion. The numbers might be a bit approximated, I report what we did to extract these number for review. The number of subversion-ed source packages have been computed running on alioth the script harvest source fields.sh (which in turn uses svnlook grep.py) its stdout can be redirected to a .txt file. Once sorted and removed of duplicates you will get something like source pkgs on svn.txt; its length approximates the number of source packages maintained via svn:
$ wc -l source_pkgs_on_svn.txt
3493

The approximation is due to the fact that debian/control are looked for everywhere in a repository, hence it can find old packages no longer in the archive or never uploaded, and some fake package (like "MODULE NAME", but it seems to be the only one). The amount of packages which are in the above list but not in the archive is about 900 packages. Still I don't think it would be fair to exclude all of them since I guess a non trivial part of that are packages that haven't yet uploaded and hence are arguably part of the active development of Debian. Excluding them, the percentage of unstable maintained using SVN on alioth is about 22%. To that you should add the packages maintained using other version control systems. The total number of source packages in unstable have been computed on my laptop as follows:
$ cd /var/lib/apt/lists/
$ ls *Sources
ftp.it.debian.org_debian_dists_unstable_contrib_source_Sources
ftp.it.debian.org_debian_dists_unstable_main_source_Sources
ftp.it.debian.org_debian_dists_unstable_non-free_source_Sources
security.debian.org_dists_testing_updates_contrib_source_Sources
security.debian.org_dists_testing_updates_main_source_Sources
$ cat *Sources   grep ^Package:   sort -u   wc -l
11786

The broader goal was to discover how many packages are maintained using any versioning system on alioth, but we were fluent only in svn internals. Dear lazyweb, feel free to harvest and forward to me your data for the other versioning systems available on alioth, I'll keep this post updated with news.

Anthony Towns: Dunc-tank Report Ideas

Okay, so with the “Bits from the DPL” talk that Sam and I shared now out of the way, that hopefully means finishing off the whole dunc-tank thing won’t imply any more conflicts of interest, potential or otherwise. And since we’ve now had the post-etch release team report, there shouldn’t be much to wait around for. I’d been kinda hoping to be able to come to debconf with a pre-prepared report of similar quality to the debconf6’s final report (or debconf5’s for that matter); but while I was going back through the discussion threads, it just got harder and harder to find a way of writing the report that didn’t seem like it’d just inspire the same arguments again. I think that’s avoidable – I know some of the people who were against the way dunc-tank ended up have indicated there are other approaches they might support, and it ought to be possible to summarise the dunc-tank experience in a way that lets us have a better idea what to do in the future based on that experience, than have the same disagreements we’ve already had. Anyway, my best guess is to try crafting the report via blogging or put it on a wiki or something. Anyway, there are three things that I thought we could usefully have in a report that wouldn’t devolve into the same old arguments (after all, if we at least have new arguments, that’s some sort of progress!). First of all is trying to have a real understanding of what happened with etch – getting a release out is complicated with lots of potential blockers beyond just “release management” work: d-i, kernel, toolchain, CDs, builds, bug tracking, whatever. Presumably dunc-tank only ever had a chance of removing release management as a blocker, and since we can’t redo the etch release while changing parameters like dunc-tank or Vancouver, at least having as clear as possible understanding of which blockers happened when, and what other influences might have been important the release process seems like a good way of understanding the influences that were and weren’t important, so we can have a better idea what to do in future. I’m figuring a reasonable structure might be something like: The theory is that the above should provide the information to make a good judgement of what (if any) effect dunc-tank (or the other projects) had on the release, without implying a preconceived conclusion of whether dunc-tank’s “good” or “bad” or whatever. As well as looking at the release stuff in some depth, it seems to me to be pretty sensible to do a report on how dunc-tank worked financially. Anyone doing any similar sort of “let’s raise funds, then spend them on free software” is going to have similar issues in getting publicity, collecting funds, and actually spending them, no matter how they end up deciding on the harder questions of deciding who or what to fund. There’s not a lot to say there, and I don’t think there’s much that’s controversial there either, but there are a few problems and approaches to solving them that are worth reporting on. I think that’s about as far as you can get trying to cleverly avoid the controversy though. And presuming we rule out the idea of choosing a position on some of the controversial questions and advocating for that (“dunc-tank was good, paying release managers was awesome, we should do it again for everyone!”), the best idea I’ve had so far is to just try summarising some of the controversial questions that remain open, which Debian, or dunc-tank, or whoever can then address in whatever way we like – by GRs, or further debate, or more experiments, or leaving it to other people to do for us, or whatever. So having the questions and some of the arguments for various answers and summarising what happened with dunc-tank seems like a plausible way to go. The questions I’ve got: No promises as to whether they’re the best questions, the best sub-points, or that we’re going to be able to come to an answer on any of them. :) Anyway, that’s my theory so far, no I need to grab some lunch before the next lot of talks – feel free to mail me, or talk to me in person, or blog responses or whatever…

Daniel Burrows: aptitude development moves to Mercurial, back to Alioth

Short version: the aptitude development tree is now maintained using Mercurial, go here to fetch it.

aptitude development has been using darcs as a version control system for the last two years. Darcs is a distributed version control system with many great concepts -- but it has one huge, glaring, enormous flaw, which is that innocuous operations, like merging one branch into another, can require practically unbounded amounts of time and space. And once two branches get screwed up in this way, there is nothing, nothing at all, that you can do to get yourself unwedged; the cause is a design flaw in darcs that no-one seems to know how to fix or work around.

Recently, I made the mistake of changing some files in both the Debian branch of aptitude and the head branch, and when I tried to merge the two branches to upload a new upstream release, darcs went off into la-la land. So, I figured that it was probably time to switch version control systems.

I'd like to say that I did extensive research on the matter, but the truth is that I chose Mercurial based on the fact that (A) a lot of ex-darcs users have written nice things about it, (B) git and arch-derived systems always feel ugly to me, and (C) John Goerzen implemented support for mercurial on Alioth. Yes, I am so a follower.

So if you want the up-to-date aptitude source, you should go to http://hg.debian.org/hg/aptitude/head. You can also fetch an RSS feed from http://hg.debian.org/hg/aptitude/head?style=rss.

You can fetch a copy of the repository with "hg clone http://hg.debian.org/hg/aptitude/head aptitude-head". To update, I recommend putting the following lines in ~/.hgrc to enable the "fetch" extension:


[extensions]
hgext.fetch =


Once you've done this, just run "hg fetch" and it should download and merge the latest code. You may want to install kdiff3 to get a better merge tool as well.

To commit a patch locally, run "hg commit". Unfortunately, there doesn't seem to be any easy way for people to send patches back within the VCS like there is for darcs (one of many nice features I had to give up in favor of being able to actually get work done -- what, me bitter?), but it looks like you can get somewhere with "hg bundle <file>", then mailing the resulting file off.

16 June 2007

Kartik Mistry: The new geek is born!

* Baby Boy, 16/06/07, 9 PM IST, 3 KG

Andrew Pollock: [life] In the Mother Country

So I'm off travelling again. I've done way too much lately, and I'm looking forward to getting home and staying there for a while. I flew from San Francisco to London yesterday for my first ever business class trip. United business class is whole different experience to United economy, that's for sure. Aside from getting ridiculous amounts of legroom, and much better cabin service, the thing I like best about the whole experience was the preferential treatment. I arrived at SFO, and there was an unholy amount of people at the economy check-in counters, so it was really nice to breeze around to the business check-in counters and wait in a much more manageable line. At Heathrow, I got to used the priority immigration line, and my bag came out pretty quickly, so I'd breezed through Heathrow and onto the tube faster than you could say "Pussycat, pussycat, where have you been?". Very happy with all of that. I caught a Piccadilly line tube from Heathrow to Acton Town, then changed to the District line to Victoria station. The tube (particularly the first one) was smaller than I expected. The ceiling was pretty low, the aisle narrow, and it just felt pretty squishy. The second one seemed a bit wider and taller. It didn't feel like it could really deal with peak-hour commuting, but I guess maybe the frequency makes up for the capacity... Buckingham Palace Road turns out to have pretty wacky numbering. Just because you're opposite number 80, doesn't mean the odd numbered 80's are anywhere near you. So it took me longer than it should have to find the hotel, and I wandered up and down Buckingham Palace Road for a while before I'd managed to calibrate myself to the numbering. More frequent numbers on the buildings would have helped immensely. So I've hardly seen anything, I'm really just passing through on the way to Edinburgh for Debconf, but I love what I've seen so far. The red double-decker buses. The taxis. The post boxes. The phone booth's. It all feels really really old, but still really really alive. We've got to come back and do the place properly. The office is really nice as well. Very modern looking. Very open-plan like the Sydney one. I wasn't able to sleep on the plane unfortunately (I couldn't convince my brain to switch off), so I was pretty zonked by the end of the day (got into the office shortly after 9am). I had a fairly productive day, and went to the hotel and crashed at about 6:30pm, woke up at about 2:30am and couldn't get back to sleep. Hopefully if I just soldier on through today, I'll get to sleep a bit later this evening and do something closer to a normal night's sleep. I'm catching the train to Edinburgh today (I blame Mark (who doesn't appear to believe in permalinks) for putting the idea in my head). Looking forward to another tube ride and seeing some of the countryside. I've been really apprehensive about this trip ever since I booked it. Mainly because I'm going over to Dublin after Debconf to try and apply for a new visa. For some reason, I'm just really worried that's all going to go pear-shaped. I'm feeling better now that I'm here, but I'll feel even better once the trip to the consulate is behind me. Even better still when I get my passport back successfully. Best still when I'm home again.

15 June 2007

David Moreno Garza: Call for Gathering of the Indigenous People of the Americas

Transcript of the call for participation on the Gathering of the Indigenous People of the Americas. If you don’t mind, feel free to skip it. Considering that 515 years after the first invasion of our ancestral territories, the war of conquest, the plunder, and capitalist exploitation have not altered their course, but rather have become a new war of extermination, a war designed for the destruction and utter plunder of all the original peoples of the Americas; Considering that the long history of wars of independence and numerous revolutions that have taken place on our continent have not yet changed the condition of colonized people, nor have they allowed for a full recognition of our rights in the nation states that formed in the last two centuries; Considering that despite a long history of domination, our resistance has sustained itself and that our people continue to live and struggle, and that this struggle has been encouraged by the uprising of the Zapatista National Liberation Front (EZLN) in the first days of 1994; Considering that the strategies of the national governments of the Americas have always sought the division of our people through the establishment of borders, reservations, and legislation designed to fragment us and to neutralize our efforts of autonomy; Considering that the strengthening and the unity of the struggles of liberation of the indigenous people of the Americas will be possible as our peoples meet and come to know each other; Considering that for our people it has proven necessary that their struggles be made known world wide in order to be supported by all honest movements that struggle for a society effectively just, free, and democratic; All indigenous communities, tribes, and nations of the Americas are called to

THE GATHERING OF THE INDIGENOUS PEOPLE OF THE AMERICAS Which will take place the 11st, 12nd, 13rd, and 14th days of October, 2007 in the community of V cam, Yaqui Territory, Municipality of Guaymas, State of Sonora, Mexico, to address the following

TOPICS 1 The war of capitalist conquest in the indigenous communities in the Americas.
2 The resistance of the indigenous peoples of the Americas and our defense of
mother earth, our territories, and our cultures.
3 Why do we, the indigenous peoples of the Americas, struggle?

ORGANIZATIONAL PRINCIPLES 1st Principal. Delegates, observers, and communications media workers attending the Gathering will abide by the regulations of the Yaqui Tribe devised by their Traditional Authorities in order to govern their presence while in attendance.
2nd Principal. All participating indigenous communities, tribes, and nations are invited to demonstrate their clothing, songs, dances, and other traditional forms of expression.
3rd Principal. Authorities and Representatives of indigenous communities, tribes, and nations of the Americas are invited to participate as delegates with voice and vote.
4th Principal. Individuals and members of social movements and civil organizations in solidarity with the struggles of indigenous peoples of the Americas invited by the organizing commission will be able to participate as observers.
5th Principal. National and international communications media workers that are accredited by the organizing commission will be able to cover the event.
6th Principal. All agreements adopted at the Gathering will be made by consensus of the participants and not through the method of voting.
7th Principal. Organization of the Gathering, the national and international distribution of its publicity, as well as accreditation of participating delegates, invitees, and any unforeseen issues will be resolved only by the organizing commission in conformity with the Traditional Authorities of the Community of V cam, Yaqui Tribe, The National Indigenous Congress (CNI), and the Sixth Commission of the Zapatista National Liberation Front. Information: 1. Office of the Sixth Commission of the EZLN, located on Zapotecos St. No 7 Col.Obrera, C.P. 06800 Mexico, D.F. Telephone: (01 or 011) 55 67 61 42 36 Monday thru Friday, 10 AM 8 PM., Saturday, 10 AM 6 PM.
webpage: www.encuentroindignea.org e-mail: informes@encuentroindigena.org
2. Official Precinct Office of the Traditional Guard of the Yaqui Tribe, Vicam Station ,Colonia Yaqui, Municipio de Guaymas, Sonora, Mexico. Telephone: (045 or 001) 64 49 98 94 08.
3. Office of the Organization of Indigenous and Campesino Communities, de Tuxpan, Jalisco, in Nicolas Bravo, No. 65 , Tuxpan, Jalisco,. Telephone: (01 or 011) 371 41 764 15 from Monday Saturday, 10 AM 8 PM. e-mail: comunidad_tuxpan@hotmail.com Written - April 22nd, 2007 in Tohono O Odham Territory of the Tohono O Odham Nation, Sonora, Mexico. Attentively,

Wa-a itom yo Lutu-ria yoribetchibo, intoka a Wiutinepo Amani
(Por el respeto a nuestros usos y costumbres, nuestra identidad y cultura y nuestra verdad que permanezcan en el tiempo y no se olviden)

Never Again, a Mexico Without Us ~ Liberty, Justice, and Democracy

 

Nde Cultural Historical Organization
(Organizaci n Cultural e Hist rica de la Naci n Nde/Apache)

 

Tierra y Libertad / Chicana Indigenous Organization, Tucson, Arizona
(Tierra y Libertad / Organizaci n Xicana Ind gena, Tucson, Arizona

 

Native and Immigrant Indigenous Development Organization
(Desarrollo de Los Pueblos Indios Inmigrantes y Nativos, A.C.)

 

Michelle Cook (Dene Nation)
(Nacion Dene/Navajo)

 

Tohono O Odham Nation Mexico United States
(Nacion Tohono O Odham M xico - Los Estados Unidos de America)

 

Traditonal Authorities of Vicam Community, Yaqui Tribe
(Autoridades Tradicionales del Pueblo V cam, Tribu Yaqui)

 

National indigenous Congress (Congreso Nacional Ind gena)

 

Clandestine Revolutionary Committee, General Command of
the Zapatista National Liberation Army (EZLN)
(Comit Clandestino Revolucionario Ind gena-Comandancia General del
Ej rcito Zapatista de Liberaci n Nacional)

Anthony Towns: Men in Skirts

Well, made it to Edinburgh, via a forty hour stopover in Singapore. Picked up a tie and kilt in the Debian tartan. Sadly Edinburgh in midsummer isn’t as warm as Singapore in summer, or even as Brisbane in winter, so there’s good odds my knees are going to be shaking as well as visible all to soon. Oh well, there’s reports that there might be scattered sunshine by Monday – fingers crossed. The dak BOF’s been delayed until tomorrow (Saturday 3pm, Edinburgh localtime) so Andi and Steve can sit in. Bit weird having something that technical on Debian day, I guess, but hey, whatever. It’s scheduled for a 2hr session, but I’m hoping it’ll be pretty informal and hacky rather than slides and lecturing or whatever. I’m hoping people will arrive with some ideas on what cool things that dak ought to be handling, and we can spend the time actually making dak support as many of those things as possible. Some of the ideas I like are in the BOF proposal. It might also be worth having a look at the video (or audio) of Robert Collins’ talk (“…Release always?”) at the Debian miniconf at linux.conf.au earlier this year, particular related to some of the ideas about setting up separate GNOME or KDE or libstdc++ staging areas for getting major updates ready for unstable rather than mixing them all up in experimental. Anyway, feel free to plan on arriving or leaving anytime during the BOF, unstructured is just another word for freedom! Yesterday I had a quick chat with Frans about getting debootstrap officially incorporated into the d-i subversion repo, so that it’s officially team maintained, and there’s a convenient central place for hacking on it. Given the recent discussion (while I was flying to debconf, in fact – how inconsiderate!) hopefully that’ll mean we’ll get a couple of cleanups there too. Oh, also got informed that Eben Moglen will be giving a free lecture in Edinburgh on Tuesday after debconf (the 26th) courtesy of the Scottish Society for Computers and Law. Sounds interesting if you’re into the whole theory of law and the effects of modern technology thereon:
In this lecture, Professor Moglen considers how private legislation is replacing public law as the organising intellectual structure for software and the technology industries, with far-reaching social consequences and theoretical implications.
Not sure if he’ll arrive in time to drop by during DebConf proper or not.

Eddy Petri&#537;or: libgnome-dev + libsvn-dev = problems

On Debian Etch systems it is impossible to install out of the box both libglade-gnome0-dev and libsvn-dev due to a conflict between depended upon libraries.

In order to install them side by side you will have to modify an existing libdb4.4-dev deb package to add "libdb3-dev" to the Provides: field of the package. You can do this by editing DEBIAN/control after running:

deb-reversion -k /bin/sh libdb4.4-dev_*.deb

When done, exit and install the newly created libdb4.4-dev package:

dpkg -i libdb4.4-dev*LOCAL*.deb


I managed to find this solution thanks to mrvn and other people on IRC. Thanks.

14 June 2007

Daniel Stone: avivo and donations

Just a quick note to say a huge thanks to everyone who's offered support (financial, hardware-wise, or just verbal) to the r5xx project -- we really appreciate it. A couple of FAQs:

  • Thanks! Where can I send money?
  • Sadly, money isn't the issue: we have jobs/university theses/lives to tend to. We just lack for time right now.

  • Thanks! Where can I send hardware?
  • If you have a card that you won't be needing back (we may lose or fry it), please email myself (daniel@fooishbar.org) and J r me (j.glisse@gmail.com), detailing what you have, and we'll get back to you if it'll be useful to us.

  • Will this work with the X2xxx cards (r6xx)?
  • Yeah, pretty much. It just needs someone to hack up the small amount of code to deal with it.

  • What's happening with X1650 and above (r530/r580)?
  • Most of the code is written, however, initialisation doesn't happen correctly for some reason.

  • What's happening with 3D support?
  • It should be relatively simple to implement from the existing driver, as the engine is believed to be extremely similar, but we want to get the basics working before we start attacking things like this.

  • Which tools do you guys use?
  • For tracing the video BIOS, we use a hacked version of xresprobe: vbetool will instrument the BIOS quite well. For tracing fglrx, we use a hacked version of valgrind: run it against the X server, making sure that it is not suid root. For getting impatient and playing with registers, we use avivotool.

  • Where does the development happen?
  • On IRC, #dri-devel seems to serve somewhat as the ATI development centre. This gets fairly well coalesced into The Irregular Radeon Development Companion, however, so you may prefer to just follow that.

  • Shouldn't all this be on a wiki page somewhere?
  • Yes, but I have to get up in less than four hours.

    Once again, thanks for the support, from all of us. It's been great.

    Gustavo Franco: debcamp updates - round III

    There's a lot more bits but I can't remember everything, oh I've also met siretart. :-)

    13 June 2007

    Eddy Petri&#537;or: Your next Gnome subversion client...

    ... is NaughtySVN.

    I have joined this project which was started by Alexander Thomas a few weeks ago and I have convinced him that is better to have a release sooner rather than later. The project is still in its early alpha stage[*] but I thought is better to have a rather minimalist and functional client first.
    So, I talked to Alexander and we came up with a roadmap; for the 0.0.1 release I am working on the update feature which is about 40% done[1][2] (update dialog screenshot).

    Of course, after the release I will probably make a debian package, too, unless someone else beats me to it :-) .

    So, the future is bright.


    Update: as a response to a comment, NaughtySVN is designed to be not only a Subversion client, but also a framework for other VCS-es and other clients. It just happens that we are working on the Subversion backend and client at the moment.

    P.S.: as curiosity of mine, I have written in python a small nautilus plugin that does the svn update (is a svn frontend) and I must say I really miss the development speed of python when writing in C (or maybe I am out of practice).

    [*] only a few features are implemented and can't be used yet as a SVN client without being forced to use another client.
    [1] according to my estimations
    [2] update related code is not committed yet

    12 June 2007

    Matt Brown: Back on the Intarnets

    Now that we’ve settled into our new apartment in Dublin, the ADSL has been connected and I’m back on the net! Obviously I’ve had Internet access at work during this time, but there has been so much new information to take in that I haven’t really had time to do any Debian or WLUG work. I’m still waiting for the shipping company to deliver my computers, so it will be another week or two before I have a development environment that can build and test package. Once that’s setup again I have updates queued for the following: Unfortunately I’m not going to make it to Debconf this year, despite being the closest geographically that I’ve ever been. :(

    Daniel Stone: Initial Avivo release

    As J r me announced, the Avivo driver for newer ATI chips is now available. Unfortunately we've all been very busy, so it's taken literally months longer than we'd hoped. But we have a driver that, while having no acceleration, is able to set modes on VGA, DVI, and laptop panels: all it really lacks is TV out support, and support for the complete set of models. Pretty cool stuff. Any help we can get is appreciated, so if you've done X or driver development, or are interested in same, please get in touch via xorg@lists.freedesktop.org. It's completely FLOSS, licensed under the GPL.

    Part of the reason I've been so busy is trying to arrange the X Developers' Summit in Cambridge, UK, around the 10th of September. But more on that later.

    Next.

    Previous.