[01:41] Blargh. Why is kde-icons-oxygen (some 48MB) suffering from KDE-stick-everything-in-one-huge-sourcepackage-itis? It was bad enough as it was without the new stuff being thrown in too! [02:40] I am the king of FTBFS! [02:41] Everything I've recently touched has failed on at least one architecture. [03:11] Hola all [03:14] NCommander: Why hello there :) [03:14] Did you know ngnix FTBFS on sparc now? :) [03:14] * NCommander is stiff and sore, and still doing FTBFS [03:14] RAOF, Yup, I saw that -_-; [03:15] RAOF, its a different file then any of the ones I patched [03:15] Yeah, I know. [03:15] I'd debug it if I had access to a SPARCstation, but it looks like its a general toolchain error ... [03:15] It's dying in the assembler, it seems [03:15] Right. [03:15] RAOF, Got a sparc I can SSH into? [03:16] Not personally. Ubuntuwire might, though... [03:16] I don't have access to a sparc debian porting machine or I'd simply create a chroot jail [03:16] NCommander: siretart or sistpoty do. [03:17] REVU runs on a sparc. [03:17] RAOF, probably what happened is this package is was built for sparc ages ago, and now with intrepids toolchain FTFBS [03:17] *FTBFS [03:20] I don't know if this is the correct place to ask but I do believe that my computer has been spammed. I have photographs of men with guns and various middle east images that are being found and displayed by a screensaver program. This is very upsetting for me. [03:20] How do I find the location of the images and get rid of them? And how do I find out you they got on my computer? [03:22] RAOF, BTW, a question, at what point should I apply for contributing developer? (I know I should apply for MOTU when people tell me to do but I'm not so clean on contrib-dev) [03:23] NCommander: I don't really know. I don't really know what the point of the contrib-dev team is; you don't (currently) get any extra priviledges or responsibilities from it. [03:24] The week says you can do debian sync/merges ... [03:24] RAOF: You get the privildges of being an Ubuntu member, slight as those are without having to wait in some other long line for it. [03:25] ScottK-laptop: True; you do get an @ubuntu.com address, I suppose. [03:25] * NCommander looks at the DD process [03:25] Yup [03:26] RAOF, care to review YAFTBFS fix ;-) [03:26] I'll just get some more coffee, then OK. [03:27] and if I have posted to the incorrect channel, then i am open to suggestions about the best channel to address this [03:27] thanks [03:27] You need a HTCTP-enabled coffee pot [03:28] anteaya: #ubuntu is the right channel for support requests. [03:28] NCommander: NTCTP? [03:28] RAOF, Hypyertext Transfer Coffee Protocol [03:28] Hold on [03:29] HTCPCP (HyperText Coffe Pot Control Protocol) [03:29] http://www.ietf.org/rfc/rfc2324.txt [03:30] Eh. That protocol doesn't map cleanly to my plunger. [03:30] Well, kettle/grinder/plunger combination. [03:31] RAOF: thanks i haven't found anyone that seems to care that I have images of people with guns on my computer [03:31] I want a coffee maker that runs NetBSD and implemented HTCPCP :-) [03:31] that appear to have come with the install [03:31] or through an approved package [03:31] but thanks [03:32] anteaya: Why do you think they came through an approved package? [03:33] anteaya: #ubuntu for support, btw. [03:33] ScottK-laptop: the install is about a week old [03:33] clean drive [03:33] hardy only [03:34] i haven't had time to compile anything [03:34] packages only [03:34] No third party repositories? [03:34] looking [03:34] now i did install cinelerra [03:34] * NCommander checks the glibc version on intrepid [03:35] and that may have been third party [03:36] RAOF, seems like a good number of FTBFS are caused by glibc 2.8 [03:36] Yay! [03:36] Toolchain fun! [03:36] sorry and medibuntu [03:36] anteaya: No cinelerra in the official repositories. [03:36] okay [03:36] and medibuntu? [03:36] anteaya: Not official. [03:36] okay [03:36] Dunno. [03:36] okay thanks [03:36] i will look there [03:36] very upsetting [03:36] RAOF, I isolated that it causes wide-dhcpv6 to obiterate itself [03:37] anteaya: You need to be more careful about what you install and where you get it from. That's my advice. [03:37] I don't need to monkey around with the toolchain tonight, I"m already too tired -_-; [03:38] ScottK-laptop: I appreciate that [03:38] wow, newlib is NOT happy on amd64 [03:42] RAOF, (<< 2.8~) - That means a version less than 2.8, right? [03:47] Yes. [03:48] *grumbles* THis package requires glibc greater then 2.7 but less then 2.8 [03:48] Presumably >= 2.7, right? [03:48] Anyway, FTBFS sponsoring? [03:48] ah yes [03:49] RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/transproxy/+bug/247886 [03:49] Launchpad bug 247886 in transproxy "FTBFS fix on AMD64/SPARC/IA-64" [Undecided,New] [03:49] Just one that I did this morning before starting my day [03:50] Nice work. Lintian+copyright+FTBFS :) [03:50] Not completely sure I did the copyright right [03:50] First time I ever did it with a BSD three-clause package [03:50] I just cat LICENSE >> debian/copyright [03:51] IIRC BSD is in /usr/share/common-licenses so you should refer to it and not repeat it. [03:51] ScottK, I didn't see the three-clause one there [03:51] Just the old four clause [03:51] * ScottK-laptop looks [03:52] Then again, I did this at 8 in the mroning [03:52] I may have missed it [03:52] The one on my Hardy system is 3 clause. [03:52] /usr/share/common-licenses/BSD appears to be the 3 clause to me. [03:52] * ScottK-laptop high fives RAOF. [03:52] ScottK, In addition, he modified the BSD license to explicately list his companies name [03:53] (in the endorse/promote product derived section) [03:53] In that case it's not BSD license anymore. [03:53] Which is why BSD license sucks. [03:53] MIT works much better. [03:53] meh [03:53] I haven't dealt with licenses since I was an Savannah FSF admin [03:54] ANd I probably should have known better then to touch copyright at 8AM in the morning ;-) [03:54] In this day and age it's essential we get it right. [03:54] Even though it's painful. [03:54] Yeah, I realize, it looked like BSD three-clause and it met DFSG from my IANAL perspective [03:55] The old copyright file said it used GPL, not hat it currently uses [03:55] Slight difference there. [03:55] Yeah, just a bit ;-) [03:56] WHoever packaged it was damn lazy [03:56] no compat file, warnings from debhelper tools, and lintian was angry [03:56] Two errors and a ****load of warnings [03:56] it was nice to brush the rust off my packaging karma by fixing lintian warnings [03:57] ;-) [03:57] I think that your debdiff was created from an unclean source; it includes substvars and debhelper.log, etc. [03:57] damn it [03:58] Sorry [03:58] I'm still getting used to using debdiff [03:58] That's fine. [03:58] Ugh, the apt-rpm documentation is bugged real nice [04:00] I think I see the error with the doctype ;-) === ScottK-laptop is now known as ScottK2 [04:03] * ScottK2 declares his man page sufficient and moves on. [04:04] ScottK2, are you a core developer? [04:04] Yes. [04:05] * ScottK2 cringes. [04:05] ScottK2, would you like to review my patch for the libnet-ssleay-perl package? [04:05] Sure. What bug? [04:05] I think it's even my fault that's in Main. [04:06] https://bugs.edge.launchpad.net/ubuntu/+source/libnet-ssleay-perl/+bug/247698 [04:06] It's a FTBFS [04:06] NCommander: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/247698/+text) [04:06] o_o; [04:07] It turns out I didn't get that one promoted, but I'll look at it. [04:07] promoted? [04:07] To main, from Universe. [04:08] Its in main ... [04:08] Oh dear lord. That's the first time I've used edge since the changed it. [04:08] But once, it was in universe. [04:08] Did I ever mention I think Launchpad U/I is getting worse? [04:08] It is. [04:08] I personally like the updated look [04:08] I think I like the big tabs up the top. [04:09] It just feels laggy [04:09] But edge was always like that for me [04:09] Launchpad is always laggy. [04:09] * NCommander just found the oTBFS [04:09] Yay for round-trips to .uk [04:09] Someone forgot to add lzma to the build-deps [04:12] Or that's just the start ... [04:12] NCommander: Is this the one that builds in Debian because they don't run the test suite? [04:12] ScottK2, I'm of a similar opinion [04:12] RAOF: You've got amd64, right? [04:12] Yup. [04:12] RAOF: Would you be willing to do a test build on libnet-ssleay-perl? [04:12] ScottK2, yeah [04:12] ScottK2: Certainly. [04:12] Thanks. [04:13] I'm currently playing email tag with four people on the Debian perl group [04:13] ScottK2: You have a trustworthy face; want ssh access instead? [04:13] NCommander: Did you report a bug? [04:13] Who are trying to reproduce, and can't [04:13] RAOF: No. [04:13] Ok. [04:13] ScottK2, Yeah. I'm going to see if I can reproduce on my debian sid box when I get home [04:14] RAOF: It's much more convenient for me to not have access to any 64bit boxen and just ask for help if I need it. [04:14] newlib's rules are weird [04:14] Heh. Lazy ScottK2 :) [04:14] Overcommitted. [04:14] Right. [04:14] Overcommited? [04:15] To much to do. [04:16] * ScottK2 is currently trying to arrange to resovle Bug #247332 [04:16] Launchpad bug 247332 in postfix "Please add a script to allow filter services to be programatically added to master.cf" [Wishlist,In progress] https://launchpad.net/bugs/247332 [04:16] With that, I think I can get apt-get install some-meta-package and have spam and a/v filtering all integrated with Postfix. [04:17] Well, newlib is FTBFS because its unpack stamp isn't being called ... [04:20] and it appears it internally chooses not to build on anything but powerpc ... [04:20] NCommander: Am I reading your debdiff wrong or do you have both a patch and the same changes inline in the code? [04:21] NCommander: Personally, I prefer debian/changelog to be a little more verbose so that when the next person comes along to do a merge on the package they can understand both why and what was done. [04:21] It's one consequence of team maintaining. We really need to document changes well. [04:21] ScottK, Let me upload a fixed version [04:21] Thanks. Ping me when it's uploaded. [04:23] Ok, I fixed it, but I just want to check to make sure this works 100% proprely on i386 [04:28] ScottK2, + * Fixed FTBFS on 64-bit architectures by changing printf %d to %ld [04:28] + so a long pointer can be printed out. [04:28] How's that for an explained changelog? [04:28] Great. [04:28] This was the first FTBFS I ever did for ubuntu [04:28] It's nice to know I totally screwed it up ;-) [04:28] NCommander: No. You figured out the problem and how to fix it. That's not screwing up. [04:29] and yeah, I forgot to run debian/rules clean before running debdiff the first time around [04:29] ScottK2, obviously debian and ubuntu use different source packages for screwup ;-) [04:29] * NCommander runs from the bad pun [04:29] Uploading now [04:29] er wait [04:30] * ScottK2 borrows Hobbsee's LongPointyStick and attaches the pun to NCommander even at a great distance. [04:30] * NCommander runs lintian [04:30] man-page-has-errors-from-man [04:32] If the fix is trival, I'll fix that too [04:32] Great. [04:32] More Debian bugs to file ... [04:33] I'll take care of that ;-) [04:34] I'm big on making sure relevant Ubuntu changes get pushed back to Debian. [04:34] If we don't work at it, entropy will turn Ubuntu into a fork in time and that would be bad for both distros. [04:35] * cody-somerville has started to do the same. [04:35] Excellent. [04:36] yeah, I'm fixing lintian bugs as I find them with FTBFS :-) [04:37] weird error [04:37] I'll take one final stab fixing it ... [04:38] ScottK2, it appears to be a bug in pod2man >.<; [04:39] I'm not willing to loose half of my life chasing down that evil bug (IANA perl hacker) [04:40] OK. Let's get the FTBFS and move on, but please at least file the bug against pod2man. [04:40] 1189 open bugs against Launchapd, but they have time to redesign the bug page using a random number generator. [04:41] Patch filed [04:41] I'm rerunning the final debdiff against pbuilder (the old one built ok, but I'm just rechecking for $SANITY sake) [04:41] * ScottK2 looks [04:42] But, of course, Launchpad is slow. [04:42] ScottK2, I also checked it on i386, the change to printf doesn't effect it there at all [04:42] OK. [04:42] RAOF: Did you get a chance to build it? [04:43] ScottK2: Oh, I was waiting for someone to give me a url. You want the archive version, or what? [04:43] RAOF, https://bugs.edge.launchpad.net/ubuntu/+source/libnet-ssleay-perl/+bug/247698 [04:43] Launchpad bug 247698 in libnet-ssleay-perl "FTBFS on AMD64/IA-64 due to printf error" [Undecided,In progress] [04:43] If you want, I'll upload the source package somewhere for you [04:44] That'd be nice. Is it easy for you? [04:44] That or just use patch on the curren Intrepid package. [04:45] the only machine I could upload and get something APT would understand isn't running, unless I post to REVU, but it isn't meant for this [04:45] Yeah, that'll be faster. [04:45] (Me applying the debdiff) [04:45] I was just being lazy. [04:46] Man, a non-lazy [04:46] wow [04:46] Whoops [04:46] Be careful what you type before you push enter ;-) [04:47] * RAOF updates his intrepid sbuild first. [04:47] so while we wait [04:47] Any requests for me to look at FTBFS, or merges, etc? [04:48] Lovely. Need to go into my Intrepid chroot just to make the source package thanks to debhelper 7. [04:48] sorry to make you work [04:51] No problem. I appreciate your contributing. [04:52] I'm working on the f-spot FTBFS [04:52] You didn't make it debhelper 7. [04:52] I didn't what? [04:52] You aren't the one that made it into a debhelper 7 package (that's the one that's giving me extra work right now). [04:52] Oh [04:53] I thought I forgot to add a build-dep [04:55] * NCommander appears to have a fix for f-spot [04:55] Just needed to twiddle the build-deps [04:56] That's one I'm not going to feel comfortable with sponsoring. [04:57] I just had to add libjpeg62-dev [04:58] NCommander: That doesn't segfault in mcs on AMD64, does it? :) [04:58] f-spot never segfautled on amd64 [04:58] It failed a configure test ... [04:59] er ... wait [04:59] ... [04:59] Damn it [04:59] I built it with the patch that broke evolution-sharp removed [04:59] NCommander: You also neglected to put the bug closing magic in your debian/changelog (I added it). [04:59] ScottK, I opened the bug after I made the debdiff ;-) [04:59] Just as Debian uses (Closes: #nnnnnn), Ubuntu uses (LP: #nnnnnn). [05:00] NCommander: Not after you made the last debdiff. [05:00] ScottK2, no, I know that. [05:00] Whoops >.<; [05:00] OK. Just making sure. [05:01] NCommander: When you did your i386 test build, how did you do it? [05:01] RAOF, Yeah, so, I built f-spot without it segfaulting on me; it did complain of missing modules though when it appeared to run its test suite [05:01] NCommander: It FTBFS in my Intrepid pbuilder. [05:01] ScottK, i386 chroot jail [05:01] Hold on [05:02] Let me install pbuilder in the i386 chroot and rerun [05:03] Hm. How long should libnet-ssleay take to build? [05:03] http://paste.ubuntu.com/27000/ [05:03] Not very long. [05:03] RAOF, not long, but the test suite will fail if localhost isn't properly setup [05:03] ScottK, ooh, thats pretty [05:03] Hold on [05:04] I know the specific problem and how to fix (thanks for the good catch, and this teachs me to rerun pbuilder in both chroots) [05:07] ScottK2, do you know the preprocessor macro for 64-bit archs? [05:07] Nope. [05:08] * ScottK2 looks over at RAOF since he knows a lot about 64bit stuff. [05:09] You mean something that's defined on all 64bit archs, but not on 32bit archs? [05:09] #if (__SIZE_TYPE__ == unsigned long) [05:09] THat should work, right? [05:09] RAOF, Yeah [05:09] Uuurgh. [05:09] That fails on win64 [05:10] Fine [05:10] And possibly other 64bit archs, I don't know. [05:10] || defined(__WIN64) [05:10] :-) [05:10] It's true for linux-ELF-x86-64 [05:10] It's also true for ia64 [05:11] I'll check for __lp64__, or the size_type [05:11] Why do you need to, incidentally? [05:12] THe test checks to see if a pointer can be cast to unsigned long and back [05:12] But why? [05:13] I dunno, I didn't check to see where the test is used in SSLeay [05:13] ScottK2: libnet-ssleay builds on AMD64 [05:13] OK. So now he needs to figure one that will build on both. [05:13] Thanks. [05:13] http://pastebin.ca/1070584 I think that will work [05:14] (I need to change the comment to be more specific, but code-wise) [05:15] * RAOF doesn't know why pastebin.ca hates him so much. [05:16] http://paste.ubuntu.com/27002/ [05:16] * NCommander changes that to __lp64__ [05:17] NCommander: Isn't there a "print a pointer" printf specifier? [05:17] Wouldn't that fix this without #if's? [05:18] * NCommander peeks in the manpage [05:18] I didn't see one, but I probably missed it [05:19] Yeah, I don't see it [05:19] It isn't %p? [05:20] The void * pointer argument is printed in hexadecimal [05:20] The problem is its printing out the value of sizeof() [05:20] On 32 bit archs, sizeof returns uint [05:20] on 64, its ulong [05:20] I think it returns size_t, actually. [05:21] ok [05:21] size_t is different on 32 archs, and 64 then unless I am mistaken [05:22] %z appears to be the size_t specifier (http://www.gnu.org/software/libc/manual/html_node/Integer-Conversions.html) [05:22] * NCommander tries it [05:23] RAOF, I love you long time if it works ;-) [05:23] Hey, all sorts of fun there: %t is the specifier for a ptrdiff_t :) [05:23] Nope [05:23] No love [05:23] * NCommander tries %t [05:26] RAOF, it seems GCC doesn't recongize %t [05:28] Maybe you need to pass -c99? [05:29] -std=c99, perhaps. [05:29] C99: providing all sorts of shiny you can't acutally use. [05:30] Hehe [05:30] You probably want -std=gnu99 instead of -std=c99, i think. (Didn’t read the discussion, though.) [05:31] The flags we're after are C99 standard; they shouldn't require the gnu extensions, right? [05:33] ScottK-laptop: thanks for the help earlier, the images were in the miro icon-cache [05:33] * NCommander grumbles [05:33] And where did you get miro from? [05:33] I really don't want to mess with the make system [05:34] NCommander: Then try passing CC="gcc -std=c99" in rules? [05:36] ScottK-laptop: checking repos i think [05:37] RAOF, it's ignoring CC="gcc -std=c99" [05:37] Does it ignore CFLAGS? [05:37] CHecking [05:37] ScottK-laptop: i do believe it is in the offical repos [05:38] Hmmm. [05:38] RAOF, it's using quilt to call make if it makes a difference [05:38] (there is no call to $(MAKE) [05:38] I know miro is in the official repos. The question is, is that where you got it? [05:38] ScottK2: yes [05:39] And even if it is from the official repos, it will download things from the internet; that's it's whole purpose. [05:39] ScottK2: i can confirm with a dpkg command right? [05:39] * NCommander hits his head on the desk [05:39] Right. [05:39] RAOF: Does it keep good logs? [05:39] ScottK2: Dunno, never really cared. [05:40] ~/.miro/miro-log shouldn't be too bad. [05:41] anteaya: ^^^ [05:42] http://pastebin.com/m59c0b447 [05:43] That's the entire log? [05:43] yes [05:43] i don't use it much [05:43] i haven't ever used it for screencasts or anything [05:43] What's likely happened is that miro has downloaded some channel icons/splash-screens to ~/.miro/icon-cache, and you have something trawling ~ for images. [05:43] What was the actual problem you had, again? [05:43] just to watch downloads when the other codecs don't work [05:44] images of people with guns playing on my slideshow screensaver [05:44] i don't know where the images had come from so i didn't know if i was being attacked or not [05:45] RAOF, some googling tells me I should check LP64 on all 64-bit compilers (and memory tells me I think thats defined on Win64 too) [05:48] That's probably OK, then. [05:48] Passes build on AMD64 [05:48] Running pbuilder on amd64, and then will run pbuilder on i386 and submit [05:49] ScottK2, do you want anything else once I confirm it works on i386 and amd64 pbuilders? [05:49] thanks for the help [05:49] Add the LP foo if you're doing it over. [05:49] * NCommander adds foo [05:53] That's was a deceptively anonying package to fix, but learned much, I ahve [05:54] Is the new debdiff on the bug now? [05:54] No [05:54] I'm having some pbuilder issues ... [05:55] The source package isn't being rebuilt with the updated patch ... [05:57] RAOF, thank you for your help :-) [05:57] :) [05:57] I now owe you one, since this was more intense then the mono bug [05:58] ok, passes pbuilder on amd64, still waiting for i386 to finish [06:00] if my internet connection wasn't as slow as **** [06:00] squid is love. [06:00] I don't have any of the i386 packages so its downloading [06:00] Ah, right. [06:01] This was fun to fix ^_^ [06:02] * NCommander can hear ScottK groaning from here [06:03] RAOF, are you a core dev? [06:03] Builds on i386 :-) [06:03] Neyope. [06:04] ScottK2, patch is now on launchpad [06:04] OK [06:04] And .... launchpad's skin just changed again o_o; [06:04] RAOF: Would you please build it again for me? [06:05] Yeah. Strange LP. [06:05] ScottK2, I apologize for having given you a nice headache so late at night [06:05] * NCommander wishes launchpad was open [06:05] The reason they give for not opening the code is weak at best [06:05] * ScottK2 would settle for fast and had a good U/I. [06:05] Yes. [06:05] * NCommander is a former gforge maintainer [06:05] * NCommander is was an FSF Savannah maintainer [06:06] The former had features out the wazoo, but a pain to run [06:06] THe later was a little feature light, but much easier to run; I even got it running acceptably on my NSLU2 (233Mhz ARM/32MB of RAM) [06:06] The bigger problem though is that even though most LP developers come from a FOSS heritige, the closed nature of the project makes them closed to community input. [06:07] I personally think Launchpad slaughters Sourceforge in terms of usability [06:07] and its on par with GForge [06:07] I don't think I've really seen GForge. [06:07] Unless your building packages to work with debian/ubuntu [06:08] Well, Canonical has pledged to open launchpad [06:08] But TBH, I can't understand how it could take "years" [06:08] Unless Canonical had another company write it, or they bought it [06:09] ScottK2: Builds fine on AMD64. [06:09] RAOF: Thanks. [06:13] ScottK2, does that mean this patch will see the light of day? [06:14] NCommander: if it builds for me too on i386, yes. [06:14] The Debian Perl guys could not reproduce, so I don't see the patch moving upstream unless the same issue bites Debian [06:21] NCommander: Uploaded. Thank you for your contribution to Ubuntu. [06:21] * NCommander strikes victory pose [06:22] Wait until it builds on the buildd's. [06:22] is there a page I can see that status (the qa page is only updated once daily) [06:23] Yes. I'll give you the link in a moment. [06:23] One advantage of Main uploads is they go first on the buildd's so less waiting. [06:24] On my buildds for m68k [06:24] I have a tweak that causes my debian packages to always take prefernce ^_^ [06:25] Speaking of contribing [06:26] I'm considering requesting Ubuntu Contributing Developer (I'd like an @ubuntu.com email so I can get my packages in Ubuntu to have bug reports go straight to me, and not through MOTU), but I think I'm too new to request it [06:27]