[07:48] <dholbach> good morning
[07:48] <iulian> G'morning dholbach.
[07:50] <dholbach> hey iulian
[08:09]  * Laney gnaws on Rhonda
[08:09] <Laney> can you make p.u.c know about saucy pretty please? :-)
[08:09] <Laney> well, it knows about saucy - know about saucy's packages/contents ...
[08:11] <Rhonda> I think I got the right motivation to investigate further on sunday.
[08:11] <Rhonda> Actually I have no clue what's going on but am fully aware of the issue, have received a fair amount of legit mail about it already
[08:12] <Laney> oh, cool!
[08:12] <Laney> ok then sorry for generating further noise :P
[08:12] <Laney> I'll provide you with suitable beverages at debconf to make up for all the traffic ;-)
[08:13] <Rhonda> \o/
[08:16] <Laney> (I just got a bug report where someone wrongly concluded that a 'broken' (actually not) changelog was breaking p.u.c)
[09:09] <Rhonda> It's the changelog's fault !!!1!!!dwarfs!!
[09:10] <Laney> if only it were that simple eh
[10:19] <Laney> RAOF: you left #debian-cli? Anyway, was wondering if you could poke at the gnome-do* FTBFS in unstable? https://bugs.launchpad.net/do/+bug/1097712/
[10:20] <RAOF> Sure, sometime over the weekend.
[10:20] <Laney> that bug has a patch anyhow
[10:20] <Laney> great
[15:17] <alo21> hi... I can't merge cbmc package, due to patch problem
[15:20] <alo21> I got: patching file src/ansi-c/c_preprocess.cpp
[15:20] <alo21> Hunk #1 FAILED at 590.
[15:20] <alo21> 1 out of 1 hunk FAILED
[15:20] <alo21> dpkg-source: info: fuzz is not allowed when applying patches
[15:20] <alo21> dpkg-source: info: if patch 'armhf-preprocessing' is correctly applied by quilt, use 'quilt refresh' to update it
[15:21] <alo21> dpkg-source: error: LC_ALL=C patc
[15:21] <alo21> I run quit-refresh and I got: Nothing in patch minisat-debian
[15:23] <alo21> and I can't build the package.. why=
[15:23] <alo21> ?*
[15:24] <rbasak> alo21: try "quilt pop armhf-preprocessing" to go back to that patch, then "quilt refresh" on there, then "quilt push -a" to push them all back again?
[15:26] <alo21> rbasak, 'pop armhf-preprocessing' says the patch is not applied
[15:26] <rbasak> alo21: oh but hold on - you don't have fuzz, you have a rejection. I think you'll need to examine the patch and fix it up manually.
[15:27] <alo21> rbasak, how? what fuzz mean...
[15:27] <alo21> the patch seems to be ok
[15:29] <alo21> rbasak, I have just weird (i think) line on the third line 'Forwarded: no'
[15:29] <rbasak> alo21: fuzz is when the patch context didn't exactly match, but patch was able to guess and apply it anyway. It says "1 out of 1 hunk FAILED" so it looks like the patch doesn't apply at all though.
[15:29] <rbasak> alo21: you should be able to run "patch --dry-run -p1 < debian/patches/armhf-preprocessing" without errors.
[15:32] <alo21> rbasak, it tells me 'reversed patch detected'
[15:32] <alo21> assume -R?
[15:32] <rbasak> alo21: perhaps the patch has been adpoted by Debian, so you need to drop it? I check manually in these cases.
[15:33] <alo21> rbasak, the patch has been created for Ubuntu only
[15:34] <rbasak> alo21: that doesn't mean that Debian or upstream can't take it.
[15:35] <rbasak> alo21: you need to check manually why the patch doesn't apply.
[15:35] <paultag> Forwarded: no patches are almost always troublesome - if anything it should be not-needed or similar
[15:37] <alo21> rbasak, debian didn't apply the patch, because that part of file changed
[15:38] <rbasak> alo21: OK, so you need to decide if the patch is still needed in Ubuntu. If it is, then you need to fix it up. If it can be dropped, then drop it and note the reason in the changelog.
[15:38] <alo21> rbasak, that means that I have to drop that patch.. right?
[15:38] <alo21> ou...ok
[15:38] <rbasak> Whether or not you can drop the patch depends on the original reason for the patch. Try to avoid a regression.
[15:57] <alo21> rbasak, I solved that problem, but during the building I got: wmm/goto2graph.cpp:935:20: error: 'current_po' may be used uninitialized in this function [-Werror=maybe-uninitialized]  goto_programt* current_po;
[15:59] <rbasak> alo21: I'm not really sure how to help you further here. Fixing this kind of issue involves needing a more in-depth knowledge of the specific problem you're getting.
[15:59] <alo21> rbasak, c++ programming too?
[16:00] <alo21> rbasak, does that error means that the variable is unused?
[16:00] <rbasak> alo21: right. Here it looks like the build system forces warnings to be errors. But that suggests that in Debian it does work OK. Perhaps try a Debian chroot to see if it's the Ubuntu toolchain.
[16:01] <rbasak> Or perhaps one of the other patches introduces that.
[16:02] <alo21> rbasak, it's weird, because the previous devel wrote in changelog: 'cbmc (4.2-6ubuntu1) raring; urgency=low * Don't fail on unused-result warnings.'
[16:20] <rbasak> alo21: perhaps he patched it previously?
[16:20] <alo21> rbasak, it what?