Rhonda's Blog                    
 
Mainpage Disclaimer

Fri, 17 Oct 2014

New Irssi

After a long time a new irssi upstream release hit the archive. While the most notable change in 0.8.16 was DNSSEC DANE support which is enabled (for linux, src:dnsval has issues to get compiled on kFreeBSD), the most visible change in 0.8.17 was addition of support for both 256 colors and truecolor. While the former can be used directly, for the later you have to explicitly switch the setting colors_ansi_24bit to on. A terminal support it is needed for that though. To test the 256 color support, your terminal has to support it, your TERM environment variable has to be properly set, and you can test it with the newly added /cubes alias. If you have an existing configuration, look at the Testing new Irssi wiki page which helps you get that alias amongst giving other useful tipps, too.

The package currently only lives in unstable, but once it did flow over to testing I will update it in wheezy-backports, too.

Enjoy!

/debian | permanent link | Comments: 0


Fri, 06 Jun 2014

No Portland

This year's debconf in portland will happen without me being there. As much as I would love to be at home again, I won't be able to afford it. As much as I'd liked to help to keep portland weird, a discussion led to the feeling that I'm not welcome there and along that lines made me miss the deadline for sponsorship request due to not being very motivated to push for it because of that. And without sponsorship I won't be able to afford it, given that I need to save up for my upcoming move.

This also means I won't be able to host the Poetry Night. I hope that someone will be picking up that ball and continue it. Personally I am more motivated than ever to start writing again, given that there is currently a Bus Bim Slam (Bus Tram Slam) happening over here in Vienna and I try to attend as much stations as possible, and there will be a Diary Slam during this year's FemCamp Vienna.
I'm indifferent on whether the Debconf Poetry Night should be recorded or not. On the one hand it would be great to see people performing, on the other hand it might shy away certain personal poems that one wouldn't want to have out in the wild. Whoever picks it up, think about that part.

I wish everyone luck in Portland, and I'm looking forward to yet another great job by the video team so I can follow a few talks from at home. It sort of breaks my heart to not be able to hug you lot this year, and I wish you a great conference. We'll meet again next year in Heidelberg!

/debian | permanent link | Comments: 3


Fri, 16 Aug 2013

Twenty Years

Happy twentieth birthday, Debian! For the celebration at this year's debconf I wrote this litte haiku. I hope you like it!

Debian OS
Twenty years, still relevant
This is what we are

The base of many
But without our great work
They could not exist

It is an honor
To be reused in that way
Be proud of your work

Enjoy the evening
Celebrate with us all night
There be poetry

Hope you had a nice celebration, I truly enjoyed this year's Poetry Night.
Enjoy!

/debian | permanent link | Comments: 0


Mon, 18 Mar 2013

Backports Integrated Into The Main Archive

Dear users and supporters of the backports service!

The Backports Team is pleased to announce the next important step on getting backports more integrated. People who are reading debian-infrastructure-announce will have seen that there was an archive maintenance last weekend: starting with wheezy-backports the packages will be accessible from the regular pool instead of a separate one, and all backports uploads will be processed through the regular upload queue (including those for squeeze-backports and squeeze-backports-sloppy).

For Users

What exactly does that mean for you? For users of wheezy, the sources.list entry will be different, a simple substitute of squeeze for wheezy won't work. The new format is:

deb http://ftp.debian.org/debian/ wheezy-backports main

So it is debian instead of debian-backports, and offered through the regular mirror network. Feel invited to check your regular mirror if it carries backports and pull from there.

For Contributers

What does it mean for contributing developers? Uploads for backports are no longer to be pushed to backports-master but to ftp.upload.debian.org, like any other regular package. Also, given that the packages are served from the same archive install there is no need to include the original tarball in the upload any longer because the archive knows it (Squeeze and beyond).

Also, given that the upload goes to the same upload queue, there is only one keyring used anymore, so no more pain with expired or replaced keys. We though still keep the rule of adding your UID to an ACL list (this also includes DM additions). This is mostly only to give us the chance to remind you that uploads to backports are directly available for installation onto stable systems and you thus should take special care there. We carefully tried to take over the old ACLs, in case you can't upload anymore, please tell us so we can look into the issue.

I've mentioned wheezy-backports (and squeeze-backports-sloppy) a few times here already, and you might wonder when it will be available. Technically, it is available from now on. Practically, while you could already upload to it, the set up of the buildd network is more painful than expected, so please allow the Buildd Team some days for setting them up.

The upload rules for wheezy-backports are the same: packages that are in the next suite are accepted. Given that Jessie isn't created yet, we want you to think about whether the package you want to upload will go into Jessie final, and that you are taking a closer look once Jessie is created and the package entered there about the upgradeability. For the time until the suite is available, you can see this as relaxed upload rule.

The same goes for squeeze-backports-sloppy: packages from two suites after Squeeze are acceptable, which turns it into the same relaxed rule as wheezy-backports above. Please also keep in mind that uploads to squeeze-backports-sloppy usually should be accompanied by uploads to wheezy-backports so people are able to upgrade from squeeze-backports-sloppy to wheezy with wheezy-backports.

Thanks

Finally, we want to thank the FTP-Master Team for their fine work on making this happen.

The documentation on backports-master has been updated, and in case of any doubt or question, feel free to ask them on either the debian-backports mailinglist, or in case of sensitive topics ask us directly.

Enjoy!
Rhonda for the Backports Team

/debian | permanent link | Comments: 3


Mon, 10 Dec 2012

BSP Essen November 2012, Report

So it happened: the Bug Squashing Party in Essen is done. And depending on your point of view at least I would call it a success.

We had in total fourteen participants. The number of release-critical bugreports touched and processed is not clear, but over 100 bugreports were looked at and either got comments added for clearification, maintainer pinged, unblock requests filed or already filed ones noted down, or NMUed. Given that we are in freeze since a while now and many easy bugreports already squashed by those who aim for a daily fix, I consider this impressive.

There is also the point that we managed to get some people involved that didn't consider themself techy enough to be of help. On the contrary, they were a great help on checking these bugreports with analyzing the discussions in some lengthy bugreports and upstream bug trackers, or trying to reproduce some issues. I can just hope that the weekend left an impression deep enough to keep them in the boat.

All in all, I'm quite pleased of the outcome, especially in the light of several other events catching the interest of potential participants which were going on at the same weekend. Thanks to all the people that stumbled by, and I am looking forward to maybe having another BSP at some point, but then I hope to not clash with so many other events. Thanks!

/debian | permanent link | Comments: 1


Fri, 21 Sep 2012

BSP Essen November 2012

Wheezy is coming closer to the release, there though are still way too many release critical bugreports outstanding for it. Squeeze has already been released, but it has collected even more release critical bugreports than wheezy since. To be able to reduce these amounts I will be at the Linuxhotel in Essen at the weekend from 23rd to 25th of November, and it would be a great pleasure if I could convince you to join me in this effort.

As readers of my blog might assume, my main aim will be those RC bugs affecting squeeze and I would be happy if some people interested to work on those could join me, I plan to give a quick quick explanation about the version tracking of the BTS and why we should care about stable too, but the event will definitely not be limited to squeeze RC bugs. Also, it will be a good chance to improve your key stats for the web of trust in case your GnuPG key hasn't got enough signatures yet or you want to transition to a stronger one.

Please read the Community page of the Linuxhotel for what they offer for accommodation in case you want to use their lodging. Personally I'll go for the two-bed room with breakfast option, but you are of course free to bring your own sleeping bag and mat if you want to cut short on the expenses.

In case of any questions, feel free to ask me right ahead. It would be great if we could help both our stable release and the next stable release during the weekend, and if you could join in! Please add yourself to the wiki page about the BSP.

/debian | permanent link | Comments: 2


Mon, 02 Apr 2012

Squeeze RCs's Squashing 2012 #2

