[00:09] <micahg> ScottK: did we ever get approval for -backports opening at feature freeze?
[00:20] <micahg> \o/ I got CMake and pkg-config to dance together
[00:37] <RAOF> Wooooooo!
[00:43] <TheMuso> /c/c
[05:23] <pitti> Good morning
[05:23] <pitti> tjaalton: aah, failsafe-x
[05:23] <RAOF> pitti: Good morning!
[05:54] <didrocks> good morning
[05:57] <pitti> superm1: mythbuntu-live-autostart should be in beta-1?
[05:58] <pitti> superm1: is ubiquity plugin migration to pygi necessary to work with the current ubiquity?
[06:11] <pitti> slangasek: portmap wants to go to universe, do you know whether that's intended?
[06:24] <infinity> pitti: Seems that rpcbind has replaced it?
[06:30] <pitti> ah
[06:31] <infinity> (seems like an odd wheel to have reinvented, but whatever, it's not like any of us particularly loved portmap)
[06:31] <pitti> ah, removed from Debian as well, I'll follow suite
[06:31] <pitti> "suit"
[06:32] <infinity> Oh, they removed portmap completely?  Interesting.
[06:32] <pitti> http://packages.qa.debian.org/p/portmap.html
[06:32] <infinity> Indeed.
[06:32] <infinity>    portmap |    6.0.0-3 | source, alpha, amd64, armel, hppa, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
[06:32] <infinity> Closed bugs: 567502
[06:32] <infinity> ------------------- Reason -------------------
[06:33] <infinity> ROM; superseded by rpcbind
[06:33] <infinity> ----------------------------------------------
[06:33] <infinity> ubottu: That was a Debian bug, you silly bot.
[06:59] <dholbach> good morning
[07:08] <ion> that.
[07:40] <pitti> superm1: ah, saw your ping on #u-release, nevermind
[07:59] <RAOF> slangasek: Yo!  Question re: -dev packages and multiarch - /usr/include isn't treated specially, is it?  Meaning that -dev packages which ship /usr/include (ie: everything) can't be Multi-Arch: same?
[08:05] <doko> RAOF, the can, as long as the files are the same on any arch
[08:05] <RAOF> doko: Thanks.  I might see if I can make the documentation clearer, then.
[08:28] <RAOF> doko: http://wiki.debian.org/Multiarch/Implementation says “Although Debian policy currently doesn't allow -dev packages to be Multi-Arch: same…”.  Is that the documentation being wrong, referring to the case when there are arch-specific files in /usr/include, or something else? :)
[08:31] <doko> RAOF, currently you cannot install them, but afaik, they are accepted into the archive
[08:33] <RAOF> doko: Is this in Debian or Ubuntu?  My empirical testing suggests that i386 and amd64 -dev packages of libpciaccess are perfectly happy to be installed.
[08:36] <RAOF> Ah, but not on Debian.
[08:45] <doko> RAOF, dpkg is still missing the bits
[08:47] <RAOF> Right; as my experimental schroot has taught me.  But a -dev package marked as Multi-Arch: same will not necessarily be a violation of policy?  Documentation fixing time :/
[08:59] <doko> RAOF, afaik, no. there are already lots of those merged back
[09:41] <pitti> ev: do you think it's ok to disable the xklavier bits in ubiquity for now?
[09:41] <pitti> ev: (not necessary for b1)
[10:01] <ogra_> Sweetshark, http://paste.ubuntu.com/677114/ is that already known (that armel, seems to affect all subarches) ?
[10:01] <ogra_> s/that/that's/
[10:06] <pitti> ogra_: yes, LibO FTBFSed again after 2 days of buildig :/
[10:06] <ogra_> ah, k
[10:07] <ogra_> should we unseed it to the milestone on arm ?
[10:07] <pitti> ogra_: it doesn't seem to be part of ubuntu-desktop on arm, is it?
[10:07] <ogra_> building it again will makes it hard to release in time i guess
[10:07] <ogra_> *make
[10:07] <ogra_> arm uses the same seed as everyone else i dont think we special case libO
[10:12] <pitti> ogra_: ubuntu-desktop isn't shown as uninstallable on arm, that's why I thought it doesn't break images
[10:12] <ogra_> intresting
[10:12]  * ogra_ goes to check the seeds
[10:12] <ogra_> desktop builds definitely fail due to it
[10:13] <pitti>  * (libreoffice-writer) [i386 amd64 powerpc]
[10:13] <pitti> and similar for other libo-* packages
[10:15] <pitti> ogra_: I have preinstalled builds in the queue, waiting for new ubuntu-desktop
[10:15] <ogra_> weird
[10:15]  * pitti checks previous logs
[10:15] <ogra_> i wonder what pulls them in
[10:15] <pitti> last successful build is from 0822
[10:15] <ogra_> yes, i know
[10:16] <ogra_> archive skew ...
[10:16] <ogra_> first telepathy-glib was out of sync with x86, then unity broke
[10:16] <pitti> ah, I see in http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu-omap4/20110829/livecd-20110829-armel.out
[10:17] <pitti> live: * libreoffice-help-en-us
[10:17] <pitti> could it be that one?
[10:17] <pitti> ogra_: i. e. do the preinstalled ones use the live seed?
[10:17] <ogra_> yes
[10:18] <ogra_> when was that added ?
[10:18] <pitti> Depends: libreoffice-writer | language-support-translations-en
[10:18] <ogra_> seems the 22th build was fine
[10:18] <pitti> l-s* doesn't exist any more
[10:18] <pitti> ogra_: so let's update the live seeds to exclude that from armel?
[10:18] <pitti> I don't think we'll get an armel LibO build plus testing by Thursday
[10:19] <pitti> ogra_: committed
[10:19] <pitti> now, I think we need two publisher cycles for that
[10:19] <pitti> we need a main upload for this, /me looks
[10:20] <ogra_> right, well, we need a bunch of other changes anyway,  linaro changed the bootloader conmpletely for omap4
[10:20] <ogra_> dont bother to do testbuilds yet, i will need to do a set of uploads during the day
[10:20] <pitti> ogra_: ah, ok; thanks, un-queueing then
[10:20] <pitti> ogra_: shall I remove the other preinstlaled ones for server/kubuntu as well then?
[10:21] <pitti> (from the tracker, I mean)
[10:21] <ogra_> (namely i should have to do d-i, flash-kernel and debian-cd changes (and i hope thats enough, i dont know about any other fallout, but you never know)
[10:21] <ogra_> kubuntu built ?
[10:22] <pitti> might fail, I currenlty have a build running
[10:22] <ogra_> yes, remove all omap4 builds, they wont boot atm
[10:22] <ogra_> omap3 should be fine
[10:23] <pitti> ogra_: ok, disabled omap4 for server and netboot
[10:23] <ogra_> thx
[10:23] <pitti> ogra_: server omap4 built, yes: http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110829/
[10:23] <ogra_> yeah, but wont boot either
[10:23] <ogra_> the first stage bootloader is gone
[10:23] <pitti> ok, then I'm cancelling the kubuntu-mobile build, too
[10:24] <pitti> kbuutnu daily-preinstalled failed
[10:24] <ogra_> yeah, thats a kde thing i think
[10:24]  * ogra_ normally doesnt look at the kubuntu builds, but i think there is still stuff out of sync 
[10:25] <pitti> ogra_: ok to add http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20110829.1/ to the tracker?
[10:25] <ogra_> yep
[10:25] <ogra_> did infinity enable x86 builds already for it ?
[10:25]  * ogra_ checks
[10:25] <ogra_> hmm, no
[10:26] <pitti> ah, kubuntu failed due to libo, too
[10:26]  * pitti fixes seeds
[10:29] <pitti> done
[10:29] <ogra_> thanks
[10:29] <pitti> ogra_: but I guess the kubuntu images are waiting for the very same bootloader changes, so I'll wait for these with the rebuild
[10:29] <ogra_> right
[10:30] <ogra_> well, omap should build and work, just omap4 not
[10:30] <ogra_> i wonder if we should disable ac100 and mx5 completely for now
[10:30] <ogra_> they steal buildd time and delay the actual images we release
[10:31] <pitti> yeah, they double image building time, as it seems
[10:32] <ogra_> right
[10:32]  * ogra_ goes and changes cdimage
[10:34] <ogra_> disabled, future builds will only build omap/omap4 now
[10:50] <Sweetshark> pitti: "Err http://ports.ubuntu.com/ubuntu-ports/ oneiric/main libpoppler-dev powerpc 0.16.7-2ubuntu1  404  Not Found
[10:50] <Sweetshark> pitti: "Err http://ports.ubuntu.com/ubuntu-ports/ oneiric/main libpoppler-dev powerpc 0.16.7-2ubuntu1  404  Not Found
[10:50] <Sweetshark> and lots more still on davis
[10:51] <Sweetshark> I thought testing it on ppc might be faster as armel will again take 3 days to get to the possible breaker ...
[10:52] <Sweetshark> pitti: ah, hmm, I seem to be allowed to do an update on that machine
[10:55]  * Sweetshark installs half the world on porter-ppc
[11:01] <jtaylor> is this the correct path for multiarch -dbg libraries? /usr/lib/debug/usr/lib/x86_64-linux-gnu/
[11:01] <jtaylor> e.g. libxss1-dbg has it
[11:09] <Sweetshark> pitti: k, building on amd64 and ppc again
[11:15] <jtaylor> problem solved in debian-dev, path is correct
[11:24] <pitti> Sweetshark: ah, "sudo apt-get update" works in the porter dchroots? nice
[11:25] <Sweetshark> pitti: IIRC it did not in the armel one when I last tried. But it did in the ppc one.
[11:29] <janimo> ogra_, who is working on the d-i armel fix? (u-boot.bin renamed for omap4)
[11:29] <ogra_> janimo, lets see, we might not need a d-i change, i just finished the debian-cd one and was about to ask pitti for a testbuild
[11:30] <ogra_> i think the d-i scripts just deal with the MLO binary that the post-boot script extracts
[11:30] <janimo> ogra_, great
[11:30] <ogra_> so we might only need to change that bit (which i just did)
[11:30] <ogra_> i have to check the code again but it might be that this two line chaneg was enough
[11:30] <Sweetshark> pitt
[11:32]  * Sweetshark just decided to throw away the old LO packaging completely for ubuntu-p ... we have new repos anyway so that will make stuff a lot easier ... 
[11:49] <cjwatson> infinity: wheel reinvention> portmap was rather fundamentally unable to do IPv6, AIUI
[11:52] <doko> ERROR: The following files could not be found:
[11:52] <doko> ERROR: File not found: libgcc_s.so.1
[11:52] <doko> ERROR: File not found: libstdc++.so.6
[11:52] <doko> Sweetshark, ^^^
[11:52] <Sweetshark> pitti: at least the first breaker (in sal) vanished on ppc (not really a surprise, it helped on armel too). Now it is up to what happens in instsetoo_native ...
[11:52] <Sweetshark> doko: known issue
[11:53] <doko> Sweetshark, well, keep the proper files there, they don't hurt, if the linker script is installed?
[11:56] <Sweetshark> doko: im currently trying a build with --without-system-stdlibs for ppc and armel as the existence of the linker script pretty much puts the whole exercise of packaging a .so from the system ad-adsurdum,
[11:57] <doko> Sweetshark, no, wrong. you don't package the linker script, apparently only the shared lib
[11:59] <doko> Sweetshark, btw, did you change the ix86 builds to build with -Os by intent?
[12:00] <Sweetshark> (if you have a linker script that tells you to link against a static libs too, and you only package the dyn lib, but not the static libs, your not portable anyway. besides anyone creating c++ extensions on armel/ppc is out of his mind anyway. _And_ besides that the LO ABI will be horribly incompatible between distros anyway.
[12:00] <Sweetshark> (on non-i386/amd64)
[12:02] <Sweetshark> doko: no. gbuild introduced change maybe?
[12:02] <doko> only if they need the synchronisation helpers
[12:02] <doko> gbuild?
[12:02] <Sweetshark> doko: new build system stuff
[12:31] <ScottK> micahg: No.  I didn't get it together to actually ask yet.
[12:37]  * ScottK waves to barry and wonders if he has power?
[12:41]  * barry waves back to ScottK with a thankful "yes" and wonders the same about him
[12:41] <ScottK> No.  No power.  All else fine though.
[12:43] <barry> ScottK: we were camping last weekend.  the weather was fine in west va (a little rain, but not bad).  no cell service.  we were a little nervous about what we'd find when we got back, but our block was lucky this time.  we're usually the first to lose power and the last to get it back.  my son's school just got power back in the early am for the first day of school
[12:44] <ScottK> No school here today.  Fortunately they canceled all of them so the middle child can watch over the youngest.
[12:45] <barry> moco (apparently) changed their policy this year.  they don't close the whole county for a couple of schools.  we'll see what happens when it snows. ;)
[12:46] <ScottK> Yeah.
[13:10] <janimo> can someone accept the gmime upload? it is needed for arm images
[13:10] <pitti> Sweetshark: ah, libreoffice-style-andromeda is NBS; I'll remove it from the DVD seeds to unbreak the DVD builds; sounds alright?
[13:12] <janimo> thanks :)
[13:16] <mterry> @pilot in
[13:32] <Sweetshark> pitti: I am checking. there was something about andromeda (being killed or renamed)
[13:34] <pitti> Sweetshark: right, I guess that was deliberate (it's hard to accidentally drop a binary package)
[13:36] <Sweetshark> pitti: not that hard actually with the dark magic behind "./debian/rules control" ;)
[13:36] <Sweetshark> pitti: but yes, drop it.
[13:37] <ogra_> awesome, with the latest oneiric upgrade my laptop gained a second battery !
[13:38] <Chipzz> cool
[13:39] <Chipzz> better not upgrade, you might loose it again :P
[13:39] <ogra_> sadly only in the panel :)
[13:39] <Sweetshark> pitti: andromeda was the old "classic" default theme (aka the buttugly one). Since the upstream default is now tango, no need to keep the ugliness around.
[13:40] <pitti> Sweetshark: ack, thanks for checking
[13:41] <ogra_> GRRR
[13:42] <ogra_> pitti, my build is broken
[13:42]  * ogra_ checks why
[13:42] <pitti> what is "your build" here?
[13:45] <pitti> eek, last ubiquity FTBFSed
[13:45] <pitti> so the initial "live/install" chooser is still broken
[13:45] <ogra_> ARGh
[13:46] <ogra_> so they not only moved around the first stage bootloader but also renamed the second stage binary, sigh
[13:46] <ogra_> pitti, the omap4 server images you rolled for me
[13:46] <pitti> ev: are you on the ubiquity FTBFS, or need help with this?
[13:47] <ogra_> rsalveti, any idea why u-boot.bin was renamed ?
[13:49] <doko> didrocks, clutk has a b-d on gir1.0-pango-1.0, which cannot be satisfied. what should be done with the package?
[13:50] <cjwatson> pitti: it's a bank holiday today and he hasn't been around; I'm trying to find time to have a look but have other things I should be doing, so have SMSed him
[13:50] <pitti> cjwatson: ah, thanks; I just checked the holiday calendar, but it wasn't there
[13:51] <didrocks> doko: the arm team was the last clutk user AFAIK, we don't use it since 11.04 for unity
[13:51] <cjwatson> yeah, people don't always fill in national holidays
[13:52] <tumbleweed> doko: did anyone point you to bug 836246? (I don't know if we should be doing an rm in postinst or if it's a bug in ldconfig)
[13:55] <cjwatson> pitti: ev is unavailable today, we'll see what we can do ...
[13:56] <pitti> cjwatson: ok; at worst we have to release-note it, i. e. that the desktop CD boots straight into the live system
[13:56] <doko> tumbleweed, looking
[13:56] <cjwatson> I think that's a pretty bad worst; there are several bug fixes backed up behind that build failure as well
[13:59] <doko> tumbleweed, I'll remove it in the postinst
[13:59] <tumbleweed> doko: thanks
[14:01] <superm1> tests are what's failing, maybe just turn 'em off to get it through the FTBFS and re-enable after beta
[14:05] <pitti> superm1: the "invalid literal" ones are test suite artifacts, not real bugs?
[14:06] <tkamppeter> pitti, hi
[14:06] <pitti> hey tkamppeter
[14:07] <doko> didrocks, ogra_ : please have a look at this ^^^ I'm neither desktop nor ARM ;-)
[14:07] <mterry> I thought BetaFreeze only applied to main/restricted?  I just had a universe update held for approval.
[14:07] <didrocks> doko: for me, if they don't use it, +1 to remove it
[14:07] <superm1> pitti, i'm not entirely familiar with the test suite, i suppose someone will need to dig further to see
[14:08] <tkamppeter> pitti, I have found a bug in our Ghostscript package. The X11 output does not work, which leads to evince, okular, and similar programs not being able to display PostScript files. I have already found the fix in the "make" command line and I am test-building now. How to proceed to get it into the beta1?
[14:08] <tumbleweed> mterry: launchpad can't only hold main packages for approval. It should get approved fast
[14:08] <tumbleweed> (only main)
[14:08] <mterry> tumbleweed, ah, makes sense.  Thanks!
[14:08] <geser> tumbleweed: s/main/seeded/ ?
[14:09] <tumbleweed> geser: well, that
[14:09] <geser> I still have to remember that we have seeded package in universe too
[14:09] <pitti> tkamppeter: just upload it
[14:10] <pitti> tkamppeter: we'll need to rebuild ubuntu anyway; kubuntu has workign images right now, but we probably need to rebuild them as well for the new ubiquity
[14:13] <doko> didrocks, doesn't help if you don't subscribe ubuntu-archive in bug #705887 :-/
[14:13] <cjwatson> superm1: strongly disagree until we know *why* the tests are failing (by which point we might well have a fix)
[14:13] <cjwatson> superm1: for all we know they're regressions with serious run-time consequences
[14:13] <cjwatson> I'm working on it in spare moments
[14:13] <superm1> cjwatson, true, i suppose especially since these tests didn't have failures in the previous upload and those are all quite small fixes that went into this one
[14:20] <tkamppeter> pitti, I will upload in some minutes.
[14:24] <tkamppeter> pitti, uploaded.
[14:28] <pitti> freeflying: hey, how are you?
[14:29] <pitti> freeflying: I'm currently building Ubuntu Chinese Edition images with full support, but it's too big for 703 MB images
[14:29] <pitti> freeflying: we currently install three fonts, each of which is about 9 MB: ttf-arphic-ukai ttf-arphic-uming ttf-wqy-zenhei
[14:30] <pitti> freeflying: do you think we can drop one of them? that would be enough
[14:31] <sladen> persia: ^^
[14:31] <sladen> ArneGoetje: ^^
[14:39] <doko> tkamppeter, pitti: is flphoto still needed by cups?
[14:40] <doko> you did package it for hardy
[14:57] <doko> didrocks, do you know somebody who would update glom? see bug #749267
[14:58] <didrocks> doko: I know of noone using glom on the desktop side and so able to test it and such
[14:58] <didrocks> doko: maybe drop a message on #ubuntu-motu? some can be interested in it
[14:59] <doko> didrocks, no, just looking through reports
[14:59] <doko> dholbach, ^^^
[14:59] <dholbach> doko, no idea, sorry
[15:00] <tkamppeter> doko, flphoto needs CUPS it is not needed by CUPS.
[15:00] <tkamppeter> doko, what is the problem of flphoto?
[15:01] <dholbach> doko, bhavi seems to have a newer version in a PPA and upstream has what I guess is the newest upstream in a PPA as well - not sure if they build now though
[15:01] <tkamppeter> pitti, ghostscript is uploaded and is waiting for approval.
[15:02] <doko> tkamppeter, bug #770854 please subscribe to the package bug reports
[15:02] <dholbach> doko, ignore what I said about bhavi - I just noticed it was an older version
[15:02] <dholbach> https://launchpad.net/~openismus-team/+archive/ppa then
[15:04] <tkamppeter> doko, it the flphoto build failure looks like a problem of the tools which handle the translations:
[15:04] <tkamppeter> doko: espmsg: Loading "po/it.po"...make[1]: *** [po/it] Bus error
[15:05] <doko> tkamppeter, fix it
[15:05] <tkamppeter> Anyone has ever seen this Bus error?
[15:07] <pitti> uh, is espmsg a cups specific version of gettext msgfmt?
[15:21] <doko> tkamppeter, else we'll have to remove the binaries from the archive
[15:21] <pitti> freeflying, persia, ArneGoetje: actually we need to free 25 MB, not just 9, sorry (CD build just finished)
[15:22] <pitti> the LibO -l10n stuff plus these three fonts plus sunpinyin is huuge :/
[15:24] <pitti> cjwatson: ^ FYI, I got all the extra cruft (apt indexes, caches, pyc files, etc.) off the ubuntu-defaults-image iso now, so without the full Chinese lang support it comes out as 656 MB
[15:24]  * pitti uploads ubuntu-defaults-builder 0.15 which now produces well-working images with full l10n support
[15:27] <pitti> sunpinyin working well OOTB, yay
[15:54] <tkamppeter> doko, pitti, flphoto depends on libgphoto2-dev and this package cannot be found by my Oneiric box. Is libgphoto2 obsolete? How could the build server arrive at the point of handling the translations?
[15:57] <pitti> tkamppeter: it's libgphoto2-2-dev
[15:58] <pitti> good night everyone
[16:02] <didrocks> pitti: have a good evening :)
[16:27] <slangasek> pitti: yes, portmap can go away now :)
[16:27] <tkamppeter> pitti, thanks.
[16:51] <doko> cyphermox, https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2704441
[16:53] <micahg> there are a few of those
[17:16] <bdmurray> mterry: could you review / sponsor https://code.launchpad.net/~brian-murray/update-manager/apport-dist-upgrade-question/+merge/73266
[17:17] <mterry> bdmurray, looking
[17:18] <mterry> bdmurray, I suspect you'd like to see this in place before beta lands?
[17:19] <bdmurray> mterry: yes as beta means more upgraders
[17:19] <mterry> i.e. you want me to upload despite BetaFreeze
[17:19] <mterry> k
[17:22] <mterry> bdmurray, how does translation work for the ui.yesno question?
[17:22] <mterry> (and that can't be determined programatically?  bummer)
[17:23] <bdmurray> mterry: For all the source package hooks no questions are translated since bugs end up in Launchpad and we prefer them in English anwyay
[17:23] <mterry> bdmurray, fair
[17:25] <mterry> bdmurray, is there an easy way to test this and/or you've run it through it's paces?  Looks fine from code review
[17:26] <bdmurray> mterry: What I've done and you could do is just 'sudo cp debian/source_update-manager.py /usr/share/apport/package-hooks/source_update-manager.py' and then use 'ubuntu-bug update-manager'
[17:26] <bdmurray> mterry: then when the ui question comes up answer yes and check and then no and check
[17:28] <hallyn> how do we feel about absolute paths in scripts and such?  upstart jobs don't use them, but should general scripts?  (for /sbin/ip, ifconfig, etc)
[17:28] <hallyn> Or do we trust that $PATH will be ok for root?
[17:29] <hallyn> kees: ^
[17:29] <kees> for upstart? we assume the path is sane.
[17:30] <hallyn> i'm looking at /etc/qemu-ifup
[17:30] <hallyn> brctl just moved from /usr/sbin/ to /sbin.  Q is is it better to just remove the paths, or fix them
[17:30] <hallyn> I always felt paths are better, but then I didn't used to "control" the distro :)
[17:31] <mterry> bdmurray, uploaded, but naturally waiting on release team approval to move out of upload queue
[17:31] <hallyn> (so as develper of upstream I think you worry more about that)
[17:31] <bdmurray> mterry: great, thanks
[17:32] <mterry> @pilot out
[17:49] <infinity> hallyn: Absolute paths should be avoided in distro scripts.
[17:50] <infinity> hallyn: If the admin wants to replace brctl with his own version in /usr/local/sbin, that's his perogative, and your scripts shouldn't second-guess that.
[17:50] <infinity> hallyn: (Sure, if he breaks things because of it, he gets to keep both pieces, but whatever, absolute paths don't guarantee the correct binary anyway, he could just as easily replace the one in /usr)
[17:52] <infinity> hallyn: I think upstreams got into the habit of abolute paths because of the bad old days of Solaris shipping POSIX binaries outside the usual sane locations, so people started doing configure checks and hardcoding paths.  That's pretty obviously the Wrong Thing in an FHS-dominated Linux world.
[17:55] <tkamppeter> doko, I have fixed flphoto now.
[17:59] <hallyn> infinity: ok, thanks.  Then I'll push my fix as is, beta-freeze-gods allowing
[17:59] <geser> doko: re bug #174851: I found recently a guide (on the debian-devel ML) how to bootstrap mig and gnumach and added it to the bug. Could you perhaps forward that comment to the internal rt ticket so it helps the person who has to deal with it?
[18:03] <doko> tkamppeter, \o/
[18:03] <tkamppeter> doko, are you using flphoto to print photos?
[18:04] <doko> geser, I assume, we'll just use the debian binaries or the bootstrap
[18:04] <doko> tkamppeter, no
[18:11] <tkamppeter> doko, flphoto is in the queue now, only needs to get approved due to the beta freeze.
[18:11] <doko> tkamppeter, thanks!
[18:12] <doko> geser, but if it's not working like that, then please attach the info to the bug report
[18:13] <geser> doko: already done, I've added that info from that mail as a comment to the bug
[18:41] <jtaylor> is there something wrong with the Release file in the main archive? http://paste.ubuntu.com/677386/
[18:52] <slangasek> jtaylor: evidently... yes
[19:37] <slangasek> jtaylor: identified the two mirrors that are out of sync; flagged to IS
[19:37] <jtaylor> thx
[19:51] <mterry> bdmurray, heyo, are you looking after foundations bugs?  Could you see if bug 407862 needs attention?
[19:52] <bdmurray> mterry: yes I'm the defect analyst for them
[20:28] <hallyn> ScottK: I posted a debdiff to fix qemu-kvm bugs #833475, #835355, and #829492.  for freeze exception, do I file a separate 'feature exception' bug, or subscribe the release team to all three bugs?
[20:35] <infinity> hallyn: debdiff looks sane to me.  I'm kinda curious, though, what on earth would be calling /etc/qemu/if* without qemu-kvm installed...
[20:36] <infinity> er, qemu-if*
[20:36] <hallyn> infinity: i think nothing, which is i presume why it's never come up before :)
[20:36] <hallyn> In fact, I never use those scripts in thef irst place
[20:36] <hallyn> (and i use kvm all the time)
[20:37] <infinity> hallyn: I use them.  But yeah, not without qemu machines. :P
[20:37] <infinity> *shrug*
[20:37] <hallyn> well, now that qemu-linaro has its own qemu,
[20:37] <infinity> It's still "correct" to have the dependency live in the same package as the scripts.
[20:37] <hallyn> right
[20:37] <infinity> Upload away, I'll approve the mess.
[20:37] <hallyn> thanks!
[20:38] <hallyn> put'ed
[21:53] <Daviey> Is it just me, or does "chown -R www-data:www-data /usr/share/foo" where foo is the package contents seem bad?
[21:54] <Daviey> (in postinst)
[21:55] <cjwatson> seems silly
[21:55] <soren> Daviey: Somewhat worrisome, yeah.
[21:56] <cnd> I'm trying to run today's daily oneiric iso from a usb stick, but it just hangs during boot
[21:56] <cjwatson> should just ship the files with the right ownership in the .deb, given that www-data is a global static user/group
[21:56] <cnd> I see it failed to load fallback graphics devices
[21:56] <soren> Daviey: Having Apache have write privileges in /usr seems.. Yeah, bad.
[21:56] <cnd> and there's an error from udevd about /run/udev not being writable
[21:57] <cnd> it's just sitting there after it successfully starts CUPS printing spooler/server
[21:57] <cnd> what should I try?
[21:57] <cjwatson> oh, yeah, there's what soren said too :)
[21:57]  * cjwatson is a bit tired
[22:28] <TheMuso> Could anybody with some apt knowledge give me a pointer to what might be the problem causing this bug? https://bugs.launchpad.net/ubuntu/+source/pyatspi/+bug/836798
[22:34] <infinity> TheMuso: That sort of thing it often caused by unresolvable Depends/Conflicts/Breaks loops that apt can't work its way out of.
[22:35] <TheMuso> Hmmmm ok.
[22:35] <infinity> TheMuso: Might want to poke at related packages and see if there's a logical snag there.
[22:35] <cjwatson> IIRC Pre-Depends can induce this
[22:35] <TheMuso> infinity: Yeah, thinking the same now that you mentioned the possible cause.
[22:35] <cjwatson> -o Debug::pkgProblemResolver=true
[22:35] <cjwatson> may help
[22:36] <TheMuso> thanks
[22:46] <RAOF> cnd: Do any of the VTs have a usable console?  Does startx work?
[22:48]  * infinity bangs his head on a desk.
[22:48] <infinity> checking build system type... x86_64-pc-linux-gnu
[22:48] <infinity> checking for ld used by gcc... no
[22:48] <infinity> configure: error: no acceptable ld found in $PATH
[22:49] <infinity> ^-- I beg to differ.
[22:52] <slangasek> TheMuso: the python-pyatspi2 conflicts: on python-pyatspi looks wrong to me
[22:53] <slangasek> TheMuso: oh, no, I see the file conflict; ignore me
[22:58] <slangasek> TheMuso: ok, libatspi2.0-0 and libatspi1.0-0 - why do these conflict?
[23:00] <TheMuso> ah crap yeah, in the early days I think they may have shared files,a nd I forgot to get rid of the conflict. I was looking at the same thing.
[23:02] <TheMuso> Fixing...
[23:08] <cnd> RAOF, when booted into single user mode, I get to the standard menu
[23:08] <cnd> I tried resuming boot, but it just returned back to the same menu
[23:08] <cnd> then I tried netroot
[23:09] <cnd> and I found that lightdm didn't exist (which I found odd...)
[23:09] <cnd> I tried to start gdm, got to low graphics mode, but my mouse didn't work
[23:09] <cnd> kb did, but I couldn't select anything
[23:12] <kees> where did the gnome font thumbnailer go?
[23:18] <RAOF> cnd: Lightdm didn't exist, but gdm did?  That's odd.  And, um, I don't think I'll be much more help from here.
[23:19] <cnd> heh
[23:24] <infinity>   * Nuke aclocal.m4 before we run ./buildconf to ensure we get it
[23:24] <infinity>     regenerated correctly, and we get an up-to-date libtoolization.
[23:24] <infinity>  -- Adam Conrad <adconrad@0c3.net>  Mon,  9 Aug 2004 07:47:46 -0600
[23:24] <infinity> Can I cry now because I had the solution to this problem seven years ago, and someone seems to have dropped it?
[23:25] <infinity> Daviey / doko: The above seems to do more or less the right thing.  I'll test a few different scenarios here to make sure it's not a red herring.
[23:25] <freeflying> pitti: ttf-arphic-ukai ttf-arphic-uming is not necessary for CD
[23:26] <doko> slangasek, ^^^
[23:27] <kees> smoser: say, please see my diff for nagios-plugins 1.4.14-5ubuntu3 and do the same in oneiric please :) that change keeps getting lost in that package, and I have no idea why.
[23:28] <kees> smoser: you'll need to fix up some flawed format-strings too
[23:28] <kees> check_radius.c:214:2: error: format not a string literal and no format arguments [-Werror=format-security]
[23:28] <Daviey> infinity: Well i could not reproduce it locally.. and the archive seems to be rebuilding it OK this time.
[23:29]  * Daviey doesn't like the machine gun approach.. it simply should not work.
[23:29] <infinity> Daviey: It fails 100% here until I modify it.  But it is disconcerting that it's intermittent.
[23:29] <Daviey> infinity: what is your build env?
[23:30] <infinity> Daviey: debootstrap --variant=buildd, bare essential build-deps, shoestring, bubblegum.
[23:30] <infinity> Daviey: (Basically, the same as the buildds)
[23:31] <Daviey> wow, not seen someone use that as their normal workflow for a while.
[23:39] <infinity> Daviey: Anyhoe, if shotgunning it is working for now (ew), I'll go eat some dinner.  But I might upload a proper fix later when I'm sure I can't reproduce it with this change.
[23:39] <infinity> Daviey: The change is correct whether it fixes the problem or not, so...
[23:51] <smoser> kees, was that to me ?
[23:52] <kees> smoser: yup, you merged nagios-plugins and the debian/control change for PIE got lost :)
[23:58] <smoser> indeed i did :-(