[19:58] <sistpoty> o/
[19:58] <sebner> huhu sistpoty :D
[19:59] <sistpoty> hi sebner
[20:01] <sistpoty> so welcome everyone
[20:01] <sistpoty> who's around for the practical fix ftbfs session?
[20:01]  * slytherin raises hand
[20:01] <joaopinto> I am until the baby starts crying :P
[20:02] <RainCT> hey sistpoty
[20:03] <sistpoty> ok, so while the last session tried to give a walkthrough, let's get our hands dirty in this one?
[20:03] <sistpoty> I assume you know what FTBFS, BTS and PTS mean?
[20:03] <sistpoty> anyone who doesn't?
[20:03] <joaopinto> I don't know about BTS and PTS, bug tracking system, package tracking system ?
[20:04] <sistpoty> exactly
[20:04] <hggdh> BTS == Bug Tracking System indeed
[20:04] <hggdh> PTS -- IDK
[20:04] <sistpoty> so our worklist is still http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909-karmic.html
[20:05] <sistpoty> every package there has a link to BTS and PTS, where a fix might already be in a) a newer version or b) sitting in a bug at debian
[20:05] <sistpoty> of course looking at launchpad bugs page for a package also is a good idea
[20:05] <sistpoty> afaik, the list is updated every 2 hours, and uploaded packages are marked as superseeded
[20:06] <sistpoty> so everyone grab a package please, and tell which one you'll start working on
[20:06] <RainCT> hggdh: PTS = Package Tracking System = http://packages.qa.debian.org/common/index.html
[20:06] <joaopinto> I am getting checkinstall
[20:07]  * sistpoty randomly grabs nstx
[20:07] <slytherin> I have already filed three sync request, but they did not get processed. Should I bug archive admins?
[20:08]  * fabrice_sp grabs contacts
[20:08] <sistpoty> slytherin: depends how long these were in the queue... if these weren't handled during the last batch of syncs, then asking might make sense
[20:08] <slytherin> they have been there for last two days
[20:09] <fabrice_sp> what is the frequency of the batch of sync?
[20:09] <sistpoty> slytherin: iirc there wasn't a batch yet, so patience :)
[20:09] <sistpoty> fabrice_sp: no idea to be honest. I assume it depends on the workload of archive admins
[20:09] <fabrice_sp> ok :-)
[20:09] <slytherin> Ok. Iwill keep filing bugs.
[20:09] <sistpoty> so as everyone got a package now, start fixing it :)
[20:10]  * RainCT takes aegis
[20:10] <sistpoty> if there's anything you have no clue how to fix it, ask :)
[20:11] <sistpoty> ideally with a pasted log of the build error (the lines of the error suffice) and snippet of the code pasted
[20:11] <sistpoty> so then we can all look and try to find out how to solve the issue
[20:11] <sistpoty> and if anyone is done and can't upload himself, there should be many sponsors here :)
[20:12] <hggdh> syspoty, please see http://pastebin.ubuntu.com/289481/ (nice, i386). What is the error here? Missing build-depends for jikes?
[20:13] <hggdh> systpoty ^
[20:13] <sistpoty> hggdh: looks more to me that jikes-classpath -> jikes cannot be satisfied
[20:14] <sistpoty> hggdh: are you on i386?
[20:14] <hggdh> no, amd64
[20:14] <sistpoty> hggdh: oh
[20:14] <sistpoty> hggdh: otherwise you could have tried to manually install build-dependencies
[20:14] <slytherin> sistpoty: hggdh: jikes is removed form archives. Grab the version of nice from Debian and see if it builds. Should be a simple sync.
[20:15] <sistpoty> hggdh: of course you could use a linux32 chroot (/me tries to recall the command to create one)
[20:15] <hggdh> slytherin: from unstable?
[20:15]  * fabrice_sp feels lucky: contacts only misses a build-dependency :-)
[20:16] <slytherin> hggdh: yes
[20:16] <hggdh> k
[20:17] <joaopinto> installwatch fails to build due a scandir64 header mismatch
[20:18] <sistpoty> joaopinto: need help or can you fix it?
[20:18] <hggdh> jikes on Debian unstable is only for m68k
[20:19] <slytherin> hggdh: I meant grab version of nice from Debian.
[20:19] <joaopinto> I guess i just need to copy the new function definition from dirent.h
[20:19] <hggdh> heh. Sorry
[20:20] <sistpoty> hggdh: I'm quite clueless about java packages, but maybe there's a different -classpath to build-depend on?
[20:21] <slytherin> sistpoty: I already gave him solution.
[20:21] <sistpoty> :)
[20:22] <slytherin> for problems with java packages, ping me
[20:22] <hggdh> slytherin, sistpoty: unstable nice does not (build) depends on jike anymore.
[20:23] <slytherin> hggdh: make sure it builds in karmic chroot and then use requestsync to file sync bug, attach the build log, Iwill mark the bug confirmed.
[20:23] <hggdh> roger
[20:24] <maco> -chat not in use
[20:24] <maco> ?
[20:24]  * slytherin is checking 'checkstyle' FTBFS
[20:25] <sistpoty> maco: the session was announced only 2 hours, is there a conflicting schedule?
[20:25] <sistpoty> 2 hours ago even
[20:25] <maco> sistpoty: no i was confused to see > 1 person talking in here and nobody talking in -chat
[20:26] <sistpoty> ah, well, it's an interactive session :)
[20:26] <fabrice_sp> sistpoty is a champion organising meetings :-D
[20:26] <sistpoty> haha
[20:27] <slytherin> why is elisa source still in archives?
[20:28] <RainCT> slytherin: packages.ubuntu.com shows python-elisa being build from it
[20:29] <slytherin> that's weird, I thought everything was build from moovida now.
[20:30] <slytherin> wow we have three source packages starting with name feisty. I guess they should be removed now.
[20:32] <joaopinto> ok, checkinstall builds, but I have changed directly the source
[20:32] <joaopinto> time to do a runtime test
[20:32] <joaopinto> Patch 15fix-kfreebsd.diff does not remove cleanly (refresh it or enforce with -f)
[20:32] <joaopinto> grrrrrrrrrrrrr
[20:33] <hggdh> slytherin: I do not have a chroot available right now, so I submitted nice to my PPA
[20:33] <joaopinto> I should have debclean first
[20:34] <slytherin> hggdh: if it is too much trouble for you I will check and file sync bug
[20:35] <hggdh> slytherin: no prob. I will wait for the PPA build to complete, and then open a sync req
[20:35] <slytherin> ok
[20:36] <hggdh> dammit. forgot to specify where the dput was going to :-(. Ah well, it will be refused, anyway
[20:37] <maco> joaopinto: pbuilder is probably a cleaner way to test the build
[20:37] <fabrice_sp_> contacts uploaded
[20:37]  * fabrice_sp_ is looking for another sexy pacakge
[20:37] <joaopinto> right now I am puzzled with the existing patchs versus my patch
[20:38] <RainCT> sistpoty: http://paste.ubuntu.com/289506/ does that make sense?
[20:39] <joaopinto> maco, I prefer chroots :P
[20:40] <sistpoty> RainCT: is needle/haystack fumbled upon later? if not, it'd be better to declare haystack/needle as unsigned const char*
[20:40]  * fabrice_sp_ is looking at comedilib
[20:40] <maco> joaopinto: oh ok i thought you were doing just on the system without a chroot at all (though pbuilder is just an automated chroot, i think)
[20:40] <joaopinto> arch, quilt, I do I add a new patch with quilt ?
[20:40] <joaopinto> brb, 20 minutes, baby bath
[20:41] <fabrice_sp_> joaopinto, you mean how?
[20:41] <fabrice_sp_> ok
[20:41] <slytherin> checkstyle has too many build-dep, download takes lot of time. moving on to other packages.
[20:41] <sistpoty> RainCT: if the contents are changed later, it makes sense. (though the slightly more readable way is needle=const_cast<unsigne char *>(haystack_start);)
[20:41] <sistpoty> (applying for c++)
[20:42] <RainCT> sistpoty: does haystack++ qualify as "fumbled upon"?
[20:43] <sistpoty> RainCT: no... *haytack=... would imply that
[20:43] <sistpoty> *haystack =
[20:43] <sistpoty> even though fumbled upon is a vague term, I admit :P
[20:47] <RainCT> sistpoty: well, the problem is it complains because of "memchr(haystack, *needle, haystack_len)", which I see at http://www.cplusplus.com/reference/clibrary/cstring/memchr/ is overloaded for both "const void*" and "void*"
[20:48] <RainCT> so dunno why it complains, maybe because it's doing "return memchr(..)" and the function is defined as returning "void *"?
[20:49] <RainCT> or because of the second arugment being const?
[20:50] <sistpoty> RainCT: can you paste the entire function?
[20:50] <joaopinto> fabrice_sp, yes, sorry, I meant, how
[20:50] <slytherin> sync requested for libgnu-regexp-java
[20:51] <fabrice_sp> joaopinto, quilt new <patch name> to create the patch
[20:51] <joaopinto> grr, a glibc change and quilt was not a goood choice :P
[20:51] <fabrice_sp> quilt add zfile> to add a file to the patch
[20:51] <fabrice_sp> lol
[20:51] <RainCT> seems to be the later
[20:51] <RainCT> ah no, it failed :P
[20:52] <joaopinto> fabrice_sp, do i need to care in which stage of the build I am ? like debclean first ?
[20:53] <RainCT> grr, I should fix cowbuilder on my laptop, compiling on the netbook is awful :P
[20:53] <fabrice_sp> joaopinto, better have a clean env before patching
[20:53] <RainCT> sistpoty: http://paste.debian.net/48656
[20:54] <joaopinto> well, a proper fix for this wold require a GLIBC version check, but let it just build
[20:55] <slytherin> sync requested for libgnujmi-java
[20:55] <sistpoty> RainCT: ah, it's an extern "C" function. That's a very interesting construct, because it sees the c++ definition
[20:56] <sistpoty> RainCT: so the fix is in line 32 of your past
[20:56] <sistpoty> RainCT: return (void *)memchr(haystack, *needle, haystack_len);
[20:57] <joaopinto> I need to read a quilt howto
[20:57] <RainCT> sistpoty: ah! ok, thanks
[20:58] <RainCT> joaopinto: https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt%20%28example%20package:%20xterm%29 :)
[20:58] <sistpoty> joaopinto: in short: export QUILT_PATCHES=debian/patches
[20:58] <sistpoty> joaopinto: quilt push -a
[20:58] <sistpoty> joaopinto: quilt new <name_of_your_patch>
[20:58] <sistpoty> joaopinto: quilt shell (then edit all files of interest, exit subshell)
[20:58] <sistpoty> joaopinto: quilt refresh
[20:58] <sistpoty> joaopinto: quilt pop -a
[20:59] <joaopinto> ok, let me add that to my notes
[20:59] <joaopinto> tks
[20:59] <RainCT> Oh, nice. So that annoying "quilt add .. # and if you forget it you're screwed" isn't needed?? and I didn't know until now???? :P
[21:01] <sistpoty> RainCT: /me overheard it in -motu recently ;)
[21:01] <fabrice_sp> I've just discovered quilt shell :-/
[21:02] <fabrice_sp> hmmm, comedilib is not  a so nice choice (problems with regenerating configure script :-/ )
[21:02] <joaopinto> janito@janito-desktop:/tmp/quilt-mU0V5M$ quilt refresh
[21:02] <joaopinto> Nothing in patch 20glibc2.10-scanw.diff
[21:03] <joaopinto> is this the expected output from refresh ?
[21:03] <RainCT> no
[21:03] <slytherin> joaopinto: you need to exit the shell first then do refresh
[21:03] <joaopinto> oh, ops, forgot to exit :P
[21:04] <slytherin> filed sync request for libpicocontainer-java
[21:05] <sistpoty> slytherin: I believe you're a robot with your ftbfs-fixing speed :P
[21:06] <slytherin> I think I am done. Filed quite a few sync requests which were easy to verify. Others are difficult because of the download required (and it is 1:30 am here)
[21:06] <slytherin> I will continue tomorrow
[21:07] <sistpoty> thanks a lot slytherin!
[21:07] <slytherin> you are welcome.
[21:13] <funkyHat> Ok I'm looking at the pygobject ftbfs, because it looked quite simple to fix, but the script missing is confusing me
[21:13] <funkyHat> I'm pretty sure I just need to bump the versions of automake and autoconf it's looking for
[21:14] <fabrice_sp> the error "The important program mcopidl was not found!" should be fixed by adding --without-arts to configure script, no?
[21:14] <sistpoty> fabrice_sp: afict, yes
[21:14] <slytherin> hggdh: are you done with nice build?
[21:14] <sistpoty> funkyHat: does it run autotools during build? or just the configure?
[21:15] <sistpoty> funkyHat: if the latter, I assume you could try to regenerate the autotools as a patch
[21:15] <fabrice_sp> sistpoty, if it does not work, what else can I try ? (log: http://pastebin.ubuntu.com/289531/)
[21:15]  * funkyHat feels stupid. How would I do that?
[21:16] <sistpoty> funkyHat: run autoreconf -i in the top-src-directory (assuming you have build-depends installed)
[21:17] <sistpoty> fabrice_sp: have you tried to run configure --help manually?
[21:17] <sistpoty> fabrice_sp: maybe it's --disable-arts
[21:17] <fabrice_sp> ohhh, right
[21:17] <sistpoty> fabrice_sp: others than that, I guess the solution is found in configure.ac (or configure.in whichever exists)
[21:18] <fabrice_sp> ok. Will check both.
[21:18] <fabrice_sp> thansk ;-)
[21:18] <sistpoty> thanks for trying to fix it :)
[21:18] <funkyHat> I have done quilt push -a first,  this is right isn't it?
[21:19] <sistpoty> funkyHat: and have QUILT_PATCHES set? then yes
[21:20] <funkyHat> Yes I set that too :)
[21:20] <sistpoty> funkyHat: then quilt shell
[21:20] <sistpoty> funkyHat: autoreconf -i
[21:20] <sistpoty> funkyHat: cross fingers :P
[21:21] <funkyHat> ah, quilt shell, I didn't do that -.-
[21:21] <funkyHat> can I do quilt add . ?
[21:21] <sistpoty> funkyHat: no idea really, have discovered how quilt works myself only recently. maybe someone else knows?
[21:22] <sistpoty> <- back in 5 minutes
[21:22] <funkyHat> I'll start again, not like I've done anything complicated
[21:22] <slytherin> hggdh: I am done with nice build. I will file sync request if you are not doing it.
[21:22] <sebner> funkyHat: . might work too or you use quilt add *  :)
[21:23] <funkyHat> sebner: ah, yeah * may have worked, too late!
[21:23] <sebner> heh
[21:24] <funkyHat> oh, I just did quilt shell before creating a new patch. bah!
[21:28] <slytherin> hggdh: done. filed sync request for nice.
[21:33] <joaopinto> W: checkinstall source: package-uses-deprecated-debhelper-compat-version 4
[21:33] <joaopinto> should I fix this ?
[21:33] <joaopinto> or i should simply introduce furhter differences to the Debian package ?
[21:34] <joaopinto> erm, avoid introducing
[21:34] <funkyHat> Ok, the patch quilt has generated is 50k lines long... so I'm missing something :D
[21:34] <sistpoty> joaopinto: at feature freeze, try to keep the changes to a minimum, so don't fix lintian warnings
[21:35] <joaopinto> ok, added a 2 lines patch , it builds, next, changelog ?
[21:35] <sistpoty> joaopinto: yep
[21:35] <sistpoty> funkyHat: that's quite usual for running autotools
[21:35] <joaopinto> checkinstall (1.6.1-8ubuntu1) karmic; urgency=low
[21:35] <joaopinto> looks good ?
[21:35] <sistpoty> yes
[21:36] <sistpoty> but add some content :)
[21:36] <funkyHat> http://ubuntu.pastebin.com/m6816d943 is the list of files that quilt adds when I exit the shell
[21:37]  * fabrice_sp uploaded cyclades-serial-client
[21:38] <sistpoty> funkyHat: you can drop config.h.in~ (backup file)
[21:38] <sistpoty> funkyHat: but all others are expected
[21:38] <sistpoty> funkyHat: eventually you can drop the files in autom4te.cache (not too sure though)
[21:39] <funkyHat> Is there a simple way to do that with quilt?
[21:39] <funkyHat> Oh, remove :)
[21:39] <joaopinto> sistpoty, http://pastebin.com/m666b289f <- looks good ?
[21:40] <sistpoty> joaopinto: maybe describe what it does? (as in change foobar to fix FTBFS)?
[21:40] <joaopinto> ok
[21:41] <joaopinto> grrr, brb
[21:41] <fabrice_sp> anybody have an idea about "channel.c:3437: error: format not a string literal and no format arguments"
[21:41] <sistpoty> fabrice_sp: generally yes, but not without the context
[21:41] <fabrice_sp> line is "sendto_local_ops_flag(UMODE_SERVNOTICE, get_str(STR_SPLIT_MODE_OFF));"
[21:41] <fabrice_sp> sorry
[21:41] <fabrice_sp> I'll pastebin the source
[21:42] <sistpoty> fabrice_sp: which package is this? source of the function might not give what I'm looking for (definition of UMODE_SERVNOTICE, definition of senddto_local_ops_flag)
[21:43] <fabrice_sp> dancer-ircd
[21:43]  * sistpoty looks
[21:45] <fabrice_sp> it seems to be because of the get_str call
[21:46] <funkyHat> sistpoty: so is the massive patch going to cause problems (assuming, of course what I've done actually fixes it)?
[21:47] <sistpoty> funkyHat: nope, it's just rerunning autotools ;)
[21:47] <funkyHat> Ok :), just seems a bit weird putting such a huge patch in debian/patches
[21:48] <sistpoty> fabrice_sp: that's just done really, really ugly from what I've seen :(
[21:48] <fabrice_sp> :-/
[21:48] <sistpoty> fabrice_sp: in src/numeric.c, you can see the string definitions for get_str
[21:48] <funkyHat> Could I run autoreconf -i in debian/rules instead?
[21:49] <sistpoty> fabrice_sp: if these don't have any format character in them, you can use sendto_local_ops_flag(UMODE_SERVNOTICE, "%s", get_str(STR_SPLIT_MODE_OFF));
[21:49] <sistpoty> fabrice_sp: which in this case is the right thing, but I'm sure there are other occurances as well
[21:49] <sistpoty> funkyHat: then you'd need to build-depend on automake
[21:49] <fabrice_sp> sistpoty, ok. I'll check the content of the string
[21:50] <sistpoty> fabrice_sp: for this case, it should work... just seen it ;)
[21:50] <fabrice_sp> cool :-D
[21:50] <funkyHat> Well, I'll wait and see if this even compiles to begin with :)
[21:58] <joaopinto> sistpoty, Added patches/20glibc2.10-scandir required to build with glibc2.10
[21:58] <sistpoty> \o/
[21:58] <joaopinto> the line on changelog
[21:59] <joaopinto> erm, my apt-cacher-ng is broken
[22:01] <funkyHat> This is the new build log, after running autoreconf -i http://pastebin.com/f462d33dd -- still pretty broken
[22:01] <joaopinto> well, it will build, what's the next step ?
[22:04] <funkyHat> What's actually causing the build to fail?
[22:04] <sistpoty> joaopinto: upload it (or paste the debdiff somewhere, then I'll upload it)
[22:06] <joaopinto> where can I upload it to ?
[22:06]  * fabrice_sp is tired. Will continue tomorrow morning
[22:06] <fabrice_sp> bye
[22:07] <sistpoty> joaopinto: if you're a motu straight to the archive
[22:07] <joaopinto> ok, I am not, next option :P
[22:07] <sistpoty> joaopinto: otherwise either paste the debdiff somewhere or attach it to a bug ;)
[22:07] <joaopinto> ok, let me check the initial page, is there an LP bug listed there ?
[22:08] <joaopinto> uff, debdiff, I need to check how to generate that
[22:09] <joaopinto> ok, that one is easy
[22:09] <joaopinto> hum, something is wrong, the patch is not shown on the debdiff, only the changelog change
[22:10] <joaopinto> brb
[22:13] <sistpoty> funkyHat: defsgen.py is listed twice to installe somewhere (question is where though)
[22:14] <funkyHat> Oh, it was just that line that was the problem, for some reason I thought that didn't look important enough
[22:14] <funkyHat> it's twice in codegen/Makefile.{am,im} - which one of those generates the other?
[22:14] <funkyHat> *in
[22:15] <funkyHat> Ah, it tells me :)
[22:15] <sistpoty> funkyHat: Makefile.am generates .in if autotools are run. Usually Makefile.in is shipped by upstream and used as in the builds (which then generates the Makefile by the configure run)
[22:15] <sistpoty> funkyHat: so if there's no build-dependency on automake you'll need to patch both
[22:17] <funkyHat> So I should correct Makefile.am and then re-run autoreconf -i, and then update my patch in quilt
[22:19] <sistpoty> funkyHat: probably simpler is to directly patch Makefile.am/Makefile.in, but whatever you prefer
[22:23] <funkyHat> True :)
[22:23] <funkyHat> Was good practise using quilt though ;)
[22:30] <funkyHat> aha! It built
[22:31] <funkyHat> Now, is there anything obvious I can do to test it before I submit my debdiff?
[22:31] <funkyHat> (pygobject)
[22:33] <sistpoty> funkyHat: also submit it to debian or upstream ;)
[22:33] <sistpoty> funkyHat: but others than that, no
[22:36] <funkyHat> Should I just submit the quilt patch I created?
[22:36] <funkyHat> Don't know if they'll like it, as it's rather huge
[22:37] <sistpoty> funkyHat: ideally just the diff of Makefile.am (and eventually a Makefile.in)
[22:37] <sistpoty> funkyHat: the rest should be recreatable by running autotools, right?
[22:38] <funkyHat> Right :)
[22:40] <joaopinto> sistpoty, any ideas why the new patch would not show up on debdiff ?
[22:42] <sistpoty> joaopinto: not too sure actually... did you eventually overwrite the old source package (calling debuild prior to adding a changelog entry?)
[22:42] <joaopinto> hum, that could be
[22:43] <joaopinto> let me get the original diff
[22:45] <joaopinto> sistpoty, it was that, next time i need to add the changelog entry first to be safe
[22:45] <sistpoty> joaopinto: yes, that's what I'm usually doing as first step ;)
[22:46] <sistpoty> (even if I just write "fix things" in it to make sure to get a new version)
[22:46] <joaopinto> is there a bug associated with the FTBFS event ?
[22:46] <joaopinto> I mean at LP
[22:47] <sistpoty> joaopinto: not for universe
[22:47] <joaopinto> :(
[22:47] <joaopinto> where should I attach the debdiff to ?
[22:48] <sistpoty> joaopinto: unless someone filed one by hand of course
[22:48] <sistpoty> joaopinto: file a new one ;)
[22:48] <joaopinto> ok
[22:48] <funkyHat> Where can I find debian FTBFS? I don't see this bug reported at b.d.o
[22:49] <sistpoty> funkyHat: there isn't really a list. however installing a file twice is certainly a bug
[22:49] <joaopinto> erm, let me do a runtime test first
[22:50] <funkyHat> sistpoty: right, so I'll just file a bug for that the
[22:50] <funkyHat> *then
[22:50] <sistpoty> yes
[22:52] <funkyHat> sistpoty: ah, debian are on a more recent version of the package than we are...
[22:52] <funkyHat> I should have checked that, shouldn't I?
[22:52] <sistpoty> funkyHat: yes, always check that first ;)
[22:53] <funkyHat> wheee
[22:53] <funkyHat> Right
[22:55]  * sistpoty files a sync request for nufw
[22:56] <sistpoty> ok, as it's getting more and more quiet in here, let's move to #ubuntu-motu, shall we?
[22:56]  * funkyHat moves
[22:57] <sistpoty> btw.: all the questions you have asked here are very much ontopic for #ubuntu-motu as well :)