Search Results: "cas"

15 March 2008

Daniel Leidert: Diploma exams are calling: Please read if you want to NMU my packages

Because my diploma exams are getting nearer, I have to reduce my contribution to the Debian project for the next two months (up to mid/end of May). There is fortunately currently not much to do for me and also no need to NMU my packages. But please read the following notes, if you (still) think there is a reason for a NMU: GCC 4.3 transition Done. All related packages have been fixed. My sponsor just needs to upload psicode to fix the last outstanding bug. PS: Also the build-twice-in-a-row release goal will be reached by the upload of the apbs update by my sponsor. gfortran transition Almost done. mpqc already reached the buildds. ghemical has been uploaded, but waits for mopac7 and libghemical, which are in NEW because of the new library names. apbs and psicode already have been transitioned. Other bugs Ok, I’ve closed almost all relevant bugs in my packages. There are a few outstanding bugs that should be examined for Lenny and can be fixed in NMUs - preferable via delayed NMU queue and an information to the debichem group:
#420795: chemical-mime-data: Unknown media type in type ‘chemical/x-*’
Upstream bug tracker for shared-mime-info contains some more information, how to deal with this. Patches/ideas welcome.
#438694: gabedit: Crashes when loading any XYZ format file
Looks tricky. Maybe an OpenGL issue related to some video card drivers. Not sure.
#442223: openbabel: some connect information lost when convert from pdb to txyz
Nothing examined yet to solve this bug.
#464867: extrema: conflicts with psi3 package
Hope, my team will cover this asap.
#465723: mopac7 — please do not use g2c.
There is currently a workaround using f2c to solve this bug. But MOPAC7 has been written in FORTRAN and we can use gfortran and drop f2c completely. See the report for more information. This is something I would like to see in Lenny.
For the xmlto package it was planned to add the dblatex toolchain for PDF/PS/DVI creation because passivetex will very probably never have a comeback in Debian and docbook-xsl/fop is not fully main and cannot create DVI output. In the case you want to help, feel free to add this feature by NMU to experimental (maybe with version 0.0.21~dblatexX.Y). A first patch is available in bug report #416622. New upstream releases It is possible that there will be a new upstream release for docbook-xsl in the near future. DO NOT consider uploading it by NMU if you did not test it! This upcoming release ships manpage stylesheets, that have been rewritten in large parts. So regressions can be expected. Fortunately Michael Smith and me agreed, that we should test it carefully, before the release is done. Unfortunately I will not have the time to do it. So if you consider uploading it, please get in contact with Michael (xmldoc) and offer your help testing it. He added (and I hope, many Debian packagers and packaging groups will like that) some kind of regressions tests. These tests build the manpages from several Debian packages: e.g. samba, apt, aptitude, git, fglrx and some more. There are further some new supported features, that should be added to the manpage example shipped with the Debian package. I also planned to split the source package (atm, docbook-xsl and docbook-xsl-doc tarballs are merged together for Debian) as soon as docbook-xsl-ns is packaged - which I wanted to do with the next upstream release. So consider all of the above notes if you plan an NMU to upload a new upstream release and in question, mail me and wait for my answer (which will need some days). In all other cases, new upstream releases should be easier to handle. ITPs All my ITPs are delayed. However if you plan to still upload one of these packages, you should consider the following notes:
docbook-xsl-ns
See the above note about docbook-xsl and the source package split.
html-xml-utils
Already in a good shape, but I sent upstream some patches to improve the manpages. Version 4.6 of the html-xml-utils should contain these patches and this version should be uploaded into Debian. With this version, Bert Bos will probably also decide, which prefix will be used for the binaries (they have very generic names atm; the prefix will probably be hx- or hxu-). Waiting for this releaes therefor is IMHO a good choice.
DocBook 5
I already found a problem that need to be addressed in the package: Where to install its catalog? You will see, that there is already a catalog file in /usr/share/xml/docbook/schema/dtd/ shipped by the docbook-xml. Now I’m not sure, what to do here. Upstream ships one catalog file for all supported schemas (RNG, DTD, W3C schema and schematron), so maybe the catalog file can go into /usr/share/xml/docbook/schema/. Really not sure atm. The answer to this question might affect the Debian XML policy and should be made carefully.
QA work/fixes Several lintian warnings have already been fixed in the SVN repositories used for my packages but have not yet been uploaded. I really only plan to reduce my work during the preparation and the exams. So whatever you do, please try to make it easy for me to continue my packaging work after the exams :)

