=== ajmitch_ is now known as ajmitch [01:24] 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? === joerlend_ is now known as XiXaQ [05:19] does ubuntu run hald by default / [07:40] 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] Feel free to be brutally honest in your response. I'm looking for alternative perspectives. [07:42] 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] not many places do support upgrades (eg) - microsoft sort of do, redhat dont at all. [07:43] yea [07:44] first rule of getting stuff done is to not make em angr [07:44] 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] fwiw, your teh second person i've seen in 4 hours complaining about feisty -> hardy upgrades [07:44] and citing bug one is basically saying "YOU THINK THIS IS OKAY?!? WELL THEN VERYONE WILL JUST STICK WITH MS!" [07:44] kgoetz: This is Feisty -> Gutsy [07:45] owh: er, yeah sorry. i meant that :$ [07:46] 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] 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] owh: you use the phrase We a lot [07:46] s/comment/comment for sure [07:46] have you been testing upgrades from gutsy to hardy? [07:47] 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] pwnguin: No, I've not been working on gutsy -> hardy upgrades. [07:48] the surest way you have to make that work is to probably start reporting bugs now ;) [07:49] make an image, install it, upgrade and see what all broke in your opinion [07:49] its essentially too late to fix feisty -> gutsy upgrades [07:50] pwnguin: which tbh i find a rather anoying pice of ubuntu policy [07:50] funny thing to hear in a server channel [07:50] its not policy [07:50] Not only that, it's not really sustainable. It means that upgrades won't ever get better. [07:51] whats a funny thing to hear in a server channel? [07:51] It means that lessons learnt since release never get incorporated. [07:51] owh: you mean like uuid disks? [07:51] So, you're no better off being conservative than doing an upgrade on day 1. [07:52] pwnguin: You mean the fstab fix? [07:52] 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] pwnguin: I'm not sure what you are getting at. [07:53] Aren't we all aiming for a better user experience than anywhere else? MS and RedHat included? [07:54] that system was put in place because upgrading the kernel can cause detection order reversals [07:54] So, are you giving me an example of a fix that was made after release to make an upgrade work better? [07:55] that'd be an example of a fix that was "a lesson learned" and the upgrade getting better [07:55] more importatnly [07:56] of that list of bugs, theres about 3 legitimate upgrade complaints [07:56] 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] pwnguin: You're referring to the list of bugs in the email? [07:57] in the pastebin, yes [07:57] 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] interesting [07:58] What? [07:58] im trying to figure out why the icons changing is a negative end user experience [07:59] 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] s/icons changed/icons changed appearance/ [08:01] so you've expressed no preference for them [08:01] That's an interesting view. [08:01] Hmm. [08:02] 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] 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] indeed [08:03] I suppose my threshold for change is lower than others. [08:03] That's interesting in its own right :) [08:03] most server people hate change ;) [08:04] That's because people start yelling at you if things change :) [08:04] afk. heading home [08:04] 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] back in a fe hours probably [08:04] *few [08:04] Thanks for your comments kgoetz. [08:05] i agree that config file diffs suck [08:05] 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] If that option came with a log, that would be even better. [08:06] hmm [08:06] At least I'll have whatever the package maintainer thinks is a good config and I can check and fiddle later. [08:06] is the GNOME frontend to apt default yet? [08:06] Mind you, sometimes the diff picks up spacing changes :( [08:06] You mean synaptic? [08:07] I'm not sure what you're referring to. [08:07] no, i mean like the user query stuff [08:07] like "run avahi service?" [08:07] dpkg-configure i think [08:07] I don't understand the question. [08:07] when you upgrade a package, it asks you questions [08:08] or even just install it [08:08] 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] that system has a normal terminal interface, but ive been using the GNOME frontend for ages [08:08] The dialogs were just simple "Keep" "Replace" boxes with a diff in the window. [08:09] Are you talking about the different ways to interact with the user, that is, via text-only, text dialog, gnome, etc? [08:09] yes, i think so [08:09] debconf frontends [08:10] Yes, we're talking about the same thing. [08:10] One mo, answering the door. [08:10] 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] The PHP.ini side-by-side view was a ripper in uselessness. [08:11] Example output line: ; such as dynamic images ; such as dynamic images [08:11] tidy.clean_output = Off tidy.clean_output = Off [08:11] That's two config lines "side-by-side" [08:12] Very helpful. [08:13] when i get diffs, they show up in a GNOME window with scrollbar and standard +- notation [08:13] 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] Well, there were those as well, but it wasn't consistent. [08:13] no use talking about methodology if you don't practice it [08:14] 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] not quite what im saying [08:15] Sorry, what were you trying to tell me. [08:15] im saying you're walking into u-d-d and demanding changes in what other people do [08:15] I suppose I'm trying to poke someone in the eye, yes. [08:15] Are you saying that I'm not practicing what I'm preaching? [08:16] im saying nobody's going to want to practice your suggested changes if even you don't help with them [08:16] I was trying to be constructive about it and attempting to start a discussion. [08:16] Fair point. [08:16] How do I best help then? [08:16] cats, mice and bells [08:16] ROTFL [08:17] number one would be to identify which of those complaints are upgrade bugs versus regressions [08:18] So, my first step would be to write down a list of what broke or what needed attention? [08:18] Then I suppose use LP to see what gives. [08:18] more importantly, i recall a session at the UDS for hardy [08:18] about automating upgrade testing [08:19] I'm all ears. [08:20] looking for it [08:21] Yeah, ditto, found https://blueprints.launchpad.net/sprints/uds-boston-2007/+roadmap [08:22] https://blueprints.launchpad.net/ubuntu/+spec/automated-installation-testing [08:23] Well the priority is high, it's been approved, but there does not appear to be any content - lovely. [08:24] Is that what you were referring to? [08:25] im not sure [08:25] i may be remembering incorrectly [08:25] I think we're agreeing that my email won't help. [08:26] i think if you aimed to be a bit more constructive [08:26] suggest a UDS session [08:26] Suggestions? [08:27] 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] 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] which meetings? [08:29] ubuntu-server meetings. [08:29] physically? [08:29] I'm in Australia, run a one-man company, no not physically. [08:30] well, if "we" means you're asking to help fix it, go ahead and use "we" [08:30] You bet, I'm not dumping this from on high - or low - I intend to assist the process. [08:31] But you raise an interesting point which I'll consider. [08:31] i mean, there are upgrade bugs [08:31] i'd like them gone [08:32] You and me both :) [08:32] 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] well that would give you a bit stronger position in the email [08:34] 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] roughly as it stands. maybe drop the "why should i even bother?" line [08:36] Yeah, it would have gone through another filter - the original draft had venom dripping from it - it helped me, but not Ubuntu :) [08:37] so what's the recommended upgrade procedure for fedora? ;) [08:38] That's not even funny - well, after I recovered from choking from laughing that hard. [08:38] It's interesting though. [08:38] last i knew it was download the latest iso and reformat [08:38] What is the Ubuntu recommended upgrade procedure for ubuntu-server and ubuntu-desktop. Is it the same? [08:39] On my deployment servers I build a new VM image and deploy that. [08:39] s/deployment/production/ [08:39] on desktop, they try to beat people into the update manager tool [08:39] not sure how that works with server [08:39] On the desktop it didn't work for me today - I'm looking forward to the LTS -> LTS upgrade *not* [08:40] Fundamentally, config change management is IMHO borked. [08:40] still at it blokes? *grin* ( i'm kgoetz ) [08:40] Yup. [08:41] 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] well, almost every app fails to provide a config migration system [08:41] So is that the real problem? [08:42] I mean, if we identify that as an actual problem, we can go about doing something about it. [08:42] s/an/the/ [08:42] well, i mean, that's what the diffs are for [08:43] Yeah, but they still show white-space differences and show diffs for files I never touched. [08:43] I suppose that's a bug :) [08:43] does it? [08:43] i thought there was a way it would handle untouched config files [08:44] It did for me. Lemmie see if I can dig up an example. [08:44] gentoo actually has a system aside from debconf for etc files [08:44] The first four lines from a /etc/pam.d/gdm diff: [08:44] -auth requisite pam_nologin.so [08:44] -auth required pam_env.so [08:44] +auth requisite pam_nologin.so [08:44] +auth required pam_env.so readenv=1 [08:45] Line 1 and 3 are the same. [08:45] they are not [08:45] but they are trivially the same [08:45] one uses tabs, the other uses spaces [08:46] I'm sure it matters for the config parser :) [08:46] if it worked before [08:46] it works now [08:46] it matters to diff, but not your average config parser [08:46] this is an argument for xml ;) [08:47] 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] right; xml wouldn't give you that sort of crap [08:47] oh, i guess there's also that readenv=1 [08:48] 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] Mind you, there's a whole different conversation about patches that include config files changed between different maintainers - yuk. [08:49] ideally, there'd be an md5 or some other hash to compare with so it knows when you've changed it [08:49] it seems that using a diff system that can ignore whitespace would save a lot of issues [08:51] 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] So, now I have a local change that matters and a maintainer change that may matter. What do I choose? [08:52] 3 way merge ;) [08:53] Sure, but now my grandma is doing the installation - what does she choose :) [08:53] moin [08:53] if your grandma can edit conf files, she can read a diff :P [08:53] owh, why did you grandma edit /etc/default/acpi-support ? [08:53] hmm, ipv6 autoconfiguration is broken after enabling ipv6 in ufw [08:53] Because her grandson came to fix her laptop that didn't sleep. [08:54] 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] well the grandma solution is to make sleep work correctly without the file hack, and blind overwrite the config file [08:55] Ah, but the sleep fix comes as a bug fix to vmware-server :) [08:55] And to mysql for that matter :) [08:55] owh: legitmate problem, and you can't propose a policy / procedure fix to that until you know why it happened [08:56] well, grandma's getting quite technical [08:56] but that's not the point [08:56] She's like that :) [08:56] No. [08:56] the kernel suspend and hibernate stuff is braindead [08:56] Oh yeah. [08:57] it'll just get worse and worse as we get more cores [08:58] 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] 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] you replace every config file on my server/s and i'll kill you ... [09:00] Well, have you got a better idea? [09:00] yes. dont fsck up thousands of servers so a few grandmas dont need to press Y [09:00] No, I think you're missing my point. [09:01] The challenge is to come up with a mechanism that deals with local change while incorporating new configurations. [09:02] I mean, for example change the default pam authentication module across Ubuntu, something which most people wouldn't fiddle with for example. [09:02] debconf is meant to handle lots of those problems. [09:03] Ah, but then its use seems incomplete at best and faulty at worst. [09:04] I agree that it should work, but it doesn't appear to. [09:04] i havent read enough in how it works on a technical level [09:04] the thing is, ubuntu sets the debconf to default [09:04] so you never get asked questions like "enable avahi?" [09:05] it just assumes the answer [09:05] it's a tricky balance [09:05] surely you've upgraded debian once? [09:05] So, then the mechanism that changes that when I tick the box to say "Disable Avahi" isn't updating debconf? [09:06] _highly_annoying to sit there for two hours playing "wait for the dialog" [09:06] I've upgraded Debian many, many times, why do you think I came to Ubuntu :) [09:06] --priority=high [09:06] or --priority=low [09:07] 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] Making the installation last 3 hours 45, rather than 2 hours. [09:07] Or in my case, 10 hours instead of 2.5 hours. [09:08] you can complain about to much info, or to little, not both at once ;) [09:08] (Only to find bugs that have been open since early December specifically relating to this upgrade :) [09:09] 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. === \sh_away is now known as \sh [09:10] 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] isn't this why professionals have a hot spare? [09:11] Fundamentally that was what my email was about. It should not be like that. Our user experience should be better. [09:11] pwnguin: You mean on a laptop, sure, as soon as IBM supports a normal size drive in the PATA socket :( [09:13] 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] honestly, i tihnk the level of effort needed to make upgrades painless is something that will probably need money backing [09:15] Well, that in itself is a useful observation. [09:15] 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] 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] soren: So how is one supposed to "prepare" for an upgrade? [09:17] TEst it. [09:17] heh [09:17] in -server no less, this should be expected behaviour ^_^ [09:18] 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] 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] 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] 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] But it will help. [09:20] 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] pwnguin, probably paying a few CS students to do testing would be more effective [09:20] owh: Virtual servers are certainly handy for testing, yes. [09:20] Transferring that to my workstation, I suppose I could have built a virtual copy of my workstation and attempted to upgrade that. [09:22] 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] 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] Upgrades should work. [09:22] ROTFL [09:22] Sorry. [09:23] And in the general case, they do. [09:23] ! [09:23] Yes, it's the edge cases where it breaks. [09:24] 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] And as soren says, it is NOW that we need testers where the edges are when upgrading from dapper|gutsy -> hardy [09:24] AS you have observed yourself, once the release is out, we're unlikely to touch it. [09:24] Yes. [09:24] ..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] 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] 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] That's very funny and I thank you for your humour. [09:26] Which part? [09:26] crack pipe? [09:26] You upgrading now instead of later? [09:27] Living on the edge by installing Hardy the day after Gutsy releases. [09:27] I suppose I should start with making my Gutsy installation work first, then break it again in Hardy :) [09:28] 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] heh [09:28] You mean sid :) [09:28] more like experimental [09:28] Too much confusion :) [09:28] but upgrades arent even always stable entry windows till alpha1 [09:28] Right. [09:29] anyways, it'd be nice at least to see some more automated tests on packages [09:29] We do a lot of that already. [09:30] It's just not very good a exposing all the corner cases. [09:30] At all. [09:30] where are the reports hiding at, exactly? [09:30] pwnguin: I'm not sure. [09:31] 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] Something like dpkg --get-selections. [09:31] i say just keep a set of images around [09:31] Together with a copy of /etc [09:31] owh: I don't think that'll do much good. [09:32] owh: In fact, I think we do that already (install a random set of packages, test upgrade, rinse, repeat). [09:32] 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] Capturing that isn't likely to be trivial, but I think it may be doable. [09:33] owh: You claim to have never touched a configuration file? [09:35] 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] I captured most if not all of the prompts during the upgrade. [09:36] If you haven't touched a config file and you're prompted about changes to it, that's a bug. [09:36] No doubt. [09:36] There were many. [09:37] Please file bug reports. [09:37] Otherwise, we'll never fix it :) [09:37] Fair enough. [09:37] pwnguin: http://people.ubuntu.com/~mvo/automatic-upgrade-testing/ [09:37] That's a project for the morning. [09:37] i knew there was one [09:38] i couldn't find a blueprint for it or a UDS meeting [09:38] Gotta run. Later all. Thanks for the input. [09:38] https://blueprints.edge.launchpad.net/ubuntu/+spec/auto-dist-upgrade-testing [09:39] ah, i was looking at the wrong release [09:45] 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] NineTeen67Comet: what's the URL of your web site? [09:46] 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] http://www.openlug.com (one of 11 on the server) [09:46] Outside IP is 122.145.71.123 [09:47] hmmm... it resolves to 122.145.71.122 [09:48] 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] Who/what/where and how is that incorrect? .. sigh and I thought today was going to be a home work day .. lol [09:50] Could it be GoDaddy (my registrar) being told to send my URL addresses to another dns server? [09:51] NineTeen67Comet: check your DNS entry for www and ensure that you are pointing to the right address [09:52] 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] Hi all! [10:54] Is anyone here interested in a installtest for Hardy on a Sunfire T1000 and a Sunfire X4500? [10:54] I'm going to produce these this week, I think [10:55] 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] Kamping_Kaiser: I'll let you know when I get one [10:57] Jeeves_, cool. you likely to get one in the next week? [10:57] Kamping_Kaiser: It should ship tomorrow [10:58] I think it'll be thursday [10:58] 60day trial? [10:58] Yes [10:58] I'm going to run the Hardy release on two T1000's and a X4500 [10:58] we are closing in on day 20 of ours [10:58] (We run nl.archive) [10:58] so putting ubuntu on this week would be handy [10:59] Kamping_Kaiser: I'll try to get it done [10:59] Jeeves_, whats your timezone? [10:59] https://weblog.bit.nl/files/2008/03/ubuntu-setup.png [10:59] Kamping_Kaiser: .nl (ehm, GMT+0100?) [11:00] hm. [11:00] thats 8/9 hours different to me, which is perfectly aquard for going through it together [11:00] :) [11:00] Ehm [11:01] So. It would be ok if I were really early, right? [11:02] * Jeeves_ isn't very great with timezones :) [11:02] i'm +10.30 am i think (usually +9.30) [11:03] i need to work out the netinstall infrastructure too [11:03] Kamping_Kaiser: I'm working very early thursday [11:03] its been quite a while since i netinstalled a sun, and we dont have the infrastructure to do it at work :( [11:03] So if I'm awake at 05:00 AM, that would be ok for you, right? [11:04] 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] henkjan: what version of ufw? [11:06] http://www.timeanddate.com/worldclock/city.html?n=5 [11:07] jdstrand: 0.13 [11:07] jdstrand: should be some default icmp handling [11:07] Kamping_Kaiser: Coolio. We can play than :) [11:07] Jeeves_, :) [11:08] Jeeves_, do you have existing netinstal infrastructure setup? or do you have a "best" reference i should look at? [11:08] 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] Kamping_Kaiser: We have a pxe-booting infra [11:08] henkjan: I hope to upload a new version today, and if the changes are small, I can get them in [11:08] No hardy support yet [11:09] And no sparc-support either [11:09] jdstrand: i'm looking at wich icmpv6-types are needed for proper ipv6 autoconfiguration [11:09] henkjan: before filing though, try 0.14 [11:09] Kamping_Kaiser: And I hope we have it by thursday [11:09] henkjan: (it's in the archive already) [11:09] 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] henkjan: and IIRC, you are on gutsy? 0.14 should work much better on gutsy [11:10] henkjan: but if you still have a problem, please file a bug report and I'll get it fixed [11:13] jdstrand: okay, ill first check with the 0.14 version [11:15] henkjan: great! please let me know how 0.14 works out for you (good or bad) [11:20] 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] morning [11:21] henkjan: check the changelog [11:21] henkjan: Use "apt-get source ufw" instad [11:22] henkjan: Or even better: Use bzr (but apt-get source will tell you this, IIRC) [11:23] henkjan: yes, apt-get source works fine [11:24] soren: that is odd though-- the tarball is 0.13. [11:24] i did an apt-get source on an hardy, and that gives me an ~/ufw-0.14/ [11:24] * jdstrand nods [11:24] jdstrand: apt-get source renames it for you :) [11:25] jdstrand: Well... dpkg-source does, actually. [11:25] ah, okay [11:25] soren: I was just curious why it was that at all [11:25] soren: I did a bzr export [11:25] maybe I need to look at that command some more [11:25] jdstrand: Oh? You don't need to do that. [11:26] soren: do tell [11:26] I am in 'trunk' [11:26] jdstrand: Just pass -I to dpkg-buildpackage, and it'll leave out .bzr [11:26] (I assume that's why you do the export) [11:26] yes [11:27] Ok. Well, just pass -I to dpkg-buildpackage instead and you should be all set. [11:28]