=== elkbuntu is now known as elky [02:20] hi guys [02:20] Hi. [02:20] I have a small technical problem is that the right place to ask ? [02:21] Depends how small and how technical - #ubuntu might be better. [02:22] it's small :) [02:23] Well ask away, and we'll continue in private if necessary :) [02:23] I can't play rhythmbox and Totem simultaneously [02:23] that mutes my sound [02:23] same with firefox and totem === elky is now known as elkbuntu [02:24] in brief can't use sound for one application [02:24] more than one application * [02:24] But when you stop trying to use the second application, sound comes back? [02:25] yeah [02:25] when I close the other application [02:25] Is this in Hardy? [02:25] yeah [02:26] 8.04 LTS [02:26] At a guess, that's probably got something to do with the new audio system (PulseAudio), but that's way outside anything I can help with. [02:26] mmm [02:26] I guessed so [02:27] #ubuntu might know more. [02:27] but when I disabled it it didn't help [02:27] anyway thx [02:27] Sure, sorry I couldn't be more help. [02:27] thx [03:45] sorry for coming here for a support type question but dpkg-reconfigure xserver-xorg used to be able to configure video displays and devices, it no longer does that,.,. is there a new command for this or how can i reconfigure my display drivers when i cannot use a gui session? [03:46] You should be _always_ able to use a GUI session. [03:48] RAOF, what about when my display drivers are 'missing' and i dont know the package name to set them nor can i connect to the internet to download anything -- is there another command for reconfiguring display? [03:49] If you can't, it means that the vesa driver is broken on your system. [03:49] RAOF, so what would i do then -- besides reinstall? [03:50] I'm not quite sure what your question is. Or, rather, I'm not sure that the conditions in your question ever trigger. [03:50] ok il rephrase [03:52] RAOF, in Gutsy when i ran dpkg-reconfigure -phigh xserver-xorg i could reconfigure my display settings things like drivers and screen res, in Hardy this is not available with the same command,. is there another command that does the same thing or how can i make the command do what it did in Gutsy? [03:53] Right. The answers there are 'no' and 'no', respectively. [03:53] RAOF, why was the command changed? [03:53] Because X no longer needs that configuration. Most of the time. [03:54] And writing _wrong_ information in xorg.conf is bad :) [03:54] The only time you should need to specify a driver is in the restricted-drivers case, since these don't seem to hook into X's autodetect. [03:54] RAOF, and what should i do if i need to reconfigure my display settings and i dont know what conf files to look in nor do i have a useable gui session (because there is loads of lines accross my screen & my screen is overlapping itself 5 times) [03:55] Bodsda: You can delete /etc/X11/xorg.conf :) [03:55] Bodsda: Or, better, move it out of the way. [03:55] RAOF, how does that help? [03:56] Another option is to reboot and pick the recover option. It's got a try to fix X option. [03:56] So, that makes X do it's funky autodetection thang, which should work. If it doesn't, it's going to be a driver bug. [03:56] ScottK: Which uses VESA, right? [03:57] ok so the nifty little tool to fix screen probs has been deleted -- why? and is it at all possible to get it back? [03:57] RAOF: I'm not sure. So far everytime I broke my xorg (and I did it a bunch patching displayconfig) it got me back to working. [03:57] Why? A: Because it no longer fixes screen problems. Not possible to get it back, at least easily. [03:58] You'd have to look at the pre-Xorg-1.4 packages and merge the old debconf information with the new packages. [03:58] why would it no longer fix screen probs ?? it choose drivers and screen res [03:59] Both of which can be accurately autodetected. [03:59] Bodsda: X changed the way it deals with stuff a lot recently. A lot of tools just don't work anymore. [03:59] ScottK, can we expect a similar tool in the future? [04:00] Probably not, since the goal is to make such a tool unnecessary. [04:00] Bodsda: I'm not sure what tool you're talking about. If you want to fix a broken X config do the reboot to the recover option and pick the fix X choice. [04:01] ok, thankyou both -- ScottK doesnt the recover mode just give u a prompt? [04:02] Bodsda: No. It gives you choices and you can fix X and then reboot normally. [04:02] ScottK, ok cheers -- il let the guys in #ubuntu know -- cheers === gnomefre1k is now known as gnomefreak [04:43] hmmm perl still broken? [06:43] good morning [07:31] Good morning [07:35] hi pitti [07:35] * pitti hugs dholbach [07:36] Hi [08:02] hi pitti [08:02] Padre! [08:02] fabbione: Rocking the penguin cluster? :-) [08:03] pitti: indeed :) getting ready for a new release today [08:24] TheMuso: Hardy kernel? [08:24] StevenK: Only just upgraded this box to hardy. [08:27] TheMuso: Ahh [08:28] good morning [08:30] fabbione: oh, FC9 o'clock? [08:30] pitti: there was an announce, but no.. it's not related to f9 [08:30] pitti: i am preparing 2.99.01 (that will eventually be 3.0) for f10 [08:33] but you might have noticed that the build-deps for 2.99.01 are already in intrepid :=))) === cpro1 is now known as cprov [08:59] seb128: hello :) [09:00] lut mathiaz [09:00] seb128: re bug 228061 - I guess this is a duplicate of a nautilus bug - which bug number should I use ? [09:00] Launchpad bug 228061 in samba "Samba doesn't display the shared stuffs" [Undecided,Incomplete] https://launchpad.net/bugs/228061 [09:01] seb128: or should I just reassign it to the nautilus package ? [09:01] mathiaz: bug #207072 [09:01] Launchpad bug 207072 in nautilus "nautilus does not display samba shares for machines inside an ADS network." [Undecided,Invalid] https://launchpad.net/bugs/207072 [09:01] seb128: great - thanks [09:01] you are welcome [09:11] hey seb128 [09:19] hello pitti [09:23] hi, how can I get a package included in Ubuntu? [09:24] tvtime with audio support might be a good candidate, as well as my em28xx drivers (compiled for 32/64bit ontop of the lum modules, including firmware) [09:25] I think #ubuntu-motu may be a good start [09:26] mrec: ^^ + https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [09:26] though I'm not sure about the dirver [09:26] *driver [09:27] driver possibly should go into -restricted-drivers [09:27] I think it's better to keep the drivers out of the linux-ubuntu-modules package since I'll update it more frequently [09:27] which wouldn't be a seperate package per se [09:27] it's completly opensource and supported by the manufacturer [09:28] well even then; I'm not sure what the policy is on shipping drivers in seperate packages as opposed to in the big package [09:32] mrec: if you wanna take the path to maintain out of tree kernel modules, have a look at the virtualbox-ose-* packages [09:33] mrec: I'd suggest you to get your driver included in lum - it will be much easier to maintain and things won't break whenever there is a new kernel published. [09:34] mathiaz: the only thing is that there will be weekly updates again [09:34] I'm working at the driver and application side to provide best possible support for those devices (while not affecting/(breaking) other things) [09:34] mrec: make sure you push them in the lum git tree [09:35] mrec: I'm thinking, updating your driver frequently may not be a good idea anyway; well, at least not for stable releases [09:35] and for the development cycle, new kernels get pushed often enough [09:35] though maybe not as much as you want [09:35] mrec: the problem is that if you maintain your driver out of the tree, whenever there is a new kernel published things will break [09:36] mathiaz: I thought about that too the package could have a direct dependency to the lum package version, so upgrading the lum package would remove the driver [09:36] at least not for stable releases >> it simply will not happen for stable releases [09:36] I already have a Ubuntu build system for it [09:36] mrec: for ex, if you install virtualbox-ose-modules-*, which are in universe, you have to wait for the virtualbox-ose-* maintainer to uploader a new version of the vbox-ose-modules- when a new kernel is published. [09:37] I'm aware of something like that yes [09:37] mrec: so it's easier to get your module in the lum tree. [09:38] mrec: your module will be part of the standard kernel upload. [09:38] mrec: uhm, first of all, you would need to manually track the lum version. and second, how is it any good for the user (who may depend on your driver) that it gets removed when stuff breaks? [09:38] mathiaz: ok, well sounds like a reasonable way to go [09:39] Chipzz: the module overall has no dependency on something else it just adds stuff [09:39] mrec: if you still wanna maintained your own kernel-modules packages, you should have a look at the virtualbox-ose package. [09:40] I think the way you propose is fine [09:40] I could still provide packages on the webserver for those who want to test the bloody edge work [09:40] mrec: btw, one more thing... doing weekly updates will make bugtracking hell I think [09:41] Chipzz: it doesn't, it usually adds support for newer devices and newer chipdrivers [09:45] pitti: Hi, is it ok to ask for give-backs to get to build order right or is some huge give-back planned? [10:10] geser: sure, just tell me; I guess infinity will do some more mass-givebacks, but it doesn't hurt to do some more coordinated ones manually === sjoerd__ is now known as sjoerd [10:15] hi sjoerd [10:15] pitti: do we need the cpio-win32 binary deb? it makes currently cpio depwait on mingw32 (universe) [10:15] pitti: morning :) [10:35] pitti: KDE 4 MIRs available when you're able [10:38] geser: erk, does that come from cpio proper? no, we certainly don't want that in main [10:38] Riddell: ok, thanks [10:40] pitti: cpio builds cpio and cpio-win32. according to the description cpio-win32 is used in the win32-loader of D-I [10:41] ogra: I have a few questions about ltsp server, if you have a minute? [10:41] sure [10:42] ogra: I see that the standalone package depends on dhcp3-server. [10:42] right [10:42] I'm curious about how you handle configuration file changes in there. [10:42] see dhcpd's initscript ;) [10:42] I suppose ltsp fiddles around with it to offer kernel images to clients. [10:42] Oh, ok. [10:42] Oh. [10:42] Hah. [10:43] we have an override file so we dont touch existing configs [10:43] So installing ltsp effectively disables any currently running dhcp server? [10:43] if an admin wants to use his existing file he just a) deletes ours or b) only installs ltsp-server [10:44] Is the user notified about this when installing ltsp-server-standalone? [10:44] -standalone assumes you want ltsp to handle everything [10:44] ltsp-server is freely adjustable in all directions [10:44] well, only by the package description, we dont notify separately [10:46] soren, if you have any better sugestion how to handle the situation, i'm all open for a beer in prague to discuss it over ;) [10:47] ogra: :) === Lamego_ is now known as joaopinto [10:48] ogra: I'm really just working on something that'll need to do almost the same thing, so I was just looking for inspiration as to how to handle this. [10:48] ogra: ...but let's have beer anyway :) [10:49] soren, we do a similar thing with syslog, if you need such overrides as well, we should consider generalizing on a /etc/overrides dir or so [10:49] currently its bound to /etc/ltsp and the files in there [10:50] ogra: Yup. [10:53] pitti: re: https://bugs.edge.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/223759.. Can't we just copy over ifenslave-2.6 from hardy-updates to intrepid? [10:53] Launchpad bug 223759 in ifenslave-2.6 "ifupdown integration broken" [Medium,In progress] === davmor2 is now known as davmor2_away [10:53] soren: no [10:53] soren: we need a different version, since we have a different toolchain [10:54] Er.. Yeah, but if this bug had been fixed before hardy released, the packages would have just been copied to intrepid anyway. We don't rebuild every package because we update the tool chain? [10:55] soren: right, but we still usually do it [10:55] can't hurt to test it properly in intrepid [10:55] *shrug* Ok. [10:55] * pitti finishes testing of virt-manager and copies to -updates [10:55] ^ same case, btw, should be uploaded to intrepid [10:58] pitti: Not entirely the same case. intrepid will have a new upstream version, too. But yeah, it's in my list :) [10:59] has someone some time to sponsor bug #229877? [10:59] Launchpad bug 229877 in cpio "[intrepid] cpio build-depends on mingw32" [Undecided,New] https://launchpad.net/bugs/229877 [11:00] Keybuk, why is ltsp showing up on MOM but ldm isnt ? debian added an epoch to the ldm versioning, could that cause MOM to ignore it ? [11:01] ogra: it's on http://merges.ubuntu.com/main-manual.html [11:01] oh, i only looked at main.html, thanks dholbach [11:02] ogra: no common base version between the two [11:03] well, just different versioning, the code i pretty much the same .... (in the new ltsp wold each distro decides on its own how to call the tarballs :/ ) [11:03] s/i/is [11:09] tkamppeter, a big "thank you" from my mother ! (i brought her a new printer this weekend and she was massively impressed that she could intsall it herself (well or that it installed itself on its own rather :) )) === sjoerd_ is now known as sjoerd === chand is now known as chand[aw] === illovae_ is now known as illovae [11:40] does anyone here use vnc4server loaded in xorg.conf and get X crashes as soon as a client connects? [11:40] in hardy [11:45] pitti: a first batch for give-back: antlr axis hsqldb jakarta-log4j javacc jcommon-serializer jsch libbsf-java libcommons-collections3-java libcommons-lang-java libformula liblayout libloader libjaxp1.3-java libjakarta-poi-java librepository libpgjava liboro-java libmx4j-java libxerces2-java libxml-commons-resolver1.1-java libxml-java mysql-connector-java sacjava libxalan2-java [11:46] pitti, you have to use "sudo hal-disable-polling --enable-polling --device /dev/scd0" if something diabled cdrom polling (i.e. powertop has such an option) couldnt we make that command a wee bit more intuitive in its naming ? [11:46] :) [11:46] geser: hm, wierd, I get 403 forbidden on those now; yay LP rollout [11:47] ah, seems my stored cookie was invalidated [11:48] darn, how do I get one back now, with Firefox 3? [11:48] ogra: anything you have to type on the CLI is unintuitive... [11:48] ogra: the UI you used to switch it off should also allow you to switch it back on [11:48] pitti, true, but calling a command disable-foo with such a switch seems weird [11:48] pitti: http://people.ubuntu.com/~kees/scripts/cookies-sql2txt [11:49] geser: \o/ [11:50] hm, still forbidden [11:52] geser: no luck; I cannot even do it in the web ui [11:52] I'm still in lp-buildd-admins, but I don't even see the 'retry build' option any more :/ [11:52] cprov: ^ any idea? [11:59] heya [12:03] ogra, great to hear this positive feedback. Which printer model did you give to her? [12:04] a HP photosmart 53xx (forgot the exact namimg, sorry) === sjoerd_ is now known as sjoerd [12:08] ogra, this one is really completely supported. Connected to USB it sets up by iteslf and you can print and scan (if it has a scanner) immediately. If you were running Windows it would take you hours to get HP's CDs installed and you would need to reboot. [12:10] yeah, indeed i slightly ceated by buying a HP since i know its well supported :) but it was very impressing :) [12:16] I had the painful experience of installing an HP PSC .* on a Windows box last week. Could they really make it any worse/ [12:19] pitti: what's the problem ? you use to be allowed to retry any builds and now you are not ? [12:19] cprov: right [12:20] pitti: even l.n not in edge.l.n ? [12:20] cprov: let me try [12:21] cprov: ah, lp.net still works [12:22] geser: ok, disabled redirection and gave back your packages [12:23] pitti: thanks [12:28] soren: FYI, (LP #223759) does not work; you have to use LP: #; so please close the ifenslave bug manually [12:28] Launchpad bug 223759 in ifenslave-2.6 "ifupdown integration broken" [Medium,In progress] https://launchpad.net/bugs/223759 [12:29] pitti: Ah, yes. Force of habit. I remove the colon on purpose when doing merges (to not try to close the bugs /again/), but this time that was clearly wrong. Thanks for catching that. [12:30] soren: btw, IIRC LP does not try to close the bugs again, that was fixed [12:30] pitti: Ah, lovely. [12:30] LP will make us all jobless some day [12:30] soren: (I do the same, though) [12:30] *g* === chand[aw] is now known as chand [13:19] cjwatson: omg [13:19] jordi: ? [13:19] cjwatson: remember my partman-auto-raid troubles? [13:20] sort of :) [13:20] I was composing a detailed email to you and Simon [13:20] I thought it was very suspicious that the only error message I got was "No root partition defined", invariably of what I tried, and no debug messages [13:21] well, partman-auto-raid is in universe in Ubuntu [13:21] aha [13:21] yes, stuff in universe won't get used ... [13:22] yeah, it's not even in the CD [13:22] now, I've tried so many things that I don't know what's the correct config :) === ryu2 is now known as ryu [13:32] cjwatson: *sigh*, the basic expert_recipe works [13:32] I'll try the more elaborate setup now. I can't understand why -raid isn't in main though [13:32] never got reviewed and promoted ... [13:33] cjwatson: what can I do to get this reviewed and promoted? [13:34] jordi: could you mail ubuntu-devel@ about it? [13:34] sure thing [13:35] from your partman-auto knowledge, do you think creating a "/ on raid1, two independent swaps and /srv/backup on ext3 on a single PATA disk" would be problematic? [13:35] +layout [13:52] SCORE!!!!! WOWOWOWOOWOW [13:52] Subject: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator [13:52] :) [13:52] aware, work in progress [13:53] cjwatson: yeah i know... [13:55] fabbione: scary title isn't it ? :) [13:57] [13:57] Recovery looks to be a bit painful. [13:59] So we will have to regenerate all our SSH keys? [14:00] not all of them no [14:00] Only DSAs? [14:00] what ubuntu releases of openssl are affected? [14:00] siretart: >= 0.9.8c-1 I think [14:00] siretart: wait for the USN [14:01] lool: which would mean all later and including dapper :/ [14:01] This would translate to anything post dapper if I understand correctly [14:01] err, s/dapper/feisty/ [14:03] siretart, hey, i dont see you on the UDS attendees list, you dont come this time ? [14:03] ogra: oh, I do! [14:04] ogra: is that on launchpad? [14:04] yeah [14:04] great to hear :) [14:04] ogra: thanks for notice, fixed :) === davmor2_away is now known as davmor2 [14:30] <\sh> pitti: I filed a new sync request for phpgroupware, where your sync script was not able to sync it last time...could you check if it does now succeed? (bug #229942) [14:30] Launchpad bug 229942 in phpgroupware "Please sync phpgroupware 1:0.9.16.012+dfsg-4 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/229942 === hwilde_ is now known as hwilde === Shely_ is now known as Shely [15:58] \sh: yes, I'll have a look next time === mathiaz_ is now known as mathiaz [16:29] ok, so the openssl bug is quite severe.. does it really mean that every key used on a buggy system should be changed? even if not generated there? [16:31] check the keys with the tool :) [16:31] (ssh-vulnkey that is) [16:32] tjaalton: quite severe is an understatement. [16:32] :/ [16:32] tjaalton: all we need now is for GPG to be compromised and the galaxy will implode. [16:33] um. [16:33] openssh-server template parse error: Template #4 in /tmp/openssh-server.template.326872 has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline. [16:33] (gutsy) [16:35] jdong: actually I was asked about the possibility [16:37] ogra: ssh-vulnkey? [16:37] Hobbsee, yes [16:37] Hobbsee: see http://www.ubuntu.com/usn/usn-612-2 for details [16:38] thom: gutsy> argh [16:38] jdstrand: ^-- [16:38] meh [16:38] kees, hmm, it would be clever if the first page of the USN somehow indicated there is a second one i guess [16:39] ogra: I know the hostkeys are fine, since they are generated on a rhel cluster during installation, but the debian report said that all keys used during authentication are compromised.. [16:39] TheMuso, imbrandon, jdong: any chance somebody could approve my fakechroot SRU? (bug 228534) [16:39] Launchpad bug 228534 in fakechroot "Does not wrap *at() functions which makes fakechroot fail badly with Hardy" [High,In progress] https://launchpad.net/bugs/228534 [16:39] kees, if you dont guess that by url ... [16:40] tjaalton: all *DSA* keys [16:40] tjaalton: RSA keys are only broken if generated on a buggy system [16:40] ogra: it isn't explicit, you're right, but the 612-1 url is in the top header [16:41] cjwatson: argh [16:41] cjwatson: the non-default DSA breakage requires traffic capture and additional computational expense to crack, though? [16:41] pitti: sorry, lemme take a look; been scrambling the morning with the SSL fun [16:41] kees: correct, though perhaps not actually all that much additional computational expense (maybe) [16:41] jdong: it's not utterly urgent, but it's sitting there for a week or so [16:41] the DSA one is not fully analysed yet, we just know that there is a weakness there [16:42] ogra: which package is it in? [16:42] pitti: you've got it :) [16:42] jdong: wow, that was fast. thanks :) [16:42] ahhh, more upgrades here now. [16:42] Hobbsee, openssh-server [16:42] which probably means i have to regenerate again. sigh. [16:43] wait, no. [16:43] Hobbsee: the upgrade is apparently just Ubuntu sauce... [16:43] Hobbsee: i.e. regen vulnerable hostkeys on postinst, reject authenication from users with weak keys [16:46] thom: feisty and hardy are fine, for the record [16:46] jdong: Debian too [16:47] cjwatson: oh. what's the scope then? [16:47] jdong: err, sorry, not sure exactly what you're asking? [16:47] scope of what? [16:48] cjwatson: USN 612 [16:48] cjwatson: I thought feisty and hardy are affected? [16:48] oh, you misunderstood me [16:48] cjwatson: sorry, seems like I did :) [16:48] jdong: cjwatson was responding to my comment that the gutsy packages are bust [16:48] thom was pointing out a problem with the upgrades in gutsy-security [16:48] OH [16:48] ok [16:48] I noted that feisty-security and hardy-security don't have that upgrade problem [16:50] cjwatson: thansk for the clarification. === Shely_ is now known as Shely [16:53] I confirm what thom said [16:54] yep, we're working on it with all possible speed [16:54] cjwatson: so all DSA keys used (!) on a buggy system should be changed, not just those that were generated there? [16:55] tjaalton: it's a somewhat arguable case as yet; for complete safety, yes [16:55] compromising a DSA key used on a buggy system requires capturing a network trace, and it's not clear yet whether user keys are susceptible except by a malicious sshd [16:55] me? I've regenerated my DSA key [16:56] erring on the side of caution seems prudent when dealing with these matters :) [16:57] ok, maybe it's time to write an announcement for 20000 students :P [16:57] haha [16:58] ugh. I'm happy that almost all our servers are still on dapper. :) [16:58] heh [16:59] also, kerberos meaning no ssh key auth. :) [16:59] maswan: yeah kerberos is saving my life right now [16:59] my campus server keys don't need any additional work atm [16:59] but on my personal system I need to regenerate some IMAPS/HTTPS certs later today :) [17:00] we are still fighting whether to use MIT or AD or both [17:00] tjaalton: heimdal! :) [17:00] maswan: that too :) === ember_ is now known as ember [17:00] maswan: we actually have MIT already set up, but it's "unofficial" [17:00] use MIT ;-) [17:01] and no trust between MIT <-> AD [17:07] http://www.pastebin.ca/1016979 [17:07] anyone seeing that with the ssh update? [17:07] jcastro: gutsy? [17:08] yeah [17:08] a new version is being prepared for gutsy [17:08] (not my machine, just got asked by someone who did this) [17:08] ok [17:08] thanks [17:10] ssh update? You mean openssl or do you actually mean ssh? [17:10] Mithrandir: ssh [17:10] jcastro: known, in progress [17:11] maswan: heimdal seems to be linked with openssl here. Are you sure it's safe? [17:11] Mithrandir: no, it's likely broken just like mit kerberos. our kdcs etc are on dapper. :) [17:12] ah, ok [17:16] Hi all, I have a problem with the update of openssh-server on Gutsy 64bit. I know that you are working on it, if I can help with some test feel free to ask me (output of apt-get -f install: http://pastebin.ubuntu.com/11878/) [17:17] Volans: known, we're on it [17:17] Volans: I just asked the same question, it's being worked on [17:17] (you're number four ...) [17:18] hehehe :D [17:18] the fix is in the works [17:18] ok, better! :) just in case we can help you with some test [17:25] Hi all :) [17:33] cjwatson: the ideal output of a "fixed" system when running "sudo ssh-vulnkey -a" is an exit code of 0? [17:33] no, the opposite [17:33] the exit code semantics are a bit tricky I'm afraid [17:33] but ssh-vulnkey exits 0 if it finds at least one vulnerable key [17:34] cjwatson: interesting, okay. output of "Not blacklisted" is optimal? [17:34] yes [17:34] "Unknown (no blacklist information)" means it's a key type/length for which we don't have a blacklist [17:34] "COMPROMISED" means regenerate the bugger now [17:34] anybody help me out with this related error please? [17:34] https://www.uptime.org.uk/tmp/apt.txt [17:34] cjwatson: yup [17:35] cjwatson: thanks. [17:35] looks like a package problem [17:35] sdh: we're on it [17:35] sdh: have you gutsy? [17:35] cjwatson: ah, it's known about? [17:35] Volans: yep, server [17:35] yes, this is gutsy only [17:35] cjwatson: worth topic'ing? [17:36] i just update/upgraded to fix the ssl nightmare :) [17:36] s/fix/help start to fix/ :) [17:36] they are working on it, only Gutsy have this update problem on openssh-server due to the USN-612-1 fix [17:36] ok, cool, thanks [17:36] it's a single sodding blank line *sigh* [17:36] i'll hold off and keep an eye on here... then update/upgrade later === gnomefre1k is now known as gnomefreak [18:05] gutsy-security is fixed [18:05] thanks cjwatson :) [18:05] thom,no0tic,jcastro,Volans,sdh: ^-- [18:05] cjwatson: thanks, I'll let people know [18:06] thanks [18:07] thanks [18:07] thanks [18:07] cjwatson: just updated all worked fine [18:07] ta [18:08] great [18:08] thanks, /me informs #ubuntu [18:08] openssh upgraded correctly [18:08] but not openvpn [18:08] openvpn: Depends: openssl-blacklist which is a virtual package. [18:08] <[reed]> kees, jdstrand, cjwatson: ping... looks like the openssl/openssh packages are wrong [18:09] pitti: please give-back: libapache-htpasswd-perl libcrypt-hcesha-perl libcrypt-openssl-dsa-perl libhtml-fromtext-perl libgnome-java [18:09] <[reed]> so, this was the "fix" Debian made in 2006 [18:09] <[reed]> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c [18:09] <[reed]> and this was the back out 5 days ago: [18:09] <[reed]> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c [18:09] <[reed]> I see a problem! [18:09] [reed]: nah [18:09] <[reed]> why not? PURIFY isn't used for compiling [18:09] [reed]: the first change to rand/md_rand.c was wrong - that was in 0.9.8b-1 [18:09] <[reed]> that code is still compiled [18:10] <[reed]> cjwatson: that code is still there [18:10] [reed]: the PURIFY bit does not matter [18:10] ok, sorry, I thought you were asking about the filename difference, but in any case [18:10] [reed]: no, it's fine - one of those two diffs was acceptable, one was incorrect [18:10] Would this vulnerability affect a red hat server if I used Ubuntu to generate the key? [18:11] cody-somerville: yes [18:11]