Search Results: "ed"

16 October 2012

Sune Vuorela: Kontact / PIM sprinting

So, a couple of days ago, I came home tired after a intense weekend of learning Akonadi and hacking on KDEPIM. At each meal, we attended 12 people, but it wasn t the same people every time. And a couple of people participated remotely. Several people, including me, got their feet wet in kdepim & akonadi code. Talks about the future with Qt 6 and Qt 7 and Akonadi 3 were also held in the corners. Hopefully, others will tell more closely about what they did, including fixing kmail memory usage to not grow until all headers of all emails was in memory and improving the address completion job to help filling in to/cc/bcc fields. Personally, I started off several times with the same issue. Not doing several synchronous calls from KMail to Akonadi during message writing and sending. On my way, I cleaned up some code and started over a couple of times. And the code is still a work in progress on my laptop. But the most important synchronous call is in that WIP patch now actually asynchronous \o/. There is still work to do on that area though and I hope to get around polishing it and finishing it this month somehow. I currently have function names like second_half_of_generateCryptoMessages and this_function_should_be_renamed . And next up will Andras Mantia hopefully blog about his accomplishments. And poke some other person for a blog post. Oh. and if you like developers taking a weekend or so out of their busy schedule to meet up for hacking, please consider supporting KDE by Joining the game

David Welton: The Dreaded Google Lockdown

It's one of those things that you read about, but are never really sure about: you think "maybe he was doing something fishy, and isn't tellling it straight in the public account of the incident". So I'll try to stick to "just the facts". A few weeks ago, I dug up some old book reviews I'd done, and posted to Facebook, and opened a site here: http://davids-book-reviews.blogspot.com/ as a way of collecting them. Naturally, I also added Amazon referral links, because, hey, it helps feed my reading habit! Last month I got enough to buy two whole Kindle books, so we're not exactly talking about "get rich quick" territory here. We're not even talking about anything remotely close to my day job, for that matter. But hey, if I can get a little bit extra to spend on books, it's nice. The reviews were basically quick notes on books I read. Nothing that I or the rest of humanity can't get along without, but I felt like writing up a little something for myself and people I know on the internet - maybe it'll help someone else find an interesting book to read. Several days later, I believe on October 8th, I woke up to find my phone was 'not signed in to Google', and, after repeated attempts, wouldn't sign in. Same thing with my Nexus 7. Logging in to my computer, in something of a cold sweat at this point, I find I can't get into Gmail or anything else, either. Luckily, on the computer, Google's system did redirect me to a page where they mentioned suspicious activity, and gave me the chance to reactivate things by sending an SMS to my phone. This did work quickly, and did a little bit to alleviate some of my stress. I understand that locking things down quickly is probably to my benefit as well as theirs in the event of an actual security breach of someone's account: it keeps the attacker from doing any more damage. However, it was sure a bad way to start a Monday morning. However, the actual 'blog' (sorry, I hate the word!) was still blocked. It too has a form to fill out to prove that you're human. Although: as a computer guy, you'd think that with all the clever people at Google, they would be able to tell from my access patterns to the site, browser footprint, IP addresses and so forth, that...well, I am me. In any event though, they promised to review the blog within two days. So, I waited patiently. A week later, still nothing. Then, the next day, I went back to check on the status, and they had reset the review request: it no longer said anything about October 8th, when I had originally made the reinstatement request. So I filled in their form again, asking to have my blog back. That was yesterday, we'll see what happens next. As far as I can tell, I did not violate their actual terms of conditions, which say nothing about referral links: http://www.blogger.com/content.g Since the people at Google are loth to speak with their users directly, it seems as if one of the best ways of getting support is to complain loudly and publicly about this kind of shennanigan. And to forestall the somewhat inevitable comments on anything related to Google: 1) Yes, I know I signed an agreement where they say they can do whatever the hell they want and I can f**k off if I don't like it. Try and do anything on line with a major company and not get a contract like that, or for even more entertainment value, try and negotiate the contract with t he company. Good luck. If you don't say yes, you're pretty much on your own; there doesn't seem to be much of a market for "more humane terms and conditions" out there. 2) I know, I know, relying on the Google beast is a great way to set yourself up for a big fall if anything ever goes wrong, because it's impossible to appeal, or pretty much even to talk with a human. But with a limited amount of time in my life, to date, Google has been a pretty good deal. I suppose it's something of a "black swan" situation: everything seems fine until one day WHACK, and Google pulls the carpet from under your legs. Conclusions? Well, I hope someone out there can help me recover my content. I wrote it myself, and I would like to save my book reviews somewhere. What alternatives are there to the Google colossus? Not too many that I can see that are anywhere at all as convenient. Edit: 2012-10-17: I don't know what did it, but they have reinstated the site. Strange and disconcerting, but I guess things are ok for the time being. Thanks to whoever it was at Google that finally had a look.