This is the third summary of my squeeze RC bug squashing. If you take a look at the bug graph you will notice that the blue line went up a bit over a two week's period. I would like to claim that confirming the samhain RC bug 618728 did cost me the time (I actually gave it the time to finish), but the real reason was that I was looking at other stuff. I came back with a vengeance though, so here is the list of the bugs squashed for squeeze since the last report:

  • 657004: libmusicbrainz in squeeze not obsolete
  • 656178: missing found version
  • 654264: doesn't fail in squeeze
  • 644690: no nautilus 3 in squeeze
  • 644692: no nautilus 3 in squeeze
  • 644693: no nautilus 3 in squeeze
  • 644696: no nautilus 3 in squeeze
  • 644352: explicit about testing
  • 654281: doesn't fail in squeeze
  • 654270: doesn't fail in squeeze
  • 654267: doesn't fail in squeeze
  • 654242: doesn't fail in squeeze
  • 654218: doesn't fail in squeeze
  • 653664: no multiarch in squeeze
  • 653625: boost1.48 not in squeeze
  • 653294: python-twisted 11.1.0-1 not in squeeze
  • 653231: libarchive 3.0.2 not in squeeze
  • 659585: doesn't fail in squeeze
  • 653418: doesn't fail in squeeze
  • 660044: doesn't fail in squeeze
  • 650631: doesn't fail in squeeze
  • 660716: doesn't fail in squeeze
  • 662807: doesn't fail in squeeze
  • 662811: doesn't fail in squeeze
  • 662622: php 5.4 not in squeeze
  • 662116: doesn't fail in squeeze
  • 662200: libcvs3-5 not in squeeze
  • 662198: libcvs3-5 not in squeeze
  • 661879: doesn't fail in squeeze
  • 661775: doesn't fail in squeeze
  • 661800: doesn't fail in squeeze
  • 661799: doesn't fail in squeeze
  • 661798: doesn't fail in squeeze
  • 663556: doesn't fail in squeeze
  • 663562: doesn't fail in squeeze
  • 663566: doesn't fail in squeeze
  • 664188: doesn't fail in squeeze
  • 663943: doesn't fail in squeeze
  • 663671: doesn't fail in squeeze
  • 663669: doesn't fail in squeeze
  • 665218: php 5.4 not in squeeze
  • 665003: clearly wrong severity
  • 665218: libconfig++8 available in squeeze
  • 662964: doesn't fail in squeeze
  • 661909: doesn't fail in squeeze
  • 661516: tm-align not available in squeeze
  • 661450: doesn't fail in squeeze
  • 661449: doesn't fail in squeeze
  • 661413: doesn't fail in squeeze
  • 660488: doesn't fail in squeeze
  • 665902: doesn't fail in squeeze
  • 666171: doesn't fail in squeeze
  • 666172: doesn't fail in squeeze
  • 666144: libmecab2 not available in squeeze
  • 666112: fixing wrong found version
  • 666417: doesn't fail in squeeze
  • 666009: doesn't fail in squeeze
  • 666006: doesn't fail in squeeze
  • 665678: doesn't fail in squeeze

Current stats: 119 bugs in 93 days, still got the margin up by five more bugs. :)

Enjoy!

/debian | permanent link | Comments: 0


Wed, 08 Feb 2012

Squeeze RCs's Squashing 2012 #2

This is the second entry in my series about squeeze release critical bug squashing. In response to my last blog post it was asked whether this is proper release critical bug squashing. Indeed there haven't been any patches or upload involved in this, only BTS handling, but this doesn't mean that these bugs weren't considered to be affecting squeeze. You can see this effort currently as weeding out the "wrong" bugs so that the list gets more useful and actually be able to ask maintainers to address the real issues.

You can at least see in this graph that the blue line is going down constantly since the year change instead of rising up like before. And I hope I will be able to keep it below the green line for a while still. Also thanks to the release-team and ftpmasters that it was possible to keep the massbugs about waf binary blob not being preferred source for modification out of affecting squeeze and ignore it for the current stable release—the required changes for those would rather be a fair bit intrusive for a stable update.

  • 637213: doesn't fail in squeeze
  • 648989: doesn't fail in squeeze
  • 584568: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 624464: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 632106: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 632108: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 632262: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 632264: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 632265: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 632266: most stuff (BTS, PTS, ...) use maintainer information from unstable only
  • 595298: squeeze has linux 2.6.32
  • 613732: doesn't fail in squeeze
  • 616694: doesn't fail in squeeze
  • 620264: doesn't fail in squeeze
  • 620573: doesn't fail in squeeze
  • 621440: libdb4.8 not obsolete in squeeze
  • 624593: doesn't fail in squeeze
  • 626868: doesn't fail in squeeze
  • 628475: libdb4.8 not obsolete in squeeze
  • 629838: boost1.46 not in squeeze
  • 628475: boost1.46 not in squeeze
  • 631623: doesn't fail in squeeze
  • 639990: doesn't fail in squeeze
  • 632763: no libevent 2.0 in squeeze
  • 627000: not affecting squeeze
  • 658216: doesn't fail in squeeze
  • 654870: doesn't fail in squeeze
  • 655115: this is explicitly about testing
  • 657092: working in squeeze
  • 655710: doesn't fail in squeeze
  • 644691: no nautilus 3 in squeeze

I am glad that I managed to keep it up and even have a nice margin in case I can't put any effort into it some day but still have more bugs squashed than days there are in the year so far. Currently I am at 60 bugs in 39 days. This gives a warm feeling. :)

Enjoy!

/debian | permanent link | Comments: 3


Tue, 07 Feb 2012

Games Screenshot Party

The following announce is lazily copied from Paul Wise's announce. There is only one thing I like to add: the screenshots that are submitted and collected on screenshots.debian.net are visible on the packages websites (both Debian and Ubuntu) and are also used by the software-center package, so they help people to get a first impression of the package they might want to install.

Have you ever wondered how to start getting involved in Debian/Ubuntu? Do you enjoy discovering new games and playing them? You might want to come to the games screenshot party! We hope that the party will be a fun, easy, low-commitment way to get involved.

The Debian/Ubuntu Games Team is organizing a half-day screenshots party on the weekend of 25th-26th February for creating screenshots for all the games that are available in Debian/Ubuntu.

If you are interested in attending, please add your availability to the poll linked from the announcement so that we can get some idea of attendance and when is a good time for the people who are interested.

Look forward to lots of game playing, screenshots and merry time, hope to see you all there!

/debian | permanent link | Comments: 0


Thu, 19 Jan 2012

Squeeze RCs's Squashing 2012 #1

As sort of new year's resolution I started picking up the habit to work on release critical bugreports for squeeze again. The number is way to high to be healthy, but at least it is (still) below the amount of release critical bugreports for unstable.

It will be an uneven fight because it seems that there are quite some people working on weeding out release critical bugreports in unstable, but those who are interested in weeding out releasing critical bugreports in stable seems to be limited, even though it is one of our supported releases and thus should receive quite some attention, at least by the corresponding package maintainers themself.

So here is the list that I managed so far:

  • 651792: not relevant for squeeze
  • 653520: builds on squeeze
  • 654568: re-add version information lost in reassign
  • 654276: not relevant for squeeze
  • 654257: not failing on squeeze
  • 654810: not happening on squeeze
  • 654459: not relevant for squeeze
  • 654406: not release critical at all, shipped as upstream
  • 655007: python2.7 isn't default in squeeze
  • 655372: doesn't fail in squeeze
  • 527403: libjack-dev in squeeze provides libjack0.100.0-dev
  • 622903: not relevant for squeeze
  • 625764: squeeze has older version of libvelocity-tools-java, not affected
  • 654818: does work in squeeze
  • 647795: squeeze still has libahven1-dev
  • 647796: squeeze still has libahven1-dev
  • 636823: not obsolete in squeeze
  • 628500: no perl 5.14 in squeeze
  • 629255: no perl 5.14 in squeeze
  • 629284: no perl 5.14 in squeeze
  • 629293: no perl 5.14 in squeeze
  • 636132: no perl 5.14 in squeeze
  • 636268: no perl 5.14 in squeeze
  • 636271: no perl 5.14 in squeeze
  • 636517: no perl 5.14 in squeeze
  • 636520: no perl 5.14 in squeeze
  • 636521: no perl 5.14 in squeeze
  • 636522: no perl 5.14 in squeeze
  • 636823: not obsolete dependencies in squeeze

