[12:10] geser: /usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../lib64/crt1.o: could not read symbols: Bad value <= what does that mean ? [12:10] look at line 31 [12:10] geser: do you have /lib64 in your system ? [12:11] yes [12:11] k, so I need to do that -fPIC thing ? === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-motu [12:12] What info do I need to put in a bug requesting syncing a package that isn't in Ubuntu yet? Just name, version, Debian component and the fact that it's new? [12:13] yes === cr3_ [n=marc@MTRLPQ02-1177745615.sdsl.bell.ca] has joined #ubuntu-motu [12:13] same sync policy [12:13] I presume I don't have to throw in changelog entries or anything... [12:13] is -fPIC a compile or link option ? [12:13] former [12:14] why not? [12:14] ^^ Fujitsu [12:14] Wow, this tss uses a GPL boilerplate with FSF address "675 Mass Ave, Cambridge" [12:14] isn't that like two versions old? [12:14] that's impressively outdated [12:15] crimsun: Because there's no changes that have to be checked, because there's no previous version? [12:15] Wow! That's really old. [12:15] Fujitsu: so you'll have to use the default, which means list them all [12:15] OK. [12:15] Shall do. [12:19] AnAnt_: How to write a good debian/copyright file: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html [12:20] i don't really understand how the queue works, seems that not all packages go through the queue ? [12:20] "the" queue? there are multiple queues [12:21] this one : https://launchpad.net/distros/ubuntu/edgy/+queue [12:21] about what are you unclear? [12:22] i see a lot of new packages coming in edgy in the rss feed (i think it's the same that edgy changes mailing list), and i don't see this packages in this queue [12:22] a new source package goes into the NEW queue. After it's accepted, it's built after the next publisher run. The binaries end up in the binary NEW queue. After those are accepted, they're synced to mirrors on the next publisher run. [12:23] minghua: thanks [12:24] https://launchpad.net/distros/ubuntu/edgy/+queue < it should be the first queue ? why are there sources and packages ? [12:24] say you upload a new source package named foobarcrack that generates one binary package, libfoobarcrack0. It goes through the precise process I just described. Now let's say you have a new upstream version that bumps the soname to 1, so you uupdate, adjust the packaging, and upload. [12:24] crimsun: after the source package is accepted & while it's binaries are in the queue, does the source package go to the repos ? === philwyett [n=philip@80-195-142-67.cable.ubr02.wiga.blueyonder.co.uk] has joined #ubuntu-motu [12:25] what is uupdate? [12:25] Because the source package already exists, it doesn't need to go through the source NEW queue again. Instead, the new binary package, libfoobarcrack1, ends up in the binary NEW queue after it's built. libfoobarcrack1 needs to be ACCEPTed, then it will be published and synced to mirrors. === nictuku [n=yves@ubuntu/member/nictuku] has joined #ubuntu-motu === Q-FUNK [n=q-funk@dsl-hkigw7-fe10f900-10.dhcp.inet.fi] has joined #ubuntu-motu [12:27] AnAnt_: see uupdate(1) [12:27] AnAnt_: yes, the source has already been ACCEPTed, published, and perhaps synced [12:28] crimsun: thanks for the ack on upgrade-system [12:28] np [12:28] bug #61626 [12:28] Malone bug 61626 in cups-pdf "Please sync cups-pdf (universe) from Debian unstable (main)." [Untriaged,Needs info] http://launchpad.net/bugs/61626 [12:28] this is the one thta would make a lot more people happier, though ;) [12:29] hm. doesn't it get added to the sync queue once a motu acknowledges it? [12:30] crimsun: so only new packages (not updates) appear in https://launchpad.net/distros/ubuntu/edgy/+queue ? [12:30] Q-FUNK, which sync queue? [12:31] Adri2000: right [12:31] crimsun: do you know why bug 57632 didn't get picked up by universe sponsors? [12:31] Malone bug 57632 in coolmail "Coolmail segfaults" [Untriaged,Confirmed] http://launchpad.net/bugs/57632 [12:31] crimsun: acon source is not there [12:32] $ apt-cache madison acon [12:32] acon | 1.0.5-0ubuntu1 | http://archive.ubuntu.com edgy/universe Sources [12:32] ok LaserJock [12:32] crimsun: Notice that ubuntu-archive is automatically subscribed using Martin Pitt's sync request script. No point in telling me not to subscribe them. [12:33] Q-FUNK: I'll speak to Martin about that, then. [12:33] crimsun: ? [12:33] crimsun: I just searched the packages.ubuntu.com site [12:33] Adri2000: source updates that generate new binary packages still end up in the binary NEW queue just as I described above. [12:33] crimsun: and the bug is auto-confirmed using that same script too. [12:34] AnAnt_: packages.uc does not sync every hour. [12:34] Q-FUNK: again, I'll speak to Martin about that [12:34] crimsun: some updates are just binaries ? [12:34] Adri2000: what are "some updates"? [12:34] Are you sure that pitti means that script to be used by non-MOTUs? That's doing very MOTUish stuff. [12:34] k [12:34] crimsun: very nice script, but as evidenced by your response, should probably have the commands it sends to malone revised according to what the concensus is. [12:35] geser: most likely because its subject line falls through my spam filter [12:35] Fujitsu: IIRC I found it via link of apge describing the steps how to ask for a sync [12:36] crimsun: i really do not understand :p all new packages and all updates must be built, ok ? the uploader uploads only the source ? [12:36] argh. ...of a wiki page [12:36] Adri2000: correct, we do only source uploads. [12:37] some packages in the queue are binaries ... :/ [12:37] Fujitsu: it had a bit that went like "do the following steps manually or use pitti's nice script at [link] " [12:37] geser: ok, I found that linux32 exists for i386, so I'll compile here first [12:37] Adri2000: because the source packages generate /new/ binary packages [12:37] naming-wise [12:38] hmmm, it's the same queue for package 1) (source) waiting to be built 2) (binary) waiting to be uploaded [12:38] ? [12:38] Yes, NEW. [12:38] crimsun: though honnestly I find the approach of asking a motu to ask a dev to ask ftp master to do a sync to feature a needlessly huge number of steps. [12:39] then i understand :) [12:39] Q-FUNK: a MOTU /is/ a member of ubuntu-dev. [12:40] ok [12:40] random joe should not be able to get an approved sync. A Debian developer is not a random joe, OTOH. [12:40] so why do I still get a feeling that getting a sync approved still goes thru one too many steps? [12:40] Q-FUNK, it doesn't. [12:41] there you go. I maintain the packages on which I request a sync. it shouldn't have to be so difficult. [12:41] Q-FUNK: how would we remove steps? [12:41] LaserJock, I'm wondering the same. It's minimal as it is. [12:41] Q-FUNK: you're also not a member of ubuntu-dev. [12:41] Q-FUNK: well, but that's a bit different, tbh [12:41] by dirrectly allowing the maintainer at debian to request a sync if he notices his packages drifting away at ubuntu, maybe? [12:42] then become a member of ubuntu-dev. [12:42] LaserJock, want to look at python-{scipy,numpy}/matplotlib? I've had to remove a bashism in matplotlib's debian/copyright generator script, but otherwise the diffs are pretty small. [12:42] crimsun: you're missing the point. [12:42] just because it's your package doesn't automatically give you rights to push into someone else's repo. [12:43] i have a package waiting since the 18th to be built. is it just that no archive admin had time to accept it yet, or may there be a problem ? [12:43] Fujitsu: sure, give me a url of the debdiffs [12:43] Adri2000: time [12:43] sometimes we wait for a couple weeks [12:43] it just depends on how much time people have [12:43] crimsun: I'm gonna be blunt about this one: you're rude and completely in the woods. [12:43] Q-FUNK: it was not my decision, I simply abide by it. [12:44] Q-FUNK: dude the same thing goes the other way === AnAnt [n=anant@62.139.225.199] has joined #ubuntu-motu [12:44] I maintain a package in Ubuntu but I still have to go through a sponsor in Debian [12:44] no different [12:44] I'm an ubuntu-dev and not a DD so I have to play by Debian's rules [12:44] and that's the way it *should* be [12:45] oh but there IS a key difference: Debian is essentially Ubuntu's upstream. [12:45] let's say I work for Red Hat and make a package. Debian (and Ubuntu) pull in the source package. Do I automatically have the right to request a sync for /my/ maintained package? [12:45] LaserJock: a couple weeks ? :/ only 5 days remaining before the universe freeze :/ [12:45] If I wish to have my maintained package synced, I need to abide by Debian's policies. [12:45] Q-FUNK: that's doesn't matter really, would you allow your upstream to ask for a new upstream release directly? [12:46] crimsun: let's just say that if you bother merging a fix that specifically benefits debian and ubuntu, it would be a good idea for debian and ubuntu to sync. [12:47] Q-FUNK: I'm not at all discussing whether syncing is good. I'm saying there's policy in place, and it holds /regardless/ what direction originated the work. [12:47] Then upstream can request it, but it will still have to go through the proper channels. === reggaemanu [n=manu@ARennes-257-1-139-218.w86-210.abo.wanadoo.fr] has joined #ubuntu-motu [12:49] I may be rude, yes, but that's the way it works in Debian, and it's the way it works in Ubuntu. [12:49] crimsun: see the code of conduct and call us back in the morning. [12:50] LaserJock, http://people.ubuntu.com.au/~fujitsu/scipy_etc [12:50] Q-FUNK: what? he didn't say anything that was against the CoC [12:50] If anyone else believes I've overstepped my bounds as a member, please do speak up. [12:50] Nope, you're fine, crimsun. [12:50] LaserJock: he was rude. that's clearly agaisnt the CoC. [12:50] he was not rude [12:51] he just simply stated that being the debian maintainer doesn't give you the right to push stuff in Ubuntu [12:51] Q-FUNK, was he? I didn't see that anywhere. [12:51] and that is 100% correct regarding policy [12:51] you are not an ubuntu-dev or ubuntu-core-dev [12:51] exactly how am I pushing anything? I'm not ftp master anywhere, am I? [12:52] ok, so s/pushing/upload or aprrove upload/ [12:53] (I believe the correct semantics are "following policy.") [12:53] so I really fail to see rudeness there and certainly not a violation of the CoC [12:53] it would be a lot simpler to simply disable some launchpad functions for people who are not ubuntu-dev. [12:54] Q-FUNK, like!? [12:54] they are [12:54] some things [12:54] I'm not really sure what you are getting at though === reggaemanu [n=manu@ARennes-257-1-139-218.w86-210.abo.wanadoo.fr] has joined #ubuntu-motu [12:54] you can request a sync [12:54] apparently not. crimsun was complaining about me setting certain flags that, for some reasons, were accessible to me. [12:55] Q-FUNK: well, that is a bit hard [12:55] such as subscribing some teams that, for some reasons, shouldn't have been. [12:55] as the flags can be used for other things [12:55] Q-FUNK, it's not sane to disable confirming of bugs. [12:55] I wasn't complaining at all. I simply asked you not to subscribe u-a first, which is not at all your fault. [12:56] Again, I've reiterated the point that I'll speak with Martin concerning it. [12:56] crimsun: might help to avoid using imperative forms in your comments then. [12:56] I fail to see how that's actually relevant. [12:57] anyhow, I'm not interested in draging this on forever. [12:57] Nor am I. [12:57] yes === reggaemanu [n=manu@ARennes-257-1-139-218.w86-210.abo.wanadoo.fr] has joined #ubuntu-motu [12:57] thanks for the concern Q-FUNK with your package [12:57] my only point is this: some maintainers at debian will gladly merge patches to help thin out the delta. I'm one of them. it would help if there were simple steps they could follow to keep track. [12:58] sorry the script led you to something we'd like to avoid [12:58] hopefully we'll get that fixed [12:58] I certainly believe sync policies could be amended to allow Debian maintainers some greater leeway. [12:58] mhm [12:59] Oh no. Another OOo upload. [12:59] Q-FUNK: keep track of what? the whole syncing proccess? [01:00] Fujitsu: that one has been there for a while, or are my mailserver not keeping up? :-) [01:00] Q-FUNK: and that's why lucas tried to launch an Ubuntu "Debian Collaboration Team" but he and I didn't have time to really work on that so far :/ [01:00] hi everybody === minghua [n=minghua@ppp-70-128-92-243.dsl.hstntx.swbell.net] has joined #ubuntu-motu [01:00] Nafallo, about 3 hours ago. [01:00] personally, the only thing I would need to have more painless interaction is to be enpowered to directly request the sync and confirm that I can build in a $release chroot. [01:00] Fujitsu: old one then ;-). already on half of the buildds :-P [01:01] Q-FUNK: I concur. [01:01] Q-FUNK: yep, sounds pretty reasonable [01:01] I already am on launchpad and I keep track of useful fixes. I tend to merge them back rather quickly, as long as I don't notice any break in Debian. [01:02] Q-FUNK: I believe the most efficient manner for the sync process to be adjusted for Edgy+1 is to raise the issue on the ubuntu-devel mailing list, which may necessitate bringing it before the Technical Board. [01:02] the script already does what I need (although, as I understand, the commands it passes to Malone should not be in a non- ubuntu-dev's hands). [01:02] It is TB material, yes. [01:02] Q-FUNK: do you think something like what's described in https://wiki.ubuntu.com/DCT would help? [01:03] I think some of the problem too, is that there aren't that many DDs that are doing that. We simple haven't come across those issues [01:03] much [01:03] our normal process is to have lots of non-devs working away on merges and syncs and having a good approval process is important [01:04] LaserJock: TBH, a lot of DDs would glady help if e.g. pitti's script could be modified in a bullet-proof way. [01:04] then, the only other stape woud be to have a user on launchpad to interact with users. [01:04] Q-FUNK, a lot of DDs hate Ubuntu, though. [01:04] mhm [01:04] not a lot [01:04] some [01:04] some [01:05] an outragous minority, I would say [01:05] bug 61949 needs another MOTU advocate (ACK the sync request). [01:05] Malone bug 61949 in Ubuntu "Please sync treeviewx 0.5.1-1 from Debian Sid (main)" [Wishlist,Confirmed] http://launchpad.net/bugs/61949 [01:05] ah, I got that one [01:05] Toadstool: yes [01:05] It needs two? [01:05] Toadstool: it's a very good start [01:06] Fujitsu: (same policy as with REVU and new packages) [01:06] Ah, OK. [01:06] Fujitsu: most DDs and Debian users I know tend to do like me and hand out Ubuntu CDs to everyone they know. [01:07] Q-FUNK: rock on! :-) [01:07] :) === jinty [n=jinty@195.Red-83-58-178.dynamicIP.rima-tde.net] has joined #ubuntu-motu [01:07] baah. I've seen to much of jdub lately ;-) === Nafallo goes to hide/give support again :-) [01:09] but basically, if all a DD needs to help is to: [01:09] 1) sign on to launchpad to be able to comment bugs. [01:09] 2) have a handy script to request a sync and a clear checklist of items to confirm in that sync request. [01:09] then I think that we can make the delat between most packages disappear in no time. [01:09] delta [01:10] typos r us [01:10] Yes, that'd be really great. [01:10] That's quite probable, and I'd like to make that a reality. [01:10] me too === reggaemanu [n=manu@ARennes-257-1-139-218.w86-210.abo.wanadoo.fr] has joined #ubuntu-motu [01:11] I also encourage you to do sustained Ubuntu work so you can upload directly to the Ubuntu repository. [01:11] here, I'm just amazed at how long it's taking to get what was a trivial fix on a package to finally get in. [01:12] yes, it is quite shameful [01:12] Just look at the backlog on REVU for a better idea [01:12] sure. I'd love to do that. mind you, I'm mostly focusing on advocacy and promotion. [01:13] Ubuntu could really use more (active) MOTUs :( [01:13] any and all help are welcome. [01:13] well, when you consider how many active MOTUs there are ... [01:13] LaserJock, count on two hands? [01:13] yep [01:13] Fujitsu: is it that bad? [01:13] Q-FUNK, I believe so. I'm not a MOTU, though. [01:13] So I'm not helping that statistic. [01:13] I'd say there are about 5 MOTUs that do most of the work [01:14] Ouch. [01:14] what obstacles do you see that currently prevent more people from joining and from participating? [01:14] That's 3000 packages each :P [01:14] You just named one. There're also resource constraints. === Nafallo counts atleast 6 ;-) [01:14] Q-FUNK: more or less, getting people to commit to it and getting them to where they have the technical ability [01:15] I've hardly touched packaging for edgy [01:15] simply have too many things to do [01:15] what would be a good way to get e.g. people frustrated by Debian's NM process and yet who already have a few good packages at Debian to prove their worth to join in? [01:16] Q-FUNK: fixing bugs, doing merges and syncs [01:17] part of it right now is the fast release cycle and time commitment [01:17] erm... you read that backwards. or well, maybe I write to long sentnces. lemme rephrase: [01:17] if I just had to maintain 5-10 packages as I do in Debian [01:17] it wouldn't be a big problem [01:17] but I'm trying to keep track of 400+ packages [01:18] what would be a good way to get people, who proved their worth at debian with good packages and good maintenance habits, to have a painless motu membership? [01:18] LaserJock: Yes, there aren't many science MOTUs, unfortunately. [01:18] pretty much what I said + showing up here and proving you're a part of the team [01:18] A few Ubuntu devs have gone that route, Q-FUNK, like StevenK and azeem to name two. [01:19] many NMs can become MOTUs in I'd say in 1-2 months if they work at it [01:19] I know many people who have had their packages sponsored for ages, some of them even having completed NM and yet without their DD account yet and who are going nuts with the bureaucracy at debian. [01:19] the Community Council and Technical Board do tack into account Debian maintainership activity [01:19] ajmitch! :-D [01:20] ajmitch was in the Hoary exception group (where we gained both membership and MOTU) in one step. [01:21] hmm, I wonder if I was. [01:21] there's a lot of people losing motivation at debian right now and mjray was only the tip of the iceberg. === Nafallo can't remember :-P [01:21] Q-FUNK: well it happens, but I know for sure that a 2-3 NM process is not something I feel like going through [01:22] some old experienced DDs but also a LOT of new faces with lots of motivation and plenty of afterschool time to spare. [01:22] LaserJock: a 2-3 NM ? [01:22] 2-3 year [01:23] ah [01:23] yes [01:23] well, it varies a lot. [01:23] however, it does weed out a lot of people I suppose [01:23] I've known peole to pass it within 1 month [01:23] yes and no [01:23] Nafallo: I _think_ you were. Yeah, my memory's horrible, too. [01:24] the delay is completely arbitrary. partly due on the AM's availabilty, but also sometimes due to the DAMnation of never getting the account created for personal vendeta. [01:25] crimsun: should I subscribe ubuntu-archive to the treeviewx sync? [01:25] Thanks LaserJock :) [01:25] I've also noticed people who's approval was fast-tracked. [01:25] LaserJock: please do [01:25] erm... whose [01:25] geser: apologies for the delay; I'll process it tonight [01:26] Fujitsu: do you have a url for the matplotlib, etc. ? [01:26] LaserJock, I mentioned it a while back... Wait a sec. [01:26] Q-FUNK: we already have the accounts on launchpad and just get approval to the right groups. that's mostly happening the moment you get approved in the meeting :-). === nixternal [n=nixterna@ubuntu/member/nixternal] has joined #ubuntu-motu [01:26] LaserJock, http://people.ubuntu.com.au/~fujitsu/scipy_etc [01:26] I don't know, I sort of feel like we perhaps to a lot more non-packaging related stuff in Ubuntu [01:27] Q-FUNK: I think Keith Packard (fontconfig upstream and maintainer) got through NM pretty fast [01:27] LaserJock: localisation, documentation and marketing-related stuff such as artwork and the overall polish have a bigger importance at ubuntu. [01:28] Fujitsu: ok, I'll take a look soonish [01:28] minghua: could be [01:28] Thanks, LaserJock. [01:29] that's actually a discussion we've had one too many times here at local LUGs. we're all debian users and yet we have to admit that the ubuntu CD really is what 99% of this planet needs. [01:30] while we are collect ACKs for Sync Requests bug 61955 needs also two, doesn't it? [01:30] Malone bug 61955 in Ubuntu "[Sync Request] sylpheed-claws-gtk2-extra-plugins 2.5.0~rc3-1 from Debian unstable (main)" [Untriaged,Unconfirmed] http://launchpad.net/bugs/61955 [01:30] ok, gota get home [01:30] Bye. [01:30] mostly because that single CD contains exactly what a desktop user needs and the default settings are sane. [01:30] geser: yes. [01:31] Q-FUNK: you can't be too sure :-) in some area with different language and different economy, Debian may still has the advantage [01:32] minghua: how? [01:33] especially looking at the emphasis that ubuntu puts on localisation, which is something that just barely got taken care of at debian [01:33] Q-FUNK: I am from China. I know a Ubuntu-derivative in China choose to start from Xubuntu, because (K)Ubuntu is a bit slow on the average machine in China [01:33] Q-FUNK: the emphasis on l10n, for sure, but it's not there yet [01:33] they've have denis and bubulle taking care of locales and coordinating the merging of trnaslations, but having a localisation infrastructure is soemthing quite recent at debian [01:33] at least not dapper [01:34] I know India's local language linux is a debian derivative [01:35] because debian has better language support [01:35] minghua: for that, I think that the main issue is that gnome and kde are complte DEs and have been localized for a long time. [01:35] things may start changing in edgy [01:35] but I know dapper is not there [01:35] what's missing? [01:36] I think the input method of quite a lot of languages in dapper is broken/half-broken [01:36] ah yes [01:36] e.g., you can't input in Qt apps if you install Ubuntu [01:36] nor GTK apps if you install Kubuntu [01:37] the input method support in dapper is quite rushed, IMHO [01:37] kmuto told me a bit about that. the free desktop needs unified input tools [01:37] Q-FUNK: oh, so you were at the i18n Ex... meeting? [01:37] it's not dapper, mind you. it's just that each DE exists in its own universe. [01:38] Q-FUNK: no, it's some simple oversight in the settings [01:38] no but kmuto was and we previously met at debconf5 [01:38] Q-FUNK: trust me, I know this business, I am the maintainer of scim in debian [01:38] minghua: ok. have those oversights been reported in malone? ;) [01:38] Q-FUNK: yes [01:38] ah :) [01:38] Q-FUNK: but nobody seems to care much [01:39] hm.. === AnAnt [n=anant@62.139.225.204] has joined #ubuntu-motu [01:39] I am a MOTU myself, but I can't fix them because the packages are in main [01:39] what's the difference between preinst & postinst ? [01:39] geez, burning this data DVD is taking forever [01:39] I should've provided the -speed arg [01:39] minghua: tried mentioning it to the localisation and internationalistion teams? [01:39] that was a quite bitter experience, to be honest === zenrox [n=zenrox@pool-71-120-239-162.spknwa.dsl-w.verizon.net] has joined #ubuntu-motu [01:39] Q-FUNK: where is said team? [01:39] and I am still at work :( === doko_ [n=doko@dslb-088-073-107-220.pools.arcor-ip.net] has joined #ubuntu-motu [01:40] got 2 mnore full DVDs to go and then ~1.4GB on the last one [01:40] Q-FUNK: to be fair, most of the bugs reported are fixed in edgy [01:41] they're actually DVD isos of my Ubuntu mirror so I have all the software available when I upgrade the server tomorrowa [01:41] have to rebuild the sangoma card driver for the T1 so I'll be offline [01:41] geser: still there ? [01:41] should've made a deb package for it [01:41] Q-FUNK: but as dapper claims to emphasize on l10n, and is going to be supported for 5 years... [01:41] AnAnt: yes [01:41] ping geser [01:42] geser: k, I think I fixed it [01:43] minghua: who cares about l10n on a server anyway? :-) [01:43] geser: so I will upload nspluginwrapper [01:44] will try a rebuild as soon as it's there [01:44] Nafallo: true, but still, dapper is current up-to-date stable, and we released 6.06.2, but things didn't improve (although bugs were reported before that) [01:45] Nafallo: I admit I was exaggerating [01:45] bah, this DVD burner is slow...won't go any faster than 2x [01:45] geser: is linux32 used to run 32-bit apps on 64-bit Ubuntu ? [01:45] what? have there been another milestone released? [01:45] ping minghua [01:45] ping Mithrandir [01:45] or 6.06.1? sorry I don't know for sure [01:45] minghua: sorry, wrong tab completion ! [01:45] AnAnt: http://www.debian.org/doc/manuals/reference/ch-system.en.html#s-maintscripts (for preinst and postinst) [01:46] geser: thanks, [01:46] Nafallo: and actually when I think about it, maybe there are people care about l10n on server [01:46] minghua: ah, 6.06.1 indeed :-). I only run that on servers anyway, so I won't really know. [01:47] AnAnt: linux32 is used to give the kernel a 32bit personality [01:47] minghua: oh, right! l10n != i18n. [01:47] geser: meaning ? [01:47] e.g. uname -m returns x86_64 but linux32 uname -m return i686 [01:47] meaning it tells the app "hey you are running on a 32-bit box, act accordingly" [01:47] you can run 32bit apps without linux32, you only need 32bit libs [01:47] Nafallo: what about those accounting dept. in China? they need a stable system for the payroll system and they need inputting Chinese names [01:47] minghua: https://launchpad.net/people/desktop-bugs [01:48] how can I know the name of the architecture I am on ? [01:49] I see that there is dpkg-architecture [01:49] dpkg-architecture [01:49] Q-FUNK: you mean l10n and i18n team? [01:49] minghua: yea, that's i18n. I don't really know that, since I'm from Sweden and we have quite working both i18n and l10n. [01:49] tseng: there are many, outputs, which should I use ? [01:49] you can also parse uname -a [01:49] or uname -m :-) [01:50] BUILD_ARCH, HOST_ARCH, HOST_ARCH_CPU , which ? [01:51] Nafallo: yeah, I hear sweden has good l10n. you weird people having two scripts for one language :-) [01:51] hehe, do we? :-) [01:51] minghua: that's the only group I foudn that could remotely be interested [01:51] was I wrong?... [01:51] AnAnt: what do you want to archieve? [01:52] i18n has UTF-8, iso-8859-1 and iso-8859-15. if that's what you mean with scripts :-) [01:52] Q-FUNK: yeah, thanks. but I don't think it's really proper to bother all of them. and I am busy anyway [01:52] minghua: I'm affraid that you were right. wanna start a team called i18n and another called input-methods? ;) [01:52] geser: ok, I need to do a symlink in postinst [01:53] Q-FUNK: there is a developer (MOTU) working on the input methods in ubuntu, but one person is probably not enough [01:53] Q-FUNK: maybe not yet... [01:53] minghua: create a team with him. generate momentum. [01:53] geser: but it seems that the file I need to symlink to is in /usr/lib/nspluginwrapper//FILE [01:53] Q-FUNK: unfortunately we don't have a very good relationship [01:53] ah :( [01:54] minghua: blog about it? [01:54] I thought his pushing input methods into dapper was pre-mature, and obviously he doesn't agree [01:55] minghua: if all it takes is merging a few simple fixes, surely bloging about it on planet ubuntu will wake someone up to merge them? [01:55] Q-FUNK: Hmm, tempting. But I am not aggregated in any planet. And the problem is much smaller in edgy anyway [01:55] minghua: any other chinese ubuntu developer on the planet? if not, might as well jump in. :) [01:56] AnAnt: most likely DEB_HOST_GNU_CPU or DEB_HOST_ARCH_CPU [01:56] Q-FUNK: I don't really know the policy for dapper-updates [01:56] Q-FUNK: and my focus is on Debian currently (as etch release is close) [01:57] minghua: it's not that importnat. blog something as simple as "I made a simple patch to harmonize the input methods on gnome and kde. it's already in debian. could someone be so kind as to merge in ubuntu?" [01:57] geser: what's the difference between the X & X_CPU [01:57] ? [01:57] Q-FUNK: not as far as I know (Chinese developer on planet) [01:58] Q-FUNK: sorry for being unclear. The settings are ubuntu-specific, Debian is now doing it in etch, but in different way [01:58] ah [01:59] well, almost the same message, still. [01:59] it could work :) [01:59] Q-FUNK: and these two ways are probably also where I and the other Ubuntu input method developer have different opinions [01:59] oh. [02:00] my time is limited, so for now I'll concentrate on debian etch === Amaranth [n=travis@ubuntu/member/amaranth] has joined #ubuntu-motu [02:00] ok [02:00] hopefully edgy will work [02:00] maybe post edgy, I'll write something (hopefully by then etch will have a working example to illustrate my points) [02:01] Q-FUNK: edgy works much better than dapper, for sure [02:01] although edgy release is before etch [02:01] AnAnt: sorry, I don't know [02:01] yeah, let's just hope etch is before edgy+1 ;-) === AnAnt_ [n=anant@62.139.225.205] has joined #ubuntu-motu [02:01] geser: sorry, I was d/c [02:02] minghua: well, hopefully something good will come up. here, I count myself lucky enough that I only need UTF-8 and 2 keyboard maps. === AnAnt_ is now known as AnAnt [02:02]