Search Results: "tar"

11 August 2010

Russell Coker: Ethernet Interface Naming

As far as I recall the standard for naming Linux Ethernet devices has always been ethX where X is a number starting at 0. Until fairly recently the interface names were based on the order that device drivers were loaded or the order in which the PCI bus was scanned. This meant that after hardware changes (replacing network cards or changing the BIOS settings related to the PCI bus) it was often necessary to replace Ethernet cables or change the Linux network configuration to match the renumbering. It was also possible for a hardware failure to cause an Ethernet card to fail to be recognised on boot and thus change the numbers of all the others! In recent times udev has managed the interface naming. In Debian the file /etc/udev/rules.d/70-persistent-net.rules can be edited to change the names of interfaces, so no matter the scanning order as long as an interface retains it s MAC address it will get the correct name or at least the name it initially had. One of the down-sides to the way this operates is that if you remove an old Ethernet card and replace it with a new one then you might find that eth1 is your first interface and there is no eth0 on the system this is annoying for many humans but computers work quite well with that type of configuration. I ve just renamed the interfaces on one of my routers by editing the /etc/udev/rules.d/70-persistent-net.rules file and rebooting (really we should have a utility like /sbin/ip with the ability to change this on a running system). I have decided to name the Ethernet port on the motherboard mb0. The PCI slots are named A, B, and C with A being the bottom one and when there are two ports on a PCI card the one closest to the left side of the system (when viewed from the front the right side when viewed from the read) is port 0 on that card. So I have interfaces pcia0, pcia1, pcib0, pcib1, and pcic0. Now when I see a kernel message about the link going down on one of my ports I won t have to wonder which port has the interface name eth4. I did idly consider naming the Ethernet devices after their service, in which case I could have given names such as adsl and voip (appending a digit is not required). Also as the names which are permitted are reasonably long I could have used names such as mb0-adsl, although a hyphen character might cause problems with some of the various utilities and boot scripts I haven t tested out which characters other than letters and digits work. I may use interface names such as adsl for systems that run at client sites, if a client phoned me to report Internet problems and messages on the console saying things like adsl NIC Link is Down then my process of diagnosing the problem would become a lot easier! Does anyone else have any good ideas for how to rename interfaces to make things easier to manage? I have filed Debian bug report #592607 against ppp requesting that it support renaming interfaces. I have also filed Debian bug report #592608 against my Portslave package requesting that provide such support although it may be impossible for me to fix the bug against Portslave without fixing pppd first (I haven t looked at the pppd code in question for a while). Thanks to Rusty for suggesting this feature during the Q/A part of my talk about Portslave for the Debian mini-conf in LCA 2002 [1].

Bdale Garbee: TeleMetrum at Apogee Components

Exciting news! As of today, TeleMetrum starter kits are available through Apogee Components in addition to the Garbee and Garbee web store!

Gregor Herrmann: RCBC - results and prizes

At the beginning of DebCamp, Zack started the RCBC the Release Critical Bug squashing Contest. Two weeks later not only DebConf10 is over but we also have results for the RCBC:

In summary: It was a huge success, we managed to fix And the winners are: All details can be found at http://wiki.debconf.org/wiki/DebConf10/RCBC.

The winners who haven't collected their prizes at the closing ceremony will get them be snail mail.

Finally let me thank

Marco Túlio Gontijo e Silva: Immix on GHC Summer of Code report #11