John Goerzen: At long last, software.complete.org migrated to Redmine

I've been writing a bit about Trac and Redmine lately. For approximately the 1/3 of the publically-available software that I've written, I maintain a Trac site for it at software.complete.org. This 1/3 is generally the third that has the most interest from others, and there's a bug tracker, wiki, download area, etc.

Trac is nice, and much nicer than one of the *Forge systems for a setup of this scale. But it has long bugged me that Trac has no integration between projects. To see what open bugs are out there on my software, I have to check -- yes -- 17 individual bug trackers.

To keep track on the wikis to make sure that nobody is adding spam, I have to subscribe to 17 different RSS feeds.

It took me some time just to hack up a way so I didn't have to have 17 different accounts to log in to...

So, mainly, my use case for Trac isn't what it was intended for.

Enter Redmine. It's similar in concept to Trac -- a lightweight project management system. But unlike Trac, Redmine allows you to have separate projects, but still manage them all as one if you please.

Redmine didn't have Git support in its latest release, but there was a patch in Redmine's BTS for it. I discussed why it wasn't being applied with Redmine's author, and then went in and fixed it up myself. (I used Git to make a branch off the Redmine SVN repo -- very slick.) Unlike Trac's Git support, Redmine's is *fast*. I tested it against a clone of the Linux kernel repo on my local machine.

There are a few things about Redmine I don't like, but I have learned that they mainly have to do with Ruby on Rails. As someone pointed out on Planet Debian lately (sorry, can't find the link), the very nature of Rails makes it almost impossible for OS developers like Debian to include Rails apps in the distribution.

Not only that, but it seems like Rails assumes that even if you are just going to *use* an app, you know how to *write* one. For instance, this is pretty much the extent of documentation on how to set up a Rails app to be able to send out mail:


# See Rails::Configuration for more options


And of course, googling that turns up nothing useful.

Redmine is a rails app, so it cannot escape some of this. It seems to be a solid piece of work, but Rails seems to make things unnecessarily complex. That, and I've found some bugs in the underlying Rails infrastructure (like activerecord not quoting the schema name when talking to PostgreSQL) that make me nervous about the stack.

But the site is up and running well now, so I'm happy, and am planning to keep working with Redmine for quite some time.

David Moreno Garza: Places I've lived in

Recently, chatting with some folks on the TextMotion IRC channel, I started thinking on the places I ve lived my whole life. From the bottom of my mind, this is a rough list: Such is life :)

Daniel Burrows: Full upgrade and conflicts

Erich Schubert wonders how to improve the handling of conflicts in package managers, particularly in aptitude full-upgrade and apt-get dist-upgrade. From the point of view of the package manager, conflicts are a bit tricky to deal with. The problem is that a conflict only really tells you not to install two packages at once; it doesn't tell you which package should end up on the system by default. Worse, aptitude has two approaches to this:
  • When a package is marked for installation in the visual interface or listed on the command-line, then if Aptitude::Auto-Install is enabled, aptitude will automatically resolve conflicts in favor of that package. The same applies to packages that are upgraded by pressing U or by full-upgrade.
  • When aptitude's dependency resolver encounters a conflict, it considers both resolutions to the conflict to be equally valid. If there are no other reasons to choose one package over the other, it will be unpredictable which one gets removed first, and even when there are reasons to choose, the user may not understand what they are.
