[00:00] * NCommander usually uses dpatch [00:00] NCommander: I really don't care. I use what's there, or what the Maintainer likes, or what whoever is reviewing a new package on Mentors likes. [00:01] * persia is likely the least good person to ask about patch system preferences, having only one strong opinion: it doesn't make sense to have a patch system and changes outside debian/ in diff.gz. [00:01] ah [00:01] That bugs the crap out of me [00:01] I think its against policy now [00:05] It ought be, if it's not. I don't mind if someone does just diff.gz patches (although it's nicer when they have a VCS), but mixing is just evil. [00:06] persia, its usually older ones that aren't [00:06] But there is virtually no oversight with DD package submissions [00:06] That's why we have REVU: helps get team review of everything. While there is the occasional package that misses REVU, most things have at least two sets of eyes, and sometimes four or five before they get uploaded. [00:08] Because no MOTU can directly upload to incoming, right? [00:08] Well, anyone can, but anyone who does is likely to have someone else ask them about it. [00:09] Questions like "Who did the second ACK for that?" or "Why didn't you put it on REVU?". Nobody likes trying to come up with an answer, so we just use REVU. [00:10] REVU logs all the uploads and comments to a public list, so it's easy to audit against -changes mail. [00:10] Cool [00:10] I actually think debian should adopt that system [00:10] But man, people would go apeshit if anyone every suggested it [00:11] NCommander: Debian uses mentors.debian.net [00:11] There was some talk about it, both the REVU code and the process. Last I knew it was stalled. [00:11] I have NEVER seen a DD use that [00:11] NCommander: if a DD don't use it is a problem, but mentors exists [00:11] I've seen DDs in collaborative teams upload to VCS and ask for comments before uploading, which is at least an example of good process. [00:12] There just isn't any oversight [00:12] But the DD process is so rigid, it weeds out a lot of .... lesser developers [00:13] So my changes will go on REVU, and then intro intrepid? [00:13] NCommander: Maybe. It tries. Personally, I find agressive peer review of most changes to be almost as good in terms of patch quality. [00:13] Nope. Your changes go to the sponsors queue, where a second person looks at them, and uploads. [00:13] MOTU upload patches like that directly. [00:14] The changes are then posted, and as all the packages are team-maintained, we all have an interest in fixing any broken uploads (no NMU barrier). [00:14] * NCommander looks forward to some of his FTBFS fixes going [00:14] This is the third one today (not counting the giveback) [00:15] persia: no maintainer in ubuntu is a great thing, in Debian I see a lot of package not updated because the maintainer is away [00:15] * NCommander is guility of that >.>; [00:16] devfil: Yes, but no Maintainer in Debian is a bad thing: Ubuntu relies on the Debian maintainers to develop good relationships with upstream. We do in some special cases (like you with WX), but in most cases, we're too busy chasing all the little bugs to concentrate properly on each package. [00:16] What I never get is how some packages seem to be not buildable on normal linux systems [00:16] And usually require one or two big patches [00:17] NCommander: Different envionment used upstream (e.g. Solaris). [00:17] I mean with Debian packages [00:17] Yes, as do I. [00:17] i.e., nginx [00:17] It requires IOV_MAX to be defined [00:17] But its not defined on Linux [00:17] I thought nginx upstream used Mac OS X. [00:17] I fixed it by aliasing it to the equivelent preprocessor macro (UIO_MAXIOV) [00:17] But the package is in debian stable [00:18] and it built on unstable without such a fix [00:18] I don't get it ... [00:18] Check the m68k logs? [00:18] maybe-successful [00:19] It always bugs me [00:19] Oh, hrm [00:20] very weird [00:21] hrm, oh I see [00:22] YOu need to define __need_IOV_MAX it appears to get it [00:22] Must be a change in glibc [00:23] do any of you run intrepid directly? [00:24] NCommander, I run Intrepid directly [00:24] Many of us, and those that don't have intrepid chroots for testing. [00:24] I'm running the chroot [00:24] I ran into issues when I ran gutsy directly [00:30] * NCommander uploads nginx [00:32] * NCommander reviews the list of FTBFS again [00:34] * NCommander waits patiently for one patch to just reach revu ;-) [00:35] REVU? On what are you waiting? [00:36] You said that someone will likely put the updated package files to REVU for review ... [00:37] No. NEW package go to review. Current packages get reviewed by the sponsors. Other people watch -changes, and complain if there is a bad upload. (well, some people both sponsor and watch changes, but...) [00:38] ack [00:38] Err. NEW packages go to REVU. Other packages get reviewed. [00:38] * NCommander hides under his desk for being an idiot :-) [00:38] * persia gets confused by homonyms again [00:38] ... [00:38] Five diet cokes [00:38] I think I can kiss sleep goodnight [00:39] So, instead, I'm waiting for one of my packages to get reviewed, and someone to smite me and tell me to try again ;-) [00:43] I'm going home, see you all laptop [00:43] ...; [00:43] later [00:44] NCommander, cya :) [00:46] persia: why did you delete last line of the wiki? [00:46] persia: to much attention for you? [00:46] :p [00:48] persia: looking at /srv/uploads/rejected, maybe a keying sync would be adequate (together with moving the .changes files back to /srv/uploads)? [00:48] ;) [00:55] cody-somerville: oh, sorry, I just finished going through the key-teams thread, and I doubt I'll have a summary before going to sleep [00:55] sistpoty, How far away is that? [00:56] cody-somerville: quite a bit... I just finished pasting any significant bit (and reading through it) [00:56] I meant, how far away is going to sleep? [00:57] cody-somerville: actually going to sleep is in the next half hour [00:57] cody-somerville: but as I haven't really structured plain comments yet, I don't think I'll be able to this during that timeframe [00:58] Okay. [00:58] Do you want to aim for gobbying it tomorrow? [00:59] cody-somerville: I'll try... but actually I'm not certain I'll do it [00:59] cody-somerville: bad thing is, that I'll be mostly afk from somewhen tomorrow afternoon to sunday evening (utc+2 pov) [00:59] (we have 10 year class meeting this weekend) [01:01] cody-somerville: not too sure how best to proceed actually... if you come up with s.th., I guess it might be better to just sent it to -motu... [01:01] (sorry again) [01:02] ok [01:14] * sistpoty goes to bed now... cya [01:23] sistpoty: is revu server re-sync again? [01:30] What are SRU bugs? [01:33] NCommander, SRU stands for "Stable Release Updates". You can find more information regarding SRUs at https://wiki.ubuntu.com/StableReleaseUpdates [01:36] REVU hasn't synced [01:37] cody-somerville, Thank you :-) [01:38] NCommander, np [01:38] cody-somerville, I just migrated from Debian to Ubuntu, and spent most of the afternoon fixing FTBFS ;-) [01:38] NCommander, Awesome :) [01:38] NCommander, did you push your changes upstream where appropriate? [01:39] I filled bug reports with Debian if that's what you mean [01:39] * cody-somerville nods,. [01:39] I got a rather angry email saying not to bug him about FTBFS's on Ubuntu :-/ [01:40] I'd just want to get some review on my debdiffs [01:40] Some Maintainers are like that, although most are happy to adopt. In many cases, it also FTBFS in Debian (always good to check), which can help get them adopted. [01:40] I'm fairly sure I did it all right === SoylentGrun is now known as gaurdro [01:53] Can I simply debootstrap an i386 chroot on aamd64 system, or do I need to do something stupid? [01:55] NCommander: You can debootstrap both i386 and lpia on amd64 [01:55] What is lpia? [01:56] Low Power Intel architecture. It's a low-power memory-limited i686 with no VMX, etc. [01:56] Google tells me its the libertarian party of iowa, but I don't think thats right ;-) [01:56] That sounds like the Asus EEE and friends [01:56] (aka Intel Atom based machines) [01:57] Chips that it runs on today are Intel A100, Intel A110, and Intel Atom. For userspace, it's not really that different than i386. The kernel is a little different. [01:57] Well, most Eee s are actually VIA C7-M, which is a i586 based chip, and can't boot an lpia kernel. [01:57] i586? [01:57] Ew. [01:58] I'm suprised [01:58] There's a few i586s out there still. Probably some i486s too, although I'm not sure Ubuntu supports those. [01:59] I know we don't support real i386s (and never have). [01:59] I think Ubuntu compiled targetting i386 like Debian [01:59] Oh [01:59] Hrm [01:59] No clue then [01:59] No, even in the beginning it was i486. Anyway, I don't think lenny will run on a real i386 without some significant tinkering. [01:59] Which leads into the next question, what specifically is a softfreeze? [02:01] During a soft freeze, we avoid uploading anything that ends up on one of the images for the test. For this freeze, it's Ubuntu, Kubuntu, Xubuntu, Edubuntu, and Ubuntu Server. Ubuntu Studio, Ubuntu Mobile, and Mythbuntu aren't participating in the Alpha for one reason or another. [02:01] So that means things like FTFBS fixes aren't going to move? [02:15] NCommander: Only for things that end up on the CDs. The Freeze ought be ending soon anyway. [02:15] The CDs is just main, or main and select universe? [02:16] select main and select universe. [02:16] ah [02:20] Can I cast a pointer on a i686/32-bit as unsigned long? [02:20] (that's the fix for this package on amd64, but I don't want to then cause a FTBFS on i686 ;-)) [02:20] I believe so. [02:21] Anyway, we don't have i686, just i586 and lpia, neither of which is quite an i686. [02:21] Close enough ;-) [02:26] NCommander: If you're going to do pointer arithmetic, intptr_t is the winning type. [02:26] intptr_t? [02:27] It's an int which is guaranteed to be big enough to hold a pointer. [02:27] Should I just use that inplace of the cast for unsigned long? [02:27] Presumably you need a bit more than just an unsigned long cast, though? [02:28] You need to actually change the destination type? [02:28] Or were they doing something strange like "unsigned long ptr = (int)the_pointer;"? [02:30] Of course, casting to unsigned long isn't portable; that will definately fail on win64, for example. [02:30] neither is intptr_t [02:31] intptr_t should be supported by any C89 (C99?) compiler. [02:31] Well, it was doing just a unsigned int cross [02:31] C99 I'd think. [02:31] and it works for me now [02:33] hello people [02:33] Howdie. [02:35] ROAF: thanks for that hint, it works great :-) [02:36] Care to work out why mcs segfaults while compiling evolution-sharp on AMD64 in a clean chroot for me, then? :) [02:37] ROAF: If you can work on reviewing my FTBFS fixes ;-) [02:42] oh yeah, motu meeting [02:45] Hobbsee: ? :) [02:45] * Hobbsee forgot about it, but wasn't here anyway [02:45] Who is emma? [02:46] you don't want to know [02:47] either way, she can come and lurk now [02:47] emgent: we've had a fair bit of trouble with her in userland. [02:49] hmm? As in being obnoxious, or..? [02:51] crimsun: yeah, mainly. prattling on about how irseek is so evil, because it's in the channel, ignoring ithe calls that she's offtopic, arguing for hours any time she gets told off or banned, and kept advertising her channel to users. [02:52] whihc, oddly enough, people were reporting as abuse. [02:53] she caused enough trouble to get an #*ubuntu*-wide channel ban. [02:54] argh [02:54] I need to make xserver-xgl build again. In order to do this, I need to include the mesa source somewhere. The .orig.tar.gz would be more appropriate than in the .diff, right? [02:55] Oh, crap. That'd mean I'd need to include the appropriate copyright stuff. Urgh. [02:55] emgent: so, she's partially reformed. She still sticks random stuff in channels, like ':)', and doesn't contribute terribly useful, and still argues for hours when she gets told off, though. But it seems there's progress, so she can lurk. [02:55] s/useful/usefully/ [02:56] understand :) [02:57] Hobbsee: hmm, if this is the same 'emma', I'll have a face-to-face chat, or have someone speak to her. [02:58] we're all in the same city [02:58] oh, interesting. could have used your help a couple of months ago [02:58] RAOF, what was that package you wanted me to check on? [02:59] NCommander: evolution-sharp. That wasn't serious, though I'd _love_ you to find out the reason. [02:59] Hobbsee: heh, I'm kinda scarce these days, so I'm not useful. :) [02:59] It's awkward and annoying, and probably a mono bug. [02:59] RAOF, are you a MOTU by any chance? [02:59] Yah. [03:01] RAOF, if I fix it, will you review my pending FTBFS fixes ;-) [03:01] Absolutely. How many of them? [03:01] 4 or 5 [03:01] I lost count ;-) [03:01] I didn't have anything to do this afternoon ... [03:02] I'll certainly look at them if you fix evolution-sharp :) [03:02] Building GCC on m68k is a slow process [03:02] Heh. [03:02] I'll possibly look at them anyway, but after breakfast :) [03:02] RAOF, 7-10 days on average for m68k [03:02] The error I see evolution-data-server is too new O_o? [03:03] NCommander: You're looking at the wrong packages, then. You're after evolution-sharp 0.17.4-0ubuntu1 [03:03] Where mcs segfaults on amd64 only. [03:03] the buildload on qa.ubuntuwire.com is old then [03:03] * NCommander looks on amd64 [03:03] link to your buildlog? [03:05] It was on launchpad, but apparently it's being rebuilt? [03:05] What's happening there? [03:05] Where on launchpad [03:05] (I use the qa page) [03:05] (but it seems to sometimes lag on newer packages) [03:05] *grumbles* it did successfully build on unstable [03:06] launchpad.net/ubuntu/+source/evolution-sharp [03:06] No, I don't think it did; they have 0.17.1. [03:06] I don't see failure logs [03:06] It's quite possible that the same package _will_ build on unstable, though... [03:06] NCommander: Yeah. For some reason it's getting rebuilt. [03:06] Wait a couple of minutes, and it'll fail. [03:07] https://edge.launchpad.net/ubuntu/+source/evolution-sharp/0.17.4-0ubuntu1/+build/666561 [03:07] There we go! [03:07] oooh [03:07] What a misirble failure [03:09] RAOF, what's your timezone? [03:09] GMT+10 [03:10] Moar pancakes! [03:10] gief [03:10] heh [03:10] -5 GMT here [03:11] :%s/GMT/UTC/g [03:13] Hm. It seems something's filing automated FTBFS bugs, but not doing it correctly. [03:13] I posit the recently-reopened: https://bugs.edge.launchpad.net/ubuntu/+source/evolution-sharp/+bug/194456 as a symptom. [03:13] Launchpad bug 194456 in evolution-sharp "FTBFS in latest archive rebuild test" [High,Confirmed] [03:20] RAOF: when was that closed? [03:20] In Hardy, methinks. [03:21] Or, rather, it wasn't visible when I checked the bugs yesterday. [03:21] Which, I assume, means it was closed. I belive that hardy's evolution-sharp did build from source. [03:21] ROAF: Any idea what's causing this FTFBS? [03:21] activity log doesn't show it being closed. [03:22] Oooh, never noticed that button. [03:22] yeah, i remember seeing a uvfe for it, and approving it - but i wouldn't bet that bug got closed as well [03:22] Hm. I wonder what happened, then. [03:22] I really wasn't visible yesterday! [03:22] UVFE? [03:22] NCommander: No, I really dont' have any good ideas. [03:22] NCommander: upstream version freeze exception [03:23] What have you tried? [03:26] * NCommander is right now thinking connecting gdb to mcs is the easiest way to find where the bug is [03:29] I've tried that, but mono is not very amenable to gdb. [03:30] It should at least show you where the SIGSERV is though o_O; [03:30] I've got a core file if you'd like to check :) [03:35] That would be handy [03:35] I'm reading tips on using GDB with mono [03:37] RAOF, I'm probably going to guess a pointer is getting mutated somewhere [03:37] Just suprising its only happening on amd64 [03:37] Right. [03:38] Also surprising: only happens in a clean chroot. I can build it just fine in my Intrepid install. [03:38] My chroot isn't clean [03:38] (I have some cruft in it) [03:39] and it still SIGSERVed [03:39] SERV? [03:40] NCommander: http://cooperteam.net/core [03:40] *SIGSEGV [03:40] This backtrace is real pretty [03:41] But it looks like its tripping a bug in pthreads .... [03:41] pthread_cond_wait@@GLIBC_2.3.2 [03:41] WTF? [03:41] That's not necessarily where it died, though. [03:41] That could just be where some non-segfaulting thread was when mono died, right? [03:42] It's always dying in the same place [03:42] EVen after running it a bunch of times [03:42] Sometime makes a thread, and bing, diad [03:42] *dead [03:42] I just don't get why its @@GLIBC_2.3.2 [03:43] libc6-dbg gets me symbols, right? [03:43] Yeah. Or libc6-dbgsym. Doesn't really matter which. [03:46] At least there is a mon-dbg package [03:50] well, installing symbols makes a lot more interesting debug data [03:53] RAOF, it's a memcpy() call that's triggering the code to go boom [03:54] Hm. Another data point: that package builds just fine in sid. [03:54] It might be time to start looking at ubuntu-applied mono patches. [03:55] I'm trying to localize where in the native code its oblierating itself [03:55] maybe its worth building mono sans patchs and see if this builds [03:56] Quite possibly. [03:57] Argh [03:57] I can't see what the arguements are to memcpy [03:57] :( [03:57] What's the command to make it load symbols for a library [03:57] (I haven't used GDB in awhile) [04:03] What. The. ****. [04:03] It just built [04:03] I cd'ed into evolution and typed make [04:03] and [04:03] ... it built [04:03] Yeah, it does that. [04:03] wtf O_O; [04:03] Sometimes it builds, sometimes it doesn't. [04:04] Although it seems to _always_ fail in automated environments. [04:04] this is pissing me off [04:04] Sounds like a *shiver* thread locking issue [04:04] It always builds if I cd into the evolution folder [04:05] Maybe it's a path thing? [04:05] Maybe [04:05] I'm tweaking the rules file to figure it out [04:05] Because I found strange things happening running the compile command manually. [04:06] mcs generated/*.cs dies, mcs <...> generated/Addresswhatever.cs died, cp generated/Addresswhatever.cs .; mcs <...> Addresswhatever.cs didn't segfault. [04:06] man [04:06] It's really not happy [04:06] Yeah. [04:07] There's some sort of madness happening. [04:07] Hm. Maybe it's the length of the command line? [04:07] The max command line on Linux is 128kb [04:07] Does mono amd64 know about that? :) [04:08] Hrm [04:08] Maybe it just randomly managed to build on Debian [04:08] A random fluke [04:09] I don't think so. [04:09] The Debian version is older it seems [04:09] according to the changelog [04:09] Oh, it is. But I'm building the new package in a sid chroot. [04:10] If that doesn't fail [04:10] It doesn't. [04:10] THen it's either an issue with the evolution API or our mono [04:10] **** [04:10] Any ideas? [04:10] Oooh, that's a fair point; we have a different evolution API, too. [04:11] If it was real time code that was dying this would be easier [04:11] I'm going to install some Sid mono packages in an Intrepid chroot, see if that flies. [04:11] But this is the equivelent debugging GCC [04:14] I'm currently running --trace on mcs [04:14] Seeing if I can catch where the compiler bombs [04:17] RAOF, the bug doesn't occcur when mcs is in ttrace mode [04:19] RAOF, and the freaking trace log is 2.1GB O_O; [04:20] RAOF, ping [04:23] NCommander: :( [04:23] Builds fine with sid's mcs. [04:24] d'oh [04:24] At least we ruled out the evolution API [04:24] Right. [04:24] and tells us the problem is specifically with mcs [04:24] Now we play the patch elimiation game [04:24] Yeah. [04:25] Want to check out my FTFBS fixes as a break, I'll work on seeing if I can figure out what patch is doing it [04:25] Win. [04:25] They're in the u-u-s queue? [04:26] u-u-s? [04:26] Ubuntu universe sponsors [04:26] I added them to the universe queue [04:26] Expect for the one which was a main package [04:26] Right. [04:26] should be [04:26] mcurs, purelibc, and ngix [04:27] er [04:27] nginx [04:27] RAOF, I also submitted a fix for libnet-ssleay-perl, but I don't think your a core developer [04:27] True. [04:27] (and we're in a soft freeze) [04:28] All that experience as a debian-porter is paying off [04:28] (pity its not paying off on my way to be a DD, but eh) [04:29] Hm. Those fixes should really be attached to the bug as debdiffs. [04:29] Unless it's also a new upstream version? [04:30] I uploaded the debdiffs O_o; [04:30] You uploaded the .diff.gz [04:31] Which isn't quite the same; a debdiff (generated by debdiff, oddly enough ;)) is generally a nice, small, reviewable patch against the existing package. [04:31] Whoops [04:31] I can fix that >.<; [04:31] I never generated those before, when someone said debdiff, I thought they meant the diff file autogenerated [04:32] !debdiff [04:32] Sorry, I don't know anything about debdiff [04:32] Oooh, that's a bit of an oversight :) [04:32] yeah [04:32] Whoops === foxbuntu is now known as fatman [04:33] Let me generate those debdiffs [04:34] I apologize [04:34] No problem at all. [04:35] I'm getting weird output fron debdiff === fatman is now known as foxbuntu [04:36] oh wait [04:36] THat's right [04:39] RAOF, I'm generating them now [04:42] RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/dmucs/+bug/247767 [04:42] Launchpad bug 247767 in dmucs "For for FTFBS on 64-bit architectures" [Undecided,New] [04:44] RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/nginx/+bug/247745 [04:44] Launchpad bug 247745 in nginx "Fix for FTBFS on i386/amd64 and other archs" [Undecided,New] [04:48] * NCommander feels like an idiot over the debdiff thing >.< [04:53] RAOF, ? [04:56] ick [04:57] I think I found the patch that broke the camels back [04:59] NCommander: i believe RAOF was reffering to the lack of a "debdiff" factoid in ubottu as the oversight, not what you are working on :) [04:59] heya nxvl :) [04:59] I uploaded the actual diff.gz filees >.<; [04:59] So Now I properly uploaded real debdiffs [04:59] no sweat :) [05:00] I feel like an idiot though [05:00] excellent [05:00] Why? [05:00] whoa! no need to feel that way [05:00] WHat, I'm from Debian [05:00] I'm assuming the usual pose someone should take when they screw up and the sponsor attacks you :-P [05:01] haha [05:01] you won't get attacked here [05:01] But I think I found the issue with evolution-sharp [05:01] Someone commented out an entire function so mono would work on a liveCD [05:01] in one of the patchs [05:02] I think this was RAOF's plan, get me to work on evolution-sharp and he can run away in horror :-P [05:03] vorian, care to check my now fixed debdiffs ;-) [05:03] dmucs? [05:04] yeah, purelibc, nginx, and libnet-ssleay-perl (which I don't think you can check) [05:04] ^as well [05:04] sure [05:04] I got busy ;-) [05:04] THanks [05:04] It's amazing seeing my patches go somewhere [05:05] I'm now interested in beginning the MOTU process [05:05] NCommander: I'm back, and I'll pick off whatever vorian doesn't get to. [05:05] And I don't have to go get my key signed :-P (drove 500 miles to get it done) [05:05] RAOF, I think I found the problem [05:05] i'm looking at dmucs === gaurdro is now known as GPL [05:06]