My project. This post assumes that the reader has read my last post. I ve been trying to find a reasonable method (which computer to use, single user or multi user) to benchmark for some time, and now an e-mail from Simon Marlow calmed me down. He suggests that in this stage it s not necessary to run a long benchmark, but only a short one, that will be enought to have an idea about what each change is causing to performance. For some time I was struggling with the benchmarks to get a reasonable result. I ve started more than once to write a blog post analysing the results I ve got, until in the middle of the post I notice the results are not consistent. This usually happens when there s a big distortion in benchmarks that shouldn t present no change. For instance, in a patch that only changes code that is executed with +RTS -w -RTS, there was a difference of 50% on execution time in default mode, that is, without +RTS -w -RTS. I think that only disabling CPU scaling and running a small number of tests, which make it easier to reproduce a possibly inconsistent result, will be enough to get a good data. I ve made a stack of patches, splitting each part of my work. The stack does not reflect my preferences between the patches, that is, the complete stack applied is not what I think that is the best change to GHC. It s only a set of patches applied linearly, in a way that it s easy to see the impact in performance of each change. The patches are: Don t check for swept blocks in -DS.
The checkHeap function assumed the allocated part of the block contained only alive objects and slops. This was not true for blocks that are collected using mark sweep. The code in this patch skip the test for this kind of blocks.
This patch is only needed to make it possible to run the binary with the parameters +RTS -w -DS -RTS. I ve already explained this patch. I didn t measure the difference in performance before this patch, since it only changes code that is not going to be executed in the benchmarks, since none of them are runned with -DS. Immix: allocate and free memory on lines. This is the main patch with the initial implementation of Immix. As it is the initial implementation, it has it s problems, that will be treated in the following patches. The comparison was done using 3 programs from nofib/gc: fibheaps, fulsom and constraints, as suggested by Simon Marlow. Two tests were made for each version of the compiler code: one using the default GC strategie (copy-collection with mark-compact if there s few heap space left), another one using mark-sweep (or Immix after my changes). When comparing the default GC strategie between before and after this change, the program got 0.4% slower, with the collection of the generation 0 being 0.1% slower and the collection of the generation 1 0.4% slower. Comparing the mark-sweep with Immix, it got 13.7% slower, 15% in GC0 and 7.2% in GC1. The change in memory used is irrelevant. Chose between allocating in line or blocks in todo_block_full The first improvement I ve made is to change the place where the allocation was searching for free lines. Most of the changes were done in the function alloc_for_copy(), in rts/sm/Evac.c. This is bad because this function is called a lot of times, and should be kept fast. So I moved them to ctodo_block_full() in rts/sm/GCUtils.c. It got about 9.9% and 9.6% faster in default and sweep, which makes it 1% faster and 2.8% slower than in the original code. Improvements in sweep() I was bothered that the code I ve written to free memory in lines was messy, and I thought it could be simplified and maybe even turn faster. The general execution time increased 0.4%, but the GC1 time, which is the only one that should be affected, was reduced by 0.6%. In the default GC strategie, there was also a 0.2% increase in time, so I guess this is inside the margin of change. I have to investigate better on this one, but it seems to have improved slightly the performance. Line before inscresing block size. In a conversatio with Simon Marlow, we thought about these two options: one is to search for a line after trying to increase the block size, and that s what I did in Chose between allocating in line or blocks in todo_block_full; the other is trying to search a line first, and just increase the block size if a block (and not a line) was being used for allocation and there is no line available. With this patch I ve changed it to use the second one. Using sweep, the GC time got 0.5% slower, and with default it got 0.1%. rts/sm/Sweep.c: Mark all BF_MEDIUM blocks as BF_FRAGMENTED In my first implementation, the blocks that contain objects bigger than a line (of medium size) are marked with BF_MEDIUM, and are treated as the usual block in mark-sweep: if the block is empty, it s freed; if it s very fragmented, it s marked to be collected using copy-collection. In this patch, instead of making it use the rules of mark-sweep, I just mark it as fragmented and make it be collected by copy-collection. This made the GC0 time be reduced by 3%, but caused an increase of 509.7% in the GC1 time. This was also the first time the memory used was reduced, by 25.4%. The results in the default mode are insignificant. What it seems to me is that the copy-collection code is more efficient with memory usage, but also more slow. Marking objects as BF_FRAGMENTED make this algorithm be used even for full objects. rts/sm/Sweep.c: Don t use 3/4 heuristics to mark as BF_FRAGMENTED The mark-sweep algorithm considered that an object was fragmented if more than 1/4 of the word groups are completely unmarked. I kept using this heuristic, and this change removes it, making more use of the Immix, and less use of copy-collection. This didn t change the memory used, and made the code 10.4% slower in sweep. In default GC mode, there was no relevant difference, as expected. Allocate in lines in minor GCs. In the initial implementation I was only allocating on lines only in major GCs, because I needed the mark stack, which was only available in these kind of allocations. In this change, I created the mark stack on all GCs, and used the allocation on lines. The results for the default mode are insignificant, and the code got 9.0% faster in sweep, using the same memory. Selection I ve made a selection with the presumably better patches, which are: Don t check for swept blocks in -DS, Immix: allocate and free memory on lines, Chose between allocating in line or blocks in todo_block_full, Improvements in sweep() and Allocate in lines in minor GCs. This is an attempt to achieve the best set of patches possible, to see how it improved the original code. Comparing the default strategie for this selection and the original code, it got 3.7% slower. Comparing both sweep, it got 3.9% slower. Comparing the original default with the final sweep, it got 4.2% slower and uses 4.7% more memory. There s a lot of room for improvement, and I m willing to hear suggestions of what I could change in the code to achieve this improvement.
The results are available. Every time I had doubt about a comparison, I d run both versions again to check. This is way there are some backup files. The data presented here is not from all the most recent versions of each measurement, but from the ones that I thought were more similar in conditions.

10 August 2010

Asheesh Laroia: "Debian for Shy People": What's next

