[01:52] <micahg> infinity: any idea why my armhf failures seem to automatically get retried?
[03:14] <chihchun> hi there, anyone how the ubuntu-core been created? is it done by debootstrap?
[03:35] <stgraber> 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
[03:42] <chihchun> stgraber: thanks
[04:41] <pitti> good morning
[04:42] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -> YIPPIE!
[04:42] <pitti> jamespage, wendar: ^
[04:42] <wendar> pitti: huzzah! :)
[04:42] <pitti> tremolux: I meant trunk, but that's what Vcs-Bzr: points to, so I thought that would be the current branch
[04:43] <pitti> cjwatson: ah, so it won't actually work in dvd-live as restricted stuff can't go into the live system
[04:45] <pitti> cjwatson: hm, I'm still confused; dvd-live depends on dvd-live-langsupport, so would that actually change anything?
[05:25] <YokoZar> Do we have an automatically generated list of non-multiarched libraries somewhere?
[05:34] <pitti> YokoZar: I think grepping Contents.gz for /usr/lib/lib.*\.so ought to produce something like that
[05:35] <pitti> I'm not aware of a more automatic tracker
[05:42] <pitti> wendar: thanks for the libsoup2.4 multiarch patch!
[05:43] <pitti> wendar: BTW, I can just apply them in Debian and then sync, so no need for an intermediate ubuntu upload
[05:43] <wendar> pitti: you're welcome
[05:45] <wendar> pitti: yes, I only did a straight Debian patch, didn't bother with anything Ubuntu-specific
[06:05] <infinity> micahg: And by "automatically", you mean lots of people are watching it like hawks and retrying things here and there?
[06:38] <micahg> infinity: that could be :), I just know as soon as I get it, when I click, the log isn't there :)
[06:44] <micahg> pitti: is there a reason we got postgresql-8.4 back in precise?
[06:44] <infinity> Nostalgia, I'm guessing.
[06:44] <micahg> heh
[06:45] <infinity> But more realistically, I bet it has to do with LTS->LTS upgrades.
[06:45] <infinity> psql is known for unfortunately needing binaries from old version to do DB converdsions, and other pain.
[06:45] <micahg> :(
[06:45] <infinity> (But that's my guess)
[06:46] <infinity> micahg: Err, to be fair, it never went away...
[06:46] <infinity> postgresql-8.4 |    8.4.8-2 | oneiric/universe | source, amd64, armel, i386, powerpc
[06:46] <infinity> micahg: So, not sure about the "getting it back".
[06:46] <micahg> infinity: ah, just not getting updates, wonderful :)
[06:47] <micahg> 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] <micahg> infinity: I'm excited that I should be able to cross-compile chromium now :)
[06:49] <pitti> micahg: I do intend to drop it, but so far it never left precise
[06:49] <pitti> micahg: still need to fix/drop a couple of rdepends
[06:49] <pitti> micahg: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=psql-8.4-deprecation;users=mpitt@debian.org FYI
[06:49] <pitti> but we additionally have glom and another package
[06:49] <micahg> 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] <pitti> infinity: nope, we don't need 8.4 in precise for upgrading from it
[06:50] <infinity> pitti: Yay.
[06:50] <pitti> I fully intent to ship both precise and the next debian stable with 9.1 only
[06:50] <infinity> pitti: Was just a guess based on micahg's question, which was based on misinformation. ;)
[06:51] <micahg> 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] <infinity> Is python on that list?
[06:52] <micahg> oh, I was wondering why python2.6 was still around
[06:52] <infinity> I meant python*
[06:52] <micahg> infinity: I don't think that's possible in Ubuntu :)
[06:52] <infinity> I'm going to try.
[06:53] <infinity> I'll call my derviative Perlbuntu.
[06:53] <micahg> so far I have, sqlite2, wxwidgets2.6, yada
[06:53] <pitti> hm, http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html is clearly boring
[06:54] <broder> pitti: time to start running it on universe! :)
[06:55] <infinity> pitti: testing-ports seems like a fat lie, though..
[06:56] <infinity> pitti: Shouldn't I at least see all the openoffice* packages as uninstallable on armhf?  Since, like, there's no libreoffice yet.
[06:57] <infinity> ... except that they're in universe... Didn't we fix that?
[06:58] <infinity> pitti: Didn't we promote openoffice* transitional stuff once this cycle? :P
[06:58] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html -> there, that's better
[06:58] <micahg> hehe
[06:58] <pitti> infinity: let me check about -ports
[06:58] <infinity> pitti: It's not a problem with ports, it's a problem with openoffice-* being in universe.
[06:59] <infinity> pitti: When it needs to be in main for the upgrade.
[06:59] <pitti> infinity: you mean s/armhf/armel/?
[06:59] <pitti> there's nothing to upgrade _from_ for armhf
[06:59] <infinity> pitti: Err, It's in universe for everyone!
[06:59] <infinity> openoffice.org-calc | 1:3.3.0-7ubuntu5 | precise/universe | all
[07:00] <infinity> For instance.
[07:00] <pitti> right
[07:00] <pitti> I'll go seed it
[07:00] <infinity> I could have sworn I seeded the whole source package at UDS.
[07:00] <pitti> openoffice.org | 1:3.3.0-7ubuntu5 |       precise | source, all
[07:00] <pitti> seems only parts of it are in universe
[07:01] <infinity> Maybe I just asked someone else to fix the seeds cause my laptop was dead. :P
[07:03] <pitti> infinity: did you touch ubuntu or platform seeds? there's nothing like that in ubuntu
[07:03] <infinity> pitti: Like I said, I think I just asked someone else to do it.  Obviously a mistake. ;)
[07:03] <pitti> ok, will seed the bits
[07:04] <infinity> pitti: But it should be in platform/supported-desktop, IMO.
[07:04] <infinity> There needs to be a platform/supported-upgrade-cruft
[07:04] <pitti> hm, we already have "transitional packages" for OO.o in ubuntu/supported
[07:04] <pitti> but I don't mind much where it lives
[07:04] <infinity> pitti: Or there, I suppose.  But it's obviously missing some. :P
[07:04] <infinity> Should probably just be an all-source stanza.
[07:05] <pitti> I think some OO.o bits were in universe in the past
[07:05] <infinity> Oh, not quite.  Yeah.
[07:05] <infinity> Ugh.
[07:05] <pitti> extra styles, mysql connector, and what not
[07:05] <infinity> Why do we do this to ourselves? :P
[07:06] <pitti> well, we can drop the whole oo.o thing after precise, so that pain is finite at least
[07:07] <micahg> @pilot in
[07:07]  * slangasek checks his clock and gives micahg a funny loouk
[07:07] <infinity> slangasek: Hey, no funny looks.  I just woke up an hour ago.
[07:08] <infinity> DON'T JUDGE US.
[07:08] <micahg> heh
[07:09] <pitti> m -s lucid $(m -s precise -S openoffice.org | grep universe | cut -f1 -d'|') | grep -v universe
[07:09] <pitti> infinity: ^ I think these are the ones we need, seeding now
[07:10] <micahg> infinity: I think you're more rested than I am ATM then :)
[07:10] <infinity> What happens in your world when you have more than 26 commands to run?
[07:10] <pitti> except -galaxy which we deliberately dropped
[07:11]  * micahg wonders if the shell can handle accented keys
[07:11] <pitti> infinity: seeded; let's see how precise_probs explodes under us now
[07:12] <jamespage> pitti: thats great
[07:14] <pitti> jamespage: good morning
[07:14] <pitti> jamespage: what do you want to tackle today?
[07:14] <pitti> jamespage: right now I thought about killing some NBS, starting with libgail-3-common and the poppler transition
[07:15] <pitti> help with the latter is greatly appreciated, of course, but there's enough fodder in there
[07:15] <pitti> jamespage: v8 is almost gone, just one rdep left; nice work on libv8!
[07:35] <jamespage> pitti: v8 will disappear once nodejs builds (this morning)
[07:37] <micahg> 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] <micahg> broder: sorry, this was for libsigc++-2.0
[07:40] <micahg> broder: same on glibmm2.4
[07:45]  * micahg guesses robert_ancell is done piloting
[07:56] <pitti> err, how about I actually _promote_ the oo.o-* transitionals instead of just seeding them
[07:59] <pitti> apw: is user-mode-linux something we want to keep around? is it still maintained?
[07:59] <pitti> apw: it's the only remaining reverse dependency of linux-source-3.0.0 which isn't built any more
[08:01] <slangasek> 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] <slangasek> hallyn: ah, the .install looks for usr/bin/qemu-spice which doesn't exist
[08:07] <doko> Sweetshark, libreoffice build failure on armhf, in testtools
[08:10] <dholbach> good morning
[08:10] <jelmer> moin dholbach
[08:11] <dholbach> hey jelmer
[08:11] <dholbach> jelmer, how are you doing?
[08:17] <wendar> doko: I'm running across several packages FTBFS with errors like "libemosR64.so: undefined reference to `sqrtq'"
[08:18] <doko> wendar, pointers to the build logs?
[08:18] <wendar> https://launchpadlibrarian.net/86672854/buildlog_ubuntu-precise-i386.code-saturne_2.1.0-3_FAILEDTOBUILD.txt.gz
[08:18] <wendar> is one
[08:19] <broder> micahg: to avoid having to bump the debhelper dependency
[08:19] <micahg> broder: is there a reason not to?
[08:20]  * broder shrugs
[08:20] <broder> i was trying to avoid being overly invasive
[08:20] <wendar> doko: another is hidden behind  AC_CHECK_LIB, so doesn't show in the build log, but shows in the config.log
[08:20] <micahg> broder: that's a good point
[08:20] <broder> and i didn't really see pre-depends: multiarch-support as any less elegant than pre-depends: ${misc:Pre-Depends}
[08:21] <doko> wendar: --no-add-needed, libmei.so not linked with libm
[08:22] <micahg> 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] <broder> micahg: hmm, ok. i hadn't seen that
[08:22] <micahg> broder: or semi-magically when people update their packages, it'll just disappear when it's no longer necessary
[08:22] <wendar> doko: so lingering as-needed problems?
[08:23] <doko> wendar, no, no-add-needed
[08:23] <broder> micahg: i'll take another look at some other time. -> sleep for now
[08:24] <pitti> infinity: ah, there we go: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[08:24] <wendar> doko: is there a difference in the default on no-add-needed between Debian and Ubuntu anymore?
[08:25] <micahg> wendar: if it's GTK based, this change prompted it http://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00236.html
[08:28] <micahg> 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] <wendar> micahg: not gtk but does use libpng12, so may be relevant
[08:30] <pitti> 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] <pitti> oo.o fix uploaded
[08:31] <doko> 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] <wendar> doko: asking because magics++ (the one I'm working on at the moment with this problem) only has the problem on Ubuntu
[08:33] <wendar> doko: on sid, it has no errors about undefined references, and builds fine
[08:34] <doko> wendar, I only see magics++ failing because of monkey patching
[08:37] <pitti> infinity: http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html -> that's more like it
[08:37] <pitti> seems powerpc finally caught up
[08:37] <infinity> doko: I'm doing a local build of libreoffice to see if I can find the issue.
[08:39] <infinity> pitti: Hrm, the gcc-multilib stuff looks suspect.  Looking into it.
[08:40] <doko> infinity, it's most likely the uno bridge code
[08:41] <doko> Sweetshark, ^^^
[08:41] <infinity> pitti: Oh, multilib is the victim of overzealous demotion (or bad binary NEWing)...
[08:41] <pitti> wendar: perhaps you can try without this manually applied no-as-needed patch?
[08:42] <pitti> infinity: c-m doesn't take armhf into account yet?
[08:42] <pitti> well, the code says it does
[08:42] <pitti> but it might be broken, of course
[08:43] <infinity> pitti: It might be broken.  Given that gcc-4.6-multilib is in main, but c-m wants to demote libc6-armel.
[08:44] <wendar> pitti: at the moment I'm working with the raw upstream sources, to minimize interference from the patches
[08:44] <doko> infinity, pitti, afaik, cjwatson did disable component-mismatches for armel
[08:44] <doko> armhf
[08:44] <infinity> Perhaps we should fix that now that almost all of main is built. :P
[08:44] <pitti>         for arch in [ "i386", "amd64", "powerpc", "armel", "armhf" ]:
[08:44] <pitti> hmm
[08:45]  * pitti checks on lillypilly
[08:45] <pitti> no bzr diff
[08:46] <infinity> 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] <pitti> infinity: the second one is for seeds
[08:47] <pitti> but let's add armhf there as well now
[08:49] <pitti>  o libc6-armel libc6-dev-armel                                        {eglibc}
[08:49] <pitti> ^ from c-m
[08:49] <infinity> I'm going to pre-emptively promote everything.
[08:49] <pitti> infinity: I suppose these should stay, too?
[08:49] <infinity> pitti: Yeah, which is wrong. :P
[08:49] <infinity> pitti: Those should stay in main, yes.
[08:49] <pitti> infinity: c-m armhf added for germinate, and rolled out
[08:54] <cjwatson> 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] <cjwatson> infinity: yeah, I disabled it because at the time it made c-m explode insanely
[08:57] <infinity> pitti: Alright, libsf* promoted.
[08:57] <infinity> cjwatson: Makes sense.
[08:58] <infinity> I guess I should let gcc-4.4 and gcc-4.5 build and clear those out of the list.
[08:58] <cjwatson> having only Arch: all and not anything else confuses the bejesus out of germinate, it turns out
[08:58] <cjwatson> and it starts picking random things that provide something kind of similar
[08:58] <infinity> cjwatson: hahaha.
[08:59] <doko> infinity, wait with gcc-4.5/gcj-4.5
[08:59] <infinity> doko: ?
[08:59] <doko> new packages underway
[08:59] <infinity> Kay.
[08:59] <infinity> So gcc-4.4, then.
[09:01] <infinity> doko: Did you snag the linker patches from gc[cj]-4.[45] and push them to Debian?
[09:02] <doko> infinity, yes
[09:02] <infinity> \o/
[09:02] <infinity> Hey, armel's almost caught up from the weekend pain we put it through.
[09:02] <infinity> I can steal buildds back for armhf again!
[09:26] <wendar> michag: so, -lm was on the right track, but also needed -lquadmath and -lgfortran
[09:33] <seb128> is there anything that needs to be done when a conffile is moved to another binary (but keeps the same location)?
[09:33] <seb128> bug #900515
[09:33] <seb128> the conffile was in "evince" in lucid and is in "evince-common" in precise
[09:33] <seb128> is a Replaces enough?
[09:34] <seb128> the dpkg-maintscript-helper documentation doesn't cover that case nor does http://wiki.debian.org/DpkgConffileHandling
[09:34] <pitti> it should at least be enough to fix the upgrade conflict
[09:34] <pitti> but it should be verified that the ownership of the conffile indeed goes to the new package
[09:34] <seb128> I will try that to start and see how it goes
[09:34] <pitti> and what happens if it is modified
[09:34] <seb128> if somebody tells me that it needs extra tweaking I can do those later on
[09:36] <seb128> pitti, dpkg -S /etc/apparmor.d/abstractions/evince is enough to know what claims to own the file right?
[09:36] <pitti> seb128: right
[09:36] <pitti> seb128: dpkg -s <package> also shows confflies and obsolete conffiles
[09:37] <seb128> let me try locally to move it to evince in the current version and see how it goes
[09:37] <pitti> infinity: ah, eglibc -armel binaries fell off http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; good
[09:38] <infinity> pitti: Which means it also got the sf stuff right, cause I promoted those in this last run.
[09:38] <pitti> and non-ports is once again empty, seems oo.o is happy enough now
[09:38] <pitti> testing-ports is pretty much the LibO FTBFS now
[09:39] <pitti> the gc{c,j} stuff is just catch-up with builds
[09:39] <infinity> pitti: Time to start tackling outdate.txt? ;)
[09:39] <pitti> yep
[09:39] <pitti> infinity: hacking at NBS now
[09:39] <pitti> (which is a subset of outdate)
[09:39]  * infinity nods.
[09:40] <pitti> jamespage and I are attacking NBS, wendar is looking into FTBFS
[09:40] <apw> 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] <infinity> seb128: Replaces is all you need to move a conffile.
[09:45] <doko> infinity, pitti: testing a fix for the libreoffice ftbfs
[09:45] <infinity> doko: \o/
[09:45] <infinity> doko: Does that mean I can kill the build on my panda?
[09:45] <doko> infinity, if it's an unmodified build, yes
[09:46] <infinity> 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] <robert_ancell> @pilot off
[09:56] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[09:56] <robert_ancell> @pilot out
[10:06] <pitti> 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] <pitti> apw: oh wait, our current linux doesn't even seem to build an -omap4 flavor?
[10:07] <apw> pitti, right omap4 is out of another source package, and is being worked right now in my other ear
[10:10] <ogra_> hmm, i knew ppisati moved, i didnt know he moved into apw 's other ear though
[10:10] <ogra_> not much space in there ... is there ?
[10:10] <ogra_> (but probably a nice view)
[10:13] <micahg> 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:22] <doko> Sweetshark, infinity, pitti: testing http://paste.ubuntu.com/761459/
[10:35] <apw> ppisati, when you have ti-omap4 'fixed' i can probabally test it, so push it up somewhere i an grab it
[10:42] <seb128> 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] <Sweetshark> 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] <doko> Sweetshark, yes, just running this build to see if it fixes the build
[10:44] <doko> when do you expect 3.5 in the archive?
[10:45] <doko> micahg, the upstream Makefile still lists the libs before the objects
[10:46] <doko> micahg, is this still the case in the ubuntu package?
[10:46] <Sweetshark> doko: branchoff is about right now
[10:46] <doko> the LD change seems to be a no-op
[10:46] <doko> micahg, please use dpkg-buildflags
[10:47] <doko> Sweetshark, when do you expect 3.5 in the archive?
[10:49] <Sweetshark> 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] <Sweetshark> doko: the beta will be there before christmas.
[10:50] <doko> Sweetshark, maybe ask caolan if he already had to build on armhf
[10:51] <Sweetshark> doko: will do
[10:52] <seb128> doko, hey?
[10:53] <pitti_> jamespage: FYI, I'm now through all libpoppler13 rdepends except karbon and luatex, which you were looking into
[10:53] <pitti_> james_w: pdftoipe is FTBFS due to a missing poppler-dev dep (not sure yet), seb128 is looking into this
[10:53] <pitti_> sorry, jamespage ^
[10:53] <pitti_> james_w: unping, tab failure, sorry
[10:53] <seb128> pitti_, I've uploaded the fix, should be good to retry soon
[10:53] <pitti_> seb128: oh, cheers
[10:53] <pitti_> seb128: my colo hoster shut down, don't get mail right now
[10:54] <doko> seb128, ?
[10:55] <seb128> 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] <doko> seb128, see the exo build failure on armhf
[10:55] <pitti_> jamespage: oh, and cups, which is still on my plate
[10:56] <pitti_> jamespage: starting with the libpoppler-glib6 rdepends now
[10:56] <seb128> 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
[10:56] <micahg> 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] <micahg> , 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] <micahg> *for --as-needed
[10:57] <seb128> doko, can you open a bug against intltool? danilo and dobey are upstream and they maintain it on launchpad, launchpad.net/intltool
[10:58] <doko> dobey: ^^^
[10:59] <doko> micahg, I would fix the linker order first, before reverting to no-as-needed
[10:59] <doko> not that you should link with -lc explicitly
[10:59] <micahg> doko: -lc is upstream craziness :)
[11:00]  * micahg leaves a comment on the bug
[11:00] <seb128> 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] <seb128> 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] <doko> seb128, bullshit, it's not a hack
[11:01] <seb128> doko, well then open a bug with the patch so it goes upstream and in debian?
[11:01] <seb128> since when did we stop upstreaming fixes?
[11:01] <pitti_> we didn't
[11:01] <pitti_> we expect everyone to do it
[11:02] <doko> seb128, you are pestering me 5min after the upload. I'll remind you the next time when I have to wait 10min
[11:02] <seb128> doko, I'm just asking if you will open a bug, not to do it now
[11:02] <seb128> doko, I've seen some cases recently where you moved on and didn't upstream or documents fixes you did
[11:02] <Sweetshark> 12:00 <@caolan> are you sure it shouldn't just be #if (!defined(__ARM_PCS_VFP) && defined(__ARM_EABI__)) || defined(__SOFTFP__)
[11:02] <Sweetshark> doko: ^^
[11:03] <Sweetshark> doko: maybe join us on #libreoffice-dev?
[11:03] <seb128> 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] <seb128> not commit -> not backported
[11:09] <ockham_> hi, can someone tell me what's wrong with
[11:09] <ockham_> override_dh_installdocs:
[11:09] <ockham_> 	dh_installdocs --exclude COPYING --exclude ChangeLog
[11:09] <ockham_> ?
[11:10] <ockham_> 'cause those files still keep getting installed...
[11:10] <tumbleweed> the changelog gets installed by dh_installchangelogs
[11:11] <pitti_> COPYING is weird, though; I know no dh_* tool which would install that by its own
[11:11] <pitti_> and it's in fact a slight policy violation to install it for the case of GPL, etc.
[11:12] <micahg> doko: thanks for the help BTW
[11:12] <micahg> @pilot out
[11:13] <ockham_> pitti_: yeah, that's why i'm trying to exclude it...
[11:13] <pitti_> ockham_: perhaps it's in some debian/*.install or *.docs file?
[11:14] <ockham_> pitti_: there was an install file, but i've already removed it.
[11:15] <infinity> DH_VERBOSE=1 debian/rules binary
[11:15] <infinity> | grep COPYING :P
[11:15] <ockham_> infinity: yeah, i'll try that
[11:17] <pitti_> doko: do we still need this change? https://launchpad.net/ubuntu/+source/python-poppler/0.12.1-4ubuntu1
[11:18] <jamespage> pitti_: ack, just uploaded karbon rebuild; still working on luatex
[11:19] <doko> pitti: $ apt-cache show libxcb-render-util0-dev|grep Filename
[11:19] <doko> Filename: pool/universe/x/xcb-util-renderutil/libxcb-render-util0-dev_0.3.8-1_amd64.deb
[11:19] <pitti_> doko: (I guess that's not the full answer yet?)
[11:20] <doko> well, it's a universe package
[11:20] <pitti_> right, but why can't we use that?
[11:20] <pitti_> it's our only delta
[11:21] <pitti_> oh, did python-poppler use to be in main? it's in universe
[11:21] <pitti_> pretty much forever
[11:21] <pitti_> doko: so it was just for the component, not a functionality issue?
[11:22] <ockham_> hm, still no luck. http://pastebin.com/y3HhyK1S
[11:22] <doko> looking
[11:22] <seb128> pitti_, it was never in main I think
[11:24] <infinity> ockham_: I see no verbose debhelper there.
[11:24] <ockham_> infinity: but i generated it with DH_VERBOSE=1 debuild > ../build.log
[11:25] <ockham_> btw, just re-uploaded to http://revu.ubuntuwire.com/p/unity-lens-bliss
[11:25] <infinity> /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] <infinity> ockham_: Is your upstream Makefile installing those?
[11:26] <infinity> (Sorry, that was verbose, I'm just not used to seeing dh_ do so little)
[11:30] <ockham_> infinity: yup, it's apparently in my upstream Makefile.
[11:30] <ockham_> infinity: so i need to exclude it there...
[11:31] <doko> 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] <pitti_> doko: ok, doing that then
[11:32] <pitti_> doko: thanks
[11:33] <doko> heh, neat +build1 trick. but how would add an ubuntu change now?
[11:33] <pitti_> +ubuntu1? :)
[11:34]  * Daviey does wonder why people do no change rebuilds, adding ubuntu to the version string. :/
[11:34] <pitti_> Daviey: uh, did I?
[11:34] <Daviey> no, in general
[11:34] <micahg> Daviey: maybe people don't know about dch -R vs dch -i :)
[11:34] <doko> Daviey, which ones?
[11:35] <Daviey> doko: i've seen a few, have you not?
[11:35] <pitti_> I've seen them occasionally, but they looked more like accidental
[11:35] <doko> Daviey, only if they already have an ubuntu version
[11:35] <cjwatson> ockham_: 'DH_VERBOSE=1 debuild' needs to be 'debuild -eDH_VERBOSE=1' - debuild filters the environment
[11:35] <ockham_> cjwatson: oops, thx
[11:36] <pitti_> 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] <doko> pitti: time for +ubuntu1 ;-P
[11:37] <micahg> hehe
[11:38] <pitti_> ah, failed on amd64 due to a pointer cast problem (didn't fail here)
[11:38] <micahg> pitti_: only works if you have an ubuntu address :)
[11:38] <pitti_> that doesn't seem immediately related to the build dep change, though
[11:38] <micahg> s/have/use/
[12:09] <cari_veri_dt> hello: what is the easiest way to combine multiple windows? like editor, terminal, other views ?
[12:13] <pitti_> 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] <pitti_> upstream's wiki says to install a third-party repo if you want to use it
[12:13] <dholbach> 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] <pitti_> ah, bug 871276 (nobody picking it up)
[12:14] <pitti_> dholbach: well, if you aren't interested, it might be better to just remove it?
[12:14] <dholbach> I dunno - it might still be useful to a lot of people, no?
[12:15] <pitti_> well, we can't leave it as it is -- we need to remove or upgrade it
[12:16] <dholbach> pitti_, the Openismus folks seem to have it updated to 1.20.1 in their ppa
[12:16] <dholbach> is that the latest & greatest?
[12:16] <dholbach> yes, looks like it
[12:16] <micahg> dholbach: pitti_: goocanvas 2.0 is in progress in Debian
[12:17] <dholbach> micahg, do you know where it's currently sitting?
[12:17] <pitti_> dholbach: yes, it is: http://ftp.gnome.org/pub/GNOME/sources/glom/1.20/
[12:17] <micahg> dholbach: mentors I think
[12:17] <dholbach> alright - I'll have a look
[12:17] <pitti_> ah, we need those libraries first
[12:18] <micahg> right, I think that's the main reason it wasn't updated last cycle
[12:18] <dholbach> 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] <ogra_> if you teach them all there wont be any fish left though
[12:19] <ogra_> :P
[12:19] <dholbach> ogra_, we're not there yet :)
[12:19] <ogra_> :)
[12:29] <seb128> dholbach, pitti_: hey (was at lunch)
[12:29] <dholbach> hey seb128
[12:30] <seb128> 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] <dholbach> seb128, I'll CC you
[12:30] <dholbach> just writing the mail
[12:30] <seb128> dholbach, pitti_: we (desktop) will find some time to update gda, glom, etc
[12:30] <seb128> dholbach, thanks
[12:31] <dholbach> 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] <dholbach> (hopefully) just a matter of trimming the changelog entries and uploading
[12:31] <seb128> dholbach, well, I first want to ask murray what version should go in the LTS
[12:31] <dholbach> 1.20 I guess is a stable version
[12:31] <dholbach> but yeah, I'll mention it in the mail as well
[12:32] <seb128> dholbach, I guess it will requite updates for some other stuff like goocanvas libgda, gegl, etc
[12:32]  * dholbach nods
[12:32] <seb128> dholbach, thanks, or just email what you wanted and I will follow up with my questions on what version he wants
[12:47] <doko> 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] <lool> 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] <lool> pitti_, cjwatson: Essentially we can't upload the squid source and binaries in Ubuntu anymore, so I think we should removeit
[12:50] <Daviey> lool: What upload are you planning?
[12:50] <cjwatson> lool: sure, file a bug and subscribe ubuntu-archive
[12:50] <cjwatson> (or subscribe us to an existing bug)
[12:51] <cjwatson> I don't do source removals outside the context of a bug normally, as they need an audit trail
[12:53] <infinity> lool: It's already planned for removal.
[12:53] <infinity> (Was discussed here a couple times over the last few days)
[12:54] <lool> Daviey: No upload
[12:54] <lool> cjwatson: Ok
[12:54] <lool> infinity: Oh ok thanks
[12:55] <lool> infinity: I couldn't find a removal bug against squid, is it against ubuntu?
[12:55] <infinity> I suppose it's hyproctical of me to complain about people uploading and filling the buildd queues after my weekend, isn't it?
[12:55] <infinity> lool: Oh, no, there's no bug filed.  Please do.
[12:56] <infinity> lool: It's just been discussed a few times and concensus met that, yes, we want to remove it, not modify it.
[12:56] <infinity> (Honestly, I would have just removed it on the weekend, but I've been frying larger fish)
[12:57] <Daviey> Using the grill is more healthy.
[12:58] <ogra_> heh, and you seem to have scared away the fish_
[12:59] <doko> Daviey, Dave Waker?
[13:00] <infinity> ogra_: That was odd timinig, wasn't it?
[13:00]  * ogra_ liked it :)
[13:00] <lool> filed LP #900741
[13:00] <lool> doko, infinity ^
[13:00] <infinity> Yeah, AA will get to it.  No big rush.
[13:02] <infinity> Daviey: Does the squid transitional package actually migrate configs sanely and such?
[13:04] <Daviey> infinity: believe so.. i'd need to check.
[13:04] <Daviey> doko: wassup?
[13:06] <infinity> Daviey: I think doko just realised who you are.  After years on IRC.
[13:06] <infinity> Daviey: Don't you feel loved?
[13:06] <ogra_> haha
[13:06] <Daviey> infinity: No, i think he realised i am not who i claim to me in From: fields of email addresses :)
[13:07] <Daviey> (i sent him an email, with a typo in my From)
[13:07] <infinity> Ahh.
[13:07] <infinity> Well done.
[13:07] <cjwatson> You write From: by hand?  What is this, 1990? :-)
[13:07] <Daviey> cjwatson: You clearly need to look at my headers closer :)
[13:08]  * cjwatson blinks at User-Agent.
[13:08] <ogra_> heh
[13:08] <cjwatson> What impresses me is that it's also GPG-signed ...
[13:08] <doko> heh
[13:09] <doko> good, that he just left out a letter, and didn't miss-type it =)
[13:09] <Laney> doko: the bony fingers of RAOF yet again!
[13:32] <soren> Daviey: Where can I see this infamous e-mail?
[14:04] <Laney> doko: -2 uploaded
[14:24] <tremolux> pitti_: re: software-center, thanks and sorry for the confusion, I updated Vcs-Bzr: in trunk to fix that
[14:37] <ogra_> slomo, pingaling
[14:45] <smoser> i'm interested in seeing what other people think about bug 726635
[14:45] <smoser> whoops
[14:45] <smoser> wrong bug.
[14:45] <smoser> bug 724601
[14:46] <smoser> alexbligh, there suggests we could add an empty /etc/udev/rules.d/75-persistent-net-generator.rules, which would then override the persistent-net rules for udev entirely.
[14:46] <smoser> what do others think of that?
[14:47] <smoser> i'm interested both in "you should/should-not do that because..." and "that will break because..."
[14:55] <doko> cnd, utouch-qml ftbfs, please see https://launchpad.net/ubuntu/+source/utouch-qml/1.0.4-0ubuntu1/+build/2968980
[14:57] <Laney> is there a bug about being able to subscribe to ftbfs?
[14:59] <doko> infinity, ^^^ I think you once did subscribe me to these reports
[15:00] <doko> Laney, you should get email, if one of your own uploads ftbfs. else you could use the ftbfs ubuntuwire pages
[15:00] <Laney> yeah, i'd rather not have to poll
[15:00] <Laney> also api syncs still don't mail about ftbfs
[15:00] <Laney> afaik
[15:00] <ogra_> ubuntuwire lists them though
[15:01] <tumbleweed> Laney: there's a bug for the api syncs bit, IIRC
[15:01] <infinity> doko: We used to send them all to a list, didn't we?
[15:01] <Laney> there is
[15:01] <infinity> doko: It's been a long time.
[15:01] <infinity> doko: If you still get them all, check your headers...
[15:02] <doko> launchpad-buildd-admin
[15:07] <slangasek> micahg: I would certainly prefer Pre-Depends: multiarch-support
[15:56] <cnd> doko, thanks, I'll take a look
[17:06] <pitti_> good night everyone!
[17:06] <pitti_> jamespage, wendar: FYI, my server is still down, so I won't have IRC scrollback for the night; mail is down, too :( (but should be back in a few hours)
[17:07] <wendar> pitti: okay, I won't send you merge requests until tomorrow :) good night!
[18:29] <micahg> slangasek: can I say I'm shocked that you prefer that version  :)
[18:34] <slangasek> micahg: as the author of both the wiki page and the debhelper support, I would wonder why ;)
[18:47] <Cas> something changed with python in ubuntu oneiric that has broken the namespaces for our plugins and i cannot find a solution?
[18:48] <micahg> Cas: partial dh_python2 conversion?
[18:49] <Cas> this is before packaging, just building the plugin
[18:50] <micahg> slangasek: so, I should take Pre-Depends: multiarch-support and tell people who use Pre-Depends: ${misc:Pre-Depends} in Ubuntu directly not to?
[18:51] <ScottK> Is the package publisher broken?  I've got a build that finished 2 hours ago still showing pending.
[18:51] <infinity> ScottK: Not so much broken as "not running".
[18:51] <Cas> here is what ive encountered: http://dpaste.com/hold/666142/
[18:51] <ScottK> OK.  On purpose?
[18:51] <infinity> ScottK: We had an oops with the librarian, publisher is on hold while things get un-oopsed.
[18:52] <ScottK> Ah.  Thanks.
[18:53] <infinity> micahg: Doesn't misc:Pre-Depends populate with useful things like dpkg-with-xz-support and such?
[18:53] <infinity> (If you build your debs with xz)
[18:53] <broder> how could it? don't you set xz with dh_builddeb?
[18:54] <broder> (i.e. after gencontrol runs)
[18:54] <micahg> infinity: not that I know of, but I think the idea was to be able to add other magic there as well eventually
[18:54] <infinity> Hrm, fair point.  But I could have sworn I saw mention of such madness earlier. :P
[18:55] <broder> hmm. looks like dh_installdeb has new <package>.maintscript support which injects a pre-depends on dpkg (>= dpkg-maintscript-whatever-version)
[18:56] <broder> but that and multiarch-support are the only things that grep misc:Pre-Depends $(dpkg -L debhelper) finds
[18:56] <broder> (in fairness, that's pretty useful, but i don't know if i've seen anyone using it yet)
[18:57] <micahg> infinity: ^^ you're right :)
[18:58]  * micahg starts using that on his own packages
[19:11] <cjwatson> ScottK: right, what infinity said - FWIW it's apparently a hardware problem, and it will be OK once the RAID array rebuilds, but for a while there (possibly still) several hours' worth of data was missing from the librarian, and we didn't want to inflict that state on the publisher
[19:12] <ScottK> cjwatson: Thanks.  Might be worth a mention in /topic.
[19:12] <infinity> cjwatson: Definitely still.
[19:12] <cjwatson> oh, yes, I forgot it wasn't in the topic here
[19:12]  * ScottK did look there before asking ....
[19:33] <chrisccoulson> infinity, thanks for fixing this problem, but it should have been done as a merge proposal: http://launchpadlibrarian.net/86490977/firefox_9.0~b4%2Bbuild1-0ubuntu1_9.0~b4%2Bbuild1-0ubuntu2.diff.gz
[19:33] <infinity> chrisccoulson: I already talked to micahg about it.
[19:33] <chrisccoulson> also, i generally avoid doing single change, single architecture uploads like that, as it's essentially a no-change rebuild on i386, amd64 and armel (which takes more than a day now)
[19:34] <chrisccoulson> in addition to that, it caused us to push the same breakpad symbols to mozilla's server twice for no reason, which is a waste of their space ;)
[19:34] <chrisccoulson> we get regular (weekly) firefox releases to fix things like this already :)
[19:35] <infinity> To be fair, I would have just committed it to your packaging branch, if I could.
[19:35] <infinity> I'm going to point out that it's a bit annoying for core-dev to not be able to, despite us obviously being able to upload the package. :P
[19:36] <chrisccoulson> right :)
[19:36] <infinity> Either way.  It was part of an arch bootstrap.  Not an every day thing.
[19:36] <infinity> I look forward to annoying you siilarly in 6-12 months with arm64. ;)
[19:36] <infinity> similarly, too.
[19:36] <chrisccoulson> we have a significantly different workflow from everyone else though, which is why we don't have everybody committing to our branches :)
[19:36] <infinity> I don't think "everybody" would.
[19:37] <cjwatson> Core is full of things that are special-snowflake in one way or another.  Part of the reason core-dev has a high bar is that you're supposed to be able to recognise that.
[19:39] <infinity> cjwatson: Oh, was there a specific reason that omap4/armhf support in d-i seems to be slightly incomplete, or was it just a quick pass?
[19:39] <infinity> cjwatson: (Missing s/armel/armel armhf/ on the u-boot-*-panda bit, for instance... Don't recall if there was other stuff)
[19:40] <cjwatson> infinity: I didn't have an omap4 kernel yet, so couldn't build the omap4 flavour, so I left out the omap4-related build-deps.
[19:40] <cjwatson> infinity: Feel free to add them in if it's buildable nw.
[19:40] <cjwatson> *now
[19:40] <infinity> cjwatson: Well, not buildable *now*, but will be after the publisher gets to run.
[19:41] <infinity> cjwatson: And we'll need a new d-i anyway to pull in my new libc-udeb.
[19:41] <infinity> cjwatson: Cause, apparently, I hadn't thought about the fact that eglibc mindlessly smooshes /lib/*/*.so* into /lib
[19:42] <infinity> cjwatson: Turns out, that doesn't work so well when your interpreter lives in /lib/<triplet>/
[19:42] <cjwatson> Hah, yes.  I wasn't really expecting it to be usable quite yet anyway.
[19:42] <infinity> That was the only bug.
[19:42] <cjwatson> Wow.
[19:42] <infinity> Tobin moved the file manually in his initrd, and the installed did instally things.
[19:42] <cjwatson> Even boot loader installation worked?
[19:43] <infinity> installer*
[19:43] <infinity> As far as I know, yep.
[19:43] <cjwatson> (Well, whatever you call the stuff partman-uboot and flash-kernel conspire to do)
[19:43] <barry> @pilot in
[19:43] <infinity> He ran into some userspace issue after first-boot, but that's not d-i's fault.
[19:43] <cjwatson> Did somebody fix flash-kernel?
[19:43] <infinity> Well, it was uploaded for armhf.
[19:43] <infinity> So, sure?
[19:43] <infinity> Did it need fixing?
[19:43] <cjwatson> We might even be able to get ubiquity working then.
[19:43] <infinity> I'd assume it never asked about dpkg arch anyway.
[19:43] <cjwatson> I thought it had some arch hardcoding, but didn't look too closey.
[19:44] <infinity> Since it was arm-only.
[19:44] <cjwatson> or even with typing.
[19:44] <cjwatson> ./debian/control:12:Architecture: arm armel armeb
[19:44] <cjwatson> I'm assuming that wanted fixed :-)
[19:44] <cjwatson> Wow, my tree dates from natty, *cough*
[19:44] <infinity> Oh, yeah.  debian/control was fixed.
[19:46] <infinity> When the publisher comes back to life, I'll regen ubuntu-meta (assuming we've picked up anything new), and do some preinstalled builds for giggles.
[19:46] <infinity> All we're missing is libreoffice, and, well, who cares?
[19:47] <cjwatson> Fastest bootstrap evah.
[19:47] <cjwatson> Apart from the bits I didn't see.
[19:47] <infinity> Not from my perspective. ;)
[19:48] <infinity> But once I hit the archive, yeah, it was quick.
[19:48] <cjwatson> That's because you didn't have to timeshare on N900s.
[19:48] <infinity> *cough*
[19:48] <infinity> I sold my last N900 to Sledge.
[19:49] <infinity> I may or may not have employed other phones, however.
[19:50] <cjwatson> How many of them did you set on fire?
[19:50] <infinity> My Panda overheated a few times.  But no actual flames.  Very sad about that.
[19:51] <infinity> I did actually promise myself that when the bootstrap was done, I'd find a nice tall building and teach my panda to fly.
[19:51] <stgraber> infinity: millbank tower is kind of nice for that :)
[19:52] <Laney> as demonstrated by Edward Woollard
[19:52] <infinity> stgraber: That's an expensive flight just to throw 200 dollars off a roof.
[19:54] <cjwatson> I think MI5 might look askance at hunks of metal hurtling towards their office.
[19:54] <cjwatson> On the whole possibly not the best idea ever
[19:57] <infinity> cjwatson: That actually makes it more appealing.
[19:59] <cjwatson> Please remind me not to be in the same building at the time
[20:00] <infinity> Some people have no sense of adventure.
[20:00] <cjwatson> Ah, finally managed to set up mawson for something resembling a germinate speed comparison test
[20:01] <infinity> If only mawson was an even vaguely reasonable guage of production speed.
[20:01] <cjwatson> Well, yeah, but I don't have to talk to the database (which IIRC makes a fairly large difference) and I mostly care about checking that this is actually the ~three times faster I expect it to be
[20:02] <cjwatson> Actually it seems to be running germinate at a fairly similar speed.
[20:03] <cjwatson> 18s for the most recent run, *40 == 12mins, give or take.  Close enough.
[20:05] <cjwatson> (This is for https://code.launchpad.net/~cjwatson/launchpad/refactor-cron-germinate/+merge/84624)
[20:06] <micahg> before I stick my foot in my mouth, for the last comment in bug 899315, isn't that the perfect case for dlopen?
[20:14] <slangasek> micahg: oh, sorry - apparently I completely misspoke
[20:14] <slangasek> micahg: I *meant* to say that I prefer Pre-Depends: ${misc:Pre-Depends}!
[20:14] <micahg> slangasek: heh, ok, my hunch was correct then :)
[20:14] <micahg> broder: ^^ can you fix please :)
[20:14] <slangasek> the reason being that this eventually goes away in the future when debhelper decides this dependency is no longer needed
[20:15] <broder> micahg: this evening, but yes
[20:15] <micahg> slangasek: right, and it can disappear centralized at the beginning of a cycle
[20:15] <micahg> broder: sure , no rush
[20:15]  * broder pulls his patches from the sponsor q for the time being
[21:14] <Daviey> smoser`: Are you currently looking at cobbler-devenv?
[21:14] <Daviey> with lxc?
[21:14] <barry> does anybody know what "Unhandled exception processing upload: 26130185" means?  I tried to dput an update to gftp, and all i get back is a rejection message with that message in it
[21:15] <cjwatson> rejection at upload time or at dput time?
[21:15] <cjwatson> er, I mean, s/at upload time/by e-mail/
[21:16] <barry> cjwatson: i dput the package which appeared to succeed, and then a little bit later, i got that message in an email from archive@ubuntu.com
[21:16] <cjwatson> hm, yes, I see the rejected package here
[21:17] <cjwatson> http://launchpadlibrarian.net/86795637/fmw5h2ageMsHnQI7HrJvMRHh7kE.txt
[21:17] <cjwatson> I suspect this is fallout from librarian hardware trouble
[21:17] <barry> ouch. i must have missed hearing about that trouble.
[21:18] <cjwatson> because that's it trying to fish the orig out of the librarian and failing
[21:18] <barry> i guess re-uploading won't help.  maybe build w/ -sa and re-upload?
[21:19] <cjwatson> leave it for now
[21:19] <cjwatson> we should be able to flush the rejected upload(s) back into the queue once everything is back to normal
[21:19] <barry> cjwatson: okay, thanks.  i'll note it in my patch pilot report
[21:19] <cjwatson> actually it's a bit weird that that's missing because the orig shouldn't have been in the time window affected; I'll ask ops
[21:23] <cjwatson> barry: I suspect trying to work around it with -sa wouldn't help anyway, since it still has to compare it against what's in the librarian; but it doesn't sound like an experiment I'd want to run
[21:24] <barry> cjwatson: fair enough.  i guess that means there's not much i can do on my side...
[21:24] <cjwatson> probably not, sorry
[21:24] <barry> k, thx
[21:25] <barry> i guess we'll see if any other uploads hit the same problem
[21:25] <cjwatson> it'll be easy enough to grep for similar failures in the logs and retry appropriately
[21:25] <broder> SpamapS: could you take a quick look at bug #886205? based on my understanding of the issues, it sounds like a dup of bug #580319, but i'd like someone with more domain expertise to double-check
[21:30] <SpamapS> broder: well.. yes and no. His firewall script still may not work right.. since the order is still in hardware detection order, not /etc/network/interfaces order
[21:30] <broder> err, right, but his patch is a less evolved version of /etc/init/failsafe.conf, right?
[21:31] <SpamapS> broder: indeed it is
[21:31] <SpamapS> broder: (and a wrong one at that, as networking does not mean that all those interfaces were actually around when it ran 'ifup -a')
[22:13] <bdrung> tumbleweed: the script fails due to wrong option
[22:13] <bdrung> tumbleweed: the output isn't structured nicely
[22:16] <tumbleweed> bdrung: will look in a minute
[22:17] <bdrung> tumbleweed: and it contains some merge markers
[22:24] <tumbleweed> bdrung: just pushed lp:~stefanor/ubuntu-dev-tools/native-sync-sponsorship which should work (I think) when bug 827555 has been QA-ed
[22:31] <bdrung> tumbleweed: the OptionGroup warning should exclude fakesyncs
[22:33] <tumbleweed> bdrung: well, they aren't part of that group
[22:34] <bdrung> tumbleweed: so --fakesync does not require --no-lp?
[22:35] <bdrung> tumbleweed: "Did Ubuntu modify this (and mark the version appropriately?" -> missing )
[22:36] <bdrung> tumbleweed: i would try to split long lines into two commands.
[22:36] <bdrung> e.g. "ubuntu_source = get_ubuntu_srcpkg(src_pkg.source, release.split("-")[0])" -> series = release.split("-")[0]
[22:37] <bdrung> ubuntu_source = get_ubuntu_srcpkg(src_pkg.source, series)
[22:37] <tumbleweed> bdrung: --fakesync implies --no-lp
[22:37] <bdrung> and second: "subprocess.Popen(cmd, stdout=subprocess.PIPE).communicate()[0]" -> process = subprocess.Popen(cmd, stdout=subprocess.PIPE)
[22:37] <bdrung> process.communicate()[0]
[22:42] <bdrung> tumbleweed: you may want to adjust the man page too
[22:42] <tumbleweed> indeed
[22:44] <bdrung> tumbleweed: --help doesn't tell you that --facesync does a local sync (and is the correct way to do it)
[22:48] <tumbleweed> bdrung: --help improved. manpage next
[22:50] <bdrung> tumbleweed: "it will leave a signed .changes file for you to upload." could be also added to --no-lp
[22:50] <tumbleweed> yeah, just thought that too
[22:56] <bdrung> tumbleweed: W: ubuntu-dev-tools: debian-changelog-line-too-long line 29
[23:11] <bdrung> good night
[23:16] <bdrung> tumbleweed: found nothing to complain any more. you can merge your branch. besides that, sponsor-patch should be modified to use the new feature of syncpackage (code is there and just needs little adjustment)
[23:16] <bdrung> now really good night
[23:16] <tumbleweed> yeah, that should happen
[23:16] <tumbleweed> I won't merge it until the feature is live
[23:24] <psusi> shouldn't udisks --inhibit prevent the desktop from fscking with new mounts that show up?  I'm trying to run the parted test suite and the tests are failing because gnome is fscking with the temp test mounts
[23:27] <broder> i don't see how anything gnome could fsck - it all runs unprivileged
[23:27] <barry> smoser: ping
[23:27] <psusi> by fsck I mean generally fucking with ;)
[23:29] <psusi> like looking for cat photos or music albums or whatever it does when it sees a new disk.. it keeps popping up and trying to tell me things about the new fs that was mounted in some deep tmp dir during the tests, even though I use udisks --inhibit
[23:29] <broder> but the point stands. gnome can't do anything to anything without udisk-daemon agreeing to it, so start there
[23:31] <psusi> hrm... killing udisks didn't help either
[23:31] <broder> i would assume that its udev rule hits it over dbus so it gets autospawned
[23:32] <psusi> I meant kill -STOP
[23:32] <broder> well then it must be the udev rules
[23:34] <psusi> I thought udisks was the bridge between udev and gnome?
[23:34] <psusi> if it is frozen... gnome shouldn't be doing anything right?
[23:38] <psusi> bwahah!  suck it gnome!  wrapped make with unshare -m and nobody else gets to see the new mounts
[23:39] <broder> oh, if the tests are mounting things i don't think that's mediated by udisks
[23:39] <barry> well, it's dinner time so...
[23:39] <barry> @pilot out
[23:56] <SpamapS> broder: were you going to mark bug 886205 a dupe of bug 580319 ?
[23:57] <broder> SpamapS: i was planning to take another look at it this evening while holding out silent hope that you'd deal with it first :-P