[00:03] <jdong> bryce: sounds reasonable to me (shut up, wgrant and Hobbsee :P)... it's not like the installer writes any stateful info about the hardware
[00:03] <wgrant> !jdong
 jdong: yes, but you're FULL OF CRACK!
[00:16] <Nafallo> hehe
[00:17] <Nafallo> that's almost harsh :-P
[00:54] <macd> Has anyone had troubles with sshd after upgrade, newly generated keys from updated ssh/ssl gives errors when trying to auth via key on ssh, http://pastie.caboo.se/197206
[00:56] <slangasek> macd: I haven't seen this.  What version of Ubuntu are you running?
[00:56] <macd> in this case, my workstation is 8.04, 2 sshd's 7.10/8.04 both doing it
[00:57] <macd> I've tried removing/purging ssh things, and then deleteing all my keys, reinstalling ssh stuff, then regenerating my keys, still no go
[00:58] <macd> slangasek, ^ above (sorry forgot to prefix)
[00:59] <sdh> "If it works, edit the .ssh/authorized_keys file from your home directory. You will probably notice that you have a new line or an unappropriate character in your file. Each key on this file must be on one line only."
[00:59] <sdh> (from http://www.webprodevelopment.com/BrightLight/2006/01/09/fixing-a-sshd-error/)
[00:59] <slangasek> macd: does ssh -v give you any more useful information on the client side?
[00:59] <macd> sdh, thanks for the suggestion, but I figured that one out a long time ago ;P
[00:59] <sdh> macd: oh well :P
[01:00] <macd> slangasek, OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007 client/ OpenSSH_4.3p2 Debian-8ubuntu1.4, OpenSSL 0.9.8c 05 Sep 2006 server
[01:02] <macd> ohh, haha, not versions, verbosity
[01:02] <macd> slangasek, http://pastie.caboo.se/197224
[01:03] <slangasek> macd: hmm, ok
[01:04] <slangasek> will try to reproduce here
[01:04] <macd> sure thing, need any other output, or a bug on LP opened
[01:06] <slangasek> I suggest going ahead with opening a bug on LP regardless
[01:09] <macd> slangasek, I just tried using the key on my workstation to ssh to a bsd box, works fine....
[01:14] <slangasek> macd: and there's no doubt that the key you're using is newly-generated using a non-vulnerable version of openssh?
[01:15] <macd> slangasek, no doubt at all
[01:16] <macd> slangasek, Im a bit short on time at the moment, but I'll file a bug and subscribe you to it, whats your LP
[01:16] <slangasek> macd: 'vorlon'
[01:16] <macd> seen that one a few times, reminds me of babyln5
[01:16] <macd> slangasek, thanks, and take it easy
[06:54] <pitti> Good morning
[07:27] <dholbach> good morning
[07:54] <dholbach> did somebody ever encounter thunderbird not listing a mail folder (main view, filter view) even if it shows it as "subscribed to"? any advice?
[08:01] <dholbach> hum, it works after clicking and unclicking "show only subscribed folders" - nevermind
[08:20] <cjwatson> macd: I'm going to need output from 'sshd -ddd' on the server side to diagnose that bug. That is, you have to run 'sudo /etc/init.d/ssh stop', then bring up sshd in debugging mode with 'sudo /usr/sbin/sshd -ddd' (yes, you need the full path there), connect to it once, then 'sudo /etc/init.d/ssh start'
[09:23] <tkamppeter> pitti, hi
[09:28] <pitti> hi tkamppeter
[09:35] <fabbione> hi guys
[09:35] <fabbione> you guys at UDS yet?
[09:45] <tkamppeter> pitti, I will be in Prag from Saturady on, with my wife and her parents, Sunday evening I move into the conference hotel.
[09:45] <tkamppeter> pitti, are you already in Prag?
[09:45] <pitti> fabbione: not yet, this evening
[09:46] <pitti> tkamppeter: ^
[09:46] <fabbione> pitti: ok :)
[09:46] <tkamppeter> pitti, so you will visit Prag at first, too?
[09:47] <pitti> tkamppeter: no, only on Sunday; FOSSCamp will happen on Friday/Saturday
[09:50] <tkamppeter> I have prepared two blueprints: https://blueprints.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format and https://blueprints.edge.launchpad.net/ubuntu/+spec/applications-printing
[09:50] <tkamppeter> ubotu, tell something about the blueprints ...
[09:51] <tkamppeter> I would like to get some desktop application developers onto these BoFs, who should I subscribe?
[09:52] <pitti> tkamppeter: did you propose it for the conf already?
[09:53] <tkamppeter> pitti, yes, by "Propose for meeting agenda" in the menu on the left.
[09:53] <pitti> ok
[09:56] <tkamppeter> pitti, https://blueprints.edge.launchpad.net/ubuntu/+spec/applications-printing was not reported by me, but I would change the title, is there a way to do this?
[09:56] <pitti> tkamppeter: the title yes, but not the ID (IIRC)
[09:57] <tkamppeter> "Edit title and summary" appears only for the blueprints I have reported by myself. Is this a bug in PL?
[09:58] <tkamppeter> s/PL/LP/
[09:58] <pitti> ah, that might be a precaution against vandalism
[10:00] <tkamppeter> pitti, you are probably root on the server and can vi it to "Common Printing Dialog".
[10:00] <pitti> heh, no, I'm not :)
[10:00] <tkamppeter> pitti, but you are core-dev
[10:01] <pitti> I still can't change it, though
[10:01] <pwnguin> is there a calendar of UDS yet?
[10:03] <[reed]> is there a channel for UDS?
[10:13] <cjwatson> tkamppeter: an extraordinarily small number of people have root on the Launchpad database server, and vi doesn't work well on postgresql databases
[10:13] <cjwatson> tkamppeter: I've changed the title for you
[10:13] <cjwatson> (members of ubuntu-drivers can do that)
[10:25] <tkamppeter> cjwatson, thank you very much. The old title was really franglish.
[10:59] <Mithrandir> cjwatson: would it make sense to make it possible to disable DSA auth completely (sshd)?
[10:59] <cjwatson> yes, somebody filed a Debian bug report for that
[11:30] <pitti> Riddell, Hobbsee: can you please ask for appropriate automounting debugging procuedures in bug 205081? It works under Gnome, and I don't know the debugging for KDE
[11:41] <emgent> morning
[11:49] <emgent> dholbach: heya, some problem with iproute sync and nis merge?
[12:02] <emgent> norsetto: o/
[12:09] <norsetto> emgent: <>/
[12:37] <Hobbsee> pitti: i don't use kde, sorry
[12:42] <pitti> argh, where the heck do I find AM_CHECK_PYTHON_HEADERS ?
[12:43] <pitti> autoreconf stumbles over this, and it's not at all obvious where to find it
[12:43] <pitti> doko: ^ any idea?
[12:43] <pitti> (trying to fix the b0rked python-gobject merge)
[12:43] <pochu> ah
[12:43] <pochu> pitti: I was looking at it
[12:44] <pitti> I so much hate, hate, hate, hate autoconf
[12:44] <pochu> pitti: I've asked seb and that patch isn't needed anymore, we can change it with the last one from http://bugzilla.gnome.org/show_bug.cgi?id=481569 which fixes the bug instead of disabling the feature
[12:45] <pitti> pochu: oh, cool, so we can drop this 61_dont_use_setwakeupfd.patch?
[12:45] <pochu> yes
[12:45] <pitti> pochu: that would be good, since its purpose is undocumented, no bug#, etc.
[12:45] <pitti> rocking
[12:45] <pochu> and the autoreconf issues would be http://bugzilla.gnome.org/show_bug.cgi?id=471528, http://bugzilla.gnome.org/show_bug.cgi?id=471559, and probably others
[12:46] <pitti> ah, thanks
[12:46] <pitti> pochu: well, with dropping the patch I don't need to rebuild them any more
[12:46] <pochu> exactly :-)
[12:46] <pochu> I wonder how Joss got to rebuild it, though...
[12:53] <lool> pitti: BTW, I think I discussed it with you and seb128 to include the updated python-gobject patch in hardy-updates
[12:54] <lool> pitti: You're still ok with this?
[12:54] <pitti> lool: I don't think I was involved in that discussion
[12:54] <lool> Ok; well basically that wakeupfd stuff was broken in pygobject and we disabled it before hardy
[12:55] <pitti> right, that's the patch I just ripped out for intrepid
[12:55] <lool> But it causes wakeups in powertop for python apps such as deskbar applet
[12:55] <pitti> python-gobject uploaded now, for the record, it actually builds now; this should unbreak the world FTBFSing
[12:55] <lool> But you pulled the updated wakeupfd patch?
[12:55] <pochu> cool
[12:55] <pochu> hey lool
[12:56] <pitti> lool: no, I just dropped it, as pochu said
[12:56] <lool> I don't think it was tarball released
[12:56] <pitti> lool: we can still apply it in a followup upload if we need
[12:56] <pitti> but I'd really like to get this fixed in intrepid soon, it causes a hell of a lot of FTBFS and uninstallability ATM
[12:57] <pitti> (that's why I attacked it now in the first place)
[12:59] <lool> Ok, I thought we had a patch for this support but actually it was tarball releasedin the old broken version in 2.14;1
[12:59] <lool> What we want is the final implementation
[12:59] <pochu> pitti: could you retry exaile libbeagle anjuta (or add to your to-retry list :)
[13:00] <lool> pitti: So you uploaded ubuntu3?
[13:00] <pitti> lool: 2.14.1-4+ubu1, yes
[13:00] <pitti> (no remaining changes any more
[13:00] <pitti> pochu: kicked
[13:02] <pochu> thank you
[13:02] <mitsuhiko> hi all
[13:02] <mitsuhiko> why is ssh-vulnkey not available for dapper?
[13:02] <pitti> mitsuhiko: it will eventually
[13:03] <mitsuhiko> that's good news
[13:08] <pitti> pochu: btw, feel free to upload bug 208097
[13:09] <pitti> pochu: and maybe poke someone from ~motu-sru to ack it (Hobbsee, TheMuso, etc.)
[13:10] <pochu> ok, on it
[13:11] <pochu> What do people think about removing reportbug(-ng) from the archive? bug 175508
[13:14] <LimCore> hi cjwatson
[13:15] <LimCore> cjwatson: can we append a warning to the installer related to openssh,  that explains that the SERVERS that accept weak keys are still vulnerable and that users should consider that?
[13:15] <LimCore> becuse users dont ralize this usually
[13:47] <kagou> do anyone have an idea to which package should I assign Bug #230694 ?
[14:05] <lool> pitti: Hmm if you remove the patch completely, we get the borken setwakeupfd support again
[14:05] <lool> I'm preparing a Debian upload with the updated fix
[14:12] <lool> doko: Hmm will we get signal.set_wakeup_fd from 2.5.2-2ubuntu2 in Debian too?
[14:23] <pitti> lool: thanks
[14:54] <siretart> any reason to not publish openssl-blacklist in dapper-security?
[14:55] <lool> Blah, I hang python2.5 when rebuilding pygobject in hardy
[14:55] <lool> lalala .........*** glibc detected *** /usr/bin/python2.5: malloc(): memory corruption: 0x0000000000a39480 ***
[14:55] <lool> Looks like it could be amd64-ish
[14:57] <lool> doko: pygobject was uploaded the 9th of April in hardy and python2.5 the 8th and the 16th; I wonder whether it could be a 2.5.2-2ubuntu4 regression
[14:59] <mvirkkil> What time does FOSSCamp start tomorrow?
[15:01] <pitti> mvirkkil: 10 am, IIRC
[15:03] <Hobbsee> argh.
[15:03] <Hobbsee> 18 / 3 != 9
[15:04] <Hobbsee> did someone steal my brain?
[15:04] <pitti> Hobbsee: 5.99999993843 last time I checked :)
[15:04] <Hobbsee> :P
[15:04]  * realist gives back hobbsee-brain.deb
[15:06] <realist> pitti: FPU bug?
[15:08] <lool> doko: There's an insane amount of valgrind errors (even when only looking at access after free errors); I guess it's a wrong memory allocation function being used: do you have any tip on chasing such issues?
[15:09] <mvirkkil> pitti: Thanks. Couldn't find it anywhere on the FOSSCamp page.
[15:12] <Hobbsee> realist: ah, thanks.
[15:19] <juliank> doko: I really need Bug #220241 to be fixed. Running applets is (if it works) slow and the applet at java.com does not even work. (but worked with IcedTea 7 in gutsy)
[15:19] <emgent> heya people
[15:20] <juliank> doko: Somehow it works now. But why?
[15:21] <candrews> Question about the openssl vulnerability: why does openssl not use /dev/urandom for entropy on Linux? Why does it need anything other than /dev/urandom?
[15:26] <pochu> pitti: can you retry them again? when you did it python-gtk2 was still uninstallable due to python-gobject, but I've checked now on a chroot and they are installable with the update
[15:27] <pochu> exaile libbeagle anjuta
[15:27] <pitti> pochu: right, doing
[15:28] <pitti> done
[15:30] <pochu> thanks again :)
[15:43] <mdz> ETOPICFULL
[15:44] <\sh> ./ctcp * sound attention_regen_ssh-keys_now.wav
[15:48] <emgent> :D
[15:51] <Hobbsee> fricking oo.
[15:52] <Hobbsee> stop crashing!
[16:08] <doko> lool: is this needed?
[16:28] <lool> doko: Well the valgrind backtraces don't end up in the python modules I'm testing
[16:32] <lool> doko: http://people.ubuntu.com/~lool/pygtk-testactionsubclass.log
[16:33] <lool> doko: I guess these issues weren't present in the previous python2.5 as pygtk built against it for hardy
[16:34] <lool> doko: The tests causing glibc assertions are doing some gc.collect() and the changes you did to python2.5 seem to affect the gc; are these patches safe, could they expose bugs in other moduels?
[16:37] <doko> lool: which tests fail, are these tests using ctypes?
[16:38] <lool> doko: I'm not sure; there's "ctypes" usage in codegen/defsgen.py, but I don't see any in generated code
[16:39] <doko> hmm
[16:39] <lool> doko: If you simply rebuild pygtk locally, you should get the bug
[16:39] <doko> lool: I already had the wakeup stuff backported, just didn't upload
[16:39] <lool> doko: Oh, well I spent time today doing it too; too bad
[16:40] <lool> doko: I committed the patches to the Debian tree, but I can't test them under hardy due to this unrelated FTBFS
[16:40] <doko> Apr 30 ...
[16:40] <lool> ?
[16:41] <lool> You mean you had prepared pygobject and pygtk back Apr 30?
[16:41] <lool> Or do you mean you told me so at that date?
[16:42] <doko> do python2.5
[16:42] <lool> You included it in hardy already
[16:43] <lool> I don't understand what you say
[16:43] <mrec> hi it seems like that mplayer fires up dbus to open and hold the video nodes open .. this has a terrible sideeffect for hybrid devices which provide multiple nodes. When the analog video node is held open it's impossible to open eg the DVB or radio part of a analog TV/dvb/radio device
[16:44] <mrec> the dbus extension seems to be an ubuntu specific patch
[16:44] <mrec> (at least for mplayer)
 doko: Hmm will we get signal.set_wakeup_fd from 2.5.2-2ubuntu2 in Debian too?