Eddy Petrișor: Zenyth Pharmaceuticals cannot face(book) critics, so they cleanse them

A few days ago I wrote an article about the lawsuit the producers of ColonHelp are trying against Wordpress in the attempt to silence a blogger who wrote some unfavourable and science-based articles on his blog.

Meanwhile Petter Reinholdtsen (who seems to be a fellow skeptic, hi!) sent further this information via his blog, but on another front, I found out the German skeptics tried to contact Zenyth Phamaceuticals on Facebook and asked them why did they use lawyers for threats against critics, instead of using words and thorough scientific studies to talk to the critics.


The people at Zenyth Pharmaceuticals probably wanted to show they do not only use lawyers, but they can be very proficient at using the 'Delete' function of Facebook, so they did just that, it seems.

This really motivates me to go ahead and translate the article Zenyth's money didn't translate, the one that shows their entire case is baseless.

Michal Čihař: Bootstrapping awesome in Prague this weekend

This weekend there is going to be a lot happening in Prague - awesome combination of four conferences will happen here. I'm sure this will be really a great event with lot of interesting things on schedule. Even if you are not interested in technical stuff, future media track might be interesting for you. And of course the event includes huge party on Saturday evening (and welcome party with pre-registration on Friday)/ Anyway if you will be around, you can meet me somewhere there, usually within organizers crew. PS: There also nice summary of latest news available now.

Filed under: English Suse 0 comments Flattr this!

Patrick Matth i: Package updates from the middle of october

glusterfs 3.3.1 has been released with a bunch of bugfixes, yeah! 3.3.1-1 is uploaded to experimental. geoip-database As usual the monthly database update, already migrated to Wheezy from Sid. otrs2 Today 3.1.11 has been released with a few bugfixes and one security fix for a XSS vulnerability on viewing special prepared HTML e-mails, which leads to that the browser executes JavaScript code (as described in CVE-2012-4751 and OTRS security announcement OSA-2012-03).
otrs2 3.1.11+dfsg1-1 is just accepted in experimental and I also backported the patch to the Wheezy version with 3.1.7+dfsg1-6.

15 October 2012

Tanguy Ortolo: Why phishers must looove smartphones

Phishing is a fraud technique that consists in reproducing the content of a targeted website, directing users to it, and recording their credentials when they log into your website. It is like fishing fish with fake food, only you phish humans with fake websites. Well, I have a good news for the phishers: people are using more and more smartphones, and mobile browsers are making your job really easy. In fact, many regular smartphone user simply have no way to tell your fake website apart from the real one.For instance, this is what my bank website looks like in my desktop browser, and what a corresponding phishing website would look like:
Iceweasel Web browser, with  caisse-epargne.fr  in its address bar

A bank website in Iceweasel

Iceweasel Web browser, with  evilpirate.net/caisse-epargne  in its address bar

A phishing website in Iceweasel

See the difference? It is not that obvious, but it is easy to detect when you are trained: the page address is not the same, with the fake website it refers to the phisher's server instead of the bank's one. Now, what does it look like on a Firefox Mobile? Well, here is the answer: the same, absolutely the same:
Firefox Mobile Web browser, with  Banque et Assurances  in its address bar

