[01:24] <owh> My cron.daily doesn't appear to be running. An entry shows in the log, showing that the crontab entry runs, but the scripts in /etc/cron.daily don't appear to run. Initially I thought it related to one of my own cron.daily scripts, but removing that has made no difference. run-parts --test shows all the scripts you expect. Any ideas?
[05:19] <someone> does ubuntu run hald by default /
[07:40] <owh> Hiya, just had a bad experience upgrading from Feisty to Gutsy and before I send an email to u-d-d about it I was wondering if anyone might have a look at it before I hit send. The email is titled: Fixing Bug #1 and while it mentions some of the issues, it's not specifically about those: http://paste.ubuntu-nl.org/59112/
[07:41] <owh> Feel free to be brutally honest in your response. I'm looking for alternative perspectives.
[07:42] <kgoetz> owh: i know people bringing up bug1 every time they have a problem raises my blood presure, dont know about other people though
[07:43] <kgoetz> not many places do support upgrades (eg) - microsoft sort of do, redhat dont at all.
[07:43] <pwnguin> yea
[07:44] <pwnguin> first rule of getting stuff done is to not make em angr
[07:44] <owh> It started with a raised blood pressure, but I felt that it wouldn't be constructive. I toyed with a rant of all the broken things, but thought that was also not constructive, so I tried to find ways of indicating how we might improve things. I'm not sure if my email does that the way I think/hope it does.
[07:44] <kgoetz> fwiw, your teh second person i've seen in 4 hours complaining about feisty -> hardy upgrades
[07:44] <pwnguin> and citing bug one is basically saying "YOU THINK THIS IS OKAY?!? WELL THEN VERYONE WILL JUST STICK WITH MS!"
[07:44] <owh> kgoetz: This is Feisty -> Gutsy
[07:45] <kgoetz> owh: er, yeah sorry. i meant that :$
[07:46] <owh> pwnguin: I did say that as my subject, because I think that's valid. What I was attempting to do with this email is get beyond that. I'm not sure I succeeded.
[07:46] <kgoetz> i expect you would be told to take it to the discussion list too (but not being on it or u-d i cant comment)
[07:46] <pwnguin> owh: you use the phrase We a lot
[07:46] <kgoetz> s/comment/comment for sure
[07:46] <pwnguin> have you been testing upgrades from gutsy to hardy?
[07:47] <owh> The reason I'm raising it here is because some of the people here know me and I figured they would smack me if I needed it.
[07:47] <owh> pwnguin: No, I've not been working on gutsy -> hardy upgrades.
[07:48] <pwnguin> the surest way you have to make that work is to probably start reporting bugs now ;)
[07:49] <pwnguin> make an image, install it, upgrade and see what all broke in your opinion
[07:49] <pwnguin> its essentially too late to fix feisty -> gutsy upgrades
[07:50] <kgoetz> pwnguin: which tbh i find a rather anoying pice of ubuntu policy
[07:50] <pwnguin> funny thing to hear in a server channel
[07:50] <pwnguin> its not policy
[07:50] <owh> Not only that, it's not really sustainable. It means that upgrades won't ever get better.
[07:51] <kgoetz> whats a funny thing to hear in a server channel?
[07:51] <owh> It means that lessons learnt since release never get incorporated.
[07:51] <pwnguin> owh: you mean like uuid disks?
[07:51] <owh> So, you're no better off being conservative than doing an upgrade on day 1.
[07:52] <owh> pwnguin: You mean the fstab fix?
[07:52] <pwnguin> i mean the system by which the kernel establishes a uuid for each disk, independent of the device detection order, and is used, among other places, in fstab
[07:53] <owh> pwnguin: I'm not sure what you are getting at.
[07:53] <owh> Aren't we all aiming for a better user experience than anywhere else? MS and RedHat included?
[07:54] <pwnguin> that system was put in place because upgrading the kernel can cause detection order reversals
[07:54] <owh> So, are you giving me an example of a fix that was made after release to make an upgrade work better?
[07:55] <pwnguin> that'd be an example of a fix that was "a lesson learned" and the upgrade getting better
[07:55] <pwnguin> more importatnly
[07:56] <pwnguin> of that list of bugs, theres about 3 legitimate upgrade complaints
[07:56] <owh> I'll bite. Why should I as a user upgrading from the previous stable release to the current stable release, six months later, still have to deal with the same problems as someone doing that upgrade on the first day of the release?
[07:56] <owh> pwnguin: You're referring to the list of bugs in the email?
[07:57] <pwnguin> in the pastebin, yes
[07:57] <owh> pwnguin: They were included in the draft to give some sense of the issues experienced from an end-user experience, they weren't intended as bug reports as such.
[07:58] <pwnguin> interesting
[07:58] <owh> What?
[07:58] <pwnguin> im trying to figure out why the icons changing is a negative end user experience
[07:59] <owh> pwnguin: Because their function didn't change and I didn't change theme. The icons changed for no benefit to me as an end-user.
[08:00] <owh> s/icons changed/icons changed appearance/
[08:01] <pwnguin> so you've expressed no preference for them
[08:01] <owh> That's an interesting view.
[08:01] <owh> Hmm.
[08:02] <owh> As an end user I used the icons that came with the selected theme would be the best way to respond I think.
[08:02] <owh> But I think I see what you're saying - I didn't choose any specifically, so why should it matter if they change?
[08:02] <pwnguin> indeed
[08:03] <owh> I suppose my threshold for change is lower than others.
[08:03] <owh> That's interesting in its own right :)
[08:03] <pwnguin> most server people hate change ;)
[08:04] <owh> That's because people start yelling at you if things change :)
[08:04] <kgoetz> afk. heading home
[08:04] <pwnguin> a few of these bugs seem like straight up bugs. they'd be the same if you reinstalled or installed for the first time.
[08:04] <kgoetz> back in a fe hours probably
[08:04] <kgoetz> *few
[08:04] <owh> Thanks for your comments kgoetz.
[08:05] <pwnguin> i agree that config file diffs suck
[08:05] <owh> I have a file full of them, and I don't even know where to begin. If I could choose "Replace all and keep a backup" then I would.
[08:05] <owh> If that option came with a log, that would be even better.
[08:06] <pwnguin> hmm
[08:06] <owh> At least I'll have whatever the package maintainer thinks is a good config and I can check and fiddle later.
[08:06] <pwnguin> is the GNOME frontend to apt default yet?
[08:06] <owh> Mind you, sometimes the diff picks up spacing changes :(
[08:06] <owh> You mean synaptic?
[08:07] <owh> I'm not sure what you're referring to.
[08:07] <pwnguin> no, i mean like the user query stuff
[08:07] <pwnguin> like "run avahi service?"
[08:07] <pwnguin> dpkg-configure i think
[08:07] <owh> I don't understand the question.
[08:07] <pwnguin> when you upgrade a package, it asks you questions
[08:08] <pwnguin> or even just install it
[08:08] <owh> During the upgrade I was given some dialogs that showed a diff, PHP.ini showed an integrated debconf window, some comments came on the terminal view, nothing was really consistent.
[08:08] <pwnguin> that system has a normal terminal interface, but ive been using the GNOME frontend for ages
[08:08] <owh> The dialogs were just simple "Keep" "Replace" boxes with a diff in the window.
[08:09] <owh> Are you talking about the different ways to interact with the user, that is, via text-only, text dialog, gnome, etc?
[08:09] <pwnguin> yes, i think so
[08:09] <pwnguin> debconf frontends
[08:10] <owh> Yes, we're talking about the same thing.
[08:10] <owh> One mo, answering the door.
[08:10] <owh> As I said: "During the upgrade I was given some dialogs that showed a diff, PHP.ini showed an integrated debconf window, some comments came on the terminal view, nothing was really consistent."
[08:11] <owh> The PHP.ini side-by-side view was a ripper in uselessness.
[08:11] <owh> Example output line: ; such as dynamic images ; such as dynamic images
[08:11] <owh> tidy.clean_output = Off tidy.clean_output = Off
[08:11] <owh> That's two config lines "side-by-side"
[08:12] <owh> Very helpful.
[08:13] <pwnguin> when i get diffs, they show up in a GNOME window with scrollbar and standard +- notation
[08:13] <owh> What I was attempting to do with my email is get beyond specific "bugs" and talk about methodology, but I'm guessing that got lost in translation.
[08:13] <owh> Well, there were those as well, but it wasn't consistent.
[08:13] <pwnguin> no use talking about methodology if you don't practice it
[08:14] <owh> But does that mean you're saying that I need to lodge a bug report for each instance. That seems hardly productive for anyone.
[08:14] <pwnguin> not quite what im saying
[08:15] <owh> Sorry, what were you trying to tell me.
[08:15] <pwnguin> im saying you're walking into u-d-d and demanding changes in what other people do
[08:15] <owh> I suppose I'm trying to poke someone in the eye, yes.
[08:15] <owh> Are you saying that I'm not practicing what I'm preaching?
[08:16] <pwnguin> im saying nobody's going to want to practice your suggested changes if even you don't help with them
[08:16] <owh> I was trying to be constructive about it and attempting to start a discussion.
[08:16] <owh> Fair point.
[08:16] <owh> How do I best help then?
[08:16] <pwnguin> cats, mice and bells
[08:16] <owh> ROTFL
[08:17] <pwnguin> number one would be to identify which of those complaints are upgrade bugs versus regressions
[08:18] <owh> So, my first step would be to write down a list of what broke or what needed attention?
[08:18] <owh> Then I suppose use LP to see what gives.
[08:18] <pwnguin> more importantly, i recall a session at the UDS for hardy
[08:18] <pwnguin> about automating upgrade testing
[08:19] <owh> I'm all ears.
[08:20] <pwnguin> looking for it
[08:21] <owh> Yeah, ditto, found https://blueprints.launchpad.net/sprints/uds-boston-2007/+roadmap
[08:22] <owh> https://blueprints.launchpad.net/ubuntu/+spec/automated-installation-testing
[08:23] <owh> Well the priority is high, it's been approved, but there does not appear to be any content - lovely.
[08:24] <owh> Is that what you were referring to?
[08:25] <pwnguin> im not sure
[08:25] <pwnguin> i may be remembering incorrectly
[08:25] <owh> I think we're agreeing that my email won't help.
[08:26] <pwnguin> i think if you aimed to be a bit more constructive
[08:26] <pwnguin> suggest a UDS session
[08:26] <owh> Suggestions?
[08:27] <pwnguin> narrow down the examples to those that are upgrade bug, and maybe avoid a condescending "we" if you're not a Ubuntu Developer
[08:29] <owh> I'm not a formal Ubuntu Developer, but I am a contributor, have provided bug fixes and attend meetings. Does that not qualify?
[08:29] <pwnguin> which meetings?
[08:29] <owh> ubuntu-server meetings.
[08:29] <pwnguin> physically?
[08:29] <owh> I'm in Australia, run a one-man company, no not physically.
[08:30] <pwnguin> well, if "we" means you're asking to help fix it, go ahead and use "we"
[08:30] <owh> You bet, I'm not dumping this from on high - or low - I intend to assist the process.
[08:31] <owh> But you raise an interesting point which I'll consider.
[08:31] <pwnguin> i mean, there are upgrade bugs
[08:31] <pwnguin> i'd like them gone
[08:32] <owh> You and me both :)
[08:32] <owh> Ok, let me revert my workstation via format/restore from backup, document the bugs and see what gives. How is that as a way forward?
[08:33] <pwnguin> well that would give you a bit stronger position in the email
[08:34] <owh> So, are you saying, keep the email roughly as it stands and attach a proper bug list, or are you saying, start again with a different email?
[08:35] <pwnguin> roughly as it stands. maybe drop the "why should i even bother?" line
[08:36] <owh> Yeah, it would have gone through another filter - the original draft had venom dripping from it - it helped me, but not Ubuntu :)
[08:37] <pwnguin> so what's the recommended upgrade procedure for fedora? ;)
[08:38] <owh> That's not even funny - well, after I recovered from choking from laughing that hard.
[08:38] <owh> It's interesting though.
[08:38] <pwnguin> last i knew it was download the latest iso and reformat
[08:38] <owh> What is the Ubuntu recommended upgrade procedure for ubuntu-server and ubuntu-desktop. Is it the same?
[08:39] <owh> On my deployment servers I build a new VM image and deploy that.
[08:39] <owh> s/deployment/production/
[08:39] <pwnguin> on desktop, they try to beat people into the update manager tool
[08:39] <pwnguin> not sure how that works with server
[08:39] <owh> On the desktop it didn't work for me today - I'm looking forward to the LTS -> LTS upgrade *not*
[08:40] <owh> Fundamentally, config change management is IMHO borked.
[08:40] <Kamping_Kaiser> still at it blokes? *grin*  ( i'm kgoetz )
[08:40] <owh> Yup.
[08:41] <owh> I mean, on the desktop, if you select a number of NTP servers, that might change the config file, but during the upgrade that should resolve itself.
[08:41] <pwnguin> well, almost every app fails to provide a config migration system
[08:41] <owh> So is that the real problem?
[08:42] <owh> I mean, if we identify that as an actual problem, we can go about doing something about it.
[08:42] <owh> s/an/the/
[08:42] <pwnguin> well, i mean, that's what the diffs are for
[08:43] <owh> Yeah, but they still show white-space differences and show diffs for files I never touched.
[08:43] <owh> I suppose that's a bug :)
[08:43] <pwnguin> does it?
[08:43] <pwnguin> i thought there was a way it would handle untouched config files
[08:44] <owh> It did for me. Lemmie see if I can dig up an example.
[08:44] <pwnguin> gentoo actually has a system aside from debconf for etc files
[08:44] <owh> The first four lines from a /etc/pam.d/gdm diff:
[08:44] <owh> -auth	requisite	pam_nologin.so
[08:44] <owh> -auth	required	pam_env.so
[08:44] <owh> +auth    requisite       pam_nologin.so
[08:44] <owh> +auth    required        pam_env.so readenv=1
[08:45] <owh> Line 1 and 3 are the same.
[08:45] <pwnguin> they are not
[08:45] <pwnguin> but they are trivially the same
[08:45] <pwnguin> one uses tabs, the other uses spaces
[08:46] <owh> I'm sure it matters for the config parser :)
[08:46] <pwnguin> if it worked before
[08:46] <pwnguin> it works now
[08:46] <pwnguin> it matters to diff, but not your average config parser
[08:46] <pwnguin> this is an argument for xml ;)
[08:47] <owh> No, my point is, that if I have to make an assessment to see if this change matters, I have to wade through crap to find real changes.
[08:47] <pwnguin> right; xml wouldn't give you that sort of crap
[08:47] <pwnguin> oh, i guess there's also that readenv=1
[08:48] <owh> Yes, so that means that the change is really only "readenv=1", but I cannot glean that by a quick glance. An end user with no programming experience has no chance and I don't recall actually ever changing this file at all.
[08:49] <owh> Mind you, there's a whole different conversation about patches that include config files changed between different maintainers - yuk.
[08:49] <pwnguin> ideally, there'd be an md5 or some other hash to compare with so it knows when you've changed it
[08:49] <Kamping_Kaiser> it seems that using a diff system that can ignore whitespace would save a lot of issues
[08:51] <owh> But that is only one example. Here's another one. In /etc/default/acpi-support, I added mysql, samba and vmware-server to the STOP_SERVICES so my machine would sleep, but then the maintainer has a config that does something with SPINDOWN_TIME=12, here's a pastebin: http://paste.ubuntu-nl.org/59114/
[08:52] <owh> So, now I have a local change that matters and a maintainer change that may matter. What do I choose?
[08:52] <pwnguin> 3 way merge ;)
[08:53] <owh> Sure, but now my grandma is doing the installation - what does she choose :)
[08:53] <kraut> moin
[08:53] <pwnguin> if your grandma can edit conf files, she can read a diff :P
[08:53] <Kamping_Kaiser> owh, why did you grandma edit /etc/default/acpi-support ?
[08:53] <henkjan> hmm, ipv6 autoconfiguration is broken after enabling ipv6 in ufw
[08:53] <owh> Because her grandson came to fix her laptop that didn't sleep.
[08:54] <owh> Here's another, I ticked the box in System Administration to disable Avahi. The config file reflects that, but the new config file has it enabled again.
[08:54] <pwnguin> well the grandma solution is to make sleep work correctly without the file hack, and blind overwrite the config file
[08:55] <owh> Ah, but the sleep fix comes as a bug fix to vmware-server :)
[08:55] <owh> And to mysql for that matter :)
[08:55] <pwnguin> owh: legitmate problem, and you can't propose a policy / procedure fix to that until you know why it happened
[08:56] <pwnguin> well, grandma's getting quite technical
[08:56] <pwnguin> but that's not the point
[08:56] <owh> She's like that :)
[08:56] <owh> No.
[08:56] <pwnguin> the kernel suspend and hibernate stuff is braindead
[08:56] <owh> Oh yeah.
[08:57] <pwnguin> it'll just get worse and worse as we get more cores
[08:58] <owh> So, my proposed "global" fix for all this crap is this. Replace all config files with default installation settings after backing up the existing config file. Log the replacement in an installation log file. In most cases, that will do the right thing. In those cases where it doesn't there is a path back.
[08:59] <owh> I suppose generic machine (perhaps XML) config files is another way to go, but you'd need to track which of those where modified by whom, too hard.
[08:59] <Kamping_Kaiser> you replace every config file on my server/s and i'll kill you ...
[09:00] <owh> Well, have you got a better idea?
[09:00] <Kamping_Kaiser> yes. dont fsck up thousands of servers so a few grandmas dont need to press Y
[09:00] <owh> No, I think you're missing my point.
[09:01] <owh> The challenge is to come up with a mechanism that deals with local change while incorporating new configurations.
[09:02] <owh> I mean, for example change the default pam authentication module across Ubuntu, something which most people wouldn't fiddle with for example.
[09:02] <Kamping_Kaiser> debconf is meant to handle lots of those problems.
[09:03] <owh> Ah, but then its use seems incomplete at best and faulty at worst.
[09:04] <owh> I agree that it should work, but it doesn't appear to.
[09:04] <Kamping_Kaiser> i havent read enough in how it works on a technical level
[09:04] <pwnguin> the thing is, ubuntu sets the debconf to default
[09:04] <pwnguin> so you never get asked questions like "enable avahi?"
[09:05] <pwnguin> it just assumes the answer
[09:05] <pwnguin> it's a tricky balance
[09:05] <pwnguin> surely you've upgraded debian once?
[09:05] <owh> So, then the mechanism that changes that when I tick the box to say "Disable Avahi" isn't updating debconf?
[09:06] <pwnguin> _highly_annoying to sit there for two hours playing "wait for the dialog"
[09:06] <owh> I've upgraded Debian many, many times, why do you think I came to Ubuntu :)
[09:06] <Kamping_Kaiser> --priority=high
[09:06] <Kamping_Kaiser> or --priority=low
[09:07] <owh> Yes, but asking a question 15 minutes into a 2 hour install is a recipe for sitting at the keyboard for another 1 hour 45 minutes afterwards.
[09:07] <owh> Making the installation last 3 hours 45, rather than 2 hours.
[09:07] <owh> Or in my case, 10 hours instead of 2.5 hours.
[09:08] <Kamping_Kaiser> you can complain about to much info, or to little, not both at once ;)
[09:08] <owh> (Only to find bugs that have been open since early December specifically relating to this upgrade :)
[09:09] <owh> You have to realise that this is about manageability. I as a human am impatient and can only manage a few inane questions at a time.
[09:10] <owh> I had a full days work ahead of me this morning, I've done none of it and the system restore will likely take another three to six hours, so if I'm lucky I'll only have lost 24 hours. Likely in reality it will be much more.
[09:11] <pwnguin> isn't this why professionals have a hot spare?
[09:11] <owh> Fundamentally that was what my email was about. It should not be like that. Our user experience should be better.
[09:11] <owh> pwnguin: You mean on a laptop, sure, as soon as IBM supports a normal size drive in the PATA socket :(
[09:13] <owh> Meanwhile, pwnguin, your suggestions were helpful and I'll spend some time incorporating them after I've restored my machine. Thanks for your time.
[09:15] <pwnguin> honestly, i tihnk the level of effort needed to make upgrades painless is something that will probably need money backing
[09:15] <owh> Well, that in itself is a useful observation.
[09:15] <soren> We invite people to help us test upgrades before the release. After release, if upgrade issues arise, it's perfectly likely that sysadmins will have devised workarounds for these issue. If we go ahead and release a new gutsy iso, those workarounds a likely to break. I am not very much in favour of doing anything at all that might break it for happy, current users of gutsy. Troublesome upgrades are bad, but breaking existing setups is inexcusable.
[09:16] <pwnguin> your average college CS student isn't going to bother fixing the upgrade process when they can just as easily work around it and move on with life
[09:17] <owh> soren: So how is one supposed to "prepare" for an upgrade?
[09:17] <soren> TEst it.
[09:17] <pwnguin> heh
[09:17] <pwnguin> in -server no less, this should be expected behaviour ^_^
[09:18] <owh> soren: That assumes a whole level of infrastructure that isn't often there at all. Even in server environments - albeit single server environments.
[09:18] <soren> owh: There's no way we can take everything into account. That's why we rely on the likes of *you* to test stuff so that we can fix it in time *before* release.
[09:19] <soren> It's the curse of providing a flexible, useful system.
[09:19]  * pwnguin wonders whether paying canonical the big bucks makes upgrades easier
[09:19] <owh> So, the best way to do that is to build a virtual server, then upgrade that - of course that won't actually help in the case where the virtual server itself doesn't upgrade.
[09:20] <owh> But it will help.
[09:20] <soren> If all we provided was an OS where all you could change was 5-6 checkboxes and perhaps a hostname, upgrades would be easy. Fortunately, that's not the case.
[09:20] <Kamping_Kaiser> pwnguin, probably paying a few CS students to do testing would be more effective
[09:20] <soren> owh: Virtual servers are certainly handy for testing, yes.
[09:20] <owh> Transferring that to my workstation, I suppose I could have built a virtual copy of my workstation and attempted to upgrade that.
[09:22] <owh> As I said earlier, in production I'd build a new image from scratch and play with that, then once happy, deploy it, but it's pretty hard to do that for a workstation.
[09:22] <soren> It's simple, really. We just need more *real* people, testing this on *real* setups, and telling us about the problems (or better yet: provide patches).
[09:22]  * owh nods.
[09:22] <soren> Upgrades should work.
[09:22] <owh> ROTFL
[09:22] <owh> Sorry.
[09:23] <soren> And in the general case, they do.
[09:23] <soren> !
[09:23] <owh> Yes, it's the edge cases where it breaks.
[09:24] <soren> Indeed. And you you have one of those edge cases, please do yourself and everyone else with similar setups a favour and test things before the release, so that we can fix it.
[09:24] <nijaba> And as soren says, it is NOW that we need testers where the edges are when upgrading from dapper|gutsy -> hardy
[09:24] <soren> AS you have observed yourself, once the release is out, we're unlikely to touch it.
[09:24] <owh> Yes.
[09:24] <soren> ..so you might as well upgrade *before* the release and help us fix issues. There's *very* little point in waiting for months and months.
[09:25] <owh> I have come to that realisation, though I confess that I had enough of "breaking" machines with Debian to want to move to something better - it seems that this might not be possible - just yet.
[09:25] <soren> I'm not saying you should fire up the crack pipe and upgrade to hardy the day after gutsy releases like I do. Right around now would be a reasonable time, though.
[09:26] <owh> That's very funny and I thank you for your humour.
[09:26] <soren> Which part?
[09:26] <pwnguin> crack pipe?
[09:26] <soren> You upgrading now instead of later?
[09:27] <owh> Living on the edge by installing Hardy the day after Gutsy releases.
[09:27] <owh> I suppose I should start with making my Gutsy installation work first, then break it again in Hardy :)
[09:28] <soren> That's what I do. I'd like a "crack" alias for whatever's the current development release. That'd save me the trouble of fiddling with sources.list once every 6 months.
[09:28] <pwnguin> heh
[09:28] <owh> You mean sid :)
[09:28] <pwnguin> more like experimental
[09:28] <soren> Too much confusion :)
[09:28] <pwnguin> but upgrades arent even always stable entry windows till alpha1
[09:28] <soren> Right.
[09:29] <pwnguin> anyways, it'd be nice at least to see some more automated tests on packages
[09:29] <soren> We do a lot of that already.
[09:30] <soren> It's just not very good a exposing all the corner cases.
[09:30] <soren> At all.
[09:30] <pwnguin> where are the reports hiding at, exactly?
[09:30] <soren> pwnguin: I'm not sure.
[09:31] <owh> soren: To deal with corner cases perhaps we should find a way to "capture the essence" of a system, that is, the installed packages, their configurations and then automatically upgrade an image of such a machine.
[09:31] <owh> Something like dpkg --get-selections.
[09:31] <pwnguin> i say just keep a set of images around
[09:31] <owh> Together with a copy of /etc
[09:31] <soren> owh: I don't think that'll do much good.
[09:32] <soren> owh: In fact, I think we do that already (install a random set of packages, test upgrade, rinse, repeat).
[09:32] <owh> But my machine isn't random. I selected a whole set of packages to get something done. For some reason - or many - the upgrade is painful.
[09:33] <owh> Capturing that isn't likely to be trivial, but I think it may be doable.
[09:33] <soren> owh: You claim to have never touched a configuration file?
[09:35] <owh> No, I claim that in many cases I've not touched a configuration file, but the upgrade process is still offering it to me. In a few cases I specifically edited a config file. In those cases sometimes a three way merge is needed. The vast majority of cases I did not touch the config.
[09:35] <owh> I captured most if not all of the prompts during the upgrade.
[09:36] <soren> If you haven't touched a config file and you're prompted about changes to it, that's a bug.
[09:36] <soren> No doubt.
[09:36] <owh> There were many.
[09:37] <soren> Please file bug reports.
[09:37] <soren> Otherwise, we'll never fix it :)
[09:37] <owh> Fair enough.
[09:37] <soren> pwnguin: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/
[09:37] <owh> That's a project for the morning.
[09:37] <pwnguin> i knew there was one
[09:38] <pwnguin> i couldn't find a blueprint for it or a UDS meeting
[09:38] <owh> Gotta run. Later all. Thanks for the input.
[09:38] <soren> https://blueprints.edge.launchpad.net/ubuntu/+spec/auto-dist-upgrade-testing
[09:39] <pwnguin> ah, i was looking at the wrong release
[09:45] <NineTeen67Comet> Help .. this morning at 6:03 the outside world can no longer see my web server. I've checked with my dns server (afraid.org), rechecked my router (Linksys WRT54GS), re-checked my server (apache2) and I'm out of ideas on where to track the loss of connection (I can get out from my server for aptitude updates, pings etc) ..
[09:46] <nijaba> NineTeen67Comet: what's the URL of your web site?
[09:46] <NineTeen67Comet> If I use the IP address (outside) it will access my main sites (default VirtualHost) site, but all the links are broken since they are URL links.
[09:46] <NineTeen67Comet> http://www.openlug.com (one of 11 on the server)
[09:46] <NineTeen67Comet> Outside IP is 122.145.71.123
[09:47] <nijaba> hmmm...  it resolves to 122.145.71.122
[09:48] <NineTeen67Comet> That's what I see too .. but when I use a "what's my ip" service it is 122.145.71.123 .. even afraid.org has this correct ip address...
[09:49] <NineTeen67Comet> Who/what/where and how is that incorrect? .. sigh and I thought today was going to be a home work day .. lol
[09:50] <NineTeen67Comet> Could it be GoDaddy (my registrar) being told to send my URL addresses to another dns server?
[09:51] <nijaba> NineTeen67Comet: check your DNS entry for www and ensure that you are pointing to the right address
[09:52] <NineTeen67Comet> Looks like it .. I've got 6 sites with afraid.org and they are all grouped with this IP address (even www, ftp., irc. and the URL w/out www) .. my subdomains too ..
[10:39] <Jeeves_> Hi all!
[10:54] <Jeeves_> Is anyone here interested in a installtest for Hardy on a Sunfire T1000 and a Sunfire X4500?
[10:54] <Jeeves_> I'm going to produce these this week, I think
[10:55] <Kamping_Kaiser> Jeeves_, i'm intereste in trying a T1000 this week.
[10:55]  * Kamping_Kaiser should have done it last week, so this week works for me
[10:57] <Jeeves_> Kamping_Kaiser: I'll let you know when I get one
[10:57] <Kamping_Kaiser> Jeeves_, cool. you likely to get one in the next week?
[10:57] <Jeeves_> Kamping_Kaiser: It should ship tomorrow
[10:58] <Jeeves_> I think it'll be thursday
[10:58] <Kamping_Kaiser> 60day trial?
[10:58] <Jeeves_> Yes
[10:58] <Jeeves_> I'm going to run the Hardy release on two T1000's and a X4500
[10:58] <Kamping_Kaiser> we are closing in on day 20 of ours
[10:58] <Jeeves_> (We run nl.archive)
[10:58] <Kamping_Kaiser> so putting ubuntu on this week would be handy
[10:59] <Jeeves_> Kamping_Kaiser: I'll try to get it done
[10:59] <Kamping_Kaiser> Jeeves_, whats your timezone?
[10:59] <Jeeves_> https://weblog.bit.nl/files/2008/03/ubuntu-setup.png
[10:59] <Jeeves_> Kamping_Kaiser: .nl (ehm, GMT+0100?)
[11:00] <Kamping_Kaiser> hm.
[11:00] <Kamping_Kaiser> thats 8/9 hours different to me, which is perfectly aquard for going through it together
[11:00] <Jeeves_> :)
[11:00] <Jeeves_> Ehm
[11:01] <Jeeves_> So. It would be ok if I were really early, right?
[11:02]  * Jeeves_ isn't very great with timezones :)
[11:02] <Kamping_Kaiser> i'm +10.30 am i think (usually +9.30)
[11:03] <Kamping_Kaiser> i need to work out the netinstall infrastructure too
[11:03] <Jeeves_> Kamping_Kaiser: I'm working very early thursday
[11:03] <Kamping_Kaiser> its been quite a while since i netinstalled a sun, and we dont have the infrastructure to do it at work :(
[11:03] <Jeeves_> So if I'm awake at 05:00 AM, that would be ok for you, right?
[11:04] <Kamping_Kaiser> Jeeves_, yes that would. i can stay at work until ~8.30pm my time, which is roughly 12:00 mid day your time (i think)
[11:05] <jdstrand> henkjan: what version of ufw?
[11:06] <Kamping_Kaiser> http://www.timeanddate.com/worldclock/city.html?n=5
[11:07] <henkjan> jdstrand: 0.13
[11:07] <henkjan> jdstrand: should be some default icmp handling
[11:07] <Jeeves_> Kamping_Kaiser: Coolio. We can play than :)
[11:07] <Kamping_Kaiser> Jeeves_, :)
[11:08] <Kamping_Kaiser> Jeeves_, do you have existing netinstal infrastructure setup? or do you have a "best" reference i should look at?
[11:08] <jdstrand> henkjan: can you file a bug report with what used to work, what doesn't and what it will take to get it to work again?
[11:08] <Jeeves_> Kamping_Kaiser: We have a pxe-booting infra
[11:08] <jdstrand> henkjan: I hope to upload a new version today, and if the changes are small, I can get them in
[11:08] <Jeeves_> No hardy support yet
[11:09] <Jeeves_> And no sparc-support either
[11:09] <henkjan> jdstrand: i'm looking at wich icmpv6-types are needed for proper ipv6 autoconfiguration
[11:09] <jdstrand> henkjan: before filing though, try 0.14
[11:09] <Jeeves_> Kamping_Kaiser: And I hope we have it by thursday
[11:09] <jdstrand> henkjan: (it's in the archive already)
[11:09] <Kamping_Kaiser> Jeeves_, ah ok. i had a PITA of a time to get my sunblades installed. i'll try to get working sparc infra at work pre thursday
[11:10] <jdstrand> henkjan: and IIRC, you are on gutsy? 0.14 should work much better on gutsy
[11:10] <jdstrand> henkjan: but if you still have a problem, please file a bug report and I'll get it fixed
[11:13] <henkjan> jdstrand: okay, ill first check with the 0.14 version
[11:15] <jdstrand> henkjan: great! please let me know how 0.14 works out for you (good or bad)
[11:20] <henkjan> hmm, unpacking http://nl.archive.ubuntu.com/ubuntu/pool/main/u/ufw/ufw_0.14.tar.gz gives an ufw-0.13 directory
[11:21] <zul> morning
[11:21] <jdstrand> henkjan: check the changelog
[11:21] <soren> henkjan: Use "apt-get source ufw" instad
[11:22] <soren> henkjan: Or even better: Use bzr (but apt-get source will tell you this, IIRC)
[11:23] <jdstrand> henkjan: yes, apt-get source works fine
[11:24] <jdstrand> soren: that is odd though-- the tarball is 0.13.
[11:24] <henkjan> i did an apt-get source on an hardy, and that gives me an ~/ufw-0.14/
[11:24]  * jdstrand nods
[11:24] <soren> jdstrand: apt-get source renames it for you :)
[11:25] <soren> jdstrand: Well... dpkg-source does, actually.
[11:25] <henkjan> ah, okay
[11:25] <jdstrand> soren: I was just curious why it was that at all
[11:25] <jdstrand> soren: I did a bzr export
[11:25] <jdstrand> maybe I need to look at that command some more
[11:25] <soren> jdstrand: Oh? You don't need to do that.
[11:26] <jdstrand> soren: do tell
[11:26] <jdstrand> I am in 'trunk'
[11:26] <soren> jdstrand: Just pass -I to dpkg-buildpackage, and it'll leave out .bzr
[11:26] <soren> (I assume that's why you do the export)
[11:26] <jdstrand> yes
[11:27] <soren> Ok. Well, just pass -I to dpkg-buildpackage instead and you should be all set.
[11:28] <soren> (if it's not a native package, you probably want -i instead, just FYI)
[11:58] <fujin> I'm looking for a better CLi email client than Mutt, Anyone suggest one?
[11:58] <fujin> too many nubs in #ubuntu
[12:03] <_ruben> hehe
[12:03] <zul> pine?
[12:20] <henkjan> whats wrong with mutt?
[12:23] <faulkes-> henkjan: try asking it to talk directly to exchange when sending mail and requiring authentication ;
[12:23] <faulkes-> otherwise, it's my favourite
[12:27] <Jeeves_> Kamping_Kaiser: I just heard that the T1000's are in
[12:28] <Kamping_Kaiser> Jeeves_, niiice :)
[12:28] <Kamping_Kaiser> Jeeves_, i'll be taking a SunBlade150 to work to act as a test unit for doing netinstalls
[12:29] <Kamping_Kaiser> hopefully that means i'll be able to do $stuff with the blade in a few days (unless we work ourselves out quick
[12:29] <Kamping_Kaiser> )
[12:32] <Jeeves_> Kamping_Kaiser: I'll try to boot it tomorrow afternoon
[12:32] <Kamping_Kaiser> Jeeves_, ok. thats tomorow night for me, so i'll probably be here :)
[12:36] <Jeeves_> :)
[13:38] <youngmusic> Very strange thing happening here: I got a server that reboots about every 5 minutes. There's nothing in the logs, and it even happens in single user mode. It's not a clean reboot either, just a power-off and the machine restarting. I begin to suspect a hardware problem, but does anyone know of other possibilities?
[13:44] <faulkes-> depends if it's happening at regular 5min to the second intervals
[13:44] <faulkes-> however, just "about" every 5 min, could be a heat issue, perhaps a dead fan for the cpu's
[13:44] <youngmusic> no, not that strict. It can be 2 minutes or 10 minutes also
[13:45] <youngmusic> yes, good idea. Iĺl check that out
[13:47] <Jeeves_> youngmusic: What kind of machine is it?
[13:51] <youngmusic> it was a bit dusty in there, but all fans are working. The cpu has passive cooling. It's also an airconditioned server room, so temperature should be safe
[13:52] <Jeeves_> youngmusic: Does it have ilom or something?
[13:52] <youngmusic> Jeeves_:  It's a dell poweredge, about 5 years old
[13:52] <youngmusic> ilom?
[13:53] <Jeeves_> Yes, or some kind of logging
[13:53] <Jeeves_> check the BIOS for SEL of BCM stuff
[13:53] <youngmusic> there's syslog
[13:53] <youngmusic> messagebus
[13:54] <youngmusic> (oops, I just realize that particular server still runs on fedora, not ubuntu. I hope that's not a big problem?)
[13:54] <youngmusic> \
[13:54] <youngmusic> (being on the wrong forum, that is)
[13:55] <Kamping_Kaiser> youngmusic, you'll need to ask #fedora
[13:55] <Jeeves_> youngmusic: I mean hardware logging
[13:55] <Jeeves_> Not linux-logging
[13:56] <youngmusic> ah, no i don't think it has something like that
[13:56] <Jeeves_> ok
[13:57] <faulkes-> is it managed via drac or?
[13:57] <faulkes-> or any of dell's management tools?
[14:05] <youngmusic> seems there was a utility partition, but its erased. (the server was installed before my time)
[14:06] <youngmusic> Jeeves_:  in the bios itself, there is no logging.
[14:09] <youngmusic> i 'm gonna try and find a diagnostic disk
[14:09] <coffeedude> dendrobates: morning.
[14:10] <dendrobates> coffeedude: morning
[14:26] <kris_ph> hello.. how remove nagios and its configuration.. everything.. since I want to reinstall it
[14:26] <Kamping_Kaiser> kris_ph, apt-get --purge remove nagios
[14:26] <Kamping_Kaiser> plus any relevent packages
[14:27] <kris_ph> I got this error: Package nagios is not installed, so not removed
[14:27] <kris_ph> but it is installed..
[14:28] <kris_ph> I followed the steps/guide by ubuntu geek
[14:28] <Kamping_Kaiser> perhaps its called something else
[14:28] <Jeeves_> dpkg -l | grep nagios ?
[14:30] <zul> hi mathiaz
[14:30] <kris_ph> dpkg -l | grep nagios <<< but no output.. it simply goes back to the terminal line..
[14:32] <kris_ph> I followed this guide to install it.. http://www.ubuntugeek.com/nagios-network-monitoring-system-setup-in-ubuntu.html
[14:33] <zul> mathiaz: survivied the snowfall?
[14:35] <nijaba> kris_ph: you compiled nagios and installed it yourself.  Normal that it is not seen as a package
[14:35] <kris_ph> nijaba: yeah..
[14:35] <nijaba> kris_ph: to remove, you now have to do it by hand...
[14:36] <kris_ph> nijaba: okay.. what will I do then?
[14:36] <kris_ph> nijaba: this must be a mess.. I read somewhere in the forum (ubuntu)..pointing me to ubuntugeek.
[14:37] <nijaba> kris_ph: look at the install part of your make file and check where the bits and pieces have been installed, then write to the ubuntugeek writer, asking that a warning be placed on this howto
[14:37] <kris_ph> nijaba: I just discovered this: https://help.ubuntu.com/community/Nagios2 which I want to follow
[14:38] <nijaba> kris_ph: look at the first comment on the ubuntugeek how to...  the reply is "because I want to have the latest version".
[14:38] <kris_ph> nijaba: is there a way to do it?
[14:38] <nijaba> kris_ph: nothing simple, no.
[14:38] <kris_ph> nijaba: uhuh... any recommendation to undo this? I have file manager installed in my box.. I could easily view files in graphical...
[14:39] <nijaba> kris_ph: as I said, look at the install part of the make file you invoke to install it in the first place
[14:39] <nijaba> kris_ph: that is the only way to tell where bits an pieces have gone
[14:40] <kris_ph> nijaba: how to see it?
[14:40] <kris_ph> nijaba: where could I find it?
[14:40] <nijaba> kris_ph: in the directory where you uncompressed the tarball you downloaded
[14:42] <kris_ph> nijaba: ows.. can i simply delete those subfolders under nagios?
[14:44] <nijaba> kris_ph: I am posting the following comment on this blog: Could you please put a HUGE warning at the top of this how to to warn people that installing a package using this method is not the recommended way to do things and should be reserved to experts that will not have trouble uninstalling it by hand?  Thanks a lot."
[14:44] <nijaba> kris_ph: unfortunately I will not be able to drive you on this...
[14:45] <kris_ph> nijaba: are you one of the developers for ubuntu?
[14:46] <kris_ph> nijaba: how about installing the guide located in https://help.ubuntu.com/community/Nagios2 ? would it overwrite it?
[14:47] <nijaba> kris_ph: I am doing the product management, but others on this channel are the dev.
[14:47] <kris_ph> nijaba: thank you.. I must believe you..
[14:47] <nijaba> kris_ph: you can try, but that may lead to inconsistencies
[14:48] <faulkes-> heya nijaba
[14:48] <nijaba> hello faulkes-
[14:48] <kris_ph> nijaba: how to remove this one.. ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios?
[14:48] <kris_ph> hello faulkes. M glad you're back.. I'm sure you can help me with this..
[14:52] <nijaba> kris_ph: "sudo rm /etc/rcS.d/S99nagios" should do the trick.  You can also use update-rc.d
[14:54] <kris_ph> nijaba: thanks.. do I need to run update-rc.d too ?
[14:58] <faulkes-> hrmm, now to see about remotely installing -server via drac onto this 1955 blade
[14:58] <faulkes-> should be lots of fun I imagine
[14:58] <nijaba> kris_ph: no you do not, but using it can help you remove all references to nagios in the init.d scripts
[14:59] <kris_ph> nijaba: thank you.. so..all I need now is to execute to stop the service right? and install it acco to ubuntu guide
[15:25] <faulkes-> zul: is there a ebox-mail component in the works?
[15:26] <zul> faulkes-: not that I know of, the ebox guys were still working with it and it doesnt use dovecot or postfix
[15:26]  * faulkes- nods
[15:26] <faulkes-> question was posted in the forum thread, I'll reply to it
[15:29] <mathiaz> kirkland: wrt bug 39157, rather than giving a detailed explanation on how-to create a debdiff, I'd suggest to give links to documentation on wiki.ubuntu.com (eg: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff)
[15:31] <kirkland> mathiaz: good idea
[15:31] <kirkland> mathiaz: done.
[15:33] <zul> mathiaz: im doing the samba upload later today
[15:34] <mathiaz> kirkland: most of the packaging questions should have an answer in the packaging guide - https://wiki.ubuntu.com/PackagingGuide/
[15:34] <kirkland> mathiaz: i see
[15:35] <sommer> mathiaz: hello, I ran into an issue with slapd and apparmor this weekend
[15:35] <mathiaz> kirkland: it used to be a docbook guide maintained by the doc team
[15:35] <mathiaz> kirkland: but now it has been moved to the wiki so that anyone can edit it.
[15:35] <sommer> mathiaz: slapadd/slapcat can't save or import when in enforce mode
[15:35] <mathiaz> kirkland: dholbach has been responsible for the migration and would welcome any comments on that
[15:36] <mathiaz> sommer: do you see any error messages ?
[15:36] <faulkes-> mathiaz: for x64 intel -server, which iso would I want to grab?
[15:36] <mathiaz> sommer: I mean audit messages
[15:36] <sommer> yep, it has to do with the ldif file
[15:36] <faulkes-> gonna see about testing a5 on a dell 1955 blade
[15:36] <sommer> if you add the ldif file to usr.sbin.slapd it will work
[15:36] <mathiaz> faulkes-: you can try -amd64
[15:36]  * faulkes- nods
[15:36] <mathiaz> faulkes-: -i386 should also work
[15:36] <faulkes-> kk
[15:37] <faulkes-> yeah, but 4 x64 cpu's and 4gb of ram, I'll go with x64 first try
[15:37] <sommer> is their a way for the profile to recoginze *.ldif?
[15:37] <mathiaz> sommer: meh.. wired
[15:37] <zul> damn 'puter
[15:38] <mathiaz> sommer: slapadd and slapcat should run whith slapd stopped
[15:38] <sommer> mathiaz: correct
[15:38] <mathiaz> sommer: as they modifies the backend db directly
[15:38] <mathiaz> zul: have you seen the new upload from steve this weekend ?
[15:39] <mathiaz> zul: they're also preparing an upload for 3.0.28a that has been released over the we
[15:39] <zul> mathiaz: yep Im using it as a pase
[15:39] <zul> base even
[15:39] <zul> hmmm...maybe we should wait then
[15:40] <mathiaz> zul: it may worth sending them all the relevant patches and make sure they can be part of 3.0.28a
[15:40] <mathiaz> zul: also I'm not sure which one are relevant to Debian.
[15:40] <zul> mathiaz: I can do that
[15:40] <zul> I think the winbind files one and the documentation fixes
[15:41] <mathiaz> zul: for the documentation fixes, I'm not sure that it will get accepted. steve grumbled when I mentionned the bug last week
[15:41] <mathiaz> zul: but it's worth a try
[15:42] <zul> Ill go through the svn see what they have
[15:42] <mathiaz> zul: you may also check with steve for a FFexception
[15:42] <zul> sure
[15:43] <sommer> mathiaz: stopped or started when using slapadd/slapcat the apparmor error still happens
[15:44] <sommer> mathiaz: here's the error message from slapcat: http://paste.ubuntu-nl.org/59142/
[15:44] <zul> mathiaz: I have to bug slangslek about some ebox stuff anyways so Ill bring it up with anyways
[15:47] <dantalizing> mathiaz: regarding the openvz info you asked me to document, was there specific info you wanted?  i put an initial page up here: http://wiki.ubuntu.com/OpenVZ
[15:48] <ubotu> Launchpad bug 39157 in samba "Samba initscript does not conform to the LSB Spec." [Low,Confirmed] https://launchpad.net/bugs/39157
[15:49] <faulkes-> oki's, went for a6 to test out, we'll see how that goes
[15:52] <kirkland> the map where you select your timezone on installation, is that provided by tzdata?
[15:53] <iclebyte> having trouble getting my head around ubuntu's method of using virtual hosts.. i've created 2 entries in /etc/apache2/sites-available one called iclebyte.ubuntu1 and one called dotproject.ubuntu1 both have been enabled and the symlinks are listed in sites-enabled however only the iclebyte.ubuntu1 vhost works. the dotproject.ubuntu1 vhosts points to the default pages...
[15:53] <iclebyte> any ideas?.. i'm not getting anything in the logs thats helpful
[15:53] <\sh> iclebyte: you need to enable them in sites-enabled via a symlink from sites-available
[15:54] <iclebyte> thats what i said i've done..
[15:54] <iclebyte> " the symlinks are listed in sites-enabled"
[15:54] <iclebyte> but only the first vhost is working..
[15:54] <\sh> iclebyte: can you pastbin both vhost configs pls?
[15:55] <iclebyte> yup 1 sec
[15:56] <mathiaz> sommer: you've got this error message even when slapd is not running ?
[15:56] <iclebyte> http://pastebin.com/d761bca7d
[15:56] <sommer> mathiaz: correct
[15:56] <\sh> iclebyte: where is your namevirtualhost directive?
[15:57] <mathiaz> zul: great - although I don't think we'll need a FFe for 3.0.28a as this is a bug-fix only release. But mention it just to be sure.
[15:57] <mathiaz> sommer: that is ... strange
[15:57] <iclebyte> \sh, I read on a forum somewhere that it should only be in the 'default' vhost file..
[15:57] <\sh> iclebyte: hehe...
[15:57] <\sh> iclebyte: if the default file is not enabled, you don't have one
[15:58] <mathiaz> jdstrand: have you test slapdcat/slapadd when generating the slapd profile ? See the backlog for sommer problem
[15:58] <\sh> iclebyte: you need to add somewhere NameVirtualHost *
[15:58] <iclebyte> the default host is enabled ....
[15:58] <sommer> mathiaz: I thought so, if you add the ldif file to /etc/apparmor.d/usr.sbin.slapd with "w" or "r" depending it works fine (after reloading the profile)
[15:59] <\sh> iclebyte: hmm...what says error log?
[15:59] <mathiaz> dantalizing: great - that's a good starting point. Could you document a little bit more what is available in hardy ?
[15:59] <\sh> iclebyte: and btw...your entry "serveralias"..you don't need it with the same name as ServerName...
[16:00] <dantalizing> mathiaz: will do
[16:01] <iclebyte> do i need the serveralias entry atall?
[16:01] <iclebyte> i seem to have fixed it now ... some how.. thanks for your time anyway! =)
[16:01] <mathiaz> dantalizing: could you also list the how-to pages on help.ubuntu.com ?
[16:02] <mathiaz> dantalizing: a first task would be to update the how-to pages to make them relevant for hardy.
[16:02] <\sh> iclebyte: nope....you need it only for e.g. "ServerName www.yourdomain.tld" and you want to point "yourdomain.tld" to the very same webspace..
[16:02] <dantalizing> mathiaz: k
[16:02] <iclebyte> oh right.. that doesnt really apply on my virtual machines then =P. cheers for your help though dude.
[16:03] <mathiaz> dantalizing: if the kernel has openvz enabled, it should be much easier to get started with openvz in hardy
[16:03] <\sh> iclebyte: you're welcome
[16:03] <dantalizing> mathiaz: yes
[16:05] <dantalizing> mathiaz: what i dont understand is what is "a separate flavour (of the kernel) via the debian/binary-custom.d/ infrastructure"
[16:05] <dantalizing> this is where ben told the openvz devs the patches would be applied....if i'm using the right terminology
[16:06] <dantalizing> i've downloaded and built the kernel with the patches, so i know its in, i just dont know how that translates to a universe package, or where to see the end result
[16:10] <mathiaz> dantalizing: which kernel did you download ?
[16:10] <dantalizing> from git, ubuntu/ubuntu-hardy
[16:10] <mathiaz> dantalizing: looking at the ubuntu-hardy git tree, I don't see any openvz flavour in debian/binary-custom.d/
[16:11] <dantalizing> mathiaz: it was just loaded friday, could that be the reason?
[16:12] <mathiaz> dantalizing: well - I'm looking at gitweb on kernel.ubuntu.com
[16:12] <mathiaz> dantalizing: I haven't done a git checkout of the kernel tree
[16:13] <mathiaz> dantalizing: did you see an openvz flavour in debian/binary-custom.d/ ?
[16:13] <zul> yeah I dont see it anywhere either
[16:13] <dantalizing> mathiaz: lemme check my laptop at home
[16:13] <mathiaz> dantalizing: There is a xen directory in there - I'd expect an openvz there too.
[16:14] <dantalizing> like i said, i didnt konw what to look for so i did close and just grepped for some of the patch code
[16:16] <dantalizing> mathiaz: its quite possible i misunderstood the exchange, shall i fwd you the email i'm looking at?
[16:16] <mathiaz> dantalizing: hum. Reading through the changelogs, I don't see any references to openvz
[16:16] <mathiaz> dantalizing: sure
[16:19] <dantalizing> mathiaz: done
[16:21] <mathiaz> dantalizing: ok - read throught it.
[16:22] <mathiaz> dantalizing: the patches haven't been loaded in the kernel yet.
[16:22] <dantalizing> ic
[16:22] <mathiaz> dantalizing: you may drop by #ubuntu-kernel to ask what's going on the openvz front.
[16:23] <dantalizing> ok
[16:23] <mok0> ping soren
[16:23] <nijaba> mathiaz: I thought that an OpenVZ kernel was going to be put in universe, not that we would have it in our kernel
[16:23] <mathiaz> nijaba: that is the case
[16:24] <mathiaz> nijaba: there will be an -openvz the same way as -xen flavour
[16:24] <mathiaz> nijaba: but the source is included in our kernel tree
[16:24] <dantalizing> where do i find debian/binary-custom.d/ ? a subdirectory of the kernel source?
[16:24] <nijaba> mathiaz: ok, I did not get that part, sorry...
[16:25] <mathiaz> dantalizing: yes
[16:25] <mathiaz> dantalizing: at the top of the tree, there is a debian/ directory
[16:26] <dantalizing> i knew that....er... not
[16:26] <dantalizing> mathiaz: ok, i'll not assume we have a -openvz flavor yet with the documentation
[16:27] <mathiaz> dantalizing: well - it seems that ben said he would accept the openvz patches.
[16:27] <mathiaz> dantalizing: so I'll try to figure out what's hapening on that front
[16:28] <dantalizing> mathiaz: you still want me to ask in #ubuntu-kernel, or wait?
[16:28] <mathiaz> dantalizing: I'd ask in #ubuntu-kernel.
[16:28] <mathiaz> dantalizing: if openvz will be available in the next upload, I'd wait a bit for updating the documentation
[16:29] <mathiaz> dantalizing: once there is a -openvz flavour in hardy universe, it will be easier to get things tested and update the documentation.
[16:30] <dantalizing> mathiaz: ok
[16:46] <jdstrand> mathiaz, sommer: I am awaer of the slap* apparmor stuff and need to think about the fix more. I can say that redirecting slapcat's stdout works fine
[16:49] <sommer> jdstrand: cool, thanks
[16:54] <zul> sommer: there should be a whole bunch of ebox fixes this week hopefully as well
[16:54] <sommer> sweet, I wrote up the ebox section to the docs, but haven't committed it yest
[16:55] <sommer> yet even... probably will this evening after another proof read
[17:13]  * faulkes- watches alpha6 install via dsl to the colo via drac
[17:14] <faulkes-> interesting little process
[17:15] <faulkes-> and given my new employer seems cool with me testing out ubuntu alpha's on our hardware so I can repot back to ServerTesting, kinda cool
[17:26] <sommer> I want a colo drac :-)
[17:27] <sommer> sounds like a new energy drink... heh
[17:27] <mruiz> hi all
[17:27] <sommer> hey
[17:30] <faulkes-> heh
[17:30] <faulkes-> if it's gonna be a drink, it's going to have alcohol in it
[18:02] <brewmaster> is there a netinstall for kubuntu similar to debian?
[18:03] <brewmaster> i'm trying to install on a friend's comp but I think his CD rom is bugging out
[18:03] <brewmaster> hangs at random %'s during the final step of the install
[18:10] <Centaur5> brewmaster: https://help.ubuntu.com/community/Installation/QuickNetboot
[18:18] <brewmaster> Centaur5, thanks, I'll give it a try
[18:19] <brewmaster> "There should be no other DHCP servers running in the subnet"
[18:19] <brewmaster> what about my router?
[18:23] <Centaur5> Then you'll have problems if the client gets an IP from your router instead of the server.
[19:18] <sdrowkcab> hello
[19:18] <zul> mathiaz: im going to upload samba since there is no eta for 2.0.28a
[19:19] <sdrowkcab> what hapens when you install a LAMP server?
[19:19] <nxvl> hi all!
[19:20] <nxvl> what's the efforts focused on in this part of the development circle?
[19:20] <sdrowkcab> When I install a LAMP server will it install the standard ubuntu server plus apache etc.?
[19:20] <sommer> sdrowkcab: yeppers
[19:21] <zul> nxvl: bug fixing
[19:21] <sdrowkcab> So it just saves the hasle of doing it manualy?
[19:21] <nxvl> zul: only bug fixing?
[19:21] <zul> nxvl: pretty much..
[19:22] <mathiaz> nxvl: there is a lot of stuff that needs attention
[19:22] <sommer> sdrowkcab: yep, but if you don't want mysql for instance you'd probably want to install the packages by themselves
[19:23] <sdrowkcab> I want to set up a game server plus web server so I think I should go for LAMP. right?
[19:24] <nxvl> mathiaz: a lot of stuff as in a lot of bugs?
[19:24] <sommer> sdrowkcab: sure, there's a ton of info regarding the LAMP stack if you're just starting out
[19:24] <mathiaz> nxvl: yes
[19:25] <nxvl> mathiaz: ok, i will take a look at some bugs :D
[19:25] <sdrowkcab> I allready have ubuntu and xubuntu I just wanted to know the difference between LAMP and non-LAMP installation
[19:25] <sdrowkcab> thanks
[19:25] <sdrowkcab> btw Is ubuntu server better than freeBSD?
[19:26] <sommer> oh ya, bsd isn't even linux :-)
[19:26] <mathiaz> nxvl:  I've come accross the tiny-erp package
[19:26] <mathiaz> nxvl: https://bugs.launchpad.net/ubuntu/+source/tinyerp-server/
[19:26] <sommer> heh... I think it's more what you want to do with it that really matters
[19:26] <mathiaz> nxvl: there seems to be a couple of bugs that are easy to fix
[19:26] <nxvl> btw, is there any efforts already on writting a centralized adminstration console for common services?
[19:26] <nxvl> mathiaz: thnx :D
[19:27] <sommer> nxvl: I'm not sure if this is exactly what you're looking for, but it's an interesting project: https://hosted.fedoraproject.org/func/
[19:27] <mathiaz> nxvl: no. That wouldn't be appriopriate for the current release cycle.
[19:27] <mathiaz> nxvl: but something that could be discuss at the next UDS
[19:28] <mathiaz> nxvl: you should register a blueprint if you're interested in that.
[19:28] <nxvl> mathiaz: thats what i meant, i want to go to the UDS with something started
[19:30] <mathiaz> nxvl: well - if you're interested in this topic, starting to do some background research and drafting a spec is a good step to take
[19:31] <nxvl> zul: btw, did you take a look at the smb.conf(5) patch i upload?
[19:31] <zul> nxvl: yes its in there
[19:32] <nxvl> mathiaz: yep, i will (want to) start some research, drafting and start some develop before UDS
[19:34]  * faulkes- prepares ServerTesting template
[19:35] <nxvl>  /j ubuntu-driver
[19:35] <nxvl> sorry about that :P
[19:35] <soneil> nxvl: good luck .. something I'd love to see, but always seems to meet opposition (the old "real admins use nipple clamps" argument )
[19:36] <nxvl> soneil: yes, the problem with server developing is that the "users" are people who actually knows what thay are doing and want to have the total control os their systems
[19:37] <nxvl> soneil: but i have some ideas that maybe can work
[20:17] <sommer> mathiaz, jdstrand, lamont: not sure who should handle this, but I just noticed that the bind9 apparmor profile is named apparmor-profile...
[20:18] <lamont> sommer: sigh.  what should it be named>?
[20:18] <jdstrand> sommer: in the packaging
[20:18] <sommer> probably usr.sbin.named
[20:18] <jdstrand> sommer: when installed its usr.sbin.named isn't it?
[20:18] <sommer> not from the package I just installed
[20:18] <lamont> -4 changed it
[20:18]  * jdstrand goes checks on that
[20:18] <lamont> -6 will have the fix
[20:18] <jdstrand> lamont: oh-- you changed it? ok then
[20:19] <jdstrand> lamont: yes, it the absolute path to the binary it protects, with '/' replaced with '/'
[20:19] <lamont> with .
[20:19] <jdstrand> haha
[20:19] <jdstrand> '/' with '.'
[20:19] <sommer> heh... thanks lamont
[20:19] <jdstrand> so yes, usr.sbin.named
[20:19] <lamont> sommer: is there a bug open for this?
[20:20] <sommer> lamont: don't think so I just discovered it going over the docs
[20:20] <sommer> I can file one if you'd like
[20:20] <lamont> the sad? part is that I _just_ uploaded -5
[20:20] <lamont> sommer: sure.
[20:20] <sommer> ok, will do
[20:20] <lamont> that'll give me something to request the sync against. :-)
[20:26]  * lamont waits for a bug number so that he can commit and upload
[20:26] <sommer> lamont: Bug #200739 filed
[20:26] <ubotu> Launchpad bug 200739 in bind "bind9 apparmor profile is named apparmor-profile" [Undecided,New] https://launchpad.net/bugs/200739
[20:27]  * lamont migrates the bug to bind9 where it belongs
[20:28] <sommer> woops
[20:42] <lamont> -rw-r--r-- root/root       587 2008-03-10 14:36 ./etc/apparmor.d/usr.sbin.named
[20:52] <sommer> lamont: should the bind user have write access to /etc/bind ?
[20:52] <jdstrand> sommer: it needs it for dynamic updates
[20:53] <lamont> sommer: not generally, no
[20:53] <sommer> jdstrand: ya, I noticed that
[20:53] <lamont> 2755 root:bind
[20:53] <jdstrand> sommer: but the DAC (ie unix permissions) are still enforced
[20:53] <jdstrand> sommer: so even though the apparmor doesn't stop it, the DAC will
[20:54] <jdstrand> s/apparmor/apparmor profile/
[20:54] <sommer> so if I have a master - slave scenerio /etc/bind should be 2755 bind:bind ?
[20:54]  * lamont can hardly wait for hardy, so he can turn on selinux instead of apparmor
[20:54] <jdstrand> 2775
[20:54] <lamont> I'd use /var/lib or /var/cache for secondary stuff
[20:54] <lamont> and/or updates
[20:54] <lamont>  /etc shouldn't be writable by the bind user
[20:55] <lamont> sadly, the jnl files go in the same place as the zone data, which hurts
[20:55] <jdstrand> lamont: ideally no, but journal files get written wherever the zone file are
[20:55] <jdstrand> oh-- yes
[20:55] <jdstrand> you knew that ;)
[20:55] <lamont> jdstrand: and that's why the package delivers an empty /var/lib/bind
[20:56] <lamont> .jnl files don't belong in /etc, so let's move the zone data to fix  that... :(
[20:56] <sommer> lamont: gotcha, can you take a look at: http://doc.ubuntu.com/ubuntu/serverguide/C/dns-configuration.html
[20:56] <sommer> if you only add the config for a slave the zone files want to go into /etc/bind
[20:56] <sommer> should that be documented different?
[20:57] <lamont> slave zone goes in /var/cache/bind
[20:57] <sommer> lamont: do you have to configure that?
[20:57] <lamont> in fact, slave zones can go in the config without a leading path name, since named's working directory is /var/cache/bind
[20:58] <lamont> so just drop the /etc/bind/ from the paths for secondary
[20:58] <sommer> gotcha
[20:58] <lamont> for dynamic, you'll need to have /var/lib/bind/ in front of the zone data.
[20:58] <jdstrand> lamont: have you uploaded -6 yet?
[20:59]  * lamont points at "Configuration Schema:" in /usr/share/doc/bind9/README.Debian.gz
[20:59] <lamont> to debian, yes.  it'll be in the dinstall run
[20:59] <lamont> tomorrow.
[20:59] <lamont> somewhere in there I should subscribe ubuntu-archive and make it a sync request
[20:59]  * lamont goes to do that
[20:59] <jdstrand> lamont: you are too fast
[20:59] <sommer> lamont: thanks I'll look through that :-)
[21:00] <jdstrand> lamont: this talk of /var/lib/bind made me check the apparmor profile
[21:00] <lamont> jdstrand: the commit was waiting for the bug number... :-)
[21:00] <lamont> jdstrand: so is it broken?
[21:00] <jdstrand> it should have '/var/lib/bind/* rw,'
[21:01]  * lamont ponders the meaning of 'DAC'
[21:01] <jdstrand> discretionary access controls
[21:01] <jdstrand> as opposed to MAC
[21:01] <jdstrand> sorry for the jargon
[21:02] <lamont> np.  I expect that directory perms are MAC though, no?
[21:02] <lamont> anyway, not sure what, if anything, a proper install should need to write in /etc.
[21:02] <jdstrand> apparmor provides the MAC, and it is supplemental to the unix permissions
[21:02] <lamont> ah, ok
[21:03] <jdstrand> so if the unix perms so 'no', apparmor will not override that
[21:03] <jdstrand> (think the most restrictive wins in this case)
[21:03]  * jdstrand can't type
[21:04] <jdstrand> say 'no'
[21:04] <lamont> right.
[21:04] <jdstrand> lamont: I only did the /etc/bind as someone will undoubtably just use /etc/bind for their zone and dynamic updates
[21:04] <lamont> so I'll ignore that for the moment, and let you file a bug on bind9 with a patch to the apparmor-profile (vs -6) and then we'll catch it after bind9 gets a chance to age for a couple of days?
[21:04] <lamont> there are lots of places that use /etc/bind in ways it was not meant to be used... like say, for secondary zones
[21:05] <jdstrand> lamont: no problem-- I'd like to test it some more anyway
[21:05] <lamont> (putting secondary zones in /etc violates FHS)
[21:05]  * jdstrand nods
[21:06] <lamont> "Every zone file contains 3 resource records (RRs): an SOA RR, an NS RR and a PTR RR."
[21:06] <lamont> Bzzzzt!
[21:07] <lamont> every zone contains an SOA RR, one or more NS RRs and probably other data.
[21:07] <sommer> talking about the docs?
[21:07] <lamont> (reverse zones tend to have PTR RRs to be useful, forward zones tend to have A and/or AAAA RRs as well as other stuff)
[21:07] <lamont> yes
[21:07] <lamont> overview, final para
[21:08] <sommer> yeah, that line was in the original doc, which wasn't very good
[21:08] <sommer> thanks, I'll reword that
[21:08]  * lamont has come to hate the title "caching nameserver", despite it's ubiquitous use.
[21:08] <lamont> all nameservers cache
[21:08] <lamont> some nameservers are authoritative
[21:08] <sommer> heh, why sounds like it will give you money :-)
[21:08] <lamont> some nameservers will accept recursive queries.
[21:09] <lamont> some do all 3
[21:09] <sommer> should that section be renamed?
[21:09] <lamont> dunno
[21:09] <lamont> they're the terms everyone expects...
[21:09] <sommer> ya, I referred to the DNS howto for a lot of that info
[21:10] <lamont> "caching only nameserver" is a common term, which means a nameserver that is only authoritative for 0.0.127.in-addr.arpa, localhost, and friends.
[21:10] <sommer> I'll mention that you can do all three types on one server
[21:11] <lamont> yeah.  my nameserver, for example, is primary for a bunch of zones, and secondary for a few others
[21:14] <sommer> cool, thanks for the feedback lamont
[21:14] <sommer> I appreciate it
[21:14] <lamont> (and allows recursion from the home network, too)
[22:40] <soren> mok0: You pang me (much) earlier?
[23:01] <mok0> soren, still there?
[23:01] <soren> mok0: I was *just* about to leave.
[23:01] <mok0> soren: I just wanted to discuss with you my bug 200648
[23:01] <ubotu> Launchpad bug 200648 in kvm "guest machines falls behind time" [Undecided,New] https://launchpad.net/bugs/200648
[23:03] <soren> mok0: Waaay too tired. Sorry :)
[23:03] <mok0> soren: np
[23:03]  * soren heads to bed
[23:03] <mok0> see you later!
[23:15] <owh> After supplying the patch for the ntp bug with the kind assistance from kirkland, I'm looking at the qa-hardy-server list: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qa-hardy-server and all that is left is a long running bug about cups-pdf. Bug #147551, posted 1 Oct, 2007. I'm not sure it even has a good description, let alone a handle on what's causing it.
[23:16] <owh> Hmm, the bot didn't pick up the bug: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/147551
[23:17] <owh> Any ideas?
[23:21] <mok0> owh: looks complex
[23:22] <owh> They always do, but I've found that most of the time, the fix is a single line - the trick being to find that line :)
[23:22] <owh> More than anything, there appears to be a lot of noise in the bug.
[23:23] <mok0> owh: there's a fix in a comment from 2007-12-06
[23:23] <mok0> owh: yeah, hard to see if it's just a configuration error
[23:24] <mok0> owh: can you reproduce it?
[23:24] <owh> No, I'm not seeing anything like that. And I don't see aa-complain in my packages list either. Not sure where it's from yet.
[23:26] <owh> Soh, I read: sudo aa-complain cupsd as sudo apt-get install aa-complain - not sure what my brain is up to this morning :)
[23:26] <owh> s/Soh/Doh/
[23:27] <owh> Ah, a bit of RTFM with aa-complain, it doesn't fix it, just hides the error in the syslog.
[23:27] <mok0> hm
[23:27] <sommer> owh: aa-complain is part of apparmor
[23:28] <owh> Yeah, my brain wasn't reading what the screen said :)
[23:28] <owh> I'm reading https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/152537 which appears to be the same bug.
[23:28] <mathiaz> owh: it's a long bug and boils down to non-standard configuration for users.
[23:29] <mathiaz> owh: most of them have non-standard home directories, or symlinks to somewhere lese.
[23:29] <owh> So, is this a real bug, or a support request?
[23:29] <mathiaz> owh: hum... good question
[23:31] <mok0> mathiaz: there are loads of bugs in Ubuntu related to having your home directory on an automounted nfs share
[23:31] <mathiaz> mok0: bugs related to AppArmor or bug in general ?
[23:32] <owh> mok0: Perhaps that's food for another tag?
[23:32] <mok0> mathiaz: various general bugs
[23:32] <mok0> owh: could be
[23:32] <mathiaz> bug 147551 is really about cups-pdf, apparmor profile and non standard configuration
[23:32] <owh> The second bug I showed seems to start in the same place, but travels to a different destination.
[23:32] <owh> I'm beginning to think that it's a support request.
[23:32] <mok0> owh: yeah
[23:33] <owh> Not that there's anything wrong with that, but we cannot come up with a patch for it :)
[23:33] <mok0> owh: it should be moved to questions
[23:33] <mathiaz> owh: well - there is a solution in the bug
[23:34] <kirkland> owh: mathiaz and I were talking earlier today about getting more of the scripts in /etc/init.d LSB-compliant
[23:34] <mathiaz> owh: which is to look at the apparmor messages and update the profile for cups-pdf
[23:34] <kirkland> owh: seems that many of those scripts are missing a "status"  action item
[23:34] <mathiaz> owh: there are also some issues in gutsy if the directory is on an nfs share
[23:34] <mathiaz> owh: kirkland: right
[23:35] <mathiaz> that could be another task to look at
[23:35] <owh> mathiaz: Specifically related to this bug, or in addition to this bug?
[23:35] <mathiaz> I've added an item to the ServerTeam Roadmap
[23:35] <kirkland> owh: just an item in general, some relatively low hanging fruit, lots of little shell scripting patches
[23:35] <mathiaz> owh: it's a general tip when debuging apparmor problems
[23:36] <owh> mathiaz: You mean, if you have an nfs share directory and you're having apparmour issues - which this cups-pdf bug report looks like, then you're saying, that's a debugging tip?
[23:36] <owh> kirkland: Yes, but what output should the "status" call make?
[23:37] <kirkland> owh: it should tell you whether or not the given service is running
[23:37] <owh> kirkland: Is there a specified format / exit code for that?
[23:37] <kirkland> so something like:
[23:37] <kirkland> root@t61p:~/bin# /etc/init.d/ntp status
[23:37] <kirkland>  * NTP server is running.
[23:37] <kirkland> root@t61p:~/bin# /etc/init.d/apache2 status
[23:37] <kirkland>  * Usage: /etc/init.d/apache2 {start|stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean}
[23:37] <mathiaz> owh: there is a specific format for the output of the status command IIRC
[23:38] <kirkland> NTP has a working "status" section, but Apache does not
[23:38] <mathiaz> owh: the lsb standard documentation has it
[23:38] <kirkland> mathiaz: owh: yes, definitely in the LSB spec
[23:38] <kirkland> i can dig that up if you want me to...
[23:38] <mathiaz> however, most of the init script in debian have their own status output :/
[23:38] <owh> Cool, in my spare life, I'll have a look at that, but meanwhile what do we do about this outstanding qa-hardy-server bug - I know I can remove the tag, that will make it go away :)
[23:39] <kirkland> mathiaz: I'll prepare a report of all of the init scripts in a hardy-server install, listing which ones are missing a "status" section by Wednesday's meeting
[23:39] <owh> kirkland: I'll give you a hand when I have a mo.
[23:39] <mathiaz> kirkland: great - it should be that hard to automate
[23:39] <kirkland> mathiaz: nope, just an xargs ;-)
[23:39] <owh> mathiaz: You mean should not right :)
[23:39] <mathiaz> kirkland: I've listed in the Roadmap a link to the wiki page in w.debian.org where they track this effort
[23:39] <kirkland> mathiaz: ah, nice
[23:39] <owh> kirkland: Uh, that's only for the scripts you have installed, not for all of them.
[23:40] <owh> kirkland: Unless you're doing something else funky.
[23:40] <kirkland> owh: well, i say we target the ones in a Hardy Server install
[23:40] <mathiaz> kirkland: implementing the status command is the easiest task.
[23:40] <kirkland> mathiaz: yes, I agree
[23:40] <kirkland> mathiaz: it's also the most useful
[23:40] <mathiaz> kirkland: defining proper dependencies is harder
[23:40] <owh> kirkland: That's only true if you install *all* the tasks I suppose.
[23:41] <mathiaz> kirkland: I'd start by making a list in main
[23:41] <kirkland> mathiaz: it's one of the things i've heard many RH admins complain about when making the switch to Ubuntu
[23:41] <mathiaz> kirkland: a list from packages in main
[23:41] <mathiaz> kirkland: agreed
[23:41] <owh> Anyone got any issues with me removing the qa tag from https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/147551, or is there a better way?
[23:42] <mathiaz> owh: well - I'm convinced we should remove it.
[23:42] <owh> Anyone else?
[23:42] <mathiaz> owh: heu... *not* convinced
[23:42] <owh> Huh?
[23:42] <kirkland> subtle difference mathiaz ;-)
[23:43] <owh> I'll say :)
[23:43] <mathiaz> owh: it's an annoying bug that keeps coming over and over
[23:43] <mathiaz> owh: I'd like to discuss it with pitti
[23:43] <mathiaz> owh: it's related to cups so it's up to him.
[23:43] <mathiaz> owh: the reason it's tag with qa-hardy-server is that it's apparmor related and we're "looking" after apparmor
[23:43] <owh> Fair enough. Is that a self-appointed action item for Wednesday :)
[23:44] <mathiaz> owh: but we won't have a proper solution on the apparmor side to handle these situation
[23:44] <ubotu> Launchpad bug 147551 in cupsys "cups-pdf fails to generate file when user does not print to default ~/PDF (apparmor vs.cups-pdf inconsistency)" [Wishlist,Confirmed] https://launchpad.net/bugs/147551
[23:44]  * mathiaz waves at ubotu
[23:45] <owh> ROTFL
[23:45] <owh> I wonder.
[23:45] <kirkland> mathiaz: what's the best way to get a comprehensive list of packages in main?
[23:46] <owh> I have found lots of printed pdf stuff from cups-pdf in /var/spool/cups-pdf. I wonder if the "non printed jobs" are all in there?
[23:47] <owh> kirkland: There was an email about that, lemmie have a looksee.
[23:47] <owh> As in, a snippet that gave you the answer.
[23:49] <kirkland> owh: lemme have it!
[23:49] <mathiaz> kirkland: you can grep in a Packages.bz2 file from the apt repository
[23:49] <owh> I'm looking, I'm looking.
[23:49] <mathiaz> kirkland: http://archive.ubuntu.com/ubuntu/dists/hardy/main/binary-amd64/
[23:49] <owh> mathiaz: Pah, that's cheating :)
[23:50] <kirkland> mathiaz: perfect, thx
[23:51] <mathiaz> kirkland: you could also have a look at madison and rmadison
[23:52] <mathiaz> kirkland: you need a package name, but it'll give you the component for the package
[23:53] <owh> Doh, I just thought of a better way, one mo.
[23:54] <kirkland> mathiaz: so I'll create a VM, install all 5914 packages in main, then `ls /etc/init.d/ | xargs -i {} status > /tmp/out`
[23:54] <kirkland> :-P
[23:56] <owh> I'm having a little fight with the packages search engine, but I suspect it will submit to my will and give us a list :)
[23:56] <mathiaz> kirkland: well - considering that you have a local mirror, you could also go through all the packages, list their content and check if they have a init script
[23:57] <mathiaz> kirkland: dpkc -c .deb
[23:57] <owh> Oh, loveley, the search engine is giving responses, but there is no standard name for the init.d script :)
[23:57] <kirkland> mathiaz: that's just what I was doing
[23:57] <mathiaz> kirkland: dpkg -c .deb
[23:57] <kirkland> installing 5900 packages in a VM was a joke
[23:57] <owh> I think we got that :)
[23:57] <mathiaz> kirkland: that way, you could even have a list of universe and another one for main