[16:54] <doko> this was my answer
[17:06] <pecisk> hi people, how firefox translation from Launchpad gets into distribution? It is converted when issuing update for particular translation?
[17:15] <mrec> http://ubuntuforums.org/showthread.php?t=652941
[17:15] <mrec> does anyone know more about this?
[17:15] <mrec> I don't think it's mplayer mplayer accesses dbus yes but only for the screensaver thing
[17:52] <needbeer> http://www.dasdeutschlandspiel.de/index.php?page=beg.php&id=4410
[17:54] <needbeer> http://www.dasdeutschlandspiel.de/index.php?page=beg.php&id=4410
[17:55] <violinappren> hi all, i'm trying build the source package of synergy and i get "/usr/bin/fakeroot: 166: debian/rules: Permission denied" ... more at http://pastebin.ubuntu.com/12261/
[17:56] <stdin> violinappren: is debian/rules set executable?
[17:56] <liw> violinappren, "chmod +x debian/rules" should fix that; when apt-get unpacks the source code, it shoudl do that, I don't know why it didn't
[17:57] <liw> more specifically, dpkg-source should do it
[17:57] <liw> maybe the clean rule in debian/rules does something funny
[17:58] <violinappren> i did chmod +x on it and then ran "dpkg-buildpackage -rfakeroot -uc -b" and it still gives the same error .. "ls -al debian/rules" says it's -rwxr-xr-x
[17:59] <needbeer> http://www.dasdeutschlandspiel.de/index.php?page=beg.php&id=4410
[18:00] <stdin> needbeer: stop spamming
[18:01] <liw> violinappren, I can't reproduce the problem on hardy
[18:01] <needbeer> i already got 7 klines today on several networks, only a shotgun could stop me spamming :D
[18:01] <stdin> needbeer: ask an you shell receive
[18:02] <liw> violinappren, I can't reproduce the problem on hardy
[18:04] <liw> violinappren, do you have all build dependencies installed? "apt-get build-dep synergy" takes care of that
[18:05] <violinappren_> umm, i tried again in my home directory (rather than my "playground" partition) and it works (!)
[18:06] <stdin> violinappren_: same filesystem type?
[18:06] <violinappren_> yes i used ext3 allover the place
[18:06] <stdin> check the mount options, there is a noexec flag that cam be set iirc
[18:07] <violinappren_> mount says "/dev/sda3 on /media/sda3 type ext3 (rw,noexec,nosuid,nodev)"
[18:07] <liw> a-ha!
[18:07] <stdin> there you go then "noexec" will stop things from being executed even if set +x
[18:08] <violinappren_> aaaah
[18:08] <Ng> noexec is overrated
[18:08] <violinappren_> it must be a default in hardy since i never manaually set it!
[18:08] <stdin> check in your /etc/fstab
[18:08] <liw> it is set for automatically mounted volumes (ref. /media)
[18:09] <liw> by gnome-mount, that is
[18:09] <violinappren_> fstab has "/dev/sda3 /media/sda3 auto nouser,atime,auto,rw,nodev,noexec,nosuid 0 0"
[18:09] <violinappren_> (i added the mount points during a clean kubuntu hardy install)
[18:10] <stdin> unmount, take out the "noexec," and mount
[18:10] <liw> or don't build packages on that filesystem, of course -- the noexec might be there for a reason
[18:10] <lool> doko: Ok; are you interested in looking in the python2.5 memory corruption issue?
[18:10] <liw> (i.e., first figure out the reason)
[18:11] <doko> lool: please recheck with the recent python2.5 upload first, I'm travelling tomorrow, and I'm offline now
[18:11] <violinappren_> well it's a personal machine, not a work one, so no "policies" with noexec
[18:11] <lool> doko: the intrepid one?
[18:11] <lool> Or the hardy one?
[18:12] <doko> lool: intrepid, hardy should be ok for ctypes
[18:12] <doko> lool: you do use hardy-proposed, do you?
[18:12] <lool> doko: No, I don't; I've seen an upload from you in proposed, but it seemed unrelated
[18:14] <lool> doko: I'm pulling python2.5{,-dev,-minimal} from proposed
[18:14] <violinappren_> anyway, thanks guys/gals for your help
[18:14] <lool> doko: Same bug
[18:15] <lool> *** glibc detected *** python: free(): invalid next size (fast): 0x0000000000b297b0 ***
[18:17] <lool> I'm debootstrapping intrepid, but I don't have much hope
[18:26] <lool> doko: Under intrepid, same thing http://paste.ubuntu.com/12270/
[18:26] <lool> Well hardy's kernel
[18:27] <norsetto> looks like debian new is chocked
[18:27] <lool> norsetto: ?
[18:28] <norsetto> lool: is it normal for so many packages to be sitting there for weeks?
[18:28] <lool> Yes
[18:30] <lool> norsetto: these are old graphes, but it's still being processed in batch http://heracles.corsac.net/~corsac/debian/new/
[18:31] <norsetto> lool: amazing
[18:57] <macd> cjwatson, ping
[19:43] <emgent> norsetto: o/
[20:04] <fbond> Hi, there seems to be some confusion regarding xorg.conf in 8.04.  Is it possible to force X.org to use a particular display driver, even if auto-detection suggests otherwise?  What is the best way to do this?
[20:10] <slangasek> fbond: all the previously supported xorg.conf options can still be used, to their usual effect; we just don't use them by default because autodetection now gives correct results in the vast majority of cases
[20:13] <fbond> slangasek: Am I incorrect, then, in thinking that I ought to be able to add a `Driver ...' line to the "Device" section and have that force the display driver?
[20:13] <tjaalton> fbond: correct
[20:14] <fbond> Of course you know that I'm asking because it's not working for me.
[20:14] <fbond> The log file indicates that the vesa driver is being used.
[20:14] <fbond> If the requested driver does not load, will the vesa driver be used instead?
[20:14] <tjaalton> if the xserver fails to start, yes
[20:15] <fbond> Hm.  It seems to do this silently; no warnings or anything.  Makes debugging a bit confusing if you come from the Old Way where the server doesn't start at all when the driver didn't pan out.
[20:15] <tjaalton> there's a bug about that
[20:16] <fbond> Oh, is there?  I couldn't find anything, and wasn't sure if I just didn't understand X.org anymore.
[20:16] <fbond> tjaalton: Do you have a bug #?
[20:17] <tjaalton> bug 148122 seems to be the one
[20:17] <tjaalton> boarding time, finally ->
[20:18] <fbond> tjaalton: No, this is a different situation.  I'm not getting the graphical configuration utility at all.  X starts normally, just with the wrong driver.
[20:26] <tseliot> ﻿fbond: that's because no driver is specified in the Device section of your xorg.conf
[20:27] <tseliot> ﻿﻿fbond: maybe Xorg's automatic detection didn't work as it should
[20:30] <fbond> tseliot: I *did* specify a driver.  That's why I'm bothered.
[20:31] <tseliot> ﻿fbond: can I see your xorg.conf and your /var/log/Xorg.0.log (use pastebin, please)?
[20:31] <fbond> tseliot: one sec.
[20:34] <tseliot> ﻿fbond: oh and I would be glad if you could post the output of this command too sudo updatedb && locate xorg.conf
[20:47] <fbond> tseliot: I think I see what's going on that is confusing me.
[20:47] <fbond> The machine in question was already being tested by someone else.
[20:47] <fbond> When I got to it, he had already seen the "low-graphics mode" dialog.
[20:48] <fbond> I edited the xorg.conf and then restarted the X server by pressing Ctl-Alt-Bkspc
[20:48] <fbond> However, it seems that restarting the bulletproof X server via C-A-B does not cause the configuration to be re-read.  I'm beginning to understand that the bulletproof X server is a separate server with a separate configuration.
[20:49] <fbond> Thus, it appeared that my configuration wasn't being read.
[20:49] <fbond> Does this sound right?
[20:50] <fbond> Now, I was eventually able to get to a log file with the openchrome output, and found the problem there.  I had to restart gdm to trigger the configuration to be re-read.
[20:50] <tseliot> ﻿fbond: yes, that's what I was going to suggest
[20:50] <fbond> I wonder if some more documentation might be helpful to advanced users trying to fiddle with things.
[20:51] <tseliot> fbond: bryce knows more about this
[20:52] <tseliot> and you can have a look at this page: https://wiki.ubuntu.com/X
[20:53] <tseliot> I've got to go now. Bye
[20:53] <fbond> tseliot: thanks
[21:12] <dmb> is this openssl bug going to require the creating of Ubuntu 8.04.1 lts?
[21:14] <liw> 8.04.1 was going to be created anyway
[21:29] <geser> pitti: Hi, I've seen that apache2 got uploaded to hardy-proposed. As apache2-mpm-itk has a very strict dependency on apache2.2-common it needs a rebuild for every apache2 upload. Does this somehow influence the SRU of apache2?
[21:33]  * slangasek shakes his fist at itk
[21:33] <slangasek> geser: would be great if someone could prepare an itk upload then; I'll be happy to push it through alongside apache2
[21:35] <geser> slangasek: would this weekend be early enough?
[21:35] <slangasek> geser: I imagine so
[22:01] <emgent> heya
[22:10] <emgent> heya sabdfl :)
[22:23] <sabdfl> howdy all
[22:24] <ion_> Hi
[22:24] <Kaleo> hi sabdfl
[22:32] <Nafallo> hey :-)
[22:32] <emgent> Nafallo: :)
[23:09] <johanbr> Hmm. The UDS wiki page still says "More details about remote participation will be announced closer to the time. ".
[23:11] <stgraber> johanbr: they have till Monday :)
[23:35] <xivulon> slangasek, would you mind clarify the first bullet in #226622? I am not too knowledgeable on versioning conventions