=== yofel_ is now known as yofel [00:42] 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] 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] Launchpad bug 851947 in ia32-libs (Ubuntu Oneiric) "/usr/lib32/libGL.so.1 prevents Doom 3 from starting" [High,Confirmed] https://launchpad.net/bugs/851947 [00:49] 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] RAOF: heya [00:50] mbiebl: Yo. [00:50] got my colord bug report? [00:51] would be cool if you can update it, I'm currently working on g-c-m 3.2.0 [00:51] I can send you a debdiff for colord 0.1.12 if that helps [00:52] It's ready and waiting in collab-maint git; I just haven't done the sponsor dance yet. [00:52] ah, great. [00:52] * RAOF needs to go for DM [00:52] let me take a look [00:52] I'll sponsor it for you, if you don't mind [00:53] I don't mind at all! [00:54] ok, will take a closer look tomorrow [00:55] * mbiebl → bed [00:57] RAOF: a few quick comments: [00:58] Shoot. [00:59] the if ! getent group scanner >/dev/null; then [00:59] checks are unnecessary [00:59] adduser already does the right thing [00:59] and adduser --system already creates the corresponding group [00:59] so no need to split that [01:00] Since when does adduser exit 0 if a group exists? [01:00] I've always done "getent blah || adduser", because it choked if you didn't. [01:01] I don't know the version number [01:01] http://wiki.debian.org/AccountHandlingInMaintainerScripts [01:03] RAOF: forgot to add adduser --system *--group colord* [01:03] will create the corresponding group [01:03] :) [01:04] I'm happy to make those changes if you like. [01:05] regarding the dependencies of libcolord-dev [01:05] does pkg-config still choke on missing requires.private deps? [01:05] I thought that was fixed and only required for static linking [01:07] It does, or at least did. [01:09] The gnome-control-centre / g-s-d plugins failed to build without those extra dependencies.\ [01:10] 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] slangasek: Ah, ok. Good. [01:12] 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] and at_console is something we actually want to get rid of [01:12] not use instead of PK [01:13] That's the existing PK behaviour; they're all yes. [01:13] auth_admin_keep [01:14] is for org.freedesktop.color-manager.install-system-wide [01:14] *facepalm* [01:14] * RAOF missed that. [01:14] 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] argh, polkit 0.103 has dropped libpolkit-gtk [01:15] so I can't upload it to Debian just yet [01:16] I don't see that in the git log? [01:17] Are we talking about the same thing? [01:18] meh, was looking at pk-gnome [01:18] In fact, I see exactly one non-version-bump commit between 0.102 to master :) [01:18] definitely bed time for me [01:18] can I catch you on irc tomorrow? [01:19] Yes. [01:19] I'll be here from ~7:30 UTC+10 [01:20] ok, cu then [01:47] 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] #multiarch is quiet so I hope somebody can enlighten me here? [01:50] I would like to create an updated lilypond deb. How do I do so? [01:51] Is there a tutorial somewhere? [01:51] clahey: "pull-lp-source lilypond && cd lilypond-* && echo "make changes here && pdebuild" [01:52] that's the really short version. a more elaborate version depends on what you already know ;-) [01:52] in essence, get the source, hack away, build, test, repeat [01:54] pdebuild? [01:54] 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] Is there a maintainer for lilypond? [01:56] 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] 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] 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] Laibsch: Oh, super fun. [01:58] I want to replace /*/ in that patch with /$DEB_HOST_MULTIARCH/ as in http://paste.debian.net/132936 [01:58] Laibsch: This is an arch: any package, right? [01:58] but http://paste.debian.net/132934 would introduce a dependency on dpkg-dev [01:58] 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] I don't maintain the other packages [01:59] jwilk also suggested to deal with the problem at build time [01:59] but then I was the one to object ;-) [02:00] 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] 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] Well, I think yours is a pretty special case; most plugin systems will hardcode the directory at build time. [02:01] which was what we did so far [02:01] There may be other cases like it, but I wouldn't expect too many. [02:01] but I think multi-arch breaks that [02:02] No? [02:03] I think this issue will arise for any binary that has a) plugins and is b) MA:foreign [02:03] plugins as separate packages [02:03] MA: foreign means that it can *satisfy* dependencies, right? [02:03] MA:foreign means that the build host's arch is irrelevant [02:04] My understanding is that foreign means that an AMD64 host can install an i686 version of the scim binary package [02:04] => build host and user host have no relation at all [02:04] Well, an AMD64 host can *always* install an i686 version of scim. [02:04] take another arch [02:05] it's the only two I can come up with now ;-) [02:05] An AMD64 host can *always* install an armel version of scim. [02:05] Update My understanding is that foreign means that a sparc host can install an i686 version of the scim binary package [02:05] What MA:foreign means (IIUC) is that an i386 scim package can satisfy *dependencies* for an amd64 package. [02:05] yes [02:06] See what python's doing with this; they're in essentially the same boat. [02:06] enlighten me, please [02:07] am I completely wrong in assuming that build host arch doesn't necessarily equal user host arch in case of MA:foreign? [02:08] s/assuming/deducing/ [02:11] 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] 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] 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] the amd64 host would need the amd64 binary package, right [02:15] Laibsch: https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships might be what you're after. [02:25] slangasek: RAOF: uploading an ia32-libs that reverts the libGL links right now, which should break mesa [02:36] 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] No, multiarch is runtime. [02:37] As in: install $FOREIGN_ARCH packages on $NATIVE_ARCH, and have them work at runtime. [02:37] (Compile time is a nice side-benefit) [02:37] 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] OK [02:37] Speaking of multiarch: https://bugs.launchpad.net/ubuntu/+source/wine1.3/+bug/852101 [02:38] Ubuntu bug 852101 in wine1.3 (Ubuntu Oneiric) "32-bit applications do not start on 64" [High,Confirmed] [02:38] apparently not having any multiarch libs causes problems now [02:38] 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] 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] Laibsch: I guess I'm not entirely sure why you'd set MA: foreign for scim. [02:46] because the master himself AKA slangasek told me so ;-) [02:47] 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] 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] 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] infinity: *And* that it'll satisfy cross-architecture dependencies, right? [02:50] Laibsch: (And same can only be used to satisfy deps from the same arch, foreign can stisfy deps from another arch) [02:50] RAOF: Yeah, I was getting there. :) [02:50] RAOF: The names relate more to the dependency issues, but most people understand the other concept better, so I start there. :P [02:51] And MA: foreign doesn't actually allow you to install on a foreign arch; you can do that anyway. [02:52] 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] Well, fair point. [02:57] YokoZar: Sounds like wine's messed up its deps, then. :/ [02:59] infinity: I'd be lying if I claimed that this is easy for me to understand. Let me try to summarize. [02:59] scim binary package is MA:foreign and thus only one version of the package can be installed at any one time. [02:59] but it can be a foreign or the native arch. [03:00] if foreign arch, will the binaries run correctly or not? [03:00] 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] 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] Laibsch: I can run several architectures on my laptop emulated, and two natively. [03:03] 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] 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] 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] 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] Man, this is heavy stuff, gets my head spinning. (But it did for jwilk as well, so I don't feel bad ;-)) [03:12] Laibsch: Yeah, if you nominate a foreign arch in your dpkg configs, it's up to you to make sure it works. [03:12] 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] I see [03:13] I didn't know that an arch has to be specifically turned on to become installable [03:13] Aye. [03:13] adconrad@cthulhu:~$ cat /etc/dpkg/dpkg.cfg.d/multiarch [03:13] foreign-architecture i386 [03:14] ^-- For instance. [03:14] That one is set up on install or upgrade to oneiric on amd64 machines. [03:15] 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] infinity: can you tell me more about the laptop you mentioned earlier and the arches it supports? [03:16] Laibsch: Assuming the plugins are DSOs, that sort of mixing and matching isn't going to work. [03:18] 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] Laibsch: But I run ARM binaries on it with no issues, for instance. [03:19] s/virtualisation/emulation/ [03:19] It's late, I can't brain anymore. [03:45] infinity: what is preventing the user from attempting to install a mix and match even in case of DSOs? [03:46] Sane dependencies of some sort, I suppose. [03:47] Not sure how most DSO maintainers deal with it so far, TBH. [03:47] 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] 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] Or actually, no. [03:49] Or, yes. ;) [03:49] 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] Yeah. Since the dep only goes one way (DSO->app), it gets messy. :/ [03:50] Do the DSOs depend on scim, or on libscim? [03:50] 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] Depending on libscim would solve it, since the library should be MA: same when multiarched. [03:51] Laibsch: And, a random one (scim-hangul) seems to depend on the library. [03:52] 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] Or. I guess you could still have both libscims installed, an i386 scim, and a few amd64 DSOs, eh? :P [03:53] Maybe a perfectly valid reason to not multiarch the package at all. :P [03:53] * infinity ponders this more. [03:53] this is way over my head :-P [03:54] I am not maintainer of the plugins, so I can never be sure on what they depend on [03:54] and I thought I remembered that most of them depend on scim directly [03:54] scim-bridge-agent is one of them (although a bad example) [03:55] Well, it also depends on the library too. [03:55] scim-modules-socket depends on the lib [03:55] 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] this seems to be such corner case, one which may never materialize [03:56] and which may even be impossible [03:56] 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] I only want to understand a bit more before consciously taking the plunge [03:56] if things go wrong I can always point fingers at jwilk [03:56] and you :-p [03:57] 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] yes [03:57] I think assuming build host for whatever scim package is installed determines lookup path for the modules should be a valid approach [03:58] thank you for your time and insight, infinity [03:59] Yeah. Now you have me trying to think of a foolproof way around this, though. [03:59] When I should be relaxing and/or sleeping. :) [03:59] hehe [03:59] So, thanks for that. :P [04:00] I'm glad you can't touch me [04:00] and over here it would not be a concern, bright daylight! [04:04] 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] 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] YokoZar: A packaged solution is always better than an installer hack. [04:05] YokoZar: Since the latter only works for people who use the one upgrade method. [04:05] 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] 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] YokoZar: Either way, I think ia32-libs just randomly dropping libraries on the floor is non-obvious. [04:05] 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] YokoZar: Do you have a concise list of libraries dropped from ia32-libs sine MA began? [04:06] s/sine/since/ [04:06] 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] infinity: they should all be enumerated in the ia32-libs changelog [04:07] 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] Nothing too important though [04:07] 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] YokoZar: I assume the ultimate solution here is to drop wine from amd64 entirely, right? [04:09] 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] YokoZar: (In fact, why haven't we?) [04:09] YokoZar: Yeah, same trick we pull with flash-* [04:09] YokoZar: amd64 package depending on something that only lives in i386. [04:09] YokoZar: Which is also how I assume you'd do a smooth transition to "oops, wine doesn't exist on amd64 anymore". [04:10] infinity: 64-bit Wine complicates this [04:10] Oh, derp. 64-bit Windows. Right. [04:10] Somehow, that didn't even cross my mind. [04:10] 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] infinity: But more importantly, not all of Wine's deps are multiarch enabled [04:11] Check. [04:11] So next cycle :P [04:11] Early next cycle, I hope. [04:11] Yeah me too [04:11] I'm not okay with wine being even remotely broken and/or a joke in an LTS. [04:12] People downplay its important a lore more than I'd like. [04:12] (And this is from someone who runs no win32 software) [04:12] s/important/importance/ [04:12] 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] While you're fighting for the honor, I'll upload. [04:12] <3 [04:12] Haha. Just one? [04:12] Perhaps we should have a lottery... [04:13] Sure, but which archive admin gets to lp-remove-package it? :-) [04:13] I'll have a loop running on ftpmaster. [04:13] Poor cocoplum. [04:13] Check for (conditions); remove ia32-libs [04:15] Good morning [04:15] [ "$ANYTHING_GOOD_ON_TV" = "false" ] && CONDITIONS=perfect [04:15] pitti: Evening. [04:16] StevenK: Please rename lp-remove-package to business-time, thanks. [04:16] infinity: File a bug. [04:17] So I can laugh at you, and close it. [04:17] Those don't end well. [04:17] And that's crazy talk, my LP bugs never get closed. [04:17] CLOSED: OPINION [04:17] They stay open for about 6 years, bounce between medium and critical, get lots of comments, and get reassigned about 12 times. [04:22] infinity: Lies! [04:22] infinity: You have *30* closed Launchpad bugs [04:23] Sorry, 28. 30 is the id for Fix Released [04:25] 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] (or did you mean recommends?) [05:06] YokoZar: Oh, I forgot that things build-dep on it. That's trickier. :/ [05:07] infinity: Well recommends would be an improvement yes? (Builds unaffected, upgrade case works) [05:41] good morning [05:56] RAOF: eh? what's python doing with MA: foreign? (It shouldn't be!) [05:57] slangasek: It isn't - that was before I refreshed my memory. [05:57] RAOF: ok :) [05:57] slangasek: Why did you suggest that Laibsch MA: foreign scim? [05:58] hello [05:58] 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] Since upgrading to Ubuntu 11.10 I am having problems connecting to my wireless network [05:58] The connection is made, and after about 30 seconds the connection is lost. [05:59] This has never happened with any of the previous versions of Ubuntu. [05:59] IT COMPLETELY LOCKS UP MY ROUTER. The only solution after attempting a connection is to reset the router. [05:59] i need help [05:59] my wireless card is wifi link 5100 [06:01] qH: you're in the wrong channel, try #ubuntu instead, please [06:01] 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] slangasek: That was what I was thinking; at *best* it's a MA: allowed, same as Python. [06:01] Laibsch: do *you* remember why I said MA: foreign for scim? :) [06:02] * Laibsch checks the logs [06:02] ah, here we are [06:02] 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] 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] 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] 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] (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] 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] (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] YokoZar: I think that means they installed libc6-i386, installed libc6:i386, and removed libc6:i386, taking the interpreter with it. [06:05] slangasek: did that refresh your memory? [06:05] slangasek: Is that bug still there? [06:07] 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] slangasek: Yeah, only for MA:same stuff that was removed. [06:08] 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] 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] infinity: yes, it does pull new recommends by default on upgrade [06:08] slangasek: Oh, I agree that the wine bug appears to just be the loader problem. I thought that bug was fixed. [06:08] unless you use 'apt-get upgrade' instead of 'apt-get dist-upgrade' or equivalent. So, y'know. Don't do that. [06:09] 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] 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] slangasek: Can't one just divert the other? [06:10] slangasek: Overwriting is meant for upgrades, not co-existing packages. :P [06:10] 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] 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] 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] ia32-libs is dead, but is biarch? [06:11] If biarch lives on, this bug does too. [06:11] yeah, I didn't realize it was causing problems in practice [06:12] And currently, -m32 relies on biarch. Are there plans to fix that? [06:16] infinity: as far as missing something wrt DSOs... did you miss Multi-Arch: allowed? [06:17] 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] 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] -m32> no plans to fix it, just aspirations [06:19] 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] Laibsch: better to ping infinity, I hope to be asleep in a few hours :) [06:20] * infinity passes the buck to pitti. [06:20] WFM [06:20] iirc infinity intended to be asleep a few hours AGO ;) [06:21] I gotta fly to wineconf tomorrow night so I intend to be up irrationally late testing out the ia32-libs-multiarch idea. [06:21] Sounds like a stellar way to spend an evening. [06:27] Hi all [06:28] 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] ubuntu-baltix: Very few. [06:29] infinity: but how many? Two, three or four? [06:29] ubuntu-baltix: I always forget what timezone we use for the cutoff. :P [06:29] ubuntu-baltix: But assume "a lot less than 24" and just get it done. [06:30] 21:00UTC is the cut-off for final freeze. [06:30] On Thursday. [06:30] 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] infinity: you will do the export from translations.launchpad.net ? [06:30] 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] pitti: are you alive? [06:32] unI certainly hope so :) [06:32] s/un/uhm/ :) [06:32] Are you sure that wasn't meant to be ub? [06:33] 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] pitti: I think I will finish ubiquity-slideshow and ubiquity translations afer 4 or 5 hours, it's ok? [06:35] ubuntu-baltix: sounds great, thanks for working on that [06:36] thanks you for coding free software :) [07:06] * cjwatson remembers to vote in the TB election [07:06] (mentioning this in case anyone else is similarly scatterbrained) [07:07] getting close, yes :) [07:07] speaking of getting close, does Perky Penguin have a name yet? [07:08] we need to upload lintian, vim, devscripts, and the like [07:09] Perfect Piranha you mean? [07:09] Pastel Protoceratops [07:10] Penultimate Pterydactyl [07:11] 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] good morning [07:12] but sabdfl looked nervous last time I asked about the name for P and backed away to consult a dictionary [07:12] Pastafarian Puffin? [07:12] infinity: if we ever devote a release to you, I think we call it "incurable insomnia" [07:13] Insomniac, surely. [07:13] * AlanBell wonders if it will be a more surprising -p name than we expect [07:13] no, insomnia is a beast that feeds on all our brains [07:13] Prehensile Platypus [07:13] * RAOF 'd like a Puffin. [07:13] Puffins are cool. [07:13] Kinda like bow-ties. [07:13] Puffy Puffin! [07:14] and on that note, I'll turn in ;) [07:14] For once, people could spell the release name. [07:14] 'night, folks [07:16] Perfect Phuckit [07:17] I like the Pterydactyl [07:19] Planus Pancake [07:20] pitti: That would devoted to all Ubuntu and Free software developers :) [07:20] (Incurable insomaniac that is) [07:20] nigelb: but only infinity claims to go to bed at least four times before he finally does :) [07:20] I think I did at most three, and only once [07:21] pitti: hahaha [07:21] Sep 29 03:19:59 mabolo kernel: [124785.393627] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,commit=0 [07:21] Hmm.. thats bad [07:22] Pining PaRROT [07:22] 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] SpamapS: Have you checked SMART or any funky RAID messages that mabolo would likely throw out? [07:24] [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] Looks like hardware to me. [07:24] Daviey: this is mabolo [07:24] Daviey: been pushing it pretty hard [07:25] pitti: I resent that! [07:25] pitti: I'll have you know I slept more than 3 hours last night! [07:25] So there. [07:25] *boggle* [07:26] (About 3.5, but still... More than 3!) [07:26] how can you make-do with that? If I get less than 7, I'm totally useless [07:28] 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] My suspicions that infinity is a bot increases. [07:28] pitti: But it's not like it's by choice. I've been like this since I was a small child. [07:28] caffeine? [07:29] beta0x64: I wasn't on caffeine as a baby, no. Nor much until I was an adult, really. [07:29] And not much now either, for that matter. [07:29] :( I was on caffeine as a baby [07:30] 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] you stopped eating too? [07:31] When I was a kid, I'd go for days without food. I've managed to more or less fix that. [07:31] But the sleep thing hasn't changed. [07:31] jhunt: Good morning! [07:31] jhunt: Do you have any news on bug 818177? [07:32] Launchpad bug 818177 in udev (Ubuntu Oneiric) "boot failures caused by udev race" [High,Confirmed] https://launchpad.net/bugs/818177 [07:32] Daviey: Not since I updated it last night :) [07:32] pah, you english - taking 12 hours off a day. === smb` is now known as smb [08:12] I have tried an upgrade to Oneiric and now the installation is totally locked up [08:16] 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] Seems that now only hand-editing the dpkg databse or reformating the system helps. [08:17] The problem leading to this is bug 862129. [08:17] Launchpad bug 862129 in samba (Ubuntu) "package samba 2:3.5.8~dfsg-1ubuntu2.3 failed to install/upgrade: subprocess new post-removal script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/862129 [08:22]