That makes 29 squeeze RCs squashed so far, I hope I can keep up with it.

Enjoy!

/debian | permanent link | Comments: 2


Mon, 20 Jun 2011

Games Team IRC Meeting #4

Another month, another Games Team IRC Meeting happening. This time it was decided to have it again on Sunday, the time was set to 10 am UTC. To find out the time in your localtime, issue date -d '2011-06-26 10:00 UTC' in your shell. The agenda can be seen as always in the wiki.

If the time or agenda doesn't fit your ideas, feel free to join our mailinglist to be informed about the discussion of agenda and time for the next meeting and raise your voice at that time. Please notice that the agenda isn't final yet, you can still drop your ideas for that.

Enjoy, and join if you care about improving games packaging in Debian and influence future development!

/debian | permanent link | Comments: 0


Tue, 14 Jun 2011

Debian/Ubuntu packages for pgadmin3 1.14.0 Beta 1

Martin Pitt announced packages of PostgreSQL 9.1 Beta 2 in his blog. Following this, I am hereby announcing the availability of pgadmin3 version 1.14.0 Beta 1 which amongst other things has added support for PG 9.1. You can find it in Debian experimental and backports for Ubuntu 10.04 LTS, 10.10 and 11.04 in my pgadmin3 backports for stable Ubuntu releases PPA.

Enjoy!

/debian | permanent link | Comments: 0


Tue, 26 Apr 2011

Games Team IRC Meeting #2

As Evgeni Golov already blogged, there is going to be the next round of a IRC meeting of the Debian/Ubuntu Games Team on the upcoming Saturday. This time it will be held at April 30th at 12:00 UTC in #debian-games on irc.oftc.net, so if you are interested in bringing the Games Team up to pace again, want to join and wonder how you could help, please attend. The agenda contains a fair amount of leftovers from the first meeting, please see Meeting Page about it.

/debian | permanent link | Comments: 0


Wed, 06 Apr 2011

The Canterbury Project

The Background

If you weren't online last Friday you probably have missed the big news announcement on the various community distribution websites. The main pages of them got replaced by a placeholder announcing the birth of The Canterbury Project. People started to wonder whether it is an April fool's prank or for real. This blog post is meant to shine a bit more light on it and address one comment received about it.

If you go to the news item on the Debian site you'll get your answer about that it indeed was an April fool's prank. The idea for doing something in coordination with other distributions came to me when I thought about last year's (or was it already two year's ago?) prank that the various web cartoon sites pulled: they replaced their main page with the page of another cartoonist. My original idea was actually along that lines. So I started to dig up website contacts from different distributions, I was aiming at the big names in the community distribution sector.

Given that my time is pretty limited these days with renovating the house we plan to live in soonish I knew I had to let in others in within Debian. I though didn't want to involve too many people, for several reasons: it should be a surprise to as many as possible, but more importantly, I didn't want to shy away other distributions by an overwhelming Debian involvement. That's also part of the reason why I didn't contact many Debian based distributions.

So first contacts where made, a dedicated IRC channel used for coordination, and people involved joined in. Then the thing happened which the Free Software community is so well known for: additional ideas came in, two people independently addressed me whether it wouldn't be better that instead of a circle replacement of the frontpage, why not display the same page on all of them. And one of them added that a corresponding news item might make sense.

So there we were, having to think about text to put into two things: the news item and the replacement page itself. At this stage Alexander threw in a project name with a background that was adopted. Francesca started with an idea for the news item, I started to put quotes in and asked for ones from the other involved people that fit their distribution well. Klaas came up with a template for the replacement page that we tweaked. Fortunately we ended up being five distributions and the colors of the banner did match the distribution ones rather well (except for one, we had to tweak the color of one banner).

The Credits

We were all set, and actually everything went fine. And it definitely caught the attention. This blog post goes out in thanks to the following people:

  • For Arch Linux: Pierre Schmitz and Dieter Plaetinck—thanks for joining in on such a short notice!
  • For Debian: Alexander Reichle-Schmehl (thanks for the name!), David Prévot, Francesca Ciceri (thanks for gathering contact information!) and Martin Zobel-Helas (thanks for webserver setting tweaks).
  • For Gentoo: Robin H. Johnson—thanks for the best quote for the news item!
  • For Grml: Michael Prokop—thanks for the great live CD and your input!
  • For openSUSE: Thomas Schmidt and Klass Freitag—thanks for the perfect website theme and the best mocked up news item!
  • ... and most of all, to the to be left unnamed person from the distribution that didn't join in in the end: a lot of thanks has to go in that direction because of the invaluable input. The actual idea about the additional news item is to be accounted to that person, and the Canterbury logo was tweaked there too.

I hopefully haven't forgotten anyone. There surely were some more people involved in the other distributions, and I guess the named people weren't aware of all the ones involved inside Debian. Feel free to drop missing names in the comments.

Addressing Feedback

Finally, let me address one concern raised: someone claimed that the real joke with this prank was that we would consider collaboration to be a joke. Actually, the total opposite is the case here. That it was possible to pull it off should be proof enough that Collaboration Across Borders actually is possible. And the background information put into the news section of the replacement site is real. Also, my personal quote in the news item was meant dead honest. I do believe that DEX has a limited point of view and only tackles part of the problem.

Unfortunately, for such efforts to really come to life it takes people with a really long breath and dedication to it. Efforts like the VCS-PKG and the Freedesktop Games effort are more or less stalled. Even though a lot of people do believe in stronger collaboration to be a good thing, the basis is not working out too well. I'm in the fortunate position that for some of the packages I maintain there is exchange between packagers from different distributions to avoid common troubles. If it can't be done in the big it should at least be tried in the small.

I want to specifically highlight again one part of the updates in the replacement page: the CrossDistro track at this year's FOSDEM. This one was more than fruitful, on several levels. From what I've heard a lot of discussion happened besides the talks too, and connections got established. It doesn't sound unlikely like this might be done again next year.

So again, thanks for enjoying this April fool's prank, thanks to everyone who helped to deliver it, and especially a lot of thanks to the people who this might have got thinking of possibilities to improve on the collaboration front!

/debian | permanent link | Comments: 8


Wed, 23 Mar 2011

LXC and NAT on notebook

Yesterday I was hinted towards lxc when I wondered what happened to openvz in unstable (which unfortunately isn't documented at all in the kernel changelogs, but that's a different story). So I started off taking a look. From a bit of experimenting around with it I consider it something that I want to play more with, and I want to share the problems I stumbled upon with you so that you don't have to figure them out on your own.

First of all, LXC uses the cgroup kernel facility for resource management. The according file system isn't mounted by default, and LXC doesn't care for where it is mounted, it just needs to be. It seems like /sys/fs/cgroup seems to be the proper place (see 601757), so add the line cgroup /sys/fs/cgroup cgroup defaults 0 0 to your /etc/fstab file and sudo mount cgroup it.

Next, it seems like bridging is the defacto standard for networking with lxc, but given that I want to use it on my notebook while being mobile I can't bind the bridge to any specific interface. To make this happen, one needs the bridge-utils package installed, and secondly, this is the path that I chose. I've added to /etc/network/interfaces this snippet:

auto br0
iface br0 inet static
    bridge_maxwait 0
    bridge_ports dummy0
    address 10.80.80.1
    netmask 255.255.255.0

This will bring up the bridge and act as gateway. For the running system, call sudo ifup br0. To make the host universally being able to work as gateway, of course ip_forward needs to be enabled. For this I added the line net.ipv4.ip_forward=1 to /etc/sysctl.d/local.conf (and for the running system, echo 1 into /proc/sys/net/ipv4/ip_forward).

