Software in the Public Interest, the contributor-led not-for-profit corporation that supports debian GNU/Linux, OpenVAS, OpenOffice.org and an ole load of other free software projects meets tonight (Wednesday 9th) at 20:30 UTC in #spi on irc.spi-inc.org. The agenda has been published and the main item to be discussed is adding LibreOffice as an associated project. What do you think of that, then? SPI supporting both LibreOffice and OpenOffice? A balanced position, fence-sitting or something else?

Someone asked me during CeBIT for official packages of mendeley. I didn't knew much about it at that time, but mentioned it in my report on the debian-project mailing list. It appears, that mendeley won't be packaged anytime soon, however Charles Plessy and others commented on that and mentioned some similar tools. As I don't have any contact data for the visitor, who asked me about it, the best thing I can do for now is mention it here, so he might notice it and read the comments on the list.

Continuing my series about my desktop in a shell, in this chapter I will present you my irssi setup.Irssi is the most customized part of my setup, using many scripts from the irssi-scripts Debian package and some from the internet , handling 6 irc networks with a total of 34 channels plus JabberXMPP, ICQ, Twitter and identi.ca. My custom irssi settingsI like my conversations to look like Buddy, you rock instead of Buddy: you rock , so:
/set completion_char ,I also like *long highlighted text*, so:
/set emphasis_multiword onHide mIRC and ANSI colors when turned on. This can be used to eliminate angry fruit salad syndrome in some channels. (Quote from irssi.org/documentation/settings, do I have to say more?):
/set hide_colors onWhen talking in more than one channel, it sometimes comes handy to repeat something from the past said in THAT channel, not searching though all:
/set window_history onTell irssi to shutup when away, noone will hear/see the beep anyways:
/set beep_when_away offI want my screen to inform me about new messages, so I need this:
/set bell_beeps onBeep for query text, notices, dcc, dcc text and hilight:
/set beep_msg_level MSGS NOTICES DCC DCCMSGS HILIGHMy used irssi scriptsactive_notice.pl (from irssi-scripts)Show notices in the active window or the corresponding query instead of the status-window.
No further configuration needed.adv_windowlist.pl (from anti.teamidiot.de)Some really smart windowlist, see my previous post about adv_windowlist.pl, I won t explain its features and settings here again.autorealname.pl (from irssi-scripts)Show peoples real-name when they join (my $nick $name memory is poor :()
No further configuration needed.chansort.pl (from irssi-scripts)Automatically sort my channels alphabetically, grouped by network.
Enable via /set chansort_autosort on<Update>kaimi asked me yesterday, whether chansort could ignore the network and just sort ALL channels in alphabetical order. Well, it could not, until yesterday ;) Fetch either the patch against chansort.pl or my chansort-ng.pl and set chansort_ignore_network to ON. You can also set chansort_ignore_windowtype to mix channels and queries if you like to.</Update>hack-whois-in-current-window.pl (from dgl.cx)Display /whois in the current window or the corresponding query instead of the status-window.
No further configuration needed.keepnick.pl (from irssi-scripts)Restore my nick after it is free again (like after a ping timepout).
Set the nick via /keepnick [-net chatnet] [nick]nickserv.pl (from irssi-scripts)Automatically authorize me on networks with NickServ.
Enable by settings services address, nick and password via:

/nickserv addnet freenode NickServ@services.
/nickserv addnick freenode Zhenech mypass

screen_away.pl (from irssi-scripts)Set away when screen is detached.
Will be enabled automatically, but you maybe want to tweak screen_away_message :)seen.pl (from irssi-scripts)Add a /seen nick command to lookup when and where nick was online the last time.
No further configuration needed.trackbar.pl (from irssi-scripts)Draw a line when you switch irssi windows so you can see which part of the conversation you have already seen.
No further configuration needed.BitlBeeI m using BitlBee as my irssi-to-every-im gateway of choice ;) But while it sounds easy, my setup isn t. I am using BitlBee only to connect to jabber.die-welt.net, my Jabber/XMPP server. There I have a pyICQt instance running, to connect to ICQ via Jabber (yes, BitlBee would support that directly, but that would fail on me when I would like to connect from a different Jabber-client). Twitter and identi.ca are handled via Jabber too: identi.ca does support this by themself, for Twitter I use the tweet.im service.
But besides of my strange setup, BitlBee is easy: apt-get install bitlbee, connect irssi to localhost:6667, you will be force-joined to &bitlbee, where you do:

register somepassword
account add Jabber you@jabberserber.example.com jabberpassword
account on 0

and done, you@jabberserver.example.com is online :)The all awaited screenshot (from my last irssi-post):

And the whole ~/.irssi/config: http://files.die-welt.net/irssi-config.txt, read it carefully while waiting for the next post about newsbeuter :)

If you were watching itv1 last night (or since), you might have seen the co-operative group s Join the Revolution advert that hints at how buying from co-op shops helps to support a wide range of other co-operative efforts. This isn t unique to that co-op our co-op has been helped by the group and many others over the years, both formally and informally, and we ve helped other co-ops too but the shops are one of the biggest co-ops and it s great to see them getting the message out there. It s rather less great that my mobile phone is convinced that John the Revolution is much more probable. Got to love software. If only it was free software I could fix

Another week is over and it's time to spam^W look again at state of translations for phpMyAdmin 3.4. There are no changes to list of complete translations, so we still have 12 translations at 100%:

• Catalan
• Chinese (China)
• Czech
• Dutch
• English (United Kingdom)
• French
• Greek
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are still lot of translations which would need some love:

• German
• Norvegian
• Polish

And I'm really happy to see progress of some exotic languages (at least for me) such as Urdu. You can help make translation to your language better! If your language is missing just let me know (either in comments or by email).

Filed under: English Phpmyadmin 2 comments Flattr this!

Spent some of my morning fixing a build issue that came down to the use of AC_ARG_ENABLE. I thought it was worth recording some notes for its use: Something enabled by default:

AC_ARG_ENABLE([badgers],
              [AC_HELP_STRING([--enable-badgers=@<:@yes/no@:>@],
                              [Enable badgers @<:@default=yes@:>@])],
              [],
              [enable_badgers=yes])

Something disabled by default:

AC_ARG_ENABLE([badgers],
              [AC_HELP_STRING([--enable-badgers=@<:@yes/no@:>@],
                              [Enable badgers @<:@default=no@:>@])],
              [],
              [enable_badgers=no])

Observe that in this case the only thing that changes is the default value in the third parameter to AC_ARG_ENABLE (and also the documentation ) Something enabled by default but with a disable syntax:

AC_ARG_ENABLE([badgers],
              [AC_HELP_STRING([--disable-badgers],
                              [Disable badgers],
              [],
              [enable_badgers=yes])

Notice that this case is just the same as the first except with the help changed. Of course you actually need to use the value from the flag. I think this is more readable if presented outside the AC_ARG_ENABLE parameters this is possible because AC_ARG_ENABLE always sets a variable called enable_<thing>. Awesome, huh? For conditional pkg-config:

AS_IF([test "x$enable_badgers" = "xyes"],
      [PKG_CHECK_MODULES(BADGERS, [badgers-1.0])],
      [])

For conditional building:

AM_CONDITIONAL(ENABLE_BADGERS, test "x$badgers" = xyes)

I've received a few requests to help with failing builds in the past, mainly for packages I maintain (either officially or unofficially). And most of those requests revolve around custom Wine builds. Because this is recurring, I'd like to take the opportunity to write down some general answers which solve most of the problems, so I can point people to this entry.

• Use pbuilder (cowbuilder is a good companion to pbuilder).
• If you've modified the packaging, make sure you didn't introduce bugs, which lead to your failure (this implies careful reading of your build logs).
• If you didn't update the packaging and just used a newer upstream version to build your packages, you should check what was changed upstream (maybe you need some additional Build-Depends or something similar) and whether the unmodified Debian package (including the .orig.tar is buildable in current Sid.
• If you added patches (maybe taken from some upstream bug tracker), make sure it's not those patches, which cause the breakage.
• When you do a backports build make sure all build dependencies are satisfied.

Apart from that, you'll most likely find a lot of answers in the Developer's Reference and the New Maintainers' Guide. Nothing of this is news to Debian Maintainers, but I hope it helps people doing a build for themselves, when they're less experienced.

In the software community, people hold strong opinions on the subject of listening to users. Some feel that users are an essential source of information for making successful products, as evidenced in the customer development methodology, and seek to involve users deeply in product development. Others believe that users don t know what they want, invoking the quote attributed to Henry Ford, If I d asked customers what they wanted, they would have said a faster horse . Some say that user needs are unknowable except through the lens of a marketplace, where people choose in aggregate which products suit them best, and customers vote with their wallets (anything else is anecdata ). Regular readers will not be surprised that I believe they are all right, but only in certain contexts. The right strategy for involving users in product decisions will depend on factors related to the product itself, the market, and the product development method being used. One of the most important is the life cycle stage of the product: is it a new and rapidly evolving concept, or a mature commodity, or somewhere in between? Simon Wardley explains this well over on his blog, so I won t rehash his points here, but will add a few of my own. If what we re looking for is inspiration for a new product, it s here that Henry Ford was right: users generally won t hand you a complete product vision on a silver platter. They ll frame their input in terms of what they know, and the choices already available to them. However, this doesn t mean that users don t have a role to play in this instance: watching users can be a great source of inspiration. It s the combination of domain knowledge and passionate imagination which triggers the creative spark. Henry Ford applied his engineer s interests to a problem which was evident all around him. If our goal is to test whether a new product is a good fit for its users, there is no substitute for user feedback. We can guess at whether there is a fit, and our intuition may be good, but users are the ultimate judges, and we don t know if we re right or wrong until users evaluate it. So ask them! By engaging in dialogue with individual users, we can learn unexpected things which will help to refine the idea. If we don t find what they think until our new product is released, we risk making something that no one wants. Why wait until it s too late? It can be challenging to extract useful feedback for a product which doesn t yet exist, but this effort is well worth it to avoid wasting much more effort in software engineering. When our objective is to incrementally improve an existing product, individual anecdotes can mislead us. A given change may be an improvement for one user, but a disaster for another. What we want to know is whether the new version is better for the population as a whole, and in this case, we do well to rely on data. There are pitfalls here as well, of course. We need to choose our questions carefully, and realize that users will often resist any change: not because they re stodgy by nature, but because they have to invest effort in adapting to the change. I think of incremental improvement as a joint investment made between product developers and their users, to improve the whole system of people and technology for the better. By choosing the right tool for the job, we can make better decisions, improve faster, and ultimately solve the right problem for our users.

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 squashing again. I came to the conclusion that working on lenny RCs 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 RCs. 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 Flattr this

Those who followed the live stream or read our News already knew it: Debian has been honored with the Linux New Media Award in the Categories "Best Open Source Server Distribution" and Outstanding Contribution to Open Source/Linux/Free Software. Especially the second one, considered to be the "kings class" of the LNM awards, is a great honour. While it is called the Linux New Media award, the decision of whom to honor with them isn't done by the company themselves, but by a bigger jury, consisting of over 300 representative community members, developers, journalists and companies. Deciding in a secret vote¹. To the best of my knowledge, there's nothing similar. So one can truly say, we weren't awarded by a company, but by the entire Free Software community! Congratulations to everyone involved! For our Outstanding Contribution to Open Source/Linux/Free Software award, we also had the special pleasure, to receive our presentation speech from Karsten Gerloff, president of the Free Software Foundation Europe, who found words, I can hardly explain myself. As it might take some time for the video of the award ceremony to be published and several people already asked for it, you'll find the text of the speech below. Still, you might want to watch the video for a special surprise by Karsten:

I'm here to congratulate the Debian project. Debian has recently taken a nearly unprecedented step, one that many people thought would never come to pass: The project has updated its website design. Today, Debian receives the Linux New Media Award for its outstanding contribution to Free Software. I could hardly think of a more fitting recipient for such an award. Debian is coming of age, literally. In August, the distribution will turn 18. Debian offers great technology. It's stable. Really stable. It's highly flexible, and performs well in lots of different roles. IT supports more different architectures than almost anything else out there. It runs on pretty much anything. The package management is great. It makes a highly complex system of almost 30,000 packages extremely simple to configure and use. Debian started out as a true pioneer. When the project was created in 1993, the whole concept of a distribution wasn't too well established. Ian Murdock announced the project thus:

"Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the past, Debian is being developed openly in the spirit of Linux and GNU. [...] Debian is being carefully and conscientiously put together and will be maintained and supported with similar care." At a recent conference, the current Debian project lead, Stefano Zacchiroli, gave a talk titled Who the bloody hell cares about Debian? Turns out that many people do indeed. Debian is the GNU/Linux distribution that has the most derivatives based on it currently 128, if Distrowatch.com is to be believed: Ubuntu, Knoppix, gNewSense, and many more. And those distributions again have their own derivatives. None of these could function without Debian. Lots of people rely on Debian. That makes it all the more important that Debian is so reliable. The Debian project gives us Free Software that is both rock-solid and exciting. But the greatest thing about Debian is not the fact that it delivers great software. Other distributions do that, too. The big thing about Debian is the *idea* of Debian: The idea that a massive Free Software project can be totally independent. Debian shows how it's possible to build a highly reliable operating system without a formal body. The project has created some pretty complex structures to run itself, as a do-ocracy, based on consensus and running code. This is important. We are currently debating how Free Software projects can best be governed in the long run. How do we make sure that a project's users can always enjoy the freedom they deserve? How can we structure a project in a way that makes it immune to a hostile takeover? Oracle's acquisition of Sun has shown that these are important question. A Free Software license, preferably one like the GPL that protects freedom in the long run, is an important first step. But a Free Software project consists of much more than code. While uncounted people and companies are earning good money with Debian, the Debian project itself can't be bought simply because there is noone you could buy it from. Debian has been doing vendor independence long before it was cool. What I love most about Debian is that like few other big projects, Debian has the idea of freedom at its core. Debian's Free Software guidelines are a central manifesto for software freedom. The Debian Social Contract does not mention a single package or program. But it is without a doubt one of Debian's most important pieces of documentation. In Debian, quality is the focus of everyone's attention. But those who work on the Debian system know that great software is worth nothing without Freedom. With the release of Squeeze, the latest stable version, in February, Debian has taken the important step of offering a completely free kernel, with no binary blobs. This is a first for a major distribution in recent times. Debian is giving its users Freedom by default. And this Freedom for users and developers on a massive scale truly is Debian's outstanding contribution, not just to Free Software, but to the information society. On behalf of the Free Software Foundation Europe, I would like to thank everyone in Debian for their work, and congratulate them on this award. It's well deserved. Keep up the good work!

1: I forgot to mention one small, but important detail: The voting period for the jury ended on December 23, 2010, so long before Squeeze was released. So we can be quite sure, that the Jury didn't followed the Squeeze-Hype with their decision, but really thinks, we did something great :)

I recently acquired a Pixma MP 250 printer, and as I had some difficulties with setting it up, I wanted to share this here. The printer isn't supported as such by CUPS, so I had to dig a little bit. After quite some time, I found debian packages on the Canon website there. Don't fear the mention of i386, amd64 packages are included too. This link is likely to break when the software is upgraded, you should try your luck in the drivers search page should that happen (or for other models). After installing that, CUPS find the connected printer and proposes the PPD for it. The scanner works out of the box with xsane As a side note, Canon also provides source for the debian packages (the packaged was ITPed ages ago). However, there are some binary-only blobs and I didn't manage to get it to compile from source.

I ve had a very courteous email from one of the founders of ALLOW, following my analysis of their password reset procedure.

Thank you for your feedback regarding the security of our platform. We are constantly reviewing these processes and regard our members security as paramount, whilst ensuring our processes are navigable to the majority of the UK. We have had the platform professionally penetration tested but your email demonstrates an excellent understanding of the challenges and we would welcome your suggestions on our options of improving the password reset process. We will be extending our SSL certificate to the publicly accessible website and please be assured that this is held on a different architecture to that of the Member application.

This is very promising!

---

Response from ALLOW Ltd. is a post from: jwiltshire.org.uk Flattr

Is there a way to access a MySQL database over the network from PHP and be confident that

• the connection is actually using SSL, and
• the server's X.509 certificate was successfully verified?

As far as i can tell, when using the stock MySQL bindings, setting MYSQL_CLIENT_SSL is purely advisory (i.e. it won't fail if the server doesn't advertise SSL support). This means it won't defend against an active network attacker performing the equivalent of sslstrip. Even if MYSQL_CLIENT_SSL was stronger than an advisory flag, i can't seem to come up with a way to tell PHP's basic MySQL bindings the equivalent of the --ssl-ca flag to the mysql client binary. Without being able to configure this, a "man-in-the-middle" should be able to intercept the connection by offering their own certificate on their endpoint, and otherwise relaying the traffic. A client that does not verify the server's identity would be none the wiser. One option to avoid a MITM attack would be for the server to require client-side certs via the REQUIRE option for a GRANT statement, but the basic MySQL bindings for php don't seem to support that either. PHP's mysqli bindings (MySQL Improved, i think) feature a command called ssl_set() which appears to allow client-side certificate support. But its documentation isn't clear on how it handles an invalid/expired/revoked server certificate (let alone a server that announces that it doesn't support SSL), and it also mentions:

This function does nothing unless OpenSSL support is enabled.

Given that debian MySQL packages don't use OpenSSL because of licensing incompatibilities with the GPL, i'm left wondering if packages built against yaSSL support this feature. And i'm more than a little bit leery that i have no way of telling whether my configuration request succeeded, or whether this function just happily did nothing because the interpreter got re-built with the wrong flags. Shouldn't the function fail explicitly if it cannot meet the user's request? Meanwhile, the PDO bindings for MySQL apparently don't support SSL connections at all. What's going on here? Does no one use MySQL over the network via PHP? Given the number of LAMP-driven data centers, this seems pretty unlikely. Do PHP+MySQL users just not care about privacy or integrity of their data? Or (please let this be the case) have i just somehow missed the obvious documentation? Tags: mysql, php, question, security, ssl, tls

I've been promoted - my job title will now be 'Software Architect'. This seems to mean I'll be writing documents rather than code - any higher-level, and I'd need Mark Shuttleworth's spacesuit. Is this a good thing? Anyway, I celebrated by opening my last bottle of Debian wine. <spam>Unfortunately, I can't take up my new role until we have hired a replacement. UK-based developers who know Perl and ideally PostgreSQL might want to look at the job description, although I'd recommend sending your CV and covering letter to me directly. I don't get a referral bonus, it's just that I don't like what that agency does with your carefully-crafted application.</spam> I'd like to thank everyone who maintains LaTeX for their assistance in this matter. In other news, I'm studying a couple of Open University courses part-time - one on software development (i.e. UML), and one on interaction design. They're going well so far - I've had a couple of tutorials, and the first part of an assignment came back with good marks. I've been reading the Lean Software Development books by Mary and Tom Poppendieck. They seem to put Agile development into a 'respectable' historical context of similar improvements in manufacturing, which might be useful for persuading project managers.

Next week is over and it's time to show another picture. Today I've decided for indoors photo, what is something I usually don't take, but here it is.

Filed under: English Photography 0 comments Flattr this!

Counting derivatives In the news, there's an article by Bruce Byfield discussing the influence of Debian and its (transitive) derivatives on the ecosystem of GNU/Linux distributions: Linux Leaders: Debian and Ubuntu Derivative Distros. The article is a sort of review of what you can find in the vast ecosystem of distributions rooted at Debian: from embedded to supercomputer distro, from netbook to scientific computing distros. The articles cites the Debian derivatives front desk and is a study similar to what we might tackle with the derivatives census by Paul Wise. (By the way: did you check if your favorite Debian derivative is already in? No? Do it!) With this article, Bruce has made me quite a favor in harvesting distrowatch to refresh the figures about the number of derivatives that I often use in speeches. The need of doing that has been polluting my LaTeX "% TODO" comments for a while now Here they are:

• 324 active distributions
• 129 of them are (directly or transitively) based on Debian
• 75 of the latter class are (directly) based on Ubuntu, i.e. transitively based on Debian

Update: update figures that Bruce misinterpreted; live data are available, thanks to Loris (see comments) for noticing

I've been nagged for a while (by Wookey mainly) about the unhelpfulness of dpkg-checkbuilddeps when it outputs the versions and alternatives alongside the package names which are missing, making it harder to pass the list to the package manager. apt-get build-dep isn't particular helpful either - it doesn't look at the modified package at all.

Of course, once the output is in a suitable format, a new script might as well make it possible to simply pass that output to said package manager. Once it can do that, it can then pass the output to the cross-dependency tools, like xapt.

So, I've refactored the embuilddeps script in the xapt package to do just this.

It's gained a few features in the process:

1. Support for Build-Conflicts resolution


2. Support for virtual packages, swapping the virtual for the first package to provide it (borrowed some code from Dpkg::Deps for that one).


3. Support for Build-Depends alternatives (currently using the buildd default of "first alternative gets first chance")


4. Reads data from debian/control, not the apt cache - to help with the package you're building instead of the one you've already uploaded.


5. Handles cross dependencies (which are always assumed to not currently be installed) and native dependencies. This support is transitory until such time as enough packages are Multi-Arch compatible that Cross-Multi-Arch becomes trivial.


6. Support for being used as a build-dependency resolver in pbuilder, including cross-architecture dependencies with pdebuild-cross.


7. Can locate a debian/control file in a specified directory without needing to be called from that directory


8. Checks your apt-cache policy to see if the required version of a package is available from your current apt sources. Fails completely if not. (The pdebuild-cross usage will need that to be extended a touch to look at the apt-cache policy from within the chroot.)


9. Hector Oron has also been asking me to get embuilddeps working with sbuild, so I'm working on that feature too.


10. verbose and quiet support (so use -q inside other scripts)


11. most output is already translated - more translations are welcome, especially for the documentation, but hold on until this version has actually been uploaded.

More testing is needed, particularly that the extensive refactoring hasn't broken the pbuilder resolution support and then looking at what still needs to be done for sbuild support. The new script is in Emdebian SVN.

The first-choice method for virtuals and alternatives may well bear extension to explicit management via command-line options. I'm unsure yet whether it needs to be a configuration file setting. It could simply be a recursive - try one, move on - model.

Cupt v2 has reached a beta stage.

Main news of Cupt v2 comparing to Cupt v1 are grouped here.

Notable changes since 2.0.0~alpha3:

• New configurable score calculation system in the native resolver (new option group 'cupt::resolver::tune-score::*')
• Added an ability to specify additional package expressions and restart the solving process in the action preview prompt (new choice 'a')
• When no solutions were found, throw an error with a solution tree(s) to show why.
  Example:
  

  $ cupt-experimental -s -R remove kdepimlibs-kio-plugins kdebase-workspace+
  Building the package cache...
  Initializing package resolver and worker...
  Scheduling requested actions...
  Resolving possible unmet dependencies...
  E: unable to resolve dependencies, because of:
  plasma-widgets-workspace 4:4.4.5-8 depends on 'plasma-dataengines-workspace (= 4:4.4.5-8)' -> no solutions
    plasma-dataengines-workspace 4:4.4.4-1 depends on 'kdepim-runtime' -> removed plasma-dataengines-workspace
      kdepim-runtime 4:4.4.3-1 depends on 'kdepimlibs-kio-plugins' -> removed kdepim-runtime
    plasma-desktop 4:4.4.5-8 depends on 'plasma-widgets-workspace (= 4:4.4.5-8)' -> installed plasma-widgets-workspace 4:4.4.5-8
      kdebase-workspace-bin 4:4.4.5-8 depends on 'plasma-desktop (= 4:4.4.5-8)   plasma-netbook (= 4:4.4.5-8)' -> installed plasma-desktop 4:4.4.5-8
        kdebase-workspace 4:4.4.5-8 depends on 'kdebase-workspace-bin (>= 4:4.4.5-8)' -> installed kdebase-workspace-bin 4:4.4.5-8
  plasma-dataengines-workspace 4:4.4.5-8 depends on 'kdepim-runtime' -> no solutions
    kdepim-runtime 4:4.4.3-1 depends on 'kdepimlibs-kio-plugins' -> removed kdepim-runtime
    plasma-widgets-workspace 4:4.4.5-8 depends on 'plasma-dataengines-workspace (= 4:4.4.5-8)' -> installed plasma-dataengines-workspace 4:4.4.5-8
      plasma-netbook 4:4.4.5-8 depends on 'plasma-widgets-workspace (= 4:4.4.5-8)' -> installed plasma-widgets-workspace 4:4.4.5-8
        kdebase-workspace-bin 4:4.4.5-8 depends on 'plasma-desktop (= 4:4.4.5-8)   plasma-netbook (= 4:4.4.5-8)' -> installed plasma-netbook 4:4.4.5-8
          kdebase-workspace 4:4.4.5-8 depends on 'kdebase-workspace-bin (>= 4:4.4.5-8)' -> installed kdebase-workspace-bin 4:4.4.5-8
  E: error performing command 'remove'
  

Full changelog is available in debian/changelog, as usual.

binary packages for i386, source package and README

Since the last post, few things did happen. Basically, it's still not the right time for Debian users to upgrade to Xfce 4.8. We eventually managed to upload the whole desktop part (except the xfce metapackage) to experimental and we did upload some of the goodies too. Licensing issues have been solved so the concerned packages have been uploaded, and we're right now waiting on the three packages sitting in NEW.

• garcon is really mandatory for Xfce 4.8 since it implements the menu library, used by xfce4-panel, xfdesktop and xfce4-appfinder;
• thunar-vfs is needed if you want to keep the goodies not yet ported to the new thunar gio-based API (right now that means squeeze, the archiver, not the distribution);
• tumbler is a replacement for thunar-thumbnailers, implementing a standard thumbnailing interface, so it's possible to skip it for now.

So you'll need to be a little more patient and kindly wait for our ftp-masters to process the (quite huge) NEW backlog. After that we'll need a bit more time in experimental to test upgrade cases, then we'll do an upload to unstable of the whole desktop part and the whole goodies. Upgrading to xfce4-panel 4.8 means *all* plugins need to be rebuilt too, so that means a huge upgrade and a quite large transition to handle for the release team, so we'll have to schedule the unstable upload with them in order not to break all their plans (yes, we try to be good Debian citizens) So please be patient, but you'll see Xfce 4.8 in unstable in a not too distant future. I'll put an update here when we'll need brave volunteers willing to break their systems by doing upgrade tests. [UPDATE]: garcon, thunar-vfs and tumbler were just accepted into experimental, thanks to our ftp-masters. Now we'll synchronize with release team and upload to unstable when possible.

There are a lot of different workflows to maintain Debian packages under a Version Control System. Some people prefer to only keep the debian directory, some the whole source. And in the latter category, some prefer the source tree to be patched with Debian changes, while others prefer to keep it unpatched and exclusively use debian/patches. It turns out the former and the latter don t work so well in one specific case that any package may hit some day ; and that day, you realize how wrong you were not tracking the entire patched source. That happened to me recently, though instead of actually going forward and switch to tracking the patched source, I cheated and simply ditched the patch, because I didn t strictly need it. In all fairness, this is not only a case against not tracking patched source, but also a case of the 3.0 (quilt) source format being cumbersome. In my specific case, I cherry picked an upstream patch modifying and adding some test cases related to a cherry-picked fix. One of the added test cases was a UTF-16 file. UTF-16 files can t be diff ed nor patch ed except in the git patch format, but quilt doesn t use nor support that. The solution around this limitation of 3.0 (quilt) format is to include the plain modified file in the Debian tarball, and add its path to debian/source/include-binaries. On the VCS side of things, it means you have to modify the file in the source directory, and fill debian/source/include-binaries accordingly. Wait. Modify the file in the source directory ? But the other files aren t ! They re tracked by patches ! So here you are, with all of your modifications exclusively in debian/patches except one.