What do you do when you have a technical question that you're embarrassed to ask? The first Sunday of Debconf, I led a birds of a feather (BoF) session called Debian for Shy People. The conference team scheduled it on "Debian Day," a pre-conference day that was open to the public and still had plenty of Debian Developers in attendance. I just uploaded the slides to the "Penta" page for the talk. I led it because of my own experience. In 2004 or so, I saw Debian as the cool kids' club, that awesome project that I wished I could be a part of. By 2006, I managed to get over myself, read the New Maintainer's Guide, and find a way to get involved. As of mid 2009, I am a full-blown Debian Developer. I have real ultimate power. But I sometimes do still feel hesitation akin to "Imposter Syndrome". (A bunch of people at Debconf didn't really believe I'm "shy," since I asked a lot of questions at the conference. At core, I don't naturally believe that the things I say are worth hearing, but I patch over this hesitation. Sometimes I speak too much, and then I feel ashamed of burdening everyone. But anyway, this is about Debconf not, me -- so moving on....) In the past year of being a Developer, one thing I've seen is that other contributors ask me privately for help. Rather than blast the public lists like debian-mentors, they email or IRC private-message me, or SMS me, or find me at a Linux Users Group event. I'm lucky to know these people, and they're lucky to have me as a safe person to ask questions of. Moreover, Debian is better because these people could move past their confusion to make a technical contribution. I began the BoF session by talking about when someone asked me for help. Then I asked, "How many of you have someone you can ask embarrassing questions of?" Of the forty people crammed into Schapiro 414, two people' raised their hands. One person put it plainly, "I don't know anyone else who does Debian." It reminded me of a fact that Karen discovered when she was doing market research for us at OpenHatch: the vast majority of free software programmers know zero other people who do free software. I had seen the figure; we even used it in a talk to try and convince venture capitalists to fund OpenHatch last year. But I didn't really feel it until I heard it from a room full of Debian contributors. I structured the BoF in two parts: First, I talked in front of some slides to set the tone properly, and then we enjoyed open discussion. As I was preparing thoes slides, Daniel Morais asked me, "What's the point of having the session? Why not just come up with some ideas, implement them, and not bother also talking about it at the conference?" I had considered this; I decided I wasn't self-confident enough to start implementing ideas without talking to people to make sure I wasn't the only one who saw a problem. But I discovered another benefit of giving the talk: people who want to make Debian more welcoming knew to reach out to me. So here are some thoughts that came from our discussion (and later discussions during the conference): I set up an Etherpad document on cjb's OpenEtherpad.org. This is what we learned together: One idea I had before the BoF was to create a discussion area that was safe for all questions, even if they seem silly. We talked for a while about what name that would take, if it were to become a new IRC channel. We reached something of a conclusion, but in the conference that followed Emmet Hickory offered to help make the debian-mentors IRC channel friendlyer. I think that's the best direction to take things, so the next step is for him and me to write up what we want and send a note to the debian-mentors email list explaining our vision. In the Etherpad document, people discussed the idea of doing Debian discussion over XMPP (also known as Google Talk, also known as Jabber). We weren't sure how such a place would get critical mass; someone briefly mentioned the idea of an IRC/XMPP gateway. I actually think this discussion is along a very reeasonable path, namely discovering what discussion method(s) Debian contributors want to use. (That might explain why I'm now an admin on forums.debian.net.) We also briefly discussed the idea of an anonymous question-answering service. I realize now that I'm not going to be able to have time to run that, but I still think it'd be a really cool idea. Biella would remind me that Debian is already successful at bringing in new contributors. I agree! As a free software project, we have an enormous number of participants. This is a really good thing, and we're clearly doing something right. The purpose of this talk was to figure out how to make contributing to Debian less stressful for those who participate. Truly, a "Debian for Shy People" effort isn't about shy people. It's about the moments of self-doubt we all have in which we don't know what to do and are too embarrassed to ask. I think that if the project more friendly, we can find more participants, make better use of our current ones, and see improvements to our diversity. Whew, that was long. What do you think of all this?

Gustavo Noronha Silva: Google s User-Agent sniffing makes one more victim

Remember when I said Epiphany worked out of the box with Youtube s WebM? Well, Google has recently decided to deny us WebM, like it did before with Wave, the Pacman doodle, and who knows what else? \o/ Wouldn t it be nice if Google practiced what they preach? Update: so it looks like my message went through to the people who needed to see it, and they found a filtering error in the User Agent sniffing code that made it think Epiphany was a too old Safari - I m told the change will land in Youtube soon, thanks for those paying attention, and working on this! User Agent sniffing keeps being a problem, of course, and there are other stuff to fix, so I will probably still push my patch to spoof the user agent to google services which are still mishandling Epiphany, but it s good to see some progress being made! Update2: I started shipping a patch to send the Chrome user agent string to google domains in the Debian package for WebKitGTK+, when the enable-site-specific-quirks setting is enabled (which is the case for Epiphany); I already found something we were missing out on =D Google Images seems to have been greatly improved, and now faking being Chrome we are also able to enjoy it:

Google Images improved

Guido G nther: system-config-printer-udev

Those old school ones among us that still need a printer who are new school enough to want to get rid of HAL should try system-config-printer from experimental. After replacing hal-cups-utils by system-config-printer-udev aptitude tells me: 
    The following packages will be REMOVED:
      hal u  hal-info u  
    0 packages upgraded, 2 newly installed, 2 to remove and 121 not upgraded.
Which means faster startup times and one daemon less on Squeeze's GNOME desktop. The new version also uses PolicyKit instead of gksu for finer grained permission control.

Alexander Reichle-Schmehl: How an "active" developer is defined

