You are here:

Tue, 02 Mar 2010

[CeBIT] Link to my Debian GNU/kFreeBSD talk

Sorry; I didn't made it in the promised 15 minutes (as someone turned the internet off), but here is finally the link to my (German) slides of my Debian GNU/kFreeBSD talk. (Sorry, no fancy website arround that, yet.)

I would also like to make clear, that Debian does not plan to drop its support for the Linux kernel. Debian will continue to release a linux based distribution. You may install the very same distribution based upon a FreeBSD kernel. It's your choice.

A several people asked that at our booth, I guess there is somewhere a misunderstanding, but I don't know the root if that missunderstanding. If someone could tell me, why he thought so (maybe I missed a unclear formulation somewhere?) I would be very glad and try to improve it.

So, thanks again for the kbsd people, who helped alot and really tried to answer every stupid question I came up with during preparing my talk :)

postet at 21:17 into [Debian/events/cebit-2010] permanent link


Mon, 01 Mar 2010

[CeBIT] Free tickets for CeBIT

Sorry, I didn't had the time to update RC Bug statistics last week, and will probably also not be able this week, as I'll be quite busy, as CeBIT is about to start tomorrow, and I haven't written a script to create the statistics, yet.

While we are talking about CeBIT, you might already know, that Debian will again be present there. This as partner of Univention, a German company using Debian as base for its own distribution. I would like to thank them very much for their short hand acceptance of us at their booth.

If you intend to visit us (Hall 2, stand B36) and still have not ticket, feel free to drop me an E-Mail. We got some free tickets and I'll try to send you the link (you'll need to register at the CeBIT website and print your ticket yourself).

postet at 15:49 into [Debian/events/cebit-2010] permanent link


Thu, 18 Feb 2010

RC-Bug statistics for Squeeze, calendar week 7:

Note: Please see RC-Bug statistics for Squeeze, calendar week 7 for an explanation of the numbers.

Total:699+49
Affecting Squeeze:559+41
Squeeze-only:117+23
Unfixed bugs remaining in Squeeze:442+18

Of these 442 bugs...

... are pending36+4
... are patched:65+1
... are duplicates:47+-0
... are in Non-free or contrib:10+10
... are claimed by someone:14-3
... are fixed in the delayed queue:5-1
... are somehow marked as fixed:53+14

Or in other words:
Release critical bugs left in squeeze, when ignoring all these:
262 (+2 compared to previous week).

With this release managers views, 472 (+48 compared to previous week) bugs remain to be fixed somehow before we can release.

Some notes:

  • Lucas Nussbaum did another archive wide rebuild of all packages to detect some FTBFS bugs. Apparently he found some, so the number increased ;)
  • Stefano Zack Zacchiroli wrote some very interesting (or should I say inspiring?) notes about his RCBW initiative running under the motto let's fix one Debian RC bug per-day.
  • To the best of my knowledge, the problems with the mips* machines haven't been solved yet. So we are still looking for mips* porters. Please see this small problem description as well as the mails on our mips mailing list.

So much for this week. Let's see, how the numbers evolve in the coming seven days...

postet at 15:48 into [Debian] permanent link


Thu, 11 Feb 2010

[Update 2] RC-Bug statistics for Squeeze, calendar week 6:

Back in the Lenny release cycle, I published some statistics of the release critical bugs. As we are (try to) get nearer to a freeze of Squeeze I think it's time to start that again.

But first, a small explanation follows, what these numbers actually mean. If you look at our official bug tracking system currently lists 750 release critical bugs affecting the next stable release. While this number is kind of true, it is not accurate to use it to measure the state of the release. The unofficial rc bug thingy at bts.turmzimmer.net is quite more powerful to actual get some interesting numbers, as you can ignore specific kinds of bug and filter them properly. Note, that at the very end of the detailed list of the bugs you get the total number.

With that interface you can for example filter them by different distributions. For example it currently lists 650 rc bugs in total for any distribution, but if you filter for squeeze bugs, you get only 518. That's a different number as the official bug tracker shows; I'm not entirely sure why, but a part of that difference is that both the official and the unofficial web pages are only synced periodically. Should someone be able to give a good explanation about the differences, please step forward ;)

But let's play more: You can filter for bugs valid in squeeze-only, but not in sid. These bugs are already fixed in sid, but the packages haven't yet migrated to squeeze. Currently that are 94 bugs. We can furthermore ignore bugs only in sid; when squeeze is unaffected, we just don't migrate the broken package from sid to squeeze. The number that is most interesting for contributors is the number of bugs affecting both, sid and squeeze, as these are the ones which really need to be fixed as no fix is known, yet.

So filtering for bugs for both we are down to 424 at the moment.

