[00:11] <broder> slangasek: ok, my initial analysis is that /usr/lib/libconf2-4/gconfd-2 needs to be moved to a new multi-arch: foreign package that libgconf2-4 depends on, but gconfd-2 also links libgconf, so you'd have a circular dependency. so i'm stuck
[00:16] <slangasek> broder: oh.  well, maybe we could have gstreamer-good not depend on gstreamer-gconf, which is a just-merged change anyway
[00:22] <SpamapS> hmm, https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/893420 .. with this bug.. libpst was accidentally demoted to universe in oneiric. How do we re-promote it ?
[00:22] <ubottu> Ubuntu bug 893420 in evolution (Ubuntu Oneiric) "PST import no longer available after update to Oneiric" [Medium,In progress]
[00:23] <broder> slangasek: also, i *think* that corba is intended to be cross-arch safe, but i don't know whether gconf's implementation is or not
[00:24] <slangasek> if it isn't, we can assume that's somebody else's problem
[00:24] <slangasek> it was shipped in ia32-libs for a long while IIRC
[00:25] <broder> it's not in oneiric's ia32-libs
[00:26] <mdeslaur> I don't believe gconf uses corba anymore
[00:26] <broder> is it all dbus now?
[00:26] <mdeslaur> I think so, yes
[00:26] <broder> i thought it used dbus to negotiate a corba...thing. but i could be out of date
[00:27] <mdeslaur> oh, hrm
[00:37] <infinity> SpamapS: How do we re-promote it in oneiric or in precise?
[00:38] <infinity> SpamapS: In oneiric, it would require a new version in updates that we could then promote to main, which is a moderately icky thing to do in a released distro, but we've done it in the past in extreme cases.
[00:38] <infinity> SpamapS: In precise, you just need to make sure it's pulled in by something in main (or seeded), and we'll fix.  Shouldn't need an MIR if it was in main before.
[00:38] <SpamapS> infinity: I believe its already back in main in precise
[00:39] <SpamapS> infinity: the SRU is trying to re-enable the libpst functionality in evolution.. which somehow disappeared. I haven't dug into the issue tho.
[00:39] <infinity> SpamapS: Kay.  So, yeah, fixing is in oneiric requires a new upload.  Because we don't change dists/ in a release pocket.
[00:40] <SpamapS> infinity: makes sense, so allow the no change rebuild into -proposed and then subscribe ubuntu-archive ?
[00:40] <infinity> SpamapS: (ie: we won't ever promote the version that shipped with oneiric, but we could promote one in oneiric-updates, if it's really dire)
[00:40] <micahg> SpamapS: was it done by accident or since Thunderbird is the new mail default?
[00:40] <SpamapS> micahg: I don't know.
[00:40] <infinity> There's also that...
[00:41] <SpamapS> evolution is still in main
[00:42] <SpamapS> whether or not that is intentional, I do not know
[00:42] <micahg> maybe talk to the desktop team?
[00:43] <infinity> It might only still be in main because people ran out of time to hunt down all the rdeps and kick it out.
[00:43] <infinity> So, yeah, possibly worth a talk with the desktop team.
[00:43] <micahg> I think the plan was to keep evo in main at least for oneiric
[00:44] <infinity> Well, there are cute comments on evo-related things in the seeds like:
[00:44] <infinity> ubuntu.oneiric/supported: * libreoffice-evolution # no rdepends any more, noticed too late
[00:44] <infinity> Which makes me wonder if there was an effort to get it out, and time just ran out. :P
[00:45] <infinity> SpamapS: Anyhow.  Assuming it has the blessing of the desktop team to fix it, my above outlined solution would be the answer.
[00:45] <TheMuso> broder: mdeslaur, I am sure gconf can be built with either CORBA, or dbus support, and we use dbus now.
[00:46] <broder> TheMuso: ok, cool. so theoretically it should be multiarch safe, other than the cyclic dependency issue
[00:46] <TheMuso> broder: As one can see from the build deps of gconf, it depends on dbus, and no bonobo stuff.
[00:47] <SpamapS> infinity: i'll punt to pitti
[00:47] <SpamapS> there's plenty more to fix in the SRU queues at the moment. :-P
[00:47] <infinity> Heh.
[00:52] <slangasek> broder: would it work to simply install gconfd-2 to /usr/lib/$arch/libgconf2-4/gconfd-2?  It only gets launched by the lib if it's not already running and we don't care which one gets started, right?
[00:52] <slangasek> this is not ideal, but it would work without a circular dep
[00:52] <broder> i haven't checked, but i assume it gets launched by dbus autospawn
[00:53] <slangasek> I don't think it does
[00:53] <broder> so the full path would have to be in /usr/share/dbus-1/services/blah
[00:53] <broder> gconf2-common ships a /usr/share/dbus-1/services/org.gnome.GConf.service
[00:53] <slangasek> ah, ok
[00:53] <slangasek> you're right
[00:59] <infinity> And, it looks libe libglib2.0-dev has grown an undeclared dependency on libpcre3-dev
[01:00] <broder> i was just about to file a bug on that
[01:05] <infinity> Or just reupload glib2.0 with that added to control?
[01:05] <infinity> libglib2.0-0 has depended on libpcre3 for ages, if anything, it's a bug that the -dev package didn't require pcre-dev until now.
[01:05] <broder> i can't upload it - i'm still just motu
[01:05] <infinity> Oh.
[01:06] <infinity> I'll take the proactive approach and do so.
[01:10] <infinity> broder: Fixed.
=== bladernr_afk is now known as bladernr_
=== dendro-afk is now known as dendrobates
=== EvilJackyAlcine is now known as JackyAlcine
[05:07] <pitti> Good morning
[05:10] <pitti> bdmurray: yes, it's from apport/crashdb/pitti.py
[05:10] <pitti> bdmurray: seriously, I was working on some retracer bug cleanup before and forgot to switch back to my normal LP account
[05:12] <pitti> sladen: seed3ed f-u-f-f-c to server
[05:16] <pitti> broder: generating precise-* pockets on ddebs now
[05:18] <pitti> infinity, SpamapS: "I'll punt to pitti" -> that's for the re-promotion of the accidentally dropped libpst in oneiric? yes, I already told cyphermox that we'll need a no-change rebuild in -proposed in order to promote it
[05:18] <pitti> broder: there now
[05:18] <infinity> pitti: The punting wasn't about that process, but about whether the dropping of pst support may have been intentional due to evolution being demoted as the default mail app.
[05:19] <pitti> infinity: no, it was entirely accidental; evolution is meant to be in main still
[05:19] <infinity> Kay.
[05:28] <pitti> infinity: can you please commit your glib2.0 change to bzr?
[05:28] <infinity> pitti: To a bzr other than ubuntu/glib2.0?
[05:28] <pitti> yes, to lp:~ubuntu-desktop/glib/ubuntu
[05:28] <pitti> what Vcs-Bzr: says
[05:28] <infinity> (We need to stop having all these mismatched ways of doing this...)
[05:28] <pitti> we don't use ubuntu/glib2.0
[05:29] <pitti> it shouldn't even exist
[05:29] <infinity> Yes, why use the branch that auto-imports and stays synced with uploads? :)
[05:29] <pitti> but our requests of not having UDD branches for packages with an explicit Vcs-Bzr: weren't considered
[05:30] <infinity> (And there's no Vcs-Bzr in the package)
[05:30] <infinity> Just the Debian Vcs-Svn.
[05:30] <pitti> keek, who dropped that..
[05:30] <pitti> I'll add it back
[05:37] <pitti> infinity: so, want me to grab the diff from LP and commit it then?
[05:38] <infinity> pitti: Just did.
[05:38] <pitti> infinity: ah, tahnks
[05:39] <infinity> Still, I wonder why people resist the UDD thing.
[05:39] <infinity> It makes life so much simpler for people like me who prefer to just fix source packages. :P
[05:39] <infinity> Cause it keeps the two in sync.
[05:39] <pitti> many reasons
[05:39] <pitti> we actually did try UDD
[05:40] <pitti> but pre-applied quilt patches in bzr are horrific, evil, bad, and wrong
[05:40] <pitti> and everyone gets them wrong
[05:40] <infinity> Yeah, full source + 3.0(quilt) is pretty ugly.
[05:40] <infinity> There used to be an elegant solution for that.
[05:40] <infinity> Many years ago. :P
[05:40] <pitti> you end up with patches auto-reversed with debian/patches/debian-changed, patches not unapplying, etc.
[05:40] <pitti> merge-upstream fails over horribly with pre-applied patches
[05:41] <infinity> Didn't Scott have clever tools, like, in Sydney, that did branch-per-patch magic?
[05:41] <pitti> also, it's a bit pathetic that UDD gets exactly those things in proper revision control which we _don't_ ever want to touch (the upstream bits)
[05:41] <infinity> Would make a lot more sense now with 3.0
[05:42] <pitti> right, that would be a sensible step
[05:42] <infinity> And yeah, I'm not saying UDD is perfect (in fact, I don't use it), I just like the idea of my source uploads being auto-merged into other people's VCS workflows.
[05:42] <pitti> so right now UDD just makes things a whole lot harder than it needs to be
[05:42] <pitti> the debian/ only branches and bzr bd -S is pretty much perfect
[05:42] <infinity> Instead of things getting lost because I didn't learn the VCS flavour of the week, and no one debdiffs against old source before they upload.
[05:43] <pitti> yeah, the dropped Vcs-Bzr: is totally our fault
[05:43] <pitti> it's back now in bzr (but won't upload just for that, the buildds are busy enough already)
[05:45] <pitti> infinity: the irony is, it's still much cheaper for us to deal with the occasional de-sync than routinely using UDD for everything
[05:45] <infinity> pitti: I don't suppose you've tried to convince people to do debian-only in UDD?
[05:45] <pitti> infinity: at first, but I quickly gave that up
[05:45] <pitti> I don't mind having full source trees, they are reasonably fast these days
[05:45] <infinity> The syncing magic is really the only thing I like, I don't really care about the rest. :P
[05:45] <pitti> infinity: but I whined uncountable times to poolie and other guys to pretty please drop teh pre-applied patches insanity
[05:46] <diwic> Having debian/ only branches often leads to stuff like "could not find the upstream tarball", when somebody is working on packaging a new version, but have not yet uploaded that to the archive.
[05:46] <infinity> diwic: Er.
[05:46] <infinity> diwic: If they don't have the orig lying around, then they're going to accidentally build native.
[05:46] <pitti> bzr bd -S gets that all for you
[05:46] <infinity> diwic: I don't see how that's any better.
[05:47] <pitti> it downloads it through debian/watch
[05:47] <diwic> pitti, in the best of worlds, yes
[05:47] <diwic> but maybe one should fixup debian/watch in case it's wrong then
[05:47] <infinity> diwic: Having no tarball is better than accidentally flipping to native.  One's an error message people can learn to deal with, the other is irritating to fix.
[05:48] <pitti> yes, we do that in ~ubuntu-desktop, but they don't tend to change often
[05:49] <diwic> infinity, Eh, I'm not suggesting we do something completely wrong just to remove the error message.
[05:49] <micahg> pitti: the langpacks are built in a PPA and then copied to -proposed, right?
[05:49] <pitti> micahg: no, we'll build them directly in -proposed
[05:49] <micahg> pitti: ah, ok, nevermind then :)
[05:49] <pitti> micahg: we can't do binary copies from normal PPAs to -proposed unfortunately
[05:49] <diwic> I think pitti is right, we should make sure debian/watch is always able to download the orig source
[05:49] <pitti> that would require one of these "blessed" ppas
[05:49] <diwic> (or point to the orig source)
[05:50] <pitti> for debian/ only branches anyway
[05:50] <pitti> that makes them utterly convenient
[05:50] <pitti> debcheckout -a mysrc, bzr bd, there it is
[05:50] <diwic> But that is, unless somebody works with a git snapshot
[05:50] <pitti> yes, of course
[05:50] <diwic> rather than a source tarball
[05:51] <pitti> well, _and_ it isn't in the archive yet
[05:51] <diwic> yep
[05:51] <pitti> bzr bd will first try to download from archive, then from watch, then from get-orig-source
[05:51] <ScottK> Does it look in Debian too?
[05:51] <pitti> no, not right now
[05:51] <pitti> there's no reason why it couldn't, I guess it just didn't come up yet
[05:52] <infinity> Would make some sense.
[05:52] <pitti> in our GNOME world at least, downloading from upstream usually is what we want anyway
[05:52] <infinity> In fact, it would make sense to check Debian right after Ubuntu, to make sure there's no orig skew.
[05:52] <pitti> (for new versions)
[05:52] <infinity> (Cause skew sucks)
[05:59] <slangasek> bdmurray: does your "package already installed and configured" check speak Polish yet? (bug #904082)
[05:59] <ubottu> Launchpad bug 904082 in krb5 (Ubuntu) "package libkrb5support0 1.8.3+dfsg-5ubuntu2.2 failed to install/upgrade: pakiet libkrb5support0 jest już zainstalowany i skonfigurowany" [Undecided,New] https://launchpad.net/bugs/904082
[06:01] <ScottK> I think I filed a bug about that (checking Debian), but I don't recall for sure.
[06:03] <bdmurray> slangasek: no but it will
[06:03] <slangasek> hurray :)
=== abhinav_ is now known as abhinav-
[08:42] <pitti> zul, Daviey: do we want nova-console seeded anywhere? it currently wants to go to universe
[09:00] <jibel> pitti, another 'missing openoffice-dicts' bug 903869
[09:00] <ubottu> Launchpad bug 903869 in openthesaurus (Ubuntu Precise) "mythes-it failed to install: /usr/sbin/update-openoffice-dicts: not found" [High,Triaged] https://launchpad.net/bugs/903869
[09:00] <pitti> bonjour jibel
[09:00] <jibel> pitti, good morning :)
[09:00] <pitti> jibel: thanks, will fix
[09:00] <pitti> darn, I thought I already caught all rdependencies
[09:03] <jibel> pitti, oh, it's not part of openthesaurus
[09:04] <jfi> Hello, actually, for precise should package sync from debian be requested or it is still automatically done?
[09:08] <pitti> jfi: Debian import freeze is Jan 12, so still automatic
[09:09] <jfi> pitti, ok, thanks
[09:10] <pitti> jibel: oh, I know why -- it doesn't depend on dictionaries-common
[09:11] <pitti> jibel: I'll try and start a complete archive grep then; I was hoping I could avoid it
[09:11] <jibel> pitti, I tried the other mythes-* and they install correctly.
[09:13] <doko_> TheMuso, pulseaudio ftbfs on any arch execpt amd64
[09:16] <pitti> jibel: bug 903869 is a hard nut to crack.. could I ask you or jamespage to re-run the main-all test once I did the two changes I mentioned in the bug?
[09:16] <ubottu> Launchpad bug 903869 in mythes-it (Ubuntu Precise) "mythes-it failed to install: /usr/sbin/update-openoffice-dicts: not found" [High,Triaged] https://launchpad.net/bugs/903869
[09:16] <pitti> jibel: how long does that take?
[09:20] <jibel> pitti, sure, it takes 2 hours or so
=== mpt_ is now known as mpt
[09:34] <pitti> jibel: mythes-it fixed, updated dictionaries-common for the new Breaks:
[10:46] <pitti> jibel: ok, I think it's worth trying the main-all upgrade again
[10:46] <pitti> jibel: if it still fails, it should fail differently, but I have high hopes that it won't fail with this particular bug any more
[10:48] <jibel> pitti, I'll try as soon the lab is back.
[10:48] <pitti> jibel: oh, did it go out for lunch?
[10:49] <jibel> pitti, it rather didn't woke up this morning, so it missed breakfast too.
[10:51] <ppisati> why some libraries don't have the corresponding -dbg version? (e.g. libfuse2)
[10:51] <pitti> ppisati: we have -dbgsym packages for pretty much everything
[10:51] <pitti> https://wiki.ubuntu.com/DebuggingProgramCrash
[10:52] <ppisati> pitti: ok, let me try again
[10:52] <pitti> ppisati: in particular, we do have libfuse2-dbgsym
[10:55] <ppisati> pitti: i can't find it, where is it?
[10:56] <pitti> ppisati: you need to add the http://ddebs.ubuntu.com apt sources for it, as in above wiki page
[10:56] <ppisati> pitti: did
[10:56] <pitti> hm, did you run apt-get update?
[10:57] <ppisati> yes
[10:57] <ppisati> i'm in oneiric amd64
[10:58] <pitti> ppisati: does apt-cache search dbgsym give any results at all?
[10:59] <ppisati> [flag@newluxor ~]$ apt-cache search dbgsym | wc -l
[10:59] <ppisati> 8149
[10:59] <ppisati> pitti: ^^
[10:59] <pitti> ok, good
[11:00] <ppisati> pitti: can you point where the file is?
[11:00] <pitti> ppisati: sorry, just checked; we are indeed missing the libfuse2 dbgsym in oneiric
[11:00] <pitti> it's there in precise and older versions
[11:00] <ppisati> pitti: doh :(
[11:01] <pitti> http://ddebs.u.c. is a rather brittle makeshift solution, which was never meant to run for so many years
[11:01] <pitti> we are waiting for Launchpad to get real ddeb support
[11:02] <pitti> ppisati: so if you want to debug something, I'm afraid you'll need to rebuild the oneiric source locally with DEB_BUILD_OPTIONS=nostrip,noopt
[11:02] <ppisati> pitti: that was the plan, thanks for the support
[11:03] <pitti> ppisati: sorry, bad luck :/
[11:05] <pitti> jibel: so, good luck with the CPR!
[11:06] <wendar> doko: it's temporary while the maintainer of magics++ and libemos works out what he wants to do. more correct would be adding the linking flags for -lquadmath and -lgfortran in libemos (or farther up the chain, if that's where they're needed),  but  weighing between the options it seemed better to minimise the number of packages touched in the meantime.
[11:07] <wendar> doko: but, I'll fix up powerpc in a few hours (it's 3am at the moment)
=== bladernr_ is now known as bladernr_afk
=== _salem is now known as salem_
=== apachelogger_ is now known as apachelogger
=== doko_ is now known as doko
[11:54] <zul> pitti: universe is fine
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[13:44] <pitti> ugh, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg just turned ... interesting
[13:45] <pitti> I suppose I revert libcommons-lang-java
[13:45] <pitti> (looks like an autosync)
[13:47] <ScottK> pitti: It is a really good case for that tool though.  I skimmed the component mismatches email and it's far easier to see the source of the problem in the picture.
[13:47] <scott-work> not sure this is the correct channel, if it isn't please point me in the right direction:
[13:47] <pitti> ScottK: even there it's a challenge to follow the line from the green bubble :)
[13:47] <pitti> but yes, quite easy to see the root of the problem
[13:48] <scott-work> ubuntu studio would like to be able to install .deb files, we used to use gdebi but it seems that software-center can do it now
[13:48] <doko> well, that's maven as its best
=== yofel_ is now known as yofel
[13:48] <scott-work> do we need to include an extra package for software-center for it to install .deb files or will it do it natively?
[13:48] <scott-work> i meant local .deb files
[13:49] <ScottK> scott-work: mvo can answer that, I'm sure.
[13:49] <mvo> scott-work, ScottK: software-center will do it natively
[13:50] <scott-work> sweet, thanks mvo
[13:50] <mvo> yw
[13:50] <scott-work> we had a user having a problem but it might have been with a release where we didn't include software-center due to package name change
[13:50] <mvo> thats possible, I would welcome more info if its a real problem, but they should share the same backend code (debfile.py from python-apt)
[13:51] <scott-work> mvo: i'll see if i can find that email or question and do a quick check on it
[13:51] <ogra_> hmpf software-center is seriously broked here
[13:54] <mvo> scott-work: thanks
[13:59] <pitti> jibel, jamespage: any luck with reviving the QA lab?
[14:23] <scott-work> there is good talk on the jack-devel ML about dropping current jack1/jack2 and developing a new implementation...that's bloody exciting news!
[14:23] <scott-work> oh, crap...wrong channel, sorry
=== dendrobates is now known as dendro-afk
[14:27] <pitti> SpamapS: thanks for handling the kernel -proposed upload
[14:28] <pitti> SpamapS: I closed the task on the tracking bug, can you please do this next time, too?
[14:28] <pitti> SpamapS: btw, we don't usually run sru-accept.py on kernels, the kernel bot already covers this
[14:28] <pitti> SpamapS: (it doesn't hurt, of course)
=== dendro-afk is now known as dendrobates
[14:29] <rbasak> is there a channel for udd discussion? I'm trying to figure out where I can branch the current lucid-updates openldap from. That's at 2.4.21-0ubuntu5.6 but the bzr branches seem to be behind - lucid at 2.4.21-0ubuntu5, lucid-proposed at 2.4.21-0ubuntu5.5, lucid-updates at 2.4.21-0ubuntu5.4 and lucid-security at 2.4.21-0ubuntu5.4
[14:30] <rbasak> is lp:ubuntu/lucid-updates/openldap stuck in some way or is this expected?
[14:33] <geser> it got stuck by bug #653320 (see http://package-import.ubuntu.com/status/openldap.html)
[14:33] <ubottu> Launchpad bug 653320 in Ubuntu Distributed Development "Import fails with "marked but not imported"" [High,Triaged] https://launchpad.net/bugs/653320
[14:37] <rbasak> thanks geser, I'll go back to !udd for this one I guess
[14:38] <pitti> slangasek, mvo: bug 902603 is an interesting dpkg multi-arch bug; is that known to you already? WDYT about the proposed workaround to unbreak upgrades?
[14:38] <ubottu> Launchpad bug 902603 in gst-plugins-good0.10 (Ubuntu Precise) "oneiric to precise - gstreamer0.10-plugins-good failed to configure due to dependency on libtag1c2a" [High,Triaged] https://launchpad.net/bugs/902603
[14:39] <pitti> slangasek, mvo: tl;dr: if you have an empty metapackage and install the :i386 version of it, dpkg will consider the amd64 package entirely "replaced" and mark it as not installed
[14:40] <pitti> slangasek, mvo: but I can't mark it as M-A: foreign, as its dependencies are M-A: same (right?)
=== mterry is now known as mterry_sprinting
[14:45] <cjwatson> pitti: Sounds like the problem slangasek noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632555#20, although I can't find an actual dpkg bug report for it
[14:45] <ubottu> Debian bug 632555 in libpthread-stubs0 "libpthread-stubs0: Multiarch support" [Normal,Fixed]
[14:46] <cjwatson> Shipping a fake file to make the file lists distinct isn't a totally awful workaround
[14:46] <pitti> cjwatson: ah, thanks for the pointer
[14:47] <pitti> cjwatson: right, and harmless and easy to revert; I'd just have a better feeling once I get confirmation from Steve that it's an actual bug, not a mis-use of Multi-Arch:
[14:47] <mugwort13> anyone know the name of the ubuntu installer?   Like what I would search for in synaptic?
[14:47] <pitti> (and then making sure that's filed)
[14:47] <pitti> mugwort13: ubiquity, but you don't usually install that in an already installed system
[14:49] <mugwort13> pitti:  yes, I understand, this box has no cdrom & no usb , so I am going to install via wubi --> install via ubiquity --> uninstall wubi ... I hate doing it this way but the bios won't even allow pxe boot
[14:49] <mugwort13> thanks
[14:49] <pitti> mugwort13: you almost certainly want ubiquity-frontend-gtk then
[14:50] <mugwort13> kk
[14:50] <cjwatson> pitti: It is an actual bug
[14:50] <cjwatson> dpkg shouldn't be doing disappearance on all-files-common between two different architectures
[14:52] <pitti> cjwatson: can't find it either -- I guess I'll file it then
[14:53] <kenvandine> @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: bryceh, kenvandine
=== JackyAlcine is now known as Guest75450
[14:56] <barry> doko: no idea why that would hang but i'll look at it
=== [Jacky] is now known as JackyAlcine
[15:04] <mvo> pitti: sorry for the delay, I was in a call. indeed, putting in a stuf file to keep it on the system sounds sensible to me
[15:04] <pitti> mvo: ok, thanks; I'm typing a Debian bug report for it, then I have less guilt applying a workaround
[15:04] <pitti> mvo: want me to CC: you, or not? (I'm CCing slangasek)
[15:06] <mvo> pitti: please do, thanks!
[15:07] <SpamapS> pitti: ... please.. can we write this all down?
[15:07] <SpamapS> pitti: I'm sorry if its already written down and I just forgot where it is.
[15:08] <pitti> SpamapS: https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed
=== [Jacky] is now known as JackyAlcine
[15:08] <SpamapS> pitti: bookmarked. Thanks. :)
[15:08] <pitti> SpamapS: FYI, I'm using https://bugs.launchpad.net/~ubuntu-sru/+assignedbugs?field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED
[15:08] <pitti> SpamapS: as a TODO list for what we need to do for kernels
[15:10] <SpamapS> it helps me to see it there in my bookmarks toolbar as "kernel->proposed" :)
[15:12] <SpamapS> pitti: ok, I've just been responding to pings fro skaet
=== elif is now known as elif_lunch
[15:15] <cjwatson> pitti: I gather that multiarch bugs are better filed in Ubuntu at the moment
[15:15] <pitti> cjwatson: filed as Debian bug 652063 FYI (with some preemtive apology if that was too early, as that dpkg branch isn't in Debian yet)
[15:15] <ubottu> Debian bug 652063 in dpkg "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [Normal,Open] http://bugs.debian.org/652063
[15:15] <cjwatson> oh well
[15:16] <pitti> cjwatson: bug 902603 is now the corresponding Ubuntu bug
[15:16] <ubottu> Launchpad bug 902603 in taglib (Ubuntu Precise) "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Triaged] https://launchpad.net/bugs/902603
[15:17] <pitti> cjwatson: at least now I'm comfortable with filing a workaround
[15:17] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html \o/
[15:17] <pitti> after only four days
[15:17] <pitti> jamespage: ^ FYI
[15:18] <pitti> and the http://people.canonical.com/~ubuntu-archive/component-mismatches.txt madness is gone, too
[15:18] <Daviey> no precise_probs?!  Can we ship now? :)
[15:18] <jamespage> ship ship ship ship!
[15:19] <jamespage> OH - not yet :-)
[15:19] <pitti> *cough* NBS, component-mismatches, FTBFS, etc :)
[15:19] <jamespage> pitti: w00t - its be a dry four days!
[15:19] <pitti> well, to be honest most of it was buildd lag
[15:19] <pitti> there were only a few real fixes there
[15:19] <pitti> but I helped it a bit with bumping some build scores
[15:20] <pitti> jamespage: and no jenkins to turn green :(
[15:20] <pitti> jamespage: still no response to CPR?
[15:24] <ogra> could an archive admin let the linux-ac100 package out of NEW ?
[15:25] <slangasek> pitti: 902603> I was sure I had filed a bug on dpkg for this in LP already, but I don't see it now
[15:25] <pitti> ogra: yes, can do
[15:25] <ogra> (needs to go to universe)
[15:26] <pitti> slangasek: I checked debian and ubuntu bugs, didn't find somethign with a searchable name ("disappear", "Multi-arch", "multiarch")
[15:26] <mvo> broder: silly question about backports - you do not have a "apt-show-backports" tools right? if not, do you want one?
=== JackyAlcine is now known as JackyAlcine_
[15:28] <mvo> (or maybe someone else from the ubuntu-backports team can help me with that question)
[15:39] <ScottK> mvo: What would such a tool do?  (It's not obvious to me from the name)
=== mterry_ is now known as mterry_sprinting
[15:42] <mvo> ScottK: it would show on the commandline what packages are available as backports (and also what packages that you have installed on your system have a backport)
[15:42] <ScottK> mvo: No.  I don't think we have such a thing and yes, I think it would be very nice.
=== dendrobates is now known as dendro-afk
[15:44] <mvo> ScottK: cool, now I just need to find a pkg to place it in and a good name (maybe the name is already good enough)
=== dendro-afk is now known as dendrobates
[15:56] <Daviey> barry (or anyone else)): should debian/pydist-overrides be used to state, i DON'T want a depends?
[15:57] <nemo> So. Just FYI for y'all
[15:57] <nemo> I did an "upgrade" of ubuntu 10.10 to 11.10
[15:58] <nemo> 3 times the install over existing one crashed. the 3rd time I noticed in the log an error on writing to /usr/local/man
[15:58] <nemo> said that there was already something there
[15:58] <nemo> so I blew away everything in /usr/local, which was all stuff I didn't really need anymore anyway
[15:58] <nemo> aaaaand, install worked the 4th time
[15:58] <ScottK> Direct upgrade from 10.10 to 11.10 isn't supported.  You need to do 10.10 -> 11.04 -> 11.10.
[15:58] <nemo> ScottK: I meant I popped in an 11.10 disc
[15:58] <nemo> and used the option in the disc to upgrade an existing install
[15:59] <nemo> ScottK: anyway. seems the installer has some bug WRT /usr/local/man - thought I'd toss it out there
[15:59] <nemo> ScottK: it was from 10.10 32bit to 11.10 64bit, so no form of normal upgrade would have worked.
[15:59] <ScottK> More likely software from outside the archive.  Ubuntu packages should never install anything there.
[15:59] <nemo> ScottK: sure. but. the installer shouldn't crash either
[16:00] <cjwatson> I agree, but please file a bug in LP rather than on IRC
[16:00] <ScottK> If you're trying to cross-grade between architectures I think the expected behavior is completely undefined.
[16:00] <cjwatson> no, this is defined
[16:00] <cjwatson> it's not a regular upgrade, it's more like save off everything not part of the system, blat new system in place, restore
[16:01] <nemo> cjwatson: eh. I file stuff there in detail, it languishes, then someone urges I retest 4 months later when my entire system is gone or a completely different config
[16:01] <cjwatson> nemo: stuff filed on IRC is *certain* to languish
[16:01] <nemo> cjwatson: I'm fed up w/ LP - it is basically a bug auto-expiring mechanism
[16:01] <cjwatson> I fix bugs in LP, not from IRC
[16:01] <nemo> cjwatson: yeah, but at least I don't get the heartbreak of the autoexpire :)
[16:01] <nemo> cjwatson: well. you now know as much about it as I do :-p
[16:02] <slangasek> bugs only autoexpire if requests for information from developers have gone unanswered
[16:02] <cjwatson> for the ten minutes until I forget, given that I'm in a meeting
[16:02] <ScottK> nemo: I understand you're frustration, but he's right.  Even if the odds are low, they are better in LP than here.
[16:02] <cjwatson> I agree the percentage of bugs fixed from LP is not as good as it should be, but IRC is AWFUL as a bug-reporting mechanism
[16:02] <nemo> ScottK: hm. I see that the upgrade put a symlink in - perhaps it was blowing up on trying to symlink something that was not a symlink
[16:02] <cjwatson> and worse as a bug-remembering mechanism
[16:02] <nemo> cjwatson: the worst thing is I file the bugs so other users can learn
[16:02] <nemo> cjwatson: and then someone closes it so my workarounds vanish
[16:02] <cjwatson> I suppose you can hope somebody else has already filed it, if you won't file it yourself
[16:02] <skaet> pitti, Spamaps - http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/kernel-sru-workflow.html is also useful to get an overview.
[16:03] <cjwatson> nemo: no, this is me asking you to file it and give me the number so that I can keep track of it
[16:03] <barry> Daviey: sorry, i don't know the answer to that
[16:03] <cjwatson> nemo: I'm one of the two or three people who can fix this bug so maybe it might be a good idea to listen :-)
[16:03] <ScottK> nemo: He's also the guy that fixes installer bugs, so I'd listen
[16:03] <ScottK> :-)
[16:03] <nemo> cjwatson: yeah, yeah. I'll get to it if I remember. in order to use launchpad from here I still have to integrate those <button> patches into my w3m
[16:03] <nemo> due to the login mechanism
[16:03] <Laney> mvo: yeah, that would be nice — is it something that apt could have a command for itself? More general than backports, for any NotAutomatic source
[16:03] <cjwatson> which I was able to find for you because they were tracked in LP ...
[16:04] <nemo> :-p
[16:04] <nemo> cjwatson: someone must have not autoexpired them like they do all my hardware bugs :)
[16:04] <cjwatson> what you're complaining about isn't fundamentally LP, it's that we don't have enough resource to fix all the bugs that get fixled
[16:04] <cjwatson> er, filed
[16:04] <cjwatson> refusing to file bugs doesn't particularly help that
[16:04] <nemo> cjwatson: sure. I just wish they were left open so other people would know. oh. hey. that laptop model has this problem. here is a workaround
[16:05] <nemo> what you guys need is a hardware database I could record this stuff in
[16:05] <cjwatson> oh, I agree with you and have been banging that drum for years; but refusing to file bugs doesn't help matters
[16:05] <ScottK> I think it's also the reasonable complaint that triagers do too much "is this still a problem" -> Incomplete triaging.
[16:05] <nemo> ubuntu version, hardware component, support, workaround
[16:05] <ScottK> nemo: You're talking with one of the Ubuntu devs that has been most outspoken about it and it still happens.
[16:05] <nemo> cjwatson: anyway. either I'll get setup on the external network, or I'll apply the w3m patch. I'll get to it eventually
[16:06] <nemo> but fundamental problem is /usr/local/man was a physical dir and installer apparently wanted to symlink to /usr/local/share/man  - it panicked and exploded
[16:06] <nemo> probably correct behaviour would have been mv /usr/local/man /usr/local/share/man
[16:06] <nemo> then symlink
[16:06] <cjwatson> sure, that is probably fixable.  but I want an audit trail for this
[16:07] <cjwatson> because otherwise it's hard for me to keep track of what bits of the code are there for
[16:07] <cjwatson> it's unfortunately rather complex
[16:08] <cjwatson> (I don't think we can decide how to move things around in /usr/local; we should just not fail)
[16:10] <tgall_foo> doko, ping - where are we at with libjpeg-turbo8 hitting the archive ?
[16:10] <nemo> cjwatson: hm. symlinks should work functionally the same, so you'd think moving would be harmless.  of course, the interesting thing is that the new /usr/local/share/man is empty anyway :)
[16:10] <nemo> cjwatson: so it blew up on trying to create an empty dir :D
[16:10] <nemo> guess it was some standard disc layout
[16:10] <cjwatson> complexity leads to failures; I'd rather keep it as simple as possible
[16:11] <nemo> it also made a bunch of other dirs - so maybe my blowing away all of /usr/local was important too
[16:12] <nemo> all empty btw :D
[16:12] <nemo> local$ find | xargs
[16:12] <nemo> . ./etc ./src ./man ./lib ./lib/site_ruby ./lib/site_ruby/1.8 ./lib/site_ruby/1.8/x86_64-linux ./lib/python2.7 ./lib/python2.7/dist-packages ./lib/python2.7/site-packages ./sbin ./bin ./share ./share/fonts ./share/man ./share/ca-certificates ./share/xml ./share/xml/misc ./share/xml/entities ./share/xml/schema ./share/xml/declaration ./share/ppd ./share/sgml ./share/sgml/dtd ./share/sgml/misc ./share/sgml/entities ./share/sgml/declaration 
[16:12] <cjwatson> *please put this in a bug*
[16:12] <cjwatson> I am NOT going to remember this when I next have a chance to fix this
[16:13] <cjwatson> the above is very likely enough for me to set up a reproduction environment, and that's great
[16:13] <nemo> oh. one interesting side effect of this (bug blah blah blah)  was that on later attempts to install it decided it was upgrading from 11.10 to 11.10
[16:13] <nemo> instead of 10.10 to 10.10
[16:14] <cjwatson> yes, it had already overwritten the bit that said it was 10.10
[16:14] <cjwatson> notabug
[16:14] <nemo> I have no idea if this impacted its ability to ID existing packages, but I was missing a lot of packages
[16:14] <cjwatson> except insofar as the previous run failed
[16:14] <cjwatson> yes, it would have done
[16:14] <nemo> cjwatson: sure. I was just thinking it might have screwed up the upgrade
[16:14] <nemo> cjwatson: only way to avoid that would be if there was some sort of incomplete upgrade log
[16:14] <cjwatson> it probably would have done a bit
[16:14] <nemo> including enumeration of prior packages
[16:14] <nemo> that you could blow away once successful
[16:15] <nemo> cjwatson: it is a mild bug in that you could keep track of that if you wanted to. but certainly the circumstance shouldn't happen anyway
[16:15] <nemo> not like a user would be able to do much once they hit the crash anyway
[16:19] <nemo> yeah, reason I could blow away /usr/local/ is it just contained cuda (which I needed to update anyway) and Aventail (which workplace abandoned for something w/ even less linux support)
=== elif_lunch is now known as elif
[16:21] <nemo> cjwatson: oh. one more thing. reason I didn't submit a crash report at the time, even though I had internet, was that it said it would include my password (!) in the crash report.
[16:22] <nemo> cjwatson: why is the installer keeping that in its memory so late in the install? or is that a just-in-case because it might have crashed in the hopefully tiny action to put it in a password file as soon as it is collected
[16:22] <nemo> heck. you'd think the first thing you'd do would be to hash it, wipe the original's memory location, then only use the hash until you can ditch it :)
[16:23] <nemo> you could probably even determine whether it was still in the installer's memory by a checkpoint on how far the installer got :)
[16:23] <nemo> anyway. scary message = no crash report from me ;)
[16:23] <nemo> I'm sure I'm not the only one
[16:24] <cjwatson> were you running the installer in debug mode?
[16:24] <nemo> I guess had I known that could happen I would have used a throwaway password and changed it after install
[16:24] <nemo> cjwatson: nope. just poppped in a standard disc
[16:24] <cjwatson> otherwise I don't recognise that message
[16:24] <cjwatson> oh, maybe:
[16:24] <cjwatson>     if os.path.exists('/var/log/installer/debug'):
[16:24] <cjwatson>         response = ui.yesno("The debug log file from your installation would help us a lot but includes the password you used for your user when installing Ubuntu.  Do you want to include this log file?")
[16:24] <nemo> yep
[16:25] <cjwatson> so (a) you have the option to submit a crash report without that debug log file
[16:25] <cjwatson> (b) I *think* it only includes that when in debug mode, but haven't checked
[16:25] <nemo> mm
[16:25] <nemo> well. apparently the installer did not know this :)
[16:25] <cjwatson> debug mode traces all debconf transactions without caring what it is, it's like strace
[16:25] <nemo> I assumed it was submitting some core file w/ installer's memory
[16:26] <cjwatson> anyway, you could have said no and filed the bug.
[16:26] <nemo> it made me all paranoid :-p
[16:26] <nemo> didn't want to accidentally send my password to a public server
[16:26] <nemo> heck. it had already crashed, I didn't trust it :)
[16:28] <mvo> Laney: yeah, good idea
[16:29] <Laney> :-)
[16:29] <cjwatson> slangasek: should bug 800561 be on rls-p-tracking, given that I don't think we can commit to fixing this until GI-friendly xklavier bindings are available?
[16:29] <ubottu> Launchpad bug 800561 in ubiquity (Ubuntu Precise) "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561
[16:31] <slangasek> cjwatson: probably only if the xklavier GI dependency is also tracked... or if we want to commit to doing that ourselves
[16:32] <slangasek> pitti: ^^ do you know if we're going to get GI xklavier bindings this cycle, and when?
[18:54] <stgraber> cjwatson: looking at bug 219260, is that something you think we should try to solve this cycle (calling console-setup directly)
[18:54] <ubottu> Launchpad bug 219260 in casper (Ubuntu) "clone-and-hack keyboard setup code needs to be replaced by calling console-setup" [High,Triaged] https://launchpad.net/bugs/219260
[19:18] <dobey> is there an easy way to install the amd64 kernel, but keep a 32bit userspace?
[19:36] <broder> dobey: i think linux-image-generic is multiarch cross-installable
[19:36] <broder> so apt-get install linux-image-generic:amd64
[19:36] <dobey> E: Unable to locate package linux-image-generic:amd64
[19:36] <broder> uh, echo foreign-architecture amd64 | sudo tee /etc/dpkg/dpkg.cfg.d/multiarch
[19:37] <broder> apt-get update, etc., etc.
=== salem_ is now known as _salem
[19:42] <broder> dobey: hmm...looks like that only works on precise, not oneiric, fyi
[19:42] <dobey> yeah, the packages seem to be broken
[19:42] <broder> it also may not willingly uninstall your current kernel before grabbing the foreign arch one - you may have to do that yourself
[19:43] <hallyn> mdeslaur: my gift to you is bug 903307.  As I don't have upload rights, i'll just leave it there with debdiff attached?
[19:43] <ubottu> Launchpad bug 903307 in virt-manager (Ubuntu) "Virtual Machine Manager unable to view GUI console" [Medium,Confirmed] https://launchpad.net/bugs/903307
[19:43] <dobey> broder: ideally i'd like to have both installed, in case the amd64 one doesn't work
[19:44] <dobey> so i can at least boot my system again if it fails
[19:44] <mdeslaur> hallyn: is that my xmas gift? :)
[19:44] <hallyn> sorry there's no bow
[19:45] <hallyn> i was afraid it might still be due to some delta in our libvirt, but no, same thing on f16
[19:45] <mdeslaur> hallyn: does virt-manager reuse the same ssh tunnel if you have two consoles opened to the same server?
[19:45] <mdeslaur> my other question was if it could be because of the nc madness
[19:45] <hallyn> well it could be, but as i say it's also in f16
[19:45] <mdeslaur> hallyn: you tried with an ubuntu server, or ith a f16 server?
[19:46] <hallyn> i don't know how to pen two consoles to the same server
[19:46] <hallyn> both
[19:46] <mdeslaur> hallyn: ok, I'll take a look and upload it
[19:46] <hallyn> mdeslaur: thanks!
[19:46] <mdeslaur> hallyn: thanks!
[19:46] <hallyn> (i did send it upstream, we'll see what they say)
[19:48] <tgall_foo> doko, ping - where are we at with libjpeg-turbo8 hitting the archive ?
[19:49] <doko> tgall_foo, I know, on my todo list. did want to wait until armhf was bootstrapped
[19:49] <tgall_foo> ok thanks
[19:52] <micahg> doko: sorry about trillinos, I thought I had tried that build-dep switch
=== deryck is now known as deryck[lunch]
[19:58] <doko> micahg, well, the R build system is broken
[19:59] <doko> barry, see bug #904248 and bug #904249, python-central isn't a big issue anymore, python-support requires some more effort
[19:59] <ubottu> Launchpad bug 904248 in python-central (Ubuntu Precise) "python-central build-dependencies in main" [High,Triaged] https://launchpad.net/bugs/904248
[19:59] <ubottu> Launchpad bug 904249 in python-support (Ubuntu Precise) "python-support build dependencies in main" [High,Triaged] https://launchpad.net/bugs/904249
[20:00] <barry> doko: ack, thanks
[20:04] <iceroot> can someone tell me why libgnome-control-center1 has a "1" at the end? in changelog its just called libgnome-control-center
[20:05] <iceroot> apt-cache search libgnome-control-center
[20:05] <micahg> iceroot: binary vs source naming?
=== dendrobates is now known as dendro-afk
[20:08] <iceroot> micahg: ah its some of these "one source-package but many binary-packages" in debian/control there is libgnome-control-center and libgnome-control-center1
[20:10] <micahg> iceroot: source is gnome-control-center, libgnome-control-center1 is the binary package
[20:10] <iceroot> micahg: but why libgnome-control-center1 and not libgnome-control-center as binary
[20:10] <micahg> iceroot: SONAME versioning probably
[20:11] <iceroot> micahg: ok, thanks for the info
[20:11] <infinity> iceroot: library package names have the SOVER in the package name.
[20:12] <infinity> iceroot: So that if there's ever a libgnome-control-center.so.2, it will be co-installable as libgnome-control-center2
[20:12] <iceroot> infinity: ah ok, thanks for the example now i get it
=== mwhudson_ is now known as mwhudson
=== fisted_ is now known as fisted
[20:34] <jtaylor> lamont: can you give some insight on whats going wrong here: https://launchpadlibrarian.net/87386428/buildlog_ubuntu-precise-i386.pyzmq_2.1.10-2_FAILEDTOBUILD.txt.gz
[20:34] <jtaylor> lamont: it seems to fail binding to 127.0.0.1 on i386 and amd64 but not on arm, local and on debians i386 and amd64 buildd's
[20:35] <jtaylor> the testsuite does not require internet access
[20:42] <debfx> slangasek: do you have a moment to review my phonon multiarch changes?
[20:43] <cjwatson> stgraber: it's a technical debt item, but it has a substantial chance of regressions; I don't think it would be a good candidate for this cycle
[20:43] <cjwatson> dobey: it does work on precise, FWIW, although you can only (easily) have one or the other, I think
[20:43] <cjwatson> dobey: I'm running an amd64 kernel with an i386 userspace on this system, having put some effort in at the start of the cycle to get this working
[20:43] <slangasek> debfx: not this moment; I would in an hour or so
[20:43] <stgraber> cjwatson: ok, won't touch that one then :)
[20:45] <dobey> cjwatson: ok, maybe i'll upgrade this system; i'll try it on another machine first
[20:45] <debfx> ok
[20:46] <broder> cjwatson: i don't suppose there's any chance you took measurements of memory savings in that setup vs. all i386? i'm curious how it compares to cking's numbers
[21:04] <kenvandine> @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: bryceh
=== broder 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:
[21:05] <cjwatson> broder: no, sorry
[21:05] <broder> i'm assuming bryceh isn't still piloting at this point
[21:26] <barry> tumbleweed: will you sync precise python-virtualenv to 1.7-1 when it lands, or do you want me to?
=== deryck[lunch] is now known as deryck
[21:29] <bryceh> broder, yeah sorry forgot to log out
[23:22] <TheMuso> doko: Yes I know, I gave it back on amd64, but had to leave before I could give back on other arches.
[23:24] <slangasek> TheMuso: ah, so a give-back should fix it? Are you doing that now?  I was about to come pestering about that myself :-)
[23:31] <doko> qcontrol only built for armel??? https://launchpad.net/ubuntu/precise/+source/qcontrol/0.4.2-7
[23:32] <infinity> doko: Architecture: armel
[23:32] <infinity> doko: Right in the .dsc
[23:33] <doko> infinity, ok, building for armhf too
[23:51] <TheMuso> slangasek: yes gave them all back.
[23:51] <slangasek> TheMuso: great, thanks