Search Results: "reg"

16 March 2007

Clint Adams: When a man can save his soul

Seeya later, aggregator
After a while, OPML file

Eddy Petrișor: sleep broken, again; thanks to xorg? gnome-core?

Today is the second day in which I find that my laptop does not resume properly from sleep and I start to wonder why. None of he old problems, blank screen, no reponse...

This time it just looses the GNOME session. I saw two segfaults on the console, on resume: one from iceweasel and one from another app. Then gdm comes up.

I think is xorg's fault or gnome-core. Why? Well, it didn't happened 4
days ago and I have these in the dpkg.log (grepped for upgrades only):

2007-03-12 00:19:04 upgrade xorg 1:7.1.0-13 1:7.1.0-15
2007-03-12 00:19:04 upgrade xvnc4viewer 4.1.1+X4.3.0-20 4.1.1+X4.3.0-21
2007-03-13 03:10:34 upgrade libeel2-data 2.14.3-3 2.14.3-4
2007-03-13 03:10:35 upgrade libnautilus-burn3 2.14.3-8 2.14.3-8+b1
2007-03-13 03:10:35 upgrade libnautilus-extension1 2.14.3-9 2.14.3-11+b1
2007-03-13 03:10:36 upgrade nautilus 2.14.3-9 2.14.3-11+b1
2007-03-13 03:10:37 upgrade nautilus-data 2.14.3-9 2.14.3-11
2007-03-13 03:10:51 upgrade nautilus-cd-burner 2.14.3-8 2.14.3-8+b1
2007-03-13 03:11:00 upgrade gnome-mount 0.5-2 0.5-3
2007-03-13 03:11:24 upgrade libxine1 1.1.2+dfsg-2 1.1.2+dfsg-3
2007-03-13 03:11:25 upgrade lintian 1.23.27 1.23.28
2007-03-13 03:11:26 upgrade unionfs-tools 1.4+debian-3 1.4+debian-4
2007-03-14 09:46:32 upgrade foomatic-filters 3.0.2-20061031-1.1 3.0.2-20061031-1.2
2007-03-14 09:46:32 upgrade libntfs-3g0 1:0.0.0+20061031-6 1:0.0.0+20061031-6+b1
2007-03-14 09:46:33 upgrade ntfs-3g 1:0.0.0+20061031-6 1:0.0.0+20061031-6+b1
2007-03-14 09:46:33 upgrade ekiga 2.0.3-4 2.0.3-5
2007-03-14 09:46:48 upgrade gnome-desktop-environment 1:2.14.3.5 1:2.14.3.6
2007-03-14 09:46:48 upgrade gnome-core 1:2.14.3.5 1:2.14.3.6
2007-03-14 09:46:48 upgrade gnomemeeting 2.0.3-4 2.0.3-5
2007-03-14 09:46:48 upgrade libgraphicsmagick1 1.1.7-12 1.1.7-13
2007-03-14 09:46:49 upgrade graphicsmagick 1.1.7-12 1.1.7-13
2007-03-14 09:46:50 upgrade obexfs 0.10-3 0.10-3+b1
2007-03-14 09:46:51 upgrade graphicsmagick-imagemagick-compat 1.1.7-12 1.1.7-13


I'll turn back time with snapshot.debian.net and see if I get back my resume ...


Notes:

Martin F. Krafft: Sony Ericsson customer support

I got myself a phone and wanted to give Sony Ericsson a chance to show that they are not like Nokia when it comes to customer feedback:
To: questions.ch@support.sonyericsson.com
From: sonyericsson.com@pobox.madduck.net
Product: W810i
Opinion: Hi, I am new owner of a W810i. I've encountered an issue
  with synchronising my address book, which contains many entries
  of companies. In those cases, first/last names are blank, only
  the company name field is filled. The W810i's phone book now
  displays these as "No name" at the top of the phonebook, which
  is not very useful at all.
  Is there any chance you could fix that in a firmware update?
  I suggest not making the name field mandatory, and to use other
  fields, like company, or primary phone number if the name is not
  specified.
  Thanks.
***
From: questions.ch@support.sonyericsson.com
To: sonyericsson.com@pobox.madduck.net
Subject: Case : 70876259
Dear Mr. Krafft,
Thank you for contacting Sony Ericsson on the World Wide Web.
If in your outlook the company names first and lanst name are
blank, the phone will register them as entry with no name. It is
not possible to get this changed with a software update.
"not possible", eh? I am really looking forward to open-source phones. This was most likely the last Sony Ericsson phone I ever bought. There's more:
To: questions.ch@support.sonyericsson.com
From: sonyericsson.com@pobox.madduck.net
Topic: Feedback on our sites
Opinion: I cannot submit this form without agreeing to subscribe
  to the eNewsletter and other marketing spam because of
  Javascript validation. Obviously, it's not hard to hack around
  this, but what is this??? Contact Sony Ericsson and get spammed,
  or don't contact Sony Ericsson at all???
***
From: questions.ch@support.sonyericsson.com
To: sonyericsson.com@pobox.madduck.net
Subject: Case : 70876261
Dear Mr.Krafft,
Thank you for contacting Sony Ericsson on the World Wide Web.
When you receive the Sony Ericsson confirmation e-mail, click on
"unsubscribe" and your personal data will be automatically
cancelled.
You can also unsubscribe by using the link contained in each
newsletter. Simply scroll down to the bottom of the newsletter,
there you will find information on how to unsubscribe. Please note
that you will need your login details to Fun & Downloads to be
able to unsubscribe.
So to recap: there is a check box on the contact form, next to the text:
I agree to receive copies of Sony Ericsson eNews or other offers, promotions or direct marketing from Sony Ericsson.
The Javascript, which is needed to submit the form, won't let you submit it without checking that box. Part of me wants to open the windows and scream "what the fuck were they thinking" and the other part really makes me now want to know. The easy workaround: get a Javascript console (e.g. via Firebug) and execute document.form.submit(). "Take back the Net" is really going to take a lot more effort than installing Free browers. NP: Dredg / Catch Without Arms Update: I replied to the second response, and promptly got an answer. Sony Ericsson really doesn't take long to get back to you, but then again it's hardly surprising if you look at the content:
To: questions.ch@support.sonyericsson.com
From: sonyericsson.com@pobox.madduck.net
Subject: Re: Case : 70876261
This seems like doing it the hard way. Why? Why not simply allow people
*not* to check the box if they do not want to receive newsletters?
***
From: questions.ch@support.sonyericsson.com
To: sonyericsson.com@pobox.madduck.net
Subject: Case : 70876261
Dear Mr. Kraft,
Thank you for contacting Sony Ericsson on the World Wide Web.
There is no reason why, it is as it is.
Thanks.

