There are things that are unique in FLOSS development:

Author: nekral-guest
Date: 2008-04-04 19:43:33 +0000 (Fri, 04 Apr 2008)
New Revision: 1966
Modified:
   debian/trunk/Makefile
Log:
Add a cheesy check.
Modified: debian/trunk/Makefile
===================================================================
--- debian/trunk/Makefile       2008-04-04 18:50:22 UTC (rev 1965)
+++ debian/trunk/Makefile       2008-04-04 19:43:33 UTC (rev 1966)
@@ -1,4 +1,16 @@
 PKG=shadow
 SITE=ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/
+deb:: check_cheese
+
 include /usr/share/quilt/quilt.debbuild.mk
+
+check_cheese:
+       @dpkg-parsechangelog   grep -q "\* The \".*\" release\."     \
+               echo ""; \
+               echo " **                                  **"; \
+               echo " **  Warning: not a cheesy release!  **"; \
+               echo " **                                  **"; \
+               echo ""; \
+               exit 1; \
+        

Summary: releases of the Debian shadow package all have the name of a French AOC cheese since July 2005. Nicolas, who was focused on a new upstrram release of shadow inadvertently forgot to add such name for the 4.1.1-1 release and thus added a failure of the package build process in case on forgets the cheese name. We should however give NMUers instructions about the right way to NMU the package, such as giving the name of a local cheese.

I’ve just finished listening to the broadcast of a radio play based on Blood, Sweat and Tea a collection of posts from by favourite blog Random Acts of Reality. Random Acts is written by “Tom Reynolds” (a pseudonym) an EMT with the London Ambulance service. I guess I enjoy reading this blog so much because it shows an insight into the lives of members of an essential but very much unappreciated occupation. Well worth adding to your daily blog intake. Direct listen again link. Playing in the browser is all garbled :-/

Are you rebasing or merging? seems to be the 64 thousand dollar question over in vcs-pkg discussions. Various people have offered their preferences, and indeed, several case studies of work flows have been presented, what is lacking is an analysis of the work-flow; an exploration of which methodology has advantages, and whether there are scenarios in which the other work flow would have been better. Oh, what are all these work flows about, you ask? Most of the issues with packaging software for distributions have a few things in common: there is a mainline or upstream source of development. There are zero or more independent lines of development or ongoing bug fixes that are to be managed. And then there is the tree from which the distribution package is to be built. All this talk about packaging software work flows is how to best manage asynchronous development upstream and in the independent lines of development, and how to create a coherent, debuggable, integrated tree from which to build the distributions package. The rebasing question goes to the heart of how to handle the independent lines of development using git; since these lines of development are based off the main line of development, and must be periodically synchronized. Here is a first look at a couple of important factors that will have bearing on that question, and packaging software for a distribution using Git in general. This is heavily geared towards git (nothing else does rebases so easily, I think), but some of the concepts should be generic. I am not considering the stacked set of quilt patches source controlled with Git in this article (I don t understand that model well enough to do an analysis) As a teaser, there is a third answer: neither. You can just add an independent line of development, and just let it sit: don t rebase, and don t merge; and in some circumstances that is a winning strategy.

...Christian, but you can use 'bubulle' if you like, provided you pronounce it properly, ie the French way (b b l'). This is actually what most French(-speaking) DDs do. There is a special exception for Amaya, who uses "boubouy " in her Sprenchglish. I am proud of "bubulle", indeed. The nickname was given to me in the old days of BBS and *very* early Linux development in France, by Ren Cougnenc, *the* French Linux zealot of these years (and translator of a huge number of books/HOWTO/documentations). Ren , who I always dedicate my talks to, found it on a night in a bar back in...1990 or 1991, when we were getting heavily drunk with a few fellow friends, some of which became FreeBSD committers later (there is probably a link somewhere). "bulle" means "bubble" in French and you find bubbles in Perrier water....on the other hand "bubulle" is the name of the goldfish of Gaston Lagaffe, a pretty famous comic character from Belgian cartoonist Andr Franquin. Linking the two lead to "bubulle" which I never left, particularly since Ren decided to leave that world in July 1996. So, feel free to call me "bubulle" and when doing so, drink a pint to the memory of Ren . Late addition: I just found the very last electronic contribution Ren sent me (in newsgroups). For those who read French, this is really typical Ren -ish.

Well not directly, but MySQL is and they will also accept our projects. So if you are student interested in getting some money for improving free software, you're welcome to contact us. We have written down our ideas to wiki, but feel free to come with your own thought. But don't forget that deadline is this Monday! While talking about this improving phpMyAdmin, phpMyAdmin team would also like to take part in Hackontest, so vote and suggest there features for us! If you have no idea for phpMyAdmin, Debian is also taking part there ;-).

