[00:42] <mpiechotka> Hello. Sorry for dropping in but by accident I noticed that Ubuntu (in all version but Oneiric Ocelot) contains versions of libgee with known bugs. I don't know the Ubuntu policy but I'd highly recommend to upgrade to 0.6.2.1 [which contains bugfixes to 0.6.1, 0.5.3 and 0.5.0 which are in Natty Narwhal, Maverick Meerkat and Lucid Lynx respectively].
[00:49] <RAOF> slangasek: Re: bug #851947 - the multiarch mesa DRI drivers aren't installable as libdrm-intel1 grew a dependency on libpciaccess0, which I multiarched and is in Sid now, but I didn't notice that it wasn't in Ubuntu.
[00:49] <RAOF> slangasek: If we're going to remove mesa from ia32-libs (which seems reasonable) that might mean we want to sync libpciaccess from Sid.
[00:50] <mbiebl> RAOF: heya
[00:50] <RAOF> mbiebl: Yo.
[00:50] <mbiebl> got my colord bug report?
[00:51] <mbiebl> would be cool if you can update it, I'm currently working on g-c-m 3.2.0
[00:51] <mbiebl> I can send you a debdiff for colord 0.1.12 if that helps
[00:52] <RAOF> It's ready and waiting in collab-maint git; I just haven't done the sponsor dance yet.
[00:52] <mbiebl> ah, great.
[00:52]  * RAOF needs to go for DM
[00:52] <mbiebl> let me take a look
[00:52] <mbiebl> I'll sponsor it for you, if you don't mind
[00:53] <RAOF> I don't mind at all!
[00:54] <mbiebl> ok, will take a closer look tomorrow
[00:55]  * mbiebl → bed
[00:57] <mbiebl> RAOF: a few quick comments:
[00:58] <RAOF> Shoot.
[00:59] <mbiebl> the if ! getent group scanner >/dev/null; then
[00:59] <mbiebl> checks are unnecessary
[00:59] <mbiebl> adduser already does the right thing
[00:59] <mbiebl> and adduser --system already creates the corresponding group
[00:59] <mbiebl> so no need to split that
[01:00] <infinity> Since when does adduser exit 0 if a group exists?
[01:00] <infinity> I've always done "getent blah || adduser", because it choked if you didn't.
[01:01] <mbiebl> I don't know the version number
[01:01] <mbiebl> http://wiki.debian.org/AccountHandlingInMaintainerScripts
[01:03] <mbiebl> RAOF: forgot to add adduser --system *--group colord*
[01:03] <mbiebl> will create the corresponding group
[01:03] <RAOF> :)
[01:04] <RAOF> I'm happy to make those changes if you like.
[01:05] <mbiebl> regarding the dependencies of libcolord-dev
[01:05] <mbiebl> does pkg-config still choke on missing requires.private deps?
[01:05] <mbiebl> I thought that was fixed and only required for static linking
[01:07] <RAOF> It does, or at least did.
[01:09] <RAOF> The gnome-control-centre / g-s-d plugins failed to build without those extra dependencies.\
[01:10] <slangasek> RAOF: I've not proposed removing mesa from ia32-libs, only putting it back where it's not on the default path (because the way it was put there was broken)
[01:11] <RAOF> slangasek: Ah, ok.  Good.
[01:12] <mbiebl> RAOF: hm, with PK support disable and instead using at_console, isn't there a problem with everyone being able to install profiles system wide?
[01:12] <mbiebl> and at_console is something we actually want to get rid of
[01:12] <mbiebl> not use instead of PK
[01:13] <RAOF> That's the existing PK behaviour; they're all <allow_active>yes</allow_active>.