Andrew Pollock: [life] Child process on the way

Finally all the family have been informed, so I can write about it here... Sarah is is 10 weeks pregnant. The news came as a bit of a surprise, because Sarah had been feeling nauseous for a few weeks, and we'd immediately suspected pregnancy, but a total of seven tests all said she wasn't. It was only after comprehensive blood tests, that we got a phone call at 11pm on February 22 from the doctor confirming she was indeed pregnant. We went to see the high-risk ob/gyn (why the feel the need to mash their specialty together like that I do not know...) and it was a bit of a sobering experience. Sarah's cardiologist had previously said that he was okay with her having a pregnancy. Her aorta was larger than it should be, but not too big, so he advised us that if we wanted to have children, we should do it sooner rather than later. Now, we sat before the ob/gyn, and she was very unhappy that Sarah was pregnant, and said that given her history and whatnot that she wasn't happy at all with the situation. She'd brought forward the appointment by a week specifically to tell us this. So that really took the edge off things a bit, at least for me. Needless to say, we're continuing with the pregnancy (and this ob/gyn, at least for the time being). Sarah's been having a bit of an unpleasant time with the all-day sickness, which hopefully will pass by the second trimester. We've got an ultrasound from a couple of weeks ago here. Not much to see really. We've nicknamed the foetus "Squirt" until we know the gender and decide on a name.

Russell Coker: things to do for the environment

I got the idea for this from Ben Hutchings.A. Copy the list below to your own journal and