A while ago, Koha started using CGI::Carp in order to give more useful error messages and save us having to tell mailing list posters to read the fine Apache HTTPD error log quite so often. Even this still has limitations. Sometimes an unexpected response from a networked resource causes one of the underlying layers to return an error. That error itself doesn't help us much. We need to know what Koha or our C4 modules did to provoke it. So, I enabled backtraces. I copied a line from BitTorrent::TrackerCGI and added $main::SIG __DIE__ = &CGI::Carp::confess; to Koha in the relevant place. Isn't there a nicer way to do that? Or is this a bad idea for some reason? A patch for this has been sent to koha.org and it's inspired Galen Charlton to fix a related bug in the CGI::Carp usage.

As a Debian developer I have on occasion felt a bit out of touch with doing things with Debian and out of touch with other users. I mentioned to some folks at DebConf7 that I felt I focused too much on working on Debian and not actually connected to what the benefit of working on Debian is. Partially as a result of those feelings and partially because I thought it would be an interesting thing to do, I started to prepare a couple of simple surveys early this year. The first one went out earlier last month and I posted the second one a few days ago after far too much procrastination and running the wording by a few people - thanks to Micah for the drug boats question So, if you are a Debian user or are a new contributor (or DM/NM/AM or new DD), I would greatly appreciate hearing from you. Please respond to the survey addresses rather than my personal ones. So far I have 15 or so responses to the new contributor survey, but ideally I would have many more, so please send something in if you are getting involved in Debian development or helping others get involved. I've had about 24 responses to the user survey so far. Many of you will have heard about Debian success stories like Extremadura, Bhutan, HP, Skolelinux, Sanger and other high-profile Debian users. I'm hoping to hear about as many different uses of Debian as possible, so please keep the responses coming in. The primary audience for these surveys is the Debian development community. The results will go to the debian-devel-announce and debian-private, I also hope to have a discussion or two about them at DebConf8 in Argentina. There is no time-frame for closing the survey or releasing the results, like the Debian distribution, I release when ready PS: Please install the popularity-contest package on your machines if possible and subscribe to the packages.qa.debian.org pages for packages that you particularly care about. PPS: Please feel free to ask me questions in your responses and I will attempt to reply as time allows.