Apparently some people misunderstood Christian's recent statistics how Debian Developers are distributed over countries a bit. Especially the the sentence We now have 62% of active DDs while we had 73% last year. is kind of misleading, if you don't know how an active developer is defined. And especially, if you ignore the following sentence: This year's campaign of MIA work has been somehow "successful", apparently So, let's start with the active developers. To be precise: Neither Christian (nor did I back then) tried in any way to decide which developer is active, in the meaning of: He is actively contributing to Debian. That's pretty difficult data to get. Instead we just took the data available, and looked for activated accounts. And that's an important difference. See, if an Debian Developer leaves the project, his account doesn't get deleted (for various reasons), it just gets deactivated in our central account setup. So, when Christian wrote, he counted active developers he basically said: I didn't counted the deactivated accounts. So far so good. But indeed quite a lot accounts got disabled last year. Is that a bad sign (as some journalist say)? Actually no. As it's quite complex to check, who's still using his account (see http://wiki.debian.org/MIA for some explanation), it is quite possible for someone to still have his account active, who isn't using it. During the last year many of these Karteileichen (nominal members, if you will) have been deactivated (after being pinged several times). Or, to write it this way: While indeed quite some accounts have been disabled, Debian hasn't lost much through at, as these account's weren't used!

Stephan Peijnik: What's all the fuzz about canonical-census?

I know I have not updated this blog in quite a long time now, but something caught my attention today: canonical-census.

As slashdot.org reports Canonical begins with tracking their (OEM) installations. Now it's obvious that people are uncomfortable with a program running on their system which phones back to their OS vendor, that's why I have had a quick look at what exactly canonical-census does.

Firstly however, I would like to point out that the report on slashdot.org is very clear about which information is being gathered, being "the number of times this system previously sent to Canonical [...], the Ubuntu distributor channel, the product name as acquired by the system's DMI information, and which Ubuntu release is being used". And it's perfectly correct. After getting the canonical-census Debian source package (using dget -u https://launchpad.net/ubuntu/+archive/partner/+files/canonical-census_0.1.dsc) the source package shows, besides the Debian packaging information, two scripts:

Now what do those scripts actually do?

send-census is installed in /etc/cron.daily, which means it will be executed once a day by the system's cron daemon. It's a mere 48 lines long, and its code is quite simple. So everyone with at least some shell scripting experience can easily check what it's doing. Now guess what, it sends exactly the information as reported on slashdot to Canonical. Nothing more and nothing less.

Technically it keeps a plain text file containing a single number as its call-counter, residing in /var/lib/send-install-count/counter and uses an on my Ubuntu Lucid system nonexistent /var/lib/ubuntu_dist_channel file for getting information about the distribution channel.
The above mentioned "system's DMI information" is not the whole bunch of DMI information available, but only the contents of /sys/class/dmi/id/product_name, which strangely enough returns "System Product Name" on my machine. Last but not least it uses lsb-release to get the distribution release (ie. 10.04 for my system).

Now those four pieces of information are sent to http://census.canonical.com/submit via a simple HTTP GET query, using wget. The full URL with all the parameters added is:
http://census.canonical.com/submit?count=count&dcd=dist_channel&product=dmi_product_name&release=ubuntu_release_version

The second script, census, is the part working on Canonical's script. Basically census reads in their Apache's access log file and creates an SQLite database from the contents of the log file. With 391 lines this script is a bit longer, but it does not end up in the Debian package at all.

Personally I do not see how Canonical or one of their partners could possibly do anything harmful with that information. Comparing this to Debian's popcon reveals that Debian is gathering a lot more information.

Now there are two more things one should consider: census is targeted at OEMs, which means its unlikely that it will end up on each and every Ubuntu installation and can be uninstalled by removing the canonical-census package with your favorite package manager.

Finally, think about this for a second: It's a shell script you can always examine. There is no hidden magic and it's a plain HTTP request the script is sending. No evil things happening there.
And now compare that to what other (often proprietary) software vendors do and how much data they submit, possibly even in encrypted form so you do not know for sure what is being sent to them.

Personally I welcome the openness of Canonical with providing their users with the package's code this early and being straight about what information it submits. They could have silently added it to those installations after all...

Happy hacking!

Sune Vuorela: Previous weekend in Debian KDE land

3 interesting small things happened in the weekend. Due to the hard work of mostly Florian Reinhard and George Kiagiadakis, Bluedevil is now available. Bluedevil is a new and improved bluetooth handling thing targetted the KDE Workspaces. The Debconf people have uploaded the Qt Debconf frontend that I blogged about a while ago, so now it should be available. Last, but not least, applications now has more accurate data for if they are online or not, by using the ntrack library. This was especially problematic for people having some interfaces defined in /etc/network/interfaces, and other interfaces managed by NetworkManager.
This feature will be committed to upstream KDE whenever Will gets around to do it. As a added bonus, KDEBindings in Debian has seen a release critical bugfix (python plugins, e.g. plasma widgets, related), and the brokenness of Konsole (libkpty) on the kFreeBSD-arches have been tracked down to a libc issue and a patch has been made. All of this is expected to be part of next stable Debian release, codename Squeeze.

Tim Retout: Sunny Southampton

On my last night in New York, I didn't sleep much. At 6am, I said farewell to Central Park by running round the reservoir, which I hadn't yet done. There was a very nice red sunrise to be seen from the west side. Unfortunately I didn't sleep much on the flight home either. The British accents sounded quite unusual when we landed in Heathrow, and it was quite confusing not being able to find a Starbucks. Once I was back home, I crashed, and woke up at 10pm. I spent last night clearing the pkg-perl review queue - gregoa is taking a short break after DebConf. Then I went running at sunrise again. This is quite a different experience to Central Park - first, you have to run 2.5km just to get to Southampton Common, and secondly it is raining quite heavily. I dug out some winter gear that had turned out to be completely inappropriate for New York.

Gunnar Wolf: Back home, back from DebConf And, hopefully, cleaner than ever!

So, DebConf time is over once again. The two weeks worth of fifty weeks waiting are left behind once again, and it's back to get back to normal. DebConf was great Yes, it always is, and that's what we are all saying, but hey - Seriously! Being in the same building than 300 crazed developers is always fun, and it's always better than last year's fun. A good highlight this year is that, given the number of Free Software and Free Culture groups that exist in USA's north-eastern coast, we had the opportunity to join a large crowd which has never been part of DebConf. Also, I must agree that the USA bid for DebConf was aiming to attract as many Debian people (developers, maintainers, or just happy users) which had not yet been to a DebConf before as possible. And it was a great success! I finally met several people I have long read in the mailing lists, in blogs or in IRC. A much higher proportion than usual, I'd venture to say. Another interesting phenomenon /methinks is that this year's DebCamp started much more staffed than usual: I arrived on the first day, Sunday 25, and there were ~40 people there already; I don't have the actual numbers, but we quickly grew, and the number started to stabilize past mid-week, only to (sharply) rise in the weekend, in time for DebianDay and DebConf start. Great time! But, they say, nobody can go to the USA without buying some sweet toys, right? Well, being the proud owner of six very hairy cats, I have thought into entering the looming and weaving industry... But cat hair, while abundant, I have heard is untreadable... Maybe due to the indisciplined, natural and independent personality of the cats (catonality should I say?)... So I had two choices: Clean up my home quite often, or live in a literally hairy mess. Enter choice #3: The Roomba! I had been waiting to buy this thing for several years, as they refuse to send to Mexico or charge Mexican cards. So, I walked across Manhattan and got my very own robot cleaner! For my further surprise, although I have not yet tried it (I don't even have a suitable cable yet), I found this: Yay, the Roomba is actually hackable (via a 7 pin miniDIN serial port)! Wikipedia says that:
Roomba comes with a Mini-DIN TTL serial interface, which is incompatible with standard PC/Mac serial ports and cables, both electrically and physically. However, third-party adapters are available to access the Roomba's computer via Bluetooth, USB, or RS-232 (PC/Mac serial). New, 500-series, and 410/420 series Roombas upgraded with the OSMO hacker device allow the user to monitor Roomba's many sensors and modify its behavior. The Roomba Open Interface (formerly "Roomba Serial Command Interface") API allows programmers and roboticists to create their own enhancements to Roomba. ( )
My first impressions? Well, the Roomba lazily charged its battery throughout the day today, and was hungry and ready when I arrived home. It is a but louder than what I expected, and of course my cats were not thrilled by the presence of a eighth animated and apparently sentient being at home. Their initial reaction was of course to be verrry alert of the thing. Twelve eyes were constantly pointing at the Roomba while mine alternated between them. As they measured the thing's speed and (I guess) inferred its movement patterns, they started escaping upstairs A flat, round thing with no legs to be seen will not likely be able to climb the stairs. And they were completely right. At first, only Chupchic remained downstairs. After a bit, I went up to show them the Roomba didn't jump on us to eat our brains, and after a bit, Santa and Macusa joined. The Roomba roombed for maybe 90 minutes (this space is large, and decided it was enough... And slowly, the rest of them started coming down. I would not say Roomba's cleaning is perfect, of course. Its room discovery algorithm is funny, and it even seems it's based on the mere chance of covering most (never all) of the space it has to clean. I had, of course, not fully studied it (after a single run, how could I?). It does make a honestly good attempt at cleaning under coaches, chairs and tables. It collected a fair amount of dust (on a house that seemed quite clean to me, I cannot imagine what would happen on a messy one). I have not yet played with the virtual walls (infrared transmitters which limit rooms as if a door was closed), but given the size of this house (and that I don't want it to clean around the cats' designated bathroom area), I guess I will end up using them regularly. During DebConf, I heard one bad (stupid useless noisy thing) and two very good (it has radically changed my life) comments on the Roomba. I hope to shift the balance towards 3/4 and not towards 2/2! Anyways... Thanks to each and every one of you. DebConf is great. Always great. Always a success. I cannot even thank specific teams. Debian Rules, and DebConf Rocks!

Julien Danjou: Update on rainbow-mode

rainbow-mode had a big success and good feedbacks when I released it for the first time a couple of months ago. Several users asked to me request its inclusion into Emacs. Therefore, some days ago, I proposed to merge it inside Emacs trunk. My request has been denied, but the mode has been added to the Emacs 24 package repository. In the mean time, I've added support for hsl() and hsla() support, and added CSS 3/SVG color names. Flattr this

9 August 2010

Gerfried Fuchs: On BTS usage

You might remember that I started to work on closing RC bugs for stable. This effort hasn't died off so I joined the RC Bug Squashing Contest that was going on during the Debian conference (which I was unable to attend). The rules did permit it, even though I was aware that it can't (and shouldn't) be compared to the unstable/testing squashers and thus it was split of into its own Special category. There still seems to be a lot of confusion on how our BTS works, especially with respect to version tracking. I was even accused of falsely claiming bug closing because the bug has been closed by someone else already. This wasn't the case, otherwise the bugs would had been archived a long time ago already[1] given that I had expected that person to know how bug archival works and also given the sheer amount of bugs that I simply had closed for stable, I guess it is needed to shine a light upon why some bugs won't get archived as expected. If you followed my IRC talk on BTS usage last month you might already have an idea of what's going on. There might be several different reasons why bugs aren't marked for archival yet. I'll try to explain them as I understand it (given that I neither have taken a look at the debbugs code nor am involved with its development) through my working on bugs over the last 10 years. I hope this will get others also interested to fix stuff for stable. Actually when I see something that potential falls into the last group I ping the maintainers of those packages to let them know about having them fixed. Some of you might already have received such a ping and I am thankful for those that received them well and actually already fixed some of those, too. Thanks for making stable a better place! Coming back to the RCBC, it was an interesting small competition (if only in my brain) between myself and the testing/unstable RC squashers going on. It would had been nice to get at least as many bugs in stable addressed as in testing/unstable because the amount is still a lot higher, but I can still be happy about the things done. And it is good to know that not everything seems to think that it's wasted effort to work on getting the RC count lower for stable, too (like I also was told about my effort). So thanks from that point of view!
[1] There are currently 2688 bugs still unarchived that were closed last year already! This UDD query helps you:
select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';

/debian permanent link Comments: 0 Flattr this

Gustavo Noronha Silva: WebKitGTK+ and the Web Inspector

When I started working on WebKitGTK+ I was a web developer, writing IT applications using Python and Django, and building features for content portals running Plone (argh). Even though I was an Epiphany user ever since it was forked off Galeon, I still had to use Firefox for my work, because I couldn t really live without Firebug. It should come as no surprise, then, that one of my first patches to WebKitGTK+ was actually making the awesome Web Inspector work in our port. After the initial support, though, not a lot has been done to further improve it, partly because it was already good enough for many uses, partly because I somehow started doing non-web development again ;). These last weeks, through my R&D efforts in Collabora, I have been able to push Web Inspector features and integration a bit further. A simple change that boosts the Inspector s usability quite a bit is having the nodes that are being hovered highlighted. Along with that, the ability to attach the inspector to Epiphany s window should make it easier to use for poking the DOM. The Web Inspector has a number of settings that control its behaviour. Since, for instance, enabling javascript debugging may slow down javascript performance, the inspector usually has it disabled by default, and provides a button to enable it. It also provides an option for always enabling that feature, but that does not work right now, because we are not saving/restoring the relevant settings. A solution to that is in the works using the GSettings infrastructure that was recently merged into glib. Here s a simple screencast, showing these improvements in action (click the video to check it out in full size): <video controls="controls" src="http://kov.eti.br/media/webkit/inspector.ogv" width="400"></video>

John Goerzen: Being A Butterfly

Well, I m back in Kansas after a bit over a week in New York for Debconf. I didn t have time to write much, so I ll probably be posting about it a few times. I already wrote about the trip to New York, and now will say just a bit about the time there and trip back home. I have to start with a quote from Jacob. We went on the Q train from Coney Island a few stops down to Brighton Beach. It s elevated, and provides an excellent view of the amusement park. Jacob s excited comment, face pressed to window, was: Wow! I see lots of everything! Which, come to think of it, sums up NYC itself pretty well. Speaking of faces pressed to windows: this was Jacob s default mode of operating in NYC. Get into any subway car, bus, whatever and he wants to stand on the seat nearest the window and look out it. It s a real problem if no such seats are available. More than once, though, we ll get on the subway and he ll run to the nearest window seat to claim it, no matter who will be his neighbors for the next few minutes. And after a few days of this, Oliver started picking up on it. Pretty soon both boys wanted to be pressed to the windows watching interesting things (to me, it was a dark tunnel with occasional lights, but interesting to them) go by. Which brings me to today. Today was Oliver s first time flying, and Jacob s second though he was an infant the first time he flew and doesn t remember it. Jacob has been perhaps cautiously optimistic about flying. The idea of it was exciting, but then again it s something completely new, which he doesn t care for so much. So we had no idea what to expect. What was got was excitement. And lots of it. From the La Guardia terminal, Dad, is this our plane? No, not that one. Well, is THIS our plane? No, not that one either. Well, is *THIS* our plane? At this point, a parent has to confront the question: which is worse, causing serious disappointment to a 3-year-old and possibly inviting a meltdown in the middle of the D concourse, or a bit of harmless encouragement that might not be 100% literally true? Uhmm . that might be it (Ah, so I went for the literally true but still exciting route ) YAY!! *jumping and clapping* Terah reminds me at this point of our security adventure. I, wearing socks, carried Oliver (1 year old) through the security checkpoint at La Guardia. But oh! I failed to remove his shoes (not really shoes). TSA made me go back through, put them in the bowl, and run them through the scanner. A nearby pilot, getting screened, noticed this and made this ironic comment well within TSA earshot: Look at his face! He s gonna get us all! Good thing you re checking his shoes! Terah and the pilot both just about bust up laughing. Meanwhile, I m carrying Oliver through, and the agent that made me take off his shoes had this look of I m sorry, I know this is stupid, but I have to. (For an excellent pilot s rant about TSA, read this). Anyhow, we got on the plane, and of course Jacob nabbed the window seat. IMG_4458.JPG There was plenty interesting to see. At each step of the way, I told him what was going to happen next, so there wouldn t be any surprises. I told him once we got in the air, and got a breathy Woooooooow .. I told him, Jacob, we are flying! And his reply has to be his best quote of the week:
Dad, I don t know that I ve ever been a butterfly before!
I pointed out that we were above the clouds, which was also exciting. About every 5 minutes, he d poke me, and say, Dad, look out the window. Look down. WE ARE UP IN THE SKY! Meanwhile, Oliver slept. IMG_4461.JPG On the second flight, Jacob slept (and was in a very foul mood when he woke up on the ground) while Oliver tried his best to squirm out of the seat and onto the ground. Now, to wind up this post, I would like to leave you with some statistics and photos comparing my home with New York.
Item NYC Marion County, KS
Land Area 469 sq mi 954 sq mi
Population 8,391,881 12,952 (6871 excluding the 3 largest towns quite some distance away)
Population Density 27,532/sq mi 14/sq mi (7 if excluding large towns)
I think of this as a wonderful difference! I ve said before how much fun it is to spend some time in NYC, where we can just walk to a fruit stand, any number of grocery stores, restaurants, etc. And finally, I leave you with two street scenes. The first is from our hotel s front door. IMG_4352.JPG That s our fruit guy there, and the bagel and roll place is across the street by the RadioShack. Now, the street view from our front door after we got home: IMG_4466.JPG OK, so that s sort of misleading. You can t actually see the street scene because it s on the other side of the hill. That s just our driveway to get to the street. (Not that the street looks much different. It has the weeds growing on the sides instead of in the middle, as one notable difference.) We loved New York and I m certain we ll go back again. It s also nice to be home and enjoy the peace of the countryside. Thanks to Debconf for a wonderful conference a topic I ll have more to say about in the coming days.

8 August 2010

Petter Reinholdtsen: Testing if a file system can be used for home directories...

A few years ago, I was involved in a project planning to use Windows file servers as home directory servers for Debian Edu/Skolelinux machines. This was thought to be no problem, as the access would be through the SMB network file system protocol, and we knew other sites used SMB with unix and samba as the file server to mount home directories without any problems. But, after months of struggling, we had to conclude that our goal was impossible. The reason is simply that while SMB can be used for home directories when the file server is Samba running on Unix, this only work because of Samba have some extensions and the fact that the underlying file system is a unix file system. When using a Windows file server, the underlying file system do not have POSIX semantics, and several programs will fail if the users home directory where they want to store their configuration lack POSIX semantics. As part of this work, I wrote a small C program I want to share with you all, to replicate a few of the problematic applications (like OpenOffice.org and GCompris) and see if the file system was working as it should. If you find yourself in spooky file system land, it might help you find your way out again. This is the fs-test.c source: 
/*
 * Some tests to check the file system sematics.  Used to verify that
 * CIFS from a windows server do not work properly as a linux home
 * directory.
 * License: GPL v2 or later
 * 
 * needs libsqlite3-dev and build-essential installed
 * compile with: gcc -Wall -lsqlite3 -DTEST_SQLITE fs-test.c -o fs-test
*/
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE_SOURCE 1
#define _LARGEFILE64_SOURCE 1
#define _GNU_SOURCE /* for asprintf() */
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/file.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
#ifdef TEST_SQLITE
/*
 * Test sqlite open, as done by gcompris require the libsqlite3-dev
 * package and linking with -lsqlite3.  A more low level test is
 * below.
 * See also <URL: http://www.sqlite.org./faq.html#q5 >.
 */
#include <sqlite3.h>
#define CREATE_TABLE_USERS                                              \
  "CREATE TABLE users (user_id INT UNIQUE, login TEXT, lastname TEXT, firstname TEXT, birthdate TEXT, class_id INT ); "
int test_sqlite_open(void)  
  char *zErrMsg;
  char *name = "testsqlite.db";
  sqlite3 *db=NULL;
  unlink(name);
  int rc = sqlite3_open(name, &db);
  if( rc ) 
    printf("error: sqlite open of %s failed: %s\n", name, sqlite3_errmsg(db));
    sqlite3_close(db);
    return -1;
   
  /* create tables */
  rc = sqlite3_exec(db,CREATE_TABLE_USERS, NULL,  0, &zErrMsg);
  if( rc != SQLITE_OK ) 
    printf("error: sqlite table create failed: %s\n", zErrMsg);
    sqlite3_close(db);
    return -1;
   
  printf("info: sqlite worked\n");
  sqlite3_close(db);
  return 0;
 
#endif /* TEST_SQLITE */
/*
 * Demonstrate locking issue found in gcompris using sqlite3.  This
 * work with ext3, but not with cifs server on Windows 2003.  This is
 * done in the sqlite3 library.
 * See also
 * <URL:http://www.cygwin.com/ml/cygwin/2001-08/msg00854.html> and the
 * POSIX specification
 * <URL:http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html>.
 */
int test_gcompris_locking(void)  
  struct flock fl;
  char *name = "testsqlite.db";
  unlink(name);
  int fd = open(name, O_RDWR O_CREAT O_LARGEFILE, 0644);
  printf("info: testing fcntl locking\n");
  fl.l_whence = SEEK_SET;
  fl.l_pid    = getpid();
  printf("  Read-locking 1 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 1;
  fl.l_type   = F_RDLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");
  printf("  Read-locking 510 byte from 1073741826");
  fl.l_start  = 1073741826;
  fl.l_len    = 510;
  fl.l_type   = F_RDLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");
  printf("  Unlocking 1 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 1;
  fl.l_type   = F_UNLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");
  printf("  Write-locking 1 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 1;
  fl.l_type   = F_WRLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");
  printf("  Write-locking 510 byte from 1073741826");
  fl.l_start  = 1073741826;
  fl.l_len    = 510;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");
  printf("  Unlocking 2 byte from 1073741824");
  fl.l_start  = 1073741824;
  fl.l_len    = 2;
  fl.l_type   = F_UNLCK;
  if (0 != fcntl(fd, F_SETLK, &fl) ) printf(" - error!\n"); else printf("\n");
  close(fd);
  return 0;
 
/*
 * Test if permissions of freshly created directories allow entries
 * below them.  This was a problem with OpenOffice.org and gcompris.
 * Mounting with option 'sync' seem to solve this problem while
 * slowing down file operations.
 */
int test_subdirectory_creation(void)  
#define LEVELS 5
  char *path = strdup("test");
  char *dirs[LEVELS];
  int level;
  printf("info: testing subdirectory creation\n");
  for (level = 0; level < LEVELS; level++)  
    char *newpath = NULL;
    if (-1 == mkdir(path, 0777))  
      printf("  error: Unable to create directory '%s': %s\n",
	     path, strerror(errno));
      break;
     
    asprintf(&newpath, "%s/%s", path, "test");
    free(path);
    path = newpath;
   
  return 0;
 
/*
 * Test if symlinks can be created.  This was a problem detected with
 * KDE.
 */
int test_symlinks(void)  
  printf("info: testing symlink creation\n");
  unlink("symlink");
  if (-1 == symlink("file", "symlink"))
    printf("  error: Unable to create symlink\n");
  return 0;
 
int main(int argc, char **argv)  
  printf("Testing POSIX/Unix sematics on file system\n");
  test_symlinks();
  test_subdirectory_creation();
#ifdef TEST_SQLITE
  test_sqlite_open();
#endif /* TEST_SQLITE */
  test_gcompris_locking();
  return 0;
When everything is working, it should print something like this: 
Testing POSIX/Unix sematics on file system
info: testing symlink creation
info: testing subdirectory creation
info: sqlite worked
info: testing fcntl locking
  Read-locking 1 byte from 1073741824
  Read-locking 510 byte from 1073741826
  Unlocking 1 byte from 1073741824
  Write-locking 1 byte from 1073741824
  Write-locking 510 byte from 1073741826
  Unlocking 2 byte from 1073741824
I do not remember the exact details of the problems we saw, but one of them was with locking, where if I remember correctly, POSIX allow a read-only lock to be upgraded to a read-write lock without unlocking the read-only lock (while Windows do not). Another was a bug in the CIFS/SMB client implementation in the Linux kernel where directory meta information would be wrong for a fraction of a second, making OpenOffice.org fail to create its deep directory tree because it was not allowed to create files in its freshly created directory. Anyway, here is a nice tool for your tool box, might you never need it. :)

Michael Banck: 8 Aug 2010

So, DebConf is over and it was a blast. I wanted to blog about my talks for a couple of days, but the conference was so great that I did not get around to it until now. The unique thing about this year's conference were the outstanding contributions by non-Debian FLOSS people from the east coast. I am really glad the organizers decided to reach out to the communi ty and take this opportunity when a lot of great minds were just a couple of hours away. Also, discussing and hanging out with the local team people was so much fun and interesting that it was wor th the visit alone. The venue was just perfect, the dorms were on campus, the cafeteria had an all-you-can-eat buffet, everything was in short walking distance and the Columbia campus is beautiful. I would have liked to go to a couple more places in the evenings, but hanging out in the Carman basement lounge with awesome people was just as good. A big thanks to Richard Darst, Biella, Micah and the rest of the crew. The Debian GNU/Hurd talk went quite well, I was pleasantly surprised so many people made it to the Davis auditorium. I wanted to do the presentation on Debian GNU/Hurd (and I had it working before the talk), but as my notebook has a different resolution than the projector, I decided to play it safe and just show a d-i run in qemu. Nevertheless, Jeremie's wo rk on debian-installer is impressive, I got it installed on my ThinkPad without a problem (using qemu) and it automatically installed and setup grub2. Unfortunately, grub2 seems to be having issues when booting my notebook natively, but I got it to work with grub-legacy, including X and evince. There were quite a few comments and I had interesting conversations afterwards with a couple of people. It is a shame Emilio Pozuelo Monfort (pochu) could not make it to DebConf to give the talk himself, he did lots of great work on porting packages and fixing the Hurd and glibc for various testsuites over the last couple of months. My other talk about GOsa and FAI was a bit rougher, I scrambled to get FAI integration in GOsa to work based on Mark Pavlichuk'sinstallation scripts which I fixed up over the last couple of weeks to the point where one can install a client using the FAI simple demo classes (which I ported to GOsa's FAI LDAP). There were some problems with the demonstration during the talk and I guess it was a tough audience for a web-based admin tool but I hopefully got my point across that we should salvage this work done for the city of Munich. Indeed, I had great discussions with Andreas Mundt from debian-edu afterwards who posted a summary and call for discussion to the debian-edu mailing list.

Joey Hess: bye bye, ny ny

view of Manhatten, Statue of Liberty, and Ellis Island from helicopter
In a few hours I will be catching the train for home. It's been a great DebConf, and a thrilling visit to New York. I'm especially happy with how well my CUT BoF went, and that we launched Branchable. As usual, DebConf is inspiring. I'm leaving with a scary new todo list:
my foot at 1000 feet

6 August 2010

Thorsten Glaser: FrOSCon 2010 and other sundries

The FrOSCon 5 - 21./22. August 2010 booth plans have finalised, I am rather content: 

	               I   STANDPLAN FROSCON 2010
	  F reeWRT
	 
	  M irBSD
	    
	 
	  D ebian
	                     C = Collectd
	 
	 C     G rml

This is especially good, as XTaran will be shared among (at least) Debian, Grml, FreeWRT; same for me plus of course MirBSD; kimnotyze is FreeWRT but may help with MirBSD; benz and gecko2 probably are MirBSD but gecko2 could help with FreeWRT, tokkee was interested in FreeWRT too anyway.

Some days, you just love software.

	Aug  6 13:55:01 blau firesomething-bin: stack overflow
	    in function VFY_EndWithSignature
	Aug  6 13:55:01 blau /bsd: signal 6 received by
	    (firesomething-bi:1146) UID(2999) EUID(2999),
	    parent (sh:9059) UID(2999) EUID(2999)

Thus, let me re terate it for all of you:
(removed from Planet Debian) Well, now that the Debian Release Managers have sent their freezing bits around *shudder* Squeeze is frozen. Well, at least everything I have my hands in has migrated. I m still not persuaded. I also can t decide which looks worse (KDE 4 or Win 7), tending towards KDE 4 (Read on for more controverse/questionable statements.)

Next.

Previous.