=== Kopfgeldjaeger is now known as Kopfi|offline
[00:31] <Peaker> hey, how come building python package from source runs its unit tests like 5-6 times (or more)?  why run them at all, and then why re-run them?
[00:32] <azeem> "why run them at all?"
[00:32] <azeem> was that a serious question?
[00:36] <Peaker> yeah - why run the unit tests as part of the build of the package?  they were run by those who distributed the source in that form
[00:37] <Peaker> most sources don't have a UT to run when building the package...
[00:37] <azeem> do you consider this a feature?
[00:37] <slangasek> changes to build environments can (and do) introduce regressions.
[00:37] <azeem> Peaker: the point of unit tests is testing the binaries
[00:38] <Peaker> I think its for testing the source
[00:38] <Peaker> the binaries will correspond to the source anyway, we have compilers we trust :)
[00:38] <azeem> Peaker: welcome to the real world
[00:39] <kees> Peaker: it's testing him in shared library form, static library form, maybe in other build ways
[00:39] <azeem> also, welcome to different architectures, etc.
[00:39] <Peaker> kees: does it ever get differing results ?
[00:39] <kees> Peaker: yup
[00:39] <Peaker> is there any way to cancel the unit tests?
[00:40] <azeem> export DEB_BUILD_OPTIONS=nocheck
[00:40] <azeem> might help
[00:40] <Peaker> thanks
[00:42] <azeem> well, not cancel, but disable
[00:42] <slangasek> kees: hmm, do you know of any toolchain behavior changes between hardy and intrepid, that wouldn't show up as added CFLAGS?
[00:43] <kees> slangasek: there was a lot of changes between gcc 4.2 and 4.3.
[00:43] <kees> slangasek: 4.3 is MUCH pickier about C++ stuff especially.
[00:43] <slangasek> but no deliberate behavior changes on C code, that you know of?
[00:43] <slangasek> I'm trying to debug the milestoned sysklogd bug
[00:44] <slangasek> I think, but haven't yet proven, that klogd is failing to call its internal openlog() implementation, the one that supports LOG_KERN
[00:44] <kees> slangasek: I'm personally not aware of anything that wouldn't yell loudly duriung compile.  (4.3 is more strict about builtins)
[00:44] <slangasek> but then when I've proven that, I'm still not sure *why* it's doing this
[00:45] <kees> (gah, 2.6.27 keeps io deadlocking on me...)
[00:45] <kees> (but only until I switch tasks or something hmpf)
[00:45] <kees> slangasek: which bug #?
[00:45] <slangasek> kees: bug #255635
[00:45] <ubottu> Launchpad bug 255635 in sysklogd "Kernel messages not logged to /var/log/kern.log" [High,Triaged] https://launchpad.net/bugs/255635
[00:45] <slangasek> build the same source on hardy, it works fine
[00:45] <slangasek> (expected, the source hasn't changed much)
[00:46] <kees> wait, built with the intrepid toolchain?
[00:46] <kees> oh you meant build on hardy with intrepid source
[00:46] <slangasek> yes
[00:46] <kees> have you tried compiling with -U_FORTIFY_SOURCE ?
[00:47] <kees> (on intrepid)
[00:47] <slangasek> not yet
[00:47] <kees> but I confirm -- my kern.log is empty.  :)
[00:48] <kees> but it is getting into my messages file
[00:51] <kees> I do see some warnings from fortify, but nothing that would seem to indicate this kind of magic.  http://launchpadlibrarian.net/16992758/buildlog_ubuntu-intrepid-i386.sysklogd_1.5-2ubuntu5_FULLYBUILT.txt.gz
[00:53] <kees> slangasek: *sigh*
[00:53] <slangasek> ?
[00:53] <kees> CFLAGS aren't imported by upstream
[00:54] <kees>         ${CC} ${SKFLAGS} ${SYSLOGD_FLAGS} $(DEB) -c syslogd.c
[00:54] <slangasek> I know; how does that /break/ the build? :)
[00:54] <kees> SKFLAGS= $(RPM_OPT_FLAGS) -O3 -DSYSV -fomit-frame-pointer -Wall -fno-strength-reduce
[00:54] <kees> no, but it's frustrating my attempts at -U_FORTIFY_SOURCE
[00:54] <kees> and I love the use of RPM_OPT_FLAGS
[00:54] <azeem> -DSYSV FTW
[00:55] <slangasek> we could always fix this bug by replacing sysklogd with rsyslog
[00:56] <wgrant> I would have thought we would be doing that anyway.
[00:56] <kees> Aug 29 16:56:28 gorgon klogd: Kernel log daemon terminating.
[00:56] <kees> Aug 29 16:56:30 gorgon kernel: Inspecting /boot/System.map-2.6.27-2-generic
[00:57] <kees> somehow, it is fortify.
[00:57] <slangasek> are you sure it's not glibc?
[00:57] <slangasek> because my money is on glibc
[00:57] <kees> well, fortify is all implemented in glibc, so yeah, I'd bet it's a bug in glibc too, but cramming -U_FORTIFY_SOURCE does fix the behavior.
[00:57] <slangasek> well, except that I can't find any evidence of this in the glibc headers :)
[00:58] <slangasek> heh, ok
[00:58]  * kees wonders if there is a macro for openlog that causes the first arg to be ignored and replaced with argv[0]
[01:01] <kees> hm, guess not.  wtf
[01:02] <slangasek> no, but if I edit the syslog.c source to add a printf() to openlog, it only shows up if I build syslog.c with hardy
[01:03]  * kees scratches his head
[01:03] <slangasek> no, I take that back
[01:03] <slangasek> I'm just confused because the printf() is dumped to syslog, and buffered very oddly such that it shows up at the end :)
=== nxvl_ is now known as nxvl
[01:08] <kees> slangasek: freaky -- it _is_ calling it with "kernel" as the arg (says the disassembly)
[01:12] <kees> slangasek: is it something else that causes it to direct stuff from klogd into kern.log?  if I juse use "logger -t kernel" it all goes into messages too.
[01:12] <slangasek> kees: logger -t kernel uses the glibc openlog() implementation
[01:13] <slangasek> which doesn't permit LOG_KERN
[01:13] <kees> what is klogd.c using?
[01:13] <slangasek> (it selects by facility anyway, so even if glibc let you, you would have to use logger -p kern.foo)
[01:13] <slangasek> it uses the openlog() implementation in syslog.c
[01:14] <kees> ah-ha
[01:15] <slangasek> so, recompiling just klogd.c on hardy fixes it
[01:17] <kees> slangasek: yup, -U_FORTIFY_SOURCE only klogd.o fixes it for me too.  wtf.
[01:18] <Peaker> its taking hours to build the python package, arrg
[01:21] <slangasek> Peaker: so the question we've jumped right over, why are you rebuilding the python package?
[01:21] <Peaker> slangasek: I thought it would be a quick way to test a source-level change I was contemplating
[01:22] <Peaker> a bug that has been annoying me for more than a year now, I think
[01:23] <slangasek> ah, well, good reason :)
[01:23] <azeem> Peaker: so a bug that annoyed your for more than a year is not worth several hours of unattended cpu cycles?
[01:23] <azeem> you*
[01:23] <Peaker> azeem: it makes the debug/test cycle quite a long one
[01:23] <Peaker> and its unnecessary :P
[01:23] <azeem> Peaker: you don't need to start over each time I assume
[01:24] <slangasek> well, yes; in that case, call ./debian/rules build, and don't bother moving things into packages after each test cycle?
[01:24] <slangasek> s/after/for/
[01:24] <kees> Peaker: did DEB_BUILD_OPTIONS=nocheck debuild ....  not work?
[01:24] <slangasek> assuming that debian/rules build isn't the part that's getting stuck in the testsuite, that is
[01:24] <Peaker> slangasek: does that avoid running the unit tests like DEB_BUILD_OPTIONS=nocheck does? or is that env-var still necessary?
[01:24] <Peaker> kees: I haven't tried yet - I thought it would be wiser to let it finish building (I am not sure whether that was the right thing)
[01:25] <azeem> Peaker: check debian/rules
[01:25] <slangasek> you would still want to set that var, to be safe
[01:25] <slangasek> or check, yes
[01:25] <azeem> depends on whether they are run by build or binary
[01:25] <kees> slangasek: fortify_source appears to be redirecting the syslog calls away from syslog.o
[01:26] <kees> +                 U __syslog_chk@@GLIBC_2.4
[01:26] <kees> +                 U __vfprintf_chk@@GLIBC_2.3.4
[01:26] <kees>                   U __vsprintf_chk@@GLIBC_2.3.4
[01:26] <kees> +                 U __vsyslog_chk@@GLIBC_2.4
[01:28] <slangasek> ahh
[01:28] <kees> at least, that's my guess
[01:28] <slangasek> doh, I was staring so hard at openlog, I didn't think to look at syslog
[01:28] <slangasek> yes, that stands to reason
[01:30] <kees> slangasek: shall I upload it with that fixed?
[01:31] <slangasek> just adding -U_FORTIFY_SOURCE for klogd.o?
[01:31] <kees> yup.
[01:31] <slangasek> yeah, go for it
[01:35] <kees> donions
[01:35] <slangasek> thanks
[01:36] <kees> sorry for the glitch.  I blame everything on fortify_source first.  ;)
[01:36] <slangasek> heh
[01:36] <slangasek> thing was, I /knew/ about syslog_chk because I'd seen it in objdumps, and didn't think to look for a local syslog() implementation to go with the openlog one... :)
[01:38] <kees> yeah, kind of a twisted source, klogd.  :P
[01:40] <kees> now if only I could fix firefox to run with fortify_source....
[01:40]  * slangasek grins
[02:42] <wgrant> Aw, who changed "Yes, do as I say" to "I am aware that this is a very bad idea"?
[03:53] <NCommander> Morning (or evening) wgrant
[04:10] <wgrant> NCommander: Early afternoon, NCommander.
[04:11] <NCommander> wgrant, I'm timezone challenged ;-)
[04:19] <NCommander> wgrant, can I call on you to sponsor a FTBFS fix?
[04:36] <slangasek> wgrant: hmm, in apt-get ?
[04:38] <wgrant> slangasek: Yes.
[04:38] <slangasek> aww
[04:39] <wgrant> NCommander: Perhaps; depends how big it is. I'm mildly busy at the moment.
[04:39] <NCommander> wgrant, relatively small debdiff, maybe 30 lines
[04:39] <wgrant> I'd recommend going through the usual u-u-s mechanism.
[04:40]  * NCommander will wait then
[04:40] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/alsaplayer/+bug/262581
[04:40] <ubottu> Launchpad bug 262581 in alsaplayer "FTBFS fix for alsaplayer" [Undecided,New]
[04:42] <Awsoonn> Is there a better place to talk about intrepid?
[04:46] <Awsoonn> are there any known issues wiht the latest intrepid kernel and the nvidia drivers?
[04:46] <wgrant> A friend of mine had to remove and reinstall nvidia-177 to get it working.
[04:46] <wgrant> But it apparently does work.
[04:46] <Awsoonn> wgrant: any logs or other data i should grab before doing that?
[04:47] <Awsoonn> thing that might be usefull to whoever works on that.. bryce maybe?
[04:47] <wgrant> That's probably tseliot's domain.
[04:48]  * Awsoonn wonders if he's around
[04:56] <NCommander> wgrant, could you reset the build records on postfix on all architectures? Soyuz goofed and marked it failed vs. dep-wait.
[04:57] <wgrant> That sounds mainish.
[04:57] <wgrant> I'm not a core-dev.
[04:57] <NCommander> I thought you were
[04:57]  * NCommander hides
[05:00] <NCommander> ScottK, are you around?
[05:00] <ScottK> Breifly
[05:00] <ScottK> Briefly even
[05:00] <NCommander> Can I ask you to retry a build on Postfix?
[05:01] <NCommander> (soyuz failed to mark it dep-wait and failed it instead)
[05:01] <ScottK> Is mysql fixed?
[05:01] <NCommander> yeah
[05:01] <NCommander> I'm going through the build failure logs trying to find the ones that are dep-waits that are resolved vs. actual failures
[05:01] <ScottK> Sure.  I'll try one arch and we'll see what happens.
[05:01] <NCommander> Got to get that FTBFS count down ;-)
[05:02]  * NCommander wants zero FTBFS if possible ;-)
[05:02] <ScottK> Queued for retry.
[05:02] <ScottK> I did amd64
[05:02] <NCommander> THanks Scott
[05:02]  * NCommander continues working on FTBFS fixes
[05:08] <NCommander> ScottK, can you reset the build record on amarok-kde4 on sparc? It bombed with Bus Failure, so it seems that is a transient failure
[05:09] <NCommander> hola LucidFox
[05:10] <ScottK> Postfix worked.  Let me do the other archs fist.  Please give me a link for amarok-kde4
[05:10] <NCommander> ScottK, http://launchpadlibrarian.net/16999884/buildlog_ubuntu-intrepid-sparc.amarok-kde4_1.90-0ubuntu1_FAILEDTOBUILD.txt.gz
[05:10] <NCommander> Ideally, I'd like to resolve every single FTBFS in main :-)
[05:11] <ScottK> NCommander: I need the package page, not the build log.
[05:11] <NCommander> oh, d'oh
[05:11] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/amarok-kde4
[05:12]  * ScottK loks
[05:12] <ScottK> looks
[05:12] <ScottK> What about hppa?
[05:12] <NCommander> Also, kde4bindings is another misidentified dep-wait, which was cleared (dep-wait python-qt4)
[05:13] <NCommander> I keep the hppa tab hidden on qa's page
[05:13] <NCommander> hold on
[05:13] <NCommander> HPPA should be dep-wait, I'm not sure all the dependencies are in place
[05:13] <ScottK> NCommander: If it's depwait and not FTBFS it'll take care of itself in time.
[05:13] <NCommander> it does?
[05:14] <NCommander> Wait
[05:14] <NCommander> No, it should be dep-wait
[05:14] <NCommander> but its not
[05:14] <ScottK> Sure.  Depwait will undepwait and build in turn.
[05:14] <ScottK> hppa was FTBFS.
[05:14] <NCommander> Looking at the log, its dep-wait
[05:14] <NCommander> Or it should be
[05:14] <NCommander> It failed because not all its build-deps were installable
[05:14] <ScottK> Yes.  I wonder about that, but that's how it works.
[05:15] <ScottK> build-deps missing or insufficient version you get depwait.  Not installable, you get FTBFS.
[05:15] <NCommander> It's a limitation in sbuild
[05:15] <ScottK> I don't understand why we would want that.
[05:15] <NCommander> Which I think is due to a limitation in apt-get
[05:16]  * ScottK wonders if there's already a bug in soyuz on that.
[05:16] <NCommander> Well, I'm asking cprov, because I know where changes have to be made in both apt-get, and sbuild to trigger the correct behavior
[05:16] <wgrant> There's been a bug about it for some time.
[05:17] <NCommander> From the way I understand it, the dep-wait status is triggered by sbuild's return code
[05:17] <NCommander> I guess log-parsing determines what should be dep-waited on
[05:20] <wgrant> Bug #160439
[05:20] <ubottu> Launchpad bug 160439 in launchpad-buildd "Some builds fail when they should depwait" [Medium,Triaged] https://launchpad.net/bugs/160439
[05:20] <ScottK> Fixing that would be high on my soyuz list.
[05:20] <NCommander> Yup
[05:20] <ScottK> If, of course, I'd been asked for a soyuz input.
[05:20] <NCommander> What's MANUALDEPWAIT
[05:20] <NCommander> I assume that means the build is just randomly retried vs waiting for a specific dependency
[05:22] <wgrant> NCommander: I don't know why the MANUAL bit is there.
[05:22] <wgrant> It's automatically retried when the missing build-depends appear.
[05:22] <NCommander> Well, I know on Debian dep-wait is a status we, as buildd-maintainers have to set packages to automatically
[05:22] <NCommander> I assume SOyuz is smart enough to determine proper dep-waits
[05:22] <wgrant> Correct.
[05:23] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/pigment - care running this one on amd64?
[05:23] <NCommander> (a lot of these FTBFS are dep-wait mistakes)
[05:24] <ScottK> Yes.  To get kde3.5.10 to build it took a LOT of retries due to this problem.
[05:24] <NCommander> kdeutils also needs it on all archs expect HPPA
[05:26] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/intrepid/+source/kvkbd/0.5.99-0ubuntu1 - here too
[05:27] <NCommander> ugh, your kidding, logwatch is still broken
[05:28] <ScottK> NCommander: Done.  I'm off to bed.
[05:29] <NCommander> Thanks
[06:25] <moquist> my package (moodle) depends on moodle-postgres | moodle-mysql, and I'm writing separate postinst scripts for moodle, moodle-postgres, and moodle-mysql, which come from the same src pkg. moodle.postinst creates a config file that differs depending on whether moodle-postgres or moodle-mysql is installed.
[06:26] <moquist> I don't know how I can (appropriately, non-hackishly) known in moodle.postinst which database is being used, without asking the user (which is an extra question that the user might get wrong, anyway).
[06:26] <moquist> slangasek: I'm not going to put something in debconf that I can look up later, but that's the best way I can think to do this. :\
[06:27] <moquist> ...or I could try to be clever and detect which database has been created...but that seems ridiculously over-complicated and error-prone.
=== ethan is now known as Eleaf
[06:41] <moquist> ogra: ping
[06:47] <Eleaf> pong
[07:38] <slangasek> moquist: you might want to look into wwwconfig-common
[07:40] <moquist> this is in main; wwwconfig-common isn't allowed IIRC
[07:41] <moquist> slangasek: I'm in the process of implmenting this using shared/moodle/db_<param>, and db_setting shared/moodle/db_server in moodle-<dbtype>.config...should I just stop now? :\
[07:42] <slangasek> wwwconfig-common isn't currently present in main; that doesn't mean that it's better to reinvent the wheel if a solution exists that could be pulled in to main
[07:42] <slangasek> I don't know if wwwconfig-common is considered unsuitable for main for some reason, but I think it's worth investigating
[07:43] <moquist> slangasek: it is.
[07:43] <slangasek> it is what? unsuitable for main?
[07:43] <moquist> slangasek: the whole reason I ever touched this package in the first place was to get rid of the dep on wwwconfig-common (in gutsy days)
[07:43] <moquist> yeah, unsuitable for main
[07:43] <slangasek> hrm
[07:43] <slangasek> why is it unsuitable?
[07:43] <moquist> I don't know that.
[07:45] <moquist> ogra might know more details; he got me started
[07:46] <moquist> slangasek: I'll just finish what I'm doing and post it for review. at least I'll learn something from this, even if I end up undoing things.
=== Kopfi|offline is now known as Kopfgeldjaeger
[12:06] <NCommander> Is there anyone who can retry universe builds for me?
[12:27] <NCommander> Riddell, ping?
[12:47] <Riddell> hi NCommander
[12:48] <NCommander> Riddell, could you retry kdebindings? I've been running down FTBFS all morning, that one is a dep-wait misidentified as a failure :-)
[12:50] <Riddell> what's that script called for retrying?
[12:51] <NCommander> buildd
[12:51] <NCommander> ALso dovecot if I can get main retrys out of you
[12:51] <NCommander> (I've sorta been torturing MOTU for the universe all morning ;-))
[12:53] <Riddell> NCommander: done
[12:53] <NCommander> Riddell, thank you
[12:53]  * NCommander hates transient failures
[12:57] <NCommander> RainCT, as an aside, your update maintainer script broke on updating the changelog in intrepid
[13:02] <RainCT> NCommander: uhm.. here it works. which error did you get? (and it's not mine, although I may have contributed to it)
[13:02] <NCommander> no error
[13:02] <NCommander> RainCT, its your name in the man file
[13:03] <NCommander> Just no changelog entry
[13:03] <RainCT> NCommander: "and this *manual page* by Siegfried"
[13:03] <NCommander> whoops
[13:03]  * NCommander slinks away
=== ryu2 is now known as ryu
[13:05] <RainCT> NCommander: and it doesn't add the changelog entry anymore. that was discussed in ubuntu-motu@ and it was decided(?) that it isn't necessary anymore to document that in the changelog file
[13:05] <NCommander> oh
[13:05] <NCommander> bah
[13:05] <NCommander> Ok
[13:05] <NCommander> Stupid question, what preprocessor symbol is defined on Linux
=== _gAri- is now known as gAri-
=== asac_ is now known as asac
[13:45] <NCommander> Riddell, you'll be happy to know that with the exception of lpia (and dep-wait on hppa), it appears kdebindings4 now properly builds on at least amd64/i386
[13:46] <Riddell> yay
[13:46] <NCommander> Riddell, I'm working on resolving the FTBFS on koffice, which appears to be longstanding
[13:51]  * NCommander is going to try and get the FTBFS count on amd64/i486 to under 20, and the other architectures to be under 50 within universe (and main if any are still left there)
[13:57] <NCommander> Riddell, BTW, where can I file bugs for changes to P-a-s?
[13:59] <geser> NCommander: see the comment in P-a-s who to contact
[14:01] <NCommander> I saw that
[14:01] <NCommander> There is no Ubuntu specific P-a-s, is there
[14:01] <NCommander> Mostly cause I can't see ubuntu specific packages getting in there like linux-lpia
[14:01] <Riddell> P-a-s?
[14:02] <NCommander> Packages-arch-specific
[14:02] <NCommander> It tells the buildds what not to build.
[14:02] <geser> NCommander: no, Debian and Ubuntu share a common P-a-s
[14:02] <NCommander> bah
[14:24] <crevette> hello
[14:25] <crevette> is a Feature freeze request is necessary for package in universe ?
[14:26] <azeem> universe is handled in #ubuntu-motu I believe
[14:26] <crevette> I would like to request a sync for nemiver
[14:26] <crevette> okay
[14:26] <crevette> thanks
[14:26] <NCommander> Riddell, do you know where I can download buildd chroots? I'm going to try and squash the SCons + buildd issue
=== Pici`__ is now known as Pici
=== bddebian2 is now known as bddebian
[15:12] <asac> tjaalton: libGL error: dlopen /usr/lib/dri/r300_dri.so failed (/usr/lib/dri/r300_dri.so: undefined symbol: _glapi_tls_Context)
[15:12] <asac> tjaalton: (me trying X1950 with ati -> direct rendering: no)
[15:13] <asac> tjaalton: doest it mean we have the wrong version of something?
[15:23] <jcristau> asac: it means you have incompatible versions of the dri driver and libGL or X
[15:24] <asac> jcristau: ok. so why do i get that in intrepid atM?
[15:25] <asac> is there an upload pending?
[15:27] <jcristau> you shouldn't get that
[15:27] <asac> but i do ;)
[15:27] <jcristau> libGL.so.1 and /usr/lib/xorg/modules/extensions/libglx.so should export _glapi_tls_Context
[15:28] <jcristau> unless you've replaced one of them with the fglrx version, or something
[15:28] <asac> ok ... lets check if that is diverted
[15:29] <asac> cool
[15:29] <asac> at least i had it installed ... which explains it i guess
[15:39] <asac> jcristau: no success
[15:39] <asac> still the same thing
[15:47] <jcristau> asac: something's wrong, then :)
[15:53] <asac> jcristau:  nm -D /usr/lib/xorg/modules/extensions/libglx.so |grep tls
[15:53] <asac> 0000000000000008 B _glapi_tls_Context
[15:53] <asac> 0000000000000000 D _glapi_tls_Dispatch
[15:56] <asac> ok i think i have an idea
[16:00] <asac> jcristau: ok i had clutter in /usr/lib/xorg/
[16:00] <asac> thx
=== _jason is now known as jrib
=== Kopfgeldjaeger is now known as Kopfi|offline
=== Kopfi|offline is now known as Kopfgeldjaeger
[17:08] <kees> asac, fta: I think I found the problems with xulrunner/firefox's misuse of realpath() (it wasn't setting MAXPATHLEN correctly)  I've got the debdiffs in bug #263014 that fix it for me (I can run and use firefox with FORTIFY_SOURCE enabled).  Can you review it and let me know it qualifies for upload?
[17:08] <ubottu> Launchpad bug 263014 in xulrunner-1.9 "fails to run when built with FORTIFY_SOURCE" [Undecided,New] https://launchpad.net/bugs/263014
[17:09] <fta> kees, we have a patch in upstream bugzilla for a while
[17:09] <fta> hold on, let me check
[17:10] <fta> mozilla bug 412610
[17:10] <ubottu> Mozilla bug 412610 in Startup and Profile System "MAXPATHLEN too small for glibc's realpath()" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=412610
[17:10] <azeem> uh
[17:11] <azeem> glibc's realpath() can deal without MAXPATHLEN, no?
[17:12] <fta> kees, i expected this upstream patch to be committed long ago, that why i didn't use the patch. then i forgot about it :P
[17:13] <fta> but upstream is not sure about the best approach
[17:13] <fta> kees, btw, it's more widespread than you debdiff, there are several places where this MAXPATHLEN is needed.
[17:13] <fta> youR
[17:14] <fta> (and also several packages)
=== ryu2 is now known as ryu
=== Awsoonn_ is now known as Awsonn
=== Awsonn is now known as Awsoonn
[18:10] <kees> fta: ah, yeah, the upstream RH patch looks more complete -- can we use that?  I'd really like to actually fix the root causes since they are real issues.
[18:10] <kees> fta: actually, the last patch looks very close to mine: https://bugzilla.mozilla.org/attachment.cgi?id=335369
[18:10] <fta> kees, sure, I will grab the patch and merge it.
[18:11] <kees> fta: and please revert the -U_FORTI...
[18:11] <fta> yes
[18:12]  * kees hugs fta
[18:15] <fta> :)
[18:16] <kees> fta: did you report the "cvs" problem too?  I can't find any notes on FORTIFY in "cvs" or "mozilla-devscripts".
[18:17] <fta> i didn't, just in the wiki. it seems the problem disappeared since.
[18:18] <kees> ah, very good.  I will drop it from the wiki for now then.
[18:25] <fta> tseliot, this bug 259808 is killing me. Seems i'm not alone to have issues with 177.70
[18:25] <ubottu> Launchpad bug 259808 in xorg-server "X Lockup in Intrepid (infinite loop)" [Undecided,Confirmed] https://launchpad.net/bugs/259808
[18:26] <kees> fta: shall I assign you to 263014?
[18:26] <fta> kees, yes please
[18:26] <kees> fta: cool, done
[18:28] <tseliot> fta: can you try with kernel 2.6.26 +177.70 and see if it solves the problem? If it doesn't you should report the problem to NVIDIA
[18:30] <tseliot> actually, either way you should report to nvidia: http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
[18:52] <fta> tseliot, reported to nvidia.
[18:53] <tseliot> fta: great, I hope they fix it before they release the driver as stable
[18:56] <fta> tseliot, could I use 177.68 with 2.6.27-2 ?
[18:57] <tseliot> fta: yes, sure
=== DrKranz is now known as DktrKranz
=== dwatson is now known as davewatson
[21:31] <fta> tseliot, it doesn't make any sense: I tried all variations of kernel 2.6.26-5 / 2.6.27-2 and nvidia 173.14.12 / 177.70, Xorg locks with mplayer/xv (not to mention corrupted consoles, corrupted display, corrupted boot splash, dead keyboard/mouse when gdm is doing autologin) Yet, i only started to see those X locks today with 2.6.27-2 & 177.70.. now it's everywhere. It has to be something else.
[21:34] <leszek> hi
[21:35] <leszek> where can I found the config / python file  where the default filesystem is set by ubiquity / partman !?
[21:36] <leszek> is it in /home/leszek/Downloads/live/edit/usr/lib/ubiquity/ubiquity/components/partman.py !?
[21:38] <leszek> aynone any idea on this partman default system question ?!
[21:48] <leszek> anyone awake !?
[21:51] <jpds> leszek: http://jldugger.livejournal.com/16594.html
[21:52] <leszek> :)
[21:57] <tseliot> fta: can you try with both the "vesa" driver and the "nv" driver? Just to make sure that it's a driver problem and not hardware problem
[22:09] <cjwatson> leszek: it's not configurable, nor is it in python; it's set in shell code in /lib/partman/free_space/50new/do_option
[22:09] <cjwatson> (in several places; it's not particularly designed to be easy to change that right now)
[22:10] <cjwatson> leszek: p.s. don't reask your question three times in a 13-minute interval, please. It's excessive
[22:10] <leszek> sry
[22:11] <leszek> and thx ;)
[22:12] <cjwatson> leszek: although as far as ubiquity's UI is concerned, the default for a new partition is effectively the first in numeric order in /lib/partman/valid_filesystems/, I suppose
[22:12] <cjwatson> that might be easier to customise
[22:15] <leszek> ah ok thx
=== Kmos_ is now known as Kmos
=== Kopfgeldjaeger is now known as Kopfi|offline
=== Kopfi|offline is now known as Kopfgeldjaeger
=== Kopfgeldjaeger is now known as Kopfi|offline