Bold the actions you are already taking
Underline the actions you plan to start taking
Italicize the actions that don't apply to youB. Add one (or more) suggested action(s) of your ownC. Leave a comment here, so that she can track the meme to your journal, and copy your suggested action(s) back to my master list.
  1. Replace standard incandescent light bulbs with compact fluorescent light bulbs
  2. Choose energy efficient appliances - I'm documenting the power consumption of my computers
  3. Wash clothes in cold(er) water - Colder than what? I suspect this is based on American machines that are controlled by mixer valves rather than using a thermostat.
  4. Turn the thermostat of your hot water tank down to 50 C (125 F) - this is a good safety measure anyway
  5. Install a programmable thermostat (or turn the heat down over night and when you're out of the house)
  6. Register with the [Canadian Marketing Association's] Do Not Contact Service to reduce the amount of junk mail delivered to your house. - Substitute MPS.
  7. Eat less meat (particularly feedlot beef) - For practical purposes I'm vegetarian, with occasional exceptions.
  8. Walk, bike, carpool or take public transit as often as possible - I'm writing this on the tram
  9. Make sure you know what can be recycled in your area, and try to recycle as much household waste as possible
  10. Compost using an outdoor compost bin or an indoor vermicomposter
  11. Clean or replace filters on your furnace and air conditioner
  12. Buy local, organic or fair trade food where possible
  13. Reduce air travel - pity that long-distance trains suck in Australia
  14. Wrap your water heater in an insulation blanket
  15. Use a clothesline instead of a dryer whenever possible - don't own a clothes dryer, hanging up clothes inside near a heater works on cold days
  16. Plant a tree - pity my trees are dying because of the drought / climate change
  17. Buy fresh foods instead of frozen
  18. Keep your car tuned up and your tires inflated to their optimal pressure - also minimise driving. I drive about 5000Km per year.
  19. Use biodegradable dishwashing liquid, laundry soap powder, etc.
  20. Drink tap water (filtered if necessary) rather than buying bottled water - remember the Benzene incident...
  21. Turn the tap off while brushing your teeth
  22. Unplug seldom-used appliances and chargers for phones, cameras, etc., when you're not using them - the power use is small so I only do this for rarely used chargers.
  23. Plug air leeks and drafts around doors and windows with weatherstripping
  24. Switch from disposable to reusable products: food and beverage containers, cups, plates, writing pens, razors, diapers, towels, shopping bags, etc - I've done this for most things, could improve though.
  25. Consider garage sales, Freecycle, eBay, or borrowing from friends/family before buying a new tool or appliance - second-hand and refurbished computers are so powerful and so cheap that you don't need to care about the environment to do this.
  26. Reuse bathwater, maybe to flush the loo, water the garden, etc.
  27. Make sure your roof is well-insulated. - I think it is, but as tenants it's not really our choice.
  28. Always wear a jumper/sweater and socks indoors unless it's warm enough outdoors to go without both.
  29. Run your vehicle on biofuel/sustainable fuels
  30. Set up a grey water barrel to use when clean water isn't necessary - grey water should never be stored. It contains chemicals that are used as food for bacteria.
  31. Put grey water on your garden immediately without storing it.
  32. Install tanks to collect rain-water from your roof for watering the garden, washing your car, etc.

15 March 2007

Gunnar Wolf: The environment and us

Ben, Erich and Russell bit - Why shouldn't I?
A. Copy the list below to your own journal and
Bold the actions you are already taking
Underline the actions you plan to start taking
Italicize the actions that don't apply to you
B. Add one (or more) suggested action(s) of your own
C. Leave a comment here, so that she can track the meme to your journal, and copy your suggested action(s) back to my master list. Shame - I cannot comment on this, as I'm no a LiveJournal registered user. And I don't intend to be either.
  1. Replace standard incandescent light bulbs with compact fluorescent light bulbs
  2. Choose energy efficient appliances - always a criteria when I have a choice. Not always the dominant criteria, though
  3. Wash clothes in cold(er) water
  4. Turn the thermostat of your hot water tank down to 50 C (125 F) We have a on-route boiler (calentador de paso - any translators? :) ), it only heats when the hot water pipe is active. Of course, it burns much more intensely than a tank, but still, I feel it's an overall saving
  5. Install a programmable thermostat (or turn the heat down over night and when you're out of the house) - Pfff... Artificial weather in Mexico City? Don't be silly! ;-)
  6. Register with the Canadian Marketing Association's Do Not Contact Service to reduce the amount of junk mail delivered to your house. - Would love to.
  7. Eat less meat (particularly feedlot beef) - Nadezhda is a vegetarian, I seldom eat meat
  8. Walk, bike, carpool or take public transit as often as possible
  9. Make sure you know what can be recycled in your area, and try to recycle as much household waste as possible - In this country, recycling is a lot. We hand-recycle some things, but of course, at a very artesanal level
  10. Compost using an outdoor compost bin or an indoor vermicomposter
  11. Clean or replace filters on your furnace and air conditioner
  12. Buy local, organic or fair trade food where possible
  13. Reduce air travel
  14. Wrap your water heater in an insulation blanket
  15. Use a clothesline instead of a dryer whenever possible
  16. Plant a tree
  17. Buy fresh foods instead of frozen (Frozen food uses 10 times more energy to produce)
  18. Keep your car tuned up and your tires inflated to their optimal pressure
  19. Use biodegradable dishwashing liquid, laundry soap powder, etc.
  20. Drink tap water (filtered if necessary) rather than buying bottled water - And not only because of the environment - huge price difference!
  21. Turn the tap off while brushing your teeth
  22. Unplug seldom-used appliances and chargers for phones, cameras, etc., when you're not using them
  23. Plug air leeks and drafts around doors and windows with weatherstripping - I guess this applies to places with heating/AC
  24. Switch from disposable to reusable products: food and beverage containers, cups, plates, writing pens, razors, diapers, towels, shopping bags, etc. - As much as possible, of course. Or try to reuse those meant to be disposed.
  25. Consider garage sales, Freecycle, eBay, or borrowing from friends/family before buying a new tool or appliance

Martin Michlmayr: Linux kernel

The Linux kernel project has seen major changes to its development and release strategy in the last few years, in particular since the first stable release of the 2.6 series in December 2003. This series was opened almost three years after the 2.4 series in January 2001, which many felt was too long. A problem that resulted from the long interval between major releases was that vendors had to back- and forward-port a lot of patches. Nowadays, major development happens on the 2.6 series and new releases are published every three to four months. This new development model has faced much controversy. While some people, in particular developers of the kernel, claim that the new model is working very well, some users are worried about the number of significant changes and lack of stability in the kernel. Andrew Morton, a lead developer, has expressed several times that he believes the kernel is getting buggier.
VersionDateMonths
1.01994-03-14
1.21995-03-0712
2.01996-06-0915
2.21999-01-2531
2.42001-01-0423
2.62003-12-1735
Past problems Solutions Outstanding problems

Erich Schubert: Energy saving meme

Via Russel Coker. A. Copy the list below to your own journal and Bold the actions you are already taking
Underline the actions you plan to start taking
Italicize the actions that don't apply to you B. Add one (or more) suggested action(s) of your own C. Leave a comment here, so that she can track the meme to your journal, and copy your suggested action(s) back to my master list.
  1. Replace standard incandescent light bulbs with compact fluorescent light bulbs - my room has a 12 W bulb. How much watts do you need for lighting?
  2. Choose energy efficient appliances
  3. Wash clothes in cold(er) water
  4. Turn the thermostat of your hot water tank down to 50 C (125 F)
  5. Install a programmable thermostat (or turn the heat down over night and when you're out of the house) - it is often sufficient to have the heater go on at like 7 at night and 5 in the morning for an hour each
  6. Register with the [Canadian Marketing Association's] Do Not Contact Service to reduce the amount of junk mail delivered to your house. - Substitute MPS.
  7. Eat less meat (particularly feedlot beef) - it's a lot healthier anyway. I enjoy the occasional steak, but you actually enjoy any taste more if you have more variance
  8. Walk, bike, carpool or take public transit as often as possible - I don't have a car. If I need to transport something big, I borrow one. I do my regular shopping via bicycle or public transit, which saves me looking for a parking space etc. anyway. Also note that when using public transit, you can work a bit, read a book, enjoy some music, ... and you arrive less stressed out than when driving a car.
  9. Make sure you know what can be recycled in your area, and try to recycle as much household waste as possible
  10. Compost using an outdoor compost bin or an indoor vermicomposter - at my parents
  11. Clean or replace filters on your furnace and air conditioner
  12. Buy local, organic or fair trade food where possible - tastes much better anyway
  13. Reduce air travel - pity that long-distance trains suck in Australia
  14. Wrap your water heater in an insulation blanket
  15. Use a clothesline instead of a dryer whenever possible - don't own a clothes dryer, hanging up clothes inside near a heater works on cold days - you often can do without ironing, too, by hanging them on a clothes hanger for drying they'll often be reasonably straight. My washing mashine has a program helping at that, too. It uses 40 C and takes just about .8 kWh and is called "easy iron".
  16. Plant a tree - pity my trees are dying because of the drought / climate change
  17. Buy fresh foods instead of frozen - especially with meat I do really notice a better taste
  18. Keep your car tuned up and your tires inflated to their optimal pressure - I don't have or need a car
  19. Use biodegradable dishwashing liquid, laundry soap powder, etc. - causes less allergies
  20. Drink tap water (filtered if necessary) rather than buying bottled water - our tap water here in Munich is better than bottled water anyway, and it saves you from carrying it, too.
  21. Turn the tap off while brushing your teeth
  22. Unplug seldom-used appliances and chargers for phones, cameras, etc., when you're not using them - consider to use a master switch for them
  23. Plug air leeks and drafts around doors and windows with weatherstripping
  24. Switch from disposable to reusable products: food and beverage containers, cups, plates, writing pens, razors, diapers, towels, shopping bags, etc. - especially shopping bags and beverage containers is easy
  25. Consider garage sales, Freecycle, eBay, or borrowing from friends/family before buying a new tool or appliance - saves energy and money
  26. Reuse bathwater, maybe to flush the loo, water the garden, etc.
  27. Make sure your roof is well-insulated.
  28. Always wear a jumper/sweater and socks indoors unless it's warm enough outdoors to go without both. - and turn down the heater a bit, it saves a lot of energy and money. Sweater and socks are quite comfortable...
  29. Run your vehicle on biofuel/sustainable fuels
  30. Set up a grey water barrel to use when clean water isn't necessary
  31. Put grey water on your garden immediately without storing it.
  32. Install tanks to collect rain-water from your roof for watering the garden, washing your car, etc. (at my parents; we also installed an overflow valve which will automatically redirect overflow water to plants that can always use more water)
  33. Don't keep windows open when your heater is on - especially don't keep them half-open. If you want better air, turn off the heater and open the windows for a few minutes completely. This will quickly refersh the air in the room. Then close the window and turn the heater on again.
  34. Turn off light that you don't need
  35. Stop your engine when waiting more than 10 seconds - for example at train crossings; maybe doesn't apply to Diesel as much because it relies on a operating temperatrue, but I doubt it cools down that quickly
  36. Install a solar panel on your roof for water heating - especially in summer or in sunny regions, this will allow you to completely turn off the heater during summer or even most of the year. A solar water heater will easily heat your water to 60 C (on hot days we reach 70 or 80 C), while even keeping your house a bit cooler). It can be installed yourself. At the same time, maybe add insulation to your pipes. If you minimize temperature loss over night, you'll even have warm water left in the morning.
  37. Use air circulation for cooling - much cooling can be achieved by having a good air flow, wearing appropriate clothing and avoiding heavy work during the hot hours. Consider doing a siesta and work in the morning and evening
  38. Ask your bank for an online-only account - some banks even offer lower fees if you don't use paper-based banking
  39. Try to make more use of daylight - that's like free light, you know.
  40. Walk and run more - it's healthy, saves you fitness club costs and it saves some energy if you are not using the lift. Walk to the supermarket or fitness club!
  41. Use your local recreational facilities - there are probably nice parks nearby where you can go running, maybe some place to go climbing nearby, some pool, ...; this can be an interesting alternative to watching a movie, too
  42. Use the refridgerator smartly - don't leave it open when not necessary, and keep the temperature only as low as you need it. Bring all your shopping into the house, sort it, and then open the refridgerator and put it all in in one go, for example.
  43. Learn how to cook energy efficient - for example, if you plan ahead you can put frozen foods into the refridgerator to defrost at virtually no power cost. It's also better for the food. Use lids when boiling water; you can also use it often for cooking if you turn down the heat. For rice, I usually put on the lid, and when the water is boiling I can turn the heat off again. With the lid on, the rice will end up cooked just fine. Also pick an appropriate applicance. A real water cooker will be more power efficient for making your tea than putting a small pot on a large flame.

Martin Michlmayr: GNOME

GNOME provides a complete desktop environment that is easy to use. The project experienced major problems, such as delays, during its 1.x series and in particular during the preparation of its 2.0 release. GNOME introduced time based releases after its 2.0 release and has significantly improved release management. The project has published time based releases every six months for a number of years now and is considered as the reference model for a good implementation of time based release management. They have shown that it's possible to set and meet deadlines in volunteer projects and to release on time.
VersionDateMonths
1.01999-03-03
1.22000-05-2515
1.42001-04-0210
2.02002-06-2715
2.22003-02-067
2.42003-09-117
2.62004-03-317
2.82004-09-156
2.102005-03-096
2.122005-09-076
2.142006-03-156
2.162006-09-066
2.182007-03-146
Past problems Solutions Outstanding problems

Ingo Juergensmann: Debian

I've been using Debian for about 10 years now. Debian was my first Linux distribution. For about 7 years I've been running a Debian m68k buildd now. For some time now I've been worrying about Debian and its future.
IMHO, there are several reasons to worry about its future.
a) Release cycles.
Funny enough Martin Michlmayr wrote today about Gnome release cycles. Apparently Gnome suffered from similar problems in Gnome 1.x times as Debian still does today. The big difference between Gnome and Debian is: Gnome has actually learned from its mistakes and changed its release model to something better. Really. I don't use "better" very often in conjunction with "Gnome", but in this regard, the Gnome project did really something good.
Debian, on the other hand, suffers more and more from its "release everything for all when it's ready" syndrome. Releases are always delayed, it's a big chunk of work for everyone involved, Debian is losing users because of the delays and so on...
b) Debian as a base for other distributions.
Lately, several distributions announced, that they will use Ubuntu as a base for their own distribution and not Debian any longer.
c) Internal problems.
Debian has many internal problems. Many of them have to do with communication problems. Others with "you can't force anyone to do anything in Debian" ideology. Some with unresponsive persons in key positions. Some problems are a mixture of all the above. Altogether, these problems are causing that many developers are losing their fun in the long run.
d) Flame wars.
Well, actually this could be listed in b) Internel problems as well, but it's a massive problem of itself, so I think it deserves its own section. Flame wars are really time consuming and destructive. I know what I say. Been there, done that.
e) Getting new people in.
It is often said, that there are >1000 Debian Developers. The truth is that many of them are inactive or MIA. There was a proposal lately to find those inactive DDs and handle them accordingly. Given this fact of many, many inactive DDs means, that there is more work for those left. To solve this problem of overworked DDs (it's another truth, that some DDs are very active and have far too many jobs within Debian), Debian needs to attract more people and encourage people to contribute. Currently, it's not that easy for people to contribute, because of bureaucratic formalisms like sponsored uploads and such. Additionally, not everyone willing to help wants to do packaging or other tasks. There is a lot of other work to do like making graphics, organizing booths or other events, etc. Currently those tasks are mostly done by DDs that could better spent their time on developing Debian itself (packaging, porting, ...).

Ok, enough for now. But how can those problems be solved?
ad a)
Martin mentioned in his post about the Gnome Release management, that they changed from "release when it's ready" to time based releases and gained credibility because of this.
I think, Debian would benefit as well from this type of release management. Additionally, every Developer can react to this new method and make his packages fit for the release because he knows "Hey! Just 4 weeks until the release! Let's get my packages ready for it!"
Another problem, IMHO, is the "release all packages for all archs at one time" problem. This lead to the drop of m68k for etch (via some obscure circumstances like a very broken gcc 4.0 version and some strange release criteria, sometimes referenced as Vancouver Massacre).
Someone of the contestants for the new DPL job mentioned in his world domination plan to have a stable release of some basic components every year and having sub-releases for desktop environments (KDE, Gnome, XFCE...) every 6 months. Basically I believe that this is the way to go. You can discuss the time frames, of course. Release a stable base every year or every 2 years? But really, I think this would be the best way to deal with many problems Debian has.
If every 1-2 years a new stable base would be released, everyone could be happy: the admins with long release cycles for their servers, the users with faster releases for their desktops and (maybe) the porters who can (maybe) omit a subrelease of the desktop apps and concentrate on porting the base system if needed. Really. 15000 packages for (let's say) 15 archs is way too much work for everyone.

ad b)
With the above mentioned changes, Debian could re-gain some more market share and users from other distributions like Ubuntu - and be a base for distributions again. The reputation of Debian would rise again, because the releases wouldn't be delayed again.
I think it would be ok for smaller ports (like m68k) to release differently than the main archs (i386, amd64, ppc, arm): if every year a new stable base release would be done, it could be ok for them to skip a release, if necessary. Of course, details must be elaborated more in detail.