[01:14] <mbiebl> is for org.freedesktop.color-manager.install-system-wide
[01:14] <RAOF> *facepalm*
[01:14]  * RAOF missed that.
[01:14] <RAOF> I've got a PolicyKit patch that removes the limitation which makes it unusable for unprivileged daemons, so polkit 0.103 should support this.
[01:15] <mbiebl> argh, polkit 0.103 has dropped libpolkit-gtk
[01:15] <mbiebl> so I can't upload it to Debian just yet
[01:16] <RAOF> I don't see that in the git log?
[01:17] <RAOF> Are we talking about the same thing?
[01:18] <mbiebl> meh, was looking at pk-gnome
[01:18] <RAOF> In fact, I see exactly one non-version-bump commit between 0.102 to master :)
[01:18] <mbiebl> definitely bed time for me
[01:18] <mbiebl> can I catch you on irc tomorrow?
[01:19] <RAOF> Yes.
[01:19] <RAOF> I'll be here from ~7:30 UTC+10
[01:20] <mbiebl> ok, cu then
[01:47] <Laibsch> Hey guys, I maintain the scim package in Debian and I'm trying to get it to support multi-arch.  Is there a way to get the equivalent of $(dpkg-architecture -qDEB_HOST_MULTIARCH) on a user system without having dpkg-dev installed?
[01:47] <Laibsch> #multiarch is quiet so I hope somebody can enlighten me here?
[01:50] <clahey> I would like to create an updated lilypond deb.  How do I do so?
[01:51] <clahey> Is there a tutorial somewhere?
[01:51] <Laibsch> clahey: "pull-lp-source lilypond && cd lilypond-* && echo "make changes here && pdebuild"
[01:52] <Laibsch> that's the really short version.  a more elaborate version depends on what you already know ;-)
[01:52] <Laibsch> in essence, get the source, hack away, build, test, repeat
[01:54] <clahey> pdebuild?
[01:54] <RAOF> Laibsch: I don't believe so, although you could maintain your own set of arch ? multiarch tuple mappings I guess.  What do you want it for?
[01:54] <clahey> Is there a maintainer for lilypond?
[01:56] <Laibsch> RAOF: thank you for your reply.  I recently updated scim because the multi-arch stuff caused a FTBFS.  But now I get a regression because the program looks for plugins in the non-multiarch location.
[01:56] <Laibsch> http://paste.debian.net/132934 is what I supposed for a fix but jwilk correctly pointed out that this could lead to another regression in certain situations.
[01:57] <Laibsch> assume an AMD64 host which has i686 input methods installed.  Those will be valid candidates due to the wide-ranging asterisk condition in that patch.
[01:58] <RAOF> Laibsch: Oh, super fun.
[01:58] <Laibsch> I want to replace /*/ in that patch with /$DEB_HOST_MULTIARCH/ as in http://paste.debian.net/132936
[01:58] <RAOF> Laibsch: This is an arch: any package, right?
[01:58] <Laibsch> but http://paste.debian.net/132934 would introduce a dependency on dpkg-dev
[01:58] <RAOF> Laibsch: Can you not just generate that script (or reference DEB_HOST_MULTIARCH at those points, and set it at the top of the script) at package build time?
[01:59] <Laibsch> I don't maintain the other packages
[01:59] <Laibsch> jwilk also suggested to deal with the problem at build time
[01:59] <Laibsch> but then I was the one to object ;-)
[02:00] <Laibsch> scim binary package is MA:foreign (as per slangasek's suggestion), so that AMD64 host could have an i686 package of it installed.
[02:00] <Laibsch> I'm sure I'm not going to be the only one with this issue in the future, so I assume there will be a general solution eventually
[02:01] <RAOF> Well, I think yours is a pretty special case; most plugin systems will hardcode the directory at build time.
[02:01] <Laibsch> which was what we did so far
[02:01] <RAOF> There may be other cases like it, but I wouldn't expect too many.
[02:01] <Laibsch> but I think multi-arch breaks that
[02:02] <RAOF> No?
[02:03] <Laibsch> I think this issue will arise for any binary that has a) plugins and is b) MA:foreign
[02:03] <Laibsch> plugins as separate packages
[02:03] <RAOF> MA: foreign means that it can *satisfy* dependencies, right?
[02:03] <Laibsch> MA:foreign means that the build host's arch is irrelevant
[02:04] <Laibsch> My understanding is that foreign means that an AMD64 host can install an i686 version of the scim binary package
[02:04] <Laibsch> => build host and user host have no relation at all
[02:04] <RAOF> Well, an AMD64 host can *always* install an i686 version of scim.
[02:04] <Laibsch> take another arch
[02:05] <Laibsch> it's the only two I can come up with now ;-)
[02:05] <RAOF> An AMD64 host can *always* install an armel version of scim.
[02:05] <Laibsch> Update My understanding is that foreign means that a sparc host can install an i686 version of the scim binary package
[02:05] <RAOF> What MA:foreign means (IIUC) is that an i386 scim package can satisfy *dependencies* for an amd64 package.
[02:05] <Laibsch> yes
[02:06] <RAOF> See what python's doing with this; they're in essentially the same boat.
[02:06] <Laibsch> enlighten me, please
[02:07] <Laibsch> am I completely wrong in assuming that build host arch doesn't necessarily equal user host arch in case of MA:foreign?
[02:08] <Laibsch> s/assuming/deducing/
[02:11] <RAOF> If scim is built on amd64 (and contains native code) then there's no point in looking anywhere but /usr/lib/x86_64-linux-gnu; it won't be able to load i386 plugins.  Similarly, for i386.
[02:14] <RAOF> Python is in the same boat; I'm not familiar with exactly what they do, but that's what I'd look to.
[02:15] <Laibsch> I'm wondering about the MA:foreign setting for the scim binary package.  I guess what slangasek meant is that for compile-time purposes and armel binary on an amd64 host is OK.  But I cannot think the same is true for running any binary inside the scim package.
[02:15] <Laibsch> the amd64 host would need the amd64 binary package, right
[02:15] <RAOF> Laibsch: https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships might be what you're after.
[02:25] <YokoZar> slangasek: RAOF: uploading an ia32-libs that reverts the libGL links right now, which should break mesa
[02:36] <Laibsch> RAOF: multi-arch is mostly concerned about compile-time, not necessarily run-time right?  I don't think the scim-binary package is a compile-time dependency for just about anything, there's libscim-dev for that.
[02:36] <RAOF> No, multiarch is runtime.
[02:37] <RAOF> As in: install $FOREIGN_ARCH packages on $NATIVE_ARCH, and have them work at runtime.
[02:37] <RAOF> (Compile time is a nice side-benefit)
[02:37] <Laibsch> but if anybody were indeed to ever install the scim binary package on a host that differs from the build-host the binaries inside the package would not run, right?
[02:37] <Laibsch> OK
[02:37] <YokoZar> Speaking of multiarch: https://bugs.launchpad.net/ubuntu/+source/wine1.3/+bug/852101
[02:38] <YokoZar> apparently not having any multiarch libs causes problems now
[02:38] <Laibsch> RAOF: I see.  Then I think the issue I raised will eventually come up.  And I don't think it's the same as the python case.  But this stuff gets my head spinning.
[02:39] <Laibsch> YokoZar: multi-arch is new.  There's going to be lots of wrinkles iron out.  I suppose by 12.04 things should look much better.
[02:42] <RAOF> Laibsch: I guess I'm not entirely sure why you'd set MA: foreign for scim.
[02:46] <Laibsch> because the master himself AKA slangasek told me so ;-)
[02:47] <infinity> Laibsch: Multi-arch has nothing to do with build-time (except for the part where we have to mangle toolchains and packages to deal with things moving), it's all about run-time
[02:49] <infinity> Laibsch: What "MA: foreign" means is that it can be installed on a foreign arch (say, i386 on amd64, or arm on i386, thanks to binfmt_misc emulation), but can't be installed with itself.
[02:49] <infinity> Laibsch: As opposed to MA: same (which multi-arched libs have), which can be installed on foreign arches, but don't conflict with themselves.
[02:49] <RAOF> infinity: *And* that it'll satisfy cross-architecture dependencies, right?
[02:50] <infinity> Laibsch: (And same can only be used to satisfy deps from the same arch, foreign can stisfy deps from another arch)
[02:50] <infinity> RAOF: Yeah, I was getting there. :)
[02:50] <infinity> RAOF: The names relate more to the dependency issues, but most people understand the other concept better, so I start there. :P
[02:51] <RAOF> And MA: foreign doesn't actually allow you to install on a foreign arch; you can do that anyway.
[02:52] <RAOF> At least, I'm pretty sure you can, as long as the dependency chain is either (a) disjoint from any native dependency chain, or (b) multiarched.
[02:52] <infinity> Well, fair point.
[02:57] <infinity> YokoZar: Sounds like wine's messed up its deps, then. :/
[02:59] <Laibsch> infinity: I'd be lying if I claimed that this is easy for me to understand.  Let me try to summarize.
[02:59] <Laibsch> scim binary package is MA:foreign and thus only one version of the package can be installed at any one time.
[02:59] <Laibsch> but it can be a foreign or the native arch.
[03:00] <Laibsch> if foreign arch, will the binaries run correctly or not?
[03:00] <infinity> slangasek: Painfully late in the game for this, but probably low impact.  How would you feel about an ia32-libs-multiarched metapackage (i386-only) that depends on everything that's been removed from ia32-libs since the MA adventure started, and ia32-libs can depend on it?  So, no surprises for upgrades.
[03:01] <infinity> Laibsch: Whether they can run or not is up to the sysadmin, not you.  They could be i386 on amd64 (which will work), they could be emulated (which might work)...
[03:02] <infinity> Laibsch: I can run several architectures on my laptop emulated, and two natively.
[03:03] <infinity> Laibsch: Packaging tools will not satisfy a dependency with an "MA: foreign" package from another arch if one is available for the native arch, and even then, you nominate your foreign arches in a config file, so it's not like apt will just run off and grab a Sparc binary for you and then laugh when it doesn't work. ;)
[03:06] <infinity> slangasek: Seeing "solutions" thrown around like "install skype:i386, it will restore all your missing 32-bit libraries!" makes me think an ia32-libs -> ia32-libs-multiarched hack is slightly less icky than it sounds, as a migration path anyway.
[03:08] <Laibsch> infinity: I understand that obviously the native arch version will be preferred.  But for the sake of understanding, I was wondering for example what happens if for whatever reason a foreign arch gets installed.
[03:08] <Laibsch> Whether or not the binary actually runs depends on the support for the foreign arch on the host?  Support for the foreign arch can either be native or emulated?
[03:09] <Laibsch> Man, this is heavy stuff, gets my head spinning.  (But it did for jwilk as well, so I don't feel bad ;-))
[03:12] <infinity> Laibsch: Yeah, if you nominate a foreign arch in your dpkg configs, it's up to you to make sure it works.
[03:12] <infinity> Laibsch: We turn on i386 on amd64 by default because we make that work, other whacky combinations are left to users to work out.
[03:13] <Laibsch> I see
[03:13] <Laibsch> I didn't know that an arch has to be specifically turned on to become installable
[03:13] <infinity> Aye.
[03:13] <infinity> adconrad@cthulhu:~$ cat /etc/dpkg/dpkg.cfg.d/multiarch
[03:13] <infinity> foreign-architecture i386
[03:14] <infinity> ^-- For instance.
[03:14] <infinity> That one is set up on install or upgrade to oneiric on amd64 machines.
[03:15] <Laibsch> OK.  Let me log into a Debian unstable pbuilder to see what I find there.  RAOF mentioned this earlier, but I wonder what happens if I mix an i386 plugin package with an amd64 scim package on an amd64 host, for example?
[03:15] <Laibsch> infinity: can you tell me more about the laptop you mentioned earlier and the arches it supports?
[03:16] <infinity> Laibsch: Assuming the plugins are DSOs, that sort of mixing and matching isn't going to work.
[03:18] <infinity> Laibsch: As for the laptop, it supports (in theory) amd64 and i386 natively, and everything that qemu-user-static supports for virtualisation.  Due to some issues with some architectures having overlapping loader locations, that's not actually completely true yet, though.
[03:18] <infinity> Laibsch: But I run ARM binaries on it with no issues, for instance.
[03:19] <infinity> s/virtualisation/emulation/
[03:19] <infinity> It's late, I can't brain anymore.
[03:45] <Laibsch> infinity: what is preventing the user from attempting to install a mix and match even in case of DSOs?
[03:46] <infinity> Sane dependencies of some sort, I suppose.
[03:47] <infinity> Not sure how most DSO maintainers deal with it so far, TBH.
[03:47] <infinity> In the usual "applications and libraries" sort of scenarios, the applications are MA: foreign, and the libraries are MA: same, so any app->lib (or lib->lib) deps will be met by same-arch libs.
[03:49] <infinity> In a DSO situation, you may well need to look at it a bit backward, and treat the application that allows plugins as a library.  I'm not sure if we have any good examples of this just yet.
[03:49] <infinity> Or actually, no.
[03:49] <infinity> Or, yes. ;)
[03:49] <Laibsch> I'm still trying to figure out if it's completely impossible that a user will install (and attempt to run) for example: amd64 host, scim is i386 and input method plugin is amd64
[03:50] <infinity> Yeah.  Since the dep only goes one way (DSO->app), it gets messy. :/
[03:50] <infinity> Do the DSOs depend on scim, or on libscim?
[03:50] <Laibsch> If I hardcode the build-host into the path were scim will look for plugins (suggestion jwilk) that would be i386 one, and not find a valid plugin in this case.
[03:50] <infinity> Depending on libscim would solve it, since the library should be MA: same when multiarched.
[03:51] <infinity> Laibsch: And, a random one (scim-hangul) seems to depend on the library.
[03:52] <infinity> Laibsch: So, yeah.  If all DSOs depend on libscim, then if libscim is multiarched with "MA: same" (as a multiarch lib should be), your whole stack will be forced to match by the packaging system.
[03:52] <infinity> Or.  I guess you could still have both libscims installed, an i386 scim, and a few amd64 DSOs, eh? :P
[03:53] <infinity> Maybe a perfectly valid reason to not multiarch the package at all. :P
[03:53]  * infinity ponders this more.
[03:53] <Laibsch> this is way over my head :-P
[03:54] <Laibsch> I am not maintainer of the plugins, so I can never be sure on what they depend on
[03:54] <Laibsch> and I thought I remembered that most of them depend on scim directly
[03:54] <Laibsch> scim-bridge-agent is one of them (although a bad example)
[03:55] <infinity> Well, it also depends on the library too.
[03:55] <Laibsch> scim-modules-socket depends on the lib
[03:55] <infinity> But yeah, that still doesn't resolve your concern.  One could have a bunch of DSOs installed for the wrong arch and they'd just not be found.
[03:56] <Laibsch> this seems to be such corner case, one which may never materialize
[03:56] <Laibsch> and which may even be impossible
[03:56] <infinity> Well, the real answer may be that it doesn't matter.  If the user chooses to install mismatched IMEs, maybe they have some weird reason to do so.
[03:56] <Laibsch> I only want to understand a bit more before consciously taking the plunge
[03:56] <Laibsch> if things go wrong I can always point fingers at jwilk
[03:56] <Laibsch> and you :-p
[03:57] <infinity> But having your DSOs in an arch-specific path would help to at least have them not even found, rather than attempt to load and fail.
[03:57] <Laibsch> yes
[03:57] <Laibsch> I think assuming build host for whatever scim package is installed determines lookup path for the modules should be a valid approach
[03:58] <Laibsch> thank you for your time and insight, infinity
[03:59] <infinity> Yeah.  Now you have me trying to think of a foolproof way around this, though.
[03:59] <infinity> When I should be relaxing and/or sleeping. :)
[03:59] <Laibsch> hehe
[03:59] <infinity> So, thanks for that. :P
[04:00] <Laibsch> I'm glad you can't touch me
[04:00] <Laibsch> and over here it would not be a concern, bright daylight!
[04:04] <YokoZar> infinity: I agree with your suggestion to slangasek about a transitional package btw, or at least some sort of intelligence in update-manager/software center
[04:04] <infinity> Laibsch: Pretty much the most evil thing I can think of would be for scim to provide scim-$arch, and have the DSOs depend on scim-$ARCH, but I still feel like I'm missing sometihng.  (of course, just as simple is to not multiarch it at all, but I assume someone wants the library multiarched, at least, to allow for a dependency chain to be MA)
[04:04] <infinity> YokoZar: A packaged solution is always better than an installer hack.
[04:05] <infinity> YokoZar: Since the latter only works for people who use the one upgrade method.
[04:05] <YokoZar> infinity: but I'm not sure why Wine is breaking in this regard because it shouldn't be linking anything from the i386 multiarch folders in its configure/build (indeed they aren't even available at build time)
[04:05] <infinity> YokoZar: Yeah, I'm not sure why wine breaks either.  It doesn't break here, but I have a ton of :i386 stuff installed.  I could yank it all out, I guess. :/
[04:05] <infinity> YokoZar: Either way, I think ia32-libs just randomly dropping libraries on the floor is non-obvious.
[04:05] <Laibsch> infinity: the reason I got started with multiarch on this package was an FTBFS.  The fix for it introduced a regression. My concern is now to fix the regression the best and most robust way possible.
[04:06] <infinity> YokoZar: Do you have a concise list of libraries dropped from ia32-libs sine MA began?
[04:06] <infinity> s/sine/since/
[04:06] <YokoZar> infinity: I suspect that's the reason we missed this particular bug as well, cause all of us concerned HAD multi-arch packages enabled
[04:06] <YokoZar> infinity: they should all be enumerated in the ia32-libs changelog
[04:07] <YokoZar> Speaking of which, Oneiric Wine actually builds with a couple less features than Natty Wine because those packages were dropped from ia32-libs :/
[04:07] <YokoZar> Nothing too important though
[04:07] <infinity> YokoZar: I'd love you forever if you could make the aforementioned ia32-libs-multiarched metapackaga and a matching ia32-libs upload to depend on it.  I'd review it in the morning and rubber-stamp it if Steve doesn't threaten to kill me.
[04:09] <infinity> YokoZar: I assume the ultimate solution here is to drop wine from amd64 entirely, right?
[04:09] <YokoZar> infinity: I assume I avoid stepping on cross-architecture-dependency-nono by making ia32-libs-multiarched i386 only, MA:foreign, and having ia32-libs depend on it yes?
[04:09] <infinity> YokoZar: (In fact, why haven't we?)
[04:09] <infinity> YokoZar: Yeah, same trick we pull with flash-*
[04:09] <infinity> YokoZar: amd64 package depending on something that only lives in i386.
[04:09] <infinity> YokoZar: Which is also how I assume you'd do a smooth transition to "oops, wine doesn't exist on amd64 anymore".
[04:10] <YokoZar> infinity: 64-bit Wine complicates this
[04:10] <infinity> Oh, derp.  64-bit Windows.  Right.
[04:10] <infinity> Somehow, that didn't even cross my mind.
[04:10] <YokoZar> infinity: There was going to be this weird transitional state this cycle where Wine needed to be split into two separate packages and it didn't happen
[04:10] <YokoZar> infinity: But more importantly, not all of Wine's deps are multiarch enabled
[04:11] <infinity> Check.
[04:11] <YokoZar> So next cycle :P
[04:11] <infinity> Early next cycle, I hope.
[04:11] <YokoZar> Yeah me too
[04:11] <infinity> I'm not okay with wine being even remotely broken and/or a joke in an LTS.
[04:12] <infinity> People downplay its important a lore more than I'd like.
[04:12] <infinity> (And this is from someone who runs no win32 software)
[04:12] <infinity> s/important/importance/
[04:12] <YokoZar> This UDS Steve and I are gonna play a hand of poker to decide who gets to be the one to make the final "ia32-libs removed forever" upload
[04:12] <infinity> While you're fighting for the honor, I'll upload.
[04:12] <infinity> <3
[04:12] <StevenK> Haha. Just one?
[04:12] <YokoZar> Perhaps we should have a lottery...
[04:13] <StevenK> Sure, but which archive admin gets to lp-remove-package it? :-)
[04:13] <infinity> I'll have a loop running on ftpmaster.
[04:13] <StevenK> Poor cocoplum.
[04:13] <infinity> Check for (conditions); remove ia32-libs
[04:15] <pitti> Good morning
[04:15] <infinity> [ "$ANYTHING_GOOD_ON_TV" = "false" ] && CONDITIONS=perfect
[04:15] <infinity> pitti: Evening.
[04:16] <infinity> StevenK: Please rename lp-remove-package to business-time, thanks.
[04:16] <StevenK> infinity: File a bug.
[04:17] <StevenK> So I can laugh at you, and close it.
[04:17] <infinity> Those don't end well.
[04:17] <infinity> And that's crazy talk, my LP bugs never get closed.
[04:17] <YokoZar> CLOSED: OPINION
[04:17] <infinity> They stay open for about 6 years, bounce between medium and critical, get lots of comments, and get reassigned about 12 times.
[04:22] <StevenK> infinity: Lies!
[04:22] <StevenK> infinity: You have *30* closed Launchpad bugs
[04:23] <StevenK> Sorry, 28. 30 is the id for Fix Released
[04:25] <YokoZar> infinity: if I make ia32-libs-multiarch and depend on it with ia32-libs, won't that be a problem when packages like wine build-depend on ia32-libs?
[04:25] <YokoZar> (or did you mean recommends?)
[05:06] <infinity> YokoZar: Oh, I forgot that things build-dep on it.  That's trickier. :/
[05:07] <YokoZar> infinity: Well recommends would be an improvement yes? (Builds unaffected, upgrade case works)
[05:41] <didrocks> good morning
[05:56] <slangasek> RAOF: eh?  what's python doing with MA: foreign? (It shouldn't be!)
[05:57] <RAOF> slangasek: It isn't - that was before I refreshed my memory.
[05:57] <slangasek> RAOF: ok :)
[05:57] <RAOF> slangasek: Why did you suggest that Laibsch MA: foreign scim?
[05:58] <qH> hello
[05:58] <qH> Since upgrading to Ubuntu 11.10 I am having problems connecting to my wireless network. The connection is made, and after about 30 seconds the connection is lost. This has never happened with any of the previous versions of Ubuntu. IT COMPLETELY LOCKS UP MY ROUTER. The only solution after attempting a connection is to reset the router.
[05:58] <qH> Since upgrading to Ubuntu 11.10 I am having problems connecting to my wireless network
[05:58] <qH> The connection is made, and after about 30 seconds the connection is lost.
[05:59] <qH> This has never happened with any of the previous versions of Ubuntu.
[05:59] <qH> IT COMPLETELY LOCKS UP MY ROUTER. The only solution after attempting a connection is to reset the router.
[05:59] <qH> i need help
[05:59] <qH> my wireless card is wifi link 5100
[06:01] <Laibsch> qH: you're in the wrong channel, try #ubuntu instead, please
[06:01] <slangasek> RAOF: while it's possible I did, I in fact don't remember making such a recommendation for scim, and looking at the reverse-deps now I don't see why I would have either.  Several of the revdeps ship binary modules that are meant to be loaded by scim, so that doesn't really seem like a sensible thing for me to recommend
[06:01] <RAOF> slangasek: That was what I was thinking; at *best* it's a MA: allowed, same as Python.
[06:01] <slangasek> Laibsch: do *you* remember why I said MA: foreign for scim? :)
[06:02]  * Laibsch checks the logs
[06:02] <slangasek> ah, here we are
 scim should almost certainly be multi-arch: foreign, as I don't believe anything outside of the scim package itself should be loading the plugins from /usr/lib/scim-1.0/1.4.0
[06:03] <infinity> Yeah, we were trying to come up with clever ways to make DSOs work with an MA:foreign loader, and the concept broke my brain, so I'm curious why too.
[06:03] <slangasek> but I overlooked the existence of revdeps that ship plugins for it and declare a dependency on it - so it was an oversight at the time
[06:03] <Laibsch> slangasek: (00:38:46) vorlon: I'm 99.97% certain nothing will break by treating the scim binary package as Multi-Arch: foreign and assuming that nothing outside scim itself loads those modules
[06:04] <Laibsch> (00:34:31) vorlon: scim should almost certainly be multi-arch: foreign, as I don't believe anything outside of the scim package itself should be loading the plugins from /usr/lib/scim-1.0/1.4.0
[06:04] <slangasek> YokoZar: eh - "bash: /usr/bin/wine: No such file or directory" is the error you get if the ELF interpreter is missing from the system.
[06:04] <Laibsch> (00:29:54) vorlon: if they're loaded by the scim package itself, then this is conceptually a Multi-Arch: foreign package (only one instance of the package needs to be installed at a time, and it can satisfy dependencies of packages of other architectures because the only interface it provides is via exec() )
[06:04] <slangasek> YokoZar: I think that means they installed libc6-i386, installed libc6:i386, and removed libc6:i386, taking the interpreter with it.
[06:05] <Laibsch> slangasek: did that refresh your memory?
[06:05] <infinity> slangasek: Is that bug still there?
[06:07] <slangasek> infinity: ia32-libs-multiarched - only for the ones that are *actually* Multiarch: same, right, not the ones that were pruned this cycle because I couldn't find anything that would need them?
[06:07] <infinity> slangasek: Yeah, only for MA:same stuff that was removed.
[06:08] <slangasek> infinity: given that an "apt-get install --reinstall libc6-i386" would have also fixed it here, or just, y'know, not removing the multiarch libs that they had installed, I'm pretty indifferent to the idea.  If you want to pick up the pieces if it breaks, though, I have no objections. :)
[06:08] <infinity> slangasek: Though, as YokoZar points out, it can only be Recommended from ia32-libs, because things build-dep on it.  Does apt pull in new Recommends on upgrade by default?
[06:08] <slangasek> infinity: yes, it does pull new recommends by default on upgrade
[06:08] <infinity> slangasek: Oh, I agree that the wine bug appears to just be the loader problem.  I thought that bug was fixed.
[06:08] <slangasek> unless you use 'apt-get upgrade' instead of 'apt-get dist-upgrade' or equivalent.  So, y'know.  Don't do that.
[06:09] <infinity> slangasek: But it's still surprising, to say the least, to have a bunch of libs go missing on upgrade if, say, a 3rd party app in /opt was relying on them.
[06:09] <slangasek> infinity: "fixed" how?  libc6-i386 has to ship the file for biarch; libc6:i386 has to ship it for multiarch (and for the real thing); one package has to replace the other; don't remove that package mmkay
[06:09] <infinity> slangasek: Can't one just divert the other?
[06:10] <infinity> slangasek: Overwriting is meant for upgrades, not co-existing packages. :P
[06:10] <slangasek> infinity: at the cost of an eleventh-hour eglibc upload, and a diverting-shared-libraries-is-pain-and-suffering tango, I guess so?
[06:11] <slangasek> yes, well, when this was written the hope was that they *wouldn't* coexist for very long... and indeed they won't for much longer, ia32-libs is dead in p
[06:11] <infinity> slangasek: It's not that bad.  But yes, something before today would have been nice.  Had I known it was still an issue, I might have spoken up.
[06:11] <infinity> ia32-libs is dead, but is biarch?
[06:11] <infinity> If biarch lives on, this bug does too.
[06:11] <slangasek> yeah, I didn't realize it was causing problems in practice
[06:12] <infinity> And currently, -m32 relies on biarch.  Are there plans to fix that?
[06:16] <slangasek> infinity: as far as missing something wrt DSOs... did you miss Multi-Arch: allowed?
[06:17] <slangasek> Laibsch: so the bug in my reasoning before was "it can satisfy dependencies of packages of other architectures because the only interface it provides is via exec()".  This isn't true, there are also package which treat it as "the thing that can load this module".  So it's logically Multi-Arch: allowed, not Multi-Arch: foreign.
[06:17] <infinity> slangasek: Ahh, yeah, I was operating on the assumption that you had reason to recommend foreign, though, so had some tunnel vision going on. :P
[06:18] <slangasek> -m32> no plans to fix it, just aspirations
[06:19] <Laibsch> slangasek: OK, thank you.  I'll adjust things and make sure the path is adjusted at build-time.  I'll ping you in a few hours to ask for a sync to oneiric.
[06:19] <slangasek> Laibsch: better to ping infinity, I hope to be asleep in a few hours :)
[06:20]  * infinity passes the buck to pitti.
[06:20] <slangasek> WFM
[06:20] <YokoZar> iirc infinity intended to be asleep a few hours AGO ;)
[06:21] <YokoZar> I gotta fly to wineconf tomorrow night so I intend to be up irrationally late testing out the ia32-libs-multiarch idea.
[06:21] <infinity> Sounds like a stellar way to spend an evening.
[06:27] <ubuntu-baltix> Hi all
[06:28] <ubuntu-baltix> AFAIK today is Non Language pack translations freeze (look at https://wiki.ubuntu.com/OneiricReleaseSchedule), how many hours I have to fix ubiquity-slideshow and ubiquity translations?
[06:28] <infinity> ubuntu-baltix: Very few.
[06:29] <ubuntu-baltix> infinity: but how many? Two, three or four?
[06:29] <infinity> ubuntu-baltix: I always forget what timezone we use for the cutoff. :P
[06:29] <infinity> ubuntu-baltix: But assume "a lot less than 24" and just get it done.
[06:30] <TheMuso> 21:00UTC is the cut-off for final freeze.
[06:30] <TheMuso> On Thursday.
[06:30] <infinity> ubuntu-baltix: It's not like we'll say no if you're 2 hours "late".  We will if you're 2 days late.
[06:30] <ubuntu-baltix> infinity: you will do the export from translations.launchpad.net ?
[06:30] <infinity> Nope.  I believe pitti's the man you probably want to talk to about translations.  And if he's not, he'll know who is. :)
[06:31] <ubuntu-baltix> pitti: are you alive?
[06:32] <pitti> unI certainly hope so :)
[06:32] <pitti> s/un/uhm/ :)
[06:32] <infinity> Are you sure that wasn't meant to be ub<tab>?
[06:33] <pitti> ubuntu-baltix: if it can land today, it would be good, but if the changes are small and reviewable, I'd also accept it tomorrow
[06:34] <ubuntu-baltix> pitti: I think I will finish ubiquity-slideshow and ubiquity translations afer 4 or 5 hours, it's ok?
[06:35] <pitti> ubuntu-baltix: sounds great, thanks for working on that
[06:36] <ubuntu-baltix> thanks you for coding free software :)
[07:06]  * cjwatson remembers to vote in the TB election
[07:06] <cjwatson> (mentioning this in case anyone else is similarly scatterbrained)
[07:07] <pitti> getting close, yes :)
[07:07] <pitti> speaking of getting close, does Perky Penguin have a name yet?
[07:08] <pitti> we need to upload lintian, vim, devscripts, and the like
[07:09] <SpamapS> Perfect Piranha you mean?
[07:09] <slangasek> Pastel Protoceratops
[07:10] <SpamapS> Penultimate Pterydactyl
[07:11] <cjwatson> I'd've thought Perky Penguin was a shoe-in given that that name has been held in reserve for about seven years
[07:12] <dholbach> good morning
[07:12] <cjwatson> but sabdfl looked nervous last time I asked about the name for P and backed away to consult a dictionary
[07:12] <infinity> Pastafarian Puffin?
[07:12] <pitti> infinity: if we ever devote a release to you, I think we call it "incurable insomnia"
[07:13] <infinity> Insomniac, surely.
[07:13]  * AlanBell wonders if it will be a more surprising -p name than we expect
[07:13] <SpamapS> no, insomnia is a beast that feeds on all our brains
[07:13] <slangasek> Prehensile Platypus
[07:13]  * RAOF 'd like a Puffin.
[07:13] <RAOF> Puffins are cool.
[07:13] <RAOF> Kinda like bow-ties.
[07:13] <infinity> Puffy Puffin!
[07:14] <slangasek> and on that note, I'll turn in ;)
[07:14] <infinity> For once, people could spell the release name.
[07:14] <slangasek> 'night, folks
[07:16] <Daviey> Perfect Phuckit
[07:17] <nigelb> I like the Pterydactyl
[07:19] <diwic> Planus Pancake
[07:20] <nigelb> pitti: That would devoted to all Ubuntu and Free software developers :)
[07:20] <nigelb> (Incurable insomaniac that is)
[07:20] <pitti> nigelb: but only infinity claims to go to bed at least four times before he finally does :)
[07:20] <pitti> I think I did at most three, and only once
[07:21] <nigelb> pitti: hahaha
[07:21] <SpamapS> Sep 29 03:19:59 mabolo kernel: [124785.393627] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0
[07:21] <SpamapS> Hmm.. thats bad
[07:22] <janimo> Pining PaRROT
[07:22] <Daviey> SpamapS: Hmm, so jamespage saw something similar with arm+ext4, and we put it down to a bad disk.  I'm not sure i'm so confident now.
[07:23] <Daviey> SpamapS: Have you checked SMART or any funky RAID messages that mabolo would likely throw out?
[07:24] <SpamapS> [124785.015731] hpsa 0000:04:00.0: cp ffff880036d00000 has check condition: unknown type: Sense: 0x5, ASC: 0x20, ASCQ: 0x0, Returning result: 0x2, cmd=[85 08 0e 00 00 00 01 00 00 00 00 00 00 40 ec 00]
[07:24] <infinity> Looks like hardware to me.
[07:24] <SpamapS> Daviey: this is mabolo
[07:24] <SpamapS> Daviey: been pushing it pretty hard
[07:25] <infinity> pitti: I resent that!
[07:25] <infinity> pitti: I'll have you know I slept more than 3 hours last night!
[07:25] <infinity> So there.
[07:25] <pitti> *boggle*
[07:26] <infinity> (About 3.5, but still... More than 3!)
[07:26] <pitti> how can you make-do with that? If I get less than 7, I'm totally useless
[07:28] <infinity> pitti: Decades of practice, I guess.  I've never slept much.  Every once in a while, it does me in, and I'll pass out for a weekend.
[07:28] <nigelb> My suspicions that infinity is a bot increases.
[07:28] <infinity> pitti: But it's not like it's by choice.  I've been like this since I was a small child.
[07:28] <beta0x64> caffeine?
[07:29] <infinity> beta0x64: I wasn't on caffeine as a baby, no.  Nor much until I was an adult, really.
[07:29] <infinity> And not much now either, for that matter.
[07:29] <beta0x64> :( I was on caffeine as a baby
[07:30] <infinity> My parents took me to doctors who had all sorts of opinions and ideas until they finally just settled on "whatever, he'll sleep when he's tired and eat when he's hungry".
[07:30] <beta0x64> you stopped eating too?
[07:31] <infinity> When I was a kid, I'd go for days without food.  I've managed to more or less fix that.
[07:31] <infinity> But the sleep thing hasn't changed.
[07:31] <Daviey> jhunt: Good morning!
[07:31] <Daviey> jhunt: Do you have any news on bug 818177?
[07:32] <jhunt> Daviey: Not since I updated it last night :)
[07:32] <Daviey> pah, you english - taking 12 hours off a day.
[08:12] <tkamppeter> I have tried an upgrade to Oneiric and now the installation is totally locked up
[08:16] <tkamppeter> On update of Samba it tells that one of the maintainer scripts exited with an error. When I run "apt-get install -f" I get the same and if I run "dpkg -P samba" i tells I should re-install samba, but this does not work.
[08:16] <tkamppeter> Seems that now only hand-editing the dpkg databse or reformating the system helps.
[08:17] <tkamppeter> The problem leading to this is bug 862129.
[08:22] <tkamppeter> Solved, looked into the terminal log attached to the samba crash report and saw that it needed perl-modules. Installed the already downloaded new perl packages from /var/cache/apt/archive/ and upgrade continues ...
[09:00] <doko> didrocks, compiz ping. is there a new emerald version compatible with compiz 0.9.x? or can it be removed?
[09:00] <didrocks> doko: I guess emerald is unmaintained now, I would go for removing it if it doesn't work with 0.9
[09:03] <doko> didrocks, done
[09:10] <YokoZar> infinity: ok, I have a preliminary package built, uploading to a launchpad PPA to make sure it builds, as this is the first time ia32-libs is "built" on i386
[09:11] <YokoZar> infinity: (even though the only binary is the dummy package I just made) -- speaking of which, am I going to run into packages-arch-specific trouble?
[09:31] <doko> pitti: still planning to address avidemux?
[09:32] <doko> apw, still planning to address uns?
[09:32] <pitti> doko: yes, just kept pushing it out as there has always been some RC bug or release stuff to attend to
[09:42] <YokoZar> pitti: any comment on the ia32-libs-multiarch discussion above (I believe infinity/slangasek passed the buck to you due to sleep issues) ;)
[09:45] <doko> soren, still planning to address user-mode-linux?
[09:54] <pitti> YokoZar: didn't read, reading backscroll
[09:54] <apw> doko, i spent some time on it, but i don't think we will get the current version in there working in short order.  there is a more up to date version which we might sub in, but it a big jump and i don't have any obvious way to test it
[09:56] <infinity> YokoZar / pitti: I passed something to pitti, but it wasn't the above.  I intend to review/test/mangle it when I wake up.  Unless Martin really wants to put in the effort. :P
[09:56] <pitti> I'm still trying to find out what this is all about
[09:57] <infinity> pitti: Don't worry about it, I'll get to it in the morning. :)
[09:57] <pitti> but if it's more complicated than a two-line explanation, it's very probably out of scope for oneiric :)
[09:57]  * pitti takes infinity's word and stops worrying
[09:57] <YokoZar> pitti: executive summary is a dummy i386 multiarch:foreign package depending on all the libs removed from ia32-libs
[09:57] <YokoZar> *removed = removed because they are multiarch
[10:04] <debfx> pitti: could you remove kipi-plugins from the archive, bug #857689
[10:09] <pitti> debfx: done
[10:10] <doko> apw, ok, I'll just remove the binary packages, and keep the source for now
[10:10] <debfx> thanks!
[10:10] <apw> doko, seems like a plan, we'll revisit it for P and see what we can do there
[10:10] <apw> doko, got the bug number to hand, seem to have lost it
[10:11] <doko> apw, 756096. if it's definitely for P only, then I'll remove the source too
[10:11] <apw> doko, as its something vendors are likely to ask for i suspect it'd be good to keep the option to reinject it there
[10:12] <doko> ok, binaries only
[10:12] <apw> would we be able to bump the version agressivly at this stage ?
[10:12] <doko> apw, why not, there are no rdepends
[10:12] <apw> ok thanks
[10:51] <tseliot> cjwatson: I'm trying to blacklist all nvidia cards so that grub doesn't set an fb (which breaks things in recovery mode) but I can't seem to do it. Here's the file that I'm using (10DE means Nvidia). I also tried using lowercase (10de). Any ideas as to how I can debug this? http://pastebin.ubuntu.com/699033/ù
[10:52] <tseliot> cjwatson: http://pastebin.ubuntu.com/699033/
[10:56] <apw> tseliot, maybe needing a * at the front ?  isn't there a vga: or something on the frnt
[10:58] <tseliot> apw: maybe something like this (which I can see in modinfo)? pci:v000010DEd*
[10:58] <apw> worth a try
[10:58] <apw> i just have the feeling there is something at the front
[10:59] <apw> i'd test with a * there and see what happens
[11:00] <tseliot> right, let's try that
[11:05] <tseliot> apw: I tried with both a ".*" and with an "*" but it doesn't seem to work
[11:06] <tseliot> apw: I can see other blacklisted devices though in the file, such as v15add0710.*
[11:06] <cjwatson> tseliot: it should definitely be .* not *
[11:06] <cjwatson> it's a regex
[11:06] <tseliot> right
[11:06] <apw> v000010ded*sv*sd*bc03sc*i*
[11:07] <apw> so all the *'s need to be .* then yes
[11:07] <cjwatson> the hexits should be lower-case
[11:08] <tseliot> ok
[11:08] <cjwatson> then try 'hwmatch ${prefix}/gfxblacklist.txt 3' by hand to see what it says
[11:10] <tseliot> cjwatson: is hwmatch somewhere in grub?
[11:10] <apw> grub command line
[11:10] <cjwatson> I've uploaded a new grub-gfxpayload-lists that says that explicitly
[11:10] <cjwatson> yes, what apw said
[11:14] <tseliot> ok
[11:17] <tseliot> cjwatson: nothing seems to happen when I enter that command
[11:17] <apw> $? and $match tell you things
[11:18] <apw> echo those
[11:19] <tseliot> apw: yes, I've already tried $? and it's 0
[11:19] <tseliot> apw: and so is $match
[11:20] <cjwatson> that means "command succeeded but no match"
[11:21] <tseliot> I should probably try some greedy matching
[11:21]  * tseliot -> lunch
[11:22] <cjwatson> the output of grub's lspci command might not hurt
[11:35] <tseliot> apw, cjwatson: 02:00.0 10de:0ca3 [0300] VGA Controller
[11:40] <cjwatson> tseliot: what's the i at the end meant to match?
[11:41] <cjwatson> the format is vVENDORdDEVICEsvSUBVENDORsdSUBDEVICEbcBASECLASSscSUBCLASS; SUBCLASS can't contain i
[11:41] <cjwatson> it's matched against v%04xd%04xsv%04xsd%04xbc%02xsc%02x
[11:41] <cjwatson> ah, so that also wants to be v10de... not v000010de...
[11:42] <cjwatson> so I think you want: v10ded.*sv.*sd.*bc03sc.*
[11:46] <tseliot> cjwatson: I suspected that the first 4 zero were the problem. Let me try..
[11:49] <tseliot> apw, cjwatson: it works now. Thanks for your help
[11:50] <cjwatson> excellent
[11:58] <YokoZar> infinity: I'm off to bed but my computer is still uploading ia32-libs-multiarch to this PPA: https://launchpad.net/~scottritchie/+archive/build-tests
[12:03] <penguin42> I don't suppose it includes freeglut does it?  I noticed freeglut doesn't like installing 32 and 64bit versions together
[12:09] <YokoZar> penguin42: freeglut was removed from ia32-libs cause only wine was using it and wine no longer uses it...did you have another app that needed it?
[12:09] <penguin42> YokoZar: fold.it
[12:09] <penguin42> YokoZar: It's not packaged
[12:10] <penguin42> (see http://fold.it )
[12:10] <YokoZar> ahh, that game :D
[12:10] <penguin42> YokoZar: Yeh, I thought I'd give it a go since they'd been nice enough to provide a linux version
[12:10] <YokoZar> penguin42: does it work on natty (with natty freeglut)?
[12:11] <penguin42> YokoZar: I don't have any natty boxes any more
[12:12] <penguin42> YokoZar: I reported it as bug 859038
[12:14] <YokoZar> penguin42: Yup, freeglut isn't multiarch ready.  I suppose adding it back to ia32-libs would be the correct thing to do...earlier in the cycle...
[12:14] <penguin42> YokoZar: Well if you remover a library there will always be some madman who wanted it!
[12:15] <YokoZar> penguin42: so you'd think, except that wasn't the case with most the other libraries removed :D
[12:15] <YokoZar> (To be fair, I was usually the madman demanding stuff in for Wine purposes)
[12:21] <hrw> does someone has pbuilder hook which installs all built packages in chroot (to check installability)?
[12:25] <ScottK> hrw: I don't, but it sounds like it ought to be easy enough to do.
[12:26]  * ogra_ bets persia would have such a hook 
[12:26] <ogra_> but i doubt he is online
[12:34]  * Daviey just went on a blueprint status binge, i'm expecting to see a decent drop in the burndown chart when it next updates \o/
[12:37] <hallyn> Daviey: yeah, your comment on 828785 makes me laugh and cry at the same time :)
[12:41] <Daviey> bug 828785
[12:41] <Daviey> hallyn: Yeah, it's been like a zombie process that will not die...
[12:42] <mvo> pitti: a question about bug #834403 and the way apport marked dupes. the issue itself is pretty straightforward and I have a fix, but I wonder if the StackTrace that is used for the duplication finding is always only the top (which is always _XError, _XReply) or will it look further? the bug is a bit concerning, it has 76 me-toos already
[12:42] <Daviey> There seemed to have been much interaction between you and Boris, which made me wonder if a plan was reached.
[12:43] <pitti> mvo: it only uses the top 5 items
[12:43] <pitti> mvo: s/items/function names/
[12:43] <pitti> mvo: that's bad in these cases indeed; there are similar cases with glibc's and glib's assert() stuff, but apport has some code to unwind the stack to the first "interesting" one
[12:44] <Laney> sladen: Err, am I doing something wrong? I just updated ttf-ubuntu-font-family to 0.80~rc-0ubuntu1+arabic and now my terminal looks like http://orangesquash.org.uk/~laney/tasty.png (full disclosure: on a sid system)
[12:44] <pitti> mvo: I suppose we need to add something similar for XError(), same problem in bug 848808
[12:44] <mvo> pitti: is there a way to get to the data of the duplicates? I would like to investigate the data myself
[12:44] <pitti> mvo: I. e. the duplicate finder looks at StacktraceTop
[12:44]  * ScottK filed a bug about this yesterday.
[12:45] <pitti> mvo: I'm afraid there isn't; the core dumps are removed after the retracer looks at them
[12:45] <pitti> ScottK: ah, was just about to do that -- which one?
[12:45] <ScottK> It wasn't Xerror exactly.  Let me find it.
[12:46] <pitti> so, it unwound the g_logv() stuff, but not until XError
[12:46] <ScottK> pitti: Bug 861645 is the one I found.
[12:47] <ScottK> It's a similar question of not digging far enough into the traceback.
[12:47] <mvo> pitti: hm, thanks. would it be possible to get a quick fix in for this so that the duplication detection is disabled if there is  a XError ? I would love to know if its all the libcanberra issue that I diagnosed or if there is more to it
[12:47] <hrw> ScottK, ogra: will write one ;)
[12:47] <ScottK> Nice.
[12:47] <pitti> ScottK: actually, it's not a problem of depth there
[12:48] <pitti> ScottK: just that it's two different KeyError bugs in the same function
[12:48] <pitti> so it's a different "class" of failure
[12:48] <ScottK> I see.
[12:48] <yofel> hrw: works for me: http://paste.kde.org/128749 (as ~/.pbuilder-hooks/B11installbuilt)
[12:48] <pitti> mvo: I don't think we should disable it; it should just unwind the stack enough, just looking at how much exactly
[12:48] <ScottK> I took it as depth in needing to look at the actual key and not just the error class.
[12:49] <yofel> could be improved I guess
[12:49] <pitti> mvo: yes, I'll work on this right now
[12:49] <mvo> pitti: thanks a lot!
[12:52] <hrw> yofel: thx
[13:24] <sladen> Laney: try choosing 'Ubuntu Mono' instead of 'Ubuntu' as your terminal font
[13:24] <Laney> sladen: I just noticed I had another update pending, 1s
[13:25] <Laney> it was on Ubuntu mono btw; but now looks fine again :-)
[13:25] <sladen> Laney: probably it was on 'UbuntuBeta Monospaced'
[13:26] <Laney> ah, possibly
[13:26] <sladen> Laney: although sometime in the next 8 hours we'll probably change the default monospace font anyway
[13:27] <Laney> have you got a bug about the unicode arrow characters being spaced wrongly? (x→y)
[13:29] <sladen> Laney: http://launchpad.net/ubuntu-font-family/+filebug?field.title=Mono:+please+add+left/right+arrows
[13:29] <nigelb> hahahaha
[13:29] <nigelb> I didn't understand what happened there for a full minute
[13:31] <Laney> Dear JAnet, please resume working. No love, Iain.
[13:48] <ahasenack> I guys, I believe landscape-client can be moved from -proposed to -updates? It's been a week if my calculations are correct, and all bugs have been verified: https://bugs.launchpad.net/bugs/813477
[13:48] <ahasenack> s/I/Hi/
[13:59] <pitti> mvo: ok, have a patch
[14:00] <mvo> pitti: \o/
[14:00] <pitti> on https://launchpadlibrarian.net/79769114/Stacktrace.txt the topmost one is now #11 meta_display_get_current_time_roundtrip
[14:00] <pitti> mvo: on https://launchpadlibrarian.net/78125841/Stacktrace.txt it is #8 XGetWindowProperty
[14:01] <pitti> on https://launchpadlibrarian.net/81397067/sync-stacktrace.txt it is #12 XCreatePixmap
[14:01] <pitti> mvo: that should cut off just enough _X* common goo to be useful again
[14:02] <mvo> pitti: nice
[14:08] <kirkland> didrocks: ping
[14:08] <didrocks> kirkland: pong
[14:08] <kirkland> didrocks: can you help me triage https://bugs.launchpad.net/ubuntu/+source/unity/+bug/861726 ?
[14:08] <seb128> kirkland, you want to talk to kamstrup rather than didrocks I guess ;-)
[14:08] <kirkland> seb128: thanks
[14:09] <didrocks> seb128: kamstrup for panel?
[14:09] <didrocks> or is it the dash
[14:09] <kirkland> seb128: i don't see a kamstrup online?
[14:09] <didrocks> (launchpad is timeouting)
[14:09] <didrocks> ah dash
[14:09] <didrocks> yeah, kamstrup :)
[14:09] <seb128> kirkland, he timeouted just a bit before
[14:09] <kirkland> seb128: k
[14:09] <seb128> kirkland, I guess he will be back
[14:16] <pitti> mvo: ok, committed and rolled out into the retracer bots
[14:16] <pitti> bring'em on!
[14:17] <pitti> mvo: (no real need to upload that to oneiric)
[15:20] <alexbligh> If I have a package with a trivial rules file, what is the proper way to change the PRIORITY of an init script installed from debian/packagename.init
[15:42] <mbiebl> RAOF: I talked to davidz about your patch
[15:42] <mbiebl> I'd like to see this fixed in PK proper instead of using the at_console approach
[15:45] <YokoZar> Can I put libqtwebkit4 back in ia32-libs?  It's multiarched but depends on libgstreamer which isn't (but is in ia32-libs)
[15:48] <pitti> doko: avidemux FTBFS is a pain; we already removed the binaries, so fixing this is not really release critical, right?
[15:50] <intgr> pitti: Hi. If you're not too busy: I just upgraded from PostgreSQL 9.0 to 9.1.1 on Ubuntu 10.04 and now every time I run psql I get "DEB_HOST_MULTIARCH is not a supported variable name at /usr/bin/dpkg-architecture"
[15:50] <intgr> Using your PPA
[15:51] <intgr> I couldn't find anything relevant on Google
[15:51] <pitti> intgr: oh, I know
[15:51] <pitti> intgr: is that actually breaking psql, or just an extra warning message?
[15:51] <pitti> intgr: can you please file a bug against postgresql-common about it and assign to me? sorry, need to run now
[15:52] <pitti> good night everyone
[15:52] <intgr> Just a message. Which is kinda annoying because I run it every minute from cron :)
[15:52] <intgr> Ok
[15:54] <doko> pitti, sure, didn't notice that the binaries were removed
[15:54] <Sweetshark> it there any easy way to check which packages are on the install CD
[15:54] <Sweetshark> ?
[15:55] <janimo> Sweetshark, loooking at the manifest files near the ISOs on the site?
[15:55] <alexbligh> OK, let me ask again more precisely. dh_installinit --update-rcd-params='defaults 98 02' fails, as does any combination of --, quotes no quotes etc. I try, with the arcane error "Duplicate specification "O=s" for option "O"
[15:55] <alexbligh> " what does that mean?
[15:56] <janimo> Sweetshark, ex http://cdimage.ubuntu.com/daily-live/20110929/oneiric-desktop-amd64.manifest
[15:59] <Sweetshark> janimo: thanks.
[16:06] <Daviey> jhunt: Can i be an ass, and ask how bug 818177 is looking?
[16:06] <Daviey> (causing me great concern)
[16:06] <janimo> Sweetshark, can LibO be crossbuilt now for linux targets (ex:ARM)?
[16:09] <Sweetshark> janimo: there is general work done on crosscompiling, but mostly to get minGW builds on windows and some Android/iOS work. Even if we could finish a crosscompile like that, I wouldnt trust the result yet.
[16:10] <Sweetshark> (a armel crosscompile that is)
[16:11] <janimo> Sweetshark, ok thanks.
[16:23] <pitti> Sweetshark: apt-cache show <pkgname>, look at Tasks:
[16:23] <pitti> Sweetshark: that will also show packages which are only on ubuntustudio or xubuntu
[16:27] <intgr> The problem cannot be reported: This is not a genuine Ubuntu package
[16:28] <intgr> Does anyone know how to use this Launchpad thing to report bugs?
[16:29] <intgr> Oops, wrong channel, sorry
[16:34] <pitti> intgr: ah, because it's a backport
[16:34] <pitti> intgr: https://launchpad.net/ubuntu/+source/postgresql-common/+filebug
[16:35] <intgr> Thanks :)
[16:53] <YokoZar> infinity: slangasek: ok, after a whole night of poking at it I think I have a workable version of the ia32-libs-multiarch.  Uploading for review now, should finish in an hour or so (better than the two versions that were in my PPAs)
[16:57] <infinity> YokoZar: If the upload will take more than a few seconds, there's something wrong..
[17:00] <jtaylor> doko: did xdotool fail to build on all architectures now? bug 823704
[17:00] <jtaylor> I'd rather not have it removed, I use it daily ._.
[17:00] <slangasek> infinity: uploading ia32-libs in a few seconds?
[17:01] <doko> jtaylor, see my pending upload
[17:01] <infinity> slangasek: Oh, right, ia32-libs control change.  I didn't infer that from his comment. :)
[17:01] <jtaylor> doko: where can I see that?
[17:02] <slangasek> infinity: :)  I in fact assumed ia32-libs-multiarch would also be built from the same source package, since -multiarch should normally be updated in tandem
[17:03] <infinity> slangasek: Stop making sense, I haven't had enough coffee.
[17:03] <jtaylor> hm indeed it fails for me on amd64 now too ... but its working fine, probably better to just disable the testsuite as it was before the last upload anyway
[17:05] <jtaylor> doko: please don't remove it, I'll have a look this weekend, and if that is not successful I'll disable the testsuite, the package is useful to remove it just because of one unreproducable testcase
[17:07] <Sweetshark> pitti: thanks
[17:10] <slangasek> YokoZar: it might behoove you to post a diff somewhere, so we can review and give feedback a bit more nimbly?
[17:10] <slangasek> rather than having an hour+ round trip between each iteration :)
[17:15] <cr3> cyphermox: hola senor, we have a checkbox candidate that we would appreciate merged before final freeze. see bug #862579, the branch is about to be attached
[17:16] <cr3> cyphermox: could you handle that and, if not, could you recommend someone perhaps?
[17:16] <ScottK> slangasek: Noting the "dpkg predependency against tar >= 1.23, objections?" discussion on debian-devel, assuming we merge that change in for "P" it will complicate Lucid -> "P" upgrades.
[17:16] <ScottK> FYI in case you think it ought to be discussed.
[17:16] <cyphermox> cr3: I was going to point you to the current patch pilot because I'm a little busy, but I don't think robert_ancell is available to do it now :)
[17:17] <cyphermox> cr3: so, sure, I'll look at it now :)
[17:20] <cr3> cyphermox: thanks man! here's the merge proposal: https://code.launchpad.net/~roadmr/ubuntu/oneiric/checkbox/0.12.8/+merge/77574
[17:22] <soren> doko: Yes.
[17:28] <cyphermox> cr3: I'm concerned by the string change for the intro prompt, the translations don't seem to be matching this or translating the added warning.
[17:30] <cyphermox> cr3: indeed, the extra string appended to the intro_prompt for warning isn't being translated.
[17:32] <cyphermox> cr3: and so I feel checkbox should have an UI Freeze bug; see https://wiki.ubuntu.com/UserInterfaceFreeze
[18:14] <mdeslaur> mvo: fyi I just got hit with bug 848676 on an up-to-date machine
[18:14] <mdeslaur> mvo: although it's supposedly fixed already
[18:18] <Laney> did something change in gconf to make these crashes happen?
[18:18] <Keybuk> W: Failed to fetch http://ppa.launchpad.net/pidgin-developers/ppa/ubuntu/dists/lucid/main/binary-amd64/Packages.gz  403  Forbidden [IP: ::ffff:172.16.255.22 3129]
[18:18] <Keybuk> ... wait, what?!
[18:18] <Laney> banshee has something similar too
[18:20] <mvo> mdeslaur: indeed it is … what happend, did you get a apport window? did the app itself crash?
[18:20] <mvo> mdeslaur: I have a look at the code
[18:21] <mvo> mdeslaur: same backtrace, line   File "/usr/share/software-center/softwarecenter/ui/gtk3/models/pendingstore.py", line 75, in _on_lowlevel_transactions_changed
[18:21] <mdeslaur> mvo: I opened software center for the first time, typed "skype" in the search box, clicked on skype, clicked on "enable partner repo", and got an apport window
[18:21] <mvo> ?
[18:21] <mdeslaur> mvo: uh, let me check...LP just told me it was a dupe
[18:22] <mdeslaur> mvo: nope, completely different backtrace
[18:22] <mvo> mdeslaur: could you pastebin it please?
[18:23] <Daviey> jdstrand: If you are happy with bug #862567, can you Confirm bug 860492 please?
[18:24] <mdeslaur> mvo: paste.ubuntu.com/699251
[18:26] <mvo> mdeslaur: thanks, fixed in trunk now
[18:27] <mdeslaur> mvo: wow, that didn't take long :)
[18:27] <mvo> mdeslaur: no, the same class of error that got fixed before, I just overlooked one call
[18:28] <mdeslaur> mvo: ah, I see...cool. thanks!
[18:28] <mvo> thank you for the backtrace, that made it realy easy
[18:28] <mdeslaur> mvo: you're welcome
[18:31] <cr3> cyphermox: we already have an accepted UI freeze exception bug which has been approved, see bug #855328. do we need another bug?
[18:31] <cr3> roadmr: hi there, I just asked cyphermox if we need another bug
[18:31] <roadmr> cr3, cyphermox : re!
[18:32] <cyphermox> sorry, no, that's good
[18:32] <cyphermox> sorry, I just didn't see it
[18:32] <roadmr> cyphermox: thanks!
[18:32] <cr3> cyphermox: nor did I, all good :)
[18:48] <jdstrand> Daviey: done
[18:50] <roadmr> cyphermox: oops, I didn't set ubuntu-sponsors as reviewer for the checkbox merge request :-/ is there a problem if I do it now?
[18:51] <cyphermox> well, no need to since I'm already reviewing it, but next time it would be best if you did
[18:51] <cyphermox> also, I think it's no longer an issue with the sponsoring queue
[18:52] <roadmr> cyphermox: ok, I'll leave it as it is then, best not to frob the bug :) thanks
[18:53] <cyphermox> roadmr: it shows up here: http://reqorts.qa.ubuntu.com/reports/sponsoring/ which is what you want :)
[18:57] <Daviey> jdstrand: thanks!
[19:25] <slangasek> ScottK: commented on the dpkg thread, thanks
[19:25] <ScottK> Great.
[19:41] <ogra_> Laney, hmm, in your last mono upload, did you include all the ubuntu arm hacks/patches ? i dont see them in the changelog (and apparently banshee stopped working)
[22:32] <Laney> ogra_: I thought they were supposed to be included in Debian / upstream or something
[22:32] <Laney> directhex might know
[22:32] <directhex> snuh?
[22:45] <hallyn> is anyone here very familiar with grantpt and ptsname in glibc?
[23:05] <TheMuso> @pilot in
[23:13] <robert_ancell> @pilot out