As I am using ferm for configuring the firewall on my notebook I have to add some parts into its configuration. This is the raw part that needs to get added, mix it into your existing configuration:

table filter {
    chain INPUT {
        # allow DNS queries from LXContainers
        proto (udp tcp) dport domain source 10.80.80.0/24 ACCEPT;
    }

    chain FORWARD {
        # allow LXContainers into the net
        source 10.80.80.0/24 ACCEPT;
    }
}

table nat {
    chain POSTROUTING {
        # NAT LXContainers
        source 10.80.80.0/24 MASQUERADE;
    }
}

For DNS I installed dnsmasq so that I won't have to touch the /etc/resolv.conf inside the containers whenever I switch networks.

So far for the host part, now to the actual containers. There is the /usr/lib/lxc/templates/lxc-debian helper script which uses debootstrap to create you a lenny chroot—at least in the squeeze package this is hardwired, likewise with using cdn.debian.net. Copy the script and edit it to your likes if you feel like it. From what I understood it expects you to store the containers below /var/lib/lxc, I haven't yet tested for different places. So this was my commandline for that:
sudo /usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/vm0

A while later you'll end up below that directory with two entries: The config file and the rootfs subdirectory which is actually the bootstrapped distribution part.

Now comes the configuration of the container. Open the config file with your favorite editor and add the following lines to the end:

lxc.utsname = vm0
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
# lxc.network.name = eth0
lxc.network.hwaddr = 00:FF:80:80:80:80
lxc.network.ipv4 = 10.80.80.80/24

The network.name part is commented out, it defaults to that name internally; you though can change it to whatever you prefer. Caution, even though this is the documented approach, it does not work for Debian containers. It will always try to get its IP address through dhcp, lxc.network.ipv4 has no meaning for us. We need to change inside the rootfs the file etc/network/interfaces to read like this instead:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
   address 10.80.80.80
   netmask 255.255.255.0
   gateway 10.80.80.1

I suggest to keep the config and the interfaces file aligned with respect to the ipv4 setting so if this gets fixed upstream you won't stumble into any surprises. Also like mentioned before, we need to change the nameserver entries inside the rootfs file etc/resolv.conf to read nameserver 10.80.80.1.

Now it's time to start it up and log in! sudo lxc-start -n vm0 -d will start the container in the background, and sudo lxc-console -n vm0 will give you the login to the container. The default password for the root user is root, obviously you want to change that before you install any networking services into the container like ssh-server. In case you want to quit from that console notice the message upon starting it, it's bound to <Ctrl+a q>.

One more issue that I had: The default route wasn't set. I had to manually call ip r a default via 10.80.80.1 dev eth0 to be able to use the network inside the container. It seems to be related to that netbase isn't installed by default. If you install it the default route will be set upon starting the container automatically.

This should get you started, there is of course more to explore and experiment with. Actually it is also suggested to create a tarball from your vm0 after you did the basic setup and installed the basic components you want to have around so you won't have to bootstrap over and over again. Do this after you have shut down the container, either through a halt from a container shell or through sudo lxc-stop -n vm0. The tarball can then get extracted to a different directory and just needs minor tweaks in the config and rootfs/etc/network/interfaces file to not create any clash with other containers (lxc.rootfs, lxc.mount.entry, lxc.utsname, lxc.network.hwaddr and ipv4 address).

About limiting the containers, you can do it dynamically through the cgroup file system, and set it permanently through the config file. See man lxc.conf about these settings, amongst others.

Enjoy, use, experiment. With sudo lxc-checkconfig you will see what your kernel actually supports for your LXCs. You will most probably notice the missing for the memory controller, this is tracked in the Debian bug report 534964.

/debian | permanent link | Comments: 6


Wed, 16 Mar 2011

Games Team IRC Meeting

As Paul Wise already blogged, there is going to be a IRC meeting of the Debian/Ubuntu Games Team on the upcoming friday night. It will be held at 18th of March at 21:00 UTC in #debian-games on irc.oftc.net, so if you are interested in bringing the Games Team up to pace again, want to join and wonder how you could help, please attend. The agenda isn't final yet, the doodle poll about it is still open, if you want to put your preferences in.

/debian | permanent link | Comments: 0


Mon, 14 Mar 2011

Squeeze RC bugs, #2

Another week, though this one wasn't as fruitful as the last one. My excuse here is that I was overwhelmed with private stuff like acquiring a house and starting with cleaning it up so it can become a home.

This is the list for my second week of my stable RC bug squashing:

  • 603846: Update LSB header for hal D-Bus activision, not relevant for squeeze.
  • 604299: please use KDE 4 port, not relevant for squeeze.
  • 608017: XLIB package is not available even after installation, only appears in relation with clisp 2.49.

I know three isn't much, and actually it doesn't impact the list of stable RC bugs not much, we are at 172 open RC bugs against squeeze now. I can only attribute it to that new bugs were filed since, because I am aware that I'm not the only one working on this front, I've been contacted by at least two other people in the last week that are investing some time into this, too.

Mostly for self-reference, the highest reported squeeze RC bugs in the list is 618295. This should help me to get a number of newly reported issues (ignoring severity-bump in lower bug numbers).

Read you next week!

/debian | permanent link | Comments: 0


Mon, 07 Mar 2011

Squeeze RC Bugs

Alright, the stress of the release and its aftermath with respect to the New Website is getting lower. We even were explicitly mentioned for that during the introduction to the category Outstanding Contribution to Open Source/Linux/Free Software at this year's Linux New Media Awards.

Given that the Webmaster Team is much more energetic and lively these days I will shift a bit of my efforts to stable RC bug squashing again. I came to the conclusion that working on lenny RC bugs doesn't gain much of appreciation or real turnaround, and given that my time is limited I started to switch over to work on squeeze RC bugs. This is the list of bugs that I squashed last week (actually, marked them as invalid/not affecting squeeze):

  • 549054: Still uses gmime2.2, not relevant for squeeze.
  • 549056: Still uses gmime2.2, not relevant for squeeze.
  • 549057: Still uses gmime2.2, not relevant for squeeze.
  • 549058: Still uses gmime2.2, not relevant for squeeze.
  • 554310: FTBFS with binutils-gold, not relevant for squeeze.
  • 554557 FTBFS: undefined reference to symbol 'gzclose', not failing in squeeze.
  • 596569: Depends on xview, not relevant for squeeze.

I hope to be able to keep up that pace for a few weeks (currently there are 168 RC bugs in squeeze listed), and hopefully being able to motivate others to also support our stable release instead of only working on unstable.

/debian | permanent link | Comments: 0


Mon, 20 Dec 2010

5 Reasons why Debian Unstable is Not for End-Users

Debian unstable is not conceived as a product for end-users, and for very good reasons. There seems to be some misunderstanding and people trying to push end-users to use unstable. This blog post tries to address the claims raised and put them into proper light.

1. It contains mainly stable versions of the software

The critical part here is the term mainly. Yes, developers are advised to only upload packages to unstable that they deem to be suitable for the next stable release. This is no hard requirement though and no one actually playing a gate-keeper enforcing this recommendation. Also, there is a fine amount of packages that follow either VCS snapshots or development branches, and only time can tell how stable those releases actually are. That's actually why there is a delay of several days before a package can transition over to testing.

2. It doesn't break badly every other day

That's right—but if you look at it, it also means that it does break badly eventually. And if you don't know how to move on from there, including knowing the location of maintainer scripts and how to edit them in those cases, or even resort to a rescue system, you are in troubles.

3. It's the basis of other distributions

That's right in itself too, but it doesn't address the fact that those other distributions do put a lot of effort into quality assurance to work around the most nasty and annoying bugs that do affect unstable every other day.

4. It's not inherently less secure than Stable or Testing