ad c)
There are many internal problems. The most urgent one is "bad communication". Needless to say that it's very important to communicate with your work mates to get your work done. If someone fails basic communication skills (answering questions about the stuff s/he is responsible for) in a reasonable time frame, s/he's simply the wrong person in that position and should be replaced. Of course this interfere with the current understanding of "not being able to be forced to do things" in Debian. People should change their mind about that.
Basically, it's similar to NMUs: if a package maintainer fails to fulfill his responsibilities (fixing bugs), he can either be enforced to fix the problem in that package by a bugreport or he can somewhat be replaced by doing a NMU when he's not fulfilling his duties. If he fails often to get his package into a good shape, he can be replaced permanently by hijacking the package.
Or to give a real world example: If you are holding a honorary post, let's say, you're doing the financial paper work for your soccer club, you can't say "Oh no... I don't have the time to do the tax declaration now or the next month...". That just doesn't work. Either you do your duties on time or you need to step down from that post. Otherwise you would do damage to your club. This is valid for other volunteer organisations as well, like Debian. Do your duties on time or step down from your post.

ad d)
Well, I'm not innocent when speaking about flame wars. Anyway, people can learn and change their mind. Flame wars are really bad in Debian, but it seems to be something like a sport to me sometimes. And usually it needs two parties for a flame war. That's the reason why I believe that expelling a fellow DD because they were involved in some major flame wars in the past is simply wrong. Either expel all parties or none.
A party is not only involved when answering to mails on mailing lists, but also when doing stuff that forces the other party to react - for example by starting a flame war on a mailing list. There's always action and always reaction. Therefore you can't disjoin both and just judge upon one party.
When a mediation is tempted, both parties are required to obey the mediators decision. Of course there should be a fair decision that honors both sides. Both sides have to give in for a successful mediation attempt. If that's not the case, the mediator failed. Not obeying to the mediators decision, because "no-one can be forced to do anything in Debian" (see above), is plainly wrong.
Anyway, most people should know of what I'm speaking here. I think it's plainly wrong to expel developers that have done really great work in the past due to some flame wars. Debian as a community has failed when it chooses this ultima ratio. Debian just proves that it is unable to establish a community where people can work together, when developers are going to get expelled because they thing that a mischief was done to him.
How would you feel and react when someone would play bad games on you? Wouldn't you yell loudly as well?
So, how can something like this be avoided? Maybe a Code of Conduct could help, maybe that CoC wouldn't be necessary when everyone would be nice to anyone and remember that there's a human being each mail with feelings and emotions?
Anyway, Debian needs to abandon flame wars in general.

