[05:16] <Voyage> How to see recently used textfiles. Kate normal history is not suffice
[10:40] <ikonia> /wi/win 14
[10:40] <ikonia> oops
[15:27] <k1l> anabain> TJ-, anyway, I'm using kubuntu, and I'm interested in qdbus on dolphin.
[15:28] <k1l> but asking about nautilus and dbus o_O


[01:38] <lamont`> BenC: it still says find: /lib/firmware/2.6.22-10-hppa64: No such file or directory with -10.30, just fyi. :)
[03:16] <doko> kylem, BenC: please could you add lpia support to: linux-backports-modules-2.6.22 linux-meta linux-source-2.6.22 linux-ubuntu-modules-2.6.22
[09:13] <kraut> moin
[09:43] <verwilst> morning
[11:30] <tseliot> BenC: can I steal a minute of your time?
[01:54] <paran> could someone look at bug 92553? I have sent two mails about it to the kernel-team list, the last one with a patch attached, but both have been ignored.
[01:54] <paran> if there is something wrong with my solution i'd really like to know so that I can fix it.
[01:55] <jwendell> Hi, BenC. I'm seeing on changelog you dropped snd-hda-intel on version 10.30. Now i have no sound on my laptop
[01:55] <jwendell> BenC, what should i do in order to have my sound back?
[02:41] <zul> hah someone wants cfs
[02:59] <verwilst> hi zul
[03:00] <verwilst> zul: you have mail
[03:00] <verwilst> zul: already gets a lot further than without the patch :)
[03:05] <zul> ill send you a patch
[03:07] <verwilst> okido
[03:07] <verwilst> go ahead, i'll test it right away
[03:07] <verwilst> an updated "diff" ?
[03:08] <zul> yeah it'll have to be later though since I just got into work
[03:12] <verwilst> ah ok :) after work you mean?
[03:12] <zul> probably
[03:12] <verwilst> ok! enjoy your work then :)
[03:29] <ogra> zul, https://lists.ubuntu.com/archives/ubuntu-users/2007-August/121818.html is that known ?
[03:30] <zul> ogra: not that i know of
[03:33] <zul> ogra: http://lists.xensource.com/archives/html/xen-users/2006-10/msg00103.html
[03:35] <ogra> i'll point him to that, thanks
[03:36] <zul> no probs
[03:44] <verwilst> zul: found the problem i think
[03:44] <zul> oh?
[03:45] <verwilst> you set LOCALVERSION to "-xen"
[03:45] <verwilst> but you have an EXTRAVERSION in make, that's -10-xen
[03:45] <verwilst> making it -10-xen-xen
[03:45] <zul> ok
[03:45] <verwilst> setting the localversion in config.amd64 to "" should fix it
[03:45] <verwilst> trying now
[03:46] <verwilst> zul: the kernel itself compiles fine though
[03:52] <paran> ignored once again. am I the only one actually using the linux-image-debug-packages? :-)
[04:26] <verwilst> zul: linux-headers-2.6.22-10-xen_2.6.22-10.30_amd64.deb and linux-image-2.6.22-10-xen_2.6.22-10.30_amd64.deb are present! ;)
[04:26] <verwilst> so it works
[04:26] <verwilst> i'll go home in 30 mins and try booting with it
[04:26] <zul> ok
[04:26] <verwilst> ( had to add amd64 in control first :)
[04:26] <verwilst> and the small fix to config.amd64
[04:31] <verwilst> zul: Signed-off-by: Bart Verwilst<EMAIL_ADDRESS>[04:31] <verwilst> hehehe
[04:33] <Kano> hi
[04:33] <Kano> config-2.6.22-10-generic:# CONFIG_SND_HDA_INTEL is not set
[04:33] <Kano> is that by purpose?
[04:34] <rtg> Kano: CONFIG_SND_HDA_INTEL is fubar'd. It being worked on.
[04:36] <mjg59> Kano: Check Launchpad. It's a known issue.
[04:36] <tseliot>  hi, does anybody know why my patches (for Feisty and Gutsy) haven't been approved yet? https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/66 https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/98641/comments/67
[04:38] <Kano> hmm system lock with that kernel...
[04:40] <BenC> tseliot: I thought that were in there...I'll check them in a few
[04:40] <Kano> why was hda-intel not active??
[04:40] <tseliot> BenC: thanks
[04:41] <mjg59> Kano: Because it was in linux-ubuntu-modules instead
[04:42] <Kano> any specific reason why it was not patched directly
[04:42] <mjg59> Because of a desire tokeep the Linux source as close to upstream as possible
[04:43] <Kano> why have been most of my kernel patches ignored
[04:43] <Kano> only the one from mm was integrated
[04:44] <mjg59> What makes you think they've been ignored?
[04:44] <Kano> they did not have been applied
[04:45] <Kano> and i added a bug one month ago for each of em
[04:45] <Kano> how do you compile linux-ubuntu-modules for one flavour only
[04:46] <zul> *sigh* here we go again
[04:48] <mjg59> Kano: linux-restricted-modules is generally handled at a lowerpriority than the core kernel. I'll be done before the release.
[04:48] <Kano> patches that only change 1 or 2 lines...
[04:48] <Kano> but the 2 others
[04:48] <Kano> about hostap_cs and the via southbridge on intel
[04:48] <Kano> currently i even patch the a new siemens id
[04:49] <Kano> these 2 where against 2.6.22 directly
[04:50] <BenC> Kano: fakeroot debian/rules binary-modules-generic
[04:50] <Kano> BenC: thanx. and for restricted too?
[04:51] <BenC> for lrm, you're just going to have to build the whole thing
[04:51] <BenC> no one has switched it over to the new build system yet, because it's ugly and hairy
[04:52] <Kano> not good...
[04:52] <mjg59> Kano: Working patches welcomed
[04:52] <Kano> they work
[04:52] <Kano> but still ignored
[04:52] <mjg59> There's no real incentive to change it - lrm builds correctly, and for the purposes of Ubuntu development there's no real incentive to build it for a single flavour
[04:53] <lamont> it's not like the build takes a long time
[04:55] <verwilst> zul: just to let you know, the kernel boots fine
[04:55] <lamont> 13 minutes is quick
[04:55] <verwilst> xend starts, xm list works, ...
[04:55] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/128289
[04:55] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132466
[04:55] <Kano> patches working, not included
[04:55] <mjg59> Kano: Thank you. We can list your bugs.
[04:55] <mjg59> Kano: They're patches of low importance and low risk, so they're not high priority righ tnow
[04:56] <mjg59> We're part-way through a development cycle. If they're not there by beta, then please feel free to remind us.
[04:56] <Kano> well risk is really low, just apply em
[04:56] <Kano> i know that they are correct. otherwise pure ubuntu kernels are absolutely useless for me
[04:56] <mjg59> But there's no point whatsoever in doing so until then. It won't make things happen any faster.
[04:57] <BenC> Kano: it's true, we could "just apply them", but the reality is, those are not the only two bugs we have to look at...we have to prioritize, else we'll never get the big problems taken care of
[04:58] <BenC> Kano: but your fixes will get in
[04:58] <Kano> there is a new one i currently patch. the one who found it reported it here:
[04:58] <Kano> http://bugzilla.kernel.org/show_bug.cgi?id=8932
[04:59] <Kano> also only id changes
[04:59] <Kano> 2 lines
[04:59] <mjg59> Kano: Please file a bug and link to the upstream bug
[04:59] <nixternal> quick question...with gutsy, my realtek 8139 lappy eth connection craps out on the wan, works fine on the lan...happens after a while of use, and then comes back...would this be kernel related at all? I just started noticing this yesterday (24+ hours ago)
[05:00] <BenC> Kano: if you want things faster, apply for a kernel.ubuntu.com account, clone our tree, commit the patches and send a pull request
[05:00] <nixternal> not wireless
[05:00] <nixternal> I can hit my gateway fine, but anything outside of my network I can't...and it is only this laptop, it doesn't happen with any other gutsy machine here
[05:00] <lamont> ah, ok
[05:00] <BenC> nixternal: doesn't sound like kernel
[05:00] <lamont> that sounds more like a router issue
[05:01] <nixternal> why only this laptop and not my other machines?
[05:01] <nixternal> hehe
[05:02] <nixternal> you know, I wouldn't 100% put it past the router either after our storms and issues last night, but it is just odd that it only happens to one machine
[05:02] <BenC> nixternal: could be something whacky with network-manager :)
[05:02] <nixternal> BenC: network-mangler you mean :)
[05:02] <BenC> for example, if it dropped the default route
[05:02] <mjg59> nixternal: Are the other machines running Linux?
[05:03] <nixternal> mjg59: yessir
[05:03] <mjg59> Hm. Ok.
[05:03] <mjg59> If the card is able to talk to your local network, it's highly unlikely that it's a kernel issue
[05:03] <mjg59> Unless your upstream is *very* odd
[05:03] <nixternal> ie. I am connected to my server which is running gutsy, that is how I am able to stay on IRC
[05:03] <BenC> nixternal: next time it happens, check "route" output to see if it's sane
[05:03] <nixternal> BenC: will do
[05:03] <mjg59> Best you could do would be to get a tcpdump of the the traffic when it's affected
[05:04] <Kano> ubuntu is really fast... just as fast as the ntfs-3g development. there is 1.8 out and 1.7 in repository...
[05:04] <nixternal> looks sane
[05:04] <nixternal> it is affected right now...let me try tcpdump
[05:04] <Kano> do i really have to report every bug...
[05:04] <zul> yes
[05:05] <zul> then it would never get fixed
[05:05] <BenC> Kano: when we hit kernel freeze, we only take fixes that have bug reports associated with them
[05:05] <Kano> is nobody tracking upstream on major packages, and ntfs-3g is major
[05:05] <Kano> it writes on ntfs
[05:05] <mjg59> Kano: We're past upstream version freeze.
[05:05] <BenC> Kano: pkl is taking care of our ntfs-write support
[05:06] <mjg59> No new upstream versions will be accepted unless somebody explicitly requests them.
[05:06] <Kano> i use it since 14 days without problems
[05:07] <zul> BenC: what should i do with the cfs wishlist bug report?
[05:07] <BenC> zul: bug#?
[05:07] <nixternal> heh, as soon as I run tcpdump the connection comes back
[05:08] <zul> 134491
[05:08] <rtg> zul: revert it to wishlist from confirmed.
[05:09] <zul> its already wishlist
[05:10] <rtg> zul: never mind. I confused status with importance.
[05:11] <zul> BenC: i say tell them to wait til gutsy+1
[05:11] <BenC> zul: mark as wont fix in 2.6.22 with a comment about being too late, and tag it gutsy-plus-one
[05:12] <BenC> zul: actually, better tag may be deferred
[05:15] <zul> BenC: done
[05:15] <BenC> zul: gracias
[05:15] <zul> no probs
[05:20] <tseliot> BenC: if you have any questions on my patches I'll be glad to answer
[05:23] <Kano> why do you compile ipw3945 and iwlwifi?
[05:24] <mjg59> Kano: Because iwlwifi is currently not stable on 3945
[05:24] <Kano> and why is it compiled then
[05:24] <Kano> you would need to blacklist it
[05:25] <mjg59> The 3945 IDs have been removed
[05:25] <mjg59> It's used for 4965
[05:25] <Kano> hmm
[05:26] <Kano> thats older lirc or
[05:26] <BenC> tseliot: sure thing
[05:26] <BlueDevil> BenC: can you share how you built the packages for nvidia 100.14.11 driver and l-r-m please?
[05:26] <BlueDevil> i'd like to build the same packages for my system. thanks
[05:26] <BenC> BlueDevil: I'm not sure what you mean
[05:26] <Kano> hmm lirc is new
[05:26] <Kano> but why is ttusbir not there
[05:27] <BenC> BlueDevil: install the latest nvidia-glx-new and you have that
[05:27] <BlueDevil> BenC: i'm running a custom kernel (because the stock kernel does not support more than 4G of ram) so i need to build l-r-m myself, right?
[05:27] <Kano> any specific reason to skip that module?
[05:28] <BenC> BlueDevil: you're better off just downloading the nvidia installer and running that for your kernel
[05:28] <BenC> Kano: lirc support came from a community member, we didn't decide what to put in there, we too what the guy gave us
[05:28] <BlueDevil> BenC: would i be able to deinstall what the installer installed if I ever wanted to?
[05:29] <BenC> took
[05:29] <BenC> BlueDevil: yes
[05:29] <BlueDevil> how?
[05:29] <tseliot> BlueDevil: you can install nvidia-glx-new nvidia-glx-new-kernel-source (or whatever it is called) and build the kernel module with module-assistant
[05:29] <Kano> BenC: i think he missed that the new lirc has a new module
[05:29] <BenC> BlueDevil: the installer will uninstall too
[05:30] <BlueDevil> tseliot: i'm not sure how to build that
[05:30] <BenC> Kano: I wasn't very keen on lirc being included in lum anyway, but the ubuntu-media folks needed it to support hw out of the box
[05:30] <Kano> yes it is needed just like the new module
[05:30] <BlueDevil> are there any chances that the kernel in gutsy will support more than 4G ram by default?
[05:30] <BenC> Kano: then by all means include it
[05:30] <tseliot> BlueDevil: you can uninstall it by typing sudo sh nameoftheinstaller --uninstall
[05:30] <Kano> i think only the CONFIG_LIRC line is missing
[05:30] <Kano> the source is there
[05:31] <BenC> BlueDevil: Not likely to happen in our default 32-bit kernel...why not run 64-bit?
[05:31] <Kano> will check it
[05:32] <tseliot> BlueDevil: this is something we can discuss elsewhere. I can show you how to do that in just few mouse clicks
[05:32] <BlueDevil> BenC: because i'm in the online video business and 64bit is nothing but trouble in that respect (flash + w32codecs) :(
[05:32] <BlueDevil> tseliot: can I pm you?
[05:32] <tseliot> BlueDevil: sure
[05:32] <BlueDevil> thx
[05:32] <BenC> BlueDevil: Maybe you should run the -server kernel?
[05:33] <BlueDevil> BenC: i tried the -bigiron but nvidia wouldn't work, would i have better success with -server?
[05:33] <BenC> BlueDevil: it's worth a shot
[05:34] <Kano> it seems you manually added those, well should be no problem...
[05:41] <Kano> well the makefile mod is simple, whats with that 0list?
[05:41] <Kano> or should it be in every arch
[05:42] <BenC> 0list is a template
[05:43] <Kano> CONFIG_LIRC_TTUSBIR=m
[05:43] <Kano> should i add it everywhere?
[05:43] <BenC> each arch needs the CONFIG_* line in it
[05:43] <BenC> yeah, including the 0list file
[05:44] <Kano> well you have to check if it compiles..
[05:44] <BenC> I'm not going to include a patch that I know I have to test
[05:44] <Kano> i can not compile sparc and such things
[05:45] <Kano> that is no real patch, i just added the line in the makefile
[05:45] <BenC> you don't have to test it everywhere
[05:45] <BenC> just binary-modules-generic will make me happy
[05:45] <BenC> Kano: does it apply with the patch command?
[05:45] <Kano> tested that on i386
[05:46] <Kano> wait one second
[05:49] <Kano> should i dcc you the patch
[05:49] <Kano> or upload
[05:49] <cjwatson> people still use dcc?
[05:49] <Kano> a very simple one
[05:50] <BenC> hehe
[05:50] <BenC> I haven't used dcc since the efnet days
[05:50] <Kano> http://kanotix.com/files/kernel/linux-ubuntu-modules-2.6.22-2.6.22-lirc-ttusbir.patch
[05:50] <BenC> Kano: email to kernel-team is preferred
[05:51] <BenC><EMAIL_ADDRESS>[05:54] <verwilst> zul: could i recommend 1 more patch?
[05:55] <verwilst> http://overlays.gentoo.org/proj/xen/browser/patches/tags/2.6.20/fedora-xen-patches-2.6.20-2925.13.fc7/1665-linux-2.6-disable-netback-checksum.patch?rev=10
[05:55] <verwilst> it's a one-liner
[05:55] <verwilst> but it makes sure you don't need to do ethtool -K ethX tx off
[06:01] <Kano> why is ndiswrapper 1.45 not 1.47?
[06:01] <BenC> Kano: UPSTREAM-VERSION-FREEZE
[06:02] <Kano> do you really know how long 1.47 was avalable
[06:02] <BenC> unless we have a compelling reason to do so, it wont get upgraded
[06:02] <Kano> bugfixes
[06:02] <BenC> Kano: can you list the bugs?
[06:02] <BenC> Kano: can you tell me how severe they are?
[06:02] <Kano> 1.47 is out since 27. 04.
[06:02] <Kano> 4 months
[06:02] <BenC> if we go by bug-fix alone, we'll be upgrading till release day
[06:03] <Hobbsee> BenC: Kano seems to be out to troll, so probably wont answer that
[06:03] <Kano> Hobbsee: should i add all changelogs since 1.46 to the bugreport?!
[06:03] <Hobbsee> BenC: that being said though, upgrades of ndiswrapper are usually a good idea, for the hellish cards that require them.
[06:03] <Hobbsee> Kano: list the bug fixes.  not changes.
[06:04] <mjg59> Kano: If you can point us to people who are having bugs in Ubuntu, that's significantly more compelling
[06:04] <Kano> Version 1.46 has been released. Short summary of changes since 1.45:
[06:04] <Kano>     * Fixed crash with large transfers (bug in version 1.45)
[06:04] <Kano> Version 1.47 has been released. Short summary of changes since 1.46:
[06:04] <Kano>     * Fixed random (occassional) crash issues with 64-bit drivers (observed with Broadcom driver)
[06:04] <Kano>     * Fixed compilation issues with version 1.46
[06:04] <Kano> so you see 64 bit fixes
[06:05] <verwilst> zul: mail sent
[06:05] <verwilst> bye!
[06:06] <BenC> Kano: 64-bit doesn't concern me too much
[06:06] <BenC> people have way too many excuses already to use 32-bit even on x86_64 hw
[06:06] <Hobbsee> ndiswrapper seems to have a disobliging habit of *breaking* some cards, the further up they go.
[06:07] <Hobbsee> version-wise
[06:07] <Kano> Hobbsee: i really prefer to use latest code
[06:07] <BenC> yeah, hence, fixing things may not be worth breaking other things
[06:07] <Hobbsee> Kano: i prefer to use code that *works*.
[06:07] <Hobbsee> Kano: tell that to my old wifi card, which broke with later versions of ndiswrapper.
[06:08] <Kano> Hobbsee: then you are not able to go to #ndiswrapper and speak to giri
[06:08] <Kano> i did serveral times, even donated to him
[06:08] <Hobbsee> Kano: you assume, wrongly, that i did not.
[06:09] <Kano> and it still does not work with 1.47?
[06:09] <Hobbsee> see the part about "old"
[06:09] <Hobbsee> it broke in 1.17, iirc.  i no longer have that card.
[06:10] <Kano> what i absolutely know is that the feisty ndiswrapper was unusable at all for my card
[06:11] <Kano> so i skipped feisty not because of that, but due to other problems
[06:13] <Kano> hmm even 1.48rc1 there...
[06:16] <mjg59> We're not shipping a release candidate
[06:18] <Kano> then use 1.47
[06:19] <mjg59> Kano: As I said, if you can point us to bugs filed against Ubuntu that show people having problems, it's much easier to convince the release team that we should do that
[06:19] <mjg59> But if we have no evidence of people having problems, we're not going to take the risk of introducing new and unknown bugs
[06:20] <Kano> the only reason that i see is that your current ubuntu users are not heavy ndiswrapper users. but kanotix users are
[06:21] <Kano> and when i want use ubuntu as base then i dont want to have worse hw support than before
[06:21] <mjg59> Kano: Perhaps the needs of your users do not align well with the Ubuntu release methods?
[06:23] <BenC> Kano: any time you use a release distribution, you are going to have slightly out-dated software
[06:24] <BenC> there's no way to get a stable dist with latest software all around
[06:24] <Kano> BenC:  sure, but not the main drivers
[06:24] <BenC> Kano: I'd hardly call ndiswrapper a main driver
[06:24] <Kano> ntfs-3g, ndiswrapper are thing that i monitor
[06:24] <mjg59> Kano: We don't accept new upstream versions after the 16th of August unless there are important bugs that we know they will fix
[06:24] <BenC> Kano: important to you doesn't mean important to all of our users
[06:25] <mjg59> Kano: If that's unacceptable to you, then I suggest that you either changethe process (you'll want to contact the technical board) or find a new source of kernels
[06:29] <doko> kylem, BenC: please could you add lpia support to: linux-backports-modules-2.6.22 linux-meta linux-source-2.6.22 linux-ubuntu-modules-2.6.22
[06:33] <BenC> doko: I'm pretty sure it's in linux-source, linux-meta and linux-ubuntu-modules
[06:33] <doko> lookking
[06:33] <BenC> doko: just needed for lbm and lrm
[06:40] <doko> BenC: linux-meta doesn't build linux-headers-generic and linux-image-generic . correct?
[06:42] <BenC> doko: yeah, it does
[06:43] <doko> BenC: and linux-ubuntu-modules and linux-backports-modules-2.6.22 is not needed for the live CD, apparently
[06:44] <BenC> doko: linux-ubuntu-modules is
[06:47] <doko> BenC: ok, was confused that lpia doesn't have a -generic, but just a -lpia kernel. but as long as that's roughly the same config as i386 that will let us boot from the liveCD
[06:47] <BenC> doko: well, linux-ubuntu-modules-2.6.22-abi-generic is, not sure about the meta package
[06:48] <BenC> doko: lpia flavour is pretty much the same as ume
[06:48] <doko> apt-cache -n search linux-ubuntu doesn't show anything
[06:51] <tseliot> doko: linux-restricted-modules
[06:51] <doko> yes, missing as well
[06:52] <tseliot> doko: instead of linux-ubuntu-modules
[06:57] <zul> doko: i was wondering why you added ipia to xen-3.1?
[06:58] <tseliot> doko: doesn't this command return anything??? apt-cache -n search linux-restricted-modules
[07:00] <doko> tseliot: it does on amd64, not on lpia
[07:00] <doko> zul: looking if it builds and works with gcc-4.2
[07:01] <zul> ah ok
[07:02] <tseliot> doko: sorry, I didn't read ipia flavour...
[08:04] <BlueDevil> what is the downside of compiling a kernel with HIGHMEM64G=y vs HIGHMEM4G=y?
[08:05] <BenC> BlueDevil: more overhead
[08:05] <BenC> you really only want 64G enabled if you have > 4G of memory
[08:06] <BlueDevil> do you know if any benchmarks have been done?
[08:06] <BenC> otherwise it hurts you performance wise and takes up more memory just for memory management
[08:06] <BenC> BlueDevil: I can't point you to any, but I'm pretty sure it's been done
[08:08] <BenC> I think most people assume that you'll be running a 64-bit kernel on such machines
[08:08] <BenC> there are ways to run 32-bit stuff decently on 64-bit
[08:08] <BenC> ia32-libs and friends help a lot
[08:09] <BlueDevil> the last time i ran flash in a 32bit chroot it took away part of my filesystem when it crashed; i didn't even think that was possible
[08:10] <BenC> were you running it as root?
[08:10] <BlueDevil> no
[08:10] <BenC> I don't see how it can corrupt your fs if it isn't run as root
[08:10] <BenC> that would be a major bug :)
[08:11] <BlueDevil> i didnt investigate much the machine being a production one; i just reinstalled 32bit
[08:12] <BlueDevil> AFAIK it didn't do anything outside of the chroot but i wasn't going to risk it
[08:17] <BenC> BlueDevil: why not ditch the chroot and use ia32-libs and the 32-bit firefox plug-in wrapper?
[08:18] <BlueDevil> BenC: i don't think those were available at that time
[08:18] <BlueDevil> i was on dapper-1
[08:18] <BlueDevil> or -2
[08:19] <BlueDevil> everybody was recommending 32-bit chroot to run flash
[08:20] <BlueDevil> looking now at ia32libs
[08:21] <BlueDevil> what are my options for w32codecs?
[08:25] <JanC> w32codecs are illegal, so...  ;)
[08:26] <tseliot> BlueDevil: have a look at this sticky in the forum: http://ubuntuforums.org/showthread.php?t=191205
[08:27] <BlueDevil> JanC: why are w32codecs illegal?
[08:27] <BlueDevil> i own a windows xp oem copy for the machine
[08:28] <pmjdebruijn> BlueDevil, because MS' license probably says you may only use the codecs in conjunction with WinXP
[08:32] <JanC> that license says that, but that part might be illegal in itself in some countries
[08:33] <JanC> OTOH, there is no license that allows redistribution of those codecs in the way w32codecs does
[08:33] <JanC> so if you use the codecs on your WinXP partition, that might be okay, but w32codecs certainly isn't
[10:14] <verwilst> http://pastebin.ca/669541 <- anybody knows about this?
[10:16] <verwilst> had to modprobe dm-mod manually


[07:25] <dholbach> good morning
[20:42] <phillw> Hi good people, there is an error (our fault) on http://fridge.ubuntu.com/calendars/ regarding lubuntu. Who do I need to contact to have it corrected?
[20:42] <jose> phillw: people here
[20:43] <pleia2> which calendar?
[20:43] <pleia2> just let us know what to fix :)
[20:43] <phillw> pleia2: http://fridge.ubuntu.com/calendars/
[20:43] <jose> phillw: what's the error?
[20:43] <pleia2> phillw: there are 3 calendars on that
[20:43] <pleia2> fridge, learning and release
[20:44] <phillw> pleia2: I'm looking at month on that link.
[20:44] <phillw> pleia2: The Fridge calendar, which is used to track Ubuntu team meetings/events
[20:44] <jose> I think he's talking about the fridge
[20:44] <pleia2> ah, ok
[20:44] <pleia2> can you please tell jose what needs changing? :)
[20:44] <phillw> lubuntu no longer have weekly meetings
[20:45] <phillw> jose: ^^
[20:45] <pleia2> delete them entirely?
[20:45] <jose> phillw: so, is it fine to just delete all the meetings?
[20:45] <phillw> jose: yes, our meetings are scheduled as per https://wiki.ubuntu.com/Lubuntu/IRC%20Meetings/Agenda
[20:46] <phillw> as we hold them on #lubuntu-offtopic so as not to clash with other teams as they are now milestone based.
[20:47] <jose> phillw: the Fridge calendar is basically for #ubuntu-meeting meetings, is there a real need to do those in #lubuntu-offtopic
[20:47] <phillw> there is a meetingbot clone on there, so logs are kept as per normal meeting channel.
[20:47] <jose> because we should note that this is also an official flavor meeting
[20:48] <phillw> jose: our proposed ones did clash on a couple of occasions when we were setting them up. So as to not to confuse people by having some on #ubuntu-meeting and some on #lubuntu-offtopic it was thought better to hold them all on one channel so people are not turning up on the wrong channel :)
[20:49] <jose> phillw: that time is specifically reserved for the Lubuntu Team Meeting, and it would have preference over another meeting as it's already scheduled
[20:49] <jose> would you like to discuss changing them to #ubuntu-meeting? that way it'd be following all fridge calendar guidelines
[20:51] <phillw> jose: we only have one left this cycle. For next cycle whilst I can book them as soon as 14.04 release schedule is finalised, I will not know what (if any) meetings that our TL wants to hold on what is planned for 14.04 probably until after vUDS
[20:52] <jose> phillw: ok, I will cancel all future meetings and only remain with this one for the 15th, is that ok?
[20:53] <phillw> jose: that'd be great.. is it possible to state it will be in #lubuntu-offtopic? (unless #ubuntu-meeting is actually free).
[20:53] <jose> #ubuntu-meeting is free for you
[20:54] <phillw> Can we book it, in that case. I'll alter our wiki page and alert the mailing list as to the venue :)
[20:54] <jose> phillw: already booked for you, it's yours to manage during that hour
[20:54] <phillw> jose: many thanks :)
[20:54] <jose> no worries
[21:41] <jose> pleia2: just as a heads up, I haven't received any emails concerning the fridge cal update
[21:42] <pleia2> jose: not all that surprised :)
[21:42] <jose> you have a minute atm?
[21:43] <pleia2> on a work call
[21:44] <pleia2> sorry :\
[21:48] <jose> no worries
[21:55] <pleia2> ok, I have a few minutes
[21:55] <pleia2> what's up?
[22:26] <jose> pleia2: oops, missed it. still available?
[22:27] <pleia2> ish, what's up?
[22:29] <jose> wanted to talk about the Fridge comments that are on hold right now
[22:30] <jose> not the spam ones, but the 'I don't like this, that LTS was better, I don't like it the way it is, it's not neat anymore' ones
[22:31] <pleia2> oh yes
[22:31] <pleia2> so I think our metric should be "if the comment is constructive, we keep it, if it's just random complaining, delete"
[22:31] <pleia2> if it's constructive, we can reply
[22:32] <pleia2> and should
[22:32] <jose> I find that good enough
[22:32] <pleia2> and always welcome to ask in here for another pair of eyeballs on ones you're not sure about
[22:32] <jose> great, thanks!
[22:32] <pleia2> the line between constructive and not can be very fine :)
[22:33] <jose> yeah, found that confusing a couple times
[22:33] <pleia2> me too, all the time
[22:38] <jose> ok, just two comments pending
[22:38] <pleia2> \o/
[22:38] <pleia2> I need to get lunch, because I just realized how late it is and hey no wonder I'm hungry
[22:39] <jose> go grab it, enjoy!


[13:27] <arges> hey. Wondering why the current linux-image-generic-lts-quantal shows <IP_ADDRESS>.55 while the git tag shows Ubuntu-lts-3.5.0-49.73 ? Why the difference in build numbers?
[13:30] <rtg> arges, I wonder if that is the meta package tag ?
[13:31] <arges> rtg: so the meta package just has a different build number?
[13:31] <rtg> arges, of course. its actually the upload number  (and is completely arbitrary)
[13:32] <arges> rtg: ok so if I uname -a that particular kernel I should get #73 (which matches with the git tag)
[13:33] <rtg> the tags in the kernel repo should be the same as the source package, e.g., Ubuntu-lts-3.5.0-49.73, Ubuntu-lts-3.5.0-50.74, etc
[13:34] <rtg> arges, the last 2 tags look right to me.
[13:34] <arges> $ rmadison linux-lts-quantal | grep updates
[13:34] <arges>  linux-lts-quantal | 3.5.0-49.73~precise1 | precise-updates  | source
[13:34] <arges> rtg: yea I think I was just looking at the wrong source package.
[13:35] <rtg> arges, the meta package is gonna be different (except for the ABI number)
[13:36] <arges> cool starting to make more sense now. thanks for clearing that up : )
[13:36] <rtg> arges, we use the upload number to distinguish interim versions within an ABI series.
[13:59] <apw> rtg, so ... why have you flippied the top of ubuntu-utopic from UNRELEASED to utopic, as it isn't done or uploaded that seems counter intuitive
[14:03] <rtg> apw, yup, so my local builds use the right chroot
[14:03] <rtg> we still have to run insertchanges before its a complete changelog
[14:03] <apw> hmmm, perhaps shove a 3.14.0-0.0 in then ?
[14:04] <apw> underneath
[14:04] <rtg> apw, is it breaking your PPA builds ?
[14:04] <apw> no it is breaking me :)  well actually it is mostly triggering confusing versioning
[14:04] <apw> as it is "released" i am appending post release versioning not ~ stuff
[14:05] <apw> rtg, now i am confused again, as you seem to have flipped it back to 3.14 and unreleased, or have i lost control of my trees
[14:05] <rtg> apw, well, go ahead and fix it as you like as long as the first changelog entry that is not 'UNRELEASED' says utopic.
[14:06] <apw> oh no, that was me being a spaz
[14:06] <apw> ack
[14:53] <Yaann> Hi !
[14:55] <Yaann> I'm looking for a way to generate a shutdown initramfs on ubuntu, does anybody know how to do that ? It needs to disconnect properly the nbd root device.
[15:16] <apw> Yaann, hmmm, not sure if anyone here would know, you might try #ubuntu-server, they might
[15:18] <Yaann> apw: Ok, thanks !
[15:24]  * ogra_ wonders why an initramfs would be involved in any shutdown bits
[15:25] <apw> oddly this is not the first question we have had on this, i think the initramfs bits are involved as you
[15:25] <apw> have to exclude yourself when starting in the initramfs, to prevent yourself being killed on the way down
[15:26] <apw> Yaann, did you mean startup or shutdown here
[15:26] <xnox> Yaann: as far as I know, shutdown initramfs is a dracut/systemd features which is not yet used in neither debian nor ubuntu.
[15:27] <xnox> Yaann: in ubuntu we only have startup initramfs, which can be updated with $ update-initramfs -u
[15:27] <xnox> (and dropping in appropriate hooks/scripts in either /etc or /usr -> see initramfs-tools manpages)
[15:27] <apw> xnox, as in we go back to the original initramfs root ?
[15:27] <apw> s/we/they
[15:28] <xnox> apw: correct. On fedora: the originial initramfs is left in-tact, at shutdown one goes back into it and unmounts root. That way all network filesystems/mdadm/fakeraid etc. are never started from the mounted rootfs.
[15:28] <ogra_> like android ?
[15:28] <ogra_> where your initrd becomes the top part of / ?
[15:29] <xnox> apw: so no processes / daemons are allowed to "takeover" daemons started from the initramfs.
[15:30] <apw> so you have to rebuild that on any package install which is included, ugg
[15:30] <xnox> ogra_: yes and no. android shutdown is very simple - sync, killall, umount. -> it really does not care.
[15:30] <ogra_> yeah, but the boot-up sounds similar
[15:30] <apw> that is how all of them work on startup though
[15:30] <ogra_> (which is pretty awful if you want to have a generic OS instead of one thats bound to a specific device)
[15:30] <xnox> yeah, startup is the same across all....
[15:30] <apw> where you mount /root in / (the initramfs one) and then get things ready and move into /root
[15:31] <ogra_> apw, no, on android your initrd *becomes* your root
[15:31] <ogra_> there is never any pivoting
[15:31] <apw> so stays your root
[15:31] <ogra_> right
[15:31] <apw> they do know how to hurt my head
[15:31]  * apw does wonder how any root which needs a daemon runnign is meant to work
[15:32] <ogra_> this is perfect if your OS is actually built for a specific device ... we will never be able to cope with their boot speed for example
[15:32] <ogra_> but if you want a generic desktop OS thats just awful ...
[15:32] <xnox> there is no "generic desktop os" =)))))))))))
[15:32] <ogra_> well, :) ubuntu :)
[15:33] <ogra_> something that works with variung hardware
[15:33] <ogra_> *varying
[15:33] <xnox> just a lot of desktop OSs highly optimised for a wide range of x86 machines with common configurations/firmware expectations =))))))
[15:33] <ogra_> yeah, that :)
[15:39] <Yaann> xnox: Yep I already have a custum startup initramfs but I when to properly disconnect my root device before shuting down and the shutdown binary will not be available anymore after disconnecting the block device
[15:39] <ogra_> Yaann, talk to the guys in #ltsp ... they do that properly
[15:40] <ogra_> (nbd is the default in ubuntus ltsp implementation)
[15:40] <xnox> Yaann: look at "/etc/init.d/sendsigs" if you drop a pidfile into /run/sendsigs.omit your process will not be killed on shutdown.
[15:40] <ogra_> i guess you only remount ro and leave the rest to the nbd-client
[15:40] <xnox> Yaann: and your daemon should not hold any files open.
[15:41] <xnox> Yaann: the fact that the binary is "no longer available" is not actually a problem.
[15:41] <ogra_> (stgraber definitely knows the mechanics)
[15:41] <Yaann> xnox: I already added the right PID in /run/sendsigs.omit.d/nbd-client, the kernel doesn't panic anymore but the server never receives a proper disconnect
[15:42] <Yaann> ogra_: I'm gonna try on #ltsp :)
[15:43] <ogra_> ask alkisg there
[15:43] <ogra_> he also knows a lot about the nbd setup they use
[16:11] <rtg> apw, # first bad commit: [177cf92de4aa97ec1435987e91696ed8b5023130] drm/crtc-helpers: fix dpms on logic
[16:11] <rtg> I reverted that on top of utopic master-next and now everything resumes just fine
[16:16] <arges> apw: do you need to add my SOB line when I ACK patches?
[16:16] <arges> err Do I rather.
[16:17] <apw> arges, people will convert an ACK to Acked-by: though i tend to include the Acked-by in mine
[16:18] <apw> rtg, that is worrying as the code is clearly spack before that fix
[16:18] <arges> apw: ok cool
[16:25] <apw> arges, oh an normally i add [ACK] or similar to teh subject to make it clear.
[16:28] <apw> see my last couple :)
[17:32] <clopez> Out of curiosity... why Ubuntu 14.04 comes with kernel 3.13 ?? That kernel version is not LTS (is already EOL, see https://www.kernel.org/). Wouldn't have made more sense to ship 3.12 instead?
[17:35] <apw> clopez, that is only not a gregkh LTS support kernel, the ubuntu kernel team is supporting the 3.13 kernel long term
[17:36] <clopez> Not only gregkh supports LTS kernels: https://www.kernel.org/category/releases.html For example debian kernel maintainer Ben Hutchings  supports the 3.2 LTS version
[17:37] <clopez> if you are going to do the effort of maintaining the 3.13 line on your own, I wonder why you don't do it upstream ?
[17:37] <bjf> clopez, yes, and we use ben's 3.2 stable patches for precise
[17:39] <bjf> clopez, we do "do it upstream"
[17:39] <bjf> clopez, you will see our announcements regularly on lkml
[17:40] <clopez> then is that kernel page outdated?
[17:40] <apw> it only includes ones gregkh officially recognises
[17:40] <mdeslaur> http://lkml.iu.edu/hypermail/linux/kernel/1404.2/05016.html
[17:40] <bjf> clopez, sort of. those maintainers are "blessed" by gregkh
[17:41] <antarus> politics, yay!
[17:42] <hallyn> stgraber: hm, trying to think... can it happen that there are cgroups in /proc/cgroups which do *not* show up in /proc/self/cgroup?
[17:42] <hallyn> apw: ^ happen to know?
[17:42] <hallyn>  i think not, but i'm not absolutely certain
[17:43] <stgraber> hallyn: should be easy enough to check
[17:43] <apw> i do not know to be hones
[17:43] <stgraber> hallyn: /proc/1/cgroup lists all of them so I don't think it's possible
[17:44] <stgraber> hallyn: pid 1 even lists the systemd one which was clearly setup long after pid 1 started
[17:44] <clopez> I guess gregkh only trusts kernel developers with a track of important contributions
[17:44] <bjf> clopez, you just trolling here or what?
[17:45] <clopez> No
[17:45] <apw> clopez, you could have picked that phrase from his emails
[17:45] <hallyn> stgraber: my concern is with the unified hierarchy crap...
[17:45] <clopez> is there any other reason why he won't allow you to maintain the 3.13 LTS "officially" ?
[17:45] <apw> you'd have to ask him his reasons not us
[17:46] <apw> nor does it make any difference, we do the work, people other than us consume it, we are happy
[17:46] <bjf> clopez, what apw said ^
[17:48] <stgraber> hallyn: yeah, not sure how things would look like with the unified hierarchy
[17:48] <clopez> I understand that, but it seems a bit odd that you don't know why he won't allow you to maintain the branch on kernel.org
[17:49] <hallyn> stgraber: just trying to decide whether i should parse both or not.  but i won't...
[17:50] <apw> clopez, he has said basically what you said, that our maintainers have no track record.  that dispite maintaing various stable trees for extended periods
[17:51] <apw> clopez, but also it makes no difference to us, people consume the trees we produce, which is the aim
[17:51] <ogasawara> http://www.spinics.net/lists/stable/msg32034.html
[17:52] <clopez> yes, I found it: this http://article.gmane.org/gmane.linux.debian.devel.kernel/79170
[17:53] <bjf> clopez, and it really doesn't matter what greg says about it being "official" or not. we have to maintain the kernels we ship and that's what we do. (and i think we do it quite well)
[17:53] <clopez> I see
[17:53] <clopez> thanks for the explanation :)
[17:55] <bjf> clopez, for every LTS we reach out to greg and ask what he's thinking of picking for his LTS and he doesn't say until after we have picked ours and then he picks something else
[17:59] <clopez> I'm checking the amount of commits from canonical: 372 on 2013, not bad.
[18:02] <clopez> So the initial reason (few contributions) seems that not longer holds... I wonder if there is something else :\
[18:27] <clopez> Maybe is because the specific canonical developer requesting to maintain the LTS branch has few contributions?
[18:37] <clopez> yeah, the link posted by ogasawara explains that... maybe you should consider putting a developer with a big enough track of contributions as the head of the stable branches in order to get greg blessing
[18:37] <clopez> some suggestions: http://sprunge.us/jfII
[21:37] <apw> clopez, or maybe we should select the person we think most qualified to get the job done
[21:44] <infinity> apw: I'm too busy.


[00:02] <mkanat> I wish I had a meliae for Perl. :-|
[00:06] <mgz> I wish there was one and only one python memory tool instead of the five or so currently used
[00:06] <mkanat> Well, at least they are reasonable and sane.
[00:07] <lifeless> mgz: there is only one.... worth knowing
[00:07] <lifeless> mgz: I've done subunit and testtools releases.
[00:07] <lifeless> mgz: is that thread fully pulled on now ?
[00:08] <mgz> I believe so. Got some updates for bzr, but that wants to lag a bit anyway.
[00:10] <mgz> bug 582113 and some other misc testtools regressions that I've still not got round to filing, then maybe followup for Parth and Alexander who got stuck on writing unicode tests prviously
[00:10] <mgz> ^fix that by using testtools bits rather than unittest bits
[00:11] <lifeless> lets nuke the use of WritelnDecorator too
[00:11] <mgz> right. it's a fantasically pointless class.
[00:11] <lifeless> its surprising for new players
[00:11] <mgz> anyway, we want testtools runner and texttestresult
[00:11] <mgz> which avoids the issues with 2.7
[06:25] <lifeless> any reviewers around ?
[06:48] <mneptok> The plot was thin, and the actors seemed both disinterested and wooden. A script rewrite is in order.
[06:48] <lifeless> well roughly
[06:53] <lifeless> turns out that using bzrlib.lsprof.profile in a threaded app is a little .. risky
[07:38] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/lsprof_lockout/+merge/29165 is the result
[07:54] <mgz> risky as well as being pointless as per bug 579185?
[07:56] <lifeless> shrug
[07:56] <lifeless> that is fixable - I thought GaryvdM had a fix pending in fact
[07:56] <lifeless> mgz: but since you are here, you can review my patches ;)
[07:56] <mgz> didn't look easy to do cleanly when we looked at it, but part of that was just the display of the results
[07:58] <mgz> the locking you've added looks sane to me, but I don't understand the actual problem
[07:58] <lifeless> minimally showing them as separate top level entry points would be better than nothing
[07:58] <lifeless> we call threading.setprofile
[07:58] <lifeless> thats a 'change a global
[07:58] <lifeless> so when 579185 is fixed
[07:58] <lifeless> say you have a threaded webapp - I dunno, a wsgi server, or launchpad, or whatever.
[07:59] <lifeless> if in two threads at once you do 'profile(sublayer, args)'
[07:59] <lifeless> the second entrant to profiler.start()
[07:59] <lifeless> will override threading.setprofile
[07:59] <lifeless> new threads started by *either* request
[07:59] <lifeless> will get collected to the second entrant.
[08:00] <lifeless> also new threads started after either exit will not get collected at all because we reset the profile function for new threads to None
[08:02] <mgz> ah, right, I get it, thanks.
[08:05] <mgz> seems like threading._profile_hook should really be thread-local
[08:05] <lifeless> so new threads would use a trampoline to pass it on each time as well
[08:05] <lifeless> and you'd get a graph of threads with it set appropriately? Yes.
[08:06] <lifeless> that would be nice.
[08:06] <mgz> yup. your fix looks good, I'll just test it here.
[08:06] <lifeless> thanks
[08:07] <lifeless> have I mentioned I hate distutils ?
[08:07] <mgz> who doesn't?
[08:07] <lifeless> tar tzf ../testtools-0.9.4.tar.gz | grep compat
[08:07] <lifeless> I hate setuptools/distribute more
[08:07] <mgz> likewise.
[08:08] <lifeless> |o/
[08:08] <mgz> distutils is just messy and barely documented. setuputils is actively evil.
[08:08] <mgz> *setuptools
[08:09] <lifeless> god, why isn't it finding it
[08:10] <mgz> hmm, interesting
[08:10] <mgz>     return _win32_fixdrive(mkdtemp(*args, **kwargs).replace('\\', '/'))
[08:10] <mgz> RuntimeError: maximum recursion depth exceeded
[08:10] <mgz> wonder what the *top* of that stack was
[08:11] <lifeless> \o/
[08:11] <lifeless> I'm fairly sure thats not my patch :>
[08:11] <lifeless> IMBW
[08:11] <mgz> I'll try dev and see if it's a recent thing there
[08:12] <mgz> yup, it's on dev... gra.
[08:13] <lifeless> ><
[08:13] <lifeless> have you perhaps looked into how distutils finds files before ?
[08:13] <mgz> ooh, I just upgraded testtools yesterday
[08:14] <lifeless> mgz: teehee
[08:14] <mgz> wonder if it's related to that rather than a bzrlib change... hope not.
[08:15] <lifeless> ok, MANIFEST existing messes setup.py up.
[08:15] <lifeless> ><
[08:16] <mgz> nope, regression from r5326 - sorry vila
[08:16] <lifeless>  /o\
[08:17] <mgz> the problem with tests... need them to be static to be reliable, but then they become full of cruft and bad examples
[08:17] <lifeless> well
[08:18] <lifeless> I don't really care about old cruft badness; I care about performance and maintainability.
[08:18] <lifeless> Folk that use tests as examples of production code are being optimistic IME.
[08:18] <mgz> the problem with that is expecting new contributors to write tests when bzr has changed style substantively several times across its lifetime
[08:19] <lifeless> and new tests have fluent folk reviewing, so at most a little rework happens when someone copies.
[08:19] <lifeless> which the reviewer can usually trivially do.
[08:19] <mgz> I'm still not sure how to write a bunch of things I'd like to be testing... and I quite like tests
[08:19] <lifeless> mgz: yeah, there is some overhead there, but new contributor % vs total-test-base-size  :>
[08:19] <lifeless> mgz: just ask !
[08:20] <mgz> okay, poping the stack, need to check your lsprof ones still
[08:21] <mgz> passes with 5326 merged out.
[08:25] <lifeless> today is yak shaving day.
[08:25] <lifeless>  /o\
[08:27] <lifeless> james_w: if you're up, have you looked into bug 588060 any further? I'm hitting it now with a fairly simple rename (util.py -> compat.py in testtools)
[08:33] <mgz> okay, fixing osutils is easy, though I'm a little confused as to what vila was trying to change there
[08:35] <mgz> ah, I see, ugly lazy import interaction
[08:36] <mgz> and mostly pointless, I don't think you can even do `bzr rocks` without importing tempfile
[08:36] <lifeless> lazy import is a bit overused as a tool
[08:36] <mgz> osutils should just... not shadow things in the os module, it's bad, wrong, and confusing
[08:37] <lifeless> no real opinion either way here
[08:37] <lifeless> OT1H the function names are well defined and we do supply less broken versions
[08:37] <lifeless> OTOH they are shadowing the real ones.
[08:40] <mgz> well, it's better than monkey patching ntpath at least, but what, off the top of your head, is the difference between os.rename and osutils.rename for instance?
[08:41] <lifeless> handles open files
[08:41] <lifeless> that one is more questionable
[08:44] <mgz> ...think I'll keep this a one-line fix, rather than trying to make the code sane
[08:44] <lifeless> :>
[08:48] <lifeless> that reminds me
[08:48] <lifeless> have you seen withhacks? I think you'll appreciate the evilness
[08:48] <lifeless> mgz: ^
[08:50] <mgz> ah, no, but... I've seen the sort of things ruby people do
[08:50] <lifeless> http://pypi.python.org/pypi/withhacks
[08:50] <mgz> using with to create tree structures like html DOMs and anything else they want an indent for
[09:01] <mgz> okay, that really is quite horrid. the javascript-style with is bad enough, but the xargs class is just... insane
[09:01] <mgz> why would anyone ever think doing that is a good idea...
[09:03] <mgz> one thing I would like the with statement for (and I'm not all that keen on it, it's a whoops-we-screwed-up-scoping-originally type modification like the javascript 'let')
[09:03] <mgz> is lazy imports.
[09:03] <mgz> could do lazy imports with with, and then not have any of that string parsing mess
[09:11] <lifeless> mgz: there was a thread on that on python-ideas just recently
[09:12] <mgz> I stopped reading python-ideas shortly after it was created
[09:12] <lifeless> :)
[09:12] <mgz> seemed like python-shutup-and-get-off-dev, has it improved?
[09:13] <mgz> what was the thread subject?
[09:14] <lifeless> looking
[09:16] <lifeless> explicitation lines
[09:19] <mgz> reading.
[09:25] <mgz> seems very alien for python (and not just because of the french word)...
[09:26] <mgz> using to just being able to read forwards, rather than in every direction at once as per functional languages
[09:26] <mgz> *used
[09:27] <fax8> hi guys, I've checked out from a .htaccess password protected directory repository. Now each time I bzr up it asks me the username/password twice.. is this a bug?
[09:27] <mgz> yes.
[09:29] <fax8> ok, I'm on bzr 2.1.2.. new versions fixes that?
[09:31] <lifeless> I've not heard of the bug before
[09:31] <mgz> trying to find bug, but I might have hallucinated it.
[09:32] <lifeless> I'd check you have your authentication.conf setup correctly.
[09:33] <lifeless> mgz: set a message on your installer merge... and land it:)
[09:33] <lifeless> mgz: you can use lp-propose -m to set the message when you create it
[09:34] <mgz> fax8: other thing you can try is -Dhttp and look at the log
[09:34] <mgz> have I got perms to land on the installer project lifeless?
[09:35] <lifeless> mgz: you put a merge up for bzr
[09:35] <lifeless> mgz: you would for the installers if you joined ~bzr no ~bzr-core, I think.
[09:35] <mgz> oh, that bit, doh.
[09:36] <mgz> ...maybe I should join ~bzr, given yesterday
[09:37] <mgz> poking bzr lead to changes across three different projects
[09:40] <fax8> here is the log http://pastebin.com/wfPS3VmQ
[09:41] <fax8> I'm still not too bzr savy to understand what's happening there
[09:41] <vila> mgz: Was your fix a one-line change to use tempfile.mkdtemp instead of mkdtemp ?
[09:41]  * vila passing around *very* briefly
[09:42] <mgz> it was: https://code.launchpad.net/~gz/bzr/win32_mkdtemp_infinite_recursion/+merge/29166
[09:42] <mgz> fax8: so, the thing that jumps out there is the 401-401-401-200 sequence
[09:43] <mgz> *401-404-401-200
[09:43] <fax8> ok, what should I do?
[09:43] <vila> SHUDDER, introduced after a review tweak :-( And as such not tested on babune :-( :-(
[09:43] <lifeless> vila: regressions hide around every change
[09:44] <vila> which is daunting as this was part of an effort to make the test suite *pass* on windows :-(
[09:44] <vila> lifeless: yeah, I don't run enough tests...
[09:45] <mgz> to avoid it for the moment you can probably put the password in authentication.conf as lifeless suggested earlier
[09:45] <mgz> I'll have a go at repoing here later.
[09:45]  * vila goes back tightening his hanging rope
[09:45] <mgz> fax8: `bzr help authentication`
[09:47] <mgz> what was I doing... oh yeah, commit message
[09:47] <vila> mgz: was it at least caught by a fialing test ?
[09:47] <mgz> it made the whole test suite blow up.
[09:47]  * vila put the rope aside
[09:48] <vila> mgz: sorry for that and thanks for the fish^H^Hx
[09:55] <mgz> ...launchpad doesn't seem to have a way of unproposing yourself of a team
[10:04] <mneptok> mgz: did you mistakenly try to join worldcup-fr?
[10:04]  * mneptok woggles an eyebrow at all the French present
[10:04] <mgz> heh
[10:06] <GaryvdM> Hi all
[10:07] <mgz> morning gary.
[10:09] <GaryvdM> mgz: Any luck with removing the win32 installer stuff out of setup.py?
[10:10] <mgz> ha, I'm too smart to launch on that one ;)
[10:11] <GaryvdM> mgz: I think I'm going to have to add to if for launchpadlib, and it feels wrong putting it in to bzr.dev/setup.py....
[10:11] <GaryvdM> s/if/it
[10:12] <lifeless> GaryvdM: to shave the yak, or yak the shave?
[10:13] <mgz> yeah, half the file is qbzr/tbzr/py2exe already... needs doing, just a little painful
[10:13] <lifeless> the question to ask is
[10:13] <lifeless> 'if someone is installing directly from source, do they need this'
[10:14] <lifeless> if the answer is yes, do it in setup.py (or something imported into setup.py)
[10:15] <GaryvdM> I feel the answer is no.
[10:15] <lifeless> then do it outside of setup.py
[10:16] <lifeless> whatever is in setup.py is irrelevant at this point :)
[10:31] <mgz> on the fax8 http auth problem from earlier, does this (typing guest/password as prompted):
[10:31] <mgz> bzr branch http://float.endofinternet.org/bazaar/testauth
[10:31] <mgz> also prompt twice for everyone else?
[10:32] <mgz> there are a lot variables with bzr and http
[10:37] <lifeless> twice
[10:37] <lifeless> love the domain
[10:38] <mgz> thanks, I'll poke around later and see if I can find the problem.
[11:45] <lifeless> mtaylor: https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/29167
[11:45] <lifeless> we'll want to port the basic support for this to bzrtools too
[11:50] <lifeless_> 20:44 < lifeless> mtaylor: https://code.edge.launchpad.net/~lifeless/bzr-builddeb/trunk/+merge/29167
[11:50] <lifeless_> 20:44 < lifeless> we'll want to port the basic support for this to bzrtools too
[12:00] <lifeless> now where was I
[12:00] <lifeless> thats right, merge-upstreaming
[12:06] <iocor> is it possible to get the changes to file contents from a TransformPreview object?
[12:08] <lifeless> should be possible
[12:08] <lifeless> I think it offers the tree interface
[12:08] <lifeless> and thus tree.get_file(file_id) -> file contents
[12:10] <iocor> .get_preview_tree.get_file(file_id).read()?
[12:10] <lifeless> yea
[12:11] <iocor> thanks
[12:32] <iocor> lifeless: how would I do the same thing post-commit? (I'm using a builder to do the commit)
[12:32] <lifeless> I need a little more context to help
[12:34] <iocor> lifeless: so I'm looking to get all the file contents of all the files in my branch after a commit
[12:36] <lifeless> are you using the API ?
[12:37] <lifeless> or command line
[12:40] <lifeless> ....and packages for testtools and subunit uploaded to debian.
[12:40] <iocor> bzrlib
[12:40] <lifeless> so, you have two options
[12:40] <lifeless> a post comit hook
[12:40] <lifeless> or after calling commit, you can obtain the revision tree from the repository for the committed revision
[12:41] <lifeless> revid = tree.commit(..)
[12:41] <lifeless> revtree = tree.branch.repository.revision_tree(revid)
[12:41] <lifeless> revtree.lock_read()
[12:41] <lifeless> revtree.get_file(fileid)
[12:41] <lifeless> etc
[12:42] <GaryvdM> mgz: I've managed to move the py2exe code to it's own file in bzr-windows-installers. It feels a bit hackey. Maybe you could take a look, tell me what you think. http://bazaar.launchpad.net/~garyvdm/bzr-windows-installers/maybe/annotate/head:/build_bzr_py2exe.py
[12:44] <GaryvdM> Let me see if I can build an installer with it...
[13:11] <iocor> ok, I have the following code: http://dpaste.com/214454/ and the following trace: http://dpaste.com/214456/. For some reason post-commit the file hasn't changed even though the TransformPreview contains a change to the repo. Why is this?
[14:06] <fbond> nit
[14:07] <fbond> (Sorry, empathy window stole my keyboard focus.)
[18:34] <PrinceAMD> hi guys, does bzr make 2 copies of images when a client do a fetch/checkout, i'm using svn right now, and if my image folder has 100 images inside .svn it has the same so it uses 2x the space
[18:58] <jam> PrinceAMD: no
[18:58] <jam> it will have a compressed copy in the local repository, but it doesn't need the pristine copy that svn uses
[19:01] <PrinceAMD> ok jam , also image does not compress that well, so i might end up with same result
[19:05] <jam> PrinceAMD: there will be a fair amount of 'it depends' involved.
[19:05] <jam> such as, you could do a lightweight checkout
[19:05] <jam> or if you have a shared repo, there is only 1 copy across all your branches, etc.
[19:09] <PrinceAMD> hm.. lightweight checkout looks nice, i'll test it
[19:19] <GaryvdM> Hi jam.
[23:10] <lifeless> mgz: small meta: when commenting on bugs, be lovely if you can triage at the same time.
[23:10] <lifeless> you don't have too, and perhaps you usually do - if either apply just ignore me :)
[23:20] <mgz> GaryvdM: the py2exe move looks pretty good to me, surely it's not that easy though :)
[23:21] <mgz> lifeless: I don't have perms. well, I can confirm, and assign to myself, but I can't set prio or any of the rest
[23:21] <lifeless> garh
[23:21] <lifeless> ok
[23:21] <lifeless> so I can add you to bzr; want to be in there ? cost: lots of mail. pros: no more process friction.
[23:21] <mgz> I was looking at that this morning
[23:22] <mgz> the main is gmail won't let you filter on X-Launchpad-Message-Rationale
[23:22] <mgz> +pain
[23:22] <lifeless> oh
[23:22] <mgz> so, it'd probably nuke my nice orderly mailinglist account
[23:22] <lifeless> I filter on the rationale paragraph at the bottom of the mail
[23:23] <lifeless> 'because you are a member of' :P
[23:23] <mgz> ah, the "You received this bug notification because..."
[23:23] <lifeless> you can also do a direct subscription in LP
[23:23] <mgz> that sounds like it'd work
[23:23] <lifeless> and then turn off things
[23:23] <lifeless> e.g. don't care about mac installers? subscribe to that with a no-mail subscription
[23:25] <lifeless> mgz: your mkdtemp patch needs landing :)
[23:26] <mgz> hm, this might be a bug, it seems "because you are a member of..."
[23:26] <mgz> don't want to archive bugs I actually filed
[23:27] <lifeless> so this is something deryck is very interested in
[23:27] <lifeless> they are overhauling the bugs subscription stuff at the moment.
[23:32] <lifeless> I can has review? https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/29139
[23:33] <mgz> me no know looms 'm 'fraid
[23:33] <mgz> ah, you're just deleting something. and... is adding the matchers there serving any purpose?
[23:38] <lifeless> oh! oversight
[23:38] <lifeless> I was going to make the same change I made a few revisions earlier to per_interbranch
[23:38] <lifeless> where the test is duplicated
[23:38] <lifeless> I changed my mind.
[23:42] <mgz> ...either I'm going mad, or there's no way to add the "inbox" label back to a thread with the basic gmail web interface
[23:43] <lifeless_> o/~ I hate huawei E160's o/~
[23:43] <lifeless_> 08:38 < lifeless> oh! oversight
[23:43] <lifeless_> 08:38 < lifeless> I was going to make the same change I made a few revisions earlier to per_interbranch
[23:43] <lifeless_> 08:38 < lifeless> where the test is duplicated
[23:43] <lifeless_> 08:38 < lifeless> I changed my mind.
[23:44] <mgz> Isee.
[23:45] <lifeless_> (changed and deleted instead)
[23:58] <mgz> does per_interbranch cover what per_branch is testing anyway?


[00:03] <ceekay> I know this isn't strcitly development-related, but it's in the topic and i get no response in #ubuntu so I'll ask here http://www.ubuntu.com/usn/usn-612-1 says that for 7.04 to get libssl0.9.8 version 0.9.8c-4ubuntu0.3 ... however packages.ubuntu.com and my nearest mirror lists 0.9.8c-4ubuntu0.2 as being the latest available... is ...ubuntu0.3 still in the works?
[00:07] <crimsun> ceekay: no, it's already available.
[00:08] <ceekay> just a mirror sync thing or something?
[00:08] <crimsun> ceekay: yes
[00:08] <crimsun> libssl0.9.8 | 0.9.8c-4ubuntu0.3 | feisty-security | amd64, i386, powerpc
[00:08] <crimsun> libssl0.9.8 | 0.9.8c-4ubuntu0.3 | feisty-updates | amd64, i386, powerpc
[00:08] <crimsun> so, you can either pull from archive.ubuntu.com or from security.ubuntu.com
[00:09] <crimsun> (sorry, I reversed that, respectively)
[00:10] <crimsun> as long as you have "Important security updates" ticked/checked in the Updates tab of System> Administration> Software Sources, you should be set.
[00:10] <ceekay> cool thx... just wanted to verify that it was actually available
[00:10] <ceekay> my repositories are set to a local mirror at work that probably just syncs nightly
[02:42] <Hobbsee> pitti: i'm no -sru'er....
[03:33] <lamont`> hrm... how do I tell network mangler to keep doing it's thing even when I'm not logged in, I wonder?
[03:51] <johanbr> lamont: for versions older than 0.7 I think the answer is "you don't".
[03:52] <ScottK> lamont: By not logging out AFAIK.
[03:52] <lamont> I see.
[03:52] <lamont> does 0.7 play well with hardy, I wonder?
[03:53] <ScottK> Dunno
[03:54] <johanbr> Not without tweaking: http://permalink.gmane.org/gmane.linux.network.networkmanager.devel/9654
[04:00] <andrew_sayers> Should I be filing wishlist bugs when I stumble over things where IPv6 is less well supported than v4?
[04:01] <andrew_sayers> (e.g. netcat6 not in main, libsocket6-perl not in main)
[07:31] <pitti> Hobbsee: ah, ok; seems I mixed that up
[07:31] <pitti> Good morning
[07:44] <YokoZar> pitti: uh oh
[08:02] <geser> good morning pitti
[08:16] <kirkland> pitti: seems my build had a problem, http://launchpadlibrarian.net/14558108/buildlog_ubuntu-intrepid-i386.ecryptfs-utils_45-1_CHROOTWAIT.txt.gz
[08:24] <geser> kirkland: looks like the buildds are broken right now :(
[08:33] <pitti> kirkland: that hit me as well yesterday; NFC, unfortunately
[08:40] <TheMuso> pitti: Ok ACKEd, will process the rest when I'm down stairs.
[08:40] <pitti> TheMuso: thanks
[08:48] <Mithrandir> pitti: why does pg_config --libs output lots of stuff like -lz?  They should be pulled in by having libpgport linked to it, should they not?
[08:50] <pitti> Mithrandir: hm, good point; can you please file a bug about it? (in Debian preferably)
[08:50] <pitti> Mithrandir: (sorry, EBUSY ATM)
[08:50] <Mithrandir> pitti: np, and will do
[08:59] <kirkland> pitti: geser: okay, thanks.  i thought this might be pervasive, but mentioned it just in case
[10:17] <Keybuk> stupid question of the day:
[10:17] <Keybuk> I always what terminals to start at 60px across
[10:17] <Keybuk> how?
[10:17] <RAOF> s/what/want/?
[10:18] <StevenK> And 60 pixels?
[10:18] <Keybuk> RAOF: yes
[10:19] <andrew_sayers> Not 60 characters?
[10:19] <RAOF> The Stupidly Configurable window managers will do this; Compiz is one, and I think you'll find the 'window rules' plugin is where you can specify this behaviour.
[10:19] <Keybuk> RAOF: I can't find a way
[10:20] <andrew_sayers> Most terminals take a --geometry attribute - the man page for the terminal will tell you more.
[10:21] <pitti> Keybuk: session management is *supposed* to do that, and it worked just fine until gutsy; too bad that hardy broke it (might be a gnome-terminal bug, though, it works for other apps)
[10:21] <RAOF> Keybuk: Advanced ... -> Window Rules -> Size rules -> New should allow you to specify that you want your gnome-terminals to be 60px wide.
[10:21] <Nafallo> Keybuk: devilspie
[10:23] <pitti> RAOF: I don't seem to be able to find an 'Advanced' thing in g-t; where is it?
[10:23] <Keybuk> RAOF: not 60px wide, as in not use the left-most 60px of the screen
[10:23] <Keybuk> Nafallo: doesn't seem to have a rule for "first terminal on an otherwise empty workspace" ?
[10:24] <Nafallo> Keybuk: ah. only the first one... not every.
[10:26] <andrew_sayers> Keybuk: I'm a but rusty with my geometry, but I think you want something like --geometry 60x?+0+0
[10:26] <andrew_sayers> (Where "?" is the height of your screen)
[10:26] <Keybuk> yeah you can do something like that
[10:26] <Keybuk> but that's annoying
[10:26] <pitti> no, rather +60+0
[10:26] <pitti> + is the offset, AxB the size
[10:31]  * Ng wonders why keybuk wants that, although the only hack I can think of right now would force all windows on all workspaces to start at +60 ;/
[10:32] <RAOF> Hm.  You can set the place plugin to manually start terminals at +60+0.
[10:32] <RAOF> But that's going to start _all_ terminals at the same place.
[10:33] <Ng> depending on how you arrange your terminals, you could go for a terminal program which keeps them all in one window and just have that window start at +60 :D
[10:33] <Keybuk> Ng: because with the size of the terminals, I can fit two on the screen
[10:33] <Keybuk> with 60px either side
[10:33] <Keybuk> which looks nice and balanced
[10:34] <Ng> ah
[10:35] <Ng> are you determined to keep 80x24? I rather like having 4 120x35 terms :)
[10:36] <RAOF> You could get compiz's put plugin to bind a key to "move this terminal to +60+0"; that's the best I can think of.
[10:42] <andrew_sayers> Keybuk: you might want to consider using screen, and splitting the screen into regions.
[11:19] <TheMuso> pitti: Ok I think I have got all of the ones that remained.
[11:50] <emgent> heya
[12:52] <Hobbsee> pitti: mp
[13:16] <Hobbsee> pitti: ping-a-ling
[13:18] <jdstrand> kees: what do you think of:
[13:18] <jdstrand> $ sudo ufw limit ssh/tcp
[13:18] <jdstrand> limit is an 'allow' but with rate limiting
[13:18] <jdstrand> (I'm still not here)
[13:19] <jdstrand> s/is an/just like/
[13:34] <lucas> where's the source code behind http://patches.ubuntu.com/?
[13:45] <Amaranth> lucas: Someone else runs that. *shrug*
[13:47] <mvo> lucas: Scott will know
[13:51] <pitti> TheMuso: thanks for the SRU acks; can you please take a look at bug 175536 as well?
[13:51] <TheMuso> pitti: I'm on it.
[13:51] <Hobbsee> pitti: tis borken :(
[13:51] <Hobbsee> pitti: https://launchpad.net/bugs/231236
[13:52] <pitti> TheMuso: thanks
[13:53] <pitti> Hobbsee: oh argh, thanks for pointing out
[13:53] <Hobbsee> pitti: may be worth adding to the doc, or something, not to do that.
[13:53] <pitti> Hobbsee: we can't update evo yet; I guess we need to do a direct -updates upload with a rebuild
[13:54] <Hobbsee> pitti: presumably, yeah.
[13:54] <Keybuk> lucas: http://launchpad.net/merge-o-matic
[13:58] <seb128> Hobbsee: rebuild uploaded to hardy-updates now, thanks for mentionning
[13:58] <Hobbsee> seb128: thanks
[13:59] <seb128> Hobbsee: it's not as easy as migrating all the rdepends, evolution-data-server is still buggy and not ready to migrate to updates
[13:59] <Hobbsee> seb128: which means it all isn't, or you should do as you're doing now, with the rebuild, just in case.
[13:59] <Hobbsee> (unless you have some easy way of seeing if all the deps get satisfied, with it in -updates.
[13:59] <seb128> right, it was an oversight
[14:00] <Hobbsee> yes, same as last time :)
[14:05] <StevenK> I wonder if I can brutalise quilt to add a patch only on one arch
[14:05] <azeem> series.$arch
[14:05] <StevenK> Sweet
[14:05] <azeem> StevenK: glibc does that on Debian at least, AFAIK
[14:05] <azeem> least*
[14:13] <kirkland> cjwatson: I would like to talk to you about the automatically generated/updated repository of ubuntu manpages and such.  Would you like to do this offline/in-the-halls, in a fosscamp session, or next week during UDS?
[15:09] <marmadeoli> Como eu posso ajudar no desenvolvimento de algum pacote ubuntu? (How can I help to develop any ubuntu package?)
[15:53] <mpt> Keybuk, what's the meaning of blue, pink, and white?
[16:05] <Keybuk> mpt: ?
[16:07] <mpt> cody-somerville: reported as bug 231403
[16:07] <mpt> Keybuk, in the UDS schedule
[16:07] <cody-somerville> mpt, thanks.
[16:12] <Riddell> there's a UDS schedule?
[16:26] <tseliot> Riddell: I'm not sure about this but have a look at this link: http://bazaar.launchpad.net/~ubuntu-drivers/uds-intrepid/trunk/files
[16:30] <Riddell> was hoping for something more readable :)
[16:32] <tseliot> Riddell: me too... :-(
[16:34] <munckfish> that's got to be the ultimate techy web UI no? :D
[16:34] <munckfish> all in XML
[16:34] <munckfish> all in source control
[16:35] <tseliot> XML is the global language. It will soon replace the English language too (which is deprecated) ;)
[16:38] <pitti> <answer type="agreement" value="no" />
[16:41] <cody-somerville> Thats not even the latest
[16:52] <tseliot> pitti: hehehe
[17:33] <McRib> I am just curious about the status of Bug #228044.  I submitted it a few days ago and it's listed as being fixed in -proposed, but I can't install it.
[17:34] <crimsun> what do you mean by "can't install it"?  Are the maintainer scripts failing?  Also, you want to migrate this discussion to #ubuntu-motu.
[17:36] <McRib> crimsun: What I mean is that it still depends on firefox-3.0... does not accept firefox-2
[17:36] <crimsun> McRib: dpkg -l mozilla-mplayer|grep ^ii
[17:37] <crimsun> McRib: and please, this belongs in -motu
[17:37] <McRib> crimsun: Alright, I'll take it there... I was referred here first, though.
[19:32] <bud32> Hi, once Ubuntu 8.04 installed, there was some file left with GID 999 throughout the file system. I fixed it with "sudo find / -nogroup -exec chgrp root {} \;"
[20:40] <hwilde> so how compromised are the keys really
[20:40] <hwilde> true randomness is not theoretically achievable by state machines
[20:41] <hwilde> so how can the new algorithm be that much better than the old one?
[20:46] <jdong> hwilde: err, very compromised.
[20:46] <jdong> hwilde: metasploit has a 10MB tarball of id_rsa's that you can use to log into any affected machine.
[20:46] <jdong> reportedly it took 3 hours to generate
[20:46] <Chipzz> hwilde: there's only 32.000 something keys now
[20:47] <jdong> if you ran ssh-keygen for 15 minutes you'd probably end up with a bunch of duplicate private keys :)
[20:47] <hwilde> and the new algorithm is better how
[20:48] <jdong> hwilde: the old one forgot to seed the random number generator.
[20:48] <hwilde> holy shit
[20:48] <jdong> hwilde: rather, it seeded ONLY by the PID of the ssh-keygen generator.
[20:48] <jdong> hwilde: which makes your key one of 32,767 predictable sequences :)
[20:48] <jdong> yeah.
[20:49] <jdong> that was my reaction waking up that morning
[20:49] <hwilde> that can't be true...
[20:49] <hwilde> the internet would not still be up
[20:49] <jdong> hwilde: I wish it weren't.
[20:49]  * hwilde wonders how many rejected login attemps my servers allow
[20:49] <jdong> hwilde: but alas, you can try the metasploit proof of concept with a VM.... it works shockingly well
[20:51] <hwilde> and what exactly does it mean when ssh-vulnkey says COMPROMISED
[20:51] <desrt> hwilde; it means that someone else _definitely_ has a copy of your private key
[20:51] <jdong> hwilde: that means your key is DEFINITELY in http://sugar.metasploit.com/debian_ssh_rsa_2048_x86.tar.bz2
[20:51] <jdong> ;-)
[20:52] <jdong> lol
[20:53]  * Chipzz wonders why this wasn't embargo'd for longer
[20:54] <jdong> Chipzz: not sure that would've been any more helpful.
[20:54] <Chipzz> jdong: well, when the embargo was lifted there only was an openssl update
[20:54] <Chipzz> no openssh update yet
[20:55] <Chipzz> I had to do a lot of manual key regeneration
[20:55] <Chipzz> this left a whole lot of people who didn't know how to regenerate their keys vulnerable for a couple of hours/a day
[20:56] <Chipzz> s/keys vulnerable/vulnerable keys/
[20:56] <jdong> ssh and ssl services were completely disabled on my system the moment I read the advisory, until I could figure out what was necessary
[20:56] <jdong> definitely the first few hours were not well handled in terms of publishing the security update informatively.
[20:56] <Chipzz> jdong: yes, on your system maybe. but there are a lot of less knowledgable people out there
[20:56] <jdong> even the DSA pointed to a dead link
[20:56] <jdong> Chipzz: I'm agreeing with you here...
[20:57] <Chipzz> it should have been as simple as apt-get install openssh-server
[20:57] <Chipzz> which it wasn't at first
[20:57] <Chipzz> also
[20:58] <Chipzz> there wouldn't have been an excuse to have a metasploit "plugin" then
[20:58] <Chipzz> since you could easily check just running apt-get install openssh-server
[21:50] <ipkaf> hi
[23:06] <Mez> cjwatson, ping. Im using ssh-vulnkey, and its showing me some entries that i cant find in files anywhere, but seem suspicious
[23:06] <Mez> any idea how to find out what files they're coming from?
[23:07] <StevenK> strace? :-P
[23:44] <gnomefreak> Mez: it doesnt give you something like /home/gnomefreak/.ssh/id_rsa.pub
[23:45] <Mez> nope. was giving me<EMAIL_ADDRESS>[23:45] <Mez> (replacing domain.i.dont.know
[23:45] <Mez> as the comment
[23:45] <Mez> appears it was my host keys as generated somwhere else
[23:45] <Mez> which I've now re-generated anyways
[23:51] <gnomefreak> Mez: ah


[05:40] <Joanet> Hi all
[05:42] <Joanet> I'm trying to change the login background & logo using Ubuntu-tweak, but no luck. Also, I've copied the files to /usr/shares/backgrounds and repaired the permissions, but still no luck. Can anyone help me? I'm using Edubuntu 12.04 x64
[07:38] <Joanet> I'm trying to change the login background & logo using Ubuntu-tweak, but no luck. Also, I've copied the files to /usr/shares/backgrounds and repaired the permissions, but still no luck. Can anyone help me? I'm using Edubuntu 12.04 x64
[07:39] <Joanet> lotuspsychje: When I use ubuntu-tweak on normal ubuntu, it wrote change on /usr/share/glib-2.0/schemas/50_unity-greeter.gschema.override, but it seems Edubuntu uses other file


[00:25] <tjaalton>  /away
[00:25] <tjaalton> uh
[09:38] <jcristau> tjaalton: thinking about it, we could only do the xhost trick for local sessions (otherwise you're telling the x server to trust some random user). not sure it's worth it...
[09:39] <jcristau> as in, you need to detect those somewhat reliably
[09:40] <tjaalton> jcristau: running 'id -un' isn't enough?
[09:42] <tjaalton> jcristau: that's what fedora does, allows only the session user to connect
[09:48] <jcristau> in xinit it's ok, since that creates a local session anyway
[09:48] <jcristau> but, if you put that in Xsession.d, you have to handle remote sessions, where `id -un` on the client may not have anything to do with uids on the server
[09:49] <tjaalton> hmm, ok
[11:28] <tjaalton> wgrant: I've now installed the packages from my PPA, and xinput list-props $id just gives me a BadRequest
[11:29] <tjaalton> so something is broken in the backport
[11:32] <jcristau> what's the request id?
[11:32] <wgrant> tjaalton: Ergh.
[11:33] <tjaalton> jcristau: Major 146, minor 41
[11:33] <tjaalton> (XInputExtension)
[11:34] <jcristau> hrm
[11:34] <jcristau> #define X_WarpDevicePointer 41
[11:34] <jcristau> that's XI2
[11:34] <wgrant> Those were just renumbered in XI2...
[11:35] <wgrant> But.
[11:35] <wgrant> Hmm.
[11:35] <wgrant> Hmmm.
[11:35] <jcristau> did you update inputproto, then libxi, then xinput?
[11:36] <tjaalton> I should have, but maybe some build-dep was broken so xinput was built against the old packages
[11:36] <tjaalton> will check
[11:36] <jcristau> 41 used to be GetDeviceProperty
[11:36] <wgrant> Sounds like xinput was built before publishing.
[11:36] <tjaalton> yeah
[11:36] <tjaalton> grr
[11:38] <tjaalton> hmm no, it was built against my versions
[11:38] <wgrant> It's a bit odd that it hardlocks my laptop.
[11:38] <jcristau> and libxi was built against the right inputproto?
[11:38] <tjaalton> just listing the props?
[11:39] <wgrant> tjaalton: Correct.
[11:39] <tjaalton> jcristau: yes..
[11:39] <tjaalton> I need to go through them once more..
[11:39] <wgrant> Well, it did last night, but I've not changed anything since and daren't try again right now.
[13:57] <james_w> tseliot: hi, are you around? I have a system with quite an old nvidia card and jockey doesn't suggest that I may want to install a different driver for it. How can I debug this?
[14:00] <tseliot> james_w: what does jockey do, exactly?
[14:01] <james_w> "No proprietary drivers are in use on this system"
[14:01] <james_w> and nothing listed in the UI at all
[14:02] <james_w> it's correct, but I thought it would show the chance to turn nvidia on
[14:02] <jcristau> james_w: if it's an old card, then that may not be an option?
[14:03] <james_w> it used to be nvidia, were some dropped in Intrepid?
[14:03] <tseliot> james_w: can you put the output of "sudo aptitude search nvidia" in pastebin?
[14:03] <tseliot> maybe some modalias packages are not available
[14:03] <james_w> sure
[14:03] <mvo> james_w: how did you upgrade?
[14:04] <james_w> I don't remember now, it was very early
[14:04] <mvo> I wonder if its driver -71 or -96 were we have no xserver 1.5 support ?
[14:04] <mvo> james_w: aha, ok :) I'm looking for testing feedback of the current upgrader for people with nvidia hardware/drivers
[14:05] <james_w> mvo: it's my second machine, so I'll consider reinstalling hardy and upgrading
[14:06] <james_w> http://paste.ubuntu.com/52840/
[14:06] <tseliot> james_w: nvidia-common wasn't installed during the dist-upgrade
[14:07] <mvo> james_w: aha, ok. that system looks like a good test candidate
[14:07] <tseliot> try installing nvidia-common and then launch jockey again
[14:07] <tseliot> NOTE: don't try to install -71 or 96 (they don't work)
[14:09] <mvo> haven't we blacklisted those yet?
[14:09] <tseliot> mvo: no, not yet
[14:09] <mvo> aha, ok
[14:09] <tseliot> I have worked on the gnome-control-center
[14:09] <james_w> nothing
[14:10] <james_w> the same as before
[14:10] <tseliot> james_w: can I see the output of this command? lspci -n | grep 300
[14:11] <james_w> 02:00.0 0300: 10de:0201 (rev a3)
[14:12] <tseliot> james_w: this is weird. Your card is supported: :/usr/share/jockey/modaliases$ grep 0201 *
[14:12] <tseliot> nvidia-71:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-71
[14:12] <tseliot> nvidia-96:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-96
[14:12] <tseliot> did nvidia-common install other packages?
[14:13] <james_w> nvidia-{71,96,173,177}-modaliases
[14:13] <tseliot> e.g. nvidia-96-modaliases, nvidia-71-modaliases
[14:14] <tseliot> ok, try killing jockey-backend
[14:14] <tseliot> and start jockey again
[14:14] <tseliot> ps aux should show jockey-backend
[14:15] <james_w> aha!
[14:15] <james_w> thanks
[14:15] <james_w> but you say don't install 71 or 96?
[14:15] <tseliot> ok, now don't install those drivers
[14:15] <tseliot> they are not compatible with the new Xorg ABI
[14:15] <james_w> are they likely to be fixed by the release?
[14:16] <tseliot> therefore I didn't bother patching them to make them compatible with kernel 2.6.27
[14:16] <tseliot> I have no idea...
[14:16] <james_w> ok, thanks for your help
[14:17] <tseliot> you're welcom
[14:17] <tseliot> e
[17:33] <bryce> whoa, jim gettys reported bug 276782 to launchpda
[17:39] <Ng> heh, shouldn't he be fixing it too? ;)
[17:52] <bryce> ;-)
[18:16] <james_w> hey bryce.
[18:17] <james_w> would you have a moment to look at bug 276680?
[18:17] <james_w> I'm not really sure which component is at fault here
[18:17] <bryce> heya james_w, one sec, looking at a bug for heno atm
[18:17] <james_w> sure, no rush
[18:20] <jcristau> james_w: if he starts X with vga disconnected, the server doesn't allocate a framebuffer big enough for the vga monitor's native resolution
[18:21] <james_w> jcristau: the "Virtual" setting?
[18:21] <jcristau> yeah
[18:22] <jcristau> his first xrandr output says 'maximum 1024 x 1024'; 1280x1024 doesn't fix
[18:22] <jcristau> fit, even
[18:22] <james_w> so the framebuffer allocated depends on what's plugged in when X starts?
[18:22] <jcristau> yes
[18:23] <jcristau> if there's no Virtual directive, anyway
[18:27] <james_w> ok, so close the bug as Invalid and ask him to set a Virtual
[18:29] <jcristau> well, it's still a bug that we can't resize the framebuffer
[18:29] <jcristau> just not one that'll be fixed tomorrow
[18:31] <james_w> thanks
[18:33] <bryce> james_w: yeah if it's the virtual directive stuff, we surely have a bug open on that already; in any case it's an upstream issue
[20:50] <bryce> tjaalton: btw, I've been cherrypicking some -ati patches from current git
[20:50] <bryce> tjaalton: maybe it'd be better to just grab a new snapshot, but release team probably would prefer cherrypicks
[20:50] <tjaalton> bryce: good.. upstream should learn how to release though ;)
[20:52] <bryce> yeah...
[20:52] <bryce> of course then I think I probably should volunteer to help with that...
[20:53] <bryce> I'll be happy if they just apply one or two of my patches ;-)
[20:53] <bryce> http://www.bryceharrington.org/ubuntu/Ati/
[22:16] <tormod> bryce: it seems upstream leaves it all up to the distros to make a stable driver, which of course makes for duplicated work.
[22:17] <tormod> one could say that upstream here is redhat though :)
[22:18] <bryce> :-/
[22:18] <tormod> maybe some people from a couple of distros should make a stable branch and cherry-pick things to it. it doesn't have to be Alex doing that.
[22:18] <bryce> tormod: well in fairness the git tree for -ati currently looks mainly like bug fixes so far
[22:18] <bryce> (although some of the changes in recent weeks are what's caused the bugs)
[22:19] <bryce> hmm, you know, establishing a stable branch might not be a bad idea.
[22:19] <tormod> currently yes, the problem is that you never know before afterwards :)
[22:20] <tormod> if Alex likes the idea, he might be helpful in saying "this should go in stable", or "now the tree is stable, time to branch"
[22:21] <tormod> he likes to think that master is always stable, but it's hard to convince release managers about that.
[22:21] <bryce> yes, he's given that kind of advice for me previously (gutsy iirc)
[22:22] <ion_> Btw, i was under the impression the reason for the ABI change that made some versions of fglrx incompatible with X in intrepid was because of MPX. Since intrepid doesn’t have MPX, what caused the ABI change?
[22:22] <tormod> just having a parallel branch almost like master would help to get things past the RM :)
[22:24] <tormod> <IP_ADDRESS> looks much better than 6.9.0+git20080925 :)
[22:25] <bryce> agreed
[22:25] <bryce> hmm, well too late really for intrepid in any case
[22:26] <bryce> (probably...)
[22:26] <bryce> likely a good practice for jaunty tho
[22:26] <bryce> esp if we run into trouble with -fglrx again
[22:27] <ion_> Probably, if the ABI change caused by MPX is yet to come. :-)
[22:29] <bryce> ion_: I heard the X changes that broke -fglrx was the devprivates rework.  Dunno if that involves MPX or not
[22:29] <bryce> afaik the MPX changes still lay in the future
[22:30] <tormod> mpx changes came past 1.5 I think
[22:30] <ion_> Alright, thanks
[22:34] <Ng> tjaalton: do the brightness hotkeys on your thinkpad work?
[22:40] <ion_> They do on mine, if that’s relevant.
[23:42] <jcristau> ion_: most important abi changes from 1.4 to 1.5 are devprivates rework, which was part of the selinux work, and also pci-rework
[23:42] <jcristau> iirc