[00:05] good night [01:10] apachelogger: try 9wm or amiwm or ctwm with .desktop files. [01:22] Oh, persia [01:22] bddebian: Yes? [01:22] How are ya? :-) [01:23] bddebian: Well. My todo list is down to < 350 items :) [01:23] Nice [01:23] Is conquest still on it? :) [01:24] * Hobbsee waves [01:24] Hi Hobbsee [01:25] bddebian: No, but it can be put back :) I thought you were looking for a sponsor for the last rev. Shall I take another try at cleaning up the -rpath stuff? [01:25] persia: Well I was more wondering about a bug that I can't reproduce. Doh you actually play it? [01:25] s/Doh/Do/ [01:26] bddebian: I've never tried, but I'll chase the bug. #338208? [01:26] God I suck at pre/post/inst/rm stuff, regexp, shell scripting, just about everything else.. [01:28] persia: No, 449136 [01:28] Debian bug #449136 [01:28] Debian bug 449136 in conquest-gl "conquest-gl: Segmentation fault when entering game world" [Grave,Open] http://bugs.debian.org/449136 [01:30] bddebian: Hmm. lousy stacktrace. I'll dig a bit. [01:30] I can't reproduce it, at least not with the -2 version from games team svn but that hasn't really changed much of the actual packaging [01:52] Is there a wiki page about how to write a merge's debian/changelog? [01:52] I would like to add a pointer to my comment in bug 173321. [01:52] Launchpad bug 173321 in maxima "Please merge maxima_5.13.0-2 from debian" [Undecided,Incomplete] https://launchpad.net/bugs/173321 [01:56] !merge [01:56] Sorry, I don't know anything about merge - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [02:00] * minghua pats ubotu. :-) [02:01] ubotu: merging is Merging is the process of including changes from other distributions (most commonly Debian) into Ubuntu packages, and is typically a major focus at the beginning of each Ubuntu development cycle. Please see https://wiki.ubuntu.com/UbuntuDevelopment/Merging for more information. [02:01] minghua: You're probably interested in that as well :) [02:01] %addeditor persia [02:01] Hobbsee: Thanks :) [02:02] persia: I saw that one, but the big "WIP" at top scared me away. [02:02] persia: can you register with the bot? i think it's "register persia " [02:02] in a query [02:02] persia: you probably want to add it like: !merging is Merging is .... [02:02] imbrandon: yeah, i fixed it to be that [02:02] :) [02:03] Hobbsee: didn't work :( (bot is not intelligent) [02:03] persia: also you can other words/terms too , like !merge-o-matic is merging [02:03] and #ubuntu-bots they hang out so you can spam/test in there too [02:03] imbrandon: i think you need a % in front [02:03] Hobbsee: you can but not nessesary [02:03] it will work both ways [02:04] wonder why it didn't then [02:04] * Hobbsee hasnt had to register with the bot in ages :P [02:04] s/will/should [02:04] !rc [02:04] Ubuntu 7.10 (Gutsy Gibbon) is the latest version of Ubuntu. Upgrading to Gutsy: https://help.ubuntu.com/community/GutsyUpgrades - Downloading: http://www.ubuntu.com/download - New Features: http://www.ubuntu.com/getubuntu/releasenotes/710tour - Please use bittorrent to download if possible, see !torrents [02:04] Someone probably should fix that. :-) [02:04] %whoami [02:04] imbrandon [02:04] persia: ^^ that test if the bot "knows" you [02:05] %whoami [02:05] I don't recognize you. [02:05] incase you need to re-login, but it should auto log you in if your cloak is active [02:05] and your registed [02:06] !merge-o-matic is merging [02:06] I'll remember that, imbrandon [02:06] !merge-o-matic [02:06] Merging is the process of including changes from other distributions (most commonly Debian) into Ubuntu packages, and is typically a major focus at the beginning of each Ubuntu development cycle. Please see https://wiki.ubuntu.com/UbuntuDevelopment/Merging for more information. [02:06] see Hobbsee :) [02:07] !bot [02:07] I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots [02:08] Interesting. I can unregister, but not register. [02:09] yea i was just looking up the exact syntax [02:09] Seveas: any help here ? pwease [02:09] Seveas: we're trying to add persia as an editor [02:10] btw persia i'm sure youve glanced at it , but that wiki has syntax for sed and such to edit/add new factoids [02:55] * emgent heya [02:56] emgent, hello there [03:34] question, I'm working on updating a package I did for my PPA. I ended up with several warnings and finally this: debuild: fatal error at line 1247: [03:34] during my debuild stage [03:34] but line 1247 where? [03:39] minghua: Sorry to have wasted your time on the forum comment yesterday. [03:39] rick_h_: It should say somewhere in the previous lines [03:40] bddebian: ok, it didn't give any line numbers in any of the previous warnings and such so I thought the fatal error must have been unrelated and seperate [03:42] ScottK: I was kidding. :-) [03:46] minghua: Ah. Glad to hear it. My grumpiness level is high enough right now, I'm taking all grumpiness claims totally seriously. [03:47] * persia passes ScottK tea & biscuits [03:48] persia: If the tea is 'special' then that might help. [03:48] * Hobbsee takes a drink [03:48] Poor ScottK. [03:49] ScottK: Anything I can help to reduce your grumpiness level? [03:49] minghua: Not really. Thanks for asking though. [03:49] * jdong hugs ScottK [03:49] * jdong is a bit under the weather today... [03:49] * Hobbsee raises an eyebrow at this [03:49] * Hobbsee thougth even html mail was supposed to contain some actual words, not just arndom letters [03:50] * imbrandon group hugs ScottK and invites all to join * [03:50] Thanks. [03:50] Hobbsee: I once got one where every freaking charactor was escaped out [03:50] ZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAojIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0 [03:50] aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJ [03:50] VE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQojIEdOVSBHZW5lcmFsIFB1 [03:50] YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCiMKIyBZb3Ugc2hvdWxkIGhhdmUgcmVjZWl2 [03:50] ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaW [03:50] it's like ^ all the way thru [03:50] Yay, base64. [03:50] looks base64 encoded [03:50] Hobbsee: base64 [03:50] grr you guys win [03:51] ahhh [03:51] now, someone decode :) [03:51] darn gmail. i wonder why. [03:51] probably some sort of pill offer [03:51] Hobbsee: someones mailer prefrences probably barfed on it [03:51] It could be an image. Or couldn't it also just be non-ASCII text? [03:51] imbrandon: this is do ubuntu-devel@l.u.c. it should be readable. [03:52] Hobbsee: i mean the senders email client prefrences [03:52] like "encode all outgoing mail base64 + send html mail [03:52] etc [03:52] imbrandon: ah right [03:52] someone poke rainct about it when he comes in then [03:52] Hobbsee: I usually just look at the Subject when doing moderation. [03:53] ok, this headache is killer... I'm gonna go to bed, night all [03:53] * Fujitsu sharpens the MOTU SWAT sword for use on HTML mailers. [03:53] iirc there should be a cmd line util to decode base64 fairly easy and pipe it to a file, then run `file blah.ext` on it to tell what it was supose to be [03:53] Night jdong. [03:53] txt or image or what [03:53] Hobbsee: RainCT is aaron whitehouse, right. [03:53] minghua: unfortunately, this is both spam/non-spam moderation, and to see if it's an acceptable topic for u-d - or whether it would be better on u-d-d [03:53] from seeing u-motu, i'd imagine i'ts the same mail [03:54] Hobbsee: if you would paste the contents to pastebin and i'll spend ~5 minutes trying to decode it, should be trivial [03:54] Hobbsee: I see. [03:54] imbrandon: already accepted it, i cant get it back [03:55] ahh so it will be "on list" soon? [03:55] Hobbsee: subject : Re: Patent issues with automatic codec installation (was: Automatic installation of DVD CSS support) ? [03:56] lol Gutsy + Hardy == 55GB [03:56] imbrandon: no - the tags stuff [03:56] Aha, I was right, it was UTF-8. [03:57] Good evening all [03:57] * Fujitsu notes that once a tag is created it requires a DBA to kill it. [03:57] Just removing all references won't help. [03:58] Ah. More sensible and scalable designs in LP. [03:58] Yes. [03:58] Fujitsu: Yes, but that's a larger matter than the list of tags & bug counts in the default list. [03:58] persia: The tags will not vanish from the list. They'll just have 0 references. [03:59] how is everyone? :) [03:59] Heya joejaxx [03:59] hello bddebian :) [04:00] hey joejaxx [04:01] heya joejaxx [04:01] Fujitsu: Right. The next step is requesting removal. [04:03] People are supposed to request removals of tags? [04:03] Should we file bugs in LP for that? Do we need a tag for such bugs? :-P [04:03] Is this documented somewhere? [04:09] Tags are poorly documented. We could file bugs against LP for removal, or maybe there's something else, but in the absence of other documentation, bugs are best. [04:09] the answers section is best for getting tags removed [04:09] bugs are really for things that require development to alter [04:10] lifeless: How is one to know externally? [04:11] * persia 's questions always time out from inactivity [04:11] yea but development to alter a tag ( e.g. remove it if refrences == 0 ) might be a good thing [04:12] would take less manpower in the longrun :) [04:13] imbrandon: so it depends what you're trying to accomplish I guess. [04:14] I would say a bug like 'only show tags with > 1 reference in the sidebar' a bug/feature request [04:14] lifeless: true true, maybe one bug, and lots of removal requests [04:14] And 'remove from the db tags with no references' a question [04:14] yea [04:14] So it's up to us to periodically ask to have unreferenced tags removed? [04:15] ScottK: as of this moment , yes, hopefully with a bug like that filed, no [04:15] It does sound like a bug. [04:15] anyone actively filing the code change bug? if not i volenteer to [04:15] * ScottK certainly isn't. [04:16] persia / minghua ? [04:16] lifeless: I'd say it'd be better to remove the unused tags so that people get the new tag definition warning when trying to use deprecated tags. [04:16] lifeless: you actualy work on the LP team correct? i have a diffrent small question if so [04:16] imbrandon: Best to wait for RainCT to wake up again, so that everyone can agree on the right way to do it. [04:17] persia: kk [04:19] lifeless: i filed a request to have my PPA "cleaned" , and all packages were marked as deleted within 24 hours, but they still reside in my pool and still show up in my disk quota counts and package counts , isnt the /pool supose to be cleaned too , and if not know of a reason why it isnt ? did i find a bug or ... ( btw yes i have asked this same thing in #launchpad many times but always seem to not get a response of even "i do [04:19] wow that was long [04:19] did it get cut off? [04:20] yes [04:20] response of even "i do [04:20] of even "i dont know" ) [04:20] thanks Hobbsee [04:20] imbrandon: tried pinging cprov-out wiht your request? [04:21] not personaly but i have when he was active in the irc [04:21] imbrandon: there's no real delete - it' all stays in librarian anyway [04:21] but it should have actually been removed from /pool [04:21] librarian is fine, but this is on ppa.lp [04:21] yea [04:22] see https://launchpad.net/~imbrandon/~archive [04:22] then click in my pool [04:22] :) [04:22] err +archive [04:22] https://launchpad.net/~imbrandon/+archive (for the lazy like me ) [04:22] yeah, they've probably messed it up :) [04:23] all i'm saying is that they don't delete it from librarian, even if the rest of it *does* work [04:23] yea i dont mind them staying in libraryian. but my pool i would expect to be empty and numbers reset on delete [04:23] probably YALPB. [04:23] that was the whole reason to request it, i dont care if it shows in the UI :) [04:24] heh [04:24] YALPB ? [04:24] Yet Another Launchpad Bug [04:24] ahh [04:24] * ScottK is guessing. [04:24] yes [04:25] sure, i guess i need to file another request, because i've been asking on and off for 1+ week now ( how long has it been since the 1.1.11 rollout? ) and umm they always "disapear" like this time :) hehe [04:25] imbrandon: i'm not sure what the actual time for requests is. [04:26] imbrandon: cprov is the lead developer on launchpad's distro build features [04:26] like, actual properly actioning the requests [04:26] s/lead developer/half of the development team/ [04:26] lifeless: cool, but is that actualy a bug or was i just mis-intrepting what all got deleted on request [04:26] imbrandon: he's on an east-coast US time zone [04:26] s/got/gets [04:26] imbrandon: well, he can answer authoritatively [04:26] kk [04:27] I would guess, but guesses tend to error. [04:27] yea its a bit late for him today. i'll see if i cant catch him monday-ish [04:27] lifeless: yea :) but thats atleaste more than ive gotten uptil this point :) [04:27] thanks [04:28] i mean its not THAT big of a deal, just annoying it 1) happened and 2) i seem to get "dropped" connections and clear the room in #launchpad when i ask :) [04:30] imbrandon: clearly, they just hate you. [04:30] hahaha [04:31] probably more like super busy, leaste thats what i'm chalking it upto this time since it was about the time 1.1.11 rolled out [04:31] :P [04:32] i'ts far more fun to be paranoid, and think that htey just hate you. [04:33] Hobbsee: Your getting imbrandon and me confused. [04:33] lol [04:33] you mean they don't hate both of you? [04:33] Could be. [04:34] btw i'm sure most of you read planet, but i'm gonna do a small OT self plug in here heh, http://www.imbrandon.com/2007.12.01/brandons-holiday-computer-fund.html [04:34] * imbrandon stops [04:36] Hmm, receiving 8 video cards and no RAM is a common problem? [04:36] if you ask for pieces and parts :) [04:38] fundable.com is an interesting idea. [04:38] yea, i really liked it, the only downside to it i noticed is the max you can run a fundraiser for is 25 days [04:38] other than that it seems like a great idea [04:39] well 25 days from the time you get the first pledge, but still [04:40] * persia thinks that any PR campaign that takes > 25 days is probably poorly designed in the first place [04:40] true === _czessi is now known as Czessi [04:46] So is it unreasonable to be grumpy that a package that I worked really hard to get removed from Universe because it was buggy and had very serious open security vulnerabilities just got put back into Gutsy in the partner repository? [04:46] And people say backports is crack. [04:46] ScottK: lol? [04:47] what package [04:47] Fujitsu an \sh_away: openssl097 is back (in partner). [04:47] joejaxx: openssl097. [04:47] ScottK: Not at all. Please complain strenuously to thegodfather: that's entirely the wrong way to solve the problem. [04:47] ScottK: oh fun :\ [04:47] slangasek: Are you around? [04:47] persia: Which godfather did you have in mind. [04:48] * joejaxx keeps telling himself it is only 55gb on the first sync, it is only 55gb on the first sync [04:48] oh wow, how did it get in partner and better why? [04:48] dunno [04:48] joejaxx: for what ? [04:49] imbrandon: Want to blog about Ubuntu's partner repo containing packages that are even to crappy for Universe? [04:49] imbrandon: gutsy+hardy archive mirror all arches [04:49] ScottK: IRC nick of person looking at issue, and person who asked for inclusion of the offending binary blob in partner. [04:49] joejaxx: apt-mirror ? hehe [04:49] imbrandon: well except ports [04:49] ScottK: sure [04:50] persia: It was fabbione and he doesn't seem to be on right now. https://launchpad.net/ubuntu/gutsy/+source/openssl097/0.9.7k-3gutsy1 [04:50] ScottK: lemme dig a little as to when you got it removed and such and i'd be more than happy to [04:50] i need to write on my blog more :\ [04:50] * persia notes that that person has been using a different nick lately, but agrees with the identification [04:50] imbrandon: It was removed that Monday before the release because pkern finally killed off the last rdepend for me. [04:50] persia: What nick then? [04:50] That's what's in LP. [04:50] ScottK: thegodfather [04:51] i thought he was only the sparc canonical guy, now he is packing for -partner ? heh [04:51] (also not around just now) [04:51] imbrandon: is an ISV packaging dude [04:51] persia: Ah. Now I understand. [04:51] Burgundavia: ahh [04:51] persia: almost ready for the mips and arm ubuntu ports, well the initial building anyway [04:51] persia: :) [04:51] joejaxx: Excellent! Let me know when you need ARM testing. [04:52] persia: ok :) [04:52] joejaxx: yea i failed at bootstrapping my mipsel, when i get a faster box i'll try it again [04:52] persia: I know why he did it too. [04:52] because i have a perfectly good 200mhz mipsel ( pretty fast considering ) sitting here doign nothing [04:52] ScottK: Yep. It's been under discussion the last couple days here & there. VMWare doesn't want to recompile their blob :( [04:52] persia: vmware-server (1.0.4-1gutsy1) [04:53] ah [04:53] Sounds like a perfectly reasonable reason not to include it. [04:53] so that is why it too so long for vmware to hit partner :P [04:53] So I get broken crap removed from Universe and they just reupload it. [04:53] ScottK: I'd prefer having a recompilation, as there's a fair bit of user demand, but the inclusion of 0.9.7 is just bad. [04:54] ScottK: Open a bug with a demonstrable exploit showing that it's bad :) [04:54] persia: Users want a binary blob so we upload a package known to be remotely exploitable. [04:54] e.g. If you install vmware-server from Canonical, your host can be compromised. [04:54] * ScottK may go hunt CVEs if I get bored. [04:55] ScottK: if you do lemme know, i'll refrence them in the blogpost [04:55] ScottK: As I said, that's the wrong way to fix it. The blob needs to be recompiled to use the updated library. [04:55] persia: Yep. [04:55] id rather not post a working exploit but a cve refrence would work just was well to prove a point [04:55] ScottK: If you're feeling particulaly cheeky, file a bug against VMWare server demonstrating a security issue that forces the recompile. [04:56] imbrandon: Working exploits for that library are widely available to the public, but I can see your point. [04:56] (most are fixed in 0.9.8, which everything in gutsy is compiled against) [04:57] hey tonyy ! :) [04:58] hi === tonyy is now known as tonyyarusso [05:00] joejaxx: arm might be fun. Been playing with my tungsten e and wondering what to do with it [05:07] imbrandon: Bug #146269 is the first one (I'd doing the bugs as I go). [05:07] Launchpad bug 146269 in openssl097 "[openssl security] OpenSSL SSL_get_shared_ciphers() off-by-one buffer overflow" [High,Confirmed] https://launchpad.net/bugs/146269 [05:07] k [05:09] Burgundavia: :D [05:11] well i am going to retire for the evening [05:11] hopefully that sync is done in 6 horus [05:11] hours* [05:12] Goodnight MOTUs :P [05:12] :) [05:12] gnight joejaxx [05:12] joejaxx: before you go.... apt-mirror ? [05:12] hehe [05:12] or just some long rsync string ... [05:13] ( and if it is apt-mirror i HIGHLY sugest you backport the package from hardy and/or grab it from sf.net ) i havent finised the backports request yet for the other supported release [05:14] and there is a ~ ( tilde ) bug that will clean any debs with a tilde in the url each "clean" run [05:14] an anything lower than 0.4.4+debian-2 [05:14] just FYI [05:15] imbrandon: That's the only one that I see that it's vulnerable to for sure and the Secunia advisory describes the impact as "Successful exploitation allows execution of arbitrary code." [05:15] hrm who awake atm has handled a few SRU's ? i personaly havent done any since edgy and would like opinons on SRUing apt-mirror to all supported releases [05:16] vs -backport(ing) [05:16] imbrandon: It doesn't sound SRU worthy to me. There isn't a regression, crash, or data loss from what you say. [05:16] as all fixes were bug ( some serious ) fixes [05:17] For an SRU you'd need to cherry pick the SRU worthy fixes anyway. [05:17] ScottK: dataloss as in it will clean / make an inconsistant mirror for any deb with a ~ in the url ( quite a few ) [05:17] imbrandon: OK. I'd buy that patch in an SRU. [05:17] imbrandon: That's data loss. You just need a patch to only fix that, instead of upgrading to the new version. [05:17] keescook: Are you around? [05:18] imbrandon: Find 2 or more people interested in verifying the SRU beforehands... Get them to commit and that'll make phase2 faster [05:18] yea it should be simple, i already have them broken into patches and 3 or 4 iirc are bug fixes [05:18] *sigh* can't sleep [05:18] 3 of 4* [05:24] joejaxx: maybe with a sd wifi card, it would actually become useful [05:24] IS there an open SDIO stack yet? [05:25] sadly, afaik, no [05:26] speaking of SD* anyone seen this, i probably would never get one, if i needed something like it i would use a pico-itx ( more power than a 486sx ) but its still kinda nice, i could see some uses for it, just none *I* have ... http://www.norhtec.com/products/mcjrsx/index.html [05:27] tiny tiny and under $100 [05:27] ~$85 usd iirc [05:28] we nice for a firewall [05:29] I hate how most routers and switches don't auth against LDAP [05:29] yea, or seomthing like a driver to show a display in a storefront [05:29] or soemthing [05:30] for soemthing like a firewall & / or router though you would need the PCIe option but iirc it only adds like 10 bux to the price [05:30] so you could ass more interfaces [05:30] add* [05:31] or i guess a small switch attached would do it and then make virt interfaces [05:31] anyhow , yea [05:31] imbrandon: It can't run Ubuntu kernels though :( [05:31] persia: could run a debian 386 one [05:31] :) [05:31] Debian still supports real i386 (no FP)? Cool! [05:32] iirc i think they have one, i havent looked in quite a while [05:32] at very leaste they have a 486 one , and iirc untill edgy we had a 486 ( labeled 386 ) capable one [05:33] grrr stupid bot [05:33] 00:31 Error: Debian bug 386 could not be found [05:33] heh [05:34] is edgy when the -generic kernels started? iirc thats when it became >= 586 subarch [05:35] persia: Not officially in etch, AFAIK. [05:35] Burgundavia, why would you want routers & switches to authenticate against ldap? [05:35] minghua: Makes sense. I thought it was on the Debian lists that I read about requiring 486. [05:35] imbrandon: we still have a -386 kernel that works with 486's though [05:35] persia: That's my recollection, too. [05:35] imbrandon: requiring 586 is a different transition than requiring 486, but Edgy, yes. [05:35] imbrandon: I don't recall any major distro supporting non-FPU true i386'es anymore [05:35] jdong: really? i thought that was dropped [05:36] well 486sx support is all it needs it says [05:36] imbrandon: AFAIK linux-386 is still around [05:36] imbrandon: at least it's in Gutsy [05:37] and somethgin that small would be ( as much as i hate to say it ) gentoo ( bootstraped via a faster box ) or LFS system anyhow, due to size [05:37] hrm or actualy there is OpenWrt for x86, wonder what kernel it uses, i know its 2.4.x [05:38] and that has the ipkg system ( similar to dpkg + apt in design and use ) [05:39] actualy iirc it was modeled after dpkg + apt but made to be really really small for embeded systems use in OpenWrt/DD-Wrt [05:40] imbrandon: I don't think stock dpkg/Debian/Ubuntu would be good on a 486sx in performance [05:40] imbrandon: you'd really want to LFS or something busybox-stacked from ground up [05:40] DD-WRT or whatever WRT is x86 compatible [05:40] I think DD-WRT is also i386 flavorable [05:40] jdong: I haven't tried recently, but I used to run Woody on a 486DX, and it was fine (with the right choice on WM, etc.) [05:40] yea i just said that heheh [05:41] jdong: ^^ [05:41] imbrandon: lol I'm feverish and tired, long sentences are not being parsed in a timely manner :D [05:41] openwrt has an x86 , although most packages are only prebuilt for mips(el) and arm(el) [05:41] openwrt needs to upstream their drivers [05:41] but an x86 can easly host a native toolchain to make packages on a faster system [05:42] Burgundavia: yea, i think as soon as they stablize on 2.6 they will, i talk to them sometimes [05:42] they are still in the 2.4 --> 2.6 stages [05:43] plus they still use binary blobs for alot of stuff , like broadcom [05:43] iirc [05:44] http://reviews.cnet.com/routers/linksys-wrt54gx/4505-3319_7-31242695.html <-- I have one of these and I really wish I could run ebox on it [05:44] Burgundavia: i have a wrt54g ( not gx ) i could help you get it running [05:44] if you wanted [05:44] is it flashed already ? [05:44] is it a v5+ ? [05:44] no, it is a gz [05:44] please say no [05:44] gx, rather [05:44] http://wiki.openwrt.org/Unsupported [05:45] ahh is that the ones the cut the flashram in half ? [05:45] they* [05:45] yup, only 4mb [05:45] crappy [05:45] that is the gx2 [05:46] I have the original gx [05:46] no [05:46] WRT54GX [05:46] 1.0 [05:46] Broadcom 4704 @ 300MHz [05:46] 4MB [05:46] 16MB [05:46] flash / ram [05:46] 4mb flash [05:46] it says [05:47] you would have to run the micro port IF it ever does get support, and then mount something, smb/nfs/sshfs [05:47] for more room for ipkg's [05:47] the j2ffs cant be enabled on those [05:47] err anything that small [05:48] that is the same as the old G and GL devices [05:49] * Burgundavia is confused [05:49] there are 2 ( 3 kinda ) gx's, 1.0 , 2.0 ( and gx2 ) [05:49] right [05:49] and I have version 1, I seem to remember [05:50] not having the device in the same house as I currently am [05:50] ok thats the one i was looking at [05:50] 300mhz [05:50] 4mb flash [05:50] 16mb ram [05:50] PCI [05:50] right [05:50] err mini-PCI [05:51] oh even a serial header, nice [05:51] i wish my FON had that [05:51] saves from easy bricking [05:52] I wonder exactly how many Linux-based routers are vulnerable to iptables issues out there right now? [05:52] err i was wrong, you would need to run mini when/if it grows support, micro is for 2mb flash routers [05:52] and full is for 8mb + ones [05:55] whoops , i run him off [06:05] heh [06:05] i have a v2 wrt54g [06:06] and a v4 [06:06] pwnguin: yea i think thats what i have access to also ( its the router i setup for my parrents with openwrt ) , i have a FON here with openwrt on it [06:06] the v2 [06:06] pwnguin: are you subscribed to debian-devel ML ? [06:07] i doubt it [06:07] motu gets enough mail as is [06:09] you should look at this, it JUST came in to debian-devel , its someoen that just ran some parallel builds on sid, something like 1000+ failed due to parallel but not in regualr builds [06:09] http://lists.debian.org/debian-devel/2007/12/msg00020.html [06:09] thats expected [06:09] since you were asking about it [06:09] thought you might like to see some actual numbers [06:09] someoine was trying to tell me that there were builds that WORKED in parallel but failed in serial [06:10] its still interesting [06:18] imbrandon: what does BROKEN mean? [06:19] as in "204 built BROKEN packages" [06:19] e.g a normal build built one thing and the parallel build built something successfullyt, but it dident match [06:20] Yay, all my packages succeeded. :-) [06:20] now that sounds like an interesting case [06:20] minghua: all 3 of mine too :) [06:20] :) [06:22] man xorg input really died on that [06:22] hell, xorg in general [06:23] imbrandon: Although it's probably not much of an achievement as all my packages use autotools. [06:23] none of mine do [06:23] well libvisual should, but i havent made those changes yet since i adopted it [06:24] crap, well i just installed hardy on that iMac and it too drops to a busy box shell on boot [06:24] damnit, whats with that box and linux, it likes -0- distros, only osx [06:24] and old osx at that [06:25] its apple hardware [06:25] lol [06:25] if it liked linux, apple couldn't chage you 100 dollars every year [06:25] evry other piece of apple hardware i've ever owned worked flawless with linux though, even my ipod nano [06:25] lol [06:26] you have a 68000? [06:26] hell i'm typing on an apple keyboard right now ( yes i'm on a non apple x86 PC , i just love their keyboards ) [06:26] pwnguin: nope, would be cool though [06:27] i like strange^W non-mainstream hardware [06:27] just because it dont always like me is a diffrent story [06:27] :) [06:28] pwnguin: your on the KS side ( even when your in-town ) correct ? [06:28] pwnguin: I am pretty sure Apple don't want to support leopard on imbrandon's machine, so no $100 this time. :-) [06:30] minghua: heh yea it dosent support anything psat 10.3 ( and i only have legit copies of 10.2 and 10.4 , and no illegal anymore since i rm -rf'd the OSx86 one ) [06:30] past* [06:31] so i can either a) figure out why *this* iMac rev1 seems to have so many issues and none other on the net seem to with any modern linuxes ( ubuntu 5.10 loads on it fine , nothing past that for any distro ) or b) live with a 10.2 OSX install or c) buy 10.3 [06:32] and really the only reason i have it arround it to load some modern ubuntu on it ( hopefully hardy ) so i can add it to the ubuntuwire network as a ppc box [06:32] imbrandon: I have a legit 10.3 copy. [06:33] (and the iBook that it came with is currently broken.) [06:33] minghua: wanna put up some pivate iso's for me or send them snail mail ? hehe [06:33] lol [06:34] actualy dont worry about it [06:34] Hehe. I'm pretty sure putting up ISOs would not be legal, but I'll consider sending the CDs to you. [06:34] because honestly if i get too frustratd and get another ppc box i will just load 10.2 on this one and give it to some child to use [06:35] really i have no use for it running osx, i only have it arround for UW, past that its just takin up space :) [06:35] and i'm not out much, i got it from a LUG member for $10 a few weeks ago [06:35] hehe [06:36] i even tried that xPostFacto program thats supose to let you run OSX 10.4 on un-supported ( by apple ) PPC hardware [06:37] and it wouldent even let me load 10.4 hehe [06:37] and on the xPostFacto site it says 10.4 is even known to run on the original powermacs ( abet really really slow ) [06:38] so i think the iMac i have is just possesed [06:38] * minghua doesn't consider trying to make OS X working on unsupported hardware worth the time spent. [06:38] I'd rather try making linux working on them. [06:39] well it was worth trying at the time, because the usb wireless nic i had only supports 10.3+ [06:39] minghua: yea, i'm gonna mess with it about a week more with hardy, past that it gets given to someone that needs it for xmas with 10.2 :) [06:40] i'm sure there is some child here localy that would love a computer, it runs fine in 10.2 with wired ethernet, but i just have no use for it in that configuration [06:41] And 10.2 is a fine OS. Although probably a bit not secure. [06:41] its still updated by apple with security updates [06:41] so it should be secure [06:43] 10.2? I thought Apple stopped Jaguar security updates long ago. [06:45] iirc they still do 10.1+ i might be wrong, they atleast still provide the downlaods for them via the normal update client and still backport things like safari 1.0 [06:45] etc [06:53] !iirc [06:53] IIRC means "if I remember correctly" [07:00] imbrandon: From http://docs.info.apple.com/article.html?artnum=75421 the last update was August 2004, so I'd guess "no security support anymore". [07:00] ahhh [07:00] well atleaste they have the old downlaods avail for the update client :) [07:00] and new apps like safari :) [07:01] even more reason to get linux working on it though [07:03] imbrandon: yes, my family lives in Kansas [07:05] pwnguin: Where in Kansas? [07:07] didnt we already have this conversation [07:07] We probably did, but it's late, I'm tired, and I don't remember. [07:07] about 15 minutes south of where your parents live, in olathe [07:07] Ah. I remember now. Thanks. [07:07] Sorry for the repeat. [07:08] i live near KSU [07:08] :) [07:34] OK. Well kmos is officially the MOTU Council's problem now. [07:37] ScottK: heh, how is that ? [07:38] imbrandon: I just asked them to have him removed on MC mailing list. [07:38] removed from the ML or ... [07:38] Removed from Ubuntu related LP functions and not allowed to bug people here or on MOTU ML. [07:39] It's the most execommunicated I think might stick. [07:39] ah [07:43] The difficulty being that he's actually helped once or twice recently (although I'd agree about the overall balance of contributions, even over the short term) [07:43] Right. Even a blind hog roots up an acorn once and a while. [07:48] ScottK: Just FYI, MC also mentioned ongoing discussions on that topic in the last Community Council meeting. [07:48] (http://irclogs.ubuntu.com/2007/11/29/%23ubuntu-meeting.html) [07:49] persia: Yes. That was in anticipation of this request as I've told them it was coming. [07:49] Ah. That makes sense. Just wanted to make sure the loop was closed. [07:49] I was there ready to suggest maybe he shouldn't be a member and dholbach wanted to avoid a bloodbath at the CC meeting. [07:49] Thanks. [07:50] Personally, I think it'd have been good to get it out in the open, but that isn't how he wanted to deal with it. [07:54] Bloodbath at CC meeting... [07:54] Unfortunately not. [07:56] I'll agree about open, but I agree with sabdfl that the CC is the wrong place for membership discussions, and I further think that MC should be taking action, rather than CC in the case of someone who doesn't meet the guidelines for Contributor or MOTU. (and TB for someone who isn't meeting guidelines for Core Dev). [07:57] * minghua wonders who can push MC to make the decision, though. [07:58] persia: well kinda, correct place for membership disscussions, wrong place for contributor/motu revocation [07:58] minghua: Push MC? It's just been formally brought for consideration a little while ago, and it's a weekend. [07:58] cc has always been the membership place [07:58] persia: Doesn't mean they'all actually do anything. [07:59] imbrandon: I disagree. We're too big. membership should be granted by LoCo coordination team, MC, Documentation team, maybe someone else if I'm missing part of the structure. [07:59] persia: granted, yes, revoked no [07:59] ScottK: Wait a week. I might agree with you, but will give them the benefit of the doubt first: this is the first removal request. [07:59] revokation is a rare ( hopefully ) thing that should be handeled by the cc ( the overseer of the smaller teams ) [08:00] persia: Agreed. I understand it'll take some time. [08:00] imbrandon: I still think it's a team decision, rather than a full community decision, but won't argue the case now. [08:00] imbrandon: That was my thought too, but jono told me to take it to the MC. [08:00] persia: ummm thats the cc's job, voice of the full community [08:00] * persia notes that the party under discussion isn't a member, this is a case of them being barred from development contributions, not a case of losing membership. [08:01] persia: And why would that make a difference? [08:01] imbrandon: Do you read the CC meeting logs or attend? It's not a functional forum when dealing with minutiae. Further, if membership is delegated to teams, that should be full delegation, not partial delegation. [08:01] probem is he can always create another account [08:01] :( [08:02] imbrandon: True, but it won't be hard to figure out it's him again. [08:02] not with the same email [08:02] wasn't there a talk on google video about poisonous people? [08:02] He has a 'unique' signature. [08:02] minghua: Because if someone was a member, and was losing membership, I'd be a little more sympathetic to the idea that it was for a larger body to consider. I'd still prefer team leadership making a decision, and CC acting as court of final appeal. [08:02] persia: Also, I think MC should have been aware of this issue for a while. [08:02] pwnguin: yea from the svn devs [08:02] imbrandon: perhaps a decision from the MC will carry enough weight to "send the message" [08:03] minghua: I'm personally disappointed I had to do this. He's clearly been disruptive long enough I think they should have stepped in. [08:03] minghua: Yes, but awareness and formal consideration are different. MC considers each issue on prosented merits, not based on arbitrary external knowledge. In the spirit of transparency, I think this is a good thing. [08:03] s/prosented/presented/ [08:03] persia: And you think in this case, banning a non-member to participate development only requires the MOTU team's decision? [08:03] persia: it also makes someone else have to become the "proscecuter" [08:04] elect themselves proscector even [08:04] minghua: Yes. If they want to contribute to advocacy or docs or translation or whatever, that's for that team to consider the quality and benefit of contributions. [08:04] pwnguin: Yes. That makes it unlikely to be abused. [08:05] persia: Part of the problem with this approach is that what I'm asking for affect much more than his ability to participate in MOTU, but it's the needed remedy. [08:05] * minghua agree with pwnguin, and would like to thank ScottK for stepping up. [08:05] pwnguin: Yes. It means I get to quit being a developer for a while and play lawyer instead. [08:05] it also means that nonconfrontational people will be abused by "confrontational" people, because they wont elect themselves to step up when they reasonably should [08:05] Yeah. Just how I want to spend my free time having 'fun'. [08:06] pwnguin: This is the first time this has ever been done in the history of Ubuntu. I shouldn't worry to much about it becoming frequent. [08:06] ScottK: True, but you're complaint is about his influence on MOTU. He has influence in other places, but unless there is another team also wishing for a full ban, it's difficult to see why CC cares. On the other hand, of DocTeam or Translations, or LoCos wants it too, then it's more of a CC issue. Testimonials from LoCo seem strong, so I remain convinced it's a MC issue. [08:07] OK. [08:07] s/you're/your/ [08:07] testimonials are always strong [08:07] * ScottK just wants it done. [08:07] pwnguin: True, but volume counts. If LoCo is seeing strong contributions, LoCo should be able to continue to receive them, regardless of MOTU ban. [08:08] if loco wants him, sure, i guess [08:08] persia: You mean LoCo team's testimonials are strongly in favor of his contributions? [08:08] persia: presumably within the LoCo [08:09] minghua: That's the impression I had from his wiki page. [08:09] pwnguin: Yes. [08:09] Hmm. A bit hard for me to comprehend. [08:09] persia: I disagree. People this disruptive should not be allowed a voice in the Ubuntu governance process (which is what membership give you). [08:10] im thinking though that if you get kicked out of one team for personality conflicts or whatever, then future applications should note this [08:10] minghua: He's enthusiatic and energetic, and not particularly careful. This is bad for MOTU, but can be good for advocacy, depending on where the care slips. [08:10] persia: I don't care what he does in a loco. [08:10] persia: I also disagree he has potential to be good in a loco. [08:10] persia: He's where he is because he doesn't listen to other people and has no idea (or doesn't care) what is helpful or not. [08:11] That's not good in a loco either. [08:11] "not particularly careful" means "potentially harmful" wherever. development or advertising [08:11] ScottK: I'm not advocating membership, just stating that I believe that teams should have quasi-independent governance, and that I'm not involved enough in LoCo to make a determination, but that the testimonials are strong. [08:11] pwnguin: True. I still believe it's a LoCo call, and not a MC call. [08:11] persia: I agree in general, but I think it would be wrong for another team to give membership to someone who'd been kicked out by MC. [08:11] persia: i guess farming out advertising to the LoCos also involves assuming some of that risk anyways [08:11] persia: Depending on what the LoCo team does, I guess. I'm still skeptical. [08:12] ScottK: Without first getting approval from MC, I'd agree. [08:12] pwnguin: Yes. [08:12] i dont know this individual and have somehow managed to avoid disvovering their negative impact [08:12] minghua: I can't say: I'm not involved in LoCo. [08:12] persia: OK. Well that's what I thought you were arguing for when you said it should be independent. [08:12] pwnguin: It hasn't been very voluminous recently. [08:13] i did hear something about a promise that gimp final would be in gutsy [08:13] pwnguin: Pull down the ubuntu-motu IRC logs for July and August and grep for Kmos. [08:13] pwnguin: That was one of his later stupidities. [08:13] I'm not exposed to much of his behavior either, but what I've seen is pretty much 100% bad. :-( [08:13] ScottK: quasi-independent. We're all Ubuntu. We're all bound to the CoC and CC, but I believe we're too big to track easily, and that the larger teams should be handling membership and assignments. The teams need to coordinate, but we can't know everyone anymore. [08:14] persia: I agree with that in general. [08:15] ScottK: can you imagine any process of reconciliation, or is this a personality conflict? [08:15] pwnguin: It's not just me. It's everyone who's worked with him. [08:15] I'm much more in favor of policies being set "in general", and specific cases compared against those policies. If nothing fits, the policies may be adjusted, but should still fit "in general". Specific policies are just bad, and setting rules to bar specific things is bad: we'd do better to have a guideline such as "works well with others" to cover any specifics that cause issues. [08:16] ScottK: im saying more along the lines of, two or three years from now, the dude mellows out, gets meds or theraputic cluebat applications. should he be banned for life? [08:16] pwnguin: We've given him about a hundered chances and bent over backwards trying to get him to focus in on doing stuff he can be productive at and he just won't. [08:16] (different meds) [08:17] pwnguin: Who knows. That's why I put something about a path back in into my request. [08:17] * pwnguin should probably read the request now [08:17] persia: You know you aren't kidding. He blamed psychiatric medicine once for why he messes up. [08:17] ScottK: Is the request publicly accessible? [08:18] minghua: Yes. It's to the MC mailing list. [08:18] No, I'm not kidding. I wish the best for him, but don't feel he's a helpful contributor at this time. [08:18] kinda sad. being fired from a volunteer position [08:20] Yes. [08:22] pwnguin: It actually happens quite often in offline communities. The people who want to help are not always the people who can help. [08:22] pwnguin: lists.debian.org seems to have gone away for a bit, but here's the Google cache version of the analysis of his contribution to debian-games: http://64.233.169.104/search?q=cache:Vnt6aZoH_XUJ:lists.debian.org/debian-devel-games/2007/10/msg00038.html+http://lists.debian.org/debian-devel-games/2007/10/msg00038.html&hl=en&ct=clnk&cd=1&gl=us&client=firefox [08:23] is he an motu, or just a hopeful? [08:23] pwnguin: Hopeful. [08:23] pwnguin: Neither. He's publically stated he has no intention of becoming MOTU: he's just a Contributor. [08:23] pwnguin: Although he sometime claims not to be actually trying to become a MOTU so some of the rules don't actually apply as a reason for mistakes. [08:24] pwnguin: What persia said. [08:24] Don't get me wrong: I'm in full support of Contributors who don't wish to take the responsibility of MOTU, but this is a special case. [08:29] I am against any Contributor who use "I have no intention to become an MOTU" as an excuse for mistakes. [08:30] would it be any better if they did have an intention to be an MOTU and did this? [08:32] No. [08:32] Such people shouldn't contribute. Period. With intention or not. [08:33] Why not? [08:33] pwnguin: In that case, correction could involve a note that MOTU would be harder to achieve. In this case, we have less moral leverage. [08:33] StevenK: Because their contribution has a substantial negative value on the project. [08:33] They have pet bugs, but they don't want the responsibility to upload to the archive. And? [08:33] By such, I mean "people make mistakes and not willing to correct or learn". [08:33] StevenK: I hope I've answered your question. [08:34] minghua: Ah, the not contributors versus non-contributors [08:34] Hello StevenK. [08:34] * StevenK waves [08:34] StevenK: Huh? Sorry English is not my native language, that's too subtle. [08:35] minghua: s/\(the\) \(not\)/\2 \1/ [08:35] minghua: People who actively cause extra effort for others as opposed to people who have only peripheral interest. [08:35] (or don't do anything at all) [08:35] Err, RegExp is not my native language either... :-) [08:35] minghua: he was attempting to make a distinction between two identical ideas [08:35] which is bound for failure [08:35] minghua: Gaah :-) [08:36] StevenK: I understand now. :-) [08:36] StevenK: But why do you need to escape the parantheses? [08:37] minghua: Because it's sed. [08:37] And sed is "special" [08:37] One *ALWAYS* escapes parentheses for real regexes. Perl got it wrong, and is for lazy people without backslash keys. [08:37] StevenK: Thanks. Good to know. [08:38] More what persia said, though. [08:38] interesting [08:38] does kmos have a lp account? [08:38] pwnguin: gothix I think. [08:38] pwnguin: Yes, used for multiple projects, and should not be purged. [08:38] Just highly restricted. [08:39] im just trying to find it [08:39] pwnguin: https://launchpad.net/~gothicx [08:40] I'm going to bed now. Good night all. [08:41] Good night ScottK. [08:41] If anyone sees fabbione around please give him a good thwack on the head from me for re-uploading openssl097 to the Gutsy partner repository with an open remote exploitation vulnerability unpatched. [08:41] good night minghua. [09:09] ScottK: excellent mail [09:16] ScottK: btw....finding people from irc spheres who have authority won't be hard. [09:17] Hobbsee: It's a matter of the decision being made by the right authority. Having a witchhunt is easy, but doesn't help really :( [09:18] persia: granted, but the irc operators have the right to act if a person is being disruptive enough, in any #*ubuntu* channel. [09:18] irrespective, really, of what the governing body and beurocratic process is up to. [09:19] or of people's statuses in the community. [09:19] Hobbsee: Sure. I'm just not convinced that this is a case of someone being in-channel disruptive, as opposed to being development-disruptive, and prefer the right solution to an IRC ban. [09:19] persia: i was only talking the case of him being disruptive in-channel [09:20] and also mentioning that it would not require going thru the MC council, getting them to weigh in, etc, on whether they thought it was necessary [09:20] Ah. I expect swatting for that, as with all disruptors: the IRC Ops team is evervigilant, and to be commended for keeping things so clean. [09:20] over a matter of a simple ban [09:20] i think i've done so once, over a consistantly disturbing individual, "attempting" to help. [09:21] muted him in all development-related channels, and #ubuntu+1. he eventually behaved, after that. [09:21] well, attempting to get his bug solved. [09:21] wouldn't listen, etc. [09:22] Sounds familiar. I'm glad there is precedent. [09:23] although i was fortunate, in that he didn't try very hard to contest the global gagging. [09:23] * persia gets annoyed at aptitude and un-NBS's everything installed locally except X stuff. [09:24] oh, and uh...the irc team doesn't take kindly to any of it's members being harrassed, so he really had no chance of winning. [09:24] Hobbsee: That's a good thing, but if you're just doing your job, I wouldn't worry about contest. It's the rare case where you'd be called down for it. [09:24] persia: we do...often enough. [09:25] Get called down, or have people contest bans? [09:25] unsure what you mean by getting called down [09:25] Hey! You!. Get down and grovel and apologize because you overreached your authority! [09:25] persia: we even had a guy today, complaining about -in ops. i pointed out the 5 rules he'd managed to break, and what he was doing, and said that he should have been banned earlier than he was. he shut up somewhat, thought about it, then went and apologiesd to the -in team. [09:26] persia: yeah, we get that slightly. some people get a little trigger-happy, particularly in userland. you know, after you've kickbanned 5 people, and it's before lunch time... [09:26] That's the behaviour I'd expect, and I'd expect other IRC Ops to support any IRC Op who made a call, as I doubt there are many cases of abuse (and expect near instant loss of IRC Ops rights if there was) [09:26] contesting bans happens a fair bit - people come in all angry, occasionally get banned from there too for a few hours [09:27] sometimes they come back and apologise later. [09:27] there are some. *shrug* [09:27] it's not clear cut [09:27] I'd expect frequent contests: there needs to be room for appeal, but as long as the operators are generally considered fair, and the channels are good, life is good. [09:28] just wait till you hear the discussions about irc censorship :) [09:28] There are far too many ways around any and all means of IRC banning for me to seriously consider IRC censorship. [09:30] heh [09:30] well, it's somewhat distracting if you've got the kline-on-sight status [09:31] Right. So I use a web IRC gateway and a different nick. Not too hard. [09:31] there are limited irc gateways [09:31] not really [09:31] and some of them just ban gateways, so your'e still stuffed. [09:31] Hobbsee: But there are unlimited open botnets... [09:32] persia / ScottK : http://www.imbrandon.com/2007.12.02/ugh.html [09:32] persia: this is true, and there are ways around them, too [09:32] ah, every internet problem comes down to microsoft being bad at network security =( [09:32] As long as I run a muted log user from a different source, I'm able to follow conversation, and just need to push anything I say from a relay. [09:33] imbrandon: s/Gusty/Gutsy/ [09:33] imbrandon: As slangasek pointed out, it's only a case where the remove management port is enabled, and there's not a PoC available. [09:36] Hobbsee: fixed, persia reworded [09:36] imbrandon: :) [09:37] pwnguin: Botnets were available before microsoft, and will be available after microsoft. Anyway, I think the difficulty of imposing true IRC censorship is a good thing. [09:41] Hello, I need help with piuparts, I run 'piuparts -d gutsy -p ', but it doesn't work, as it can't get debfoster, I found that debfoster is in universe, yet piuparts for some reason uses main & restricted only, can anyone help ? [09:46] ScottK: Aaaaaargh. Their problem, anyway. [09:50] mr_pouit: as you sponsored the dir2ogg merge: what's the reason behind "- Don't use new VCS-* and Homepage fields as the new dpkg has not been merged yet [09:50] "? [09:50] geser: Because they don't get passed to the binary package, as dpkg-strips them (no XSBC). [09:51] * persia hopes for a dpkg merge soon, as we're damaging heaps & heaps of stuff with the syncs, never mind uploads [09:51] persia: but is this important enough to undo the changes in the Debian package? [09:51] * Fujitsu wonders why it wasn't merged months ago... [09:52] geser: Undoing it is good. [09:52] * geser hopes that dpkg gets merged soon as there are packages FTBFS because of a to old dpkg [09:52] geser: Well, if we don't undo it, we'll need to push a new update later anyway. We have to do this for several thousand packages, so I'm not sure which is right. [09:52] Fujitsu: uploaded htdig fix via QA upload, thanks for the patch [09:53] white: Is the QA miniconf still underway? [09:53] white: Danke. [09:53] Fujitsu: :) [09:54] Ah, just got the -commits mail. [09:54] persia: ? [09:54] persia: i am not in extremadura [09:55] white: Ah. So Yes, but you're not there. Thanks. [10:17] no one knows about piuparts ? [10:19] AnAnt: are you using an existing pbuilder base.tgz or a new one? [10:23] * Fujitsu blinks. Why are there some bugs tagged with bugXXXXXX, where XXXXXX is some other bug? [10:25] RainCT, wow, you triaged my needs-packaging bug fast! [10:26] Fujitsu: ... Interesting [10:26] tsmithe: hehe :) [10:26] * RainCT cheats and has a script for it [10:27] haha, but still... [10:28] yes, you had luck :). I usually only run it once a day [10:28] geser: existing one [10:29] AnAnt: and it has universe enabled? [10:29] geser: yup [10:33] AnAnt: have you used "-b /path/to/your/pbuilder/base.tgz"? When I read the manpage correctly a new chroot gets created when you don't specify it [10:34] AnAnt: I used the piuparts deb from Debian as the gutsy one has some problems [10:34] geser: I ran: sudo piuparts -d gutsy -p [10:34] geser: it fetches /var/cache/pbuilder/base.tgz [10:35] geser: that's the base.tgz that I use when I run pbuilder to build packages [10:35] ok, I didn't play much with pbuilder yet [10:37] geser: if I do pbuilder login, I can do apt-get install debfoster [10:37] I just can't get it [10:50] AnAnt: sorry, I meant piuparts but typed pbuilder: I didn't play much with piuparts yet [10:50] so I should try the piuparts from Debian ? [10:52] I had some problems with the piuparts package from gutsy but I don't remember anymore which problem it was [10:57] Hi, with my package http://revu.tauware.de/details.py?package=cpptest it's been suggested I symlink the docs for the -dev package to the lib package. However I don't know how to do this. I can create links in cdbs using the packagename.links however because the dir already exists it complains. [10:59] DaveMorris: I think you want to not create /usr/share/doc/libfoo-dev and symlink that to /usr/share/doc/libfoo, but I'm not sure of the implementation details. [10:59] yeah I just don't know how to tell cdbs to do that [11:00] geser: I used Debian's piuparts, still same problem [11:02] DaveMorris: you probably want to use a debain/.links file [11:02] * imbrandon is off to bed, gnight all [11:02] Night imbrandon. [11:02] imbrandon: I did, however it complains that the dir already exists [11:03] because the docs are installed to the same path as what the symlink will be [11:03] why would i be getting assembler errors in my pbuilder that don't happen outside of it? [11:04] DaveMorris: Then don't install any docs or changelogs for the -dev package [11:04] how do I do that? [11:04] tsmithe: Different library versions? [11:04] why should that be the case, if I'm using the same distribution for each? [11:05] DaveMorris: Don't have debian/libfoo.docs and pass some magic to dh_installchangelogs to exclude that package (I don't know which CDBS variable needs setting, but you can probably find it in the debhelper.mk include file) [11:05] tsmithe: Perhaps one or the other isn't 100% up to date, or you have a | supported alternative locally. [11:06] hmm [11:06] i'll update my main system, but i still think it's odd that the error occurs in the process of compiling a c++ file ("/tmp/ccYzfS81.s:12998: Error: unbalanced parenthesis in operand 1.") [11:06] DaveMorris: Sorry: I meant "don't have debian/libfoo-dev.docs". My apologies for any confusion. [11:08] I knew what you meant, I just can't find the option to tell cdbs not to make the docs. As I was thinking along the same lines as you guys last night [11:08] bug 173415 [11:09] Launchpad bug 173415 in malone "Please perform a massive tag purge for the Ubuntu project" [Undecided,New] https://launchpad.net/bugs/173415 [11:09] bug 2345 [11:09] Launchpad bug 2345 in eclipse "Dependencies for eclipse-sdk are not installable/don't exist" [Medium,Fix released] https://launchpad.net/bugs/2345 [11:09] DaveMorris: CDBS calls dh_installchangelogs -p$(cdbs_curpkg) $(DEB_DH_INSTALLCHANGELOGS_ARGS) $(DEB_INSTALL_CHANGELOGS_ALL) $(DEB_INSTALL_CHANGELOGS_$(cdbs_curpkg)) which gives you a few opportunities to add arguments. /usr/share/cdbs/1/rules/debhelper.mk has some comments at the top that might help you choose which. [11:10] Hei everyone, Ive just got 1 quick question. if I have a patch form someone in .diff format intended to patch a library, what is the way to apply this? note, its not a debdiff.... [11:10] jussi01: patch -p# < ../patch [11:10] from the source dir [11:11] jussi01: a debdiff is just a special patch [11:11] jussi01: Unpack the package. Check the patch system. Prep the package to accept a patch. apply the patch. Exit the patch system helper. Edit the changelog. Build the source. Ignore Hobbsee for now. [11:11] hehe [11:11] * persia notes that Hobbsee is correct, but not complete [11:12] oh, i was assuming that the patch was fine to apply and such. [11:13] can someone please look at the gtk-engines-mono FTBFS: http://launchpadlibrarian.net/10688624/buildlog_ubuntu-hardy-amd64.gtk-engines-mono_0.0.5-1build1_FAILEDTOBUILD.txt.gz [11:13] is this a bug in dh_strip or in the package (I build it successfully in a pbuilder)? [11:14] * persia doesn't know C#, but tries it in a sbuild environment [11:14] persia: it has nothing to do with C# [11:14] !info gtk-engines-mono [11:14] gtk-engines-mono: Mono theme for GTK+ 1.2. In component universe, is optional. Version 0.0.5-1 (gutsy), package size 24 kB, installed size 140 kB [11:17] Really? I thought all the mono stuff was C#. I'll dig more then. [11:17] persia: It's just a theme called Mono. [11:18] Bad, bad name choice. :-) [11:18] Well, I can reproduce the build failure at least. [11:19] persia> Not all of Mono is C#, there's also VB.NET -_- [11:20] LucidFox: Sure, but that's special, and can be safely ignored. [11:20] it looks like dh_strip expects debian/gtk-engines-mono but the package uses debian/tmp (it's an old package) [11:23] To me it looks like missing includes, as the new GCC is very picky. I thought that all of those were filed as bugs in Debian, usually with patches, but the Debian servers aren't being very helpful right now (for me). [11:26] persia: you're talking about the gtk-engines-mono package? did you get an other build failure as the buildds? [11:26] geser: I get the same build failure as the buildds. [11:26] Directory debian/gtk-engines-mono does not exist, aborting [11:27] On the other hand, I appear to be investigating a non-build failure problem with the package, and have stopped :) [11:28] well, this is nice.. even the author of the software doesn't know what the stuff does [11:28] Looks to me like the problem is with pkg-create-dbgsym [11:28] persia: I've successfully build the the package in a pbuilder (but without the dh_strip version from the buildds) [11:29] geser: If you put pkg-create-dbgsym in your pbuilder, can you replicate? [11:29] persia: will try [11:30] * persia highly recommends the use of pkg-create-dbgsym and pkgbinarymangler in chroots for pbuilder & sbuild. [11:32] persia: with pkg-create-dbgsym I can replicate the FTBFS [11:33] geser: Right. Ask pitti if you need to adjust it, but that's likely the source of error. [11:33] ok, thanks [11:36] Debian bug #385245 [11:36] Debian bug 385245 in bsdutils "renice succeeds on garbage input" [Normal,Open] http://bugs.debian.org/385245 [11:36] Err. Debian bug #386246 [11:36] Debian bug 386246 in debhelper "debhelper: scripts silently succeed on nonexisting package build dir" [Normal,Open] http://bugs.debian.org/386246 [11:39] geser: It looks like the package built with the default dh_strip doesn't actually get stripped due to 386246. Best to force the right tmpdir (which may be debian/tmp, but this needs to be clear to debhelper). I suspect there's some other oddities as a result of the confusion. [11:41] persia: I will talk to pitti about this FTBFS on monday [11:42] geser: Look at bug 386246 and the changelog for pkg-create-dbgsym 0.17. It's intentional, and the expectation is that the packages will be adjusted so that debhelper gets the right value for tmpdir. === DarkMageZ_ is now known as DarkMageZ [11:50] Hobbsee: Please give back gnustep-base on lpia, let's see if that convinces to build [11:50] * Fujitsu convinces it to not build. [11:50] * StevenK kicks Fujitsu [11:51] * Fujitsu cackles evilly. [11:51] In the face [11:51] Damn. [11:51] * Fujitsu goes back to mplayer CVEs, then. With no teeth. [11:51] Hah [11:53] StevenK: looking at the build log for gnustep-base on lpia: line 72 in debian/rules is 'error "unsupported architecture"' [11:53] Hobbsee: Ah, then never mind me, I'll belt it [11:54] that's inside the block which checks the ffi lib settings based on the arch [11:55] So it just needs to be taught that lpia == i686 === azeem_ is now known as azeem [12:16] * persia is late again === persia changed the topic of #ubuntu-motu to: Ubuntu Masters of the Universe: https://wiki.ubuntu.com/MOTU | Hardy Heron is in active development. | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Go Merging! http://dad.dunnewind.net/universe.php | QA resources from http://qa.ubuntuwire.com | It's REVU Day. Uploaders: please refresh your uploads, and ask for review. Reviewers, let's close all the open reviews from the top of http://revu.ubuntuwire.com/ [12:18] * Fujitsu tut tuts. [12:19] it's monday again? [12:19] At least this time I have an expectation of not having a network failure, and might end it on time. [12:19] geser: Yep. Has been for 139 minutes now. [12:20] Only 6 packages to review though, so it'll be a boring REVU day (unless we get a lot of uploads). [12:22] persia: I'll get my next versions uploaded to REVU ASAP [12:23] persia: Your advocation on sdlmame-cheat looks bogus. [12:23] Oh, I see. [12:23] Fujitsu: Even with the note that it is intentional? The only issue is a single '.' character and some wishlists. [12:23] I just saw said note, oops. [12:24] On the other hand, until sdlmame gets in, sdlmame-cheat is largely useless. [12:24] Fujitsu: No worries. I added the note because another reviewer came to the same conclusion. [12:25] ajmitch: bug 145520 - how does libapache-filter-perl relate to khalkhi? Oo [12:25] Launchpad bug 145520 in khalkhi "[UNMETDEPS] khalkhi has unmet dependencies" [Undecided,Confirmed] https://launchpad.net/bugs/145520 [12:26] apachelogger__: Look at the note in the first comment. [12:26] persia: yeah that one is valid, but the orignial comment is kinda strange [12:26] persia: anyway, do you think that's reason enough for an SRU? [12:27] apachelogger__: If the package cannot be installed, and it could be installed in a previous release, then it counts as a regression. If it could never be installed, it doesn't count. [12:27] (check the unmetdeps output for previous releases to decide) [12:28] persia: gutsy was the first release for khalkhi [12:28] the missing package just got stuck in new queue [12:28] hence didn't make it into the release [12:28] apachelogger__: Then unless there's some other compelling reason, it doesn't count for SRU. This is especially true for NEW, as NEW for SRU makes the archive-admins cry. You might consider a backport. [12:29] ok, thanks a lot [12:30] apachelogger__: No problem. Also, if there is a compelling reason, you can ask an archive admin, just be prepared for them to say "No". [12:30] (and when ~motu-sru comes back, ask them instead of bothering the archive admins) [12:31] ok [12:31] though I don't think there is a compelling reason, khalkhi is a metapackage [12:33] * Fujitsu heads to bed. [12:33] Good night Fujitsu [12:33] Night persia. [12:38] Hi. I have a few questions regarding a revu feedback I hope someone can answer. [12:38] The package in question is: http://revu.tauware.de/details.py?package=mumble [12:38] 1) Please add a color to the (LP: #129081) stanza in the changelog: it doesn.t currently close the bug. [12:39] How do I add color to a changelog? [12:39] slicer: I think they mean 'colon' [12:39] StevenK: It suddenly makes much more sense then. [12:39] Although n and r are not close on a US keyboard === LifeHacker is now known as tuxmaniac [12:40] I'll interpret it as colon and fix it. [12:40] Next up: 4) Consider linking to /usr/share/common-licenses/GPL-2 for GPKv2 code [12:40] Linking what? [12:41] slicer: That is probably telling you fix up your debian/copyright file [12:42] THat's probably related to: 6) It would be nice to include licensing for the packaging [12:43] Though I'm not sure how that is different from the debian/copyright? [12:43] slicer: Pastebin your debian/copyright, I'm sure we can pick it to bits [12:43] !pastebin [12:43] pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) [12:44] Hobbsee: The Ubuntu pastebin is not there, but http://paste.ubuntu.com/ [12:44] Also, "a service to post large texts" reads wrong. :-) [12:44] http://revu.tauware.de/revu1-incoming/mumble-0711180130/mumble-1.1.1/debian/copyright [12:44] * persia notes that n & r are also not close on a jp106 keyboard, but that fingers don't always follow directions very well. [12:44] .. should do, right? [12:45] slicer: You should point at /usr/share/common-licenses/GPL-2 [12:46] Ah, instead of just /GPL? [12:46] slicer: Right. [12:48] hello [12:48] ubotu: pastebin is A Pastebin is a service where large texts can be posted as an alternative to flooding IRC channels. The Ubuntu pastebin is at http://paste.ubuntu.com/ . After pasting, please copy the URL of the paste to the channel so others know where to find your data. [12:48] is ubuntu's dpkg already supporting the new Homepage field ? [12:48] jeromeg: It complains, but that's all [12:49] jeromeg: No, but we're pretending it does. [12:49] mok0, persia : ok [12:49] and where exactly am i supposed to put it in debian/control ? [12:49] I can't find any doc for this [12:50] just debian usage stats [12:50] jeromeg: If there is a single homepage for the entire package, put it in the source stanza. If there are separate homepages for the binaries, put them in the binary stanzas. [12:50] jeromeg: I don't think it matters. Somewhere in the source package section [12:50] persia, mok0 : ok thank you both [12:51] how extensive does the copyright information in debian/copyright need to be with regards to source files? [12:52] tsmithe: Every file that has a distinct license needs to be mentioned. [12:52] imbrandon: There? [12:52] persia, but not a distinct copyright owner? [12:52] Hi minghua, I addressed your comments for maxima [12:52] because there can be lots of those, and this is already mentioned in the source files themselves [12:52] minghua: It's 6am there, I doubt it. [12:52] imbrandon: Just to let you know that *all* your blog posts show up on Planet Debian, which you probably don't want. [12:53] StevenK: I prefer to think you're staying up late ;-) [12:53] StevenK: It's more like 7am, but it was worth a shot. [12:53] mok0: Great, thanks. [12:53] tsmithe: If all the licenses match, and all the copyright holders are listed in debian/copyright, you don't need to specify all the files (I believe). [12:53] ok [12:54] minghua: Well thanks for your very clear comment. I was wondering whether it was necessary to put the "old" mods in there. I see the logic of it now. [12:55] mok0: https://wiki.ubuntu.com/UbuntuDevelopment/Merging should help, but I have no idea how accurate that page is. [12:55] mok0: In case of uncertainty, ask here. :-) [12:58] persia, but i'm not allowed to do something like "(C) 2007 Werner Schweer and others". ie, i have to list every contributor? [12:58] minghua: yeah I should've done that [12:58] minghua: but now I've learned it [12:58] tsmithe: I believe so, unless the other contributors have explicitly indicated that they don't mind being referred to as "Werner Schweer and others". [12:59] ok [12:59] mok0: Hope you can find a sponsor soon. If you have trouble finding one, let me know. [13:00] Have any of you guys experience with hacker attacks? [13:00] minghua: ok, thx [13:00] mok0: Could you rephrase that? [13:00] We've had a visit from a hacker that propagated some attack on a website in France [13:01] I think he got in through webmin, but I am not sure [13:01] persia, what about wrt to "Upstream Authors", if their names are given in "Copyright:"? [13:03] tsmithe: Authorship and Copyright are only coincidentally related. For many large projects, there is considerable copyright assignment (most contributors assign copyright to the core team when sending patches). [13:03] I got a message from CERT about it [13:03] :-( [13:04] persia, ok then. so i'm just going to give the primary author of the majority of the code, and list the copyright holders for other parts [13:04] mok0: Ah. Someone penetrated your system. I don't like the term hacker for that. I recommend 1) getting affected systems offline, 2) putting in replacements, and 3) doing a forensic analysis to find how when and how so you can notice next time. [13:08] * minghua had a system compromised before. [13:08] * persia doesn't have anything useful to say about the remaining uncommented items on REVU, and would welcome an upload. [13:08] I'm not the admin, though. And it was a remote xen machine, so we simply reinstalled it. [13:09] minghua: reinstall without forensics can often mean renewed exploit [13:10] persia: True. But it was not my decision. [13:10] persia: And that machine was a bit behind on security updates when it got compromised. [13:11] imbrandon: sorry, pretend I'm not really here, but about PPA removals, you have to start uploading new stuff to trigger the cleanup procedures in your PPA. [13:11] persia: yeah I agree that the term "hacker" has multiple meanings. I should've said a "script-kiddie" [13:11] imbrandon: see a similar saga in https://answers.edge.launchpad.net/launchpad/+question/17826 [13:12] An inexperienced colleague installed webmin. I would *never* use it [13:12] * cprov-out goes out again. [13:13] mok0: I've run rkhunter and it doesn't find anything suspicious [13:15] how do I send a patch upstream? [13:16] effie_jayx: Just attach it in an email [13:17] effie_jayx: I prefer a -p0 patch from the top dir [13:18] mok0, what is the standard format for sending these patches upstream [13:18] effie_jayx: output from diff -u [13:18] effie_jayx: ... or diff -urN if you do the whole dir [13:19] effie_jayx: I would think upstream wants separate patches for each file you have modified [13:21] mok0, I'll give it a wack [13:21] and I shall let you know later [13:21] I am hunting for a bug :D [13:21] effie_jayx: I'll be on the channel for a while [13:21] mok0, great :D [13:22] effie_jayx: I enjoy reading your blog, btw! [13:22] mok0, it was a suggestion and I really haven't a clue as to howto... is there some doc I can read? [13:22] effie_jayx: ?? [13:23] effie_jayx: you mean how to diff? [13:23] mok0, yes [13:24] effie_jayx: You can do it in a couple of ways. Either, directory wise, or on a per-file basis [13:24] http://wiki.ubuntu.com/Bugs/HowToFix has some basic guidelines on running diff. [13:24] So, either you have 2 parallel directories, foo/ and foo-orig/ , say [13:25] I usually just make a copy of the file I am fixing -> foo.c.orig [13:26] effie_jayx: If you compare 2 dirs, you need the -r switch on diff [13:26] mmkey [13:26] * persia tends to do it by directories, so as not to have to start over if more than one file needs an update. [13:26] sounds easy [13:26] Possibly -NP, too, depending on how complex the changes are [13:26] effie_jayx: Try it, with a dummy file created for the purpose [13:27] * mok0 prefers diffs on a per-file basis [13:28] you can always cat the patches together [13:28] lsdiff is a nice tool for looking in diffs [13:28] ok... when I say upstream... it is ... debian... or the team that distributes the software? [13:29] mok0: Maybe, but cat doesn't track directories if they aren't at the same level, whereas splitdiff always works. [13:29] effie_jayx: team [13:29] persia: you are right [13:29] * persia hugs patchutils [13:30] :-) [13:30] effie_jayx: Once you get comfortable with diffs (alias patches) you start thing in those terms [13:31] s/thing/thinking === Hobbsee_ is now known as Hobbsee [13:31] I see :D [13:32] effie_jayx: a bit of nomenclature: a "-p1 patch" is one that is based _above_ the top level [13:33] effie_jayx: and a "-p0 patch" is one that is based _at_ the toplevel dir [13:34] effie_jayx: (top-level == the one that has debian/) === jekil2 is now known as jekil [13:35] * persia advocates -p1 patches as easiest to use [13:37] I would like to know more about levels and stuff [13:37] let me check my facts [13:37] I have the original directory [13:37] and the one I modified [13:38] I do a diff between those directories [13:38] diff -uNr orig/ modif/ will give you a -p1 patch [13:38] ok [13:38] imbrandon: is your request from donations going to actually work? [13:38] I am trying it know [13:39] effie_jayx: when you have the diff, you should try and see if it works. Make a copy of the orig directory in /tmp [13:39] I think it's a neat idea for collecting for a large present, and am very curious to see how it works. [13:40] effie_jayx: then: cd /tmp; patch < your-diff.patch [13:40] persia, it has helped people pay off large debts [13:41] persia, http://www.savekaryn.com/ [13:42] effie_jayx: I was specifically referring to the use of www.fundable.com, but in the abstract, yes. [13:46] persia: Wow, that could be a huge scam [13:55] persia: You have time to discuss my theseus upload? [13:55] mok0: Yes, but not huge volumes. Can you remind me of the URL? [13:55] mok0, I have done the patch and I tested it... [13:55] quite lenghty [13:56] effie_jayx: did it work? [13:56] yes [13:57] persia: http://revu.ubuntuwire.com/details.py?package=theseus [13:57] effie_jayx: :) [13:57] mok0, thanks ... :D lots info just one bug [13:58] mok0: OK. Let's go through my comments. Any questions about #1? [13:58] persia: ad 1) should I make a new entry in changelog, promoting from ..ubuntu1~ppa1 -> ...ubuntu1 ?? [13:58] Right. [13:59] persia: I had the discussion about the lengthy changelog with someone here, and the conclusion was, that if the package has been published on a PPA, then you need to retain the changelog [14:02] mok0: OK. I can accept that, but I'm not very happy about it. Note that if your package is accepted into Debian, this will all be lost. My main objection is that I don't consider PPAs trustworthy or authoritative, and would prefer a policy of wiping so as never to have to adjudicate between competing PPAs. [14:03] persia: you mean debian will trunkate the changelog at the point it gets incorporated? [14:03] truncate [14:04] mok0: The Debian policy is to generate a new changelog for inclusion in Debian. On rare occasions this isn't done, but it's standard practice. [14:04] s/policy/practice/ [14:04] persia: I have seen that they retain comments for all the uploads though [14:05] mok0: Depends on the sponsor, but often, yes. [14:05] persia: even before it is accepted. [14:05] persia: ad 10-11) I think this belongs in rules [14:06] persia: If the original makefile had had provisions for installing, I would have used that to install directly into the package build dir [14:07] mok0: Why not just add dh_install in rules, and create debian/package.install? [14:07] Also, why not use dh_installdirs in rules, and create debian/package.dirs? [14:07] persia: I really don [14:07] I really don't like the debhelper scripts all that much [14:08] These are fairly standard, as it makes it easier to read, but if you don't like debhelper, they can be skipped. [14:08] persia: I could also patch the make file to do an install, but that seems pretty silly, when I can do it from rules [14:08] mok0: Although, in that case, I'd recommend not using dh_installdocs. It's the mix that is confusing. [14:08] * mok0 looks [14:09] persia: it's gone [14:09] You've also dh_installman and dh_installchangelogs. [14:09] Not according to http://revu.ubuntuwire.com/revu1-incoming/theseus-0711171510/theseus-1.1.5/debian/rules [14:09] * mok0 re-looks [14:10] Ah [14:10] I don't need installdocs [14:10] because of 9) [14:10] You're using it to install README (but yes, because of 9) ) [14:10] I got rid of it [14:11] OK. installchangelogs & installman? [14:11] persia: like you say, it's just the manpage [14:11] those I need, I think [14:11] but they have no package.* files associated with them [14:11] mok0: Well, I'd argue that if you're not using debhelper much, you should use install -m for those as well. [14:13] persia: hmm. So using some of the dh_install* scripts means you have to use dh_install for the rest? [14:14] mok0: No. I just personally feel it's better to be consistent. If you really don't want to, I shan't make you. Lack of advocation was for more significant issues: I just list everything I find in case the packager wants to make me happy. [14:15] persia: It's no big deal for me, I just want to understand how to best make a good package [14:16] persia: personally, I find looking at rules gives a good picture of the flow of things [14:16] mok0: I believe the best package is consistent. Basically raw, all debhelper, or all CDBS. I don't really like DBS or yada, or any of the others. [14:17] mok0: Sure, and there are many well-packaged packages that do it all in rules. [14:17] persia: OK, makes sense. I'll work on it. Finally, I have a question concerning 12) [14:17] Yes? [14:17] persia: I don't think the version no is incorporated in upstreams tarball [14:18] persia: and then watch isn't of much use [14:19] http://www.theseus3d.org/ [14:19] mok0: Hmm.. You're right. That's annoying. In that case, I encourage to you request that upstream does include a version in their tarballs so we can watch for the latest version and be sure to keep up to date. In the mean time, you might want a get-orig-source; rule to use wget to construct the orig.tar.gz. [14:19] persia: ok, I think I just made a link [14:20] You put a link in debian/copyright which is required, and have a bug for no watch file (which you can't help). get-orig-source: is encouraged, but optional. [14:21] persia: you mean I create a bug report in LP? [14:21] mok0: No need. It will show on http://qa.ubuntuwire.com/uehs/no_watch.php [14:21] persia: Ah. [14:22] (with 403 freinds - all packagers are encouraged to try to create watch files for these, and update them if required). [14:22] persia: I add put the full URL to the tarball in copyright? [14:23] mok0: A full URL is preferable. A website with a link is acceptable. [14:23] persia: I have a good communication with upstream, so it may be fixed in the future [14:23] mok0: Excellent. That makes it a lot easier to keep the software up to date. [14:24] persia: well thanks, that takes care of it. I'll work on the package and upload it ASAÅ [14:24] ooops ASAP [14:24] mok0: Thanks. [14:32] mok0, I patch the files and it ask many questions [14:33] like ... what files to patch [14:34] personally I think the ppa changelog should go. [14:42] ScottK: so all my various fixes to get the package to work properly, I just zap that? [14:42] ScottK: I can do that [14:43] effie_jayx: try patch -p1 [14:43] effie_jayx: It has to do it without asking questions. [14:44] it also complained at me not having priviledges [14:44] ...not having priviledges? [14:46] just fixed it... [14:46] I had made a new copy as root [14:46] dummy me [14:46] heh ;) [14:48] done [14:48] it paches 5 files [14:48] before I got confused with 5 files... [14:52] effie_jayx: you should be able to: tar -xzf orig.tar.gz; patch < effie.patch; and it should work no questions asked [14:52] * txwikinger is confused [14:52] mok0, you said I should send this to the developer [14:53] mok0: incorrect. [14:54] Hobbsee: elaborate, please [14:54] mok0: you should be able to apply patches using the debian/rules apply-patches (iirc), but your statement does not cover where there are multiple patches modifying the same file, and thereofre changing line numbers. [14:54] effie_jayx: yes, if you want [14:54] (which is where patch ordering comes in) [14:55] Hobbsee: he is making a diff -urN patch [14:55] mok0: hopefully against the already-patched source? [14:55] mok0: or just the unpacked source? [14:55] Hobbsee: against the original source from upstream. He wants to send them [14:56] mok0: oh, okay, then that's fine [14:56] Hobbsee: yup :-) [14:56] mok0: i thought you were talking about adding it to an ubuntu package [14:56] Hobbsee: no, he just wants to send a patch upstream [14:56] cool :) [14:56] this is what you get, when you come in on the end of a conversation [14:57] I know the feeling ;-) [14:58] Hobbsee: I may not know ubuntu packaging very well, but I have > 20 years of experience with programming for unix/linux [14:58] mok0: :) [14:59] Hobbsee: are you employed by canonical? [14:59] mok0: unfortunately not. [15:00] Hobbsee: I thought they were keen to hire experienced developers [15:00] mok0: i don't code python and such. yet [15:00] mok0: you also have to be wlel known, outside of the community, it appears [15:01] Hobbsee: Like, within Debian? [15:01] what should be provided for a package that needs to be updated from debian? [15:01] mok0: anywhere but ubuntu, it appears [15:01] a debdiff, or the new .dsc file? [15:02] Hobbsee: you have to author some essential, small and beautiful piece of python that they will desperately need maintained [15:02] mok0: heh :) [15:02] Hobbsee: Like a python replacement for debhelper [15:02] (which s*x bigtime) [15:04] Hi bddebian [15:04] Heya gang [15:04] Hi geser [15:24] persia, are you there still? [15:27] when and how often are packages synced from debian? [15:31] Isn't there some option to ls to just give me back the files or dirs without the path if I do: ls /foo/bar/* ? [15:36] why not use find? [15:37] txwikinger: till DIF regularly when an archive admin starts the script, after DIF on request [15:37] hey peeps [15:37] long time no see [15:39] geser: So I don't hav to do anything when a bug gets fixed by the newest version in debian? [15:39] I just wait until it gets updated and note it in the bug? [15:40] geser: if I do: find $(CURDIR) foo-* I am still going to get the path === Lure_ is now known as Lure [15:41] what do people do for media servers round here? [15:41] I want my music available on one machine so I can stream it easily to others [15:42] cbx33: check out jinzora [15:43] I don't use it myself, but I have a friend that really likes it. [15:43] hmm [16:01] Why does dpatch have to change the mode of the debian/patches/*.dpatch files? [16:02] I think it's a bug === luka74 is now known as Lure [16:12] is there a list of .desktop file "Category"s anywhere? [16:13] actually, don't worry [16:15] tsmithe: http://standards.freedesktop.org/menu-spec/latest/apa.html [16:17] gnump3d seems quite good [16:17] RainCT, thanks [16:18] bddebian: then use "(cd /foo/bar; ls *)" [16:19] txwikinger: exactly [16:20] Is there a way to know inside debian/rules what version is being built? [16:20] txwikinger: but check before if it has no ubuntu changes (can get synced) or needs a merge [16:20] geser: It doesn't need any changes [16:20] tsmithe: I've many link on the bottom of my wiki, https://wiki.ubuntu.com/RainCT/Contributions, you might find some of them usefull [16:22] txwikinger: than wait, if it's still not synced after DIF (around Dec 13th) then you need to file a sync request [16:22] ok.. thanks geser [16:22] mok0: That's what I would recommend. I'd say debian/changelog is the history of the package in Ubuntu and PPA is not Ubuntu. [16:22] geser: I got it, thx [16:25] ScottK: persia complained about it too, so I've zapped it [16:26] ScottK: perhaps you can answer my question 6 min ago [16:26] mok0: I think we ought to have a discussion about this and come to a rough consensus at a MOTU meeting and then document the results. Would you be willing to raise this as a meeting topic. [16:26] * ScottK reads the backscroll. [16:26] Can someone please merge ~rainct/ubuntu-dev-tools/dev into ~ubuntu-dev/ubuntu-dev-tools/trunk? (changelog here: http://tinyurl.com/2t6b5x) [16:26] TheMuso: ^ [16:26] ScottK: sure [16:27] mok0: There is no easy way. Packages I've seen that do that use (IIRC) sed and regex's to extract it from debian/changelog. [16:27] ScottK: I am writing a get-orig-source rule to place a tarball without a version number in the correct orig.tar.gz files [16:28] ScottK: OK; I was wondering whether there were some symbols defined [16:28] mok0: Not AFAIK. [16:29] ScottK: I'll grep it out of changelog, then [16:29] mok0: Good luck. That's the only way I know of, but it always seems fragile to me. [16:30] ScottK: yeah very flakey [16:31] ScottK: ... and they didn't exactly make changelog easy to parse === Pici` is now known as Pici [16:31] mok0: Of course not. If it was easy it wouldn't be any fun. [16:32] mok0: something like "head -1 debian/changelog | awk '{print $2}' | sed 's/(// ; s/)//' " _should_ work [16:32] ScottK: :-) [16:33] you'll have to get rid of the debian/ubuntu revision too I guess [16:34] stdin: I can grep for the chars between '(' and '-' [16:34] imbrandon: I commented on your blog post. Thanks for taking some spears on this. [16:35] mok0: As long as upstream will never release a version number with a '-' in it. [16:35] maybe change " sed 's/(// ; s/)//' " to " sed 's/(// ; s/)// ; s/-[0-9]*.*//' " [16:35] stdin: jesus.... [16:35] stdin: dpkg-parsechangelog. [16:35] ScottK: as long as it's not put in changelog [16:36] jdong: but... that would be easy... [16:36] LOL [16:36] jdong: (and thanks for letting me know about dpkg-parsechangelog) :p [16:36] well you still have to grep and sed once with dpkg-parsechangelog to get the Version: line [16:36] but it's a MUCH easier match! [16:37] jdong: thanks, but it doesn't solve my problem, it only becomes a different problem :-) [16:38] mok0: what was the original problem? [16:38] To extract the version number of the package from within rules [16:39] mok0: use dpkg-parsechangelog.... *investigates exact line* [16:40] jdong: I still have to isolate the version from the release [16:40] mok0: oh, you want only the upstream version? [16:40] jdong: yeah [16:41] mok0: dpkg-parsechangelog | sed -n 's/^Version: //p' | sed 's/-[^-]*$//' [16:41] mok0: that'll remove the last dashed item to the end from the version [16:42] which SHOULD be an okay heuristic for upstream ver [16:42] jdong: Yup, it works [16:42] show off... [16:43] jdong: should be an option to dpkg-parsechangelog, [16:43] ScottK: yea, and i likely ruffled some feathers, but oh well /* goes back to sleep for a few hours */ [16:43] XD [16:43] mok0: yeah it'd be a nice touch to have more dpkg-parechangelog params :) [16:44] * jdong hugs stdin [16:44] jdong: but if you use --version you get something quite unexpected ;-) [16:45] mok0: hehe what can I say, it's a self-centered command :) [16:45] jdong: hehe what can I say, debhelper sux [16:46] should be rewritten i python [16:46] s/i/in [16:46] ... in fact, rules should be a python script [16:47] then how would make parse it? [16:47] and not everyone knows python :p [16:47] stdin: someone will write a pymake :) [16:47] stdin: it wouldn't. The python parser would [16:47] stdin: oh oh oh ! setup.py! [16:47] XD [16:48] I barely understand Makefiles, don't make me learn python too... [16:48] I'll write up a whitepaper for it one day. [16:48] stdin: meh they have a lot in common [16:48] stdin: first off, both are anal about indents. [16:48] stdin: You'd just add statements to customize your package [16:48] everything != python, python is a great tool, but not good for EVERYTHING [16:48] imbrandon: how... dare you! ;-) [16:49] I may think about learning python yet, just for PyKDE4 [16:49] You mean, like make does not use white space in the syntax ;-) [16:49] I'm packaging it, may as well learn how to use it [16:50] mok0: no, it's just more picky about what kind of whitespace it demands. [16:50] mok0: and displays utterly nonsensical errors when you put spaces instead. [16:50] IMHO, using make to run the rules script is a mis-use of make [16:50] jdong: exactly [16:51] make is for building with complex dependencies and checking for changed files etc [16:51] with all due respect to the original designers of debian [16:52] they wanted to use standard tools which is cool [16:52] meh it seems to work so far [16:56] revu days are mondays, right? [16:56] tsmithe: remember it's already monday :-) [16:56] you're right [16:57] what are the chances of my first upload being advocated twice? [16:57] (not first ever package, mind) === davro is now known as davromaniak [16:57] tsmithe: are you taking bets? [16:58] if you want to lose, then, yes. === nianiak is now known as davro-desktop [17:13] woop: http://revu.tauware.de/details.py?package=mscore [17:18] L8R [18:21] do i need to run a special command to install/use a watch file for my debian package, or is it enough that there is a debian/watch (or must it named watch.ex?) [18:22] It should be debian/watch [18:23] You can use uscan -report-status to test that it works [18:23] yeah it works perfectly [18:23] i just wonder if i need dh_installdocs or something like that for the watch file [18:24] Nope [18:24] gencontrol installs it iirc [18:25] okay thanks a lot, as always. hopefully my package then fits all requirements [18:27] bddebian: are you are revu admin? [18:29] dsop: No, sorry === jussi__ is now known as jussi01 [19:00] dsop, some problems with REVU? [19:00] bluekuja: yes [19:00] dsop, like? [19:01] bluekuja: an admin synced my key from launchpad, but i never got a mail about an account. the revu system knows my email, but if i try to recover my password, there is no string displayed to decrypt [19:01] bluekuja: but i'm allowed to upload my signed packages into the system. [19:02] dsop, did you use two different mails for uploading/requesting-a-pwd? [19:02] bluekuja: no, i checked that twice [19:02] dsop, what's your mail? [19:03] sn_@gmx.net [19:04] dsop, you're right [19:05] dsop, http://revu.tauware.de/lostpw.py?email=sn_@gmx.net [19:07] hmmmmm [19:07] Initial release. Closes: #172309 [19:07] is that actually going to work? [19:08] apachelogger_, is the bug on LP? [19:08] apachelogger_, that works for Debian BTS only [19:08] bug 172309 [19:08] Launchpad bug 172309 in ubuntu "[needs-packaging] gcutils" [Wishlist,In progress] https://launchpad.net/bugs/172309 [19:08] dsop: please change to (LP: #172309) [19:08] apachelogger_, LP: #bugid will work not closes [19:08] ;) [19:08] apachelogger_: k, i'll change that [19:09] bluekuja: thanks :) [19:09] I wasn't sure whether it works without LP [19:09] apachelogger_, np :) [19:09] apachelogger_, if you gonna upload that remember to check .changes file [19:09] to see if Launchpad-Bugs-Fixed is there [19:10] if not get back to check what's wrong on the changelog [19:10] ok [19:11] persia will have to give his advocate first anyway [19:11] yep [19:11] dsop, can you try with another mail please? [19:12] could a kde user take a look at http://revu.tauware.de/revu1-incoming/mscore-0712021810/mscore-0.7.0.1/debian/mscore.desktop and tell me why it appears in lost+found in the menu without an icon? it works for me, with the icon as expected, in xfce [19:12] dsop, actually I cannot generate you a random pwd [19:12] apachelogger_: changed, thx. [19:12] bluekuja: what do you mean with another email? I uploaded my package with that email, etc. [19:13] siretart, around? [19:13] tsmithe: very good question [19:13] * apachelogger_ investigates [19:13] i suppose the icon problem is because the kde theme doesn't provide the icon, whereas gnome/xfce do [19:13] well [19:13] true [19:14] but lost+found? [19:14] tsmithe: does the software ship with an icon? [19:14] it's got lots of categories [19:14] apachelogger_, no, sadly [19:14] and i'm not an artist, so i won't be making one ;) [19:14] hm [19:14] well [19:15] tsmithe: you can generate a seperate desktop file for kde [19:15] if you wanna test a built package: http://launchpadlibrarian.net/10693387/mscore_0.7.0.1-0ubuntu1_i386.deb [19:15] using one of kde's stock icons [19:15] and put them both in /usr/share/applications? [19:15] i'd prefer one size fits all, naturally [19:16] tsmithe: yes [19:16] OnlyShowIn=KDE for the kde desktop file [19:16] hmm [19:16] NotShowIn=KDE for the other one [19:16] what would be an appropriate category/icon for kde? [19:17] tsmithe: can you please upload the gnome/xfce icon? [19:17] ok. where to? [19:17] anywhere ;-) [19:18] just need to have a look at it [19:19] "tango-icon-theme" provides /usr/share/icons/Tango/22x22/categories/applications-multimedia.png [19:19] oh [19:19] I think I have tango on my laptop [19:19] * apachelogger_ heads over [19:19] dsop, we should wait siretart [19:19] dsop, or Hobbsee [19:20] bluekuja: okay no problem. [19:20] dsop, so we can have a random pwd or we can check what's the problem [19:21] if it's revu day, can i ask for a review? [19:21] package is mscore [19:22] tsmithe: I'd go with multimedia for kde [19:22] just "multimedia"? [19:23] tsmithe: yep [19:23] for the icon? [19:23] * aplg|mobile nods [19:23] What happens to packages that get two advocates in REVU? [19:23] It should get uploaded [19:23] or maybe it's damned :P [19:23] Probably that too ;-P [19:24] apachelogger_, what about the category? [19:24] checking right now [19:24] Does this happen automagically? [19:25] cyberix, no [19:25] Who does uploading? [19:26] a MOTU [19:26] cyberix, maybe a developer? :) [19:26] probably the one who gave the 2nd advocate === luka74 is now known as Lure [19:26] apachelogger_, exactly [19:27] tsmithe: Categories=Qt;AudioVideo;Sequencer;Midi;AudioVideoEditing;Music; [19:27] for some strange reason kde3 can't use the Audio categorie [19:28] oh [19:28] cyberix, why do you ask? [19:28] tsmithe: that's just not spec compatible [19:28] tsmithe: if you use Audio -> Desktop entry must include AudioVideo as well [19:28] cyberix, is there a package with already two acks in REVU? [19:28] tsmithe: http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html [19:28] can I use both Audio and AudioVideo? [19:29] tsmithe: well, you can use just AV, but if you stick with A you have to include AV as well [19:29] ok [19:29] bluekuja: Not yet. Just trying to understand "how it all works". [19:29] cyberix, oh ok :) [19:29] then i can stick to one .desktop file only, and have AudioVideo as the category and multimedia as the icon, and it works on all platforms [19:29] cyberix, usually a package needs two ACKs for a certain upload [19:30] tsmithe: there is no multimedia icon in gnome/xfce, is there? [19:31] cyberix, so if someone gave you a +1 on a upload, and someone doesnt [19:31] cyberix, it will require the first ack to be given again [19:31] on the next upload [19:31] can i have Icon=applications-multimedia;multimedia? [19:31] *shrug* [19:32] * apachelogger_ tests [19:33] tsmithe: nope, doesn't work [19:33] damn [19:33] bluekuja: ok [19:33] well gnome provides a "multimedia" icon, but it looks wrong [19:33] and damn, i just started an upload [19:33] :| [19:33] tsmithe: you should suggest upstream to get himself an icon ;-) [19:36] Oo [19:36] dsop: how did you manage to have diffent md5sums for orig.tar.gz and your released tar.gz? [19:38] apachelogger_: ???? [19:38] good question [19:39] apachelogger_: you mean the one from the downloads.experimentalworks.net? [19:39] yes [19:40] maybe i forgot to push my git tags, cause the releases are generated directly from git [19:40] dsop: well, for me it's no big issue since the tarballs are identical, but I don't know how emmet.hikory thinks about this [19:41] apachelogger_, lol [19:42] bluekuja: persia usually finds some issue in packages I advocated ;-) [19:43] apachelogger_, I've noticed that some days ago browsing REVU [19:43] :) [19:43] dsop, please clean debhelper cruft in rules [19:45] bluekuja: whats no necessary? hmm the shlibs... [19:45] dsop, I mean commented stuff [19:45] dsop: rules line 24: you don't touch a configure-stamp, so no need to remove it [19:45] bluekuja: there is none [19:46] only actual comments [19:47] dsop: dh_shlibdeps can be removed [19:47] apachelogger_, check better please [19:47] bluekuja: ? [19:48] apachelogger_, do you see commented stuff in debian/rules? [19:49] bluekuja: are you looking at an old version? [19:49] http://revu.ubuntuwire.com/revu1-incoming/gcutils-0712021930/gcutils-0.0.2/debian/rules [19:49] dsop: you could remove the intro stuff though [19:50] apachelogger_, yes, that's what I mean [19:50] apachelogger_, that stuff is all commented out [19:50] so it's not needed.. [19:51] apachelogger_: okay [19:51] bluekuja: well, should dsop remove all comments? [19:51] hmm that md5sum stuff is crazy. everytime i generate a new version out of git, the md5sum differs [19:51] apachelogger_, http://pastebin.ubuntu.com/2429/ [19:52] dsop: very strange [19:52] bluekuja: ok, I agree on that :) [19:52] apachelogger_, ^^ [19:52] though #export DH_VERBOSE=1 might be handy [19:52] bluekuja: even the DH_VERBOSE line? [19:52] dsop, yeah, you can leave that if you want [19:52] it's your choice after all [19:53] * apachelogger_ likes to keep the verbose line around [19:53] dsop, remove binary-indep stuff [19:53] dsop, with comments like nothing to do by default [19:53] :) [19:54] dsop, remove *targets* only [19:54] dsop: don't forget to remove it at the very bottom as well [19:54] dsop, not the rule itself [19:54] dsop, the files are not tagged with a license header [19:54] so they cannot hit the archive [19:54] would you mind fixing it? :) [19:55] okay, so i'll remove the targets and ... whats that with the license header? [19:55] i should prepend every file with a license header? [19:55] btw. thanks for the help.. [19:56] bluekuja: so an empty binary-indep rule, that doesnot execute any targets? [19:57] dsop, a license header should be placed in every file [19:57] * apachelogger_ demands license header for everything ;-) [19:57] dsop, yes, leave the rule, clean the targets [19:57] remove the comments around the rule [19:57] every file should be as clean as possible [19:58] yes, everthing done, i just have to add the license header to every file in debian/, and to check this md5 sum thing [19:59] dsop, ? [19:59] dsop, you don't have to add license headers inside maintainers dir [19:59] dsop, but on upstream source [20:01] bluekuja: ah okay you think about license header in the *.sh files? [20:02] dsop, yes [20:02] dsop, why not GPL? [20:08] bluekuja: because i prefer bsd/mit [20:09] dsop, kk [20:14] What should I do about a merge that does not build in hardy due to missing dependencies, but builds fine in gutsy? === tonyy is now known as tonyyarusso [20:21] Hey MOTUs. === asac_ is now known as asac [20:24] heya TheMuso [20:27] What should I do about a merge that does not build in hardy due to missing dependencies, but builds fine in gutsy? [20:27] (asking again) [20:27] uhm [20:27] TheMuso: ahoy [20:27] * apachelogger_ gives TheMuso a cookie [20:28] mok0: what did happen to the dep? [20:28] apachelogger_: Congratulations. [20:28] TheMuso: hehe, thanks :) [20:28] apachelogger_: libgoffice-0-dev was not found in hardy [20:28] ... and libgtk-2.0 or some such [20:30] Perhaps I should just leave it pending until the build-depends resolve [20:30] hmmm [20:31] mok0: https://edge.launchpad.net/ubuntu/+source/goffice [20:31] it appears to be named libgoffice-0-5-dev now [20:32] jdong, what's happening with x264 ? [20:32] apachelogger_: wtf? [20:32] mok0: talk to gpocentek, he did the merge [20:32] jdong, https://edge.launchpad.net/ubuntu/hardy/+source/x264/1:0.svn20070930-0.0ubuntu2 [20:33] apachelogger_: It should not be named like that [20:33] apachelogger_: Actually, libgoffice-dev is the correct [20:34] apachelogger_: no so version in dev packages [20:34] jdong, sources are there, all bins have been removed once again [20:34] yeah [20:34] mok0: feel free to take all of gpocentek's cookies ;-) [20:34] apachelogger_: hehe [20:35] the interesting thing is in debian it's also -0-5- [20:35] http://packages.debian.org/source/sid/goffice [20:35] apachelogger_: I've never met gpocentek herer [20:36] gpocentek: please tell mok0 about the goffice merge ;-) [20:36] apachelogger_: arrrgh it comes from debian [20:36] * apachelogger_ just hopes the debian package mok0 wants to merge is depending on 0-5, else it might be hell confusing now [20:37] apachelogger_: I should have been able to find this out myself, sorry for bringing it up [20:37] no problem [20:37] * mok0 will continue merging effort [20:39] apachelogger_, bluekuja: done, hopefully... [20:40] apachelogger_: i figured out, that tar xzvf foo.tar.gz foo/ always produces different md5sums even the content of foo/ doesnt change [20:40] Oo [20:40] strange [20:40] so, who's going to testbuild? [20:40] apachelogger_: re: theseus, what's this about the needs-packaging bug? [20:40] * apachelogger_ already did for almost every upload :P [20:41] apachelogger_: Is it new policy? I've never had to before [20:41] apachelogger_: i know :), i'm really sorry that i need about 10 uploads. pretty hard to create a good package if it's your first time... [20:42] mok0: new policy, you have to create a needs-packaging bug in launchpad then assign yourself to it, then paste a revu upload and set the status to in progress, you have to close the bug in your changelog entry with (LP: #bugnumber) [20:42] then when a motu uploads it, he/she sets the status to fix commit [20:42] ed [20:42] apachelogger_: so, a bug with no package, I guess? [20:42] once it got past new queue it gets automagically changed to fix released [20:43] apachelogger_: cool [20:43] apachelogger_: I'll do it now [20:43] mok0: https://bugs.edge.launchpad.net/ubuntu/+bug/173103 [20:43] Launchpad bug 173103 in ubuntu "[needs-packaging] kirocker" [Wishlist,Confirmed] [20:44] dsop: hehe, not your fault if people keep complaining ;-) [20:48] * emgent heya [20:49] so [20:49] dsop: I'll give you the 2nd advocate, maybe someone finds something :P [20:49] still looks good to me [20:51] dsop, perfect ;) [20:51] dsop: one thing: you might want to change the download location in copyright to http://downloads.experimentalworks.net [20:53] apachelogger_: Done. But now my revu-upload has a "needs work" icon :-/ [20:54] apachelogger_: of course I can re-upload with the changelog change [20:54] dsop, well, that's not a *very* good header [20:54] ^^ [20:55] you have to re-upload with the changelog change [20:55] bluekuja: better than none, isn't it? :P [20:55] * apachelogger_ should start learning -.- [20:56] apachelogger_, lol, yes, better than none, but still wrong :) [20:56] ^_^ === Tonio__ is now known as Tonio_ [20:56] dsop, maybe you might want to look at how other upstreams handle it [20:57] e.g with the GPL [20:57] http://jldugger.livejournal.com/1968.html <-- comments welcome [20:57] apachelogger_: Is this the right syntax for changelog: [20:57] Initial release (LP: #173506) [20:58] yep [20:58] thx [20:58] will re-upload [21:08] apachelogger_: yay, now I can harvest som karma from contributing new packages :-) [21:08] s/som/some/ [21:09] mok0, unfortunately you get no karma on LP for that [21:09] bluekuja: grrr [21:09] mok0, there's a bug open and hopefully it will be fixed soon [21:10] bluekuja: ah, but _then_ I'll get karma, yes? [21:10] mok0, yep [21:10] * mok0 lusts for karam [21:10] karma [21:10] lol [21:10] mok0, only when you get a package uploaded of course :) [21:10] hehe [21:11] mok0, you won't receive karma for sending packages on REVU [21:11] :P === Nightrose2 is now known as Nightrose [21:11] bluekuja: I know, but for fixing bugs on LP [21:11] which I didn't before :-D [21:12] lol [21:12] It makes sense to let things pivot around LP, though [21:13] Although I hate the UI [21:13] mok0, which package do you have on revu? [21:13] bluekuja: theseus, and then torque, which needs work [21:14] mok0, link for theseus [21:14] http://revu.ubuntuwire.com/details.py?package=theseus [21:14] mok0, this evening me and apachelogger_ are inspired to check some packages [21:15] so you're lucky [21:15] hehe [21:15] bluekuja: cool [21:15] It's a mono-package package [21:15] k [21:15] been reviewed once by persia [21:15] apachelogger_, take a look at it as well [21:18] mok0, +The ncbi_math.h and ncbi_math.c are in the public domain, and distrbuted [21:18] fix that [21:19] mok0, but wait more comments [21:19] bluekuja: it's written in copyright [21:19] mok0, yes [21:19] mok0, remove commented stuff from debian rules [21:19] bluekuja: ok [21:20] bluekuja: yes, but i thing its enough. i don't want to include 30lines of header into a small shell script [21:20] bluekuja: you mean the comments at the top? [21:20] mok0, yes [21:20] dsop, just your copyright there [21:21] dsop, e.g Copyright (c) year-year name email [21:21] or whatever [21:21] bluekuja: the public domain files, well enough documented? [21:22] mok0, huh? [21:22] mok0, also why do you remove configure-stamp if there isnt a configure rule? [21:23] bluekuja: you said something about the ncbi_math etc. [21:23] mok0, plus configure seems to be on PHONY as well [21:23] mok0, no, comments in debian/rules [21:23] * mok0 is confused [21:24] mok0, ah yea [21:24] mok0, that's in the copyright [21:24] distrbuted/ distributed [21:25] bluekuja: Arghh using the spellchecker is on my list [21:25] ^^ [21:26] mok0, I think comments like "# Compile THESEUS!" are not really needed^^ [21:26] bluekuja: you are right. [21:27] bluekuja: so, you don't like comments in debian/rules at all, huh [21:27] mok0, yes [21:27] mok0, only if really needed to explain a certain command or rule [21:28] but that's not your case [21:28] mok0, remove configure stuff [21:28] in clean, PHONY [21:28] bluekuja: so "clean up after build process" is ok [21:28] mok0, adding that in the clean rule? [21:28] bluekuja: no it's there [21:29] mok0, remove that please [21:29] bluekuja: sure thing :-) [21:30] bluekuja: only 1 comment left in rules [21:30] bluekuja: plus my standard #### at the end :-) [21:30] mok0, is that needed? [21:30] :) [21:30] bluekuja: it's my tag :-) [21:31] mok0, lol [21:31] mok0, remove that! [21:31] mok0, jk [21:31] ;) [21:31] bluekuja: aye-aye sir [21:32] lol [21:32] bluekuja: I'll put my emacs stuff before eof, then [21:33] mok0, if you want to keep that "tag", you can [21:33] don't worry [21:33] * mok0 thanks bluekuja :-) [21:34] mok0, :) [21:34] bluekuja: so, I've only made mods to rules, anything else? [21:34] mok0, that's the only file, I've checked for now [21:34] :) [21:34] Cool [21:34] mok0, need to finish something and then I go to sleep [21:34] I'll reupload [21:35] mok0, did you note configure stuff as well? [21:35] remove configure from .PHONY? [21:36] I did that [21:36] bluekuja: meh, so I have to revu again on my own -.- [21:37] * apachelogger_ continues learning for his business economics exam [21:37] apachelogger_, lol [21:37] mok0, not only [21:37] mok0, any configure related stuff [21:37] bluekuja: theseus doesn't use configure [21:38] bluekuja: It's upstreams handcrafted make [21:38] file [21:38] makefile [21:38] mok0, that's why I said you to remove configure stuff from rules file [21:38] :) [21:38] e.g in clean [21:39] hi [21:39] Ah. Missed that. Now gone [21:39] Ubulette: consult an archive admin regarding status of x264 -- I've heard it's STILL related to some LP bug.... [21:42] re-uploaded -> REVU [21:43] bluekuja: Thanks a lot [21:43] mok0, np [21:43] mok0, have a good night [21:43] bluekuja: You too [21:43] mok0, tnx [21:47] bluekuja, apachelogger_: okay another try....it's getting really hard :) [21:49] after years of software development, i never thought that I'll feel as dumb as a kiddie [21:50] heh. I think if you don't feel like a kid, then you're approaching software development incorrectly. [21:50] dsop: from being part of the amarok team, I can totally reproduce teh feeling as dumb as a kiddie part :P [21:52] apachelogger_: while packaging or while developing? what are you developing in amarok, doc, engine, gui? [21:53] dsop: manging [21:53] in any kind [21:53] though, it doesn't really matter what you do @amarok you always have a very strange feeling while doing it ;-) [21:54] hehe, same in the php dev team, where i'm involved [21:55] how do you know if a source packages need to create more than one .deb file? can someone tell me a example of program with various deb files? [21:55] dcordero: a library for example [21:56] in most cases you just need the library itself, but if you want to compile something or develop or both, you'll need the headers [21:56] so it makes sense to split into libfoobar0 and libfoobar-dev as the latter isn't needed all that much [21:57] i see [21:57] now i understand [21:57] thanks [21:57] you're welcome [21:58] mok0: ye know, I actually didn't intent on revuing theseus :P [21:59] apachelogger_: I got a lot of input from bluekuja. I think the package is near ready to go. [22:00] apachelogger_: Don't worry, I think I can get a couple of sponsors [22:00] mok0: oh, shall I turn nazi revu mode on? :P [22:00] then you'll see how ready it is ;-) [22:00] Mez: around? [22:00] apachelogger_: I dare you :-) [22:03] mok0: standards-version: 3.7.2.2 please [22:03] apachelogger_: I looked for it, where is it published? [22:03] mok0: http://www.debian.org/doc/debian-policy/index.html [22:05] apachelogger_: ok, ok, it's 3.7.2.2 :-/ [22:05] mok0: please insert an empty line before Upstream Author [22:05] and remove the 2nd one at the end of the author list [22:06] mok0: any specific reason to provide 4 mail addresses? [22:06] apachelogger_: nah, I wasn't sure which one was the best one to use, but I do now, actually. [22:07] okay [22:07] apachelogger_: I'll clean them [22:07] apachelogger_: ... so 2 empty lines after author: section ? [22:07] nah [22:07] one [22:08] one before the actual statement Upstream Author: [22:08] right now at the end are 2, should be one [22:08] apachelogger_: yes that looked dumb [22:08] totally :P [22:08] mok0: unnecessary white space in copyright's line 62 [22:09] apachelogger_: lol, that's nazi revuing alright [22:09] mok0: line 71 exceeds 80 characters [22:09] mok0: I told you so :P [22:10] apachelogger_: space check done. [22:10] mok0: adding a copyright/license header to the getexamples might be a good idea [22:11] apachelogger_: I was wondering about that. I sent the script upstream but he didn't put it in the tarball. [22:11] well, make it branded to you ;-) [22:11] ... what about getvers.awk ?? :-) [22:12] not license worthy [22:12] ap [22:12] apachelogger_: WHAT? It's my greatest creation [22:12] omg, now that sounds pathetic -.- [22:12] if it means that much, note it as much in debian/copyright [22:13] mok0: it's up to you of course ;-) [22:13] argh what happened to x264? [22:13] apachelogger_: I've never dealt with a nazi reviewer before, so better safe than sorry [22:14] jdong, did you steal it? [22:14] mok0: lol, good point [22:14] hmm? It's at https://edge.launchpad.net/ubuntu/hardy/+source/x264/1:0.svn20070930-0.0ubuntu2 [22:14] hm packages.ubuntu.com doesn't seem to think so for hardy [22:14] s/edge\.//, though I doubt you're not an LP beta member [22:14] http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=x264&searchon=names&subword=1&version=hardy&release=all [22:15] oh according to that changelog though it was accidently removed from the archive [22:15] that would explain it [22:15] https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=x264 [22:16] okay thanks :) [22:16] I also would refrain from using packages.uc for canonical status; lp is more current [22:17] mok0: awk: debian/getvers.awk: line 1: syntax error at or near , [22:17] p.u.c is just a little quicker for me since i've got a little box in FF search bar that searches it. i'll be mindful for that though [22:18] apachelogger_: what awk are you using? [22:18] I'm surprised apachelogger_ hasn't gone pedantic on ^Description [22:18] apachelogger_: works for me [22:18] * mok0 shivers [22:18] crimsun: didn't read that yet :P [22:18] mok0: well, maybe my pbuilder is silly [22:18] mok0: nuke dh_link [22:18] doesn't do anything [22:19] apachelogger_: right [22:19] apachelogger_: fixperms neither, for that matter :-) [22:19] actually [22:20] fixperms does do something :P [22:20] apachelogger_: perhaps it depends on the umask [22:20] *shrug* [22:20] better have permissions fixed than not :P [22:20] apachelogger_: yeah [22:20] mok0: any good reasony for the ####? [22:21] apachelogger_: it's my tag. bluekuja let me keep it ;-) [22:21] mok0: was he in nazi mode? :P [22:21] apachelogger_: what's with the awk script? [22:22] mok0: why? [22:22] mok0: if your rules uses awk than you need it as a build-depends (its not part an essential package) [22:22] apachelogger_: you talked about syntax error; [22:22] norsetto: that would explain my error I guess [22:22] mok0: or consider using mawk (which is an essential package) [22:23] mok0: or just use sed :-) [22:23] norsetto: ah! thanks, good idea [22:23] * jussi01 wonders what the qmake command for qt4 is in ubuntu? [22:23] norsetto: I need a pipe, so with awk we only have to create 1 process. :-) [22:24] jussi01: qmake-qt4 [22:24] norsetto: with sed I will need a pipe [22:24] apachelogger_: thank you [22:24] you're welcome [22:24] mok0: yes ... and ... are we short of them? [22:24] mok0: unnecessary white space in copyright file, line 17, 2007 Douglas [22:25] and remind me if you will which libs i need for qt4 -dev stuff? [22:25] norsetto: nah, I just that I like awk a lot [22:25] mok0: well, then add it as a build-deps or use mawk [22:26] apachelogger_: you mean between "2007" and "Douglas"? [22:26] yes [22:26] mok0: please update debianized time in copyright to the one in changelog [22:26] * mok0 tests mawk [22:26] apachelogger_: god damn [22:27] meh [22:27] moo [22:27] apachelogger_: it's dh_make's fault! [22:27] so kick it [22:27] dh_make is horrible [22:27] * apachelogger_ uses his own templates [22:28] much faster [22:28] mok0: I'd rather not see rules, line 19, exceed 80 characters [22:28] apachelogger_: you mean, if someone decides to punch it out on cards? [22:29] nah, if someone wants to edit it on a small console [22:29] mok0: 2 unnecessary white spaces in changelog, line 14 [22:30] mok0: 1 unnecessary new line at the very end of control [22:30] * apachelogger_ reads description [22:31] hum, is superpositioning actually a valid word? [22:31] apachelogger_: yes [22:31] apachelogger_: but perhaps not the best languae. [22:32] language [22:32] well, IMO the description is too complex [22:32] should be very easy to understand, so that everyone can evaluate whether he/she wants to read the extended-description or not [22:32] personal opinion though [22:33] apachelogger_: yeah, perhaps. It's a description for people who know what the program is for [22:33] apachelogger_: I'll see if I can improve it [22:33] mok0: which isn't really what a description is for, is it? :P [22:33] apachelogger_: are you saying it's so people can decide that they don't want to use this program ;-) [22:34] kinda, it aims a very special audience [22:34] apachelogger_: you are right. 'll work on it. === nightrose3 is now known as Nightrose [22:36] norsetto: I think the new elisa is a sync. If you have a hopeful whoe could use the practice to check/test, please go for it. [22:37] scottk: why not assigning it to yourself as a mentor? [22:37] ScottK: wait, there is no bug report yet, right? [22:38] norsetto: Right. I just saw it on DaD. [22:38] apachelogger_: http://pastebin.ubuntu.com/2435/ [22:38] very special purpose apps go priority extra, right? [22:39] mok0: looks good [22:39] apachelogger_: Not exactly. [22:39] scottk: the best would be to send an email to ubuntu-motu-mentors, but since you refuse to do that, just send it to ubuntu-motu, some contributor will pick it up [22:39] Well I'm not subscribed to mentors, so it'd just be moderated anyway. [22:39] Isn't the optional/extra distinction that those in extra can conflict with others? [22:40] Those in extra Conflict with some in optional [22:40] Right, that's what I thought. [22:40] Fujitsu: Something like that. It's explicitly defined in I don't remember where exactly. [22:40] It's defined in Debian Policy [22:40] StevenK: I thought it was conflict with or could be confused with both. [22:40] ScottK: so, what does that last part mean?: This contains all packages that conflict with others with required, important, standard or optional priorities, or are only likely to be useful if you already know what they are or have specialized requirements. [22:41] apachelogger_, norsetto: grrrrrr, mawk gives the syntax error... [22:41] apachelogger_: As an example, gnupg and gnupg2 do not conflict. [22:41] mok0: then b-d explicitly on gawk [22:41] mok0: yes, thats what I meant, you have to adapt it to mawk [22:41] apachelogger_: gnupg2 is extra because it could be confused with gnupg and it's the preferred one to use. [22:42] ScottK: ah, I think I got it, thanks :) [22:42] crimsun: thx. I'll invoke it as gawk, than === jekil2 is now known as jekil [22:43] mok0: I'm only half-paying attention. If you need it to generate binaries correctly, use a b-d. [22:43] crimsun: I got the hint I needed :-) [22:43] * apachelogger_ is afraid [22:44] apachelogger_: OK nazipachelogger, got more? :-D [22:45] mok0: you might suggest upstream to update his FSF addresses in the license statements [22:45] apachelogger_: I can patch them [22:46] nah, no need [22:46] upstream should fix this [22:46] * txwikinger feels offended [22:46] txwikinger: why that? [22:46] all this raising of the German history is not very respectful [22:47] -.- [22:47] mmkay. [22:47] * Fujitsu suspected that would come up. [22:47] s/nazi/pedantic /, then [22:47] txwikinger: respectful, to whom? [22:47] right [22:47] txwikinger: apachelogger_ [22:47] also, there are bigger fish to fry, so whatever. [22:47] txwikinger: and I have been bullshitting for a while [22:47] well mok0 I am sorry [22:48] mok0: in coypright you should write "The libdltmath/ncbi_math.h and libdltmath/ncbi_math.c .." since they aren't in ./ :P [22:48] apachelogger_: touché [22:48] * apachelogger_ suspects that everyone was just waiting for something to bring up the history thing [22:48] Well I'll just juump in and say that I was moderately uncomfortable with the use of the term, but wasn't going to mention it. [22:48] apachelogger_: Yes. [22:49] we never use that again [22:49] pedantic sounds better anyway [22:49] muahaha [22:49] It's also accurate. [22:49] and we wont mention the soup-xxxx [22:49] mok0: That's a special case. I don't mind that one. [22:50] mok0: have you considered joining debichem? [22:50] norsetto: I've never heard about it [22:50] In fact, I've had my hands full getting to know ubuntu [22:51] and getting to know some people here [22:51] mok0: its a small group in debian who is interested in packaging and maintaining chemistry related packages [22:51] mok0: DLTmath.h is inculding code from ncbi_math.h, hence partly PD [22:51] se line 1541 [22:51] apachelogger_: ok [22:51] superm1_: Are you interested in seeing if we can sync elisa from Debian? [22:52] mok0: that file actually appears twice [22:52] libdistfit/ and libdltmath/ [22:52] norsetto: I'll check it out. I've been packaging some science packages that we use in my lab. I got a few into gutsy, thanks to ScottK and others [22:53] mok0: same applies for libdistfit/distfit.h [22:53] ScottK, is it stable yet? [22:53] norsetto: I know for a fact that lots of people in my field are starting to use ubuntu [22:53] mok0: DLTmath.h and distfit.h also appea in the main directory [22:53] ok [22:53] mok0: that's it [22:53] can't find anymore issues :P [22:54] * apachelogger_ now needs a cigarette [22:54] mok0: I see a little problem [22:54] superm1_: It look like the same thing we already have. [22:54] apachelogger_: Well, you deserve it you really _are_ a na^H^Hpedantic [22:54] It's the same upstream version and I think it has all the Ubuntu changes in it. [22:54] mok0: your package ships a pdf file without the "preferred form of modification"I think [22:54] norsetto: what's that? [22:55] oh [22:55] I agree [22:55] mok0: It needs to be something editable. [22:55] Like, no PDFs? [22:55] well [22:55] Whatever the 'source' for the PDF is. [22:55] like the source of the PDF [22:55] I don't think the source is there [22:55] that's the problem [22:56] mok0: upstream has to include a source for the PDF [22:56] or remove the pdf [22:56] apachelogger_: that's silly [22:56] and, ScottK may correct me on this, if he doesn't want to do either you should probably repack the tarball [22:56] mok0: no, thats GPL [22:56] ScottK, yeah looking over a debdiff from us to them, it looks like we should be able to [22:56] i'll do a test build and see [22:56] superm1_: Thanks. [22:57] hm [22:57] so no docs is better than pdfs? [22:57] mok0: If you don't have the source, then it's not distributable. You can repack the tarball with an alternative form. [22:57] He probably wrote it in MS-Word or something [22:58] Which, if you had it, you could easily convert to ODF and include. [22:58] well, get the doc and convert it to odt, or he might export the msword doc to html [22:58] apachelogger_: Does it need a license clause inside? [22:58] oh [22:59] actually it was created with groff [22:59] mok0: Ideally yes. [22:59] apachelogger_: Is the groff source present? [22:59] thats a gnu thingy [22:59] http://www.gnu.org/software/groff/ [22:59] Ah, it's the groff formatted man page [22:59] mok0: btw, you are not installing it [22:59] so the source _is_ there [23:00] norsetto: now I remember: I thought it was redundant [23:00] mok0: its possible, I didn't check it [23:00] norsetto: I did [23:00] yep [23:01] the pdf is just an export of the man page [23:01] issue resolved [23:01] apachelogger_: yes [23:01] mok0: so, just get rid of it from the tarball [23:01] phew [23:01] norsetto: why can't it stay? [23:01] norsetto: why? [23:01] If it's generated from source that's provided it [23:01] good night [23:01] is fine [23:01] good night RainCT [23:02] ScottK: after all the "zomg! you shouldent have said anything" comments there is some actual meat there now :) [23:02] mok0: whats the source then? [23:02] norsetto: I can provide a script to generate it [23:02] norsetto: theseus.1 [23:02] ScottK: the debian vmware psudo package mantainer even chimed in with some data [23:02] norsetto: without my patcches [23:02] mok0: ok, if thats the case than issue is solved [23:03] imbrandon: Cool. I'm looking now. [23:03] http://revu.ubuntuwire.com/revu1-incoming/theseus-0712022250/theseus-1.1.5/theseus.1 -> http://revu.ubuntuwire.com/revu1-incoming/theseus-0712022250/theseus-1.1.5/theseus_man.pdf [23:03] **phew** [23:03] mok0: now get everything else sorted out! :P [23:03] I was keeping up with you until the PD stuff [23:03] * apachelogger_ heads outside meanwhile [23:04] * mok0 scrolls back [23:04] * mok0 is releaved after fighting off 3 MOTUs :-) [23:04] basically you have the 2 PD files from before plus some files which include the .h [23:04] mok0: lol [23:04] afk [23:05] hehe, love this: HISTORY: Long, tedious, and sordid. [23:05] norsetto: yes, it's funny [23:05] mok0: funny guys you alchimists ..... [23:05] norsetto: lol [23:06] norsetto: I will try to get xtide processed tomorrow [23:06] mok0: sure [23:06] imbrandon: It looks good. It would have been better not to put it on p.d.o though. [23:06] its not [23:07] well not after the first hour ( feedburner screwed me ) [23:08] mok0: you should compile with the -g flag [23:10] imbrandon: OK. Good. [23:10] imbrandon: Looks like Christer Edwards kind of changed his tune too. [23:10] ahh i dident see that one yet /me looks [23:11] hrm i only see once comment from him [23:11] #5 [23:13] Ooh, we're lazy because we don't upgrade packages in stable releases. [23:14] Watch out, we're going to be replaced. [23:14] ScottK: can you please have a look at bug 173532 [23:14] Launchpad bug 173532 in feisty-backports "please backport psi 0.11" [Undecided,New] https://launchpad.net/bugs/173532 [23:16] looks like they missed out on some important information, like a feisty pbuilder log [23:16] and that they actualy tested it etc [23:17] imbrandon: he's more like a user ;-) [23:18] apachelogger_: yea but i'm still not gonna ack it untill those are done by $someone :) [23:19] * apachelogger_ feels like he has to do that :P [23:19] heh, dinner time, bbiab [23:19] apachelogger_: re the PD files, it looks like he relicensed them as GPL [23:20] mok0: huh? [23:20] apachelogger_: Not right now. Headed out for a while. [23:20] apachelogger_: ncbi_math.* have both GPL and PD license in them [23:21] apachelogger_: so I should be able to get rid of the extra complication in copyright [23:22] can one actually do that? [23:22] apachelogger_: of course. It's in the public domain [23:22] *shrug* [23:22] apachelogger_: and the guy is american [23:22] I'm not really into PD stuff :P [23:22] mok0: still I think you should mention it [23:22] mok0: ok, I see the problem, you define CFLAGS but you don't pass it to make [23:23] If it's exported, it should be okay [23:23] stevenk: its not [23:23] apachelogger_: AFAIK it only has a meaning in the US¨ [23:23] *shrug* [23:23] norsetto: right. it's not used, I should get rid of it [23:23] archive admins will reject it if they don't like :P [23:24] mok0: well, then you don't pass the -g flag as you should [23:24] norsetto: hang on... [23:25] norsetto: why do you need -g? We strip symbols anyway [23:25] norsetto: look in patches/200-make.inc.dpatch [23:26] mok0: yes, I don't see it there, as I didn't see it in the build log === nuu is now known as nu === nu is now known as nuu [23:26] norsetto: I don't understand why -g is needed [23:26] norsetto: We always use dh_strip [23:27] mok0: yes, thats the policy [23:27] norsetto: so first create symbols, then strip them from the exe? That's stupid [23:28] mok0: So that those debugging symbols can be split off by the buildds [23:28] norsetto: and doesn't -g turn off optimization [23:28] mok0: no [23:29] norsetto: ok, I'll put -g in there, then [23:30] btw, what's the minimum 86 platform we build for? i486? i586? [23:30] i486 [23:30] i386 gets emulated or something strange [23:31] StevenK: so is there a -march required cf. policy? [23:32] Don't pass one, let the compiler make up it's own mind [23:32] StevenK: ok [23:32] * norsetto is pondering going to bed === azeem_ is now known as azeem [23:44] why does i386 get emulated? [23:45] i386 is built natively [23:45] * mok0 thinks that i486 code will not run on an old 386 machine [23:46] well mok0 if there are opcodes that are not part of the i386 opcode set that this is correct [23:46] txwikinger: Emulated in libc ... [23:46] StevenK: errr...? [23:47] StevenK: there is more code in a program than library calls [23:47] You call an i486 op code on an i386, it throws SIGILL, libc traps the SIGILL and deals [23:47] Keep in mind, this is going back *years*, and is based on Debian knowledge [23:48] StevenK: got it [23:48] it should be all done with the compiler options [23:49] gcc can compile and optimise according to the opcode set that is given to it [23:50] I thought it was libc that dropped support for i386 then [23:50] * StevenK shrugs. Who knows [23:50] http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/i386-and-x86-64-Options.html [23:50] It wasn't about the compiler, it was about libc, I remember that much. [23:52] There is a _lot_ to be gained > 10% on when compiling with --target=athlon for that target [23:52] on execution speed [23:52] aren't there different packages for i386 and i686? [23:52] no [23:53] I386 packages need to be built for the lowest common denominator. [23:53] mok0: Yes, but no one has come up with benchmarks and metrics that show the real difference, it's all conjecture and "my gentoo goes faster" [23:53] Some packages, i.e. atlas, is available for the various platforms [23:54] StevenK: I have tried to benchmark it on the same machine. [23:54] http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=libc&searchon=names&subword=1&version=gutsy&release=all [23:54] Which isn't reproducible for other people [23:54] there is a libc for i386 and one optimised for i686 [23:54] StevenK: why not? [23:54] mok0: Because they don't have your machine? [23:55] If they have a K7 or K8 CPU it will [23:55] They may not have your stepping or CPU speed [23:55] norsetto, ping [23:55] if you're still awake [23:55] This is my point, it's quite machine-specific [23:56] StevenK: I agree that the speed gain may not be the same percentage, but you get more efficient code nonetheless [23:56] that may or may not work for everyone [23:56] Right [23:56] lowest common denom [23:56] StevenK: The compiler can make special optimization for the athlon platform [23:57] mok0: Which will just give SIGILLs on the Pentium I use as a firewall [23:57] StevenK: you also get faster code when compiling with -march=i686 [23:57] mok0: and that screws those like me that have no AMD chips and / or use non x86 [23:57] superm1_: barely :-) [23:57] well maybe someone else can field an answer. i saw that norsetto added a patch to vlc on gutsy that fixed it from opening multiple instances from multiple files by having it call wxvlc %F. Well upstream now ships with a %U in the field of the .desktop file by default, so i'm not sure what the appropriate thing to do is. what does the %U vs %F change? [23:57] oh hi norsetto [23:58] maybe you will know then [23:58] imbrandon: we would need a new arch [23:58] != i386 [23:58] Sorry, I don't know anything about i386 - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [23:58] Ha [23:58] ubotu: Shut up [23:58] Sorry, I don't know anything about shut up - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [23:58] hehe [23:58] mok0: ok come up with hard reporduceable numbers and propose it, but i doubt that will happen [23:58] imbrandon: no kidding? [23:59] superm1_: yes, I remember that [23:59] norsetto: I thought you'd gone to bed... [23:59] mok0: struggling but keeping the position