A bank website in Firefox Mobile

Firefox Mobile Web browser, with  Banque et Assurances  in its address bar

A phishing website in Firefox Mobile

The page address is hidden for space reasons, and only shown when touching the address page title bar. Want to browse the Web safely? After each link you follow, click on the page title bar. Good luck if you are using such a mobile Web browser. Fortunately, I am not.

Pietro Abate: Improved dose-builddebcheck

The new release of dose, apart from a few bug fixes, ships a new and improved version of dose-builddebcheck (man page). All the improvements done to dose-builddebcheck are from a set of patches submitted by Johannes Schauer in the context of the Bootstrap GSoC. We are still actively working on this. I invite you to read josh's recent blog post on the topic. For more background and discussion, you can have a look at the archives of this mailing list. Dose-builddebcheck (or buildcheck for short) is similar in intent to dose-debcheck but for source packages. Buildcheck allows you to check, just by looking at the Source and Packages files, if all the dependencies can be satisfied and installed, all this in a matter of seconds (less then 30 secs to test all the source packages in sid on my laptop). A simple example :
deb-buildcheck.native \
--deb-native-arch=amd64 \
tests/DebianPackages/Sid-amd64-Packages-050812.bz2
tests/DebianPackages/Sid-Sources-050812.bz2

native-architecture: amd64
background-packages: 55945
foreground-packages: 18175
broken-packages: 64

real 0m22.223s
user 0m21.937s
sys 0m0.204s
This will check for all source packages in the Source file if their build dependencies can satisfied on amd64 given the Packages binary file. This is nice but nothing new. A script based on the old edos tools has been around for quite a long time. We want more ! The new exciting feature brought by Johannes is the capability of checking source packages for cross-compilation :
dose-builddebcheck -f -e -s --checkonly picolisp \
--deb-native-arch=amd64 \
--deb-foreign-archs=armel \
--deb-host-arch=armel \
tests/DebianPackages/Sid-amd64-Packages-050812.bz2 \
tests/DebianPackages/Sid-armel-Packages-050812.bz2 \
tests/DebianPackages/Sid-Sources-050812.bz2

(I)Sources: Parsing Sources file tests/DebianPackages/Sid-Sources-single-version-050812.bz2...
(I)Format822: total packages 17723
(I)Format822: Merging repositories
(I)Packages: Parsing Packages file tests/DebianPackages/Sid-armel-Packages-050812.bz2...
(I)Packages: Parsing Packages file tests/DebianPackages/Sid-amd64-Packages-050812.bz2...
(I)Format822: total packages 58095

native-architecture: amd64
foreign-architecture: armel
host-architecture: armel
report:
-
package: src:apicolisp
version: 3.1.0.7-1
architecture: kopensolaris-amd64,solaris-amd64,amd64,any-i386,any-armel,any-armeb,any-arm,any-avr32,any-hppa,any-m32r,any-m68k,any-mips,any-mipsel,any-powerpc,any-s390,any-sh3,any-sh3eb,any-sh4,any-sh4eb,any-sparc,any-armhf
source: picolisp (= 3.1.0.7-1)
status: ok

background-packages: 75818
foreground-packages: 17723
broken-packages: 0
This will check, if the source package 'picolisp' in the Sources file can be cross compiled for 'armel' on the native architecture 'amd64' given the list of binary packages in the Packages file. The generated report is, as for dose-debcheck, encoded in yaml and it can be simply parsed using an off-the-shelf library. Apt is the canonical tool that can be used to check if a package can be cross compiled. Josh found a few discrepancies between dose and apt results. This was a very good test for both tools: Bug #683786 is a very interesting read... Dose 3.1.1 (the latest release) should land soon in experimental. Otherwise you can get it from our (new) project homepage.

Andrea Veri: Some statistics about GNOME.org