It's not inherently more secure than stable or testing either. And this is also ignoring the fact that some security bugs don't even get into stable or testing, they only affect unstable and have to get addressed just there.

5. I use it on my main computer

This is the reason that you should ignore as most. People using unstable are often enough deeply involved into Debian maintenance, know how to write maintainer scripts, know where they are located in case of troubles, know how to use a rescue system in case of bootloader or kernel troubles. Just think about whether you would consider yourself to be at the same knowledge level than the person who wrote the blog article you read that used this as a convincing argument.

Conclusion: Stories always have several truths attached to them. If you feel adventurous, like to understand what's going on and have a tendency for digging into things that go wrong, you most probably are using unstable already anyway and are reporting bugs that you find along your way. If you on the other hand rather just want to use your computer and don't want to work around (smaller) bugs every other day, you rather should stick with the release that is actually provided as purpose to suit the needs of end-users: stable.

/debian | permanent link | Comments: 19


Wed, 27 Oct 2010

Report from openSUSE Conference

Like you most likely know, I've been at the openSUSE Conference last week. I've been representing Debian through a talk about Debian - The Project and its Resources, covering services and resources that are usable and useful for other distributions too. The invitation to submit talks were sent to various projects and distributions because of the set topic on Collaboration across Borders for the conference. My impression was that very few distributions have followed the invitation, I am only aware of some Fedora people that have attended. Vincent Untz from GNOME gave a combined keynote with Cornelius Schumacher from KDE.

The abstract of my talk and the slides are available from the conference website. The talk was well received and interested people also asked about some of the services like how our buildd network works, or whether the screenshots service has support for localized images too, or if it would be expandable for more general usage of non-Debian based distributions.

One topic raised was with respect to the whohas tool: A mapping layer/tool/database for package names. We divert from upstream naming schemes for consistency reasons, like with our library, Perl and Python naming schemes. Other distributions have similar approaches but a different naming scheme. To make inter-distribution tools really useful it would require to have some layer that is able to map the package name from one distribution to another one. One idea for it that was thrown in was to use upstream homepage, but not all packages do have proper homepages, some only live in some git repository, others would either like to link to sourceforge's project page instead of the project's homepage, and other tricky issues. Something unique is clearly called for here and needed to get stored in the package's metadata.

Apart from my talk and the occasional mentioning of openSUSE is on my desktop, but I run Debian on my server I noticed that the beverage of openSUSE is their own beer. Taste is a tough topic, personally I rather prefer our Debian wine. And I missed the chance to seduce them into playing Mao, I forgot to bring playing cards along. I hope to get a second chance at anoter event.

/debian | permanent link | Comments: 3


Sun, 17 Oct 2010

Debian at openSUSE conference

Within the next few days there will be the openSUSE conference held in Nuremberg/Germany. The topic of the conference was set to Collaboration Across Borders and along that theme they invited other distributions to submit talks. Given my involvement with the Derivatives Frontdesk zack asked me whether I'd like to submit a talk proposal. I usually have a hard time to refuse such questions this will actually happen.

My talk will be in the Distributions Track on Thursday afternoon, the topic is Debian—The Project and its Resources. The resources that I will cover are those that can be very useful to other distributions too, and last Thursday I tested the talk at our local Debienna Meeting, gathered further ideas and feedback to cover in the talk. Thanks to you, guys!

Unfortunately contrary to what we are used to in Debian (extraordinary thanks to the Video Team!!!) there will be no streaming or recording of the talks from what I was told, so you have either to hurry to be there, or be satisfied with the slides I'll put up after the talk. It's the best I can offer.

See you around!

/debian | permanent link | Comments: 5


Fri, 15 Oct 2010

Open Source Projectmanagement

I wrote the following as a foreword for the great German book Open Source Projektmanagement that Michael Prokop wrote. Unfortunately the foreword didn't manage it in time into the book because of various circumstances. As I'm not a person to throw away already written material, here is it for your reading pleasure. Maybe it makes you consider obtaining a copy of the German language book for yourself!

The Whole is more than the Sum of the Parts

When I first met Mika at a Linux conference some years ago I quickly noticed that he had potential. The way he asked questions and tackled issues did impress me. We did meet again at various events, joined forces in various projects and knew that the result would be good.

Back in the year 2004 the only real live CD was Knoppix. It always was too sluggish for me because I never really liked KDE and also OpenOffice.org was too bloated for me. I was working since a year at an Internet provider, felt comfortable in the shell and was missing the tools on Knoppix which I used daily.

Often enough the frustration with the status quo starts the best projects. And so I had the idea spinning around to start a sysadmin live CD. There was just one problem here: Exactly at the same time Mika had already started such a project. And I knew one thing: it would had been a lost race to compete with him in creating the better live CD. So I joined his team and helped with the best of my knowledge. The name choice alone showed that he was the right person for the job: Grml—an expression of the frustration that even he felt which spoke directly to the heart of so many.

But it wasn't just the chosen name that showed that Mika was the right person for the job of the project leader. It's always the sum of the parts, no matter how minor they might look. He quickly managed a first release and in light of that also created an event which was fitting for the release of the first version: the OS04—an Open Source event which managed to get Jon Maddog Hall as keynote speaker.

Mika managed through his welcoming way to lure more people into helping out. The team grew over the years, further regular releases increased the fan base, not only through the creative release names—which are surely one of the parts that helped create the success. He always was open to suggestions for new tools that helped to extend the project.

The lived openness did lead among other things to the case that other live CDs started to use the grml build system. JUXlala 2.0 (the system for preschool kids) is just one example.

Why do I write primarily about Grml, one could get subliminal advertising probably cheaper? I do it because Grml is an extremely good example of the experience revealed in this book. And even though every project is different, it is still exactly the sum of the parts that leads to the success of a project. And exactly these parts are covered in this book—and can be considered for the project at hand and get implemented accordingly.

Good luck—whether in large or small.
Rhonda

/debian | permanent link | Comments: 0


Tue, 12 Oct 2010

sudo and timeouts

People start to wonder why the timeouts for the passwords in sudo seem to be so short recently in squeeze. The reason is a change in the defaults that causes it. The following option changed its default:

tty_tickets
If set, users must authenticate on a per-tty basis. Normally, sudo uses a directory in the ticket dir with the same name as the user running it. With this flag enabled, sudo will use a file named for the tty the user is logged in on in that directory. This flag is on by default.

To change it back you can add this line into your sudoers file:

Defaults !tty_tickets

Please be aware that the change in default is done because of security considerations. You might not always have all the ttys you are logged in directly visible and others might be able to access them (like, sudo on a remote SSH session). Use with caution, you though might consider disabling it on local systems with no remote users.

Hope that helps! Actually this blog post was triggered by a question on ask.debian.net, a new service in the Debian eco system.

/debian | permanent link | Comments: 1


Tue, 05 Oct 2010

New Backports Suite created

The Backports Team is pleased to announce the availability of a new suite on backports: lenny-backports-sloppy. Please read carefully before considering using or uploading to it what this entails.

The Background

You might want to ask: What's that? Let me explain it. During the etch release discussions popped up on the backports list with two clashing groups:

  • One that expected to always be able to upgrade from sarge + sarge-backports to etch without backports,
  • others that wanted new versions of packages flowing in even after the release and were happy to upgrade from sarge + sarge-backports to etch + etch-backports.

The standing at that time was to accept packages that were in testing after the release, which wasn't etch anymore but lenny.

The same discussion started again before the lenny release, and given that we are facing the upcoming squeeze release we started internally to discuss how to noise down these long and tedious discussions, because both groups of people had valid opinions that shouldn't get ignored. So this is where the idea for lenny-backports-sloppy comes from.

The Change

