[00:00] wgrant: well, we don't have the source file, so we don't know. it'll probabbly be a few kb less [00:03] er, what exactly is the plan of action here? You want to re-encode using a source format that's not available? [00:03] slangasek: well, we're wondering if it's recorded anywhere where the file came from. [00:04] the copyright file states it came from http://librivox.org/ [00:04] ScottK: unlikely that the regression window really is the latest upload. at least if its a knetworkmanager specific issue [00:05] ScottK: read: no dbus api changes in the last upload [00:05] slangasek: ah, we got it, it's on archive.org [00:05] ScottK: do you use a "hybrid" setup, e.g. one connection managed by ifup/ifdown and the wireless with NM? [02:26] mdz, I've sorted out why the OCD doesn't display - it's a bug in gnome-power-manager [02:26] hmm, no mdz [02:28] cjwatson: so mdz's bug is a combination of two bugs - one is a thinkpad t61 kernel bug, that it's not propagating numlock key changes up properly (verified this with whot upstream), the other bug is local to gnome-power-manager where it's not bothering to grab keys with modifiers (it's grabbing with modmap=0 instead of modmap=AnyModifier) === LucidFox_ is now known as LucidFox [02:44] slangasek: is there a reason why /var/lib/samba is created in the samba package rather than the samba-common package? [02:44] slangasek: it seems that libpam_smbpass segfaults if /var/lib/samba doesn't exists - see bug 260687 [02:44] Launchpad bug 260687 in samba "Purging samba breaks login (pam_smbpass.so segfaults)" [High,Confirmed] https://launchpad.net/bugs/260687 === mathiaz_ is now known as mathiaz [04:36] mathiaz: it's a bug that was overlooked until recently; feel free to fix it [04:36] * StevenK uploads most of the remaining libbluetooth2 transistion [04:37] superm1: ^ [04:40] TheMuso: "812KB" - yeah, we don't have that to spare, please solve this another way for intrepid [04:44] StevenK, how much is left on that transition [04:48] NCommander: Um. Let me answer that after these process and the publisher finishes, roughly sixty minutes [04:52] i sliced the end of my finger with a serated bread knife, oops :( [04:52] that'll teach me not to stick my fingers where i can't see what is there [04:52] ScottK, I'm attacking openexr [04:52] No promises though, this is an ugly test failure [04:53] there was a knife stuck between boxes stacked in my garage, tried to pick up box and ouch [04:53] calc: You okay? [04:53] StevenK: yea it wasn't deep so i just cleaned it well, makes it a little harder to type without using that finger [04:54] i'm starting to get the hang of it, heh :) [04:54] ouch [04:55] i thought i had cut myself on the cardboard until i looked under the box, lol === ZhengZhi is now known as Zane [05:45] lamont, ping? [05:48] You know it's nearly midnight, right? [05:52] StevenK, not really [05:52] StevenK, time is relative afterall [05:52] * StevenK teaches NCommander about "time zones" [05:53] as I said, time is relative ;-) [05:53] And there is only one true timezone and UTC is its name [05:57] NCommander: some astronomers may disagree with you. [05:57] *on earth [05:57] On Mars, UMT rules, and sols define the days ;-) [05:57] ScottK, I did some initial debugging on openexr; the main issue seems to be a race issue in glibc (it appears to me that some of the pthread() functions aren't working appropriately). I'm running the test suite on glibc as we speak. If you need this package uploaded, and you don't care about it supporting threads (due to the borked glibc), I can give you a patch to prevent it from calling make check on HPPA === tkamppeter_ is now known as tkamppeter [07:14] NCommander, superm1: The last two libbluetooth2 transistion packages are libpam-blue and ussp-push [07:14] NCommander: If you prepare an upload to Intrepid proper, I'll sponsor it. [07:14] * NCommander does that [07:15] NCommander: Just libpam-blue, since you fixed it, you deserve the upload for it [07:16] StevenK, http://pastebin.ca/1224354 [07:16] StevenK, I haven't test built it yet (not on my intrepid box) [07:16] Care to do that for me? [07:16] ANd yes, its a big diff just because the upstream inlined ****loads of unneeded crap that had to go [07:18] That's nasty [07:18] Well, if upstream is willing to inline autotools changes ... [07:18] I'd prefer you update the date of the changelog, but *shrug* [07:41] NCommander: libpam-blue uploaded [07:45] \o\ /o/ \o/ >o Good morning [07:49] pitti: I have belted the NBS list down to 7 affected packages [07:49] It will jump again since 2.6.27-7 got uploaded [07:50] slangasek: samba with -v> WFM [07:53] ScottK: nominated 280997 for intrepid [07:53] good morning pitti [07:53] StevenK: rocking [07:57] good morning [07:58] StevenK, As an admin, could you subscribe the Bluetooth team to bluez bugs? ( https://bugs.launchpad.net/ubuntu/+source/bluez/+subscribe ) [07:59] persia: Done [07:59] ogra: speaking of admins: can you please unsubscribe edubuntu-members from thin-client-manager bugs and subscribe some edubuntu-bugsquad instead? [08:00] I could unsubscribe edubuntu-members myself, but I'd prefer if some other team was subscribed at the same time [08:16] good morning dholbach [08:16] hiya geser [08:17] slangasek, It was suggested that you might have a useful comment for bugs 281135 and 281144 [08:17] Launchpad bug 281135 in bluez-libs "Please remove bluez-libs from Intrepid" [Low,Confirmed] https://launchpad.net/bugs/281135 [08:17] Launchpad bug 281144 in bluez-utils "Please remove the bluez-utils source from Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/281144 [08:38] Is there a reason linux-generic is being held back on my beta install of 8.10? [08:39] lukehasnoname, Have you checked on what it depends? Is everything available? [08:39] I'll check. [08:39] lukehasnoname: try "sudo apt-get install linux-generic" and it should tell you why it can't be installed [08:43] geser: I ran the install and I didn't get errors [08:44] lukehasnoname, In that case it probably included a new dependency : update-manager won't install those except when doing a distribution upgrade. [08:45] bluez-cups bluez-utils evolution evolution-common gimp gimp-data gvfs gvfs-backends libgimp2.0 libpisock9 linux-headers-generic obex-data-server totem totem-gstreamer totem-mozilla totem-plugins ubuntu-desktop [08:45] Those are all being held back, in addition to the linux-generic packages that were previously held back. Any clue on specifics? [08:46] lukehasnoname: it probably wants to add or remove packages [08:46] lukehasnoname, Try running aptitude or synaptic or similar interactive tool to investigate. [08:46] "sudo apt-get dist-upgrade" and check very carefully what it wants to remove (or add) [08:49] morning guys [08:49] ehh I already pushed ahead with apt-get upgrade. I'll still check that though. [08:51] cjwatson: are you ok with http://paste.ubuntu.com/55921/ ? [08:56] mvo, in update-manager, you seem to be using gettext.gettext rather than gettext.install/gettext.translation. the latter is strongly recommended by the python stdlib docs. do you have a reason to prefer gettext.gettext? [08:57] liw: no strong reason, that I what I used in C and I'm familiar with. [08:58] mvo, ack, that's a good reason [08:58] liw: what is the advantage of using the alternative form? [08:58] liw: is there something to read up? pydoc gettext seems to be not that informative [08:59] mvo, "more flexibility and greater convenience than the GNU gettext API" says file:///usr/share/doc/python2.5/html/lib/node732.html [09:00] mvo, the flexibility probably means just that the newer API allows easily switching between languages, or supporting several concurrently [09:00] pitti: I have fixed this bug in jockey, can you have a look at my branch? https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/280147 [09:00] Launchpad bug 280147 in jockey "crash without interaction" [Undecided,New] [09:01] * mvo waves to tseliot [09:01] liw: aha, cool. thanks. I will keep that in mind :) [09:01] mvo: hi :-) [09:02] mvo, I'm not sure the "greater convenience" applies to modules, just for applications, but we'll see; since the new API is the recommended one, I'll do system-cleaner with it, and we can compare notes some day [09:03] liw: sounds good! [09:03] I have found a surprising dearth of documentation on this [09:04] liw: gettext in python? yeah, it seems that everybody just copies what he found other code. I find it also slightly anoying that gtk.glade needs its own bindtextdomain() calls (or at least it needed when I wrote the code) [09:06] mvo, I think I saw a note somewhere saying that it might not be needed anymore, but who knows... writing such a doc (or a patch to python's stdlib docs) would be a good upstream contribution [09:06] * mvo nods [09:19] mvo: hmm, disabling cancel altogether sort of worries me. Could you wrap that in an environment variable that update-manager sets for now, and send it upstream to see what Joey thinks of it? [09:20] mvo: the rest is OK although would it be worth allowing GDK_FUNC_RESIZE and GDK_FUNC_MAXIMIZE too? [09:20] mvo: oh, trivial things: there's some tab damage visible there, and debconf is in bzr (lp:~ubuntu-core-dev/debconf/ubuntu) [09:21] pitti: What do you think about bugs 281135 and 281144? [09:21] Launchpad bug 281135 in bluez-libs "Please remove bluez-libs from Intrepid" [Low,Confirmed] https://launchpad.net/bugs/281135 [09:21] Launchpad bug 281144 in bluez-utils "Please remove the bluez-utils source from Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/281144 [09:22] liw: I think gettext.translation makes more sense for modules in the same way that C libraries using gettext need to use dgettext - it gives you separate control over the domain in use [09:23] hmm, although python gettext offers dgettext too [09:23] dunno then :) [09:24] lifeless: lock shell script> there's a 'with-lock-ex' command in chiark-utils-bin [09:24] cjwatson: thanks, I will forward it to joeyh and wrap it for now [09:24] lifeless: or there's the lockfile-* suite in lockfile-progs; IME those are more annoying to use though [09:25] lifeless, I use lockfile(1) from procmail for locking in shell scripts [09:31] Hey there. Would you think that bug #150872 should be targeted for intrepid? [09:31] Launchpad bug 150872 in partman-target "Installer should not list removable media in /etc/fstab" [Medium,Confirmed] https://launchpad.net/bugs/150872 [09:37] nijaba: no, it would break things if done for intrepid [09:37] nijaba: removable media is listed for a good reason right now [09:37] nijaba: apt-cdrom has no way to discover the CD drive dynamically [09:38] cjwatson: ok, thanks, might be worth mentioning the issue in the release notes then and usb-creator help/doc/whatever as well [09:39] nijaba: Evan is already aware of the issue and it's possible that some minor hack just for USB could be possible [09:39] but we can't just strip those lines out across the board. [09:41] static device names seem to be a problem in every case, these days [10:03] mvo: btw, on that debconf patch, wouldn't it be better to attach a realize signal handler rather than calling realize? [10:04] cjwatson: http://paste.ubuntu.com/55931/ <- updated version [10:04] cjwatson: realize-handler> hm, good point [10:05] so $this->win->signal_connect("realize", sub { $this->win->window->set_functions(blah); }) or something # TEST THIS [10:06] if we continue this, I will actually lern perl along the way ;) [10:06] * mvo adds it [10:07] cjwatson: do you remember on the fly what source/udeb has partman_devices ? [10:08] cjwatson: thanks, works fine, if its otherwise ok I will upload [10:10] tseliot: bah, this Python unicode() vs. UTF-8 handling keeps driving me nuts [10:11] pitti: is the error message handled by the kde ui? [10:11] kde or gtk [10:12] tseliot: why is wrapping the string into unicode() the right fix here? [10:12] tseliot: it looks like a wrong encoding in a translation to me? [10:12] pitti: kde uses QStrings [10:12] tseliot: but this isn't KDE, this is just simple "print" to stdout [10:12] stderr, but same thing [10:13] pitti: where do you take the error message from? [10:13] fabbione: partman-base [10:13] tseliot: self.string_unprivileged [10:13] fabbione: it's parted_devices, BTW [10:14] tseliot: it calls AbstractUI._("english string") [10:14] cjwatson: oh yes.. parted_devices sorry.. but i know you are much quicker than me there :) thanks [10:14] pitti: if this is a Qt frontend, anything you get back from Qt as a QString tends to have to be wrappped in unicode() :( [10:14] I ran into that in a big way in ubiquity [10:15] cjwatson: that also affects the standard _() function? [10:15] pitti: oh, or for printing to stdout, there is some really annoying stuff you have to do [10:15] no, this is separate [10:15] right, I assumed that much [10:15] # Avoid having to do .encode('UTF-8') everywhere. This is a pain; I wish [10:15] # Python supported something like "sys.stdout.encoding = 'UTF-8'". [10:15] def fix_stdout(): [10:15] import codecs [10:15] sys.stdout = codecs.EncodedFile(sys.stdout, 'UTF-8') [10:15] def null_decode(input, errors='strict'): [10:15] return input, len(input) [10:15] sys.stdout.decode = null_decode === jamesh_ is now known as jamesh [10:15] and then call fix_stdout somewhere [10:15] I'll try to reproduce the error first, I guess [10:16] pitti: ok, wrong fix then ;) [10:16] cjwatson: thanks; I think I saw that so many times already, but it still didn't settle in my brain [10:16] pitti: my previous commit is still useful though (to blacklist nvidia 71 and 96) [10:16] tseliot: yeah, I'll merge that [10:16] ok [10:18] pitti: see also http://ewx.livejournal.com/457086.html (read the comments) [10:19] tseliot: hm, I don't get the crash with de_DE.UTF-8 (same as the reporter), and I get proper umlauts on stderr [10:19] tseliot: with both the GTK and KDE frontends [10:20] pitti: it might depend on the locale. I had a similar problem with Envy with a Turkish guy [10:20] tseliot: right, I know, but I'm using the very same locale as the reporter [10:21] ah [10:21] ok, it would be nice if we could reproduce the problem [10:23] tkamppeter: I fixed the hpgl regression and uploaded 1.3.9 to debian and intrepid [10:23] pitti: unfortunately python people don't appear to understand how encodings actually conventionally work in Unix and regard all this as not-a-bug [10:24] too many MacOS X programmers amongst them? :-/ [10:24] pitti, great, it contains also an important fix in pstops. [10:24] specifically they don't understand that stream encodings are supposed to be set by the environment not (in some undefined way) by the terminal [even though in some entirely different ideal world the latter might be how it ought to work] [10:24] pitti, why does "bzr pull"W not show it? [10:24] tkamppeter: I just pushed like 10 seconds ago [10:25] and that there have to be ways to override it since the environment can be wrong [10:25] pitti, sorry, I was 1 minute too early [10:26] actually, python does set stdout's encoding from the environment, but *only if stdout is a terminal*. This is clearly mad since putting | less after your program can cause it to stop working. [10:26] indeed I just tried that, but it still works [10:26] pitti: is it worth catching the exception then? (not that I like it...) [10:26] $ PYTHONPATH=. gtk/jockey-gtk --check 2>&1 |cat [10:26] Sie sind nicht berechtigt, diese Aktion auszuführen. [10:26] it depends on your environment [10:26] the reporter might have the locale set but not in fact have the locale generated, for example [10:27] ah, that's a good thing to ask in the bug report [10:27] I really would suggest just clobbering it with something like the rune I suggested above [10:27] python is known-broken in this area and you have to set things explicitly [10:27] if sys.stdout.encoding were writable it would be much more pleasant [10:28] cjwatson: right, I just don't feel good about hardcoding UTF-8, since users might actually use an ISO, KOI-8, or whatever encoding in their locale [10:28] pitti: use locale.getpreferredencoding() in place of 'UTF-8' then [10:29] (I haven't tested that but I think it should work) [10:29] this raises a severe deja-vu for me; I think I got that like half a year ago in apport [10:37] pitti: confirmed, http://paste.ubuntu.com/55934/ [10:38] you might want to do the same for stderr [10:43] cjwatson: nice, thanks! [10:45] StevenK: hm, those are duplicates? [10:45] StevenK: looking at checkrdepends bluez-libs intrepid [10:46] So, a game I've been preparing for Intrepid for some time (Spring) just made a release, and I have a package ready. Is there still enough time to upload it to Intrepid, or will it be rejected? (this is a completely new package) [10:46] pitti, Note that libbluetooth3 is now provided by the bluez source. [10:47] YokoZar, It's decidedly late. you might appeal to MOTU SRU, but it's unlikely. [10:47] -- intrepid/universe i386 deps on libbluetooth2: [10:47] ussp-push [10:48] and some in main/universe on eternally-lagging hppa [10:48] mvo, 0.7.8 didnt fix it for me :/ [10:48] pitti: Yup, ussp-push is the last one [10:49] I fixed the rest today [10:49] however, there are a couple of more unfixed things in bug 276343 [10:49] Launchpad bug 276343 in ussp-push "Rebuild for libbluetooth2 -> libbluetooth3 transition" [Undecided,Fix committed] https://launchpad.net/bugs/276343 [10:49] StevenK: so once the transition is complete, then the package can go, sure [10:50] but it seems most of them should be closed? [10:53] pitti: Yeah, most of the bugs should be sorted. I forgot to add the bug number to the my buildX uploads [10:54] Hmmm [10:54] Should do this through the mail gateway [10:56] it just occurred to me that our gnutls13 -> gnutls26 transition is still outstanding, too [10:56] *sigh* [10:56] otherwise we'd again have two gnutls versions in stable [10:57] What's needed for that? [10:58] That's a bundle, including curl [10:59] Whee [10:59] pitti: Let me finish dealing with bluetooth first [10:59] I am just doing process-removals, and that reminded me [11:00] Ah [11:00] Is there any good tool that could identify transitions underway? While completing them all is maybe hard, having a list would be a good start. === asac_ is now known as asac [11:00] persia: NBS, mostly [11:01] StevenK, That only covers cases where there isn't a source name transition. I'm wondering if just checking packages that build-depend against a given -dev have binaries that depend on the associated lib. [11:01] the gnutls13 source is still there, so that won't appear as NBS [11:01] Same for bluetooth, or other stuff [11:02] pitti: Right, but we have rdepends [11:02] StevenK: you know checkrdepends? [11:04] pitti: Of course [11:04] Right, that mail should set everything aside from ussp-push to Fix Released. [11:04] Where the ussp-push source has gone, I don't know [11:07] * pitti needs to run out for some errands, bbl [11:08] asac: About NM, not on purpose I don't use a hybrid setup. Everyone who tried it (there were three of us, IIRC) saw similar issues on Kubuntu. [11:09] ScottK: hybrid == /etc/network/interfaces has a configuration ;) [11:10] asac: It says auto eth0. Does that count? [11:10] ScottK: if there is no iface eth0 ... line then it shouldnt [11:11] Nope [11:11] The only iface line I have is for lo [11:11] ScottK: please paste your route -n output when you see these packet losses [11:11] OK. Will do. [11:11] ScottK: i have received other complains, but couldnt reproduce here except for a hybrid setup [11:12] ScottK: for me "wired" interfaces always have a metric/prio of "1" and wireless have a metric/prio of "2" [11:12] could some native speaker/UI expert review those strings: http://paste.ubuntu.com/55942/ ? its for the upgrade note about the new fusa applet that replaced the logout button [11:12] which should tie-break the path the packages travel - assuming that both interfaces provide a route to the same net [11:13] OK. [11:14] ScottK: are you using NM 0.7 on intrepid right now? if so, please post the routing right away :) [11:14] (even if you dont see the package loss right now9 [11:14] asac: gnash is still on your list, right? [11:15] asac: Will do [11:16] asac: In the bug or pastebin? [11:16] mvo: http://paste.ubuntu.com/55946/ [11:16] james_w: excellent, thanks! is the text ok? understandable etc? [11:16] mvo: "got" -> "has been", "on the standard location" -> "in the standard location" [11:17] mvo: yeah, but you might want a UI review if you can find somebody [11:18] james_w: I will try, I had hoped that mpt is around [11:18] asac: I added it to Bug #280919 [11:18] Launchpad bug 280919 in network-manager "NetworkManager 0.7~~svn20081008t224042-0ubuntu1 breaks Knetworkmanager" [Medium,Incomplete] https://launchpad.net/bugs/280919 [11:18] mvo: yeah, is seele around? [11:19] does anyone know if it's possible to get rmadison to really show me just source records. It seems to recognise "source" as an architecture, and has a "source and binary" option that I'm not selecting, but it still shows me all architectures. [11:20] looking at the php it seems to proxy directly to "dak ls" calls [11:28] ogra: what video driver is this? [11:29] mvo, intel [11:30] * ogra goes to debug it more [11:30] might be gpm [11:30] or just a bug in xorg wrt dpms [11:42] james_w: it actually proxies to madison-lite for us; it's probably a madison-lite bug if it doesn't work. That said, 'rmadison -a source linux' seems to DTRT. What's your example? [11:42] cjwatson: ah, I was running against Debian [11:43] it does indeed seem to work for Ubuntu [11:43] ScottK: thanks. the routing looks fine. but as you said in the bug you didnt have problems with that? [11:44] james_w: ahright [11:44] asac: Yes. Riddell just reported he has no wired connection either right now. [11:44] it's rather unusual for madison-lite to work *better* than dak ls ... [11:44] ScottK: ok. you dont see an AP ... but thats a different issue (if not a general knetworkmanager bug) [11:44] So I think there is a real problem here, not sure exactly what as I couldn't replicate the laggy behaviour I saw yesterday. [11:45] ScottK: you could try to load iwl4965 with disable_hw_scan=1 ... and see if you get more reliable scans [11:45] davmor2, rumor tells me you have an acer aspire one... does it require non-free drivers? [11:45] Could be. Others have no wired at all, so don't take my success as meaningful. [11:45] (but thats a different bug) [11:45] actually my eth0 seems to have disappeared completely [11:45] ScottK: others == users that currently see this problem? [11:45] I think that's probably unrelated [11:45] dmesg doesn't show it [11:45] liw: I do indeed, goes and double checks [11:46] asac: Yes. Riddell and regreening at least. [11:46] Riddell: e1000? [11:46] ;) [11:46] Riddell: if you see packet loss please put your route -n to the bug [11:46] asac: fortunately not [11:47] Riddell: if eth0 is gone its obviously a driver issue. if wireless is the only iface used, its unlikely that slowness is a NM problem [11:47] at least ii dont see how it could be :/ [11:50] I have no eth0 but I have something called pan0 [11:50] Riddell: but that doesnt show up in NM right? [11:50] Riddell: pan0 :( [11:51] Riddell: pan0 is bluetooth-related [11:51] Riddell: hal-find-by-capability --capability net.80203 [11:51] oh. bluetooth. [11:51] if that doesnt show up anything then NM cannot know your wired [11:51] for wireless its: hal-find-by-capability --capability net.80211 [11:51] asac: that shows up nothing indeed [11:52] for 3G mdoem its: hal-find-by-capability --capability modem [11:52] the wireless one shows something [11:52] Riddell: yeah. what chipset has your wired? [11:53] 00:19.0 Ethernet controller: Intel Corporation 82566DC Gigabit Network Connection [11:53] "Kernel modules: e1000e" erk [11:53] ha ;) [11:53] i knew it :-D [11:53] wasnts e1000e fixed? [11:53] Riddell: is that driver loaded (e.g. lsmod | grep e1000) ? [11:54] Yes, but the key to restore broken firmware wasn't pushed (IIRC) [11:54] oh ... so Riddell has a broken firmware ;) ... not that cool [11:54] asac: yes [11:54] shows how often I use ethernet [11:54] Riddell: ok i think you should talk to rtg [11:55] Riddell: and your wireless issues are? [11:55] asac: my wireless is all good [11:55] ok. then there is no NM regression at least :) [11:56] well other people have troubles we havn't got to the bottom of yet [12:13] if I add translatable strings to my code, the .pot file needs updating; do I just re-create it from scratch using xgettext or what? [12:14] gettext supplies a Makefile that can do it [12:15] /usr/share/gettext/intl/Makefile.in? [12:16] you don't want to copy it around by hand if you can help it ... [12:16] or possibly /usr/share/gettext/po/Makefile.in.in, hmm [12:16] cjwatson, yeah, I really really don't want hundreds of lines of excessively complicated Makefiles :) [12:16] I guess you aren't using automake [12:16] this is for a Python program, so no [12:16] you could use gettextize [12:16] and see what it does and whether you can massage the result to be acceptable [12:17] usually you just leave its results in po/ and forget about it [12:17] to directly answer your original question, it ultimately comes down to recreating it using xgettext and using msgmerge to update the .po files [12:17] . o O (someone needs to document this really well) [12:18] info gettext [12:18] cjwatson, I have been reading that, and I find it to be confusing [12:19] while I sympathise with a detestation of autogenerated Makefiles, in this case it is orders of magnitude less wasted time than doing it by hand, IME [12:19] might be because it's a complicated process, of course [12:20] cjwatson, that's possibly true, but then I need to deal with the massive headache of keeping the autogeneration of the Makefile working [12:20] I find that easier than keeping the .pot/.po files working without that [12:20] gettextize won't work without autotools being used, it seems [12:21] you could look at how debconf does it [12:21] it has a by-hand Makefile for this [12:21] copying somebody else's by-hand work is probably easier than duplicating it :) [12:23] I return to my point that someone needs to document this well :) [12:24] as far as I can see, there needs to be something that updates the .pot file with new strings (and removes old ones?), then based on that updates the .po files (adds missing strings, marks changed strings as fuzzy?); that doesn't sound like it should require autotools or hordes of Makefile magic [12:28] update .pot files with new strings => xgettext; update .po files => msgmerge; you also need something to compile .po to .gmo files; you might want to support 'make install' and/or 'make dist'; sometimes people want to disable i18n or enable only certain languages; and some people want to support systems where GNU gettext is not already installed [12:29] also some maintainers only want to rebuild .pot manually rather than automatically [12:29] or want to update it only if the .pot changed non-trivially (i.e. more than just the creation date or whatever) [12:29] (which avoids vcs noise) [12:30] are .gmo files the same as .mo files or is this some fourth type of file? [12:30] once you do all of that you're actually not that far off the complexity of gettext's po/Makefile.in.in [12:30] info gettext C-s gmo [12:32] ack, they're gnu's extended and embraced version of .mo, good :) [12:36] cjwatson, all that complexity could surely be wrapped in tools less awful than autotools, I'm sure; anyway, I don't want or need most of the complexity, so I'll go some simpler route [12:39] liw: check out python-distutils-extra if you look for something that does the i18n in system cleaner [12:42] mvo, that looks like useful for the parts that are involved in installing the .mo files; does it take care of generating the .mo files from .po files, too? [12:42] liw: yes [12:42] cool [12:42] liw: it should do all that is required, if not, file a bug against it [12:43] (or let glatzor or me know about the problem) [12:43] mvo, is it also involved in updating .po files from .pot? [12:44] * liw goes read docs [12:44] liw: yes, it should do all that, check gnome-app-install setup.cfg and setup.py for a example [12:44] liw: + po/POTFILES.in and you should be done [12:45] liw: it also supports desktop files and desktop file i18n [12:45] Riddell: if people have troubles ask them if they are running a hybrid setup (meaning: 1 device managed in /etc/network/interfaces and the other in NM) [12:45] asac: right [12:45] Riddell: that setup is know to have metric issues i still have to sort somehow [13:15] mvo, "setup.py build_i18n --merge-po" seems to require a po/POTFILES.in, which does not support wildcards; is that intentional? [13:17] liw: po/POTFILES.in is required, not sure about the wildcards, it uses intltool internally, not sure if that supports them or not (I guess not if you have problems with it) [13:18] mvo, ah, so it's just intltool-update that uses that, ok [13:18] liw: yeah, its just a (thin) wrapper around the intltool* stuff [13:19] mvo, has anyone reported that in intrepid beta update-manager doesn't *ever* close itself but just hangs in the "ldconfig deferred processing" phase? [13:20] alkisg: yes - that bug is milestoned [13:20] (ogra told me to tell you, he also saw that yesterday) [13:20] mvo, ah, great, i wasnt sure [13:20] bug 280236 [13:20] Launchpad bug 280236 in update-manager "update-manager --dist-upgrade gets stuck at the end" [High,Triaged] https://launchpad.net/bugs/280236 [13:21] mvo, btw i just removed gnome-screensaver and still see the issue ... i'll run a dbus-monitor session now to see if there are any events keeping it from proerly doing dpms [13:21] mvo, ogra, thanks. [13:22] ogra: oh, that is interssting [13:24] mvo, yay! ./usr/share/locale/fi/LC_MESSAGES/systemcleaner.mo [13:25] liw! [13:26] Does anyone know from which package network-manager(-gnome?) gets the available UTMS/GPRS network list? [13:26] I can't find it in network-manager{,-gnome} [13:27] mvo, and another somewhat serious one, gparted (and the installer) can't create smaller partitions on empty disks (tried on different 3 PCs). I had to create 1 full-disk partition, shrink it, then create others and then run the installer... [13:31] alkisg: oh, is that reported already? [13:32] mvo, I saw something similar reported, but only for the installer, not the backend lib which is used (and I think the fault is there... libparted is it?) [13:33] alkisg: I've never heard of such a bug (I co-maintain the installer); it must be hardware-specific. Can you refer me to the bug number? [13:33] It's usually reported as ubiquity crashed, with auto-collected debug data [13:34] I've sent one myself, and was considered a duplicate [13:34] let me find it... [13:35] I'm not sure why that would be a crash, unless there's something more than what you described above [13:35] liw: Good :) [13:35] liw: Do you need sponsoring for system-cleaner with i18n? [13:36] lool, when it's done, yes [13:36] This is the main one: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/260001 (I think it's the same symptoms as mine), [13:36] Launchpad bug 260001 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader()" [Undecided,New] [13:36] configure_bootloader has nothing to do with creating partitions! [13:36] And this one's mine: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/278019 [13:36] Launchpad bug 278019 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader() (dup-of: 260001)" [Undecided,New] [13:37] cjwatson, read mine, I'm not really sure if they're the same [13:37] this sounds like the problem where libparted sometimes forgets to change the partition type [13:37] cjwatson, yes, that's what I got [13:37]