I don't think it's possible to always make upgrades predictable. But I think that even just making Auto-Install stick to installing packages and not removing conflicts would be a plus. Installing obvious dependencies up-front is good because it means less work for the resolver and a more predictable starting point. Many trivial dependency problems can even be completely solved this way. But removing conflicts is a lot trickier and should probably kick the problem into the full resolver. Unfortunately, the code enabled by Auto-Install is all deep in the guts of libapt. I've tried to avoid duplicating this code so far, but it does seem like I periodically run into cases where it doesn't do exactly what I need, so maybe I'll have to eventually. :-(

Daniel Burrows: HOWTO convert your Blogger/BlogSpot blog to ikiwiki

Until recently, my blog was hosted on Google's free Blogger service. When I decided to move to my own server and ikiwiki, I didn't want to lose all my old posts. But exporting your blog from Blogger is a bit tricky. In fact, the Blogger page that provides instructions on how to do so starts off by saying:
Blogger does not have an export or download function.
Regardless of what they say, you can cajole Blogger into exporting text for use in other blog systems. Instructions for moving from Blogger to various pieces of software are available out there on the Web, but to switch to ikiwiki I had to tweak them a bit. Here's the procedure I used:
  1. Extract your information from Blogger's clutches and add minimal IkiWiki tags. As in the official Blogger instructions, change your template temporarily. However, instead of using the page template they suggest, use the following template, which you can find as a text file here. 
    <Blogger>