lenny-backports-sloppy will please the group that is happy to upgrade from lenny + lenny-backports to squeeze + squeeze-backports. lenny-backports is meant only for packages from squeeze, even after the release. Technically that means it will get locked down for uploads after the release of squeeze and require manual approval (for e.g. point release update versions, or security updates that happen during the squeeze release cycle), while lenny-backports-sloppy will accept packages from wheezy. Uploading to lenny-backports will have to get approved by the Debian Backports Team after the squeeze release, just like uploads to lenny are currently approved by the Release Team.

While lenny-backports-sloppy is created already and working we ask you to not upload packages there without prior discussion with the Backports Team. This is meant to ensure that the Uploader is aware about the expectations that come along with that: The package should have a good chance to get included in the next Debian release aka wheezy, and that the Uploader is willing to look after the package in the upcoming squeeze-backports suite after the release of squeeze to ensure upgradability.

In case of questions, feel free to ask either directly on the debian-backports@lists.debian.org mailinglist, or contact team@backports.debian.org privately.

We are also pleased to announce that the first upload to lenny-backports-sloppy already happened. From now on you will be able to install Postgresql 9.0 (which is not targeted at squeeze) from lenny-backports-sloppy.

How to use

If you want to use lenny-backports-sloppy you will have to add both lenny-backports and lenny-backports-sloppy to your sources.list. Backports from lenny-backports-sloppy may depend on packages in lenny-backports.

  deb http://backports.debian.org/debian-backports lenny-backports   main
  deb http://backports.debian.org/debian-backports lenny-backports-sloppy main
About Backports

You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.

Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. It is recommended to pick out single backports which fit your needs, and not to use all available backports.

Thanks for reading this far, and enjoy!
Rhonda in the name of the Backports Team

/debian | permanent link | Comments: 1


Fri, 10 Sep 2010

Lenny: 900 RC bugs

It is a while since we managed to get below the 1000 stable RC mark. Last weekend we managed the next mark, that is we are below 900 now! Obviously my effort during the RCBC did take us a fair step in that direction, but I don't want to take full credit for it.

The last bit that got us below the 900 happened through an event of last weekend: The current point release of lenny. Be aware that the BTS doesn't know about proposed-updates, so bugs closed through uploads to there only are seen when they hit the main pool—which is the reason for point releases. It were something around 25 RC bugs that were closed by that. I haven't checked who exactly is to thank here, but looking at the non-DSA packages one finds some perl packages and at least two font packages. Thanks to the corresponding teams for their help!

I plan to continue these efforts, so if you think it's a good idea you might want to flattr it. I think this quote sums up the motivation behind this pretty well:

<jwilk> Yay, only 900 bugs to fix and we can release lenny! Oh wait...

/debian | permanent link | Comments: 2


Tue, 07 Sep 2010

flattr

I started to give flattr a try, too. It is a social micropayment site and the similarity of its name to the verb flatter is on intention. It is meant to say thanks in small amounts month by month to "things" you like. One such thing I created is my blog—you can find the link to it below every entry. To be able to flattr someone one needs to create an account on the site and put money into their account. After that it's possible to follow the flattr button links. If you are reading my blog on my site and have JavaScript enabled you just have to click the flattr part of the image (not the number) to do so. If you are reading it through my feed or with JavaScript disabled you will have to click a second time on the flattr site to make the flattring happen.

Another thing I've created is Debian BTS: cleaning up. I use this link in my mails to the Debian BTS for my stable RC cleanup efforts, or general proper closing of bugs that aren't getting archived. Through the help of UDD I've created me helpful overview pages of bugs that need attention for this.

The third thing I've created is Package Maintenance. If you are a fan of one of the packages I maintain and want to thank me for taking proper care of it, feel free to also click this one. Please be aware that this shouldn't be seen as an Upstream appreciation—if one of the projects I package for Debian uses flattr themself then you should definitely (also) consider flattring them for their own.

About Upstream projects that use flattr: One of the packages I invest quite a lot of effort into started using flattr: wesnoth. They have put the flattr button on their entry page at wesnoth.org, here is the direct link to their first and general thing: The Battle for Wesnoth.

Please be reminded that the things you did flattr in a previous month can again be flattred the next month. This is especially true for general purpose things like what I am using currently. Others might create things for every single blog entry, or very specific tasks, to allow people to flattr them more often in a month and get a bigger share of the cake. So keep in mind which things are general ones and consider returning to them.

Enjoy!

/debian | permanent link | Comments: 1


Fri, 20 Aug 2010

Screenshots on packages.debian.org

People often want to know what an application looks like before they install it. This is one of the reason why Christoph Haas started with the screenshots.debian.net service. People can upload screenshots for their favorite applications for others to take a look at.

Finally, as convenience feature, they are now added on packages.debian.org. When you click on the screenshot of a package you can see the list of all of the available ones.

In the case when no screenshot is available yet the page will show a placeholder image which gives you a convenience link to the screenshots page of the package where you can submit one for the benefit of all. Please make sure that you are following the guidelines for submissions, otherwise your upload might get rejected.

On a not totally unrelated topic, the packages.ubuntu.com site finally will also show you packages in maverick. It doesn't show screenshots yet—if you think adding support for screenshots in there would be a good thing too, please let me know!

Enjoy!

/debian | permanent link | Comments: 5


Mon, 16 Aug 2010

Happy 17th Birthday, Debian!

Happy 17th Birthday, Debian! You kept me busy for the last 10 years and I am really looking forward to what the next 10 years might bring for our relationship.

Thanks also to all the people who also are able to keep calm and to the point when discussions turn to get heated. You are the ones who make work on Debian enjoyable.

Also a lot of thanks to all the people that understand the power of positive encouragement like what is currently flowing in through the thank.debian.net website.

Likewise much thanks to the ever growing number of distributions that are based on Debian, because doing that is a very special kind of appreciation of our work.

Thank you all!

/debian | permanent link | Comments: 0


Thu, 12 Aug 2010

Why new Design isn't deployed yet

This blog post is actually a response to a talk that was given at the debconf last week. It was marga's talk about Making Debian Rule, again. Now that the beta versions of the talks are available for download I'm able to proper quote what I want to respond to: Is there a reason why we haven't yet updated the website?, perhaps someone can answer.

I feel the need to respond to this as I am the main person driving that effort. Unfortunately the question was asked in a talk with no-one involved in that work around instead of addressing those people directly, and the question wasn't brought to my attention before the talk so that I could have provided an answer to offer in the presentation already. Also, as disclaimer, this is my personal story for it and doesn't need to get shared by the other people involved. I hope it can be seen as an answer anyway.

As a little of background, Kalle's proposal went a long path before even I found out about it. I was simply in awe in several ways about it because it wasn't just a great mockup of the page (which it actually is, IMHO) but was accompanied by thoughts about not only the main site but also about several sub sites. Also, it was accompanied by patches, so it was seemingly ready to get deployed right ahead.