But of these 424 remaining release critical bugs, we can still ignore some (for now). For example bugs concerning packages in non-free or contrib (9 currently) won't stop us from release, will they? There are also many bugs marked as pending (32), meaning that the maintainer is aware of the bug has a fix prepared and is just waiting with the upload a moment. Some of this bugs have already a patch (64), but no one reviewed it and uploaded it by now. You'll also see that you can ignore merged bug reports (47). That are bug reports reporting the very same bug several times. Finally there are bug fixes already uploaded to the so called delayed queue (6). This are bug fixes which where uploaded by someone else than the real maintainer, but to give the maintainer a chance to act on himself or to comment, the upload is delayed by some days before it will actually hit the archive. Currently 6 bugs are fixed by uploads to delayed. 17 bugs are claimed meaning that someone already said he will take care of this bug (but they are not finished, yet).

You could also ignore the bugs invalidated by today's britney bug category, representing bugs which will vanish after the next migration of packages from sid to freeze, but as we are only looking at rc bugs in both sid and squeeze, this number will always 0 ;)

That leaves bugs somehow other marked as fixed which are bugs (39) where I honestly have no Idea what they are... If someone can explain them, please do so ;)

Here is a small tabular showing the above numbers:

Total:650
Affecting Squeeze:518
Squeeze-only:94
Unfixed bugs remaining in Squeeze:424

Of these 424 bugs...

... are pending32
... are patched:64
... are duplicates:47
... are in Non-free or contrib:9
... are claimed by someone:17
... are fixed in the delayed queue:6
... are somehow marked as fixed:39

Or in other words:
Release critical bugs left in squeeze, when ignoring all these:
260

That's a pretty number, isn't it? There are only 260 bugs left which need our immediate attention :)

But that is a rather optimistic view of the situation. We e.g. assume that all bugs having a patch are really fixed by the patch. We also ignored, that some bugs in squeeze are already fixed in sid, but the package can't migrate because the package in sid contains a new bug. (Which happens to release wizard Marc Brockschmidt quite often.)

So if we take off the purple classes and take a more pessimistic view (release mangers must be pessimists to ensure high quality packages ;) we count the bugs in squeeze and ignore only those bugs, which are:

  • hinted / delayed upload (hint means a package is forcefully migrated from sid to squeeze without waiting the usual time span)
  • merged
  • contrib
  • non-free
  • bugs invalidated by today's britney (fixed in sid, package will migrate soon)

With this release managers views, 424 bugs remain to be fixed somehow before we can release. As far as I know, we can freeze once that number is reliable under 300. So we better get working ;)

When asked, what is the thing mostly needed to help the release, I was told: mips porter!
As you might have read we have some problems with the mips and mipsel architectures. It seems we have all the hardware we need, but it doesn't work very reliable. I have been told, that over 300 packages are only waiting to be build on mips* architectures. So if you can help us in that regard, please contact our mips porter mailing list.

Update: Andreas Barth just told me, that he already send a couple of mails to the mips list describing the problem and asking questions. Answers to these questions would be most welcome and accpeted gladly.

Update 2: Moritz Muehlenhoff just informed me, that I should also ingore RC bugs having the tag security for my statistics, as they come in all over the time and can always be fixed with a security update or in a point release.

postet at 13:49 into [Debian] permanent link


Wed, 03 Feb 2010

Dear lazyweb, I have problem understanding ACLs, maybe you can help me?

It was easy to understand how to activate and set ACLs and I also understood the mask, which defines the maximum rights a user might get through ACLs.

However, what I don't understand is, why this mask is dynamically calculated and set with every chmod (or equivalent) access...

Perhaps I should describe my problem a bit more: For our (web-) developers Linux workstations I need to grant them some additional rights to the configuration files. As they always get no tasks and need to install new software (solved via sudo) and change the configuration, I so far thought the easiest would be to grant them write privileges on /etc (safe some special files like /etc/shadow of course).

So I thought I could use ACLs to grant them rwx-privileges. Using default-ACLs (which are inherited when creating new files) it would be easy, if they e.g. install an own Apache web server, as the new directory and the new files inherit the default ACL.

However, due to the mask being set to r-x, our developers still don't get write permission on /etc/apache2/foo. I tried to set a default mask, too, which seems to be inherited. But as soon as the package management does the equivalent of chmod 740 the mask gets recalculated and my ACLs don't work any more.

Appearently, ACLs are not the solution to my problem :( But how do I solve my problem? And why is the mask always recalculated?

postet at 14:13 into [Debian] permanent link


<<  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87  >>

About

Alexander Tolimar Reichle-Schmehl lives in Tuttlingen / Germany. Hw works as IT manager (specialized on Unix and SAN/Storage) for an international automotive supplier.

Links