Fri, 11 Nov 2011
Release Critical Bug report for Week 45
The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
| In Total: | 1869 |
|---|---|
| Affecting Wheezy: | 1211 |
| Wheezy only: | 155 |
| Remaining to be fixed in Wheezy: | 1056 |
Of these 1056 bugs, the following tags are set:
| Pending in Wheezy: | 54 |
|---|---|
| Patched in Wheezy: | 197 |
| Duplicates in Wheezy: | 48 |
| Can be fixed in a security Update: | 33 |
| Contrib or non-free in Wheezy: | 12 |
| Claimed in Wheezy: | 0 |
| Delayed in Wheezy: | 10 |
| Otherwise fixed in Wheezy: | 87 |
Ignoring all the above (multiple tags possible) 684
bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy
released.
However, with the view of the Release Managers, 1105 need to be dealt with for the release to happen.
Please see Interpreting the
release critical bug statistics
for an explanation of the different numbers.
postet at 13:02 into [Debian/rc-stats/7.0-wheezy] permanent link
Mon, 07 Nov 2011
Release Critical Bug report for Week 45
The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:
| In Total: | 1893 |
|---|---|
| Affecting Wheezy: | 1250 |
| Wheezy only: | 180 |
| Remaining to be fixed in Wheezy: | 1070 |
Of these 1070 bugs, the following tags are set:
| Pending in Wheezy: | 47 |
|---|---|
| Patched in Wheezy: | 190 |
| Duplicates in Wheezy: | 51 |
| Can be fixed in a security Update: | 33 |
| Contrib or non-free in Wheezy: | 10 |
| Claimed in Wheezy: | 0 |
| Delayed in Wheezy: | 3 |
| Otherwise fixed in Wheezy: | 87 |
Ignoring all the above (multiple tags possible) 709
bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy
released.
However, with the view of the Release Managers, 1144 need to be dealt with for the release to happen.
Please see Interpreting the
release critical bug statistics
for an explanation of the different numbers.
postet at 20:38 into [Debian/rc-stats] permanent link
Weekly RC Bug Statistics enabled again
Friday David Prévot reminded me about the statistics for release critical bugs I used to publish during the squeeze release cycle, and asked if I could enable them again.
After tweaking the script generating the statistics a bit (mainly a s/squeeze/wheezy/g) the stats will be again published weekly, every Friday at 13:05 CET.
The first report is already available, and it seems it is about time, that we got the Wheezy Bug Squashing Party Marathon started! So, see you at the first BSP in Hildesheim.
postet at 12:18 into [Debian/rc-stats] permanent link
Wed, 28 Sep 2011
How to properly route packages on hosts with multiple NICs?
Dear lazyweb,
I'm encountering a routing problem on one of my Linux machine, for which I haven't found a solution so far. I have a machine which has several network interfaces in different network (it's our monitoring system). So I have eth0 with 192.168.1.2 and eth1 with 10.0.0.2, and an dns entry pointing from myname to 192.168.1.2.
Problems occur, if hosts in the 10.x.x.x network try to access the hosts. Accessing it via it's IP address in that network works, however if they try to access him via his other IP address 192.168.1.2 (e.g. because they resolve it via dns), it leads to some problems:
The host send their packet to his IP address (which works), however when my machine sends the answer, it takes a shortcut, and sends them directly via eth1 and with 10.0.0.2 as source IP. This however gets filtered by a (stateful) firewall somewhere in between, as packet send to 192.168.1.2 are suddenly answered by 10.0.0.2.
So far I found two solutions: Adjust the DNS to resolve to different IPs depending on the source of the request (ugly) or tell all firewalls to always let packet from my host pass, despite the changes source IP (also ugly, and probably quite some work).
Is there anything else I can do? What I would really like, would be a way to tell my linux box to always respond with the IP it was talked to, even if there would be a shorter way to the origin according to the routing rable. So, if a host 10.0.0.42 contacts my host via the IP 192.168.1.2, the answer packet should come from 192.168.1.2 via eth0 instead of instead of having a source IP set to 10.0.0.2, it should be send via eth1. Is that somehow possible?
Update: Wow, that was fast! The ink of my blog is still fresh,
and I already got the answer! The solution to my problem is policy
based routing
. Thanks to weasel, Peter and Dale for their pointers!
More information available at http://lartc.org/howto/lartc.rpdb.html,
http://www.itbuzzer.net/corner/2007/09/how-to-implement-source-routing-with.asp
or http://wiki.georgweiss.de/Linux/source_routing.
postet at 13:25 into [Debian] permanent link
Fri, 19 Aug 2011
How to read ftp-masters package numbers table
In my previous blog about Debian's growing archive size I pointed as reference to an hard to read table on the ftp-master server, and missed that the table is not self explanatory and on the first glance hard to read.
The table currently looks like the following:
| e | s | p-u | t | u |t-p-u | l-r | s-u | o |o-p-u | s-r |
---------------------------------------------------------------------------------------------
all | 1096 |12034 | 70 |14442 |15784 | 20 | 1 | 12 | 8910 | 230 | 0 |
alpha | - | - | - | - | - | - | - | - |13183 | 297 | - |
amd64 | 1164 |16997 | 242 |18581 |19605 | 39 | - | 21 |13964 | 342 | - |
arm | - | - | - | - | - | - | - | - |13251 | 291 | - |
armel | 988 |16401 | 239 |17879 |18680 | 39 | - | 21 |13411 | 327 | - |
hppa | - | - | - | - | - | - | - | - |13227 | 264 | - |
hurd-i386 | 445 | - | - | - |12622 | - | - | - | - | - | - |
i386 | 1178 |17188 | 242 |18727 |19751 | 39 | - | 21 |14377 | 350 | - |
ia64 | 951 |16036 | 239 |17303 |18045 | 39 | - | 21 |13554 | 329 | - |
kfreebsd-amd64 | 807 |14499 | 231 |15905 |16480 | 39 | - | 21 | - | - | - |
kfreebsd-i386 | 826 |14491 | 231 |15881 |16498 | 39 | - | 21 | - | - | - |
mips | 974 |16269 | 241 |17730 |18504 | 39 | - | 21 |13638 | 323 | - |
mipsel | 984 |16291 | 239 |17807 |18558 | 39 | - | 21 |13600 | 319 | - |
powerpc | 1078 |16677 | 239 |18156 |19036 | 39 | - | 21 |13872 | 332 | - |
s390 | 1030 |16252 | 239 |17678 |18469 | 39 | - | 21 |13331 | 327 | - |
source | 522 |14974 | 51 |16376 |17405 | 1 | 19 | 6 |12519 | 75 | 151 |
sparc | 992 |16423 | 239 |17895 |18673 | 39 | - | 21 |13542 | 329 | - |
The lines represent different hardware architectures Debian supports, like amd64 (for 64-Bit PCs), i386 (for 32-Bit PCs), etc. Two lines are kind of special, the one marked source and the one marked all. Let's start with the source line: That counts the number of source packages. Those are rarely seen by end users. Source packages contain the actual source needed to build a package, as well as Debian specific changes and a blue print on how to create an actual installable binary package from the source.
As you can see Debian supports quite some architectures, which leads to
a small problem on the mirrors: Quite a lot shipped in Debian is actually
architecture independent. For example documentation, most sound and
graphic files, or level data for a game. To avoid storing the very same
date multiple times, Debian makes haeavy use of so called arch: all
packages. You might have noticed them already while installing them:
Hole:5 ftp://ftp.rrzn.uni-hannover.de/debian/debian/ squeeze/main extremetuxracer-data all 0.4-4 [28,1 MB] Hole:6 ftp://ftp.rrzn.uni-hannover.de/debian/debian/ squeeze/main extremetuxracer amd64 0.4-4 [273 kB]
In this example I installed a quite small game on the amd64 architecture, which depends on a quite big architecture independent package (notice the all between package name and version) containing it's data.
So, to get the actual number of packages a user can install on a specific architecture, one has to add the number in the all line to the number in the specific architecture line.But what column to pick?
The columns represent so called suites. The s is for
stable, currently Debian 6.0 aka Squeeze
and o for
oldstable, aka Debian 5.0 Lenny
. The t
is for testing, aka Wheezy
or the upcoming Debian 7.0. The
u is for unstable aka sid
. The e is for
experimental, used for stuff probably not yet ready to be part of a stable
release and therefore not uploaded to unstable. The rest is not that
interesting (as you see it's mostly empty anyway), like s-u for stable
updates, several p-u suites for proposed-updates
(that is
stuff that might end up in the next point release, and should be tested).
And then we have s-r and l-r which I forgot what they are
about... Sorry.
But back to topic: As I explained briefly a source package is mostly used internally, but may create several binary packages, which a user can install. So the most interesting number for users is the number of binary packages on an arch. So we usually publish this number. So for example, using squeeze on i386 you can install: 17'188 (architecture dependent packages, column s row i386) + 12'034 (architecture independent packages columns s row all) = 29'222 packages. And for completeness: They are build from 14'974 source packages (row source column s).
So if look that up for unstable on amd64 you should get to the result 35'389 binary packages build from 17'405 source packages. Slightly less than I reported yesterday, because we removed some old stuff e.g. obsolete libraries in the meantime.
Update: Jörg just explained me, that the s-r and l-r are there to ensure Debian complies with the GPL. They hold the sources of everything shipped in the original lenny and squeeze releases.
Update 2: Jörg explained it to me again: s-r and l-r contains sources used without being referenced by a package, and so might get lost otherwise. One example is the kernel used by the debian installation system. You have to boot a kernel somehow, so it can't be packaged. But we still need to save the sources, so it is referenced in these suites and won't get lost.
postet at 13:33 into [Debian] permanent link