I started working on it, got accused of being discouraging while doing that, got told that it would require a proper vote for a decision and can't happen just as, but those are just the Debian way of communication. I nevertheless did set up several test sites for some over the time to play with it. Some did work out better (like the git one, though this one came last and Kalle improved the CSS over time a fair bit), some weren't ready yet (like wiki, missing e.g. the coloring for the version diff, or the packages one where the separation between the different sections isn't that visible yet). Time passed, other things demanded their attention too.

Like the thing where our system administrators did send me a request along about a new www-master server that needs to get set up from scratch. Given that the documentation about the required packages for the website was lacking a fair bit (to say the least) it did require a lot of attention, especially when doing things from scratch the wish to document the dependencies properly is just natural. There are still some issues with that as can e.g. be seen on this page in the empty table at the bottom. The same issue also appears on my testsite for the new design.

The last part though is currently the biggest blocking issue for both efforts. There is no way to move forward with either without having that addressed. Simon Paillard did a great job on helping the move along so far, keeping the thread about the server move requirements that I started on the debian-www mailinglist updated with information about what's still pending. Unfortunately Kalle, Simon and me are also facing some private time constraints (amongst other duties that require attention) which weren't helping to move forward at a bigger pace. Unfortunately not very many people actually has shown interest in helping out neither, after all it's easier to go and ask questions about why it's not done yet to the completely wrong audience.

My plan is to switch many sites at the same time instead of one after the other simply for the effect but also for less distraction for our users, including less people repeatedly pestering about when this or that site gets done, too. At least we need a final discussion on what should go into the header links and what should be at the bottom before a switch can be made anyway. And for some there is still the opinion that such a switch is nothing that we are rightfully allowed to decide without a vote, so that's also part of the reason to not just deploy it.

I hope this answers the question to some extend—and like said, if only I would had been addressed about this before the talk was given an answer to it would had been ready for presentation right ahead instead of having a pretty terse statement getting relayed through IRC (thanks, Yoe!) because I was fortunate enough to be around and watching the talk at that time. Feel free to discuss it further or offer your help on debian-www, especially if you are familiar with working on CSS files.

/debian | permanent link | Comments: 3


Mon, 09 Aug 2010

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.

  • Usually bugs are marked for archival when they are not affecting testing or unstable. That means, for a bug filed against a version that is only in unstable and closed in unstable, an immediate archival process is started (actually, it's not that immediate: It requires the package to be in sync on all architectures it's available for, too); otherwise the fix has to enter testing before bugs are considered for archival.
  • Sometimes the bug is still considered affecting unstable though, even when the fixing package version already moved over to testing. This is the case when the hurd-i386 package is outdated in unstable and can be checked in the unstable overview of the package on packages.debian.org at the end of the page, it will have red entries next to the green ones (you can ignore red entries for debports architectures, though!). You have to file an arch specific removal request for those bugs to get them archived.
  • For packages in experimental it's quite the similar situation, because that packages from experimental don't transition anywhere, so those will stay unarchived for the time being if they also affect unstable.
  • So what can be the reason when the fix is already available in testing and unstable but the bug still doesn't get archived? Those cases mean that the bug is considered as affecting stable and has to get addressed there, too. Bugs that are considered for that are of a release-critical severity, bugs with lower severity aren't considered for stable because they are unlikely to get fixed in stable and thus get archived. So what can we do about them?
    • Do they actually really affect stable? Working on those is what I did over the last months. There are often enough bugs filed for library transition issues, FTBFS for toolchain changes, or other things that aren't applicable for stable. Those are easy to close in stable:
      • If the version information got lost (through reassigning or similar), the only thing needed is to re-add the found versions, given that it is a higher one than the one in stable.
      • If the version information is proper (because it had still the same version in unstable at the time of the reporting) tagging them with + squeeze sid will tell the BTS to consider them only for those releases, so not thinking it affects lenny, too.
    • Some do affect stable but still aren't severe enough to warrant an update in stable (like for documentation corrections in debian/copyright or similar). If you found one of those please talk to the release-team about getting them tagged lenny-ignore, don't do that yourself because that tag is meant to be set by the release-team themself only!
    • If they actually affect stable (like security issues that though are considered to be too minor by the security team to warrant a DSA, or other severe usability issues), please try to backport the relevant fix, propose a diff to the release-team on their mailinglist and have it uploaded to lenny-proposed-updates to be fixed in the next point release.

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


Wed, 04 Aug 2010

The Good, The Bad and The Ugly

Debian always was known for its communication "style". There were even shirts sold in memory of Espy Klecker with a quote he is known for: Morons. I'm surrounded by morons. Yes, I bought me one of those shirts too in the early days. And there were the talks that promoted Debian as a place to have Good flamewar training. And people considered that to be the fun part.

After some years it got tiring. It got stressful. It got annoying. Bad feelings popped up, stirred you into the next flamewar, and it went down the gutter from there. It was almost becoming impossible to not be the target of a flamewar when one was doing more than just basic maintenance. Snide and extreme terse responses became the standard.

In the end people are starting to give up and leave. The Ugly thing about this is that human resources are crucial. They aren't endless and can't be replaced as easily as broken hardware, especially when capable people or when people leave who invested an enormous amount of their spare time and effort. And given that a fair amount of people do put their heart into Debian, it feels like a small suicide to them and the public thinking about leaving is meant as a call for help which wasn't and isn't given.

The solution to this death swirl? I'm not sure. When one looks over the edge of the plate and ignores for a moment all the bad feelings they one might have built up against Ubuntu because of their success and possibility to find new contributors on a regular basis one is able to find a much friendlier and productive environment there. This might be attributed to the Code of Conduct about which I wrote about last year already and which is an extremely well intended and useful document (the point I raised in there is already solved for a while, so I became a MOTU). And even if it might be hard to follow it at times, Mark Shuttleworth reminds and encourages its contributors to stick to these principles even in tough times.

The result? When following the planets, one finds on Planet Ubuntu a very good rate of blog posts on things that had been done, compared to the good rate of blog posts of rants on Planet Debian. And even though people regularly complain about the communication style within Debian, the answers of this year's DPL candidates to the question about a code of conduct for Debian were rather rather disappointing. So it is just well too understandable that people go the path that hurts themself, take a cut and leave the project behind in its mess.

For myself? I'm not too far from that point on a regular basis, and I can understand those who did the final step only too well. Regular abuse, especially when doing stuff that others neglect on a regular basis but needs to be done anyway, being belittled on that grounds and not being taken serious and getting disrespectful responses isn't improving the situation. It happens to way too many people, and the only thing that still keeps me on tracks is that I do not want to give in yet, that I don't think that it would improve Debian to leave the grounds to various destructive people.

On the other hand, there is only so much abuse one can take...
ObTitle: Ennio Morricone - The Good, The Bad and The Ugly

/debian | permanent link | Comments: 8


Fri, 18 Jun 2010

New Face, Part 3: gitweb

We ain't dead. A long time has passed since I last wrote on this topic, and much happened—unfortunately (for this effort) in other areas.

This doesn't mean that this effort is being abandoned. So here is the next big step: A gitweb theme using Kalle's proposal. I enabled it on my own gitweb installation so that people can see it live and test it. Feel free to clone it from there, too.

Enjoy!

/debian | permanent link | Comments: 0


Wed, 09 Jun 2010

Battle for Wesnoth 1.8

Some people still ask me from time to time when I'll upload Battle for Wesnoth 1.8. My usual answer is that it's there already since before the official announce went out in the wesnoth-1.8 package.

The longer answer which also answers Why the name change? goes like this: People asked for a way to be able to install different branches side-by-side so that they can keep the old stable branch around for finishing started campaigns there while still being able to play with their friends multiplayer games using the new stable branch. Also people using the development version wanted to not having to get rid of the stable version just to use the development branch.

So there it is! Enjoy! There though is still something missing though, and that's why the question where the 1.8 version of Wesnoth is still pops up: There is no transitional/meta package yet. This requires a bit more work including adding alternative handling (so one can still run wesnoth and not have to use the versioned wesnoth-1.8 binary name) and for that some dpkg-divert magic about the historical unversioned wesnoth packages.

Given that my release is requesting quite some support overhead I can't tell yet when these things will be done, but a similarly related support contract will run out by the end of the month so potential I'll be able to find some time next month to finish this for good. If you want to have it done earlier or feel like helping out, feel free to send in patches after talking with me about the fineprints and potential approaches. Thanks in advance!

/debian | permanent link | Comments: 0


Thu, 25 Mar 2010

dpkg source format 3.0

Ben Hutchings writes:

You are missing the point - debian/source/format allows you to make it explicit that the source format is 1.0, if you want to stick with that.

You are missing the point - the planned switch of the default format isn't considered a good approach by quite some people. If something new gets introduced, switching to it should be done in wake manner. Other tools do that too, so why can't a central package as dpkg use that approach? I especially want to mention that a point release update for stable was required to get it working in stable like it should.

/debian | permanent link | Comments: 0


Wed, 24 Mar 2010

rxvt-unicode Matcher Patch for Bug Numbers

A while ago Ganneff wondered weather it would be possible to make the matcher extension of rxvt-unicode also pick up something like #12345 and turn it into a link into the BTS.

It isn't—or rather, it wasn't. The idea got stuck in my head and invested some time to make it happen. Here is the quick'n'dirty diff to make it happen:

--- /usr/lib/urxvt/perl/matcher.distrib	2009-11-30 06:44:07.000000000 +0100
+++ /usr/lib/urxvt/perl/matcher.rhonda	2010-03-24 23:57:01.000000000 +0100
@@ -3,13 +3,14 @@
 # Author: Tim Pope <rxvt-unicodeNOSPAM@tpope.info>
 
 my $url =
-   qr{
+   qr{(?:
       (?:https?://|ftp://|news://|mailto:|file://|\bwww\.)
       [a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*
       (
          \([a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*\)| # Allow a pair of matched parentheses
          [a-zA-Z0-9\-\@;\/?:&=%\$_+*~]  # exclude some trailing characters (heuristic)
       )+
+      )|\#[0-9]{4,}
    }x;
 
 sub on_user_command {
@@ -145,6 +146,7 @@
          my @begin = @-;
          my @end = @+;
          if (!defined($col) || ($-[0] <= $col && $+[0] >= $col)) {
+            $match =~ s/^#/http:\/\/bugs.debian.org\//;
             if ($launcher !~ /\$/) {
                return ($launcher,$match);
             } else {

The diff is intentionally small so it is clear what is happening here. And it should give ideas for other extensions that one would like to make. I don't consider it though flexible enough to submit it upstream. Enjoy anyway!

/debian | permanent link | Comments: 0


Mon, 15 Mar 2010

stable RC Bug Squashing, Part 2

A while ago I blogged about squashing release-critical bugs in stable. Yesterday we have reached a big milestone on that area: The amount of release-critical bugs in stable dropped below 1000 (blue graph). This might sound like it's still pretty high but given that we were well over 1600 RC bugs in stable a while ago I consider this quite a success.

This is though no time for rest. There is still way too many RC bugs in stable, there are definitely still a lot of bugs that just aren't affecting stable and thus can be marked as such meaning no upload needs to get done for them. I'm taking a close look at those with higher numbers and most of those seem to be validly affecting stable too so they might require a bit more work than just tagging them.

Thanks to all people who helped on that area, I can just remember a few names and don't want to make anyone else also working on stable to feel singled out, though I want to thank Lucas for tagging his FTBFS rounds with squeeze sid right from the start because the packages obviously have built before due to his regular rebuilds. Thanks to all, but like said, not the time to rest. The green squeeze graph is still around 250 bugs away from us!

/debian | permanent link | Comments: 0


Mon, 22 Feb 2010

t-prot testing

The t-prot package might need your help: There is a discussion going on with the upstream developer how to proceed with respect to a hopefully helpful change in its behavior. There are several options how to address this, one of them would involve using the Getopt::Long module instead of Getopt::Mixed. Given that the benchmarks of upstream rather speak for sticking with Getopt::Mixed we would like to ask you for help:

Please test this version of t-prot (for your safety: detached gpg signature for the version) and compare it to the packaged version 2.15 that I just upload into unstable (it is installable without anything else also into (old)stable or testing). Your feedback on this is truly appreciated, please send it until the start of next week (Monday evening/Tuesday morning) to "t-prot (AT) tolot.escape.de".

Much thanks in advance!

/debian | permanent link | Comments: 0


Sun, 22 Nov 2009

stable RC Bug Squashing

Others are doing it, so I thought I'd join in, too. Though, from a different perspective. Often enough people claim that package maintainers don't seem to care about their packages anymore once they did hit stable because they say it isn't as easy to update packages in stable. While this is partly true it still doesn't send a too good impression to have a high and increasing release-critical bug count for stable.

UDD makes it easy. It has a field affects_stable in its bugs table, and the view bugs_rt_affects_stable is even yet better. I fiddled together two short statements that help me to find release-critical bugs for stable:

SELECT b.id FROM bugs_rt_affects_stable bas
   LEFT JOIN bugs b ON bas.id=b.id
   WHERE b.severity IN ('serious', 'critical', 'grave')
   AND b.id NOT IN (select bau.id from bugs_rt_affects_unstable bau)
   ORDER BY b.id;

The second statement is without the AND clause to see all open release-critical bugs. Going through this list isn't too complicated, and I already found a good rush of bugs to mark as not affecting stable because the reason for the bug only appeared after the lenny release. I could list their bugnumbers, but it's currently up to 39 such bugs since yesterday and I don't want to bore you with it, actually it didn't involve any touching of the package—but it will definitely make it easier to find the real release-critical bugs that do affect stable and should get addressed in an update to it.

Still lots to do, 39 bugs down isn't the world when the barrier is set to about 1500. Though, it's still more than 2% and this is something that makes me a bit happy.

/debian | permanent link | Comments: 0


Tue, 10 Nov 2009

Things that make me happy

  • when people upload to Debian with an @ubuntu.com email address
  • even better, if they do that when they are DDs (so with a @debian.org address)

Yeah! Actually, doing so shows several things: That the collaboration between Debian and Ubuntu actually works out. That people that feel more attached to Ubuntu also do care for Debian. And that those people started to realize that contributing things back to Debian actually does reduce their own workload with respect to not having to maintain seperate patches, with the benefit of all involved parties.

So big kudos to you people being able to look over the corner of your little universe and see the bigger picture for the benefit of all!

/debian | permanent link | Comments: 0


Fri, 16 Oct 2009

Signing Jokes in Contracts

It is great to see that the collaboration between Debian and Ubuntu is improving; and I don't say that just because it probably can't be much better within the Debian/Ubuntu Games Team, we have people from both distributions working inside the team and most of the packages don't carry Ubuntu specific patches (anymore) because of that.

Actually, seeing that things do go pretty well in that area made me consider signing up to become a MOTU. To do that one has to sign the Ubuntu Code of Conduct (CoC) which is a fairly good document, actually. I wish there would be something similar within Debian that is considered binding, it would be able to reduce quite some tough and rough times, actually. It is about and explains to be considerate, be respectful, be collaborative, what to do when you disagree, when you are unsure and wants you to step down considerately. If these principles would be carried out amongst all the free software communities (and I really mean carried out and not just be there and grow old) I expect it would be much more welcoming for new people. And it's not too hard to do your part for it (... says the person who just recently had to excuse for her behavior).

Anyway, there is this one part with the CoC that itches me. It's not that one has to sign it with their GnuPG key, but related to it. Making it a requirement to sign it gives the document a much more official character, actually gives it the feeling and impression of a contract and I expect it is meant to carry that feeling. Though, there is this one part in it that I consider off for such a document:

Nobody knows everything, and nobody is expected to be perfect in the Ubuntu community (except of course the SABDFL).

Given that the acronym SABDFL refers to Mark Shuttleworth it means that one has to expect him to be impeccable—which I am sorry but cannot sign. I don't expect that from anyone else but myself, even Mark is only human and can make mistakes. Even though it's obvious that this is a tongue-in-cheek kind of joke which might be meant to make it clear that the Ubuntu community isn't just sterile having this in a document that is expected to get signed by contributors is just an extremely bad idea.

Sorry, Ubuntu, as long as this joke is part of the CoC I can't sign it with clean conscience, no matter how much I would sign the rest of it a thousands' time. It really makes me wonder how many others actually did read the "contract" carefully that they are signing but on the other hand simply didn't care. There is too many site signup stuff out there that noone reads neither.

/debian | permanent link | Comments: 0


 
Feeds
If you want to syndicate this blog, feel free to do so.
This list contains the feeds that I follow:

 
Calendar
October
Sun Mon Tue Wed Thu Fri Sat
     
24 25
26 27 28 29 30 31  

2014
Months
OctNov Dec

 
About
©opyright 1999++ by Rhonda
[rss feed]

[html by vim] [graphics by gimp]

[generated by wml]

[powered by blosxom]