The GNOME infrastructure runs a Piwik s istance and it s been amazing seeing some of the statistics published there. A few details: Traffic during the 27/09/2012 GNOME 3.6 Launch Visits: 23063 Page views: 50352 Traffic during the last month. (from 15/09/2012 to 15/10/2012) Visits: 187598 Page views: 454313 Traffic during the last six months. (from 15/05/2012 to 15/10/2012) Visits: 773153 Page views: 1867200 GNOME is growing really fast and a great thank you goes to its great community and contributors! Let s keep rocking!

Eddy Petrișor: HOWTO: sudo + cowbuilder (+git-buildpackage)

In case you tried to use git-buildpackage and wanted to use cowbuilder as a builder, you might have ran into the error

sudo: sorry, you are not allowed to preserve the environment

This is due to a change in sudo default configuration in version 1.7.4p4-2 (I know, is true since 2010) which doesn't allow the execution of commands via sudo using the parameter '-E' which means 'setenv'.

The news item even explicitly states pbuilder can be affected by this because it wants to port over to the pbuilder environment the HOME environment variable and suggests using

Defaults env_keep += HOME

But adding such a line to your /etc/sudoers.d/01_pbuilders file (/etc/sudoers is recommended to be touched only by the package) will do the same for all commands and users ran via sudo, which is, according to my preferences, too permissive.

The irony is that running git-buildpackage --git-pbuilder will invoke sudo -E cowbuilder so the env_keep suggested fix will not work because for -E to be allowed, setenv needs to be set in sudoers. This would defeat the purpose of env_reset, if done for all commands, but we can do a better job if we allow this kind of change only for the cowbuilder and pbuilder commands. You do have different commands that are allowed explicitly stated, don't you?

On my system I have made a group especially for people allowed to do packaging work, the group is called 'pack'. The only account in that group is my own.

Also, I have defined a command alias named PBUILDERS which looks something like this:

Cmnd_Alias PBUILDERS = /usr/sbin/pbuilder, /usr/sbin/cowbuilder

Running PBUILDERS is already restricted to the pack group. Here is an example that requires password on run:

%pack ALL=PBUILDERS

So all that needs to be done is to allow setenv for the PBUILDERS commands. Reading through the sudoers manpage and after some trial and error (use visudo for editting sudoers files - visudo -f /etc/sudoers.d/01_pbuilders) I found out that the symbols that distinguish between commands, users and groups in a 'Defaults' line needs to be right next to the 'Defaults' word. For command the sign is an exclamation sign '!' (for user lists it's ':') so since we want to link the exception to the command, not the user list, we'll use 'Defaults!':

Defaults! PBUILDERS setenv

Assuming you also have a PBUILDERS commands alias, this is what you need to be able to use git-buildpackage in conjunction with cowbuilder and sudo.

If there is a non-intrusive way to prevent sudo to use -E when invoking cowbuilder, please add your comment, I would be interested to know it.

Kartik Mistry: [Life] Relocation and running

* In case you re not watching my twitter (and other social medias), I ve moved to none other than Bangalore. I m working with credativ. So, hello all DDs there! * On running front, I m back to track from today. Planning to run Bangalore Ultra 50K next month and then Mumbai Marathon (SCMM) in January 2013. BLR Ultra registration should be done in next 1-2 days. * It is challenging to stay along after four and half years of staying with family (and out of it 3 years of working from home!). I hope to move them here as soon as some things are fixed and start enjoying real life.

John Sullivan: Libre Software World Conference

I'm off to Spain to attend and speak at the Libre Software World Conference. If you're going to be there too, let me know.

14 October 2012

Diego Escalante Urrelo: Enabling SATA AHCI on a Linux Macbook3,1

I have a Macbook3,1 with the following SATA controller: 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 03) This chip can work either in AHCI or IDE mode. Even though (in numbers) AHCI and IDE should have similar performance, I have found that AHCI mode is much better. Specially when the disk is under heavy siege by more than one application. The catch is that Macbooks turn off AHCI when booting in BIOS mode, which is the mode I use for GNU/Linux. I understand this also affects Windows.