ad e)
Well, I've already written a little bit about this problem above. There are many tasks in Debian that doesn't need technical excellence of packaging details - instead it needs excellence in social skills. Something that many technically focussed people are missing. Debian needs to become more attractive to those kind of people that are good at this non-technical issues and encourage them to join the project - and not to frighten them away by a very technical and bureaucratic procedure like the current NM process. Those kind of people won't wait some years to be actually being able to do work. They will just go on and find a place where their skills are better welcomed.


Ok, that's for now, I think... it's been a long post and therefore I've used folding for it.

Conclusion:
Well, not a nice one. Debian needs big changes in its structure and the candidates for the upcoming DPL elections identified some of them and put them on their agenda for their DPL period (if they win, of course). But the history showed that none of the past DPLs had really the power or the will to push big changes and made hard decisions. So, after all everything will stay as it is now. Nothing will change for the better, I fear. Users will leave Debian because of its stale release cycles, more and more Debian-based distributions will change their base to Ubuntu and Debian will become more and more irrelevant over time instead of being a strong participant in the free software world.

14 March 2007

Michael Prokop: Maintain /etc with mercurial on Debian

Based on Bart Trojanowski’s blog article “etc snapshots with git” I removed one further item from my todo list: maintain /etc with mercurial on my Debian systems. First step is creating the repository and securing access to the repository. As mercurial stores all its files within one single directory named .hg you won’t have any further directories within /etc besides /etc/.hg, rocking - right? ;-)
cd /etc
hg init
chmod og-rwx .hg
Ignore a few files:
cat > .hgignore << EOF
syntax: regexp
(^)*.dpkg-new
(^)*.dpkg-old
(^)blkid.tab( .old)
(^)mtab
# add other files if necessary, depends on your setup...
EOF
Now commit the current state:
hg add
hg ci -m "initial checkin"
We want to commit the changes automatically when using apt-get/aptitude so let’s write and include a wrapper for it:
cat > /etc/apt/hg-snapshot-script << EOF
#!/bin/sh
set -e
caller=$(ps axww   mawk '/aptitude apt-get/  for (i=5; i<=NF ; i++) printf ("%s ",$i); printf ("n")  '   head -1)
hg add 1>/dev/null
STATUS="$(hg st)"
if [ -n "$STATUS" ] ; then
   echo "hg-snapshot-script: found changed files:"
   hg st
   hg ci -m "snapshot from $LOGNAME after: $caller"
else
   echo "hg-snapshot-script: nothing to be done"
fi
EOF
chmod +x /etc/apt/hg-snapshot-script
cat >> /etc/apt/apt.conf << EOF
DPkg  
  Post-Invoke  "cd /etc ; ./apt/hg-snapshot-script"; ;
 
EOF
Finally track the two files too:
hg add
hg commit -m "apt will track /etc automagically using hg"
That’s it. :-) Oh BTW: users of subversion might want to point their browser to /etc under svk (by Enrico Zini).

Francesco P. Lovergine: To package or not to package...

... this is the problem

I just casually saw Norbert post about the ion3 querelle. This a very unfortunate example of collapsing interactions among upstreams and maintainers. My general advice (but for suggesting to use wmii or dwm instead of ion3 :-)) is avoiding packaging of development branches, but this is a decision which sometimes is difficult to take: some programs seems in development for years and stable releases could result largerly unusable or limited. Surely our - and generally speaking any distribution - release cycle and maintainance are not adequate for many on-the-edge software out there.

