=== JackyAlcine is now known as [Jacky] === [Jacky] is now known as JackyAlcine [01:52] infinity: any idea why my armhf failures seem to automatically get retried? [03:14] hi there, anyone how the ubuntu-core been created? is it done by debootstrap? === ion_ is now known as ion [03:35] chihchun: I'm not really familiar with core but I'd say it's likely live-build and the logs also point in that direction http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-core/20111205/livecd-20111205-i386.out === bladernr_ is now known as bladernr_afk [03:42] stgraber: thanks [04:41] good morning [04:42] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -> YIPPIE! [04:42] jamespage, wendar: ^ [04:42] pitti: huzzah! :) [04:42] tremolux: I meant trunk, but that's what Vcs-Bzr: points to, so I thought that would be the current branch [04:43] cjwatson: ah, so it won't actually work in dvd-live as restricted stuff can't go into the live system [04:45] cjwatson: hm, I'm still confused; dvd-live depends on dvd-live-langsupport, so would that actually change anything? [05:25] Do we have an automatically generated list of non-multiarched libraries somewhere? [05:34] YokoZar: I think grepping Contents.gz for /usr/lib/lib.*\.so ought to produce something like that [05:35] I'm not aware of a more automatic tracker [05:42] wendar: thanks for the libsoup2.4 multiarch patch! [05:43] wendar: BTW, I can just apply them in Debian and then sync, so no need for an intermediate ubuntu upload [05:43] pitti: you're welcome [05:45] pitti: yes, I only did a straight Debian patch, didn't bother with anything Ubuntu-specific === mglidden_ is now known as mglidden [06:05] micahg: And by "automatically", you mean lots of people are watching it like hawks and retrying things here and there? === mglidden_ is now known as mglidden [06:38] infinity: that could be :), I just know as soon as I get it, when I click, the log isn't there :) [06:44] pitti: is there a reason we got postgresql-8.4 back in precise? [06:44] Nostalgia, I'm guessing. [06:44] heh [06:45] But more realistically, I bet it has to do with LTS->LTS upgrades. [06:45] psql is known for unfortunately needing binaries from old version to do DB converdsions, and other pain. [06:45] :( [06:45] (But that's my guess) [06:46] micahg: Err, to be fair, it never went away... [06:46] postgresql-8.4 | 8.4.8-2 | oneiric/universe | source, amd64, armel, i386, powerpc [06:46] micahg: So, not sure about the "getting it back". [06:46] infinity: ah, just not getting updates, wonderful :) [06:47] pitti: nevermind, rmadison output was larger than my terminal :) [06:48] * infinity starts a local build of libreoffice to find the 13-hour-in failure. >:( [06:49] infinity: I'm excited that I should be able to cross-compile chromium now :) [06:49] micahg: I do intend to drop it, but so far it never left precise [06:49] micahg: still need to fix/drop a couple of rdepends [06:49] micahg: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=psql-8.4-deprecation;users=mpitt@debian.org FYI [06:49] but we additionally have glom and another package [06:49] pitti: right, infinity pointed that out to me, I just saw lucid-maverick w/security updates, then precise, so it looked like it was missing from oneiric, I didn't realize that it just dropped to universe [06:49] infinity: nope, we don't need 8.4 in precise for upgrading from it [06:50] pitti: Yay. [06:50] I fully intent to ship both precise and the next debian stable with 9.1 only [06:50] pitti: Was just a guess based on micahg's question, which was based on misinformation. ;) [06:51] pitti: heh, I've got a list myself of things I'd like gone from the next release, unfortunately, I'm not the maintainer of any of them :) [06:51] Is python on that list? [06:52] oh, I was wondering why python2.6 was still around [06:52] I meant python* [06:52] infinity: I don't think that's possible in Ubuntu :) [06:52] I'm going to try. [06:53] I'll call my derviative Perlbuntu. [06:53] so far I have, sqlite2, wxwidgets2.6, yada [06:53] hm, http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html is clearly boring [06:54] pitti: time to start running it on universe! :) [06:55] pitti: testing-ports seems like a fat lie, though.. [06:56] pitti: Shouldn't I at least see all the openoffice* packages as uninstallable on armhf? Since, like, there's no libreoffice yet. [06:57] ... except that they're in universe... Didn't we fix that? [06:58] pitti: Didn't we promote openoffice* transitional stuff once this cycle? :P [06:58] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -> there, that's better [06:58] hehe [06:58] infinity: let me check about -ports [06:58] pitti: It's not a problem with ports, it's a problem with openoffice-* being in universe. [06:59] pitti: When it needs to be in main for the upgrade. [06:59] infinity: you mean s/armhf/armel/? [06:59] there's nothing to upgrade _from_ for armhf [06:59] pitti: Err, It's in universe for everyone! [06:59] openoffice.org-calc | 1:3.3.0-7ubuntu5 | precise/universe | all [07:00] For instance. [07:00] right [07:00] I'll go seed it [07:00] I could have sworn I seeded the whole source package at UDS. [07:00] openoffice.org | 1:3.3.0-7ubuntu5 | precise | source, all [07:00] seems only parts of it are in universe [07:01] Maybe I just asked someone else to fix the seeds cause my laptop was dead. :P [07:03] infinity: did you touch ubuntu or platform seeds? there's nothing like that in ubuntu [07:03] pitti: Like I said, I think I just asked someone else to do it. Obviously a mistake. ;) [07:03] ok, will seed the bits [07:04] pitti: But it should be in platform/supported-desktop, IMO. [07:04] There needs to be a platform/supported-upgrade-cruft [07:04] hm, we already have "transitional packages" for OO.o in ubuntu/supported [07:04] but I don't mind much where it lives [07:04] pitti: Or there, I suppose. But it's obviously missing some. :P [07:04] Should probably just be an all-source stanza. [07:05] I think some OO.o bits were in universe in the past [07:05] Oh, not quite. Yeah. [07:05] Ugh. [07:05] extra styles, mysql connector, and what not [07:05] Why do we do this to ourselves? :P [07:06] well, we can drop the whole oo.o thing after precise, so that pain is finite at least [07:07] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg, robert_ancell [07:07] * slangasek checks his clock and gives micahg a funny loouk [07:07] slangasek: Hey, no funny looks. I just woke up an hour ago. [07:08] DON'T JUDGE US. [07:08] heh [07:09] m -s lucid $(m -s precise -S openoffice.org | grep universe | cut -f1 -d'|') | grep -v universe [07:09] infinity: ^ I think these are the ones we need, seeding now [07:10] infinity: I think you're more rested than I am ATM then :) [07:10] What happens in your world when you have more than 26 commands to run? [07:10] except -galaxy which we deliberately dropped [07:11] * micahg wonders if the shell can handle accented keys [07:11] infinity: seeded; let's see how precise_probs explodes under us now [07:12] pitti: thats great [07:14] jamespage: good morning [07:14] jamespage: what do you want to tackle today? [07:14] jamespage: right now I thought about killing some NBS, starting with libgail-3-common and the poppler transition [07:15] help with the latter is greatly appreciated, of course, but there's enough fodder in there [07:15] jamespage: v8 is almost gone, just one rdep left; nice work on libv8! === Guest86932 is now known as kklimonda === kklimonda is now known as Guest35546 === Guest35546 is now known as kklimonda [07:35] pitti: v8 will disappear once nodejs builds (this morning) [07:37] broder: is there a reason you didn't use Pre-Depends: ${misc:Pre-Depends} instead of Pre-Depends: multiarch-support (needs compat level 9 IIRC) [07:37] broder: sorry, this was for libsigc++-2.0 [07:40] broder: same on glibmm2.4 [07:45] * micahg guesses robert_ancell is done piloting === micahg changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg [07:56] err, how about I actually _promote_ the oo.o-* transitionals instead of just seeding them [07:59] apw: is user-mode-linux something we want to keep around? is it still maintained? [07:59] apw: it's the only remaining reverse dependency of linux-source-3.0.0 which isn't built any more [08:01] hallyn: did you test the full qemu-linaro build using this 'dh_install --sourcedir' override? I'm getting a very strange build failure that I'm struggling to make sense of [08:06] hallyn: ah, the .install looks for usr/bin/qemu-spice which doesn't exist === doko_ is now known as doko [08:07] Sweetshark, libreoffice build failure on armhf, in testtools [08:10] good morning [08:10] moin dholbach [08:11] hey jelmer [08:11] jelmer, how are you doing? [08:17] doko: I'm running across several packages FTBFS with errors like "libemosR64.so: undefined reference to `sqrtq'" [08:18] wendar, pointers to the build logs? [08:18] https://launchpadlibrarian.net/86672854/buildlog_ubuntu-precise-i386.code-saturne_2.1.0-3_FAILEDTOBUILD.txt.gz [08:18] is one [08:19] micahg: to avoid having to bump the debhelper dependency [08:19] broder: is there a reason not to? [08:20] * broder shrugs [08:20] i was trying to avoid being overly invasive [08:20] doko: another is hidden behind AC_CHECK_LIB, so doesn't show in the build log, but shows in the config.log [08:20] broder: that's a good point [08:20] and i didn't really see pre-depends: multiarch-support as any less elegant than pre-depends: ${misc:Pre-Depends} === smb` is now known as smb [08:21] wendar: --no-add-needed, libmei.so not linked with libm [08:22] broder: well, it makes so that Pre-Depends: multiarch-support being killed in a single place with no-change rebuilds, ISTR a discussion somewhere about this [08:22] micahg: hmm, ok. i hadn't seen that [08:22] broder: or semi-magically when people update their packages, it'll just disappear when it's no longer necessary [08:22] doko: so lingering as-needed problems? [08:23] wendar, no, no-add-needed [08:23] micahg: i'll take another look at some other time. -> sleep for now [08:24] infinity: ah, there we go: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [08:24] doko: is there a difference in the default on no-add-needed between Debian and Ubuntu anymore? [08:25] wendar: if it's GTK based, this change prompted it http://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00236.html [08:28] slangasek: should we push Pre-Depends: ${misc:Pre-Depends} usage in multiarch conversions, or should I take stuff with Pre-Depends: multiarch-support [08:29] micahg: not gtk but does use libpng12, so may be relevant [08:30] infinity: but testing-ports is still broken, there's a ton of armhf/powerpc stuff in ./update_out/check_out.py data/precise; investigating.. [08:30] oo.o fix uploaded [08:31] wendar, no, there shouldn't. but hmm, this is a convenience lib, and the order of -lm and libmei.so is wrong too. [08:33] doko: asking because magics++ (the one I'm working on at the moment with this problem) only has the problem on Ubuntu [08:33] doko: on sid, it has no errors about undefined references, and builds fine [08:34] wendar, I only see magics++ failing because of monkey patching [08:37] infinity: http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html -> that's more like it [08:37] seems powerpc finally caught up [08:37] doko: I'm doing a local build of libreoffice to see if I can find the issue. [08:39] pitti: Hrm, the gcc-multilib stuff looks suspect. Looking into it. [08:40] infinity, it's most likely the uno bridge code [08:41] Sweetshark, ^^^ [08:41] pitti: Oh, multilib is the victim of overzealous demotion (or bad binary NEWing)... [08:41] wendar: perhaps you can try without this manually applied no-as-needed patch? [08:42] infinity: c-m doesn't take armhf into account yet? [08:42] well, the code says it does [08:42] but it might be broken, of course [08:43] pitti: It might be broken. Given that gcc-4.6-multilib is in main, but c-m wants to demote libc6-armel. [08:44] pitti: at the moment I'm working with the raw upstream sources, to minimize interference from the patches [08:44] infinity, pitti, afaik, cjwatson did disable component-mismatches for armel [08:44] armhf [08:44] Perhaps we should fix that now that almost all of main is built. :P [08:44] for arch in [ "i386", "amd64", "powerpc", "armel", "armhf" ]: [08:44] hmm [08:45] * pitti checks on lillypilly [08:45] no bzr diff [08:46] ubuntu-archive@lillypilly:~/ubuntu-archive-tools$ grep armel component-mismatches for arch in [ "i386", "amd64", "powerpc", "armel", "armhf" ]: for arch in [ "i386", "amd64", "powerpc", "armel" ]: [08:47] infinity: the second one is for seeds [08:47] but let's add armhf there as well now [08:49] o libc6-armel libc6-dev-armel {eglibc} [08:49] ^ from c-m [08:49] I'm going to pre-emptively promote everything. [08:49] infinity: I suppose these should stay, too? [08:49] pitti: Yeah, which is wrong. :P [08:49] pitti: Those should stay in main, yes. [08:49] infinity: c-m armhf added for germinate, and rolled out [08:54] pitti: oh, sorry, for Kubuntu it's just 'dvd' that goes on the pool on the DVD, apparently. I always have to look this up in cdimage list-seeds ... [08:57] infinity: yeah, I disabled it because at the time it made c-m explode insanely [08:57] pitti: Alright, libsf* promoted. [08:57] cjwatson: Makes sense. [08:58] I guess I should let gcc-4.4 and gcc-4.5 build and clear those out of the list. [08:58] having only Arch: all and not anything else confuses the bejesus out of germinate, it turns out [08:58] and it starts picking random things that provide something kind of similar [08:58] cjwatson: hahaha. [08:59] infinity, wait with gcc-4.5/gcj-4.5 [08:59] doko: ? [08:59] new packages underway [08:59] Kay. [08:59] So gcc-4.4, then. [09:01] doko: Did you snag the linker patches from gc[cj]-4.[45] and push them to Debian? [09:02] infinity, yes [09:02] \o/ [09:02] Hey, armel's almost caught up from the weekend pain we put it through. [09:02] I can steal buildds back for armhf again! [09:26] michag: so, -lm was on the right track, but also needed -lquadmath and -lgfortran [09:33] is there anything that needs to be done when a conffile is moved to another binary (but keeps the same location)? [09:33] bug #900515 [09:33] Launchpad bug 900515 in evince (Ubuntu) "evince-common conflicts with old evince package" [Undecided,New] https://launchpad.net/bugs/900515 [09:33] the conffile was in "evince" in lucid and is in "evince-common" in precise [09:33] is a Replaces enough? [09:34] the dpkg-maintscript-helper documentation doesn't cover that case nor does http://wiki.debian.org/DpkgConffileHandling [09:34] it should at least be enough to fix the upgrade conflict [09:34] but it should be verified that the ownership of the conffile indeed goes to the new package [09:34] I will try that to start and see how it goes [09:34] and what happens if it is modified [09:34] if somebody tells me that it needs extra tweaking I can do those later on [09:36] pitti, dpkg -S /etc/apparmor.d/abstractions/evince is enough to know what claims to own the file right? [09:36] seb128: right [09:36] seb128: dpkg -s also shows confflies and obsolete conffiles [09:37] let me try locally to move it to evince in the current version and see how it goes [09:37] infinity: ah, eglibc -armel binaries fell off http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; good [09:38] pitti: Which means it also got the sf stuff right, cause I promoted those in this last run. [09:38] and non-ports is once again empty, seems oo.o is happy enough now [09:38] testing-ports is pretty much the LibO FTBFS now [09:39] the gc{c,j} stuff is just catch-up with builds [09:39] pitti: Time to start tackling outdate.txt? ;) [09:39] yep [09:39] infinity: hacking at NBS now [09:39] (which is a subset of outdate) [09:39] * infinity nods. [09:40] jamespage and I are attacking NBS, wendar is looking into FTBFS [09:40] pitti, that is an interesting question as it is clearly recently updated if it has a dep on -3.0.0 source, as that only appeared in oneiric [09:40] * pitti sees his 4 cores glow with building jigabytes of poppler rdepends [09:41] seb128: Replaces is all you need to move a conffile. [09:45] infinity, pitti: testing a fix for the libreoffice ftbfs [09:45] doko: \o/ [09:45] doko: Does that mean I can kill the build on my panda? [09:45] infinity, if it's an unmodified build, yes [09:46] doko: It is, yeah. I was building to get to the failure, then I was going to dig. if you're one it, I'll stop. :P [09:56] @pilot off [09:56] (pilot (in|out)) -- Set yourself an in or out of patch pilot. [09:56] @pilot out [10:06] apw: linux-headers-omap4 and linux-image-omap4 still depend on the old linux 3.0.0 omap packages; does the -meta package need a bump there? [10:07] apw: oh wait, our current linux doesn't even seem to build an -omap4 flavor? [10:07] pitti, right omap4 is out of another source package, and is being worked right now in my other ear [10:10] hmm, i knew ppisati moved, i didnt know he moved into apw 's other ear though [10:10] not much space in there ... is there ? [10:10] (but probably a nice view) [10:13] doko: could adding LDFLAGS upstream fix a linking issue with no-add-needed? context is bug 899315, https://launchpadlibrarian.net/86640020/ebtables.debdiff, http://ebtables.cvs.sourceforge.net/viewvc/ebtables/ebtables2/userspace/ebtables2/ChangeLog?view=markup, and http://ebtables.cvs.sourceforge.net/viewvc/ebtables/ebtables2/userspace/ebtables2/Makefile?r1=1.60&r2=1.61 [10:13] Launchpad bug 899315 in ebtables (Ubuntu) "ebtables crashed with SIGSEGV in ebt_initialize_entry()" [Medium,Confirmed] https://launchpad.net/bugs/899315 [10:22] Sweetshark, infinity, pitti: testing http://paste.ubuntu.com/761459/ [10:35] ppisati, when you have ti-omap4 'fixed' i can probabally test it, so push it up somewhere i an grab it [10:42] doko, could you give a bit extra context on the intltool issue you fixed? do you plan to open a bug about it? [10:42] doko: dont waste too much time on 3.4 for precise as we will ship 3.5 and it has been completely mostly rewritten there anyway: http://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx [10:44] Sweetshark, yes, just running this build to see if it fixes the build [10:44] when do you expect 3.5 in the archive? [10:45] micahg, the upstream Makefile still lists the libs before the objects [10:46] micahg, is this still the case in the ubuntu package? [10:46] doko: branchoff is about right now === pitti is now known as pitti_ [10:46] the LD change seems to be a no-op [10:46] micahg, please use dpkg-buildflags [10:47] Sweetshark, when do you expect 3.5 in the archive? [10:49] doko: ah, forget that: I got it wrong -- its uno2cpp and not cpp2uno which is pretty much unchanged. so yes, I would be still interested if that builds. [10:49] doko: the beta will be there before christmas. [10:50] Sweetshark, maybe ask caolan if he already had to build on armhf [10:51] doko: will do [10:52] doko, hey? [10:53] jamespage: FYI, I'm now through all libpoppler13 rdepends except karbon and luatex, which you were looking into [10:53] james_w: pdftoipe is FTBFS due to a missing poppler-dev dep (not sure yet), seb128 is looking into this [10:53] sorry, jamespage ^ [10:53] james_w: unping, tab failure, sorry [10:53] pitti_, I've uploaded the fix, should be good to retry soon [10:53] seb128: oh, cheers [10:53] seb128: my colo hoster shut down, don't get mail right now [10:54] seb128, ? [10:55] doko, could you give a bit extra context on the intltool issue you fixed? do you plan to open a bug about it? [10:55] seb128, see the exo build failure on armhf [10:55] jamespage: oh, and cups, which is still on my plate [10:56] jamespage: starting with the libpoppler-glib6 rdepends now [10:56] doko, it would be nice if you could at least open a bug in such cases, or give a pointer to the issue in the changelog entry so other can understand why we have a diff in Ubuntu and get it fixed upstream or in Debian === brendand_ is now known as brendand [10:56] doko: I didn't try to fix the issue yet, but was wondering if the new upstream release would help, I guess not (there were some other changes to the Makefile: http://ebtables.cvs.sourceforge.net/viewvc/ebtables/ebtables2/userspace/ebtables2/Makefile?revision=1.67&view=markup seems to be the latest upstream), we don't seem to be patching it at all for , but it seems to build happily, oops I mean no-as-needed before [10:56] , I guess I can try to patch the makefile to work properly or maybe I'll just leave a note in the bug to patch the make file rather than disabling --as-needed [10:57] *for --as-needed [10:57] doko, can you open a bug against intltool? danilo and dobey are upstream and they maintain it on launchpad, launchpad.net/intltool [10:58] dobey: ^^^ [10:59] micahg, I would fix the linker order first, before reverting to no-as-needed [10:59] not that you should link with -lc explicitly [10:59] doko: -lc is upstream craziness :) [11:00] * micahg leaves a comment on the bug [11:00] doko, no, dumping an hack this way with an IRC ping is not the way to work, please open a bug on launchpad explaining the issue and your fix [11:00] doko: by doing workaround this way and not sending back the issue where it should you create a diff in ubuntu we need to maintain for no reason and work for other people [11:00] seb128, bullshit, it's not a hack [11:01] doko, well then open a bug with the patch so it goes upstream and in debian? [11:01] since when did we stop upstreaming fixes? [11:01] we didn't [11:01] we expect everyone to do it [11:02] seb128, you are pestering me 5min after the upload. I'll remind you the next time when I have to wait 10min [11:02] doko, I'm just asking if you will open a bug, not to do it now [11:02] doko, I've seen some cases recently where you moved on and didn't upstream or documents fixes you did [11:02] 12:00 <@caolan> are you sure it shouldn't just be #if (!defined(__ARM_PCS_VFP) && defined(__ARM_EABI__)) || defined(__SOFTFP__) [11:02] doko: ^^ [11:03] doko: maybe join us on #libreoffice-dev? [11:03] doko, but yes, if I do any upload with a fix not commit from upstream git without a bug reference in the changelog or patch please tell me off for doing it [11:03] not commit -> not backported [11:09] hi, can someone tell me what's wrong with [11:09] override_dh_installdocs: [11:09] dh_installdocs --exclude COPYING --exclude ChangeLog [11:09] ? [11:10] 'cause those files still keep getting installed... [11:10] the changelog gets installed by dh_installchangelogs [11:11] COPYING is weird, though; I know no dh_* tool which would install that by its own [11:11] and it's in fact a slight policy violation to install it for the case of GPL, etc. [11:12] doko: thanks for the help BTW [11:12] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [11:13] pitti_: yeah, that's why i'm trying to exclude it... [11:13] ockham_: perhaps it's in some debian/*.install or *.docs file? [11:14] pitti_: there was an install file, but i've already removed it. [11:15] DH_VERBOSE=1 debian/rules binary [11:15] | grep COPYING :P [11:15] infinity: yeah, i'll try that [11:17] doko: do we still need this change? https://launchpad.net/ubuntu/+source/python-poppler/0.12.1-4ubuntu1 [11:18] pitti_: ack, just uploaded karbon rebuild; still working on luatex [11:19] pitti: $ apt-cache show libxcb-render-util0-dev|grep Filename [11:19] Filename: pool/universe/x/xcb-util-renderutil/libxcb-render-util0-dev_0.3.8-1_amd64.deb [11:19] doko: (I guess that's not the full answer yet?) [11:20] well, it's a universe package [11:20] right, but why can't we use that? [11:20] it's our only delta [11:21] oh, did python-poppler use to be in main? it's in universe [11:21] pretty much forever [11:21] doko: so it was just for the component, not a functionality issue? [11:22] hm, still no luck. http://pastebin.com/y3HhyK1S [11:22] looking [11:22] pitti_, it was never in main I think [11:24] ockham_: I see no verbose debhelper there. [11:24] infinity: but i generated it with DH_VERBOSE=1 debuild > ../build.log [11:25] btw, just re-uploaded to http://revu.ubuntuwire.com/p/unity-lens-bliss [11:25] /usr/bin/install -c -m 644 AUTHORS ChangeLog COPYING NEWS README '/home/bernie/src/packages/unity/unity-lens-bliss/debian/unity-lens-bliss/usr/share/doc/unity-lens-bliss' [11:26] ockham_: Is your upstream Makefile installing those? [11:26] (Sorry, that was verbose, I'm just not used to seeing dh_ do so little) [11:30] infinity: yup, it's apparently in my upstream Makefile. [11:30] infinity: so i need to exclude it there... [11:31] pitti_, hmm, no, that was the time for the rebuild tests. I assume that lp couldn't resolve the b-d's. so maybe try without the patch, and then re-add it if necessary. maybe it was armel only? [11:31] doko: ok, doing that then [11:32] doko: thanks [11:33] heh, neat +build1 trick. but how would add an ubuntu change now? [11:33] +ubuntu1? :) [11:34] * Daviey does wonder why people do no change rebuilds, adding ubuntu to the version string. :/ [11:34] Daviey: uh, did I? [11:34] no, in general [11:34] Daviey: maybe people don't know about dch -R vs dch -i :) [11:34] Daviey, which ones? [11:35] doko: i've seen a few, have you not? [11:35] I've seen them occasionally, but they looked more like accidental [11:35] Daviey, only if they already have an ubuntu version [11:35] ockham_: 'DH_VERBOSE=1 debuild' needs to be 'debuild -eDH_VERBOSE=1' - debuild filters the environment [11:35] cjwatson: oops, thx [11:36] Daviey: in general, the debuild -S failure ought to yell at you for not changing the Maintainer: field; that has caught a few cases where I forgot it :) [11:36] pitti: time for +ubuntu1 ;-P [11:37] hehe [11:38] ah, failed on amd64 due to a pointer cast problem (didn't fail here) [11:38] pitti_: only works if you have an ubuntu address :) [11:38] that doesn't seem immediately related to the build dep change, though [11:38] s/have/use/ === _salem is now known as salem_ [12:09] hello: what is the easiest way to combine multiple windows? like editor, terminal, other views ? [12:13] dholbach: are you still interested in glom, or know someone who is? it's several versions behind and now unbuildable (still uses gtksourceviewmm2 which doesn't exist any more, and builds against psql 8.4, etc.) [12:13] upstream's wiki says to install a third-party repo if you want to use it [12:13] pitti_, not so much interested really - I can add it as a low prio entry into my TODO list and do it if nobody beats me to it, but it might still take a while [12:14] ah, bug 871276 (nobody picking it up) [12:14] Launchpad bug 871276 in glom (Ubuntu) "Please update to Glom 1.19.x" [Wishlist,Confirmed] https://launchpad.net/bugs/871276 [12:14] dholbach: well, if you aren't interested, it might be better to just remove it? [12:14] I dunno - it might still be useful to a lot of people, no? [12:15] well, we can't leave it as it is -- we need to remove or upgrade it [12:16] pitti_, the Openismus folks seem to have it updated to 1.20.1 in their ppa [12:16] is that the latest & greatest? [12:16] yes, looks like it [12:16] dholbach: pitti_: goocanvas 2.0 is in progress in Debian [12:17] micahg, do you know where it's currently sitting? [12:17] dholbach: yes, it is: http://ftp.gnome.org/pub/GNOME/sources/glom/1.20/ [12:17] dholbach: mentors I think [12:17] alright - I'll have a look [12:17] ah, we need those libraries first [12:18] right, I think that's the main reason it wasn't updated last cycle [12:18] I'll have a chat with the Openismus folks - they seem to actively care for their stuff, so they might want to have upload rights at some stage - at least I'll tell them to ask for review of their PPA packages, etc etc etc [12:18] * pitti_ hugs dholbach, that sounds great -- teach a man to fish etc. [12:19] if you teach them all there wont be any fish left though [12:19] :P [12:19] ogra_, we're not there yet :) [12:19] :) === MacSlow is now known as MacSlow|lunch [12:29] dholbach, pitti_: hey (was at lunch) [12:29] hey seb128 [12:30] dholbach, pitti_: don't remove glom please, murray (upstream) cares about it, I meant to email him about the stuff he maintains and the version he would like to see in the LTS [12:30] seb128, I'll CC you [12:30] just writing the mail [12:30] dholbach, pitti_: we (desktop) will find some time to update gda, glom, etc [12:30] dholbach, thanks [12:31] seb128, oh yeah? if you do, check out https://launchpad.net/~openismus-team/+archive/ppa/+packages - the work seems to be done there already [12:31] (hopefully) just a matter of trimming the changelog entries and uploading [12:31] dholbach, well, I first want to ask murray what version should go in the LTS [12:31] 1.20 I guess is a stable version [12:31] but yeah, I'll mention it in the mail as well [12:32] dholbach, I guess it will requite updates for some other stuff like goocanvas libgda, gegl, etc [12:32] * dholbach nods [12:32] dholbach, thanks, or just email what you wanted and I will follow up with my questions on what version he wants [12:47] Laney, gnome-do ftbfs the same way as gnome-desktop-sharp2: https://launchpadlibrarian.net/86763720/buildlog_ubuntu-precise-armhf.gnome-do_0.8.5-1ubuntu2_FAILEDTOBUILD.txt.gz [12:48] pitti_, cjwatson: Could we remove and blacklist the squid source from precise? we generate transitional "squid" binaries from the squid3 source package while Debian ships squid 2 in its squid binaries built from the squid source; zul said he was ok with this approach [12:48] pitti_, cjwatson: Essentially we can't upload the squid source and binaries in Ubuntu anymore, so I think we should removeit [12:50] lool: What upload are you planning? [12:50] lool: sure, file a bug and subscribe ubuntu-archive [12:50] (or subscribe us to an existing bug) [12:51] I don't do source removals outside the context of a bug normally, as they need an audit trail [12:53] lool: It's already planned for removal. [12:53] (Was discussed here a couple times over the last few days) [12:54] Daviey: No upload [12:54] cjwatson: Ok [12:54] infinity: Oh ok thanks [12:55] infinity: I couldn't find a removal bug against squid, is it against ubuntu? [12:55]