Pictured: a girl after enabling AHCI on her Linux Macbook After some googling I found this post that explains how to activate AHCI mode using GRUB2. The fix is to just add a setpci call on your GRUB configuration. To be safe you can test it by going into command line mode in GRUB, and doing something like this: > lspci
(check for the ID for IDE mode, in my case 8086:2828)
> setpci -d 8086:2828 90.b=40
> lspci
(The 2828 ID is now gone, replaced by 8086:2829, AHCI/SATA mode)
You can add this to your GRUB configuration, and avoid losing it on upgrades, by adding a script like this to /etc/grub.d/:

#!/bin/sh
set -e
## Enable SATA (AHCI) mode on macbook 3,1
echo "setpci -d 8086:2828 90.b=40"
I understand this is also relevant for newer Macbooks and standard PC hardware, so you might want to do some googling. The easy way to know if you are on the right mode is to run lspci -nn on a regular terminal (not GRUB) and see if you have a SATA controller that is in the wrong mode.

Gregor Herrmann: RC bugs 2012/41

these are the RC bugs I've worked on during the last week:
  • #575087 wbar: "On a default installation wbar will fail due dot.wbar"
    add comments to the bug report, severity lowered later by maintainer
  • #652638 libuuid-perl: "libuuid-perl: conflict with older doc-base versions to fix upgrade problems"
    add Conflicts (pkg-perl)
  • #656505 taxbird: "taxbird: build-dependency on libgeier-dev needs to be versioned"
    fix versioned build/runtime dependencies, upload to DELAYED/2
  • #657465 conserver-client: "conserver-client: prompting due to modified conffiles which where not modified by the user"
    fix configuration file handling, upload to DELAYED/2
  • #688206 pure-ftpd-common: "pure-ftpd-common: modifies conffiles (policy 10.7.3): /etc/default/pure-ftpd-common"
    fix configuration file handling, upload to DELAYED/2
  • #688223 emacspeak: "emacspeak: modifies conffiles (policy 10.7.3): /etc/emacspeak.conf"
    fix configuration file handling, QA upload
  • #688231 acgvision-agent: "acgvision-agent: modifies conffiles (policy 10.7.3): /etc/acgvision/agent.ini"
    add comments, and file #690170 while we're there
  • #688796 src:libkdtree++: "libkdtree++: incomplete debian/copyright"
    sponsor maintainer upload
  • #688891 psad: "psad: modifies conffiles (policy 10.7.3): /etc/psad/psad.conf"
    add thoughts and questions to bug report
  • #689120 gstreamer0.10-gconf: "gstreamer0.10-gconf: does not really provide sinks and sources"
    send a patch to the BTS
  • #690355 libfile-data-perl: "libfile-data-perl: (virtually) empty binary package"
    prepare a patch (pkg-perl)

Arnaud Quette: Cryptography: SSL support using Mozilla NSS landed in NUT

this week, a new feature was merged into the NUT development tree: beside of the historical OpenSSL support (for more than 10 years), NUT now also provides SSL features using Mozilla NSS. I've already posted a lengthy mail on the NUT developers list. But there are still a few things to be told:
  • for legal reasons, I won't detail, NUT (GPL v2+), can't be linked on OpenSSL without exiting from the 'main' Debian repository. Thus, NUT packages in Debian (and derivatives) don't provide NUT crypto features!
  • to me, NSS has some advantages, compared to OpenSSL. Among these, NSS is distributed under 3 licenses, including GPL. So it will fix the situation for NUT in Debian! But there will be more things to come with NSS, such as client authentication, and more security for infrastructure power management.
  • other distros (mainly Redhat and Suse) have attempted (and are still attempting) to consolidate crypto features, using NSS. Debian has not taken any decision on this topic though. NUT now offers the choice between OpenSSL and Mozilla NSS.
  • NSS support will be officially available with NUT 2.8.0. There is currently no release date since we're committed to a features set, not a release date. Some would say Debian old school. Everything would be different with more manpower, as everywhere else in our Free land...
