| === Kopfgeldjaeger is now known as Kopfi|offline | ||
| 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:31 |
|---|---|---|
| azeem | "why run them at all?" | 00:32 |
| azeem | was that a serious question? | 00:32 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| azeem | export DEB_BUILD_OPTIONS=nocheck | 00:40 |
| azeem | might help | 00:40 |
| Peaker | thanks | 00:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| kees | (on intrepid) | 00:47 |
| slangasek | not yet | 00:47 |
| kees | but I confirm -- my kern.log is empty. :) | 00:47 |
| kees | but it is getting into my messages file | 00:48 |
| 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:51 |
| kees | slangasek: *sigh* | 00:53 |
| slangasek | ? | 00:53 |
| kees | CFLAGS aren't imported by upstream | 00:53 |
| 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:54 |
| slangasek | we could always fix this bug by replacing sysklogd with rsyslog | 00:55 |
| 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:56 |
| 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:57 |
| 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] | 00:58 | |
| kees | hm, guess not. wtf | 01:01 |
| 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:02 |
| * 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 :) | 01:03 |
| === nxvl_ is now known as nxvl | ||
| kees | slangasek: freaky -- it _is_ calling it with "kernel" as the arg (says the disassembly) | 01:08 |
| 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:12 |
| 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:13 |
| kees | ah-ha | 01:14 |
| slangasek | so, recompiling just klogd.c on hardy fixes it | 01:15 |
| kees | slangasek: yup, -U_FORTIFY_SOURCE only klogd.o fixes it for me too. wtf. | 01:17 |
| Peaker | its taking hours to build the python package, arrg | 01:18 |
| 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:21 |
| Peaker | a bug that has been annoying me for more than a year now, I think | 01:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:28 |
| kees | slangasek: shall I upload it with that fixed? | 01:30 |
| slangasek | just adding -U_FORTIFY_SOURCE for klogd.o? | 01:31 |
| kees | yup. | 01:31 |
| slangasek | yeah, go for it | 01:31 |
| kees | donions | 01:35 |
| slangasek | thanks | 01:35 |
| 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:36 |
| kees | yeah, kind of a twisted source, klogd. :P | 01:38 |
| kees | now if only I could fix firefox to run with fortify_source.... | 01:40 |
| * slangasek grins | 01:40 | |
| wgrant | Aw, who changed "Yes, do as I say" to "I am aware that this is a very bad idea"? | 02:42 |
| NCommander | Morning (or evening) wgrant | 03:53 |
| wgrant | NCommander: Early afternoon, NCommander. | 04:10 |
| NCommander | wgrant, I'm timezone challenged ;-) | 04:11 |
| NCommander | wgrant, can I call on you to sponsor a FTBFS fix? | 04:19 |
| slangasek | wgrant: hmm, in apt-get ? | 04:36 |
| wgrant | slangasek: Yes. | 04:38 |
| slangasek | aww | 04:38 |
| 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:39 |
| * 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:40 |
| Awsoonn | Is there a better place to talk about intrepid? | 04:42 |
| 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:46 |
| Awsoonn | thing that might be usefull to whoever works on that.. bryce maybe? | 04:47 |
| wgrant | That's probably tseliot's domain. | 04:47 |
| * Awsoonn wonders if he's around | 04:48 | |
| NCommander | wgrant, could you reset the build records on postfix on all architectures? Soyuz goofed and marked it failed vs. dep-wait. | 04:56 |
| wgrant | That sounds mainish. | 04:57 |
| wgrant | I'm not a core-dev. | 04:57 |
| NCommander | I thought you were | 04:57 |
| * NCommander hides | 04:57 | |
| 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:00 |
| 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:01 |
| * 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:02 | |
| 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:08 |
| NCommander | hola LucidFox | 05:09 |
| 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:10 |
| 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:11 |
| * 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| * 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:16 |
| 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:17 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| NCommander | ScottK, https://edge.launchpad.net/ubuntu/intrepid/+source/kvkbd/0.5.99-0ubuntu1 - here too | 05:26 |
| NCommander | ugh, your kidding, logwatch is still broken | 05:27 |
| ScottK | NCommander: Done. I'm off to bed. | 05:28 |
| NCommander | Thanks | 05:29 |
| 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:25 |
| 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:26 |
| moquist | ...or I could try to be clever and detect which database has been created...but that seems ridiculously over-complicated and error-prone. | 06:27 |
| === ethan is now known as Eleaf | ||
| moquist | ogra: ping | 06:41 |
| Eleaf | pong | 06:47 |
| slangasek | moquist: you might want to look into wwwconfig-common | 07:38 |
| moquist | this is in main; wwwconfig-common isn't allowed IIRC | 07:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| moquist | ogra might know more details; he got me started | 07:45 |
| 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. | 07:46 |
| === Kopfi|offline is now known as Kopfgeldjaeger | ||
| NCommander | Is there anyone who can retry universe builds for me? | 12:06 |
| NCommander | Riddell, ping? | 12:27 |
| Riddell | hi NCommander | 12:47 |
| 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:48 |
| Riddell | what's that script called for retrying? | 12:50 |
| 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:51 |
| Riddell | NCommander: done | 12:53 |
| NCommander | Riddell, thank you | 12:53 |
| * NCommander hates transient failures | 12:53 | |
| NCommander | RainCT, as an aside, your update maintainer script broke on updating the changelog in intrepid | 12:57 |
| 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:02 |
| NCommander | Just no changelog entry | 13:03 |
| RainCT | NCommander: "and this *manual page* by Siegfried" | 13:03 |
| NCommander | whoops | 13:03 |
| * NCommander slinks away | 13:03 | |
| === ryu2 is now known as ryu | ||
| 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 | 13:05 |
| === _gAri- is now known as gAri- | ||
| === asac_ is now known as asac | ||
| 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:45 |
| Riddell | yay | 13:46 |
| NCommander | Riddell, I'm working on resolving the FTBFS on koffice, which appears to be longstanding | 13:46 |
| * 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:51 | |
| NCommander | Riddell, BTW, where can I file bugs for changes to P-a-s? | 13:57 |
| geser | NCommander: see the comment in P-a-s who to contact | 13:59 |
| 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:01 |
| 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:02 |
| crevette | hello | 14:24 |
| crevette | is a Feature freeze request is necessary for package in universe ? | 14:25 |
| 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 | 14:26 |
| === Pici`__ is now known as Pici | ||
| === bddebian2 is now known as bddebian | ||
| 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:12 |
| asac | tjaalton: doest it mean we have the wrong version of something? | 15:13 |
| jcristau | asac: it means you have incompatible versions of the dri driver and libGL or X | 15:23 |
| asac | jcristau: ok. so why do i get that in intrepid atM? | 15:24 |
| asac | is there an upload pending? | 15:25 |
| 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:27 |
| 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:28 |
| asac | cool | 15:29 |
| asac | at least i had it installed ... which explains it i guess | 15:29 |
| asac | jcristau: no success | 15:39 |
| asac | still the same thing | 15:39 |
| jcristau | asac: something's wrong, then :) | 15:47 |
| 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:53 |
| asac | ok i think i have an idea | 15:56 |
| asac | jcristau: ok i had clutter in /usr/lib/xorg/ | 16:00 |
| asac | thx | 16:00 |
| === _jason is now known as jrib | ||
| === Kopfgeldjaeger is now known as Kopfi|offline | ||
| === Kopfi|offline is now known as Kopfgeldjaeger | ||
| 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:08 |
| fta | kees, we have a patch in upstream bugzilla for a while | 17:09 |
| fta | hold on, let me check | 17:09 |
| 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:10 |
| azeem | glibc's realpath() can deal without MAXPATHLEN, no? | 17:11 |
| 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:12 |
| 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:13 |
| fta | (and also several packages) | 17:14 |
| === ryu2 is now known as ryu | ||
| === Awsoonn_ is now known as Awsonn | ||
| === Awsonn is now known as Awsoonn | ||
| 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:10 |
| kees | fta: and please revert the -U_FORTI... | 18:11 |
| fta | yes | 18:11 |
| * kees hugs fta | 18:12 | |
| fta | :) | 18:15 |
| kees | fta: did you report the "cvs" problem too? I can't find any notes on FORTIFY in "cvs" or "mozilla-devscripts". | 18:16 |
| fta | i didn't, just in the wiki. it seems the problem disappeared since. | 18:17 |
| kees | ah, very good. I will drop it from the wiki for now then. | 18:18 |
| 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:25 |
| kees | fta: shall I assign you to 263014? | 18:26 |
| fta | kees, yes please | 18:26 |
| kees | fta: cool, done | 18:26 |
| 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:28 |
| tseliot | actually, either way you should report to nvidia: http://www.nvnews.net/vbulletin/forumdisplay.php?f=14 | 18:30 |
| fta | tseliot, reported to nvidia. | 18:52 |
| tseliot | fta: great, I hope they fix it before they release the driver as stable | 18:53 |
| fta | tseliot, could I use 177.68 with 2.6.27-2 ? | 18:56 |
| tseliot | fta: yes, sure | 18:57 |
| === DrKranz is now known as DktrKranz | ||
| === dwatson is now known as davewatson | ||
| 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:31 |
| leszek | hi | 21:34 |
| leszek | where can I found the config / python file where the default filesystem is set by ubiquity / partman !? | 21:35 |
| leszek | is it in /home/leszek/Downloads/live/edit/usr/lib/ubiquity/ubiquity/components/partman.py !? | 21:36 |
| leszek | aynone any idea on this partman default system question ?! | 21:38 |
| leszek | anyone awake !? | 21:48 |
| jpds | leszek: http://jldugger.livejournal.com/16594.html | 21:51 |
| leszek | :) | 21:52 |
| 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 | 21:57 |
| 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:09 |
| 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:10 |
| leszek | and thx ;) | 22:11 |
| 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:12 |
| leszek | ah ok thx | 22:15 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!