[00:09] pitti, ping? === chuck_ is now known as zul [00:17] NCommander: If pitti isn't sleeping, I'd be suprised. [00:17] ah, right === emgent_ is now known as emgent [00:29] * Hobbsee wonders what the current 'central time' is. [00:30] CET is 1:30am [00:31] (in EST :)) [00:31] Hobbsee, CST is 18:31 [00:32] hmm, what I just said doesn't make any sense ... [00:32] % TZ=US/Central date [00:32] Thu Jan 22 18:32:19 CST 2009 [00:33] $ TZ=CEST date [00:33] Fri Jan 23 00:32:51 UTC 2009 [00:34] slangasek: isn't CEST Central Europe Summer Time ? making it non-existent at this time of the year ? [00:35] maybe :) [00:35] that might explain why it shows an hour earlier than if I type 'CET' [00:35] probably explains why the TZ in your date's output is UTC and not CEST as it should have been if the timezone existed [00:35] well, that's simply because /usr/share/zoneinfo/CEST doesn't exist. :) [00:36] Yeah, date has a "feature" if the timezone doesn't exist, then it must be UTC [00:39] hrm, OK, thanks. [00:40] 2am meeting. damn. [00:40] OpenWeek isn't so friendly for the Australian timezones this time around [00:41] nah, release team meetings [00:41] and what do you mean *this* time around? They're not friendly *any* time around. [00:41] I was trying to remember ... [00:41] * StevenK mumbles something about caffeine [00:41] they always start at 1600 utc or so. [00:42] heh, caffeine. If only that would work in this house... ;) [01:16] Hi, I am one of the developers of a programme which is as a package in Ubuntu The package you have is ancient. It is very frustrating for us as we get constantly bug reports for ancient stuff from ubuntu users,. The maintainer listed does not respond to our emails. What is the mechanism to get him/her removed and replaced by someone from us? [01:17] we generally maintain packages as a group in Ubuntu rather than having individual maintainers. You may be seeing the Debian maintainer listed. [01:18] refdoc: what is the package? do we inherit it from debian? [01:18] So what shall we do? [01:18] is there an Ubuntu bug filed about this? [01:18] Gnomesword, libswrod diatheke [01:18] yes [01:18] multiple [01:18] I think you inherit from debian [01:19] as we do with the vast majority of our packages, yes [01:19] refdoc: has a bug in debian been filed yet? [01:19] one of our guys maintains for years now his own repository [01:19] not sure [01:19] never looked yet [01:19] refdoc: ok [01:19] but people say even there they complain [01:19] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463207 [01:19] Debian bug 463207 in gnomesword "gnomesword: new version available" [Wishlist,Open] [01:19] Debian is frozen for release at the moment, of course [01:20] Is it now always frozen? :-) [01:20] no. :-P (Note that many people in this channel work on Debian too.) [01:20] refdoc: no it was not frozen when that bug was filed [01:20] Sorry that was an attempt at a joke [01:20] so, what shall we do [01:21] it would probably be fine for us to update, but it needs an enthusiastic Ubuntu developer to step up and do it. mail ubuntu-motu@lists.ubuntu.com which is a good place for that kind of thing [01:21] one of us maingtains his own packages for years [01:21] they are good and work immediately fine on clean installs [01:21] ok I will email there [01:21] thanks [01:21] no offence to your developer but we do always like to make sure of things ourselves :-) [01:22] sometimes people who work on the distribution have a better idea of what needs to be got right in certain areas, so it's always worth having a distro expert look it over [01:22] Aye, no problem, but your packages are now two years out of date in this particular case [01:22] refdoc: if you don't get any hits from there after a week or so you can email me ccheney@ubuntu.com and i'll try to take a look at it (i'm pretty busy most of the time though) [01:22] not saying that's why the package is still at an old version - that's almost certainly because Daniel Glassey ran out of time [01:23] great calc! [01:23] I can maybe ask around in debian-uk and find out if he's still active [01:23] i'm sure my father in law would like to run that program and an up to date version would be good ;-) [01:23] i'm supposed to be finishing up his system as soon as i get some spare time [01:24] we are moving to 3.0 release, the version you have is 2.1 or 2.2 [01:24] ok thanks a lot to everyone! [01:26] cjwatson: ISTR he was presumed MIA except that he appeared in person at DebConf 7... [01:27] he came to debconf but doesn't actually update his packages, weird :-\ [01:35] hello i have the problem with ubuntu 8.10 and intel 945GM [01:35] GL_RENDERER = Software Rasterizer [01:35] GL_VERSION = 2.1 Mesa 7.2 [01:35] GL_VENDOR = Mesa Project [01:36] i found a lot of posts and bug reports for ubuntu but nobody knows a solution [01:38] the only solution is to wait for jaunty but i can not update my stable installation [01:39] mybe some knows anything on this problem [01:40] one of the bug reports https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094 [01:40] Launchpad bug 252094 in xserver-xorg-video-intel "[i965, etc.] Poor graphics performance on Intel" [Wishlist,In progress] [01:41] slangasek: so, apparently Debian has *finally* fixed the grub/xfs problems, and there's a decent chance that we can switch it on again in grub-installer at long last [01:42] slangasek: how hard would a merge be? :-) [01:42] oh, really? [01:42] a merge of which package? [01:42] grub [01:42] grub? [01:43] turned out that (a) the kernel was fixed upstream in around .19/.20 to arrange that xfs_freeze -f doesn't return until I/O is complete (b) grub was doing xfs_freeze -f; write to filesystem; xfs_freeze -u which was completely broken, and xfs_freeze -f; xfs_freeze -u; write to filesystem actually works now that the kernel has been fixed [01:43] or at least so I gather from a while reading Debian #239111 [01:43] Debian bug 239111 in grub "Install report: Successful install" [Unknown,Closed] http://bugs.debian.org/239111 [01:43] very hard, the repo is bollocked right now because of a bzr-svn bug :( [01:43] i just noticed that in intrepid there is a im status icon on the right side, why is it there when the same thing is in the tray? [01:43] heh, what a title [01:43] * jelmer wakes up [01:43] * calc hadn't done a full reinstall in a while [01:43] slangasek: yeah, I didn't expect it to be a straightforward bzr merge [01:43] maybe we can just backport that patch, not sure [01:44] is the other im icon not visible enough or something? [01:44] it was only in xfs_freeze.patch, really [01:44] cjwatson: well it was meant to be, that's why I put it in bzr! :) [01:44] yeah, but I knew about the bzr-svn problems [01:44] jelmer: any progress on that bug which I will refer to with hand-waving because I don't have the number in front of me? [01:45] hrm, it's not in my subscribed bugs list [01:45] slangasek: maybe; I did fix one bug (for which I had a test case) related to pushing of unrelated merged trees, but there's another issue still remaining [01:45] maybe it got fixed and I wasn't watching [01:46] slangasek, If you created the combined branch by merging the debian directory into the grub directory, it does not work yet - if you did it the other way around (keeping the tree root from the debian packaging directory), it should work. [01:47] ok, then it's going to not work [01:47] the bug # is 295416, btw [01:47] slangasek: (and fjp just confirmed that grub/xfs now works on a system where he could previously reproduce the bug, if you're watching #debian-boot) [01:48] jelmer: ah, new bug number that I hadn't seen before :) [01:48] er, except I'm subscribed so apparently I have [01:49] cjwatson: a one-time manual cherry pick, then? [01:50] calc: there are some threads about that on the desktop list, no urls handy though [01:51] slangasek: yeah, I think so [01:51] calc: i believe that the idea is to make the fusa conrol global status for im ect eventually [01:52] sounds doom-laden otherwise [02:10] asomething: doesn [02:10] asomething: doesn't sound particularly useful since the IM app is already in the tray [02:10] re hi i think i found the problem Virtual 2560 1888 without them all works fine [02:10] asomething: perhaps more gnome crack? :) [02:11] asomething: and the im app (pidgin or telepathy) is already essentially global setting anyway [02:12] * calc has 5 or 6 im protocols running in pidgin and only has one status setting for them [02:19] calc: I think it's an Ubuntu patch http://www.markshuttleworth.com/archives/233 [02:22] asomething: yes, but ubuntu gnome crack ;-) [02:23] calc: don't you mean innovation? ;-) [02:24] asomething: useless innovation, unless something hasn't been hooked up properly and is just buggy [02:25] i have within 3in of the corner a second IM status icon [02:25] that actually does what it is supposed to... control the IM program [02:25] the screenshot you posted apparently has no running IM client, or something else weird [02:25] its not in the tray [02:26] tedg: ping [02:33] * calc thinks he will just delete it [02:33] yea that works better :) [02:38] better than what? [02:41] slangasek: better than a lot of wasted corner screen real estate [02:41] * calc now has the calendar there which he uses much more often than a duplicated IM status widget [02:42] oh? I still have plenty of real estate to spare on my toolbar, so. :) [02:44] i never use fusa and don't need a duplicate im applet so it was completely useless [02:46] * calc wishes someone would fix the clock applet to have radar map support, then i could throw out gweather [03:44] dtchen: I'd be interested in your thoughts re bug 235007, since a quirk already exists for this in upstream alsa, and users are reporting 3stack as a better option... [03:44] Launchpad bug 235007 in linux "no sound on Toshiba L40-139" [Medium,Triaged] https://launchpad.net/bugs/235007 === hyperair is now known as Guest29546 [04:41] hey cjwatson [05:10] hey RAOF [05:10] Howbidie. [05:10] RAOF: you ever get compiz++ working? [05:10] the snap port is fixed now [05:11] For values of "working" equal to "able to move windows without decoration", yes. [05:12] well that's creepy to see, snap only stops the window from moving, not the decoration [05:13] onestone must not have noticed (he fixed it) because he uses kde-window-decorator which does reparenting [05:13] Nifty. [05:13] RAOF: Just build libcompizconfig and compizconfig-python so you can use the ccp plugin and ccsm [05:13] Both from compiz++ branch, I take it. [05:13] I have a feeling you're missing a plugin dependency there or something [05:13] right [05:13] Probably. [05:13] and make sure you set PYTHONPATH to point to the compiz++ version when you run ccsm [05:14] Or just install it systemwide! [05:14] I'm about to, it's usable now [05:15] I might get myself a working GL stack and give it another whirl then. [05:15] * RAOF wishes nvidia was as fast as nouveau. [05:15] RAOF: If you use kde-window-decorator you just need good RenderAccel and Composite :) [05:16] Well, I've got me _that_. [05:16] Although I dunno if even the minimize plugin works without opengl [05:16] but move, resize, and snap should work :) [05:17] Actually with Composite you can use gtk-window-decorator, kwd is only needed if you don't want to use Composite [05:17] onestone is apparently working on a plugin to handle viewport changes that will work without composite and then other plugins (wall, cube) can plug into it to provide composited and opengl effects to switching [05:19] Wouldn't that require you to not unmap the windows on viewport change? How does that fly with lack of composite? [05:20] eh? they just go offscreen like they do now [05:21] viewports were not designed with composited desktops in mind [05:22] Hm. There appears to be a compiz++ branch of only libcompizconfig. [05:24] RAOF: oh, right, you just have to build the python bindings against that one [05:24] the ABI changed, not the API [05:26] Hm. How much do I care about protobufs? [05:28] I haven't done any benchmarks but if compiz++ gains support for it that should solve most of our startup time problems [05:28] not much, I guess [05:28] I built it because it was cool though :) [05:29] Hurrah for name mangling! That configure.ac check is a thing of beauty. :l [05:37] good morning [05:38] Hey dholbach . [05:38] dholbach: Re sound volume profiles, its not possible afaik. [05:39] hi TheMuso [05:39] TheMuso: that's fine, alsactl will do what I want to do :) [05:39] dholbach: I thought as much, but I don't know of a GUI equivalent. [05:40] ah OK [05:40] thanks TheMuso [05:40] np [05:44] bluesmoke: So, that kind of works. Still no decoration, though ;) [05:45] RAOF: You've got the plugin loaded and you're running the right gtk-window-decorator? [05:45] RAOF: Perhaps try kde-window-decorator [05:48] Oh, yeah. There we go. [05:48] bluesmoke: Hm. Doesn't actually seem that composite's working. [05:49] * bluesmoke blames your driver [05:49] apparently intel, fglrx, ati, and nvidia work fine [05:52] This has been tested with Composite !OpenGL? [05:56] RAOF: I think I screwed up and loaded that combo once, yes :P [05:56] kde4-window-decorator works, but there 'aint no composite. [05:57] ok, i see what you mean [05:57] Apparently Composite doesn't have an XRender internal system, dunno how I missed that [05:58] RAOF: Hey, you need a fun project? :) [05:58] * RAOF is fairly sure his definition of "fun" does not accomodate adding an XRender backend to compiz. [05:58] But I'll put it on the list, right after "Learn Portugese" :P [06:04] RAOF: Looks pretty straightforward, really [06:04] If you know XRender, anyway [06:04] The composite plugin handles basically everything, you just have to hook into it and draw stuff [06:18] bug 320351 (new gnome crack of the day) [06:19] Launchpad bug 320351 in gnome-applets "gweather: city options were radically reduced to uselessness" [High,Confirmed] https://launchpad.net/bugs/320351 [06:20] * calc should start a blog so he can have a gnome crack of the day meme on it ;-) [06:20] * calc digs in svn to see if there is a reason why they did this [06:21] * ScottK thought reduced options were a Gnome feature? [06:22] lol [06:22] because all cities are small enough the weather is the same everywhere :) [06:23] i found the commit i think [06:23] rev 518 of libgweather [06:23] Don't worry about sub-city locations; people generally aren't going to know which of the locations is closest to them, and the weather reports from all of them should be basically the same anyway. [06:23] bahaha, yea this is true of a city that is 4000 sq km [06:32] calc, ick [06:41] generally cities only have one weather station if any at all unless they are very large cities, in which case the weather is likely not to be the same [06:42] houston is somewhere in the range of 4000 sq km and has 6 stations (maybe more?) and now they don't even tell you which one it is much less let you choose which one to use [06:43] hi ! i've been reading the "contribute" pages of Ubuntu's web site and i was wondering if there is any task managment platform for ubuntero ? [06:43] some of the stations listed as 'houston' aren't really houston but are in the houston metro area so get grouped that way [06:43] strictly speaking houston city limits aren't that big but the stations listed for houston are in the huge area [06:49] any task repatition platform for a devoted want-to-contribute ? :) [06:50] mininat: welcome! could you explain what you're looking for specifically? [06:51] i've checked the contributes pages on the main site, developemnt team [06:51] i checked the first stage, called "ubuntero" [06:51] but seems there is no task list or any specific project [06:51] and i'm looking for one to start contributing [06:52] see what i can do etc etc [06:52] ah, most tasks are in launchpad.net [06:52] mininat: what sorts of tasks in particular are you looking for? [06:53] bbiab [06:54] i like hacking my computer, i mean, read docs, looking solutions, scripts things [06:54] and as i want to go more deep in programming stuff [06:54] contributing to my system community should be a cool starting point [06:56] https://launchpad.net/ubuntu/+mentoring [06:56] that would be a good wau to start according to you ? === hyperair_ is now known as hyperair [07:22] [0123 09h27.42] real_name = Colin Alston [07:23] sorry about that [08:36] StevenK, NCommander: sorry, was away doing some login time measurements, took a while [08:36] !ping | NCommander [08:36] NCommander: ping yourself ;-) really the diodes all down my left side are sore [08:36] erm [08:37] I meant to say "Please do not send contentless pings, just ask" :) === hyper914 is now known as hyper53 === hyper53 is now known as hyper425 === hyper425 is now known as hyper512 === hyper512 is now known as hyper901 === hyper901 is now known as hyper466 === hyper466 is now known as hyper105 === hyper105 is now known as hyper392 === hyper392 is now known as hyperair === jcm is now known as jonmasters [09:17] primes2h: hi [09:17] pitti: Hello. [09:17] primes2h: thanks for working on this [09:17] primes2h: some comments: [09:17] pitti: I have the new correct debdiff [09:18] Did you get? [09:18] - package should drop the old *.icon files, since they are autogenerated now; the Makefile.am's clean rule should do that [09:18] - changelog should just say "renamed *.icon to *.icon.in and marked description as translatable" or so, instead of putting that long redundant list of new files [09:20] In fact I made .icon.in from scratch. [09:20] there were no .icon file before. [09:21] you mean this? CLEANFILES = $(icons_in_DATA) [09:21] primes2h: well, there certainly must have been a place before where the C strings came from? [09:21] are they in the .svg files? [09:22] .icon file are created during build and then are cleaned [09:22] primes2h: it seems wrong to maintain a separate set of files, since that would duplicate the original strings [09:22] hm, I don't know how emblem translations work [09:22] gnome-icon-theme doesn't ship *.icon files either [09:23] Exactly. [09:23] I got that example. [09:23] as example [09:23] strings are taken from icon.in files that I created. [09:24] I mean, it uses icon.in to create .icon files... [09:25] strings are probably taken from them, [09:25] and finally .icon file are removed. [09:26] This is how gnome-icon-theme (and human-icon-theme) works (I'm quite sure) [09:26] primes2h: so where did the English strings for the emblems came from before? [09:26] from the name of the icon.. emblems-important.svg etc... [09:27] In fact the name was not in Capital letter. [09:27] <_max> dono if this is a bug or not, if i boot 8.10 x86 livecd, i can make changes to /etc/network/interfaces, add /etc/resolv.conf etc, and they are "kept" after actual installation. [09:27] <_max> however my /etc/apt/apt.conf was discarded. [09:27] have a look at Edit -> Backgrounds and emblems -> emblems [09:28] I guess this... but it's the more probable explanation... [09:30] I learnt this looking at gnome-icon-them [09:30] primes2h: "Edit" where? [09:34] primes2h: so whether it's from the file name or a field in the .svg file, I think the pot should be created from that one instead of a separately maintained .icon.in file [09:35] otherwise you'd always have to make the same change in two different places [09:36] pitti, I have answered your question to bug 308817 [09:36] Launchpad bug 308817 in ghostscript "duplex printing through CUPS no longer works" [Undecided,Fix released] https://launchpad.net/bugs/308817 [09:37] pitti: Edit in nautilus [09:37] pitti: hold on, I'm on the phone. [09:39] tkamppeter: thanks [09:40] pitti, then I think you can pass through the 3 -proposed packages, cups, ghostscript, and foomatic-filters [09:53] those .a files in the dev packages use .so files. right? [09:53] you link blah.a to your program and program uses blah.a [09:53] blah.so [09:56] epicgoo: no, .a files and .so files are two different things; and this is not really the channel for learning how the linker works [09:56] pitti: did you try to talk to dobey? he's on #ubuntu-desktop and he's the upstream icon naming specification maintainer and working on gnome-icon-theme, he likely knows about those things [09:57] I know... [09:57] they are different so? [09:57] I am talking about the dev packages in ubuntu [09:58] if you link a blah.a lib to your program (from libblah-dev), will the program use blah.so? [09:59] or those .a files are just static libs [09:59] a .a file is a static lib, yes. [09:59] with the exception of libc.a, which is a linker script for arcane reasons [09:59] but your program may or may not need the .so file [10:02] Not sure what you're meaning to ask. If your program is statically linked against a library, it doesn't need a shared copy of that library. [10:05] http://en.wikipedia.org/wiki/Library_(computing)#Naming [10:05] linux =/= windows [10:15] pitti: icon.in files it's the way gnome-icon-theme works... [10:16] pitti: and I think is the best way because it's more flexible... [10:17] You can choose the best text to explain the icon purpose. [10:18] It's not necessarily the same as icon-name [10:19] e.g emblem-CVS-controlled.svg you can choose "CVS controlled" [10:19] and you can use capital letter [10:19] that it's missing in icon-name. [10:22] that is [10:25] pitti: In fact if you look at gnome-icon-theme changelog you see that this kind of patch was made on 2004 to add emblem translation... [10:32] pitti: By the way I found out another emblem untranslated (emblem-desktop) in 48x48/emblems/ 16x16/emblems/ and 24x24/emblems/ [10:32] I need to add it in the patch. === asac_ is now known as asac [10:38] pitti: You need icon.in files because POTFILES needs to know where to pick up strings for po files... [10:38] primes2h: right, but those could be autogenerated from the actual source, like the file names or svg header? [10:39] No, that's the problem! [10:40] because now what you see on emblem name in the GUI is a sort of fallback because it's not set up for translation [10:41] Or better, I don't know but I think it's more complicated... [10:41] POTFILES doesn't work this way. [10:42] have a look on POTFILES.in [10:42] in [10:48] primes2h: re (sorry, we have the plumber here) [10:49] pitti: no problem :-) [10:49] primes2h: what I meant is: autogenerate .icon.in from the original source, then use the inltool magic to create the .pot, and throw away the .icon.in/.icon again [10:52] Ah, ok. It probably can be done adding code I think, but it could be a problem if, for some reason, you need to change strings name, in that case you should change .svg name [10:52] and it's worse [10:53] .icon.in files are present in gnome-icon-theme source [10:53] one for each svg [10:55] and moreover you should change linkname on each file where svg files are mentioned. [10:55] primes2h: that's exactly what I was heading to; if you change the .svg's name, you have to remember changing the .icon.in [10:56] .icon.in is derived information, it shouldn't be something that has to explicitly be maintained? [11:01] Following gnome-icon-theme changelog, you have to manage .icon.in manually (adding, removing, changing) and the correspondent Makefile.am [11:01] hmm [11:02] They are needed to mantain separated code from translation things... [11:02] To keep all clearer... [11:03] primes2h: but if the .icon.in file is the definitive place for the strings, then they would need to be shipped in the gnome-icon-theme package? [11:03] In fact they are. [11:04] :-) [11:04] Have a look at the source... [11:04] ah, I see [11:05] and of course again with statically replicated translations [11:05] those spread faster than we can squash them *sigh* [11:07] :-) [11:14] hi === mib_p8yxoe6r is now known as shankhs [11:14] pitti: In fact they are not replicated, because some strings in .icon.in are different from the svg-name (e.g. emblem-important.svg -> Important (with capital letter in .icon.in), and emblem-cvs-added.svg -> CVS added (in .icon.in)) [11:15] primes2h: ok, I see now [11:15] primes2h: so, that looks fine then [11:16] primes2h: mind to attach the current debdiff to the bug and subscribe me? I'll review/sponsor it [11:17] Ok, I just need to add emblem-desktop in 48x48(24x24,16x16)/emblems that I forgot to set up [11:17] Thank you! and what about changelog? [11:18] Do you think it's too long with all icon.in files? [11:19] In my opinion it's needed to keep trace of changing... [11:20] pitti: What do you think? [11:21] primes2h: you could just say "Added *.icon.in: Explanation..." [11:21] pitti: ok! Other changes? [11:23] primes2h: should be alright; I'll give it another review once it's attached to the bug [11:23] primes2h: thanks for bearing with me and explaining everything [11:23] That's nice, thank you very much for all. [11:24] pitti: Just one last thing... [11:26] This patch expose also another bug already present in human-icon-theme, that kwwii told you yesterday... [11:26] pitti: bug #319991 [11:26] Launchpad bug 319991 in human-icon-theme "Strange behaviour of some emblem icons." [Undecided,New] https://launchpad.net/bugs/319991 [11:27] pitti: just to remaind you... :-) [11:29] primes2h: let me ask Ken [11:30] primes2h: ah, I guess I know [11:30] it should be named stock-mail, not stock_mail [11:33] pitti: ask Ken, I am puzzled because the icon doesn't exist and I don't know where it looks for the name... [11:34] pitti: I go away for lunch, see you later... === lan3y is now known as Laney [12:13] hi [12:17] how to use autoconf and automake to change the configuration file of an existing project? [12:19] Please give alink so that I can read and know the use of autoconf and automake [12:20] the autoconf-doc and automake packages include extensive info documentation for those tools; 'info autoconf', 'info automake' [12:20] cjwatson: thanx [12:21] the autoconf documentation is also in /usr/share/doc/autoconf-doc/autoconf.html if you prefer that [12:21] the automake documentation is only installed as info, but is available online as HTML in http://www.gnu.org/software/automake/manual/automake.html [12:22] cjwatson: do the change in configure.in file needs automake( it needs autoconf).. [12:22] cjwatson: thanx for the valuable links [12:23] mib_730riq17: that depends on the project. Some do, some don't [12:23] mib_730riq17: you should generally use autoreconf rather than running the individual tools [12:25] cjwatson: autoreconf thats a new tool I heard now???Is it installed along with autoconf? === _steron is now known as steron [12:26] cjwatson: I will try both the ways so that I learn all of the processes , thanx for all the info... [12:26] mib_730riq17: autoreconf is in the autoconf package, and has been around for a long time [12:27] it's documented in the autoconf documentation [12:27] cjwatson: OK [12:28] cjwatson: what are the general precaution should I take to edit the configure.in file of an existing project so that it does not damage the app or the process of installation of app... [12:31] I would personally recommend keeping files in revision control so that you can easily check the diffs produced (e.g. bzr diff) and test extensively [12:31] if you're using different versions of the autotools from those used to generate the previous files you have in hand, then the diff may be very large, and you may need to make changes simply to get it to work at all [12:32] with poorly-written configure.in files it can be quite a difficult exercise to modify them at all, I'm afraid [12:32] and you typically end up learning rather more about the autotools than you expected :-) [12:32] the fact that it's called configure.in at all (rather than the modern name, configure.ac) is not a good sign to begin with [12:39] cjwatson: actually I have the task to update the configure.in so I have to take all the pain [12:40] cjwatson: anyways if you are new to something its always adventurous to learn... [12:42] cjwatson: what are difs , revision control and all those stuffs ??? do u have a link to the tutorial explaining all those stuffs.. [12:42] mib_730riq17: you can google for "revision control" as a first step and read e.g. the Wikipedia article on the subject [12:43] mib_730riq17: the 'bzr' tool I referred to is http://bazaar-vcs.org/ and there are several general tutorials on that site [12:48] cjwatson: it seems that bzr has a bug that it does not support proxy with authentication so i think i have limited use of bzr :( [12:50] mib_730riq17: #bzr may be able to help you check whether this is something you can work around [12:50] there were some old bugs about this but I thought they had been fixed [12:52] cjwatson: i tried #bzr but they confirmed that this bug has no way around and this is not going to be fixed in coming future.This was pretty rude I hope that I can help them but I dont have enough knowledge to do so :( [12:52] I don't think it's rude for developers to be honest about their roadmap! [12:55] cjwatson: after being into 1 or 2 developing projects i agree with u... [12:56] cjwatson: can I get help from here if i am stuck during revision or i have to go to some other channel? [12:56] this is really not the best channel; I would recommend you look elsewhere [13:03] cjwatson: like...do u have any ideas? [13:04] mib_730riq17: no, it depends on the problem you are having; please be creative :-) [13:10] cjwatson: OK thanx for ur valuable time...:) bye [14:07] mvo: hi there, are you around? [14:19] * pitti squashes his first pet bug [14:19] \o/ [14:20] cjwatson: fyi-- I really liked HardyReleaseNotes/ChangeSummary/8.04.2. I hadn't seen that for previous point releases and think it is a great idea. [14:20] slangasek: ^ that's a CD space present for you (bug 123025) [14:20] Launchpad bug 123025 in gconf2 "stop shipping static gconf translations, use gettext at runtime" [Wishlist,Fix committed] https://launchpad.net/bugs/123025 [14:21] jdstrand: glad you liked it, it was a lot of work :) [14:21] pitti: How much space does that buy us? [14:22] soren: once all the GNOME packages are rebuilt, in the order of 100 MB uncompressed and 10 MB compressed [14:22] Whee! [14:22] well, that is, 10 MB on desktops (which has the pregenerated /var/lib/gconf/defaults/) [14:23] on the alternates, where that tree is generated at runtime, I guess more like 5 MB [14:23] but still not to be sneezed at [14:23] Certainly not. [14:28] hey soren: are you well again? === azeem_ is now known as azeem [14:29]