When upstreams releases [a]periodical milestones, those could be packaged, but upstream will not support them: we have already our problems in supporting regular releases for security independently by upstream for mainstream programs, without adding pieces of casual crap around.

Packaging a casual snapshots is out of question IMHO, but for using it in sid/experimental, so I can understand the upstream opinion, because many users report problem to upstream instead of maintainers. I see definitively no silver bullet anyway, but for maintainers' capability of understanding what should be packaged or not and opening an unbreakable communication channel with upstreams to be up-to-date in respect with upstream roadmap.

Martin Michlmayr: GCC

The GNU Compiler Collection (GCC) is a compiler suite which supports a number of programming languages, such as C and C++. It is a very important development tool and is the standard compiler among free software projects. GCC was quite stagnant in the middle of the 1990s until the EGCS project formed. EGCS took over development of the official GCC in October 1998 and instituted rigorous processes, such as high levels of peer review, and created a steering committee which has the power to appoint maintainers and make important decisions. In theory, the project follows a time based release with an interval of six months. In practice, the project has released only one new version every year in recent times.
VersionDateMonths
3.02001-06-18
3.12002-05-1511
3.22002-08-143
3.32003-05-139
3.4.02004-04-1811
4.0.02005-04-2012
4.1.02006-02-2810
Past problems Solutions Outstanding problems

Russell Coker: getting big changes in Debian

Erich Schubert comments on the issues relating to getting big changes into Debian. This is something that I had also noticed. I started work on SE Linux in Debian in 2001 and continued it actively until 2003 when I joined Red Hat. Less than a year after I joined Red Hat there was a Fedora release with SE Linux fully integrated and shortly after that there was a release with SE Linux on by default. The reason for this was that Red Hat management supported the idea of SE Linux and everyone had to accept it. There was no option for a package maintainer to refuse to support SE Linux.