Currently my SE Linux Play Machine [1] is running as a Xen DomU. So if someone cracks it they would also have to crack Xen to get access to directly change things on the hardware (EG modifying the boot process). As documented in my last post [2] a user of my Play Machine recently managed to change my password. Of course this was just two days after the vmsplice() kernel security flaw had been discovered [3]. Of course any machine that offers shell access to remote users (or the ability to run CGI-BIN scripts or other programs that users can upload) is immediately vulnerable to such exploits and while SE Linux has blocked local kernel exploits in the past [4] there will always be the possibility of kernel exploits that SE Linux can’t block or which can be re-written to work in a way that is not stopped by the SE Linux policy. So it’s best to assume that SE Linux systems are vulnerable to kernel exploits. At the time that the vmsplice() exploit was announced there was a claim that it could be used to de-stabilise a Xen Dom0 when run within a DomU. It’s best to assume that any attack which can make some software perform in an unexpected manner can also be used to successfully attack it. So at the time I was working on the assumption that the Dom0 could have been exploited. Therefore I reinstalled the entire machine, I firstly installed a new Dom0 (on which I decided to run Debian/Unstable) and then I made a fresh install of Etch for the Play Machine. There is a possibility that an attacker could compromise the hardware (changing the BIOS or other similar attacks), but this seems unlikely - I doubt that someone would go to such effort to attach hardware that I use for demonstrating SE Linux and for SE Linux development (it has no data which is secret). If someone attacks my Play Machine they would have to first get root on the DomU in question and then crack Xen to get access to the hardware. Then the machine is on a separate Ethernet segment which has less access to my internal network than the general Internet does (so they would not gain any real benefit). One thing an attacker can do is launch a DOS attack on my machine. One summer a Play Machine overheated and died, I suspect that the extra heat produced by a DOS attack contributed to that problem. But losing a low-end machine I bought second-hand is not a big deal. When discussing the machine there are two common comments I get. One is a suggestion that I am putting myself at risk, I think that the risk of visiting random web sites is significantly greater. Another is a challenge to put the machine on my internal network if I really trust SE Linux, as noted I have made mistakes in the past and there have been Linux kernel bugs - but apart from that it’s always best to have multiple layers of protection.

• [1] http://www.coker.com.au/selinux/play.html


• [2] http://etbe.coker.com.au/2008/04/02/se-linux-play-machine-passwords/


• [3] http://www.avertlabs.com/research/blog/index.php/2008/02/13/analyzing-the-linux-kernel-vmsplice-exploit/


• [4] http://doc.coker.com.au/computers/se-linux-saves/

Share This

My Etch back-port repository of SE Linux related packages (which I documented in a previous post [1]) now has a complete set of packages for AMD64. From now on I aim to make AMD64 and i386 be my main supported platforms for SE Linux development. There is a guy who may be able to give me a stack of well configured PowerMacs (2gigs of RAM), if he comes through with that then I may add PPC-32 to the list of architectures I support. If that happens then probably the machines will have their hard drives smashed for security reasons, so I’ll want to swap some G3 PowerMacs for hard drives.

• [1] http://etbe.coker.com.au/2007/10/19/my-se-linux-etch-repository/

Share This

First of all, you can't do All Fool's Day pranks on global web sites because of time zones: if you do, you'll be pranking either early or late somewhere and so you're the fool. Now, I've been a bit quiet recently because I've been moving dozens of Wordpress blogs over to one Wordpress MU install. Clearly the right way to do it. They're all on different domains and we want their names to have www, which needed the following small change...

 
--- wpmu-settings.php
+++ wpmu-settings.php
@@ -6,8 +6,8 @@ if( $current_site && $current_blog )
 $wpmuBaseTablePrefix = $table_prefix;
 $domain = addslashes( $_SERVER['HTTP_HOST'] );
-if( substr( $domain, 0, 4 ) == 'www.' )
-       $domain = substr( $domain, 4 );
+if( substr( $domain, 0, 4 ) != 'www.' )
+       $domain = 'www.'.$domain;
 if( strpos( $domain, ':' ) )  
        if( substr( $domain, -3 ) == ':80' )  
                $domain = substr( $domain, 0, -3 );

I could have sworn I changed something else in that file, but I don't see what. Oops. I guess I'll run a check against the release tarball before merging the next upgrade from upstream. If anyone wants to hire someone to move blogs to Wordpress MU, you how where to find me. It's pretty enjoyable once you get into the routine, even if this project overran. I'm looking at changing my own blogs too. I'm looking at Chronicle but maybe with more email-like input files.

As outlined some days ago, patience is a requirement. That said, I'm glad that all things come to (s)he who waits, Lufthansa hardware finally landed! Ganneff, already very busy with his well-known DAM and ftpmaster hats, managed to also handle shipping some hardware donated by the Lufthansa some months ago. pkg-games was promised a powerful box, look: Pentium 4 (2400 MHz, 1024 MB); we will finally be able to try and provide backports in a semi-automated fashion, so as to ease stable users' life, when it comes to installing bleeding-edge versions of their favourite games! Thank you for making this possible and keeping everyone posted about the status of that hardware donation. Hopefully, it'll be possible to also communicate through bits of the DAMs , as suggested some weeks ago on debian-newmaint@. Yay for communication! \o/

