=== Mez|OnAir is now known as Mez [00:01] RAOF: Maybe, but sort the remainder normally, but always before the precedent (but not before anything that would otherwise sort before the precedent) isn't as obvious to some people as it perhaps is to you. [00:04] Or maybe I use an imprecise but useful rule of thumb of "anything after & including the ~ is less than any other string, including nothing". [00:05] RAOF: That could be it, but I'm still not sure "less than nothing" is obvious to non-mathematicians (where "mathematicians" includes lightly dabbling amateurs) [00:05] * Fujitsu goes by '~' < '', which is I believe the proper rule. [00:06] Fujitsu: Yes, it is. [00:21] yes, I think its bed time [00:21] g'night all [00:28] evening [00:39] StevenK: your blog is fired. [01:10] how do I invoke a shell and run a command before "make build" in a CDBS+autotools.mk package? (this is the debian/rules: http://pastebin.ca/811562). I've tried "makebuilddir/packagename::" but it does not work :-/ [01:14] pwnguin: I don't have a blog. [01:14] but you should [01:15] so you can get ponies [01:17] fired ponies? [01:17] blogs are overrated [01:18] zul: really? they are email 2.0 [01:18] ;-) [01:18] meh [01:18] since when? ;) [01:19] pgquiles: First, stop using CDBS ;-P [01:20] zul: since like Y2k or something [01:21] bddebian: annoying, I know. I didn't package it in the first place and I'd like to build a CVS version of the software but CVS version require to run command in a shell before ./configure is invoked :-/ [01:21] pgquiles: you could just run that command manually and add the outcome in the .diff.g [01:22] z [01:22] azeem: no, because there are symlinks [01:23] like? [01:23] pgquiles: put it in a makebuilddir/foo:: rule. This runs between unpack and configure: [01:24] persia: it's not executed, I don't know why [01:24] persia: He said he tried that and it didn't work [01:24] azeem: like install-sh -> /usr/share/automake-1.9/install-sh [01:24] pgquiles: are you running autoreconf? [01:24] Bah, that's dumb [01:24] or autogen.sh or something [01:24] azeem: autogen.sh, yes [01:24] there's an option to force a copy instead of a symlink [01:25] pgquiles: you might have to change the auto* invocations inside autogen.sh then [01:25] if it's not just running autoreconf anyway [01:25] azeem: I've tried AUTO_UPDATE_ACLOCAL, etc but it fails because of not included .m4 but I don't know how to pass parameters to ACLOCAL with AUTO_UPDATE [01:25] isn't AUTO_UPDATE_ACLOCAL deprecated [01:26] azeem: what do you mean with "you might have to change the auto* invocations inside autogen.sh then"? [01:26] pgquiles: what *is* inside autogen.sh? [01:27] I can't look into it for you [01:27] azeem: autopoint --force; shell libtoolize --copy --force; aclocal -I m4 -I gnulib/m4; shell autoheader; automake --add-missing; autoconf [01:27] huh, autopoint? [01:27] from gettext [01:27] ah [01:27] I need some help using dch [01:28] well, there's a bunch of programs being run starting with "auto", aren't there? [01:28] dch -U isn't adding a new release, just a new bulletpoint under my existing one [01:28] I've tried with the makebuilddir/foo:: and $(shell thecommands) but it didn't work [01:28] pgquiles: apparently your trouble is with automake, so see how to invoke automake to copy the missing files rather than generating symlinks [01:28] azeem: probably, but every single one I found already has ./configure in [01:29] pgquiles: [01:29] pgquiles: ...being run *by autogen.sh* [01:29] pgquiles: Ah, you're trying to generate the (autotools) buildsystem in debian/rules? [01:29] oh, never mind, got it :) [01:29] RAOF_: yes, that's it [01:29] pgquiles: That's generally not a fun thing to do. [01:29] if you use CDBS [01:30] that's the problem, CDBS [01:30] my debian/rules usually are only bash scripts which allow me to do everything I want [01:30] :-/ [01:30] * persia is certain makebuilddir:: is the solution, and would like to see a build log [01:30] pgquiles: in any case "didn't work" isn't enough information [01:30] pgquiles: bash scripts? [01:30] pgquiles: debian/rules isn't a bash script! 1) it's not bash, 2) it's not shell [01:31] Ugh, I'm having another problem: (WARNING: Failed to sign .dsc and .changes file) [01:31] azeem: "didn't work" meaning it's not run. I guess the makebuilddir/foo:: rule I'm adding is queued after the existing rule with the same name. [01:31] cdm10: You need the identity on your GPG key to exactly match the identify in the last debian changelog entry. [01:31] It works fine when I build it the first time, but when I increment the version with dch and dpkg-buildpackage it again, it doesn't sign. [01:31] persia: oh, lemme doublecheck that... [01:31] pgquiles: where did you add it in debian/rules? [01:32] pgquiles: Just to make sure, you7re replacing "foo" with the name of your package, right? [01:32] azeem: I've tried at the beginning and at the end, but both fail [01:32] persia: yes :-) [01:32] persia: ha, it put in caleb@caleb-comp rather than my email address. [01:32] cdm10: :) [01:32] azeem: Location in debian/rules doesn't matter. make isn't sequential [01:33] Hm. Dear internet: stop sucking. [01:33] pgquiles: So, you presumably need to do the autogen stuff because you're packaging a development snapshot, right? [01:34] cdm10: putting DEBFULLNAME and DEBEMAIL in ~/.bashrc helps with that [01:34] RAOF__: exactly [01:34] LaserJock: thanks [01:58] gotcha! [01:59] I needed to add a debian/stamp-autotools-maintregen-arch:: cd $(DEB_BUILDDIR); sh ./autogen.sh to get makebuilddir/foo:: to work, holy shit [02:01] Very odd. For most packages, it seems to work without that (although perhaps it's related to autotools magic) [02:01] and configure and build are run twice :-? [02:01] autohell might be more accurate :-) [02:11] Hm. Now that telstra's finished poking around at the exchange, maybe the internet will stay up for a few minutes at a time... [02:11] pgquiles: Did you get your autotools working? [02:12] RAOF: yes, but I needed to add a weird rule [02:12] pgquiles: A better plan may have been to not do the autotools on build. Rather, autotoolise the original tarball. [02:25] StevenK: ah. ive mistaken you for steven kemp [02:25] who is on planet debian [02:25] 12 times [02:30] it's Steve Kemp IIRC === tonyy is now known as tonyyarusso === tonyy is now known as tonyyarusso [03:51] LaserJock: are you around? :D [03:52] sure am [03:52] have time for a pm ? :) [03:52] sure === asac_ is now known as asac [04:59] it's amazing how much compiling depends on hard drive speed [05:00] No it isn't, of course parts of it will be I/O bound. [05:01] hmm, I don't get why my laptop would be so slow then [05:02] my AMD 1800+ compiles I think around twice as fast as my Celeron 2.6GHz laptop [05:02] The Celeron has much less on-die cache [05:02] LaserJock: RAM size? Cache? [05:02] That's not one of those old celerons with *no* L2 cache? [05:03] It's late P4 if it's 2.6GHz [05:03] it's 2.8Ghz actually [05:03] AMD Athlon(tm) XP 1800+ cache size : 256 KB [05:04] Intel(R) Celeron(R) CPU 2.80GHz cache size : 128 KB [05:05] the AMD has 1GB of RAM and the Intel 512MB of RAM [05:06] Those two factors explain most of it. With more RAM you get pagecache advantages, and with more local cache, you've a higher chance of keeping the processor fed. [05:06] hmm [05:06] And what sort of code? If you go crazy with the templates it shouldn't be too hard to get g++ to thrash in 512mb. [05:06] that seems crazy to me [05:07] Especially if you've already loaded 200-300MB with a healthy bit of OS stuff. [05:07] it doesn't seem to be using up all the RAM most of the time [05:08] LaserJock: If you're not using all your RAM, your pagecache settings aren't agressive enough. [05:09] I seem to generally have 150-200MB of RAM free still [05:11] * RAOF 's laptop with 2GB of ram rarely uses < 95% of the ram [05:12] ? [05:12] My amd64 desktop is the same [05:12] - buffers/cache? [05:12] * persia takes ~2 hours to reach 2GB in pagecache [05:12] So unless that free ram count doesn't include the various caches, I'm not sure how you get 200MB unused ram. [05:12] oh, I thought you were talking about -buffers/cache [05:13] * TheMuso only has 1GB of ram in his P4, but only ever starts using swap if he is 1) using GNOME+Speech, and 2) is doing a lot of package building, particularly with big packages. [05:13] Oh, no. [05:13] I have 50-100MB free if I include cache [05:13] LaserJock: It's the buffers & cache that make it faster. Without loading the pagecache, you need to read the pages from disk again. For common operations, it's better to have the binaries, libraries, etc. already in RAM. [05:14] * persia notes that for package building, it's ideal to have enough ram for base system + base cache + simulated build environment + build space [05:14] persia: Yeah very true. [05:15] I"m not using pbuilder [05:15] just compiling some stuff from svn [05:15] LaserJock: In that case, you can probably get by with 2-3GB before you start dropping pages, either to swap or clean pages from the disk. [05:15] I just can't believe my laptop is so slow [05:17] LaserJock: It's your choice of benchmark. Compare the two systems when encoding video or something. [05:18] heh, like I ever do that [05:18] I need to find a test for that, it might be interesting [05:30] ... === imbrando1 is now known as imbrandon [05:32] that sucked [05:32] ice storm + internet + power brownouts == no love for imbrandon [05:32] bummer [05:32] yea ... [05:33] internet all day has sucked and it dont look like its getting better [05:33] ok, I just did a benchmark with the *small* app I'm building from source: [05:33] in the next 48 hours [05:33] AMD 1800+ [05:33] real 6m7.545s [05:33] user 5m13.436s [05:33] sys 0m36.406s [05:33] Celeron 2.8GHz [05:34] real 16m12.889s [05:34] user 12m19.662s [05:34] sys 0m57.780s [05:34] so even more than twice as slow :( [05:34] This is why we don't eat celery. [05:34] celerons are P4 though; they are borked by design :) [05:34] Heh. [05:34] Nice branchy compile code for the huge pipeline! [05:35] ok i have a small OT question to ask yall, since i love you all so much, i'm setting up a blog ( self hosted wordpress ) for my wife to get her away from myspace hehe, anyhow i dont have the $$ for a domain name so i'm gonna use a no-ip.com domain but i want something semi witty, ideas ? [05:35] lifeless: As long as your code guarantees it will never branch the P4s can be quite fast :P [05:35] so far we have liked *.isasecret.com *bounceme.net and ummm yea [05:35] imbrandon: why not wordpress.com [05:36] LaserJock: so i can install my custom rolled themes and plugins [05:36] imbrandon: how about imnotbrandon.com [05:36] lol [05:36] RAOF: yahuh. branch. Lets see. Thats what. IF ?!!!!! [05:36] LaserJock: hehe yea but i'm trying to work with the free no-ip domains here hehe [05:36] lifeless: You're smart. I'm sure you can write some useful program that has no conditionals :) [05:36] since i dont have the cash to reg a new domain right now [05:37] imbrandon: you can't do mrs.imbrandon.com ? :-) [05:37] ahh nice, lemme ask if she likes that [05:37] good idea [05:38] hrm nope ;( [05:38] slightly egotistically and selfcentered perhaps, but it's funny [05:38] heh thats what she said, just before "no" heh [05:38] RAOF: I can yes, problem is the software stack. 1) Fix the kernel. 2) Profit. [05:39] imbrandon: how about thepantswearer.imbrandon.com? [05:39] seems like all the good *.isasecret.com domains are taken , like life. love. [05:39] she dont want "brandon" [05:39] heh [05:39] stupid question, but, in debian/changelog, what's the field 'gutsy', 'hardy' etc. actually used for? [05:39] yeah ... I wouldn't either ;-) [05:39] and does apt ever care? [05:40] imbrandon: kernelbug.isasecret.com [05:40] mdomsch: the release its built and installed to [05:40] lol [05:40] and installed into... [05:40] apt dont, some buildd env's do [05:40] ah, that's the key - apt doesn't care [05:40] I think it's useful more on the developer end than the user end [05:41] basicly if its not built via soyuz or dak then it dont matter [05:41] mdomsch: Some of the archive acceptance tools use that to select the build and deployment environment. [05:41] so that's not my constantly-reinstalls-the-same-package bug [05:41] correct [05:41] mdomsch: ahhh [05:41] mdomsch: is that from a PPA? [05:41] LaserJock, no, linux.dell.com/repo/dists/cross-distro/dell-firmware/ [05:41] mdomsch: more likely a depend/confict/replace bug [05:42] perhaps [05:42] PPA has a known bug that makes packages with PreDepends or some similar fields to constantly reinstall [05:42] imbrandon, no conflict/replace [05:42] and depends looks like: [05:42] Depends: firmware-addon-dell (>= 0:1.1), firmware-tools (>= 0:1.1) [05:43] mdomsch: Do you have Provides: ? [05:43] which I think is sane [05:43] hrm, can you pastebin the control file ? [05:43] mdomsch: Why a epoch of 0? [05:43] epoch are evil hehe [05:43] http://pastebin.domsch.com/18 [05:44] re epoch: good question, it's unnecessary [05:44] those packages don't define epochs, so it's safe to remove [05:44] * persia suspects the epoch is stuck now, if the package is being distributed, as'0' > '' [05:44] Isn't no epoch equal to 0? [05:45] neither firmware-addon-dell nor firmware-tools define an epoch, so, ok [05:45] but it's not failing due to missing deps [05:45] apt/aptitude/synaptic just keep thinking the installed package system-bios-... isn't up-to-date [05:45] when it clearly is [05:46] could it be because the epoch is 0 ? e.g is that a legal value ? [05:46] persia, yes, it can have a Provides line, but it fails both when it does and when it does not [05:46] mdomsch: Just to make sure, that control file goes through an expansion parser before becoming source, so you're not redefining the set of generated packages at build time, right? [05:47] mdomsch: No, you likely don't want Provides:, but Provides isn't versioned, which might have been a source of confusion (but isn't) [05:47] persia, right [05:47] I _do_ want a provides for some packages [05:47] packages have binary packages in two forms [05:47] mdomsch: what does apt-cache policy give? [05:47] system-bios-ven-0x1028-dev-0xabcd [05:48] Sure, but if you're not providing either firmware-addon-dell or firmware-tools, that wouldn't be the issue. [05:48] LaserJock, http://pastebin.domsch.com/19 [05:49] the other form is system-bios-poweredge-2950, which Provides: system-bios-ven-0x1028-dev-0xabcd [05:49] which is so I can have packages with pretty names, but programatically look up the package via aptitude install system-bios-ven-0x1028-dev-0xabcd [05:50] It's the epoch. [05:50] mdomsch: I think it's the epoch [05:50] darn, Fujitsu beat me too it [05:50] mdomsch: That's it. The candidate apparently has an epoch, but the source isn't defining an epoch. [05:50] * mdomsch rebuilds w/o the epochs [05:50] if that's it, I'm kicking myself [05:50] As an empty epoch is equal to 0, so apt's local lists don't have it. [05:51] i beat you both to it , hehe [05:51] although i wasent sure and it was a question :) [05:52] pffft [05:52] guessing doesn't count ;-) [05:52] lol [05:52] imbrandon: I brought that up first :P [05:52] I thought it first so there :p [05:53] hahaha [05:54] * GoldenPony crushes LaserJock. [05:55] * LaserJock expires ... leaving the Golden Ponies unfinished [05:55] Objection! [05:55] How can something unfinished act in a crushing manner. I suspect GoldenPony just wants more playmates. [05:56] * GoldenPony grumbles. [05:58] * LaserJock notices GoldenPony is limping and decides he has to put'er down :( [06:05] LaserJock, Fujitsu, persia, imbrandon you folks are geniuses [06:05] that was it [06:05] mdomsch: awesome, easy fix :-) [06:06] geniuses i doubt ( leaste in my case ) but experince in weirdness with dpkg/apt/etc is a plus :) [06:06] mdomsch: Don't forget to close your bug :) [06:07] doing so now :-) [06:59] * TheMuso has just managed to get Ubuntu's cdimage building system working locally, or least I think so. Still waiting on seeing whether it builds a gutsy i386 image first. [07:01] wow, really? [07:01] LaserJock: Yeah. [07:01] Its building the image now, but it still may fail, but things are looking good. [07:02] Once I get hardy i386 mirrored, I'll be able to build my own hardy disks, which will be rather handy. [07:02] With the exception of the live disks, but thats my next project. === SWAT__ is now known as SWAT [07:24] Hi all! [07:24] the live disks are the fun ones though :) [07:27] warp10: hi [07:27] sakhi: hi :) [07:37] TheMuso: wow, mind sharing how to do that ? [07:37] i would love to be able to roll my own [07:38] me too but I think I'm gonna cheat and use Reconstructor or some such on a Desktop CD [07:39] * imbrandon thinks TheMuso should blog about it [07:41] imbrandon, as discussed at uds, the plan is to expand the cdimage script to make it more usable for derivatives [07:41] imbrandon, so joejaxx and TheMuso are both working with it [07:42] nice [07:42] i'd love to help too, i'd probably not be able to dedicate much time to it, but a bit here and there [07:42] until its ready for general consumption, if you want to see how the mythbuntu disks were rolled for 7.10, i can point you at a bzr tree for that [07:42] it was a custom script that I wrote [07:43] sure [07:43] https://code.edge.launchpad.net/~mythbuntu/mythbuntu/mythbuntu-livedisk [07:44] cool thanks [07:44] bash? [07:44] yeah [07:58] imbrandon: I'm just playing with it atm, but once I've confirmed that it works properly for hardy as well as gutsy, I'll be starting a fresh, and I'll document everything. [08:00] imbrandon: And I also have to test-build a live filesystem. [08:07] good morning === greeneggsnospam is now known as jsgotangco [08:09] Man, *awesome*. It's possible to trick Rhythmbox's gapless playback engine into playing two songs at once :) [08:09] How so? Setting the overlap time extremely high? [08:10] hey soren [08:10] Hi, dholbach! [08:11] imbrandon, next time you file an update to mplayer (even for a rebuild), can you please remember to update the bzr branch [08:18] persia: I am working on bug #145074 and I see to encountered an error that is similar but different to the bug raised in the first place. [08:18] Launchpad bug 145074 in xgalaga "xgalaga-hyperspace crashed with SIGSEGV" [Medium,In progress] https://launchpad.net/bugs/145074 [08:23] superm1: i tried but it never fully checked out [08:24] imbrandon, its a huge branch (especially the way its organized now) [08:29] superm1: is there a good reason the packing isnt kept in a seperate branch like most packing stored on LP ? [08:29] that would help tremendusly [08:29] imbrandon, yes there is [08:29] the way that its organized, the rc2 upstream version is in its own branch [08:29] and then each release branches from the upstream version [08:29] and adds in the debian/ directory via patches [08:30] directly in bzr patches that is [08:30] Gunner_Sr: Firstly, you'll likely get better assistance for asking a question generally to the channel. Secondly, if you7ve dicovered a different bug, and can fix that as well, it's better. [08:30] Err.. And if you wait around, I have a chance to answer. [08:31] imbrandon, this way when there is a new release, the upstream version branch is updated, and then the different release branches merge from it [08:31] and add/remove appropriate patches [08:32] hrm still seems excessive, no worries, i just wont touch it again, if i cant grab the source in less than 1 hour no need for me to mess with it [08:32] imho [08:34] Does it really take that long to checkout the mplayer sources? [08:34] thats when i cancled it both times i tried to check it out [08:35] That's no useful then. Is there some tool that allows cleanup of a bzr branch? Otherwise there's no point. [08:36] well really if the vcs control field is used it should be for the packaing , not the unpacked orig [08:36] imho [08:36] Actually, I kinda like having the unpacked orig in the VCS (and think pristine-tar is really cool), but not at that cost in updates. it's not worth an hour. [08:37] imbrandon, siretart can go into an depth discussion about the different "modes" of storing packaging and the advantages of them [08:37] he described them to me at UDS [08:37] s/depth/in\ depth/ [08:37] eg bzr get http://bazaar.launchpad.net/~kubuntu-members/amarok/debian [08:37] imbrandon, were you using bzr+ssh? [08:37] or http? [08:37] or sftp [08:37] http branch [08:38] and ssh_bzr [08:38] both [08:38] imbrandon, bzr+ssh is significantly faster. [08:38] ok [08:38] i dont recall it taking an hour to checkout though [08:38] point is the vcs control field is for packing not upstream sources, i;m not saying dont keep them arround in bzr but .... [08:39] just like svn on alioth [08:39] well the thing is packaging is in that url though too [08:39] can i co and commit only the packing ? [08:39] imbrandon: There's different schools of thought on that (and in svn in alioth). Both have strong arguments. [08:40] imbrandon, no you can't, because the patches applied in the ubuntu bzr tree require you to have all the source there still [08:40] superm1: huh ? === \sh_away is now known as \sh [08:41] the patches are applied to the source in bzr already ? [08:41] imbrandon, there are source changes to things outside the debian directory. traditionally those would be handled by packaging patches in debian/patches [08:41] but the way things are implemented here, they are directly applied [08:41] eww ok, even more reason not to touch the package again, ok [08:42] how is one supose to work with whats in the archive and whats in bzr and upstrem and keep i streight from the "outside" ? [08:43] well the idea is to be using feature branches [08:43] so you've got your upstream bzr branch, and the ubuntu package is considered a "feature branch" of the upstream branch [08:43] now say you've got a patch for gnome-screensaver [08:43] you go and branch off the ubuntu feature branch [08:43] apply your patches, test [08:43] right but that totaly screws regular group maintainers like me, if i had known the source was ptached and repackd i wouldent have touched it [08:43] see how its working [08:44] once you are ready, you merge the two branches back into the ubuntu feature branch [08:44] sounds like a good project branch on LP, but NOT a good vcs control branch [08:44] well you didn't necessarily need to know exactly how this branch worked for what you were doing, it was just a matter of letting that checkout finish, commit your update and carry on [08:45] well really it does, i dont want to be uploading code i dont know where came from thats not in the org tarbal [08:45] so it does matter to me [08:46] well when you did this, did you not see all the code changes in the .diff.gz and wonder what was going on before uploading then? [08:46] <\sh> Fujitsu, do I see it right, that -security stuff is being announce again on -changes? [08:47] not to mention, all of the changes are indeed in the bzr history. you can see who made what changes exactly when and even look at the history of each file [08:48] superm1: right but i dont care about the source, i wasent updating the source, i was updating the packing [08:48] its kinda the same thought as to why upstream shouldent include debian/ in the tarbals [08:48] \sh: yes, yes, yes, yes, yes, yes_1-1ubuntu1 [08:49] \sh: The fix must have been cherrypicked, or Kees has been doing things differently.. [08:50] superm1: imbrandon has a good point about orig.tar.gz. Look into pristine-tar: if you can't recreate the upstream distributed file, your repo is inherently untrustworthy. [08:50] well if the speed of this process was (is) the issue, i'd say have a checkout of this branch sitting around. i committed your changelog entry just now, it took less then 5 seconds to push up, so things are much faster once you've got that checkout there (not to mention the ease of bzr update versus finding the dsc and dget) [08:50] persia, well you can though [08:50] persia, the repo for the orig.tar.gz is the other bzr tree [08:50] that this branched from [08:51] superm1: Do the md5sums match? [08:52] persia, the get-orig-source in mplayer's debian/rules was used to build the upstream branch. it was committed as is from that rule [08:52] superm1: haveing a bzr checkout of every package in ubuntu localy isnt an option [08:53] so you could do an export of the upstream branch, tar it up and do it an md5sum comparison and they should both match [08:53] atleaste not for most [08:53] superm1: Right (which is nice), but get-orig-source only gets run on package update, not on applying a patch or a rebuild (note that I like VCS packaging, I'm just pointing out possible issues). [08:53] superm1: They won't because of timestamps, etc. [08:53] imbrandon, that's why it makes more sense for folks in motu-media (generally) to be working on packages like this rather than the general MOTU consensus [08:54] persia, i see your point. I might visit adjusting how that get-orig-source rule is done for that reason at some point. [08:54] so that it instead grabs from the bzr tree to build the .orig.tar.gz [08:55] the upstream bzr tree that is [08:55] superm1: Upstream has a debian/. [08:55] superm1: Take a look at pristine-tar. 99% of my stuff is patches to things already in the repos rather than maintenance, but from the docs it looks like it should do the right thing. [08:55] Fujitsu, yeah, so currently that has to be moved to debian_upstream at some point [08:56] its a matter of where that should occur though [08:56] ugh [08:56] damn connection [08:57] persia, looks interesting. [08:57] superm1: If I'm reading the docs right, it should mean you can get all the benefits of upstream-code-in-VCS, and still have reliable checksums for verification. [09:00] persia: mind reposting the link, i got dissconnected === imbrando1 is now known as imbrandon [09:00] imbrando1: No link: pristine-tar package in hardy [09:00] ahh ok === Sikon is now known as LucidFox [09:04] superm1: in anycase, thanks for doing the commit for me :) [09:04] no prob. it's a good excuse for me to nab a few more of the mplayer bugs i've been meaning to grab at the same time [09:04] :) [09:05] well at least in the morning that is. bed for now. night all [09:05] gnight [09:15] <\sh> moins jonp [09:15] <\sh> jono [09:15] <\sh> i mean [09:15] heya \sh [09:16] Hi \sh, jono [09:16] <\sh> jono, are there any recordings of the jam session from UDS? I want to listen to a singing ogra [09:16] hey geser [09:17] \sh: not sure [09:19] <\sh> jono, that would be a cool thing...good news everyone, please cheer to the almighty Canonical Allstars Band with their song "Do you know it's Christmas" DeathMetalStyle ,-) [09:19] haha [09:19] :) [09:21] <\sh> jono, TBH, you should think about it doing it next time during LinuxTag on Stage...imho this would be something new for the LinuxTag ;) [09:21] \sh: a gig? [09:21] <\sh> jono, yeah :) [09:22] \sh: that would be cool :) [09:23] <\sh> jono, wasn't it LUGRadio who thought about the "Ubuntu Song"? "Dum Dum Dum Dee Ubuntu" or something? there was something [09:24] \sh: Ubuntu, Ubuntu, They Drink It In The Jungle :) [09:26] <\sh> jono, hmm...what about "Welcome To Ubuntu...Get it 'cause it's free" (music from guns'n'roses "Welcome To The Jungle") [09:26] haha [09:26] nice : [09:26] :) [09:26] brb [09:40] <\sh> hmmm.... [09:44] morning everyone [09:44] <\sh> "Take Me Down To The Ubuntu City, where the ground is brown and the community is pretty" [09:46] \sh: hehe [09:57] dh_icons doesn't work for .xpm right [09:57] ? [10:00] dholbach: dh_icons doesn't work for .xpm right [10:00] ? [10:01] Kmos: gtk-update-icon-cache does not work on .xpm files - it's just for icons that are installed into /usr/share/icons [10:04] dholbach: but if they're installed at /usr/share/icons as xpm doesn't work either.. ? [10:05] I'm not sure that GTK's icon cache will return an .xpm file if you ask it for let's say "gtk-dialog-error", size 48 [10:05]