For the braves who want to test, here is a small procedure, adapted to Debian. We will use an existing installation, and overwrite upsd, upsmon, libupsclient and few more. Beware that it will obviously breaks the MD5 sums of your nut packages!
  • install NUT, if it's not already done:
# apt-get install nut
  • download the source snapshot, and uncompress it:
$ tar xzvf nut-trunk-r3751.tar.gz
  • install NSS development files:
# apt-get install libnss3-dev 
  • change to NUT source directory and configure it using --with-nss, to force using NSS. For Debian, the following flags are needed:
./configure --without-all --with-nss \
        --prefix=/ --sysconfdir=/etc/nut  \
        --with-statepath=/var/run/nut \
        --with-altpidpath=/var/run/nut \
        --with-drvpath=/lib/nut \
        --with-pidpath=/var/run/nut \
        --datadir=/usr/share/nut \
        --with-pkgconfig-dir=/usr/lib/pkgconfig \
        --with-user=nut --with-group=nut
  • now compile and install:
$ make && make install
  • refer to the documentation, NSS backend usage chapter, for detailed configuration and usage instructions.
  • Enjoy ;-)
Before concluding, here is the traditional thank you guys:
  • Emilien Kia, who developed the NSS support in NUT,
  • Fr d ric Boh , for the validation testing,
  • Charles Lepple, for handling the merge from github to our Alioth Subversion repository,
  • and Eaton for sponsoring this development.
As a conclusion, cryptography integration and usability is still not on par with other proprietary OS. I would love to see the crypto situation improving in Debian (and friends obviously). So this was just my 2 cents (nuts ;-)) to the cause... cheers,
-- Arno

Michael Stapelberg: My recent systemd activity

I recently worked on the following systemd-related issues:

Jonathan Wiltshire: Tips for a successful BSP

  1. It is important to rehearse your space carefully. Find a quantity of friends equal to the attendees you expect, lay out the intended room, and check that everybody has free and easy access to their chair.
  2. Invest in a decent access point and some power strips with a decent cord length.
  3. Relax. I cannot stress enough the importance of this step!

Happy Hackers Hacking


Tips for a successful BSP is a post from: jwiltshire.org.uk Flattr

Dirk Eddelbuettel: Rcpp 0.9.15

Rcpp release 0.9.15 is now on CRAN and being uploaded to Debian. Martin Morgan provided a clever fix for a header search needed between clang++ (especially on OS X) and g++ (which still provided libstdc++ and headers for clang++). This should hopefully put the clang issues to bed. Ben North noticed an unprotected string conversion when exception messages are turned into R errors which got fixed, and I expanded the coverage of Date (and Datetime) types to deal properly with non-finite values NA, NaN and Inf. The complete NEWS entry for 0.9.15 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.
Changes in Rcpp version 0.9.15 (2012-10-13)
  • Untangling the clang++ build issue about the location of the exceptions header by directly checking for the include file an approach provided by Martin Morgan in a kindly contributed patch as unit tests for them.
  • The Date and Datetime types now correctly handles NA, NaN and Inf representation; the Date type switched to an internal representation via double
  • Added Date and Datetime unit tests for the new features
  • An additional PROTECT was added for parsing exception messages before returning them to R, following a report by Ben North
Thanks to CRANberries, you can also look at a diff to the previous release 0.9.14. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

Pietro Abate: dose has a new git repository and mailing list !

Recently we did a bit of clean up of our git repositories and now thanks to roberto's efforts we have a new shiny git repository on the inria forge and two mailing lists to discuss development and user questions. If you are a user, or interested in dose development, please sign up to these mailing lists: if you already have a copy of the latest git repository, you can change the upstream repository issuing the following command :
git config remote.origin.url git://gforge.inria.fr/dose/dose.git
If you are curious, you can clone dose git clone git://gforge.inria.fr/dose/dose.git and let us know what you think about it. The API documentation is available here. The man pages or various applications developed on top of the dose library are available here. We are still actively working on the documentation and any contribution is very much welcome. I'm working on a nice homepage... You can get the latest tar ball release here : https://gforge.inria.fr/frs/?group_id=4395 Old releases will be left on the old forge.

