[00:09] <rlaager> andrews: You probably want to work on gparted. You should contact them.
[00:11] <andrews> rlaager:  I saw gparted on Launchpad is that the main project.
[00:12] <rlaager> andrews: This is most likely off-topic for this chat room. Google gave me this: http://gparted.sourceforge.net/
[00:12] <andrews> rlaager: thanks
[00:28] <GodfatherofEire> I know that I'm probably going to be re-directed, but have any of you specifically dealt with the usplash setup for the previous releases, and/or working on it for Jaunty?
[00:29] <Hobbsee> GodfatherofEire: would suggest checking the changelog of the package 'usplash' to see who's been working on it.
[00:30] <Hobbsee> that appears to be pitti, who will be asleep at the moment (he's in germany)
[00:30] <GodfatherofEire> THank you Hobbsee.
[00:30] <Hobbsee> GodfatherofEire: you're welcome
[00:30] <Hobbsee> you'll probably have to wait 7+ hours, i expect
[00:30] <GodfatherofEire> Where would I find this Changelog, however?
[00:30] <Hobbsee> aptitude changelog usplash
[00:31] <GodfatherofEire> Ich kann warten Hobbsee (I think that'd be it)
[00:31] <Hobbsee> or changelogs.ubuntu.com
[00:31] <Hobbsee> GodfatherofEire: :)
[00:31] <GodfatherofEire> Well, thanks for the help, looks like I'll be back in a bit.
[00:32] <Hobbsee> good luck :)
[00:33] <GodfatherofEire> Thanks.
[02:05] <jdong> are there any future plans for proper 32-bit library support on x86-64, instead of our ia32-libs hack?
[02:06] <TheMuso> jdong: WOuldn't that mean apt/dpkg multi-arch support?
[02:07] <jdong> TheMuso: yeah, I guess
[02:08] <RAOF> That seems to have died a quiet death.
[02:11] <jdong> I was hoping we can do away with scripts like getlibs
[02:15] <RAOF> It'd be nice.
[03:37] <RAdams> why did they change the default inode size to 256 in a new intrepid install? that borks so many utilities for cross-platform FS access...
[03:38] <RAdams> what makes 256 blocks so great?
[03:38] <RAdams> and, how do I install ubuntu in such a way as to prevent that from happening again? I'll have to reformat as it is
[05:38] <blahbleh> hello, i've been thinking about/working on a little app, that would be similar in purpose to #ubuntu, but would allow each end-user with their own problem to have their own little "room" - ie: it's just for their problem. anyone coming in who wants to help can have a look at all the problems people have listed and want live help for, and go in and out; the advantage being that a person can get help from one or more people without inter
[05:39] <persia> blahbleh, Something like answers.launchpad.net, except interactive?
[05:39] <Hobbsee> blahbleh: you got cut off, too
[05:39] <blahbleh> pretty much, yeah. #ubuntu is good because you don't need an account or anything ad can get right into it; this would be similar
[05:40] <blahbleh> hobbsee: where did i get cut off?
[05:40] <persia> Personally, I suspect the main issue is that there's little opportunity for collaboration and cooperation.  One of the great strengths of places like #ubuntu is that as each of us learns more we can help those learning those things whilst seeking help for that which we don't yet understand.
[05:40] <Hobbsee> more people without inter
[05:41] <blahbleh> "the advantage being that a person can get help from one or more people without interference from other people who have their own problems. good idea or bad idea? should i keep going? (not even sure if this is the right place; if not, point me :-) )"
[05:42] <persia> It's probably not the right place, but the location of the right place escapes me.
[05:42] <persia> That said, I still don't think it's good.  Look at the throughput at answers.launchpad.net as compared to the forums.
[05:43] <blahbleh> persia: good point with collaboration... i was thinking that anyone using the app can roam between rooms if they want to, preferably as long as they keep on the same subject as the OP. it would be a bit like ubuntuforums in that respect
[05:43] <persia> It's the same issue: a.l.n expects people to want to solve problems, and look for them (which happens, but to a moderate degree).  the forums encourages people to answer simple questions so that more complex questions get the attention of others, because it's not separate.
[05:44] <persia> Well, maybe.  With the right design, it might work.  The trick is maintaining the incentive for people to answer simple stuff, and build the sense of working together towards a common goal.
[05:47] <blahbleh> thanks very much for the insight, persia :-)   i suppose part of the #ubuntu incentive is that it's *fun*, and incredibly easy
[05:47] <persia> Yep :)
[05:47] <blahbleh> i think i'll keep at it (it's good coding practice anyway, and i have heaps of free time at the moment)
[06:45] <dholbach> good morning
[06:52] <pitti> Good morning
[06:52] <dholbach> hi pitti
[06:53] <Hobbsee> hey pitti, dholbach!
[06:53] <dholbach> hi Hobbsee, hi iulian
[06:54] <iulian> Morning Daniel.
[06:54] <iulian> Hey Hobbsee.
[08:07] <pitti> Riddell: does your "breaks adept" comment in bug 278602 apply to the intrepid SRU or jaunty?
[08:20] <pitti> asac: is bug 278095
[08:20] <pitti> asac: ... an issue in firefox at all?
[10:05] <Riddell> pitti: to the SRU version
[11:44] <ikonia> wgrant: possibly to pick up here ?
[11:45] <wgrant> ikonia: Possibly. You might get better results here from people who know what they're talking about.
[11:45] <ikonia> I think your quite on track
[11:46] <ikonia> I was just curious to how things like the libc headers are decided if the toolchain components are picked up pretty quick after the current release
[11:46] <ikonia> the headers are a good/easy example
[11:46] <cjwatson> how they're "decided"? I don't understand the question
[11:46] <ikonia> cjwatson: from a previous discussion it was explained the the toolchain for current+1 is finalised quite quick after current release
[11:47] <ikonia> so would I be right in thinking that they are picked from a "current" libc header availability say based off 2.6.27 , or is there prospective choices such as say 2.6.29 headers
[11:47] <cjwatson> oh, you mean linux-libc-dev?
[11:48] <cjwatson> it's built directly from the kernel packaging
[11:48] <ikonia> thats one example yes
[11:48] <cjwatson> so it always matches whatever kernel is current in the release
[11:48] <ikonia> cjwatson: that part I would expect however, the current jaunty kernel is 2.6.27, which measn the headers would be based from the .27 kernel
[11:48] <soren> ikonia: We don't start from scratch with every release.
[11:48] <soren> ikonia: When Jaunty came into existence, it was identical to Intrepid.
[11:48] <ikonia> so if you swap later on to say 2.6.29 will your headers follow that or stay with .27
[11:49] <cjwatson> ikonia: yes, that'll be changed whenever the kernel team get a new kernel in place
[11:49] <cjwatson> the headers will follow that
[11:49] <ikonia> that makes sense
[11:49] <ikonia> perfect
[11:51] <cjwatson> it's not ideal that it tends to be a while before the kernel is available so in a sense the toolchain is always going to change quite a bit after the initial bootstrap, but the kernel team are only human and it does take time; I don't think it's all that important in practice
[11:52] <ikonia> cjwatson this is what I suspected, which makes sense now returning back to a prevsious conversation which made me ask this question
[11:52] <persia> I think we usually get someone in the range of 3-5 packages that need readjustment for the changes per cycle, which is not unmanageable.
[11:52] <persia> s/someone/somewhere/
[11:52] <ikonia> persia really, that few ?
[11:53] <persia> ikonia, While the kernel changes a lot, the libc headers from the kernel don't tend to change too wildly.  Depends on which package uses the feature that just went from deprecated to obsolete.
[11:53] <ikonia> persia yes, they have stabiliised a lot since the ed of the LLC project,
[11:53] <ikonia> persia: I just would have expected more breakage
[11:53] <persia> Well, there's certainly the possibility of breakage that I don't hear about :)
[11:54] <ikonia> I just remember how fussy things like libc and binutil where to header changes, even slight ones
[11:54] <ikonia> so I'm surprised that you don't have more breakages, it is a positive thing that you don't though
[11:54] <cjwatson> it's not that bad nowadays.
[11:55] <ikonia> I guess I see more due to the cross-compiling process, rather than the native build, which isn't a good benchmark
[11:57] <ikonia> interesting info, thansk chaps
[13:10] <seb128> doko: you really don't want to use requestsync?
[13:12] <kagou> Hi
[13:13] <kagou> tkamppeter, what do you think about my comment on #294671 ?
[13:22] <seb128> do we have a list of packages which have a newer version in debian experimental than ubuntu somewhere?
[13:24] <mvo> seb128: if we don't have one, I could write you one I think
[13:25] <seb128> mvo: I can probably hack something too, I was just wondering because for GNOME all the recents versions are in experimental so that's what we want to base updates on
[13:25] <seb128> and I expect it's not only GNOME since debian is frozen for a while
[13:27] <joaopinto> is there an easy way to set conditional name resolution, like using different dns server ips based on the hostname domain ?
[13:29] <soren> Where's the documentation for the format of the files in /usr/share/pam-configs?
[13:30] <cjwatson> soren: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
[13:31] <mvo> seb128: whatever you prefer, I was thinking of something very simple based around the apt.Cache(rootdir=debian-experimental); cache.update(); and again for jaunty
[13:31] <persia> seb128, mdt can generate that fairly easily.  Do you think it's useful to have a persistent list?
[13:32] <soren> cjwatson: Thanks.
[13:33] <seb128> persia: what is mdt? that would be useful to have an idea on things we might want to update
[13:33] <geser> multi-distro-tools
[13:33] <seb128> persia: usually there is not so many things there but during freezes they upload to experimental a lot of things which would go usually to unstable
[13:33] <geser> http://qa.ubuntuwire.com/multidistrotools/
[13:33] <seb128> geser: ok, still doesn't tell me a lot
[13:33] <seb128> looking
[13:34] <mvo> geser: interessting, is the source available?
[13:34] <persia> seb128, It's a tool to compare versions of sortware between debian-format archives.  Very handy.  Originally put together by the Utnubu folk.
[13:34] <seb128> mvo: I did something around those lines previous cycle to list merges to do for the desktop team I think, let me have a look if I still have the code around
[13:34] <persia> mvo, There should be a link to the source on that page.  If not, check LP.
[13:36] <geser> mvo: wgrant should have access to the scripts used on ubuntuwire, I just have a old checkout from somewhere
[13:43] <cjwatson> could somebody do me the favour of a quick MIR review? bug 299032
[13:44] <cjwatson> it's on my critical path for getting the installer working for alpha 1
[13:57] <Haegin> hi, can a preseed file contain commands that are executed before being passed to the client?
[13:58] <cjwatson> executed on the server?
[13:59] <Haegin> cjwatson: yeah
[13:59] <cjwatson> Haegin: no, but there are other approaches that can get you similar effects; what are you actually trying to do?
[13:59] <Haegin> i want to set a hostname for the client without knowing anything about the client, i really don't care what hostname it gets, it just needs to be unique
[14:00] <Gast171> dfdds
[14:00] <Haegin> i am installing ubuntu on about 10PCs in an afternoon each week and netbooting them seems the solution
[14:00] <cjwatson> Haegin: use preseed/include and point it at a CGI script that generates something unique
[14:00] <cjwatson> Haegin: or just feed out hostnames using DHCP
[14:01] <Haegin> cjwatson: i tried the hostnames using dhcp approach and the only thing i could find wanted me to prefill the config files with maps between mac addresses and hostnames
[14:03] <cjwatson> dhcp assigns IP address, reverse-DNS ...
[14:03] <cjwatson> you have a finite pool of IP addresses right? :-)
[14:03] <Haegin> yeah :)
[14:03] <cjwatson> comment in netcfg says:
[14:03] <cjwatson>                  * Default to the hostname returned via DHCP, if any,
[14:04] <cjwatson>                  * otherwise to the requested DHCP hostname
[14:04] <cjwatson>                  * otherwise to the hostname found in DNS for the IP address
[14:04] <cjwatson>                  * of the interface
[14:04] <cjwatson> so just seed your DNS server with the IP address range in question
[14:05] <Haegin> it is currently giving an error of "" not being a valid hostname which is the problem I am trying to avoid
[14:06] <Haegin> I think for simplicity i will use the include in the preseed file
[14:06] <Haegin> thanks cjwatson
[14:07] <cjwatson> no problem
[14:07] <pitti> cjwatson: if you are too busy with getting d-i in shape, I can do the installation-report merge; shall I?
[14:07] <NCommander> dholbach, ping
[14:07] <dholbach> NCommander: pong
[14:07] <cjwatson> pitti: it's ok, I'll do it now
[14:07] <cjwatson> pitti: you can do the isoquery MIR in exchange :-)
[14:07] <pitti> cjwatson: hehe, deal
[14:10] <pitti> cjwatson: I didn't get a mail, and it's not on https://bugs.edge.launchpad.net/~ubuntu-mir/+subscribedbugs, hm
[14:11] <pitti> you mean "write it" then, I take it
[14:11] <tkamppeter> kagou, pitti, I have also already thought about SRUing bug 294671. Therefore I have nominated it for Intrepid.
[14:12]  * pitti subscribes ubuntu-mir to bug 299032 and does it
[14:13] <cjwatson> pitti: oh, sorry, I forgot to subscribe ubuntu-mir to the bug
[14:13] <cjwatson> pitti: I wasn't expecting you to write it, no :)
[14:13] <kagou> tkamppeter, oh great, thanks !
[14:14] <cjwatson> installation-report done
[14:14] <pitti> tkamppeter: nomination accepted; however, we should let this mature a bit more, I feel
[14:14] <pitti> cjwatson: bzr merge FTW :)
[14:14] <cjwatson> yeah, not exactly hard work :)
[14:24] <tkamppeter> kagou, it turned out that the Poppler-based pdftoraster filter has not only problem with SpliX but also with Gutenprint and perhaps also with other drivers. Therefore we will not proceed as we did with the SRU for SpliX (adding the Ghostscript-based pdftoraster to Intrepid's driver package) but we should generally replace the pdftoraster driver by the new one.
[14:25] <tkamppeter> kagou, with this we will wait for a certain time to see whether the Ghostscript-based pdftoraster driver does not show other problems.
[14:25] <kagou> ok
[14:37] <asac> pitti: not really understood if its ffox
[14:38] <asac> pitti: but its likely that the root cause is somewhere in ffox
[14:59] <asac> pitti: somehow nspluginwrapper 1.1.2 wasnt built (not attempted) on i386
[14:59] <asac> while 1.1.0 is properly available
[15:01] <asac> both were uploaded during intrepid
[15:07] <persia> asac, I suspect you still have 1.1,0-0ubuntu1 for i386, rather than 1.1.0-0ubuntu2, based on upload dates and P-a-s commit logs.
[15:07] <asac> persia: do you see a reason in pas commit logs?
[15:08] <persia> asac, Nope.  The relevant commit is http://cvs.debian.org/srcdep/Packages-arch-specific?rev=1.712&root=dak&view=markup
[15:09] <persia> asac, Sorry.  Didn't scroll to the right enough.  "64-bit wrapper for 32-bit i386 plugins"
[15:10] <asac> super
[15:10] <asac> but no bug ;)
[15:10] <asac> i would like to see what triggers these kind of things
[15:10] <persia> No.  P-a-s changes aren't managed by bugs.
[15:10] <asac> how are they?
[15:10] <persia> email to the P-a-s committers requesting changes.
[15:12] <persia> Changes get posted to debian-dak@lists.debian.org for review.
[15:13] <asac> so who to CC ... rmurray, infinity ... anyone else?
[15:14] <cjwatson> asac: mail addresses at the top of the file
[15:15] <asac> cjwatson: thanks
[15:15] <asac> hmm. rmurray is not in there
[15:20] <asac> ok sent
[15:22] <zerwas> Is there any work going on in implementing support for intrepid in debootstrap? (scripts/intrepid is missing in http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.10ubuntu1~intrepid1.tar.gz )
[15:23] <asac> zerwas: you mean jaunty?
[15:24] <zerwas> asac: no, i meant intrepid. i wonder why the package i linked to does not contain a file called intrepid
[15:25] <cjwatson> zerwas: it's not missing, it's created as a symlink to gutsy at runtime
[15:25] <cjwatson> er, build-time
[15:25] <cjwatson> see Makefile
[15:25] <zerwas> cjwatson: oh ... i tried to symlink it manually but failed. thanks for the hint, i'll have a look
[15:25] <cjwatson> zerwas: fear not, intrepid supports debootstrapping intrepid ;-)
[15:25] <cjwatson> zerwas: get the binary package rather than the source package if you can
[15:26] <zerwas> d'oh! there it is. thanks.
[15:34] <asac> TheMuso: do we know anyone from at-spi upstream we could poke to take a look at patch in gnome bug 558028 (lp 278095)
[16:13] <emgent> flashplugin 64bit is out: http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.d20.7.linux-x86_64.so.tar.gz
[16:16] <cjwatson> kees,jdstrand_: is it OK if I copy all the packages from intrepid-security that are newer than jaunty into jaunty? the list is: dovecot 1:1.1.4-0ubuntu1.2; enscript 1.6.4-12ubuntu0.8.10.1; linux 2.6.27-7.16; procps 1:3.2.7-9ubuntu2.1
[16:16] <cjwatson> also pam 1.0.1-4ubuntu5.3 from intrepid-updates
[16:26] <emgent> DktrKranz: pinghe ponghe
[16:33] <wasabi> so at some point something started rebuilding /etc/dhcp3/dhclient.conf. Debconf I'm assuming. Except it lost the send "<hostname>" setting.
[16:33] <wasabi> sup with that?
[16:34] <wasabi> I thought we'd just fixed that in hardy.
[16:34] <slangasek> cjwatson: I wouldn't worry about pam, I have an update pending for that (but it also doesn't hurt if you do copy it :)
[16:35] <wasabi> Hmm. No. Broke in hardy. Well then.
[16:36] <NCommander> pitti, ping
[16:36] <slangasek> wasabi: eew?  dhclient.conf is a conffile and shouldn't be rebuilt.
[16:36] <cjwatson> slangasek: copied for tidiness, then
[16:36] <wasabi> I just installed a clean hardy, and dhclient.conf is a single line long... and 'looks' generated. And dpkg-dist exists, with the original Debian content
[16:37] <wasabi> I'm not sure what the thought here is.
[16:37] <slangasek> wasabi: I'm not seeing this on my hardy install
[16:38] <wasabi> Hmm.  Well. I just finished the install. Server install.
[16:38] <NCommander> cjwatson, mind if I ask you an SRU question?
[16:38] <wasabi> Let me dig through post* stuff and see if I can find it
[16:38] <cjwatson> NCommander: better to ask than to ask to ask ...
[16:39] <NCommander> cjwatson, during my efforts to resolve a FTBFS in adept in intrepid-proposed, it seems that the cmake shipped with intrepid has a bug that causes it to hardcode in the paths of some libraries from the build-envrionment, i.e. /build/buildd, etc.
[16:39] <liw> cjwatson, can I ask slangasek if I can ask Keybuk whether he's OK with me asking sabdfl about presenting him with a question on the general topic of asking me a question?
[16:39] <cjwatson> kees,jdstrand_: copied dovecot and enscript; linux and procps go together and I might just wait for the kernel team to get an upload together
[16:40] <cjwatson> liw: :-P
[16:40] <slangasek> EMETAOVERFLOW
[16:40] <wasabi> slangasek: https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/221881         Seems to be the same problem.
[16:40] <NCommander> cjwatson, the version of cmake in jaunty and intrepid-backports has this bug resolved
[16:40] <wasabi> Oh well. Man. I thought we had this stuff solid now.
[16:40] <wasabi> Guess not.
[16:40] <NCommander> cjwatson, it wasn't caught because it seems only the last update to cmake caused it to manifest, and kdelibs wasn't rebuilt until a small patch was added via updates
[16:41] <slangasek> wasabi: that doesn't seem to be a report of the problem of dhclient.conf being munged to death, though?
[16:41] <wasabi> It's not clear whether it is or not.
[16:41] <NCommander> cjwatson, I've been trying to find the commit in cmake's CVS that fixed this, but I don't see any explicate references to a bug that would cause this, it might have been unintentionally fixed. Is it possible we could drop the newer cmake into proposed/updates if I can't isolate the necessary change? (I'm working to see if there is a less invasive solution, but its not looking promising)
[16:41] <wasabi> He says he also has a dhclient.conf.dpkg-dist, which I do too.
[16:42] <wasabi> Clean install and I ended up with a .dpkg-dist
[16:42] <wasabi> I don't know what's doing it either. none of the maintainer scripts seem to be touching it.
[16:43] <slangasek> so my best guess is that something is creating the dhclient.conf before dhcp3-client is installed; then the installer is using the default "use locally modified version" option non-interactively
[16:43] <wasabi> Ahh.
[16:43] <wasabi> d-i must be doing it
[16:43] <cjwatson> NCommander: the least invasive option would be to fix it just in the packages where it causes a problem; I'm a bit scared of any cmake changes given its reverse-build-dep list
[16:43] <slangasek> but I've never seen this in practice.  I've also never done a server install.
[16:44] <slangasek> (not a persistent one, anyway)
[16:44] <slangasek> wasabi: you said your dhclient.conf was one line long, what's the line?
[16:44] <wasabi> "request subnet-mask, broadcast-address, time-offset, routers, domain-name,    domain-name-servers, host-name, ntp-servers;"
[16:44] <wasabi> Funny spacing included.
[16:44] <slangasek> hmm
[16:44] <cjwatson> d-i stopped copying dhclient.conf to the target system in intrepid due to conffile problems like this
[16:44] <wasabi> Okay. So this is just a hardy problem ya'll have fixed
[16:44] <slangasek> ah, so this is resolved for intrepid but present in hardy
[16:44] <cjwatson> I believe so
[16:45] <NCommander> cjwatson, fair enough, although I think my hack meter might self-destruct from the necessary fixes
[16:45] <cjwatson> this is just from scanning the netcfg changelog though
[16:45] <cjwatson> NCommander: if it is necessary, I'd like a second opinion from another Kubuntu developer as well; just because I don't know the area at all myself
[16:48] <wasabi> I've noticed -updates has become a bit more liberal lately. Could this be something for consideration?
[16:59] <slangasek> wasabi: if a reasonably self-contained fix is possible, we could roll that into 8.04.2, yes
[17:06] <kirkland> pitti: ping, regarding your comments to https://bugs.launchpad.net/bugs/259631
[17:11] <kirkland> pitti: i responded in the bug;  will need some feedback from you either here or there before proceeding.
[17:17] <kees> cjwatson: cool, thanks.
[17:18] <kees> cjwatson: I'm fine with copying the kernel/procps stuff too, unless the kernel team actually objects for some reason.
[17:20] <slangasek> kees: hee, upstream has looked at the per-user env pam_environment patch, and reports that it's full of memory leaks
[17:20] <kees> slangasek: interesting.  it's been a while since I've looked at that.
[17:23] <kees> I think tollef wrote it originally.  which processes would see the leak?
[17:24] <Mithrandir> gdm
[17:25] <kees> Mithrandir: ah-ha!  I couldn't think of something that was long-running.  (ssh exits, login exits)
[17:25] <kees> slangasek: looks like it should be easy to fix.
[17:25] <Mithrandir> maybe gdm-login would be the one.
[17:27] <kees> Mithrandir: looks like callers of _pam_parse just need to free all the passed variables?
[17:28] <Mithrandir> kees: yeah, I think so.
[17:28] <Mithrandir> "full of memory leaks" is probably a slight exaggeration, but fixing this would be good anyway.
[17:29] <kees> Mithrandir: yeah, agreed.  just a slow build-up of a few strings per login.
[17:29] <Mithrandir> yup
[17:29] <Mithrandir> so you'll run out of memory if you log in and out two million times and only have 64MB RAM.
[17:31] <Mithrandir> (ok, it leaks a bit more, but less than 1k per login, I think, so not exactly a big problem)
[17:58] <pitti> NCommander: pong
[17:59] <pitti> kirkland: replied
[18:00] <kirkland> pitti: yeah, sorry about that ... i should have explained that more clearly in the SRU details
[18:00] <pitti> kirkland: no need to be, was just a misunderstanding
[18:01] <kirkland> pitti: i'll add a couple of lines to https://help.ubuntu.com/community/EncryptedPrivateDirectory on how to establish those symlinks
[18:18] <NCommander> pitti, cjwatson answered my question
[18:30] <jelmer> Does anybody know whether Ian Jackson hangs out on IRC?
[18:31] <cjwatson> not routinely on this network
[18:31] <cjwatson> probably best to e-mail him
[19:50] <zul> slangasek: ping what do you think of https://bugs.launchpad.net/bugs/282298?
[19:53] <slangasek> zul: the NAS is insecure and they should migrate to something newer; and if they don't like that answer they have to re-enable 'client lanman auth', which is now disabled by default upstream
[19:54] <zul> slangasek: ok
[19:54] <slangasek> zul: oh, but there's a patch that fixes a protocol compatibility issue with Samba 2.2?
[19:54] <slangasek> that would be sensible to apply, then; I assumed this was the known password encryption compat issue
[19:55] <slangasek> and is appropriate for SRU
[19:55] <zul> slangasek: yeah theirry did the path I was just going to upload to proposed now
[19:59] <directhex> hm, usplash looks completely busted when a widescreen console mode is forced
[20:00] <mohbana_> is anyone using the 64bit flash plugin
[20:01] <directhex> mohbana_, just trying it out
[20:02] <mohbana_> directhex: i'd also like to but i'm afraid something will break
[20:02] <mohbana_> something. flash is always crashing my machine it's absurd
[20:05] <directhex> mohbana_, thedailyshow.com is no longer a guaranteed browser crash
[20:06] <joaopinto> mohbana_, you can't break nothing, except that if flashes crashes your browser will crash
[20:08] <directhex> joaopinto, which nspluginwrapper has been doing for years
[20:08] <directhex> hm. usplash is very confused. how do debug it.....
[20:14] <directhex> sigh. bollocks to it. i'll just try a non-widescreen fb mode, and file a bug
[20:15] <directhex> urgh, 1024x768 is still fail
[20:20] <directhex> hm. if i can pick between usplash fail or console fail, do i file a bug against usplash or the kernel?
[20:29] <NCommander> pitti, hola
[20:30] <wgrant> geser: http://people.ubuntuwire.com/~fujitsu/bzr/multidistrotools/, for future reference. I think there's only one new revision since I last pushed to lp:~ubuntu-qa/multidistrotools/ubuntuwire, however.
[20:30] <wgrant> There are a few changes in the dead Debian branch that I should probably merge at some point, but nothing too significant.
[20:31] <pitti> hi NCommander
[20:32] <NCommander> pitti, in the mood to sponsor and process an SRU for intrepid in main for me :-)?
[20:33] <pitti> NCommander: can do, but not today any more (about to fall to bed, not feeling well)
[20:33] <pitti> NCommander: can you please subscribe me to the bug? I'll do it tomororw
[20:33] <NCommander> pitti, sure. SRU is subscribed, but I'll add you specifically
[20:33] <pitti> NCommander: SRU is fine, too, I get that
[20:57] <pitti> ArneGoetje: did you send a CFT to -translators@?
[22:57] <Ceriand> I'm trying to make some changes to the configure.in file for pango to get it to compile for directfb
[22:57] <Ceriand> i run autogen.sh and it completes with a warning: configure.in:40: version `pango_version()' doesn't follow Gnits standards
[22:57] <Ceriand> doing ./configure works fine
[22:57] <Ceriand> but when i try to run make it gives me the same error as above
[22:58] <Ceriand> anyone more versed in autoconf-fu care to help me out?