=== ryu2 is now known as ryu [00:06] nvm my query above, I misread. [00:34] cjwatson, thanks. I subscribed you to bug 524020 where I tried to describe the problem. The big thing is that I don't want to face this again in lucid. [00:34] Launchpad bug 524020 in Ubuntu Lucid "karmic uec builds fail to publish due to 2 installed -ec2 kernels" [High,New] https://launchpad.net/bugs/524020 === virtuald_ is now known as virtuald [01:02] just wanted to say that using yelp to popup help files in html format is extremely useful :) [01:02] (aka gnome-help) [01:08] bah, I leave for work and stuff explodes. [01:08] sorry folks, fixing now. [01:27] Does anyone have a less ugly way to accomplish `LIB=$i; [ -h "$LIB" ] && LIB=$(ls -l $i | cut -d\ -f11); [ -z "$LIB" ] && LIB=$(ls -l $i | cut -d\ -f12); dpkg -S "$LIB" | cut -d: -f1` without awk? [01:28] * persia is using it to try to determine the right package that provides a shared library given a string containing a path to the .so file [01:29] persia: what could 'i' be [01:29] persia: any .so under lib? [01:30] jcole: Yep, assuming libfoo-dev is installed. [01:31] Unfortunately, cut doesn't seem to have a "show me the last element" function, and I'm not sure of a good way to show symlink info other than ls. [01:32] persia: readlink -f ? [01:32] I knew there was something better :) [01:33] dpkg -S $(readlink -f $i) | cut -d: -f1 works perfectly. Thanks! [01:33] persia: also if you delimit by directory slashes ('/') you could use basename to extract the "last" column :) [01:33] persia: no problem [01:38] hmm why does onboard pull in the x headers? [01:38] lifeless: I have no clue as to whether debcommit uses --author [01:39] ah i see the bug [01:39] 524148 [01:42] bug 524148 [01:43] Launchpad bug 524148 in onboard "onboard has overactive dependencies" [Medium,Triaged] https://launchpad.net/bugs/524148 [02:02] ccheney: Because it's *hard* to use CDLL sanely :) [02:43] slangasek: do you get nervous on every pam upload? [03:26] sebner, persia: is there a bug report for this pulseaudio regression? === kenvandine_ is now known as kenvandine [03:50] tlp: which one? The alsa-lib one is already fixed in 1.0.22-0ubuntu4 [03:51] tlp: the "unable to change volume controls" one is known; I'll be uploading the fix after testing it locally. [03:56] crimsun: I did a dist-upgrade this morning from an earlier set of Lucid packages and my sound broke completely, but the pulseaudio process is running [03:56] I checked alsamixer and nothing seems to be muted [03:56] by broke I mean there is no output, but otherwise everything seems in order [03:58] I need to reboot here, but I'll check out syslog shortly [04:04] crimsun, did something happen to libpulse-dev? i had a build build against it successfully two days ago, and yesterday it appears to have not? [04:04] the configure test for pulse seems to have failed the next day [04:04] no code changes on my end [04:07] seems to have broken from 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu5 to 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu6, but there is now an ubuntu8, so if I queue another rebuild, should things be fine on ubuntu8? [04:09] good grief that's a nasty looking version number [04:10] yeah i have no idea what that really is [04:10] looks like at some point we said "screw it, I'm doing changelog entries in the version string" ;-) [04:10] haha [04:11] i should click bug links; https://bugs.edge.launchpad.net/ubuntu/+source/pulseaudio/+bug/523716 [04:11] that would appear to be the cause of problems [04:11] Ubuntu bug 523716 in pulseaudio "pulseaudio version defined as UNKNOWN, which breaks everything with build-dep on libpulse-dev" [High,Fix released] [04:12] hola buenas [04:12] desde argentina, necesito ayuda [04:12] alguien habla castellano? [04:12] glad it's not just me who has trouble parsing that [04:13] hay alguien aca? [04:14] pero, pero [04:14] LaserJock: upstream hasn't released from the master branch, and their wishes are for us to use another branch (stable-queue). That version string is slightly modified from git-annotate output; essentially it's "32 changesets have been committed since this last tag (0.9.21), and the hash can be uniquely identified by 8478" [04:14] un monton de gente conectada y nadie contesta? [04:14] julio: #ubuntu-es? [04:14] estan todos durmiendo [04:14] ok [04:15] #ubuntu-es [04:15] crimsun: this is something about DVCS I've noticed now, it is much harder to version snapshot packages nicely [04:17] julio: #ubuntu-ar [04:17] julio: http://ubuntu-ar.org/argentina/irc [04:18] julio: Lo siento, no hablo español. este es el mejor que puedo hacer [04:19] * LaserJock crosses fingers that Google didn't just say something dirty ;-) [04:21] Feb 18 21:16:18 maya pulseaudio[16207]: module.c: Failed to load module "module-esound-protocol-unix" (argument: ""): initialization failed. [04:21] I wonder if that has something to do with it [04:25] gracias [04:26] crimsun: can you give me any leads as to what might have changed to cause this problem? [04:27] LaserJock: Haha [04:28] bah, something did mute ALSA. [04:28] I didn't catch it the first time. [04:28] disregard. Someone said earlier what I reported was a known problem, so I assumed there was a regression. [04:29] I don't understand the relationship between PulseAudio and ALSA well enough to know why that happens, but it happens constantly. [04:30] but I've gotta go launch alsamixer or something to even notice something is muted [04:33] tlp: ok, I'll repeat. There was a change that broke pulseaudio. alsa-plugins was compiled against this broken pulseaudio. I fixed pulseaudio and alsa-plugins, then realized that alsa-lib was missing a configure variable. That was fixed twice. Now the "can't (un)mute/adjust volume" issue is caused by certain alsa-mixer/paths files not being installed but still being referenced. I'm building and testing the fix to push upstr [04:34] Perhaps it was the former. I don't have any trouble with volume controls in "Sound Preferences" [04:35] I just know from past experience that silent output, a fair percentage of the time, means something got muted at the ALSA level. So I always check that first. [04:36] alsa itself is fine now; it's the mixer paths that are affecting PA [04:44] okay. thanks for the clarification === foxbuntu` is now known as foxbuntu [05:13] deb-substvars has successfully confused me. debian/substvars contains "cdll:Depends=libx11-6, libxi6", and debian/control contains "Depends: ${cdll:Depends}". Do I need to do something else to make this just work? Could anyone recommend an example package that does this right? [05:22] persia: That should be right [05:23] That's what all the documentation says. Apparently, CDBS adds a special -T which caught me. [05:23] persia: An example package I can think of is fbreader, but probably Jaunty === ubott2 is now known as ubottu [05:23] * persia is hoping this works this time [05:24] Thanks. If this doesn't work, I'll look there. That was lpia-magic? [05:24] Yeah, that was lpia magic that changed Depends with substvars magic [05:24] Too much magic ... [05:25] Indeed. Now there is no special smoke, and we can all rejoice :) [05:27] * cody-somerville rejoices. [05:38] Good morning [05:38] kees: thanks [05:42] to summarise: sound problems from yesterday all fixed up. Patches pushed upstream where applicable. Sorry for the delay (real life, work, yadda). [05:49] crimsun: Surely you're not really using yada! [05:50] oops, slid that additional 'd' in there [06:01] pitti, re bug 523649, that code snippet that it crashed on has been there a while. has the behavior of 'assert' changed in python? from what i gather, it's behavior is changes if __debug__ is True, but that's not manually modifiable. so perhaps that was caused by https://lists.ubuntu.com/archives/lucid-changes/2010-February/005739.html [06:01] Launchpad bug 523649 in ubiquity "ubiquity crashed with RuntimeError in progress_loop()" [Undecided,New] https://launchpad.net/bugs/523649 [06:02] which makes me thing that assertion isn't correct in the first place the way it's written [06:03] hi superm1 [06:03] superm1: I don't think assert changed recently [06:04] http://docs.python.org/reference/simple_stmts.html#the-assert-statement . "The current code generator emits no code for an assert statement when optimization is requested at compile time" is what put me on that thought process [06:05] and hi pitti :) [06:09] superm1: do you know whether one of the reported crashes is just a followup of the other one? [06:10] I never saw two crashes at once so far [06:10] pitti, they look like they are caused by one-another to me yes [06:12] the important one is the one that crashed in install.py with the assertion error [06:12] that runtime error will go away when the assertion error is fixed [06:13] superm1: ok, please feel free to invalidate the other one then === dendro-afk is now known as dendrobates === thekorn_ is now known as thekorn [07:54] bryceh: oh, CD builds failed because -nouveau is uninstallable (it's still in universe) [07:57] * pitti promotes and closes MIR [08:00] pitti, danke [08:00] bryceh: so the lbm metapackage is sorted out now? [08:01] pitti, I believe so. [08:02] pitti, I haven't verified that yet though [08:02] linux-backports-modules-nouveau-lucid-generic | 2.6.32.13.14 | lucid | amd64, i386 [08:02] \o/ [08:02] Source: linux-meta [08:02] Depends: linux-backports-modules-nouveau-2.6.32-13-generic [08:02] * bryceh nods [08:02] looks fine [08:02] yeah I pulled the source and checked the changelog and so on and it all looked kosher [08:02] bryceh: want to have the pleasure of closing two work items? :-) [08:02] on it [08:03] add nouveau lbm metapackage as dependency to xserver-xorg-video-nouveau: TODO [08:03] that sounds easy now [08:03] great, then this should be done [08:03] well done! [08:03] * pitti yays for KMS on nvidia [08:03] it was a good team effort [08:04] thank god for RAOF and Sarvatt [08:07] pitti, did you see that we now have apport collecting bugs on X freezes now too? [08:07] bryceh: yes, I saw the WI and the upload [08:07] \o/ [08:07] bryceh: craving for more bug reports? :-) [08:07] heh, heck no [08:07] seriously, I hope this will be a huge help in tracking those down [08:08] right now we can't do much more than just shrugging, I guess [08:08] s/right/until/ [08:08] actually I think it will help because before people would file bugs about freezes but it took a lot of effort to walk the user through collecting this info [08:10] pitti, hmm it looks like lbm is already listed as a depends for -nouveau? [08:10] Depends: ${shlibs:Depends}, [08:10] ${misc:Depends}, [08:10] ${xserver:Depends}, [08:10] linux-backports-modules-nouveau-2.6.32-12-generic | linux-backports-modules-nouveau-2.6.32-12-generic-pae | linux-backports-modules-nouveau-2.6.32-12-server [08:11] do we need anything beyond that? [08:11] bryceh: no, only an (obsolete) ABI version, not the metapackage [08:11] oh right [08:13] so it's enough to just Depends on linux-backports-modules-nouveau-lucid-generic ? [08:14] bryceh: I don't see a metapackage for -i386 or -server [08:14] so from my POV yes [08:14] lifeless: generally only the ones when upstream is rewriting code :) [08:14] bryceh: oh, incidentally this is quite urgent; lbm-n is uninstallable [08:14] bryceh: due to the obsolete abi [08:15] bryceh: if you could change that now, I can trigger a new CD build later today, so that we finally have buildable CDs again (also for testing) [08:15] doing it now [08:15] bryceh: cheers [08:15] uploaded [08:21] good morning [08:23] pitti, 3 WIs closed [08:23] \o/ [08:24] http://people.canonical.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-3.html#bryceharrington [08:24] down to 1 then, go, Bryce, go! [08:24] Close out all -nv bug reports filed before transition as obsolete due to move [08:24] now, that sounds like a fun one :) [08:24] yep [08:24] "Status: invalid\n nv, we do not love you any more, kthxbye" [08:27] we still need it for the really old chips though [08:28] tjaalton: yes, but we still don't love it, I take it :) [08:28] pitti: got that right :) [08:29] ok, I think the Xsession.d/ scripts are really streamlined now [08:29] sweet [08:29] tjaalton: I hope I didn't screw up any git with my xorg upload? [08:30] pitti, I fixed it [08:30] is the UNR the choice if we want to install on ARM devices? [08:30] bryceh: my ubuntu6 followup as well? [08:30] pitti: yeah it's ok [08:30] bryceh: thanks [08:31] that one isn't there yet [08:31] I think I'm down to exactly one external program now ("cat"), thanks to dash not having $(< file) [08:31] pitti, oh no I just did the first one [08:31] sorry for the blunder of the first one [08:31] bryceh: probably add -nv back to video-all as well? [08:31] I uploaded that, went to bed, and thought "oh argh" [08:32] tjaalton, yep [08:32] tjaalton, pushed [08:32] pitti, how are we on disk space? [08:33] bryceh: I don't know; we didn't have buildable CDs for several days [08:33] I chopped some langpacks [08:33] but each day there was something else causing uninstallability [08:33] james_w, somehow , in my greatness, i got http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/lucid/cloud-init/lucid/annotate/head%3A/.bzr-builddeb/default.conf commited with "native = True" [08:33] and that is wreaking havok [08:33] bryceh: once your -nouveau fix is pushed, I'll trigger a rebuild [08:34] i branched from that, and worked by way to lp:~cloud-init-dev/cloud-init/lucid [08:34] which i believe is in a "fixed" state. [08:36] pitti, subject: [ubuntu/lucid] xserver-xorg-video-nouveau [08:36] 1:0.0.15+git20100128+2630a15-0ubuntu2 (Accepted) [08:37] bryceh: right, it's already built; now just waiting for the next publisher to finish (in 1:20 hours) [08:40] anyone seen this on the buildds, this is on arm, /usr/bin/dpkg-deb: line 53: 15639 Segmentation fault /usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS [08:41] that message implies dpkg-deb is a script, which its not on my local installs ... [08:45] lool: on netbook seed, I see the Germinate workaround about webfav and abrower. I would have thought that we have to list firefox before webfav so that it doesn't download abrowser (and furthemore, if I just try to install abrowser, it tries to install last firefox) [08:51] bryceh: fun that the freeze hook works now -- there's a typo in teh udev rule: "ACTION=="change" [08:51] bryceh: (first " before ACTION) [08:51] oops [08:51] how'd that get there? [09:03] hi [09:04] i'm posting here because it's more relevant than #ubuntu [09:04] where is the source for efl interface in netbook remix? [09:08] I was just going to answer, but if you disappear after 60 seconds.. [09:09] pitti, yours to slow, really [09:09] *you're [09:14] pitti, cjwatson, any suggestions how to debug this: [09:14] /usr/bin/dpkg-deb: line 53: 15639 Segmentation fault /usr/bin/pkgmaintainermangler $ORIGINAL_ARGUMENTS [09:14] dh_builddeb: dpkg-deb --build debian/sata-modules-2.6.32-14-versatile-di ../sata-modules-2.6.32-14-versatile-di_2.6.32-14.19_armel.udeb returned exit code 139 [09:15] seems to only occur on buildds [09:17] apw, buildd hiccup, just give back [09:19] why the heck did it have to do it on the build which takes 6 hours ... ie. arm [09:19] * primes2h waves tseliot [09:19] apw, because it only does that with very long building packages ... [09:20] apw, aks the kde guys how much fun they have with our armel buildds :) [09:20] *ask even [09:20] tseliot: Did you read the last comment? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/499445 [09:20] Ubuntu bug 499445 in linux "Conflicts between Broadcom 4312 wireless driver and internal Bluetooth on HP Mini 110" [High,Invalid] [09:21] tseliot: I think a SRU could be worthwhile [09:22] tseliot: That version has just been uploaded in Lucid.. [09:22] tseliot: as I see some days ago [09:23] tseliot: What do you think? [09:26] apw: urgh, no immediate idea I'm afraid :/ [09:26] apw: maintainermangler is just pure shell [09:26] yay [09:27] apw, itzs very likely a buildd kernel memory management issue ... and we cant replace the kernels on these machines easily [09:33] primes2h: yes, I did that upload. We're considering idea of an SRU [09:35] tseliot: That's really nice. So can I nominate it for Karmic? [09:36] primes2h: it's something we'll deal with if we decide to file an SRU [09:37] tseliot: Ok, so I'll patiently wait for it ;-) [09:37] Thank you. [09:37] np [10:11] Hi. I'm the founder of Jalbum (http://jalbum.net). We've just adopted our web photo album software for Ubuntu and packaged it as a .deb package [10:11] Can anyone here give me guidance on how to get Jalbum into "Ubuntu Software Center" [10:12] We're true freeware, no crippleware, but Jalbum is only 50% open source - generic code under LGPL but still some core code not opened. [10:18] Anyone with input on this? [10:19] davidekholm: I think that falls to #ubuntu-motu (: [10:20] Ok. I'll post there and see what repsonse I get. [10:33] superm1: would you happen to know an easy workaround for the installer failure? [10:39] superm1: oops -- it just occured to me that it didn't even ask me for partitioning [10:41] Is it intentional that onboard pulls in a whole stack of x development packages? [10:43] persia: You touched it last :) Any idea? [10:48] soren: He last touched it to remove those dependencies. [10:50] Oh. Heh :) [10:50] * soren kicks his mirror around a bit [11:48] hi all, I have a problem with building a qt app on karmic. https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/524354 do I need to upgrade my qt? [11:48] Ubuntu bug 524354 in qt4-x11 "problem building qgis from source cannot call constructor ‘QVariant::QVariant’ directly" [Undecided,New] [12:00] bryceh: yay, I just got an apport reported freeze bug! [12:01] pitti: thanks for remotely teaching me about the type builtin today :-) [12:01] hey jdub, how are you? [12:01] pitti: lovely - you? [12:01] I'm great, thanks! [12:02] still struggling with boot speed, though [12:02] lucid is rocking along nicely [12:02] yeah, it is, if only plymouth would work :) [12:02] heh [12:02] been having issues with that on my netbook, but not my desktop [12:03] bryceh: except that the GPU dump says "no such file or directory" :( perhaps it doesn't get along so well with collecting infos after a reboot [12:09] pitti - how do you get apport to report a freeze? [12:09] X freezes constantly on my laptop now [12:09] chrisccoulson: it "just happens" [12:09] xserver-xorg-video-intel.2010-02-19_12:55:36.379175.crash [12:09] pitti - it's magic? ;) [12:10] chrisccoulson: with today's xorg === MacSlow is now known as MacSlow|lunch [12:20] pitti: sweet... did you not have intel_reg_dumper installed maybe? [12:21] indeed I don't [12:21] xserver-xorg-video-intel-dbg, isn't it? [12:22] ah, no, intel-gpu-tools [12:22] * pitti -> lunch [12:23] bryceh: thanks for sponsoring a debdiff I posted a few days back :) [12:23] nigelb, my pleasure [12:23] :) [13:05] hi gents, we got a question on the ubuntu-server mailing list about nfs v4 for lucid+1. has anyone here given that any thought before? https://lists.ubuntu.com/archives/ubuntu-server/2010-February/003808.html === MacSlow|lunch is now known as MacSlow [13:58] Hm, looks like console-setup no longer sets up keyboard on recent ISOs [14:06] bug 524439 [14:06] Launchpad bug 524439 in console-setup "20100219 Server ISO fails to set up console keyboard correctly" [Undecided,New] https://launchpad.net/bugs/524439 [14:26] apw, tjaalton: do you happen to know about the status of bug 507148? [14:26] Launchpad bug 507148 in xserver-xorg-video-ati "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [High,Confirmed] https://launchpad.net/bugs/507148 === dendrobates is now known as dendro-afk [14:27] this sounds like it could require a painful backport of the .33 ati driver? (AFAIUI, upstream does not recommend us to use .32, but .33, which will be supported longer) [14:27] pitti, i think that one is the one where KMS doesn't work for that board, and it also crashes a bit [14:28] if so: then i think we had a few patches for it which might mean nomodeset might work for it [14:28] but ... as you say upstream is saying "2.6.32 is crap use .33 we don't care about .32' [14:28] its not clear how that gives us any more support really as they won't care about .33 in about 2 weeks either [14:28] apw: hm, I thought they said "we'll support that longer", perhaps they also release something with it? [14:29] yeah but htat might just mean, "cause we care about the previous release until the next one" for all i actually know [14:29] ok [14:30] pitti, but yes we are getting pressure for ati to be .33 indeed they are actually saying 'drm' at .32 is crap [14:30] and that we should be backporting .33 drm en-toto for long term use [14:30] http://pastebin.com/m58534978 <-- is udev supposed to fork this many times? [14:30] that sounds like fun [14:30] i have an action to see how hard that is, then its up to bryceh to chose i suspect [14:30] hyperair: erm, no [14:32] pitti: okay. this is weird >_> [14:32] * hyperair sighs. such a problematic laptop [14:32] from pulseaudio leaking memory to udev forkbombing to undetected usb devices... [14:32] i can't possibly think of any machine that is less ubuntu-friendly than this [14:33] apw, pitti: f12 already has the .33 drm on top of .32, so it'll end up in rhel6 as well [14:33] and at least bits from .34 [14:33] what a mess :/ [14:33] why? [14:33] upstream drm seems to have no idea what 'release' means [14:34] its not meant to mean 'drop the tip ... NOW' [14:34] tjaalton, how do you expect to be able to support a lash up like that for 5 yeas [14:34] .32 drm is buggy all over the place [14:35] 3y for the desktop [14:35] you'd think they would produce some fixes for it though wouldn't you [14:35] just pull in what rhel6 has [14:35] I guess going with .33 is entirely out of question? [14:35] pitti, the whole of .33? [14:35] pitti: no, that's what will likely happen [14:35] just the drm of course [14:35] apw: yes [14:36] drm is self-contained [14:36] (for having the same kernel version as other distros, and thus sharing patches, etc.) [14:36] it would put us out of sync with long term support release [14:36] pretty much completely separate from the rest of the kernel [14:36] tjaalton: oh, it's relatively independent of the other kernel bits? [14:36] pitti: right [14:36] the other distros seem to be going .32 + .33 drm [14:37] if it's sanely possible to pull the drm .33 bits, this would certainly be better than taking all of .33 [14:37] we also need the nouveau abi bump that'll happen for .34 (and was reverted from the libdrm 2.4.18 I just uploaded) [14:37] * pitti remembers a recent LKML post about Linus not being happy about so many recent regressions [14:37] pitti, yeah ... i am lookin at it [14:37] apw: May the source be with you! [14:37] the nouveau people are even worse [14:38] http://cvs.fedoraproject.org/viewvc/rpms/kernel/F-12/drm-upgrayedd.patch?view=log [14:38] well, nouveau hasn't even had a release yet [14:39] but it should happen after .33 I think [14:39] its in .33? [14:39] yes [14:39] so when .33 releases it will be released [14:39] that's why lbm has it no? :) [14:39] well I meant the ddx [14:39] there has been no tagged releases [14:39] so far [14:43] so there will be no userspace support for .33 nouveau ? [14:48] apw: we have it now, but we need to backport fixes from >= .34 in the future, so having the new abi in lucid is beneficial [14:49] what a damn mess [14:49] it's still better than status quo [14:56] dpeends if you have to try and maintain the kernel that results from the fusion [15:06] I'm confused by the locale names I see in Lucid. So, gdm sets my $LANG to da_DK.utf8. It's been da_DK.UTF-8 since almost forever, but now it's changed. /usr/lib/locale/da_DK.utf8 does exist, but "locale-gen $LANG" no longer works, since locale-gen still expects da_DK.UTF-8. [15:07] I'm not sure who or what to blame. [15:09] Good morning people of Ubuntu [15:12] pitti: Yay for a default keyboard shortcut for launching a term. [15:12] BenC: Hey dude. [15:12] ion: :) [15:17] bah, why does rhythmbox try to index my whole harddisk everytime I start it [15:18] ok, rather ~, but that's still bad enough [15:19] Do you have ~ set as the media library path? [15:23] guys une doesn't show the install option in favourites [15:25] apw: linux-backports-modules-nouveau-lucid-generic is mistyped with ‘noveau’. linux-backports-modules-wireless-lucid-generic-pae depends on linux-backports-modules-2.6.32-13-generic-pae instead of linux-backports-modules-wireless-2.6.32-13-generic-pae. [15:30] ion: I don't have a media library path set === mathiaz_ is now known as mathiaz [15:40] ion, ta [15:50] I wonder if it'd make sense to have the build-essential seed not include recommends. [15:51] It would free at least a couple of MB on the ISOs. [15:51] (manpages-dev alone eats 3 MB) [15:53] brb [15:53] Hi [15:55] git-buildpackage in lucid currently does not handle dpkg v3 which I guess is a pretty serious thing. The version in testing and unstable does. I think there is a minimal patch available that could be backported to the lucid package but I wonder if it isn't better to still try a merge instead. Opinions? === dmart is now known as Guest48348 [15:55] * Laibsch is afraid we may end up backporting just about everything [16:02] pitti, i think it's a small fix, the pointer that partitioning wasn't being asked is the real problem [16:08] \//k [16:14] soren: We talked about `locale-gen ${foo}.utf8` earlier, and the consensus seemed to be that either vm-builder needed to do something like language-selector to get a complete list of locales (and match against it), or just check for well-formedness, as 1) the complete list of locales is not available locally without extra work, and 2) the set of locales differs by release. [16:16] persia: It does seem rather odd that "locale-gen $LANG" doesn't work. [16:16] regardless [16:16] Why should it work? There's no guarantee that the relevant langpack is installed in the chroot. [16:16] Not in my chroot. [16:16] On my own system. [16:17] OK. There's no guarantee that the relevant langpack is installed on your system :) [16:17] $ locale-gen $LANG || echo this is weird [16:17] this is weird [16:17] Well.. it is. [16:18] locale-gen expects the charset to be "UTF-8", not "utf8". [16:18] soren: You may want to review http://irclogs.ubuntu.com/2010/02/18/#ubuntu-devel.txt from 21:25 for more in-depth discussion. [16:18] well, there is no guarantee that $LANG is sometinh locale-gen can use [16:18] I didn't say I wanted a guarantee. [16:18] i'm just saying it's odd. [16:19] Can't we just all please accept that my life would be easier if everyone else did something differently? [16:19] kthxbai [16:19] Accepting that is easy. Now make sure it's everyone's goal :) [16:20] soren: I can't make a lot of sense from this either, FWIW; locales have been .UTF-8 forever, and in lucid libc6 seems to have switched to .utf8 [16:20] like "almost, but not quite" [16:20] pitti: Exactly. [16:20] I haven't investigated it at all, though [16:20] i know cjwatson has looked at it [16:20] soren: however, locale-gen $LANG does work [16:21] It doesn't. [16:21] it doesnt [16:21] it's just that LANG=de_DE.utf8, not .UTF-8 any more [16:21] It silently fails. [16:21] Check the exit code. [16:21] oh [16:21] ok, that's a bug [16:21] ...and try it with UTF-8. [16:21] See the difference. [16:21] * persia suspects a bug in locale-gen [16:21] GENERATE=`grep -E "^${1}( |[._@][^[:space:]]* )UTF-8" /usr/share/i18n/SUPPORTED` [16:22] that was me, in ancient times === Guest48348 is now known as dmart_ [16:23] Oh! [16:24] /usr/share/i18n/SUPPORTED also needs to be updated then, I figure [16:24] but I'm still not sure what the "canonical" form is [16:24] we don't do any migration on upgrade right now [16:25] and I don't even know whether .utf8 was even intentional [16:25] We can argue all day long that /[uU][tT][fF]-?8/ are all valid ways to write it, but we've always done it one particular way. It would be nice to at least understand why it changed. [16:25] ack [16:26] * pitti will read the IRC link from persia after meeting [16:27] ..and for another week, I'm still getting paid to understand this operating system, and not just accept when it changes underneath me. :) === beuno is now known as beuno-lunch [16:28] soren: you know that by saying that you've effectively deferred the investigation for a week, right? :) [16:28] mdeslaur: I do now :( [16:28] Darn it. === yofel_ is now known as yofel [16:40] what needs to be done to promote a binary package to main? (puppet-common is currently in universe - while puppet is in main) [16:41] puppet-common is already in the component-mismatch list since puppet and puppetmaster (both in main) depend on it [16:41] mathiaz: just poke an archive admin [16:41] * pitti looks [16:42] mathiaz: done [16:42] pitti: \o/ - thank you! [16:49]