A press release from Telecom just landed in my inbox: TELECOM TO SEPARATE WHOLESALE AND RETAIL OPERATIONS.
From what I can make out, Telecom is announcing that they’re going to ‘voluntarily’ do what the Government’s proposed legislation would force them to do anyway. That is, separate the accounting and business processes of their wholesale and retail departments. It’s not a full structural separation (which would involve different shareholders and upper management teams).
It’s still a good thing, but the way the press release is worded makes me think Telecom is trying to confuse the public into thinking that a full structural separation has occured.
Comments Off
I had a bit of a surprise today when I sat down to read this weeks DWN and found my own name and a link to and old post about some Lightweight Debian Archive Scripts that I had written in October last year staring back at me from the second sentence!
As chance would have it, just last week I updated these scripts to use reprepro, as suggested in many of the comments that I received after writing the last post. I hadn’t got around to making the new scripts public yet, so I guess the link from DWN is a sign of sorts!
My main motivation for updating the scripts to use reprepro was to give myself the ability to have a testing, and stable archive as recently we’ve been dealing with .debs manually for testing as we didn’t want to put them into the archive for fear of prematurely updating the production hosts with untested code. I’d heard that reprepro had some nice support for moving packages between local repositories which sounded exactly like what I wanted.
Reprepro was indeed fairly easy to setup and install. I backported reprepro 0.9.1 and installed it alongside my existing sbuild setup as documented in the original post.
The changes to the scripts were fairly minimal, although again, they assume some things for my environment, and its likely that they’ll need some modification before being useful to you:
- process_packages assumes you have pairs of distributions named like ‘foo’ and ‘foo-testing’. Every package picked up from incoming/foo is automatically added into foo-testing after it is successfully built
- add-packages is mostly redundant, used only to add packages manually if the automatic insertion fails because reprepro has got itself confused
You can grab the updated scripts and my reprepro configuration from:
The new setup is great and I’m very happy with reprepro and the new archive. The only thing I haven’t had time to look into properly yet is how to pull specific packages from testing into stable, but not everything. Ideally I would be able to run a command like
reprepro <stable-dist> pull <pkgname>
If I could get that working then it would be awesome.
Over the past few weeks I’ve been working on extending the dbconfig-common packages to support the SQLite database format. My primary motivation for this is so that I can start using dbconfig-common to manage the database(s) for the PHPwiki packages which currently only support SQLite out of the box.
The main changes that were required were to separate out the debconf questions that are only relevant for remote and authenticated database types. These changes were committed yesterday. I plan to make the remaining changes required to bring the SQLite support up to scratch over the next few days, so hopefully dbconfig-common 1.8.18 with SQLite support will be uploaded before too long.
NM Application
In other news, Alexander Wirt finished off my NM Report, so now I’m waiting for the front desk to review it and send me on to the DAM. It’s great to be making progress and a big thank you to Alexander for taking me through the process, testing my knowledge and sponsoring my packages.
Comments Off
I think the current brouhaha surrounding PDF functionality in Office 2007 is an excellent object lesson in why software patents shouldn’t be allowed anywhere near an Open Standard (and software in general!). I’m not sure if a patent is the tool of choice that Adobe is wielding in this particular example, but even if it’s not Patent’s present a large risk to Open Standards and should be resisted.
It’s the same as the distinction between a Shared Source program and Open Source or Free Software. You may have the source code for a shared source program and be able to see how it is implemented and how it operates, but there are restrictions preventing you from doing anything with that information. Likewise a standard shouldn’t be called Open simply because you have details on how it is implemented (although that is undoubtably a critical part of openness). An Open Standard should be one which is openly specified and completely free of any other encumberances (such as patents).
Unfortunately I don’t see any of the standards bodies making this a priority. My understanding of the IETF RFC process is that you have to file a statement stating any IP claims but you’re not prevented from standardising somethign that you hold a patent on. W3C and the IEEE seem slightly less prone to this problem as they tend to have committee oriented standards process that require more interaction, but I’m still not aware of any direct efforts to prevent parts of the resulting standard from becoming patent encumbered.
If the lack of truly Open Standards can bite Microsoft it can bit any of us. It’s not an issue we should be ignoring.