Slow sunday afternoon? Choose a release goal and work on it!

Yesterday I focused on the goal-recommends issue: No unmet recommends relations inside main. I worked from 18:00 pm to 2:00am, aprox, and 32 bugs were closed.

16 Non Maintainer Uploads, closing 21 bugs:
* delo  (Closes: #378221, #414389, #416161, #452953)
* gpib  (Closes: #430998)
* php-net-smtp (Closes: #369273)
* rpc2 (Closes: #377829) (NMU Overriden by maintainer)
* rvm (Closes: #377410) (NMU Overriden by maintainer)
* smooth-themes (Closes: #379195)
* xmltex (Closes: #429564)
* acpitool (Closes: #436637)
* asciidoc (Closes: #452470)
* chasen (Closes: #363196, #452474)
* cl-screen-sbcl (Closes: #436641, #460444)
* cpufreqd (Closes: #436647)
* denemo (Closes: #439929)
* lacheck (Closes: #448911)
* sablevm (Closes: #346071)
* ddcontrol-db (Closes: #436649)

Filed for removal, will close 3 bugs:
* digikamimageplugins-doc (Closes: #448904)
* free-java-sdk (Closes: #429306, #401492)
* php4-apd Filed for removal by KiBi (Closes: #418319)

Orphaning uploads, closing 2 bugs:
* xcin2.3 (Closes: #276885)
* gnochm (Closes: #429304)

Packages only present in oldstable, closing 4 bugs:
* eagle-usb-utils (Closes: #448905)
* zd1211 (Closes: #378725)
* python-pysnmp4 (Closes: #377075)
* lessdisks-terminal (Closes: #361939)

Bugs marked fixed but never properly closed, closing 2 bugs:
* araneida (Closes: #436638)
* gtk2-engines-murrine (Closes: #430999)

That leaves a total of 2 bugs remaining to finish the release goal:
* #436650: syslinux: Please build (at least a subset of) syslinux for all arches
* #448890: bioperl: recommends packages not in main (pending, serious)

These don't seem trivial to fix, anyone dares to step in?

(Updated: Monday, March 31 2008 17:50)

Via Lifehacker, legal cost-free books under copyright from Wowio. This is a great idea, and I give it even odds for being the future of books. (Or at least, part of books’ future).

What is WOWIO?
WOWIO is a new kind of online bookstore that enables readers to download ebooks for free, using commercial sponsorships to compensate authors and publishers. Readers get free ebooks. Sponsors get a powerful new channel to communicate their message to precisely the people they want to reach. Publishers get a new means of distributing their books, expanding their readership, and monetizing their intellectual property.

Does WOWIO use any kind of digital rights management (DRM)?
Since anyone can defeat the most “sophisticated” DRM with the print screen button, we believe that technology-based DRM is essentially a fraud. Our approach takes the market incentive out of misbehaving, rewards people for doing the right thing, and tries to stay out of the way of honest users. To help keep everyone honest, however, readers must authenticate their identity and agree to a licensing agreement when they set up their account. Then, each ebook is serialized with the reader’s authenticated name and a unique serial number, as well as other less visible markers. WOWIO will immediately terminate the account of anyone caught illegally distributing ebooks, and will prosecute serious offenders.

Technorati Tags: Wowio, Books, DRM, Digital Rights Management, Copyright

Share This

At the moment I’ve got more time to work on these things than I have had for a while. I’ve got Etch support going quite well (see my post about my Etch repository [1]), the next step is to back-port some packages for AMD64 to get it working as well as i386. I’ve got an i386 Xen server for SE Linux development (which is also used for my Play Machine’s [2] DomU - so it’s definitely not for anything secret). I can give accounts and/or DomU’s to people who have a good use for them (the machine has 512M of RAM so could have 4-5 DomU’s). Currently it seems that the 2.6.24 kernel in Debian doesn’t work for Xen (at least on with an i686 CPU). I have filed bug report #472584 about it not working as a DomU [3]. This combined with the fact that according to bug report #466492 it doesn’t work as a Dom0 (which I have verified in my own tests) [4] makes the package linux-image-2.6.24-1-xen-686 unusable. Due to the inability to use 2.6.24 Xen I can’t do SE Linux development for Lenny in a DomU (Lenny tools build policy version 21 and the Etch kernel I’m using only supports policy version 20). So I have repurposed one of my servers for Lenny (unstable) development. I can give user accounts on that machine to anyone who has a good reason (and there are some people who I would give root access to if they need it). The current policy packages in Unstable are built without MCS support. This is a problem as converting between a policy which has MCS or MLS and one which doesn’t is rather painful (purge policy, reinstall policy, and reboot are all required steps). I have filed bug report #473048 with a patch for this - my patch may not actually be much good (I don’t understand some aspects of Manoj’s code) but it does achieve the desired result [5]. I won’t be making Apt repositories for such things as I expect that the changes will get into Debian fast enough. The next thing I am starting to work on is MLS support for Debian (currently it only supports the Strict and Targeted policies). See the Multilevel Security Wikipedia page for some background information on the technology [6]. I don’t expect that many people will use MLS on Debian in production environments, and it wouldn’t surprise me if no-one used it on a production server (although of course it would be impossible to prove this). But I still believe that it’s worth having for educational purposes. I am sure that there are packages in Debian of a similar size that will get less use so it’s not a waste of disk space on mirror servers! The only real down-side to adding MLS support is that it will increase the build time for the Debian SE Linux policy packages, currently they take 13 minutes to build on a 1.1GHz Celeron system (the Xen server I mentioned previously) and I expect that the machine in question will have build times greater than 20 minutes with MLS included. I will probably need to set up an Unstable DomU on a dual-core 64bit machine for the sole purpose of building policy packages. I will also have to investigate use of the “-j” option to make when building the policy to take advantage of the dual cores. I often do small tweaks to policy and it’s annoying to have to wait for any length of time for a result. The version of Coreutils that is currently in Unstable will have ls display a “+” character for every file when running SE Linux (I have filed bug report #472590) about this [7]. It is being actively discussed and at this stage it seems most likely that the functionality from Etch in this regard will be restored (which is using “+” to represent ACLs only not SE Linux contexts). It seems likely to me that I will find a few other issues of a similar nature now that I have started seriously working on Unstable. For the benefit of Debian and upstream developers who get involved in such discussions, please do not be put off if you join a discussion that is CC’d to the NSA SE Linux mailing list and have your message rejected by the list server. The code of conduct is much the same on most mailing lists, and the SE Linux list is not much different to others. The difference is that before your get your email address white-listed for posting you have to agree to the terms of service for the list. The people who run the list server appear to work more than 40 hours a week so there should not be a great delay. If anyone wants to get a message about Debian SE Linux development sent to the list without delay on a weekend then they can send it to me for forwarding. I am aware of some discussions about SE Linux and the Debian installer. I have not responded to them yet because I wanted to get some serious coding done first as an approach of “I haven’t done much coding recently but trust me I’ll fix the problems for you” might not be accepted well. I will start investigating these issues as soon as I have my Debian/Unstable server working well in enforcing mode. Update: I’ve just filed bug report #473067 with a patch to enable MLS policy builds [8].

• [1] http://etbe.coker.com.au/2007/10/19/my-se-linux-etch-repository/


• [2] http://www.coker.com.au/selinux/play.html


• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472584


• [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466492


• [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473048


• [6] http://en.wikipedia.org/wiki/Multilevel_security


• [7] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472590


• [8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473067

Share This

There is one particular aspect of Microsoft’s document format going through ISO process that I had a hard time to find a counter-argument against: “Well it is better to have multiple open formats, isn’t it?”. Last night when I was presenting in a Document Freedom Day event, I finally got one. When multiple standards exist in the same area, two options can exist:

1. Cooperative standards - providing similar functionality in different ways that can coexist in the same medium without a significant overhead. An example of this are the credit cards - they have multiple ways that the card information can be transferred to the bank: visual writing down of the data, imprint, magnetic strip and the chip. Any of these ways can be used and all of the are equally valid;
2. Conflicting standards - providing the same functionality in incompatible ways. The example here is the power adaptors - the form of the power plug is an open and public standard (AFAIK), but so many of them exist in different places that it creates all sorts of problems both for companies producing electronic equipment and for frequent travellers.

What Microsoft proposes is much worse than the power plug mess, because the power plug standards are at least restricted by region. But imagine going to another country and having to be ready that you hotel could have any one of 8 power plug types at random. And while electricity is rather easy to convert looselesly, complex documents are far more .. complex. It is like having to buy 8 different power bricks for each of your electrical devices to be prepared for all possible voltages, frequencies, waveforms, polarities and whatnot. Having more than one ISO document standard in a horrifying idea for any programmer that will have to ever work on software that will need to support both of them - twice the work for no etra benefit whatsoever. If Microsoft can prove (in technical terms) that their file formats present capabilities that Open Document can not, then the only sane way to implement those in the ISO format is to add those capabilities as an extension of the existing Open Document format and not to reinvent the wheel. Microsoft also has a habit of pointing to JPEG and PNG being “competing”. Well, they are not - those are complimentary standards, because JPEG is designed for compression of photographic details while PNG is designed for the compression of bitmapped vector images. Something like DejaVu could be seen as a superset of the two formats. So, if you ever need an argument against more standards - remember about the power plugs.

New invariant sigils in Perl 6 Wouter, apparently most people found Perl's changing sigils (that's the name of Perl's paraphernalia: $, %, @) annoying. That's the reason why they are becoming invariant with Perl 6. Actually I assume that's the reason; I haven't read the corresponding RFC, partly because it is usually impossible to find the one you are looking for ... BTW, I recommend to all people interested in Perl to have a look at Patrick Michaud's slides on Perl 6: I quite enjoyed his talk at FOSDEM, way better than Larry Wall's talks I've attended in the past (this time at least I went back home with some actual content, instead of only LOLing for the talk duration).

GNU Smalltalk 3.1 rc1 includes Seaside, a web application framework based on continuations. To use, you'll need to install package gnu-smalltalk 3.1~rc1-2 from experimental. Then, from a terminal, launch gst and type[1]:

st> PackageLoader fileInPackage: 'Seaside'
st> PackageLoader fileInPackage: 'Seaside-Development'
st> PackageLoader fileInPackage: 'Seaside-Examples'
st> ObjectMemory snapshot: 'seaside.im'

Now start you can start Seaside with gst-remote -I seaside.im --daemon --start=Seaside, and launch your browser on http://localhost:8080/seaside:

---

[1] taken from GNU Smalltalk info page

Some people expressed some concerns about the fact that we currently have about ~440 bugs in testing, but still hold to our plan of releasing in september 2008. The development of the RC bug graph as seen on bugs.debian.org is in fact not very promising - but using the information the BTS now keeps through version tracking, a more detailed graph can be created. This one in fact shows how nicely we are progressing: The number of long-standing RC bugs is steadily shrinking, while the number of fixed bugs just waiting for transition is increasing. The latter is due to several complex transitions that are stuck (such as the ghc upgrade to 6.8, the suitesparse upgrade or X.org). Anyway, lenny's overall situation is a lot better than the simple RC bug count shows, so try to be positive and start bug-fixing now, for the first Debian release on time!

In other positive news, the first bits of Gnome 2.22 have reached testing, we will switch the default gcc version to 4.3 on this weekend and will start using python2.5 as default python version in the next week. Interesting times!

After a while, I ended up building WWW::Tumblr (implementing the Tumblr API), so that Blog::Normalize::Tumblr can easily replace scrapping. The interesting part would be to write small applications to interact with the WWW::Tumblr to handle your tumblelog. Only file uploads missing for now. For now.