Update And now we are even social ! follow us on identi.ca : http://identi.ca/group/dose3

13 October 2012

Johannes Schauer: Does it become harder to bootstrap Debian?

My last post explained how I retrieved and corrected data from snapshot.debian.org so that dose3 was able to parse it. In this post I will cover some surprising results I found when using my tools on those Packages and Sources files from 2005 until today. For each pair of Packages and Sources files I did the following:
  1. created a reduced distribution
  2. calculated the dependency graph
I call a reduced distribution the smallest set of binary and source packages with the following properties:
  • all source packages can be built with the available binary packages
  • all binary packages are built from the available source packages
Creating a reduced distribution first, greatly increases the execution speed of my algorithms as it reduces the amount of binary and source packages by an order of magnitude while still preserving the dependency cycle situation of the core packages. In many cases, once the packages of a reduced distribution are available, all the rest of Debian can be compiled from them without any dependency cycles. As also mentioned in earlier posts, there is always one central, big strongly connected component (SCC) in the dependency graph. I am especially interested in how the size of the reduced distribution and the SCC change over time as both are an indication of:
  • the amount of interdependencies between core packages
  • the amount of dependency cycles in the dependency graph
Lets look at the plots I did from the data I gathered. The gray data points indicate that at that point in time, one or more of the core source packages (the ones in the reduced distribution) in Debian Sid was not compilable. This means that the resulting values cannot be fully trusted. But as it is mostly only a single source package that doesnt compile, it doesnt influence the overall result much and therefor I included them anyways. Red and green data points represent a fully successful run. The only thing that I do not yet understand is what happened in 2007... So while a potential porter in 2005 only had to look at a graph of 150 nodes, he now needs to solve a graph of nearly 1000 nodes. The amount of edges in the dependency graph grew even more dramatic from about 500 to over 8000 edges. While the dependency situation for Debian Sid in 2005 can easily be printed using xdot and visually solved, this in not possible anymore in 2012. While dependencies of only a few dozen source packages had to manually be dropped in 2005, now even dropping build dependencies from a few hundred source packages doesnt solve the dependency situation. So my assumption is, that due to a growing amount of interdependencies between source and binary packages (as both gain more features), bootstrapping Debian for a new architecture becomes harder over time. Is this also the perceived subjective impression of people that ported Debian in the past? If my assumption is correct, then there is a growing need for official support of droppable build dependencies (or "stage builds" or "profile builds") to break dependency cycles during the bootstrapping process. Work of a porter would be much easier if source packages would already contain information about what build dependencies can be dropped (if so needed). In the best case, a machine could use those annotations to calculate a build order automatically. As one can see in the graph above, there are currently 370 source packages in the main SCC. This means that no more than this amount of packages (but probably much less) have to be annotated to break the SCC into a directed acyclic graph. Discussion about what syntax to use to mark potentially droppable build dependencies currently happens in bug#661538 but should maybe be discussed by a wider audience. The currently favored solution was proposed in said bugreport by Guillem Jover and is called "build profiles". It has the advantage that it is not only trivial to implement (a patch exist for dpkg and dose3 already supports them) but would also be useful for other purposes like embedded builds. The format is similar to how architecture restrictions for individual dependencies are specified but uses "triangular brackets":
Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny
The work Patrick McDermott did for his GSoC project over the summer already uses above syntax.

Raphael Geissert: Debian mirrors map

Ever wondered how the Earth would look like if you added markers for every mirror that is part of Debian's mirrors network?
Debian mirrors map

(the bigger the shadow of the marker, the larger the number of mirrors in that zone)

Mirrors map generated with leaflet, using Openstreetmap.org tiles, and mirrors geolocation using GeoLite data created by MaxMind, available from maxmind.com.

Next.

Previous.