[[meta author="<$BlogItemAuthor$>"]]
[[meta date="<$BlogItemDateTime$>"]]
[[meta title="<$BlogItemSubject$>"]]
<$BlogItemBody$>
</Blogger>
<BlogItemComments>
Comment by <$BlogCommentAuthor$> at <$BlogCommentDateTime$>:
<$BlogCommentBody$>
</BlogItemComments>
    I recommend saving the file that's produced by this step even after you process it in the next step, in case you discover that you made a mistake.
  2. Split the extracted file into pieces. Exporting your blog using the template above will get you all your blog posts in reasonable Markdown format, with all dates and titles preserved. But they'll all be scrunched into one file. Blogspot also won't interpret paragraph breaks into blank lines, and it inserts strange empty <div> tags all over. So the next step is to split this file into pieces and clean up the HTML. Since I had over a hundred posts, I wrote a Python script to do this postprocessing for me. You can find it here. You can run it like this to output each blog post as a separate file in the current directory: 
    /path/to/fixup-blogspot-export input-file
    This script makes a few assumptions about its input file:
    1. It assumes that the text [[meta author="NAME']] does not appear at the start of a line anywhere except the first line of a blog post. If you write about MarkDown syntax on your blog, you will run into problems.
    2. It makes a similar assumption about Ikiwiki's date meta.
    3. It assumes that line breaks are expressed using a variant of <br/>, and that <br/> never appears in the text of your blog.
    4. It assumes that the text Comment by does not appear at the start of a line in any post.
    5. It assumes, in general, that no Markdown or Ikiwiki commands appear in the blog text. If any do, you'll have to manually escape them, either before or after running the conversion script.
    All in all, it's probably a good idea to at least skim the output once.
  3. Create a top-level Ikiwiki page for your blog. The Ikiwiki site has instructions on doing this that are probably better than I could write. The most important thing is to use the created-after tag to limit your RSS feeds, so you don't spew new posts all over the planet (pun intended). For instance: 
     [[inline pages="./blog/entry/*"
          feedpages="created_after(last_page_of_the_old_blog)"]]

Daniel Burrows: aptitude 0.4.10 released

I've just released version 0.4.10 of aptitude, a terminal and command-line package management tool for Debian. This release has many user-visible changes (see the changelog below). It also fixes an annoying and much-reported segfault. The Debian packages of this version are built against the new version of cwidget, which is sitting in NEW, but if you're impatient you can compile it by hand by dropping the versioned dependency. The dependency is there to ensure that we don't get dependency skew across architectures (aptitude depending on libcwidget0 on some archs and libcwidget1 on others) and doesn't represent an actual build requirement of aptitude.
[12/15/2007] Version 0.4.10 Oscillating Reindeer
  • New features:
    • In command-line mode, if the resolver fails to produce a solution for whatever reason, then instead of aborting the program entirely aptitude will now display a prompt at which you can fix the dependency problems by hand. Enter r at this prompt to try to automatically fix dependencies again.
    • safe-upgrade will now install new packages to fulfill dependences (but it will never remove packages, downgrade packages, or install a version that's not the default). The option --no-new-installs will disable this behavior.
    • Updates and commands that install, remove, or upgrade packages will now display a brief summary of what changed. For instance: 
      There are now 64 updates [+10], 3 new [+1].
      Unfortunately, this change requires reading the cache after an update is complete. Passing -q will disable this behavior, but also make the update progress bar less attractive. More work on resolving this tension between features and performance remains to be done.
    • Add an option --allow-untrusted to override trust warnings. (Closes: bug #452201, bug #452541)
    • Recommended packages are now hidden if quiet mode is enabled. (Closes: bug #452202)
    • The options Aptitude::ProblemResolver::Trace-File and Aptitude::ProblemResolver::Trace-Directory allow you to generate a minimal cut of the cache that allows a problem resolver run to be reproduced. The eventual aim is both to simplify bug reporting and to generate a corpus of automatic test cases for the resolver (although more work needs to be done to accomplish the latter).
    • When run in command-line mode, instead of displaying many separate and sometimes duplicative groups of packages (e.g.: installed, auto-installed, auto-installed in a light cream sauce, etc), aptitude displays packages in a few exclusive categories and uses tags (like the existing purge tag) to provide more state information. For instance: 
      $ aptitude -s install wesnoth
The following NEW packages will be installed:
  wesnoth wesnoth-data a  wesnoth-music a 
$ aptitude -s remove freeciv-data
    (... dependency resolution ...)
The following packages will be REMOVED:
  freeciv-client-gtk a  freeciv-data freeciv-server a  ggzcore-bin u 
  libggz-gtk1 u  libggz2 u  libggzcore9 u  libggzdmod6 u  libggzmod4 u
      Here a indicates that a package was automatically installed or removed, and u indicates that a package is being removed because it is unused. Hopefully this will be less confusing than the old format.
  • Bug fixes:
    • Crashes and serious errors:
      • Track down and fix a SEGV triggered on the first action after a cache reload (sometimes). There are multiple bugs where this might have been the root cause, but it's confirmed that it was the cause of at least bug #454695, bug #454700, bug #455349, and bug #453362. Bug bug #455865 is almost certainly the same issue, and bug bug #352278 may be another manifestation of it.
      • If StepLimit is set to 0, refuse to solve dependencies instead of going into an infinite loop. (Closes: bug #451311)
    • Minor bugs:
      • Return a failing exit code after jumping from the command-line to visual mode if the last install run failed. (Closes: bug #282408)
      • Return a failing exit code from aptitude update if any download fails. (Closes: bug #233129)
    • Cosmetic and UI bugs:
      • In addition to Enter, Space will now activate checkboxes and radio buttons. (Closes: bug #451765)
      • Abort the program if we get EOF at the resolver prompt instead of claiming the resolver failed.
      • Command-line searches will now only print each result once. (Closes: bug #450798)
    • Documentation bugs:
      • The options menu documentation now minimally describes the new configuration interface.
      • The documentation of the configuration file options has been placed back in alphabetic order after apparently suffering bitrot over the years.
      • Corrected the documented default of Parse-Description-Bullets to match reality.
      • The manpages for aptitude-create-state-bundle and aptitude-run-state-bundle are now generated using DocBook, which should produce higher-quality and more consistent typesetting, as well as making the manpages more maintainable and allowing translators to easily produce localized versions of the manpages.
  • Internal changes:
    • Removed some unit tests that really tested cwidget.
  • Translation updates:
    • French (Christian Perrier)

Daniel Burrows: I hate it when I'm right this way

A few months ago, I registered my first domain name ever. When you want to register a domain, the first step is generally to enter the domain you are interested in into a box; the registrar will then check to see if the domain is not registered yet, and allow you to register it if it's available. When I saw this, I thought to myself: huh, I bet that if I were a registrar and I were evil, I would take domain names that people ask about but don't register and register them myself. So I used the normal DNS lookup process to check hostnames until I came up with one I liked, on the theory that they can't possibly be registering every single lookup failure. I really hoped that I was just being excessively paranoid, so it makes me sad to learn that apparently my cynicism in this particular case was entirely well-founded. Someday I want to believe bad things about humanity and have them turn out to be false. :-(

Daniel Burrows: The power of self-delusion

Groklaw has a link up to an interesting interview regarding behavioral economics. I haven't listened to the podcast, but the posted text is quite interesting. This line, in particular, struck a chord with me:
Feeling that your work is useful, even if you know it's an illusion, has motivational power with respect to that work.
This resonates with some thoughts I've been turning over in my head lately. Back when I was in college, I thought my work in Debian was useful and I was really excited to work on it. I'd sit around thinking up new ways to improve the system and spend all my spare time hacking code to implement my ideas. Then I graduated, and went into the real world, and got a job, and suddenly I discovered that working on Debian was not so much useful as it was worthless self-indulgence with no value to anyone but a small and marginal group of individuals. This sent me into a funk for a good year or so, during which time I released a few bugfix uploads for aptitude but didn't do much else free-software-related. I spent my time on the bus reading science fiction novels and computer science textbooks. However, at some point last year I realized a couple things:
  1. In the grand scheme of things, the work I do for pay is no more important than the work I do for free. It might be more important to the people who pay for it, but to most of the world I simply don't matter no matter what hat I'm wearing, and I need to learn to live with it.
  2. At the end of your life, you're dead and no-one asks you whether you made yourself miserable enough by doing useful stuff, so you might as well do things you enjoy instead.
  3. The only practical effect of my delusions regarding Debian was that I spent my spare time hacking code and enjoying it, instead of playing video games and feeling like a loser.
  4. If there's any chance that I might ever have a kid, I certainly want to write free software now, while I don't have one. Based on observing my coworkers who have kids, it's pretty much impossible to be both a free software hacker and a parent: after the paid job and the kid, there isn't much time left over for writing code.
So, I decided to try deliberately believing a false thing: namely that my Debian work is valuable and worthwhile. And hey, it worked! I still know that what I'm doing is worthless, but I can convince myself otherwise for stretches of time, and I have enough fun while I'm working on the project that I consider it worth a small amount of unreality. It sure beats the heck out of computer games (which I still spend a distressingly large amount of time on). The doublethink aspect of it creeps me out, but I can't argue with the results. The one problem is that this state of deluded motivation seems to be a bit fragile and is vulnerable to being popped by rude shocks. In December, I found myself mentally composing a letter in which I resigned from Debian to go spend my free time on stuff that was more gratifying, or at least where the expectations and (more importantly) level of abuse were commensurate with the pay and hours. As usual, I had enough sense to not follow through, and everything seemed less dire in the morning, but it was still weeks before I could bring myself to begin to think about spending my free time working on Debian. Presumably the only way to avoid this is to find something to do in my spare time that I enjoy and that is actually meaningful to the world. But since I don't know of any activity that meets these criteria, I'll keep my self-delusion for the time being, thank you very much. At least I know I'm doing it -- I suspect that most people don't.

14 March 2008

Michal &#268;iha&#345;: Nvidia is bad, Intel is good?

Intel is always seen as good guy, who is writing open source drivers, releasing at least some specifications for hardware. Unfortunately it is not always the case. If you want to use their new embedded solution - Menlow CPU and Poulsbo chipset, they provide you lot of crap. Basically what you get is a zip file containing several Microsoft Word documents, badly formatted text files (end of lines at each 80 chars), PDFs and some zip and tar archives. If you look to one of these archives, you will get binary graphical installer, which will install license, uninstallator and yet another set of tarballs. These tarballs finally contain binary and source packages you need to make graphics work on this platform. Maybe somebody did this to practise various ways of compressing and distributing things, but it is really amazing how many times you need to decompress several archives to actually get to the things you want. Unfortunately at the end you will find out that libgl1-mesa-dri-psb binary (DRI driver for graphics) has no sources and Intel is not willing to give them to you. Bad luck if you have slightly different distribution than one of these which are supported (FC6, Midinux-build9, ubuntu-gutsy, ubuntu-hardy) and the provided binary simply crashes.

13 March 2008

Wouter Verhelst: Real Men don't take backups

They figure out how the filesystem works, and start hacking. Heh. Actually, I did the same thing once myself. The difference between Carlo and myself was that in my case, only a few files that were not in backup had been deleted, rather than 3G worth of data; hence, using a hex editor, a cursory glance at the Linux source code, and a few hours to kill was all that was needed to recover. (via) (With apologies to Linus, and any Real Women reading this)

MJ Ray: SPI: Forgive me world, for I have sinned

Before I start on this, note that SPI's next board meeting is next Wednesday at 1900 UTC on irc.oftc.net #spi and logs should appear here and on spi-general less than a day after. I expect the agenda will appear here. Last Tuesday morning, someone asked about SPI holding copyrights. On Tuesday afternoon, I answered with the policy and the only practice example I found. SPI's policy is fine. SPI's practice seemed unclear. On Wednesday morning, I clarified that reply to one board member and made a suggestion to one who seemed to want to ask a lawyer. On Sunday afternoon, after a staggering number of posts which weren't really getting anywhere, I tried to drag it back to the practice example a bit rudely, but that's the level the discussion had fallen to by then. It didn't go down well. It seems rude is fine from other people, but not me. Damn baggage. There was a sequence of posts telling me that SPI members weren't even allowed to ask about this task. I replied to one on Tuesday morning and took the useful bits off to debian vote. Yesterday, I lost my cool, really, and posted too much, replying to all the stupid posts suggesting that you can only ask if you wear the right hat, and one or two particularly ugly personal attacks. Sorry about that. Meanwhile, over on IRC, a draft solution to the problem has been developed/found. So all's well in the end. I give big thanks to Jimmy, Sam and Lucas in particular and a big apology for responding to the mailing list abuse.

12 March 2008

Neil Williams: Serial over USB, broken laptops and screen

Well, after many failed attempts, here I am on my problematic HP laptop with a USB key mounted, a balloon3 board booted under an Emdebian root filesystem and visible over USB-to-serial using /dev/ttyUSB0 via screen.
Thanks to Daniel's tip about screen /dev/ttyUSB0 115200, my USB to Serial converter (Maplins with a Prolific PL2303 chipset) is working on my problematic HP laptop.
The proviso is that I have to reboot to enable all this stuff - allow the laptop to hibernate and all this USB stuff just disappears. :-(
The only remaining problem is the wireless - I haven't decided yet whether to patch the current stock Debian kernel (I've had enough problems without getting into more kernel issues) - I may simply buy a replacement external wireless unit or just not use wireless until the b43 driver is capable of working with the Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02).
The magic runes for enabling USB are to add some more options to the grub boot list (on the 'kernel' line):


 noapic nolapic noirqfixup

minicom still doesn't like serial over USB (on this laptop, it adds an extra line feed and then refuses to pass on any keyboard entry to the device in a similar manner to the powerpc laptop) but screen works nicely. Thanks Daniel.
With noirqfixup added, I can also plug in other USB things like a USB mouse and actually see them work. This is all good news because apart from adding these mysterious runes to Grub, this is a completely standard Debian box running Sid and with no particular configuration changes or tweaks in the system setup.
This means that I can now get on with uploading the emdebian-tools package split to Debian unstable, adapting the Emdebian root filesystem for balloon3 to support USB networking by default and suggesting screen as an alternative to minicom in the control information for the new emdebian-rootfs package. (The package split is now in Emdebian SVN - main trunk - if you are interested.) I'm also downgrading my old G4 iBook to running Lenny instead of sid and it will now stay running Lenny as Debian stable when Lenny is released. It just makes it easier to not have to keep downloading massive updates on the brief occasions that I now use the iBook.
Now if I can just work out why hibernation forgets 'noirqfixup', I'll have a usable HP laptop....
Not bad for a machine that I once considered as a complete non-starter.

Filip Van Raemdonck: Debian firewire support

Christian, you forgot to mention the Linux kernel, where a member of the kernel team deliberately broke hardware support.
Thanks to Holger for these links, he has listed several more. I disagree with the suggestion that shipping the old firewire stack in the linux-extra-modules package is sufficient workaround; unless this is not prohibiting it from being included in the installer to support ethernet over firewire? (though in such case it will certainly have implications due to the fact that this package should be pulled in when the installer used eth1394)

So Adrian, you too may want to reconsider if Debian really does have less compatibility regressions than other distributions.

Filip Van Raemdonck: Debian firewire support

Christian, you forgot to mention the Linux kernel, where a member of the kernel team deliberately broke hardware support.
Thanks to Holger for these links, he has listed several more. I disagree with the suggestion that shipping the old firewire stack in the linux-extra-modules package is sufficient workaround; unless this is not prohibiting it from being included in the installer to support ethernet over firewire? (though in such case it will certainly have implications due to the fact that this package should be pulled in when the installer used eth1394)

So Adrian, you too may want to reconsider if Debian really does have less compatibility regressions than other distributions.

10 March 2008

Christian Perrier: A good way for Debian to fail in the long term...

...is continuing to neglect our key packages. We have ridiculous numbers of maintainers on some of them. Mentioning dpkg right now is probably not appropriate but there have been not more than 4 people active on it (including Ian Jackson despite the recent events). Just look at its bugs database. APT is maintained by Michael Vogt and Otavio Salvador, both involved in (too?) many other parts of the distribution. Just look at its bugs database. aptitude is maintained by Daniel Burrows alone (my help for l10n doesn't really count). Just look at its bugs database. Despite the tremendous work of the XSF, X.Org bugs decrease quite slowly and I don't doubt that in case one of the current 3-4 people who are very hard-working on it are swaped by real life, we'd be in trouble. I could find dozens of these, probably. In the same time, we're still seeing tons of ITPs for different pieces of junk^W software which I really wonder about us needing them. We should maybe reconsider the implicit encouragements we are giving to new applicants to maintain "their" package. We'd probably better encourage them to *adopt* an existing package and rank these by order of priority or popcon score. Stop having that damn archive growing and expand the outbounds of the Debian galaxy. We'd better take care of the inside black hole.

Randall Donald: New Farm Website

In an effort to work on our marketing, I've been working on our alpaca farm website Alpacas of the Coast. It could do with a bit more descriptive content but it is coming along. With a herd of 10 animals with 6 crias coming this spring my wife and I want to put our business into the next gear.

Filip Van Raemdonck: Read between the lines

Recently I've been debugging a SQL Server 2005 replication setup, where the "Distribution clean up" job for the distributor database was failing. The error message in the agent history was:
Executed as user: <sqlagent_serviceuser>. Could not remove directory <UNC_path_to_snapshot_directory>.
Check the security context of xp_cmdshell and close other processes that may be accessing the directory.
[SQLSTATE 42000] (Error 20015).  The step failed.

The <sqlagent_serviceuser> was the Windows user that the SQL Server Agent service was running under, while the <UNC_path_to_snapshot_directory> was the network path to the directory where snapshots where created.

Looking around on some discussion forums, I found the same message reported several times but without any real solution; at least no solution that would work when I tried to apply it to this particular setup. Most answers to the problem focused on the xp_cmdshell procedure mentioned in the error, and how it would require certain configuration at the server end.

However, one answer on the MSDN forums did give a useful clue it pointed to the SQL Books Online article about Securing the Snapshot Folder (which I should've read right away, really). In a note, this page reads:
If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. [...]

It's the SQL Server service account reference which is essential: even though the SQL Agent service account may be the one mentioned in the error message, the actual account that is used to try and delete the snapshot directories is the SQL Server service account instead. Giving that service account the necessary access rights fixed the problem; as in the Task Scheduler case, accurate error reporting on Microsoft's side might go a long way towards people disliking their software less.

Filip Van Raemdonck: Read between the lines

Recently I've been debugging a SQL Server 2005 replication setup, where the "Distribution clean up" job for the distributor database was failing. The error message in the agent history was:
Executed as user: <sqlagent_serviceuser>. Could not remove directory <UNC_path_to_snapshot_directory>.
Check the security context of xp_cmdshell and close other processes that may be accessing the directory.
[SQLSTATE 42000] (Error 20015).  The step failed.

The <sqlagent_serviceuser> was the Windows user that the SQL Server Agent service was running under, while the <UNC_path_to_snapshot_directory> was the network path to the directory where snapshots where created.

Looking around on some discussion forums, I found the same message reported several times but without any real solution; at least no solution that would work when I tried to apply it to this particular setup. Most answers to the problem focused on the xp_cmdshell procedure mentioned in the error, and how it would require certain configuration at the server end.

However, one answer on the MSDN forums did give a useful clue it pointed to the SQL Books Online article about Securing the Snapshot Folder (which I should've read right away, really). In a note, this page reads:
If a publication is dropped, replication attempts to remove the snapshot folder under the security context of the SQL Server service account. [...]

It's the SQL Server service account reference which is essential: even though the SQL Agent service account may be the one mentioned in the error message, the actual account that is used to try and delete the snapshot directories is the SQL Server service account instead. Giving that service account the necessary access rights fixed the problem; as in the Task Scheduler case, accurate error reporting on Microsoft's side might go a long way towards people disliking their software less.

Martin F. Krafft: Customer support farce

There are plenty of reasons why a company might provide a web form as the only means for customers to get in touch with their customer support department: for instance, the web form compels the customer to send along important information with the first request, therefore saving time (and money) for the customer service department. Even though I hate web forms, I sometimes do fill them in and usually get an answer back; it works. Every once in a while, however, I ll encounter a form designed by people without any form of understanding of the role of a customer for any business (it s the most important asset ). Such is the case when the form limits the message to a certain number of characters. Obviously, no customer service agent wants to read novel-length prose when fielding incoming requests, but a few hundred characters may also not be enough to get the point across. Star Alliance, for instance, expects you to get your point across in 300 characters. I find it hard to imagine that people write lengthy texts into web forms, unless they have more information to get across. I also see no technical reason for limiting the length of the text which can be submitted. The only logical explanation I have is that those companies give a flying food about customers and would much rather not have them contact the support department. NP: The Flower Kings: Back in the World of Adventures

9 March 2008

William Pitcock: Resignation as atheme.org project lead

In case you didn’t know, I’ve decided to resign as atheme project lead. This is for a few reasons: However, just because I’m resigning as project lead doesn’t mean that I will stop working on projects I care about inside atheme, like audacious, mowgli, and mcs. These projects are critical components of the modern FOSS desktop, and I intend to continue working on them. This is purely an administrative change, so that any mistakes or stupidity I do have no effect on atheme.org’s overall health. I hope to see many other Atheme members step up and try to become project lead. Under the right leadership, atheme’s projects could become a much more notable platform in FOSS development within a short amount of time. Update: Due to popular demand, I have changed my mind. I’m no longer resigning as project lead of atheme.

Next.

Previous.