[00:00] * persia forgets the command to do the right thing, and hopes someone else is watching. [00:02] persia: you mean, about me? [00:02] XSource_: Yes. [00:02] well I was just trying this new plug-in, didn't mean that [00:03] XSource_: Ah. If you're just testing, no worries then (but be careful: most multichannel traffic is interpreted poorly) [00:03] and the bad thing it's in every channel [00:04] hey guys [00:04] Hi [00:04] do i need to include orig.tar.gz for a package that has no source (game data files, they [00:04] 're just texturtesa nd sounds etc) [00:04] Happy New Year from here now too ;) [00:04] jscinoz: That's source. You need a source to generate a binary (even if it's just copying files). [00:04] happy new year :P (was 11hours ago for me) :P [00:05] ah [00:05] also persia [00:05] or anyone else [00:05] can tar get input from stdin [00:05] im trying to have a pipe that extracts a zip, tars what comes out, then gzips it [00:05] but i dont think tar can take stdin as input [00:06] iirc.. [00:06] jscinoz: I think tar only accepts tarfiles to stdin (zcat foo.tgz | tar xf -), but doesn't accept filestreams (I'm not even sure what a filestream would be: how does one differentiate EOF from EOS?) [00:07] also, zipfile header info is at the EOF [00:07] so it's not real suitable for piping [00:08] so would it be better to have unzip extract to /tmp/something and just have it read from there since /tmp gets cleaned automatically [00:08] you should clean up your mess anyways. :) [00:08] or attempt to [00:08] jscinoz: Be sure to create a safe temporary directory, and clean up after yourself. /tmp only gets cleaned on reboot, which may not be often for some users. [00:08] alright [00:09] mktemp [00:17] snackpack, if i use mktemp, how do i inform the next command of the randomly generated directory name? [00:17] if I recall... [00:18] MYTMPDIR=$(mktemp) [00:18] use man mktemp for an example [00:18] ah yeah got it [00:18] * persia advocates := unless it's really important to perform the creation at the moment of invocation [00:20] true [00:20] if variables set out are only needed by one build rule is it better practise to put them in that rule rather than at the beginning of the debian/rules [00:21] jscinoz: Depends on what the variables do. In this case, likely. note that creating rule-scoped variables in make is done at the end of the rule definition line, rather than on a separate line. [00:21] hmm [00:22] whats the differenceb etween using, "=" or ":=" [00:22] jscinoz: parse time vs. run time. http://www.gnu.org/software/make/manual/make.html#Flavors has specifics [00:23] ah [00:23] * txwikinger wonders what the problem with bonobo is [00:25] other than its evil? [00:26] Amaranth: monkeys can't be evil: no morality applies [00:26] persia i got the sed thing to work to add the underscores at the right place now [00:27] 's_$[0-9][0-9][0-9][0-9]$$[0-9][0-9]$$[0-9][0-9]$_\1\_\2\_\3_' [00:27] jscinoz: I'm glad to hear your problem has been addressed, but I'm sure there is a more aesthetically pleasing way to accomplish it. Was uscan --dehs completely unhelpful? [00:28] yes unfortunately [00:28] as i need both the mangled and unmangle version numbers and i could find no way to get it to output both without breaking other things. [00:28] it messes up something when compiling evolution [00:29] jscinoz: You could make it slightly less bad by using something other than '_' as your sed delimiter. '/' is popular, or '#' [00:29] hmm ok i'll try that [00:31] jscinoz: How about s/$\d{4}$$\d{2}$$\d{2}/\1_\2_\3/ ? [00:32] ill give it a try one sec. [00:32] Err... nevermind. I'm confusing sed & perl again :( [00:32] I’d use sed -r and drop most of the backslashes. [00:32] dont do it that way persia? [00:32] *confused* [00:33] ion_: Good suggestion :) [00:33] ill do that now :) [00:34] which of the \ should i remove from 's_\([0-9][0-9][0-9][0-9]$$[0-9][0-9]$$[0-9][0-9]$_\1\_\2\_\3_' [00:36] % echo foo01234567bar | sed -r 's/([0-9]{4})([0-9]{2})([0-9]{2})/\1_\2_\3/' [00:36] foo0123_45_67bar [00:37] cheers [00:45] * SnackPack upgrades to hardy [00:52] gah [00:52] it seems that later in my script it just reads these variables as null [00:52] rather than what they truly are. [00:52] jscinoz: debian/rules is not a script, which might be part of that. [00:53] ugh [00:54] wait got it i think [00:55] jscinoz: echo x$(VARIABLE)x can be surprisingly informative [00:55] whats the x on eachside for? [00:55] jscinoz: Helps detect the difference between a space and a null [00:56] ah [00:56] ah [00:56] oops [00:56] woo got it [00:57] $() is used for command substitution, you probably mean ${VARIABLA} [00:58] victor_: In a makefile? [00:58] * persia reiterates that debian/rules is not a shell script [00:58] oh :) [00:59] (well, not normally.) [01:00] crimsun: it really, really, really oughtn't be. I thought the "debian/rules is not a makefile" meme even reached mass-bug-file status once, didn't it? [01:00] guess it depends on the #! thats at the top :) [01:01] Err.. "debian/rules is not a shell script" (carefully wiping egg) [01:01] I've seen debian/rules be a compiled executable. [01:01] Wow :-) [01:01] and yes, it left a rather nasty aftertaste. [01:01] crimsun: Ah. I suppose it works, but... [01:01] heh [01:02] crimsun: bash [01:02] debian/rules could be a python script too [01:02] or ruby, etc [01:02] I suppose it could be anything as long as it takes the right arguments, but I still believe it ought to be a makefile. [01:03] It can't be for some things [01:03] except where make is broke [01:03] the package for make can't have a makefile [01:03] Amaranth: Why not? Lots of packages build-depend on themselves. [01:03] I'd hate to bootstrap that [01:03] bootstrap + equivs [01:03] heh [01:04] vala svn depends on itself but the releases come with preconverted code [01:04] it's really fun when latest svn can't be compiled with the latest release [01:04] Amaranth: debian/rules for make is a makefile :P [01:04] you have to jump to some revision in the middle, etc === RzR is now known as rZr [01:06] mmm almost newyears [01:06] ( here ) [01:06] 5 hours [01:07] Bah. People in obsolete places. so behind the times. [01:10] ugh [01:10] we can't all be as chronologically progressive as you, persia :p [01:11] crimsun: That's just last year's thinking :) [01:11] Ha.. a new scale pf discrimination... chronologically challenged [01:14] ugh tar includes the temp directory in the orig.tar.gz directory structure [01:15] ie.. in the tarball we have tmp.xxxxx/sourcefolder1 sourcefolder 2 [01:15] any idea how to make it stop doing this. [01:15] jscinoz: call it with (cd $$foo; tar czf $$bar .) === boomer^ is now known as boomer [01:16] ah [01:16] thanks :) [01:23] yay got my get-orig-source all good :D [01:23] now.. [01:27] ugh [01:27] the .svn directories are still included in the orig.tar.gz [01:27] how can i strip these out somewhere between extracting the zip and building the tarball? [01:28] jscinoz: You're pulling from svn directly, or upstream is providing them in the zip file? [01:28] upstream providing in zip [01:28] jscinoz: man tar. Read about --exclude [01:29] * crimsun wonders about libsdl1.2debian-pulseaudio vice libsdl1.2debian-alsa by default. [01:29] alright here goes, lets hope get-orig-source is finally working [01:29] crimsun: surely pulse. The games may have (slightly) higher latency, but otherwise there are strange blocking effects (why doesn't my music play when I'm playing this?) [01:31] crimsun: got time to help me debug a sound issue on my imac, if not its all good ( seems alsa think my front built in speakers are headphones , ontop of that it mutes them on startup no matter what ) [01:31] hmm alls looking good, for my man pages should i gzip them or have dh_compress handle the compression? [01:31] jscinoz: dh_compress is more likely to track current policy [01:32] dh_installman compresses them too doesnt it ? [01:32] * imbrandon isnt sure [01:32] imbrandon: it doesn't claim to do so in the manpage [01:33] ahh i'm likely mistaken then [01:33] been quite a while since i looked [01:33] imbrandon: sure, but a sec, please [01:34] crimsun: sure no problems, and no hurries at all, i'm just watching irc as my kids play twister [01:34] persia: I was hoping that there wouldn't be any seed issues, and there appear to be none (e.g., *ubuntu-desktop depending on libsdl1.2debian-foo) [01:34] hehe [01:34] looks like we simply need to ask for libsdl1.2debian-pulseaudio's promotion [01:35] crimsun: Excellent then. I welcome our new pseudopodic overlords with glee. [01:36] i've read over the man page of dh_compress, i'm assuming i need to create a copy of the filesystem hirachy in ./debian and place the man page and other documentation in their appropriate locations for it to work? [01:36] Is Henrik Stokseth available? I've reviewed one of five REVU candidates, and wonder if the others need review, or may have some of the same issues as the first reviewed (cdemu-client) [01:37] jscinoz: debian/rules install should take care of most of that for you [01:38] Could i get a second person to advocate http://revu.tauware.de/details.py?package=hardware-connected (a program that indicates whether given hardware exists in the system; useful for scripting) and http://revu.tauware.de/details.py?package=apt-mark-sync (a program that synchronizes the “automatically installed” status of packages between different package managers)? Thanks. [01:38] * persia notes there are four other packages also awaiting a second advocate, if anyone is just watching twister and otherwise bored [01:39] *confused* [01:39] jscinoz: About? [01:40] so i have a man page, the copyright file, the debian changelog and the upstream changelog [01:41] i need the copyright to go uncompressed in /usr/share/doc/urbanterror, the two changelogs to go in the same directory compressed as changelog.gz and changelog.Debian.gz, and the currently uncompressed man page to go in /usr/share/man/man6/urbanterror.6.gz [01:41] how would i get dh_compress to do that. [01:42] persia: heh ok i'll look at revu [01:42] Personally i quite like CDBS. It Does The Right Thing™ with only a few lines in debian/rules. [01:42] i've already mostly completed this package i dont want to start over with cdbs. [01:42] jscinoz: For the manpage, use dh_installman. For the upstream changelog, use dh_installchangelogs For debian/copyright and debian/changelog, expect something else to handle it (I forget which). Call dh_compress in your binary-arch target to compress everything properly. [01:42] thanks [01:42] The non-CDBS debian/rules files made by dh_make handle that just fine, of course. [01:44] imbrandon: for a stable, supported release, or hardy? [01:45] thanks :) [01:50] crimsun: Is the default output for pulse really all connected output devices simultaneously? [01:54] persia: for which version? [01:55] it wasn't for 0.9.5 or 0.9.6 [01:55] crimsun: The version to be released in April with hardy (just saw a comment in the CleanupAudioJumble spec to this effect, and wanted to confirm or deny) [01:55] Specifically https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble?action=diff&rev2=56&rev1=55 [01:55] ah, for 0.9.8 it should be by default, yes. [01:56] Ah. Hmm. OK. Thanks for the confirmation. [01:56] there's some buffoonery still for hotplugged usb devices, so I need to track that [01:57] * crimsun migrates wifi hotspots [01:58] crimsun: gutsy on ppc , actualy its on etch right now ( to see if it was a ubuntu specific thing ) [01:59] so i guess i'll put gutsy back on it later or maybe hardy [01:59] but i'm guessing its a core alsa thing as it happens with all linux i have put on it ( only debian based ones ) [02:02] argh [02:03] i'm building both the server and client packages for a game, the source gotten from the upstream vendor is a zip file containing a client and server folder, in my orig.tar.gz should i have both client and server in one tarball or separate for each package? [02:07] jscinoz: It is best practice to have one orig.tar.gz for each upstream distributed file. If upstream combines the client and server in a single package, you may wish to have one source package (with multiple binary packages). [02:14] ok [02:23] imbrandon: ok, I'll need to know whether you're using the version(s) of alsa built-in to linux-image* or whether you've used module-assistant with alsa-source [02:24] imbrandon: also, for each of those, please grab http://trilug.org/~crimsun/alsa-info.sh, and let me know the URLs. === LongPoin1yStick is now known as LongPointyStick [03:01] * persia declares victory over REVU, and finds alternate entertainment [03:01] heh [03:01] persia: sponsorship queue? [03:02] Hobbsee: Not soon. I need to take a break from looking at possible mistakes, and don't want to be unduly firm (UUS has a lower threshold for acceptance than REVU). [03:02] heh [03:02] true [03:14] txwikinger: Good catch on the *really* old standards versions :) [03:47] uscan is ignoring --force-download, it doesnt download the upstream source [03:47] jscinoz: Please pastebin your watch file. [03:48] can i just paste here as its only two lines? [03:48] version=3 [03:48] opts=uversionmangle=s/_//g ftp://ftp.snt.utwente.nl/pub/games/urbanterror/iourbanterror/source/complete/ioUrbanTerrorSource_(.*)\.zip [03:50] jscinoz: I get "uscan warning: In debian/watch no matching files for watch line" with that watch file. === harrisony is now known as harrisony1 [03:51] i dont get any errors, it just refuses to download it [03:51] it states current version is latest [03:51] and even with --force-download doesnt download [03:52] jscinoz: What is the output of bare `uscan` in the package directory? [03:53] nothing [03:53] And your watchfile matches http://paste.ubuntu.com/3170/ ? [03:55] yes [03:55] hmm [03:55] i didnt change anything but it worked this time. [03:55] maybe the server had a brainfart :P [03:55] Odd. I don't know why I'd get different output than you, and I don't know why it works for you when it doesn't for me. [03:56] strange isnt it [04:09] persia: I just installed that qdevelop and I have to say it is a mess [04:09] it doesn't work [04:09] nixternal: Ah. Please leave a note :) [04:09] doing so now [04:10] nixternal: I don't suppose you'd be up for rejecting the 6 candidates remaining as well (assuming you can find a reason)? [04:10] do you have a list of them? [04:11] nixternal: The ones with the glass on http://revu.ubuntuwire.com/ [04:11] roger [04:12] holy shit, a 12mb dat file [04:14] which package? [04:14] pfft. Try the ia32-libs source. ;) [04:14] bf04278fc7870bae37175e314cde66a0 454876971 ia32-libs_2.2ubuntu2.tar.gz [04:14] munch on that, dude! [04:14] * persia thinks urbanterror-data wins [04:14] it's larger than 454 MB?! [04:14] crimsun: http://revu.ubuntuwire.com/details.py?package=urbanterror-data [04:15] eww. [04:15] thank goodness for rsync [04:16] persia: the mame hacks [04:16] that shouldn't even be packaged, let alone be on revu [04:17] if it doesn't meet ppa rules, then I do not advocate..I hope that is what you were looking for on this [04:17] if it isn't free, then you get no advocation from me :p [04:17] nixternal: Doesn't meet PPA rules? [04:17] ya, has to be free in a sense === santiago-ve is now known as foursixnine [04:18] nixternal: cheat.dat is a text file. [04:19] ya, 12mb text file that you can't edit, and doesn't belong in universe [04:19] don't even feel it belongs in multiverse [04:19] err, what's the license on it? [04:19] nixternal: That works for me. Last time I tried to shoot something down because it wasn't free (pq), I was overridden, so I'm not making that call any more. [04:22] crimsun: http://paste.ubuntu.com/3172/ is the relevant section of cheat.dat [04:22] eww. [04:22] yeah, kill it. [04:23] progress quest? [04:23] at best, one could use a wrapper to grab it (e.g., flashplugin-nonfree, and formerly, djbdns-installer) [04:23] The arguable bit is that it says "all I ask..." and "Please...", which may not actually mean we can't, but that doing so isn't nice. [04:23] * Fujitsu wonders if such badly written licenses are enforcable. [04:23] pwnguin: Yes. [04:24] you dont need nonfree to shoot that down [04:24] * persia thinks it's like postcardware [04:24] Both English- and `Please'-wise. [04:24] useless is enough in my book [04:24] pwnguin: Really? Would you like to file a removal request? [04:24] pwnguin: But wrapperss involving Wine are *fun*! [04:24] I think most present would love to see it killed. [04:24] persia: i dont count for much [04:25] pwnguin: Everyone counts :) [04:26] if it got into the archive, i dont see how a "this is pointless" is going to take it out [04:26] persia: Is cheat.dat redistributable if not distributed with MAME or a MAME frontend? [04:27] Fujitsu: Actually, no. Good point. [04:27] What is sdlmame-cheat? Is it a MAME frontend? [04:27] Fujitsu: No, just the cheat file. [04:27] Or does it not mean `MAME frontend', but `cheat.dat frontend'? [04:28] The duplication of `any' in that phrase makes it a bit confusing. [04:28] Still, there's a good argument that distribution without any MAME compile or any frontend may be in violation of the license. [04:28] So there's no frontend at all with it? [04:28] * Fujitsu looks. [04:29] Fujitsu: Nope. The entire package is just a wrapper for the cheat DB. It's intended to go with http://revu.ubuntuwire.com/details.py?package=sdlmame, which is packaged separately. [04:30] ... so it is. [04:30] That's unredistributable. [04:30] * Fujitsu would advise a nuking. [04:30] Excellent. One down: 5 to go. Commenting and nuking. [04:31] * Fujitsu likes dealing with licensing if it keeps packages like that out. [04:31] Erm, licencing, I guess. [04:31] persia: http://revu.tauware.de/details.py?package=mscore <- why are there 2 debian/ directories? one in the root directory and one in the mscore directory..is that fine? [04:32] persia: I like your second mscore review. [04:32] heh, he is like "oh that was brief, here is the full review" [04:32] Yep. [04:32] his full review is about the size of that damn mame.dat file :p [04:33] nixternal: Nah. Some of my reviews actually flood the buffer, and require two comments :P [04:34] The first review was interrupted as there was discussion in-channel regarding the package, and all parties were convinced it was a duplicate (it's not). [04:35] I recall that discussion, and the intense confusion that abounded for some time. [04:36] Fujitsu: Erm. nuking is broken :( [04:36] Somebody probably wants to remove the two sdlmame-cheat orig.tar.gzs at some point. [04:36] persia: One cannot nuke from the web interface, I don't think. [04:37] And nuking destroys the comments and all, I believe. [04:37] There are Nuke buttons on http://revu.ubuntuwire.com/index.py?archived=true for me. [04:37] Ah, I'm not logged in. [04:38] Also, all comments are archived at http://lists.tauware.de/listinfo/motu-reviewers, so http://lists.tauware.de/pipermail/motu-reviewers/2008-January/019164.html remains available for discussion in the future. [04:38] mozilla-devscripts looks ok. I'd only update the FSF address in debian/rules and src/* [04:38] That's true. [04:39] crimsun: Please upload or reject asking for the adjustment :) [04:39] persia: Does /index.py?nuke= work? [04:39] Fujitsu: No. I tried http://revu.ubuntuwire.com/index.py?nuke=624 [04:40] "No REVU account for crimsun@fungus.sh.nu exists yet." [04:40] erm, ok. [04:40] * persia creates an account for crimsun... [04:41] crimsun: Try your primary LP address. [04:41] crimsun: Actually, try the email address you usually use when uploading first [04:41] doesn't work. [04:42] (besides, my primary LP address is @fungus, and that's the one associated with the "old" revu account) [04:42] Right. New account coming up... [04:42] thanks! === foursixnine is now known as santiago-php === santiago-php is now known as santiago-ve [04:43] Erm. register_user.py doesn't seem to have execute permission :( [04:44] (I promise I really did have a rationale for saying it here in the channel instead of logging in and commenting ;-) [04:44] persia: Just do it manually. [04:44] * persia investigates [04:46] persia: Or in fact just run `python register_user.py' [04:46] Don't know why I didn't think of that immediately [04:48] Fujitsu: Right. Thanks. [04:48] crimsun: Try again [04:50] there's nothing for me to enter [04:50] crimsun: You should be able to "Recover" your password, if you control GPG key c88abda3 [04:51] I attempted that. [04:51] the resulting page provides no data to paste. [04:51] (this bug has existed since the recovery option existed ;) [04:52] Strange. Recovery usually works for me. [04:53] * persia hopes someone with deeper understanding of REVU can explain what I did wrong [04:54] * Hobbsee suspects it's just borked. [04:54] ./me looks. [04:55] persia: do you have any clarification on that second debian/ directory in the mscore package? otherwise it is a good package, builds, installs/uninstalls/purges just fine [04:55] have no clue wth the app does though [04:56] nixternal: Second debian directory? It's designed to help composers: they write songs with it. [04:56] under the mscore/ directory there is another debian/ directory [04:56] Ah. Somehow I missed that. Hrm. [04:56] crimsun: Your existing account was crimsun@ubuntu.com. [04:56] * Fujitsu tries to work out why recovery isn't working. [04:57] holy cow, you mean I found something that you didn't persia? ;) [04:57] nixternal: Fairly easy, really. [04:57] persia: I can find the easy stuff, you, you find stuff I have never even heard of :) [04:57] nixternal: That's because I make half of it up :P [04:58] hahahahhahaha [04:58] so I am not the only one then [04:58] nixternal: The extra debian directory is part of the upstream tarball. I suppose it could be pulled in the repack, but I don't know if it matters much. [04:59] ya, that is what I figured [04:59] just a dirty tarball [04:59] * persia tends to review diff.gz, with only passing reference to orig.tar.gz regarding licensing and application functionality [04:59] you can be pedantic with Toby; he can handle it. ;) [04:59] I tend to grab the dsc, build it, run dh_install --list-missing on it, and find the easy stuff [04:59] nixternal: That's another you can kill then :) Only 3 to go. [04:59] hehe [05:08] persia: you want me to upload mozilla-devscripts? [05:08] persia, crimsun: I think I probably know why the recovery wasn't working, though I don't have enough permissions on sparky to check - 0xC88ABDA3 won't be on the keyring until the next sync. [05:09] Fujitsu: Are you resyncing now? [05:09] persia: I can't. [05:09] nixternal: I don't have an opinion either way. crimsun mentioned a couple issues, so I thought he was handling it. [05:09] Fujitsu: Ah. I will then. [05:10] persia: ok, crimsun mozilla-devscripts is all yours [05:10] You could always just PM crimsun his password for now. [05:10] Except I've purged it from my logs and don't remember it [05:10] gonna grab a snack before new years hits, then I am going to see if the coppers are hiding so I can pull the snowmobile out for some quick laps [05:10] brb [05:10] * Fujitsu does so. [05:12] * persia is amused at the separation of roles between system administrators and applications administrators, and notes that some "highly secure" installations don't do as well. [05:13] Fujitsu: thanks. [05:13] crimsun: Your name also just passed in the sync, so you should be able to recover if you lose it. [05:14] * Fujitsu notes that sparky is probably a bit too open at the moment, if an unprivileged person like he can grab passwords from the DB. [05:14] Ah. I thought you had permissions. In that case, there is an issue. [05:17] My account on sparky is much the same as any other member of ubuntu-dev. [05:17] Fujitsu: I see that. Conflicts with MOTD, but that's a different issue. [05:18] Indeed. [05:19] There are only three candidates left on REVU. Someone should find a problem with them, or upload them. Let's get it clear for the new year :) [05:20] * Fujitsu has a look. [05:23] Aha, I might be able to test inkblot. [05:23] (looking at apt-mark-sync) [05:34] Fujitsu: you should be able to sync the keyring, any ubuntu-dev can [05:34] imbrandon: Ah, is there a sudoers entry for it? [05:34] imbrandon: don't you need to have the DB admin key? [05:34] * imbrandon notes he is not really here, just popin in a sec [05:34] Fujitsu: yes [05:34] persia: nope [05:35] * persia retracts the statement about separation of concerns, and blames poor documentation for the appearance of security [05:35] right [05:35] :) [05:35] poor docs but its all good, ones sec [05:37] any member of ubuntu-dev on sparky should be able to run the following ( but its not documented anywhere , yet ) [05:37] alias keysync='sudo -u revu1 -H /srv/revu-production/bin/revu-key update' [05:37] ^^ my .bashrc entry [05:38] persia / Fujitsu ^^ [05:38] * Fujitsu just added that. [05:38] Thanks. [05:38] * persia has "revukey" for the alias [05:39] :) [05:40] 21 minutes localtime, almost time for bed, i'm barely makin newyears localtime [05:40] heh [05:40] * imbrandon is sooooo tired atm [05:41] imbrandon: Have you been awake all day? [05:41] Yay, inkblot works. [05:41] Fujitsu: you seen my Windows XP aka "royale" theme for KDE right ? seen my latest GNOME atrocity ? [05:41] http://farm3.static.flickr.com/2308/2152618255_ed3e9ba526_o.png [05:41] persia: yea [05:42] Ew. SwiftFox. [05:42] no , just the icon [05:42] its epiphany actualy [05:42] Ah, good. [05:42] imbrandon: I don't suppose you'd like to test http://revu.ubuntuwire.com/details.py?package=awn-extras-applets. There's an issue with orig.tar.gz now, but the packaging is nice, and it could use some ubuntu-dev testing. [05:43] and evolution and gnome term and pigdin , and so on [05:43] Wait, aren't you a KDEer? Why are you using the GNOMEest (but best) browser? [05:43] persia: sure, i run awn as you can see too :) [05:43] imbrandon: Yep: your screenshot gave it away [05:44] persia: I think inkblot looks good. [05:44] Fujitsu: yea i am using gnome untill hardy release , was a self promis thing to "see the other side" [05:44] Fujitsu: Don't tell me. Tell REVU, ubuntu-motu@, and LucidFox :) [05:44] persia: Was just wondering if you had any objections to its upload. [05:45] Fujitsu: No. I'd like to see an updated FSF address, but that could also be a bugfix. [05:46] (or you could update it when uploading) [05:46] Or I could fix it right now and you would re-approve it. [05:46] LucidFox: I was wondering if you were around. [05:47] Yes, I am :) [05:47] LucidFox: Do so, please :) [05:47] imbrandon: another traitor, then [05:47] Fujitsu: despite the icons the apps are ( in order R to L ) : [05:47] epiphany , evolution, terminal , pidgin, frostwire, audacity, banshee, vmware console, photoshop ( wine ), and a trashcan [05:47] * persia suspects y'all are just gathering intel for a killer next release [05:48] err L to R [05:48] heh [05:48] persia: Heh. [05:48] persia: heh [05:48] nixternal lost to Vista, and (Hobbsee, imbrandon) to GNOME. Tut tut. [05:48] yea i totaly plan to go back to KDE when hardy releases, 6 months of gnome is enough for me [05:48] but it has been a nice insight [05:49] Now taking bids on the last candidate on REVU. Who wants it? [05:49] and i'll probably keep gnome in a VM , but i'm stickin with my KDE :) [05:49] i'm touching the awn one if thats what you mean persia [05:49] me lost to Vista? are you insane? [05:50] Happy New Year [05:50] imbrandon: That one already got rejected, but testing will help it get in next time. [05:50] right now I am using PCBSD [05:50] persia: k [05:50] Wait... 51 Franklin St. is the old address? [05:50] does gnome even compile on BSD ? /me ducks [05:50] Then what is the new one? [05:51] imbrandon: bah gnome, but bah kde4 on bsd at times [05:51] * persia rebuilds to encourage lintian to divulge the secrets [05:52] someday i need to get used to gimp so i can replace my Photoshop [05:52] heh [05:52]