Recently in a discussion on debian-devel one DD (who I won't name in this blog post) advocated removing SE Linux support from dpkg. I then asked him whether he had the same attitude towards non-executable stack
(Exec-Shield/PaX/OpenWall), Poly-Instantiated directories, and PIE executables. When he expressed interest in having those features I pointed out that one of the enemies of security in Debian is the fact that every person controls their little area and has no requirement to work towards common goals (apart from the most obvious ones of making the system work).

This means that instead of having a little cooperation from other developers anyone who wants to get a significant change included will have to fight hundreds of battles.

SE Linux is a classic example of this. Debian could have had SE Linux support long before Fedora, but instead it gets it long afterwards.

The same battles occur with regard to all the other security measures I mentioned (and some others I didn't). We could made Debian the most secure Linux distribution, there are many people who have the skills and the interest in doing so.

If you want features such as exec-shield, then you are missing out - largely because the people with the skill and time to work on them are too busy fighting trench-warfare rather than actively coding.

Now while I strongly object to most incarnations of the "you can't force a volunteer to do anything" meme that infects Debian I do agree that we can't force developers to write new code. We can however strongly discourate an antagonistic attitude towards new features. If someone proposes a feature
that you don't plan to use but which doesn't hurt you then there's no reason to attack - you can just ignore it. If someone sends in a patch that adds a feature which is requested by many people but you personally don't use, then if it has little or no down-side (linking against a couple of shared objects as is the case for many SE Linux enabled programs provides no measurable overhead) and the code is good it should be merged!

The real problem is that some DDs are more concerned about what is best for them personally (in the most short-term manner) than about what is best for the users.

Wouter Verhelst: iniTscripts: followup

(yes, I know how to type, but my keyboard is degrading. Apparently, I didn't know how to read yesterday) There were a number of replies to my post about upstart and other init-implementations yesterday. Since it apparently didn't come through properly: yes, I do know about upstart-compat-sysv, and yes, I'm obviously using it. That wasn't the point. The point is that using upstart-compat-sysv is a workaround which allows to migrate to upstart, rather than to support it in parallel. Debian has always been about choice; giving people the choice to use upstart rather than sysvinit and vice versa is something we should do. Ubuntu has chosen to use upstart rather than sysvinit, and that's their prerogative; but Debian as a whole cannot (and will not) make that choice. The point of the exercise was to figure out a way to allow people to say "I want upstart", and bang—everything gets migrated to event.d scripts. But if they then decide that they don't like upstart after all, they should be able to just reinstall sysvinit, and bang—everything gets migrated back to regular SysV initscripts. That currently isn't possible, and upstart-compat-sysv doesn't offer that.

Gunnar Wolf: High, cold, tiring, beautiful, delightful, proud... Should I go on?

[ Warning: Long post follows ]
Just today, I read that H01ger is happy he can wear just a T-shirt somewhere in Northern Germany. Well, from my point of view, much the opposite has happened. And I'm not just happy - I'm fucking proud!
About four years ago, Nadezhda went almost every weekend to hike to the mountains with the Grupo de los Cien people. I'll sidetrack a bit to speak about them: Grupo de los Cien is a group of mountain lovers (no relation with the enviromentalist group which later took the same name) that, since the 1950s, have built and maintained the high mountain shelters in Central Mexico. It is a group, by the way, with which Nadezhda fell completely in love - and now it's up to me to find out why ;-) But lets go back to the main topic.
Almost every week, she came back delighted and loaded of energy from a mountain hike. Almost every week, I told her I wished to go with her, of course, if they went to a simpler route. Of course, lugging around over 130Kg of humanity is no easy deal. And, after over a year and because of many problems that came together at once, she stopped going to the mountain as well. She always kept an eye on their friends, but so far had not been able to return to the mountain.

Ok, so last week she heard the group was organizing volunteers to go fix the Ayoloco 2 shelter. She signed up, and invited me. I was afraid, but accepted the challenge - Of course, full of fear.
Being this a historical event (at least in my life), I cannot but offer you some of the photos I took. And, yes, I've just started playing with Flickr. Lets see if it works for me ;-)
Saturday, 5 AM, we woke up. 5:50AM, we met part of the group near Daniel's house, in Condesa. 7 AM, we were having a nice breakfast (tamales and coffee, yum!) in Amecameca, still 28km from La Joya. From Amecameca, we went to Paso de Cort s, where we met the rest of the group, and from there we went by a little, bumpy and unpaved road until La Joya. Somewhat around 20 people started the hike at around 9 AM.


According to Google Earth, La Joya (just South of the Iztacc huatl - white woman or sleeping woman in N huatl) is at 3995m - And, of course, to start at that altitude is not easy. The air is very thin, and walking a little bit too fast quickly makes you feel the blood pumping, trying to get some more oxygen. I often remembered how my Bolivian friends behave in Potos , walking slowly even when in a hurry :)

We first went down a little valley, then up. The first portion of the hike was on soft, wet sand, with some grass (what we call zacate - Strong, hard grass, not what you commonly see in a garden). I soon learnt that was a blessing, as it was by far the easiest part. Then we went up a steep and quite rocky area - It started getting tricky for somebody not used to trusting his own feet. And it was steep, yes. This was the first time (of many, of course) I started thinking whether I should head back.

We reached what I foolishly thought was the summit, only to find a steeper, longer way to go. It started getting common to find little deposits of snow/ice (I don't know the exact term in English - it's called aguanieve in Spanish, literally snow-water. [[Update]: Thanks to the now-DD H01ger, I now know that aguanieve in English is called sleet]. I understand it's a bit harder than snow, but still much lighter than hail). We crossed a completely rocky section - No sand to hold the rocks to their place. That meant being extra careful (and thus, extra slow).

But just afterwards, in case it was not enough, Mother Nature answered my pleads for some sand - we crossed a section made exclusively of loose sand. And, please, if you have ever walked upwards on sand, imagine doing so at over 4000 meters. I was taking so much care of how and where I stepped that I strayed not more than 5 meters down of the path the group was following - Being able to climb back to the right path was really not easy. This was the point that not only I was thinking about heading back, but I'm sure Nadezhda thought I would abort the mission. She cheered me up, took some pictures of me as soon as I got out of the sand trap, and we were able to move on.

After the sand, some more rocks, and we started feeling the chilly wind. We entered a cloudy region - Humidity does get the coldness into your bones! We could not really see where was the rest of the group, so we proceeded the best way we could. Fortunately for Nadezhda and me, just behind us came the very experienced Mario Corsalini and led us. And, yes, we finally saw the Ayoloco 2 shelter.

I was by then exhausted, after some four hours of ascent. I ate one of my apples - The sweetest apple I have tasted so far. After resting a bit, and realizing I was almost frozen (we were at 2 Celsius under, with constant chilly, humid wind)... Then I started working with the guys, reinforcing the shelter, while Nadezhda and some other people painted the inside with. People started eating - of course, I joined them. And, after some time up there, we started going back down. Miguel ngel, a volunteer in the Izta-Popo park, walked a good portion of the descent with me, giving me tons of help and tips. Thank you, thank you, really. The descent is, of course, much easier - We were chatting most of the time, and we made only around two hours back. The weather was quite nice on us - We had some aguanieve falling every now and then (yes! Yes! many of you guys have heard/read me bitch on how I had never seen snow falling before - Ok, this is not exactly snow, but I think it qualifies as my first experience ;-) ), but aguanieve does not make you wet, as it bounces off the clothes. When we approached La Joya we started having some light rain. We hopped in the cars, and then the rain really began.
But even if this was not enough: Grupo de los Cien was celebrating the 83th birthday of one of its senior members, Poncho Rico. No, being 83 years old is not an excuse for skipping this memorable hike.

We went to Anatolio's house, very close to Amecameca, and had a delicious dinner, cake and drinks.
Nadezhda: Thank you. So, so, so very much. Thank you for being so patient with me, for dragging me up the Sleeping Woman. Thank you for getting me into this so very important and beautiful experience. I hope this will be the first of many. There is still a very long way for me to go before I'm really up to the challenge, but believe me: This will not be my last time on the mighty mountains.

Steve McIntyre: Travels after Debconf - an alternative

To whom it may concern... Daniel and Rob are holding a party in June to celebrate their Civil Partnership. Yay! And I'm invited. Double-yay! Unfortunately, it's the same weekend that Debconf 7 finishes. And it's in in deepest, darkest Wales, almost at the opposite end of the UK from Edinburgh. Less yay...! As Daniel is a DD, I'm guessing (and he has confirmed) that quite a few of the party guests will be at Debconf. That means there will be quite a number of people will be needing to get from one end of the country to the other on Saturday 23rd June. As I'm a mug for this kind of thing, I'm looking into organising travel for a group. If you're looking at making this trip, mail me if you're interested in travelling together. Options at the moment include hiring a minibus and driving the whole distance, or maybe flying from Edinburgh to somewhere much closer (Bristol or Cardiff) and sharing a vehicle from there. Let me know...

Eddy Petri&#537;or: Wishlist for lenny... or why debian packaging is considered hard

(Update: Yes, Gunnar, the policy says that the debian/rules file must be a makefile, so if you do something else, you have a serious bug because of a policy break. Of course, probably there is nothing that should stop one from using, let's say bash, or python or perl, from a technical PoV.)

Erich has a wish list for Lenny.

What draw my attention was the very first "define and deploy a standard way of packaging software, that can be used for like 90% of packages", later he mentions rationale "other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes."; these two quotes contain the real essence of Gentoo's success in the area of fast development.

A half a year ago I did an experiment in packaging a rpm, a deb and an ebuild for the same piece of software. What I observed back then made me think a lot about the entry level knowledge needed for a person to create a decent package for those types of package systems.

With the risk of being flamed by many people that will miss my point, I will tell you from the start that the deb would have been the most painful if had to start from scratch. Second would have been the rpm due to lack of good/updated documentation and the clear winner in lack of pain points was the ebuild. In reality places were switched between the deb and the rpm.

And before I start, please understand that what I want to point out is that the building system in debian is showing its age and we should do something about it, and is not about pointing people to documentation; it is about making things behave more sanely by default and not about having to read a whole day to understand why the package fails to install a file you just added then to find that you had to add the destination path to a debian/dirs file etc...


The deb had to be the most difficult. Not because I didn't do it before, or because it was hard, but because there are a lot of things that need to be done because the package management is not smart enough to do it by default (i.e. class inheritance does not exist, like is the case for the ebuilds or the macros for rpms).

The Debian approach is backwards, is reversed with regard to the others and the way it should be by default, to allow easier understanding of the packaging. You can, by default, make a package that is tweaked a lot. There is no concept (if you don't count cdbs which is boo-ed a lot by some people) or possibility to just say "make this package a package that is a standard linux app with the regular ./configure && make && make install recipe". And I don't count such a recipe the templates based on dh_make, that is way too verbose. A new maintainer wannabe has difficulties understanding why are those lines in there, and what they do, and most importantly, why is that order correct and no other. Another question which is legitimate is "is that the minimum or can that be trimmed"? (Follow debian-mentors and see how many people leave the .ex files just because they are afraid they will not know how to generate them again.)

Even the rpm has a concept of standard stuff to do for a package, there are some macros that implement that. And that is more logical for an untainted mind (as in not yet debianized) than what we have in the dh_make template, or worse, a clean and new debian/rules file. Why should one care to learn the ways and philosophy of make just to make a small package?


Let me tell you something that will feel like knife stab for many people in our community: the clear winner was the ebuild, not because I was smart or exciting, but because:

I did the ebuild in one day's work (it was less, but some will not believe me, so I'd say 1 day is reasonable enough) starting from absolutely 0 knowledge about the packaging system (if you don't count knowing to emerge package as knowledge).

What is done properly in the portage system is the fact that there are some default classes which your ebuild can inherit to behave more like a certain type of packages (base - a generic recipe, gnome, kde, games, sourceforge - they download tarballs directly, if needed - ...)

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file...

Gentoo implemented initially portage's default behaviour (and as a consequence, the "classes") in shell, later they migrated some parts to python and the whole portage is implemented in python now (while classes are implemented in bash). I am not saying that we should put python in essential, God forbid, probably the emdebian guys would stab me :-), I am saying that possibilities exist, alternatives should be possible.

I know, some will just say "show me the code", "making such a change over the entire archive is insane" or "the makefile is a really good way to do things like installing and building, after all, that's what it was designed for". Yes, all of these will miss the point, which is having nothing-to-do as a default policy for a package is a bad policy, it should be an empty/default package will use a standard recipe to build itself, and that recipe should be implemented in the build system.


And if you still don't believe me, just look at these few ebuilds and tell me you'd not be able to write them after a quarter after seeing one the first time and skimming over the docs or/and knowing what a regular gentoo user knows (what a keyword is, what is a slot). Also compare with the debian counter parts and don't forget the different building aids that we have.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/amphetamine/amphetamine-0.8.10.ebuild?view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/control?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/postinst?op=file&rev=0&sc=0

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/holotz-castle/holotz-castle-1.3.8.ebuild?rev=1.3&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/control?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/late/late-0.1.0.ebuild?rev=1.10&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postinst?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postrm?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/ppracer/ppracer-0.3.1.ebuild?rev=1.15&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=file&rev=0&sc=0


One more thing, the ebuilds mostly need not be updated when an upstream release occurs, they just need to be copied and given a different filename.

13 March 2007

Martin Michlmayr: Quality Improvement in Free Software: Release Management

As I'm nearing the completion of my PhD, I'm starting to write about the findings from my research. The aim of my PhD is to investigate quality improvement in free software projects. After some exploratory studies about quality in free software, I decided to focus on release management as one problematic area in which improvement is possible. My approach is to study the development process of projects and to investigate ways how these processes can be improved. The hope is that such improvements will lead to increased levels of quality in the software produced by free software projects. With regard to release management, I'm focusing especially on large and complex projects, in which hundreds of volunteers need to be coordinated during release preparations. I've been looking particularly at time based release management since my exploratory studies have shown that there is significant interest in this release management strategy. The main question of my research is how and why time based release management works for large free software projects. In my first series of postings, I will introduce the seven free software projects I have studied in depth during my research. For each project, I will briefly summarize what problems the project faced in the past, what changes they have implemented to address these problems, and what outstanding problems they still have.

Wouter Verhelst: Iniscripts

Been trying out upstart today. It's a nice piece of code, but unfortunately it's totally useless today. Not because its concepts suck; rather, because Debian packages today ship with SysV-style initscripts, and those do not integrate well with upstart: most of the features that make upstart so interesting require you to create an event.d script, which has a totally different syntax. The Debian Developer inside me couldn't help but start to think about a way to fix this, but that seems harder than what it initially would sound like to the uninitiated. My first idea was to add some /sbin executable to upstart or one of its supporting packages, so that a SysV-style initscript could exit if that binary told it that upstart was running, before doing anything. That way, a package could ship both upstart event.d files and SysV-style initscripts during a migration period, and we could get rid of the SysV-style initscripts when and if Debian eventually decides to migrate to upstar. But when I sent that past #debian-devel, someone mentioned initng, which is yet a different init implementation. If this would work for upstart, it could also work for initng, and I don't think many packages would want to ship initscripts for three different init implementations. So scratch that. My next idea was to generate initscripts, rather than have packages ship them. The amount of common code in our initscripts is huge, anyway, and it's not as if it's all that hard to write an initscript. The things an initscript needs to do are limited, anyway: start a daemon when requested, stop it, restart it, perhaps send it a SIGHUP if or when configuration updates have been performed, and provide some useful output on all that. In most cases, that's about it. So, I thought, why not create an RFC822-style file (analogously to other files in the debian/ directory of a debian source package) containing all the metadata on an initscript, and generate the correct style of initscript out of that? That should work, I thought. So I started writing a specification, and had a look at the initscript of one of my own packages, nbd-server. Which does this at some point (nonrelevant content cut out):
i=0
while [ ! -z $ NBD_FILE[$i]  ]
do
  start-stop-daemon --start --quiet --exec /bin/nbd-server (...)
  echo -n " $ NBD_FILE[$i]  ]
  i=$(( $i + 1 ))
done
There's no way you'll be able to express that type of flexibility with an RFC822-style file containing all the metadata. So, scratch that too. I still do think generating initscripts is the right thing to do, however; the question that remains is "how". One idea I had was to use m4 in an autoconf kind of way, since autoconf allows one to mix autoconf macros with "regular" shell snippets, which would be exactly the kind of flexibility that one would need. However, that totally ignores the fact that autoconf is only able to pull this off because its output is shellscript in every case. An m4 macro that has to produce output which are not, in fact, shellscripts (such as would be the case for this project) could not do that. I think I'm kinda stuck now...

Next.

Previous.