[00:00] <cnd> micahg: it's not needed for beta
[00:00] <micahg> cnd: nah, happened about an hour ago
[00:00] <micahg> or 2 hours actually :)
[00:00] <cnd> I only want to push it so I don't forget to do it later :)
[00:00] <slangasek> cnd: ftbfs fixes probably still warrant getting in
[00:01] <cnd> slangasek: ok, I'll take your word for it
[00:01] <micahg> cnd: an AA will have to process it in any event since the archive is frozen
[00:01] <cnd> yeah
[00:01]  * cnd fears the retribution of an AA
[00:01] <slangasek> SpamapS: so a year ago, you argued for putting libdbi-drivers in main because libdbi is useless without it (bug #608556)... I would argue that libdbi is worthless even with it and would like to redemote libdbi-drivers so I don't have to touch it for the sqlite demotion. ;)  Any thoughts?
[00:03] <micahg> slangasek: is it too late to take an axe to sqlite?  most of the applications already support sqlite3
[00:03] <micahg> or should we wait for Debian and or P?
[00:04] <slangasek> micahg: define "axe"?
[00:04] <Daviey> slangasek: wait, multiverse can depend on partner?  Is there precedent of that?
[00:04] <slangasek> micahg: you mean wholesale removal?
[00:04] <micahg> slangasek: yes
[00:04] <SpamapS> slangasek: rrdtool and gnucash recommend or depend on libdbi at the moment
[00:04] <slangasek> Daviey: well, I would be more sanguine about allowing a package to depend on a partner package in multiarch than in partner - but yes, ideally we don't want multiarch to depend on partner eithe
[00:04] <slangasek> r
[00:05] <SpamapS> slangasek: and really, libdbi is useless w/o the drivers.
[00:05] <Daviey> slangasek: I think you have multiarch on your brain :)
[00:05] <SpamapS> slangasek: I'd be quite supportive of disabling 'sqlite' tho.
[00:05] <slangasek> SpamapS: sure; that doesn't mean we want to encourage its use or suggest that we support that lousy library
[00:06] <SpamapS> slangasek: there are some very excited folks who use rrdtool's libdbi integration to graph their databases.
[00:06] <slangasek> SpamapS: rrdtool has to link against it if it's to be able to use it at all, so libdbi has to be in main - but I don't think that translates to extending support to libdbi-drivers
[00:06] <slangasek> sure, and that integration would still be there
[00:06] <slangasek> they'd just pull it from universe
[00:06] <SpamapS> slangasek: just.. not usable.. ?
[00:06] <slangasek> where it belongs
[00:06] <slangasek> who are these hypothetical people who don't have universe enabled on their systems? :
[00:07] <slangasek> )
[00:08] <SpamapS> Truth be told I don't like it either.. we could probably make a strong appeal to the upstreams to use libodbc instead.
[00:08] <slangasek> +1
[00:09] <slangasek> in the meantime, what do we do with libdbi-drivers?  I stil think it should be demoted... we've been trying to get sqlite out of main for years already, and this is the last blocker.  We could demote them both, or you could upload libdbi-drivers if you prefer? :)
[00:09] <RAOF> slangasek: Wine just looks like ia32-libs needs to be updated to not depend on lib32v4l-0.  And then add some appropriate depends somewhere.
[00:09] <slangasek> RAOF: oh, that bit
[00:10] <slangasek> add what appropriate depends where?
[00:11] <RAOF> I don't know, but whatever actually depnds on libv4l is obviously going to need to depend on libv4l-0:i386 now.
[00:12] <slangasek> can't be done
[00:12] <slangasek> No way to express a dependency on a foreign package of a specific architecture; ia32-libs should just pick up libv4l for the moment, if it's really needed
[00:13] <micahg> slangasek: wine could be give a dependency i386 only package :)
[00:16] <slangasek> micahg: libv4l-0 isn't i386-only though, and I'm not going to do that horrible trick for a library
[00:24] <micahg> slangasek: well, if there's more than one library, it might make sense to do it in the wine package
[00:27] <infinity> Indeed, wine could depend on wine-libs, or something, an i386 package with dependencies to i386 libs.
[00:27] <infinity> But if we keep perpetuating that hack over and over, it starts making a valid excuse for allowing foo:arch deps. :/
[00:29] <slangasek> oh, it's perfectly *valid* to have foo:arch deps
[00:29] <slangasek> it's just not implemented in dak, soyuz, or dpkgapt.
[00:29] <infinity> Well, yes.  That's what I meant by "allow".
[00:29] <infinity> As in, actually implement it. :P
[00:30] <slangasek> I wish I could make code happen just by giving the bits permission
[00:30] <infinity> *grin*
[00:30] <slangasek> anyway, yeah, it's going to be needed down the line
[00:31] <slangasek> but ia32-libs isn't going to cause it to move up on my priority list any
[00:31] <infinity> Actually, have you considered replacing ia32-libs with a similar "depend on an i386-only metapackage" hack?
[00:31] <slangasek> can't
[00:31] <slangasek> half the libs it depends on aren't multiarch-ready yet
[00:31] <infinity> Or will that not work because ia32-libs is still bi-arch stuff, and things can't find the multiarch versions?
[00:31] <infinity> Yeah.  You beat me to it.
[00:32] <infinity> Though reasoning from the other direction, perhaps.
[00:33] <slangasek> SpamapS: no further comment on libdbi-drivers? :)
[00:35] <SpamapS> slangasek: I hesitate to defend it too much, but I do think its a bit.. funky to have libdbi in main w/o them.
[00:36] <slangasek> SpamapS: are you willing to do the upload to cut out libdbd-sqlite?
[00:36] <slangasek> if not, we don't actually support it - QED ;)
[00:41] <SpamapS> slangasek: yeah that sounds easy
[00:42] <slangasek> ok
[00:42] <Daviey> SpamapS: slangasek is setting up a trap for you.. touched-it-last next cycle ;)
[00:42] <slangasek> darn right I am
[00:42] <slangasek> you'll have to adopt it in Debian
[00:43]  * SpamapS dons his sucker hat
[00:43] <slangasek> I thought the trap was fairly obvious :)
[00:43] <SpamapS> I've tried adopting it in Debian. :-P
[00:43] <slangasek> OTOH, if you get rrdtool to switch to odbc, you can make me do all the work :)
[00:51] <micahg> slangasek: you seem to have evaded my question about dropping sqlite entirely :)
[00:52] <slangasek> micahg: ohright - yes, I don't think it's too late for that provided someone does the work to cull the reverse-dependencies
[00:52] <slangasek> but I wouldn't remove it this late in the cycle without first fixing the revdeps
[00:52] <slangasek> since that's not fair to folks who use those packages
[00:53] <micahg> slangasek: right,there aren't too many rdeps left actually, I have to actually see if any of them only use sqlite and not sqlite3
[01:17] <ScottK> doko: Thanks.
[01:21] <ScottK> jbicha: Is your gnome-shell upload bugfix only?
[01:29] <micahg> slangasek: that's a shame, a 500MB upload for a one line change + changelog (ia32-libs)
[01:35] <Keybuk> I pity the mirrors
[01:42] <slangasek> micahg: I has fast internets now, uploading ia32-libs doesn't bother me anymore :)
[01:43] <micahg> heh
[01:43] <slangasek> I really should've refreshed the contents before upload though... well, I'll do that in a few weeks when skype/partner is sorted
[01:44] <slangasek> or I'll do it when dealing with v4l or something
[01:52] <jbicha> ScottK: no but it's in universe and it has a lot of bug fixes: http://git.gnome.org/browse/gnome-shell/tree/NEWS
[01:55] <jbicha> one issue is that the Gnome Shell in the archives now is almost 2 months old so it's difficult to tell what bugs are still broken upstream
[02:02] <ScottK> jbicha: It needs an FFe.
[02:03] <ScottK> Sounds like something reasonable, but we need to follow the process.
[02:10] <jbicha> ScottK: GNOME 3.2 has a standing FFe
[02:11] <jbicha> I understand that we're in Beta Freeze but GNOME Shell isn't shipped on the CDs
[02:22] <infinity> ScottK: The process doesn't explicitely require bug filing and paper trails, that's just the best way to document things if you can't get an FFe more readily.
[02:22] <infinity> jbicha: And you're right about GNOME's standing FFe, combined with gnome-shell being universe.  I'm fine with it.
[02:33] <ScottK> OK.
[05:39] <pitti> Good morning
[05:39] <pitti> infinity: I meant to sync it, but aborted as I noticed yet another problem in ubiquity first
[05:40] <pitti> ev: I figured out the two remaining ubiquity regressions FYI; I followed up to bug 829186, we need to replace the static "xklavier" import
[06:54] <ricotz> janimo, hello, are you around?
[06:57] <janimo> ricotz, hello, now
[06:58]  * janimo feels this is clutter related :)
[06:58] <ricotz> janimo, yes kind of ;)
[06:58] <ricotz> could you testbuild this on armel http://people.ubuntu.com/~ricotz/gnome-shell/gnome-shell_3.1.4-0ubuntu2.debdiff
[06:59] <janimo> ricotz, sure
[06:59] <ricotz> janimo, thanks
[07:01] <ricotz> janimo, please say so if you want a real package dsc
[07:02] <janimo> ricotz, I'll just apt-get that, I assume it is against latest in oneiric
[07:02]  * janimo just booted up the pandaboard
[07:02] <ricotz> yes
[07:07] <janimo> ricotz, what is happening on armel if no glx is used?
[07:07] <janimo> is functionality missing in GS?
[07:08] <ricotz> janimo, the uncommented parts arent real functionalities, they are just perf related
[07:09] <ricotz> janimo, the configure* changes probably arent needed
[07:09] <janimo> ok
[07:10] <ricotz> janimo, i hope this wont need mutter to be patched too
[07:11] <doko> first compiz crash today
[07:20] <dholbach> good morning
[07:24] <pitti> ev: I have a question for you in https://bugs.launchpad.net/ubuntu-sso-client/+bug/829186/comments/31
[07:29] <janimo> ricotz, GS builds fine with your patch
[07:30] <OdyX> Hmm. It's unfortunate that the Natty PPAs don't support .xz. What else similar can I use ? lzma ?
[07:32] <ricotz> janimo, thanks, i hope it runs too ;)
[07:32] <janimo> ricotz, I do not have my panda set up for graphics testing ATM, but I suppose it should run :)
[07:33] <ricotz> janimo, ok :), thank you
[07:33] <micahg> OdyX: I think that feature was just released to launchpad :)
[07:33] <ricotz> micahg, xz deb compression?
[07:33] <micahg> yeah
[07:33] <OdyX> micahg: okay, but do Natty hosts support data.tar.xz ?
[07:33] <ricotz> nice
[07:34] <micahg> bug 619152
[07:34] <ricotz> OdyX, xz tarball are supported for all pockets
[07:41] <tjaalton> almost to give up.. is there a bzr equivalent of 'git show $sha'?
[07:42] <RAOF> tjaalton: bzr log -p -r $REVISION
[07:42] <RAOF> tjaalton: bzr alias show="log -v -p" ☺
[07:43] <jbicha> micahg: ooh, that looks useful
[07:43] <jbicha> let's just convert the CD to xz so that we can get it <700MB again ;-)
[07:44] <tjaalton> RAOF: did you mean 'bzr alias show="log -p -r"' :)
[07:44] <tjaalton> thanks anyway
[07:44] <RAOF> tjaalton: Hm, that might be a nice optimisation! :)
[07:47] <micahg> pitti: regarding Firefox 6 for maverick, I'm running a little behind, so I'll get it up later today and it'll be ready over the weekend (takes ~17hrs on armel), I can send you an e-mail before my EOD today and let you know the status and when it'll be ready to be copied to -proposed
[07:47] <pitti> micahg: cool, thanks
[08:02] <ev> pitti: looking over all of this now
[08:02] <pitti> ev: this is all post-beta 1 matter now anyway
[08:03] <pitti> ev: the main thing that concerns me is that the xklavier stuff caused hangs with the current pygobject for me, i. e. I'm afraid it might cause trouble with the current CDs
[08:03] <ev> indeed, that is worrisome
[08:04] <pitti> ev: but either it's happening in a thread, or the different program context prevents the hang
[08:04] <pitti> it doesn't seem to happen in ubiquity, just in the standalone python test case
[08:05] <pitti> doko: present for you: libdbi-drivers_0.8.3-1-0ubuntu5_source.changes just uploaded, dropping sqlite
[08:05] <pitti> doko: once that gets accepted, we can demote sqlite
[08:08] <tjaalton> hmm, does anyone know how a package depending on ia32-libs should be fixed to be installable in both oneiric and earlier releases?
[08:09] <doko> pitti, except for the php5 build failure on amd64 :-/
[08:10] <pitti> ah, right -- always the n+1st thing :/
[08:10] <doko> but hey, it's now away on powerpc and i386
[08:11] <tjaalton> ah, I'll see how flashplugin-installer is packaged
[08:13] <RAOF> tjaalton: I'm not sure that's a wonderful role-model; I believe slangasek has made dark and secretive pacts with apt to make that work.
[08:15] <tjaalton> RAOF: damn, I noticed that bibble5 wants to deinstall along with ia32-libs, and began filing a bug upstream..
[08:15] <tjaalton> and flashplugin-nonfree doesn't seem backportable anyway
[08:16] <RAOF> No, I don't think it is.  Doesn't it now Depend: on a package that's only available on i386?
[08:16] <tjaalton> which one?
[08:18] <RAOF> I can't recall.
[08:18] <tjaalton> oh I see
[08:19] <tjaalton> it has flashplugin-downloader which is i386 only, and flashplugin-installer installs it
[08:19] <tjaalton> depends on it
[08:20] <slangasek> RAOF: naw, the pact is still caught up in legal review on apt's side; mdeslaur went with a much simpler approach that doesn't involve nearly so much blood :)
[08:22] <tjaalton> slangasek: long story short; is there a way for proprietary software vendors to change the deps so that the package is installable on both multiarch and pre-multiarch ubuntu?
[08:22] <tjaalton> something like '$i386-package | ia32-libs' ?
[08:22] <tjaalton> in deps
[08:22] <tjaalton> hmm no
[08:22] <slangasek> tjaalton: they should just provide an i386 package, and people should install that via multiarch
[08:23] <slangasek> if they want to provide an amd64 package for older releases that depends on ia32-libs, they can
[08:23] <tjaalton> slangasek: ah, of course. and that exists :)
[08:23] <slangasek> (and ia32-libs isn't quite dead yet)
[08:24] <tjaalton> something is making ia32-libs deinstall on my machine
[08:24] <slangasek> that's the libv4l bug
[08:24] <dholbach> tjaalton, is it https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/808064?
[08:24] <dholbach> see the last comment
[08:25] <tjaalton> yeah, it's the same. thanks
[08:25] <slangasek> I intend to fix that tomorrow; I wouldn't trouble yourselves with having to touch ia32-libs, unless you're really keen
[08:26] <tjaalton> nah it's fine, I can reinstall bibble later, need the upgrade more
[08:26] <dholbach> I tried installing the i386 version of google-talkplugin but for some reason that didn't work
[08:27] <tjaalton> actually I'll just install the i386 version of bibble, duh
[08:28] <slangasek> dholbach: we're well short of 100% archive coverage for multiarch libraries.  Pastebin the error?
[08:31] <dholbach> slangasek, LoadPlugin: failed to initialize shared library /opt/google/talkplugin/libnpgtpo3dautoplugin.so [/opt/google/talkplugin/libnpgtpo3dautoplugin.so: wrong ELF class: ELFCLASS32]
[08:31] <dholbach> LoadPlugin: failed to initialize shared library /opt/google/talkplugin/libnpgoogletalk.so [/opt/google/talkplugin/libnpgoogletalk.so: wrong ELF class: ELFCLASS32]
[08:31] <tjaalton> bibble5:i386 installs and runs fine
[08:31] <dholbach> at least I guess that's what the problem is :)
[08:31] <slangasek> dholbach: oh.  What is that supposed to be loaded into?  Is this a browser plugin?
[08:31] <dholbach> the package installs fine and everything
[08:31] <dholbach> slangasek, yes, it is
[08:32] <slangasek> dholbach: right; ideally we'd want it integrated with nspluginwrapper then, the same way that flashplugin-nonfree is.  Who provides this package?
[08:32] <slangasek> I guess it's distributed by google directly?
[08:32] <dholbach> slangasek, Google
[08:32] <dholbach> deb http://dl.google.com/linux/talkplugin/deb/ stable main
[08:37] <slangasek> heh, their 64-bit package is made for Debian, it depends on ia32-libs-gtk which isn't in Ubunut
[08:37] <slangasek> s/ut/tu/
[08:37] <chrisccoulson> urgh, not more stuff using nspluginwrapper ;)
[08:37] <chrisccoulson> what we want is a multiarch aware plugin-container for firefox :)
[08:38] <slangasek> dholbach: so it looks like the amd64 package they provide contains a 64-bit browser plugin, plus some other 32-bit binaries for some reason
[08:39] <slangasek> that makes it tricky to do anything with on the Ubuntu side; it really would need to have the package split in two to allow for multiarch install
[08:39] <dholbach> thank god our ia32-libs provides: ia32-libs-gtk :)
[08:40] <slangasek> oh, does it?  ok
[08:40] <dholbach> that's why the package was installable at all
[08:40] <slangasek> but since they also offer a click-to-download website, they may not want to split the package in two and make it harder for users to install
[08:45] <dholbach> I'm probably missing the obvious, but wouldn't 1) removing lib32v4l-0 from ia32-libs's list of depends and 2) adding libv4l to ia32-libs solve the problem for now? (however ugly the upstream google packaging might be)
[08:45] <dholbach> ... since lib32v4l-0 is not available any more
[08:45] <slangasek> dholbach: yes, it will
[08:45] <slangasek> and that's what I'll do in the morning
[08:45] <dholbach> ok
[08:45] <dholbach> you rock!
[08:45] <dholbach> thanks
[08:46] <slangasek> but, I'd rather like it if the google upstream packaging were improved *as well* :)
[08:47] <dholbach> understood :)
[08:50] <dholbach> from what I can see http://www.google.com/intl/en/+/learnmore/forum/ is the feedback mechanism there
[09:14] <siretart> cjwatson: is it okay if I upload libav (with the MAP_ANONYMOUS bugfix of yours included) to oneiric now, despite the freeze currently being in effect?
[09:15] <pitti> siretart: sounds fine, please upload
[09:15] <pitti> we can review it from the queue, and if it seems unintrusive enough, accept it; otherwise, keep it for post beta 1
[09:17] <siretart> pitti: thanks, uploaded
[09:24] <OdyX> tkamppeter: could you please detail https://launchpad.net/ubuntu/+source/foomatic-filters/4.0.9-1ubuntu2 to me ?
[09:26] <cjwatson> astraljava: you can also (undocumentedly, sorry) pass multiple seed source URLs to -S, separated by commas
[09:33] <cjwatson> ricotz,OdyX: maverick and natty support data.tar.xz, but (in practice) not older - LP enforces that data.tar.xz uploads must Pre-Depends: dpkg (>= 1.15.6)
[09:33] <cjwatson> siretart: yep, what pitti said
[09:33] <OdyX> cjwatson: okay. Is there such an enforcement on the Debian side ?
[09:34] <cjwatson> I would have to check, but it's traditional to do that
[09:34]  * cjwatson git pulls dak
[09:34] <Sweetshark> pitti: testbuild is running again
[09:34]  * pitti tosses in some hamster food
[09:35] <ricotz> cjwatson, i am using xz tarballs for lucid+ ppas
[09:35] <OdyX> ricotz: in data.tar.gz ?
[09:35] <ricotz> OdyX, yes
[09:36] <ricotz> i.e. https://edge.launchpad.net/~wfg/+archive/0ad.dev/+packages
[09:36] <ricotz> but with lzma deb compression
[09:37] <cjwatson> ricotz: lzma != xz
[09:37] <ricotz> cjwatson, i know
[09:37] <cjwatson> lzma only requires dpkg (>= 1.14.0)
[09:38] <cjwatson> xz was not supported in dpkg until 1.15.6
[09:38] <OdyX> hmm. I think I'll drop the xz-handling for those backporting PPAs.
[09:38] <ricotz> cjwatson, like i wrote xz-tarballs which generate lzma compressed debs ;)
[09:38] <cjwatson> ok, this isn't relevant to the question
[09:39] <cjwatson> OdyX: dak doesn't seem to have the same check (IMO unwisely)
[09:39] <OdyX> cjwatson: ack. lintian either.
[09:39] <DktrKranz> OdyX: in theory, dak won't reject an upload if you don't pre-depend on dpkg, it does if the host running dak has an older version
[09:39] <cjwatson> the approach of checking Pre-Depends is borrowed from how dak used to add such features, modelled on when data.tar.bz2 was introduced
[09:41] <DktrKranz> cjwatson: perhaps that could be handled via a lintian tag + hard autoreject
[09:42] <OdyX> DktrKranz: that'd be cool, yes. But dak should run those autorejects on binary-only uploads from buildds.
[09:42] <OdyX> .oO(We should move the discussion to #debian-ftp @ OFTC.)
[09:58] <tkamppeter> OdyX, due to improvements in Ghostscript's PDF iunterpreter and PostScript output device, especially in terms of color management and speed I have switched the PDF->PS tasks from Poppler to Ghostscript in Ubuntu. To make it all consistent, I also wnted to change the built-in PDF->PS of foomatic-rip to Ghostscript, which I have done with this patch to ghet it into Ubuntu before Beta freeze. This is not a long-term solution (therefore the
[09:58] <tkamppeter>  patch instead of applying it upstream). Upstream this should be made configurable via the config file. If there is no urgency for an update of foomatic-filters in Debian, you could evcen wait for the upstream solution.
[09:58] <OdyX> tkamppeter: okay. Thank you.
[10:26] <astraljava> cjwatson: Alright, thanks! May I also ask for seeds upload again? I don't know where to check for if it's happened, I asked Luke a while back, but he hasn't replied.
[10:28] <pitti> tjaalton: do you have some insight into bug 820370? it looks a little weird
[10:31] <lenios> does anybody knows if the patch provided in https://bugs.launchpad.net/lightdm/+bug/602505 can be applied before oneiric release? https://bugs.launchpad.net/lightdm/+bug/602505
[10:31] <seb128> janimo, thanks for the unity bug fix, don't upload though please
[10:33] <pitti> jibel: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-xorg-stakeholders-request has "[jibel] Arrange community testing for Alpha-2: INPROGRESS" -> did that happen?
[10:34] <janimo> seb128, I am not uploading, sure
[10:34] <seb128> janimo, I will likely do an upload a bit later with some other fixes included
[10:34] <seb128> janimo, thanks
[10:34] <cjwatson> astraljava: you mean an ubuntustudio-meta upload?  I did that yesterday.  Have the seeds changed since then?
[10:34] <janimo> I am not in a hurry, and let frequently uploaded packages dealt by their de-facto maintainers
[10:35] <cjwatson> astraljava: https://launchpad.net/ubuntu/+source/ubuntustudio-meta
[10:35] <cjwatson> seb128: while you're there, I don't suppose you could deal with the occurrences of unity in http://people.canonical.com/~ubuntu-archive/nbs.html ?
[10:35] <cjwatson> well, occurrence.  it still build-depends on libxcb-icccm1-dev
[10:36] <cjwatson> astraljava: ah, yes, looks like you made a couple of changes.  I'll update it
[10:36] <seb128> cjwatson, I will have a look, thanks for pointing it
[10:38] <tjaalton> pitti: yeah I just had a quick look at it when I did another commit to xorg. I'll reboot this thing and look closer..
[10:39] <vista_killer> i still have this bug with the new kernel https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791089 is there a kernel ubuntu team in this irc?
[10:42] <jibel> pitti, yes. I updated the status.
[10:42] <pitti> jibel: ah, merci
[11:27] <astraljava> cjwatson: Yep, it's work-in-progress, we're lagging behind a bit for this cycle. Thanks a bunch for your cooperation!
[11:40] <mdeslaur> tjaalton: flashplugin-nonfree is kind of an exception. Normally I would just have killed the amd64 binary package. But in the flash case, we need to install nspluginwrapper on amd64. For skype and other stuff, all you need to do is simply stop shipping an amd64 package.
[11:41] <doko> Sweetshark, does the lo upload only fix the one bug, or does it introduce another one? ;-P
[11:45] <tjaalton> mdeslaur: yeah, I just forgot that you can actually install the i386 version of a blob instead (of a normal app) :)
[11:45] <tjaalton> so didn't need f-n as an example afterall
[11:45] <mdeslaur> tjaalton: cool
[11:52] <Sweetshark> doko: I work on Libreoffice, I use bigger units of measure than "1 bug"
[11:53] <Sweetshark> (unless fixing, which is always measure in "1 bug")
[11:55] <doko> Sweetshark, so can we kill the current build on armel? already ab-used some build time
[11:56] <Sweetshark> doko: the 3.4.2-2ubuntu1 build? yes
[11:59] <doko> Sweetshark, well, I would appreciate having a build on armel before beta1
[12:04] <Sweetshark> doko: 3.4.2-2ubuntu2 is already sponsored
[12:05] <doko> directhex, Laney: could you have a look at the nunit test rebuild failure? https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2706515
[12:10] <mdeslaur> @pilot in
[12:16] <jtaylor> mdeslaur: can you have a look at bug 455461, thx
[12:16] <mdeslaur> jtaylor: sure, one sec
[12:17] <mdeslaur> lol...libmusicbrainz4 is _older_ than libmusicbrainz3? :)
[12:17] <jtaylor> yes, in one its weird
[12:18] <jtaylor> someone did not adher to proper library package naming
[12:18] <jtaylor> the 3 in the latter is the upstream version number no soversion
[12:19] <jtaylor> in response to a question cnd asked in the merge proposal, the extra build deps are required for building with version 3, they are also in maverick+
[12:20] <mdeslaur> jtaylor: yeah, looks fine. I'll update the bug and upload. thanks
[12:25] <jtaylor> thx
[12:28] <Laney> doko: it is fixed, ajmitch was supposed to close the bug
[12:29] <doko> Laney, thanks for the update
[12:29] <doko> Laney, was the fix in another package?
[12:35] <Laney> doko: yeah, in mono
[12:35] <Laney> the change in 2.10.4-3 fixed it
[12:42] <doko> Daviey, what is the state of bug 795087?
[12:45] <Daviey> doko: zul is away today, i'll do it shortly.
[12:46]  * apw is trying to update-manager to oneiric from natty, and i am getting some 403 Forbidden returns, known?
[12:47] <doko> Daviey, never mind, everything was done, but the state was still on incomplete, and directhex didn't see either
[12:48] <Daviey> doko: Ah, ScottK tackled it
[12:48] <Daviey> super
[12:49] <directhex> doko, in upstream 2.10.4, upstream reverted a detail we were relying on for our transition to work. we reverted their revert in 2.10.4-3.
[12:50] <cjwatson> apw: any chance of switching lbm over to 3.0.0-9?
[12:51] <apw> cjwatson, can do
[12:52]  * cjwatson is unaware of 403 Forbidden on upgrade; no doubt it depends on the mirror
[12:52] <cjwatson> gb.archive seems kind of outdated the other day
[12:52] <cjwatson> *seemed
[12:53] <Daviey> cjwatson: i noticed i was getting 403's via squid-deb-proxy the other day, with that disabled it worked.
[12:59] <apw> cjwatson, yeah seems that the files are there but not readable on gb.a.u.c ok on a.u.c
[13:00] <apw> cjwatson, who owns talking to mirrors about problems
[13:02] <cjwatson> apw: not sure, try #ubuntu-mirrors
[13:05] <ScottK> Daviey: What did I tackle?
[13:11] <Daviey> ScottK: lots, and lots of win.
[13:12] <Daviey> ScottK: you fixed python-netifaces
[13:12] <ScottK> Oh, right.  The broken dh_python2 transition.
[13:12] <ScottK> No problem.
[13:12] <Daviey> yah
[13:12] <Daviey> thanks.
[13:31] <apw> cjwatson, just checking you want this -lbm update for oneiric uploaded now?
[13:34] <cjwatson> apw: yes please, if you can
[13:35] <apw> cjwatson, on it
[14:14]  * apw is just doing an upgrade and gdm and not lightdm is the default in the popup dialog, is that expected or a bug
[14:15]  * Sweetshark is happy about his big ceiling fan today.
[14:30] <victorp> sconklin, ping
[14:30] <sconklin> victorp, what's up?
[14:31] <victorp> sconklin, I have a quick questoin
[14:31] <victorp> question rather
[14:31] <victorp> about srus and security patches
[14:31] <victorp> do we have a kernel that only updates with security updates or the -updates kernel is the only one for maintenance
[14:31]  * victorp not sure that question made any sense
[14:32] <jdstrand> I can answer that
[14:32] <victorp> jdstrand, cool
[14:32] <victorp> fwiw I am mainly interested for server
[14:32] <jdstrand> victorp: in almost all cases, kernels with security fixes will have srus fixes as well. that is the SRU cadence
[14:33] <victorp> right
[14:33] <jdstrand> victorp: if an -updates kernel has no security fixes, it doesn't go to -security
[14:33] <pgraner> victorp, to answer you question the is not just a security stream
[14:33] <victorp> pgraner, yes - that was my question
[14:34] <jdstrand> victorp: it is theoretically possible for an out of band kernel to go through -security only, with no sru patches, but this is only for emergencies
[14:34] <victorp> so -security is not only security fixes, but all security fixes + whatever else made it into that kernel
[14:34] <victorp> jdstrand, ack
[14:35] <jdstrand> victorp: well, -security is for kernels with security fixes-- and they typically have other things as well
[14:35] <victorp> yes, makes sense
[14:35] <jdstrand> victorp: it used to be a bit different, but that was untenable and why we have the current process
[14:35] <jdstrand> (now)
[14:36] <victorp> the reason I am asking is because I need to figure out how often we need to test somethink that has a dependecy on ABI
[14:36] <victorp> so I was hoping that -security would break ABI less often that -updates
[14:37] <jdstrand> victorp: you might lighten your kernel churn by disabling -updates, but the frequency of vulns found in the kernel kinda makes it unlikely that it would be significantly fewer upgrades
[14:37] <victorp> but sounds that it would be almost as often
[14:37] <victorp> jdstrand, agreed
[14:38] <victorp> sconklin, I am right on assuming that each new -updates kernel is very likely to break ABI compatibility with the previous one?
[14:39] <pgraner> victorp, yes, it almost always does
[14:40] <victorp> pgraner, thanks that is what I though. fair enough
[14:40] <om26er> mdeslaur, Hi! could you sponsor https://code.launchpad.net/~om26er/ubuntu/oneiric/empathy/fix-crashes/+merge/72761 please
[14:40] <mdeslaur> om26er: let me take a look
[14:49] <om26er> mdeslaur, are you bulding it?
[14:49] <mdeslaur> om26er: I will, yes...but am asking in #ubuntu-release if I can upload it since the archive is frozen
[14:52] <om26er> ok.
[14:56] <mdeslaur> om26er: ok, got approval, will upload in a few minutes
[14:58] <om26er> mdeslaur, great, thank you :)
[15:25] <pitti> ogasawara: OOI, why are the 3.0.1 upstream kernels called 3.0.0-9?
[15:29] <ogasawara> pitti: mostly old habits... when we'd originally had 2.6 kenels we stayed with the 2.6 package version, even though they were technically 2.6.x.  And we originally started out with a 2 digit 3.0 version scheme.  Now that we're into a 3 digit scheme, we could likely start reflecting the actual stable version.
[15:29] <ogasawara> pitti: I'll bring it up with the rest of the team
[15:30] <pitti> not a biggie, I just wondered
[15:33] <ogasawara> pitti: tgardner did also bring up a good point that we don't always take all of upstream stable, so it wouldn't be entirely accurate
[15:36] <ogra_> pitti, seems tp-glib is gone from http://qa.ubuntuwire.org/ftbfs/ too now, seems it got fixed today
[16:02] <mdeslaur> @pilot out
[16:05] <cjwatson> ScottK,debfx: would anyone cry if I dropped the ruby-kate package?  it can't build since kate_smoke went away
[16:05] <ScottK> cjwatson: No.  Removing it is on the TODO list.
[16:06] <cjwatson> I'll go ahead and do that then
[16:06] <ScottK> Hopefully the qtruby upload that debfx did will make korundum buildable so I can do that.
[16:09] <pitti> cjwatson: anythign I can help with there in ubuntu-defaults-image?
[16:10] <cjwatson> ScottK: no, not quite, that's where I was starting from
[16:11] <cjwatson> ScottK: but the thing that breaks is the include of kate_smoke.h - it's not testing for that properely
[16:11] <cjwatson> so I wanted to know whether the obvious "check that and don't build the kate module" was right
[16:11] <ScottK> Yes.  Please.
[16:11] <cjwatson> pitti: u-d-i is OK I think, it's something wrong with the livecd-rootfs integration
[16:12] <cjwatson> the log didn't have anything obvious
[16:12] <pitti> next week I'll look at making the iso smaller, it currently comes out at 740 MB or so
[16:16] <tjaalton> pitti: sorry, couldn't fix that xorg bug, spent too much time triaging unity ;) but next week
[16:16] <pitti> tjaalton: oh, I just wondered if this is "triaged", or needs some further debugging/explanatino
[16:17] <pitti> tjaalton: the half of it where it doesn't remove a non-empty directory isn't a bug, but there was some other half which did sound like a breakage; I just wondered why /etc/gdm is covered by the generic x11-common package
[16:19] <pitti> have a nice weekend everyone!
[16:21] <tjaalton> pitti: because failsafe-x used to install stuff there, and kubuntu system doesn't have gdm
[16:24] <cjwatson> ScottK: does http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/korundum/revision/6 look plausible to you?
[16:25] <cjwatson> oh, I should add DEP-3 headers
[16:26] <cjwatson> (done)
[16:33] <ScottK> cjwatson: Yes.
[16:34] <cjwatson> ok, uploading, thansk
[16:34] <cjwatson> *thanks
[16:37] <ScottK> cjwatson: Accepted.
[17:01] <bdmurray> Is there a patch piloting schedule so I can figure out who to wait for and pounce on?
[17:05] <stgraber> bdmurray: IIRC there's a google calendar for that
[17:06] <micahg> bdmurray: it's rodrigo and mdeslaur today, my guess would be both are done for the day
[17:06] <bdmurray> :-(
[17:06] <mdeslaur> bdmurray: I'm done, but do you want me to look at something?
[17:06] <stgraber> bdmurray: Calendar ID: 6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com
[17:07] <stgraber> bdmurray: I'm also happy to sponsor
[17:07] <bdmurray> Thanks - https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/ubiquity-dupe-sig/+merge/72989
[17:08] <stgraber> looking
[17:08] <bdmurray> I've detailed what this does in the merge proposal and I could provide more information about the testing I've done if somebody wants to test it.
[17:09] <stgraber> bdmurray: is that something you'd like to have for beta1? (I'll upload anyway but you may want to poke -release if you want it in for beta1)
[17:09] <bdmurray> stgraber: yes so we can get the duplicate signature in the bugs as people are testing
[17:09] <bdmurray> stgraber: this allows the retracer to automatically duplicate bug reports
[17:10] <stgraber> bdmurray: ok, I'll review, upload and mention it in -release then
[17:11] <bdmurray> stgraber: great, thank you!
[17:22] <apw> cjwatson, i tried to upload the oneiric-lbm you requested, but just noticed it got bounced as linux-backports-modules-3.0.0 is not on the kernel upload rights
[17:31] <kees> how do I make network-manager not steal my resolv.conf ?
[17:32] <infinity> kees: chattr +i? :P
[17:32] <infinity> kees: (Or stop managing interfaces with NM...)
[17:32] <nigelb> infinity: hehe, that's what I'd done.
[17:33] <infinity> kees: I dunno.  I just use append/prepend/supersede in dhclient.conf to get a nice merge of "what the DHCP server told me" and "what I actually want".
[17:33] <mdeslaur> kees: click on the options, and select "automatic dhcp, adresses only"
[17:33] <infinity> kees: Which seems to me like the "correct" solution, cause you do kinda want to know what the DHCP server told you too, right?
[17:34] <kees> well, see, the problem is I have none of my interfaces managed by network-manager, but it decides to wipe out resolv.conf anyway
[17:34] <infinity> kees: Err, oh.  That's differently special.
[17:34] <mdeslaur> kees: you wireless either?
[17:34] <kees> this is on my desktop.
[17:34] <mdeslaur> kees: what you need to do is have network manager manage ALL your interfaces...then it just works :)
[17:35] <kees> or maybe there's some magic interface it thinks its managing? how do I get it to tell me which it's operating on?
[17:35] <kees> mdeslaur: no, no, that's the opposite of what I want. :)
[17:35] <mdeslaur> kees: that's cause you're doing it wrong :)
[17:35] <mdeslaur> kees: does it have an auto interface listed in "wired connections"?
[17:36] <kees> mdeslaur: it's not wrong -- it's a server as far as I'm concerned. :)
[17:36] <mdeslaur> kees: why are you running network manager on a server?
[17:36] <infinity> And why does a server have NM installed?
[17:36] <mdeslaur> lol
[17:36] <mdeslaur> attack of the trolls
[17:36] <kees> this circular trolling isn't working
[17:36] <infinity> We can try harder!
[17:36] <kees> hehe
[17:36] <infinity> But yeah, does NM list any interfaces in the drop-down UI?
[17:36] <kees> okay, so, if I start nm, it wipes out my resolv.conf.
[17:36] <mdeslaur> kees: seriously, do you have an auto interface in "Wired"?
[17:37] <kees> mdeslaur: I don't have an applet because it's not running
[17:37] <infinity> You're the best debugging buddy ever.
[17:37] <kees> sudo chattr +i /etc/resolv.conf; sudo service network-manager start ...
[17:37] <infinity> "My car's making weird noises, but I left it at home."
[17:38] <mdeslaur> kees: either kill it completely, or don't kill it at all
[17:38] <mdeslaur> kees: in /etc/NetworkManager/system-connections, do you have any files?
[17:38] <kees> nope
[17:39] <kees> mdeslaur: okay, in the applet, "enable networking" is greyed out :)
[17:39] <kees> well let me chattr -i again, just for fun
[17:40] <kees> currently, the file is fine. nm loves to gas-light me
[17:40] <kees> uhp, nope, there is goes. wiped the file.
[17:41] <kees> mdeslaur: okay, I have no network connections listed in the "edit connections" dialog.
[17:41] <mdeslaur> hmm
[17:41] <kees> and yet it wiped out the file.
[17:41] <mdeslaur> that's not very nice
[17:41] <kees> agreeds
[17:41] <mdeslaur> open a bug
[17:41] <kees> will do.
[17:41] <kees> in the meantime.... chattr +i :)
[18:41] <lucidfox> YokoZar, any chance for a wine1.3 update in Oneiric?
[18:57] <nigelb> 32-bit binaries should work fine on 64-bit machines, shouldn't they?
[18:58] <lucidfox> if the required libraries are installed, yes
[18:59] <nigelb> Mine just fails. Sigh.
[18:59] <ion> and if the architecture supports 32-bit code.
[18:59] <nigelb> x86_64
[18:59] <nigelb> The longer fix is to just use 64-bit, but I'm puzzled by the failure.
[19:03] <infinity> nigelb: How does it fail?
[19:04] <nigelb> infinity: well, it just doesn't work. I tried with 64-bit binary and it worked. I canste the error if you'd like.
[19:04] <infinity> An error tends to be more informative than "doesn't work". ;)
[19:05] <nigelb> "-bash: ./check_disk: No such file or directory"
[19:05] <slangasek> that would be the classic posix error value, ENOWORKIE
[19:05] <infinity> But it's probably as lucidfox says, and you're missing some 32-bit userspace bits.
[19:05] <slangasek> nigelb: you don't have the 32-bit ld.so.
[19:05] <nigelb> ah.
[19:05] <nigelb> how do I get them?
[19:05] <slangasek> you need to install the libc6:i386 package (or on pre-oneiric, libc6-i386)
[19:05] <nigelb> wait, this is lucid.
[19:06] <infinity> Yeah, libc6-i386 on lucid.
[19:06] <nigelb> ah.
[19:06] <nigelb> I should have read, appologies.
[19:06] <nigelb> hm, when did this locale error start showing up :|
[19:07] <infinity> Perl complaining about your locales?
[19:07] <nigelb> yeah
[19:07] <infinity> That's entirely valid. :P
[19:07] <nigelb> I need to note down somewhere how I fix it.
[19:07] <infinity> The machine you're SSHed into doesn't have the locale generated that your client pushed.
[19:08] <nigelb> so, its not a server thing, but just something a combination of that machine + client?
[19:08] <infinity> (ie: if you are SSHing from a machine with en_US.UTF-8, it will helpfully push that to the remote machine, which doesn't have it built)
[19:08] <nigelb> ah, I know what's wrong then.
[19:08] <infinity> It's not a "problem" with either machine, per se, except that I consider remote locale poisoning a braindead feature.
[19:08] <nigelb> I'm SSH-ing into a server from another server.
[19:09] <infinity> But then again, I speak English.  I imagine others find the feature pretty handy.
[19:09] <nigelb> Phew, I was afraid of another few hours of debugging.
[19:09] <nigelb> I doubt my terminal has had to display anothing non-English.
[19:09] <nigelb> well, except when I'm using irssi.
[19:10] <mdeslaur> infinity: yeah, but you get weird spelling when the remote machine doesn't have en_CA
[19:10] <infinity> But yeah, the messages are harmless, and only due to your LANG being set to a locale that the host doesn't have installed/built.
[19:10] <infinity> Everything gracefully falls back to LANG=C in that case anyway.
[19:10] <nigelb> "gracefully"?
[19:10] <nigelb> :)
[19:10] <infinity> Well, perl's verbose about it.
[19:11] <infinity> But it still works!
[19:11] <nigelb> except autocompletion throws me 3 lins of errors
[19:11] <nigelb> ;)
[19:11] <infinity> That's marginally more icky, yes.
[19:11] <infinity> Fix your locales? :P
[19:12] <nigelb> My usual fix is to do export LC_ALL="en_US.UTF8" in the .bashrc
[19:12] <nigelb> is that a kosher enough fix? :)
[19:12] <infinity> If only that was a valid locale...
[19:12] <nigelb> oh.
[19:12] <infinity> Plus, you probably want LANG, not LC_ALL.
[19:13] <infinity> But more importantly, I'm assuming that server you're on doesn't have any locales generated.
[19:13] <infinity> Which is pretty common.
[19:13] <nigelb> what is the Right thing to do™?
[19:13] <nigelb> generate locales?
[19:13] <infinity> If you want UTF all over and the same locale all over, just "sudo locale-gen en_US.UTF-8" on all your hosts.
[19:13] <nigelb> localegen or some such?
[19:13] <infinity> Or install a langpack.
[19:14] <infinity> Which will do it for you.
[19:14] <infinity> SSH will helpfully forward your LANG across connections, so if your local locale also exists on the target host, it all Just Works.
[19:14] <nigelb> aha, thanks!
[19:15]  * nigelb removes the .bashrc hack
[19:17] <nigelb> infinity: I owe you a beer! :D
[19:42] <cjwatson> apw: you should have linux-backports-modules-3.0.0 upload rights now
[20:45] <jdstrand> apachelogger: hey, is there a bug associated with your kde-l10n-ug upload?
[20:52] <jdstrand> apachelogger: actually, I had another question. sent via email
[22:23] <jo-erlend> how do I report a security issue that causes you to gain access to a locked desktop by pressing a keyboard combination? I don't know what package to file against, and launchpad won't let me file bugs without associating with a package.
[22:24] <ion> Report it against gnome-screensaver, the most probable culprit. If it’s not a gnome-screensaver issue, someone will change it.
[22:24] <jo-erlend> oh, ok.
[22:47] <bdmurray> Has anybody run into this issue when authenticating with Launchpad via launchpadlib?
[22:48] <bdmurray> ERROR: connecting to Launchpad failed: unclosed token: line 38953, column 8
[22:58] <bdmurray> Well okay the last thing I did that may have resolved it was rm * in ~/.launchpadlib/api.launchpad.net/cache